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

Содержание 
 

     Введение                                                                                                      3

     1. Протокол доставки пользовательских дейтаграмм UDP                    5

     1.1 Зарезервированные и доступные UDP-порты                                    5

     1.2  Мультиплексирование и демультиплексирование запросов протоколом UDP                                                                                                   6

     1.3 Формат сообщений UDP                                                                      6

     1.4 Контрольное суммирование                                                                7

     2. Протокол надежной доставки сообщений TCP                                   9

     2.1 Формат сообщений TCP                                                                       9

     2.2 Порты и установление TCP-соединений                                            11

     2.3 Концепция квитирования                                                                     12

     2.4 Реализация скользящего окна в протоколе TCP                                13

     2.5 Выбор тайм-аута                                                                                   14

     Заключение                                                                                                  15

     Список  использованной литературы                                                         16                                     
 
 
 
 
 

     ВВЕДЕНИЕ 
 

     Приложение, работающее с Интернет, как правило, общается с одним из протоколов транспортного уровня TCP/IP: протоколом управления транспортировкой (TCP) или протоколом пользовательских датаграмм (UDP). Приложение строит свою работу на взаимодействии с одним из этих протоколов.

       Приложения Интернет, например программа  ftp, передающая файлы по сети, обычно использует TCP, так как он предлагает надежную потокоориентированную службу доставки. Приложения типа электронной почты часто пользуются TCP по той же самой причине. Не требующие особой надежности приложения типа tftp (протокол простой передачи файлов, trivial file transfer protocol) используют UDP. Приложения на основе протокола времени (time protocol), связывающиеся с серверами времени Интернет, могут пользоваться как тем, так и другим протоколом. Прочтя эту главу, вы будете точно знать, в каком случае может потребоваться TCP, а в каком — UDP.

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

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

       ·                   Назначение полей данных в  заголовке UDP.

       ·                   Как TCP обеспечивает надежную  доставку данных.

       ·                   Как TCP использует скользящее  окно для увеличения пропускной  способности сети.

       ·                   Как модули TCP устанавливают и заканчивают соединение.

       ·                   Как TCP использует сообщения-подтверждения. 

       ·                   Назначение полей данных в  заголовке TCP.  

       Что такое транспортный уровень? 

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

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

       Что такое порт транспортного  уровня?

       Понятие «порте» в терминологии TCP/IP очень похоже на IP-адрес компьютера. Только порт обозначает приложение, а IP-адрес — определенный компьютер  (вернее, его сетевой интерфейс). Так же как IP-датаграммы содержат адреса источника и получателя данных, транспортные протоколы хранят номера портов источника и получателя. Если вышесказанное кажется вам несколько странным, давайте рассмотрим, что нам известно об аппаратных портах нашего персонального компьютера. Может быть, вам приходилось писать программу, посылающую данные на порт компьютера. Если нет, то вспомним процесс печати через параллельный или последовательный порт. Если вам приходилось пользоваться

       модемом, концепция портов TCP/IP должна  показаться вам еще более знакомой.

     Примечание: В случае модема, компьютер принимает  и посылает данные через последовательный порт. В случае принтера, данные обыкновенно  только посылаются.

       Порты персональных компьютеров  имеют название и номер. Параллельные  порты компьютера называются LPT1 и LPT2. Последовательные — СОМ1 и COM2. В сети Интернет номера портов протоколов только нумеруются. Параллельный порт LPT1 персональных компьютеров годами использовался для печати данных. Тысячи программных продуктов знают, что печатать надо через LPT1. Точно так же порт протокола Интернет ассоциируется со вполне определенным приложением или функцией. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

     1. Протокол доставки пользовательских дейтаграмм UDP 
 

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

     1.1 Зарезервированные и доступные UDP-порты 

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

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

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

       Централизованное присвоение сервисам  номеров портов выполняется организацией Internet Assigned Numbers Authority. Эти номера затем закрепляются и опубликовываются в стандартах Internet. Например, упомянутому выше сервису удаленного доступа к файлам TFTP присвоен стандартный номер порта 69.

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

     1.2 Мультиплексирование и демультиплексирование запросов протоколом UDP 

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

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

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

     1.3 Формат сообщений UDP 

       Единица данных протокола UDP называется UDP-пакетом или пользовательской  дейтаграммой. UDP-пакет состоит из  заголовка и поля данных, в котором размещается пакет прикладного уровня. Заголовок имеет простой формат и состоит из четырех двухбайтовых полей:

     Поле source port - номер порта процесса-отправителя.

     Поле destination port - номер порта процесса-получателя.

     Поле message length - длина UDP-пакета в байтах.

     Поле checksum - контрольная сумма UDP-пакета.

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

     1.4 Контрольное суммирование 

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

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

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

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

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

     2. Протокол надежной доставки сообщений TCP 
 

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

       Протокол TCP используется в тех  случаях, когда требуется надежная  доставка сообщений. Он освобождает  прикладные процессы от необходимости  использовать таймауты и повторные передачи для обеспечения надежности. Наиболее типичными прикладными процессами, использующими TCP, являются FTP и TELNET. Кроме того, TCP используют система X-Window, rcp (remote copy - удаленное копирование) и другие "r-команды". Большие возможности TCP даются не бесплатно. Реализация TCP требует большой производительности процессора и большой пропускной способности сети. Внутренняя структура модуля TCP гораздо сложнее структуры модуля UDP.  

     2.1 Формат сообщений TCP 

       Единицей данных протокола TCP является сегмент. Информация, поступающая  к протоколу TCP в рамках логического  соединения от протоколов более  высокого уровня, рассматривается  протоколом TCP как неструктурированный  поток байт. Поступающие данные  буферизуются средствами TCP. Для передачи на сетевой уровень из буфера "вырезается" некоторая непрерывная часть данных, которая и называется сегментом. Сегменты состоят из заголовка и блока данных. Заголовок сегмента имеет следующие поля:

     Порт  источника (SOURS PORT) занимает 2 байта, идентифицирует процесс-отправитель;

     Порт  назначения (DESTINATION PORT) занимает 2 байта, идентифицирует процесс-получатель;

     Последовательный  номер (SEQUENCE NUMBER) занимает 4 байта, указывает  номер байта, который определяет смещение сегмента относительно потока отправляемых данных;

     Подтвержденный  номер (ACKNOWLEDGEMENT NUMBER) занимает 4 байта, содержит максимальный номер байта в полученном сегменте, увеличенный на единицу; именно это значение используется в качестве квитанции;

     Длина заголовка (HLEN) занимает 4 бита, указывает длину заголовка сегмента TCP, измеренную в 32-битовых словах. Длина заголовка не фиксирована и может изменяться в зависимости от значений, устанавливаемых в поле Опции;

     Резерв (RESERVED) занимает 6 битов, поле зарезервировано для последующего использования;

     Кодовые биты (CODE BITS) занимают 6 битов, содержат служебную информацию о типе данного  сегмента, задаваемую установкой в  единицу соответствующих бит  этого поля:

     URG - срочное сообщение; 

     ACK - квитанция на принятый сегмент;

     PSH - запрос на отправку сообщения  без ожидания заполнения буфера;

     RST - запрос на восстановление соединения;

     SYN - сообщение используемое для  синхронизации счетчиков переданных  данных при установлении соединения;

     FIN - признак достижения передающей стороной последнего байта в потоке передаваемых данных.

     Окно (WINDOW) занимает 2 байта, содержит объявляемое  значение размера окна в байтах;

     Контрольная сумма (CHECKSUM) занимает 2 байта, рассчитывается по сегменту;

     Указатель срочности (URGENT POINTER) занимает 2 байта, используется совместно с кодовым битом URG, указывает на конец данных, которые необходимо срочно принять, несмотря на переполнение буфера;

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

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

       В протоколе TCP предусмотрен случай, когда приложение обращается  с запросом о срочной передаче  данных (бит PSH в запросе установлен  в 1). В этом случае протокол TCP передает указанные данные  в сеть немедленно, не ожидая заполнения буфера до уровня размера сегмента. О таких данных говорят, что они передаются вне потока - out of band.

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

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

     2.2 Порты и установление TCP-соединений 

       В протоколе TCP также, как и  в UDP, для связи с прикладными  процессами используются порты.  Номера портам присваиваются  аналогичным образом: имеются  стандартные, зарезервированные номера (например, номер 21 закреплен за сервисом FTP, 23 - за telnet), а менее известные приложения пользуются произвольно выбранными локальными номерами.

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

       Соединение в протоколе TCP идентифицируется  парой полных адресов обоих  взаимодействующих процессов (оконечных  точек). Адрес каждой из оконечных  точек включает IP-адрес (номер  сети и номер компьютера) и  номер порта. Одна оконечная точка может участвовать в нескольких соединениях.

       Установление соединения выполняется  в следующей последовательности:

     При установлении соединения одна из сторон является инициатором. Она посылает запрос к протоколу TCP на открытие порта для передачи (active open).

     После открытия порта протокол TCP на стороне  процесса-инициатора посылает запрос процессу, с которым требуется  установить соединение.

     Протокол TCP на приемной стороне открывает  порт для приема данных (passive open) и возвращает квитанцию, подтверждающую прием запроса.

     Для того чтобы передача могла вестись  в обе стороны, протокол на приемной стороне также открывает порт для передачи (active port) и также передает запрос к противоположной стороне.

     Сторона-инициатор  открывает порт для приема и возвращает квитанцию.

     Соединение  считается установленным. Далее  происходит обмен данными в рамках данного соединения.  
 
 
 

     2.3 Концепция квитирования 

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

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

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

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