Я не знаю, относится ли этот вопрос к теме здесь, поэтому, пожалуйста, перенаправьте меня, если нет.
Пытаясь понять, как работает TCP, я смоделировал одноточечную связь с помощью симулятора ns-3. Установив полосу пропускания канала на 5 Мбит / с, подходящую частоту ошибок и задержку на 5 мс, я получил необработанные данные около 4,9 Мбит / с. Однако после увеличения линка до 50 Мбит / с я смог получить только 16 Мбит / с. Кроме того, уменьшение задержки до 1 мс увеличивает пропускную способность до ~ 40 Мбит / с.
Может кто-нибудь объяснить эту огромную разницу?
РЕДАКТИРОВАТЬ: Я понимаю, чем отличаются пропускная способность и задержка. Я просто хочу знать, глючит ли мой симулятор или это ожидается от TCP.
Вкратце: да, слишком большая задержка может снизить общую пропускную способность., и эффект более выражен для соединений последовательного типа, то есть: соединение, которое не может передавать больше данных, пока не будет получено ACK для предыдущей передачи.
Корреляция задержки / пропускной способности становится проблемой только тогда, когда два значения сильно различаются, например, при очень «широкой», но высокой задержке связи (или наоборот - очень низкой задержке, но чрезвычайно «узкой» связи).
Позвольте мне сделать пример, используя что-то столь же простое, как пинг 32 байта в WAN-соединении с задержкой около 50 мс (RTT 100 мс). С таким подключением вы можете отправить максимум 10 эхо-запросов по 32 бита, что в сумме составляет Только 320 бит / с в каждую сторону! Неудивительно, что пинг-наводнения явно не ждите подтверждения от другой стороны, иначе флуд не будет существовать.
Если вы не можете снизить задержку, как можно обойти проблему? В основном двумя способами:
TCP использует обе системы: после установления потокового соединения (например, при запуске загрузки) размер пакета увеличивается до максимального значения (MSS - максимальный размер сегмента) и количество пакетов, отправленных без ожидания какого-либо подтверждения / подтверждения - иначе Масштабирование окна TCP. Много работы было потрачено на создание сетевого стека, способного динамически регулировать масштабирование окна TCP, поэтому в настоящее время его редко нужно настраивать вручную. Однако иногда плохой сетевой драйвер и / или странный случай могут помешать правильному масштабированию, что приведет к снижению пропускной способности.
Протоколы, которые изначально не реализуют масштабирование окна (например, IP и UDP), более чувствительны к проблеме пропускной способности и, как правило, нуждаются в помощи со стороны приложения более высокого уровня (где это возможно) или специальной настройки системы (например, увеличение максимального размера пакета, известен как MTU).
Очевидно, что соединения WAN, из-за присущей им более высокой задержки, более подвержены этой проблеме. Однако это может повлиять даже на очень быстрые локальные соединения.
Рассматриваемые случаи:
Слишком долго для комментария, но не совсем полный ответ, но задержка может повлиять на пропускную способность (пропускная способность - фиксированное свойство):
Сетевой стек TCP должен хранить в памяти копии всех переданных пакетов до тех пор, пока он не получит подтверждение от получателя, что пакет был получен, чтобы пакеты можно было повторно передать в случае потери пакета.
Минимальный размер этого буфера - это простое умножение:
<throughput> * <roundtrip time> = <retransmit buffer size>
то есть для поддержки максимальной пропускной способности для гигабитной сетевой карты со временем прохождения туда и обратно (= задержкой) 0,2 миллисекунды в вашей локальной сети необходимый буфер повторной передачи будет:
(1Gigabit/s = 10^9 bit/s) * 0.0002 s = 200000 bits = 25 Kb
Довольно скромная сумма. Более реалистичная задержка WAN составляет 2 миллисекунды, и вам потребуется 250 КБ.
Если ваш сетевой драйвер динамически не регулирует объем памяти, выделенный для размера вашего буфера повторной передачи TCP, этот буфер фактически становится ограничителем пропускной способности, которую ваша система может поддерживать, независимо от доступной полосы пропускания в сети:
<max throughput> = <retransmit buffer size> / <roundtrip time>
И любое увеличение задержки снижает эффективную пропускную способность вашей системы.
Теперь представьте, что вместо LAN / WAN с низкой задержкой тот же буфер 250 Кб установлен для подключения с высокой задержкой и высокой пропускной способностью, например, для спутникового восходящего канала с типичной задержкой 500 мс, и ваша пропускная способность ограничивается:
250 Kb / 0,5 s = 2 000 000 / 0,5 = 4 Mbit/s
а не пропускную способность 1 Гбит, которую может поддерживать спутниковое интернет-соединение (согласно Википедия)
Пропускная способность = Емкость
Задержка = задержка
Представьте, что у меня есть бассейн на 500 галлонов, и у меня есть ведро на 1 галлон для воды и ведро на 5 галлонов для воды. У меня уходит 1 минута, чтобы перенести ведро из водопровода в бассейн. Если я использую только ведро на 1 галлон для наполнения бассейна, тогда мне нужно будет совершить 500 поездок, что в сумме составит 500 минут времени, потраченных на перенос воды из источника воды в бассейн. Если я использую только 5-галлонное ведро для наполнения бассейна, мне нужно совершить всего 100 поездок, что в сумме составит 100 минут времени, потраченных на перенос воды из источника воды в бассейн.
Время, необходимое для ходьбы до бассейна (задержка), не влияет на количество воды, которое я могу унести с каждым ведром (пропускная способность), и, наоборот, размер ведра (пропускная способность) не влияет на время, необходимое для ходьбы до бассейна. пул (задержка).
Конечным результатом является то, что при использовании ведра на 5 галлонов бассейн будет заполняться в 5 раз быстрее, чем при использовании ведра на 1 галлон, потому что ведро на 5 галлонов больше, а не потому, что оно быстрее.