TCP에 의한 승인은 데이터가 전달되었음을 보증하지 않습니다.

RFC 793에는 TCP 세그먼트의 승인에 관한 부분이 있습니다.

TCP는 데이터가 포함 된 세그먼트를 전송할 때 재전송 큐에 사본을두고 타이머를 시작합니다. 해당 데이터에 대한 승인이 수신되면 세그먼트가 큐에서 삭제됩니다. 타이머가 다 떨어지기 전에 승인이 수신되지 않으면 세그먼트가 재전송됩니다.

TCP에 의한 승인은 데이터가 최종 사용자에게 전달되었음을 보장하지는 않지만 수신 TCP가 책임을지는 것만 보장합니다 .

자, 이것은 흥미 롭습니다. NOC에서는 종종 네트워크와 외부 클라이언트 네트워크 간의 연결 문제를 해결하고 방화벽에서 트래픽을 감지하고 양방향으로 송수신되는 SYN 및 ACK 비트를 볼 때마다 연결이 설정되어 있고 문제가 없다고 가정합니다. 네트워크와 관련이 있습니다.

그러나 이제이 RFC는 TCP 연결이 설정되었지만 사용자에게 여전히 연결 문제가있는 경우 Wireshark를 설정하지 않고 무엇을 확인해야합니까?

RFC의이 부분은 운영 체제 또는 프로세스의 다음 단계에 책임을 전달하는 것입니다. 기본적으로 레이어 분리와 관련이 있습니다.

TCP에 의한 승인은 데이터가 최종 사용자에게 전달되었음을 보장하는 것이 아니라 수신 TCP가 책임을 졌다는 것을 보증합니다.

나는 항상 이런 식으로 생각했습니다.

• ACK 전송과 클라이언트 프로세스에 도달하는 데이터간에 OS가 충돌 할 수 있습니다 (여기서 "클라이언트"는 "네트워크 클라이언트"가 아니라 OS의 클라이언트를 의미 함)
• 클라이언트 프로세스는 버그가 있거나 크래시되거나 들어오는 데이터를 처리하는 데 예상되는 것보다 훨씬 느리거나 실제로는 명백하지 않은 상황에서만 읽습니다.
• 클라이언트가 데이터를 디스크 파일로 전송하는 경우 파일이 아직 작성되거나 플러시되지 않았을 수 있습니다.
• 클라이언트가 TCP를 통해 데이터를 전송하는 경우 상대방 TCP가 데이터를 전송하지 않았거나 ACK를 수신했거나 원거리 프로세스가 성공적으로 데이터를 사용했을 수 있습니다.

이것은 상위 계층 승인 이 아닌 계층 3 승인 ( "나는 당신의 바이트를 듣는다")이라는 것 입니다. 예를 들어 TCP ACK, 다음 홉 메일 게이트웨이 이후 의 SMTP 가 메시지, 메시지 수신 메시지 (예 : RFC 3798 ), 메시지 열기 추적 픽셀, PA의 감사 메모, "그렇습니다."라고 답장합니다.250 OK

또 다른 구체적인 예는 프린터입니다.

• 데이터의 끝을 포함하기 전에 데이터를 조기에 ACK해야합니다 (TCP 전송 창보다 큰 포함 된 라이브러리로 시작하는 포스트 스크립트 파일 일 수 있음)
• 상태 쿼리가 포함되어있을 수 있습니다 ( "종이가 있습니까?", 명백히 실행할 수 있음)
• 인쇄 명령이 포함되어있을 수 있습니다 ( "이것을 인쇄하십시오". 용지가 없으면 실패 할 수 있습니다)

사용자가 ACK를보고 보내고 있지만 여전히 연결 문제가 발생하는 경우 네트워크 관련 문제보다 정체, OS 또는 응용 프로그램 문제가 발생할 가능성이 훨씬 높습니다.

진단하려면 ACK가 아닌 재전송을 찾으십시오.

RFC 관점에서 "최종 사용자"는 응용 프로그램입니다. 응용 프로그램이 데이터를 얻었음을 보증하지 않으며 TCP 프로세스가 데이터를 받았다고 보장 할 수 없습니다.

NOC 관점에서 네트워크가 작동하고 데이터가 최종 호스트에 도달했습니다. 아마도 그게 당신이 신경 쓰는 전부일 것입니다.

이런 식으로 볼 수 있습니다.

M.Smith이고 M.Toto에게 편지를 보내려고합니다 (사람은 응용 프로그램 계층 임).

편지를 보내려면 지역 우체국 A로 이동하여 M.Toto 지역 우체국 B (우체국은 TCP 계층)로 편지를 보냅니다.

우체국 A와 우체국 B 사이에 모든 것이 잘 작동 할 수 있습니다.-B는 우체국 A에 ACK를 보내지 만 편지가 M.Toto에 도착한다고 보장 할 수는 없습니다. 우체국 B와 M.Toto 사이에 어떤 일이 발생할 수 있습니다.

이것이 기본적으로 RFC의 말입니다.