처음에 네트워킹 SE에 문의할 때 이 사이트를 참조했습니다.
TCP의 rwnd 광고에 대해 몇 가지 질문이 있습니다. RFC를 읽었지만 답이 없는 생각이 남았습니다(또는 몇 가지 내용을 놓쳤을 수도 있습니다). 아마도 답변 중 일부는 구현에 따라 다를 수 있습니다. 이 경우 일반적인 경우에 어떤 일이 발생하는지 알고 싶으므로 귀하의 경험을 바탕으로 답변해 주십시오.
TCP 표준은 다음과 같이 명시합니다.
전송 TCP는 전송 창이 0이더라도 사용자로부터 수락하고 최소한 1옥텟의 새 데이터를 보낼 준비가 되어 있어야 합니다.
그 이유는 윈도우 프로브 메시지에 1옥텟의 데이터가 포함되어 있기 때문이라고 가정합니다. 그러나 그것은 나에게 다음과 같은 생각을 하게 만들었습니다.
나는 프로브 패킷이 새로운 데이터의 1옥텟을 포함해야 한다는 표준에서 언급된 것을 본 적이 없습니다. 창 크기를 조사하는 다른 방법이 있습니까?
이것이 유일한 방법이라면 이전 세그먼트(이전 시퀀스 번호 포함)를 다시 보내는 것만으로는 충분하지 않은 이유가 무엇인지 궁금합니다. 수신자는 특정 순간에 창 내에 있는 데이터만 승인해야 합니까(즉, 오래된 데이터는 반드시 승인되지는 않음). 즉, 프로빙 패킷을 해당 규칙의 예외로 처리해야 합니까?
일반적으로 수신자는 창 크기가 커지면 발신자에게 알립니까? 그렇게 해야 합니까(확인이 손실되어 발신자가 어쨌든 조사해야 할 수도 있음을 이해합니다)?
프로브 패킷은 해당 시간에만 전송됩니까
window = 0, 아니면 이전에 전송될 수 있습니까?
답변1
그 이유는 윈도우 프로브 메시지에 1옥텟의 데이터가 포함되어 있기 때문이라고 가정합니다.
분명히 말하면 윈도우 프로브 패킷에는 특별한 패킷 형식이나 헤더 또는 기타 식별자가 없습니다. TCP는 창을 조사해야 할 때 표준 TCP 패킷을 보냅니다. 해당 TCP 패킷의 사용자/애플리케이션 데이터를 하나의 단일 옥텟으로 제한하는 일이 발생합니다.
- 나는 프로브 패킷이 새로운 데이터의 1옥텟을 포함해야 한다는 표준에서 언급된 것을 본 적이 없습니다.
프로브 패킷에는 최소한 1옥텟의 새 데이터가 포함되어야 한다는 표준의 설명을 방금 인용하셨죠? 추가 설명이 필요한 경우 RFC 793 및 RFC 1122에서 새 애플리케이션 데이터가 없는 Ack는 안정적으로 전송되지 않는다는 점을 상기시키는 설명을 찾을 수 있습니다. 통과했습니다).
창 크기를 조사하는 다른 방법이 있습니까?
TCP 표준의 작성자가 다른 방법을 고안했을 수도 있다고 상상할 수 있지만, 당신이 인용한 방법은 그들이 표준에서 제공한 유일한 방법입니다.
- 이것이 유일한 방법이라면 이전 세그먼트(이전 시퀀스 번호 포함)를 다시 보내는 것만으로는 충분하지 않은 이유가 무엇인지 궁금합니다.
그것은 충분할 것인가의 문제가 아니라, 최선의 방법이 무엇인가의 문제입니다. 더 이상 보낼 데이터가 없으면 창을 검색할 필요가 없습니다. 만약 너라면하다보낼 추가 데이터가 있는데 사용하지 않으시겠어요?저것이전에 전송된(아마도 승인된) 데이터에 대역폭을 낭비하는 대신 창을 조사하려면 어떻게 해야 할까요?
수신자는 특정 순간에 창 내에 있는 데이터만 승인해야 합니까?(즉, 오래된 데이터는 반드시 승인되지는 않습니다.)
수신자는 수신한 최신 데이터, 즉 처음부터 수신한 모든 데이터와 연속된 데이터만 승인해야 합니다(연속이란 하나 이상의 패킷을 놓쳤지만 나중에 패킷을 받았기 때문에 구멍이 있는 경우를 의미합니다. 이후의 패킷을 응답할 수 없습니다. 첫 번째 홀 이전의 마지막 시퀀스 번호를 계속 응답해야 합니다.
- 일반적으로 수신자는 창 크기가 커지면 발신자에게 알립니까?
예, 일반적으로 수신자는 Ack가 있을 때마다 창 크기 업데이트를 발신자에게 알립니다.
또한 3페이지의 "창 관리 제안"을 참조하십시오. RFC 793의 43에서 저자는 TCP 수신기가 "창이 더 클 때 새 창 정보와 함께 또 다른 승인을 보냅니다"라고 제안합니다. 이 RFC는 MAY/SHOULD/MUST 용어 표준을 정의한 RFC 2119보다 앞서 있지만 이 제안은 RFC 2119의 요구 사항 수준 지침에 따라 SHOULD로 간주되는 것처럼 보입니다.
그렇게 해야 합니까(확인이 손실되어 발신자가 어쨌든 조사해야 할 수도 있음을 이해합니다)?
나는 이 동작을 필수로 만드는 RFC 793을 업데이트하는 RFC에 대해 알지 못합니다.
프로브 패킷은 window = 0일 때만 전송됩니까, 아니면 그 전에 전송될 수 있습니까?
창이 0이 아니면 단일 데이터 바이트 TCP 세그먼트는 실제로 프로브로 간주되지 않습니다. 예를 들어, 개별 키 입력을 원격 호스트에 보내는 텔넷 연결이 있는 경우 각 키 입력은 단일 데이터 바이트 TCP 세그먼트로 전송될 수 있습니다. 창이 0 또는 1보다 큰 경우에도 텔넷과 같은 경우에는 보낼 수 있지만 프로브로 간주되지는 않습니다.
답변2
이는 다음을 기반으로 합니다.스피프의 대답, 그러나 주석에 들어갈 수 있는 것보다 더 많은 추가 사항이 있습니다. 참고로 2022년 8월RFC9293마침내 원래 TCP 사양을 대체했으며 모든 MUST/SHOULD/MAY 언어를 포함합니다.
Q1. 나는 프로브 패킷이 새로운 데이터의 1옥텟을 포함해야 한다는 표준에서 언급된 것을 본 적이 없습니다.
하나의 옥텟으로 제한되지 않는 다음 요구 사항은 원래 TCP 사양에 있었습니다.RFC793RFC9293에 그대로 복사되었습니다.
When the receiving TCP peer has a zero window and a segment arrives, it must
still send an acknowledgment showing its next expected sequence number
and current window (zero).
Q2. 왜 이전 세그먼트를 다시 보내는 것이 충분하지 않은지 궁금합니다.
가장 효율적인 방법은 아닙니다(창이 충분히 커지면 여전히 옥텟을 버려야 합니다). 그러나 TCP 혼잡 제어 사양은 항상 다음과 같이 말했기 때문에 작동합니다.RFC5681이제 말한다:
A TCP receiver SHOULD send an immediate duplicate ACK when an out-of-
order segment arrives.
Q3. 일반적으로 수신자는 창 크기가 커지면 발신자에게 알립니까?
수신 응용 프로그램이 수신 버퍼의 일부 데이터를 소비하기 때문에 수신자의 창이 커진다는 의미라고 가정합니다. 그렇다면 이를 알리기 위해 ACK를 보내야 하는 사양 요구 사항은 없다고 생각합니다. 따라서 ACK를 유도하려면 윈도우 프로브가 필요합니다.
Q4. 창 = 0일 때만 프로브 패킷이 전송됩니까?
예, 정의상 그렇습니다. 1옥텟 패킷이 window = 0 이전에 전송된 경우 이는 1옥텟 크기의 일반 패킷이 되기 때문입니다.