Демультиплексирования на транспортном уровне
В этом разделе мы рассмотрим операции мультиплексирования и демультиплексирования на транспортном уровне, «продолжающие» соединение между оконечными системами до уровня соединения между процессами. Для того чтобы конкретизировать обсуждение, мы будем рассматривать службу мультиплексирования и демультиплексирования на транспортном уровне в контексте Интернета. Тем не менее эта служба необходима во всех компьютерных сетях.
Сетевой уровень принимающей оконечной системы передает полученные сегменты транспортному уровню, а транспортный уровень передает данные, содержащиеся в сегментах, процессам, которым они предназначены. Рассмотрим простой пример.
Предположим, что вы находитесь за своим персональным компьютером и загружаете web-страницы; при этом на компьютере одновременно открыты два Telnet-сеанса и один FTP-сеанс. Таким образом, данные, поступающие из Интернета, могут быть адресованы одному из четырех процессов: FTP-процессу, HTTP-процессу, одному из двух Telnet-процессов. Протокол транспортного уровня должен определить, какому процессу предназначается каждый принятый сегмент Данных. Рассмотрим, каким образом это происходит.
Вернемся к разделам «Программирование ТСР-сокетов» и «Программирование UDP-сокетов» в главе 2. Как мы выяснили, процесс, представляющий собой часть приложения, имеет собственный сокет, или «дверь», через которую осуществляется обмен данными с другими процессами. Таким образом, как показано на рис. 3.2, транспортный уровень фактически передает данные не процессу, а сокету.
Поскольку принимающий хост может иметь несколько сокетов одновременно, каждый сокет имеет уникальный идентификатор. Формат идентификатора, как мы увидим позже, зависит от того, к какому протоколу принадлежит сокет, к TCP или к UDP.
Теперь рассмотрим, каким образом принятые сегменты транспортного уровня направляются в соответствующие сокеты. Для этой цели каждый сегмент содержит набор специальных полей. Транспортный уровень принимающего хоста анализирует содержимое этих полей, идентифицирует сокет, которому предназначен сегмент, и передает ему данные сегмента. Процедура вручения данных сокету носит название демультиплексирования. Сбор фрагментов данных, поступающих на транспортный уровень хоста-отправителя из различных сокетов, создание сегментов путем присоединения заголовка (который используется при демультиплексировании) к каждому фрагменту и передача сегментов сетевому уровню называется мультиплексированием. Транспортный уровень среднего хоста на рисунке должен демультиплексировать сегменты, поступающие от сетевого уровня в адрес процессов Vx и Р2; это достигается путем направления данных, содержащихся в сегментах, в сокеты соответствующих процессов. Кроме того, транспортный уровень среднего хоста собирает данные, поступающие из сокетов процессов P1 и Р2, формирует сегменты и передает их сетевому уровню.
Для того чтобы наглядно представить процесс демультиплексирования, обратимся к примеру с двумя семьями, приведенному в предыдущем разделе. Каждый ребенок идентифицируется своим именем. Получая от почтальона новые письма, Роберт выполняет операцию демультиплексирования, читая имя получателя и вручая письма своим братьям и сестрам. Анна выполняет операцию мультиплексирования, собирая письма от членов своей семьи и передавая их почтальону.
Узнав о роли мультиплексирования и демультиплексирования на транспортном уровне, обратимся к их практической реализации на оконечных системах. Как мы знаем, мультиплексирование на транспортном уровне требует наличия у сокетов уникальных идентификаторов, а у сегментов — специальных полей, содержащих номера сокетов, которым они предназначены. Как показано на рис. 3.3, сегменты транспортного уровня содержат поле номера порта отправителя и поле номера порта получателя (в сегментах протоколов UDP и TCP имеются также другие поля, о которых будет рассказано в следующих разделах этой главы). Номер порта представляет собой 16-разрядное число, принимающее значения от 0 до 65 535.
Номера в диапазоне от 0 до 1023 предназначены для использования в популярных протоколах прикладного уровня (таких, как HTTP и FTP, имеющих порты с номерами 80 и 21 соответственно). Список зарезервированных номеров портов приведен в документе RFC 1700, а его регулярно обновляемая версия находится в Интернете по адресу _http://www.iana.org (RFC 3232). При разработке новых приложений (примеры которых приведены в разделах «Программирование ТСР-сокетов», «Программирование UDP-сокетов» и «Разработка простого web-сервера» главы 2) необходимо присваивать им собственные номера портов.
Теперь становится ясен один из вариантов организации службы демультиплексирования: каждому сокету сопоставляется номер порта, а сегмент направляется тому сокету, чей номер совпадает со значением, содержащимся в поле номера порта получателя. Затем данные сегмента передаются через сокет соответствующему процессу. Как мы увидим, подобная схема характерна для протокола UDP; процесс мультиплексирования/демультиплексирования в протоколе TCP несколько сложнее.