tanenbaum_seti_all.pages (525408), страница 166
Текст из файла (страница 166)
Борьба с перегрузкой в ТСР Когда в какую-либо сеть поступает больше данных, чем она способна обработать, в сети образуются заторы. Интернет в этом смысле не является исключением. В данном разделе мы обсудим алгоритмы, разработанные (за последние двадцать пять лет) для борьбы с перегрузкой сети. Хотя сетевой уровень также пытается бороться с перегрузкой, основной вклад в решение этой проблемы, заключающееся в снижении скорости передачи данных, осуществляется протоколом ТСР. Теоретически, с перегрузкой можно бороться с помощью принципа, заимствованного из физики, — закона сохранения пакетов. Идея состоит в том, чтобы не передавать в сеть новые пакеты, пока ее не покинут (то есть не будут доставлены) старые.
Протокол ТСР пытается достичь этой цели с помощью динамического управления размером окна. Первый шаг в борьбе с перегрузкой состоит в том, чтобы обнаружить ее. Пару десятилетий назад обнаружить перегрузку в сети было сложно. Трудно было понять, почему пакет не доставлен вовремя. Помимо возможности перегрузки сети имелась также большая вероятность потерять пакет вследствие высокого уровня помех на линии. В настоящее время потери пакетов при передаче случаются относительно редко, так как большинство междугородных линий связи являются оптоволоконными (хотя в беспроводных сетях процент пакетов, теряемых из-за помех, довольно высок).
Соответственно, большинство потерянных пакетов в Интернете вызвано заторами. Все ТСР-алгоритмы Интсрнета предполагают, что потери пакетов вызываются перегрузкой сети, и следят за тайм-аутами как за предвестниками проблем, подобно шахтерам, наблюдающим за своими канарейками.
Прежде чем перейти к обсуждению того, как ТСР реагирует на перегрузку, опишем сначала способы ее предотвращения, применяемые протоколом. При обнаружении перегрузки должен быть выбран подходящий размер окна. Получатель может указать размер окна, исходя из количества свободного места в буфере.
Если отправитель будет иметь в виду размер отведенного ему окна, переполнение буфера у получателя не сможет стать причиной проблемы, однако она все равно может возникнуть из-за перегрузки на каком-либо участке сети между отправителем и получателем. На рис, 6,29 эта проблема проиллюстрирована на примере водопровода. На рис. 6.29, а мы видим толстую трубу, ведущую к получателю с небольшой емкостью, Ло тех пор, пока отправитель не посылает воды больше, чем может поместиться в ведро, вода не будет проливаться. На рис. 6.29, 6 ограничительным фак- 624 Глава 6.
Транспортный уровень тором является ие емкость ведра, а пропускная способность сети. Если из крана в воронку вода будет литься слишком быстро, то уровень воды в воронке начнет подниматься и, в конце концов, часть воды может перелиться через край воронки. Регулирование скорости передачи 6 Получатель малой емкости ч ® Получатель большой емкос Рис. 6.29. Быстрая сеть и получатель малой емкости (в); медленная сеть и получатель большой емкости (б) Решение, применяемое в Интернете, состоит в признании существования двух потенциальных проблем: низкой пропускной способности сети и низкой емкости получателя — и в раздельном решении обеих проблем.
Для этого у кажлого отправителя есть два окна: окно, предоставленное получателем, и окно перегрузки. Размер каждого из иих соответствует количеству байтов, которое отправитель имеет право передать. Отправитель руководствуется минимальным из этих двух значений. Например, получатель говорит; «Посылайте 8 Кбайта, ио отправитель знает, что если ои пошлет более 4 Кбайт, то в сети образуется затор, поэтому ои посылает все же 4 Кбайт. Если же отправитель знает, что сеть способиа пропустить и большее количество данных, например 32 Кбайт, ои передаст столько, сколько просит получатель (то есть 8 Кбайт). При установке соединения отправитель устанавливает размер окна перегрузки Равным размеру максимального используемого в данном соединении сегмеита.
Затем ои передает один максимальный сегмент. Если подтверждение получения этого сегмента прибывает прежде, чем истекает период ожидания, к размеру окна добавляется размер сегмента, то есть размер окна перегрузки удваивается, и посылаются уже два сегмента. В ответ иа подтверждение получения каждого из сегментов производится расширение окна перегрузки иа величину одного мак- Транспортные протоколы Интернета: ТСР 6к6 симального сегмента. Допустим, размер окна равен п сегментам. Если подтверждения для всех сегментов приходят вовремя, окно увеличивается на число бай гов, соответствуюшсе и сегментам.
По сути, подтверждение каждой последовательности сегментов приводит к удвоению окна перегрузки. Этот процесс экспоненциального роста продолжается до тех пор, пока нс будет доспи нут размер окна получателя или не будет выработан признак тайм-аута, сигналнзируюший о перегрузке в сети. Например, если пакеты размером 1024, 2048 и 4096 байт дошли до получателя успешно, а в ответ иа передачу пакета размером 8192 байта подтверждение не пришло в установленный срок, окно перегрузки устанавливается равным 4096 байтам. Пока размер окна перегрузки остается равным 4096 байтам, более длинные пакеты не посылаются, независимо от размера окна, предоставляемого получателем, Этот алгоритм называется затяжным пуском, или медленным пуском. Однако он не такой уж и медленный ЦасоЬзоп, 1988).
Он экспоиснциальный. Все реализации протокола ТСР обязаны его поддерживать. Рассмотрим теперь механизм борьбы с перегрузкой, применяемый в Интернете. Помимо окон получателя и перегрузки, в качестве третьего параметра в нем используется пороговое значение, которое изначально устанавливается равным 64 Кбайт. Когда возникает ситуация тайм-аута (подтвержденис не возвращается в срок), новое значение порога устанавливается равным половине текущего размера окна перегрузки, а окно перегрузки уменьшается до размера одного максимального сегмента. Затем, так же как и в предыдущем случае, используется алгоритм затяжного пуска, позволяющий быстро обнаружить предел пропускной способности сети.
Однако на этот раз экспоненциальный рост размера окна останавливается по достижении им порогового значения, после чего окно увеличивается линейно, на один сегмент для каждой следующей передачи. В сушности, предполагается, что можно спокойно урезать вдвое размер окна перегрузки, после чего постепенно нарашивать его.
Иллюстрация работы дашюго алгоритма борьбы с перегрузкой приведена на рис. 6.30. Максимальный размер сегмента в данном примере равен 1024 байт. Сначала окно перегрузки было установлено равным 64 Кбайт, но затем произошел тайм-аут, и порог стал равным 32 Кбайт, а окно перегрузки — 1 Кбайт (перелача О).
Затем размер окна перегрузки удваивается на каждом шаге, пока не достигает порога (32 Кбайт). Начиная с этого момента, размер окна увеличивается линейно. Передача 13 оказывается несчастливой (как и положено), так как срабатывает тайм-аут. При этом пороговое значение устанавливается равным половине текущего размера окна (40 Кбайт пополам, то есть 20 Кбайт), и опять происходит затяжной пуск. После достижения порогового значения экспоненциальный рост размера окна сменяется линейным. Если тайм-аутов больше не возникает, окно перегрузки может продолжать расти до размера окна получателя. Затем рост прекратится, и размер окна останется постоянным, пока не произойдет тайм-аут или не изменится размер окна получателя. Прибытие!СМР-пакета 50%Се 00ЕкСн (гашение источника) обрабатывается таким же образом, как и тайм-аут.
Альтернативный (и более современный) подход описан в КГС 3168. 626 Глава 6. Транспортный уровень Зз зг тг 2 4 6 8 10 12 14 16 18 20 22 24 Номер передачи Рис. 6.30. Пример алгоритма борьбы с перегрузкой, применяемого е Интернете Управление таймерами в ТСР В протоколе ТСР используется много различных таймеров (по крайней мере, такова концепция). Наиболее важным из них является таймер повторной передачи.
Когда посылается сегмент, запускается таймер повторной передачи. Если подтверждение получения сегмента прибывает раньше, чем истекает период таймера, таймер останавливается. Если же, наоборот, период ожидания истечет раньше, чем прибудет подтверждение, сегмент передается еще раз (а таймер запускается снова). Соответственно возникает вопрос каким должен быть интервал времени ожидания? На транспортном уровне Интернета эта проблема оказывается значительно сложнее, чем на уровне передачи данных, описанном в главе 3. На уровне передачи данных величину ожидаемой задержки довольно легко предсказать (ее разброс невелик), поэтому таймер можно установить на момент времени чуть позднее ожидаемого прибытия подтверждения (рис. 6З1, а).
Поскольку на уровне передачи данных подтверждения редко запаздывают на больший срок (благолаРя тому, что нет заторов), отсутствие подтверждения в течение установленного временного интервала с большой вероятностью означает потерю кадра или подтверждения. Протокол ТСР вынужден работать в совершенно иных условиях.
Функция распределения плотности вероятности времени прибытия подтверждения на этом Транспортные протоколы Интернета: тСР 627 уровне выглядит значительно более полого (рис. 6.31, б). Поэтому предсказать, сколько потребуется времени для прохожления данных от отправителя до получателя и обратно, весьма непросто. Если выбрать значение интервала ожидания слишком малым (например, Т, на рис. 6.31, б), возникнут излишние повторные передачи, забивающие Интернет бесполезными пакетами. Если же установить значение этого интервала слишком большим (Т,), то из-за увеличения времени ожидания в случае потери пакета пострадает производительность. Более того, среднее значение и величина дисперсии времени прибытия подтверждений может изменяться всего за несколько секунд при возникновении и устранении перегрузки.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
