Масштабирование окна TCP для спутниковых подключений
Спутниковая связь обычно имеет RTT около 500 мс. Соединения, как правило, страдают от неоптимальных скоростей передачи, несмотря на большие объемы полосы пропускания, поскольку подтверждение TCP занимает слишком много времени для получения.
Насколько я понимаю, хорошим способом решения этой проблемы с TCP-соединениями является установка размера окна TCP на скорость соединения (в битах), умноженную на RTT (в секундах). Таким образом, соединение со скоростью 1 Мбит / с через спутник должно иметь размер окна 512 КБ.
Какие подводные камни связаны с этим? Существуют ли другие подобные настройки, которые необходимо оптимизировать для спутниковой связи? Я понимаю, что многие современные операционные системы будут автоматически изменять размер окна, но будут ли они достаточно агрессивными, чтобы сделать размеры окна достаточно большими, чтобы работать для спутниковой связи?
Кроме того, я собираюсь предположить, что большой размер окна нежелателен в сетях, которые часто отбрасывают пакеты, так как повторная передача будет иметь размер окна, и вы можете выделить большую часть своей полосы пропускания для накладных расходов на повторную передачу.
Спасибо, я все еще многому учусь по работе в сети и ценю ваш вклад.
3 ответа
Как правило, вы должны использовать стек TCP, который реализует правильное масштабирование окна. Но, конечно, вы правы в том, что размер вашего окна должен соответствовать продукту полосы пропускания (BDP). В случае, если у вас изменяющийся BDP, вы можете установить размер окна на то, что вы ожидаете в обычном "худшем" случае. Интересно, что большинство соединений не страдают слишком сильно, если размер окна больше, чем BDP (конечно, оно не должно быть слишком большим), но показывают сниженную производительность, если размер окна намного меньше, чем BDP.
Чтобы проверить, правильно ли ваш стек TCP/IP увеличивает размер окна, вы должны использовать Wireshark или любой другой анализатор трафика. Вы можете непосредственно посмотреть на флаг размера окна в заголовке (с учетом масштабирующих факторов!). Wireshark также может показывать эффективный размер окна, принимая во внимание коэффициент масштабирования.
Посмотрите этот урок о том, как изобразить размер окна TCP как функцию времени здесь.
Это абсолютно академично, потому что никто не запускает TCP через спутниковые соединения. Я не знаю ни одного спутникового провайдера, который бы это делал. Все они запускают специфические для спутника протоколы через спутник и размещают конечную точку TCP на наземной станции.
Когда компьютер в сети отправляет пакет SYN TCP на спутниковый терминал, спутниковый терминал отправляет запрос прокси TCP на спутник. Это дает указание наземной станции открыть TCP-соединение с каким-либо сервером в Интернете. Наземная станция разговаривает по TCP с интернет-сервером. Спутниковый терминал не говорит по TCP через спутник, а говорит по протоколу, оптимизированному для использования со спутника. Наземная станция действует как прокси между спутниковым терминалом и интернет-сервером.
Для удобства доступны калькуляторы продуктов с задержкой пропускной способности - один такой калькулятор здесь. Что касается больших окон, вызывающих проблемы в случае потери пакетов - именно поэтому TCP-окна являются переменными. При потере пакета размер окна уменьшится, что позволит уменьшить объем данных в полете и, как следствие, снизить скорость передачи. Через некоторое время размер окна будет пересмотрен.
Ваша задержка на самом деле не так уж и плоха для спутника - 1с RTT @ 1M - это всего лишь 125K окно. Множество современных операционных систем могут легко поддерживать это сразу, поэтому дополнительные модификации могут не потребоваться.
Кроме того - некоторым очень повезло с различными оптимизаторами WAN, доступными на рынке. Они имеют тенденцию как оптимизировать размеры окна TCP, так и использовать кэширование и сжатие, чтобы как протолкнуть больше по каналу, так и улучшить видимую отзывчивость.