LINUX.ORG.RU
Форум — Admin  

nginx, tcp и потеря пакетов.


0

2

Ситуация такая, сайт часто стал быть недоступен из-за сетевых проблем, я то их не ловил не разу, но люди жалуются. В логах я ничего подозрильного не нашел. Решил глянуть дампы с 2х сторон. На сервере 

15:17:57.119931 IP 1.1.1.1.61403 > 2.2.2.2.80: Flags [S], seq 2864988994, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
15:17:57.119945 IP 2.2.2.2.80 > 1.1.1.1.61403: Flags [S.], seq 2501375397, ack 2864988995, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 9], length 0
15:17:57.195429 IP 1.1.1.1.61403 > 2.2.2.2.80: Flags [.], ack 1, win 256, length 0
--
15:17:57.196836 IP 1.1.1.1.61403 > 2.2.2.2.80: Flags [.], seq 1:1461, ack 1, win 256, length 1460
15:17:57.196844 IP 1.1.1.1.61403 > 2.2.2.2.80: Flags [P.], seq 2276:2397, ack 1, win 256, length 121
--
15:17:57.496553 IP 1.1.1.1.61403 > 2.2.2.2.80: Flags [.], seq 1:1461, ack 1, win 768, length 1460
15:17:58.096696 IP 1.1.1.1.61403 > 2.2.2.2.80: Flags [.], seq 1:1461, ack 1, win 256, length 1460
15:17:59.296000 IP 1.1.1.1.61403 > 2.2.2.2.80: Flags [.], seq 1:537, ack 1, win 768, length 536
15:18:01.693065 IP 1.1.1.1.61403 > 2.2.2.2.80: Flags [.], seq 1:1461, ack 1, win 256, length 1460
15:18:04.096969 IP 1.1.1.1.61403 > 2.2.2.2.80: Flags [.], seq 1:1461, ack 1, win 256, length 1460
15:18:08.894512 IP 1.1.1.1.61403 > 2.2.2.2.80: Flags [.], seq 1:1461, ack 1, win 768, length 1460
15:18:18.494706 IP 1.1.1.1.61403 > 2.2.2.2.80: Flags [R.], seq 1461, ack 1, win 0, length 0

со стороны клиента 

15:17:55.022543 IP 192.168.1.21.61403 > 2.2.2.2.80: Flags [S], seq 2864988994, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
15:17:55.098483 IP 2.2.2.2.80 > 192.168.1.21.61403: Flags [S.], seq 2501375397, ack 2864988995, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 9], length 0
15:17:55.098571 IP 192.168.1.21.61403 > 2.2.2.2.80: Flags [.], ack 1, win 256, length 0
--
15:17:55.098837 IP 192.168.1.21.61403 > 2.2.2.2.80: Flags [P.], seq 1:2276, ack 1, win 256, length 2275
15:17:55.098861 IP 192.168.1.21.61403 > 2.2.2.2.80: Flags [P.], seq 2276:2397, ack 1, win 256, length 121
--
15:17:55.398358 IP 192.168.1.21.61403 > 2.2.2.2.80: Flags [.], seq 1:1461, ack 1, win 256, length 1460
15:17:55.998397 IP 192.168.1.21.61403 > 2.2.2.2.80: Flags [.], seq 1:1461, ack 1, win 256, length 1460
15:17:57.198462 IP 192.168.1.21.61403 > 2.2.2.2.80: Flags [.], seq 1:537, ack 1, win 256, length 536
15:17:58.398515 IP 192.168.1.21.61403 > 2.2.2.2.80: Flags [.], seq 1:537, ack 1, win 256, length 536
15:17:59.594561 IP 192.168.1.21.61403 > 2.2.2.2.80: Flags [.], seq 1:1461, ack 1, win 256, length 1460
15:18:01.998675 IP 192.168.1.21.61403 > 2.2.2.2.80: Flags [.], seq 1:1461, ack 1, win 256, length 1460
15:18:06.795902 IP 192.168.1.21.61403 > 2.2.2.2.80: Flags [.], seq 1:1461, ack 1, win 256, length 1460
15:18:16.397355 IP 192.168.1.21.61403 > 2.2.2.2.80: Flags [R.], seq 1461, ack 1, win 0, length 0

первые 3 пакета установка tcp соединения

далее клиент посылает 2 пакета(на самом деле видимо 3, но wireshark собрал первые 2 в 1), POST запрос. До сервера долетает только первый и третий пакет.

Далее клиент начинает повторять запросы, но начиная с первого пакета. Сервер на это никак не реагирует.

Собсно вопрос, кто из них ведет себя правильно.

★
← Автозапуск приложения
Exim Perl и DKIM →

А почему сервер не отвечает никак на пакеты от клиента (кроме первого SYN)? Мне кажется, это не нормально.

generator ★★★
()
Ответ на: комментарий от generator

Полный POST запрос улетает от клиента в 3х пакетах, долетает до сервера только первый и третий, т.е. до nginx'а не дошел полный запрос, ему просто не на что отвечать пока.

С другой стороны, клиент начинает повторять пакеты с seq=1, а сервер уже ждет пакеты с seq 1461.

swelf ★
() автор топика
Ответ на: комментарий от swelf

т.е. до nginx'а не дошел полный запрос

А nginx-то при чём? Я ж про TCP говорю. ACK-то не nginx посылает, а ядро (сетевой стек).

Хотя я здесь скорее диванный кокоретик, могу ошибаться :)

generator ★★★
()
Последнее исправление: generator (всего исправлений: 1)
Ответ на: комментарий от generator

Я ж и говорю, сервер получил 1460 байт данных. И ждет 1461ый байт, а клиент перепосылает ему снова эти 1460 байт.

swelf ★
() автор топика
Ответ на: комментарий от swelf

сервер получил 1460 байт данных

Он должен сообщить об этом клиенту, то бишь послать пакет с флагом ACK и номером последовательности, которую он ждёт в следующем пакете - 1462 (1461+1). Но он не посылает подтверждение. Следовательно, клиент считает, что этот пакет до сервера не дошел и шлёт его заново. Логично?

UPD. 1461 должно быть в поле подтверждения конечно же.

generator ★★★
()
Последнее исправление: generator (всего исправлений: 1)
Ответ на: комментарий от vel

У мту другие симптомы, тем более, как выше заметили, сервер должен отвечать на первый пакет с данными ack пакетом.

swelf ★
() автор топика
Ответ на: комментарий от swelf

15:17:55.098837 IP 192.168.1.21.61403 > 2.2.2.2.80: Flags [P.], seq 1:2276, ack 1, win 256, length 2275

У клиента длина пакета 2275 байт - это значит что у него включено tso/gro.

Попробуй для начала отключить tso и gro и повторить.

C tcp-шным коннектом (3 первых пакета) как раз проблем нет.

vel ★★★★★
()
Ответ на: комментарий от vel

Проблему надо решать не на всех клиентах, а на 1 сервере. Была бы проблема в клиентах, касалась бы всего интернета а не 1 сайта.

Да и это не повод серверу не отвечать ack пакетом на пришедшие данные.

swelf ★
() автор топика
Ответ на: комментарий от swelf

На данный момент в распоследних ядрах (начиная с момента выхода 3.4.92) есть проблемы с gro.

forwarding с включеным gro на e1000e дает почти удвоение трафика или существенное снижение скорости.

Выключить их не сложно «ethtool -K ethX gro off tso off» (сначала на сервере, потом на клиенте), но одну из возможных проблем ты отсечешь.

Хорошо бы посмотреть трафик рядом с клиентом - если он не посылает второй сегмент от пакета в 2275 байт (из-за кривого tso), то сервер в этом не виноват.

vel ★★★★★
()
Ответ на: комментарий от vel

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

Скорее сегмент теряется из-за общих потерь до хостера(хецнера) у клиента, пинги теряются.

Проблемы пока только в связке конкретный клиент(офис) - конкретный сервер, из дома у него все работает.

swelf ★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Автозапуск приложения
Admin
Exim Perl и DKIM →