Медленные загрузки? Убедитесь, что ваше окно (масштабирование) не сломано

Если вы столкнулись с очень низкими скоростями загрузки на том, что должно быть высокоскоростным каналом, одна из наиболее вероятных причин связана с тем, что масштабирование TCP-окна не поддерживается или не реализовано должным образом. Давайте подробнее рассмотрим масштабирование и то, как оно может значительно помочь улучшить скорость загрузки, а также то, где что-то может пойти не так, что приведет к снижению производительности.

Основы TCP

Когда две системы хотят надежно обмениваться данными через IP-сеть, они обычно используют TCP в качестве транспорта. TCP устанавливает сеанс с рядом взаимно согласованных параметров, передает данные и гарантирует доставку. Как указано в RFC 793, TCP обеспечивает надежный транспорт по сетям, которые могут быть ненадежными.

Благодарности

В сеансе TCP отправляющая система и принимающая система согласовывают параметры, чтобы помочь отслеживать обмен данными, и используют серию отправок, за которыми следуют подтверждения для подтверждения доставки. Система-отправитель отправляет определенный объем данных, а затем ждет подтверждения, прежде чем отправлять дальнейшие данные. Если подтверждение так и не было получено, предполагается, что данные также не были получены, поэтому отправитель повторно отправляет сообщение, и процесс повторяется до тех пор, пока не будут отправлены все данные. Хотя это гарантирует доставку, это дорого с точки зрения времени и полосы пропускания, поскольку для обмена подтверждениями требуется полоса пропускания, а время, в течение которого TCP ожидает этих подтверждений, увеличивается при передаче больших объемов данных.

Задержка

Под задержкой понимается время, необходимое пакету для прохождения от отправителя к получателю. Это (обычно) измеряется в миллисекундах, и каждое промежуточное устройство между отправителем и получателем (маршрутизаторы, прокси, балансировщики нагрузки и т. Д.), Которое должно обрабатывать данные, увеличивает задержку. Занятые сети также увеличивают задержку, и, конечно, чем дальше друг от друга находятся отправитель и получатель, тем выше будет задержка. Поскольку это время требуется для того, чтобы пакет дошел от отправителя до получателя, чем выше задержка, тем хуже общая пропускная способность, и чем больше объем передаваемых данных, тем более очевидным это становится. Все эти миллисекунды ожидания ACK складываются. Таким образом, если бы существовал способ уменьшить количество требуемых ACK за счет увеличения объема данных, которые могут быть отправлены, передача была бы быстрее, поскольку для передачи фактических данных использовалась бы большая пропускная способность, и меньше времени тратилось бы на ожидание ACK.

Буферы

По сравнению с системами, использовавшимися при разработке TCP, сегодняшние хосты имеют значительно больше памяти для хранения данных. Буферы используются для хранения сегментов данных при передаче, чтобы их можно было собрать для завершения передачи данных. Чем больше памяти выделено для буфера, тем больше данных может быть передано до того, как потребуется подтверждение. Объем данных, которые могут быть помещены в буфер перед отправкой подтверждения, согласовывается между отправителем и получателем во время установления сеанса TCP (трехстороннее рукопожатие). Чем больше буфер, часто называемый значением размера окна, тем выше общая производительность, поскольку это означает меньшие накладные расходы. Здесь мы видим, что окно размером 8 КБ согласовывается в SYN ACK от целевой системы.

Значение размера окна представлено 16-битным числом, что означает, что максимальное значение, которое теоретически может быть, составляет 64 КБ с использованием только параметров TCP. Но есть варианты.

Масштабирование окна TCP

По мере того, как сети становились более надежными, а системные ресурсы увеличивались, был опубликован RFC 1323, «Расширения TCP для высокой производительности» (и позже обновленный RFC 7323), в котором была представлена концепция масштабирования окна TCP для увеличения согласованного размера буфера с максимальных 64 КБ до колоссальный 1 ГБ, хотя очень редко две системы имеют столько памяти, которую они могут выделить для буферизации передачи данных. Как это работает? Опция масштабирования окна TCP отображает еще 16 бит (14 бит шкалы), так что размер окна TCP может быть увеличен на 2 ^ # битов, выделенных в масштабе окна. Хотя на приведенном ниже снимке экрана показан размер окна TCP, равный 8 КБ, посмотрите ниже, где установлен коэффициент масштабирования.

Масштаб окна установлен на 8, что соответствует 2 ^ 8, что составляет 256. Умножьте окно размером 8 КБ на 256, чтобы получить общий размер 2048 КБ, прежде чем должен быть отправлен ACK. По каналу с высокой задержкой это действительно может добавиться. Без включенного/поддерживаемого коэффициента масштабирования, чем выше задержка, тем сильнее влияние. Взгляните на эти диаграммы от Microsoft, которые показывают теоретическую максимальную пропускную способность по каналу 1 Гбит/с при различных значениях задержки.

А вот тот же 1Gbps канал с включенным масштабированием.

Как видите, даже на канале с очень низкой задержкой разница в пропускной способности огромна! Но при загрузке с веб-сервера на другом конце вашего континента с включенным масштабированием вы получаете потенциальную пропускную способность на три порядка выше. Конечно, по ряду факторов это будет не так быстро, но это иллюстрирует важность коэффициента масштабирования.

Маршрутизаторы, VPN и прокси, о боже!

Теперь, когда вы понимаете, что делает TCP Scale Factor, при устранении неполадок с низкой пропускной способностью это одна из первых (и самых простых) вещей, которые нужно проверить. Все современные операционные системы поддерживают TCP Scale Factor. RFC, определяющий его, был впервые опубликован в 1992 году, и все операционные системы Windows, Linux и Mac поддерживают его. Но есть ряд сетевых устройств, которые этого не делают либо из-за возраста, либо из-за преднамеренной настройки. В частности, прокси-серверы могут уменьшать или полностью исключать коэффициент масштабирования TCP, чтобы справляться с нагрузкой нескольких одновременных пользователей. Обычно прокси-серверы от многих поставщиков изначально устанавливают более низкий коэффициент масштабирования и дополнительно уменьшают или устраняют его в ответ на высокий спрос. Конечно, этот прокси защищает вас от плохих вещей, но какой ценой?

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

Обратите внимание, что при захвате в TCP SYN, в разделе TCP, после флагов и опций показано 12 байт. Вы должны увидеть, что это доходит до сервера, и ответ сервера должен быть на уровне окна или близко к нему. Занятые серверы могут уменьшить шкалу до 4 или даже 2, если они очень загружены.

Вот еще более очевидный признак того, что что-то не так, и вам даже не нужно расширять пакеты. Посмотрите на SYN, у которого WS = 256, что означает, что коэффициент масштабирования Windows установлен на 2 ^ 8. SYN ACK возвращается, а WS даже не отображается в ответе!

Расширяя это, мы видим, что SYN предлагает коэффициент масштабирования окна.

И SYN ACK его полностью игнорирует!

Если вы видите это, то вы знаете, что что-то убивает коэффициент масштабирования TCP, что, в свою очередь, снижает вашу производительность. Вам может потребоваться некоторое время, чтобы определить, какое устройство это делает, но начните с вашего прокси-сервера, и в девяти случаях из 10 вы обнаружите виновника. Например, некоторые модели Bluecoat по умолчанию вообще не поддерживают TCP Window Scale, но их можно включить простым набором команд и перезагрузкой.

поймать волну

Если ваши загрузки или тесты скорости не соответствуют предполагаемой пропускной способности вашей ссылки, не вините сразу своего интернет-провайдера. Выполните трассировку, посмотрите на коэффициент масштабирования окна TCP и, если он не используется, начните анализировать свою сетевую инфраструктуру. Этот единственный вариант может иметь огромное значение для общей производительности сети.