IP - Історія редагувань

Aleksey в 20:56, 18 грудня 2011

2011-12-18T20:56:12Z

Мусієнко Тетяна в 10:48, 7 квітня 2009

2009-04-07T10:48:56Z

Мусієнко Тетяна в 10:45, 7 квітня 2009

2009-04-07T10:45:28Z

Мусієнко Тетяна в 10:42, 7 квітня 2009

2009-04-07T10:42:51Z

Hiss в 09:52, 24 грудня 2008

2008-12-24T09:52:31Z

Hiss в 18:38, 4 грудня 2008

2008-12-04T18:38:51Z

Показати зміни

Hiss в 18:32, 4 грудня 2008

2008-12-04T18:32:49Z

Hiss в 19:22, 3 грудня 2008

2008-12-03T19:22:14Z

Hiss в 17:42, 3 грудня 2008

2008-12-03T17:42:56Z

Hiss в 17:40, 3 грудня 2008

2008-12-03T17:40:37Z

Нова сторінка

Міжмережевий протокол '''IP''' специфікований у RFC 791. Це самий фундаментальний протокол з комплекту TCP/IP - передає IP-дейтаграми по інтрамережі і виконує важливу функцію, що називається маршрутизацією, по суті справи це вибір маршруту, по якому дейтаграма буде випливати з пункту А в пункт B, і використання маршрутизаторів для "стрибків" між мережами.

Його основні характеристики перераховані нижче:
реалізує обмін інформації пакетами, які будемо називати IP-сегментами (максимальний розмір IP-сегмента - 65535 байт);
є протоколом взаємодії без установлення логічного з'єднання;
для адресації вузлів мережі використовується адреса довжиною 4 байти;
забезпечує в разі потреби фрагментацію IP-сегментів;
IP-сегменти мають кінцевий час життя в мережі;
не гарантує надійність доставки IP-сегментів адресату;
не має засобів керування інтенсивністю передачі IP-сегментів стороною, що посилає, (flow control);
не гарантує правильну послідовність IP-сегментів на приймаючій стороні.

Отже, IP - ненадійний протокол, що надає сервіс доставки датаграмм без з'єднання.

Під словом ''ненадійний'' ми маємо на увазі те, що не існує гарантії того, що IP датаграмма успішно досягне пункту призначення. Однак IP надає визначений сервіс обробки деяких подій. Коли що-небудь йде не так як хотілося б, як наприклад, тимчасове переповнення буфера в маршрутизатора, IP застосовує простий алгоритм обробки помилок: він відкидає датаграмму і намагається послати ICMP повідомлення відправникові. Будь-яка необхідна надійність повинна бути забезпечена верхніми рівнями (наприклад TCP).

Термін ''без з'єднання'' (connectionless) означає, що IP не містить ніякої інформації про просування датаграмм. Кожна датаграмма обробляється незалежно від інших. Це також означає, що може бути доставлена зіпсована датаграмма. Якщо джерело відправляє дві послідовні датаграммы (перша A, потім B) в один і те ж пункт призначення, кожна з них маршрутизується незалежно і може пройти по різних маршрутах, датаграмма B може прибути раніше за A.

IP заголовок

На малюнку показаний формат IP датаграми. Стандартный розмір IP заголовка складає 20 байт, якщо нема опцій.

[[category:Комп'ютерні мережі]]

@@ Рядок 29: / Рядок 29: @@
 біта TOS наступні: мінімальна затримка, максимальна пропускна здатність, максимальна надійність і мінімальна вартість. Тільки один з цих 4 біт може бути встановлений в одиницю одночасно. Якщо всі 4 біти рівні 0, це означає звичайний сервіс. RFC 1340 [Reynolds and Postel 1992] указує, як ці біти повинні бути встановлені для всіх стандартних додатків. RFC 1349 [Almquist 1992] містить деякі корекції для цього RFC і більш детальний опис характеристики TOS.
-''Діалогові додатки'', Telnet і Rlogin, вимагають звести до мінімуму затримку, тому що вони використовуються людиною інтерактивно і здійснюють невелику передачу даних. Передача файлів з використанням FTP, з іншого боку, вимагає максимальної пропускної здатності. Максимальна надійність необхідна для мережного керування (SNMP) і для протоколів маршрутизації. Новини Usenet (NNTP) - це єдиний додаток, що вимагає мінімізації вартості.
+''Діалогові додатки'', Telnet і Rlogin, вимагають звести до мінімуму затримку, тому що вони використовуються людиною інтерактивно і здійснюють невелику передачу даних. Передача файлів з використанням FTP, з іншого боку, вимагає максимальної пропускної здатності. Максимальна надійність необхідна для мережного керування ([[SNMP]]) і для протоколів маршрутизації. Новини Usenet (NNTP) - це єдиний додаток, що вимагає мінімізації вартості.
 ''Поле повної довжини'' (total length) містить повну довжину IP датаграми в байтах. Завдяки цьому полю і полю довжини заголовка, ми знаємо, з якого місця починаються дані в IP датаграмі і їхню довжину. Тому що це поле складається з 16 біт, максимальний розмір IP датаграми складає 65535 байт.  Це поле змінюється в момент фрагментації і повторної зборки датаграми.
-Незважаючи на то що існує можливість відправити датаграму розміром 65535 байт, більшість канальних рівнів поділять подібну датаграму на фрагменти. Більш того, від хоста не потрібно приймати датаграму розміром більше за 576 байт. TCP поділяє користувацькі дані на частині, тому це обмеження звичайно не робить впливу на TCP. Що стосується UDP, послугами якого користуються багато додатків (RIP, TFTP, BOOTP, DNS, SNMP), те він обмежує себе 512 байтами користувацьких даних, що навіть менше обмеження в 576 байт. Більшість додатків у даний час (особливо ті, котрі підтримують NFS - Network File System) дозволяють використовувати IP датаграму розміром 8192 байта.
+Незважаючи на то що існує можливість відправити датаграму розміром 65535 байт, більшість канальних рівнів поділять подібну датаграму на фрагменти. Більш того, від хоста не потрібно приймати датаграму розміром більше за 576 байт. TCP поділяє користувацькі дані на частині, тому це обмеження звичайно не робить впливу на TCP. Що стосується UDP, послугами якого користуються багато додатків (RIP, TFTP, BOOTP, DNS, [[SNMP]]), те він обмежує себе 512 байтами користувацьких даних, що навіть менше обмеження в 576 байт. Більшість додатків у даний час (особливо ті, котрі підтримують NFS - Network File System) дозволяють використовувати IP датаграму розміром 8192 байта.
 Однак, поле повної довжини потрібно в IP заголовку для деяких каналів (як наприклад, Ethernet), що доповнює маленькі фрейми до мінімальної довжини. Незважаючи на те що мінімальний розмір фрейму Ethernet складає 46 байт (малюнок 2.1), IP датаграма може бути ще менше. Якщо поле повної довжини не було представлено, IP рівень не буде знати, скільки 46-байтных фреймів Ethernet вийде з IP датаграми.

@@ Рядок 31: / Рядок 31: @@
 ''Діалогові додатки'', Telnet і Rlogin, вимагають звести до мінімуму затримку, тому що вони використовуються людиною інтерактивно і здійснюють невелику передачу даних. Передача файлів з використанням FTP, з іншого боку, вимагає максимальної пропускної здатності. Максимальна надійність необхідна для мережного керування (SNMP) і для протоколів маршрутизації. Новини Usenet (NNTP) - це єдиний додаток, що вимагає мінімізації вартості.
-''Поле повної довжини'' (total length) містить повну довжину IP датаграммы в байтах. Завдяки цьому полю і полю довжини заголовка, ми знаємо, з якого місця починаються дані в IP датаграмі і їхню довжину. Тому що це поле складається з 16 біт, максимальний розмір IP датаграми складає 65535 байт.  Це поле змінюється в момент фрагментації і повторної зборки датаграми.
+''Поле повної довжини'' (total length) містить повну довжину IP датаграми в байтах. Завдяки цьому полю і полю довжини заголовка, ми знаємо, з якого місця починаються дані в IP датаграмі і їхню довжину. Тому що це поле складається з 16 біт, максимальний розмір IP датаграми складає 65535 байт.  Це поле змінюється в момент фрагментації і повторної зборки датаграми.
 Незважаючи на то що існує можливість відправити датаграму розміром 65535 байт, більшість канальних рівнів поділять подібну датаграму на фрагменти. Більш того, від хоста не потрібно приймати датаграму розміром більше за 576 байт. TCP поділяє користувацькі дані на частині, тому це обмеження звичайно не робить впливу на TCP. Що стосується UDP, послугами якого користуються багато додатків (RIP, TFTP, BOOTP, DNS, SNMP), те він обмежує себе 512 байтами користувацьких даних, що навіть менше обмеження в 576 байт. Більшість додатків у даний час (особливо ті, котрі підтримують NFS - Network File System) дозволяють використовувати IP датаграму розміром 8192 байта.

@@ Рядок 38: / Рядок 38: @@
 ''Поле ідентифікації'' (identification) унікально ідентифікує кожну датаграму, відправлену хостом. Значення, що зберігається в полі, звичайно збільшується на одиницю з посилкою кожної датаграми.
-Поле часу життя (TTL - time-to-live) містить максимальну кількість пересилань (маршутизаторів), через які може пройти датаграма. Це поле обмежує час життя датаграми. Значення установлюється відправником (як правило 32 або 64) і зменшується на одиницю кожним маршрутизатором, що обробляє датаграму. Коли значення в полі досягає 0, датаграмма видаляється, а відправник повідомляється про це за допомогою ICMP повідомлення. Подібний алгоритм запобігає зацикленню пакетів у петлях маршрутизації.
+Поле часу життя (TTL - time-to-live) містить максимальну кількість пересилань (маршутизаторів), через які може пройти датаграма. Це поле обмежує час життя датаграми. Значення установлюється відправником (як правило 32 або 64) і зменшується на одиницю кожним маршрутизатором, що обробляє датаграму. Коли значення в полі досягає 0, датаграма видаляється, а відправник повідомляється про це за допомогою ICMP повідомлення. Подібний алгоритм запобігає зацикленню пакетів у петлях маршрутизації.
 ''Поле протоколу'' (protocol) вказує, який протокол відправив дані через IP.

@@ Рядок 11: / Рядок 11: @@
 - не гарантує правильну послідовність IP-сегментів на приймаючій стороні.
-Отже, IP - ''ненадійний протокол, що надає сервіс доставки датаграмм без з'єднання''.
+Отже, IP - ''ненадійний протокол, що надає сервіс доставки датаграм без з'єднання''.
-Під словом ''ненадійний'' ми маємо на увазі те, що не існує гарантії того, що IP датаграмма успішно досягне пункту призначення. Однак IP надає визначений сервіс обробки деяких подій. Коли що-небудь йде не так як хотілося б, як наприклад, тимчасове переповнення буфера в маршрутизатора, IP застосовує простий алгоритм обробки помилок: він відкидає датаграмму і намагається послати ICMP повідомлення відправникові. Будь-яка необхідна надійність повинна бути забезпечена верхніми рівнями (наприклад TCP).
+Під словом ''ненадійний'' ми маємо на увазі те, що не існує гарантії того, що IP датаграма успішно досягне пункту призначення. Однак IP надає визначений сервіс обробки деяких подій. Коли що-небудь йде не так як хотілося б, як наприклад, тимчасове переповнення буфера в маршрутизатора, IP застосовує простий алгоритм обробки помилок: він відкидає датаграму і намагається послати ICMP повідомлення відправникові. Будь-яка необхідна надійність повинна бути забезпечена верхніми рівнями (наприклад TCP).
-Термін ''без з'єднання'' (connectionless) означає, що IP не містить ніякої інформації про просування датаграмм. Кожна датаграмма обробляється незалежно від інших. Це також означає, що може бути доставлена зіпсована датаграмма. Якщо джерело відправляє дві послідовні датаграммы (перша A, потім B) в один і те ж пункт призначення, кожна з них маршрутизується незалежно і може пройти по різних маршрутах, датаграмма B може прибути раніше за A.
+Термін ''без з'єднання'' (connectionless) означає, що IP не містить ніякої інформації про просування датаграм. Кожна датаграма обробляється незалежно від інших. Це також означає, що може бути доставлена зіпсована датаграма. Якщо джерело відправляє дві послідовні датаграми (перша A, потім B) в один і те ж пункт призначення, кожна з них маршрутизується незалежно і може пройти по різних маршрутах, датаграма B може прибути раніше за A.
 '''''IP заголовок'''''.На малюнку показаний формат IP датаграми. Стандартный розмір IP заголовка складає 20 байт, якщо нема опцій.
@@ Рядок 38: / Рядок 38: @@
 ''Поле ідентифікації'' (identification) унікально ідентифікує кожну датаграму, відправлену хостом. Значення, що зберігається в полі, звичайно збільшується на одиницю з посилкою кожної датаграми.
-Поле часу життя (TTL - time-to-live) містить максимальну кількість пересилань (маршутизаторов), через які може пройти датаграма. Це поле обмежує час життя датаграми. Значення установлюється відправником (як правило 32 або 64) і зменшується на одиницю кожним маршрутизатором, що обробляє датаграму. Коли значення в полі досягає 0, датаграмма видаляється, а відправник повідомляється про це за допомогою ICMP повідомлення. Подібний алгоритм запобігає зацикленню пакетів у петлях маршрутизації.
+Поле часу життя (TTL - time-to-live) містить максимальну кількість пересилань (маршутизаторів), через які може пройти датаграма. Це поле обмежує час життя датаграми. Значення установлюється відправником (як правило 32 або 64) і зменшується на одиницю кожним маршрутизатором, що обробляє датаграму. Коли значення в полі досягає 0, датаграмма видаляється, а відправник повідомляється про це за допомогою ICMP повідомлення. Подібний алгоритм запобігає зацикленню пакетів у петлях маршрутизації.
 ''Поле протоколу'' (protocol) вказує, який протокол відправив дані через IP.

← Попередня версія		Версія за 09:52, 24 грудня 2008
Рядок 58:		Рядок 58:
	Поле опцій завжди обмежено 32 бітами. Байти заповнення, значення яких дорівнює 0, додаються по необхідності. Завдяки цьому IP заголовок завжди кратний 32 биткам (як це потрібно для поля довжини заголовка).		Поле опцій завжди обмежено 32 бітами. Байти заповнення, значення яких дорівнює 0, додаються по необхідності. Завдяки цьому IP заголовок завжди кратний 32 биткам (як це потрібно для поля довжини заголовка).

		+
		+
		+	[[TCP/IP]]
	[[category:Комп'ютерні мережі]]		[[category:Комп'ютерні мережі]]

← Попередня версія		Версія за 18:32, 4 грудня 2008
Рядок 36:		Рядок 36:

	Однак, поле повної довжини потрібно в IP заголовку для деяких каналів (як наприклад, Ethernet), що доповнює маленькі фрейми до мінімальної довжини. Незважаючи на те що мінімальний розмір фрейму Ethernet складає 46 байт (малюнок 2.1), IP датаграма може бути ще менше. Якщо поле повної довжини не було представлено, IP рівень не буде знати, скільки 46-байтных фреймів Ethernet вийде з IP датаграми.		Однак, поле повної довжини потрібно в IP заголовку для деяких каналів (як наприклад, Ethernet), що доповнює маленькі фрейми до мінімальної довжини. Незважаючи на те що мінімальний розмір фрейму Ethernet складає 46 байт (малюнок 2.1), IP датаграма може бути ще менше. Якщо поле повної довжини не було представлено, IP рівень не буде знати, скільки 46-байтных фреймів Ethernet вийде з IP датаграми.
		+
		+
		+	Поле ідентифікації (identification) унікально ідентифікує кожну датаграму, відправлену хостом. Значення, що зберігається в полі, звичайно збільшується на одиницю з посилкою кожної датаграми.
		+	Поле часу життя (TTL - time-to-live) містить максимальну кількість пересилань (маршутизаторов), через які може пройти датаграма. Це поле обмежує час життя датаграми. Значення установлюється відправником (як правило 32 або 64) і зменшується на одиницю кожним маршрутизатором, що обробляє датаграму. Коли значення в полі досягає 0, датаграмма видаляється, а відправник повідомляється про це за допомогою ICMP повідомлення. Подібний алгоритм запобігає зацикленню пакетів у петлях маршрутизації.
		+	Поле протоколу (protocol) вказує, який протокол відправив дані через IP.
		+
		+	Контрольна сума заголовка (header checksum) розраховується тільки для IP заголовка. Вона не містить у собі дані, що слідують за заголовком. ICMP, IGMP, UDP і TCP мають контрольні суми у своїх власних заголовках, що охоплюють їхні заголовки і дані.
		+
		+	Щоб розрахувати контрольну суму IP для вихідної датаграмми, поле контрольної суми спочатку встановлюється в 0. Потім розраховується 16-бітна сума з пірозрядним доповненням (One's complement - порозрядне доповнення до двійкової системи.) (заголовок цілком сприймається як послідовність 16-бітних слів). 16-бітне порозрядне доповнення цієї суми зберігається в поле контрольної суми. Коли IP датаграма приймається, обчислюється 16-бітна сума з порозрядним доповненням. Контрольна сума, розрахована приймачем, містить у собі контрольну суму, збережену відправником, контрольна сума приймача складається з бітів рівних 1, якщо в заголовку нічого не було змінено при передачі. Якщо в результаті не вийшли всі одиничні біти (помилка контрольної суми), IP відкидає прийняту датаграму. Повідомлення про помилку не генерується. Тепер задача верхніх рівнів яким-небудь образом визначити, що датаграма відсутнія, і забезпечити повторну передачу.
		+
		+	Кожна IP датаграмма містить IP адреса джерела (source IP address) і IP адреса призначення (destination IP address). Це 32-бітні значення, що ми описали в розділі "Адресація Internet" глави 1.
		+
		+	І останнє поле - поле опцій (options), це список додаткової інформації змінної довжини. В даний час опції визначені в такий спосіб:
		+	- безпека й обробка обмежень (для військових додатків, описане в RFC 1108 [Kent 1991]),
		+	- запис маршруту (запис кожного маршруту і його IP адреса, глава 7, розділ "Опція запису IP маршруту"),
		+	- тимчасова марка (запис кожного маршруту, його IP адреса і час, глава 7, розділ "IP опція тимчасової марки"),
		+	- вільна маршрутизація від джерела (указує список IP адрес, через які повинна пройти датаграма), і тверда маршрутизація від джерела (те ж саме, що й у попередньому пункті, однак IP датаграма повинна пройти тільки через зазначені в списку адреси).
		+
		+	Ці опції рідко використовуються і не всі хости або маршрутизатори підтримують всі опції.
		+
		+	Поле опцій завжди обмежено 32 бітами. Байти заповнення, значення яких дорівнює 0, додаються по необхідності. Завдяки цьому IP заголовок завжди кратний 32 биткам (як це потрібно для поля довжини заголовка).

	[[category:Комп'ютерні мережі]]		[[category:Комп'ютерні мережі]]

← Попередня версія		Версія за 19:22, 3 грудня 2008
Рядок 20:		Рядок 20:
	<center>[[Image:T3_1.jpg]]</center>		<center>[[Image:T3_1.jpg]]</center>

		+	Старший значущий біт має номер 0 (ліворуч), а молодший значущий біт з 32-х біт має номер 31 і показаний праворуч.
		+
		+	4 байти з 32-бітного значення передаються в наступному порядку: спочатку біти 0 - 7, потім біти 8 - 15, потім 16 - 23 і, нарешті, 24 - 31. Такий порядок руху байтів називається big endian (метод збереження або передачі даних, при якому старший значущий біт або байт стоїть першим) і обов'язковий для всіх двійкових цілих чисел у TCP заголовках при їхній передачі по мережі. Це називається порядок мережних байтів (network byte order). Машини, що зберігають двійкові цілі в інших форматах, як наприклад у форматі little endian (little endian - метод збереження або передачі даних, при якому молодший значущий біт або байт стоїть першим), повинні конвертувати значення заголовків у відповідний порядок мережних байтів перед передачею даних.
		+
		+	Довжина заголовка (header length) це кількість 32-бітних слів у заголовку, включаючи будь-які опції. Тому що це 4-бітне поле, воно обмежує розмір заголовка в 60 байт. Це обмеження сильно впливає на деякі опції, такі як опція запису маршруту. Звичайна величина в цьому полі (коли відсутні опції) - 5.
		+
		+	Поле типу сервісу (TOS - type-of-service) складається з 3-бітного поля приставки (яке в даний час ігнорується), 4 біт TOS і невикористовуваного біта, що повинен дорівнювати 0.
		+	4 біта TOS наступні: мінімальна затримка, максимальна пропускна здатність, максимальна надійність і мінімальна вартість. Тільки один з цих 4 біт може бути встановлений в одиницю одночасно. Якщо всі 4 біти рівні 0, це означає звичайний сервіс. RFC 1340 [Reynolds and Postel 1992] указує, як ці біти повинні бути встановлені для всіх стандартних додатків. RFC 1349 [Almquist 1992] містить деякі корекції для цього RFC і більш детальний опис характеристики TOS.
		+
		+	Діалогові додатки, Telnet і Rlogin, вимагають звести до мінімуму затримку, тому що вони використовуються людиною інтерактивно і здійснюють невелику передачу даних. Передача файлів з використанням FTP, з іншого боку, вимагає максимальної пропускної здатності. Максимальна надійність необхідна для мережного керування (SNMP) і для протоколів маршрутизації. Новини Usenet (NNTP) - це єдиний додаток, що вимагає мінімізації вартості.
		+
		+	Поле повної довжини (total length) містить повну довжину IP датаграммы в байтах. Завдяки цьому полю і полю довжини заголовка, ми знаємо, з якого місця починаються дані в IP датаграмі і їхню довжину. Тому що це поле складається з 16 біт, максимальний розмір IP датаграми складає 65535 байт. Це поле змінюється в момент фрагментації і повторної зборки датаграми.
		+
		+	Незважаючи на то що існує можливість відправити датаграму розміром 65535 байт, більшість канальних рівнів поділять подібну датаграму на фрагменти. Більш того, від хоста не потрібно приймати датаграму розміром більше за 576 байт. TCP поділяє користувацькі дані на частині, тому це обмеження звичайно не робить впливу на TCP. Що стосується UDP, послугами якого користуються багато додатків (RIP, TFTP, BOOTP, DNS, SNMP), те він обмежує себе 512 байтами користувацьких даних, що навіть менше обмеження в 576 байт. Більшість додатків у даний час (особливо ті, котрі підтримують NFS - Network File System) дозволяють використовувати IP датаграму розміром 8192 байта.
		+
		+	Однак, поле повної довжини потрібно в IP заголовку для деяких каналів (як наприклад, Ethernet), що доповнює маленькі фрейми до мінімальної довжини. Незважаючи на те що мінімальний розмір фрейму Ethernet складає 46 байт (малюнок 2.1), IP датаграма може бути ще менше. Якщо поле повної довжини не було представлено, IP рівень не буде знати, скільки 46-байтных фреймів Ethernet вийде з IP датаграми.

	[[category:Комп'ютерні мережі]]		[[category:Комп'ютерні мережі]]