Автор: Александр Коленко
Привет, дорогой читатель!
Зарегистрируйтесь и получите доступ к бесплатному контенту. А также будьте в курсе нового учебного контента. Ссылка на учебную платформу:
Если материал полезен, то есть способ отблагодарить меня. Любая сумма будет отличной наградой и стимулом писать полезный контент для Вас.
Итак поговорим про потоки, сегменты и порядковые номера. Так же в этой части я затрону пожалуй самый главный функционал TCP: выбор размера окна, механизмы устранения перегрузки (congestion control), методику устранения перегрузки - multiplicative decrease, методику разгона после устранения перегрузки и после установления сессии.
Мы уже знаем, что поток данных от приложения разбивается на сегменты, а сегменты дальше передаются пакетами по объединенной сети. Для решения двух важных задач - повышения эффективности передачи данных и управления потоком данных-в протоколе TCP применяется механизм движущихся окон (описан в первой части данной статьи ). Помимо очевидного профита - увеличение суммарной пропускной способности сети за счет сокращения времени ее простоя механизм предоставляет получателю средства, позволяющие ограничить поток передаваемых данных в случае исчерпания буферного пространства приема данных.
Следует остановится на данном механизме чуть подробнее!
Данный механизм базируется на параметре "размер окна" в заголовке TCP сегмента. Данный параметр присутствует в любом типе сегмента (о типах сегментов скажу в Части 3). Этот параметр согласуется при установлении соединения и может динамически изменяться в процессе отправки подтверждения отправителю. Данный параметр завязан на текущее состояние буфера для приема потока данных. Если буфер переполняется, то приемная сторона уменьшает размер окна указывая отправителю чтобы тот сбавил "обороты" иначе наступит коллапс.
На рисунке выше изображен формат заголовка TCP. Поле параметра размера окна в красной рамке. Под поле размера окна отводится 16 бит. Т.е. максимальный размер окна может быть 65536 байт. И раньше этого значения было достаточно. Но с увеличением производительности систем, а в конкретном случае речь идет об оперативной памяти, ввели опцию, позволяющую увеличить данное значение за счет битового сдвига.
Еще раз распишу процесс:
1. Узел с IP адресом 10.159.114.35 отправляет партнеру TCP опцию с значением Window scale=3. Таким образом указанный узел сообщает партнеру, чтобы тот при формировании сегментов на передачу использовал не стандартное поле Window (16 бит), а поле Calculated window size (далее CWS) (19 бит)
Механизм управления потоком очень важен для работы реальной объединённой сети, состоящей из большого количества сетей разной протяженности и пропускной способности, соединенных маршрутизаторами различной мощности и скорости. Однако есть две проблемы не связанные между собой. Первая - управление потоком между отправителем и получателем. Эта проблема решается за счёт описанного выше механизма. Вторая проблема - это способ детекции и управлениями перегрузками возникающими на транзитных сетевых устройствах. Если промежуточное устройство не справляется с поступающим потоком данных, такая ситуация называется перегрузкой (congestion). При этом в действие приводятся механизмы устранения перегрузкой (congestion control). О перегрузке обычно свидетельствует резкое увеличение задержки при доставке, вызванное скоплением большого количества пакетов на одном или нескольких устройствах коммутации(маршрутизации). Тут необходимо понимать, что если на обоих концах TCP сессии резервируется оперативная память для этой сессии, то на промежуточных сетевых железках трафик обрабатывается безотносительно к сессиям. Трафик разных сессий обрабатывается на общих условиях: есть в очереди место - пакет помещается в неё до принятия решения о том куда дальше пакет отправлять, нет мест - пакет уничтожается. Конечные точки не знают в каком месте объединённой сети произошла перегрузка. Конечные точки лишь осознают факт того, что есть перегрузка по симптомам- увеличение задержки. К сожалению, в большинстве реализаций TCP модулей используется стратегия повторной передачи в случае истечения таймера RTO. Интенсивность снижается за счёт удвоения таймера RTO и в конечном счете сессия разрывается
(данный механизм описан в первой чести статьи). Но этого не достаточно для того, чтобы быстро разгрузить сеть и не вызвать эксплуатационный отказ в обслуживании (DoS). Таким образом трафик продолжает поступать в перегруженную сеть вызывая в конечном итоге полный затор в сети (congestion collapse).
Для предотвращения перегрузки в сети современная версия стандарта TCP рекомендует использовать две методики: медленный запуск (slow-start) и мультипликативное уменьшение (multiplicative decrease). Как работает механизм снижения нагрузки - multiplicative decrease?
TCP вводит дополнительно ограничение - "окно перегрузки". Т.е. получив от получателя его CWS, принимающий сравнивает CWS с значением окна перегрузки и выбирает меньшее из них:
Фактический CWS получателя=min(анонс CWS получателя, окно перегрузки)
В штатной ситуации, когда сессия только была установлена или идет обмен трафиком без задержек:
Фактический CWS получателя=анонс CWS получателя
Значение окна перегрузки высчитывается локально, на стороне отправителя. При вычислении TCP использует следующую логику и заложенные в нее соображения:
1. Если на отправленный пакет не поступило подтверждение в установленное RTO таймером время, то вероятнее всего пакет был отправлен в dev/null на перегруженном сетевом устройстве;
2. Учитывая первый пункт, помимо увеличения RTO, после не получения подтверждения на первую попытку повторной передачи отправитель уменьшает окно перегрузки в два раза. Если данная мера не меняет ситуацию, то TCP продолжает экспоненциально увеличивать RTO и экспоненциально уменьшать размер окна перегрузки;
3. Таким образом экспоненциально уменьшается и интенсивность повторных передач и поток в сторону получателя.
Теперь представим, что в некоторый момент времени, после снижения нагрузки, ситуация начала потихоньку выравниваться и можно увеличить интенсивность и обьем передаваемых данных. Но! Линейно или экспоненциально увеличивать обороты было бы не логично, чтобы не вызвать повторную перегрузку. И тут на сцену вступает механизм slow-start.
Методика медленного запуска предназначена для восстановления работоспособности сети после перегрузки, а также для начала передачи данных по новому соединению. При этом первоначальный размер окна перегрузки выбирается равным одному сегменту и каждый раз после получения подтверждения (ACK) о приеме он увеличивается на один сегмент.
Может показаться, что процесс возврата к исходной производительности затянут по времени, но на самом деле, если сеть действительно восстановилась, то много времени он не занимает. На первоначальном этапе старта размер CWS растет экспоненциально, но достигая половинного значения от изначального CWS (того, что было до возникновения перегрузки), модуль протокола переходит к фазе аннулирования перегрузки и снижает скорость наращивания размеров CWS. Во время этой фазы размер CWS увеличивается на 1 сегмент, только после получения подтверждения о получении всех сегментов окна.
На графике можете увидеть этот процесс наглядно;
Подводя итоги вышеописанных процессов и алгоритмов необходимо отметить, что методы медленного запуска, мультипликативного уменьшения, фаза аннулирования перегрузки и экспоненциального изменения значения тайм-аута позволяют существенно поднять производительность системы, работающей с использованием TCP без выполнения сложных математических расчетов внутри программы, реализующей функции этого протокола. В тех версиях протокола TCP, где применены все описанные методы, удалось поднять производительность системы от 2 до 10 раз по сравнению с реализациями, где одна или несколько методик не использовались.
Продолжение в следующей статье "TCP/IP (Часть 3) просто о сложном"
Перечень использованной литературы:
1. Сети TCP/IP (Дуглас, Камер);
2.Анализ пакетов. Практическое руководство по использованию Wireshark (Крис Сандерс);
3.Атака сетей на уровне протоколов (Джеймс Форшой).
