akbr1k
Junior Member | Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
За нарушение извиняюсь!
Я не грешу, так как если бы была явная проблема, она была бы со всеми хостами (или с большей частью), но, проблем ни с одним хостом явных я более не наблюдаю. Причем самое интересное, что smtp сессия не закрывается... Точнее закрывается через 4 суток... То есть они 4о суток обмениваются данными, это как!?
По поводу \r\n. разве непонятки? Со слов второй стороны происходит следующая картина:
Начало сессии:
5 0.000000 192.168.173.250 mx3.fclm.ru TCP 66 53414 → smtp [SYN, ECN, CWR] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
8 0.006888 mx3.fclm.ru 192.168.173.250 TCP 66 smtp → 53414 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=64 SACK_PERM=1
Обе стороны соглашаются с тем, что пакетов размером больше 1460 байт отправлять не стоит.
Спустя непродолжительное время ваша сторона отправляет пакет с пэйлоадом в 4096 байт.
43 0.000515 192.168.173.250 mx3.fclm.ru TCP 4150 53414 → smtp [PSH, ACK] Seq=121 Ack=285 Win=65280 Len=4096
При этом при всем в IP заголовке стоит DF флаг.
60 0.020062 mx3.fclm.ru 192.168.173.250 TCP 60 smtp → 53414 [ACK] Seq=285 Ack=3041 Win=64192 Len=0
Этот ack не относся ни к одному пакету, который отправлял ваш сервер: грубо и не совсем правильно говоря он подтверждает получение 3041 байта данных от вас, которые находятся в середине пакета 43, если быть точнее, то 3041 = 121(Seq num пакета 43) + 2*1460(MSS). Т.к. ack должен подтверждать прием данных в конце пакета, а не в середине, то TCP стеку на вашем сервере немножко рвет крышу и весьма скоро ваш сервер начинает повторно перепосылать нам пакеты (которые при этом по факту были получены и ack’нуты).
88 0.305694 192.168.173.250 mx3.fclm.ru TCP 1514 [TCP Retransmission] 53414 → smtp [ACK] Seq=12977 Ack=285 Win=65280 Len=1460
Ну и в конечном итоге сервер скатывается к отправке по пакету в минуту, а затем отваливается по таймауту.
|
