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