Лекции 2010-го года (1130544), страница 76
Текст из файла (страница 76)
Для генерациипоследовательных номеров сегментов используют механизм логических часов.ТСР-соединение, как уже говорилось, - дуплексное, т.е. в каждом направлении данныепередаются независимо и соединение разрывается независимо по каждому направлению.Поэтому лучше всего представлять его как два симплексных соединения. Если вочередном сегменте флаг FIN=1, то в этом направлении данных больше не будет.
Приполучении подтверждения для этого сегмента соединение в этом направлении считаетсяразорванным. В другом направлении передача может продолжаться сколь угодно долго.Если подтверждения на первый FIN нет в течение двух интервалов жизни пакетов, то поtime-out соединение считается разорванным. Противоположная сторона также поистечении этого периода времени узнает, что никто от нее не ждет ответа. В таблице 6-18и на рисунке 6-19 представлена процедура установления и разрыва соединения в видедиаграммы конечного автомата.Таблица 6-18.
Состояния, используемые в конечном автомате управления TCPсоединениямиСостояниеОписаниеCLOSEDНет активных или ожидающих соединенийLISTENСервер ожидает входящего вызоваSYN RCVDЗапрос на соединение доставлен; ожидание подтвержденияSYN SENTПриложение открывает соединениеESTABLISHED Состояние нормальной передачи данныхFIN WAIT 1Приложение сообщило об окончании работыFIN WAIT 2Другая сторона согласилась разорвать соединениеTIMED WAITОжидание, пока все пакеты прекратят свое существованиеCLOSINGПопытка обоих сторон одновременно закрыть соединениеCLOSE WAITПротивоположная сторона инициировала разрывLAST ACKОжидание, пока все пакеты прекратят свое существованиеРисунок 6-19.
Конечный автомат управления TCP-соединениями6.3.5. Стратегия передачи в TCPУправление окнами в протоколе ТСР, как в управлении потоком на канальном уровне, несвязано прямо с поступлением подтверждений. Предположим, что у получателя естьбуферы в 4096 байт, как показано на рисунке 6-20. Если отправитель послал сегмент в2048 байт, то получатель, получив и подтвердив этот сегмент, будет показывать окно в2048 байт до тех пор, пока приложение не возьмет часть данных из полученного сегментав 2048 байт.
Отправитель посылает следующие 2048 байт. Теперь размер окна равен 0байт.Рисунок 6-20. Управление окнами в TCPКогда поле WIN=0, отправитель может послать сегмент в двух случаях. Первый - если этоданные URGENT. Например, когда требуется убить процесс на удаленной машине.Второй - если это однобайтовый сегмент. Это может потребоваться, чтобы заставитьполучателя показать текущее состояние буфера, что очень важно, так как позволяетобойти тупик.Заметим, что протокол ТСР не требует от агента-отправителя сразу передавать сегмент,как только данные поступили от приложения. Эту свободу ТСР использует, чтобыповысить свою производительность.
Рассмотрим, к примеру, удаленный редакторTELNET. Если передавать по сети каждое движение пользователя мышкой или нажатиеим клавиши на клавиатуре, то обмен будет очень не эффективным. На передачу одногосимвола будет приходиться передача сегмента в 160 байт. Поэтому часто при реализациипротокола ТСР вводят специальную задержку на посылку подтверждения и состоянияокна, чтобы дать отправителю накопить буфер для отправки.
Другую стратегиюпредложил Нагл (Nagle) – если работа идет с приложением, которое генерируетоднобайтные сообщения, то надо первый байт послать, а все остальные буферизовать дотех пор, пока не придет подтверждение на посланный байт. Все буферизованные байтынужно послать одним сегментом, после чего буферизовать все байты, пока не придетподтверждение на посланный сегмент.Алгоритм Нагла работает хорошо.
Однако есть приложения, где его следует отключить, –X-Windows. Здесь перемещения мыши по экрану надо пересылать сразу без буферизации.Другая проблема, которая может существенно понизить производительность протоколаТСР – т.н. «синдром дурацкого окна» (рисунок 6-21). Он возникает, когда приложение настороне отправителя передает ТСР-агенту данные большими блоками, а приложение настороне получателя читает данные побайтно! В этой ситуации может произойтиследующее.
Буфер на стороне получателя полон и отправитель знает об этом.Приложение-получатель считывает один байт из буфера. ТСР-агент получателя радостношлет сообщение о доступном буфере в один байт. Отправитель обязан послать один байт.После чего буфер получателя опять полон, и т.д.Кларк предложил запретить сообщать получателю в таких случаях об освободившемсяместе на один байт. Получателя принуждают ждать, пока либо не освободится размер,равный максимальной длине сегмента, объявленной при установлении соединения, либоне освободится половина буфера. Отправитель также должен стараться избегатькрохотных сегментов, а посылать большие.У ТСР-агента получателя также есть средства улучшить производительность соединения.Например, можно запретить приложению использовать примитив READ до тех пор, покау агента есть данные в буфере.
Конечно, такое решение увеличит время отклика, но длянеинтерактивных приложений это не страшно.Другая проблема для получателя, понижающая производительность соединения, нарушение порядка поступления сегментов. Например, если поступили сегменты 0, 1, 2, 4,5, 6, 7, получатель может подтвердить сегменты 0-2, забуферизовать сегменты 4-7.
Тогдаотправитель по time-out перешлет сегмент 3, после чего получатель подтвердит 4-7сегменты.Рисунок 6-21. «Синдром дурацкого окна»6.3.6. Управление перегрузками в TCPЗдесь мы рассмотрим, как протокол ТСР борется с перегрузками. В основе всех методовлежит принцип сохранения количества пакетов: не посылать новый, пока старый непокинет сеть, т.е. не будет доставлен.
Основная идея очень проста - при возникновенииперегрузки не посылать новых пакетов. В протоколе ТСР это реализуется динамически спомощью механизма окон.Прежде всего, протокол ТСР обнаруживает перегрузку по росту числа time_out. Если этавеличина превышает некоторый предел, являющийся параметром протокола, то этофиксируется как перегрузка.
Причин может быть две – шум в канале и сброс пакетовмаршрутизатором. Различить их сложно. В наши дни каналы достаточно надежные, такчто актуальной остается вторая причина.На рисунке 6-22 дана иллюстрация перегрузок. Перегрузки возникают по двум причинам:нехватка буфера на стороне получателя – недостаточная емкость получателя (а);перегрузка внутри сети – недостаточная емкость сети (b).Рисунок 6-22. Причины перегрузокВ Internet эти ситуации различаются как внутренняя емкость сети и емкость получателя.Поэтому каждый отправитель поддерживает два окна - обычное окно отправителя и окноперегрузки. Каждое показывает количество байтов, которое отправитель может послать.Фактически отправляемое количество байтов - минимум из этих двух величин.Сначала окно перегрузки полагают равным размеру максимального сегмента для данногосоединения.
Если сегмент успешно (без time_out) был передан, то окно перегрузкиувеличивается вдвое. Это увеличение будет происходить до тех пор, пока либо ненаступит time_out и произойдет возврат к предыдущему значению, либо размер окнаперегрузки не достигнет размера окна получателя. Этот алгоритм называется slow start медленный старт.Другой параметр управления перегрузками в Internet – порог (threshold). Алгоритммедленного старта при возникновении перегрузки устанавливает этот параметр равнымполовине длины окна перегрузки, а окно перегрузки - равным размеру максимальногосегмента. Окно перегрузки растет экспоненциально до тех пор, пока не сравняется спорогом, после чего оно растет линейно, пока не достигнет размера окна получателя. Наэтом рост прекращается до первой перегрузки.
Работа этого алгоритма показана нарисунке 6-23.Рисунок 6-23. Алгоритм управления перегрузками в internet6.3.7. Управление таймером в TCPПротокол ТСР использует несколько таймеров для управления передачей. Наиболееважный из них - таймер повторной передачи. Этот таймер устанавливают, когдаотправляют сегмент. (Напомним, что так мы называем TPDU-пакет.) Если подтверждениепришло до исчерпания этого таймера, то его останавливают и сбрасывают. Если таймерисчерпан, то сегмент посылают повторно.Здесь основная проблема - как удачно выбрать величину time_out: временной интервал, поистечении которого сегмент надо передать повторно.
Как мы знаем, эта проблемавстречается и на других уровнях. Однако на транспортном уровне она имеет особенность,которая заключается в следующем. На канальном уровне дисперсия величины задержкиподтверждения имеет ярко выраженный максимум (см. рисунок 6-24 (a)). Другимисловами, ее разброс невелик.
Величину time_out на этом уровне устанавливают чутьбольше ожидаемой величины прихода подтверждения. На транспортном уровне функцияраспределения величины задержки подтверждения носит более гладкий характер, чем наканальном уровне (см. рисунок 6-24 (b)). Поэтому предсказать величину времени, котораянужна для передачи данных от источника до получателя и передачи подтверждения отполучателя до источника, очень трудно.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
