Продолжаю тему про протокол TCP, на мой взгляд есть весьма интересная информация об этом протоколе – размер окна. Наверняка много раз слышали или встречали это понятие, но как понять что же это такое? Попробую объяснить доступно.
Для начала советую ещё раз ознакомиться со статьей про установку TCP соединения.
Так вот, когда соединение уже установлено, клиент должен послать подтверждение о приёмке. В противном случае будет считаться, что пакет не получен и требуется переотправка. А теперь представим ситуацию, что передать нужно большой файл, который не влезет целиком в MTU. Файл будет отправляться “кусками”, которые будут собираться на клиенте в один файл. Внимание. А подтверждения нужно посылать после каждого куска? Оказывается, можно посылать подтверждения сразу за несколько пакетов, что здорово экономит обратный трафик и ускоряет передачу (не нужно ждать каждый раз ответа), тут каждый раз учитывается время прохождения пакета в сети (дважды, причём).
Этот параметр и называется размер окна. Количество сегментов(байт), которые могут быть приняты без подтверждения. Подтверждение же, при переполнении окна, высылается сразу за все предыдущие пакеты.
В примере ниже размер окна = 3. То есть подтверждение приёма посылается после каждого 3-го пакета. Полученное подтверждение означает, что все пакеты до этого номера были получены.
Перед началом обмена получатель и отправитель договариваются о размере своих окон.
Кроме того, размер окна может динамически меняться, что может быть вызвано проблемами с каналом (высокая загрузка сети), вплоть до установки размера в 0, что прекращает дальнейший приём до тех пор, пока не будет послано другое значение размера окна.
Вот пример:
После того, как были отправлены 3 сегмента, получатель отправил пакет с ACK 3, (а не 4, как в предыдущем примере), то есть повторная передача сегмента 3 потребовалась, в то же время был отправлен размер окна 2. Отправитель получив ACK 3 будет отправлять сегменты начиная с 3-го, в количестве 2 штук (размер окна получателя).
Из-за чего мог возникнуть подобный сбой? Да что угодно, лавинный флуд канала, отчего пакет не пришел в установленный временной интервал. В случае таких сбоев предусмотрено так называемое Congestion Window Size (размер окна перегрузки), который обычно равен размеру окна получателя, но в случае обнаружения подобных проблем с доставкой, уменьшается вдвое, регулируя таким образом оптимальный объем передачи.
Прикольный процесс, не так ли? Но бывает ситуация, когда такая синхронизация размеров окон перегрузки начинает образовывать волны перегрузок. Все клиенты в сети, встретив “затык”, уменьшают своё окно и пропускная способность канала возрастает. Они, видя это, вновь увеличивают окна (одновременно), и вновь образуется “пробка”. Вот такие скачкообразные колебания трафика в сети и называются глобальной синхронизацией TCP – есть негативный процесс.
Comments: