FIN, ACK после PSH, ACK

Я пытаюсь реализовать связь между устаревшей системой и системой Linux, но постоянно получаю один из следующих сценариев:

(Унаследованная система — серверная, Linux — клиентская)

Function recv(2) returns 0 (the peer has performed an orderly shutdown.)
> SYN
< SYN, ACK
> ACK
< PSH, ACK  (the data)
> FIN, ACK
< ACK
> RST
< FIN, ACK
> RST
> RST

Function connect(2) returns -1 (error)
> SYN
< RST, ACK

Когда сервер отправляет свои данные, клиент должен ответить данными, но вместо этого я получаю «FIN, ACK». Почему это так? Как мне это интерпретировать? Я не настолько знаком с TCP на этом уровне


networking tcp sockets tcpdump tcp-ip
person magol    schedule 07.11.2012    source источник
comment
Вам нужно посмотреть код вашего клиента.   -  person Brian White    schedule 07.11.2012
comment
FIN может быть добавлен к данным.   -  person user207421    schedule 08.11.2012

Ответы (2)


arrow_upward
1
arrow_downward

Когда сервер отправляет свои данные, клиент должен ответить данными, но вместо этого я получаю «FIN, ACK». Почему это так? Как мне это интерпретировать?

Возможно, после того, как сервер отправил данные (строка 4), клиент закрывает сокет или преждевременно завершает работу, а операционная система закрывает свой сокет и отправляет FIN (строка 5). Сервер отвечает на FIN ACK, но клиент уже перестал существовать, и его операционная система отвечает RST. (Я бы ожидал, что клиентская ОС будет молча игнорировать и отбрасывать любые TCP-сегменты, поступающие для закрытого соединения во время пресловутого состояния TIME-WAIT, но по какой-то причине этого не происходит.)

http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_termination:

Некоторые стеки хоста TCP могут реализовывать полудуплексную последовательность закрытия, как это делают Linux или HP-UX. Если такой хост активно закрывает соединение, но еще не прочитал все входящие данные, которые стек уже получил по ссылке, этот хост отправляет RST вместо FIN (раздел 4.2.2.13 в RFC 1122). Это позволяет приложению TCP быть уверенным, что удаленное приложение прочитало все данные, отправленные ранее, ожидая FIN от удаленной стороны, когда оно активно закрывает соединение. Однако удаленный стек TCP не может отличить RST прерывания соединения от RST потери данных. Оба заставляют удаленный стек выбрасывать все данные, которые он получил, но которые приложение все еще не прочитало.

person Maxim Egorushkin    schedule 07.11.2012

arrow_upward
0
arrow_downward

После FIN, PSH, ACK --> Одна транзакция завершена Второй запрос получен, но отправлен [RST] seq=140 win=0 len=0

person Dee    schedule 19.12.2017