Настройка сетей Microsoft дома и в офисе. Учебный курс
Шрифт:
Алгоритм вычисления нового значения тайм-аута зависит от конкретной реализации протокола TCP. В большинстве реализаций протокола эта величина вычисляется путем умножения прежнего значения тайм-аута на специальный корректирующий множитель. Обычно величина этого множителя выбирается равной двум. Если эта величина будет меньше двух, система может работать нестабильно.
Для того чтобы решить проблему вычисления постоянного предполагаемого полного времени доставки пакета, в алгоритме Карна используется методика принудительного изменения тайм-аута. При вычислении предполагаемого полного времени доставки пакета игнорируются результаты замеров, относящихся к повторно отправленным сегментам. В целях определения точного времени доставки пакетов в алгоритме Карна используется метод приращения значения тайм-аута при повторной
Предполагаемое значение полного времени доставки используется только для вычисления начального значения тайм-аута. При каждой повторной передаче сегмента данных значение тайм-аута увеличивается на некоторую величину до тех пор, пока этот сегмент не будет успешно доставлен получателю. Таким образом, при отправке последовательности сегментов используется значение тайм-аута, полученное в результате принудительной коррекции значения таймера. Это происходит до тех пор, пока не будет получен сигнал подтверждения приема, соответствующий однократно посланному сегменту данных. После этого экземпляр протокола TCP, основываясь на выполненном замере, пересчитывает предполагаемое значение полного времени доставки и соответствующим образом изменяет значение тайм-аута. Как показывает практика, алгоритм Карна идеален для применения в тех сетях, где потери данных весьма велики.
Исследования, в ходе которых вычислялось предполагаемое значение полного времени доставки пакетов, показали, что описанные методы неприменимы в том случае, если значение времени задержки в сети сильно изменяется. Эта проблема была учтена в спецификации протокола TCP, выпущенной в 1989 году, где требовалось, чтобы оценивалось среднее время полной доставки пакетов, а также величина статистического разброса.
Разработчики протокола TCP предусмотрели ситуации, связанные с возникновением перегрузки в сети. Признаком возникновения подобной ситуации может служить резкое увеличение времени задержки при доставке пакетов. При перегрузке устройства маршрутизации задержка увеличивается, поскольку поступающие дейтаграммы ставятся в очередь и находятся там до тех пор, пока маршрутизатор не сможет их обработать. Следует учитывать то, что емкость памяти маршрутизатора является конечной, поэтому она рано или поздно исчерпывается. Иными словами, при передаче дейтаграмм в сети для каждого ТСР-соедине-ния увеличения выделяемой памяти не происходит.
В самом худшем варианте, когда дейтаграммы не могут поместиться в памяти нагруженного маршрутизатора, они просто теряются. Как правило, в конечных точках соединения неизвестно, в каком месте сети и по какой причине возникла перегрузка. Для них перегрузка просто означает увеличение задержки.
К сожалению, в большинстве транспортных протоколов используется стратегия повторной передачи пакетов в случае истечения времени ожидания сигнала. Поэтому увеличение задержки вызывает повторную передачу дейтаграмм, что, в свою очередь, приводит к еще большей задержке. Если ничего не предпринимать, то увеличение трафика вызовет увеличение задержки, а рост времени задержки снова приведет к увеличению трафика в сети, и т. д. до тех пор, пока работа сети не будет полностью парализована. Подобная ситуация называется полным коллапсом сети.
Чтобы избежать полного коллапса сети, в случае возникновения перегрузки экземпляр протокола TCP должен уменьшить интенсивность передачи пакетов. Маршрутизаторы постоянно отслеживают длину внутренней очереди дейтаграмм, а в случае ее переполнения сообщают о возникшей перегрузке всем компьютерам-отправителям, используя механизм, подобный рассылке ICMP-сообще-ний. Однако протоколы транспортного уровня тоже могут регулировать степень перегрузки в сети, автоматически снижая интенсивность передачи данных при возникновении задержек. Применяемые при этом алгоритмы должны быть тщательно продуманы, поскольку даже при обычных условиях полное время доставки пакета в сети может варьироваться в очень широких пределах.
Для предотвращения перегрузки в сети современная версия стандарта TCP рекомендует использовать медленный запуск и мультипликативное уменьшение. Обе методики взаимосвязаны и могут быть легко реализованы на практике. Ранее уже упоминалось о том, что для каждого открытого соединения экземпляр протокола TCP хранит размер окна получателя. Чтобы избежать перегрузки, в протоколе TCP установлено еще одно ограничение, которое называется ограничением размера окна перегрузки. При возникновении перегрузки оно ограничивает поток данных настолько, чтобы он был меньше размера буфера приема данных.
В стационарном режиме при неперегруженном соединении размер окна перегрузки совпадает с размером окна получателя. При уменьшении размера окна перегрузки уменьшается поток данных, передаваемый экземпляром протокола TCP через конкретное соединение. Чтобы определить ориентировочный размер окна перегрузки, модуль протокола TCP считает, что большая часть дейтаграмм теряется из-за перегрузки. При этом используется описанная далее стратегия мультипликативного уменьшения. Каждый раз после возникновения перегрузки размер окна перегрузки уменьшается в два раза, вплоть до минимума, соответствующего одной дейтаграмме. Для тех сегментов данных, которые попали в окно нового размера, применяется стратегия экспоненциального увеличения значения таймера тайм-аута.
Поскольку в протоколе TCP при каждой потере пакета размер окна перегрузки уменьшается в два раза, размер основного окна передачи уменьшается по экспоненциальному закону. Другими словами, при возникновении перегрузки экземпляр протокола TCP уменьшает величину потока данных в сети. При этом интенсивность повторной передачи сегментов также снижается экспоненциально. При продолжительной перегрузке экземпляр протокола TCP, в конечном счете, ограничивает интенсивность передачи данных до одной дейтаграммы и удваивает значение тайм-аута перед повторной передачей сегмента. Идея состоит в том, чтобы в критических ситуациях система могла резко уменьшить величину потока данных в сети.
В этом случае маршрутизаторы получат время, достаточное для проверки и аннулирования «лишних» дейтаграмм, находящихся в их внутренней очереди. Теперь следует рассмотреть методику восстановления работоспособности системы после устранения перегрузки. На первый взгляд создается впечатление, что все должно выполняться в обратном порядке. То есть, как только сеть возвращается в обычный режим работы, размер окна перегрузки должен удваиваться. Однако следствием подобных действий может стать нестабильность работы системы. Ее состояние будет постоянно изменяться в широких пределах – от перегруженности до полного отсутствия трафика. Поэтому в протоколе TCP для постепенного увеличения интенсивности передачи данных используется метод медленного запуска.
Этот метод предназначен для восстановления работоспособности сети после перегрузки, а также для начала передачи данных по новому соединению. При этом первоначальный размер окна перегрузки выбирается равным одному сегменту, и каждый раз после получения сигнала подтверждения приема размер увеличивается на один сегмент. Таким образом, метод медленного запуска позволяет избежать коллапса сети сразу после прекращения перегрузки или при начале передачи данных по новому соединению.
Словосочетание «медленный запуск» не должно никого вводить в заблуждение, поскольку в идеальных условиях запуск механизма передачи данных происходит не столь уж медленно. Первоначально размер окна перегрузки устанавливается равным одному сегменту, после чего выполняется передача этого сегмента, и система переходит в состояние ожидания. После получения сигнала подтверждения приема этого сегмента размер окна перегрузки устанавливается равным двум сегментам, после чего посылается уже два сегмента и система снова переходит в состояние ожидания. После получения каждого из двух сигналов подтверждения приема этих сегментов размер окна перегрузки снова увеличивается на один сегмент. Поэтому модуль протокола TCP может отправить уже четыре сегмента. После получения четырех сигналов подтверждения приема размер окна перегрузки будет равен уже восьми сегментам. Таким образом, после завершения четырех циклов передачи-приема, модуль протокола TCP может отправить уже шестнадцать сегментов, что часто превышает размеры приемного окна получателя пакетов. Таким образом, перед тем, как модуль протокола TCP сможет отправить N сегментов, он должен выполнить log2iV циклов передачи-приема. Очевидно, что даже в случае очень больших размеров окон выход системы на проектную мощность будет довольно быстрым.