Операционная система UNIX

Робачевский Андрей М.

Глава 6

Поддержка сети в операционной системе UNIX

 

 

Сегодня изолированный компьютер имеет весьма ограниченную функциональность. Дело даже не в том, что пользователи лишены возможности доступа к обширным информационным и вычислительным ресурсам, расположенным на удаленных системах. Изолированная система не имеет требуемой в настоящее время гибкости и масштабируемости. Возможность обмена данными между рассредоточенными системами открыла новые горизонты для построения распределенных ресурсов, их администрирования и наполнения, начиная от распределенного хранения информации (сетевые файловые системы, файловые архивы, информационные системы с удаленным доступом), и заканчивая сетевой вычислительной средой. UNIX — одна из первых операционных систем, которая обеспечила возможность работы в сети. И в этом одна из причин ее потрясающего успеха и долгожительства.

Хотя многие версии UNIX сегодня поддерживают несколько сетевых протоколов, в этой главе мы подробнее остановимся на наиболее известном и распространенном семействе под названием TCP/IP. Эти протоколы были разработаны, а затем прошли долгий путь усовершенствований для обеспечения требований феномена XX века — глобальной сети Internet. Протоколы TCP/IP используются практически в любой коммуникационной среде, от локальных сетей на базе технологии Ethernet или FDDI, до сверхскоростных сетей ATM, от телефонных каналов точка-точка до трансатлантических линий связи с пропускной способностью в сотни мегабит в секунду.

Глава начинается с описания наиболее важных протоколов семейства TCP/IP — Internet Protocol (IP), User Datagram Protocol (UDP) и Transmission Control Protocol (TCP). Здесь описываются стандартная спецификация этих протоколов и особенности реализации их алгоритмов, не определенные стандартами, но позволяющие значительно повысить производительность работы в сети.

Далее обсуждается программный интерфейс доступа к протоколам TCP/IP. При этом рассматриваются два основных интерфейса — традиционный интерфейс работы с протоколами TCP/IP — интерфейс сокетов, изначально разработанный для системы BSD UNIX, и интерфейс TLI, позволяющий унифицированно работать с любыми сетевыми протоколами, соответствующими модели OSI. В конце раздела описан программный интерфейс более высокого уровня, позволяющий отвлечься от особенностей сетевых протоколов и полностью сосредоточиться на определении интерфейса и функциональности предоставляемых прикладных услуг. Эта система, которая называется RPC (Remote Procedure Call — удаленный вызов процедур), явилась предтечей современных систем разработки распределенных приложений, таких как CORBA (Common Object Request Broker), Java и т.д.

В последних разделах главы рассматривается архитектура сетевого доступа в двух основных ветвях операционной системы — BSD UNIX и UNIX System V.

 

Семейство протоколов TCP/IP

 

В названии семейства присутствуют имена двух протоколов — TCP и IP. Это, конечно, не означает, что данными двумя протоколами исчерпывается все семейство. Более того, как будет видно, названные протоколы выполняют различные функции и используются совместно.

В 1969 году Агентство Исследований Defence Advanced Research Projects Agency (DAPRA) Министерства Обороны США начало финансирование проекта по созданию экспериментальной компьютерной сети коммутации пакетов (packet switching network). Эта сеть, названная ARPANET, была построена для обеспечения надежной связи между компьютерным оборудованием различных производителей. По мере развития сети были разработаны коммуникационные протоколы — набор правил и форматов данных, необходимых для установления связи и передачи данных. Так появилось семейство протоколов TCP/IP. В 1983 году TCP/IP был стандартизирован (MIL STD), в то же время агентство DAPRA начало финансирование проекта Калифорнийского университета в Беркли по поддержке TCP/IP в операционной системе UNIX.

Основные достоинства TCP/IP:

□ Семейство протоколов основано на открытых стандартах, свободно доступных и разработанных независимо от конкретного оборудования или операционной системы. Благодаря этому TCP/IP является наиболее распространенным средством объединения разнородного оборудования и программного обеспечения.

□ Протоколы TCP/IP не зависят от конкретного сетевого оборудования физического уровня. Это позволяет использовать TCP/IP в физических сетях самого различного типа: Ethernet, Token-Ring, т.е. практически в любой среде передачи данных.

□ Протоколы этого семейства имеют гибкую схему адресации, позволяющую любому устройству однозначно адресовать другое устройство сети. Одна и та же система адресации может использоваться как в локальных, так и в территориально распределенных сетях, включая Internet.

□ В семейство TCP/IP входят стандартизированные протоколы высокого уровня для поддержки прикладных сетевых услуг, таких как передача файлов, удаленный терминальный доступ, обмен сообщениями электронной почты и т.д.

 

Краткая история TCP/IP

История создания и развития протоколов TCP/IP неразрывно связана с Internet — интереснейшим достижением мирового сообщества в области коммуникационных технологий. Internet является глобальным объединением разнородных компьютерных сетей, использующих протоколы TCP/IP и имеющих общее адресное пространство. Явление Internet уникально еще и потому, что эта глобальная сеть построена на принципах самоуправления (хотя ситуация отчасти начинает меняться). Однако вернемся к истории.

Сегодняшняя сеть Internet "родилась" в 1969 году, когда агентство DARPA получило заказ на разработку сети, получившей название ARPANET. Целью создания этой сети было определение возможностей использования коммуникационной технологии пакетной коммутации. В свою очередь, агентство DARPA заключило контракт с фирмой Bolt, Beranek and Newman (BBN). В сентябре 1969 года произошел запуск сети, соединивший четыре узла: Станфордский исследовательский институт (Stanford Research Institute), Калифорнийский университет в Санта-Барбаре (University of California at Santa Barbara), Калифорнийский университет в Лос-Анжелесе (University of California at Los Angeles) и Университет Юты (University of Utah). Роль коммуникационных узлов выполняли мини-компьютеры Honeywell 316, известные как Interface Message Processor (IMP).

Запуск и работа сети были успешными, что определило быстрый рост ARPANET. В то же время использованием сети в своих целях заинтересовались исследователи, далекие от военных кругов. Стали поступать многочисленные запросы от руководителей университетов США в Национальный научный фонд (National Science Foundation, NSF) с предложениями создания научно-образовательной компьютерной сети. В результате в 1981 году NSF одобрил и финансировал создание сети CSNET (Computer Science Network).

В 1984 году ARPANET разделилась на две различные сети: MILNET, предназначенную исключительно для военных приложений, и ARPANET для использования в "мирных" целях.

В 1986 году фонд NSF финансировал создание опорной сети, соединившей каналами с пропускной способностью 56 Кбит/с шесть суперкомпьютерных центров США. Сеть получила название NSFNET и просуществовала до 1995 года, являясь основной магистралью Internet. За это время пропускная способность опорной сети возросла до 45 Мбит/с, а число пользователей превысило 4 миллиона.

Стремительное развитие NSFNET сделало бессмысленным дальнейшее существование ARPANET. В июне 1990 года Министерство обороны США приняло решение о прекращении работы сети. Однако уроки, полученные в процессе создания и эксплуатации ARPANET, оказали существенное влияние на развитие коммуникационных технологий, таких как локальные сети и сети пакетной коммутации.

При создании ARPANET был разработан и протокол сетевого взаимодействия коммуникационных узлов. Он получил название Network Control Program (NCP). Однако этот протокол строился на предположении, что сетевая среда взаимодействия является абсолютно надежной. Учитывая специфику ARPANET, такое предположение являлось, мягко говоря, маловероятным: качество коммуникационных каналов могло существенно изменяться в худшую сторону (особенно при предполагаемом использовании радио- и спутниковой связи), а отдельные сегменты сети могли быть разрушены. Таким образом, подход к коммуникационной среде нуждался в пересмотре, и, как следствие, возникла необходимость разработки новых протоколов. Еще одной задачей, стоявшей перед разработчиками, являлось обеспечение согласованной работы связанных сетей (internet), использующих различные коммуникационные технологии (например, пакетное радио, спутниковые сети и локальные сети). Результатом исследований в этой области явилось рождение нового семейства протоколов — Internet Protocol (IP), с помощью которого осуществлялась базовая доставка данных в гетерогенной коммуникационной среде, и Transmission Control Protocol (TCP), который обеспечивал надежную передачу данных между пользователями в ненадежной сетевой инфраструктуре. Спецификации этих протоколов в 1973 году получили статус стандартов Министерства обороны MIL-STD-1777 и MIL-STD-1778 соответственно.

 

Архитектура TCP/IP

Архитектура семейства протоколов TCP/IP основана на представлении, что коммуникационная инфраструктура включает три объекта: процессы, хосты, и сети. Процессы являются основными коммуникационными объектами, поскольку между процессами, в конечном итоге, осуществляется передача информации. Выполнение процессов происходит на различных хостах (или компьютерах). Передача информации между процессами проходит через сети, к которым подключены хосты.

Подобный взгляд на вещи позволяет сделать основной вывод: чтобы доставить данные процессу, их необходимо сначала передать нужному хосту, а затем определенному процессу, который выполняется на этом хосте. Более того — эти две фазы могут выполняться независимо. Таким образом, от коммуникационной инфраструктуры требуется маршрутизация и доставка данных между хостами, а хосты, в свою очередь, обязаны обеспечить доставку нужным процессам.

Основываясь на этом простом соображении, при разработке семейства протоколов взаимодействия логичным было четкое распределение обязанностей между отдельными протоколами, представив их в виде нескольких уровней. Разработчиками было выбрано четыре уровня:

□ Уровень приложений/процессов (Application/process layer)

□ Транспортный уровень (Host-to-host layer)

□ Уровень Internet (Internet layer)

□ Уровень сетевого интерфейса (Network interface layer)

Уровень сетевого интерфейса составляют протоколы, обеспечивающие доступ к физической сети. С помощью этих протоколов осуществляется передача данных между коммуникационными узлами, подключенными к одному и тому же сетевому сегменту (например, сегменту Ethernet или каналу точка-точка). Протоколы этого уровня должны поддерживаться всеми активными устройствами, подключенными к сети (например, мостами). К этому уровню относятся протоколы Ethernet, IEEE802.X, SLIP, PPP и т.д. Протоколы уровня сетевого интерфейса формально не являются частью семейства TCP/IP, однако стандарты Internet определяют, каким образом должна осуществляться передача данных TCP/IP с использованием вышеперечисленных протоколов.

Уровень Internet составляют протоколы, обеспечивающие передачу данных между хостами, подключенными к различным сетям. Одной из функций, которая должна быть реализована протоколами этого уровня, является выбор маршрута следования данных, или маршрутизация. Сетевые элементы, осуществляющие передачу данных из одной сети в другую, получили название шлюзов (gateway). Шлюз имеет несколько сетевых интерфейсов, подключенных к различным физическим сетям, и его основной задачей является выбор маршрута передачи данных из одного сетевого интерфейса в другой. Основной представитель уровня Internet — протокол IP.

Протоколы транспортного уровня обеспечивают передачу данных между процессами, выполняющихся на разных хостах. Помимо этого транспортные протоколы могут реализовывать дополнительные функции, например, гарантированную доставку, создание виртуального канала и т.д. К транспортному уровню относятся протоколы TCP и UDP.

Наконец, протоколы уровня приложений обеспечивают функционирование прикладных услуг, таких как удаленный терминальный доступ, копирование удаленных файлов, передача почтовых сообщений и т.д. Работу этих приложений обеспечивают протоколы Telnet, File Transfer Protocol (FTP), Simple Mail Transfer Protocol (SMTP) и т.д.

На рис. 6.1 показана иерархическая четырехуровневая модель семейства протоколов TCP/IP. Заметим, что протоколы уровня сетевого интерфейса, фактически не являются частью семейства, поскольку не определены ни стандартами Министерства обороны США, ни стандартами Internet. Вместо этого используются существующие протоколы сети и определяются методы передачи трафика TCP/IP с помощью данной коммуникационной технологии. Например, RFC894 (A Standard for the Transmission of IP Datagrams over Ethernet Networks) определяет формат и процедуру передачи IP-пакетов в сетях Ethernet, a RFC 1577 (Classical IP and ARP over ATM) — в сетях ATM.

Рис. 6.1. Архитектура протоколов TCP/IP

На рис. 6.2 показана базовая коммуникационная схема протоколов TCP/IP. Коммуникационная инфраструктура может состоять из нескольких физических сетей. Для передачи данных в физической сети между подключенными хостами используется некоторый протокол уровня сетевого интерфейса, определенный для данной технологии передачи данных (Ethernet, FDDI, ATM и т.д.). Отдельные сети связаны между собой шлюзами, — устройствами, подключенными одновременно к нескольким сетям и служащими для передачи пакетов данных из одного интерфейса в другой. Выполнение этой функции обеспечивается протоколом IP. Как видно из рисунка, протокол IP выполняется на хостах и шлюзах и в конечном итоге обеспечивает доставку данных от хоста-отправителя к хосту- получателю. За обмен данными между процессами отвечают протоколы транспортного уровня — TCP или UDP. Поскольку работа транспортных протоколов обеспечивает передачу данных между удаленными процессами, протоколы этого уровня должны быть реализованы на хостах. При этом шлюзов для TCP или UDP как бы не существует, поскольку их присутствие и работу полностью скрывает протокол IP. Наконец, процессы также используют некоторый протокол для обмена данными, например Telnet или FTP.

Рис. 6.2. Коммуникационная схема TCP/IP

Для правильного обмена данными каждый коммуникационный узел должен иметь уникальный адрес. На самом деле, как правило, существует несколько уровней адресации. Например, в локальной сети, каждый сетевой интерфейс (первый уровень модели) имеет т.н. MAC-адрес. С помощью этого адреса обеспечивается доставка данных требуемому получателю в физической сети. Для доставки данных IP необходимо адресовать хост-получатель. Для этого используется т.н. IP- или Internet-адрес. Наконец, хост, получивший данные, должен доставить их требуемому процессу. Таким образом, каждый процесс хоста, участвующий в коммуникационном взаимодействии также имеет адрес. Этот адрес получил название номера порта.

Таким образом, для того чтобы однозначно адресовать принимающую сторону, отправитель данных должен указать адреса хоста (IP-адрес) и процесса на этом хосте (номер порта). Он также должен указать, какой протокол транспортного уровня будет использован при обмене данными (номер протокола). Поскольку путь данных может проходить по нескольким физическим сегментам, физический адрес, или MAC-адрес, сетевого интерфейса не имеет смысла и определяется автоматически на каждом этапе пересылки (hop) между шлюзами.

Попробуем вкратце рассмотреть процесс передачи данных от процесса 2000 (номер порта), выполняющегося на хосте А, к процессу 23, выполняющемуся на хосте В. Согласно рис. 6.2 хосты расположены в разных физических сегментах, соединенных шлюзом X. Для этого процесс 2000 передает некоторые данные модулю протокола TCP (допустим, что приложение использует этот транспортный протокол), указывая, что данные необходимо передать процессу 23 хоста В. Модуль TCP, в свою очередь, передает данные модулю IP, указывая при только адрес хоста В. Модуль IP выбирает маршрут и соответствующий ему сетевой интерфейс (если их несколько) и передает последнему данные, указывая шлюз X в качестве промежуточного получателя.

Можно заметить, что наряду с передачей данных, каждый уровень обработки передает последующему некоторую управляющую информацию (IP-адрес, номер порта и т.д.). Эта информация необходима для правильной доставки данных адресату. Поэтому каждый протокол формирует пакет (Protocol Data Unit, PDU), состоящий из данных, переданных модулем верхнего уровня, и заголовка, содержащего управляющую информацию. Эта управляющая информация распознается модулем того же уровня (peer module) удаленного узла и используется для правильной обработки данных и передачи их соответствующему протоколу верхнего уровня.

На рис. 6.3 схематически показан процесс обработки данных при их передаче между хостами сети с использованием протоколов TCP/IP. С точки зрения процессов 23 и 2000 между ними существует коммуникационный канал, обеспечивающий надежную и достоверную передачу потока данных, внутреннюю структуру которого определяют сами процессы по предварительной договоренности (например, в соответствии с протоколом Telnet). Модуль TCP хоста А обменивается сегментами данных с парным ему модулем TCP хоста В, не задумываясь о топологии сети или физических интерфейсах. Задача модулей TCP заключается в обеспечении достоверной и последовательной передачи данных между модулями приложений (процессов). TCP не интерпретирует прикладные данные и ему безразлично, передается ли в сегменте фрагмент почтового сообщения, файл или регистрационное имя пользователя. В свою очередь модуль IP хоста А передает данные, полученные от транспортных протоколов, модулю IP хоста В, не заботясь о надежности и последовательности передачи. Он не интерпретирует данные TCP, поскольку его задача — правильно адресовать отправляемую датаграмму. Поэтому модулю IP все равно, передает ли он данные TCP или UDP, управляющие сегменты или инкапсулированные прикладные данные.

Рис. 6.3. Обработка данных в соответствии с протоколами TCP/IP

Работу модулей TCP/IP можно сравнить со сборочным конвейером: каждый участок выполняет определенную для него задачу, полагаясь на качество работы, выполненной на предыдущем этапе.

 

Общая модель сетевого взаимодействия OSI

При знакомстве с семейством протоколов TCP/IP мы отметили уровневую структуру этих протоколов. Каждый из уровней выполняет строго определенную функцию, изолируя в то же время особенности этой обработки и связанные с ней данные от протоколов верхнего уровня. Четкое определение интерфейсов между протоколами соседних уровней позволяет выполнять разработку и реализацию протоколов независимо, не внося изменений в другие модули системы. Характерным примером является интерфейс между протоколом IP и протоколами транспортного уровня TCP и UDP. Хотя последние выполняют различную обработку, их взаимодействие с IP идентично.

Развитие сетевых технологий и связанных с ними протоколов обмена данными наглядно показало необходимость стандартизации этого процесса. Вместе с тем было очевидно, что единый стандарт на все случаи жизни не может решить подобную задачу. Очевидно также, что коммуникационная архитектура должна иметь модульную структуру, в которой модули обладают стандартными интерфейсами взаимодействия и могут подключаться в соответствии с этими интерфейсами, образуя "конвейер" обработки данных. Все это позволяет считать наиболее жизнеспособным подход, когда в рамках общей модели или архитектуры сетевого взаимодействия стандартизируются интерфейсы и функциональность отдельных модулей.

Такая общая модель была принята в 1983 году Международной организацией по стандартизации (International Organization for Standardization, ISO), и получила название модели взаимодействия открытых систем (Open Systems Interconnection, OSI). Эта модель является основой для объединения разнородных компьютеров в гетерогенную сетевую инфраструктуру. Данная архитектура определяет возможность установления соединения между любыми двумя системами, удовлетворяющими модели и поддерживающими соответствующие стандарты.

В модели OSI, как и в TCP/IP, общая функциональность системы разделена на несколько уровней, каждый из которых выполняет свою часть функций, необходимых для установления соединения с парным ему уровнем удаленной системы. В то же время каждый из уровней выполняет определенную обработку данных, реализуя набор услуг для уровня выше. Описание услуг и формат их предоставления определяются внутренним протоколом взаимодействия соседних уровней и определяют межуровневый интерфейс.

Модель OSI состоит из семи уровней, краткое описание которых приведено в табл. 6.1.

Таблица 6.1. Семь уровней модели OSI

Название уровня Описание
Уровень приложений (Application layer) Обеспечивает пользовательский интерфейс доступа к распределенным ресурсам
Уровень представления (Presentation layer) Обеспечивает независимость приложений от различий в способах представления данных
Уровень сеанса (Session layer) Обеспечивает взаимодействие прикладных программ в сети
Транспортный уровень (Transport layer) Обеспечивает прозрачную передачу данных между конечными точками сетевых коммуникаций. Отвечает за восстановление ошибок и контроль за потоком данных
Сетевой уровень (Network layer) Обеспечивает независимость верхних уровней от конкретной реализации способа передачи данных по физической среде. Отвечает за установление, поддержку и завершение сетевого соединения
Уровень канала данных (Data link layer) Обеспечивает надежную передачу данных по физической сети. Отвечает за передачу пакетов данных — кадров и обеспечивает необходимую синхронизацию, обработку ошибок и управление потоком данных
Физический уровень (Physical layer) Отвечает за передачу неструктурированного потока данных по физической среде. Определяет физические характеристики среды передачи данных

Рассмотрим процесс передачи данных между удаленными системами в рамках модели OSI. Пусть пользователю А системы C1 необходимо передать данные приложению В системы C2. Обработка прикладных данных начинается на уровне приложения. Уровень приложения передает обработанные данные и управляющую информацию на следующий уровень — уровень представления и т.д., пока данные наконец не достигнут физического уровня и не будут переданы по физической сети. Система C2 принимает эти данные и обрабатывает их в обратном порядке, начиная с физического уровня и заканчивая уровнем приложения, после чего исходные прикладные данные будут получены пользователем В.

Для того чтобы каждый уровень мог правильно обработать полученные данные, последние содержат также управляющую информацию. Эта управляющая информация интерпретируется только тем уровнем, для которого она предназначена, в соответствии с его протоколом, и невидима для других уровней: для верхних, потому что после обработки она удаляется, а для нижних — потому, что представляется им как обычные данные. Благодаря этому каждый уровень по существу общается с расположенным на удаленной системе равным (peer) ему уровнем. Таким образом, взаимодействие между удаленными системами можно представить состоящим из нескольких логических каналов, соответствующих уровням модели, передача данных в каждом из которых определяется протоколом своего уровня.

Так физический уровень и уровень канала данных обеспечивают коммуникационный канал сетевому уровню, который, в свою очередь, предоставляет связность объектам транспортного уровня и т.д.

Нетрудно заметить, что модель TCP/IP отличается от модели OSI. На рис. 6.4 показана схема отображения архитектуры TCP/IP на модель OSI. Видно, что соответствие существует для уровня Internet (сетевой уровень) и транспортного уровня. Уровни сеанса, представления и приложений OSI в TCP/IP представлены одним уровнем приложений. Обсуждение соответствия двух моделей носит весьма теоретический характер, поэтому мы перейдем к более ценному для практики обсуждению прекрасно зарекомендовавших себя протоколов Internet.

Рис. 6.4. Соответствие между моделями TCP/IF и OSI

 

Протокол IP

 

Межсетевой протокол (Internet Protocol, IP) обеспечивает доставку фрагмента данных (датаграммы) от источника к получателю через систему связанных между собой сетей. В протоколе IP отсутствуют функции подтверждения, контроля передачи, сохранения последовательности передаваемых датаграмм и т.д. В этом смысле протокол IP обеспечивает потенциально ненадежную передачу. Надежность и прочие функции, отсутствующие у IP, при необходимости реализуются протоколами верхнего уровня. Например, протокол TCP дополняет IP функциями подтверждения и управления передачей, позволяя приложениям (или протоколам более высокого уровня) рассчитывать на получение упорядоченного потока данных, свободных от ошибок. Эта функциональность может быть реализована и протоколами более высокого уровня, как например это сделано в реализации распределенной файловой системы NFS, традиционно работающей на базе "ненадежного" транспортного протокола UDP. При этом работа NFS в целом является надежной.

В рамках модели OSI протокол IP занимает 3-й уровень и, таким образом, взаимодействует с протоколами управления передачей снизу и транспортными протоколами сверху. В рамках этой модели IP выполняет три основные функции: адресацию, фрагментацию и маршрутизацию данных.

Данные, формат которых понятен протоколу IP, носят название датаграммы (datagram), вид которой приведен на рис. 6.5. Датаграмма состоит из заголовка, содержащего необходимую управляющую информацию для модуля IP, и данных, которые передаются от протоколов верхних уровней и формат которых неизвестен IP. Вообще говоря, термин "датаграмма" обычно используется для описания пакета данных, передаваемого по сети без установления предварительной связи (connectionless).

Рис. 6.5. IP-датаграмма

Протокол IP обрабатывает каждую датаграмму как самостоятельный объект, не зависящий от других передаваемых датаграмм. Для датаграмм неприменимы виртуальные каналы или другие логические тракты передачи.

Модули IP производят передачу датаграммы по направлению к получателю на основании адреса, расположенного в заголовке IP-датаграммы. Выбор пути передачи датаграммы называется маршрутизацией.

В процессе обработки датаграммы протокол IP иногда вынужден выполнять ее фрагментацию. Фрагментация бывает необходима, поскольку путь датаграммы от источника к получателю может пролегать через локальные и территориально-распределенные физические сети различной топологии и архитектуры, использующие различные размеры кадра. Например, кадр FDDI позволяет передавать датаграммы размером до 4470 октетов, в то время как сети Ethernet накладывают ограничение в 1500 октетов.

Заголовок IP-датаграммы, позволяющий модулю протокола выполнить необходимую обработку данных, приведен на рис. 6.6.

Рис. 6.6. Заголовок IP-датаграммы

Заголовок занимает как минимум 20 октетов управляющих данных. Поле Version определяет версию протокола и ее значение равно 4 (для IPv4). Поле IHL (Internet Header Length) указывает длину заголовка в 32-битных словах. При минимальной длине заголовка в 20 октетов значение IHL будет равно 5. Это поле также используется для определения смещения, начиная с которого размещаются управляющие данные протоколов верхнего уровня (например, заголовок TCP). Поле Type of Service определяет требуемые характеристики обработки датаграммы и может принимать следующие значения:

Биты 0–2 Precedence . Относительная значимость датаграммы. Это поле может использоваться рядом сетей, при этом большее значение поля Precedence соответствует более приоритетному трафику (например, при перегрузке сети модуль передает только трафик со значением Precedence выше определенного порогового значения).
Бит 3 Delay . Задержка. Значение 0 соответствует нормальной задержке при обработке, значение 1 — низкому значению задержки.
Бит 4 Throughput . Скорость передачи. Значение 0 соответствует нормальной скорости передачи, значение 1 — высокой скорости.
Бит 5 Reliability . Надежность. Значение 0 соответствует нормальной надежности, значение 1 — высокой надежности.
Биты 6–7 Зарезервированы для последующего использования.

Поле Type of Service определяет обработку датаграммы при передаче через различные сети от источника к получателю. В большинстве случаев может оказаться невозможным удовлетворение сразу всех требований по обработке, предусмотренных полем Type of Service. Например, удовлетворение требования низкого значения задержки, может сделать невозможным повышение надежности передачи. Фактическое отображение параметров Type of Service на процедуры обработки конкретной сети зависит от архитектуры этой сети. Примеры возможных отображений можно найти в RFC 795 "Service mappings".

Поле Total Length содержит общий размер датаграммы в октетах. Размер поля (16 бит) ограничивает максимальный размер IP-датаграммы 65535 октетами.

Следующее 32-битное слово используется при фрагментации и последующем реассемблировании датаграммы. Фрагментация необходима, например, когда датаграмма отправляется из сети, позволяющей передачу пакетов, размер которых превышает максимальный размер пакета какой-либо из сетей по пути следования датаграммы к получателю. В этом случае IP-модуль, вынужденный передать "большую" датаграмму в сеть с малым размером кадра, должен разбить ее на несколько датаграмм меньшего размера. Вообще говоря, модуль протокола должен обеспечивать возможность фрагментации исходной датаграммы на произвольное число частей (фрагментов), которые впоследствии могут быть реассемблированы получателем. Получатель фрагментов отличает фрагменты одной датаграммы от другой по полю Identification. Это поле устанавливается при формировании исходной датаграммы и должно быть уникальным для каждой пары источник-получатель на протяжении жизни датаграммы в сети. Поле Fragment Offset указывает получателю на положение данного фрагмента в исходной датаграмме.

Поле Flags содержит следующие флаги:

Бит 0 Зарезервирован
Бит 1 DF. Значение 0 позволяет фрагментировать датаграмму. Значение 1 запрещает фрагментацию. Если в последнем случае передача исходной датаграммы невозможна, модуль протокола просто уничтожает исходную датаграмму без уведомления
Бит 2 MF. Значение 0 указывает, что данный фрагмент является последним в исходной датаграмме (в исходной датаграмме значение равно 0). Значение 1 сообщает реассемблирующему модулю о том, что данный фрагмент исходной датаграммы не последний

Для фрагментации датаграммы большого размера модуль протокола формирует две или более новых датаграмм и копирует содержимое заголовка исходной датаграммы в заголовки вновь созданных. Флаг MF устанавливается равным 1 для всех датаграмм, кроме последней, для которой значение этого флага копируется из исходной датаграммы. Данные разбиваются на необходимое число частей с сохранением 64-битной границы. Соответствующим образом устанавливаются значения полей Total Length и Fragment Offset.

Получатель фрагментов, например хост, производит реассемблирование, объединяя датаграммы с равными значениями четырех полей: Identification, адрес источника (Source Address), адрес получателя (Destination Address) и Protocol. При этом положение фрагмента в объединенной датаграмме определяется полем Fragment Offset.

Следующее поле заголовка называется TTL (Time-to-Live) и определяет "время жизни" датаграммы в сети. Если значение этого поля становится равным 0, датаграмма уничтожается. Каждый модуль протокола, обрабатывающий датаграмму, уменьшает значение этого поля на число секунд, затраченных на обработку. Однако поскольку обработка датаграммы в большинстве случаев занимает гораздо меньшее время, a TTL все равно уменьшается на 1, то фактически это поле определяет максимальное количество хопов (число промежуточных передач через шлюзы), которое датаграмма может совершить. Смысл этой функции — исключить возможность засорения сети "заблудившимися"

Поле Protocol определяет номер протокола верхнего уровня, которому предназначена датаграмма. Значения этого поля для различных протоколов приведены в RFC 1700 "Assigned numbers", некоторые из них показаны в табл. 6.2.

Таблица 6.2. Некоторые номера протоколов

Номер Протокол
1 Internet Control Message Protocol, ICMP
2 Internet Group Management Protocol, IGMP
4 Инкапсуляция IP в IP
6 Transmission Control Protocol, TCP
17 User Datagram Protocol, UDP
46 Resource Reservation Protocol, RSVP
75 Packet Video Protocol, PVP

Завершает третье 32-битное слово заголовка его 16-битная контрольная сумма/поле Header Checksum.

Поля Source Address и Destination Address содержат соответственно адреса источника датаграммы и ее получателя. Это адреса сетевого уровня, или IP-адреса, размер которых составляет 32 бита каждый.

Поле Options содержит различные опции протокола, а поле Padding служит для выравнивания заголовка до границы 32-битного слова.

 

Адресация

Каждый IP-адрес можно представить состоящим из двух частей: адреса (или идентификатора) сети и адреса хоста в этой сети. Существует пять возможных форматов IP-адреса, отличающихся по числу бит, которые отводятся на адрес сети и адрес хоста. Эти форматы определяют классы адресов, получивших названия от А до D. Определить используемый формат адреса позволяют первые три бита, как это показано на рис. 6.7.

Рис. 6.7. Форматы IP-адресов

Взаимосвязанные сети (internet), должны обеспечивать общее адресное пространство. IP-адрес каждого хоста этих сетей должен быть уникальным. На практике это достигается с использованием иерархии, заложенной в базовый формат адреса. Некий центральный орган отвечает за назначение номеров сетей, следя за их уникальностью, в то время как администраторы отдельных сетей могут назначать номера хостов, также следя за уникальностью этих номеров в рамках собственной сети. В итоге — каждый хост получит уникальный адрес. В случае глобальной сети Internet уникальность адресов также должна выполняться глобально. За назначение адресов сетей отвечает центральная организация IANA, имеющая региональные и национальные представительства. При предоставлении зарегистрированного адреса сети вам гарантируется его уникальность.

Адреса класса А позволяют использовать 7 бит для адресации сети, ограничивая таким образом количество сетей этого класса числом 126. Этот формат адреса напоминает формат, используемый в предтече современной глобальной сети Internet — сети ARPANET. В те времена мало кто мог предвидеть столь бурное развитие этих технологий и число 126 не казалось малым.

Число уникальных сетей класса В значительно больше — 16 382, поскольку адрес сети состоит из 14 бит. Однако сегодня и этого недостаточно — поэтому адреса сетей этого класса больше не предоставляются.

В настоящее время выделяются сети класса С. Сетей такого класса в Internet может быть не более 2 097 150. Но и это число сегодня нельзя назвать большим. При этом в каждой сети класса С может находиться не более 254 хостов.

Популярность локальных сетей в середине 80-х годов и стремительный рост числа пользователей Internet в последнее десятилетие привели к значительному "истощению" адресного пространства. Дело в том, что если ваша организация использует только четыре адреса сети класса С, то остальные 250 адресов "потеряны" для сообщества Internet и использоваться не могут. Для более эффективного распределения адресного пространства была предложена дополнительная иерархия IP-адреса. Теперь адрес хоста может в свою очередь быть разделен на две части — адрес подсети (subnetwork) и адрес хоста в подсети.

Заметим, что подсети по-прежнему являются отдельными сетями для протокола IP, требующими наличия маршрутизатора для передачи датаграмм из одной подсети в другую.

Для определения фактической границы между адресом подсети и хоста используется маска сети, представляющая собой 32-битное число, маскирующее единицами (в двоичном виде) номера сети и подсети и содержащее нули в позициях номера хоста. Модуль протокола IP производит логическую операцию "И" между маской и конкретным адресом, и таким образом определяет, предназначена ли эта датаграмма данному хосту (для модуля протокола хоста), или датаграмма адресована непосредственно подключенной подсети, или ее необходимо передать другому шлюзу для последующей доставки. Использование маски сети показано на рис. 6.8.

Рис. 6.8. Подсети

Если хост или шлюз "не знает", какую маску использовать, он формирует сообщение ADDRESS MASK REQUEST (запрос маски адреса) протокола ICMP и направляет его в сеть, ожидая сообщения ICMP ADDRESS MASK REPLY от соседнего шлюза.

Ряд IP-адресов имеют специальное значение и не могут присваиваться сетевым элементам (хостам, шлюзам и т.д.). Эти значения приведены в табл. 6.3.

Таблица 6.3. Специальные IP-адреса

Адрес Пример Интерпретация
Адрес: 192.85.160.46 Маска: 255.255.255.240 Адрес сети: 192.85.160.0 Адрес подсети: 2 Адрес хоста: 14
Сеть:0, Хост:0 0.0.0.0 Данный хост в данной сети
Сеть:0, Хост:H 0.0.0.5 Определенный хост в данной сети (только для адреса источника)
Сеть:1111...1 Подсеть:1111...1 Хост:1111...1 255.255.255.255 Групповой адрес всех хостов данной подсети
Сеть:N Подсеть:1111...1 Хост:1111...1 192.85.160.255 Групповой адрес всех хостов всех подсетей сети N
Сеть:N Подсеть:S Хост:1111...1 192.85.160.47 Групповой адрес всех хостов подсети S сети N
Сеть: 127 Хост: 1 127.0.0.1 Адрес внутреннего логического хоста

 

Протоколы транспортного уровня

 

В соответствии с моделью DARPA, рассмотренной нами ранее, протоколы транспортного уровня работают исключительно на хостах, являющихся точками обмена информацией — источниках или получателях датаграмм. Поскольку основная функция шлюзов заключается в выборе пути и последующей передаче датаграммы, которые непосредственно шлюзу не адресованы, протоколы этого уровня обычно не задействованы в шлюзах.

Два протокола этого уровня — TCP и UDP обеспечивают транспорт данных с заданными характеристиками между источником и получателем. Поскольку на каждом хосте как правило существует несколько процессов- получателей данных, протоколы этого уровня должны располагать необходимой информацией для доставки данных требуемому протоколу уровня приложений.

Как было показано, каждый уровень протоколов DARPA имеет собственную систему адресации. Например, для уровня сетевого интерфейса (соответствующего физическому уровню и уровню канала данных модели OSI) в локальных сетях используется физический адрес интерфейса. Он представляет собой 48-битный адрес, как правило, записанный в память платы. Для отображения физического адреса в адрес протокола верхнего уровня (Internet) используется специальный протокол трансляции адреса Address Resolution Protocol (ARP).

Уровень Internet (или сетевой уровень модели OSI) в качестве адресов использует уже рассмотренные нами IP-адреса. Для адресации протокола верхнего уровня используется поле Protocol заголовка IP-датаграммы.

Протоколы транспортного уровня замыкают систему адресации DARPA. Адреса, которые используются протоколами этого уровня и называются номерами портов (port number), служат для определения процесса (приложения), выполняющегося на данном хосте, которому адресованы данные. Другими словами, для передачи сообщения от источника к получателю требуется шесть адресов — по три с каждой стороны (физический адрес адаптера, IP-адрес и номер порта) — для однозначного определения пути. Номер порта адресует конкретный процесс (приложение) и содержится в заголовке TCP- или UDP-пакета. IP-адрес определяет сеть и хост, на котором выполняется процесс, и содержится в заголовке IP-датаграммы. Адрес сетевого адаптера определяет расположение хоста в физической сети.

Номера портов занимают 16 бит и стандартизированы в соответствии с их назначением. Полный список стандартных номеров портов приведен в RFC 1700 "Assigned Numbers". Часть из них в качестве примера приведена в табл. 6.4.

Таблица 6.4. Некоторые стандартные номера портов

Номер порта Название Назначение (протокол уровня приложений)
7 echo Echo
20 ftp-data Передача данных по протоколу FTP
21 ftp Управляющие команды протокола FTP
23 telnet Удаленный доступ (Telnet)
25 smtp Электронная почта (Simple Mail Transfer Protocol)
53 domain Сервер доменных имен (Domain Name Server)
67 bootps Сервер загрузки Bootstrap Protocol
68 bootpc Клиент загрузки Bootstrap Protocol
69 tftp Передача файлов (Trivial File Transfer Protocol)
70 gopher Информационная система Gopher
80 www-http World Wide Web (HyperText Transfer Protocol)
110 pop3 Электронная почта (POP версии 3)
119 nntp Телеконференции (Network News Transfer Protocol)
123 ntp Синхронизация системных часов (Network Time Protocol)
161 snmp Менеджмент/статистика (Simple Network Management Protocol)
179 bgp Маршрутизационная информация (Border Gateway Protocol)

 

User Datagram Protocol (UDP)

UDP является протоколом транспортного уровня и, как следует из названия, обеспечивает логический коммуникационный канал между источником и получателем данных без предварительного установления связи. Другими словами, сообщения, обрабатываемые протоколом не имеют друг к другу никакого отношения с точки зрения UDP. Для передачи датаграмм использует протокол IP и так же, как и последний, не обеспечивает надежности передачи. Поэтому приложения, использующие этот транспортный протокол, должны при необходимости самостоятельно обеспечить надежность доставки, например, путем обмена подтверждениями и повторной передачей недоставленных сообщений.

Однако благодаря минимальной функциональности протокола UDP, передача данных с его использованием вносит гораздо меньшие накладные расходы по сравнению, скажем, с парным ему транспортным протоколом TCP. Размер заголовка UDP, показанного на рис. 6.9, составляет всего 8 октетов.

Рис. 6.9. Заголовок UDP

Первые два поля, каждое из которых занимает по 2 октета, адресуют соответственно порты источника и получателя. Указание порта источника является необязательным и это поле может быть заполнено нулями. Поле Length содержит длину датаграммы, которая не может быть меньше 8 октетов. Поле Checksum используется для хранения контрольной суммы и используется только если протокол верхнего уровня требует этого. Если контрольная сумма не используется, это поле заполняется нулями. В противном случае она вычисляется по псевдозаголовку, содержащему IP-адреса источника и получателя датаграммы и поле Protocol из IP-заголовка. Вид псевдозаголовка представлен на рис. 6.10. То, что вычисление контрольной суммы включает IP-адреса, гарантирует, что полученная датаграмма доставлена требуемому адресату. Заметим, что для протокола UDP значение поля Protocol равно 17.

Рис. 6.10. Псевдозаголовок UDP

В качестве примеров протоколов уровня приложений, которые используют в качестве транспортного протокол UDP, можно привести:

□ Протокол взаимодействия с сервером доменных имен DNS, порт 53.

□ Протокол синхронизации времени Network Time Protocol, порт 123.

□ Протокол удаленной загрузки BOOTP, порты 67 и 68 для клиента и сервера соответственно.

□ Протокол удаленного копирования Trivial FTP (TFTP), порт 69.

□ Удаленный вызов процедур RPC, порт 111.

Для всех перечисленных протоколов и соответствующих им приложений предполагается, что в случае недоставки сообщения необходимые действия предпримет протокол верхнего уровня (приложение). Как правило, приложения, использующие протокол UDP в качестве транспорта, обмениваются данными, имеющими статистический повторяющийся характер, когда потеря одного сообщения не влияет на работу приложения в целом. Приложения, требующие гарантированной надежной доставки данных, используют более сложный протокол транспортного уровня, в значительной степени дополняющего функциональность протокола IP, — протокол TCP.

 

Transmission Control Protocol (TCP)

 

TCP является протоколом транспортного уровня, поддерживающим надежную передачу потока данных с предварительным установлением связи между источником информации и ее получателем. На базе протокола TCP реализованы такие протоколы уровня приложений, как Telnet, FTP или HTTP.

Протокол TCP характеризуется следующими возможностями, делающими его привлекательным для приложений:

□ Перед фактической передачей данных необходимо установление связи, т.е. запрос на начало сеанса передачи данных источником и подтверждение получателем. После обмена данными сеанс передачи должен быть явно завершен.

□ Доставка информации является надежной, не допускающей дублирования или нарушения очередности получения данных.

□ Возможность управления потоком данных для избежания переполнения и затора.

□ Доставка экстренных данных.

Эти возможности протокола позволяют протоколам верхнего уровня и, соответственно, приложениям, их реализующим, не заботиться о надежности, последовательности доставки и т.д. Таким образом, протоколы приложений, использующие TCP, могут быть значительно упрощены. С другой стороны, это ведет к сложности самого транспортного протокола и, как следствие, к значительным накладным расходам при передаче данных.

TCP-канал представляет собой двунаправленный поток данных между соответствующими объектами обмена — источником и получателем. Данные могут передаваться в виде пакетов различной длины, называемых сегментами. Каждый TCP-сегмент предваряется заголовком, за которым следуют данные, инкапсулирующие протоколы уровня приложения. Вид заголовка TCP-сегмента представлен на рис. 6.11.

Рис. 6.11. Формат TCP-сегмента

Положение каждого сегмента в потоке фиксируется порядковым номером (Sequence Number), представленным соответствующим полем заголовка и обозначающим номер первого октета сегмента в потоке TCP. Порядковые номера также используются для подтверждения получения: каждый TCP-сегмент содержит номер подтверждения (Acknowledgement Number), сообщающий отправителю количество полученных от него последовательных данных. Номер подтверждения определяется как номер первого неподтвержденного октета в потоке.

И порядковый номер, и номер подтверждения занимают по 32 бита в заголовке TCP-сегмента, таким образом, их максимальное значение составляет (2³² - 1), за которым следует 0. При установлении связи стороны договариваются о начальных значениях порядковых номеров (Initial Sequence Number, ISN) в каждом из направлений. Впоследствии первый октет переданных данных будет иметь номер (ISN+1).

Управление потоком данных осуществляется с помощью метода скользящего окна (sliding window). Каждый TCP-заголовок содержит также поле Window, которое указывает на количество данных, которое адресат готов принять, начиная с октета, указанного в поле Acknowledgement Number.

Заголовок TCP-сегмента занимает как минимум 20 октетов. Помимо рассмотренных нами порядковых номеров и анонсируемого окна, он содержит ряд других важных полей. Заголовок начинается с двух номеров портов, адресующих логические процессы на обоих концах виртуального канала. Далее следуют порядковый номер и номер подтверждения.

Поле смещения (Offset) указывает начало данных сегмента. Это поле необходимо, поскольку размер TCP-заголовка имеет переменную величину.

Значение этого поля измеряется в 32-битных словах. Таким образом, при минимальном размере заголовка поле Offset будет равно 5.

Далее заголовок содержит шесть управляющих флагов Flags, каждый из которых занимает отведенный ему бит:

URG Указывает, что сегмент содержит экстренные данные, и поле Urgent pointer заголовка определяет их положение в сегменте.
ACK Указывает, что заголовок содержит подтверждение полученных данных В поле Acknowledgement Number.
PSH Указывает, что данные должны быть переданы немедленно, не ожидая заполнения сегмента максимального размера.
RST Указывает на необходимость уничтожения канала.
SYN Указывает, что сегмент представляет собой управляющее сообщение, являющееся частью "тройного рукопожатия" для синхронизации порядковых номеров при создании канала.
FIN Указывает, что сторона прекращает передачу данных и желает закрыть виртуальный канал.

Поле контрольной суммы Checksum используется для защиты от ошибок. Контрольная сумма вычисляется на основании 12-октетного псевдозаголовка, содержащего, в частности IP-адреса источника и получателя, а также номер протокола. Цель включения в контрольную сумму части заголовка IP та же, что и для протокола UDP — дополнительно защитить данные от получения не тем адресатом.

Поле Urgent Pointer позволяет указать расположение экстренных данных внутри сегмента. Это поле используется при установленном флаге URG и содержит порядковый номер октета, следующего за экстренными данными.

В конце заголовка располагается поле Options переменной длины, которое может содержать различные опции, например, максимальный размер сегмента (MSS). Это поле дополняется нулями (Padding) для того, чтобы заголовок всегда заканчивался на границе 32 бит.

 

Состояния TCP-сеанса

Как уже говорилось, передача данных с использованием протокола TCP предусматривает предварительное установление связи, или создание логического TCP-канала. Эта предварительная фаза призвана усилить надежность протокола. В процессе этой фазы определяется начало TCP-потоков в обоих направлениях, их характеристики (например, максимальный размер окна), в это же время могут быть обнаружены "полуразрушенные" TCP-каналы прошлых сеансов передачи, некорректно закрытые, например, ввиду аварийного останова одной из сторон. Стороны выбирают произвольные начальные порядковые номера потоков, чтобы уменьшить вероятность обработки сегментов, принадлежащих "старым" сеансам.

Начальная фаза сеанса передачи получила название "тройное рукопожатие" (three-way handshake), которое достаточно точно отражает процесс обмена служебными сегментами между сторонами. Этот процесс является ассиметричным — одна из сторон, называемая клиентом, инициирует начало сеанса, посылая другой стороне — серверу сегмент SYN. Как правило этот сегмент является числом служебным, т.е. не содержит полезных данных, его заголовок определяет номер порта и начальный порядковый номер потока клиент-сервер. Если сервер готов принять данные от клиента, он создает логический канал (размещая соответствующие структуры данных) и отправляет клиенту сегмент с установленным начальным порядковым номером потока сервер-клиент и флагами SYN и ACK, подтверждающий получение сегмента SYN и выражающего готовность сервера к получению данных. Наконец, и это третье рукопожатие, клиент отвечает сегментом с установленным флагом ACK, подтверждающим получение ответа от сервера и тем самым завершающим фазу создания TCP-канала. Процесс установления связи в TCP-сеансе представлен на рис. 6.12.

Рис. 6.12. Установление связи, передача данных и завершение TCP-сеанса

После этого обе стороны начинают передачу TCP-сегментов, каждый из которых содержит подтверждение полученных данных и новое значение окна. Начиная с подтвержденного октета, источник может передать, не дожидаясь подтверждения, количество данных, определенных значением окна. Если отправитель не получает подтверждения на посланные данные в течение определенного промежутка времени, он полагает, что данные утеряны, и их передача повторяется, начиная с последнего подтвержденного октета. Поскольку надежность передачи гарантируется протоколом, для данных приложения, переданных, но не подтвержденных, протокол хранит копию, которая уничтожается после получения подтверждения или вновь передается при отсутствии такового. Получение дублированных данных также подтверждается, хотя сами данные уничтожаются, поскольку дублирование могло быть вызвано неполучением подтверждения. Если одна из сторон получает неупорядоченные данные, они, как правило, сохраняются до получения недостающих последовательных сегментов. Разумеется, получение таких неупорядоченных данных не подтверждается, поскольку подтверждение отправляется только на полученный непрерывный последовательный поток октетов.

Завершение сеанса в TCP происходит в несколько этапов. Любая из сторон может завершить передачу данных, отправив сегмент с установленным флагом FIN (рис. 6.12). Получение такого сегмента подтверждается другой стороной и эквивалентно достижению конца файла при его чтении. Однако другая сторона может продолжать передавать данные, также впоследствии завершив передачу сегментом FIN. Подтверждение этого сегмента полностью разрушает канал и завершает сеанс. Для того чтобы гарантировать синхронизацию завершения сеанса, сторона, отправившая подтверждение на последний сегмент FIN, должна поддерживать сеанс достаточно долго, чтобы иметь возможность вновь подтвердить повторные сегменты FIN данного сеанса в случае, когда подтверждение не было получено другой стороной.

На рис. 6.12 также проиллюстрированы состояния коммуникационных узлов TCP-канала.

Как видно из рисунка, начальное состояние узла (сервера или клиента) — состояние CLOSED. Готовность сервера к обработке инициирующих запросов от клиента определяется переходом его в состояние LISTEN. С этого момента сервер может принимать и обрабатывать инициирующие сеанс сегменты SYN. При отправлении такого сегмента клиент переходит в состояние SYN-SENT и ожидает ответного запроса от сервера. Сервер при получении сегмента также отправляет сегмент SYN с подтверждением ACK и переходит в состояние SYN-RECEIVED. Подтверждение от клиента завершает "рукопожатие" и сеанс переходит в состояние ESTABLISHED. После завершения обмена данными одна из сторон (например, клиент) отправляет сегмент FIN, переходя при этом в состояние FIN-WAIT-1. Приняв этот сегмент другая сторона (например, сервер) отправляет подтверждение ACK и переходит в состояние CLOSE-WAIT, при этом канал становится симплексным — передача данных возможна только в направлении от сервера к клиенту. Когда клиент получает подтверждение он переходит в состояние FIN-WAIT-2, в котором находится до получения сегмента FIN. После подтверждения получения этого сегмента канал окончательно разрушается.

Расшифровка состояний приведена в табл. 6.5.

Таблица 6.5. Состояния TCP-сеанса

Состояние Описание
LISTEN Готовность узла к получению запроса на соединение от любого удаленного узла.
SYN-SENT Ожидание ответного запроса на соединение.
SYN-RECEIVED Ожидание подтверждения получения ответного запроса на соединение.
ESTABLISHED Состояние канала, при котором возможен дуплексный обмен данными между клиентом и сервером.
CLOSE-WAIT Ожидание запроса на окончание связи от локального процесса, использующего данный коммуникационный узел.
LAST-ACK Ожидание подтверждения запроса на окончание связи, отправленного удаленному узлу. Предварительно от удаленного узла уже был получен запрос на окончание связи и канал стал симплексным.
FIN-WAIT-1 Ожидание подтверждения запроса на окончание связи, отправленного удаленному узлу (инициирующий запрос, канал переходит в симплексный режим).
FIN-WAIT-2 Ожидание запроса на окончание связи от удаленного узла
CLOSING Ожидание подтверждения от удаленного узла на запрос окончания связи.
TIME-WAIT Таймаут перед окончательным разрушением канала, достаточный для того, чтобы удаленный узел получил подтверждение своего запроса окончания связи. Величина тайм-аута составляет 2 MSL (Maximum Segment Lifetime). [73]
CLOSED Фиктивное состояние, при котором коммуникационный узел и канал фактически не существуют.

Для обеспечения правильной обработки данных для каждого логического TCP-канала хранится полная информация о его состоянии, различных таймерах и о текущих порядковых номерах переданных и принятых октетов. Это необходимо, например, для корректной обработки служебных сегментов SYN и FIN.

 

Передача данных

После создания виртуального канала взаимодействующие процессы получают возможность обмениваться данными в дуплексном режиме.

Хотя фактически передача данных осуществляется в виде сегментов, ее логический вид представляет собой последовательный поток октетов, каждый из которых адресуется порядковым номером. Каждый сегмент хранит в заголовке порядковый номер первого октета данных. Данные буферизуются обоими коммуникационными узлами TCP-канала. Как правило, модуль TCP самостоятельно принимает решение, когда именно сформировать сегмент для отправки и когда передать полученные данные процессу- адресату.

В случае, когда требуется немедленная передача данных, без ожидания заполнения сегмента определенного размера, протокол верхнего уровня (приложение) устанавливает флаг PSH, который указывает модулю TCP на необходимость немедленной доставки данных, находящихся в очереди на отправление. Это может потребоваться, например, при передаче пользовательского ввода при удаленном доступе (протокол Telnet).

Как уже говорилось, протокол TCP обеспечивает надежный последовательный виртуальный канал передачи данных между приложениями. Поскольку нижележащий сетевой протокол IP является по определению ненадежным, а среда передачи вносит дополнительные ошибки, переданные данные могут быть утеряны, продублированы или испорчены, при этом порядок их доставки может быть нарушен. В случае ошибочности полученного сегмента модуль TCP узнает об этом, проверив контрольную сумму. Другие ошибки являются более сложными, и TCP должен обеспечить их определение и исправление.

Рассмотренные выше порядковый номер и номер подтверждения играют ключевую роль в обеспечении надежности доставки. По существу порядковый номер адресует каждый октет логического потока данных между источником и получателем, позволяя последнему определить правильность доставки (порядок доставки и потерю отдельных октетов). TCP является протоколом с позитивным подтверждением и повторной передачей (Positive Acknowledgement and Retransmission, PAR). Это означает, что если данные доставлены без ошибок, получатель подтверждает это сегментом ACK. Если отправитель не получает подтверждения в течение некоторого времени, он повторно посылает данные. В любом случае отсутствует негативное подтверждение (NAK).

В качестве примера рассмотрим передачу данных между двумя хостами сети А и В, проиллюстрированную на рис. 6.13. Для простоты предположим симплексную передачу большого количества данных от хоста А к B. Начиная с SEQ=100 хост А посылает хосту В 200 октетов. Первый посланный сегмент (SEQ=300) доставлен без ошибок и подтвержден хостом В (ACK=301). Следующий сегмент передан с ошибкой и не доставлен получателю. Таким образом, хост А не получает подтверждения на второй сегмент и повторно посылает его после определенного тайм-аута. В конечном итоге все данные, переданные хостом А будут получены и подтверждены хостом В.

Рис. 6.13. Повторная передача

Говоря об управлении потоком данных, следует отметить, что TCP представляет собой протокол со скользящим окном. Окно определяет объем данных, который может быть послан (send window — окно передачи) или получен (receive window — окно приема) TCP-модулем. Размеры окон фактически отражают состояние буферов приема коммуникационных узлов. Так окно приема свидетельствует о количестве данных, которое принимающая сторона готова получить, а окно передачи определяет количество данных, которое отправителю позволяется послать, не ожидая подтверждения о получении. Несомненно, между этими двумя параметрами существует связь — окно передачи одного узла отражает состояние буферов другого (его окно приема) и наоборот. Принимающая сторона имеет возможность изменять окно передачи отправителя (с помощью подтверждения или явного обновления значения окна в поле Window заголовка передаваемого сегмента), и, таким образом, регулировать трафик.

Интерпретация отправителем окна передачи показана на рис. 6.14. Размер окна передачи отправителя в данном случае покрывает с 4 по 8 байт. Это означает, что отправитель получил подтверждения на все байты, включая 3, а получатель анонсировал размер окна равным 5 байтам. Это также означает, что отправитель может еще передать 2 байта (7 и 8). По мере подтверждения получения данных окно будет смещаться вправо, открывая новые "горизонты" для передачи. Однако окно может изменять свои размеры, при этом имеет значение, смещение какого края окна (правого или левого) приводит к изменению размера.

□ Окно закрывается по мере смещения левого края вправо. Это происходит при отправлении данных.

□ Окно открывается по мере смещения правого края вправо. Это происходит в соответствии с освобождением буфера приема получателя данных.

□ Окно сжимается, когда правый край смещается влево. Хотя такое поведение не рекомендуется, модуль TCP должен быть готов к обработке этой ситуации.

Рис. 6.14. Окно передачи TCP

Если левый край окна достигает правого, размер окна становится равным нулю, что запрещает дальнейшую передачу данных.

Суммируя вышесказанное, можно отметить, что размер окна, сообщаемый получателем данных отправителю, является предлагаемым окном (offered window), которое в простейшем случае равно размеру свободного места в буфере приема. При получении этого значения отправитель данных вычисляет фактическое, доступное для использования окно (usable window), которое равно предлагаемому за вычетом объема отправленных, но не подтвержденных данных. Таким образом, доступное для использования, или просто доступное, окно меньше или равно предлагаемому. Неэффективная стратегия подтверждений может привести к чрезвычайно малым значениям доступного окна и, как следствие, к низкой производительности передачи данных. Это явление, известное под названием синдром "глупого окна" (Silly Window Syndrome, SWS), будет рассмотрено ниже.

 

Стратегии реализации TCP

Рассмотренный стандарт протокола TCP определяет взаимодействие между удаленными объектами, достаточное для обеспечения совместимых реализаций. Другими словами, модуль протокола, в точности следующий спецификации стандарта, является гарантированно совместимым с модулями TCP, разработанными другими производителями. Тем не менее ряд вопросов функционирования протокола остается за рамками стандарта и допускает различные реализации, в конечном итоге влияющие не на совместимость, а на производительность приложений, использующих этот протокол. В данном разделе мы рассмотрим различные подходы к реализации TCP, направленные на повышение его производительности.

 

Синдром "глупого окна"

Механизм подтверждения получения данных является ключевым в протоколе TCP. Стандарт указывает, что подтверждение должно быть передано без задержки, но не определяет конкретно, насколько быстро данные должны быть подтверждены, и объем подтверждаемых данных. К сожалению, корректная с точки зрения спецификации протокола, но неоптимальная реализация стратегии подтверждения приводит к неудовлетворительной работе механизма управления потоком данных (оконного механизма), что приводит к синдрому "глупого окна" (SWS).

Для иллюстрации этого явления рассмотрим передачу файла большого размера между двумя приложениями, использующими протокол TCP. Допустим, что модуль протокола осуществляет передачу сегментами, размер которых составляет 200 октетов. В начале передачи предлагаемое окно отправителя — 1000 октетов. Он полностью использует этот кредит, послав пять сегментов по 200 октетов каждый. После обработки первого полученного сегмента адресат отправляет подтверждение (сегмент ACK), которое также содержит обновленное значение предлагаемого окна. Предположим, что адресат передал полученные данные приложению, и таким образом его буфер приема вновь содержит 1000 байтов свободного места. Поэтому обновленное значение окна будет также равным 1000 октетов. Эта ситуация показана на рис. 6.15.

Рис. 6.15. Возникновение SWS

При получении подтверждения отправитель вычисляет доступное окно. Поскольку получение 800 октетов данных еще не подтверждено, значение доступного окна получается равным 200.

Рассмотрим теперь процесс возникновения SWS. Предположим, что отправитель вынужден передать сегмент размером 50 октетов (например, если приложение указало флаг PSH). Таким образом, он отправляет 50 байтов, и вслед за этим следующий сегмент, размером 150 октетов (поскольку размер доступного окна равен 200). Через некоторое время адресат получит 50 байтов, обработает их и подтвердит получение, не изменяя значения предлагаемого окна (1000 октетов). Однако теперь при вычислении доступного окна, отправитель обнаружит, что не подтверждены 950 байтов, и, таким образом, его окно равняется всего 50 октетам. В результате отправитель вновь вынужден будет передать всего 50 байтов, хотя приложение этого уже не требует.

Если мы продолжим анализировать передачу данных, то заметим, что рисунок транзакций будет периодически повторяться, т.е. отправитель будет вынужден периодически передавать сегмент необоснованно малого размера. Этот порочный круг не может быть разорван естественным образом. Происхождение сегментов малого размера очевидно: периодически у отправителя возникает необходимость разделить доступное окно на несколько мелких сегментов. При непрерывной передаче больших объемов данных такие ситуации будут время от времени возникать, оставляя неизгладимый след на характере транзакций. В результате это может привести к "засорению" сети множеством мелких пакетов в одну сторону и множеством подтверждений в другую.

Описанный синдром может также порождаться и принимающей стороной, которая анонсирует чересчур маленькие окна. Таким образом, для преодоления этих ситуаций, необходима модификация алгоритмов TCP как для отправления, так и для приема данных. К счастью, SWS легко избежать, обязав модули выполнять следующие правила:

1. Принимающая сторона не должна анонсировать маленькие окна. Говоря более конкретно, адресат не должен анонсировать размер окна, больший текущего (который скорее всего равен 0), пока последний не может быть увеличен либо на размер максимального сегмента (Maximum Segment Size, MSS), либо на ½ размера буфера приема, в зависимости от того, какое значение окажется меньшим.

2. Отправитель должен воздержаться от передачи, пока он не сможет передать сегмент максимального размера или сегмент, размер которого больше половины максимального размера окна, который когда-либо анонсировался принимающей стороной.

Однако как мы уже заметили, анализируя причины возникновения SWS, поспешные подтверждения полученных данных сыграли не последнюю роль в этом процессе. С одной стороны, немедленное подтверждение позволяет постоянно держать отправителя "в курсе дела", тем самым избегая ненужных повторных передач. Подтверждение также приводит к смещению окна, и таким образом, позволяет отправителю продолжить передачу данных. С другой стороны, немедленное подтверждение может привести к возникновению SWS и дополнительным накладным расходам.

Хорошим компромиссом между немедленным и отложенным подтверждением можно считать следующую схему. При получении сегмента адресат не отправляет подтверждение, если, во-первых, сегмент не содержит флага PSH (дающего основание полагать, что вслед за полученным сегментом вскоре последуют дополнительные данные), и, во-вторых, отсутствует необходимость отправки обновленного значения окна.

Тем не менее получатель должен установить таймер, который позволит послать подтверждение, если в передаче данных произошел определенный перерыв, что может быть вызвано, например, потерей сегментов.

 

Медленный старт

Старые реализации TCP начинали передачу, отправляя сегменты в пределах предлагаемого окна, не дожидаясь подтверждения. Это вызывало взрывообразный рост трафика в сети и могло привести к переполнению, в результате которого часть сегментов отбрасывалась и требовалась повторная передача.

Алгоритм, направленный на избежание подобной ситуации, получил название медленного старта (slow start). Основная идея, лежащая в основе этого алгоритма, заключается в том, что на начальном этапе передачи сегменты должны отправляться со скоростью, пропорциональной скорости получения подтверждений.

Реализация этого алгоритма предусматривает использование дополнительного к рассмотренным ранее окна отправителя — окна переполнения (congestion window). При установлении связи с адресатом значение этого окна cwnd устанавливается равным одному сегменту (значению MSS, анонсированному адресатом, или некоторому значению по умолчанию, обычно 536 или 512 байтов). При вычислении доступного окна отправитель использует меньшее из предлагаемого окна и окна переполнения. Каждый раз, когда отправитель получает подтверждение полученного сегмента, его окно переполнения увеличивается на величину этого сегмента.

Легко заметить, что предлагаемое окно служит для управления потоком со стороны получателя, в то время как окно переполнения служит для управления со стороны отправителя. Если первое из них связано с наличием свободного места в буфере приема адресата, то второе — с представлением о загрузке сети у отправителя данных.

Обычно предлагаемое окно больше одного сегмента, поэтому отправитель передает один сегмент и ожидает подтверждения. Когда подтверждение приходит, он увеличивает значение окна переполнения до двух сегментов, таким образом, два сегмента разрешены к передаче. После того как получение каждого из этих сегментов подтверждено, размер окна переполнения становится равным четырем сегментам. Можно показать, что по мере отправления сегментов и получения подтверждений размер окна переполнения растет экспоненциально, соответственно растет и эффективная скорость передачи.

Начиная с некоторого значения скорость передачи достигнет эффективной пропускной способности виртуального канала между источником и получателем, и ее дальнейший рост приведет к потере данных. Начиная с этого момента, включается механизм устранения заторов, который будет обсужден ниже.

 

Устранение затора

Переполнение, или затор, может возникнуть в сети по многим причинам. Например, если данные поступают к шлюзу по высокоскоростному каналу и должны быть переданы в низкоскоростной канал. Или данные нескольких каналов мультиплексируются в один канал, пропускная способность которого меньше суммы входящих. Во всех этих случаях неизбежна потеря пакетов.

Алгоритмы, позволяющие избежать заторов, основываются на предположении, что потеря данных, вызванная ошибками передачи по физической среде, пренебрежимо мала (гораздо меньше 1%). Следовательно, потеря данных свидетельствует о заторе, произошедшем где-то на пути следования пакета. В свою очередь, о потере данных отправитель может судить по двум событиям: значительной паузе в получении подтверждения или получении дубликата(ов) подтверждения.

Хотя устранение затора и медленный старт являются независимыми механизмами, каждый из которых имеет свою цель, обычно они реализуются совместно. Для их работы необходимо два дополнительных параметра виртуального канала; окно переполнения cwnd и порог медленного старта ssthresh. Работа комбинированного алгоритма определяется следующим правилам:

1. Начальные значения cwnd и ssthresh инициализируются равными размеру одного сегмента и 65535 байтов соответственно.

2. Максимальное количество данных, которое может передать отправитель, не превышает меньшего из значений окна переполнения и предлагаемого окна.

3. При возникновении затора (что определяется по тайм-ауту или получению дубликатов подтверждений) параметр ssthresh устанавливается равным половине текущего окна, но не меньше размера двух сегментов. Если же свидетельством затора является тайм-аут, то дополнительно размер cwnd устанавливается равным одному сегменту, или, другими словами, включается медленный старт.

4. Когда отправитель получает подтверждение, он увеличивает размер cwnd, однако новый размер зависит от того, выполняет ли модуль медленный старт или устранение затора.

Если значение cwnd меньше или равно ssthresh, то TCP находится в фазе медленного старта, в противном случае производится устранение затора. Таким образом, режим медленного старта продолжается до тех пор, пока эффективная скорость передачи не достигнет половины скорости, при которой был обнаружен затор. После этого включается процедура устранения затора.

Как мы только что видели, медленный старт начинается с отправления одного сегмента, затем двух, затем четырех и т.д., что порождает экспоненциальный рост размера окна. В фазе устранения затора вычисление нового значения cwnd производится по следующей формуле при каждом подтверждении сегмента:

cwnd n+1 = cwnd n + 1/cwnd n

Таким образом, формула дает зависимость роста размера окна, при которой максимальная скорость приращения составит не более одного сегмента за время передачи данных туда и обратно (Round Trip Time, RTT), независимо от того, сколько подтверждений было получено. Это утверждение легко доказать. Допустим, в какой-то момент времени размер окна составлял cwnd n . Тогда отправитель может передать максимум cwnd n /sz сегментов размером sz, на которые он получит такое же число подтверждений. Можно показать, что

cwnd n+1 ≤ cwnd n + (cwnd n /sz)×(1/cwnd n ) = cwnd n + sz

На рис. 6.16 показан рост окна переполнения при медленном старте и последующем устранении затора. Заметим, что переход в фазу устранения затора происходит при превышении размером окна порогового значения ssthresh.

Рис. 6.16. Рост окна переполнения при медленном старте и устранении затора

 

Повторная передача

До сих пор рассматривалось получение дублированных подтверждений как свидетельство потери сегментов и затора в сети. Однако согласно RFC 1122 "Requirements for Internet Hosts — Communication Layers", модуль TCP может отправить немедленное подтверждение при получении неупорядоченных сегментов. Цель такого подтверждения — уведомить отправителя, что был получен неупорядоченный сегмент, и указать порядковый номер ожидаемых данных. Поскольку ожидаемый порядковый номер остался прежним (получение неупорядоченного сегмента не изменит его значение), данное подтверждение может явиться дубликатом уже отправленного ранее.

Таким образом, получение дублированных подтверждений может быть вызвано двумя причинами: потерей сегмента, как следствием затора в сети, и получением неупорядоченного сегмента. Чтобы установить истинную причину, модуль TCP ждет получения еще нескольких дублированных подтверждений. Если причина в получении неупорядоченного сегмента, вызванном буферизацией на промежуточных шлюзах или различными путями передачи датаграмм, то, вероятнее всего, вскоре ожидаемый сегмент будет получен и порядок будет восстановлен, что выразится в получении нового (уже не дубликата) подтверждения. Если получено три или более дубликатов, следует полагать, что произошла потеря данных. В этом случае отправитель совершает повторную передачу утраченного сегмента. Эта процедура получила название быстрой повторной передачи (fast retransmit). При этом, включается механизм устранения затора, но не медленный старт. Причиной такого поведения является то, что получение сегмента, хотя и не упорядоченного, свидетельствует об относительно невысоком уровне переполнения в сети, и необходимость в столь радикальных мерах, как медленный старт, отсутствует.

Однако потеря данных может вызвать ответное молчание. Для обработки подобной ситуации отправитель должен установить таймер и повторно передать данные по тайм-ауту, начиная с последнего подтверждения. Данный механизм является запасным и гарантирует повторную передачу, хотя и вызывает довольно большие задержки.

 

Программные интерфейсы

 

Программный интерфейс сокетов

Вы уже познакомились с интерфейсом сокетов при обсуждении реализации межпроцессного взаимодействия в BSD UNIX. Поскольку сетевая поддержка впервые была разработана именно для BSD UNIX, интерфейс сокетов и сегодня является весьма распространенным при создании сетевых приложений. В разделе "Поддержка сети в BSD UNIX" мы вновь вернемся к сокетам, когда будем рассматривать внутреннюю архитектуру сетевой подсистемы в UNIX ветви BSD. Сейчас же рассмотрим простой пример приложения клиент-сервер, который демонстрирует возможности сокетов при обеспечении взаимодействия между удаленными процессами. Несмотря на то что взаимодействие затрагивает передачу данных по сети, приведенная программа мало отличается от примера, рассмотренного в разделе "Межпроцессное взаимодействие в BSD UNIX. Сокеты" главы 3. Логика приложения сохранена — клиент отправляет серверу сообщение, сервер передает его обратно, а клиент, в свою очередь, выводит полученное сообщение на экран. Наиболее существенным отличием является коммуникационный домен сокетов — в данном случае AF_INET. Соответственно изменилась и схема адресации коммуникационного узла. Согласно схеме адресации TCP/IP, коммуникационный узел однозначно идентифицируется двумя значениями: адресом хоста (IP-адрес) и адресом процесса (адрес порта). Это отражает и структура sockaddr_in, которая является конкретным видом общей структуры адреса сокета sockaddr. Структура sockaddr_in имеет следующий вид:

struct sockaddr_in {

 short sin_family;        Коммуникационный домен — AF_INET

 u_short sin_port;        Номер порта

 struct in_addr sin_addr; IP-адрес хоста

 char sin_zero[8];

};

Адрес порта должен быть предварительно оговорен между клиентом и сервером.

В заключение, прежде чем перейти непосредственно к текстам программы, заметим, что интерфейс сокетов также поддерживается и в UNIX System V, наряду с другим программным интерфейсом — TLI, который будет рассмотрен в следующем разделе.

Приведенный пример в качестве транспортного протокола использует TCP. Это значит, что перед передачей прикладных данных клиент должен установить соединение с сервером. Эта схема, приведенная на рис. 6.17, несколько отличается от рассмотренной в разделе "Межпроцессное взаимодействие в BSD UNIX. Сокеты", где передача данных осуществлялась без предварительного установления связи и в данном случае соответствовала бы использованию протокола UDP.

Рис. 6.17. Схема установления связи и передачи данных между клиентом и сервером

В соответствии с этой схемой сервер производит связывание с портом, номер которого предполагается известным для клиентов bind(2), и сообщает о готовности приема запросов listen(2)). При получении запроса он с помощью функции accept(2) создает новый сокет, который и обслуживает обмен данными между клиентом и сервером. Для того чтобы сервер мог продолжать обрабатывать поступающие запросы, он порождает отдельный процесс на каждый поступивший запрос. Дочерний процесс, в свою очередь, принимает сообщения от клиента (recv(2)) и передает их обратно (send(2)).

Клиент не выполняет связывания, поскольку ему безразлично, какой адрес будет иметь его коммуникационный узел. Эту операцию выполняет система, выбирая свободный адрес порта и установленный адрес хоста. Далее клиент направляет запрос на установление соединения (connect(2)), указывая адрес сервера (IP-адрес и номер порта). После установления соединения ("тройное рукопожатие") клиент передает сообщение (send(2)), принимает от сервера ответ recv(2)) и выводит его на экран.

В программе используются несколько функций, которые не рассматривались. Эти функции значительно облегчают жизнь программисту, выполняя, например, такие действия, как трансляцию доменного имени хоста в его IP-адрес (gethostbyname(3N)), приведение в соответствие порядка следования байтов в структурах данных, который может различаться для хоста и сети (htons(3N)), а также преобразование IP-адресов и их составных частей в соответствии с привычной "человеческой" нотацией, например 127.0.0.1 (inet_ntoa(3N)). Мы не будем подробнее останавливаться на этих функциях, предоставляя читателю самостоятельно обратиться к соответствующим разделам электронного справочника man(1).

Ниже приведены тексты программ сервера и клиента.

Сервер

#include

#include

#include

#include

#include

#include

#include

/* Номер порта сервера, известный клиентам */

#define PORTNUM 1500

main(argc, argv)

int argc;

char *argv[];

{

 int s, ns;

 int pid;

 int nport;

 struct sockaddr_in serv_addr, clnt_addr;

 struct hostent* hp;

 char buf[80], hname[80];

 /* Преобразуем порядок следования байтов

    к сетевому формату */

 nport = PORTNUM;

 nport = htons((u_short)nport);

 /* Создадим сокет, использующий протокол TCP */

 if ((s=socket(AF_INET, SOCK_STREAM, 0))==-1) {

  perror("Ошибка вызова socket()");

  exit(1);

 }

 /* Зададим адрес коммуникационного узла */

 bzero(&serv_addr, sizeof(serv_addr));

 serv_addr.sin_family = AF_INET;

 serv_addr.sin_addr.s_addr = INADDR_ANY;

 serv.addr.sin_port = nport;

 /* Свяжем сокет с этим адресом */

 if (bind(s, struct sockaddr*)&serv_addr,

  sizeof(serv_addr))==-1) {

  perror("Ошибка вызова bind()");

  exit(1);

 }

 /* Выведем сообщение с указанием адреса сервера */

 fprintf(stderr, "Сервер готов: %s\n",

  inet_ntoa(serv_addr.sin_addr));

 /* Сервер готов принимать запросы

    на установление соединения.

    Максимальное число запросов, ожидающих обработки – 5.

    Как правило, этого числа достаточно, чтобы успеть

    выполнить accept(2) и породить дочерний процесс */

 if (listen(s, 5)==-1) {

  perror("Ошибка вызова listen()");

  exit(1);

 }

 /* Бесконечный цикл получения запросов и их обработки */

 while (1) {

  int addrlen;

  bzero(&clnt_addr, sizeof(clnt_addr));

  addrlen = sizeof(clnt_addr);

  /* Примем запрос. Новый сокет ns становится

     коммуникационным узлом созданного виртуального канала */

  if ((ns=accept(s, (struct sockaddr*)&clnt_addr,

   &addrlen))==-1) {

   perror("Ошибка вызова accept()");

   exit(1);

  }

  /* Выведем информацию о клиенте */

  fprintf(stderr, "Клиент = %s\n",

   inet_ntoa(clnt_addr.sin_addr));

  /* Создадим процесс для работы с клиентом */

  if ((pid=fork())==-1) {

   perror("Ошибка вызова fork()");

   exit(1);

  }

  if (pid==0) {

   int nbytes;

   int fout;

   /* Дочерний процесс: этот сокет нам не нужен. Он

      по-прежнему используется для получения запросов */

   close(s);

   /* Получим сообщение от клиента и передадим его обратно */

   while ((nbytes = recv(ns, buf, sizeof(buf), 0)) !=0) {

    send(ns, buf, sizeof(buf), 0);

   }

   close(ns);

   exit(0);

  }

  /* Родительский процесс: этот сокет нам не нужен. Он

     используется дочерним процессом для обмена данными */

  close(ns);

 }

}

Клиент

#include

#include

#include

#include

#include

#include

#include

/* Номер порта, который обслуживается сервером */

#define PORTNUM 1500

main (argc, argv)

char *argv[];

int argc;

{

 int s;

 int pid;

 int i, j;

 struct sockaddr_in serv_addr;

 struct hostent *hp;

 char buf[80]="Hello, World!";

 /* В качестве аргумента клиенту передается доменное имя

    хоста, на котором запущен сервер. Произведем трансляцию

    доменного имени в адрес */

 if ((hp = gethostbyname(argv[1])) == 0) {

  perror("Ошибка вызова gethostbyname()");

  exit(3);

 }

 bzero(&serv_addr, sizeof(serv_addr));

 bcopy(hp->h_addr, &serv_addr.sin_addr, hp->h_length);

 serv_addr.sin_family = hp->h_addrtype;

 serv_addr.sin_port = htons(PORTNUM);

 /* Создадим сокет */

 if ((s = socket(AF_INET, SOCK_STREAM, 0)) == -1) {

  perror("Ошибка вызова socket!)");

  exit(1);

 }

 fprintf(stderr, "Адрес клиента: %s\n",

  inet_ntoa(serv_addr.sin_addr));

 /* Создадим виртуальный канал */

 if (connect (s, (struct sockaddr*)&serv_addr,

  sizeof(serv_addr)) == -1) {

  perror("Ошибка вызова connect()");

  exit(1);

 }

 /* Отправим серверу сообщение и получим его обратно */

 send(s, buf, sizeof(buf), 0);

 if (recv(s, buf, sizeof(buf) , 0) < 0) {

  perror("Ошибка вызова recv()");

  exit(1);

 }

 /* Выведем полученное сообщение на экран */

 printf("Получено от сервера: %s\n", buf);

 close(s);

 printf("Клиент завершил работу \n\n");

}

 

Программный интерфейс TLI

При обсуждении реализации сетевой поддержки в BSD UNIX был рассмотрен программный интерфейс доступа к сетевым ресурсам, основанный на сокетах. В данном разделе описан интерфейс транспортного уровня (Transport Layer Interface, TLI), который обеспечивает взаимодействие прикладных программ с транспортными протоколами.

TLI был впервые представлен в UNIX System V Release 3.0 в 1986 году. Этот программный интерфейс тесно связан с сетевой подсистемой UNIX, основанной на архитектуре STREAMS, изолируя от прикладной программы особенности сетевой архитектуры. Вместо того чтобы непосредственно пользоваться общими функциями STREAMS, рассмотренными в предыдущей главе, TLI позволяет использовать специальный набор вызовов, специально предназначенных для сетевых приложений. Для преобразования вызовов TLI в функции интерфейса STREAMS используется библиотека TLI, которая в большинстве систем UNIX имеет название libnsl.a или libnsl.so.

Схема использования функций TLI во многом сходна с рассмотренным интерфейсом сокетов и зависит от типа используемого протокола — с предварительным установлением соединения (например, TCP) или без него (например, UDP).

На рис. 6.18 и 6.19 представлены схемы использования функций TLI для транспортных протоколов с предварительным установлением соединения и без установления соединения. Можно отметить, что эти схемы очень похожи на те, с которыми мы уже встречались в разделе "Межпроцессное взаимодействие в BSD UNIX. Сокеты" главы 3 при обсуждении сокетов. Некоторые различия отмечены ниже при описании функций TLI.

Рис. 6.18. Схема вызова функций TLI для протокола с предварительным установлением соединения

Рис. 6.19. Схема вызова функций TLI для протокола без предварительного установления соединения

Прежде чем перейти к обсуждению функций TLI, остановимся на определении адреса коммуникационного узла. TLI не накладывает никаких ограничений на формат адреса, возлагая интерпретацию на протоколы нижнего уровня. Благодаря этому, один и тот же интерфейс может быть использован при работе с различными семействами сетевых протоколов.

Для определения адреса TLI предоставляет общую структуру данных netbuf, имеющую вид:

struct netbuf {

 unsigned int maxlen;

 unsigned int len;

 char *buf;

}

Поле buf указывает на буфер, в котором может передаваться адрес узла, maxlen определяет его размер, a len — количество данных в буфере, т.е. размер адреса. Эта структура по своему назначению похожа на структуру sockaddr, которая является общим определением адреса коммуникационного узла для сокетов. Далее рассматривается пример сетевого приложения, основанного на TLI, где показано, как netbuf используется при передаче адреса для протоколов TCP/IP.

Структура netbuf используется в TLI для хранения не только адреса, но и другой информации — опций протокола и прикладных данных. Эта структура является составной частью более сложных структур данных, используемых при передаче параметров в функциях TLI. Для упрощения динамического размещения этих структур библиотека TLI предоставляет две функции: t_alloc(3N) для размещения структуры и t_free(3N) для освобождения памяти. Эти функции имеют следующий вид:

#include

char *t_alloc(int fd, int struct_type, int fields);

int t_free(char *ptr, int struct_type);

Аргумент struct_type определяет, для какой структуры данных выделяется память. Он может принимать следующие значения:

Значение поля struct_type Структура данных
T_BIND struct t_bind
T_CALL struct t_call
T_DIS struct t_discon
T_INFO struct t_info
T_OPTMGMT struct t_optmgmt
T_UNITDATA struct t_unitdata
T_UDERROR struct t_uderr

Co структурами, приведенными в таблице, мы познакомимся при обсуждении функций TLI. Большинство из них включают несколько элементов netbuf. Поскольку в некоторых случаях может отсутствовать необходимость размещения всех элементов netfuf, поле fields позволяет указать, какие конкретно буферы необходимо разместить для данной структуры:

Значение поля fields Размещаемые и инициализируемые поля
T_ALL Все необходимые поля
T_ADDR Поле addr в структурах t_bind , t_call , t_unitdata , t_uderr
T_OPT Поле opt в структурах t_call , t_unitdata , t_uderr , t_optmgmt
T_UDATA Поле udata в структурах t_call , t_unitdata , t_discon

Отметим одну особенность. Фактический размер буфера и, соответственно, структуры netbuf зависят от значения поля maxlen этой структуры. В свою очередь, этот параметр зависит от конкретного поставщика транспортных услуг — именно он определяет максимальный размер адреса, опций и прикладных данных. Чуть позже мы увидим, что эта информация ассоциирована с транспортным узлом и может быть получена после его создания с помощью функции t_open(3N). Поэтому для определения фактического размера размещаемых структур в функции t_аlloc(3N) необходим аргумент fd, являющийся дескриптором транспортного узла, который возвращается процессу функцией t_open(3N).

Перейдем к основным функциям TLI.

Как видно из рис. 6.18 и 6.19, в качестве первого этапа создания коммуникационного узла используется функция t_open(3N). Как и системный вызов open(2), она возвращает дескриптор, который в дальнейшем адресует узел в функциях TLI. Функция имеет вид:

#include

#include

int t_open(const char *path, int oflags, struct t_info *info);

Аргумент path является именем специального файла устройства, являющегося поставщиком транспортных услуг, например, /dev/tcp или /dev/udp. Аргумент oflags определяет флаги открытия файла и соответствует аналогичному аргументу системного вызова open(2). Приложение может получить информацию о поставщике транспортных услуг в структуре info, имеющей следующие поля:

addr Определяет максимальный размер адреса транспортного протокола. Значение -1 говорит, что размер не ограничен, -2 означает, что прикладная программа не имеет доступа к адресам протокола. Протокол TCP устанавливает размер этого адреса (адрес порта) равным 16.
options Определяет размер опций для данного протокола. Значение -1 свидетельствует, что размер не ограничен, -2 означает, что прикладная программа не имеет возможности устанавливать опции протокола.
tsdu Определяет максимальный размер пакета данных протокола (Transport Service Data Unit, TSDU). Нулевое значение означает, что протокол не поддерживает пакетную передачу (т.е. не сохраняет границы записей). Значение -1 свидетельствует, что размер не ограничен, -2 означает, что передача обычных данных не поддерживается. Поскольку протокол TCP обеспечивает передачу неструктурированного потока данных, значение tsdu для него равно 0. Напротив, UDP поддерживает пакетную передачу.
etsdu Определяет максимальный размер пакета экстренных данных протокола (Expedited Transport Service Data Unit, ETSDU). Нулевое значение означает, что протокол не поддерживает пакетную передачу (т.е. не сохраняет границы записей). Значение -1 свидетельствует, что размер не ограничен, -2 означает, что передача экстренных данных не поддерживается. TCP обеспечивает такую поддержку, а UDP — нет.
connect Некоторые протоколы допускают передачу прикладных данных вместе с запросом на соединение. Поле connect определяет максимальный размер таких данных. Значение -1 свидетельствует, что размер не ограничен, -2 означает, что данная возможность не поддерживается. И TCP и UDP не поддерживают этой возможности.
discon Определяет то же, что и connect , но при запросе на прекращение соединения. И TCP и UDP не поддерживают этой возможности.
servtype Определяет тип транспортных услуг, предоставляемых протоколом. Значение T_COTS означает передачу с предварительным установлением соединения, T_COTS_ORD — упорядоченную передачу с предварительным установлением соединения, T_CLTS — передачу без предварительного установления соединения. Протокол TCP обеспечивает услугу T_COTS_ORD , a UDP — T_CLTS .

Прежде чем передача данных будет возможна, транспортному узлу должен быть присвоен адрес. Эта фаза называется операцией связывания и мы уже сталкивались с ней при разговоре о сокетах в главе 3 и при обсуждении сетевой поддержки в BSD UNIX ранее в этой главе. В рассмотренных случаях связывание выполнял вызов bind(2). В TLI для этого служит функция t_bind(3N), имеющая вид:

#include

int t_bind(int fd, const struct t_bind *req,

 struct t_bind *ret);

Аргумент fd адресует коммуникационный узел. Аргумент req позволяет программе явно указать требуемый адрес, а через аргумент ret возвращается значение, установленное протоколом.

Два последних аргумента описываются структурой t_bind, имеющей следующие поля:

struct netbuf addr Адрес
unsigned qlen Максимальное число запросов на установление связи, которые могут ожидать обработки. Имеет смысл только для протоколов с предварительным установлением соединения

Рассмотрим три возможных формата аргумента req:

req == NULL Позволяет поставщику транспортных услуг самому выбрать подходящий адрес
req != NULL req->addr.len == 0 Позволяет поставщику транспортных услуг самому брать подходящий адрес, но определяет максимальное число запросов на установление связи, которые могут ожидать обработки
req != NULL req->addr.len > 0 Явно указывает требуемый адрес и максимальное число запросов на установление связи, которые могут ожидать обработки

Во всех случаях фактическое значение адреса возвращается в структуре ret. Даже если программа явно указала требуемый адрес, необходимо проверить, совпадает ли он с адресом, указанным в ret.

Для протоколов с предварительным установлением соединения программе-клиенту необходимо использовать функцию t_connect(3N), отправляющую запрос на создание соединения с удаленным транспортным узлом. Функция t_connect(3N) имеет вид:

#include

int t_connect(int fd, const struct t_call* sndcall,

 struct t_call *rcvcall);

Аргумент sndcall содержит информацию, необходимую поставщику транспортных услуг для создания виртуального канала. Формат этой информации описывается структурой t_call, имеющей следующие поля:

struct netbuf addr Адрес удаленного транспортного узла
struct netbuf opt Требуемые опции протокола
struct netbuf udata Прикладные данные, отправляемые вместе с управляющей информацией (запрос на установление соединения или подтверждение)
int sequence В данном случае не имеет смысла

Через аргумент revcall программе возвращается информация о виртуальном канале после его создания: адрес удаленного узла, опции и прикладные данные, переданные удаленным узлом. Как уже отмечалось, ни TCP, ни UDP не позволяют передавать данные вместе с управляющей информацией. Программа может установить значение rcvcall равным NULL, если информация о канале ее не интересует.

Обычно возврат из функции t_connect(3N) происходит после окончательного установления соединения, когда виртуальный канал готов к передаче данных (конечно, в случае успешного завершения).

Для протоколов с предварительным установлением соединения программа-сервер вызывает функцию t_listen(3N), блокируя свое выполнение до получения запроса на создание виртуального канала.

#include

int t_listen(int fd, struct t_call *call);

Информация, возвращаемая транспортным протоколом в аргументе call, содержит параметры, переданные удаленным узлом с помощью соответствующего вызова t_connect(3N): его адрес, установленные опции протокола, а также, в ряде случаев, прикладные данные, переданные вместе с запросом. Поле sequence аргумента call содержит уникальный идентификатор данного запроса.

Хотя t_listen(3N), несмотря на название, напоминает функцию accept(2), используемую для сокетов, сервер должен выполнить вызов другой функции — t_accept(3N) для того, чтобы фактически принять запрос и установить соединение. Функция t_accept(3N) имеет вид:

#include

int t_accept(int fd, int connfd, struct t_call *call);

Аргумент fd адресует транспортный узел, принявший запрос (тот же, что и для функции t_listen(3N)). Аргумент connfd адресует транспортный узел, для которого будет установлено соединение с удаленным узлом. За создание нового транспортного узла отвечает сама программа (т.е. необходим явный вызов функции t_open(3N)), при этом fd может по-прежнему использоваться для обслуживания поступающих запросов.

Как и в случае t_listen(3N), через аргумент call передается информация об удаленном транспортном узле.

После возврата из функции t_accept(3N) между двумя узлами (connfd и удаленным узлом-клиентом) образован виртуальный канал, готовый к передаче прикладных данных.

Для обмена прикладными данными после установления соединения используются две функции: t_rcv(3N) для получения и t_snd(3N) для передачи. Они имеют следующий вид:

#include

int t_rcv(int fildes, char *buf, unsigned nbytes, int* flags);

int t_snd(int fildes, char *buf, unsigned nbytes, int flags);

Первые три аргумента соответствуют аналогичным аргументам системных вызовов read(2) и write(2). Аргумент flags функции t_snd(3N) может содержать следующие флаги:

T_EXPEDITED Указывает на отправление экстренных данных
T_MORE Указывает, что данные составляют логическую запись, продолжение которой будет передано последующими вызовами t_snd(3N) . Напомним, что TCP обеспечивает неструктурированный поток и, следовательно, не поддерживает данной возможности

Эту информацию принимающий узел получает с помощью t_rcv(3N) также через аргумент flags.

Для протоколов без предварительного установления соединения используются функции t_rcvdata(3N) и t_snddata(3N) для получения и передачи датаграмм соответственно. Функции имеют следующий вид:

#include

int t_rcvudata(int fildes, struct t_unitdata *unitdata,

 int* flags);

int t_sndudata(int fildes, struct t_unitdata *unitdata);

Для передачи данных используется структура unitdata, имеющая следующие поля:

struct netbuf addr Адрес удаленного транспортного узла
struct netbuf opt Опции протокола
struct netbuf udata Прикладные данные

Созданный транспортный узел может быть закрыт с помощью функции t_close(3N). Заметим, что при этом соединение, или виртуальный канал, с которым ассоциирован данный узел, в ряде случаев не будет закрыт. Функция t_close(3N) имеет вид:

#include

int t_close(int fd);

где fd определяет транспортный узел. Вызов этой функции приведет к освобождению ресурсов, связанных с транспортным узлом, а последующий системный вызов close(2) освободит и файловый дескриптор. Судьба виртуального канала (если таковой существует) зависит от того, является ли транспортный узел, адресующий данный канал, единственным. Если это так, соединение немедленно разрывается. В противном случае, например, когда несколько файловых дескрипторов адресуют один и тот же транспортный узел, виртуальный канал продолжает существовать.

Завершая разговор о программном интерфейсе TLI, необходимо упомянуть об обработке ошибок. Для большинства функций TLI свидетельством ошибки является получение -1 в качестве возвращаемого значения. Напротив, в случае нормального завершения эти функции возвращают 0. Как правило, при неудачном завершении функции TLI код ошибки сохраняется в переменной t_errno, подобно тому, как переменная errno хранит код ошибки системного вызова. Для вывода сообщения, расшифровывающего причину ошибки, используется функция t_error(3N):

#include

void t_error(const char *errmsg);

При вызове t_error(3N) после неудачного завершения какой-либо функции TLI будет выведено сообщение errmsg, определенное разработчиком программы, за которым последует расшифровка ошибки, связанной с кодом t_errno. Если значение t_errno равно TSYSERR, то расшифровка представляет собой стандартное сообщение о системной ошибке, связанной с переменной errno.

В заключение в качестве иллюстрации программного интерфейса TLI приведем пример приложения клиент-сервер. Как и в предыдущих примерах, сервер принимает сообщения от клиента и отправляет их обратно. Клиент, в свою очередь, выводит полученное сообщение на экран. В качестве сообщения, как и прежде, выступает жизнерадостное приветствие "Здравствуй, мир!".

Сервер

#include

#include

#include

#include

#include

#include

#include

#include

/* Номер порта, известный клиентам */

#define PORTNUM 1500

main(argc, argv)

int argc;

char *argv[];

{

 /* Дескрипторы транспортных узлов сервера */

 int tn, ntn;

 int pid, flags;

 int nport;

 /* Адреса транспортных узлов сервера и клиента */

 struct sockaddr_in serv_addr, *clnt_addr;

 struct hostent *hp;

 char buf[80], hname[80];

 struct t_bind req;

 struct t_call *call;

 /* Создадим транспортный узел. В качестве поставщика

    транспортных услуг выберем модуль TCP */

 if ((tn = t_open("/dev/tcp", O_RDWR, NULL)) == -1) {

  t_error("Ошибка вызова t_open()");

  exit(1);

 }

 /* Зададим адрес транспортного узла — он должен быть

    известен клиенту */

 nport = PORTNUM;

 /* Приведем в соответствие порядок следования байтов для хоста

    и сети */

 nport = htons((u_short)nport);

 bzero(&serv_addr, sizeof(serv_addr));

 serv_addr.sin_family = AF_INET;

 serv_addr.sin_addr.s_addr = INADDR_ANY;

 serv_addr.sin_port = nport;

 req.addr.maxlen = sizeof(serv_addr);

 req.addr.len = sizeof(serv_addr);

 req.addr.buf = (char*)&serv_addr;

 /* Максимальное число запросов, ожидающих обработки,

    установим равным 5 */

 req.qlen = 5;

 /* Свяжем узел с запросом */

 if (t_bind(tn, &req, (struct t_bind*)0) < 0) {

  t_error("Ошибка вызова t_bind();

  exit(1);

 }

 fprintf(stderr, "Адрес сервера: %s\n",

  inet_ntoa(serv_addr.sin_addr));

 /* Поскольку в структуре t_call нам понадобится только буфер

    для хранения адреса клиента, разместим ее динамически */

 if ((call =

  (struct t_call*)t_alloc(tn, T_CALL, T_ADDR)) == NULL) {

  t_error("Ошибка вызова t_alloc()");

  exit(2);

 }

 call->addr.maxlen = sizeof(serv_addr);

 call->addr.len = sizeof(srv_addr);

 call->opt.len = 0;

 call->update.len = 0;

 /* Бесконечный цикл получения и обработки запросов */

 while (1) {

  /* Ждем поступления запроса на установление соединения */

  if (t_listen(s, call) < 0) {

   t_error("Ошибка вызова t_listen()");

   exit(1);

  }

  /* Выведем информацию о клиенте, сделавшем запрос */

  clnt_addr = (struct sockaddr_in*)call->addr.buf;

  printf("Клиент: %s\n", inet_ntoa(clnt_addr->sin_addr));

  /* Создадим транспортный узел для обслуживания запроса */

  if (ntn = t_open("/dev/tcp", O_RDWR, (struct t_info*)0)) < 0) {

   t_error("Ошибка вызова t_open()");

   exit(1);

  }

  /* Пусть система сама свяжет его с подходящим адресом */

  if (t_bind(ntn, (struct t_bind*)0), (struct t_bind*)0) < 0) {

   t_error("Ошибка вызова t_accept()");

   exit(1);

  }

  /* Примем запрос и переведем его обслуживание на новый

     транспортный узел */

  if (t_accept(tn, ntn, call) < 0) {

   t_error("Ошибка вызова t_accept()");

   exit(1);

  }

  /* Создадим новый процесс для обслуживания запроса.

     При этом родительский процесс продолжает принимать

     запросы от клиентов */

  if ((pid = fork()) == -1) {

   t_error("Ошибка вызова fork()");

   exit(1);

  }

  if (pid == 0) {

   int nbytes;

   /* Дочерний процесс: этот транспортный узел уже не нужен,

      он используется родителем */

   close(tn);

   while ((nbytes = t_rcv(ntn, buf,

    sizeof(buf), &flags)) != 0) {

    t_snd(ntn, buf, sizeof(buf), 0);

   }

   t_close(ntn);

   exit(0);

  }

  /* Родительский процесс: этот транспортный узел не нужен,

     он используется дочерним процессом для обмена данными

     с клиентом */

  t_close(ntn);

 }

 t_close(ntn);

}

Клиент

#include

#include

#include

#include

#include

#include

#include

#include

#define PORTNUM 1500

main(argc, argv)

char *argv[];

int argc;

{

 int tn;

 int flags;

 struct sockaddr_in serv_addr;

 struct hostent *hp;

 char buf[80]="Здравствуй, мир!";

 struct t_call* call;

 /* В качестве аргумента клиенту передается доменное имя хоста,

    на котором запущен сервер. Произведем трансляцию доменного

    имени в адрес */

 if ((hp = gethostbyname(argv[1])) == 0) {

  perror("Ошибка вызова gethostbyname()");

  exit(1);

 }

 /* Создадим транспортный узел. В качестве поставщика

    транспортных услуг выберем модуль TCP */

 printf("Сервер готов\n");

 if ((tn = t_open("/dev/tcp", O_RDWR, NULL)) == -1) {

  t_error("Ошибка вызова t_open()");

  exit(1);

 }

 /* Предоставим системе самостоятельно связать узел с

    подходящим адресом */

 if (t_bind(tn, (struct t_bind*)0,

  (struct t_bind *)0) < 0} {

  t_error("Ошибка вызова t_bind()");

  exit(1);

 }

 fprintf(stderr, "Адрес клиента: %s\n",

  inet_ntoa(serv_addr.sin_addr));

 /* Укажем адрес сервера, с которым мы будем работать */

 bzero(&serv_addr, sizeof(serv_addr));

 bcopy(hp->h_addr, &serv_addr.sin_addr, hp->h_length);

 serv_addr.sin_family = hp->h_addrtype;

 /* Приведем в соответствие порядок следования байтов

    для хоста и сети */

 serv_addr.sin_port = htons(PORTNUM);

 /* Поскольку в структуре t_call нам понадобится только буфер

    для хранения адреса сервера, разместим ее динамически */

 if ((call =

  (struct t_call*)t_alloc(tn, T_CALL, T_ADDR)) == NULL) {

  t_error("Ошибка вызова t_alloc()");

  exit(2);

 }

 call->addr.maxlen = sizeof(serv_addr);

 call->addr.len = sizeof(serv_addr);

 call->addr.buf = (char*)&serv_addr;

 call->opt.len = 0;

 call->udata.len = 0;

 /* Установи соединение с сервером */

 if (t_connect(tn, call, (struct t_call*)0) == -1) {

  t_error("Ошибка вызова t_rcv()");

  exit(1);

 }

 /* Передадим сообщение и получим ответ */

 t_snd(tn, buf, sizeof(buf), 0);

 if (t_rcv(tn, buf, sizeof(buf), &flags) < 0) {

  t_error("Ошибка вызова t_rcv()");

  exit(1);

 }

 /* Выведем полученное сообщение на экран */

 printf("Получено от сервера: %s\n", buf);

 printf("Клиент завершил работу!\n\n");

}

В рассмотренном примере большая часть исходного текста посвящена созданию транспортных узлов и установлению соединения, в то время как завершение сеанса связи представлено скупыми вызовами t_close(3N). На самом деле, вызов t_close(3N) приводит к немедленному разрыву соединения, запрещая дальнейшую передачу или прием данных. Однако виртуальный канал, обслуживаемый протоколом TCP, является полнодуплексным и, как было показано, TCP предусматривает односторонний разрыв связи, позволяя другой стороне продолжать передачу данных. Действиям, предписываемым TCP, больше соответствуют две функции t_sndrel(3N) и t_rcvrel(3N), которые обеспечивают "корректное "прекращение связи (orderly release). Разумеется, эти рассуждения справедливы лишь для транспортного протокола, обеспечивающего передачу данных с предварительным установлением связи, каковым, в частности, является протокол TCP.

Функции t_sndrel(3N) и t_rcvrel(3N) имеют вид:

#include

int t_sndrel(int fd);

int t_rcvrel(int fd);

Вызывая функцию t_sndrel(3N), процесс отправляет другой стороне уведомление об одностороннем прекращении связи, это означает, что процесс не намерен больше передавать данные. В то же время процесс может принимать данные — файловый дескриптор fd доступен для чтения.

Другая сторона подтверждает получение уведомления вызовом функции t_rcvrel(3N). Однако поскольку получение такого уведомления носит асинхронный характер, процесс должен каким-то образом узнать, что запрос поступил. Такой индикацией является завершение с ошибкой попытки получения данных от удаленного узла, например, с помощью функции t_rcv(3N). В этом случае вызов функции t_rcv(3N) завершится с ошибкой TLOOK.

Эта ошибка свидетельствует, что произошло событие, связанное с коммуникационным узлом, анализ которого позволяет получить дополнительную информацию о причине неудачи. Текущее событие может быть получено с помощью функции t_look(3N):

#include

int t_look(int fildes);

Функция возвращает идентификатор, соответствующий одному из событий, перечисленных в табл. 6.6.

Таблица 6.6. События, связанные с коммуникационным узлом

Событие Значение
T_CONNECT Узлом получено подтверждение создания соединения
T_DISCONNECT Узлом получен запрос на разрыв соединения
T_DATA Узлом получены данные
T_EXDATA Узлом получены экстренные данные
T_LISTEN Узлом получен запрос на установление соединения
T_ORDREL Узлом получен запрос на корректное прекращение связи
T_ERROR Свидетельствует о фатальной ошибке
T_UDERR Свидетельствует об ошибке датаграммы

Если в рассматриваемом случае событием, связанным с ошибкой t_rcv(3N), является T_ORDREL, это означает, что удаленный узел завершил передачу данных и более не нуждается в соединении. Если узел, получивший запрос на прекращение связи, не возражает против полного прекращения сеанса, он вызывает функцию t_sndrel(3N). Впрочем, при необходимости, коммуникационный узел может продолжить передачу данных. Единственное, отчего ему следует воздержаться, это от попытки получения данных, или, другими словами, от вызова t_rcv(3N), поскольку в этом случае выполнение процесса будет навсегда заблокировано, т.к. данные от удаленного узла поступать не будут.

Проиллюстрируем описанную процедуру фрагментом программы, обрабатывающей корректное прекращение связи:

while (t_rcv(fd) != -1) {

 /* Выполняем обработку принятых данных */

 ...

}

if (t_errno == T_LOOK && t_look(fd) == T_ORDREL) {

 /* Значит, получен запрос на корректное прекращение связи.

    Мы согласны на завершение сеанса, поэтому также корректно

    завершаем связь */

 t_rcvrel(fd);

 t_sndrel(fd);

 exit(0);

} else {

 t_error("Ошибка получения данных (t_rcv)");

 exit(1);

}

 

Программный интерфейс высокого уровня.

 

Удаленный вызов процедур

В предыдущих разделах рассматривался программный интерфейс достаточно низкого уровня — по существу программа взаимодействовала непосредственно с транспортным протоколом, самостоятельно реализуя некоторый протокол верхнего уровня при обмене данными. В приведенных примерах легко заметить, что значительная часть кода этих программ посвящена созданию коммуникационных узлов, установлению и завершению связи.

С точки зрения разработчика программного обеспечения, более перспективным является подход, когда используется прикладной программный интерфейс более высокого уровня, изолирующий программу от специфики сетевого взаимодействия. В данном разделе мы рассмотрим один из таких подходов, на базе которого, в частности, разработана файловая система NFS, получивший название удаленный вызов процедур (Remote Procedure Call, RPC).

Использование подпрограмм в программе — традиционный способ структурировать задачу, сделать ее более ясной. Наиболее часто используемые подпрограммы собираются в библиотеки, где могут использоваться различными программами. В данном случае речь идет о локальном (местном) вызове, т.е. и вызывающий, и вызываемый объекты работают в рамках одной программы на одном компьютере.

В случае удаленного вызова процесс, выполняющийся на одном компьютере, запускает процесс на удаленном компьютере (т. е. фактически запускает код процедуры на удаленном компьютере). Очевидно, что удаленный вызов процедуры существенным образом отличается от традиционного локального, однако с точки зрения программиста такие отличия практически отсутствуют, т.е. архитектура удаленного вызова процедуры позволяет сымитировать вызов локальной.

Однако если в случае локального вызова программа передает параметры в вызываемую процедуру и получает результат работы через стек или общие области памяти, то в случае удаленного вызова передача параметров превращается в передачу запроса по сети, а результат работы находится в пришедшем отклике.

Данный подход является возможной основой создания распределенных приложений, и хотя многие современные системы не используют этот механизм, основные концепции и термины во многих случаях сохраняются. При описании механизма RPC мы будем традиционно называть вызывающий процесс — клиентом, а удаленный процесс, реализующий процедуру, — сервером.

Удаленный вызов процедуры включает следующие шаги:

1. Программа-клиент производит локальный вызов процедуры, называемой заглушкой (stub). При этом клиенту "кажется", что, вызывая заглушку, он производит собственно вызов процедуры-сервера. И действительно, клиент передает заглушке необходимые параметры, а она возвращает результат. Однако дело обстоит не совсем так, как это себе представляет клиент. Задача заглушки — принять аргументы, предназначаемые удаленной процедуре, возможно, преобразовать их в некий стандартный формат и сформировать сетевой запрос. Упаковка аргументов и создание сетевого запроса называется сборкой (marshalling).

2. Сетевой запрос пересылается по сети на удаленную систему. Для этого в заглушке используются соответствующие вызовы, например, рассмотренные в предыдущих разделах. Заметим, что при этом могут быть использованы различные транспортные протоколы, причем не только семейства TCP/IP.

3. На удаленном хосте все происходит в обратном порядке. Заглушка сервера ожидает запрос и при получении извлекает параметры — аргументы вызова процедуры. Извлечение (unmarshalling) может включать необходимые преобразования (например, изменения порядка расположения байтов).

4. Заглушка выполняет вызов настоящей процедуры-сервера, которой адресован запрос клиента, передавая ей полученные по сети аргументы.

5. После выполнения процедуры управление возвращается в заглушку сервера, передавая ей требуемые параметры. Как и заглушка клиента, заглушка сервера преобразует возвращенные процедурой формируя сетевое сообщение-отклик, который передается по сети системе, от которой пришел запрос.

6. Операционная система передает полученное сообщение заглушке клиента, которая, после необходимого преобразования, передает значения (являющиеся значениями, возвращенными удаленной процедурой) клиенту, воспринимающему это как нормальный возврат из процедуры.

Таким образом, с точки зрения клиента, он производит вызов удаленной процедуры, как он это сделал бы для локальной. То же самое можно сказать и о сервере: вызов процедуры происходит стандартным образом, некий объект (заглушка сервера) производит вызов локальной процедуры и получает возвращенные ею значения. Клиент воспринимает заглушку как вызываемую процедуру-сервер, а сервер принимает собственную заглушку за клиента.

Таким образом, заглушки составляют ядро системы RPC, отвечая за все аспекты формирования и передачи сообщений между клиентом и удаленным сервером (процедурой), хотя и клиент и сервер считают, что вызовы происходят локально. В этом-то и состоит основная концепция RPC — полностью спрятать распределенный (сетевой) характер взаимодействия в коде заглушек. Преимущества такого подхода очевидны: и клиент и сервер являются независимыми от сетевой реализации, оба они работают в рамках некой распределенной виртуальной машины, и вызовы процедур имеют стандартный интерфейс.

 

Передача параметров

Передача параметров-значений не вызывает особых трудностей. В этом случае заглушка клиента размещает значение параметра в сетевом запросе. возможно, выполняя преобразования к стандартному виду (например, изменяя порядок следования байтов). Гораздо сложнее обстоит дело с передачей указателей, когда параметр представляет собой адрес данных, а не их значение. Передача в запросе адреса лишена смысла, так как удаленная процедура выполняется в совершенно другом адресном пространстве. Самым простым решением, применяемым в RPC, является запрет клиентам передавать параметры иначе, как по значению, хотя это, безусловно накладывает серьезные ограничения.

 

Связывание (binding)

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

□ Нахождение удаленного хоста с требуемым сервером

□ Нахождение требуемого серверного процесса на данном хосте

Для нахождения хоста могут использоваться различные подходы. Возможный вариант — создание некоего централизованного справочника, в котором хосты анонсируют свои серверы, и где клиент при желании может выбрать подходящие для него хост и адрес процедуры.

Каждая процедура RPC однозначно определяется номером программы и процедуры. Номер программы определяет группу удаленных процедур, каждая из которых имеет собственный номер. Каждой программе также присваивается номер версии, так что при внесении в программу незначительных изменений (например, при добавлении процедуры) отсутствует необходимость менять ее номер. Обычно несколько функционально сходных процедур реализуются в одном программном модуле, который при запуске становится сервером этих процедур, и который идентифицируется номером программы.

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

Для передачи запроса клиенту также необходимо знать сетевой адрес хоста и номер порта, связанный с программой-сервером, обеспечивающей требуемые процедуры. Для этого используется демон portmap(1M) (в некоторых системах он называется rpcbind(1M)). Демон запускается на хосте, который предоставляет сервис удаленных процедур, и использует общеизвестный номер порта. При инициализации процесса-сервера он регистрирует в portmap(1M) свои процедуры и номера портов. Теперь, когда клиенту требуется знать номер порта для вызова конкретной процедуры, он посылает запрос на сервер portmap(1M), который, в свою очередь, либо возвращает номер порта, либо перенаправляет запрос непосредственно серверу удаленной процедуры и после ее выполнения возвращает клиенту отклик. В любом случае, если требуемая процедура существует, клиент получает от сервера portmap(1M) номер порта процедуры, и дальнейшие запросы может делать уже непосредственно на этот порт.

 

Обработка особых ситуаций (exception)

Обработка особых ситуаций при вызове локальных процедур не представляет особой проблемы. UNIX обеспечивает обработку ошибок процессов, таких как деление на ноль, обращение к недопустимой области памяти и т.д. В случае вызова удаленной процедуры вероятность возникновения ошибочных ситуаций увеличивается. К ошибкам сервера и заглушек добавляются ошибки, связанные, например, с получением ошибочного сетевого сообщения.

Например, при использовании UDP в качестве транспортного протокола производится повторная передача сообщений после определенного тайм- аута. Клиенту возвращается ошибка, если, спустя определенное число попыток. отклик от сервера так и не был получен. В случае, когда используется протокол TCP, клиенту возвращается ошибка, если сервер оборвал TCP-соединение.

 

Семантика вызова

Вызов локальной процедуры однозначно приводит к ее выполнению, после чего управление возвращается в головную программу. Иначе дело обстоит при вызове удаленной процедуры. Невозможно установить, когда конкретно будет выполняться процедура, будет ли она выполнена вообще, а если будет, то какое число раз? Например, если запрос будет получен удаленной системой после аварийного завершения программы сервера, процедура не будет выполнена вообще. Если клиент при неполучении отклика после определенного промежутка времени (тайм-аута) повторно посылает запрос, то может создаться ситуация, когда отклик уже передается по сети, повторный запрос вновь принимается на обработку удаленной процедурой. В этом случае процедура будет выполнена несколько раз.

Таким образом, выполнение удаленной процедуры можно характеризовать следующей семантикой:

□ Один и только один раз. Данного поведения (в некоторых случаях наиболее желательного) трудно требовать ввиду возможных аварий сервера.

□ Максимум раз. Это означает, что процедура либо вообще не была выполнена, либо была выполнена только один раз. Подобное утверждение можно сделать при получении ошибки вместо нормального отклика.

□ Хотя бы раз. Процедура наверняка была выполнена один раз, но возможно и больше. Для нормальной работы в такой ситуации удаленная процедура должна обладать свойством идемпонентности (от англ. idemponent). Этим свойством обладает процедура, многократное выполнение которой не вызывает кумулятивных изменений. Например, чтение файла идемпонентно, а добавление текста в файл — нет.

 

Представление данных

Когда клиент и сервер выполняются в одной системе на одном компьютере, проблем с несовместимостью данных не возникает. И для клиента и для сервера данные в двоичном виде представляются одинаково. В случае удаленного вызова дело осложняется тем, что клиент и сервер могут выполняться на системах с различной архитектурой, имеющих различное представление данных (например, представление значения с плавающей точкой, порядок следования байтов и т.д.)

Большинство реализаций системы RPC определяют некоторые стандартные виды представления данных, к которым должны быть преобразованы все значения, передаваемые в запросах и откликах.

Например, формат представления данных в RPC фирмы Sun Microsystems следующий:

Порядок следования байтов Старший — последний
Представление значений с плавающей точкой IEEE
Представление символа ASCII

 

Сеть

По своей функциональности система RPC занимает промежуточное место между уровнем приложения и транспортным уровнем. В соответствии с моделью этому положению соответствуют уровни представления и сеанса. Таким образом, RPC теоретически независим от реализации сети, в частности, от сетевых протоколов транспортного уровня.

Программные реализации системы, как правило, поддерживают один или два протокола. Например, система RPC разработки фирмы Sun Microsystems поддерживает передачу сообщений с использованием протоколов TCP и UDP. Выбор того или иного протокола зависит от требований приложения. Выбор протокола UDP оправдан для приложений, обладающих следующими характеристиками:

□ Вызываемые процедуры идемпонентны.

□ Размер передаваемых аргументов и возвращаемого результата меньше размера пакета UDP — 8 Кбайт.

□ Сервер обеспечивает работу с несколькими сотнями клиентов. Поскольку при работе с протоколами TCP сервер вынужден поддерживать соединение с каждым из активных клиентов, это занимает значительную часть его ресурсов. Протокол UDP в этом отношении является менее ресурсоемким.

С другой стороны, TCP обеспечивает эффективную работу приложений со следующими характеристиками:

□ Приложению требуется надежный протокол передачи

□ Вызываемые процедуры неидеипонентны

□ Размер аргументов или возвращаемого результата превышает 8 Кбайт

Выбор протокола обычно остается за клиентом, и система по-разному организует формирование и передачу сообщений. Так, при использовании протокола TCP, для которого передаваемые данные представляют собой поток байтов, необходимо отделить сообщения друг от друга. Для этого, например, применяется протокол маркировки записей, описанный в RFC1057 "RPC: Remote Procedure Call Protocol specification version 2", при котором в начале каждого сообщения помещается 32-разрядное целое число, определяющее размер сообщения в байтах.

По-разному обстоит дело и с семантикой вызова. Например, если выполняется с использованием ненадежного транспортного протокола (UDP), система выполняет повторную передачу сообщения через короткие промежутки времени (тайм-ауты). Если приложение-клиент не получает отклик, то с уверенностью можно сказать, что процедура была выполнена ноль или большее число раз. Если отклик был получен, приложение может сделать вывод, что процедура была выполнена хотя бы однажды. При использовании надежного транспортного протокола (TCP) в случае получения отклика можно сказать, что процедура была выполнена один раз. Если же отклик не получен, определенно сказать, что процедура выполнена не была, нельзя.

 

Как это работает?

По существу, собственно система RPC является встроенной в программу- клиент и программу-сервер. Отрадно, что при разработке распределенных приложений, не придется вникать в подробности протокола RPC или программировать обработку сообщений. Система предполагает существование соответствующей среды разработки, которая значительно облегчает жизнь создателям прикладного программного обеспечения. Одним из ключевых моментов в RPC является то, что разработка распределенного приложения начинается с определения интерфейса объекта — формального описания функций сервера, сделанного на специальном языке. На основании этого интерфейса затем автоматически создаются заглушки клиента и сервера. Единственное, что необходимо сделать после этого, — написать фактический код процедуры.

В качестве примера рассмотрим RPC фирмы Sun Microsystems.

Система состоит из трех основных частей:

□ rpcgen(1) — RPC-компилятор, который на основании описания интерфейса удаленной процедуры генерирует заглушки клиента и сервера в виде программ на языке С.

□ Библиотека XDR (eXternal Data Representation), которая содержит функции для преобразования различных типов данных в машинно- независимый вид, позволяющий производить обмен информацией между разнородными системами.

□ Библиотека модулей, обеспечивающих работу системы в целом.

Рассмотрим пример простейшего распределенного приложения для ведения журнала событий. Клиент при запуске вызывает удаленную процедуру записи сообщения в файл журнала удаленного компьютера.

Для этого придется создать как минимум три файла: спецификацию интерфейсов удаленных процедур log.x (на языке описания интерфейса), собственно текст удаленных процедур log.c и текст головной программы клиента main() — client.c (на языке С) .

Компилятор rcpgen(1) на основании спецификации log.x создает три файла: текст заглушек клиента и сервера на языке С (log_clnt.c и log_svc.с) и файл описаний log.h, используемый обеими заглушками.

Итак, рассмотрим исходные тексты программ.

log.x

В этом файле указываются регистрационные параметры удаленной процедуры — номера программы, версии и процедуры, а также определяется интерфейс вызова — входные аргументы и возвращаемые значения. Таким образом, определена процедура RLOG, в качестве аргумента принимающая строку (которая будет записана в журнал), а возвращаемое значение стандартно указывает на успешное или неудачное выполнение заказанной операции.

program LOG_PROG {

 version LOG_VER {

  int RLOG(string) = 1;

 } = 1;

} = 0x31234567;

Компилятор rpcgen(1) создает файл заголовков log.h, где, в частности, определены процедуры:

log.h

/*

 * Please do not edit this file.

 * It was generated using rpcgen.

 */

#ifndef _LOG_H_RPCGEN

#define _LOGH_H_RPCGEN

#include

/* Номер программы */

#define LOG_PROG ((unsigned long)(0x31234567))

#define LOG_VER  ((unsigned long)(1)) /* Номер версии */

#define RLOG     ((unsigned long)(1)) /* Номер процедуры */

extern int *rlog_1();

/* Внутренняя процедура - нам ее использовать не придется */

extern int log_prog_1_freeresult();

#endif /* !_LOG_H_RPCGEN */

Рассмотрим этот файл внимательно. Компилятор транслирует имя RLOG, определенное в файле описания интерфейса, в rlog_1, заменяя прописные символы на строчные и добавляя номер версии программы с подчеркиванием. Тип возвращаемого значения изменился с int на int*. Таково правило — RPC позволяет передавать и получать только адреса объявленных при описании интерфейса параметров. Это же правило касается и передаваемой в качестве аргумента строки. Хотя из файла print.h это не следует, на самом деле в качестве аргумента функции rlog_1() также передается адрес строки.

Помимо файла заголовков компилятор rpcgen(1) создает модули заглушки клиента и заглушки сервера. По существу, в тексте этих файлов заключен весь код удаленного вызова.

Заглушка сервера является головной программой, обрабатывающей все сетевое взаимодействие с клиентом (точнее, с его заглушкой). Для выполнения операции заглушка сервера производит локальный вызов функции, текст которой необходимо написать:

log.с

#include

#include

#include

#include "log.h"

int* rlog_1(char** arg) {

 /* Возвращаемое значение должно определяться как static */

 static int result;

 int fd; /* Файловый дескриптор журнала */

 int len;

 result = 1;

 /* Откроем файл журнала (создадим, если он не существует),

    в случае неудачи вернем код ошибки result == 1. */

 if ((fd = open("./server.log",

  O_CREAT | O_RDWR | O_APPEND)) < 0)

  return(&result);

 len = strlen(*arg);

 if (write(fd, arg, strlen(arg) != len)

  result = 1;

 else

  result = 0;

 close(fd);

 return(&result); /* Возвращаем результат — адрес result */

}

Заглушка клиента принимает аргумент, передаваемый удаленной процедуре, делает необходимые преобразования, формирует запрос на сервер portmap(1M), обменивается данными с сервером удаленной процедуры и, наконец, передает возвращаемое значение клиенту. Для клиента вызов удаленной процедуры сводится к вызову заглушки и ничем не отличается от обычного локального вызова.

client.c

#include

#include "log.h"

main(int argc, char* argv[]) {

 CLIENT *cl;

 char *server, *mystring, *clnttime;

 time_t bintime;

 int* result;

 if (argc != 2) {

  fprintf(stderr, "Формат вызова: %s Адрес_хоста\n", argv[0]);

  exit(1);

 }

 server = argv[1];

 /* Получим дескриптор клиента. В случае неудачи — сообщим

    о невозможности установления связи с сервером */

 if ((cl =

  clnt_create(server, LOG_PROG, LOG_VER, "udp")) == NULL) {

  clnt_pcreateerror(server);

  exit(2);

 }

 /* Выделим буфер для строки */

 mystring = (char*)malloc(100);

 /* Определим время события */

 bintime = time((time_t*)NULL);

 clnttime = ctime(&bintime);

 sprintf(mystring, "%s - Клиент запущен", clntime);

 /* Передадим сообщение для журнала — время начала

    работы клиента. В случае неудачи — сообщим об ошибке */

 if ((result = rlog_1(&mystring, cl)) == NULL) {

  fprintf(stderr, "error2\n");

  clnt_perror(cl, server);

  exit(3);

 }

 /* В случае неудачи на удаленном компьютере сообщим об ошибке */

 if (*result != 0)

  fprintf(stderr, "Ошибка записи в журнал\n");

 /* Освободим дескриптор */

 clnt_destroy(cl);

 exit(0);

}

Заглушка клиента log_clnt.с компилируется с модулем client.с для получения исполняемой программы клиента.

cc -o rlog client.c log_clnt.c -lns1

Заглушка сервера log_svc.с и процедура log.c компилируются для получения исполняемой программы сервера.

cc -o logger log_svc.c log.c -lns1

Теперь на некотором хосте server.nowhere.ru необходимо запустить серверный процесс:

$ logger

После чего при запуске клиента rlog на другой машине сервер добавит соответствующую запись в файл журнала.

Схема работы RPC в этом случае приведена на рис. 6.20. Модули взаимодействуют следующим образом:

1. Когда запускается серверный процесс, он создает сокет UDP и связывает любой локальный порт с этим сокетом. Далее сервер вызывает библиотечную функцию svc_register(3N) для регистрации номеров программы и ее версии. Для этого функция обращается к процессу portmap(1M) и передает требуемые значения. Сервер portmap(1M) обычно запускается при инициализации системы и связывается с некоторым общеизвестным портом. Теперь portmap(3N) знает номер порта для нашей программы и версии. Сервер же ожидает получения запроса. Заметим, что все описанные действия производятся заглушкой сервера, созданной компилятором rpcgen(1M).

2. Когда запускается программа rlog, первое, что она делает, — вызывает библиотечную функцию clnt_create(3N), указывая ей адрес удаленной системы, номера программы и версии, а также транспортный протокол. Функция направляет запрос к серверу portmap(1M) удаленной системы server.nowhere.ru и получает номер удаленного порта для сервера журнала.

3. Клиент вызывает процедуру rlog_1(), определенную в заглушке клиента, и передает управление заглушке. Та, в свою очередь, формирует запрос (преобразуя аргументы в формат XDR) в виде пакета UDP и направляет его на удаленный порт, полученный от сервера portmap(1M). Затем она некоторое время ожидает отклика и в случае неполучения повторно отправляет запрос. При благоприятных обстоятельствах запрос принимается сервером logger (модулем заглушки сервера). Заглушка определяет, какая именно функция была вызвана (по номеру процедуры), и вызывает функцию rlog_1() модуля log.c. После возврата управления обратно в заглушку преобразует возвращенное функцией rlog_1() значение в формат XDR, и формирует отклик также в виде пакета UDP. После получения отклика заглушка клиента извлекает возвращенное значение, преобразует его и возвращает в головную программу клиента.

Рис. 6.20. Работа системы RPC

 

Поддержка сети в BSD UNIX

 

Перейдем теперь к обсуждению внутренней архитектуры сетевого в UNIX. Разговор начнем с ветви UNIX, в которой реализация TCP/IP появилась впервые — BSD UNIX.

Сетевая подсистема UNIX может быть представлена состоящей из трех уровней, каждый из которых отвечает за выполнение определенных функций:

Транспортный уровень Обмен данными между процессами
Сетевой уровень Маршрутизация сообщений
Уровень сетевого интерфейса Передача данных по физической сети

Два верхних уровня представляют собой модули коммуникационных протоколов, а нижний уровень по существу является драйвером устройства. Легко заметить, что представленные уровни соответствуют транспортному, сетевому уровням и уровню канала данных модели OSI.

Транспортный уровень является самым верхним в системе и призван обеспечить необходимую адресацию и требуемые характеристики передачи данных, определенных коммуникационным узлом процесса, которым является сокет. Например, сокет потока предполагает надежную последовательную доставку данных, и в семействе TCP/IP модуль данного уровня реализует протокол TCP. Следующий, сетевой, уровень обеспечивает передачу данных, адресованных удаленному сетевому или транспортному модулю. Для этого модуль данного уровня должен иметь доступ к информации о маршрутах сети (таблице маршрутизации). Наконец, последний уровень отвечает за передачу данных хостам, подключенным к одной физической среде передачи (например, находящимся в одном сегменте Ethernet).

Внутренняя структура сетевой подсистемы изолирована от непосредственного доступа прикладных процессов. Единым (и единственным) интерфейсом доступа к сетевым услугам является интерфейс сокетов, рассмотренный в главе 3 в разделе "Межпроцессное взаимодействие в BSD UNIX. Сокеты". Для обеспечения возможности работы с конкретным коммуникационным протоколом соответствующий модуль экспортирует интерфейсу сокетов функцию пользовательского запроса. При этом данные от прикладного процесса передаются от интерфейса сокетов требуемым транспортным модулям с помощью соответствующих вызовов экспортированных функций. И наоборот, данные, полученные из сети, проходят обработку в соответствующих модулях протоколов и помещаются в очередь приема сокета-адресата.

Движение данных вниз (т.е. от верхних уровней к нижним) обычно инициируется системными вызовами и может иметь синхронный характер. Принимаемые данные из сети поступают в случайные моменты времени и передаются сетевым драйвером в очередь приема соответствующего протокола. При этом функции модуля протокола и обработка данных не вызываются непосредственно сетевым драйвером. Вместо этого последний устанавливает бит соответствующего программного прерывания, в контексте которого система позднее и запускает необходимые функции. Если данные предназначены протоколу верхнего уровня (транспортному), его функция обработки будет вызвана непосредственно модулем сетевого уровня. Если же сообщение предназначено другому хосту, и система выполняет функции шлюза, сообщение будет передано уровню сетевого интерфейса для последующей передачи.

Прежде чем более подробно ознакомиться со взаимодействием различных модулей сетевой подсистемы BSD UNIX, рассмотрим сначала структуры данных, определяющие сокет, коммуникационный протокол и сетевой интерфейс.

 

Структуры данных

 

Структура данных socket, описывающая сокет, представлена на рис. 6.21. В этой структуре хранится информация о типе сокета (so_type), его текущем состоянии (so_state) и используемом протоколе (so_proto).

Рис. 6.21. Структуры данных сокета

Сокет является коммуникационным узлом и обеспечивает буферизацию получаемых и отправляемых данных. Как только данные попадают в распоряжение сокета в результате системного вызова (например, write(2) или send(2)), сокет немедленно передает их модулю протокола для последующего отправления. Данные передаются в виде связанного списка специальных буферов mbuf, структура которых также показана на рис. 6.21. Модуль протокола может ожидать подтверждения получения отправленных данных или отложить их отправку. В обоих случаях сообщения остаются в буфере передачи сокета до момента окончательной отправки или получения подтверждения. Аналогично, данные, полученные из сети, в конечном итоге буферизуются в приемной очереди сокета-адресата, пока не будут извлечены оттуда системным вызовом (например, read(2) или recv(2)).

Для избежания переполнения буфер (структура sockbuf) хранит параметр sb_hiwat — значение верхней ватерлинии. Модуль коммуникационного протокола может использовать это значение для управления потоком данных. Например, модуль TCP устанавливает максимальное значение окна приема равным этому параметру.

Сокеты, используемые для приема и обработки запросов на установление связи (зарегистрированные с помощью системного вызова listen(2)), адресуют два связанных списка: список сокетов, связь для которых не полностью установлена, и список сокетов, обеспечивающих доступ к созданным каналам передачи данных.

Следующая структура данных, которую мы рассмотрим, относится к коммуникационным протоколам. Каждый модуль протокола представляет собой набор функций обработки и структур данных и описывается структурой данных, называемой коммутатором протокола. Коммутатор протокола хранит адреса стандартных функций протокола, например, функций ввода (pr_input()) и вывода (pr_output()), и выполняет ту же роль, что и элемент коммутатора устройств, рассмотренный в главе 5. Поле so_proto сокета содержит адрес этой структуры для соответствующего протокола. Вид коммутатора протокола показан на рис. 6.22.

Рис. 6.22. Коммутатор протокола

Перед первым использованием модуля вызывается функция его инициализации pr_init(). После этого система будет вызывать функции таймера модуля протокола pr_fasttimo() каждые 200 миллисекунд и pr_slowtimo() каждые 500 миллисекунд, если протокол определил эти функции. Например, модуль протокола TCP использует функции таймера для обработки тайм-аутов при установлении связи и повторных передачах. Функция pr_drain() вызывается системой при недостатке свободной памяти и позволяет модулю уничтожить некритичные сообщения для освобождения места.

С помощью функции pr_usrreq() модулю протокола передаются сообщения от прикладного процесса. Таким образом, эта функция определяет интерфейс взаимодействия между сокетом и протоколом нижнего уровня. Одним из параметров этой функции является номер запроса, зависящий от произведенного системного вызова. Интерфейс взаимодействия сокета с прикладными процессами является стандартным интерфейсом системных вызовов и преобразует вызовы bind(2), listen(2), send(2), sendto(2) и т.д. в соответствующие запросы функции pr_usrreq(). Некоторые из них приведены в табл. 6.7.

Таблица 6.7. Запросы функции pr_usrreq()

Системный вызов Значение Запрос
close(2) Прекратить обмен данными PRU_ABORT
accept(2) Обработать запрос на установление связи PRU_ACCEPT
bind(2) Связать сокет с адресом PRU_BIND
connect(2) Установить связь PRU_CONNECT
listen(2) Разрешить обслуживание запросов PRU_LISTEN
send(2) , sendto(2) Отправить данные PRU_SEND
fstat(2) Определить состояние сокета PRU_SENSE
getsockname(2) Получить адрес локального сокета PRU_SOCKADDR
getpeername(2) Получить адрес удаленного сокета PRU_PEERADDR
ioctl(2) Передать команду модулю протокола PRU_CONTROL

Функции pr_input() и pr_output() определяют интерфейс взаимодействия протокол-протокол и служат для передачи данных между модулями соседних уровней. Аналогично для обмена управляющими командами между модулями протоколов используются функции pr_ctlinput() и pr_ctloutput(). Цепочка взаимодействующих протоколов производит размещение и освобождение памяти при обмене сообщениями, которые передаются посредством рассмотренных структур mbuf: при передаче сообщений от сети прикладному процессу за освобождение буферов mbuf отвечает модуль верхнего уровня и наоборот, при передаче сообщений в сеть память, занимаемая сообщением, освобождается на самом нижнем уровне.

Поле pr_flags определяет некоторые характеристики протокола и режим его функционирования, которые в основном относятся к уровню сокетов. Например, протоколы, предусматривающие предварительное установление связи, указывают это с помощью флага PR_CONNREQUIRED, не позволяя тем самым функциям сокета передавать данные модулю до создания виртуального канала. Если установлен флаг PR_WANTRCVD, соответствующие функции сокета будут уведомлять модуль протокола, когда прикладной процесс получает данные из буфера приема. Это может служить сигналом протоколу для отправления подтверждения о получении, а также для обновления значения окна в соответствии с освободившимся местом.

Заметим, что каждый модуль протокола имеет собственные очереди сообщений, используемые для приема и передачи данных.

Каждый сетевой интерфейс системы представлен структурой данных, показанной на рис. 6.23. Сетевой интерфейс обычно связан с соответствующим сетевым адаптером, хотя это не является обязательным условием. Например, внутренний сетевой интерфейс loopback представляет собой псевдоустройство, используемое для унифицированного взаимодействия сетевых процессов в рамках одного хоста, отладки и т.п.

Рис. 6.23. Сетевой интерфейс

Решение об использовании того или иного сетевого интерфейса для передачи сообщения базируется на таблице маршрутизации и производится модулем сетевого уровня. Интерфейс может обслуживать протоколы различных коммуникационных доменов. Соответственно, один и тот же интерфейс может иметь несколько адресов, определенных для каждого семейства протоколов. Структуры, определяющие локальный и широковещательный (broadcast) адреса интерфейса, а также сетевую маску, хранятся в виде связанного списка.

Каждый сетевой интерфейс имеет очередь, в которую помещаются сообщения для последующей передачи, выполняемой функцией if_output(). Интерфейс также может определить процедуры инициализации if_init(), сброса if_reset() и обработки таймера if_watchdog(). Последняя может использоваться для управления потенциально ненадежными устройствами или для периодического сбора статистики устройства.

Состояние интерфейса характеризуется флагами, хранящимися в поле if_flags. Возможные флаги приведены в табл. 6.8.

Таблица 6.8. Состояния интерфейса

Флаг Значение
IFF_UP Интерфейс доступен для использования
IFF_BROADCAST Интерфейс поддерживает широковещательные адреса
IFF_MULTICAST Интерфейс поддерживает групповые адреса
IFF_DEBUG Интерфейс обеспечивает возможность отладки
IFF_LOOPBACK Программный внутренний интерфейс
IFF_POINTOPOINT Интерфейс для канала точка-точка
IFF RUNNING Ресурсы интерфейса успешно размещены
IFF_NOARP Интерфейс не использует протокол трансляции адреса

Флаг IFF_UP свидетельствует о готовности интерфейса передавать сообщения. Если сетевой интерфейс подключен к физической сети, поддерживающей широковещательную адресацию (broadcast), например, Ethernet, для интерфейса будет установлен флаг IFF_BROADCAST и определен широковещательный адрес (поле ifa_broadaddr структуры адресов ifaddr для соответствующего коммуникационного домена). Если же интерфейс используется для канала точка-точка, будет установлен флаг IFF_POINTOPOINT и определен адрес хоста (интерфейса), расположенного на противоположном конце (поле ifa_dstaddr). Заметим, что эти два флага являются взаимоисключающими, a ifa_broadaddr и ifa_dstaddr являются различными именами одного и того же поля. Интерфейс устанавливает флаг IFF_RUNNING после размещения необходимых структур данных и отправления начального запроса на чтение устройству (например, сетевому адаптеру), с которым он ассоциирован.

Состояние интерфейса и ряд других параметров можно просмотреть с помощью команды ifconfig(1M):

$ ifconfig le0

le0: flags=863 mtu 1500

 inet 194.85.160.50 netmask: ffffff00 broadcast 194.85.160.255

Легко заметить, что команда выводит значение следующих полей структуры ifnet для интерфейса le0 (if_name): if_flags, if_mtu (Maximum Transmission Unit, MTU) определяющее максимальный размер пакета, который может быть передан по физической сети, а также значения полей структуры ifaddr: адрес интерфейса inet (ifa_addr), маску netmask (ifa_netmask) и широковещательный адрес broadcast (ifa_broadaddr).

Интерфейс хранит статистическую информацию, которая может быть использована при мониторинге сети. В частности, эта информация включает число полученных пакетов уровня канала (if_ipackets), количество ошибок при приеме (if_ierrors), число отправленных пакетов уровня канала (if_opackets), количество ошибок при передаче (if_oerrors) и число коллизий (if_collisions). Команда netstat(1M) позволяет получить эту информацию для сконфигурированных интерфейсов в системе:

$ netstat -in

Name  Mtu Net/Dest     Address         Ipkts Ierrs  Opkts Oerrs Collis

lo0   823 127.0.0.0    127.0.0.1      168761     0 168761     0      0

le0  1500 194.85.160.0 194.85.160.50 1624636  1042 110166  1933 382604

 

Маршрутизация

Сетевая подсистема предназначена для работы в коммуникационной среде, представляющей собой набор сетевых сегментов, связанных между собой. Связь между отдельными сегментами достигается путем подключения их к хостам, имеющим несколько различных сетевых интерфейсов, как показано на рис. 6.24. Такие хосты при необходимости выполняют передачу данных от одного сегмента к другому (forwarding). Для сетей пакетной коммутации, о которых идет речь, выполнение этой задачи непосредственно связано с выбором маршрута прохождения пакетов данных (routing). Для этого система хранит таблицы маршрутизации, которые используются протоколами сетевого уровня (например, IP) для выбора требуемого интерфейса для передачи пакета адресату.

Рис. 6.24. Коммуникационная среда UNIX (internetwork)

Маршрутизационная информация хранится в виде двух таблиц, одна из которых предназначена для маршрутов к хостам, а другая — для маршрутов к сетям. Такой подход позволяет использовать универсальные механизмы определения маршрута как для сетей с разделяемой средой передачи (например, Ethernet), так и для сетей с каналами типа точка-точка. Например, для доставки пакета удаленному хосту, подключенному к сети первого типа, достаточно знать адрес этой сети, в то время как для каналов точка-точка необходимо явно задать адрес интерфейса противоположного конца канала.

При определении маршрута модуль сетевого протокола (IP) сначала просматривает элементы таблицы для хостов, а затем для сетей. Если оба поиска не дают результата, используется маршрут по умолчанию (если такой установлен), определенный как маршрут в сеть с адресом 0. Обычно используется первый найденный маршрут. Таким образом, порядок поиска обеспечивает приоритетность маршрутов к хостам по отношению к маршрутам к сетям, что естественно, поскольку первые представлены более конкретными адресами.

Каждый элемент таблицы маршрутизации, показанный на рис. 6.25, содержит адрес получателя (это может быть адрес сети получателя или адрес конкретного хоста). Это значение хранится в поле rt_dst. Следующее поле, rt_gateway, определяет следующий шлюз, которому необходимо направить пакет, чтобы последний в конечном итоге достиг адресата. Поле rt_flags определяет тип маршрута (к хосту или к сети), а также его состояние. В поле rt_use хранится число переданных по данному маршруту пакетов, a rt_refcnt определяет использование маршрута сетевыми процессами (виртуальными каналами). Наконец, поле rt_ifp адресует сетевой интерфейс, которому необходимо направить пакет для дальнейшей передачи по данному маршруту.

Рис. 6.25. Элемент таблицы маршрутизации

Различают не только маршруты к хостам и сетям, но также маршруты прямые (direct) и косвенные (indirect). Первое различие определяет критерий сравнения адреса получателя пакета с полем rt_dst элемента таблицы маршрутизации. Если маршрут к сети, то сравнивается только сетевая часть адреса, в противном случае требуется полное совпадение адресов.

Определение маршрута как прямого или косвенного зависит от того, имеется ли непосредственная связь между получателем, указанным в поле rt_dst, и сетевым интерфейсом, обслуживающим данный маршрут. Например, маршрут в сеть, непосредственно подключенную к сетевому интерфейсу, является прямым. Напротив, маршрут по умолчанию является косвенным маршрутом, поскольку всегда адресует получателя, расположенного вне непосредственно доступных сетевых сегментов. Эта информация необходима при формировании кадра уровня канала данных. Если пакет адресован хосту или сети, которые непосредственно не подключены к сетевому интерфейсу, то, хотя сетевой адрес этого пакета будет равен сетевому адресу фактического получателя данных, заголовок уровня канала данных будет адресовать соседний шлюз, используемый для дальнейшей передачи пакета. Если пакет не выходит за пределы непосредственно подключенной сети, адреса и сетевого уровня и уровня канала будут совпадать с соответствующими адресами фактического получателя.

Данный аспект проиллюстрирован на рис. 6.26. Здесь мы рассмотрели процесс передачи IP-датаграммы хосту, расположенному в удаленном сетевом сегменте Ethernet. Поскольку доставка датаграммы предполагает использование промежуточного шлюза, передача данных на канальном уровне требует соответствующей адресации: на первом "перегоне" в качестве адреса получателя используется МАС-адрес шлюза, и только затем — МАС-адрес фактического адресата.

Рис. 6.26. Инкапсуляция пакетов для косвенных маршрутов

На то, что маршрут является косвенным, указывает флаг RTF_GATEWAY элемента таблицы маршрутов. В этом случае MAC-адрес получателя при формировании кадра канального уровня, будет определяться исходя из сетевого адреса шлюза, хранящегося в поле rt_gateway.

Модуль протокола имеет возможность доступа к маршрутизационной информации с помощью трех функций: rtalloc() для получения маршрута, rtfree() для его освобождения и rtredirect() для обработки управляющих сообщений о перенаправлении маршрута (ICMP REDIRECT).

Функция rtalloc() позволяет модулю протокола определить маршрут к требуемому адресату. В результате модуль размещает структуру route, имеющую следующие поля:

struct rtentry *ro_rt Указатель на соответствующий элемент таблицы маршрутизации
struct sockaddr ro_dst Адрес получателя данных

Возвращаемый функцией rtalloc() маршрут может быть освобожден с помощью функции rtfree() (это не означает, что маршрут будет удален из таблицы маршрутизации). Время жизни маршрута зависит от протокола верхнего уровня. Например, модуль протокола TCP хранит маршрут на протяжении жизни виртуального канала.

Функция rtredirect() обычно вызывается модулем протокола в ответ на получение от соседних шлюзов управляющих сообщений о перенаправлении маршрута. Шлюз генерирует такое сообщение в случае, когда обнаружен более предпочтительный маршрут для передаваемого пакета. Например, если хосты А и В находятся в одной и той же сети, и хост А направляет пакеты В через шлюз С, последний отправит А сообщение о перенаправлении маршрута, информирующее, что А в дальнейшем должен посылать данные В непосредственно. Этот процесс показан на рис. 6.27.