tanenbaum_seti_all.pages (525408), страница 165
Текст из файла (страница 165)
Когда приходит встречный И/Ч/-сегмент, в ответ на него также высылается подтверждение, и второе направление соединения также закрывается. Теперь обе стороны соединения закрыты, но ТСР-сущность выжидает в течение времени, равного максимальному времени жизни пакета, чтобы можно было гарантировать, что все пакеты этого соединения больше не перемещаются по сети даже в том случае, если подтверждение было потеряно.
Когда этот период ожидания истекает, ТСР-сущность удаляет запись о соединении. Транспортные протоколы Интврнвта: ТСР 619 иия. Когда приходит ЯЪ~-сегмеит, в ответ иа него высылается подтверждение, после чего сервер переходит в состояние ЯУХ ЯСИР (запрос соединения получек), Когда в ответ иа суй-подтверждеиие сервера от клиента приходит АСК- сегмент, процедура чтройиого рукопожатия» завершается и сервер переходит в состояние ЕБТАВ7.1ЕНЕ7).
Теперь можно пересылать данные. По окончании выполнения своей зздачи клиент запускает примитив С~05Е в результате чего иа сервер прибывает ГЕН-сегмеит (пуиктириый прямоугольник, обозначенный как пассивное разъедииеиие). Теперь сервер выполняет примитив 0~05Г, а ГГЖ-сегмеит посылается клиенту. Когда от клиента прибывает подтверждеиие, сервер разрывает соединение и удаляет запись о ием. Управление передачей в ТСР Как уже было сказано ранее, управление окном в ТСР ие привязаио напрямую к подтверждениям, как это сделано в большинстве протоколов передачи даииых.
Например, предположим, что у получателя есть 4096-байтовый буфер, как показаио иа рис. 6.27. Если отправитель передает 2048-байтовый сегмент, который успешио принимается получателем, то получатель подтверждает его получеиие. Одиако при этом у получателя остается всего лишь 2048 байт свободного буферного пространства (пока приложение ис заберет сколько-нибудь данных из буфера), о чем ои и сообщает отправителю, указывая соответствуюший размер окна (2048) и номер следующего ожидаемого байта. После этого отправитель посылает еше 2048 байт, получение которых подтверждается, ио размер окна объявляется равным О.
Отправитель должен прекратить передачу до тех пор, пока получающий хост ие освободит место в буфере и ие увеличит размер окна. При нулевом размере окна отправитель не может посылать сегменты, за исключеиием двух случаев. Во-первых, разрешается посылать срочные данные, иапример, чтобы пользователь мог уничтожить процесс, выполияюшийся иа удаленной машиие. Во-вторых, отправитель может послать 1-байтовый сегмент, прося получателя повторить информацию о размере окна и ожидаемом следующем байте.
Стандарт ТСР явно предусматривает эту возможность для предотврашеиия тупиковых ситуаций в случае потери объявления о размере окна. Отправители ие обязаны передавать данные сразу, как только оии приходят от приложения, Также никто ие требует от получателей посылать подтверждеиия как можно скорее. Например, иа рис. 6.27 ТСР-сушиость, получив от приложеиия первые 2 Кбайт данных и зная, что доступный размер окна равен 4 Кбайт, была бы совершенно права, если бы просто сохранила полученные данные в буфере до тех пор, пока ие прибудут еше 2 Кбайт данных, чтобы передать сразу сегмент с 4 Кбайт полезной иагруэки. Эта свобода действий может использоваться для улучшения производительности. Рассмотрим ТЕЕХЕТ-соедииеиие с интерактивным редактором, реагируюшим иа каждое нажатие клавиши.
В худшем случае, когда символ прибывает к передающей ТСР-сушиости, оиа создает 21-байтовый ТСР-сегмеит и передает его 1Р-уровню, который, в свою очередь, посылает 41-байтовую 1Р-дейтаграмму. 620 Глава Б. Транспортный уровень Иа принимающей стороне ТСР-сущность немедленно отвечает 40-байтовым подтверждением (20 байт ТСР-заголовка и 20 байт 1Р-заголовка).
Затем, когда редактор прочитает этот байт из буфера, ТСР-сушность пошлет обновленную информацию о размере буфера, передвинув окно на 1 байт вправо. Размер этого пакета также составляет 40 байт. Наконец, когда редактор обработает этот символ, он отправляет обратно эхо, передаваемое 41-байтовым пакетом. Итого для каждого введенного с клавиатуры символа пересылается четыре пакета общим размером 162 байта. В условиях дефицита пропускной способности линий этот метод работы нежелателен, Получатель Буфер получателя о зх Отправитель Приложение вьаюпняет — ~ запись 2К Пусто Приложение записывает — а' еще ЗК Приложение — читает 2К Отправитель заблокирован Отправитель может послать до 2К Рис. 6.27.
Управление окном а ТОР Для улучшения ситуации многие реализации ТСР используют задержку подтверждений и обновлений размера окна на 500 мс в надежде получить дополнительные данные, вместе с которыми можно будет отправить подтверждение олним пакетом. Если редактор успеет выдать эхо в течение 500 мс, удаленному пользователю нужно будет выслать только один 41-байтовый пакет, таким образом, нагрузка на сеть снизится вдвое.
Транспортные протоколы Интернета: ТСР 621 Хотя такой метод задержки и снижает нагрузку на сеть, тем не менее, эффективность использования сети отправителем продолжает оставаться невысокой, так как каждый байт пересылается в отдельном 41-байтовом пакете. Мстод, позволяющий повысить эффективность, известен как алгоритм Нагля (гча8!с, 1984). Предложение Нагля звучит довольно просто: если данные поступают отправителю по одному байту, отправитель просто передает первый байт, а остальные помешает в буфер, пока не будет получено подтверждение приема первого байта. После этого можно переслать все накопленные в буфере символы в виде одного ТСР-сегмента и снова начать буферизацию до получения подтверждения отосланных символов. Если пользователь вводит символы быстро, а сеть медленная, то в каждом сегменте будет передаваться значительное количество символов, таким образом, нагрузка на сеть будет существенно снижена.
Кроме того, этот алгоритм позволяет посылать новый пакет, даже если число символов в буфере превышает половину размера окна или максимальный размер сегмента. Алгоритм Нагла широко применяется различными реализациями протокола ТСР, однако иногда бывают ситуации, в которых его лучше отключить. В частности, при работе приложения Х-ЪИпг)оюз в Интернете информация о перемещениях мыши пересылается на удаленный компьютер. (Х-Ю!пг)ое — зто система управления окнами в большинстве ОС типа 1Л~ПХ). Если буферизировать эти данные лля пакетной пересылки, курсор будет перемещаться рывками с большими паузами, в результате чего пользоваться программой будет очень сложно, почти невозможно. Еще одна проблема, способная значительно снизить производительность протокола ТСР, известна под именем синдрома глупого окна (С!аг!г, 1982).
Суть проблемы состоит в том, что данные пересылаются ТСР-сущностью крупными блоками, но принимающая сторона интерактивного приложения считывает их посимвольно. Чтобы ситуация стала понятнее, рассмотрим рис. 6.28. Начальное состояние таково: ТСР-буфер приемной стороны полон, и отправителю это известно (то сеть размер его окна ранен 0). Затем интерактивное приложение читает один символ из ТСР-потока. Принимающая ТСР-сущность радостно сообщает отправителю, что размер окна увеличился, и что он теперь может послать 1 байт. Отправитель повинуется и посылает 1 байт. Буфер снова оказывается полон, очем получатель и извещает, посылая подтверждение для 1-байтового сегмента с нулевым размером окна. И так может продолжаться вечно.
Дэвид Кларк (РачЫ С)аг)г) предложил запретить принимающей стороне отправлять информацию об однобайтовом размере окна. Вместо этого получатель должен подождать, пока в буфере не накопится значительное количество свободного места. В частности, получатель не должен отправлять сведения о новом размере окна до тех пор, пока он не сможет принять сегмент максимального размера, который он объявлял при установке соединения, или его буфер не освободился хотя бы наполовину. Кроме того, увеличению эффективности отправки может способствовать сам отправитель, отказываясь от отправки слишком маленьких сегментов.
Вместо этого он должен подождать, пока размер окна не станет достаточно большим для 622 Глава б, Транспортный уровень того, чтобы можно было послать полный сегмент или, по меньшей мере, равный половине размера буфера получателя. (Отправитель может оценить этот размер по последовательности сообщений о размере окна, полученных им ранее.) ° Ф~ Загол~~~аок 1 байт Рис. 6.2В. Синдром глупого окна В задаче избавления от синдрома глупого окна алгоритм Нагля и решение Кларка дополняют друг друга.
Нагль пытался решить проблему приложения, предоставляющего данные ТСР-сушности посимвольно. Кларк старался разрешить проблему приложения, посимвольно получающего данные у ТСР. Оба решения хороши и могут работать одновременно. Суть их состоит в том, чтобы не посылать и не просить передавать данные слишком малыми порциями.
Принимающая ТСР-сушность может пойти еше дальше в деле повышения производительности, просто обновляя информацию о размере окна большими порциями. Как и отправляющая ТСР-сушность, она также может буферизировать данные и блокировать запрос на чтение йода, поступаюший от приложения, до тех пор, пока у нее не накопится большого объема данных.
Таким образом, снижается количество обращений к ТСР-сушностн и, следовательно, снижаются накладные расходы, Конечно, такой подход увеличивает время ожидания ответа, но лля неинтерактивных приложений, например при передаче файла, сокрашение времени, затраченного на всю операцию, значительно важнее увеличения времени ожидания ответа на отдельные запросы. Еше одна проблема получателя состоит в сегментах, полученных в неправильном порядке. Они могут храниться или отвергаться по усмотрению получателя. Разумеется, подтверждение может быть выслано, только если все данные вплоть до подтверждаемого байта получены.
Если до получателя доходят сег- Транспортные протоколы Интврнвта: ТСР 623 менты 0, 1, 2, 4, 5, 6 и 7, он может подтвердить получение данных вплоть до последнего байта сегмента 2. Когда у отправителя истечет время ожидания, он передаст сегмент 3 еше раз. Если к моменту прибытия сегмента 3 получатель сохранит в буфере сегменты с 4-го по 7-й, он сможет подтвердить получение всех байтов, вплоть до последнего байта сегмента 7.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
