TCP розпізнає кінцеві точки таких з'єднань за IP адресами двох хостів, та числами (які також називаються портами) на кожному з них. Порти можуть розглядатись як точки приєднання мережевих з'єднань. Якщо ми знову розглянемо це на прикладі телефонії, то IP адреса буде виступати в ролі коду міста, а порт - телефонному номеру.

В прикладі з rlogin, програма-клієнт (rlogin) відкриває порт на erdos, та під'єднується до порта 513 на quark, на якому висить сервер - rlogind. Таким чином встановлюється TCP з'єднання. Використовуючи це з'єднання, rlogind виконує процедуру авторизації та запускає шелл. Стандартний вхідний та вихідний потік переадресовуються на TCP з'єднання, так, щоб будь-які данні які ви наберете на своїй машині у відповідь на запрошення передадуться через TCP потік та сприймуться віддаленим шелом як стандартний вхід.

2.3.7 User Datagram Protocol

Звичайно TCP не єдиний користувачський протокол в TCP/IP сережах. Хоча TCP підходить для звернень типу rlogin, але великі затрати спричиняють неможливість використання в прикладних програмах типу NFS. Замість нього в таких випадках використовують подібний до TCP протокол UDP - User Datagram Protocol. Подібно до TCP, UDP також дозволює прикладній програмі під'єднатись до послуги на певному порті на віддаленій машині, але він на встановлює з'єднання для цього. Замість цього, протокол UDP дозволяє просто посилати окремі пакети на місце призначення (що відповідає його назві).

Припустіть що Ви змонтували ієрархію каталогу TeX з центрального NFS сервера (garois), і хочете подивитись документ в якому описано як використовувати LaTeX. Ви запускаєте редактор який для початку читає весь файл. Однак це займе досить багато часу : створити TCP з'єднання, отримати файл, відправити підтвердження. Замість цього робиться запит на galois, який посилає файл кількома UDP пакетами, що є значно швидше. Однак UDP не вміє опрацювувати помилки передачі пакетів та їх втрату. Ці обов'язки залишаються за прикладною програмою (у цьому випадку за NFS).

2.3.8 Детальніше про порти

Порти можуть розглядатись як точки приєднання для мережевих з'єднань. Якщо прикладна програма хоче запропонувати певну послугу, вона приєднується до певного порта та очікує запитів від клієнтів (цей процес також називають прослуховування порта - listening on the port). Клієнт який хоче використати цю послугу приєднується до порта на локальному хості і з'єднується з портом сервісу на віддаленій машині.

Важливою особливістю портів є те, що як тільки було встановлено з'єднання між клієнтом та сервером, інша копія сервера приєднується до порта і очікує звернень від інших клієнтів. Це дозволяє, для прикладу, декілька паралельних віддалених входів на той самий хост (при чому всі клієнти будь під'єднані до сервера через порт 513). TCP здатен розрізняти всі ці з'єднання одне від одного, так як вони відрізняються портами або хостами з якими відбувається з'єднання. Наприклад якщо ви двічі ввійдете на quark з erdos то локальний rlogin буде в першому випадку використовувати порт 1023, а другий - 1022. Однак на quark він буде під'єднаний до одного порта - 513 в обох випадках.

Цей приклад показує використання портів як точок зустрічі, де клієнт під'єднується до певного порта щоб отримати певну послугу. Для того щоб клієнт знав потрібний номер порта, повинно бути досягнена згода між адміністраторами обох систем про призначені сервісами номери портів. Для послуг тапу rlogin ці номери повинні встановлюватись централізовано. Станадартний варіант розміщення номерів регулярно випускає IETF (Internet Engineering Task Force) в RFC що називається Assigned Numbers. Linux використовує файл /etc/services для опису розміщення призначених для служб номерів. Детальніше описано в секції 10.3.

Коштує вказати що хоча і TCP, і UDP приєднуються на однакові порти, вони все одно не вступають в протиріччя. Це означає що, для прикладу, TCP порт 513 відрізняється від порта 513 UDP. Фактично ці порти слугують для доступу до двох відмінних послуг, TCP до rlogin, а UDP до rwho.

2.3.9 Бібліотека сокетів

В операційних системах Un*x, програмне забезпечення що забезпечує виконання всіх завдань та протоколів описаних вище знаходиться в ядрі, так само це і в Linux. Найбільш відомий програмний інтерфейс до мережі в Un*x світі - Berkeley Socket Library. Його назва походить від популярної аналогії в якій порти розглядаються як гнізда (сокети), та під'єднання до порта як включення (pluging in). В бібліотеку входять : запит (bind(2)) для виклику вказаного віддаленого хоста, транспортний протокол, та служби з допомогою яких програми можуть під'єднуватись або прослуховувати (запити connect(2), listen(2) та accept(2)). Бібліотека сокетів є дещо більш загальною - вона підтримує не лише один класс базованих на TCP/IP сокетів (сокети AF INET), а також і клас що вказує на локальні під'єднання до машини (AF UNIX). Деякі програми можуть також використовувати інші класи, типу XNS (Xerox Networking System) протокол, або X.25.

В Linux бібліотека сокетів - частина стандартної C бібілотеки libc. На зараз підримуються тільки сокети AF INET та AF UNIX, але робиться все, щоб включити підтримку протоколів мережі Novell, так, щоб один чи більше клас сокетів було добавлено.

2.4 Мережі в Linux

Будучи результатом концентрованих зусиль програмістів у всьому світі, Linux, з самогих початків, не міг існувати без глобальної мережі. Тому і не дивно що вже на початкових стадіях розробки, кілька людей розпочали роботу по підтримці