TCP возможно ли добиться более высокой скорости передачи данных с несколькими подключениями? - PullRequest
13 голосов
/ 03 ноября 2008

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


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

Ответы [ 4 ]

18 голосов
/ 04 ноября 2008

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

Принцип, к которому это относится, - произведение задержки полосы пропускания . (Более подробное объяснение здесь ).

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

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

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

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

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

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

7 голосов
/ 03 ноября 2008

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

1 голос
/ 04 ноября 2008

Описание проблемы Муз находится на месте.

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

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

1 голос
/ 03 ноября 2008

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...