Computer Science/네트워크 (Network)

네트워크 모델 | (3) TCP, UDP 프로토콜 소개

hyuga_ 2023. 11. 18. 17:04

 

 

TCP와 UDP는 IP 위에서 동작하며 인터넷 프로토콜 스위트 중 핵심 프로토콜이다. 

TCP/IP 모델에서는 L4 Transport 계층에 해당하는 프로토콜이다. 

 

이들은 IP의 한계를 보완하거나, 더욱 업그레이드하기 위한 목적으로 설계되었으며,  

IP를 포함하고 있는 Network 계층 위 Transport 계층의 주요 요소로 올라가게 되었다.

 

IP의 한계

IP만 믿고 모든 네트워크 통신을 하기에는 한계가 있다. 

바로 데이터 전송을 신뢰할 수 없다는 것이다

 

IP의 한계점은 다음과 같다: 

  1. Data loss
    • 비연결성: 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷이 전송되고, 클라이언트는 이를 모르는 경우
    • 비신뢰성: 네트워크 경로 중간에 패킷이 사라지는 경우 (이상한 경로로 빠져버렸다든지..)
  2. Out of order
    • 패킷이 순서대로 도착하지 않은 경우
  3. 프로세스 구분 X
    • 같은 IP를 사용하는 프로세스가 둘 이상인 경우 구분할 방법이 없다.

 

TCP (Transmission Control Protocol)

위에서 말한 IP의 한계들이 명확했고, 그래서 다음과 같은 아이디어가 나온다.

IP의 한계를 보완할 수 있도록 기능을 덧붙이자! (포장을 하나 더 하자!)

 

그래서 TCP 라는 프로토콜이 추가적으로 도입되었다. 

즉, Network Layer(L3) 위에 Transport Layer(L4)가 올라가게 되었다. 

 

  1. Data loss 해결책
    • 비연결성: 3-way handshake
    • 비신뢰성: 데이터 전달 보증 (패킷 누락 등을 알 수 있도록 한다)
  2. Out of order 해결책
    • TCP 순서보장
  3. 프로세스 구분 X 해결책
    •  헤더에 포트(Port) 정보 추가

 

TCP가 동작하는 과정은 다음과 같다: 1) connection을 열고, 2) 데이터를 주고 받고, 3) connection을 닫는다.

다만, 그 과정에서 연결성과 패킷의 순서를 보장한다는 점!

  1. connection을 연다: 3-way handshake (연결 보장)
  2. 데이터를 주고받는다: 순서 보장
  3. connection을 닫는다: 4-way handshake

 

참고로, connection을 열고 -> 데이터 교환 -> connection 닫고 라는 과정으로 동작하는 방식을 connection-oriented 라고 부른다.

 

3-way handshake

TCP/IP 프로토콜로 연결을 하면 다음 3단계를 거친다: SYN → SYN/ACK → ACK (신 → 신/액 → 액)

  1. SYN: SYN (Synchronize의 약어) 이라는 메세지를 보낸다
  2. SYN/ACK: 서버가 확인했다는 의미에서 ACK 이라는 메세지를 클라이언트에 보낸다 (ACK: acknowledgement code, 승인코드) 동시에 나도 연결해달라는 의미에서 SYN을 클라이언트에 보낸다
  3. ACK: 클라이언트도 ‘오케이 알겠어’라는 의미로 ACK을 서버에 보낸다. 이 단계에서는 ACK와 함께 데이터를 전송할 수 있다.

 

여기까지 되면 ‘TCP가 연결됐다’, ‘소켓이 연결됐다’고 표현하는데, 진짜로 서버와 클라이언트를 위한 전용 랜선이 연결된 건 아니고 개념적인 연결, 즉 가상 연결이다.

 

먼 옛날에는 전화 포트를 꼽아서 진짜 물리적으로 연결을 했다. 근데 지금은 서로 메세지를 주고받음으로써 그냥 ‘클라이언트와 서버가 잘 연결됐구나~’라는 걸 논리적으로 파악한다. 왜냐하면 그 중간에 수많은 노드들이 있다. 이걸 다 알기엔 어렵고 그럴 필요도 없다.

 

 

데이터 전달 보증

TCP가 붙게 되면, 데이터 전송 시 서버에서 ‘나 데이터 잘 받았어~’ 하고 답신을 보내준다.

내가 전송을 했는데 서버에서 응답이 없으면 클라이언트는 무언가 문제가 있음을 파악할 수 있다.

 

 

순서 보증

클라이언트가 패킷을 1 → 2 → 3 순서로 보냈는데, 서버에는 1 → 3 → 2 순서로 도착했다면?

그렇게 되면, 서버는 순서가 잘못된 패킷들을 다 버리고 ‘패킷 2부터 다시 보내’ 라고 답장한다.

 

물론 서버 내부적으로 최적화를 통해 순서를 바로 잡을 수도 있지만, 그건 더 발전된 기술이고 기본적으로는 이런 구조로 설계되어있다.

이게 가능한 이유는 위에서 살펴봤듯, TCP에 전송 제어 정보, 순서 정보, 검증 정보가 추가되어 있기 때문이다.

 

 

 

UDP (User Datagram Protocol)

UDP는 IP에서 최소한의 기능(포트 등) 외에는 거의 추가된게 없다. 

 

UDP의 특징

  • connectionless 프로토콜: 연결을 맺지않고 바로 데이터를 주고받음
  • unreliable 프로토콜: IP를 거의 그대로 사용 (간단한 에러 체크 정도?)
  • UDP 표준 문서를 보면, socket이라는 단어가 등장하지 않음. (TCP 문서에서는 socket이라는 개념을 자세히 기술하고 있음. 때문에 처음에는 TCP에서만 주소 체계를 위해 도입한 개념이다. 근데 쓰다보니 UDP에서도 자연스럽게 이 개념을 사용하기 시작한듯)

 

Q. 그럼 UDP의 장점이 뭐야?

 

→ TCP는 다 좋은데 데이터 양도 크고, 전송 속도도 빠르게 하기 어렵다. 이미 구축이 다 되어 있기 때문에 최적화에 한계가 있다.

→ UDP는 대역폭을 적게 사용하며, 빠른 전송이 가능하다. 또한 하얀 도화지와 같아서 내가 더 최적화할 수 있는 여지가 있다.

(신뢰성과 속도는 진정 Trade off 관계인가..)

 

[예전의 트렌드]

위와 같은 특징 때문에 TCP는 신뢰할 수 있는 데이터를 보낼 때 쓰고, UDP는 영상처럼 좀 깨져도 되는걸 보낼 때 쓴다고 배웠다. 

실시간 스트리밍, 온라인 게임, 비디오 회의 등 실시간성이 중요하고 일부 패킷 손실이 허용되는 애플리케이션에서 주로 사용된다.

즉, UDP라고 나쁜건 아니고, 여기에도 상황 논리가 적용된다는 것이다

 

[최근의 트렌드]

기능좋은 TCP의 점유율이 90% 대로 올라오면서 영상 등을 보낼 때도 TCP 프로토콜을 썼다고 한다.

 

[아주아주 최근의 트렌드]

그러나 시대가 또 바뀐게, 최근에는 오히려 UDP가 뜨고 있다고 한다. 

HTTP/3 스펙이 나왔는데, TCP의 3-way handshake와 같은 단계까지도 줄여보자며 UDP를 사용하면서 다시 부상하고 있는 중이다.