Полный курс лекций 2009-го года (1130357), страница 75
Текст из файла (страница 75)
(а) 4 сегмента по 512 байт отправлены как отдельные IPдейтаграммы; (b) 2048 байт данных доставлены к приложению за один вызовREAD6.3.3. Заголовок сегмента в TCPЗаголовок сегмента в ТСР показан на рисунке 6-19. Максимальная длина раздела данных – 65 495байтов.§Поля Source port и Destination port указывают номера портов на стороне отправителя и получателясоответственно.§Sequence number и Acknowledgement number содержат порядковый номер ожидаемого байта иследующего ожидаемого, а не последнего полученного байта.§Поле ТСР-заголовок указывает на длину ТСР-заголовка в 32 разных словах.
Дело в том, что полеOptions (параметры) может иметь переменную длину, а вместе с ним и вся длина зголовка ТСР станетпеременной.Рисунок 6-19. Заголовок TCP§6-битное поле флагов.§Бит Urg используется вместе с полем Urgent pointer, которое указывает на начало области срочныхданных.§ACK - 1, если поле Acknowledgement number используется, в противном случае – 0.§PSH - 1, если отправитель просит транспортного агента на стороне получателя сразу передать эти данныеприложению и не буферизовать их.§RST – используется, чтобы переустановить соединение, которое по какой-либо причине сталонекорректным. Получение пакета с таким флагом означает наличие проблемы, с которой надоразбираться.§SYN – 1, при запросе на соединение. Флаг ACK указывает на наличие или отсутствие подтверждения.SYN = 1 ACK = 0 – запрос на соединение, SYN = 1 ACK = 1 – подтверждение соединения.§FIN - запрос на разрыв соединения.
У отправителя нет больше данных.§Поле Window size используется алгоритмом управления окном.§Поле Options используется для установления возможностей, не предусмотренных стандартнымзаголовком. Например, здесь часто указывается максимальный размер поля данных, допустимый поданному соединению. Это поле имеет переменную длину.Рисунок 6-20. Псевдозаголовок, включенный в контрольную сумму6.3.4.
Управление соединениями в TCPКак уже было сказано, установление ТСР-соединения происходит по протоколу трехкратногорукопожатия. Флаги SYN и ASK в заголовке сегмента используются для реализации примитивовCONNECTION REQUEST и CONNECTION ACCEPTED. Флаг RST используется для реализации примитиваREJECT. Это означает, что указанные выше примитивы вызывают посылку ТСР-пакета с установленнымсоответствующим флагом.На рисунке 6-21 (а) показаны состояния при установлении соединения.
Когда приходит запрос насоединение по определенному порту, транспортный агент проверяет, есть ли процесс, который выполнилпримитив LISTEN на этом порту. Если такой процесс есть, то ему передается управление. Если такогопроцесса нет, то в ответ идет отказ от установления соединения.Рисунок 6-21. Установление TCP-соединенияСлучай (b) показывает ситуацию, когда два хоста одновременно пытаются установить соединениемежду двумя одинаковыми сокетами (коллизия). Поскольку каждое соединение идентифицируется паройсокетов, то будет установлено только одно из соединений.Таймер для последовательных номеров сегментов тактируется с частотой 4 мксек., максимальноевремя жизни пакета - 120 сек. Напомним, что начальный номер сегментов никогда не равен нулю, посоображениям, приведенным ранее.
Для генерации последовательных номеров сегментов используютмеханизм логических часов.ТСР-соединение, как уже говорилось, - дуплексное, т.е. в каждом направлении данные передаютсянезависимо и соединение разрывается независимо по каждому направлению. Поэтому лучше всегопредставлять его как два симплексных соединения. Если в очередном сегменте флаг FIN = 1, то в этомнаправлении данных больше не будет. При получении подтверждения для этого сегмента соединение вэтом направлении считается разорванным.
В другом направлении передача может продолжаться скольугодно долго. Если подтверждения на первый FIN нет в течение двух интервалов жизни пакетов, то поtime-out соединение считается разорванным. Противоположная сторона также по истечении этого периодавремени узнает, что никто от нее не ждет ответа. В таблице 6-22 и на рисунке 6-23 представленапроцедура установления и разрыва соединения в виде диаграммы конечного автомата.Таблица 6-22. Состояния, используемые в конечном автомате управления TCPсоединениямиСостояниеОписаниеCLOSEDНет активных или ожидающих соединенийLISTENСервер ожидает входящего вызоваSYN RCVDЗапрос на соединение доставлен; ожидание подтвержденияSYN SENTПриложение открывает соединениеESTABLISHEDСостояние нормальной передачи данныхFIN WAIT 1Приложение сообщило об окончании работыFIN WAIT 2Другая сторона согласилась разорвать соединениеTIMED WAITОжидание, пока все пакеты прекратят свое существованиеCLOSINGПопытка обоих сторон одновременно закрыть соединениеCLOSE WAITПротивоположная сторона инициировала разрывLAST ACKОжидание, пока все пакеты прекратят свое существованиеРисунок 6-23.
Конечный автомат управления TCP-соединениями6.3.5. Стратегия передачи в TCPУправление окнами в протоколе ТСР, как в управлении потоком на канальном уровне, не связанопрямо с поступлением подтверждений. Предположим, что у получателя есть буферы в 4096 байт, какпоказано на рисунке 6-24. Если отправитель послал сегмент в 2048 байт, то получатель, получив иподтвердив этот сегмент, будет показывать окно в 2048 байт до тех пор, пока приложение не возьметчасть данных из полученного сегмента в 2048 байт.
Отправитель посылает следующие 2048 байт. Теперьразмер окна равен 0 байт.Рисунок 6-24. Управление окнами в TCPКогда поле WIN = 0, отправитель может послать сегмент в двух случаях. Первый - если это данныеURGENT. Например, когда требуется убить процесс на удаленной машине. Второй - если это однобайтовыйсегмент. Это может потребоваться, чтобы заставить получателя показать текущее состояние буфера, чтоочень важно, так как позволяет обойти тупик.Заметим, что протокол ТСР не требует от агента-отправителя сразу передавать сегмент, как толькоданные поступили от приложения.
Эту свободу ТСР использует, чтобы повысить свою производительность.Рассмотрим, к примеру, удаленный редактор TELNET. Если передавать по сети каждое движениепользователя мышкой или нажатие им клавиши на клавиатуре, то обмен будет очень не эффективным. Напередачу одного символа будет приходиться передача сегмента в 160 байт. Поэтому часто при реализациипротокола ТСР вводят специальную задержку на посылку подтверждения и состояния окна, чтобы датьотправителю накопить буфер для отправки. Другую стратегию предложил Нагл (Nagle) – если работа идетс приложением, которое генерирует однобайтные сообщения, то надо первый байт послать, а всеостальные буферизовать до тех пор, пока не придет подтверждение на посланный байт.
Всебуферизованные байты нужно послать одним сегментом, после чего буферизовать все байты, пока непридет подтверждение на посланный сегмент.Алгоритм Нагла работает хорошо. Однако есть приложения, где его следует отключить, – X-Windows.Здесь перемещения мыши по экрану надо пересылать сразу без буферизации.Другая проблема, которая может существенно понизить производительность протокола ТСР – т.н.«синдром дурацкого окна» (рисунок 6-25).
Он возникает, когда приложение на стороне отправителяпередает ТСР-агенту данные большими блоками, а приложение на стороне получателя читает данныепобайтно! В этой ситуации может произойти следующее. Буфер на стороне получателя полон иотправитель знает об этом. Приложение-получатель считывает один байт из буфера. ТСР-агент получателярадостно шлет сообщение о доступном буфере в один байт. Отправитель обязан послать один байт.
Послечего буфер получателя опять полон, и т.д.Кларк предложил запретить сообщать получателю в таких случаях об освободившемся месте на одинбайт. Получателя принуждают ждать, пока либо не освободится размер, равный максимальной длинесегмента, объявленной при установлении соединения, либо не освободится половина буфера. Отправительтакже должен стараться избегать крохотных сегментов, а посылать большие.У ТСР-агента получателя также есть средства улучшить производительность соединения. Например,можно запретить приложению использовать примитив READ до тех пор, пока у агента есть данные вбуфере.
Конечно, такое решение увеличит время отклика, но для неинтерактивных приложений это нестрашно.Другая проблема для получателя, понижающая производительность соединения, - нарушениепорядка поступления сегментов. Например, если поступили сегменты 0, 1, 2, 4, 5, 6, 7, получатель можетподтвердить сегменты 0-2, забуферизовать сегменты 4-7. Тогда отправитель по time-out перешлет сегмент3, после чего получатель подтвердит 4-7 сегменты.Рисунок 6-25. «Синдром дурацкого окна»6.3.6.
Управление перегрузками в TCPЗдесь мы рассмотрим, как протокол ТСР борется с перегрузками. В основе всех методов лежитпринцип сохранения количества пакетов: не посылать новый, пока старый не покинет сеть, т.е. не будетдоставлен. Основная идея очень проста - при возникновении перегрузки не посылать новых пакетов. Впротоколе ТСР это реализуется динамически с помощью механизма окон.Прежде всего, протокол ТСР обнаруживает перегрузку по росту числа time_out. Если эта величинапревышает некоторый предел, являющийся параметром протокола, то это фиксируется как перегрузка.Причин может быть две – шум в канале и сброс пакетов маршрутизатором. Различить их сложно.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
