TCP vs UDP

대표적인 TCP 와 UDP 에 관한 잘못된 인식을 하나 들라면 UDP 가 fast response 를 더 잘 보장한다는 것이다. TCP 의 디폴트 설정에서 확실히 response time 의 variance 는 들쭉 날쭉하다.
그렇지만 이것은 bandwidth utilization 을 높이기 위해 존재하는 두가지 hack 때문이다.

1. nagle algorithm
unacknowledged data 가 있을때 data transfer request 가 들어오더라도 unacknowledged data 가 acknowlegment 될 때 까지 기다렸다가 data 를 보낸다.

2. delayed ack
TCP header 가 payload 없이 전송되는 bandwidth 낭비를 막기 위해, 정해진 시간 (보통 100ms) 동안 ack 를 늦추면서 다른 data 가 전송될때 ack 를 싣는다.

2번과 1번은 요즘 거의 모든 OS 의 TCP 설정에서 디폴트다. 위의 피쳐들이 bandwidth utilization 면에서는 좋은 피쳐들이지만 response delay 측면에서는 좋지 않다. response dealy 가 중요할때는 단순히 TCP_NODELAY 옵션을 주면 1,2번의 영향을 없애버릴 수 있다. TCP_NODELAY 를 주고 나면 UDP 와 TCP 의 response dealy 는 거의 차이가 없다.

그렇다면 UDP 의 TCP 에 대한 장점은 없을까? 없을리가 없다. 확실히 low level control 은 protocol stack 을 다 만들어야 하지만 대신 몇가지 예외를 핸들하는데서 확실히 유리하다.
다음은 그 몇가지 예외다.

1. sending urgent control message
UDP 의 경우 packet 단위로 data 가 전송 되므로 data 가 전송되는 와중에도 간단히 urgent control message 를 끼워 넣을 수 있다. 이를 위해 OOB sending 이 TCP 에 있지만, OS 마다 세만틱이 다르고 정확한 동작을 게런티 하지 않으며, data receiving 에서 if 문이 하나 추가 된다. UDP 의 경우 보통의 packet handler 에서 처리할 수 있으며, data buffering mechanism 과도 쉽게 integration 이 가능하다.

2. fail-over
UDP 의 경우 connection 이라는 것이 따로 존재 하지 않으므로, 각각의 request 에 대해서만 sanity 를 atomic 하게 체크하면 된다. TCP 의 경우에는 각각의 connection 은 상대의 인터페이스는 살아 있고 기계는 비정상인 경우 sanity check 를 하기 위해서 별도의 PING/PONG mechanism 이 필요하다.