reference:
"하루 3분 네트워크 교실" / 아미노 에이지
https://m.blog.naver.com/devks0228/221822132594 / 꼬마개발자의 블로그
요약
- 확인응답을 보낼 때는 확인응답 번호에 다음에 수신 받을(예정의) 데이터 번호를 넣는다.
- 전송 에러가 발생했을 때에는 지금 보낸 것과 같은 데이터를 보낸다.
- TCP는 윈도우 제어라는 구조로 버퍼 플로우를 방지한다.
- 상대방의 버퍼사이즈=윈도우사이즈를 확인하면서 송수신을 수행한다. => '확실'한 수신을 위해
- 윈도우 사이즈 분량까지는 확인 응답을 수신하지 않아도 한번에 보낼 수 있다.
에러 복구
"시퀀스 번호"와 "확인 응답 번호"
수신 측에서 세그먼트를 수신하면, 수신한 것을 송신처에게 전달하는데 이것을 확인 응답이라 한다.
여기서 키 포인트는 TCP 헤더의 시퀀스 번호(3bit)와 확인 응답 번호(3bit)이다.
데이터 송신에서는 시퀀스 번호가, 확인 응답에는 확인 응답 번호가 중요한 값이 된다.
- 시퀀스 번호: 보내는 데이터의 앞 부분에 있는 옥텟 번호
- 확인 응답 번호: 다음에 받고 싶은 데이터 선두 옥텟 번호
즉, 단순히 '수신했다'가 아닌 다음에 받을 예정의 데이터 번호까지 전달하는 것이 확인 응답 번호이다.
이를 통해 송신측은 어느 데이터까지 수신측이 받았는지도 알 수 있는 것이다.
ex) 확인응답 번호가 100이면, '100번을 보내라'는 것이니 99번까지는 수신했다는 의미이다.
source: https://m.blog.naver.com/devks0228/221822132594
RTT값(보낸 데이터에 대해 확인응답이 돌아오기까지 걸린 시간 계산)으로 에러 판단 -> 에러 복구: 다시 데이터 보냄
확인 응답이 일정 시간동안 오지 않는다면 에러라고 간주해 에러 복구를 한다. 즉 데이터를 다시 보낸다는 뜻이다.
이 일정시간은 RTT(Round Trip Time)라는 값으로 판단한다. 지금까지 보낸 데이터에 대해 확인응답이 돌아오기까지 걸린 시간으로 계산하는 것이다(RTT는 동적으로 변경).
일정시간의 RTT 이후에도 응답이 돌아오지 않으면 '타임 아웃'되어 송신 측에서 해당 패킷을 재전송한다.
흐름 제어
윈도우 제어 => 윈도우 사이즈를 알림으로써 '확실'하게 수신할 수 있게 함.
'단일 세그먼트 전송 -> 확인 응답 수신'(Stop-And-Wait 방식)이 아닌 '복수의 세그먼트 전송 -> 확인 응답 수신'이라는 형태를 통해 효율 좋은 전송 방법을 취할 수 있다. (시간 효율 UP)
세그먼트 전송 후 하나 하나 확인 응답을 기다리는 대신 연속적으로 세그먼트를 보내고 난 다음 확인 응답을 확인하는 방식으로 효율을 높이는 것이다.
수신 측에는 세그먼트를 버퍼(buffer)라는 공간에 일시적으로 보관한다. 만약 대량으로 데이터가 전송되고, 버퍼의 용량을 넘어가면 오버플로우(overflow, 버퍼 플로우)가 발생한다.
source: https://m.blog.naver.com/devks0228/221822132594
이를 막기 위해 TCP의 흐름제어 중 하나인 윈도우 제어를 한다. 수신측이 수용할 데이터만 보내는 것이다.
수신측은 송신측에 자신이 어느 정도 버퍼량을 가지고 있는지를 알려줄 필요가 있다. 이것을 윈도우 사이즈라고 하는데, 윈도우 사이즈를 상대방에게 알려줌(TCP 헤더의 필드)으로써 윈도우 사이즈만큼의 데이터를 한번에 보내도 오버플로우 하지 않는다는 것을 알려준다.
source: https://m.blog.naver.com/devks0228/221822132594
윈도우 사이즈로 상대방에게 자신의 버퍼량을 전달해 '확실'하게 수신할 수 있는 용량의 데이터만 송수신한다는 뜻이고, 이를 '윈도우 제어'라 한다. 이 윈도우 제어를 통해 버퍼 플로우를 방지한다.
복수의 세그먼트 전송 -> 확인 응답 수신 방식에서의 윈도우 제어는 "Sliding Window(슬라이딩 윈도우"를 통해 이루어질 수 있다.
