#networking #tcp #wireshark
Вопрос:
У меня есть приложение, которое должно передавать данные между сервером и клиентом. Оба конца находятся за корпоративным брандмауэром, но они должны безопасно взаимодействовать. Я написал сервер ретрансляции TCP, который может устанавливать связь между 2 приложениями.
Моя проблема в том, что производительность TCP-потока теперь резко снизилась, и я хотел бы выяснить, почему. У меня размер буфера приема и отправки TCP установлен на 10 МБ для сервера, клиента и ретранслятора. Проблема с производительностью наиболее заметна при больших RTT, поэтому мой текущий RTT составляет 60 мс. Как только начальное рукопожатие выполнено, ретранслятор передает необработанные TCP-потоки между сервером и клиентом без дополнительного кадрирования.
Я проверил масштаб размера окна TCP, и он установлен правильно. Попытался выполнить поиск tcp.analysis.flags в wireshark, чтобы узнать, заполнено ли окно приема, но такого предупреждения никогда не создавалось.
Что я могу сделать, чтобы понять, почему производительность так падает? Заранее благодарю вас!
Вот некоторые данные, которые мне удалось собрать с помощью Wireshark:
- Загрузка однорангового:
- [Расчетный размер окна: 10485504]
- [iRTT: 0,062404000 секунд]
- [Байт в полете: 163200] (прямо перед снижением скорости)
- [Байты, отправленные с момента последнего флага PSH: 217600] (прямо перед падением скорости)
- Загрузка однорангового:
- [Расчетный размер окна: 10485760]
- [iRTT: 0,061190000 секунд]
Захват, показывающий точку, когда скорость падает (Желтый=одноранговый узел загрузки, Голубой=одноранговый узел загрузки)
Загрузка графика пропускной способности однорангового узла
Загрузка графика пропускной способности однорангового узла
Комментарии:
1. Пропускная способность однорангового узла при загрузке выглядит как контроль перегрузки поведения. В вашей трассировке, считывающей с начала синего цвета, у вас есть 4 пакета, помеченных как «TCP dup ack», затем пакет, помеченный как «Быстрая повторная передача TCP». Это я бы расценил как указание на то, что контроль за перегрузкой вот-вот начнется. Я не уверен, что означают все эти «tcp не в порядке», но они могут быть обычными операциями «быстрой повторной передачи». Контроль за перегрузкой определенно может ухудшиться с увеличением RTTs.
2. Итак, вам нужно в первую очередь выяснить, почему у вас есть дубликаты ack. Если происходит реальное отбрасывание пакета, то то, что вы видите, является предполагаемым поведением. Если это не так, вам следует проверить свое реле. Если падение действительно, возможно, что сетевой стек на ретрансляционной машине отбрасывает сегменты. В Linux вы можете проверить параметры в очередях интерфейсов, которые находятся где-то на уровне qdisc. В противном случае, если вы не можете настроить размеры очередей на коммутаторах/маршрутизаторах между ними, я не думаю, что вы можете что-то сделать. Это должно было так себя вести.
Ответ №1:
Оказывается, это было вызвано VPN-соединением, которое я использовал для имитации междугородних соединений. Как только я смог протестировать систему с реальными людьми на другом конце света, проблема исчезла, и вместо всплесков я получил приятные волновые паттерны.