TCP의 ACK
TCP는 기본적으로 GBN, SR의 혼합형이다. GBN처럼 cumulative ack를 사용하지만, 또 동시에 각 세그먼트별로 타임아웃이 따로 존재한다.
각 이벤트 별로 ACK 생성을 알아보도록 하겠다.
-
seq에 맞게 각 세그먼터가 도착함. 에러 로스 없음
대응: delayed ACK를 보낸다. 500ms후에도 아무것도 안온다면 ack를 보내고 500ms후에 뭐가 또 오면 그걸로 바꿔서 대기한다. GBN처럼 Cumulative ACK를 쓰기 때문에 이러한 방법이 가능하다. -
GAP이 발견된경우
GAP이란 아래와 같은 경우이다.
0 -- 200|GAP|400 -- 600이때는 ack200을 보내서 gap에 대한 요청을 다시 해야 한다. 즉, gap을 다 처리할 수 있는 ack를 보내야하는것이다.
Retransmission
Lost ACK
ACK가 loss나면, 어차피 timeout으로 다시 전송하게 된다.
Premature timeout
ACK가 타임아웃보다 늦게 도착해서 생기는 문제이다.
이 경우 A는 92~100까지 다시 보내지만, 이걸 받은 B는 어차피 이미받은거니깐 120을 다시 보내주게 된다.
Fast Retransmission
위와 같은 상황이 있다고 가정하자. cumulative ACK는 이전 값을 커버할 수 있는 ACK를 보낸다.
만약 1234라는 4개의 세그먼트가 가고 1 34만 도착했다고 하자.
이 경우, 1은 다음 2를 반환하고, 3 4 역시 2를 받아야하니깐 2를 반환한다. 이렇게 3개의 duplicated ack가 오게되면, Timeout이 발생하기 이전이더라도 sender는 이것이 잘못된것이라 판단, 다시 보내주게 되는 시스템이다.
이는 Cumulative ACK라서 신뢰도있게 작동 가능한 시스템이다.
Flow Control
플로우컨트롤이란, 상대의 버퍼의 사이즈를 초과하는 데이터를 보내지 않도록 조정해주는 과정이다.
플로우컨트롤의 원리
- 서로 Connection established Seq#을 알고있고, rcv buffer size를 주고받는다.
즉, 버퍼 사이즈를 이용해서 receiver가 sender를 control하는거시다. receiver가 자기 buffersize를 전달하면, sender가 이를 기반으로 보내게 된다. 이는 receiver window로 알려지게 된다.
이는 header에 rwnd 필드로 전달되며, 이를 통해 receiver buffer가 overflow하지 않는것을 보장한다.
Connection Management
2way handShake
가장 단순한 방식의 통신이다. 하지만 실제로는 제대로 작동하지 않을 수도 있다.
variable delay, retransmitted message, reordering같은 문제로 인해 제대로 작동하지 않는 경우가 발생한다.
이런식으로 T.O 발생으로 재전송이 나면, 서버는 half open 상태가 되어버린다.
혹은 이렇게 커넥션이 성립된 종료 된 후에 데이터가 또 가서 서버가 중복데이터를 받을 수도 있다.
3way HandShake
3way에서는 est를 바로 하지 않고, 서버가 받아서 ack를 한번 보낸다. 이 ack를 받은 client가 est하고 또 ack를 보내면 이때 est가 성립된다.
이를 FSM으로 보면 위와 같다.
요약하자면, ACK를 두번 주고 받아야 conn이 성립하기때문에, 2way에서 생기던 문제가 어느정도는 해결된것이다.
Closing Connection
전화처럼 한쪽이 끊어버린다고 다 끊어지는것이 아니라, 둘 다 동의를 해야 끊어진다.
양측이 FIN을 보내고 이걸 받으면 끊어진다.
FIN을 보내게 되면 더 이상 Data를 보낼 수 없게 된다. 그리고 client의 경우 FIN을 받고 세그먼트 lifetime의 2배만큼 기다리고 자동종료된다.
일반적으로는 3way해서 처리한다.
만약 ack가 loss 되거나 아무는 안와서 timeout되면 받은것으로 간주 그냥 끊어버린다.
최악의 경우는 4번 케이스로 dr로스 경우이다.
