Э. Таненбаум - Компьютерные сети. (4-е издание) (DJVU) (1130092), страница 166

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 166)

Во-вторых, отправитель может послать 1-байтовый сегмент, прося получателя повторить информацию о размере окна и ожидаемом следующем байте. Стандарт ТСР явно предусматривает эту воэможность для предотвращения тупиковых ситуаций в случае потери объявления о размере окна. Отправители не обязаны передавать данные сразу, как только они приходят от приложения. Также никто не требует от получателей посылать подтверждения как можно скорее. Например, на рис, 6.27 ТСР-сущность, получив от приложения первые 2 Кбайт данных н зная, что доступный размер окна равен 4 Кбайт, была бы совершенно права, если бы просто сохранила полученные данные в буфере до тех пор, пока не прибудут еше 2 Кбайт данных, чтобы передать сразу сегмент с 4 Кбайт полезной нагрузки.

Эта свобода действий может использоваться для улучшения производительности. Рассмотрим ТЕ1ХЕТ-соединение с интерактивным редактором, реагирующим на каждое нажатие клавиши. В худшем случае, когда символ прибывает к передающей ТСР-сущности, она создает 21-байтовый ТСР-сегмент и передает его 1Р-уровню, который, в свою очередь, посылает 41-байтовую 1р-дейтаграмму. 620 Глава 6.

Транспортный уровень На принимающей стороне ТСР-сущность немедленно отвечает 40-байтовым подтверждением (20 байт ТСР-заголовка и 20 байт 1Р-заголовка). Затем, когда редактор прочитает этот байт из буфера, ТСР-сущность пошлет обновленную информацию о размере буфера, передвинув окно на 1 байт вправо. Размер этого пакета также составляет 40 байт. Наконец, когда редактор обработает этот символ, он отправляет обратно зхо, передаваемое 41-байтовым пакетом. Итого для каждого ввсденного с клавиатуры символа пересылается четыре пакета общим размером 162 байта. В условиях дефицита пропускной способности линий этот метод работы нежелателен.

Отправитель Приложение выполняет — ~ запись 2К Получатель Буфер получателя о 4К Пусто Приложение записывает — ~ еще ЗК Приложение — читает 2К Отправитель заблокирован Отправитель может послать до 2К Рис. В.27. Управление окном в ТОР Для улучшения ситуации многие реализации ТСР используют задержку подтверждений и обновлений размера окна на 500 мс в надежде получить дополнительные данные, вместе с которыми можно будет отправить подтверждение одним пакетом. Если редактор успеет выдать эхо в течение 500 мс, удаленному пользователю нужно будет выслать только один 41-байтовый пакет, таким образом, нагрузка на сеть снизится вдвое.

Транспортные протоколы Интернета: ТСР 621 Хотя такой метод задержки и снижает нагрузку на сеть, тем не менее, эффективность использования сети отправителем продолжает оставаться невысокой, так как каждый байт пересылается в отдельном 41-байтовом пакете. Метод, позволяющий повысить эффективность, известен как алгоритм Нагля (Ыа81е, 1984). Предложение Нагля звучит довольно просто; если данные поступают отправителю по одному байту, отправитель просто передает первый байт, а остальные помешает в буфер, пока не будет получено подтверждение приема первого байта. После э гого можно переслать все накопленные в буфере символы в виде одного ТСР-сегмента и снова начать буферизацию до получения подтверждения отосланных символов.

Если пользователь вводит символы быстро, а сеть медленная, то в каждом сегменте будет передаваться значительное количество символов, таким образом, нагрузка на сеть будет существенно снижена. Кроме того, этот алгоритм позволяет посылать новый пакет, даже если число символов в буфере превышает половину размера окна или максимальный размер сегмента. Алгоритм Нагля широко применяется различными реализациями протокола ТСР, однако иногда бывают ситуации, в которых его лучше отключить.

В частности, при работе приложения Х-Ъ'1пбочз в Интернете информация о перемещениях мыши пересылается на удаленный компьютер. (Х-Ъ'1пс1оч — это система управления окнами в большинстве ОС типа ПХ1Х). Если буферизировать эти данные для пакетной пересылки, курсор будет перемещаться рывками с большими паузами, в результате чего пользоваться программой будет очень сложно, почти невозможно. Еше одна проблема, способная значительно снизить производительность протокола ТСР, известна под именем синдрома глупого окна (С1агк, 1982).

Суть проблемы состоит в том, что данные пересылаются ТСР-сушностью крупными блоками, но принимающая сторона интерактивного приложения считывает их посимвольно. Чтобы ситуация стала понятнее, рассмотрим рис. 6.28. Начальное состояние таково: ТСР-буфер приемной стороны полон, и отправителю это известно (то есть размер его окна равен 0). Затем интерактивное приложение читает один символ нз ТСР-потока. Принимающая ТСР-сушность радостно сообщает отправителю, что размер окна увеличился, и что он теперь может послать 1 байт. Отправитель повинуется и посылает 1 байт. Буфер снова оказывается полон, о чем получатель и извещает, посылая подтверждение для 1-байтового сегмента с нулевым размером окна. И так может продолжаться вечно.

Дэвид Кларк (РачЫ С!агк) предложил запретить принимающей стороне отправлять информацию об однобайтовом размере окна. Вместо этого получатель должен подождать, пока в буфере не накопится значительное количество свободного места. В частности, получатель не должен отправлять сведения о новом размере окна до тех пор, пока он не сможет принять сегмент максимального размера, который он объявлял при установке соединения, или его буфер не освободился хотя бы наполовину. Кроме того, увеличению эффективности отправки может способствовать сам отправитель, отказываясь от отправки слишком маленьких сегментов.

Вместо этого он должен подождать, пока размер окна не станет достаточно большим для 622 Глава б. Транспортный уровень того, чтобы можно было послать полный сегмент или, по меньшей мере, равный половине размера буфера получателя. (Отправитель может оценить этот размер по последовательности сообщений о размере окна, полученных им ранее.) 1 байт Рно. 6.28.

Синдром глупого окна В задаче избавления от синдрома глупого окна алгоритм Нагля и решение Кларка дополняют друг друга. Нагль пытался решить проблему приложения, предоставляющего данные ТСР-сущностн посимвольно. Кларк старался разрешить проблему приложения, посимвольно получающего данные у ТСР. Оба решения хороши и могут работать одновременно. Суть их состоит в том, чтобы не посылать и не просить передавать данные слишком малыми порциями.

Принимающая ТСР-сущность может пойти еще дальше в деле повышения производительности, просто обновляя информацию о размере окна большими порциями. Как и отправляющая ТСР-сущность, она также может буферизировать данные и блокировать запрос на чтение ккдб, поступающий от приложения, до тех пор, пока у нее не накопится большого объема данных, Таким образом, снижается количество обращений к ТСР-сущности и, следовательно, снижаются накладные расходы.

Конечно, такой подход увеличнваег время ожидания ответа, но для неинтерактивных приложений, например при передаче файла, сокращение времени, затраченного на всю операцию, значительно важнее увеличения времени ожидания ответа на отдельные запросы. Еще одна проблема получателя состоит в сегментах, полученных в неправильном порядке. Они могут храниться или отвергаться по усмотрению получателя.

Разумеется, подтверждение может быть выслано, только если все данные вплоть до подтверждаемого байта получены. Если до получателя доходят сег- Транспортные протоколы Интернета; ТСР 623 менты О, 1, 2, 4, 5, 6 и 7, он может подтвердить получение данных вплоть до последнего байта сегмента 2. Когда у отправителя истечет время ожидания, он передаст сегмент 3 еще раз.

Если к моменту прибытия сегмента 3 получатель сохранит в буфере сегменты с 4-го по 7-й, он сможет подтвердить получение всех байтов, вплоть до последнего байта сегмента 7. Борьба с перегрузкой в ТСР Когда в какую-либо сеть поступает больше данных, чем она способна обработать, в сети образуются заторы. Интернет в этом смысле не является исключением, В данном разделе мы обсудим алгоритмы, разработанные (за последние двадцать пять лет) для борьбы с перегрузкой сети. Хотя сетевой уровень также пытается бороться с перегрузкой, основной вклад в решение этой проблемы, заключающееся в снижении скорости передачи данных, осуществляется протоколом ТСР. Теоретически, с перегрузкой можно бороться с помощью принципа, заимствованного из физики, — закона сохранения пакетов, Идея состоит в том, чтобы не передавать в сеть новые пакеты, пока ее не покинут (то есть не будут доставлены) старые.

Характеристики

Список файлов книги