Повтор фазы медленного старта

Долговременные соединения создают привлекательную альтернативу установлению отдельных TCP-соединений для каждого сеанса передачи данных. Возможность предотвратить фазу медленного старта является одним из преимуществ использования уже имеющегося соединения, как уже говорилось в главе 7 (раздел 7.5). Однако отправка ответного сообщения по пассивному в течение некоторого времени долговременному соединению приводит к появлению большого числа передаваемых пакетов. Чтобы не перегрузить сеть, спецификация TCP требует от отправителя повторить фазу медленного старта для управления скользящим окпом после некоторого периода бездействия соединения. Однако имеется несколько рекомендаций, как все-таки избежать этой фазы без перегрузки сети.

НЕАКТИВНЫЕ ДОЛГОВРЕМЕННЫЕ СОЕДИНЕНИЯ

Клиент HTTP часто загружает многочисленные ресурсы с одного Web-сайта за очепь короткое время. Например, пользователь может загрузить Web страницу, содержащую несколько изображений. Браузер запрашивает эти изображения, проанализировав содержимое HTML-файла. В дополнение к этому пользователь мо-

с

Рис. 8.3. после таймаута повторной передачи

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

С другой стороны, использование больших размеров скользящего окпа может перегрузить сеть, если долговременное соединение оставалось неактивным в течение некоторого времени. Представим себе пользователя, который загружает Web- страницу с сервера, а после пяти секупд чтения страницы загружает другую страницу с того же сервера. Предположим также, что клиент и сервер оба решили сохранить соединение. Сетевой трафик может существенно измениться за пятисе- кундпый период простоя. Пока соединение было неактивно, другие ТСР-соедипе- пия с тем же сервером могли расширить свои скользящие окпа так, чтобы в полной мере иснользовать пропускную способность канала. Возьмем простой пример: по участку сети проходит трафик пяти соединений с одинаковыми RTT. В среднем, каждое из них имеет пропускную способность в 20% от общей пропускной способности участка сети. Если одно из этих соединений будет неактивно несколько секупд, то остальные четыре соединения «съедят» его долю и будут занимать по 25% от общей нропускпой способности.

Если соединение, которое было некоторое время неактивным, будет работать с тем же размером скользящего окна, который оио имело до периода простоя, то это может вызвать серьезную иерегрузку сети. Соединение сразу иачпет использо- вагь для передачи 20% пропускной способности сети, хотя остальные соединения продолжат использовать по 25%. В таком случае пропускная способность будет превышена на 20%. Многие из передаваемых пакетов будут теряться. Между прочим, утери пакетов могут заставить некоторые соединения снизить скорость передачи, что приведет к педогрузке сети. Соединениям придется заново медленно увеличивать размеры своих скользящих окоп, чтобы, в копце копцов, полностью использовать пропускпую способность сети. В итоге, помимо спижепия общей производительности, отправка слишком большого числа пакетов может ухудшить пропускпую способность и самого соединения, так как общая перегрузка сети может привести к существенным потерям пакетов данным соединением. Все это приведет к повторной передаче пакетов.

ПОВТОР ФАЗЫ МЕДЛЕННОГО СТАРТА

Чтобы предотвратить «вспышку» активности, отправитель должен после периода простоя передавать данные менее агрессивно, чем до этого. Фаза медленного старта была введепа в протокол, чтобы избежать неожиданных и резких «вспышек» трафика. В течение фазы медленного старта TCP-отправитель увеличивает свое скользящее окно и пытается оценить размер своей законной доли пропускпой способности соединения с сервером. Позволить соединению, бывшему неактивным, получить сразу большое скользящее окпо — это все равпо, что позволить новому соединению начать работу с большим скользящим окпом. Такая «вспышка» трафика может вызвать перегрузку сети и обусловить большую вероятность утери пакетов. Чтобы избежать этой проблемы, спецификация TCP требует повторения фазы медлеииого старта после периода бездействия. Этот механизм называется повтором фазы медленного старта.

Точное определение механизма повтора фазы медленного старта требует уточнения двух ключевых понятий: начала периода бездействия и установки начального размера скользящего окна. Период бездействия начинается сразу же, как только отправитель перестает передавать данные, а прибытие всех предыдущих пакетов с данными было подтверждено получателем. Получив последнее подтверждение, отправитель запускает таймер. Когда время таймера истекает, отправитель устанавливает начальный размер скользящего окпа, равный длине одного-двух пакетов данных. Отправитель TCP-пакетов использует текущее зпачепие RTO для измерения периода бездействия. Иными словами, если приложение не передает данных  в течепие периода времени, равного RTO, то отправитель устанавливает начальный размер скользящего окпа и осуществляет повтор фазы медленного старта.

может начаться, если соединение неактивно дольше, чем несколько RTT, что составляет обычно не более нескольких секунд. Большинство автоматически генерируемых запросов на загрузку встроенных ресурсов нруходят именно за такой интервал времени. Помимо этого, долговременные соединения могут обслуживать запросы, генерируемые пользователями, когда’ они просматривают различные страницы на том же сайте. При этом часто бывают значительные задержки между последовательными запросами. Свойства таких задержек между последовательными запросами более подробно рассматриваются в главе 10 (раздел 10.5.3). Большие промежутки между запросами, обусловленные просмотром страниц пользователями, могут привести к повтору фазы медленного старта. спижает преимущества повышения производительности с помощью долговременных соединений. Сервер не сможет в полной мере использовать высокую пропускную способность капала, если каждый последовательный запрос пользователя будет начинаться с небольшим скользящим окном. С другой стороны, повтор фазы медленного старта также влияет на общую пропускную способность сети.

УМЕНЬШЕНИЕ ВЛИЯНИЯ ПОВТОРОВ ФАЗЫ МЕДЛЕННОГО СТАРТА

НА ОБЩУЮ ПРОПУСКНУЮ СПОСОБНОСТЬ СЕТИ

Механизм повтора фазы медленного старта предотвращает генерацию слишком большого числа пакетов для соединений, которые были перед этим пеактивпы. Предлагается несколько способов для уменьшения или даже устранения влияния повтора фазы медленного старта на сннжепие производительности соединения [Hei97J:

•          Отключение повтора фазы медленного старта. Web-cepвep может заблокировать механизм повтора фазы медленного старта, оставляя долговременному соединению возможность отправить большое число пакетов за короткое время. Риск уменьшается, если сервер закрывает соединения после небольшого периода простоя. Например, сервер может закрыть соединение, которое было неактивно в течение 15 секупд, чтобы уменьшить общее число соединений, как это описапо ниже в разделе 8.4.2.

•          Использование большего таймаута повтора фазы медленного старта. В операционной системе, под управлением которой функционирует Web-cepвep, Можно увеличить таймаут, необходимый для повтора фазы медленного старта. Однако не следует забывать, что чем больше таймаут, гем больше вероятность того, что размер скользящего окпа, остающийся от предыдущего периода активности, не будет соответствовать текущему состоянию сети.

•          Постепенное уменьшение размера скользящего окна. Вместо того чтобы использовать решение «все или ничего», отправитель TCP-пакетов может постепенно уменьшать размер скользящего окна для неактивного соединения. Отправитель может уменьшать ее пропорционально времени периода простоя. Этот адаптивпый подход становится все более копсервативпым при увеличении неопределенности в предсказании состояния сети.

•          Постепенная отправка пакетов. Чтобы избежать резкого возрастания числа передаваемых пакетов, отправитель может постепенно увеличивать число отправляемых получателю пакетов. Предположим, что размер скользящего окпа равен длипе четырех пакетов. Передача всех четырех пакетов сразу друг за другом может резко увеличить трафик и вызвать иерегрузку сети. Вместо этого отправитель может делать небольшой перерыв после отправки каждого пакета. Это уменьшит вероятность перегрузить сеть, используя по-нрежнему скользящее окна, размер которого равеп размеру четырех пакетов.

Реализация TCP на компьютере, где функционирует Web-сервер, может применять комбинацию этих методов. Например, отправитель может использовать больший таймаут, ностепеино уменьшать размер скользящего окна и постепенно передавать пакеты.

Источник: 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