TCP/IP 전송제어 프로토콜은 신뢰성에 초점을 맞추고 데이터가 신뢰성있게 올바른 순서로 유실되지 않게 빨리 전송할 수 있도록 설계된 프로토콜이다.
TCP 의 기본적인 작동 원리는 다음과 같다.
<TCP hand shake >
<출처 : https://wiki.mikrotik.com/wiki/Manual:Connection_oriented_communication_(TCP/IP)>
TCP 는 통신을 위해 3 way handshake 란 방식을 이용한다. 먼저 통신이 가능한지 SYN 을 보내고, 통신이 가능하다는 SYN-ACK을 받는다. 이 과정에서 문제가 없으면 이제 통신하고자 하는 메시지를 보내고, 양방향 통신이 된다. 이 과정을 3-WAY Handshake 라 하며, 이 과정은 TCP 매 통신 시마다 적용이 되며, 통신이 끝날때에는 SYN 대신 FIN 을 보내서 서로 확인을 받는다. 이러한 과정을 통해 TCP 는 무조건 메시지가 잘 전달되었으며 잘 도착했다는 확인을 받게 되고, 신뢰성을 보장받게 된다. 이러한 특성으로 TCP는 주로 전화에 비견된다. 이러한 TCP 통신을 위한 헤더는 다음과 같다.
위의 헤더 정보에는 보내는 메시지의 목적지 주소와, 순서 보장을 위한 일련 번호(Sequence Number), 에러 체크를 위한 Checksum 정보 등이 포함된다.
그 외에 사용하는 TCP 알고리즘 별로 슬라이딩 윈도우 정보 등 다양한 정보가 포함될 수 있다.
슬라이딩 윈도우는 패킷의 흐름을 제어하기 위한 메모리 버퍼(Window) 로, 다양한 경우에 대비해서 사용된다. 가령 3WAY Handshaking 중 네트워크 장애 발생이나, 받은 메시지가 중간에 누락이 된 경우 해당 패킷의 재전송이 필요하다. 다음 패킷의 전송을 멈추고 이전 패킷의 전송을 기다리는 Stop And Wait 방식 보다, 훨씬 효율적일 수 있다.
<슬라이딩 윈도우 송신 측>
위의 그림 처럼 슬라이딩 윈도우는 이미 전송하고 확인이 완성된 부분, 전송했지만 확인되지 않은 부분, 보내지 않았지만 수신자가 수신 준비 된부분, 수신준비 되지 않았으며 송신하지 않은 부분으로 영역을 나누어 네트워크 상황에 따라 포인터를 관리한다.
<슬라이딩 윈도우 수신 측>
위의 그림은 수신측이다. 받았고 승인한 버퍼를 갖고 있으며 ( 이 버퍼는 나중에 다른 패킷으로 덮어써진다.) 수신자가 아직 받지 못한 부분, 수신준비되지 않았으며 수신하지 않은 부분으로 나뉘며 전송 상태에 따라 포인터를 조정한다.
(관련 내용의 예시를 잘 정리한 블로그는 다음을 참조하기 바란다. http://blog.naver.com/donjobani/30110435544)
위의 내용들을 바탕으로 한 TCP 의 특징을 정리하자면 다음과 같다.
(1) Connection Oriented : 2개의 endpoint간 연결을 먼저 맺고 데이터 통신을 한다.
(2) Bidirectional byte stream : 양방향 Data stream(Byte stream)
(3) In-order delivery : 송신자가 보낸 순서대로 수신하며 Segment의 데이터 순서 표시를 위한 32비트의 정수를 사용한다.
(4) Reliability through ACK : 송신자는 수신자가 ACK 보내는 것을 체크하고 보내지 않은 데이터를 보관한다.
(5) Flow control : 송신측과 수신측의 처리 속도 차이를 해결하기 위해(특히 수신측이 느린 경우) 지원하는 제어 방식으로 흐름 제어라 불린다. 속도 차이로 전송 누수가 생기는 것을 방지하기 위해서 수신자는 받을 수 있는 버퍼의 크기(Receive window)를 송신자에 전달하여 송신자가 보내는 양을 제어하게 한다.
(6) Congestion control : 통신시 한 Router에 데이터가 몰려 혼잡할 경우, 호스트 들이 데이터 유실 때문에 재전송을 하게 되고 결국 혼잡이 더 늘어나는 악순환이 생긴다. 이를 막기 위해 송신측에서는 Congestion window가 존재하여 허용하는 만큼만 전송하게 하여 혼잡을 제어한다. TCP Vegas, BIC, CUBIC 등의 알고리즘을 사용한다.
반면 UDP는 이러한 Hand shaking 과정이 없다. UDP 의 통신과정은 단순하다. 단순히 명시받은 IP 주소와 포트로 메시지를 UDP 헤더를 담은 메시지를 보낸다. UDP 헤더가 담긴 메시지를 받으면, 어플리케이션은 해당 메시지를 해독해서 로직을 처리한다. UDP 헤더는 다음과 같다. TCP 헤더보다 많이 단순한 모양이다.
하지만 TCP 와 다르게 UDP 는 응답값을 기대하면 안된다. 신뢰성이 보장되지 않기 때문에, 중간에 네트워크 이슈로 인해 데이터가 손실되더라도 이를 알아차릴 방법이 없다. 그렇게 때문에 UDP 는 편지에 비유되며, 상대방 IP 주소의 포트에 메시지를 놓고온다고 이해하면 쉽다.
정리하자면, TCP의 경우 좀 더 시간이 오래 걸리는 무거운 프로토콜이지만 신뢰성이 보장되며 UDP 의 경우 가볍지만 신뢰성을 보장할 수는 없다. 이런 특징 때문에 신뢰성이 중요한 메시지 들은 TCP로, 몇몇 패킷이 누락되어도 상관없는, 가령 이미지나 실시간 스트리밍 들은 UDP 로 구현이 된다.
물론 몇몇 서비스의 경우에는 비즈니스 로직에 따라 UDP 로 구현하되, 헤더를 커스터마이즈하여 특정 조건에서 신뢰성을 갖으면서 가볍고 빠른 자체 프로토콜을 만들어 서비스 품질을 높이는 경우가 많다.