Сервер занимает слишком много времени, чтобы отправить FIN, ACK
У меня есть мобильное приложение (в перехвате 186.18.33.118) Запрос данных с какого-то простого http-сервера из php api (200.80.41.246).
Когда я отправляю запрос из своего приложения, я не могу получить доступ к веб-серверу с той же локальной сети, которая отправляет запрос, в течение минуты.
Сервер является apache Centos 7 и все обновления.
Я анализирую с помощью tcpdump пакеты между сервером и моим приложением (ниже показан захват при запросе от приложения к серверу и после того, как из моего браузера на сервер открыть с помощью wireshark).
Странно все, что я вижу, что сервер слишком долго отправляет пакет FIN, ACK
Что может быть не так?
EDIT / ADD
(шаги, как я делаю захват)
-
Я открыл приложение в телефоне (это приложение обращается к WordPress, установленному на сервере 200.80.41.246)
-
через несколько секунд я попытался войти из браузера (из той же локальной сети, которая подключена к мобильному телефону) в WordPress
-
сервер приносит мне сообщение: тайм-аут ошибки (около пакета 45)
-
поэтому я пробую много раз и через минуту соединение работает нормально (около пакета 110)
РЕДАКТИРОВАТЬ 2
Я сделал сравнение между запросом к API из браузера и из приложения, потому что когда я делаю запрос из браузера, это не вызывает проблем, и я обнаружил разницу в том, что браузер отправляет RST-пакет, который приложение не делает Отправить.
Ниже я оставляю картинку, сверху — запрос из браузера, а снизу — запрос из приложения.
анализируемый захват проволочной акулой
Какие-либо предложения?
Решение
Анализируя конфигурации соединений в Linux, я обнаружил два параметра, которые позволяли повторно использовать ранее закрытые соединения, которые были включены. Когда я хотел получить доступ с другого устройства с тем же общедоступным IP-адресом, который был до того, как открытое соединение вступило в конфликт, и было бы новое соединение, отключить и теперь работает правильно.
Параметры:
net.ipv4.tcp_tw_recycle
net.ipv4.tcp_tw_reuse
Они были на 1 (включены)
Чтобы отключить выполнение команд
Sysctl net.ipv4.tcp_tw_recycle = 0
Sysctl net.ipv4.tcp_tw_reuse = 0
Другие решения
Здесь нужно знать две вещи: 1. Конечный автомат TCP для соединения. 2. Таймеры TCP, связанные с закрытием соединения.
Всего есть 7 таймеров TCP, из которых «максимальное время жизни сегмента « и таймеры «повторной передачи» вступают в действие в контексте закрытия соединения.
Теперь о состояниях TCP: клиент может инициировать закрытие соединения или сервер может это сделать.
«Сервер отправляет клиенту пакет с установленным битом« FIN ». В этот момент сервер находится в состоянии FIN_WAIT_1. Клиент получает пакет FIN и переходит в состояние CLOSE_WAIT и отправляет пакет подтверждения обратно на сервер. Когда» сервер получает этот пакет, он переходит в состояние FIN_WAIT_2. С точки зрения сервера, соединение теперь закрыто, и сервер больше не может отправлять данные. Однако, согласно протоколу TCP, клиент должен завершить работу, также отправив пакет FIN, который должен быть подтвержден реализацией TCP сервера. Сервер должен закрываться через период времени, определенный максимальным временем жизни сегмента (MSL). «
В любое время, если отправитель не получает подтверждение, он запускает повторную передачу.
Вы должны искать в вашем конкретном случае:
1 — это MSL, играющая роль в упомянутой вами задержке.
2 есть ли повторные передачи? Есть ли ложные ретрансляции?
Будет полезно, если вы поделитесь tcpdump. Обычно пакет FIN отправляется после определенного значения времени ожидания, которое зависит от ОС.
В Linux I значение по умолчанию составляет 60 секунд.
Смотри сюда: Параметры TCP, ядро Linux
Редактировать:
Я посмотрел на захват и есть несколько вещей:
-
Повторная передача TCP происходит, когда сервер просто не отвечает на запрос SYN с пакетом [SYN, ACK]. Он пытается открыть много сеансов для сервера, но сервер не отвечает (~ 20 сеансов). Повторная передача TCP является частью протокола TCP, где она отправляет повторную передачу после 3, 6, 12, 24 и т. Д. (Зависит от реализации стека TCP), когда не получает ответ, так что это нормальное поведение.
-
В следующий раз сервер ответит через ~ 48 секунд (с первого SYN без ответа). Я предполагаю, что сервер не закрывает сеанс и не принимает другие сеансы в течение этого времени.