Повторная передача по одному TCP вызывает задержку 15 секунд на беспроводном

602
mythos

У меня странная проблема, которая приводит к длительным задержкам http-запросов (в данном случае POST) к моему собственному веб-серверу. Это происходит только в том случае, если
- используется клиент Linux или Mac (с Windows в порядке), и
- используется беспроводное соединение, кабельное соединение в порядке.
Это происходит на частотах 2,4 ГГц и 5 ГГц. На полосе 5 ГГц активны только 3 другие точки доступа, и я выбрал канал, который далек от этого (автоматическая настройка точки доступа также не улучшает ситуацию). Таким образом, я исключаю внешние помехи беспроводной связи как причину. Большинство (все?) Других веб-сайтов по той же беспроводной сети в порядке.

Wireshark говорит мне, что разница между кабельным и беспроводным соединением заключается в ретрансляции TCP. Это приводит к задержкам в 10-20 секунд. На следующем изображении показано
- linux по беспроводной сети -> повторная передача и задержка
- окна по беспроводной сети (тот же клиент) -> повторная передача, без задержки
- linux по кабелю -> нет повторной передачи

enter image description here

Это происходит не для всех запросов, а для большинства из них. Однако повторная передача всегда находится в одной и той же точке сообщения (ответ 200 OK на запрос POST).

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

Вот некоторые подробности по настройке:
- Сервер под управлением Ubuntu 14.04, ядро ​​3.13.0-042stab108.2 (внутри ВМ)
- Клиентское устройство под управлением Ubuntu 12.04.5, ядро ​​3.2.0-97-generic, драйвер iwlwifi, Centrino Advanced -N 6230 AGN REV = 0xB0
- устройство находится в локальной сети, NAT выполняется маршрутизатором / Wi-Fi AP FritzBox 7390, работает под управлением FRITZ! OS 06.30

1
Это очень интересный вопрос. Пожалуйста, отредактируйте свой вопрос, чтобы добавить больше деталей. На каком устройстве была сделана эта трассировка пакетов? Какие именно версии ОС задействованы? Есть ли какие-либо из этих устройств за шлюзом NAT? Как выглядят трассировки пакетов рабочего случая (особенно в случае Windows)? Можете ли вы включить полный сеанс TCP в предоставленные вами трассировки пакетов? - Я хочу увидеть рукопожатие и кадры данных, которые позже будут подтверждены. Что такое MTU пути между клиентом и сервером? Вы говорите, что это всегда сообщение "200 OK", которое теряется? Spiff 8 лет назад 0
Спасибо за просмотр этого @Spiff и счастливого нового года! Я обновил свой вопрос с дампами Wireshark для трех случаев. На самом деле раньше я не был уверен: повторная передача TPC также присутствует в Windows, но не вызывает задержки. После подключения нет повторной передачи. MTU пути в соответствии с tracepath - 1500. Каким образом вы хотели бы получить полный сеанс TPC (просто как скриншот Wireshark - чуть больше, чем я, или больше подробностей?). mythos 8 лет назад 0

0 ответов на вопрос

Похожие вопросы