Сетевые протоколы. Семейство протоколов TCP/IP
Так случилось, что Мефодий мало что знал о компьютерных сетях до знакомства с Linux. Если пользоваться только www-броузером и почтовой программой, сведений, вроде «у каждого компьютера Internet есть имя, на компьютерах бывает почта и WWW», бывает вполне достаточно. Строго говоря, если сеть настроена, почтовые клиенты или броузеры Linux не требуют большего объёма знаний. Однако Linux хорош именно тем, что позволяет проследить работу сети от процедур самого низкого уровня, вроде поведения сетевых карт, до приложений высокого уровня и их протоколов.
В разговоре о сетях передачи данных понятие «уровень» возникает неспроста. Дело в том, что передача данных между компьютерами — сложный процесс, в котором решается сразу несколько разноплановых задач. Если представить себе весь процесс организации сети «на пустом месте», как если бы никаких сетевых разработок доныне не было, все эти задачи встают одна за другой, по мере решения предыдущей.
Итак, если бы Мефодий получил задание «придумать Internet» на пару с Гуревичем, какие бы вопросы перед ними встали?
- Среда передачи данных. Посредством чего передавать данные? Как именно представляется передаваемая информация?
- Устройство передачи данных. (Раз уж известно, как передаются данные). Как подключаться к среде? Как отличить данные от не-данных (т. е. определить идёт ли передача)? Как определить очерёдность работы нескольких устройств, подключённых к одной среде передачи данных? Как определить, кому предназначаются даннее, передаваемые в общей среде?
- Топология неоднородной сети. (Раз уж известно, как подключить компьютер к одной или нескольким средам передачи данных). Если в сеть объединены несколько сред передачи данных, как определить адресата (и отправителя тоже)? Как обеспечить пересылку данных из одной среды в другую? Как выстроить непрерывный маршрут пересылок от отправителя к адресату.
- Доставка данных. (Раз уж есть механизм передачи данных от любого абонента сети к любому). Как обеспечить целостность и надёжность передачи данных (и нужно ли)? Как управлять самим каналом передачи данных (например, чтобы не отправлять данных больше, чем принимающая сторона в состоянии принять)? Как разделять несколько каналов передачи данных (например, когда от одного компьютера к другому одновременно передаются два файла)?
- Интерпретация данных. (Раз уж возможна надёжная и без искажений доставка). Что делать с полученными данными? Какие части операционной системы отвечают за их обработку, и откуда про это знает абонент с другой стороны соединения?
Ответы на эти вопросы в формализованном виде носят название протоколов: в них пунктуально описывается, как именно предлагается решать ту или иную задачу, какая для этого потребна дополнительная информация, какова должна быть логика поведения передающей и принимающей стороны и т. п.
В приведённом делении на этапы (уровни) примечательна их относительная независимость: если группа задач, связанная с некторым уровнем, решена, на следующем уровне можно забыть, как именно решались эти задачи. Так, устройство передачи данных типа «Ethernet» с точки зрения компьютера всегда одно и то же, какой бы носитель при этом не использовался: коаксиальный кабель или кабель типа «витая пара», хотя с физической и даже топологической точки зрения эти среды сильно различаются.
Ethernet с коаксиальным кабелем имеет топологию «общая шина»: все абоненты подключаются к единому кабелю, «врезая» в него Т-образный отводок; ethernet с витой парой имеет топологию «звезда»: от каждого абонента идёт собственный кабель к центральному устройству-концентратору.
Точно так же обстоят дела при переходе со второго уровня на третий: во время получения данных уже совершенно неважно, какие среды передачи были при этом задействованы (ethernet, три провода, голубиная почта. ).
Организация TCP/IP с помощью почтовых голубей описана в RFC1149.
Переход с третьего уровня на четвёртый и с четвёртого на пятый тоже обладает этим свойством.
По всей видимости, именно с этими задачами сталкивались и разработчики из института ARPA (Advanced Research Projects Agency, «Агенство Перспективных Исследовательских Проектов»; в процессе работы оно было переименовано в DARPA, где «D» означало Defence). По крайней мере, предложенное ими в середине семидесятых семейство протоколов TCP/IP также подразделялось на пять уровней: аппаратный, интерфейсный, сетевой, транспортный и прикладной. Впоследствии аппаратный уровень стали смешивать с интерфейсным, так как с точки зрения операционной системы они неразличимы.
Поэтому, если в книге написано, что TPC/IP имеет четыре уровня, это тоже будет правдой — с учётом двойственности самого нижнего.
Именно разделение на независимые друг от друга уровни позволило со временем объединить большинство разнородных локальных сетей в единое сетевое пространство — глбальную сеть Internet.
В TCP/IP вопрос о том, как обеспечить нескольким абонентам сети возможность передавать данные, не мешая друг другу, решён с помощью разделения пакетов данных. Разделение пакетов предполагает, что данные передаются не единым блоком, а по частям, пакетами. Алгоритмы, определяющие, когда абоненту разрешено посылать следующий пакет, могут быть разными, но результат всегда один: в сети передаются попеременно фрагменты всех сеансов передачи данных. В сильно загруженном состоянии такая сеть может просто не принять очередной пакет от абонента-отправителя, и тому придётся ждать удобного случая, чтобы всё-таки «пропихнуть» его в переполненную другими пакетами среду. Таким образом, обеспечить гарантированное время передачи одного пакета в сетях с разделением пакетов бывает довольно сложно, хотя есть алгоритмы, позволяющие это сделать.
Протвоположность метода разделения пакетов — метод разделения каналов, который предполагает, что в сети имеется определённое число каналов передачи данных, которые абоненты сети арендуют на всё время передачи. По такому принципу построены, например, телефонные линии: дозвонившись, мы арендуем канал связи между двумя телефонными аппаратами, и до тех пор, пока этот канал занят, невозможно ни воспользоваться им кому-то другому, ни огранизовать параллельно передачу данных откуда-нибудь ещё. Главное достоинство сетей с разделением каналов — постоянная (за вычетом помех на линии) скорость передачи данных. Главный недостаток — ограниченное количество каналов передачи. Проектировать среду передачи так, чтобы каждый абонент был связан с каждым отдельным каналом, имеет смысл только когда абонентов очень мало: количество каналов будет пропорционально квадрату количества абонентов. Количество каналов в большой сети будет существенно меньшим, и ровно столько сеансов передачи данных можно будет в этой сети установить. Попытка соединиться с абонентом, когда все каналы уже заняты, окончится неудачей. Мефодий припомнил своего знакомого, дозвониться которому тяжело, хотя телефон тот занимает нечасто и не подолгу. По всей видимости, каналов между какими-то двумя АТС, через которые Мефодий связывается с приятелем, хронически недостаёт (так бывает, когда отдалённый район быстро застраивается и наполняется телефонами).
Если вернуться к сети с разделением пакетов, то можно заметить, что на каждом уровне, под пакетом понимается разное. С точки зрения интерфейсного уровня пакет — это ограниченный возможностями среды передачи данных фрагмент, в котором необходимо дополнительно указать, какое устройство из числа подключённых к среде передачи данных его отправило, и какому устройству он предназначен. С точки зрения сетевого уровня размер пакета определяется удобством его обработки, а дополнительно в нём надо указать уникальные для всей сети адреса отправителя и получателя (а также тип протокола и многое другое). С точки зрения уровня транспортного размер пакета определяется качеством связи (чем меньше пакет, тем ниже вероятность порчи, но тем больше теряется на дополнительной информации: идентификатор сеанса, тип, специальные поля, описывающие логику связи и т.п.). Наконец, если на прикладном уровне определено понятие «пакет», то размер его и содержимое определяются протоколом прикладного уровня.
Таким образом, процесс передачи данных выглядит так: порция данных прикладного уровня нарезается на части, соответствующие размеру пакета транспортного уровня (фрагментируется), к каждому фрагменту приписывается транспортная служебная информация, получаются пакеты транспортного уровня. Каждый пакет транспортного уровня может быть опять-таки фрагментирован для передачи по сети, к каждому получившемуся фрагменту добавляется служебная информация сетевого уровня, что даёт последовательность сетевых пакетов. Каждый сетевой пакет тоже может быть фрагментирован до размера, «пролезающего» через конкретное сетевае устройство, из него формируются пакеты интерфейсного уровня (фреймы). Наконец, к каждому фрейму само устройство (по крайне мере, так это сделано в Ethernet) приписывает некоторый ключ, по которому принимающее устройство распознаёт начало фрейма. В таком виде данные передадутся по проводам. Процесс «заворачивания» пакетов более высокого уровня в пакеты более низкого уровня называется инкапсуляцией.
Компьютер, получивший фрейм, выполняет процедуры, обратные инкапсуляции и фрагментации: пакеты низкого уровня освобождаются от служебной информации и накапливаются до тех пор, пока не сформируется пакет более бысокого уровня. Затем этот пакет отсылается на уровень выше и всё повторяется до тех пор, пока освобождённые от всей дополнительной информации и заново собранные воедино данные не попадут к пользователю (или к программе, которая их обрабатывает).
сетевой пакет Единица передачи информации в компьютерной сети. Помимо передаваемых данных содержит служебную информацию, в частности, идентификаторы отправителя и адресата, контрольную сумму, поля используемого протокола. Наибольший размер пакета определяется чаще всего не объёмом передаваемых данных, а требованиями протокола и необходимостью разделять сеть передачи данных между несколькими абонентами.
TCP/IP
Протокол управления передачей и межсетевой протокол (TCP/IP) — это стандартный набор протоколов, разработанный в конце 1970-х Агентством передовых оборонных исследовательских проектов (DARPA) как средство взаимодействия между различными типами компьютеров и компьютерными сетями. TCP/IP является движущей силой интернета и поэтому является самым популярным стеком сетевых протоколов на Земле.
Введение в TCP/IP
Два компонента протокола TCP/IP представляют разные аспекты компьютерного взаимодействия. Межсетевой протокол («IP» в TCP/IP) — это протокол без установления соединения, который предоставляет только маршрутизацию пакетов, используя IP пакет (datagram) как основной блок сетевой информации. IP пакет содержит заголовок с последующим сообщением. Протокол управления передачей («TCP» в TCP/IP) позволяет сетевым хостам устанавливать соединения, которые могут использоваться для передачи потоков данных. TCP также гарантирует, что данные между подключениями будут доставлены и что они придут на сетевой хост в том же порядке, как они были посланы с другого.
Настройка TCP/IP
Общие элементы настройки TCP/IP и их назначение следующие:
IP адрес IP адрес — это уникальная идентифицирующая строка, представленная в виде четырех десятичных чисел от 0 до 255, разделенных точками, каждое из которых представляет 8-битный адрес, составляющие полный 32-битный адрес Этот формат называют точечной четверичной записью (dotted quad notation).
Сетевая маска Маска подсети (или просто сетевая маска) — это локальная побитовая маска или набор флагов, которые разделяют IP адрес на часть, значимую для всей сети, и биты, значимые для данной подсети. Например, в сети класса C стандартная сетевая маска 255.255.255.0, которая маскирует первые 3 байта IP адреса и делает последний байт адреса доступным для хостов, определенных в подсети.
Адрес сети Адрес сети представляет собой байты, составляющие сетевую часть IP адреса. Например, хост 12.128.1.2 в сети класса A будет использовать 12.0.0.0 в качестве адреса сети, где 12 представляет первый байт IP адреса (сетевая часть) и нули в оставшихся трех байтах для предоставления возможных значений для хостов. Сетевой хост, использующий частный IP адрес 192.168.1.100 будет использовать для адреса сети 192.168.1.0, который определяет первые три байта сети 192.168.1 класса C и 0 для всех возможных хостов сети.
Адрес рассылки Адрес рассылки — это IP адрес, который позволяет посылать сетевые данные на все хосты заданной подсети вместо того чтобы задавать определенный хост. Стандартный общий адрес рассылки для IP сетей 255.255.255.255, но этот адрес рассылки не может быть использован для отправки сообщения каждому хосту в интернете, поскольку роутеры его блокируют. Более уместно устанавливать адрес рассылки, соответствующий вашей подсети. Например, в частной IP сети класса С 192.168.1.0 адрес рассылки будет 192.168.1.255. Широковещательные сообщения обычно создаются сетевыми протоколами, такими как протокол определения адреса (ARP) и информационный протокол маршрутизации (RIP).
Адрес шлюза Адрес шлюза — это IP адрес, через который можно соединится с определенной сетью или хостом в сети. Если один сетевой хост хочет соединиться с другим хостом в сети, и этот хост находится не в этой же сети, необходимо использовать шлюз. В большинстве случаев адрес шлюза является адресом роутера в этой сети, который включается для пропускания трафика к другим сетям или хостам, таким как интернет хостам. Значение адреса шлюза должно быть корректным или система не сможет получать доступ к хостам за пределами этой самой сети.
Доступ к странице системного руководства по интерфейсам следующей командой:
Доступ к странице системного руководства по resolv.conf следующей командой:
IP маршрутизация
IP маршрутизация — это средства по обнаружению и изучению путей в сети TCP/IP по которым могут передаваться сетевые данные. Маршрутизация использует набор таблиц маршрутизации для непосредственного направления сетевых пакетов данных от источника к точке назначения, обычно через множество узлов сети, известных как роутеры. Существует две простейшие формы IP маршрутизации: статическая и динамическая.
Статическая маршрутизация предполагает ручное добавление IP маршрутов в системную таблицу маршрутизации, и обычно это делается через изменение таблицы маршрутизации командой route. Статическая маршрутизация предоставляет много преимуществ по сравнению с динамической маршрутизацией, такие как простота реализации на небольших сетях, предсказуемость (таблица маршрутизации всегда составлена заблаговременно и поэтому всегда используется маршрут, который в точности повторяется каждый раз), и низкая нагрузка на другие роутеры и сетевые соединения из-за недостатков протокола динамической маршрутизации. Однако у статической маршрутизации есть и слабые места. Например, статическая маршрутизация ограничена небольшими сетями и не может наращиваться. Статическая маршрутизация также не приспосабливается к сетевым обрывам и сбоям на маршруте из-за статичной природы своих маршрутов.
Динамическая маршрутизация полагается на большие сети с несколькими возможными IP маршрутами от источника к приемнику и использует для этого специальные протоколы маршрутизации, такие как RIP, который управляет автоматическим регулированием таблиц маршрутизации, что и делает динамическую маршрутизацию возможной. Динамическая маршрутизация имеет ряд преимуществ над статической, таких как хорошая масштабируемость и возможность адаптации к сбоям и обрывам в сетевых соединениях. Кроме того она требует меньше ручного администрирования таблиц маршрутизации, поскольку роутеры сами узнают один от другого о своем существовании и доступных маршрутах. Эта особенность также исключает возможность внесения ошибок в таблицу маршрутов из-за человеческого фактора. Динамическая маршрутизация не совершенна, поскольку у нее существуют слабые места, такие как повышенная сложность и дополнительная нагрузка от взаимодействия роутеров, которые не дают немедленного эффекта конечным пользователям, а только используют полосу пропускания сети.
TCP и UDP
TCP — это протокол основанный на соединении, обеспечивающий коррекцию ошибок и гарантирующий доставку данных с использованием так называемого управления потоком. Управление потоком определяет когда передачу потока данных необходимо остановить и когда послать пакеты данных повторно, например, из-за сбоев в канале, тем самым убеждаясь в завершенности и аккуратности переданных данных. TCP обычно используется для обмена важной информации, таких как транзакции базы данных.
С другой стороны, пользовательский пакетный протокол (UDP) — это протокол без установления соединения, который редко используется для передачи важных данных, поскольку не использует управление потоком и иные методы проверки целостности передаваемых данных. UDP обычно используется в таких приложениях, как передача аудио- и видео-потоков, поскольку он значительно быстрее TCP из-за отсутствия коррекции ошибок и управления потоком, где потеря нескольких пакетов обычно не катастрофично.
Сервисы (Daemons)
Сервисы — это специальные системные приложения, которые обычно выполняются длительно в фоновом режиме и ожидающие запросов на выполнение определенных функций от других приложений. Много сервисов связаны с сетевым обменом, то есть большое количество сервисов, работающих в фоне в Ubuntu могут предоставлять сетевую функциональность. Среди таких сетевых сервисов сервис гипертекстового транспортного протокола (httpd), которые обеспечивает функциональность web сервера; сервис безопасной оболочки (sshd), который обеспечивает безопасный удаленный доступ и возможность передачи файлов; и сервис протокола IMAP (imapd), обеспечивающий сервис почтовых сообщений.
Ссылки
Существуют страницы руководств по TCP и IP, которые содержат больше полезной информации.
Также посмотрите TCP/IP Tutorial and Technical Overview из «красной книги» IBM.
Linux — Networking Deep Dive
Like CPU, memory and I/O, network is the core function of Linux system. Network is a technology that connects different computers or network devices together.
It is essentially an inter-process communication method, especially inter-process communication across systems, which must be carried out through the network.
Сетевые интерфейсы, протоколы и сетевые сокеты Linux
Сетевая подсистема Linux организует сетевой обмен пользовательских приложений и, как следствие, сетевое взаимодействие самих пользователей.
Часть сетевой подсистемы, выполняющаяся в режиме ядра, естественным образом ответственна за управление сетевыми устройствами ввода-вывода, но кроме этого на нее также возложены задачи маршрутизации и транспортировки пересылаемых данных, которые решаются при помощи соответствующих Сетевых протоколов. Таким образом, именно ядерная часть сетевой подсистемы обеспечивает процессы средствами сетевого межпроцессного взаимодействия (network IPC).
Внеядерная часть сетевой подсистемы отвечает за реализацию сетевых служб, предоставляющих пользователям прикладные сетевые услуги, такие как передача файлов, обмен почтовыми сообщениями, удаленный доступ и т. д.
Непосредственное, физическое взаимодействие сетевых узлов через каналы связи между ними реализуется аппаратурой сетевых адаптеров. Сетевые адаптеры, как и любые другие устройства ввода-вывода, управляются соответствующими драйверами, реализующимися в большинстве случаев в виде динамических модулей ядра.
Драйверы сетевых устройств
$ lspci
01:00.0 Network controller: Intel Corporation Centrlno Wireless-N 130 (rev 34)
02:60.0 Ethernet controller: …, Ltd. RTL8111/8168B PCI Express … Ethernet controller …
$ lspci -ks 01:00.0
01:00.0 Network controller: Intel Corporation Centrlno Wireless-N 130 (rev 34)
Subsystem Intel Corporation Centrino Wireless-N 130 BGN
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi
02:00.0 Ethernet controller: …, Ltd. RTL8111/8168B PCI Express … Ethernet controller …
Subsystem: Samsung Electronics Co Ltd Device c0b6
Kernel driver in use: r8169
$ modinfo iwlwifi r8169 | grep ^description
description: Intel(R) Wireless WiFi driver for Linux
description: RealTek RTL-8169 Gigabit Ethernet driver
В отличие от несетевых устройств, большинство которых имеют специальный файл в каталоге /dev, сетевые устройства представляются в системе своими интерфейсами. Список доступных интерфейсов, их параметры и статистику можно получить при помощи «классической» UNIX-команды ifconfig или специфичной для Linux команды ip.
Сетевые интерфейсы (UNIX ifconfig)
eth0 Link encap:Ethernet HWaddr e8:03:9a:0a:73:40
UP BROADCAST MULTICAST MTU: 1500 Metric: 1
lo Link encap:Локальная петля (Loopback)
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
wlan0 Link encap:Ethernet HWaddr b8:03:05:a2:28:4e
inet addr:192.168.100.5 Bcast: 192.168.100.255 Mask-.255.255.255.0
inet6 addr: fe80::ba03:5ff:fea2:284e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
$ ifconfig wlanO
wlanO Link encap:Ethernet HWaddr b8:03:05:a2:28:4e
inet addr-.192.168.100.5 Beast: 192.168.100.255 Mask:255.255.255.0
inet6 addr: fe80: :ba03:5ff:fea2:284e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU: 1500 Metric: 1
RX packets:23103842 errors:0 dropped:0 overruns:0 frame:0
TX packets-.15591575 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2010967763 (2.0 GB) TX bytes:2828583098 (2.8 GB)
Сетевые интерфейсы (Linux ip)
$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000 link/ether e8:03:9a:0a:73:40 brd ff:ff:ff:ff:ff:ff
3: wlan0: «BROADCAST,MULTICAST,UP,L0WER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether b8:03:05:а2:28:4е brd ff:ff:ff:ff:ff:ff
$ ip -s link show dev wlanO
3: wlan0: «BROADCAST,MULTICAST,UP, LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether b8:03:05:a2:28:4e brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
2026956879 23261031 0 0 0 0
TX: bytes packets errors dropped carrier collsns
$ ip addr show dev wlanO
3: wlan0: «BROADCAST,MULTICAST,UP,L0WER_UP> mtu 1500 qdisc nq state UP qlen 1000
link/ether b8:03:05:a2:28:4e brd ff:ff:ff:ff:ff:ff
inet 192.168.100.5/24 brd 192.168.100.255 scope global wlan0
valid_lft forever preferred_lft forever
inet6 fe80::ba03:5ff: fea2:284e/64 scope link
valid_lft forever preferred_lft forever
За логическое взаимодействие (адресацию, маршрутизацию, обеспечение надежной доставки и пр.) отвечают сетевые протоколы, тоже в большинстве случаев реализующиеся соответствующими модулями ядра.
Нужно отметить, что в примере из листинга ниже показан список динамически загруженных модулей, среди которых присутствует «нестандартный» TCP vegas, но нет IP, TCP, UDP и прочих «стандартных» протоколов стека TCP/IP.
На текущий момент времени сложно вообразить применение Linux без подключения к IP-сети, поэтому модули стандартных протоколов TCP/IP стека скомпонованы в ядро статически и являются частью «стартового» модуля.
Драйверы сетевых протоколов
$ lsmod
Module Size Used by
tcp_vegas 13603 0
esp4 12868 0
ah4 12866 0
xfm_algo 14869 2 esp4,ah4
bnep 19167 2
bluetooth 356727 24 bnep,rf com,btusb
mac80211 564463 1 iwldvm
$ nodinfo tcp_vegas bnep mac86211 | grep ‘^description
description: TCP Vegas
description: Bluetooth BNEP ver 1.3
description: IEEE 862.11 subsystem
Доступ процессов к услугам ядерной части сетевой подсистемы реализует интерфейс сетевых сокетов socket, являющихся основным (и единственным) средством сетевого взаимодействия процессов в Linux.
Разные семейства (address family) сокетов соответствуют различным стекам сетевых протоколов. Например, стек TCP/IP v4 представлен семейством AFJNET, см. ip, стек TCP/IP v6 — семейством AF_INET6, см. ipv6, и даже локальные (файловые) сокеты имеют собственное семейство — AF_L0CAL, см. unix.
Для просмотра статистики по использованию сетевых сокетов применяют «классическую» UNIX-команду netstat или специфичную для Linux команду ss. В листингах ниже иллюстрируется использование этих команд для вывода информации обо всех (-a, all) сокетах протоколов (-u, udp) UDP и (-t, tcp) TCP стека TCP/IP v4 (-4), порты и адреса которых выведены в числовом (-n, numeric) виде, а также изображены процессы (-p, process), их открывшие.
Сетевые сокеты (UNIX netstat)
$ sudo netstat -4autpn
Активные соединения с интернетом (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0:0.0.0:5900 0.0.0:0:* LISTEN 28880/vino-server
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 5999/dnsmasq
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 655/sshd
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 1064/cupsd
tcp 0 0 192.168.100.5:22 192.168.100.3:57929 ESTABLISHED 15841/sshd: …
udp 0 0 0.0.0.0:5353 0.0.0.0:* 15094/avahi-daemon:
udp 0 0 0.0.0.0546347 0.0.0.0:* 15094/avahi-daemon:
udp 0 0 127.0.0.1:53 0.0.0.0:* 5999/dnsmasq
udp 0 0 0.0.0.0:68 0.0.0.0:* 5995/dhclient
Сетевые сокеты идентифицируются парой адресов (собственным, local, и чужим (адрес удаленного приложения, с которым установлено соединение), foreign), принятыми в их семействе. Например, для семейства TCP/IP адрес сокета состоит из (сетевого) IP-адреса и (транспортного) номера порта, причем нули имеют специальное — «неопределенное» значение.
Так для прослушивающего (LISTEN) сокета 0.0.00 в собственном IP-адресе означает, что он принимает соединения, направленные на любой адрес любого сетевого интерфейса, а 0.0.0.0 в чужом адресе указывает на то, что взаимодействие еще не установлено. Прослушивающие сокеты используются «серверными» приложениями, пассивно ожидающими входящие соединения с ними.
Для сокетов с установленным (ESTABLISHED) взаимодействием оба адреса имеют конкретные значения, определяющие участников взаимодействия, например 192.168.100.5:22 и 192.168.100.3:57929.
Сетевые сокеты (Linux ss)
$ sudo ss -4atupn
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
udp UNCONN 0 0 *:5353 *:* users: ((«avahi-daemon»,15094,13))
udp UNCONN 0 0 *:46347 *:* users: ((«avahi-daemon»,15094,15))
udp UNCONN 0 0 127.0.0.1:53 *:* users: ((«dnsmasq»,5999,4))
udp UNCONN 0 0 *:68 *:* users: ((«dhcltent”,5995,6))
udp UNCONN 0 0 *:5900 *:* users: ((«vino-server»,28880,14))
udp UNCONN 0 0 127.0.0.1:53 *:* users: ((«dnsmasq»,5999,5))
udp UNCONN 0 0 *:22 *:* users: ((«sshd»,655,4))
udp UNCONN 0 0 127.0.0.1:631 *:* users: ((«cupsd»,1064,10))
udp UNCONN 0 0 127.0.0.1:25 *:* users: ((«master»,2021,12))
Из примеров листингов выше видны 5 «слушающих» (LISTEN) сокетов TCP и 4«несоелииеиных» (UNCONN) сокета UDP, открытых разными службами операционной системы. Например, 22 порт TCP открыл сервер sshd, PID = 655 службы удаленного доступа W:[SSH], а 5900 порт TCP — сервер vino-server, PID = 28880 службы удаленного доступа к рабочему столу пользователя W:[VNC].
Сетевая подсистема ОС Linux чрезвычайно развита на всех ее уровнях — от сетевых интерфейсов и протоколов до прикладных сетевых служб. На сегодняшний день колоссальное количество сетевых устройств работают под управлением Linux — маршрутизаторы, сетевые хранилища, медиаплееры, TV-боксы, планшеты, смартфоны и прочие «встраиваемые» и мобильные устройства.
К сожалению, рассмотреть весь пласт сетевых возможностей в рамках этой статьи, не представляется возможным, т. к. потребует от читателя серьезного понимания устройства и функционирования самих сетевых протоколов стека TCP/IP, что не является предметом настоящего рассмотрения.
Основополагающим результатом должно стать понимание принципов организации сетевого взаимодействия в Linux, необходимое и достаточное в качестве базы для последующего самостоятельного расширенного и углубленного изучения. Не менее полезными в практике администратора и программиста будут навыки использования инструментов трассировки и мониторинга сетевых сокетов, а в особенно «непонятных» ситуациях навыки применения анализаторов пакетов.
Исключительное место (эдакий «швейцарский нож») среди прочих сетевых инструментов Linux займет служба SSH, при распределенном использовании оконной системы X Window System, являющейся основой современного графического интерфейса пользователя.