Автор: Александр Коленко
Привет, дорогой читатель!
Зарегистрируйтесь и получите доступ к бесплатному контенту. А также будьте в курсе нового учебного контента. Ссылка на учебную платформу:
Если материал полезен, то есть способ отблагодарить меня. Любая сумма будет отличной наградой и стимулом писать полезный контент для Вас.
Продолжаем тему TCP options и на очереди у нас опция Timestamps.
Сразу надо сказать, что далеко не всегда приложения реализуют данную опцию. Однако же если она все же реализуется, то вычисления RTO таймера производятся более точно.
TCP options - Timestamps включает в себя два параметра: Timestamp value (далее TSval) и timestamp echo replay (далее TSecr).
Проследим значения данных параметров на примере SYN запроса и SYN/ACK ответа, а потом я расскажу в чем суть. Итак рассмотрим дамп трафика:
Заглянем в TCP options - Timestamps каждого из трех пакетов
1-й пакет
2 -й пакет
3 -й пакет
TSval 1-го пакета = 1122369159 - относительная временная метка, обозначающая момент отправки SYN пакета. Данное значение выбирается отправителем псевдослучайно и не имеет ничего общего с реальным временем.
TSval 2-го пакета = 2226349661-время приема ответного пакета SYN/ACK. TSecr 2-го пакета = TSval 1-го пакета=1122369159.
Что делает хост инициатор? Он высчитывает разницу: RTT=TSval - TSecr
На основании меняющегося RTT участники обмена динамически формируют RTO таймер.
В данной статье я хотел бы еще описать такую TCP Option - SACK
SACK - selective acknowledgment
Данная опция позволяет сгладить нюанс использования окна, в рамках которого отправителем может передаваться n-е количество сегментов и уже только после отправки последнего сегмента ожидаться подтверждение.
В чем собственно нюанс? Предположим получатель анонсировал окно=1000 байт, MSS=200. Т.е. не сложно посчитать, что если у отправителя имеется к передачи в буфере 1000 байт, то он передаст последовательно 5 сегментов по 200 байт и будет ждать подтверждение! Что произойдет если, к примеру 3-й сегмент потеряется по дороге?
Не получив 3-й сегмент получатель говорит отправителю: "Знаешь что, попробуй с самого начала!". Вот и собственно нюанс! Не смотря на то, что 80% данных дошло успешно, без опции SACK (выборочного) подтверждения, отправителю приходится повторить передачу всех данных с самого начала. При использовании SACK обмен будет выглядеть следующим образом:
Профит - нет повторной передачи 800 байт.
Вопросы эффективности TCP
В первых реализациях протокола TCP столкнулись с проблемой которую впоследствии "обозвали" синдромом полного окна. Иногда встречается выражение "синдром бестолкового окна" .
Синдром полного окна, это когда после полного заполнения приемного буфера, сразу при малейшем его освобождении, получатель шлет подтверждение и анонс нового окна минимального размера. Отправитель воспринимает это как призыв к действию и сразу же досылает небольшое количество данных получателю. Возникает ситуация при котором получатель не успевает "прожевывать", а отправитель продолжает заносить почти пустую ложку. Это приводит к тому, что эффективность канала, т.е. соотношение полезные данные/служебные данные стремится к нулю.
Выходом из данной ситуации послужило внедрение в TCP эврестического алгоритма. Данный алгоритм запрещает получателю анонсировать окна небольшого размера в случае, если их прирост незначителен. Тут необходимо отметить, что понятие "значительный прирост", т.е. значительное высвобождение приемного буфера имеет конкретные значения. Стандарт определяет, что приемная сторона может анонсировать новое окно если освобождена минимум половина приемного буфера либо пространство в буфере, достаточного для приема сегмента максимальной длины (MSS).
Фактором не влияющим на RTT, однако снижающим эффективность канала, таким же образом как это происходило из-за синдрома полного окна, но уже на стороне отправителя является ситуация когда отправитель сразу же получив, пусть даже 8 байт данных отправляет их из исходящего буфера. Такая реализация также ведет к тому, что соотношение полезные данные/служебные данные стремится к нулю.
Выходом из такой ситуации является реализация механизма, обеспечивающего задержку отправки сегмента до тех пор, пока его размер не достигнет приемлемых значений. Данная методика называется накопление (clumping). Однако возникает вопрос до какого момента можно накапливать?
Ответ - сигналом к началу передачи накопленного служит момент получения сигнала подтверждения последнего сегмента.
Вспоминая, что TCP сессия это дуплексный обмен данными между двумя участниками, то для максимальной эффективности обе стороны должны в своей работе учитывать оба описанных выше механизма.
Описанная в этом разделе методика борьбы с синдромом полного окна на стороне отправителя называется алгоритмом Нейгла по имени его создателя. Ценность этой методики заключается в том, что для выполнения алгоритма не требуются серьезные вычисления. Узлу сети не нужно поддерживать работу отдельных таймеров для каждого соединения. При получении данных от прикладной программы модуль протокола не должен опрашивать значение таймера. Важнее всего тот факт, что эту методику можно использовать при любых значениях задержек в сети, максимальных размерах сегмента и скорости работы приложения. При нормальных условиях она не снижает пропускную способность сети.
Резюме
В современные реализации протокола TCP включен эврестический алгоритм подавления синдрома полного окна как на стороне отправителя, так и на стороне получателя. Суть его состоит в том, что получатель старается избежать анонсирования окон небольшого размера, а отправитель использует адаптивный алгоритм для задержки передачи сегментов. Это дает возможность отправителю собирать данные в сегмент большого размера.