TCP(Transmission Control Protocol)
전송을 제어하는 프로토콜(규약)
- 인터넷상에서 데이터를 메시지의 형태로 보내기 위해 IP와 함께 사용하는 프로토콜
일반적으로 TCP와 IP를 함께 사용하는데, IP가 데이터의 배달을 처리한다면 TCP는 패킷을 추적 및 관리하게 된다.
TCP는 연결형 서비스를 지원하는 프로토콜로 인터넷 환경에서 기본으로 사용한다.
TCP 특징
- 연결 지향 방식으로 패킷 교환 방식을 사용한다(가상 회선 방식이 아님).
- 3-way handshaking 과정을 통해 연결을 설정하고 4-way handshaking을 통해 해제한다.
- 흐름 제어 및 혼잡 제어
- 높은 신뢰성을 보장한다.
- UDP보다 속도가 느리다.
- 전이중(Full-Duplex), 점대점(Point to Point) 방식
TCP가 연결 지향 방식이라는 것은 패킷을 전송하기 위한 논리적 경로를 배정한다는 것이며, 3-way handshaking 과정은 목적지와 수신지를 확실히 해서 정확한 전송을 보장하기 위해 세션을 수립하는 과정을 의미한다.
TCP가 이러한 특징을 지니는 이유는 연결형 서비스로 신뢰성을 보장하기 위함으로, 3-way handshaking의 과정도 사용하고 데이터 흐름제어나 혼잡 제어와 같은 기능도 한다. 다만 이러한 기능으로 인해 UDP보다 속도가 느리게 된다(CPU를 사용하기 때문에 속도에 영향을 준다).
TCP는 연속성보다 신뢰성 있는 전송이 중요할 때 사용하는 프로토콜로 파일 전송과 같은 경우에 사용된다.
TCP 서버의 특징
- 서버 소켓은 연결만 담당한다.
- 연결과정에서 반환된 클라이언트 소켓은 데이터의 송수신에 사용된다.
- 서버와 클라이언트는 1대 1로 연결된다.
- 스트림 전송으로 전송 데이터의 크기가 무제한이다.
- 패킷에 대한 응답을 해야하기 때문에(시간 지연, CPU 소모) 성능이 낮다.
- Streaming 서비스에 불리하다(손실된 경우 재전송 요청을 하기 때문).
패킷(Packet)
인터넷 내에서 데이터를 보내기 위한 경로 배정(라우팅)을 효율적으로 하기 위해서 데이터를 여러 개의 조각들로 나누어 전송을 하는데 이때, 이 조각을 패킷이라고 한다.
TCP가 패킷을 추적 및 관리하는 방법
예를 들어 A, B, C라는 패킷들이 발신지에서 출발해 수신지로 간다고 할 경우, A, B, C가 순차적으로 가는 상황에서 B가 분실되었을 경우 수신지에서는 A, B, C가 모두 필요한지 모르고 A, C만 보고 다 왔다고 착각할 수 있기 때문에 A, B, C라는 패킷에 1, 2, 3이라는 번호를 부여하여 패킷의 분실 확인과 같은 처리를 하여 목적지에서 재조립을 하는 방식으로 TCP는 패킷을 추적하며, 나누어 보내진 데이터를 받고 조립할 수 있다.
UDP(User Datagram Protocol)
사용자 데이터그램 프로토콜(규약)
- 데이터를 데이터그램 단위로 처리하는 프로토콜
데이터그램 : 독립적인 관계를 지니는 패킷
TCP와 달리 UDP는 비연결형 프로토콜로 연결을 위해 할당되는 논리적인 경로가 없는데, 그렇기 때문에 각각의 패킷은 다른 경로로 전송되고 각각의 패킷은 독립적인 관계를 지니게 되는데, 이렇게 데이터를 서로 다른 경로로 독립적으로 처리하게 되는 프로토콜을 UDP라고 한다.
UDP 특징
- 비연결형 서비스로 데이터그램 방식을 제공한다.
- 정보를 주고받을 때 정보를 보내거나 받는다는 신호절차를 거치지 않는다.
- UDP 헤더의 CheckSum 필드를 통해 최소한의 오류만 검출한다.
- 신뢰성이 낮다.
- TCP보다 속도가 빠르다.
UDP는 비연결형 서비스이기 때문에, 연결을 설정하고 해제하는 과정이 존재하지 않는다. 서로 다른 경로로 독립적으로 처리함에도 패킷에 순서를 부여하여 재조립을 하거나 흐름 제어 또는 혼잡 제어와 같은 기능을 처리하지 않기에 TCP보다 속도가 빠르며 네트워크 부하가 적다는 장점이 있지만 신뢰성 있는 데이터의 전송을 보장하지 못한다.
그렇기 때문에 신뢰성보다는 연속성이 중요한 서비스, 실시간 서비스(Streaming)에 자주 사용된다.
UDP 서버의 특징
- UDP에는 연결 자체가 없어서(Connect 함수 불필요) 서버 소켓과 클라이언트 소켓의 구분이 없다.
- 소켓을 활용해 IP와 Port를 기반으로 데이터를 전송한다.
- 서버와 클라이언트는 1대 1, 1대 N, N대 M 등으로 연결될 수 있다.
- 데이터그램(메시지) 단위로 전송되며 그 크기는 65535 바이트로, 크기가 초과하면 잘라서 보낸다.
- 흐름제어(flow control)가 없어서 패킷이 제대로 전송되었는지, 오류가 없는지 확인할 수 없다.
- 파일 전송과 같은 신뢰성이 필요한 서비스보다 성능이 중요시 되는 경우에 사용된다.
흐름제어(Flow Control)와 혼합제어(Congestion Control)
흐름제어는 데이터를 송신하는 곳과 수신하는 곳의 데이터 처리 속도를 조절하여 수신자의 버퍼 오버플로우를 방지하는 것으로 송신하는 곳에서 감당이 안 되게 데이터를 빠르게 많이 보내면 수신자에서 문제가 발생하기 때문이다.
혼잡제어는 네트워크 내의 패킷 수가 넘치게 증가하지 않도록 방지하는 것으로 만약 정보의 소통량이 과다하다면 패킷을 조금만 전송하여 혼잡 붕괴 현상이 일어나는 것을 막는다.
TCP와 UDP의 비교
| 프로토콜 종류 | TCP | UDP |
| 연결 방식 | 연결형 서비스(패킷 교환 방식) | 비연결형 서비스(데이터그램 방식) |
| 전송 순서 | 전송 순서 보장 | 전송 순서가 바뀔 수 있음 |
| 수신 여부 확인 | 수신 여부를 확인함 | 수신 여부를 확인하지 않음 |
| 통신 방식 | 1 : 1 통신 | 1:1 OR 1:N or N:N 통신 |
| 신뢰성 | 높다 | 낮다 |
| 속도 | 느리다 | 빠르다 |
교환 방식
TCP Flow
UDP Flow
TCP 대신 UDP를 선택한 HTTP 3.0
TCP는 구조상 한계로 개선해도 여전히 느리다
TCP가 만들어지던 시절에는 클라이언트와 서버가 동시 다발적으로 여러 파일의 데이터 패킷을 교환을 상정할 수 없었고, 그래서 모바일 기기와 같이 네트워크 환경을 바꾸어 가면서 서버와 클라이언트가 소통할 수 있을 것이라고 생각하지 못했기 때문에 와이파이를 바꾸면 다시 새로운 커넥션을 맺어야 되서 끊김 현상이 일어난다.
TCP를 사용한 통신에서는 패킷은 신뢰성을 위해 무조건 순서대로 처리되어야 하고, 패킷이 처리되는 순서도 정해져 있어 이전에 받은 패킷을 파싱하기 전까지는 다음 패킷을 처리할 수 없다. 만일 중간에 패킷이 손실되어 수신 측이 패킷을 제대로 받지 못했으면 다시 보내야 한다.
패킷이 중간에 유실되거나 수신 측의 패킷 파싱 속도가 느리다면 통신에 병목이 발생하게 되는데, 이러한 현상을 HOLB(Head of line Blocking)라고 부른다.
HOLB는 TCP 설계 상 어쩔 수 없이 발생하는 문제이기 때문에 HTTP/1.1 뿐 아니라 HTTP/2도 가지고 있는 아주 고질적인 문제였고, 이런 문제들을 해결하기 위해 HTTP/3은 UDP를 선택했다.
UDP는 신뢰성이 없는 게 아니라 탑재를 안 했을 뿐이다.
기본적으로 인터넷은 클라이언트와 서버 간의 정확한 패킷 통신이 필요하기 때문에 신뢰성이 보장받아야 한다. HTTP가 TCP를 기반으로 한 이유이다.
UDP는 신뢰성이 없는 것이 아니라 탑재를 안 한 것으로 UDP의 진짜 장점은 커스터마이징이 가능하다는 점이 있다.
즉, UDP 자체는 헤더에 들어 있는 것이 없어 신뢰성이 낮고 제어 기능도 없지만, 이후 개발자가 애플리케이션에서 구현을 어떻게 하냐에 따라서 TCP와 비슷한 수준의 기능을 가질 수도 있다.
UDP를 개조한 QUIC 프로토콜
QUIC(Quick UDP Internet Connections)는 UDP를 기반으로 TCP + TLS + HTTP의 기능을 모두 구현하는 프로토콜로 HTTP 3.0은 UDP 기반으로 만들어진 QUIC 프로토콜을 채택했다는 뜻이다.
QUIC은 TCP를 사용하지 않기 때문에 통신을 시작할 때 번거로운 3-way handshake 과정을 거치지 않아도 된다.
클라이언트가 보낸 요청을 서버가 처리한 후 다시 클라이언트로 응답해주는 사이클을 RTT(Round Trip Time)이하고 하는데, TCP는 연결을 생성하기 위해 기본적으로 1RTT가 필요하고, 여기에 TLS를 사용한 암호화까지 하려면 TLS 자체 핸드쉐이크까지 더해져 총 3RTT가 필요하다.
반면 QUIC는 첫 연결 설정에 1RTT만 소요된다. TCP 핸드쉐이크 과정을 거치지 않으며 TLS 자체를 내포하고 있기 때문에, 연결 설정에 필요한 정보와 함께 데이터도 보내버리기 때문이다.
한 번 연결에 성공하면 서버는 그 설정을 캐싱해 놓고, 다음 연결 때는 캐싱한 설정을 사용해 바로 연결을 성립시키기 때문에 0RTT만으로도 바로 통신을 시작할 수도 있다.
이 밖에도 패킷 손실 감지에 걸리는 시간도 단축되고, 클라이언트의 IP가 바뀌어도 연결이 유지되어 모바일에서 와이파이를 바꿔도 끊김이 없어지게 되었다.
