Внутреннее устройство Linux - Уорд Брайан (читать книги полностью .txt) 📗
tcp 0 0 10.23.2.4:47626 10.194.79.125:5222 ESTABLISHED
tcp 0 0 10.23.2.4:41475 172.19.52.144:6667 ESTABLISHED
tcp 0 0 10.23.2.4:57132 192.168.231.135:22 ESTABLISHED
Поля Local Address и Foreign Address показывают соединения с точки зрения компьютера. Следовательно, для этого компьютера интерфейс настроен на IP-адрес 10.23.2.4, а локальные порты 47626, 41475 и 57132 подключены. Здесь первое соединение установлено между портом 47626 и портом 5222 по адресу 10.194.79.125.
9.14.2. Установление TCP-соединений
Чтобы установить соединение с помощью транспортного уровня, процесс на каком-либо хосте инициирует подключение одного из своих локальных портов ко второму хосту с помощью специальной серии пакетов. Чтобы распознать входящее соединение и ответить на него, второй хост должен обладать процессом, который прослушивает правильный порт. Как правило, подключающийся процесс называется клиентом, а прослушивающий — сервером (подробности изложены в главе 10).
О портах важно знать следующее: клиент выбирает такой порт со своей стороны, который в настоящее время не используется, но он практически всегда соединяется с каким-либо хорошо известным портом на стороне сервера. Вернитесь к выводу команды netstat из предыдущего раздела:
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 10.23.2.4:47626 10.194.79.125:5222 ESTABLISHED
С небольшой подсказкой можно понять, что это соединение с удаленным сервером было, по-видимому, инициировано локальным клиентом, так как порт локальной стороны (47626) выглядит как динамически присвоенное число, в то время как удаленный порт (5222) является хорошо известной службой (службой сообщений Jabber или XMPP, если быть конкретнее).
примечание
Динамически назначаемый порт называется эфемерным портом.
Однако если локальный порт в этом выводе хорошо известен, то соединение, вероятно, было инициировано удаленным хостом. В приведенном ниже примере удаленный хост 172.24.54.234 подключился к порту 80 (веб-порт по умолчанию) локального хоста.
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 10.23.2.4:80 172.24.54.234:43035 ESTABLISHED
Удаленный хост, подключающийся к хорошо известному порту вашего компьютера, подразумевает, что сервер локального компьютера прослушивает данный порт. Чтобы убедиться в этом, выведите список всех TCP-портов, которые прослушивает ваш компьютер, с помощью команды netstat:
$ netstat -ntl
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN
—snip—
Строка, которая содержит значение 0.0.0.0:80 как локальный адрес, говорит о том, что локальный компьютер прослушивает подключения к порту 80 от удаленных компьютеров. Сервер может ограничить доступ к некоторым интерфейсам, как показано в последней строке, где нечто прослушивает соединения только в интерфейсе локального хоста. Чтобы узнать еще больше подробностей, воспользуйтесь командой lsof для идентификации процесса, выполняющего прослушивание (как рассказано в подразделе 10.5.1).
9.14.3. Номера портов и файл /etc/services
Как узнать, является ли порт хорошо известным? Однозначно сказать нельзя, но начать стоит с просмотра файла /etc/services, который переводит значения хорошо известных портов в имена. Это простой текстовый файл. Вы можете увидеть в нем записи вроде:
ssh 22/tcp # SSH Remote Login Protocol
smtp 25/tcp
domain 53/udp
Первый столбец содержит имя, а во втором указаны номер порта и относящийся к нему протокол транспортного уровня (который может отличаться от TCP).
примечание
В дополнение к файлу /etc/services по адресу http://www.iana.org/ существует онлайн-реестр портов, который регулируется документом RFC6335 о сетевых стандартах.
В Linux только те процессы, которые запущены с корневыми (superuser) правами, могут использовать порты с 1 по 1023. Все пользовательские процессы могут выполнять прослушивание и создавать соединения, применяя порты с 1024 и далее.
9.14.4. Характеристики протокола TCP
Протокол TCP популярен как протокол транспортного уровня, поскольку он требует сравнительно немного со стороны приложения. Процессу приложения надо знать лишь о том, как открывать (или прослушивать), считывать, записывать и закрывать соединение. Для приложения это напоминает входящие и исходящие потоки данных; процесс почти так же прост, как работа с файлом.
Однако за всем этим стоит большая работа. Для начала протоколу TCP необходимо знать о том, как разбивать исходящий от процесса поток данных на пакеты. Сложнее узнать, как преобразовать серию входящих пакетов во входной поток данных для процесса, в особенности тогда, когда входящие пакеты не обязательно приходят в правильном порядке. В дополнение к этому хост, использующий протокол TCP, должен выполнять проверку на ошибки: при пересылке через Интернет пакеты могут быть потеряны или повреждены, протокол TCP должен обнаружить и исправить подобные ситуации. На рис. 9.3 приведена упрощенная схема того, как хост может использовать протокол TCP для отправки сообщения.
К счастью, вам не нужно знать обо всем этом практически ничего, кроме того, что в Linux протокол TCP реализован главным образом в ядре, а утилиты, которые работают с транспортным уровнем, стремятся использовать структуры данных ядра. Одним из примеров является система фильтрации пакетов с помощью IP-таблиц, которая рассмотрена в разделе 9.21.
9.14.5. Протокол UDP
Протокол UDP является намного более простым транспортным уровнем по сравнению с протоколом TCP. Он определяет передачу только для отдельных сообщений, потока данных здесь нет. В то же время, в отличие от протокола TCP, протокол UDP не выполняет коррекцию утерянных или неправильно расположенных пакетов. На самом деле, хотя у протокола UDP и есть порты, он даже не обладает соединениями! Хост просто отправляет сообщение от одного из своих портов порту на сервере, а сервер отправляет что-либо обратно, если желает. Тем не менее в протоколе UDP все же присутствует выявление ошибок данных внутри пакета. Хост может установить, что пакет поврежден, но он ничего не должен делать в связи с этим.
Если протокол TCP похож на телефонный разговор, то протокол UDP напоминает отправку письма, телеграммы или мгновенного сообщения (за исключением того, что мгновенные сообщения более надежны). Приложения, которые используют протокол UDP, часто заинтересованы в скорости: отправить сообщение настолько быстро, насколько возможно. Им не нужны дополнительные данные, как в протоколе TCP, поскольку они предполагают, что сетевое соединение между двумя хостами достаточно устойчивое. Им не нужна, как в TCP-протоколе, коррекция ошибок, так как они располагают собственными системами обнаружения ошибок или же просто не обращают на них внимания.
Одним из примеров приложения, которое использует протокол UDP, является протокол NTP (Network Time Protocol, протокол сетевого времени). Клиент отправляет короткий и простой запрос серверу, чтобы получить текущее время, ответ сервера такой же краткий. Поскольку ответ необходим клиенту по возможности быстро, приложению годится протокол UDP; если ответ сервера затеряется где-либо в сети, клиент может просто направить повторный запрос или прекратить попытки. Другим примером является видеочат: в этом случае изображения пересылаются с помощью протокола UDP. Если некоторые фрагменты будут утрачены в пути, клиент на принимающей стороне сделает все возможное для их компенсации.
