B.1. Класифікація мережевих протоколів
B.1.1. Фізичний рівень OSI B.1.2. Канальний рівень OSI B.1.3. Мережевий рівень OSI B.1.3.1. ARP B.1.3.2. RARP B.1.3.3. IP B.1.3.4. IPv6 B.1.4. Транспортний рівень OSI B.1.4.1. ICMP B.1.4.2. UDP B.1.4.3. TCP B.1.4.3.1. Структура пакета TCP B.1.4.3.2. Відкриття з'єднання TCP, потрійне рукостискання B.1.4.3.3. Закриття з'єднання TCP B.1.4.3.4. Стан з'єднання TCP B.1.5. Рівні додатки, уявлення і сеансовий
Для класифікації мережевих протоколів застосовують так звану еталонну семиуровневую модель OSI (див. [Url: // wiki-OSI-ru]).
Мережева модель OSI (англ. Open Systems Interconnection Reference Model - модель взаємодії відкритих систем) - абстрактна модель для мережевих комунікацій і розробки мережевих протоколів.
Модель розбиває мережеві протоколи на сім рівнів:
- Фізичний рівень (Physical layer).
- Канальний рівень (Data Link layer);
- Мережевий рівень (Network layer);
- Транспортний рівень (Transport layer);
- Сеансовий рівень (Session layer);
- Рівень представлення (Presentation layer);
- Рівень додатки (Application layer);
B.1.1. Фізичний рівень OSI
Фізичний рівень призначений безпосередньо для передачі сигналу. У протоколах фізичного рівня описується, наприклад, як повинен бути влаштований провід (кручена пари) для того, щоб він гарантовано пропускав сигнал у стандарті Ethernet 100base-TX: товщина окремих жив, їх опір, частота обвива, мінімально відстань від проводу до силового кабелю, максісмальное кількість витків в бухті і мінімальний радіус бухти, довжина проводу від ретранслятора до ретранслятора кількість з'єднань типу шнур-розеркі, спосіб розведення жив в роз'ємі RJ45.
На фізичному рівні працюють концентратори і репітери (вони ж ретранслятори). Призначення репитеров полягає в тому, щоб посилювати сигнал. Вони потрібні в тому випадку, якщо треба передати сигнал далі ніж це передбачено в стандарті. Концентратор (так само відомий як hub) потрібен для того, щоб не тільки посилювати сигнал, але і передавати його з одного проводу в кілька інших, таким чином, хаб потрібен для об'єднання декількох пристроїв Ethernet в сегмент.
B.1.2. Канальний рівень OSI
На даному рівні працюють комутатори (switch), мости (bridge) і, звичайно, власне Ethernet-адаптери (мережеві карти).
Якщо мережа зібрана нема на комутаторах, а на концентраторах (тобто не на switch'ах, а на hub'ах; для такої мережі є влучне жаргонний вислів «паскудна мережу»), всі кадри доставляються всім. Така організація погана не тільки з точки зору безпеки, але, головним чином, з точки зору продуктивності. Якщо два пристрої Ethernet одночасно посилають в сегмент кадри, то відбудеться колізія - обидва кадру пропадуть. Буде виконана повторна відправка кадрів. Для того, щоб колізія не повторилася, повторна відправка відбувається із затримкою на випадковий проміжок часу. Чим більше пристроїв в мережі, тим вище ймовірність колізії. Про пристрої, які можуть увійти в подібний конфлікт, кажуть, що вони знаходяться в одному «домені колізій». Таким чином, головна перевага switch'ей перед hub'амі полягає в тому, що вони дроблять мережу на безліч незначних доменів колізій, тим самим істотно підвищуючи продуктивність мережі.
Для моніторингу заголовків канального рівня в програмі tcpdump (1) передбачена опція -e. (Див. Розділ 6.11, «Демонстрація основних навичок роботи з утилітою tcpdump (1)»).
B.1.3. Мережевий рівень OSI
На даному рівні функціонують протоколи IP, IPv6, ARP, RARP та деякі інші, проте нас тут будуть цікавити лише ці чотири.
B.1.3.1. ARP
B.1.3.2. RARP
B.1.3.3. IP
Протокол IP призначений для передачі пакетів, завдання формування пакетів, контроль помилок, в функції протоколу IP не входять. Це прерогатива більш високорівневих протоколів, таких як TCP, UDP, ICMP.
В Розділ 6.11, «Демонстрація основних навичок роботи з утилітою tcpdump (1)» наводиться лістинг програми tcpdump (1) з перехопленням двох ICMP пакетів. На цьому прикладі детально описано з чого складається заголовок пакета IP.
B.1.3.4. IPv6
B.1.4. Транспортний рівень OSI
Примітка: в деяких інших, більш пізніх RFC можуть бути додані додаткові коди ICMP. Наприклад в RFC 950 додані повідомлення Address Mask Request (код 17) і Address Mask Reply (код 18)
Найбільш ІЗВЕТСНОГО повідомлення ICMP, це мабуть echo request і echo reply. Зазвичай вони використовуються з метою тестування. У Розділ 6.4.2, «traceroute (1)» розповідається як програма traceroute (8) з їх допомогою він визначає маршрут від точки до точки.
B.1.4.2. UDP
Протокол UDP діє за принципом «вистрілив і забув». Він не тільки не гарантує доставку пакетів, але навіть не гарантує, що доставлені пакети прийдуть в тому ж порядку, в якому вони були вислані. Проте, в надійних мережах в ім'я зростання продуктивності можна в деяких додатках використовувати протокол UDP. У свій час мережева файлова система NFS була заснована на протоколі UDP, а контроль помилок здійснювався на більш високих рівнях OSI. Однак зараз від цієї практики відмовилися.
B.1.4.3. TCP
І нарешті, протокол TCP відрізняється від протоколу UDP тим, що в ньому діє механізм контролю помилок. Для реалізації цього механізму в заголовок додано додаткове поле з прапорами TCP. (Це не єдине ускладнення в порівнянні з UDP, але нас буде цікавити саме воно.) Кожен пакет TCP підтверджується пакетом з прапором ACK (acknowledgement). Один пакет з прапором ACK може підтверджувати отримання декількох пакетів. У протоколі обумовлена складна процедура підтверджень, які відбуваються при відкритті і закритті з'єднання.
B.1.4.3.1. Структура пакета TCP
Таблиця B.2. Формат TCP заголовка
Source Port Порт відправника, 16 біт - номер порта відправника. Destination Port Порт одержувача, 16 біт - номер порту одержувача. Sequence Number Номер черги, 32 біта - Номер черги для першого октету даних в даному сегменті (за винятком тих випадків, коли є присутнім прапор синхронізації SYN). Якщо ж прапор SYN є присутнім, то номер черги є ініціалізацій (ISN), а номер першого октету даних - ISN + 1. Acknowledgment Number Номер підтвердження, 32 біта - Якщо встановлений прапор ACK, то це поле містить наступний номер черги, який відправник даної датаграми бажає отримати в зворотному напрямку. Номери підтвердження посилаються постійно, як тільки з'єднання буде встановлено. Data Offset Зсув даних, 4 біта - Кількість 32-бітних слів у TCP заголовку. Вказує на початок поля даних. TCP заголовок завжди кінчається на 32-бітної кордоні слова, навіть якщо він містить опції. Reserved Зарезервоване поле, не може залишатися порожнім нулями. 6 біт. Control Bits Прапори TCP, 8 біт (8 прапорів). Прапори зліва на право: CWR, ECE, URG, ACK, PSH, RST, SYN, FIN. Перші два прапора в старих посібниках часто оттсутствуют. Розшифровка прапорів дана в Таблиця B.3, «Прапори TCP». Window Вікно, 16 біт - Кількість октетів даних, починаючи з октету, чий номер зазначений в полі підтвердження. Кількість октетів, одержання яких чекає відправник справжнього сегмента. Checksum Контрольна сума, 16 біт Urgent Pointer Покажчик терміновості 16 біт - Це поле повідомляє поточне значення термінового покажчика. Останній є позитивною величиною - зсувом щодо номера черги даного сегмента. Терміновий покажчик повідомляє номер черги для октету, наступного за терміновими даними. Це поле інтерпретується тільки в тому випадку, коли в сегменті виставлений прапор URG. Options Додаткові опції, довжина змінна.
Таблиця B.3. прапори TCP
відправник інформує одержувача про уповільнення пересилання (див. [RFC-3168])
поле термінового покажчика задіяне
поле підтвердження задіяне
перезавантаження даного з'єднання
синхронізація номерів черги
немає більше даних для передачі
B.1.4.3.2. Відкриття з'єднання TCP, потрійне рукостискання
З'єднання TCP, на відміну від UDP, підтримує поняття «сеансу зв'язку». Це означає, що дані можуть йти від джерела до одержувача одним потоком. Протокол гарантує контроль помилок. Дані не можуть губитися або повторюватися або обганяти один одного. Для реалізації цього вимоги організовується у відповідь трафік від одержувача до відправника, в якому отримувач звітує про те, які пакети він отримав і доводить їх до відома контрольні суми. Для цього висилаються пакети з виставленим прапором ACK.
Наведена схема ілюструє односпрямований потік даних. Тобто навіть для односпрямованого потоку даних потрібно передача пакетів в обидві сторони. Тим часом, більшість з'єднань TCP двоспрямованістю, так як протоколи рівня додатків (HTTP, SMTP і т.п.) передають дані в обидві сторони. Так, якщо браузер повинен завантажити деякий ресурс, то з боку браузера надсилається запит GET <имя ресурса>, а з боку сервера власне ресурс. Розглянемо як відкривається таке двонаправлене з'єднання.
Спершу одна зі сторін, будемо називати її «клієнт» посилає інший строне ( «серверу») пакет з виставленим прапором SYN. Це свого роду заявка на відкриття з'єднання.
Сервер повинен підтвердити отримання цього пакету і вислати у відповідь пакет з виставленим прапором ACK. Але оскільки з'єднання повинно бути двонаправленим, він повинен теж вислати клієнтові пакет із заявкою на відкриття з'єднання, тобто з прапором SYN. Ці два пакети, з прапорами ACK і SYN можуть бути об'єднані в один пакет.
Клієнт отримав від сервера пакет SYN, тепер він повинен його підтвердити, і він висилає серверу пакет ACK підтверджує відкриття з'єднання від сервера до клієнта.
Отже, клієнт і сервер обмінялися трьома пакетами: 1) клієнт зробив заявку на відкриття з'єднання від клієнта до сервера; 2) сервер підтвердив відкриття цього з'єднання і зробив заявку на відкриття з'єднання від сервера до клієнта; 3) клієнт підтвердив відкриття з'єднання від сервера до клієнта. Дана процедура обміну трьома пакетами називається процедурою «потрійного рукостискання» (threeway handshaking).
Перші три пакети, які ми тут спостерігаємо якраз і відносяться до процедури потрійного рукостискання. Видно, що перший пакет мав прапор SYN (на це вказує велика літера S в роздруківці), другий теж мав прапор SYN і на додачу прапор ACK. Третій пакет не мав ніяких прапорів крім ACK.
Наступні два пакети (4-й і 5-й) в нашій роздруківці це пакети відповідальні за передачу даних по протоколу HTTP. У першому з них клієнт вислав запит http-ресурсу командою протоколу HTTP GET. Так як весь запит вклався в один пакет, то в цьому пакеті був виставлений прапор PSH (push). Цей прапор ставиться для того, щоб змусити сервер відправити всі накопичені пакети з додатком яке їх очікує (тобто веб-сервера). У відповідь сервер висилає сторінку html. Ця сторінка так само помістилася в один пакет, і тому в ньому теж встановлений прапор PSH.
Нарешті останні чотири пакети відповідають процедурі закриття з'єднання TCP і будуть розглянуті нижче.
B.1.4.3.3. Закриття з'єднання TCP
З'єднання TCP, як уже говорилося вище, двунаправленное, тому воно закривається окремо клієнтом і сервером. Таким чином породжується 4 пакети: 1) сервер надсилає повідомлення про закриття каналу від сервера до клієнта, пакет з прапором FIN; 2) клієнт підтверджує його отримання пакетом з прапором ACK; 3) клієнт висилає пакет FIN - повідомлення про закриття каналу від клієнта до сервера; 4) сервер підтверджує його отримання. Іноді пакети 2 і 3 об'єднуються, подібно до того, як це відбувається при потрійному рукостисканні.
Після того як хост вислав пакет з прапором FIN він більше не має право висилати дані через цей же сокет.
Чому ж покупець не висилає пакет FIN в тому ж пакеті, в якому він висилає прапор ACK? Тому що закриття каналів - незалежна процедура. Вона здійснюється в той момент коли додаток (браузер або вебсервер) зробить виклик функції close (2). В принципі, після того як з'єднання з боку сервера до клієнта закрилося і перебуває в такому напівзакритому стані, клієнт ще може продовжувати передавати якісь дані на сервер.
У цій процедурі є деяка проблема: коли клієнт отримав останній пакет з прапором ACK підтверджує отримання пакету з прапором FIN сервером, він нічого сервер не висилає. Як же сервер дізнається, що клієнт отримав його пакет ACK? Щоб не впасти в порочне коло і не висилати до нескінченності підтвердження на підтвердження, в протоколі TCP обраний наступний алгоритм: існує деяка абстрактна величина, яка називається «гранична затримка сегмента» (MSL maximum segment lifetime). Цей параметр характеризує передбачуваний максимально можливий термін перебування сегмента в мережі до того, як він буде де-небудь відкинутий. В [RFC-793] рекомендовано значення MSL рівне 2 хвилинах. На практиці цей час залежить від конкретної реалізації операционой системи і може бути і менше. Сервер після відправки пакета ACK чекає подвоєну час MSL і якщо за цей час він не отримав повторного пакету FIN, то він вважає, що його пакет ACK благополучно дістався до клієнта і закриває сокет.
B.1.4.3.4. Стан з'єднання TCP
Зверніть увагу, стан TIME_WAIT, як уже зазначалося, триває подвоєне час MSL, тобто до 4 хвилин. В цей стан потрапляє тільки та сторона, яка виконує активну закриття з'єднання. На наведеній діаграмі це клієнт, а в роздруківці tcpdump (1) в прикладі з веб-сервера, це був сервер. У ситуації, коли активне закриття виконує сервер (а для вебсервера це саме так) може накопичуватися велика кількість незакритих сокетов. Рано чи пізно для перевантажених вебсервер це може перетворитися в чесний біду. З цієї причини більшість сучасних операційних систем в даному місці не відповідають RFC. FreeBSD перебуває в стані TIME_WAIT протягом однієї хвилини.