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