[네트워크] TCP와 UDP

TCP와 UDP는 OSI 7 계층 중 전송 계층에서 사용되는 프로토콜로, 전송 계층은 송신자와 수신자를 연결하는 통신 서비스를 제공하는 계층이다.

 

TCP / IP 프로토콜의 패킷 교환 방식

전 세계를 연결하는 복잡한 네트워크인 인터넷에서는 엄청난 양의 데이터를 효율적으고 안정적으로 전송하기 위해 패킷 교환 방식으로 데이터를 전송한다.
이때 TCP와 IP는 패킷 교환 방식에 따라 데이터를 전송할 때 사용하는 프로토콜이다.

• 네트워크에서 데이터 전송 방식
  • 송신지 호스트에서 수신지 호스트로 데이터가 전송될 때, 데이터가 중간 노드들을 경유하게 되는데 어떤 링크로 이동할지 선택하고 이동한다.
  • 이때 노드와 노드 사이의 이동 과정에서 어떤 경로를 선택해 데이터를 전송하는 방법은 크게 2가지가 존재한다.
    • 회선 교환 방식
    • 패킷 교환 방식
• 회선 교환(Circuit Switching) 방식
  • 통신하고자 하는 두 호스트가 데이터를 전송하기 전에 미리 데이터 이동 경로를 하나 설정해두는 방식
  • 미리 설정해 둔 경로는 두 호스트만을 위한 전용 경로가 되며 이 경로를 통해 통신의 처음부터 끝까지 모든 데이터가 이동
  • 과거에는 회선 교환 방식을 사용하였는데 미리 이동 경로를 결정하기 때문에 연결된 선 하나가 잘려나가면 그대로 통신이 끊기는 문제 존재
    • 하나의 회선에 전적으로 의존하는 연결이라는 큰 단점을 보완하기 위해 나온 방식이 패킷 교환 방식
• 패킷 교환 방식(Packet Switching) 방식
  • 미리 고정된 이동 경로를 설정하지 않는 대신, 패킷이라는 작은 단위로 나누어 전송하는 방식
  • 데이터는 네트워크를 통해 전송되기 전에 패킷이라는 작은 조각으로 나누고 각 패킷에는 고유 번호가 있어 네트워크를 거쳐 최종 수신지에 전송되었을 때 원래의 데이터로 재결합
    • 각 패킷은 전송 당시 가장 효율적인 경로를 각자 설정하여 최종 수신지까지 이동
    • 패킷을 수신한 중간 노드가 패킷의 수신지 호스트를 확인하고 수신지 호스트까지 가는 다양한 경로 중 가장 좋다고 판단되는 경로를 따라 다음 중간 노드로 패킷을 전송하는 기능(라우팅)을 수행
  • 현재는 데이터를 패킷이라는 작은 단위로 분할하여 라우터를 통해 전송하는 것이 기본
  • 패킷 교환 방식의 유형
    • 가상 회선 패킷 교환 (연결 지향 패킷 교환) → TCP
    • 데이터그램 패킷 교환 (비연결 지향 패킷 교환) → UDP

 

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

 

TCP (Transmission Control Protocol) 란?

• 전송 제어 프로토콜로 인터넷상에서 데이터를 메세지 형태로 보내기 위해 IP와 함께 사용하는 프로토콜이다.
• 일반적으로 TCP와 IP를 함께 사용하여 TCP / IP 프로토콜로 불리기도 한다.
  • IP : 인터넷 망 속에서 IP 주소와 패킷과 같은 규칙을 통해 클라이언트와 서버 간에 통신을 할 수 있게 하는 것
  • TCP :  IP 규칙으로 통신하기에 부족하거나 불안정한 단점들을 보완하기 위해 패킷 전송을 제어하여 신뢰성을 보장
  • → IP가 데이터의 배달을 처리한다면 TCP는 패킷을 추적 및 관리
    
    • TCP 는 패킷을 어떻게 추척 및 관리하는가?
      데이터는 패킷 단위로 나누어 같은 목적지(IP 계층)으로 전송된다.
      
      ex) 한 줄로 서야 하는 A,B,C라는 사람(패킷)이 서울(송신측)에서 출발하여 부산(수신측)으로 가야한다고 가정한다.
      그런데 A,B,C가 순차적으로 가는 상황에서 B가 길을 잘못 들어서 분실되었다.
      하지만 목적지에서는 A,B,C가 모두 필요한지 모르고 A,C만 보고 다 왔다고 착각할 수 있다.
      그렇기 때문에 A,B,C라는 패킷에 1,2,3이라는 번호를 부여하여 패킷의 분실 확인 처리를 하기 위해 목적지에서 패킷을 재조립한다.
      이런 방식으로 TCP는 패킷을 추적하며, 나누어 보내진 데이터를 목적지에서 받고 재조립할 수 있게 된다.
      
• 네트워크에 연결된 컴퓨터에서 실행되는 프로그램 간에 데이터를 세그먼트(segment) 단위로 쪼개어 신뢰성(안정적으로, 순서대로, 에러 없이)을 기반한 통신을 제공한다. → 네트워크 통신에서의 신뢰성있는 데이터 전송을 지원하는 연결 지향형 프로토콜
  
  
• TCP는 기본적으로 unreliable network에서, reliable network를 보장할 수 있도록 하는 프로토콜
  • reliable network를 보장한다는 것은 4가지 문제점이 존재
    1. 손실 : packet이 손실될 수 있는 문제
    2. 순서 바뀜 : packet의 순서가 바뀌는 문제
    3. Congestion : 네트워크가 혼잡한 문제
    4. Overload : receiver가 overload 되는 문제
• TCP는 network congestion avoidance algorithm 사용

 

TCP 특징

• 연결형 서비스로 가상 회선 패킷 교환 방식 제공
  • 가상 회선 방식 : 발신지와 수신지를 연결하여 패킷을 전송하기 위한 논리적 경로를 배정
  • 3-way handshaking 과정을 통해 연결을 설정하고, 4-way handshaking 과정을 통해 연결을 해제(가상 회선 방식)
    • 3-way handshaking : 발신지와 수신지 사이에 논리적인 접속(세션)을 성립하는 과정
• 전송 제어
  • 흐름 제어 (flow control) : 데이터 처리 속도를 조절하여 수신자의 버퍼 오버플로우 방지
  • 오류 제어 (error control) : 데이터가 유실되거나 잘못된 데이터가 수신되었을 경우 대처하는 방법
  • 혼잡 제어 (congestion control) : 네트워크 내의 패킷 수가 과도하게 증가하지 않도록 방지
• 높은 신뢰성 보장
  • UDP보다 속도가 느리다.
• 전이중 (full-duplex), 점대점 (point to point) 방식
  • 전이중 : 전송이 양방향으로 동시에 일어날 수 있음
  • 점대점 : 각 연결이 정확히 2개의 종단점을 가지고 있음
• 데이터의 전송 순서를 보장하며 수신 여부 확인 가능
• 연속성 보다는 신뢰성이 있는 전송이 필요할 때 사용
  • ex) 파일 전송, 이메일 전송, 웹 HTTP 통신

 

TCP 헤더

TCP 헤더 크기는 최저 20byte로, 송수신자의 번호 뿐만 아니라 데이터 검증 및 순서 확인을 위한 정보 등을 포함하고 있다.

Wikipedia - TCP

• Source / Destiantion Port (발신/목적지 포트 번호)
  • 각 16 bit (0~15bit, 16~31bit), 2byte x2
  • 세그먼트의 출발지와 목적지를 나타내는 필드로, 애플리케이션 식별을 위한 포트 번호가 필요하다. (IP 주소는 네트워크 계층에 있는 IP 헤더에 담긴다.)
• Sequence Number
  • 32bit, 4byte
  • TCP 세그먼트를 올바른 순서로 정렬하기 위해 사용된느 필드
  • 송신 측 단말은 애플리케이션에서 받은 데이터의 각 바이트에 대해 초기 시퀀스 번호(ISN, Initial Sequence Number)에 연번을 부여
• Acknowledgement Number
  • 32bit, 4byte
  • 확인 응답 번호(ACK)는 다음 수신을 기대하는 데이터의 시퀀스 번호를 의미
• Data Offset (Header Length)
  • 4bit, 0.5byte
  • TCP 세그먼트가 시작되는 위치를 기준으로 헤더의 길이를 나타내는 필드
• Code Bit (Flags)
  • 6bit
  • 컨트롤 비트는 커넥션의 상태를 나타내는 필드
  • Bit Flag 종류

    비트	플래그 이름	설명	개요
    1번째 비트	CWR	Congestion Window Reduced	ECN-Echo에 따라, 혼잡 윈도우가 줄어든 것을 알리는 플래그
    2번째 비트	ECE	ECN-Echo	혼잡이 발생한 것을 통신 상대에게 알리는 플래그
    3번째 비트	URG	Urgent Pointer field significant	긴급을 나타내는 플래그
    4번째 비트	ACK	Acknowledgment field significant	확인 응답을 나타내는 플래그
    5번째 비트	PSH	Push Function	빠르게 애플리케이션에 데이터를 전달하는 플래그
    6번째 비트	RST	Reset the connection	커넥션을 강제로 끊는 플래그
    7번째 비트	SYN	Synchronize sequence numbers	커넥션을 여는 플래그
    8번째 비트	FIN	No more data from sender	커넥션을 닫는 플래그

• Window
  • 16bit
  • 한 번에 전송할 수 있는 데이터의 양
  • 단위 : BYTE
• CheckSum
  • 16bit, 2byte
  • 데이터 송신 중에 발생될 수 있는 오류를 검출하기 위한 값
  • 헤더 및 데이터를 16비트 단위로 분할하여 비트 합을 구한 뒤, 이에 대한 1의 보수를 취함으로써 계산
  • 만약 carry (자리 수가 하나 올라간 부분)가 발생한다면 wrap around(넘친 부분만 떼어내어 다시 더해줌) 적용
• Urgent Pointer (긴급 포인터)
  
  • 16bit, 2byte
  • 긴급 포인터는 컨트롤 비트의 URG 플래그가 1로 설정되었을 때 유효한 필드
  • 긴급 데이터가 있을 때 긴급 데이터를 나타내는 가장 마지막 바이트의 시퀀스 번호 설정
• Options
  • TCP에 관련된 확장 기능을 알리기 위해 사용

 

 

TCP 전송 제어 기법

흐름 제어, 오류 제어, 혼잡 제어

 

데이터 전송 과정

1. 응용 계층(Application Layer)에서 데이터를 전송할 때, 송신자(sender)의 애플리케이션(Application)은 소켓(Socket)에 데이터를 쓴다.
2. 이 데이터는 전송 계층으로 전달되어 세그먼트(segment)라는 작은 단위로 나뉜다.
3. 전송 계층은 이 세그먼트를 네트워크 계층으로 넘거준다.
4. 전송된 데이터는 수신자 쪽으로 전달되어 수신 버퍼(receive buffer)에 저장된다.
   • 이때 수신자 측에서는 수신 버퍼의 용량을 넘치지 않게 조절해야 한다.
   • 흐름 제어(control flow) 과정
     • 수신자 측에서 자신의 수신 버퍼의 남은 용량을 송신자에게 알려주는데 이를 수신 윈도우(receive window)라고 한다.
     • 송신자는 수신자의 수신 윈도우를 확인하여 수신자의 수신 버퍼 용량을 초과하지 않도록 데이터를 전송한다.
     • 이를 통해 데이터 전송 중에 수신 버퍼가 넘치는 현상을 방지하면서 안정적은 데이터 전송을 보장한다.
5. 수신 측 애플리케이션이 준비가 되면 수신 버퍼에 있는 내용을 읽기 시작한다.

 

1. 흐름 제어 (Flow Control)

데이터 전송 중에 발생하는 수신 버퍼의 오버플로우를 방지하면서, 안정적인 데이터 전송을 위한 기술
송신측과 수신측 사이의 데이터 처리 속도 차이(흐름)을 해결하기 위한 기법

• 수신 측이 송신 측보다 데이터 처리 속도가 빠르면 문제 x
• but 송신 측의 속도가 빠를 경우 문제가 발생한다.
  • 수신 측에서 제한된 저장 용량을 초과한 이후에 도착하는 데이터는 손실될 수 있으며, 만약 손실된다면 불필요한 응답과 데이터 전송이 발생한다.
  • 즉, 송신측의 전송량이 수신측의 처리량보다 클 경우, 전송된 패킷은 수신측의 큐를 넘어서 손실될 수 있기 때문에 송신측의 패킷 전송량을 제어해야 한다.
• 흐름 제어는 이러한 송신측과 수신 측의 데이터 처리 속도 차이를 해결하기 위한 기법으로
• 수신자가 패킷을 지나치게 많이 받지 않도록 조절하는 것이다.
  • 기본 개념은 수신자가 송신자에게 현재 자신의 상태를 feedback 하는 것

 

흐름 제어 기법

• Stop and Wait
  • 매번 전송한 패킷에 대해 확인 응답(ACK)를 받아야만 그 다음 패킷을 전송

              그러나 이는 패킷을 하나씩 보내기 때문에 비효율적

• Sliding Window
  • 수신 측에서 설정한 윈도우 크기만큼 송신 측에서 확인 응답 없이 세그먼트를 전송할 수 있게 하여 데이터 흐름을 동적으로 조절하는 제어 기법
  • 최초의 윈도우 크기는 3-way handshake 과정에서 수신 측의 윈도우 크기가 송신 측에 전달
    • 윈도우 크기 : 수신 측이 한 번에 처리할 수 있는 데이터의 양 
    • 이후 수신 측의 버퍼에 남아있는 공간에 따라 변함
    • 수신 측에서 송신 측으로 확인 응답(ACK)를 보낼 때 TCP 헤더(window size)에 담아서 보낸다.
    • 송신측에서는 ACK 프레임을 수신하지 않더라도 여러 개의 프레임을 연속적으로 전송할 수 있다.

 

2. 오류 제어 (Error Control)

• TCP 통신 중에 오류 (데이터 유실 or 잘못된 데이터 수신)가 발생하면 해당 데이터를 재전송
  • 재전송 기반 오류 제어 ARQ (Automatic Repeat Request)를 사용
    → 프레임이 손상되었거나 손실되었을 경우, 재전송을 통해 오류 복구
• 오류를 알 수 있는 방법
  • 송신 측이 ACK를 받지 못함 (송신 측이 보낸 데이터가 유실되거나 수신 측이 보낸 ACK 데이터가 유실된 경우)
  • 중복된 ACK를 받는 경우
  • 수신 측이 NACK(부정 응답)을 보내는 경우

 

오류 제어 기법

1. Stop and Wait ARQ
   • 송신측에서 1개의 프레임을 송신하고, 수신측에서 수신된 프레임의 에러 유무 판단에 따라 ACK or NAK를 보내는 방식이다.
   • 식별을 위해 데이터 프레임과 ACK 프레임은 각각 0,1 번호를 번갈아가며 부여한다.
     • 순서 번호(Sequence Number) 와 응답 번호(Acknowledgment Number, ACK Number) 를 이용해서 데이터 구분
     • 데이터 프레임 번호(sequence number) → 0 or 1
     • ACK 프레임 번호 (ACK number) → 0 or 1
     • 이 방식은 이전 프레임과 현재 프레임을 구별하기 위해 사용
   • 수신측이 데이터를 받지 못했을 경우, NAK를 보내고 NAK를 받은 송신측은 데이터를 재전송한다.
   • 만약, 데이터나 ACK가 분실되었을 경우 일정 간격의 시간을 두고 타임아웃이 되면, 송신측은 데이터를 재전송한다.

 

2. Go Back N (슬라이딩 윈도우)

• 어느 데이터로부터 오류가 발생했는지 파악하여, 오류가 발생한 지점부터 다시 순서대로 재전송하는 방식
• 전송된 프레임이 손상되거나 분실된 경우 그리고 ACK 패킷의 손실로 인한 TIME_OUT이 발생한 경우, 확인된 마지막 프레임 이후로 모든 프레임을 재전송한다.
• 슬라이딩 윈도우는 연속적인 프레임 전송 기법으로 전송측은 전송된 모든 프레임의 복사본을 가지고 있어야 하며, ACK와 NAK 모두 각각 구별해야 한다.
  • ACK : 다음 프레임을 전송
  • NAK : 손상된 프레임 자체 번호를 반환

• 성공적으로 전송된 데이터까지 재전송하기 때문에 비효율적

 

3. Select Reject ARQ(선택적 재전송)

• 에러가 난 데이터만 재전송하고, 그 전에 받았던 순서가 잘못된 데이터 버퍼를 재정렬하여 제어
• 수신 측 버퍼의 데이터가 순차적이지 않기 때문에 정렬의 과정이 추가로 필요하고 별도의 버퍼가 필요

 

3. 혼잡 제어 (Congestion Control)

• 네트워크의 혼잡을 피하기 위해 송신 측에서 보내는 데이터의 전송 속도를 강제로 줄이는 제어 기법
  • 송신 측의 데이터는 지역망이나 인터넷으로 연결된 대형 네트워크를 통해 전달되는데, 만약 한 라우터에 데이터가 몰리게 되면 자신에게 온 데이터를 처리할 수 없게 됨
  • 한 라우터에 데이터가 몰려 모든 데이터를 처리할 수 없는 경우 호스트들은 재전송을 하게 되고 결국 혼잡만 가중시켜 오버플로우나 데이터 손실 발생
  • 이러한 경우 호스트들은 재전송하게 되고, 결국 혼잡만 가중시켜 오버 플로우나 데이터 손실이 발생
• 송신 측의 데이터 전달과 네트워크의 데이터 처리 속도 차이를 해결하기 위한 기법
  • 흐름 제어가 송신 측과 수신 측 사이의 전송 속도를 다루는데 반해, 혼잡 제어는 호스트와 라우터를 포함한 보다 넓은 관점에서 전송 문제를 다룸

 

혼잡 제어 기법

1. AIMD(Additive Increase / Multiplicative Decrease)
   • 합 증가 / 곱 감소 알고리즘
   • 처음에 패킷을 하나씩 보내고 이것이 문제없이 도착하면 window 크기(단위 시간 내에 보내는 패킷의 수)를 1씩 증가시켜가며 전송하는 방법
   • 패킷 전송에 실패하거나 일정 시간을 넘으면(time out) 패킷의 보내는 속도(window size)를 절반으로 줄임
   • 장점
     • 공평하다
     • 여러 호스트가 한 네트워크를 공유하고 있으면 나중에 진입하는 쪽이 처음에는 불리하지만 시간이 흐르면 평형 상태로 수렴하게 되는 특징이 있다.
   • 단점
     • 윈도우 크기를 너무 조금씩 늘리기 때문에 네트워크의 모든 대역을 활용하여 제대로 된 속도로 통신하기까지 시간이 오래 걸린다.
     • 네트워크의 수용량 주변에서는 효율적으로 동작하지만 처음에 전송 속도를 올리는데 시간이 너무 길다.
     • 초기 네트워크의 높은 대역폭을 사용하지 못하고 네트워크가 혼잡해지는 상황을 미리 감지하지 못해 혼잡해지고 나서야 대역폭을 줄이는 방식이다.
2. Slow Start(느린 시작)
   • AIMD와 마찬가지로 패킷을 하나씩 보내는 것부터 시작
   • Slow Start는 AIMD와 마찬가지로 패킷을 하나씩 보내는 것부터 시작한다.
     이 방식은 패킷이 문제 없이 도착하면 각각의 ACK 패킷마다 Window Size를 1씩 늘린다.
     즉, 한 주기가 지나면 Window Size는 2배가 된다. → 그래프의 모양은 지수 함수 꼴이 된다.
   • AIMD에 반해 지수 함수 꼴로 증가시켜 윈도우 크기를 더 빠르게 증가시키다가 혼잡이 감지되면 윈도우 크기를 1로 줄이는 방식
     
     
   • 보낸 데이터의 ACK가 도착할 때마다 윈도우 크기를 증가시키기 때문에 처음에는 윈도우 크기가 조금 느리게 증가할지라도, 시간이 가면 갈수록 윈도우 크기가 점점 빠르게 증가함
   • 처음에는 네트워크의 수용량을 예측할 수 있는 정보가 없지만 한번 혼잡 현상이 발생하고 나면 네트워크의 수용량을 어느정도 예상할 수 있으므로 혼잡 현상이 발생하였던 Window Size의 절반까지는 이전처럼 지수 함수 꼴로 Window Size를 증가시키고 그 이후부터는 완만하게 1씩 증가시키는 방식
   • 전송되는 데이터의 크기가 임계 값에 도달하면 혼잡 회피 단계로 넘어간다.
     • 혼잡 회피(Congestion Avoidance)
       • 윈도우의 크기가 임계 값에 도달한 이후에는 데이터의 손실이 발생할 확률이 높아진다.
       • 따라서 이를 회피하기 위해 윈도우 크기를 선형적으로 1씩 증가시키는 방법이다.
       • 수신측으로부터 일정 시간 동안까지 ACK를 수신하지 못하는 경우
         • 타임 아웃의 발생 : 네트워크 혼잡이 발생했다고 인식
         • 혼잡 상태로 인식된 경우
           • 윈도우 크기를 즉, 세그먼트 수를 1로 감소
           • 동시에 임계값을 패킷 손실이 발생했을 때의 윈도우 크기의 절반으로 줄임
3. Fast Retransmit(빠른 재전송)
   • 패킷을 받는 수신자 입장에서는 세그먼트로 분할된 내용들이 순서대로 도착하지 않는 경우가 생길 수 있음
     • 이런 상황이 발생했을 때, 수신 측에서는 순서대로 잘 도착한 마지막 패킷의 다음 순번을 ACK 패킷에 실어서 보냄
       따라서 중간에 패킷 하나가 손실되면 송신측에서는 순번이 중복된 ACK 패킷을 받게 된다.
       이것을 감지하면 문제가 되는 순번의 패킷을 재전송할 수 있다.
     • 그리고 이런 중복 ACK를 3개 받으면 재전송이 이루어짐
       이러한 현상이 일어나는 것은 약간의 혼잡이 발생한 것으로 간주되어 window size를 절반으로 줄임
   • 송신 측은 자신이 설정한 타임 아웃 시간이 지나지 않았어도 바로 해당 패킷을 재전송할 수 있기 때문에 보다 빠른 재전송률을 유지할 수 있음
4. Fast Recovery(빠른 회복)
   • 혼잡한 상태가 되면 window size를 1로 줄이지 않고 반으로 줄이고 선형 증가시키는 방법
   • 혼잡 상황을 한 번 겪은 이후부터는 순수한 AIMD 방식으로 동작하게 됨

 

 

신뢰성있게 메세지가 누락 없이 잘 전송되면 좋은거 아닌가? udp는 왜 필요한 걸까?

TCP는 작은 패킷 하나가 제대로 전송되지 않더라도 재전송 된다.
이는 신뢰성을 보장하기도 하지만 예를 들어 사진을 전송의 경우 일부분이 눈에 띄지 않게 아주 조금 누락된 상황에서는 재전송하는 것이 비효율적일 수 있다.
따라서 이를 보안하고자 UDP가 등장했다.

 

 

UDP (User Datagram Protocol) 란?

• 사용자 데이터그램 프로토콜로 데이터를 데이터그램 단위로 처리하는 프로토콜
  • TCP는 세그먼트
  • 데이터그램 : 독립적인 관계를 지니는 패킷
• 데이터를 서로 다른 경로로 독립적으로 처리

 

UDP 특징

• 비연결형 서비스 : 사전 연결 설정 없이 데이터 전달
• 데이터그램 패킷 교환 방식 제공
  • 연결을 위해 할당하는 논리적인 경로가 없고, 하나의 메세지에서 분할된 각 패킷은 다른 경로로 전송되며 독립적인 관계를 지닌다.
  • 따라서 데이터의 전송 순서가 바뀔 수도 있다.
  • 그러나 서로 다른 경로로 패킷을 처리함에도 불구하고 순서를 부여하거나 재조립 x
• 데이터의 수신 여부를 확인 x
  • TCP의 3-way handshaking과 4-way handshaking과 같은 연결을 설정하고 해제하는 과정이 없다.
• 신뢰성이 낮다
  • 흐름 제어 또는 혼잡 제어와 같은 기능이 없어 제대로 전송되었는지 오류가 없는지 확인이 불가능하다.
  • 손상된 세그먼트에 대한 재전송 x
• TCP보다 속도가 빠르며 네트워크 부하가 적다.
• 1:1 & 1:N & N:N 통신이 가능하다.
  • 브로드캐스트 및 멀티캐스트 기능을 통해 하나의 UDP 전송을 여러 수신자에게 한 번에 전송할 수 있다.
• 신뢰성 보다는 연속성 있는 전송이 필요할 때 사용
  • ex. 실시간 서비스, RTP(Real Time Protocol), Multicast, DNS 등

 

UDP 헤더

UDP 헤더는 TCP와 비교했을 때 훨씬 더 작은 크기의 헤더를 갖는다.

• Source/Destination Port
  • UDP Datagram Length (16bit)
  • Checksum (16bit)

 

UDP를 사용해야하는 경우

1. 빈번한 서비스 요청
   
   • DNS의 경우 누군가 DNS 서비스를 요청할 때마다 TCP처럼 Session을 맺고 통신한다면 속도도 느리고, 서버 리소스도 엄청나게 소모될 것이다.
   • 그런가 하면 NMS(Network Management Server)가 5분에 한번씩 장비 상태를 점검하기 위해 정보를 읽어오는데 수백, 수천대의 장비와 Session을 맺어야 한다면 이것도 마찬가지로 문제가 생긴다.
   • → 따라서 UDP를 사용한다.
2.  재전송을 하면 안되는 서비스가 있다.
   • 대표적으로 RTP
   • 전화를 하고 있다 다고 가정
     • "여","보","세","요"라는 4개의 데이터를 전송했는데, "세"를 못받았다고 다시 보내달라고 하면 "여보요세"가 될 것
     • 이럴 때는 그냥 "여보X요"로 전달하는게 나은 상황
3. Multicast 서비스
   • 1:N으로 통신하는 방식에서 한 사람이 데이터를 받지 못했다고 재전송을 요청한다고 가정
   • 제대로 받은 사람들도 해당 데이터를 다시 받아서 처리해야 한다는 문제점이 발생할 수 있기 때문에 UDP를 사용

 

 

QUIC

• TCP와 비교했을 때 UDP 헤더 포멧은 거의 백지와 마찬가지로, User Datagram이라는 의미는 사용자가 정의해서 사용하라는 의미
  • 즉, 여기에 원하는 기능을 얼마든지 얹으면 되고 서버와 클라이언트의 구현에 따라 그 퍼포먼스는 크게 달라질 수 있다.
  • TCP 처럼 신뢰성 있는 전송을 하고싶으면 시퀀스 번호 등을 정의하여, 서버와 클라이언트 간에 패킷 유실에 대한 대처방법도 상호 정의한다면 UDP 기반의 신뢰성 있는 프로토콜을 만들 수 있다.
  • 이러한 개념에서 나온 것이 QUIC
• QUIC(Quick UDP Internet Connections) 프로토콜은 Google을 통해 개발이 진행되었고, 현재 모든 Google 관련 제품의 기본 프로토콜로 사용
  • UDP 보다 안전하고 TCP 보다 빠르다는 장점을 갖고 있다.
  • TCP는 클라이언트와 서버 연결 과정에서 핸드셰이크를 사용하여 커넥션을 만든다음 통신

• 반면에 QUIC은 사전에 핸드셰이크를 완료할 필요 없이 연결 시작 시에 클라이언트가 바로 서버에 데이터를 보낼 수 있도록 함

 

TCP와 UDP 비교

종류	UDP	TCP
IP 헤더의 프로토콜 번호	17	6
연결 방식	비 연결지향형 프로토콜	연결지향형 프로토콜
패킷	데이터그램 TCP 패킷	세그먼트 UDP 패킷
패킷 교환 방식	데이터그램 패킷교환	가상회선 패킷교환
신뢰성	낮음	높음
즉시성(실시간성)	빠름	느림
순서 보장	X	O
통신 방식	1:1, 1:N, N:N	1:1

 

 

 

 

 

 

 

 

reference

https://github.com/jmxx219/CS-Study/blob/main/network/TCP%EC%99%80%20UDP.md

CS-Study/network/TCP와 UDP.md at main · jmxx219/CS-Study

https://www.saturnsoft.net/network/2019/03/21/quic-http3-1/

QUIC과 HTTP/3 - 1. UDP기반 전송 프로토콜의 대두

https://gyoogle.dev/blog/computer-science/network/%ED%9D%90%EB%A6%84%EC%A0%9C%EC%96%B4%20&%20%ED%98%BC%EC%9E%A1%EC%A0%9C%EC%96%B4.html

TCP/IP (흐름제어/혼잡제어) | 👨🏻‍💻 Tech Interview

https://github.com/WooVictory/Ready-For-Tech-Interview/blob/master/Network/TCP.md

Ready-For-Tech-Interview/Network/TCP.md at master · WooVictory/Ready-For-Tech-Interview

https://github.com/JaeYeopHan/Interview_Question_for_Beginner/tree/main/Network#tcp-3-way-handshake

Interview_Question_for_Beginner/Network at main · JaeYeopHan/Interview_Question_for_Beginner