Комп'ютерні мережі

Взаємодія комп'ютерів між собою, а також з іншим активним мережевим обладнанням, в TCP/IP-мережах організовано на основі використання мережевих служб, які забезпечуються спеціальними процесами мережевої операційної системи (ОС) — демонами в UNIX-подібних ОС, службами в ОС сімейства ОС Windows і т. д. Прикладами мережевих сервісів є веб-сервери (сайти всесвітньої павутини), електронна пошта, FTP-сервери для обміну файлами, та багато іншого.

 

29.1. Сокети, з'єднання

Спеціальні процеси операційної системи (демони, служби) створюють «слухаючий» сокет і «прив'язують» його до певного порту (пасивне відкриття з'єднання), забезпечуючи тим самим можливість іншим комп'ютерам звернутися до даної служби. Клієнтська програма або процес створює запит на відкриття сокета із зазначенням IP-адреси і порту сервера, в результаті чого встановлюється з'єднання, що дозволяє взаємодіяти двом комп'ютерам з використанням відповідного мережевого протоколу прикладного рівня.

 

29.2. Номери портів

Номер порту для «прив'язки» служби вибирається залежно від його функціонального призначення. За привласнення номерів портів певним мережним службам відповідає IANA. Номери портів знаходяться в діапазоні 0-65535 і розділені на 3 категорії:

 

Номери портів	Категорія	Опис
0—1023	загальновідомі порти	Номери портів призначені IANA і на більшості систем можуть бути використані виключно процесами системи (або користувача root), або прикладними програмами, запущеними привілейованими користувачами. Не повинні використовуватися без реєстрації IANA. Процедура реєстрації визначена в розділі 19.9 RFC 4340
1024—49151	зареєстровані порти	Номери портів включені в каталог IANA і на більшості систем можуть бути використані процесами звичайних користувачів або програмами, запущеними звичайними користувачами. Не повинні використовуватися без реєстрації IANA. Процедура реєстрації визначена в розділі 19.9 RFC 4340.
49152—65535	динамічні порти	Призначені для тимчасового використання (наприклад, для тестування додатків до реєстрації IANA), а також як клієнтські (використовуваних для приватних служб у середині мереж). Ці порти не можуть бути зареєстровані.

 

29.3. Історія регулювання відповідності

Питання уніфікації відповідності мережевих служб номерами сокетів (портів) піднімалися в RFC 322 і RFC 349, перші спроби регулювання були зроблені Джоном Постелом в RFC 433 і RFC 503.

У березні 1990 року (див. RFC 1060) функція регулювання відповідності мережевих служб номерам портів була передана спеціальної організації -IANA, яка актуалізувала список відповідності випуском документів RFC «Assigned Numbers» (під номерами 739, 750, 755, 758, 762, 770, 776, 790, 820, 870, 900, 923, 943, 960, 990, 1010, 1060, 1340, 1700). Значну частину цих документів готував Джон Постел.

З січня 2002 року (див. RFC 3232) IANA публікує актуальний список відповідності на своєму сайті (без закріплення в RFC): http://www.iana.org/assignments/port-numbers.

 

29.4. Стан мережевих служб операційної системи

У більшості операційних систем можна подивитися стан мережних служб за допомогою команди

netstat -an

В ОС сімейства Windows результат роботи цієї команди виглядає приблизно так:

В UNIX-подібних ОС результат роботи команди netstat -an має приблизно такий вигляд:

 

Стан (State) LISTEN (LISTENING) показує пасивно відкриті з'єднання. Саме вони і надають мережеві служби.

ESTABLISHED — це встановлені з'єднання, тобто мережеві служби в процесі їх використання.

 

29.5. Перевірка доступності мережевих служб

У разі виявлення проблем з тією чи іншою мережевою службою, для перевірки її доступності використовують різні засоби діагностики, залежно від їх наявності в даній ОС.

Один з найзручніших засобів — команда (утиліта) tcptraceroute (різновид  traceroute), яка використовує TCP-пакети відкриття з'єднання (SYN|ACK) з вказаним сервером (за замовчуванням — web-сервер, порт 80) хоста і показує інформацію про час проходження даного виду TCP-пакетів через маршрутизатори, а також інформацію щодо доступності хоста, або, у разі проблем з доставкою пакетів — в якому місці шляху вони виникли.

Як альтернативу можна використовувати окремо

• traceroute для діагностики маршруту доставки пакетів (недолік — використання UDP-пакетів для діагностики)
• telnet або netcat на порт проблемної служби для перевірки її відгуку.

  

29.6. traceroute

Traceroute - це службова комп'ютерна програма, призначена для визначення маршрутів прямування даних в мережах TCP/IP. Traceroute може використовувати різні протоколи передачі даних в залежності від операційної системи пристрою. Такими протоколами можуть бути UDP, TCP, ICMP або GRE. Комп'ютери з встановленою операційною системою Windows використовують ICMP-протокол, при цьому операційні системи Linux і маршрутизатори Cisco - протокол UDP.

Traceroute входить в поставку більшості сучасних мережевих операційних систем. У системах Microsoft Windows ця програма носить назву tracert, а в системах GNU/Linux, Cisco IOS і Mac OS - traceroute.

Розглянемо приклад роботи програми в операційній системі Windows. Програма tracert виконує відправку даних вказаному вузлу мережі, при цьому відображаючи відомості про всіх проміжних маршрутизаторах, через які пройшли дані на шляху до цільового вузла. У разі проблем при доставці даних до будь-якого вузла програма дозволяє визначити, на якій саме ділянці мережі виникли неполадки. Необхідно відзначити, що програма працює тільки в напрямку від джерела пакетів і є вельми грубим інструментом для виявлення неполадок в мережі. В силу особливостей роботи протоколів маршрутизації в мережі Інтернет, зворотні маршрути часто не збігаються з прямими, причому це справедливо для всіх проміжних вузлів в Трейсі. Тому ICMP відповідь від кожного проміжного вузла може йти своїм власним маршрутом, загубитися або прийти з великою затримкою, хоча в реальності з пакетами, які адресовані кінцевому вузлу, цього не відбувається. Крім того, на проміжних маршрутизаторах часто стоїть обмеження числа відповідей ICMP в одиницю часу, що призводить до появи помилкових втрат.

 

29.7. Telnet та інші протоколи

У середовищі фахівців з технологій internet поширена думка, що клієнт Telnet придатний для здійснення ручного доступу (наприклад, з метою налагодження) до таких протоколів прикладного рівня як HTTP, IRC, SMTP, POP3 і іншим текст-орієнтованим протоколами на основі транспорту TCP.

Такі програми як netcat дійсно забезпечують чистий доступ до TCP, однак потрібні спеціальні хитрощі для передачі переведення рядка як CR LF (що потрібно багатьма протоколами). Зазвичай клієнт Telnet за замовчуванням передає будь-яке переведення рядка як CR LF, незалежно від його кодування у системі клієнта. Також для доступу до прикладних протоколів (крім FTP і, власне, Telnet) з метою відлагодження є використання клієнта PuTTY в режимі «Raw» (чистий доступ до TCP) - PuTTY перетворює переведення рядка окремо від підтримки протоколу Telnet.