Р.Л. Смелянский - Компьютерные сети. Том 2. Сети в ЭВМ (1130083), страница 30
Текст из файла (страница 30)
В данном состоянии сервер находится до получения от ", ~4глиента запроса на установление соединения 2. После получения флага 8 т')Ч сервер отправляет флаг ЗУ)ччАСК :; тьпереходит в состояние 8'т')ч' КСУР 3. В состоянии 8УМ КСЧР сервер может либо отправить флаг КЗТ „';-:Иг сразу перейти обратно в состояние ИЗТЕХ, либо выполнить вызов : 1 'СдЕОВЕ, отправить флаг Г111 и перейти в состояние Е11ч 'зтА! Т1, либо '.'по получении флага АСК от клиента перейти в состояние ЕЗТАВ ! т,1ВНЕР : т 4. Разрывы соединений для клиента и сервера выполняются оди"'!";: пахово 3.3.6.
Стратегия передачи а ТСР Управление окнами в протоколе ТСГ, как и управление потоком :;;:~Фа канальном уровне, не связано прямо с поступлением подтвержде- - ~„:.'-"~уий. Предположим, что у получателя есть буферы размером 4 096 байт :-)~Если отправитель послал сегмент размером 2 048 байт, то получатель, ':,-,.1~.;";:получив и подтвердив этот сегмент, будет показывать окно размером , "-"'.;;2 048 байт до тех пор пока приложение не возьмет часть данных из ;::!;::т4олученного сегмента размером 2 048 байт. Отправитель посылает '-'!~;,"~Яедуюшие 2 048 байт. Теперь размер окна равен 0 байт -'-";;,";""" При поле %ГМ = 0 отправитель может послать сегмент в двух слу',«',:,'-,чаях: если это данные 13КОЕ)чТ (например, когда требуется «убить» 'з':,,",;,процесс на удаленной машине) или если это однобайтовый сегмент "-'-",;":!3то может потребоваться, чтобы заставить получателя показать те- .;-",~:„-',.гсущее состояние буфера, что очень важно, так как позволяет обойти ':,~',-.~~!,уник, который мог бы возникнуть в случае потери объявления о ",=«~еазмере окна 1см.
полразд. 3.2.5) "~",,!;: .Заметим, что протокол ТСР не требует от транспортного агента - -:;;,'.~3тправителя передавать сегмент сразу, как только данные поступили 1'А'-".опт приложения. Эту свободу ТСР использует, чтобы повысить свою :.'...~~производительность. Рассмотрим к примеру удаленный текстовый Ях! !~Фредактор ТЕ1 1ч'ЕТ. Если передавать по сети каждое движение поль",,:,;-':,копателя мышкой или нажатие им клавиши на клавиатуре, то обмен '.;:! ч)Улет очень неэффективным. На передачу одного символа будет при- ,~;:-'Ждиться передача сегмента размером 1бО байт.
Поэтому часто при ~-„;!:тМализации протокола ТСР вводят специальную задержку на посыл:;"'„;~':;,1ЕУ'подтверждения и состояния окна, чтобы дать отправителю нако„:,'-'Пить буфер для отправки. Другую стратегию прелложил Нагл 1041 '!:;,'- вали работа идет с приложением, которое генерирует однобайтовые ':,",Мобшения, надо первый байт послать, а все остальные буферизовать ,;:;; до тех пор пока не придет подтверждение на посланный байт.
Все : ~,буферизованные байты следует послать одним сегментом, после чего :!-' буферизовать все байты, пока не придет подтверждение на посланный '!!:Фегменз ,гглдсмеляккик ~ ~ 129 Алгоритм Нагла работает хорошо. Однако есть приложения, гле его следует отключать, например Х-Иптоотга. Здесь перемещения мыши по экрану надо пересылать сразу без буферизации. Сушественио снизить производительность протокола ТСР может также так называемый синдром дурацкого окна. Это явление возникает, когда приложение на стороне отправителя передает ТСР- агенту данные большими блоками, а приложение на стороне получателя читает данные побайтово.
В этой ситуации может произойти следующее. Буфер на стороне получателя полон, и отправитель знает об этом. Приложение-получатель считывает 1 байт из буфера. ТСР- агент получателя радостно посылает сообщение о доступном буфере размером 1 байт. Отправитель обязан послать 1 байт. После чего буфер получателя опять полон и т.д. Кларк [321 предложил запретить сообшать получателю в таких случаях об освободившемся месте размером 1 байт. Получателя принуждают ждать, пока либо не освободится место размером, равным максимальной длине сегмента„объявленной при установлении соединения, либо пока не освободится половина буфера. Отправитель . также должен стараться избегать крохотных сегментов, а посылать большие. У ТСР-агента получателя также есть средства улучшить производительность соединения.
Например, можно запретить приложению использовать примитив ВЕАО до тех пор, пока у ТСР-агента есть данные в буфере. Конечно, такое решение увеличит время отклика, но для неинтерактивных приложений это не страшно. Проблемой для получателя, понижаюшей производительность соединения, является также нарушение порядка поступления сегментов. Например, если поступили сегменты О.. 7, получатель может подтвердить сегменты 0...2 и буферизовать сегменты 4...7. Тогда отправитель по гппе-опг перешлет сегмент 3, после чего получатель подтвердит сегменты 4...7.
3.3.7. Управление перегрузками в ТСР Рассмотрим, как протокол ТСР борется с перегрузками. В основе всех методов лежит принцип сохранения числа сегментов: не посылать новый сегмент, пока старый не покинет сеть, т, е, не будет доставлен. Основная идея очень проста — при возникновении перегрузки не посылать новых сегментов.
В протоколе ТСР это реализуется динамически с помощью механизма окон. Прежде всего протокол ТСР обнаруживает перегрузку по росту числа возникновения Шпе-опп Если это значение превышает некоторый предел, являюШийся параметром протокола, фиксируется перегрузка. Причин перегрузки может быть две: шум в канале и сброс сегментов маршрутизатором, различить которые сложно. В наши дни каналы достаточно надежные, а вторая причина остается актуальной. 130 Ре лягор скорости перелачи передачи гняя яка р ,;,.;.:Ча Получатель с'мелейькои - < .-- ь емкостью Рис.
332. Иллюстрация причин перегрузок: а — недостягочняя емкость получателя; б — недостаточная емкость сети , На рис. 3.12 [191 дана иллюстрация причин перегрузок. Перегрузди возникают по двум причинам: нехватка буфера на стороне полутеля, т.е. недостаточная емкость получателя 1рис. 3.12, а); пере- узка внутри сети, т.е. недостаточная емкость сети (рис. 3.12, б). В Интернете эти случаи различают как внутреннюю емкость сети емкость получателя, поэтому каждый отправитель поддерживает 44 Тайм-аут 40 36 Порог "'-„;: 4 32 — — — — --— ,~~";:,..г .
28 '!ф.';:;:„:!" $24 Порог '"~'!,::,...6 12 0 2 4 6 8 10 12 14 16 18 20 22 24 Чисяо передач Рис. 3.! 3. Алгоритм управления перегрузками в Интернете 131 два окна: обычное окно отправителя и окно перегрузки. Каждое окно показывает число байтов, которое отправитель может послать.
Фактически отправляемое число байтов равно минимальному из этих двух значений. Сначала окно перегрузки полагают равным размеру максимального сегмента для данного соединения. Если сегмент успешно (без гппе-опг) был передан, то окно перегрузки увеличивают вдвое. Это увеличение будет происходить до тех пор, пока либо не наступит гппе-опг и произойдет возврат к предыдугцему значению, либо пока размер окна перегрузки не достигнет размера окна получателя. Этот алгоритм, называемый з!отт зтагà — медленный старт 154, 59), описан в ВЕС 3390. Кроме окна перегрузки в протоколе ТСР используют параметр, называемый порог (г)згез)зо1Й).
Алгоритм медленного старта при возникновении перегрузки устанавливает этот параметр равным половине текущей длины окна перегрузки, а окно перегрузки — не более максимального сегмента для данного соединения. Окно перегрузки растет экспоненциально до тех пор пока не сравняется с порогом, после чего оно растет линейно пока не достигнет размера окна получателя. На этом рост прекращается до первой перегрузки. Работа этого алгоритма показана на рис. 3.13, 3.3.8. Управление таймером в ТСР Протокол ТСР использует несколько таймеров для управления передачей.
Наиболее важный из них — таймер повторноа передачи. Этот таймер устанавливают, когда посылают сегмент. Если подтверждение пришло до исчерпания этого таймера, то его останавливают и сбрасывают. Если таймер исчерпан, то сегмент посылают повторно. Здесь основной проблемой является удачный выбор значения йпе-оцг для таймера повторной передачи, т.е. временного интервала, по истечении которого сегмент необходимо передать повторно.
Как мы знаем, эта проблема встречается и на других уровнях. Однако на транспортном уровне она имеет особенность, которая заключается в следующем. На канальном уровне дисперсия задержки подтверждения имеет ярко выраженный максимум. Другими словами, ее разброс невелик. Значение бше-оцг на этом уровне устанавливают чуть больше ожидаемого значения прихода подтверждения. На транспортном уровне функция распределения задержки подтверждения носит более гладкий характер„чем на канальном уровне, поэтому предсказать значение времени, которое требуется для передачи данных от источника до получателя и передачи подтверждения от получателя до источника, очень трудно.
Заведомо известно, что это значение не должно быть постоянным в силу гладкости функции распределения. 132 1'-;ь Алгоритм протокола ТСР, предложенный Якобсоном в 1988 г. [54, ::~:, 59], основывается на специальной переменной КТТ (Колод Тпр , -.;.;,!.: Типе), которая используется для вычисления оптимального значения пше-опк Это значение равно наименьшему времени подтверждения, которое вычисляется следующим образом.
При каждой передаче "';,':„!: сегмента измеряется задержка подтверждения М. Если при очередной передаче подтверждение поступило раньше, чем наступил гппе-ощ, .'.::;-,::,значение переменной КТТ немного уменьшают, а в противном слу';='~;:::.-"; чае — увеличивают по формуле чение ожидания ять отклонение 1м по формуле я случая повтор- когда поступает ждение для перовал вопрос вышью протоколов не. Эксперименгов эффективно аподтверждение тойчивости, котипа. Когда покна, отправитель енении размера оно было потельзуется таймер осыпает сообщеа буфера. нирования.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
