Flow Control
생산자가 데이터를 생성하는 속도와 소비자가 데이터를 사용할 수 있는 속도의 균형을 유지한다.
📌 sliding window
window는 Ack없이 보낼 수 있는 데이터의 양이다. 송신측은 송신 윈도우를 유지해 송신 윈도우 크기만큼 한 번에 데이터를 보낼 수 있다. 마찬가지로 수신측은 수신 윈도우를 유지하며 이 크기만큼 데이터를 한 번에 받을 수 있다. 양측 윈도우 크기는 TCP 헤더의 Window Size 필드에 의해 설정된다.
📌 Window Management
2개의 버퍼와 1개의 window로 구성되어 데이터의 flow를 control한다.
- Sending TCP: 송신 응용 프로그램에서 오는 데이터를 저장하는 버퍼로 윈도우의 크기가 0이 아닌 한 세그먼트를 보내기 위해 필요하다.
- Receiving TCP: 데이터를 수신하여 확인 후 수신버퍼에 저장하여 수신응용프로그램에서 소비하기 위함이다. window의 크기는 일반적으로 수신 TCP 버퍼에 남은 공간이다.
만약 sender가 window size가 0인 것을 받았을 때 다시 전송을 시작하기 위해서는 그것을 받았을때 Timer를 구동한다. 그후 time-out이 되면 아직도 window size가 0인지 확인한다.
📌 Silly Window Sydrome
데이터 전송 시에는 MAC, IP, Port 번호가 반드시 필요하다. 따라서 1byte의 데이터를 전송하더라도 수신자의 주소의 정보를 담고 있는 헤더가 반드시 함께 전송되어야 한다.
그런데 1byte의 데이터를 전송하고자 매번 40byte 이상의 헤더(TCP 헤더 크기: 20 ~ 60byte, IP 헤더 크기: 20byte, MAC/CRC를 제외하더라도 40byte 이상의 헤더가 필요)를 함께 전송하는 것은 효율적이지 못하다.
송신 응용 프로그램에서 데이터를 천천히 발생하거나 수신 응용 프로그램에서 데이터를 천천히 소비하는 경우에 슬라이딩 윈도우 동작에 문제가 발생하는 이를 silly window sydrome이라 한다.
💡Syndrome created by sender - Nagle 알고리즘
TCP 패킷수를 줄이고 보낼 수 있는 데이터양을 늘려야 성능이 좋아진다. 그래서 보낼 데이터가 MSS(Maximun Size Segment)로 정의된 크기만큼 쌓이거나 혹은 window size의 반만큼 쌓이면 보내는 방법이다. 보낼 데이터가 MSS보다 작을 경우, 이전에 보낸 데이터에 대한 ACK가 오기를 기다린다. ACK가 도달하면 보낼 데이터가 MSS보다 작더라도 상대방에게 보낸다.
💡Syndrome created by receiver - Clark 알고리즘, ACK delay
-
Clark 알고리즘
read 속도가 느려서 버퍼가 1byte씩 비워지는 상황에 수신 버퍼가 MSS만큼, 또는 전체 버퍼크기의 1/2만큼 비어 있는 경우에만 상대에게 정상적인 응답(ACK)을 보내주고 그렇지 않을 경우 rwnd(수신 윈도우 크기)를 0으로 해서 전송(rwnd = 0)한다. Sender는 Receiver가 가리킨 곳에서 데이터 송신을 중단한다.(즉시 전송 중단. 받은 ACK의 rwnd가 0이기 때문에 Receive Buffer가 꽉 찼다고 판단해 데이터를 보내지 않음) -
ACK delay
아예 ACK 을 안보내버리는 방법으로 송신측은 내가 보낸 데이터가 갔는지 안갔는지,이제 Window size가 어느정도인지 알 방법은 ACK 밖에 없는데 이 ACK가 오지않으니 아무것도 못한채 그저 기다리기만 할것이다. 충분한 빈 공간이 생겼을 때 ACK 을 다시 보내준다.
이 방식은 sender 쪽에서 Time-out이 발생하여 재전송을 할 수도 있다는 문제가 있다.
Error Control
TCP는 신뢰할 수 있는 transport layer 프로토콜이다. 즉, TCP로 데이터 스트림을 전송하는 응용 프로그램은 TCP에 의존해 전체 스트림을 반대쪽 끝에 있는 응용 프로그램에 오류 없이 순서대로 전달할 수 있다. TCP의 Error Control(오류 제어)는 순서에 맞게, 오류없이,중복없이 하기위해 checksum, acknowledgment, and time-out의 세 가지 tool을 사용하고 빠진것이없이 하기위해 restransmitting, outdated segment를 사용한다.
📌 acknowledgment
ACK에 대한 ACK은 존재하지 않는다. 데이터는 순서가 잘못된 상태로 도착하여 receiving TCP에 의해 일시적으로 저장될 수 있지만, TCP는 순서가 잘못된 데이터가 프로세스에 전달되지 않도록 보장한다. TCP는 receiving buffer에서 application으로 데이터를 전송할 시 제대로 된 데이터만 올려보낸다(신뢰성 보장). 순서 바뀐 것은 아예 process로 전달되지 않는다.
📌 Retransmission
오류(패킷 손실,지연,중복,순서역전 등)라고 믿어지는 즉, 확인응답되지 않은 데이터를 재전송한다. time-out까지 ack를 받지 못하면 재전송을 한다.
💡 retransmission timer가 존재하는 경우
소스 TCP는 전송된 각 세그먼트에 대해 하나의 RTO(재전송 시간 초과) 타이머를 시작한다. RTO의 값은 동적이며 세그먼트의 RTT를 기반으로 업데이트된다. go-back N 방식과 같이 처음부터 다시보낸다.
💡 sender가 Duplicate ACK 3개를 받은 경우
time-out 전에 3개의 중복 ack가 발생한다면 이는 패킷의 loss가 발생했다고 간주하고 loss한 패킷을 재전송한다. 이는 빠른 재전송을 위한 방법이다.
📌 Normal operation scenario
Rule 1
데이터를 받았을 때 ACK을 보내야 하는데 ACK을 바로 보내는 게 아니라 Buffer에 보낼 데이터가 있는지 확인하고 보낼 데이터가 있으면 같이 보낸다
(= ACK가는 김에 데이터도 같이 가자)
Rule 2
Sender는 패킷을 송신하고 나면 별도로 정의된 Timer(ACK-delaying timer)를 켜놓고 정해진 시간 동안 대기한다. 위의 그림에서는 지연 시간을 50ms로 설정하였다. 50ms까지 기다려도 Buffer에 보낼 데이터가 없을 시 데이터 없이 ACK만 전송한다.
Rule 3
timer를 켜놓고 기다리는 중에 패킷이 하나 더 도착하면 더 이상 안 기다리고 바로 ACK을 전송한다.(=데이터가 없는 상황에 패킷 2개 들어오면 2개당 ACK 하나는 보냄)
Rule 4
잃어버린 패킷이 존재할 시 바로 Ack 전송
Rule5
못 받은 패킷을 받은 경우 바로 Ack 전송
💡 RTO timer: Retransmission Timeout, 재전송 타임아웃 시간
패킷 제대로 받았는지 패킷마다 확인하는 타이머로 패킷마다 넉넉한 시간을 부여하고, 그 시간 안에 패킷에 대한 Ack이 도착하지 않은 경우 패킷이 정상적으로 상대방에게 도착하지 않았다고 간주하고 패킷을 재전송한다.
RTO설정/계산 = 전송된 한 세그먼트에 대한 확인응답을 기다려야 하는 시간 = TCP 재전송 타이머 값, sending TCP는 매 세그먼트를 전송할 때 마다 재전송 타이머(RTO) 가동한다.
RTO는 TCP 연결의 RTT(왕복시간)보다 약간 크면 이상적인데 세그먼트 전송부터 확인응답 받기까지의 시간보다 약간 크면 좋다는 것이다.
📌 Deadlock Created by Lost acknowledgment
Receiver가 rwnd=0을 보내 Sender가 데이터 송신을 멈춘 상황이다. Receiving Buffer에 MSS만큼의 공간이 생기거나 1/2만큼 빈 공간이 생길 때 Receiver는 rwnd=k(k: 빈 공간 용량)를 보내 상대방에게 알린다. 이때 상대방에게 보낸 Ack이 유실된다면, Sender는 Receiver를 기다리고 있고, Receiver는 Sender가 데이터를 보내주기를 무한정으로 기다리게 되는 deadlock이 발생한다. 이러한 문제를 해결하기 위해서 Persistence Timer를 사용한다.
💡 Persistence Timer
Receiver가 rwnd=0을 보내 Sender가 데이터 송신을 멈춘 상황에 persistence timer가 작동한다. persistence timer가 time out이 되었는데도 상대방에게서 아무런 반응이 없으면, Sender는 일단 작은 사이즈의 데이터(probe segment)를 상대방에게 보내본다.
데이터를 보내면 해당 데이터에 대한 Ack이 도착한다. rwnd가 여전히 0이면 상대방 수신버퍼가 아직 비워지지 않았다는 의미. rwnd = k이면 중간에 Receiver가 보낸 Ack이 유실되었을 가능성이 존재한다.
