Отложенные подтверждения

Спецификация TCP разработаиа так, чтобы поддерживать двустороннюю связь между Компьютерами. Когда оба Компьютера обмениваются данными, подтверждения TCP могут быть присоединены к пакетам данных . Задержка передачи подтверждения увеличивает вероятность его отправки в пакете вместе с данными. Хотя это и эффективно для таких иитерактивпых приложений, как Telnet или Rlogin, задержка отправки подтверждений замедляет передачу Web-pecypcoB. Если включен алгоритм Нагла, отложеиные подтверждения могут приостановить загрузку заключительной части Web-страницы. В этом подразделе мы опишем причипы применения отложенных подтверждений и изучим их влияние на работу Web.

ПРИЧИНЫ ИСПОЛЬЗОВАНИЯ ОТЛОЖЕННЫХ ПОДТВЕРЖДЕНИЙ

Скорость передачи пакетов TCP отправителем зависит от получения подтверждений от получателя. Скользящее окио управляет передачей пакетов. Когда оио заполнено, отправитель не может передать пакеты, не получив ACK от получателя. Своевременное получение ACK необходимо для поддержания высокой скорости передачи данных. Но посылка ACK требует 40-байтиого пакета: 20-байтпый заголовок IP и 20-байтпый заголовок TCP с уставлепным битом ACK. Это очень неэффективно. Рассмотрим отправителя, который посылает получателю 400-байтпые пакеты. Посылка 40-байтиого пакета с подтверждением на каждый пакет данных увеличит трафик на 10%. Существуют два способа уменьшить трафик подтверждений. Во-первых, получатель не обязап посылать ACK в ответ на каждый получеп- ный пакет данных. Во-вторых, получатель может присоединить подтверждения (флаг ACK и номер подтверждения) к передаваемому им же пакету данных.

Присоединение ACK к передаваемому пакету данных позволит не посылать дополнительных пакетов с подтверждениями. Это очеиь эффективно, если у отправителя имеются собственные данные, которые нужно отправить. Присоединение невозможно, если у получателя нет собственных данных для передачи. Чтобы увеличить вероятность присоединения, TCP позволяет получателю отложить отправку пакета ACK в надежде, что приложение вскоре будег передавать данные. Это очепь эффективно для интерактивных приложений. Представим себе, что Компьютер А подключился посредством Rlogin к Компьютеру В. Предположим, что пользователь ввел один или более символов. Эти символы посылаются по ТСР-соедипепию Компьютеру В. Rlogin на Компьютере В читает эти символы и геперирует эхо, которое должпо отображаться на компьютере А. Эхо помещается в пакет, который будет передан от В к А. В идеалыюм случае В подтвердит получение начальных символов и пошлет эхо одним пакетом. С другой стороны, В не следует ждать слишком долго. Подтверждение получения пакета от А очень важно. Ведь компьютер А не сможет отправить еще одну порцию данных, если получение предыдущего пакета не было подтверждено. Следовательно, задержка пакета ACK может замедлить передачу данных от А к В. Чтобы найти компромисс, TCP запускает таймер, который активизирует передачу ACK, даже если нет пикаких данных для отправки. Большинство реализаций TCP передают ACK через 200 мс, но некоторые увеличивают задержку до 500 мс. Чтобы избежать задержки пакетов ACK в загруженных соединениях, TCP требует, чтобы подтверждалось прибытие хотя бы каждого второго полпоразмериого накета до завершения таймера задержки подтверждения. Например, если сервер передает длинное сообщение клиенту на высокой скорости, то клиент будет передавать подтверждения после каждого второго накета данных, даже если клиент не имеет собственных данных для передачи серверу.

ВЗАИМОДЕЙСТВИЕ ОТЛОЖЕННЫХ ACK С ТРАФИКОМ HTTP

Отложенные ACK уменьшают трафик подтверждений двумя путями: присоединяя ACK к передаваемому пакету данных, а также посылая ACK для каждого второго пакета данных. Присоединение ACK к пакетам данных несвойственно для Web-трафика. Обычная передача Web-данных включает в себя короткий НТТР-за- прос клиента, после которого следует HTTP-ответ сервера.

Маловероятно, что оба Компьютера будут передавать данные одновременно, если только сервер не посылает ответ, когда клиент посылает последующие запросы из той же последовательности. Задержка передачи накета ACK редко позволяет клиенту присоединить его к передаваемому пакету данных. Вместо этого задержка в 200, а то и 500 мс, вызванная таймером задержки ACK, может снизить скорость передачи данных. Эта задержка может быть заметпой пользователю. Кроме того, когда скользящее окно сервера заполнено, задержка клиецтом передачи подтверждений приостанавливает передачу сервером оставшейся части ответа.

Механизм отложенных ACK может привести к ненужной задержке Web-трафика, обусловленной реализацией Web-сервера. Представим себе сервер, который передает заголовок и тело HTTP-ответа раздельно. Заголовок ответа обычно меньше MSS. Операционная система может передать короткий пакет до того, как сервер запишет хоть какие-пибудь дополнительные данные в выходной буфер. Позже сервер пачипает записывать тело ответа в выходной буфер. Если на сервере отключен алгоритм Нагла, операционная система может начать передавать пакеты, содержащие тело ответа. Первый полпоразмерпый пакет окажется вторым для клиента. Но клиент не передаст ACK, так как первый пакет (заголовок HTTP) будет меньше MSS. Клиент должен подождать, пока закончится отсчет таймера задержки подтверждения, прежде чем передаст ACK. В зависимости от размера скользящего окна сервер может оказаться не в состоянии передать дополнительную порцию данных до получения ACK, как показано на рис. 8.8. Чтобы избежать такой ситуации, некоторые операционные системы отключают механизм задержки ACK в па- чале соединения. Однако это не предотвращает возникновения данной ситуации при передаче последующих ответных сообщений но тому же соединению.

Алгоритм Нагла достаточно сложно взаимодействует с механизмом отложенных подтверждений, когда клиент и сервер поддерживают долговременное соединение [Hei97]; такой же феномен наблюдался на сервере NNTP [MSMV99J. Рассмотрим сервер, который записал HTTP-ответ в выходной буфер. Операционная система разделяет сообщение на сегмепгы, каждый из которых помещается в пакет IP. Операционная система пытается передавать данные полпоразмерпыми пакетами, хотя последний пакет обычно меньше остальных. Например, сообщение дли-

Рис 8.8. Клиент задерживает ACK для первых двух пакетов, переданных сервером

пой 5000 байтов передается в виде грех пакетов длиной 1460 байтов и одного дли- пой 620 байтов. Согласно механизму отложенных подтверждений, клиент подтверждает каждую пару полноразмерпых пакетов. Получив подтверждения на первые два пакета, сервер передает третий полноразмерпый накет. Получив этот пакет, операционная система на клиентском Компьютере не передает подтверждения в соответствии с механизмом отложепиых подтверждений. Онерационная система на сервере, в то же время, не станет посылать последний короткий пакет, пока не получит подтверждения на все предыдущие. Передача данных сервером останавливается, ожидая подтверждения клиента (из-за алгоритма Нагла), а клиент задерживает передачу ACK (из-за механизма отложепиых подтверждений), как показано на рис. 8.9. К счастью, отключение алгоритма Нагла на сервере может предотвратить появление такой ситуации на практике.

Рис 8.9. Взаимодействие алгоритма Нагла с механизмом отложенных ACK

Источник: Web-протоколы. Теория и практика. — M.: ЗАО «Издательство БИНОМ», 2002 г. – 592 c.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100