TCP можно достичь более высокой скорости передачи с несколькими соединениями?

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


Может ли TCP отправлять данные так быстро, как это возможно, если получатель не сообщает о переполнении буфера с размером окна 0? Так что, если RTT, например, 60 секунд, это не влияет на курс вообще? Есть ли максимальный размер окна или что-то еще, ограничивающее скорость?

Ответ 1

Одно из преимуществ нескольких одновременных подключений может дать вам (с учетом тех же предостережений, о которых говорили голубь и Брайан), вы сможете лучше решить проблему слишком малого окна приема TCP.

Принцип, который относится к продукт задержки полосы пропускания. (Здесь более подробное описание здесь).

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

Более подробно рассмотрим следующее: у вас есть сквозная полоса пропускания 10 ^ 8 бит в секунду (10 мегабит/с) и задержка в оба конца 100 мс (0,1 секунды). Следовательно, может быть до 10 ^ 7 бит (10 мегабайт = ~ 1,25 мегабайт) данных, отправленных до того, как подтверждение первого бита данных вернется к отправителю.

Это будет зависеть от стека TCP вашей ОС, но нестандартное значение для размера окна приема TCP составляет 64 Кбайт. Это, очевидно, слишком мало, чтобы позволить вам в полной мере использовать пропускную способность от конца до конца; после отправки 64-килобайтных (512 тыс. бит) данных процесс отправки будет ожидать обновления окна от приемника, указывая на то, что некоторые данные были израсходованы до помещения каких-либо дополнительных данных в провод.

При открытии нескольких открытых сеансов TCP это происходит благодаря тому, что каждый TCP-сеанс будет иметь свои собственные буферы отправки/получения.

Конечно, в Интернете сложно определить истинную доступную сквозную пропускную способность из-за размера окна TCP, конкуренции и т.д. Если вы можете предоставить некоторые примеры, мы можем помочь больше.

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

Ответ 2

Если вы единственный в ссылке, это увеличит накладные расходы и уменьшит скорость. Однако при совместном использовании полностью насыщенной связи с другими, это способ игры в систему и увеличение общей скорости (каждое соединение будет медленнее, чем одно, но агрегат будет быстрее, так как теперь у вас есть больший процент "временные интервалы" (что означает технический термин "Это ускользает от меня сейчас" ).

Ответ 3

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

Ответ 4

Описание проблемы в Muz.

Имейте в виду, что использование этого может зависеть от реализации TCP в вашей операционной системе. В частности, для достижения наилучших результатов вам нужен стек TCP, который поддерживает параметр "Шкала окон" из RFC 1323.

Кроме того, вам может потребоваться настроить некоторые настройки ОС, чтобы сделать эту работу. В Windows есть параметр реестра TcpWindowSize, который вам может потребоваться настроить. Существует статья Microsoft KB 224829: Описание возможностей Windows 2000 и Windows Server 2003 TCP, в которой описывается, как это сделать.