해결된 질문
작성
·
31
·
수정됨
0
안녕하세요 선생님.
질문하기 전 우선 좋은 강의 촬영해주셔서 너무 감사드립니다. 공부에 많은 도움이 되고 있습니다.
저는 의도적으로 장애 상항을 만들고 Wireshark로 확인해보며 공부 중인데 이해가 가지 않는 상황이 존재하여 사진과 함께 여쭤봅니다.
우선 간략하게 테스트 환경을 공유드리겠습니다.
루프백 통신,
Server Port: 7777,
Client Port: 65066,
Netsh interface tcp set global autotuninglevel=disabled 으로 WindowSize Auto Tuning 비활성화
Client는 recv 함수 호출 전 브레이크 포인트 걸고 Server가 132,000 데이터를 send 하는 상황입니다.
3-way handshake 상황에서 클라이언트가 Win = 65495로 공유받았고, ①에서 서버는 Len = 65495 만큼 데이터를 송신하고 있습니다.
클라이언트는 ACK로 Win =65495를 보내고 있는데, 클라이언트가 Recv를 하고 있지 않기 때문에 Win = 0으로 와야될 것 같은데… 이 부분이 어떤 것 때문에 이렇게 오는 지 이해가 어려워 여쭤봅니다.
혹시나 os에서 내부 TCP 버퍼 크기를 자동으로 조정했는지 확인해보기 위하여 getsockopt으로 RCV_BUF를 확인해본 결과 65536으로 따로 변경하거나 그런 것은 확인하지 못했습니다.
답변 2
0
어쩌면 Window Scaling 옵션이 적용되어 실제 윈도우 크기가 65495 커진 탓이 아닐까 의심해봅니다. 이와 관련된 내용을 다시 한 번 확인해보시기를 권장드립니다. 😄
0
안녕하세요, 인프런 AI 인턴입니다. JjaengE님, TCP의 장애 테스트와 관련하여 질문 주셔서 감사합니다.
TCP에서 윈도우 크기는 송신 측이 수신 측으로부터 수신 가능한 데이터의 양을 나타냅니다. 클라이언트가 해당 버퍼를 비우지 않으면, 즉 recv 호출을 통해 데이터를 처리하지 않으면, 일정 시점 이후로 수신 가능한 용량이 줄어들게 됩니다. 보통, 이런 상황에서는 윈도우 크기가 0으로 나타날 것이라 예상됩니다. 그러나:
ACK와 윈도우 광고: 송수신된 ACK 패킷에서 win 필드가 여전히 65495로 유지되는 것은 잠재적으로 두 가지를 의미할 수 있습니다.
윈도우 업데이트의 지연: 때때로 윈도우 업데이트가 네트워크 상에서 지연될 수 있습니다. 따라서, 현재 보고 있는 캡처 데이터에서 윈도우의 사후 업데이트가 빠르게 반영되지 않을 수 있습니다.
유사한 문제나 더 심층적인 분석을 위해 이전에 논의되었던 내용을 참고하시면 좋을 것 같습니다:
Wireshark 등을 통해 패킷을 분석하셨다면, ACK 패킷을 통해 클라이언트 및 서버 간의 데이터 흐름과 윈도우 크기 변화를 관찰해 보세요. 이를 통해 데이터 수신 버퍼가 실제로 비어 있는지, 윈도우 크기에 영향을 미치는 요소가 무엇인지에 대한 힌트를 얻을 수 있을 것입니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.