Данная статья призвана помочь администраторам сетей понять тонкости работы транспортной системы.
Некорректное «поведение» почтовой системы Microsoft Exchange в распределенной сети с облаком frame relay стало для автора стимулом, побудившим его обратить особое внимание на работу протокола TCP в сетях под управлением программных продуктов Microsoft. Последующий детальный анализ сбоев показал, что их причина кроется вовсе не в работе почтовой системы, а в громоздкости механизма передачи информации. В частности, многие попытки скопировать «Проводником» с удаленного сервера по frame relay (CIR=32 кбит/с) большой обюем данных (несколько сотен мегабайт) заканчивались ошибками передачи.
Эти ошибки возникали из-за слишком высоких «накладных расходов» на служебную информацию. Например, при простой процедуре копирования файлов необходимо установить соединение TCP, инициировать сеанс NetBIOS, произвести обмен служебной информацией протокола SMB и т.д. Другими словами, процедура копирования смахивает на русскую матрешку, так как состоит из вложенных друг в друга протоколов с их компонентами. Каждый протокол при транспортировке этого «милого создания» занимает часть сетевых ресурсов, что в конечном счете приводит к нестабильной работе медленных каналов связи.
К сожалению, проблемы, связанные с транспортировкой данных по распределенной сети, не решаются сами собой. Основным «действующим лицом» в такой сети является ТСР, и вот почему: IP просто предоставляет другим протоколам свои дейтаграммы и не производит решительно никаких действий по повышению производительности, пакеты же более высоких (относительно ТСР) уровней инкапсулируются в поле полезной нагрузки ТСР и терпеливо ждут, когда их доставят приложению-получателю.
Вопрос о производительности сетей под Windows NT открыт до сих пор. Практически во всех учебных пособиях по этой сетевой операционной системе прямо говорится, что не имея высокой квалификации, не следует браться за настройку оптимальной скорости транспорта ТСР (иными словами – изменять значения параметров в системном реестре).
Встречаются и более осторожные утверждения типа «настройка протокола ТСР может не дать ожидаемого эффекта». Думается, что пассивная позиция, основанная на постулате «работает и слава Богу», для современных сетевых администраторов неприемлема. Хочется обратить ваше внимание на то, что многообразие расширений протокола ТСР позволяет администратору творчески подойти к построению и оптимизации своей сети. В системном реестре хранится большое количество параметров, которые позволяют довести сеть «до ума». Одни расширения имеют два состояния – включено по умолчанию или выключено, для других предусмотрено несколько настраиваемых значений. Конечно, надо твердо знать, что можно и нужно настраивать и какие эффекты способна породить произведенная настройка. Документы RFC во многих случаях просто описывают процесс.
Цель настоящей публикации – подробно описать процессы, лежащие в основе тех или иных алгоритмов, выделить наиболее критичные параметры и определить степень их влияния на производительность ТСР. Следует отметить, что углубленное понимание работы механизмов протокола TCP и вопросов его производительности является важным условием успешного внедрения сетевых проектов. Так, при создании крупной распределенной сети на базе ОС Windows NT проектировщику надо внимательно отнестись к планированию загрузки сетевых каналов.
Протокол TCP
Протокол TCP, поддерживаемый всеми приложениями в сетях IP, входит в тройку транспортных протоколов операционной системы Windows NT (рис. 1).
 |
| Рис. 1. Протокол ТСР в ОС Windows NT 5.0 |
ТСР дает возможность пользователям среды Windows NT обращаться ко всем доступным сервисам. Наиболее широкий список дополнений и расширений протокола ТСР фирмы Microsoft представлен в операционной системе Windows 2000 (Windows NT 5.0).
Чтобы облегчить восприятие последующего материала, кратко напомним основы протокола ТСР. Минимальная длина заголовка ТСР составляет 20 байт, что позволяет протоколу производить большое количество операций. В дальнейшем изложении чаще других упоминаются три поля заголовка.
Поле «Номер в последовательности» (Sequence Number, SN) определяет номер первого байта в очереди (или последовательности) байтов в текущем сегменте. Исключение составляют случаи, когда установлен бит (флаг) синхронизации SYN. Тогда это поле обозначает начальный номер в последовательности (Initial Sequence Number, ISN), и первый байт данных получает номер очереди ISN + 1.
Поле «Номер подтверждения» (Acknowledgement Number) содержит номер сегмента с подтверждением успешного приема (который отправитель ожидает в ответ на отосланный сегмент) в последовательности получаемых подтверждений. Указанный номер заносится в поле «Номер в последовательности». При этом должен быть установлен контрольный бит подтверждения ACK. После того как соединение установлено, подтверждения посылаются постоянно.
Поле «Окно» (Window) содержит обюявленный размер окна в байтах.Назначение большинства полей заголовка ТСР определяется контрольными битами (URG, ACK, PSH, RST, SYN и FIN). Соединения протокола TCP переходят из одного состояния в другое в ответ на определенные события (запросы клиента, поступление сегментов с флагами SYN, ACK, RST, FIN) или по истечении заданного времени. Условно можно выделить три стадии: установление, рабочее состояние и закрытие соединения.
В основном состоянии соединения – ESTABLISHED (соединение установлено) – происходит обмен данными между абонентами. При формировании соединения осуществляется так называемая синхронизация номеров. Рассмотрим этот процесс для станций А и Б. Для синхронизации необходимо выполнить следующие действия.
- Станция А отправляет сегмент с флагом SYN и своим номером очереди N станции Б.
- Станция Б посылает подтверждение («ваш номер очереди – N») станции А.
- Станция Б отправляет сегмент с флагом SYN и своим номером очереди (обозначим его через K) станции А.
- Станция А посылает подтверждение («ваш номер очереди – K») станции Б.
Шаги 2 и 3 можно обюединить, поэтому такой обмен называется установлением (открытием) соединения с подтверждением трех сообщений. Для надежной передачи данных между прикладными программами по установленным логическим соединениям протокол TCP должен обеспечивать следующие функции:
- передачу данных;
- проверку достоверности данных при передаче;
- управление потоком данных и контроль за перегрузками в сети;
- разделение каналов связи;
- обслуживание сформированных соединений;
- соблюдение установленного приоритета пользователей;
- обеспечение соответствующего уровня безопасности.
 |
| Рис. 2. Последовательность этапов передачи (а) и приема (б) данных |
Рассмотрим пример использования некоторых переменных. Отправитель, используя переменную SND.NXT, контролирует отправку очередного сегмента из очереди. Получатель с помощью переменной RCV.NXT отслеживает номер следующего поступающего сегмента. В поле переменной SND.UNA отправитель помещает последний номер сегмента, который уже отправлен, но еще не подтвержден. При отсылке нового сегмента отправитель увеличивает значение своей переменной SND.NXT. Получатель при приеме этого сегмента увеличивает значение своей переменной RCV.NXT и посылает подтверждение. При получении подтверждения увеличивается значение переменной SND.UNA отправителя.
Разность величин SND.NXT и SND.UNA может служить мерой задержки сегментов в сети. Переменные изменяются на величину длины поля данных сегмента. Более подробно формат заголовка, назначение полей, флаги, возможные состояния соединения и переменные описаны в RFC 793.
Плавающее окно
Как и большинство протоколов, осуществляющих управление потоком данных (например, HDLC и X.25), TCP использует механизм плавающих окон, который без преувеличения можно назвать основополагающим. Протоколы HDLC и X.25 применяют его в классическом виде – на каждый отправленный блок данных должно быть получено подтверждение. TCP несколько отходит от классической схемы, главный недостаток которой состоит в том, что за один сеанс может быть передан лишь один сегмент. В данном случае под сеансом понимается посылка сегмента и получение подтверждения о его успешном приеме. Такая схема не позволяет работать с максимальной производительностью. Эффективность передачи можно значительно повысить, если разрешить пересылку множества сегментов в одном сеансе с группировкой всех подтверждений об их приеме.
Рассмотрим этот метод подробнее на примере обмена данными между станциями А и Б. Станция Б выделяет буферное пространство для приема n сегментов, которые станция А может отправить, не дожидаясь индивидуальных подтверждений их приема. Для идентификации подтверждений о принятых сегментах каждый из них помечен своим номером в последовательности данных. Станция Б посылает подтверждение о получении текущего сегмента, включающее в себя номер в последовательности следующего ожидаемого сегмента. Это подтверждение косвенно извещает станцию А о том, что станция Б готова принять следующие n сегментов, начиная с указанного номера.
Очевидно, что можно выслать одно подтверждение на несколько сегментов. Например, станция Б получила сегменты 2, 3 и 4, но задержала подтверждения о приеме сегментов 2 и 3 до получения сегмента 4. После посылки подтверждения с номером последовательности 5 станция Б подтверждает получение сегментов 2, 3 и 4 за один раз. Другими словами, станция А соблюдает список номеров сегментов в последовательности, которые ей разрешено посылать, а станция Б поддерживает аналогичный список для сегментов, которые она готова принять. Каждый из этих списков может рассматриваться как окно сегментов. Описанную схему часто называют управлением потоком с использованием плавающего окна.
 |
| Рис. 3. Сегменты в потоке данных на стороне отправителя (а) и получателя (б) |
В процессе передачи и приема сегменты проходят ряд промежуточных состояний, представленных на рис. 3. Здесь же показаны направления, в которых движутся границы окон отсылки и приема. Для простоты размер поля «Номер в последовательности» принят равным 3 битам. Затененные прямоугольники указывают на сегменты, которые могут быть посланы. Так, отправитель может передать шесть сегментов, начиная с нулевого. Каждый раз, когда сегмент послан, ширина затененного окна уменьшается; при каждом приеме подтверждения она увеличивается. Сегменты, находящиеся между вертикальной чертой и затененным окном, уже были отправлены, но еще не подтверждены. Отправитель должен хранить копии этих сегментов в своем буфере, чтобы при необходимости передать их повторно. Заметим, что реальный размер окна не обязательно должен совпадать с максимально возможным номером в последовательности.
 |
| Рис. 4. Пример работы технологии плавающего окна |
В начале работы размеры окон на станциях А и Б таковы, что станция А может передать семь сегментов, начиная с S0, а станция Б – принять такое же их количество. После передачи трех сегментов (S0, S1 и S2) без подтверждения станция А сокращает размер своего окна отсылки до четырех сегментов и сохраняет в буферной памяти копию трех посланных сегментов. Новый размер окна отсылки указывает на то, что станция А может передать четыре сегмента, начиная с S3.
Станция Б после получения части сегментов передает сообщение RR3, из которого следует, что все сегменты по S2 включительно получены и станция Б готова принять S3, а также еще шесть сегментов, следующих за ним. Для станции А эта информация эквивалентна разрешению на передачу семи сегментов, начиная с S3. Кроме того, станция А может очистить свою буферную память от копий первых трех сегментов, как успешно принятых. Теперь станция А передает S3, S4, S5 и S6, а cтанция Б в ответ отправляет подтверждение RR4 на получение S3 и разрешает отослать сегменты от S4 до S2 (где S0–S2 относятся уже к следующей последовательности из семи сегментов). Однако на момент получения станцией А этого подтверждения S4, S5 и S6 уже были посланы, следовательно, она может расширить свое окно отсылки и отправить четыре сегмента, начиная с S7 (правда, сегменты S4–S6 пока должны оставаться в буфере).
«Узкие места» в сети
В протоколах канального уровня управление потоком данных с использованием плавающего окна дает возможность получателю контролировать скорость работы отправителя. Получатель в этом случае только подтверждает принятые сегменты и расширяет свое окно приема в соответствии с наличием свободного буферного пространства. Скорость передачи данных можно задавать и при работе с протоколом TCP. Для простоты рассмотрим классический вариант, при котором скорость отсылки данных определяется скоростью поступления подтверждения для предыдущего посланного сегмента.
Покажем, что в этом случае скорость поступления подтверждений лимитируется наличием так называемых «узких мест» в сети между отправителем и получателем. «Узким местом» может быть либо сетевое устройство, либо часть канала, пропускная способность которого значительно уступает скоростным показателям сети в целом. Иногда «узким местом» становится станция-получатель.
 |
| Рис. 5. Примеры логических и физических «узких мест» |
Флуктуации задержек, которые образуются в распределенных IP-сетях, затрудняют выбор политики отсылки данных протоколом TCP на стороне отправителя. Если поток имеет слишком маленькую скорость, то распределенная сеть будет задействоваться неэффективно. Если один или несколько отправителей передают данные на повышенной скорости, то другие потоки TCP будут «зажаты» потоками, исходящими от этих отправителей. Наконец, в том случае, когда множество отправителей TCP используют чрезмерно высокую скорость, сегменты начнут теряться либо подтверждения будут поступать со значительной задержкой, что вызовет ненужные повторные передачи. Более того, чем больше сегментов транспортируется повторно, тем выше нагрузка на сеть, что, в свою очередь, приводит к дальнейшему увеличению задержек, числа отброшенных сегментов, повторных передач и т.д.
 |
| Рис. 6. Пример «узкого места» в сети |
Обозначим через Pb время прохождения сегмента через определенную точку медленного канала; оно определяется разностью между моментами пересечения этой точки передней и задней границами сегмента. Предположим, что в медленном канале сегменты перемещаются сплошными потоками, т.е. задняя граница одного сегмента вплотную примыкает к передней границе следующего за ним. В данном случае Pb определяет и время между прохождениями через фиксированную точку канала передних границ двух последовательных сегментов. При попадании сегментов в высокоскоростной канал это время остается прежним даже с учетом повышения допустимой скорости передачи данных, так как темп поступления сегментов из низкоскоростного канала не меняется. А поскольку в высокоскоростном канале сегмент как бы сокращается, увеличиваясь в ширину, то теперь это время (обозначим его Pr) складывается из времени прохождения самого сегмента и паузы до передней границы следующего сегмента (т.е. Pr=Pb). Если получатель подтверждает прием сегментов в момент их поступления, то время между отсылками подтверждающих сегментов (АСК-сегментов) Ar на выходе от получателя равно Pr. Наконец, время Ab (аналог Pb для подтверждающих сегментов) будет равно Ar, а Аs (аналог Ar на стороне отправителя) равно Аb.
После попытки работать с высокой скоростью система переходит в устойчивое состояние, в котором скорость отправки сегментов с данными равна скорости поступления подтверждений. Очевидно, что первая скорость будет лимитироваться пропускной способностью самого медленного канала. Можно сказать, что протокол TCP автоматически определяет «узкое место» в сети и регулирует интенсивность потоков. Этот процесс называется самосинхронизацией (self-clocking).
Параметры, влияющие на пропускную способность TCP
Рассмотрим методы определения максимально возможной пропускной способности TCP-соединения, которая зависит от размера окна отправки, задержки и скорости передачи данных. Введем следующие обозначения: W – размер окна в байтах; R – скорость передачи данных (бит/с) по определенному соединению, доступная на стороне отправителя; D – задержка (в секундах) при передаче данных между отправителем и получателем через определенное соединение.
Предположим, отправитель начинает передавать последовательность байтов получателю через установленное соединение. Первый байт достигнет получателя через время, равное D секундам. Такое же время потребуется для получения подтверждения. В течение этого промежутка времени отправитель способен передать 2RD бит, или RD/4 байт. Но отправитель ограничен размером окна в W байт и не может сдвигать окно до получения подтверждения. Только при WБ??RD/4 в этом соединении достигается максимально возможная пропускная способность. В противном случае близость фактической пропускной способности к максимальной определяется отношением W к RD/4. Следовательно, нормированная пропускная способность S/Smax может быть выражена как
| S/Smax = | { | 1, если WБ??RD/4, |
| 4W/RD, если W |
На рис. 7 представлена зависимость максимальной пропускной способности от произведения RD. Максимальный размер окна может составлять 216-1=65 535 байт (если длина поля «Окно» 16 бит), что достаточно для большинства приложений.
 |
| Рис. 7. Влияние параметра масштабирования окна на максимальную пропускную способность |
Анализируя взаимное влияние рассмотренных параметров, можно получить представление о потенциале протокола TCP в плане повышения производительности. При этом следует принять во внимание множество факторов, которые заметно усложняют описанную выше ситуацию.
Во-первых, в большинстве случаев несколько TCP-соединений мультиплексируются через один канал, так что каждое соединение получает часть его доступной пропускной способности. Это приводит к снижению скорости передачи R и, следовательно, эффективности работы протокола.
Во-вторых, множество TCP-соединений будет проходить через несколько маршрутизаторов, и время D окажется равным сумме задержек в отдельных каналах и маршрутизаторах на пути передачи данных. Суммарная задержка в маршрутизаторах часто вносит основной вклад в значение D, особенно при возникновении перегрузок.
В-третьих, значение R в вышеприведенной формуле определяет скорость передачи данных, доступную для соединения только на стороне отправителя. Если она превышает скорость на одном из участков пути от отправителя к получателю, то попытка передачи данных на максимальной скорости приведет к образованию «узкого места», что неизбежно увеличит время D.
В-четвертых, если любой потерянный сегмент должен быть передан вновь, фактическая пропускная способность снижается еще больше, влияние же потерянных сегментов определяется выбранной схемой повторных передач.
Для повышения производительности сетей с большими задержками в ОС Microsoft Windows NT 5.0 введен алгоритм масштабирования окна (TCP Receive Window Size Calculation and Window Scaling), описанный в разделе 2.2 документа RFC 1323. При использовании параметра масштабирования окна F число байтов данных, определяемых полем «Окно», становится кратным значению 2F. Максимальное значение F, которое может быть использовано протоколом TCP, равно 14. Следует отметить, что алгоритм масштабирования включается только на время инициирования соединения.
В системе Windows NT размер приемного окна может увеличиваться на величину, кратную максимальному размеру сегмента (Maximum Segment Size, MSS). Значение MSS определяется во время установления соединения. По умолчанию приемное окно задает размер данных 8 Кбайт для Windows NT 4.0 и 16 Кбайт для Windows NT 5.0. Такой размер окна выставляется в реестре операционной системы (параметр ТсрWindowSize – столбец 2 табл. 1). Размер окна, устанавливаемый в сетях Ethernet, позволяет передать 8760 байт информации (8 Кбайт, размещенные в шести сегментах по 1460 байт) для операционной системы Windows NT 4.0 и 17520 байт (16 Кбайт, размещенные в 12 сегментах по 1460 байт) для Windows NT 5.0.
Таблица 1. Параметры реестра Windows NT, регулирующие работу протокола TCP
| Параметр | ТсрWindowSize | Tcp1323Opts |
| Ключ в реестре | TcpipParameters, TcpipParametersInterface | TcpipParameters |
| Тип записи | REG_DWORD – Number of bytes (количество байтов) | REG_DWORD – Number (флаги) |
| Возможные значения | 0 – 0x3FFFFFFF (десятичное – 1073741823) | 0, 1, 2, 3 |
| Значение по умолчанию | 17 520 (для сети Ethernet) | 3 |
Для ОС Microsoft Windows NT 5.0 размер окна рассчитывается следующим образом. Первый запрос на установление соединения, посылаемый удаленному абоненту, предлагает установить размер окна, определяющий 16 Кбайт (16 384 байт) данных. После формирования соединения размер приемного окна округляется до обюема данных, кратных максимальному размеру сегмента MSS, который был оговорен в процессе установления соединения. Если размер приемного окна определяет обюем данных, близкий к четырехкратному значению MSS, то окно выравнивается до значения 4MSS, которое сохранится до тех пор, пока не будет активизирован алгоритм масштабирования окна.
В операционной системе Windows NT 5.0 окно масштабируется автоматически, если параметр ТсрWindowSize реестра установлен в значение, превосходящее 64 Кбайт. Масштабирование окна можно запретить вручную параметром Tcp1323Opts (столбец 3 табл. 1).
Работать с окном, размер которого превышает 64 Кбайт, можно только в том случае, если абонент поддерживает эту опцию. Значение по умолчанию устанавливается как наименьшее из следующих величин: 0xFFFF; значение дополнительного параметра GlobalMaxTcpWindowSize в реестре ОС Windows NT; наибольшее из четырехкратного значения максимального размера данных TCP в сети и значения 16 384, выравненного до кратного размера данных протокола TCP. Значение по умолчанию для сети Ethernet составляет 17 520 байт (в реализации TCP для Windows NT 5.0). Оно может быть немного уменьшено, если соединение установлено с абонентом, который поддерживает алгоритмы SACK и временные метки (time stamp), так как они увеличивают размер заголовка протокола TCP сверх обычного 20-байтного размера, оставляя меньше места для данных.
Размер окна является одновременно и глобальным параметром, и параметром, устанавливаемым отдельно на каждом интерфейсе в зависимости от того, где расположен ключ реестра. Значение для определенного интерфейса перекрывает значение для всей системы.
Параметр Tcp1323Opts может принимать следующие значения: 0 - применение опций RFC 1323 запрещено, 1 – разрешено использовать только масштабирование окна; 2 – разрешено применять только временные метки; 3 – разрешено использовать обе опции.
Управление потоком
Для управления потоком используется не только механизм плавающего окна, но и более гибкая схема передачи данных, их приема и отсылки подтверждений. Управление потоком основывается на лимитной схеме выделения массива данных, разрешенного к отправке.
В соответствии с указанной схемой каждый индивидуальный передаваемый байт имеет собственный номер в последовательности. При отсылке сегмента TCP выставляет в качестве номера в последовательности номер первого из байтов, размещаемых в поле данных этого сегмента. Приемная сторона подтверждает поступление сегмента сообщением, имеющим форму (A = i, W = j). Такая запись означает следующее: А (АСК) подтверждает получение всех байтов, вплоть до номера в последовательности (i - 1); следующие ожидаемые к приему байты имеют номера начиная с i. Кроме того, выдается разрешение на отправку дополнительного окна W (Window) из j данных; соответствующие байты имеют номера в последовательности от i до (i + j - 1).
 |
| Рис. 8. Принцип управления потоком |
Отправив 600 байт в трех сегментах, станция А уменьшает свое окно отсылки до 800 байт (номера с 1601 до 2400). После получения этого сегмента станция В подтверждает получение всех байтов, вплоть до байта с номером 1600 (при этом А=1601), и формирует свое окно приема на 1000 байт. Следовательно, А может посылать байты с номера 1601 по номер 2600 (пять сегментов). Однако к моменту прихода сообщения от станции В на станцию А она уже успела переслать два сегмента, содержащих байты с номерами от 1601 до 2000. Таким образом, на этот момент оставшийся лимит станции А составляет всего 400 байт, или два сегмента. В процессе обмена станция А продвигает левую границу своего окна каждый раз, когда передает данные, а правую – только при получении нового лимита.
На практике обе стороны одновременно задействуют режимы отсылки и приема, поскольку данные могут передаваться в обоих направлениях (режим дуплексной передачи). Механизм выделения лимита достаточно гибок. В качестве примера рассмотрим ситуацию, в которой последним сообщением, посланным станцией В, было (A = i, W = j). Последний байт данных, полученный станцией В, имел номер i - 1. В результате для увеличения лимита до значения k при выполнении условия k > j и отсутствия дополнительных данных станция В формирует сообщение (A = i, W = k), а для подтверждения входящего сегмента, содержащего m байт данных (m < j), без получения дополнительного лимита станция В формирует сообщение (A = i + m, W = j - m).
Следует отметить, что от получателя не требуется немедленного подтверждения приходящих сегментов; обобщенное подтверждение для некоторого их числа может быть сформировано через какое-то время. Тем не менее получатель должен подчиняться определенной политике, регламентирующей количество входных данных, которое он позволяет передавать отправителю. Можно выделить две схемы поведения получателя: «консервативную» и «оптимистическую».
«Консервативная» схема управления потоком основана на том, что лимит выделяется, исходя из фактического значения свободного буферного пространства. Если это правило применить к ситуации, проиллюстрированной рис. 8, то первое лимитирующее сообщение будет говорить о способности станции В разместить в своем буфере 1000 байт, а второе – о возможности разместить 1400 байт. Консервативная схема управления потоком ограничивает пропускную способность логического соединения при возникновении длительных задержек.
Получатель может увеличивать пропускную способность с помощью «оптимистического» выделения лимита на свободное буферное пространство, которого он в данный момент не имеет. Например, если буфер получателя заполнен, но он ожидает, что успеет освободить 1000 байт за время прохождения информации из конца в конец соединения, то он немедленно выделяет лимит на 1000 байт. Если получатель в состоянии поддерживать скорость, заданную отправителем, то такая схема способна повысить пропускную способность без каких-либо отрицательных последствий. Однако в том случае, когда отправитель работает быстрее получателя, некоторые сегменты будут отбрасываться по причине занятости буфера, что повлечет за собой повторную передачу. А поскольку последняя является необходимым атрибутом надежного сетевого сервиса, то «оптимистическое» управление потоком может повысить нагрузку на сеть.
Получатель всегда пытается увеличить приемное окно, если имеет свободное буферное пространство. Отправитель также при малейшей возможности старается расширить окно отсылки на любую допустимую величину. В такой ситуации говорить о стабильном потоке сегментов не приходится. Чтобы уберечь отправителя и получателя от соблазна «втиснуть» в канал лишний сегмент, используется алгоритм предотвращения синдрома «глупого окна» (Silly Window Syndrome, SWS), описанный в RFC 1122. Большой обюем данных не отправляется до тех пор, пока получатель не обюявит размер окна, достаточный для передачи полного сегмента, либо не будет произведена настройка, не позволяющая увеличивать ширину приемного окна меньше чем на сегмент.