TCP : half-closed 연결의 데이터

TCP 스택을 구현 중이며 반 폐쇄 연결에 문제가 발생했습니다.TCP : half-closed 연결의 데이터

내 구현은 서버 측으로 동작합니다. 클라이언트가 연결을 설정 한 다음 일부 데이터를 보낸 다음 "FIN"메시지를 보냅니다. 그런 다음 서버는 클라이언트로부터 데이터를 수신 확인하고 자체 데이터를 보내고 연결의 절반을 닫습니다 ("FIN"을 보냄).

문제는 클라이언트가 서버가 반 폐쇄 연결에서 보낸 데이터 또는 최종 "FIN"메시지를 승인하지 않는다는 것입니다. netstat에 따르면 클라이언트는 FIN_WAIT2 상태에 있습니다. 서버가 아무런 데이터도 보내지 않는 동일한 시나리오에서 일이 순조롭게 진행됩니다. 문제의 클라이언트는 netcat입니다. 따라서 문제가 내 마지막에 있다고 가정합니다.

스크린 샷은 here입니다. 실제 PCAP 파일은 here입니다.

내 질문에 일반적으로 절반 닫힌 연결에서 보낸 데이터에 대한 ACKS를 기대해야합니다; 그리고 특히 위의 예에서 내가 뭘 잘못하고 있는지.

도움이 될 것입니다.

출처

2013-10-23 Guy Katz

피어의 관점에서 절반 닫힌 연결인지 모릅니다. 클라이언트가 연결을 완전히 닫았을 수 있습니다.이 경우 포트는 사용자 측의 CLOSE_WAIT 및 피어의 FIN_WAIT_2에 있지만 피어는 ACK 대신 RST를 전송자에게 보냅니다. 귀하의 링크는 .exes를 다운로드합니다. 이는 바이러스와 관련이 있습니다. 그 (것)들을 이용할 수있게하는 다른 방법 있는가? – EJP

의견을 주셔서 감사합니다. 링크를 업데이트했습니다. 이제 올바르게 표시됩니다. –

스크린 샷의 마지막 줄은 첫 번째 PSH에 대한 ACK입니다. 더 이상 있습니까? – EJP

아마도 서버는 FIN/ACK에서 2562 대신 ACK = 2561을 전송해야합니까?

출처

2013-10-24 00:33:31 Den

방금 25662 대신 2561을 사용하려고했습니다. 클라이언트가 [FIN, PSH, ACK] 메시지를 반복하지만 시퀀스 번호가 2562 인 유사한 결과를 생성했습니다. 따라서 2562가 올바른 것으로 생각합니다. (FIN은 1 바이트로 계산됩니다). EJP, 이전 답장에서 실수를했습니다. Netstat은 최초의 질문 (2562 수락)에서 클라이언트는 FIN-WAIT-2에 있다고 말합니다. 2561을 사용할 때 FIN-WAIT-1에 있습니다. –

네, 잘못되었습니다 : 2562 여야합니다. 분명히 클라이언트는 알 수없는 이유로 데이터를 확인하지 않으려합니다. 당신은 당신의 데이터를 재전송하고 어떤 일이 일어나는지 보려고 할 수 있습니다. – Den

FIN-WAIT-2는 ACK를 보았으므로 시퀀스 번호가 정확해야하지만 동일한 세그먼트에서 FIN을 보지 못했음을 의미합니다. FIN이 1 바이트로 계산되면 LEN은 1이어야합니다.

출처

2013-10-24 21:58:36 EJP

"LEN"은 패킷의 실제 필드가 아니라고 생각합니다. tcp 세그먼트에 포함 된 바이트 수를 알려주는 wireshark입니다. FIN은 헤더의 플래그이며 실제 바이트가 아니므로 0이 맞다고 생각합니다. 나는 클라이언트가 지느러미를 무시하고 있다는 귀하의 평가에 동의합니다.문제는 이전에 시작한 것처럼 보입니다. 핀이 전송되기 전에 ACK를 보내지 않으면 ACK가 전송됩니다. 이것은 원래 질문의 일부였습니다. 클라이언트가 이미이 연결을 닫은 상태에서이 데이터를 확인해야합니까? –

예, 모든 데이터에 대한 ACK가 있어야합니다. – EJP

TCP : half-closed 연결의 데이터

답변

관련 문제