Після знайомства з фізичним переміщенням бітів в носії і маршрутизацією датаграмм в Інтернеті, настав час розглянути служби для додатків, пов'язані з пересилкою даних. Почнемо з протоколу користувальницьких датаграм (User Datagram Protocol - UDP). Це досить простий протокол, що дозволяє додаткам обмінюватися окремими повідомленнями.
Мал. 9.1. Питання і відповідь DNS
Навантаження з відкриття та закриття з'єднань при пересиланні великого обсягу повідомлень можуть бути виключені завдяки передачі простих запитів і відповідей. Крім того, UDP служить прекрасною основою для конструювання засобів моніторингу, налагодження, обслуговування або тестування.
UDP є первинною службою, пересилати прості окремі повідомлення в IP для подальшої передачі по мережі. Оскільки IP не забезпечує надійності пересилки, то немає і гарантій доставки повідомлення. Якщо програма намагається пересилати свої запити в датаграму UDP, але не отримує відповідей за розумний інтервал часу, з додатком слід повторно переслати дані.
Іноді це призводить до дублювання запитів на сервері. Якщо додаток включить в своє повідомлення ідентифікатор транзакції, сервер зможе розпізнати дублювання і виключити додаткову копію повідомлення. За ці дії відповідально сам додаток, а не UDP.
Що відбувається після прибуття даних в хост призначення? Як виконується їх доставка в потрібне додаток (процес)?
На рис. 9.2 видно, що для кожного рівня існує ідентифікатор протоколу, який вказує операції, що виконуються над даними. На другому рівні тип Ethernet X'08-00 в заголовку кадру показує, що кадр потрібно передати в IP. На третьому рівні поле протоколу в заголовку IP вказує протокол четвертого рівня, куди потрібно переслати дані (наприклад, 6 для TCP або 17 для UDP).
Мал. 9.2. Пересилання даних до рівня додатків
Хост може брати участь одночасно в декількох комунікаціях. Так як же із загального потоку виділяється датаграмма UDP і доставляється на потрібний рівень програми? Такий процес пересилання даних в необхідний процес часто називають демультиплексування. Відповідь полягає в тому, що кожній кінцевій комунікаційної точці UDP присвоєно 16-розрядний ідентифікатор, званий номером порту. Термін "порт" не дуже вдалий для даного ідентифікатора. Порт для клієнтської і серверної частин програми не має ніякого відношення до портів обладнання та фізичному шляху пересилання даних).
Порти з номерами від 0 до 1023 зарезервовані для стандартних служб. Такі порти називаються загальновідомими (well-known). Їх використання дозволяє клієнту ідентифікувати службу, до якої він хоче отримати доступ. Наприклад, доступ до DNS (яка заснована на UDP) проводиться через загальновідомий порт 53.
Хто призначає загальновідомі порти? Як не важко здогадатися, цим займається IANA. Номери портів для певних програм реєструються цією організацією і публікуються в документі RFC Assigned Numbers (присвоєні номера). Скорочений список портів UDP з поточного документа RFC Assigned Numbers показаний в таблиці 9.1.
Таблиця 9.1 Приклади загальновідомих портів UDP
Служить для отримання звітів про проблеми в мережі
Кілька загальновідомих служб забезпечує модулі для тестування, налагодження і вимірювань. Наприклад, echo (відлуння) з портом 7, відповідаючи своїй назві, повертає будь-яку надіслану на цей порт датаграмму. Служба Discard (скасування) порту 9, навпаки, видаляє з мережі будь-яку надіслану на цей порт датаграмму. Character generator (генератор символів) відповідає на будь-яке повідомлення датаграммой, що містить від 0 до 512 байт. Кількість байт вибирається випадковим чином.
Служба quote of the day (цитата дня) відповідає на будь-яку датаграмму певним повідомленням, наприклад, в деяких системах програма fortune виводить при реєстрації "мудрі" поради (в даному прикладі приведена фраза Вінстона Черчилля: "Людина може випадково спіткнутися об істину, але в більшості випадків не помічає її і зосереджено продовжує подальший пошук ".):
Churchill's Commentary on Man:
Man will occasionally stumble over the truth, but most of the
time he will pick himself up and continue on.
Служба daytime (час дня) відповідає на будь-які датаграми повідомленням, що містить поточну дату і час у форматі ASCII. Такий формат можна прочитати на екрані без додаткових перетворень. Інакше поводиться служба Network Time Protocol (NTP), що забезпечує надійний метод синхронізації комп'ютерів мережі.
Ми вже знаємо, що сервер імен доступний через порт 53 і команду nslookup. Порти 161 і 162 використовуються протоколом Simple Network Management Protocol.
Крім офіційно призначених номерів, будь-яка система з TCP / IP може резервувати діапазон номерів для важливих мережевих служб і додатків.
Решта номера портів (вище 1023) надаються клієнтам від програмного забезпечення хоста в міру необхідності. Виділення передбачає наступні кроки:
1. Користувач запускає клієнтську програму (наприклад, nslookup).
2. Клієнтський процес виконує системну підпрограму, що має сенс: "Я хочу виконати комунікацію UDP. Надайте мені порт".
3. Системна підпрограма вибирає невикористаний порт з пулу доступних портів і надає його клієнтського процесу.
Можна бачити, що TCP також ідентифікує джерело і призначення своїм 16-розрядних ідентифікатором порту. Наприклад, порт 21 застосовується для доступу до служби пересилання файлів. а порт 23 - для служби реєстрації telnet.
Номери TCP і UDP незалежні один від одного. Один процес може посилати повідомлення з порту UDP з номером 1700, в той час як інший продовжує сеанс TCP через порт 1700. Існує кілька служб, доступних як через TCP, так і через UDP. В цьому випадку IANA передбачає присвоєння однакового номера порту для служби UDP і TCP. Однак кінцеві точки комунікації залишаються в різних місцях.
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Address (state)
Tcp 0 0 127.0.0.1.1340 127.0.0.1.111 TIME_WAIT
Tcp 0 0 128.121.50.145.25 128.252.223.5.1526 SYN_RCVD
Tcp 0 0 128.121.50.145.25 148.7.9.160.65.3368 ESTABLISHED
Tcp 0 438 128.121.50.145.23 130.132.57.246.2219 ESTABLISHED
Tcp 0 0 128.121.50.145.25 192.5.5.1.4022 TIME_WAIT
Tcp 0 0 128.121.50.145.25 141.218.1.100.3968 TIME_WAIT
Tcp 0 0 128.121.50.145.25 35.8.2.2.3722 TIME_WAIT
Tcp 0 0 128.121.50.145.1338 165.247.48.4.25 ESTABLISHED
Tcp 0 0 128.121.50.145.25 128.173.4.8.3626 ESTABLISHED
Tcp 0 0 128.121.50.145.25 192.48.96.14.3270 ESTABLISHED
Який механізм необхідний для запуску протоколу User Datagram Protocol? Перш за все, UDP повинен бути привласнений унікальний ідентифікатор протоколу (17). Це значення буде міститися в поле протоколу IP з назвою Protocol у всіх вихідних повідомленнях UDP. Вхідні повідомлення зі значенням 17 в поле протоколу IP доставляються в UDP. Протокол UDP формує повідомлення, додаючи простий заголовок до даних від додатка. У цьому заголовку вказуються номера портів джерела і призначення.
На рис. 9.3 представлений формат заголовка UDP. Тема містить 16-розрядні номери портів джерела і призначення, що визначають кінцеві точки комунікації. Поле довжини визначає загальна кількість октетів в заголовку і частині для даних повідомлення UDP. Поле контрольної суми дозволяє перевірити коректність вмісту повідомлення.
Мал. 9.3. заголовок UDP
Згадаймо, що заголовок IP містить контрольну суму для перевірки коректності своїх полів. Призначенням контрольної суми UDP є перевірка вмісту повідомлення UDP.
У UDP контрольна сума обчислюється як комбінація спеціально сформованого псевдозаголовка (pseudo header), що містить деяку інформацію IP, заголовка UDP і даних з повідомлення.
Мал. 9.4. Поля псевдозаголовка для контрольної суми UDP
Використання контрольної суми в комунікації не є обов'язковим. Коли вона не застосовується, поле має нульове значення. Якщо ж контрольна сума була обчислена і дорівнює нулю, таке значення представляється послідовністю одиниць.
Крім відправки та отримання датаграмм, UDP повинен керуватися здоровим глуздом при пересиланні даних вниз, від додатка до IP, і забезпечувати вказівку на помилки від IP до додатка.
Мал. 9.5 містить поєднаний висновок IP і UDP частин запиту та відповідних їм відповідей. Цей результат отримано в моніторі локальної мережі Sniffer компанії Network General. Запит містив вимогу виведення статусу інформації і був посланий хостом на мережеву станцію управління. Частина для даних в повідомленнях запиту і відповіді не наведено.
Мал. 9.5. Заголовки IP і UDP для запиту і відповіді
В обох заголовках IP поле протоколу має значення 17, що вказує на використання протоколу UDP. Контрольна сума UDP немає обчислюється для запиту, але присутній у відповіді.
Аналізатор Sniffer розпізнає, що порт 161 призначений для мережевого обслуговування.
Коли додаток отримує порт UDP, мережеве програмне забезпечення протоколу резервує кілька буферів для зберігання черги вступників на цей порт для користувача датаграм. Служби на основі UDP не можуть передбачити кількість одночасно надходять датаграмм і управляти ними.
Якщо на службу приходить більше датаграмм, ніж вона може обробити, то додаткові повідомлення просто відкидаються. Цей факт можна виявити за допомогою секції UDP Socket Overflows (переповнення в socket протоколу UDP) звіту мережевий статистики. Наприклад, наведений нижче звіт створений командою netstat:
0 incomplete headers
0 bad data length fields
0 bad checksums
17 socket overflows
Протокол User Datagram Protocol визначено в RFC 768. RFC від 862 до 865 обговорюють UDP-служби, echo, discard, character generator і quote of the day. RFC 867 описує утиліту daytime. a RFC 1119 представляє другу версію служби network time. Протокол BOOTP розглядається в розділі 11, а про додаткові службах UDP буде згадано в наступних розділах.