이전 포스트에서 봤던 ACK를 효율적으로 보내는 방법에 이어서, 좋지 않은 상황을 처리하는 방법을 알아보자.
이전 내용을 상기시켜보자. rule을 보여주기 위한 예시와 다르게 데이터 패킷은 이전에 받은 window size만큼 계속해서 보낼 수 있다. 이에 대한 ACK 패킷은 상황에 따라 다르게 전송된다. 이를 rule의 원리를 이해하면 알 수 있을 것이다.
- Rule 4: Seq 701의 패킷이 소멸되었기 때문에, Seq 801 패킷을 받자마자 바로 701을 달라는 ACK을 보낸다.(out-of-order)
여기서 sender의 입장에서 Seq 701 패킷에 대한 timer를 킨다. 이에 대한 응답(ACK)을 받지 못한채 time-out이 되면 701 패킷을 재전송한다.- Rule 5: 기다리고 있던 패킷이 도착하면 order를 맞춘 것으로 이에 대한 ACK 패킷을 바로 보낸다.
이제 소멸된 패킷을 처리하는 방법을 알아보자.
이전에 봤듯이 application 입장에선 out-of-order의 데이터를 read하지 않는다.
UDP를 사용한다면 이는 신뢰성이 보장되지 않아 소멸되는 데이터가 있어도 모르고, 아무 데이터던 application이 가져간다.
이전에 타이머로 소멸된 것을 timer를 사용하여 알아냈다. time-out의 시간은 delay까지 고려하여 넉넉하게 time-out 까지의 시간을 잡아야한다.
여러개의 패킷을 모두 time-out으로만 잡는다면 꽤 오래걸릴 것이다.
위의 diagram에서 보았을 때, out-of-order를 만났을 때, receiver는 받지 못한 패킷에 대한 ACK을 계속해서 보낸다. time-out 이전에 이 ACK을 중복하여 3번(총 4번) 받는다면 소멸됐다 생각하고 바로 데이터 패킷을 전송한다.(이를 Fast retransmit이라 부른다.)(소멸되지 않고 나중에 도착할 수도 있다.)
참고: 모든 패킷에 timer가 존재한다.
그런데 만약에 여러개의 패킷이 소멸되면 어떻게 해야할까? 3개의 중복된 ACK를 받으면 이에 대한 데이터 패킷만 전송할까? 그리고 그 바로 다음에 소멸된 ACK를 연달아 보낼까?
101, 301, 501 패킷이 소멸되었다 해보자. 101에 대한 응답을 세 번 보내고 101을 전달 받았다. 이후 301에 대한 응답을 세 번 받아야할까?
굉장히 비효율적으로 들린다. 여기서 sender는 101 이후 전송된 모든 패킷을 재전송한다.
sender는 receiver의 window size의 상한까지 데이터를 계속해서 보낼 수 있다고 했다. 위와 같이 701 ACK이 소멸됐다 하더라도, 901 ACK을 보냄으로써 아무일이 일어나지 않은 것처럼 데이터 송신이 수행될 수 있다.
- Rule 6: 위는 receiver의 ACK 패킷이 소멸되었는데 sender에서 time-out이 발생한 사황이다. 여기선 그냥 바로 데이터 패킷을 보내고 receiver는 여기에 대해 바로 ACK패킷을 전송한다.
(사실 501, 601 다보내야한다.)
Deadlock
이전에 봤을 때, ACK에 rwnd size가 0일 때, sender는 데이터 전송을 중단한다.
이후 버퍼가 충분히 비어졌을 경우, rwnd size를 수정하여 ACK를 전송해야하는데, 만약 이 패킷이 소멸되면 둘 다 deadlock이 일어난다.(둘 다 중단된다.)
sender는 rwnd가 0이였을 때, timer를 킨다. 여기서 time-out이 발생했을 경우, receiver에게 1byte와 같이 작은 패킷을 전송한다. receiver는 여기에 대해 ACK을 보내는데 이 ACK 패킷의 rwnd 값을 확인하고 데이터를 보낼 수 있으면, 데이터 송수신이 재개된다.
Congestion(혼잡제어)
만약 100Mbps의 속도로 데이터를 송수신해주는 router에 200M bit를 전송하면 어떻게 될까? router에도 버퍼가 존재하기 때문에 나머지를 여기에 저장하여 처리한다. 그런데 이게 계속 지속되면 버퍼가 꽉차 수신하는 데이터를 버려야할 것이다.
checksum, router 문제도 있겠지만 대개 네트워크 혼잡 때문에 패킷이 소멸된다.
컴퓨터 네트워크는 중앙 제어 방식이 아니다. 옆집 김씨가 router에 얼마나 많은 데이터를 전송할지 모른다. 마치 명절에 꽉 막힌 고속도로를 생각할 수 있다.
(서로 몇시에 가는지 모르기 때문에 교통체증이 발생한다.)
TCP는 best-effort 방식으로 최선을 다한다. 하지만 보장은 되지 않는다.
그렇다고 중앙 제어 방식이 무조건 좋은 것도 아니다. 중앙에서 router를 중앙에서 조율하면 다른 네트워크가 사용할 수 있을 때, 이미 예약돼 있어 사용하지 못할 수도 있다.
delay를 패킷 받기 위한 시간이라 하고, capcity를 네트워크의 용량이라 하자.
데이터가 많아지만 당연히 데이터를 수신 받는데에 오래걸릴 것이다.
게다가 Capacity를 넘어 혼잡될 때(버퍼에 저장할 때)까지 가면 계속해서 증가할 것이다.
Throughput은 Receiving rate는 아니다.
Throughput은 파일 받는 시간이라 생각해보자. 하나의 파일을 보내는데, capacity를 넘어갈 정도로 보내면 온전한 파일을 받는데 시간이 굉장히 오래 걸릴 것이다.
receiving rate는 그렇다면 유지될 것이다. 그냥 데이터를 받는량이기 때문이다.
throughput이 떨어지는 것을 100mbps였다가 50mbps로 떨어졌다고 생각하자.
패킷이 없어지기 시작함 -> 재전송 -> 혼잡 -> 패킷 또 없어짐 -> 파일 받는데 걸리는 시간 증가
단위 시간당 네트워크로 전송될 수 있는 데이터인데, 계속 삭제되니까 저렇게 떨어지는 것 같다.(뇌피셜)
