TCP와 UDP

TCP와 UDP

 

• TCP와 UDP는 OSI 표준 모델과 TCP/IP 모델의 전송 계층에서 사용되는 프로토콜입니다. 전송 계층은 송신자와 수신자를 연결하는 통신 서비스를 제공하고 IP에 의해 전달되는 패킷의 오류를 검사하며 재전송 요구 제어 등을 담당하는 계층입니다. 쉽게 말해 데이터의 전달을 담당한다고 생각하면 됩니다. TCP와 UDP는 포트 번호를 이용하여 주소릴 지정하는 것과 데이터 오류 검사를 위한 CheckSum이 존재한다는 두 가지 공통점을 가지고 있지만 정확성(TCP)을 추구할지 신속성(UDP)을 추구할지 구분하여 나뉩니다.
• 데이터를 중요하게 생각하여 확실히 주고받고 싶을 때는 TCP(Transmission Control Protocol)를 사용합니다. TCP는 통신할 컴퓨터끼리 '보냈습니다', '도착했습니다'라고 서로 확인 메시지를 보내면서 데이터를 주고 받음으로써 통신의 신뢰성을 높입니다. 웹이나 메일, 파일 공유 등과 같이 데이터를 누락시키고 싶지 않은 서비스는 TCP를 사용하고 있습니다.
• 그에 반해, 데이터의 신뢰성은 제쳐두고 빨리 보내고 싶을 때는 UDP(User Datagram Protocol)를 사용합니다. UDP는 데이터를 보내면 그것으로 끝이므로 신뢰성은 없지만, 확인 응답과 같은 절차를 생략할 수 있으므로 통신의 신속성을 높입니다. VoIP(Voice over IP)나 시간 동기, 이름 해결 등과 같이 무엇보다 속도를 필요로하는 서비스는 UDP를 사용하고 있습니다.

  포트 번호로 서비스를 식별한다.

  TCP와 UDP는 '포트 번호'라는 숫자를 이용하여 컴퓨터 안의 어떤 서비스(애플리케이션)에게 데이터를 전달하면 좋은지를 식별합니다. 포트 번호는 '0~65535'(16비트 분)까지의 숫자로 되어 있으며, 범위에 따라 용도가 정해져 있습니다. '0~1023'은 '잘 알려진 포트(well-known port)'라고 해서 웹 서버나 메일 서버 등과 같이 일반적인 서버 소프트웨어가 클라이언트의 서비스 요청을 대기할 때 사용합니다. '1024~49151'은 '등록된 포트(registered port)'로, 제조업체의 독자적인 서버 소프트웨어가 클라이언트의 서비스 요청을 대기할 때 사용합니다. '49152~65535'는 '동적 포트(dynamic port)'로, 서버가 클라이언트를 식별하기 위해 사용합니다.

 

TCP (Transmission Control Protocol)

• TCP는 연결 지향적 프로토콜입니다. 연결 지향 프로토콜이란 클라이언트와 서버가 연결된 상태에서 데이터를 주고 받는 프로토콜을 의미합니다. 클라이언트가 연결 요청(SYN 데이터 전송)을 하고, 서버가 연결을 수락하면 통신 선로가 고정되고, 모든 데이터는 고정된 통신 선로를 통해서 순차적으로 전달됩니다. 그렇기 때문에 TCP는 데이터를 정확하고 안정적으로 전달할 수 있습니다. TCP는 호스트 간 신뢰성 있는 데이터 전달과 흐름 제어를 합니다. TCP 프로토콜은 신뢰성 있는 데이터의 전송을 위해 확인 작업을 거치는데, TCP는 패킷을 성공적으로 전송하면 ACK라는 신호를 날리고, 만약에 ACK 신호가 제시간에 도착하지 않으면 Timeout이 발생하여 패킷 손실이 발생한 패킷을 다시 전송해줍니다. TCP는 이렇게 데이터를 송신할 때마다 확인 응답을 주고 받는 절차가 있으므로 통신의 신뢰성이 올라갑니다. 주로 Client와 Server 또는 P2P Socket 통신 등 네트워크를 사용한 통신을 할 때 TCP 통신을 많이 사용합니다.

 

• TCP의 단점
  • 데이터로 보내기 전에 반드시 연결이 형성되어야 함
  • 1:1 통신만 가능함
  • 고정된 통신 선로가 최단선(네트워크 길이)이 아닐 경우, 상대적으로 UDP보다 데이터 전송 속도가 느림

   

• TCP의 특징
  1. 연결형 (Connection-Oriented) 서비스로, 연결이 성공해야만 통신이 가능합니다.
  2. 데이터의 경계를 구분하지 않습니다. (바이트 스트림 서비스)
  3. 데이터의 전송 순서를 보장합니다. (데이터의 순서 유지를 위해 각 바이트마다 번호를 부여)
  4. 신뢰성 있는 데이터를 전송합니다. (Sequence Number, Ack Number를 통한 신뢰성 보장)
  5. 데이터 흐름 제어(수신자 버퍼 오버플로우 방지) 및 혼잡 제어(패킷 수가 과도하게 증가하는 현상 방지)
  6. 연결의 설정(3-way handshaking)과 해제(4-way handshaking)
  7. 전이중(Full-Duplex), 점대점(Point to Point) 방식
  8. UDP보다 전송 속도가 느립니다.

   

• TCP 서버의 특징
  • 서버 소켓은 연결만을 담당합니다.
  • 연결 과정에서 반환된 클라이언트 소켓은 데이터의 송수신에 사용됩니다.
  • 서버와 클라이언트는 1:1로 연결됩니다.
  • 스트림 전송으로 전송 데이터의 크기가 무제한입니다.
  • 패킷에 대한 응답을 해야하기 때문에 성능이 낮습니다.(시간 지연, CPU 소모)
  • Streaming 서비스에 불리합니다. (손실된 경우 재전송 요청을 하므로)

   

• 3-way handshaking 방식(SYN, ACK)

  

  • TCP 통신을 위한 네트워크 연결은 3-way handshaking 이라는 방식으로 연결됩니다. 3-way handshaking 방식은 서로의 통신을 위한 관문(port)을 확인하고 연결하기 위해 3번의 요청/응답 후에 연결이 되는 것을 말합니다. (이 과정에서 가장 많은 시간이 소요되어 UDP 방식보다 속도가 느려지는 주요 원인으로 지목됩니다.)
  • 연결 과정
    1. Client에서 Server에 연결 요청을 하기 위해 SYN 데이터를 보냅니다.
    2. Server에서 해당 포트는 LISTEN 상태에서 SYN 데이터를 받고 SYN_RCV로 상태가 변경됩니다.
    3. 그리고 요청을 정상적으로 받았다는 대답(ACK)와 Client도 포트를 열어달라는 SYN을 같이 보냅니다.
    4. Client에서는 SYN+ACK를 받고 ESTABLISHED로 상태를 변경하고 서버에 ACK를 전송합니다.
    5. ACK를 받은 서버는 상태가 ESTABLISHED로 변경됩니다.

    위와 같이 3번의 통신이 정상적으로 이루어지면, 서로의 포트가 ESTABLISHED가 되면서 연결이 됩니다.

   

• 4-way handshaking 방식(FIN, ACK)

  

  • 4-way handshaking은 클라이언트와 서버의 통신을 종료하기 위해 4번의 요청/응답이 일어나는 과정을 말합니다.
  • 연결 과정
    1. Client가 연결을 종료하기 위해 FIN 신호를 전송합니다.
    2. Server는 Client의 요청(FIN)을 받고 정상적으로 받았다는 확인 메시지(ACK)를 보냅니다.
       그 후에는 데이터를 모두 보낼 때까지 잠깐 TIME_OUT 상태가 됩니다.
    3. 데이터를 모두 보내고 통신이 끝나면, 연결이 종료되었다고 Client에게 FIN 신호를 보냅니다.
    4. Client는 FIN 메시지를 확인했다는 메시지(ACK)를 보냅니다.
    5. 클라이언트의 ACK 메시지를 받은 서버는 연결을 Close 합니다.
    6. Client는 아직 서버로부터 받지 못한 데이터가 있을 것을 대비해 일정 시간 동안 세션을 남겨놓고 남은 패킷을 기다리는 과정을 거칩니다. (TIME_WAIT)

  SYN / ACK

  SYN :: Synchronize Sequence Number

  ACK :: ACKnowledgement

   

  TCP State

  • netstat 명령어를 통해 확인 가능
  • LISTEN : 서버의 데몬이 떠서 접속 요청을 기다리는 상태
  • SYN-SENT : 로컬의 클라이언트 애플리케이션이 원격 호스트에 연결을 요청한 상태
  • SYN_RECEIVED : 서버가 원격 클라이언트로부터 접속 요구를 받아 클라이언트에게 응답을 하였지만, 아직 클라이언트에게 확인 메시지는 받지 못한 상태
  • ESTABLISHED : 3-way handshaking이 완료된 후, 서로 연결된 상태
  • FIN-WAIT1, CLOSE-WAIT, FIN-WAIT2 : 서버에서 연결을 종료하기 위해 클라이언트에게 종결을 요청하고 회신을 받아 종료하는 과정의 상태
  • TIME-WAIT : 연결은 종료되었지만 분실되었을지 모를 느린 세그먼트를 위해 당분간 소켓을 열어두고 있는 상태
  • CLOSING : 흔하지 않지만 주로 확인 메시지가 전송 도중 분실된 상태
  • CLOSED : 완전히 종료된 상태

   

• TCP 헤더 정보

  

필드	크기	내용
송수신자의 포트 번호	16	TCP로 연결되는 가상 회선 양단의 송수신 프로세스에 할당되는 포트 주소
시퀀스 번호 (Sequence Number)	32	송신자가 지정하는 순서 번호, 전송되는 바이트 수를 기준으로 증가 SYN = 1 : 초기 시퀀스 번호가 됩니다. ACK 번호는 이 값에 1을 더한 값 SYN = 0 : 현재 세션의 이 세그먼트 데이터의 최초 바이트 값의 누적 시퀀스 번호
응답 번호 (ACK Number)	32	수신 프로세스가 제대로 수신한 바이트 수를 응답하기 위해 사용
데이터 오프셋 (Data Offset)	4	TCP 세그먼트의 시작 위치를 기준으로 데이터의 시작 위치를 표현(TCP 헤더의 크기)
예약 필드 (Reserved)	6	사용을 하지 않지만, 나중을 위한 예약 필드이며 0으로 채워져야 합니다.
제어 비트 (Flag Bit)	6	SYN, ACK, FIN 등의 제어 번호
윈도우 크기 (Window)	16	수신 윈도우의 버퍼 크기를 지정할 때 사용. 0이면 송신 프로세스의 전송 중지
체크섬 (Checksum)	16	TCP 세그먼트에 포함되는 프로토콜 헤더와 데이터에 대한 오류 검출 용도
긴급 위치 (Urgent Pointer)	16	긴급 데이터를 처리하기 위함. URG 플래그 비트가 지정된 경우에만 유효

 

• TCP 제어 비트(Flag Bit) 정보

종류	내용
ACK	응답 번호 필드가 유효한지 설정할 때 사용하며 상대방으로부터 패킷을 받았다는 걸 알려주는 패킷. 클라이언트가 보낸 최초의 SYN 패킷 이후에 전송되는 모든 패킷은 이 플래그가 설정되어야 합니다.
SYN	연결 설정 요구. 동기화 시퀀스 번호. 양쪽이 보낸 최초의 패킷에만 이 플래그가 설정되어 있어야 합니다. TCP에서 세션을 성립할 때, 가장 먼저 보내는 패킷, 시퀀스 번호를 임의로 설정하여 세션을 연결하는 데에 사용되며 초기에 시퀀스 번호를 보내게 됩니다.
PSH	수신 애플리케이션에 버퍼링된 데이터를 상위 계층에 즉시 전달할 때 사용
RST	연결의 리셋이나 유효하지 않은 세그먼트에 대한 응답용으로 사용
URG	긴급 위치 필드가 유효한지 설정 (긴급한 데이터는 다른 데이터에 비해 우선순위가 높음)
FIN	세션 연결을 종료시킬 때 사용되며 더 이상 전송할 데이터가 없을 때 연결 종료 의사 표시

 

패킷(Packet) 이란?

인터넷 내에서 데이터를 보내기 위한 경로 배정(라우팅)을 효율적으로 하기 위해서 데이터를 여러 개의 조각들로 나누어 전송하는데 이때, 이 조각을 패킷이라고 합니다.

TCP가 패킷을 추적 및 관리하는 방법은?

데이터는 패킷 단위로 나누어 같은 목적지(IP 계층)로 전송됩니다. 예를 들어, 한 줄로 서야하는 A, B, C라는 사람(패킷)들이 서울(발신지)에서 출발하여 부산(수신지)으로 간다고 합시다. 그런데 A, B, C가 순차적으로 가는 상황에서 B가 길을 잘못 들어서 분실되었다고 했을 때, 목적지에서는 A, B, C가 모두 필요한지 모르고 A, C만 보고 다 왔다고 착각할 수 있습니다. 그렇기 때문에 A, B, C라는 패킷에 1, 2, 3이라는 번호를 부여하여 패킷의 분실 확인과 같은 처리를 하여 목적지에서 재조립을 합니다. 이런 방식으로 TCP는 패킷을 추적하며, 나누어 보내진 데이터를 받고 조립을 할 수 있습니다.

 

• TCP Flow

  

 

 

UDP(User Datagram Protocol)

• UDP는 전송 계층의 비연결 지향적 프로토콜입니다. 비연결 지향적이란 데이터를 주고 받을 때, 연결 절차를 거치지 않고 발신자가 일방적으로 데이터를 발신하는 방식을 의미합니다. 연결 과정이 없기 때문에 TCP보다 빠른 전송을 할 수 있지만, 데이터 전달의 신뢰성은 떨어집니다. UDP는 발신자가 데이터 패킷을 순차적으로 보내더라도 이 패킷들은 서로 다른 통신 선로를 통해 전달될 수 있습니다. 먼저 보낸 패킷이 느린 선로를 통해 전송될 경우, 나중에 보낸 패킷보다 늦게 도착할 수 있으며 최악의 경우 잘못된 선로로 전송되어 유실될 수도 있습니다. 이럴 경우 TCP와는 다르게 UDP는 중간에 패킷이 유실되거나 변조되어도 재전송을 하지 않습니다.
• UDP는 비연결형 서비스이기 때문에, 연결을 설정하고 해제하는 과정이 존재하지 않습니다. 서로 다른 경로로 독립적으로 처리하는데도 패킷에 순서를 부여하여 재조립을 하거나 흐름 제어 또는 혼잡 제어와 같은 기능도 처리하지 않기 때문에 TCP 보다 속도가 빠르며 네트워크 부하가 적다는 장점이 있지만, 신뢰성있는 데이터의 전송을 보장하지는 못합니다. 그렇기 때문에 신뢰성보다는 연속성이 중요한 서비스, 예를 들면 실시간 서비스(Streaming)에 자주 사용됩니다.

 

• UDP의 단점
  • 데이터의 신뢰성이 없습니다.
  • 의미있는 서버를 구축하기 위해서는 일일이 패킷을 관리해주어야 합니다.

 

• UDP의 특징
  1. 비연결형 서비스로 연결없이 통신이 가능하며 데이터그램 방식을 제공합니다.
  2. 데이터 경계를 구분합니다. (Datagram 서비스)
  3. 정보를 주고 받을 때, 정보를 보내거나 받는다는 신호 절차를 거치지 않습니다.
  4. 신뢰성 없는 데이터를 전송합니다.(데이터 재전송과 데이터 순서 유지를 위한 작업을 하지 않습니다.)
  5. UDP 헤더의 CheckSum 필드를 통해 최소한의 오류만 검출합니다.
  6. 패킷 관리가 필요합니다.
  7. 패킷 오버헤드가 적어 네트워크 부하가 감소된다는 장점이 있습니다.
  8. 상대적으로 TCP보다 전송 속도가 빠릅니다.

 

• UDP 서버의 특징
  1. UDP에는 연결 자체가 없어서(connect 함수 불필요) 서버 소켓과 클라이언트 소켓의 구분이 없습니다.
  2. 소켓 대신 IP를 기반으로 데이터를 전송합니다.
  3. 서버와 클라이언트는 1:1, 1:N, N:M 등으로 연결될 수 있습니다.
  4. 데이터그램(메시지) 단위로 전송되며, 그 크기는 65535 바이트로 크기가 초과하면 잘라서 보냅니다.
  5. 흐름 제어(Flow Control)가 없어서 패킷이 제대로 전송되었는지, 오류가 없는지 확인할 수 없습니다.
  6. 파일 전송과 같은 신뢰성이 필요한 서비스보다 성능이 중요시되는 경우에 사용됩니다.

 

흐름 제어(Flow Control)와 혼잡 제어(Congestion Control)란?

흐름 제어는 데이터를 송신하는 곳과 수신하는 곳의 데이터 처리 속도를 조절하여 수신자의 버퍼 오버플로우를 방지하는 것입니다. 예를 들어, 송신하는 곳에서 감당이 안되게 데이터를 빠르게 많이 보내면 수신자에서 문제가 발생하기 때문입니다.

혼잡 제어는 네트워크 내의 패킷 수가 넘치게 증가하지 않도록 방지하는 것입니다. 만약, 정보의 소통량이 과다하면 패킷을 조금만 전송하여 혼잡 붕괴 현상이 일어나는 것을 막습니다.

 

• UDP 헤더 정보

  필드	크기	내용
  송신자의 포트 번호	16	데이터를 보내는 애플리케이션의 포트 번호
  수신자의 포트 번호	16	데이터를 받을 애플리케이션의 포트 번호
  데이터의 길이	16	UDP 헤더와 데이터의 총 길이
  체크섬(CheckSum)	16	데이터 오류 검사에 사용

 

• UDP Flow

  

 

TCP vs UDP

• 공통점
  • 포트 번호를 이용하여 주소를 지정
  • 데이터 오류 검사를 위한 체크섬(CheckSum) 존재

   

• 차이점

	TCP	UDP
연결방식	연결형 서비스	비연결형 서비스
패킷 교환 방식	가상 회선 방식	데이터그램 방식
전송 순서	전송 순서 보장	전송 순서가 바뀔 수 있음
수신 여부 확인	수신 여부를 확인함	수신 여부를 확인하지 않음
통신 방식	1:1 통신만 가능	1:1 / 1:N / N:M 통신 모두 가능
신뢰성	높음	낮음
속도	느림	빠름

 

 

 

 

 

References

• https://coding-factory.tistory.com/614
• https://mangkyu.tistory.com/15
• https://asfirstalways.tistory.com/356
• https://swiftymind.tistory.com/35