|
9. Транспортный уровень:
TCP и
UDP |
||
|
9.1
Протокол
UDP Транспортные протоколы Интернета: UDP В Интернете нашли применение два основных
протокола транспортного уровня, один из которых ориентирован на соединение,
другой – нет. В следующих разделах мы изучим их. Протоколом без установления
соединения является UDP. Протокол TCP, напротив, ориентирован на соединение.
Так как UDP – это, на самом деле, просто IP с добавлением небольшого заголовка,
мы изучим сперва его. Среди набора протоколов Интернета есть
транспортный протокол без установления соединения, UDP (User
Datagram Protocol –
пользовательский дейтаграммный протокол). UDP
позволяет приложениям отправлять инкапсулированные IP-дейтаграммы без
установления соединений. UDP описан в RFC 768. С помощью протокола UDP передаются
сегменты, состоящие из 8-байтно- го
заголовка, за которым следует поле полезной нагрузки. Заголовок показан на рис.
6.18. Два номера портов служат для идентификации конечных точек внутри
отправляющей и принимающей машин. Когда прибывает пакет UDP, содержимое его
поля полезной нагрузки передается процессу, связанному с портом на-значения. Это связывание происходит при выполнении
примитива типа BIND. Это было продемонстрировано в листинге 6.1 применительно к
TCP (в UDP процесс связывания происходит точно так же). В сущности, весь смысл
использования UDP вместо обычного IP заключается как раз в указании портов
источника и приемника. Без этих двух полей на транспортном уровне невозможно
было бы определить действие, которое следует произвести с пакетом. В
соответствии с полями портов производится корректная доставка сегментов.
Информация о порте источника требуется
прежде всего при создании ответа, пересылаемого отправителю. Копируя значения
поля Порт источника из входящего сегмента в поле Порт назначения исходящего сегмента,
процесс, посылающий ответ, может указать, какому именно процессу на
противоположной стороне он предназначается. Поле Длина UDP содержит информацию о
длине сегмента, включая заголовок и полезную нагрузку. Контрольная сумма UDP не
является обязательной. Если она не подсчитывается, ее значение равно 0 (настоящая
нулевая контрольная сумма кодируется всеми единицами). Отключать функцию подсчета контрольной
суммы глупо, за исключением одного случая – когда нужна высокая
производительность (например, при передаче оцифрованной речи). Наверное, стоит прямо сказать о том, чего
UDP не делает. Итак, UDP не занимается контролем потока, контролем ошибок,
повторной передачей после приема испорченного сегмента. Все это перекладывается
на пользовательские процессы. Что же он делает? UDP предоставляет интерфейс для
IP путем демультиплексирования нескольких процессов, использующих порты. Это
все, что он делает. Для процессов, которым хочется управлять потоком,
контролировать ошибки и временные интервалы, протокол UDP – это как раз то, что
доктор прописал. Одной из областей, где UDP применяется
особенно широко, является область клиент-серверных приложений. Зачастую клиент
посылает короткий запрос серверу и надеется получить короткий ответ. Если
запрос или ответ теряется, клиент по прошествии определенного временного
интервала может попытаться еще раз. Это позволяет не только упростить код, но и
уменьшить требуемое количество сообщений по сравнению с протоколами, которым
требуется начальная настройка. DNS (Domain Name System – служба имен
доменов) – это приложение, которое использует UDP именно так, как описано
ранее. Мы изучим его в главе 7. В двух словах, если программе нужно найти
IP-адрес по имени хоста, например, www.cs.berkeley.edu, она может послать
UDP-пакет с этим именем на сервер DNS. Сервер в ответ на запрос посылает
UDP-пакет с IP-адресом хоста. Никакой предварительной настройки не требуется,
как не требуется и разрыва соединения после завершения задачи. По сети просто
передаются два сообщения.
9.3
Транспортные протоколы Интернета: TCP UDP является простым протоколом и имеет
определенную область применения. В первую очередь, это клиент-серверные
взаимодействия и мультимедиа. Тем не менее, большинству интернет-приложений
требуется надежная, последовательная передача. UDP не удовлетворяет этим
требованиям, поэтому требуется иной протокол. Такой протокол называется TCP, и
он является рабочей лошадкой Интернета. Позже мы рассмотрим его детально. Протокол TCP (Transmission
Control Protocol – протокол
управления передачей) был специально разработан для обеспечения надежного
сквозного байтового потока по ненадежной интерсети. Объединенная сеть
отличается от отдельной сети тем, что ее различные участки могут обладать
сильно различающейся топологией, пропускной способностью, значениями времени
задержки, размерами пакетов и другими параметрами. При разработке TCP основное
внимание уделялось способности протокола адаптироваться к свойствам
объединенной сети и отказоустойчивости при возникновении различных проблем. Протокол TCP описан в RFC 793. Со
временем были обнаружены различные ошибки и неточности, и по некоторым пунктам
требования были изменены. Под-робное
описание этих уточнений и исправлений дается в RFC 1122. Расширения протокола
приведены в RFC 1323. Каждая машина, поддерживающая протокол
TCP, обладает транспортной сущ-ностью
TCP, являющейся либо библиотечной процедурой, либо пользовательским процессом,
либо частью ядра системы. В любом случае, транспортная сущность управляет
TCP-потоками и интерфейсом с IP-уровнем. ТСР-сущность принимает от локальных
процессов пользовательские потоки данных, разбивает их на куски, не
превосходящие 64 Кбайт (на практике это число обычно равно 1460 байтам данных,
что позволяет поместить их в один кадр Ethernet с
заголовками IP и TCP), и посылает их в виде отдельных IP-дейтаграмм. Когда
IP-дейтаграммы с TCP-данными прибывают на машину, они передаются ТСР-сущности,
которая восстанавливает исходный байтовый поток. Для простоты мы иногда будем
употреблять «ТСР» для обозначения транспортной сущности TCP (части программного
обеспечения) или протокола TCP (набора правил). Из контекста будет понятно, что имеется в виду. Например, в выражении
«Пользователь передает данные ТСР» подразумевается, естественно, транспортная
сущность TCP. Уровень IP не гарантирует правильной
доставки дейтаграмм, поэтому именно TCP приходится следить за истекшими интервалами
ожидания и в случае необходимости заниматься повторной передачей пакетов.
Бывает, что дейтаграммы прибывают в неправильном порядке. Восстанавливать
сообщения из таких дейтаграмм обязан также TCP. Таким образом, протокол TCP
призван обеспечить надежность, о которой мечтают многие пользователи и которая
не предоставляется протоколом IP. В основе службы TCP лежат так называемые
сокеты (гнезда или конечные точки), создаваемые как отправителем, так и
получателем. Они обсуждались в разделе «Сокеты Беркли». У каждого сокета есть
номер (адрес), состоящий из IP-адреса хоста и 16-битного номера, локального по
отношению к хосту, называемого портом. Портом в TCP называют TSAP-адрес. Для
обращения к службе TCP между сокетом машины отправителя и сокетом машины
получателя должно быть явно установлено соединение. Примитивы сокетов приведены
в табл. 6.2 Один сокет может использоваться
одновременно для нескольких соединений. Другими словами, два и более соединений
могут оканчиваться одним сокетом. Соединения различаются по идентификаторам сокетов
на обоих концах – {socket1, socket2). Номера виртуальных каналов или другие
идентификаторы не используются. Номера портов со значениями ниже 1024,
называемые популярными портами, зарезервированы стандартными сервисами.
Например, любой процесс, же-лающий установить
соединение с хостом для передачи файла с помощью протокола FTP, может связаться
с портом 21 хоста-адресата и обратиться, таким образом, к его FTP-демону.
Список популярных портов приведен на сайте www.iana.org. Таких портов на данный
момент более 300. Некоторые из них включены в табл. 6.4. Можно было бы, конечно, связать
FTP-демона с портом 21 еще во время за-грузки, тогда
же связать демона telnet с портом 23, и т. д. Однако
если бы мы так сделали, мы бы только зря заняли память информацией о демонах,
которые, на самом деле, большую часть времени простаивают. Вместо этого обычно пользу-ются услугами одного
демона, называемого в UNIX inetd, который связывается
с несколькими портами и ожидает первое входящее соединение. Когда оно происходит,
inetd создает новый процесс, для которого вызывается
подходящий демон, обрабатывающий запрос. Таким образом, постоянно активен
только inetd, остальные вызываются только тогда,
когда для них есть работа. Inetd имеет спе-циальный конфигурационный файл,
из которого он может узнать о назначении портов. Это значит, что системный
администратор может настроить систему таким образом, чтобы с самыми
загруженными портами (например, 80) были связаны постоянные демоны, а с
остальными – inetd. Порт Протокол Использование 21 FTP Передача файлов 23 Telnet Дистанционный
вход в систему 25 SMTP Электронная почта 69 TFTP Простейший протокол передачи файлов 79 Finger Поиск
информации о пользователе 80 HTTP Мировая Паутина 110 POP-3 Удаленный доступ к электронной почте 119 NNTP Группы новостей Все TCP-соединения являются
полнодуплексными и двухточечными. Полный дуплекс означает, что трафик может
следовать одновременно в противоположные стороны. Двухточечное соединение
подразумевает, что у него имеются ровно две конечные точки. Широковещание и
многоадресная рассылка протоколом TCP не поддерживаются. TCP-соединение представляет собой
байтовый поток, а не поток сообщений. Границы между сообщениями не сохраняются.
Например, если отправляющий процесс записывает в TCP-поток четыре 512-байтовых
порции данных, эти данные могут быть доставлены получающему процессу в виде
четырех 512-байтовых порций, двух 1024-байтовых порций, одной 2048-байтовой
порции (см. рис. 6.22) или как-нибудь еще. Нет способа, которым получатель смог
бы определить, каким образом записывались данные.
Файлы в системе UNIX
также обладают этим свойством. Программа, читающая файл, не может определить,
как был записан этот файл: поблочно, побайтно или
сразу целиком. Как и в случае с файлами системы UNIX, TCP-программы не имеют
представления о назначении байтов и не интересуются этим. Байт для них – просто
байт. Получив данные от
приложения, протокол TCP может послать их сразу или поместить в буфер, чтобы
послать сразу большую порцию данных, по своему ус-мотрению. Однако иногда приложению бывает
необходимо, чтобы данные были посланы немедленно. Допустим, например, что
пользователь регистрируется на удаленной машине. После того как он ввел команду
и нажал клавишу Enter, важ-но, чтобы введенная им
строка была доставлена на удаленную машину сразу же, а не помещалась в буфер,
пока не будет введена следующая строка. Чтобы выну-дить передачу данных без промедления, приложение
может установить флаг PUSH (протолкнуть). Некоторые старые
приложения использовали флаг PUSH как разделитель сообщений. Хотя этот трюк
иногда срабатывает, не все реализации протокола TCP передают флаг PUSH
принимающему приложению. Кроме того, если прежде чем первый пакет с
установленным флагом PUSH будет передан в линию, TCP-сущность получит еще несколько
таких пакетов (то есть выходная линия будет занята), TCP-сущность будет иметь
право послать все эти данные в виде единой дейтаграммы, не разделяя их на
отдельные порции. Последней особенностью
службы TCP, о которой следует упомянуть, явля-ются
срочные данные. Когда пользователь, взаимодействующий с программой в
интерактивном режиме, нажимает клавишу Delete или Ctrl-C, чтобы прервать начавшийся удаленный процесс,
посылающее приложение помещает в выходной поток данных управляющую информацию и
передает ее TCP-службе вместе с флагом URGENT (срочно). Этот флаг заставляет
TCP-сущность прекратить накоп-ление
данных и без промедления передать в сеть все, что у нее есть для данного
соединения. Когда срочные данные
прибывают по назначению, получающее приложение прерывается (то есть «получает
сигнал», в терминологии UNIX), после чего оно может считать данные из входного
потока и найти среди них срочные. Конец срочных данных маркируется, так что
приложение может распознать, где они заканчиваются. Начало срочных данных не
маркируется. Приложение должно само догадаться. Такая схема представляет собой
грубый сигнальный механизм, оставляя все прочее приложению. В данном разделе будет рассмотрен
протокол TCP в общих чертах. В следующем разделе мы обсудим заголовок
протокола, поле за полем. Ключевым свойством TCP, определяющим всю
структуру протокола, являет-ся
то, что в TCP-соединении у каждого байта есть свой 32-разрядный порядковый
номер. В первые годы существования Интернета базовая скорость передачи данных
между маршрутизаторами по выделенным линиям составляла 56 Кбит/с. Хосту,
постоянно выдающему данные с максимальной скоростью, потребовалось бы больше
недели на то, чтобы порядковые номера совершили полный круг. При нынешних
скоростях порядковые номера могут кончиться очень быстро, об этом еще будет
сказано позже. Отдельные 32-разрядные порядковые номера исполь-зуются для подтверждений и для механизма
скользящего окна, о чем также будет сказано позже. Отправляющая и принимающая TCP-сущности
обмениваются данными в виде сегментов. Сегмент состоит из фиксированного
20-байтового заголовка (плюс необязательная часть), за которой могут следовать
байты данных. Размер сег-ментов определяется программным обеспечением TCP. Оно может
объединять в один сегмент данные, полученные в результате нескольких операций
записи, или, наоборот, распределять результат одной записи между несколькими
сегментами. Размер сегментов ограничен двумя пределами. Во-первых, каждый
сегмент, включая TCP-заголовок, должен помещаться в 65 515-байтное поле
полезной нагрузки IP-пакета. Во-вторых, в каждой сети есть максимальная единица
передачи (MTU, Maximum Transfer
Unit), и каждый сегмент должен помещаться в MTU. На
практике размер максимальной единицы передачи составляет обычно 1500 байт (что
соответствует размеру поля полезной нагрузки Ethernet),
и таким образом определяется верхний предел размера сегмента. Основным протоколом, используемым
TCP-сущностями, является протокол скользящего окна. При передаче сегмента
отправитель включает таймер. Когда сегмент прибывает в пункт назначения,
принимающая TCP-сущность посылает обратно сегмент (с данными, если есть что
посылать, или без данных) с номером подтверждения, равным порядковому номеру
следующего ожидаемого сегмента. Если время ожидания подтверждения истекает,
отправитель посылает сегмент еще раз. Хотя этот протокол кажется простым, в нем
имеется несколько деталей, которые следует рассмотреть подробнее. Сегменты
могут приходить в неверном порядке. Так, например, возможна ситуация, в которой
байты с 3072-го по 4095-й уже прибыли, но подтверждение для них не может быть
выслано, так как байты с 2048-го по 3071-й еще не получены. К тому же сегменты
могут задерживаться в сети так долго, что у отправителя истечет время ожидания
и он передаст их снова. Переданный повторно сегмент может включать в себя уже
другие диапазоны фрагментов, поэтому потребуется очень аккуратное
администрирование для определения номеров байтов, которые уже были приняты
корректно. Тем не менее, поскольку каждый байт в потоке единственным образом
определяется по своему сдвигу, эта задача оказывается реальной. Протокол TCP должен уметь справляться с
этими проблемами и решать их эффективно. На оптимизацию производительности
TCP-потоков было потрачено много сил. В следующем разделе мы обсудим несколько
алгоритмов, используемых в различных реализациях протокола TCP. На рис. 6.23 показана структура заголовка
ТСР-сегмента. Каждый сегмент начи-нается
с 20-байтного заголовка фиксированного формата. За ним могут следовать
дополнительные поля. После дополнительных полей может располагаться до 65 535 -
20 - 20 = 65 495 байт данных, где первые 20 байт – это IP-заголовок, а вторые –
TCP-заголовок. Сегменты могут и не содержать данных. Такие сег-менты часто применяются
для передачи подтверждений и управляющих сооб-щений. Рассмотрим TCP-заголовок поле за полем.
Поля Порт получателя и Порт отправителя являются идентификаторами локальных
конечных точек соединения. Популярные номера портов перечислены на
www.iana.org, однако, что касается всех остальных портов, то каждый хост может
сам решать, как их распределять. Номер порта вместе с IP-адресом хоста образуют
уникальный 48-битный идентификатор конечной точки. Пара таких идентификаторов,
относящихся к ис-точнику и
приемнику, однозначно определяет соединение. Поля Порядковый номер и Номер
подтверждения выполняют свою обычную функцию. Обратите внимание: поле Номер
подтверждения относится к следую-щему
ожидаемому байту, а не к последнему полученному. Оба они 32-разряд-
ные, так как в TCP-потоке нумеруется каждый
байт данных. Поле Длина TCP-заголовка содержит размер
TCP-заголовка, выраженный в 32-разрядных словах. Эта информация необходима, так
как поле Факультативные поля, а вместе с ним и весь заголовок, может быть
переменной длины. По сути, это поле указывает смещение от начала сегмента до
поля данных, измеренное в 32-битных словах. Это то же самое, что длина
заголовка.
Следом идет неиспользуемое 6-битное поле.
Тот факт, что это поле выжило в течение четверти века, является свидетельством
того, насколько хорошо продуман дизайн TCP. Затем следуют шесть 1-битовых флагов. Бит
URG устанавливается в 1 в слу-чае использования поля Указатель на срочные данные,
содержащего смещение в байтах от текущего порядкового номера байта до места
расположения срочных данных. Таким образом в протоколе TCP реализуются
прерывающие сообщения. Как уже упоминалось, протокол TCP лишь обеспечивает
доставку сигнала пользователя до получателя, не интересуясь причиной
прерывания. Если бит АСК установлен в 1, значит, поле
Номер подтверждения содержит осмысленные данные. В противном случае данный
сегмент не содержит подтвер-ждения,
и поле Номер подтверждения просто игнорируется. Бит PSH является, по сути, PUSH-флагом, с
помощью которого отправитель просит получателя доставить данные приложению
сразу по получении пакета, а не хранить их в буфере, пока тот не наполнится.
(Получатель может заниматься буферизацией для достижения большей
эффективности.) Бит RST используется для сброса состояния
соединения, которое из-за сбоя хоста или по другой причине попало в тупиковую
ситуацию. Кроме того, он ис-пользуется для отказа от неверного сегмента или от попытки
создать соединение. Если вы получили сегмент с установленным битом RST, это
означает наличие какой-то проблемы. Бит SYN применяется для установки
соединения. У запроса соединения бит SYN= 1, а бит АСК = О, что означает, что
поле подтверждения не используется. В ответе на этот запрос содержится
подтверждение, поэтому значения этих би тов
в нем равны: SYN= 1, АСК= 1. Таким образом, бит SYN используется для
обозначения сегментов CONNECTION REQUEST и CONNECTION ACCEPTED, а бит АСК –
чтобы отличать их друг от друга. Бит FIN используется для разрыва
соединения. Он указывает на то, что у от-правителя
больше нет данных для передачи. Однако, даже закрыв соединение, процесс может
продолжать получать данные в течение неопределенного времени. У сегментов с
битами FIN и SYN есть порядковые номера, что гарантирует правильный порядок их
выполнения. Управление потоком в протоколе TCP осуществляется
при помощи скользя-щего окна
переменного размера. Поле Размер окна сообщает, сколько байт может быть послано
после байта, получившего подтверждение. Значение поля Размер окна может быть
равно нулю, что означает, что все байты вплоть до Номер подтверждения1-1
получены, но у получателя в данный момент какие-то проблемы, и остальные байты
он пока принять не может. Разрешение на дальнейшую передачу может быть получено
путем отправки сегмента с таким же значением поля Номер подтверждения и
ненулевым значением поля Размер окна. В главе 3 мы обсуждали протоколы, в
которых подтверждения приема кадров были связаны с разрешениями на продолжение
передачи. Эта связь была следст-вием
жестко закрепленного размера скользящего окна в этих протоколах. В TCP подтверждения
отделены от разрешений на передачу данных. В сущности, при-емник может сказать: «Я получил байты вплоть до k-vo, но я сейчас не хочу про-должать прием данных». Такое
разделение (выражающееся в скользящем окне переменного размера) придает
протоколу дополнительную гибкость. Далее мы об-судим
этот аспект более детально. Поле Контрольная сумма служит для
повышения надежности. Оно содержит контрольную сумму заголовка, данных и псевдозаголовка, показанного на рис. 6.24. При выполнении
вычислений поле Контрольная сумма устанавливается равным нулю, а поле данных
дополняется нулевым байтом, если его длина представляет собой нечетное число.
Алгоритм вычисления контрольной суммы просто складывает все 16-разрядные слова
в дополнительном коде, а затем вычисляет дополнение для всей суммы. В
результате, когда получатель считает контрольную сумму всего сегмента, включая
поле Контрольная сумма, результат должен быть равен 0.
Псевдозаголовок
содержит 32-разрядные IP-адреса отправителя и получателя, номер протокола для
TCP (6) и счетчик байтов для TCP-сегмента (включая заголовок). Включение псевдозаголовка в контрольную сумму TCP помогает об-наружить неверно доставленные
пакеты, хотя это нарушает иерархию протоколов, так как IP-адреса в нем
принадлежат IP-уровню, а не TCP-уровню. В UDP для контрольной суммы
используется такой же псевдозаголовок. Поле Факультативные поля предоставляет
дополнительные возможности, не покрываемые стандартным заголовком. С помощью
одного из таких полей каж-дый
хост может указать максимальный размер поля полезной нагрузки, который он может
принять. Чем больше размер используемых сегментов, тем выше эф-фективность, так как при этом снижается удельный вес
накладных расходов в виде 20-байтных заголовков, однако не все хосты способны
принимать очень большие сегменты. Хосты могут сообщить друг другу максимальный
размер поля полезной нагрузки во время установки соединения. По умолчанию этот
размер равен 536 байтам. Все хосты обязаны принимать TCP-сегменты размером 536
+ 20 = 556 байт. Для каждого из направлений может быть установлен свой
максимальный размер поля полезной нагрузки. Для линий с большой скоростью передачи
и/или большой задержкой окно размером в 64 Кбайт оказывается слишком маленьким.
Так, для линии ТЗ (44,736 Мбит/с) полное окно может быть передано в линию всего
за 12 мс. Если значение времени распространения
сигнала в оба конца составляет 50 мс (что типично для
трансконтинентального оптического кабеля), 3/4 времени отправитель будет
заниматься ожиданием подтверждения. При связи через спутник ситуация будет еще
хуже. Больший размер окна мог бы улучшить эффективность, но 16-битовое поле
Размер окна не позволяет этого сделать. В RFC 1323 был предложен новый параметр
Масштаб окна, о значении которого два хоста могли договориться при установке
соединения. Это число позволяет сдвигать поле Размер окна до 14 разрядов влево,
обеспечивая расширение размера окна до 230 байт (1 Гбайт). В настоящее время
большинство реализаций протокола TCP поддерживают эту возможность. Еще одна возможность, предложенная в RFC
1106 и широко применяемая сейчас, состоит в использовании протокола выборочного
повтора вместо возврата на п. Если адресат получает один плохой сегмент и
следом за ним большое ко-личество
хороших, у нормального TCP-протокола в конце концов истечет время ожидания и он
передаст повторно все неподтвержденные сегменты, включая те, что были получены
правильно. В документе RFC 1106 было предложено исполь-зовать отрицательные подтверждения (NAK),
позволяющие получателю запраши-вать отдельный сегмент
или несколько сегментов. Получив его, принимающая сторона может подтвердить все
хранящиеся в буфере данные, уменьшая таким образом количество повторно
передаваемых данных. В протоколе ТСР-соединения
устанавливаются с помощью «тройного рукопожа-тия»,
описанного в разделе «Установка соединения». Чтобы установить соедине ние,
одна сторона (например, сервер) пассивно ожидает входящего соединения, выполняя
примитивы LISTEN и ACCEPT, либо указывая конкретный источник, либо не указывая
его. Другая сторона (например, клиент)
выполняет примитив CONNECT, указывая IP- адрес и порт, с которым он хочет
установить соединение, максимальный размер ТСР-сегмента и, по желанию, некоторые
данные пользователя (например, пароль). Примитив CONNECT посылает TCP-сегмент с
установленным битом SYN и сброшенным битом АСК и ждет ответа. Когда этот сегмент прибывает в пункт
назначения, TCP-сущность проверяет, выполнил ли какой-нибудь процесс примитив
LISTEN, указав в качестве параметра тот же порт, который содержится в поле Порт
получателя. Если такого процесса нет, она отвечает отправкой сегмента с
установленным битом RST для отказа от соединения.
Если какой-либо процесс прослушивает
какой-либо порт, то входящий ТСР- сегмент передается этому процессу. Последний
может принять соединение или от-казаться от него. Если
процесс принимает соединение, он отсылает в ответ под-тверждение. Последовательность TCP-сегментов,
посылаемых в нормальном случае, показана на рис. 6.25, а. Обратите внимание на
то, что сегмент с установ-ленным битом SYN занимает 1 байт пространства порядковых
номеров, что по-зволяет избежать неоднозначности в их
подтверждениях. Если два хоста одновременно попытаются
установить соединение друг с дру-гом, то последовательность происходящих при этом событий
будет соответство-вать рис. 6.25, б. В результате
будет установлено только одно соединение, а не два, так как пара конечных точек
однозначно определяет соединение. То есть если оба соединения пытаются
идентифицировать себя с помощью пары (х, у), делается всего одна табличная
запись для (х, у). Начальное значение порядкового номера
соединения не равно нулю по обсу-ждавшимся выше
причинам. Используется схема, основанная на таймере, изме-няющем свое состояние каждые 4 мкс. Для большей надежности хосту после сбоя запрещается
перезагружаться ранее чем по прошествии максимального вре-мени жизни пакета. Это позволяет гарантировать,
что ни один пакет от прежних соединений не бродит где-нибудь в Интернете. Хотя ТСР-соединения являются
полнодуплексными, чтобы понять, как происходит их разъединение, лучше считать
их парами симплексных соединений. Каждое симплексное соединение разрывается
независимо от своего напарника. Чтобы ра-зорвать
соединение, любая из сторон может послать TCP-сегмент с установлен-ным в единицу битом FIN, что означает, что у него больше
нет данных для переда-чи. Когда этот TCP-сегмент
получает подтверждение, это направление передачи закрывается. Тем не менее,
данные могут продолжать передаваться неопределенно долго в противоположном
направлении. Соединение разрывается, когда оба направления закрываются. Обычно
для разрыва соединения требуются четыре TCP-сегмента: по одному с битом FIN и
по одному с битом АСК в каждом направлении. Первый бит АСК и второй бит FIN
могут также содержаться в одном ТСР- сегменте, что уменьшит количество
сегментов до трех. Как при телефонном разговоре, когда оба
участника могут одновременно по-прощаться
и повесить трубки, оба конца ТСР-соединения могут послать FIN-cer- менты в одно и то же время. Они оба получают обычные
подтверждения, и со-единение закрывается. По сути,
между одновременным и последовательным разъединениями нет никакой разницы. Чтобы избежать проблемы двух армий,
используются таймеры. Если ответ на посланный F/iV-сегмент
не приходит в течение двух максимальных интервалов времени жизни пакета,
отправитель Д/У-сегмента разрывает соединение. Другая сторона в конце концов
заметит, что ей никто не отвечает, и также разорвет со-единение.
Хотя такое решение и не идеально, но, учитывая недостижимость иде-ала,
приходится пользоваться тем, что есть. На практике проблемы возникают довольно
редко. Транспортный уровень – это ключ к
пониманию многоуровневых протоколов. Он предоставляет различные услуги,
наиболее важной из которых является сквозной, надежный, ориентированный на
соединение поток байтов от отправителя к получателю. Доступ к нему
предоставляется при помощи сервисных примитивов, позволяющих устанавливать, использовать
и разрывать соединения. Транспортные протоколы должны обладать
способностью управлять соеди-нением
в ненадежных сетях. Установка соединения осложняется возможностью существования
дубликатов пакетов, которые могут появляться в самый неподхо-дящий момент. Для борьбы с этими дубликатами
при установке соединения применяется алгоритм «тройного рукопожатия». Разрыв
соединения проще установки и, тем не менее, далеко не тривиален из-за наличия
проблемы двух армий. Даже если сетевой уровень абсолютно надежен,
у транспортного уровня полно работы. Он должен обрабатывать все служебные
примитивы, управлять со-единениями и таймерами, а
также предоставлять и использовать кредиты. Основными транспортными протоколами
Интернета являются TCP и UDP. UDP – это протокол без установления соединения,
который работает с IP-пакетами и занимается обеспечением мультиплексирования и
демультиплексирования нескольких процессов с использованием единого IP-адреса.
UDP может ис-пользоваться при клиент-серверных взаимодействиях, например,
при удаленном вызове процедур. Кроме того, на его основе можно создавать
протоколы реаль-ного
времени, такие как RTP. Наиболее распространенным протоколом
Интернета является TCP. Он обеспе-чивает
надежную двухстороннюю потоковую байтовую передачу. Он использует 20-байтный
заголовок для всех сегментов. Сегменты могут фрагментироваться маршрутизаторами
Интернета, поэтому хосты должны уметь восстанавливать исходные сегменты из
отдельных фрагментов. Оптимизации производительности протокола TCP было уделено
много внимания. Для этого в нем применяются алгоритмы Нагля
(Nagle), Кларка (Clark),
Джекобсона (Jacobson), Карна
(Кагп) и др. Беспроводные линии связи приводят к
усложнению протокола TCP. Транзакционный TCP – это расширение традиционного
протокола TCP, предназначенное для поддержки клиент-серверного взаимодействия с
использо-ванием упрощенной
процедуры обмена пакетами. Производительность сети обычно в основном
определяется протоколом и на-кладными
расходами по обработке TPDU-модулей, причем с увеличением ско-рости
передачи данных эта ситуация ухудшается. При разработке протоколов следует
стараться минимизировать количество TPDU-модулей, количество пе-реключений контекста и время
копирования TPDU-модулей. В гигабитных сетях требуются простые протоколы. |
||
