[네트워크] TCP vs UDP

TCP - 전송 제어 프로토콜

`IP(Internet Protocol)`가 인터넷 프로토콜로서 복잡한 인터넷 망 속에서 클라이언트와 서버 간에 통신할 수 있게 IP 주소와 패킷과 같은 규칙을 통해 통신을 하게 하는 것이라면, 
`TCP(Transmission Control Protocol)`는 IP 규칙으로만 통신하기에 부족하거나 불안정하던 여러 단점들(패킷 순서가 이상하거나 패킷이 유실)을 커버해, 패킷 전송을 제어하여 신뢰성을 보증하는 프로토콜로 보면 된다.
 
IP와 TCP 둘다 프로토콜이지만 이 둘을 동일시로 보면 안된다. 이 둘은 별개의 규칙이다.
IP 규칙에 써있는대로 목적지까지 다다랐으면, TCP 규칙에 써있는대로 올바르게 도착했는지 정확히 누구에게 전달되야하는지 하나하나 따진다고 생각하면 된다. 그래서 은행 업무나 메일과 같은 반드시 수신자가 정보를 받아야하는 신뢰성 있는 통신이 필요할때 사용된다.

 

TCP 헤더 구성

TCP의 경우 워낙 오래 전에 설계되기도 했고, 이런 저런 기능이 워낙 많이 포함된 프로토콜이다보니 이미 헤더가 거의 풀방이다.

(1) Source Port : 데이터를 생성한 애플리케이션에서 사용하는 포트번호
(2) Destination Port : 목적지 애플리케이션이 사용하는 포트 번호
(3) Sequence Number 필드 : 세그먼트 순서를 맞추기 위한 필드
(4) Acknowledgement Number 필드 : 다음 세그먼트 수신 준비 및 모든 데이터 수신 확인 역할
(5) Data Offset 필드 : TCP 헤더의 크기 ( 5~15 : 5*32<160bit> ~ 15*32<480bit> )
(6) Reserved 필드 : 차후의 사용을 위한 예약된 필드
(7) Control Flags (SYN, ACK, FIN ...등) : 긴급, 혼잡, 확인, 수신 거부 등의 기능
(8) Window size 필드 : 수신자가 한번에 받을 수 있는 데이터의 양. 송신자는 Window size만큼 ACK를 기다리지 않고 데이터를 전송. ACK가 계속 왔다갔다 하지 않아도 된다
(9) Checksum : 세그먼트 내용의 유효성과 손상 여부 검사

 

3 way handshake & 4 way handshake

 

 

1) Flag 종류

FLAG	설명
SYN	접속요청을 할 때 보내는 패킷을 말한다.TCP접속시에 가장먼저 보내는 패킷이다.
ACK	상대방으로부터 패킷을 받은 뒤에, 잘 받았다고 알려주는 패킷을 말한다. 다른 플래그와 같이 출력되는 경우도 있다.
PSH	데이터를 즉시 목적지로 보내라는 의미이다.
FIN	접속종료를 위한 플래그이 패킷을 보내는 곳이 현재 접속하고 있는 곳과 접속을 끊고자 할 때 사용한다.

 

 

2) 3-way handshake 과정

 

 

(1) 클라이언트는 접속을 요청하는 SYN 패킷을 보낸다.이때 클라이언트는 응답을 기다리기위해 SYN_SENT 상태로 변한다.

 

(2) LISTEN 상태였던 서버는 SYN 요청을 받으면, 클라이언트에게 요청을 수락하는 ACK 패킷과 SYN 패킷을 보낸다. (서버도 클라이언트에 접속해야 양방향 통신이 되기 때문에) 그리고 SYN_RCVD(SYN_RECEIVED)상태로 변하여 클라이언트가 ACK 패킷을 보낼 때 까지 기다리게 된다.

 

(3) 클라이언트는 다시 서버에 ACK 패킷을 보내고, 이 후 ESTABLISHED 상태가 되어 데이터 통신이 가능하게 된다.

 

 

3) 데이터 통신 과정

 

(1) Established 된 상태에서 서버에게 데이터를 보낸다.

 

(2) 서버는 잘 전송받았다고 ACK 플래그를 넣어 응답한다.

 

(3) 만약 클라이언트가 서버로부터 ACK를 못받았으면 제대로 송신하지 못한걸로 판단하고 데이터를 재전송을 한다.

 

4) 4-way handshake 과정

1) 서버와 클라이언트가 TCP 연결이 되어있는 상태에서 클라이언트가 접속을 끊기 위해 CLOSE() 함수를 호출한다.

    그러면 FIN 플래그를 보내게 되고 클라이언트는 FIN_WAIT1 상태로 변한다.

 

2) 서버는 클라이언트가 CLOSE() 한다는 것을 알게되고 CLOSE_WAIT 상태로 바꾼 후 ACK 플래그를 전송한다.

    만일 서버에서 클라이언트로 보낼 남은 데이터가 있을 경우 이때 나머지를 모두 전송시킨다.

 

3) ACK를 받은 클라이언트는 FIN_WAIT2로 변환되고, 이때 서버는 CLOSE() 함수를 호출하고 FIN 플래그를 클라이언트에게 보낸다.

 

4) 서버도 연결을 닫았다는 신호를 클라이언트가 수신하면 ACK 플래그를 보낸 후 TIME_WAIT 상태로 전환된다.

    이 후 모든것이 끝나면 CLOSED 상태로 변환된다. 

 

TCP의 전송 제어 기법

TCP(Transmission Control Protocol)는 단어 그대로 원활한 통신을 위해 전송 흐름을 제어하는 기능을 프로토콜 자체에 포함하고 있다. 만약 TCP가 없었더라면 개발자가 일일히 데이터를 어떤 단위로 보낼 것인지 정의해야하고, 패킷이 유실되면 어떤 예외처리를 해야하는 지까지 신경써야하기 때문에, 덕분에 우리는 온전히 상위의 동작에만 집중할 수 있는 것이다.

 

보통 TCP의 전송 제어 방법은 다음 3가지로 정리 된다.

이 TCP 제어 알고리즘은 굉장히 양도 많고 난도도 높기 때문에 따로 시간이 있을때 파보길 권하며, 개념을 잡는 지금은 TCP는 이러한 예외적인 상황에 대해서 잘 알아서 대처한다 정도로 알고 넘어가도록 하자.

 

1) 흐름 제어(Flow Control)

- 수신자가 처리할 수 있는 데이터 속도가 다르기 때문에, 송신 측은 수신 측의 데이터 처리 속도를 파악하고 얼마나 빠르게 어느 정도의 데이터를 전송할 지 제어
- 슬라이딩 윈도우(Sliding Window) 방식을 사용
   - Window 라는 데이터를 담는 공간을 동적으로 조절하여 데이터량을 조절

 

 

2) 오류 제어(Error Control)

- 통신 도중에 데이터가 유실되거나 잘못된 데이터가 수신되었을 경우 대처
- Go Bank N 기법과 Selective Repeat(선택적인 재전송) 기법을 사용
   - Go Bank N 기법 : 어느 데이터로부터 오류가 발생했는지 파악하여, 그 부분만 다시 순서대로 보내 제어한다.
   - Selective Repeat 기법 : 에러난 데이터만 재전송하고 그전에 받았던 순서가 잘못된 데이터 버퍼를 재정렬하여 제어한다.

 

3) 혼잡 제어(Congestion Control)

- 네트워크가 불안정하여 데이터가 원활히 통신이 안되면 제어를 통해 재전송을 하게 되는데, 재전송 작업이 반복되면 네트워크가 붕괴될 수도 있다. 따라서 네트워크 혼잡 상태가 감지되면 송식 측의 전송 데이터 크기를 조절하여 전송량을 조절한다.

- TCP에는 Tahoe, Reno, New Reno, Cubic, Elastic-TCP ..등 다양한 혼잡 제어 기법이 존재한다.

 

 

UDP - 사용자 데이터그램 프로토콜

보통 UDP 와 TCP를 비교하는데 있어 아래와 같은 표를 많이 인용해왔을 것이다.

표를 보면 대략 TCP는 신뢰성이 높고 느리다 와 UDP는 신뢰성이 낮고 빠르다 정도로 정리가 된다.

	TCP	UDP
연결 방식	연결형 서비스	비연결형 서비스
패킷 교환	가상 회선 방식	데이터그램 방식
전송 순서 보장	보장함	보장하지 않음
신뢰성	높음	낮음
전송 속도	느림	빠름

아무래도 클라이언트와 서버가 서로 신뢰성있는 통신을 할 수 있도록 TCP는 핸드쉐이크 과정을 거치게 되는데, 위에서 살펴본것 처럼 데이터 하나를 전송하기 위한 밑작업들이 많았었다.
그렇지만 인터넷 기술이 발전하면서 전송해야하는 데이터도 단순 텍스트를 넘어서 동영상이나 음악과 같은 멀티미디어도 전송하면서 데이터의 크기가 점점 커져가며 동시에 빠른 통신이 필요해 졌다. 그래서 HTTP 2.0Visit Website 에서는 한번 연결된 TCP 회선을 길게 유지하고 데이터도 스트림이라는 특수한 형태로 보내는 식으로 극복을 했지만, TCP 자체가 가지는 근본적인 특징때문에 결과적으로 속도 한계가 있었다. (즉, 너무 헤비해서 더이상 속도를 뽑아 낼수가 없음)
 
반면, UDP(User Datagram Protocol)는 단어에서도 알 수 있듯이 데이터그램 방식을 사용하는 프로토콜이기 때문에 애초에 각각의 패킷 간의 순서가 존재하지 않는 독립적인 패킷을 사용한다.
데이터그램 방식은 패킷의 목적지만 정해져있다면 중간 경로는 어딜 타든 신경쓰지 않기 때문에 핸드쉐이크 과정 같은 연결 설정이 필요 없게 된다. 즉, UDP는 신뢰성을 확보하기 위해 거치던 TCP의 과정을 거치지 않기 때문에 속도가 더 빠를 수 밖에 없다는 것이다. 그래서 UDP는 실시간 영상 스트리밍과 같은 고용량 데이터를 다루는 곳에 이용된다.

 

UDP 헤더 

UDP는 데이터 전송 자체에만 초점을 맞추고 설계되었기 때문에 헤더에 들어있는게 없다. (그래서 하얀 도화지 같다는 비유가 생긴 것이다)
UDP의 헤더에는 출발지와 도착지, 패킷의 길이, 체크섬 밖에 없다.

(1) Source Port : 데이터를 생성한 애플리케이션에서 사용하는 포트번호
(2) Destination Port : 목적지 애플리케이션이 사용하는 포트 번호
(3) checksum : 중복 검사의 한 형태로, 오류 정정을 통해 공간(전자 통신)이나 시간(기억 장치) 속에서 송신된 자료의 무결성을 보호하는 단순한 방법. (TCP의 체크섬과는 다르게 UDP의 체크섬은 사용해도 되고 안해도 되는 옵션)

 

UDP 통신 과정 시각적으로 보기

UDP가 왜 TCP 보다 빠른지는 리눅스 명령어를 통해서도 한눈에 이해할 수 있다.
기존 netcat 명령어에 -u 옵션을 주게 되면 UDP로 데이터를 송신 하게 되는데, 수신측 로그를 보면 진짜 딸랑 한줄이 끝이다. 잘받았다는 응답 패킷 없이 무지성으로 보내기만 하는 것이다.

# "Hello World" 라는 데이터를 -u 옵션(UDP로) naver.com 에 80번 포트로 전송
$ echo "Hello World" | nc -u naver.com 80

 

 

 

 

3. TCP를 버리고 UDP를 선택한 HTTP 3.0

학부에서는 아무래도 TCP는 인터넷 통신에서 필수적으로 쓰이는 녀석이라 자세히 배우고, UDP는 빠르다 정도로 간단히 배우고 휙 넘어가버리는 모양인데, 이제는 그럴수가 없다. 위의 제목에서와 같이 HTTP/3 에서는 TCP를 버리고 UDP를 채택했기 때문이다.

🌐 HTTP 3.0 소개 & 통신 기술 알아보기

 

2022년 11월 15일 한국 최초로 네이버도 HTTP/3을 도입하였다고 한다.

 

 

3-1. TCP는 구조상 한계로 개선해도 여전히 느리다

사실 TCP는 인류가 지금과 같이 엄청난 속도로 발전할 것이라곤 상상 할 수 없는 시기에 만들어졌다. TCP가 만들어지던 시절에 클라이언트와 서버가 동시 다발적으로 여러 개 파일의 데이터 패킷을 교환할 것이라고 상상하지 못했기 때문이다.
그래서 모바일 기기와 같이 네트워크 환경을 바꾸어가면서 서버와 클라이언트가 소통할 수 있을 것이라고 생각하지 못했다. 그 때문에 와이파이를 바꾸면 다시 새로운 커넥션을 맺어야 되서 끊김 현상이 일어나는 것이다.
 
또한 TCP를 사용한 통신에선 패킷은 신뢰성을 위해 무조건 순서대로 처리되어야 한다. 또한 패킷이 처리되는 순서 또한 정해져있으므로 이전에 받은 패킷을 파싱하기 전까지는 다음 패킷을 처리할 수도 없다. 만일 중간에 패킷이 손실되어 수신 측이 패킷을 제대로 받지 못했으면 다시 보내야 한다.
이렇게 패킷이 중간에 유실되거나 수신 측의 패킷 파싱 속도가 느리다면 통신에 병목이 발생하게 되는데, 이러한 현상을 HOLB(Head of line Blocking)라고 부른다.
이 HOLB는 TCP 설계도상 어쩔수 없이 발생하는 문제이기 때문에 HTTP/1.1 뿐만 아니라 HTTP/2도 가지고 있는 아주 고질적인 문제였다.
 
따라서 이런 고질적인 문제들을 해결하기 위해 HTTP/3는 TCP를 버리고 UDP를 선택하였다. 

 

3-2. UDP는 신뢰성이 없는게 아니라 탑재를 안했을 뿐이다

앞서 신뢰성 대신 속도를 택한 UDP는 스트리밍과 같은 서비스에서 사용된다고 소개한 바가 있다. 방송이나 동영상은 중간에 끊길지언정 바로바로 데이터를 빠르게 송출하는것이 더 중요하기 때문이다.
하지만 기본적으로 인터넷은 클라이언트와 서버 간의 정확한 패킷 통신이 필요하기 때문에 신뢰성이 보장받아야 한다. 왜 HTTP가 TCP를 기반으로 했는지 그 이유이다.
많이들 착각하는 것이 빠른건 알겠는데 UDP는 신뢰성이 없기 때문에 사용성이 적다고 이해하는 것이다. 하지만 이는 명확하지 않다.
UDP는 신뢰성이 없는게 아니라 탑재를 안했을 뿐이다. UDP의 진짜 장점은 커스터마이징이 가능하다는 점이다.
즉, UDP 자체는 헤더에 들은게 없어 신뢰성이 낮고 제어 기능도 없지만, 이후 개발자가 애플리케이션에서 구현을 어떻게 하냐에 따라서 TCP와 비슷한 수준의 기능을 가질 수도 있다는 말이다.

 

3-3. UDP를 개조한 QUIC 프로토콜

QUIC(Quick UDP Internet Connections)는 UDP를 기반으로 TCP + TLS + HTTP 의 기능을 모두 구현하는 프로토콜이다. 따라서 HTTP 3.0이 UDP를 이용하였다라는 말은 정확히 말하면 UDP 기반으로 만들어진 QUIC 프로토콜을 채택하였다라는 뜻이다.

 

QUIC은 TCP를 사용하지 않기 때문에 통신을 시작할 때 번거로운 3 Way Handshake 과정을 거치지 않아도 된다. 
클라이언트가 보낸 요청을 서버가 처리한 후 다시 클라이언트로 응답해주는 사이클을 RTT(Round Trip Time)이라고 하는데, TCP는 연결을 생성하기 위해 기본적으로 1 RTT가 필요하고, 여기에 TLS를 사용한 암호화까지 하려고 한다면 TLS의 자체 핸드쉐이크까지 더해져 총 3 RTT가 필요하다.

 

 

반면 QUIC은 첫 연결 설정에 1 RTT만 소요된다.

 

TCP 핸드쉐이크 과정을 거치지 않으며 TLS 자체를 내포하고 있기 때문에, 연결 설정에 필요한 정보와 함께 데이터도 보내버리기 때문이다. 그리고 한번 연결에 성공했다면 서버는 그 설정을 캐싱해놓고 있다가, 다음 연결 때는 캐싱해놓은 설정을 사용하여 바로 연결을 성립시키기 때문에 0 RTT만으로 바로 통신을 시작할 수도 있다. 

 

이밖에도 패킷 손실 감지에 걸리는 시간 단축되었으며, 클라이언트의 IP가 바뀌어도 연결이 유지되어 모바일에서 와이파이를 바꾸어도 끊김이 없어지게 되었다.

 

---

출처

https://inpa.tistory.com/entry/NW-%F0%9F%8C%90-%EC%95%84%EC%A7%81%EB%8F%84-%EB%AA%A8%ED%98%B8%ED%95%9C-TCP-UDP-%EA%B0%9C%EB%85%90-%E2%9D%93-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EC%9E%90

🌐 아직도 모호한 TCP / UDP 개념 ❓ 쉽게 이해하자