Значительная часть действий, которые вы наблюдали в этой главе, происходит в ядре с добавлением некоторых основных управляющих утилит из пространства пользователя, работающих с внутренними структурами данных ядра (например, с таблицами маршрутизации). Это традиционный способ работы с сетями. Однако некоторые задачи не подходят для ядра из-за своей сложности и требуемой от них гибкости. Тогда к делу подключаются утилиты из пространства пользователя. В частности, менеджер NetworkManager контролирует ядро и выполняет запросы, а затем управляет конфигурацией ядра. Еще один пример — поддержка протоколов динамической маршрутизации, таких как протокол BGP (Border Gateway Protocol, пограничный шлюзовый протокол), который используется в больших интернет-маршрутизаторах.
Возможно, к этому моменту вам немного наскучило конфигурирование сети. Перейдем к ее использованию на прикладном уровне.
10. Сетевые приложения и службы
В этой главе рассмотрены основы сетевых приложений — клиентов и серверов, работающих в пространстве пользователя, которое располагается на прикладном уровне. Так как этот уровень находится на самом верху стека, ближе всего к конечным пользователям, материал данной главы более доступен, по сравнению с главой 9. Действительно, вы взаимодействуете с такими клиентскими сетевыми приложениями, как браузеры и почтовые клиенты, каждый день.
Для выполнения своей работы сетевые клиенты подключаются к соответствующим сетевым серверам. Сетевые серверы Unix включаются в дело различными способами. Серверная команда может либо самостоятельно прослушивать порт, либо через вторичный сервер. В дополнение к этому у серверов нет общей базы данных конфигурации и широкого набора функций. Большинство серверов использует файл конфигурации для контроля своего поведения (хотя для такого файла и нет установленного формата), а многие применяют также системную службу syslog для записи уведомлений. Мы рассмотрим некоторые распространенные серверы, а также инструменты, которые помогут вам понять и отладить работу сервера.
Сетевые клиенты используют протоколы и интерфейсы транспортного уровня операционной системы, поэтому важно понимать основы транспортных уровней TCP и UDP. Начнем рассмотрение сетевых приложений, поэкспериментировав с сетевым клиентом, который использует протокол TCP.
10.1. Основные понятия о службах
Службы TCP являются одними из самых простых для понимания, поскольку они построены на несложных, непрерывных двухсторонних потоках данных. Вероятно, лучший способ увидеть, как они работают, — «пообщаться» с веб-сервером напрямую через TCP-порт 80 и получить представление о том, как данные перемещаются через это соединение. Запустите, например, такую команду для подключения к веб-серверу:
$ telnet www.wikipedia.org 80
Вы должны увидеть в ответ нечто подобное:
Trying
Connected to www.wikipedia.org.
Escape character is '^]'.
Теперь введите:
GET / HTTP/1.0
Нажмите клавишу Enter дважды. Сервер должен отправить в виде ответа некоторое количество HTML-текста, а затем разорвать соединение.
Это упражнение говорит нам о том, что:
• на удаленном хосте есть процесс веб-сервера, прослушивающий TCP-порт 80;
• клиентом, который инициировал соединение, являлась команда telnet.
примечание
Команда telnet изначально была предназначена для осуществления входа на удаленные хосты. Хотя вход на удаленный сервер с помощью команды telnet без использования технологии Kerberos совершенно не защищен (как вы увидите далее), клиент telnet может быть полезен для отладки удаленных служб. Команда telnet не работает с протоколом UDP или любым транспортным уровнем, отличным от TCP. Если вы ищете сетевой клиент общего назначения, попробуйте команду netcat, описанную в подразделе 10.5.3.
В приведенном выше примере вы вручную выполнили взаимодействие с веб-сервером в сети с помощью команды telnet, использовав протокол HTTP (Hypertext Transfer Protocol, протокол передачи гипертекста) прикладного уровня. Хотя в обычных условиях вы воспользовались бы браузером для установления подобного соединения, немного отойдем от команды telnet и применим команду, которая знает, как «говорить» с прикладным уровнем HTTP. Мы используем утилиту curl со специальным параметром, чтобы записать подробности ее взаимодействия:
$ curl —trace-ascii
примечание
В вашей версии ОС может не оказаться встроенной утилиты curl, но, если она понадобится, ее установка не должна вызвать трудностей.
Вы получите обширный отчет в формате HTML. Проигнорируйте его (или перенаправьте в устройство /dev/null) и вместо этого посмотрите только что созданный файл trace_file. При условии, что соединение оказалось успешным, первая часть этого файла, в том месте, где команда curl пытается установить TCP-соединение с сервером, должна выглядеть так:
