tcp 알고리즘

1. Piggybacked Ack(Delayed Ack)
데이터를 수신하면 Ack delay 타이머를 작동시켜서 일정 시간동안 기다리는 중 송신 데이터가 있으면 Ack 과 같이 전송을 하는 방법. 만약 Ack delay 이후에도 송신 데이터가 없으면 Ack 만 전송한다.

2. Naggle Algorithm
세그먼트의 크기가 일정 크기가 될 경우만 데이터를 전송해서 네트워크의 효율성을 올리기 위한 방법이다

3. Karn Algorithm
패킷 전송후 RTO(Retransmission TimeOut) 이후에 재 전송을 한경우 이후에 수신된 Ack 가 어떤 녀석의 Ack 인지 구분할 수가 없다(첫 Packet 인지 재전송된 Packet 인지). 이를 해결하기 위해 재전송이 이루어진 경우는 재전송에 대한 Ack 를 수신하기 전까지는 RTT(Round Trip Time) 측정값을 갱신하지 않고 새로운 RTO 를 계산하지 않는다. 재전송된 패킷에 대해서는 exponential backoff 가 사용된다.

4. Sliding Window
Ack 를 수신해야만 전송을 하는 비효율성을 극복하기 위해, Ack 가 도착하기 전에도 수신측이 정해준 양만큼 패킷을 연속 송신하는 방식, 일반적으로 2개후 Ack 를 보낸다고 책에 나와있어서 실제 capture 해봤더니 2개후 Ack 를 전송하고 있네..^^

5. Conegstion Control
라우터 혹은 스위치 에서 오버플로가 발생하면 당근 패킷은 폐기된다. 만약 송신측은 Ack 가 오지 않으면 RTO 후 재전송을 하게되고, 그러면 Congestion 만 가중될 것이다. 이를 해결 하기 위해 아래와 같은 방법이 있다.

-Slow Start Algorithm
Congestion Window 를 사용하는 방법으로, Cwind 를 1로 하고 최초 전송하여 이후 순차 증가시키다가 재전송이 일어난 경우 Cwind 를 반으로 줄여서 Congestion 을 회피한다.

-Fast Retransmission
패킷이 손실된 경우 수신측은 이전에 수신된 Ack 를 전송한다. 송신측은 동일 Ack 를 세번이상 수신하면 해당 패킷을 재전송하게 된다.

6. TCP Persist Timer
수신측의 처리속도보다 송신측의 전송속도가 빠를 경우, 수신측의 버퍼 부족으로 window size 를 0으로 송신측으로 알리게 된다. 이후 수신측이 가용 버퍼가 생겨 window size 증가를 알렸을 경우, 이 패킷이 손실되어 버리면 헉;;; 데드락이 발생한다. 이를 방지하기위해 window size 가 0인 패킷을 수신한 후 일정시간동안 window size 가 0 보다 큰 녀석이 도착하지 않으면 1byte 를 계속 전송하여 Ack 를 수신하여 window size 를 갱신하여 데드락을 회피한다.

7. Silly Window Syndrom
적은 양의 데이터가 계속 교환되면 window size 가 0이 될 것이고, 금방 1이 될 것이고 이럴 것이다. 이렇게 반복되면 1->0->1->0 의 악순환만 발생하게 된다. 이를 멍청한 윈도우 현상이라고 한다. 이를 방지하기 위해 버퍼의 50% 이상의 window 가 수신되지 않으면 송신측에서는 메시지를 보내지 않는다.