흐름제어 (endsystem 대 endsystem)
TCP 송수신 과정에서 만약 수신측에서 처리할 수 있는 양보다 송신측의 전송량이 더 많다면?
- 송신측과 수신측의 데이터 처리 속도 차이를 해결하기 위한 기법
- Flow Control은 receiver가 packet을 지나치게 많이 받지 않도록 조절하는 것
- 기본 개념은 receiver가 sender에게 현재 자신의 상태를 feedback 한다는 점
Stop and Wait
매번 전송한 패킷에 대해 확인 응답을 받아야만 그 다음 패킷을 전송
Sliding Window (Go Back N ARQ)
수신측에서 설정한 윈도우 크기만큼 송신측에서 확인 응답 없이 세그먼트를 전송할 수 있게 하여 데이터 흐름을 동적으로 조절
윈도우: 송,수신 스테이션 양쪽에서 만들어진 버퍼
가장 최근 ACK로 응답한 프레임 수 - 이전에 ACK 프레임을 보낸 프레임 수
송신측은 송신 윈도우를 유지해 송신 윈도우 크기만큼 한번에 데이터를 보낼 수 있고, 수신측도 수신 윈도우를 유지하며 수신 윈도우 크기만큼 데이터를 한번에 받을 수 있다
동작방식
먼저 윈도우에 포함되는 모든 패킷을 전송하고, 그 패킷들의 전달이 확인되는대로 이 윈도우를 옆으로 옮김으로써 그 다음 패킷들을 전송
호스트들은 실제 데이터를 보내기 전에 '3 way handshaking'을 통해 수신 호스트의 receive window size에 자신의 send window size를 맞추게 된다
송신
1. 송신윈도우에서 3,4를 전송하고, ACK를 기다림.
2. 5,6을 즉시 전송
3. 만약 RTO까지 ACK를 못받을 경우, 3,4가 제대로 전송되지 않았다고 판단하고 재전송
수신
1. 3,4를 수신 후 윈도우를 2칸 이동
2. ACK 5 를 전송하여 다음 수신할 것이 5바이트 라고 알려줌.
3. 재전송된 세그먼트를 받은 경우,윈도우가 3,4를 포함하지 않으므로 다음 받을 것이 5라고 다시 ACK5 전송
하지만, RTO 타이머가 만료되었다는 것이 항상 세그먼트의 유실을 의미하지는 않는다
세그먼트가 아직 수신측에 도달하지 않았을 수도 있고, 수신측에서 보낸 ACK 응답이 유실되었을 수도 있다
https://gyoogle.dev/blog/computer-science/network/%ED%9D%90%EB%A6%84%EC%A0%9C%EC%96%B4%20&%20%ED%98%BC%EC%9E%A1%EC%A0%9C%EC%96%B4.html
https://velog.io/@nnnyeong/Network-TCP-Flow-Control-%ED%9D%90%EB%A6%84%EC%A0%9C%EC%96%B4
