Кратко

  • Синдром глупого окна — не один малый сегмент, а устойчивая обратная связь, при которой небольшое продвижение окна снова и снова порождает отправку такого же масштаба.
  • TCP разрывает цикл сдержанностью на обеих сторонах, а аварийный таймер не позволяет ожиданию ради эффективности превратиться в тупик.

Пусть принимающее приложение прочитало всего 50 байт из почти заполненного буфера. Место действительно появилось, и TCP вправе сразу объявить его. У отправителя в очереди гораздо больше данных, но новое доступное окно позволяет передать только 50 байт. Они приходят, приложение их потребляет, и освобождаются следующие 50. Подтверждение возвращает отправителю такую же малую возможность. Каждое действие соблюдает управление потоком, однако их последовательность заставляет соединение двигаться шагами, которые воспроизводят сами себя.

David Clark назвал этот рисунок Silly Window Syndrome, или SWS, в RFC 813 1982 года. Речь шла не о том, что любой короткий сегмент ошибочен. Документ описывал устойчивое вырождение длительной передачи. Естественная граница данных может однажды разделить используемое окно; затем подтверждения и малые перемещения его правой границы сохраняют разделение. Пока отправитель не остановится, естественного момента для повторного объединения частей может не возникнуть.

RFC 813 отделил предлагаемое получателем окно от действительно используемого отправителем. Из объявленной величины отправитель вычитает данные, уже переданные, но ещё не подтверждённые. Если получатель предлагает 1 000 байт, а 950 ещё находятся в пути, для новой отправки остаётся только 50. Подтверждение передвигает правую границу ещё на 50 и создаёт очередную возможность такого же размера. Большое значение в поле окна само по себе не гарантирует крупной передачи: решающим становится размер каждого продвижения границы.

Исторический ущерб не ограничивался долей заголовков. RFC 813 сообщал, что неудачная оконная стратегия могла ухудшить пропускную способность и эффективность CPU в несколько раз. В документе приводились случаи, когда средний сегмент составлял десятую часть размера, приемлемого для обеих сторон, а повторные передачи множились. Это наблюдения начала 1980-х, а не оценка распространённости в современных сетях. Но они объясняют, почему SWS потребовал изменения транспортного алгоритма.

Получатель разрывает цикл, не отождествляя свободную память с кредитом, который следует немедленно опубликовать. Когда приложение освобождает немного места, TCP может оставить объявленную правую границу неподвижной. Пространство накапливается локально и открывается одним полезным скачком. Слишком долгое ожидание способно опустошить конвейер и добавить задержку. Слишком частое открытие сохраняет дробление и расходует сеть и процессор. RFC 813 советовал смещать выбор в сторону сдержанности и открывать окно как минимум на величину разумно крупного сегмента.

RFC 1122 превратил этот принцип в требование к хосту. Раздел 4.2.3.3 требует от принимающего TCP алгоритм предотвращения SWS. Предложенное правило удерживает RCV.NXT + RCV.WND постоянным, пока доступное, но ещё не объявленное пространство не достигнет меньшего из двух порогов: доли приёмного буфера или эффективного MSS отправки. Рекомендованная доля равна половине. При реалистичных размерах буфера окно обычно продвигается единицей, способной вместить полезный сегмент, а не отдельными байтами.

Отправитель тоже должен уметь отказаться от законной, но неэффективной возможности. RFC 1122 §4.2.3.4 требует SWS-алгоритм и на передающей стороне. Отправлять рекомендуется, если помещается сегмент максимального размера; если при указанных условиях можно отправить все данные с требованием PUSH; если можно использовать как минимум половину максимального ранее замеченного окна; либо если истёк аварийный таймер. Малое используемое окно разрешает отправку, но не обязывает немедленно воспользоваться разрешением.

Таймер нужен из-за неравенства информации. Получатель знает полный размер своего буфера, а отправитель — нет. В качестве оценки он использует максимальное окно, которое видел в этом соединении. Получатель может позднее уменьшить буфер, и оценка устареет. Если бесконечно ждать доли старого максимума, правило укрупнения само создаст тупик. Таймер в итоге разрешает отправку вопреки ожиданию. RFC 9293 сохраняет рекомендуемый диапазон 0,1–1,0 секунды, но он не доказывает фактические настройки всех современных реализаций.

Сводная современная спецификация RFC 9293 сохраняет обязательство для обеих сторон. Она также проводит важную границу с алгоритмом Nagle. Nagle сдерживает малые сегменты, возникающие потому, что приложение выдаёт данные малыми порциями. SWS-алгоритм отправителя сдерживает малые сегменты, возникающие из-за малых продвижений правой границы приёмного окна. Механизмы дополняют друг друга, но работают с разными причинами.