TCP/UDP 오류와 흐름 제어

1.  오류와 흐름 제어

Client와 Server는 통신을 하며 수많은 데이터를 패킷으로 쪼게 주고받게 됩니다. 이과정에서 오류와 흐름이 제어된 신뢰성 있는 전송을 위하여 노이즈로 인하여 전달받은 패킷이 중간에 회손되지는 않았는지? 네트워크 문제로 인하여 패킷이 중간에 유실되지는 않았는지? 만약 유실되었다면 이후 패킷을 어떻게 재전송할지? 확인이 필요합니다.

 

첫번째 전달 받은 패킷이 중간에 회손되지는 않았는지?(오류 검출 방식) 확인하기 위해서 체크섬, 패리티 검사, CRC 등을 이용합니다. 세그먼트 헤더에서는 체크섬 필드를 통하여 오류를 정정하고 무결성을 보호하고 있습니다.

 

 

두번째 패킷이 중간에 유실되지는 않았는지?(확인 응답) 확인하기 위해서 수신측은 송신측으로부터 패킷을 받고 긍정 응답으로 ACK 패킷을 부정 응답으로 NACK 패킷을 발송합니다. 수신측은 송신측으로부터 응답 패킷을 받은 후 어떤 패킷을 다음에 보낼지 결정하게 되는데 이 과정에서 언제까지나 응답 패킷을 기다릴 수 없기 때문에 재전송 타이머가 동작합니다. 재전송 타이머가 끝나게되면 응답 패킷을 받지 않으면 유실로 간주하고 패킷을 재전송합니다.

 

여기서 등장하는 재전송 타이머(RTO, Retransmission Timeout)는 데이터를 재전송하기 위한 타이머입니다. 재전송 타이머는 RTT(Round Trip Time)과 어떠한 알고리즘,,,? 계산식,,,?으로 계산되며 동적으로 정해집니다. RTT는 3 Way Handshaking에서 SYN 패킷을 보내고 ACK 패킷을 받기까지의 시간이며 해당 시점은 재전송 타이머가 정해지기 전이기 때문에 Initial RTO를 참고하게 됩니다. Initial RTO는 운영체제에 따라서 다르게 설정되어 있으며 보통 1초이며 2제곱으로 늘어납니다. 이렇게 3 Way Handshaking에서 측정된 Initial RTT는 패킷에서 확인 가능합니다.

 

세번째 패킷을 어떻게 재전송할지?(ARQ, Automatic Repeat reQuest) 확인하기 위해서 다음 패킷의 크기와 유실 시점으로부터 얼마나 패킷을 재전송할지 결정해야 합니다. 총 세가지 동작 방식이 있습니다.

 

Stop and Wait ARQ는 패킷을 한개씩만 보낼 수 있는 가장 단순한 방식입니다. 수신측에서 패킷을 보내고 송신측으로부터 ACK 패킷을 전달 받아야 다음 패킷을 전송합니다. 수신측은 재전송 타이머가 완료되기 전까지 응답 패킷을 받지 못할 경우 마지막에 보낸 패킷을 재전송합니다. 응답 패킷을 받기 전과 재전송 타이머가 완료되기 전까지 수신측은 아무것도 할 수 없기 때문에 가장 비효율적입니다.

 

Go Back N ARQ는 슬라이딩 윈도우를 이용하여 한번에 여러 패킷을 보낼 수 있으며 패킷 유실 시 유실된 시점부터 재전송하는 방식입니다. 수신측은 순서대로 패킷이 도착하지 않았을 경우 패킷을 폐기하며 NACK 패킷으로 유실된 패킷을 재전송 요청합니다. 만약 수신측은 재전송 타이머가 완료되기 전까지 응답 패킷을 받지 못할 경우 응답을 받지 못한 패킷부터 재전송합니다.

 

Selective Repeat ARQ입니다. 슬라이딩 윈도우를 이용하여 한번에 여러 패킷을 보낼 수 있으며 패킷 유실 시 유실된 패킷만 재전송하는 방식입니다. 수신측은 순서대로 패킷이 도착하지 않았을 경우 패킷을 버퍼에 보관하며 NACK 패킷으로 유실된 패킷을 재전송 요청합니다. 재전송 받은 후 버퍼에 보관된 패킷과 재정렬합니다. 만약 수신측은 재전송 타이머가 완료되기 전까지 응답 패킷을 받지 못할 경우 응답을 받지 못한 패킷부터 재전송합니다. 가장 효율적이지만 비교적 복잡하고 별도 버퍼와 재정렬이 필요합니다.

 

여기서 등장하는 슬라이딩 윈도우(Sliding Window)는 수신측과 송신측이 네트워크 상황과 메모리 버퍼를 고려하여 한번에 처리할 수 있는 메모리 버퍼 안에 윈도우 사이즈를 협의합니다. 수신측은 윈도우 사이즈 이내에서 한번에 패킷을 전송하며 ACK 패킷을 받은 후 새로운 패킷이 있는 방향으로 미는 과정을 반복합니다. 수신측은 현재 수신할 수 있는 여유 윈도우 사이즈(RWND) 전송하면 송신측은 이를 참고하여 전송 윈도우 사이즈(AWND)를 결정합니다. 만약 네트워크 상황이 좋지 않아 혼잡 제어를 위해 윈도우 사이즈의 조절해야 한다면 송신측은 혼잡 윈도우 사이즈(CWND)를 함께 참고하여 전송 윈도우 사이즈(AWND)를 결정합니다.

 

2. TCP

TCP는 신뢰성 높은 전송을 목표로 하며 오류와 흐름을 제어하기 위해서 오류 검출 방식, 확인 응답, ARQ 모두 사용하고 있습니다. 아래 TCP를 사용하는 TLS 1.2의 전송을 보면 실제 데이터가 최초 전송되기까지 두차례 패킷(3 Way Handshaking, TLS Handshaking) 교환이 필요합니다. 이 과정에서 3 Way Handshkaing은 필수이지만 TLS Handshaking은 HTTP 암호화를 위한 과정이라 암호화가 필요 없을 시 생략될 수 있으며 이후 응답 패킷의 여부를 확인하며 데이터를 전송합니다.

 

첫번재 오류 검출 방식으로는 체크섬 필드를 사용하고 있습니다. 아래와 같이 TCP 패킷에는 체크섬 필드가 필수로 있으며 상태 필드 값을 통하여 해당 패킷의 오류 검출 여부를 확인할 수 있습니다.

 

두번째 확인 응답으로는 응답 패킷을 송수신하고 있습니다. 아래와 같이 TCP는 패킷 전송 후 응답 패킷을 통하여 수신측의 패킷 전송 여부를 확인합니다. 다만 이 과정에서 ACK 패킷만 사용합니다. NACK 패킷을 함께 사용할 경우 수신측이 패킷을 확인하는 과정이 필요하여 혼잡 제어의 3 Duplicate ACK를 통해 특정 ACK 패킷을 세번 받을 경우 패킷 유실로 간주하고 재전송합니다.

 

세번째 ARQ로는 Go Back N ARQ와 Selective Repeat ARQ를 함께 사용하고 있으며 슬라이딩 윈도우를 이용하여 한번에 여러 패킷을 보낼 수 있습니다. 아래와 같이 여러가지 상황에 따라 패킷을 재전송하여 송수신측은 현재 가능한 윈도우 사이즈를 공유하고 조절합니다.

 

3. UDP

UDP는 빠른 전송을 목표로 하며 최소한의 오류를 제어하기 위해 오류 검출 방식만을 사용하고 있습니다. 아래 UDP를 사용하는 QUIC(HTTP3)의 전송을 보면 실제 데이터가 최초 전송되기까지 한차례 패킷(QUIC Handshaking) 교환이 필요합니다. 이 과정도 HTTP 암호화를 위한 과정이라 암호화가 필요 없을 시 생략될 수 있으며 이후 응답 패킷 없이 빠르게 데이터를 전송합니다.

 

오류 검출 방식으로는 체크섬 필드를 사용하고 있습니다. 아래와 같이 UDP 패킷에는 체크섬 필드가 필수로 있으며 상태 필드 값을 통하여 해당 패킷의 오류 검출 여부를 확인할 수 있습니다.