[UNP] 2.4 (TCP) Transmission Control Protocol

TCP

 - connection 기반으로 데이터를 교환한다.

 - Reliable 

 - ACK가 오지 않으면 자동으로 데이터를 재전송하고, 기다린다.

   보통 4~10분간(구현에 따라 다름) 몇 번의 데이터 재전송을 해도 응답이 없다면 포기한다. 

 - 다른 endpoint로부터의 데이터를 receive할 거라는 보장을 하지 않는다. 그저 가능하다면 데이터를 전달하는 것이다. 

   데이터를 받을 수 없다면 그 정보를 알려 준다.

- 그래서 TCP는 100% 신뢰성 있는 프로토콜을 보장하는 것이 아니다.

- Round-Trip Time(RTT : ACK가 얼마나 오래 걸리는지에 대한 시간 => 패킷 주고받는 시간)을 추정하는 알고리즘을 사용한다.

  만약 LAN을 통한 RTT는 밀리초 단위 시간이 걸린다면, WAN에서는 초 단위로 걸릴 수 있다.

  네트워크 트래픽에 의해 영향을 받기 때문에, TCP는 지속적으로 RTT 체크를 한다.

 - TCP는 모든 데이터의 연속성을 보장하며 전송한다. 실제로 TCP는 내부적으로 Sequence 번호를 가지고 있다.

   예를 들어, TCP 소켓에 2048bytes를 2번의 segment로 전송했다고 가정하면, 1번째에 1 ~ 1024, 2번째에 1025 ~ 2048까지 번호를 저장한다.

 - 만약 수신자 측에서 segment가 꼬이면, sequence number를 토대로 2개의 세그먼트를 재배열한다.

   * 즉, TCP는 보낼 때 데이터를 sequence number와 함께 순서대로 보내지만, 사실 receive하는 쪽은 순서와 상관없이 받을 수도 있다. 

  그래서 내부적으로  sequence number를 확인하여 재배치하는 작업을 한다.

   또, TCP가 어떤 peer(네트워크 과부하 혹은 다른 오류로 인해 새그먼트가 분실되었다 생각하고 재전송된)로부터 중복된 데이터를 receive했을 때에도, 

   TCP는 sequence number를 토대로 중복됨을 감지해 낸 후, 중복된 데이터를 파기한다.

 - Flow Control을 제공한다. 한 번에 peer로부터 데이터를 몇 byte를 받는지 알 수 있다. 이걸 window라 하는데, 

   현재 receive buffer에서 수용 가능한 양을 의미한다. 송신 측에서 receive buffer를 overflow시킬 수 없도록 해 주는 것을 보장한다.

   데이터가 송신 측으로부터 수신되면 window의 size는 감소한다. 하지만 버퍼에서 데이터를 읽을 때, 다시 window size가 늘어난다. buffer에 데이터가 

   꽉 차서 window size가 0일 때가 있는데, 이렇게 되면 buffer에서 데이터를 읽을 때까지 기다리게 된다.

UDP

 - Sequence number나 ACK, RTT estimation(추정), timeout(아까 TCP에서 4~10분 얘기했던 거), ReTransmission을 일체 제공하지 않는다.

 - UDP Datagram은 sequence number가 없기 때문에, 중복된 데이터를 받을 때도 있다. 

 - 데이터 순서(배치)가 꼬일 수 있다.

UDP로 프로그램을 개발한다면, 위의 상황을 잘 고려해서 개발해야 한다.

 - Flow Control를 제공하지 않는다.

TCP는 Full-duplex(양방향) 통신이다. 이 말은 즉 TCP는 sequence number / window size 같은 상태 정보를 항상 추적하고 있어야 한다는 뜻이다.