본문 바로가기

QUIC과 전송 계층의 진화

QUIC이 UDP 위에 다중 스트림·TLS·손실 복구·연결 이동을 통합해 TCP 기반 웹의 지연 문제를 줄이는 방식을 이해합니다.

TCP는 인터넷의 기반이며 오랫동안 안정적으로 동작해 왔습니다.

하지만 웹이 더 짧은 지연 시간, 더 많은 동시 요청, 모바일 네트워크 전환을 요구하면서 TCP 위에 기능을 계속 덧붙이는 방식의 한계가 드러났습니다.

QUIC은 이 문제를 해결하기 위해 UDP 위에 새 전송 기능을 구현한 프로토콜입니다.

UDP를 쓰지만 단순히 “UDP 위의 TCP”는 아닙니다.

스트림 다중화, TLS 1.3 기반 보안, 손실 복구, 혼잡 제어, 연결 마이그레이션을 하나의 전송 계층으로 통합합니다.

HTTP 버전별 진화와 한계

QUIC을 이해하려면 HTTP의 진화와 전송 계층의 병목을 구분해야 합니다.

HTTP/1.1은 여러 요청을 효율적으로 병렬 처리하기 어렵고, HTTP/2는 하나의 TCP 연결 안에서 스트림을 다중화했습니다.

그러나 HTTP/2도 TCP 위에 있기 때문에 패킷 손실이 발생하면 TCP의 순서 보장 때문에 여러 HTTP/2 스트림이 함께 막힐 수 있습니다.

이 현상을 TCP 수준의 Head-of-Line Blocking이라고 부릅니다.

HTTP/2는 애플리케이션 레벨의 요청 큐 문제를 크게 줄였지만, TCP가 하나의 순서 있는 바이트 스트림이라는 사실은 바꾸지 못했습니다.

한 스트림의 손실이 막는 전달 범위

앞 순서에 필요한 데이터가 손실됩니다. 독립적인 B의 필요 데이터가 모두 도착했습니다. 각 단계의 값과 전환 이유를 비교합니다.

QUIC · 손실의 전달 범위

한 스트림의 빈 구간이 다른 스트림의 전달까지 막을까

A의 앞 데이터가 손실되고 A의 뒤 데이터와 B의 필요한 데이터가 도착한 가정입니다. QUIC은 스트림별 순서를 유지하므로 A가 기다리는 동안에도 B는 전달될 수 있습니다.

같은 손실에서 TCP와 QUIC의 전달 대기 범위 비교TCP에서는앞의빈바이트구간때문에뒤에도착한A와B바이트의순서전달이대기한다. QUIC에서는A의빈offset구간은A전달을막지만필요바이트가갖춰진독립B스트림은전달가능하다. 상자는버퍼상태이고화살표는조건에따른앱전달관계이며실제네트워크홉이아니다.TCP하나의 바이트 순서A 앞: 미도착A 뒤·B 바이트 도착A·B 전달 대기QUIC스트림마다 순서A 앞: 미도착A 뒤: 도착A 전달 대기B 필요 바이트 도착B 전달 가능
같은 손실에서 TCP와 QUIC의 전달 대기 범위 비교TCP에서는앞의빈바이트구간때문에뒤에도착한A와B바이트의순서전달이대기한다. QUIC에서는A의빈offset구간은A전달을막지만필요바이트가갖춰진독립B스트림은전달가능하다. 상자는버퍼상태이고화살표는조건에따른앱전달관계이며실제네트워크홉이아니다.TCP하나의 바이트 순서A 앞: 미도착A 뒤·B 바이트 도착A·B 전달 대기QUIC스트림마다 순서A 앞: 미도착A 뒤: 도착A 전달 대기B 필요 바이트 도착B 전달 가능

점선은 앞 구간이 비어서 기다리는 관계, 실선은 도착한 바이트와 전달 상태의 관계입니다. 패킷 이동 경로가 아닙니다. B는 필요한 바이트가 갖춰지고 A의 업무 결과에 의존하지 않는 조건입니다.

한 스트림의 손실이 막는 전달 범위
같은 손실 가정HTTP/2 over TCPHTTP/3 over QUIC
A 앞 데이터 손실TCP 바이트 순서의 빈 구간이 생김A 스트림의 offset 빈 구간이 생김
A 뒤 데이터 도착손실 복구까지 순서 전달 대기A의 손실 복구까지 순서 전달 대기
B 데이터 도착같은 TCP의 빈 구간 뒤 바이트라면 함께 대기B에 필요한 데이터가 갖춰지면 전달 가능
A 앞 데이터 손실
HTTP/2 over TCP: TCP 바이트 순서의 빈 구간이 생김
HTTP/3 over QUIC: A 스트림의 offset 빈 구간이 생김
A 뒤 데이터 도착
HTTP/2 over TCP: 손실 복구까지 순서 전달 대기
HTTP/3 over QUIC: A의 손실 복구까지 순서 전달 대기
B 데이터 도착
HTTP/2 over TCP: 같은 TCP의 빈 구간 뒤 바이트라면 함께 대기
HTTP/3 over QUIC: B에 필요한 데이터가 갖춰지면 전달 가능

가정한 전달 순서의 비교이며 실행 추적이 아닙니다. 한 QUIC 패킷에 여러 스트림 데이터가 들어 있으면 그 패킷 손실은 모두에 영향을 주며, 혼잡 제어와 애플리케이션 의존성도 남습니다.

이 예의 조건

  • 본문과 전체 도표의 예를 따라 A 앞 손실부터 B 필요 데이터까지 진행합니다.
관계도의 보충 설명
전체 도표의 표기·관계·조건
구분전체 도표의 내용
관계 설명TCP에서는 앞의 빈 바이트 구간 때문에 뒤에 도착한 A와 B 바이트의 순서 전달이 대기합니다. QUIC에서는 A의 빈 offset 구간이 A 전달을 막지만 필요 바이트가 갖춰진 독립 B 스트림은 전달 가능합니다. 상자는 버퍼 상태이고 화살표는 조건에 따른 앱 전달 관계이며 실제 네트워크 홉이 아닙니다.
표의 값A 앞 데이터 손실 — HTTP/2 over TCP: TCP 바이트 순서의 빈 구간이 생김; HTTP/3 over QUIC: A 스트림의 offset 빈 구간이 생김. A 뒤 데이터 도착 — HTTP/2 over TCP: 손실 복구까지 순서 전달 대기; HTTP/3 over QUIC: A의 손실 복구까지 순서 전달 대기. B 데이터 도착 — HTTP/2 over TCP: 같은 TCP의 빈 구간 뒤 바이트라면 함께 대기; HTTP/3 over QUIC: B에 필요한 데이터가 갖춰지면 전달 가능.
예의 값과 변화
관찰·상황값·보충 정보변화·이유
A 앞 손실

앞 순서에 필요한 데이터가 손실됩니다.

  • A·B 수신 상태 1: TCP 바이트 gap
  • A·B 수신 상태 2: QUICAoffsetgap
  • A의 순서 전달을 기다림; TCP 바이트 gap과 QUIC A의 offset gap 구별
A 뒤 도착

A의 뒷부분이 와도 앞의 빈 구간은 남습니다.

  • A·B 수신 상태 1: A 뒤 버퍼 있음
  • A·B 수신 상태 2: A 전달 대기
  • A의 뒷부분을 보관하고 손실 구간 복구를 기다림
B 필요 데이터

독립적인 B의 필요 데이터가 모두 도착했습니다.

  • A·B 수신 상태 1: TCP gap 뒤 B 대기
  • A·B 수신 상태 2: QUIC B 전달 가능
  • QUIC B는 전달 가능; TCP는 앞 gap을 기다리며 앱의 A 의존성은 별도

한 스트림의 손실이 막는 전달 범위

앞 순서에 필요한 데이터가 손실됩니다. 독립적인 B의 필요 데이터가 모두 도착했습니다. 각 단계의 값과 전환 이유를 비교합니다.

QUIC · 손실의 전달 범위

한 스트림의 빈 구간이 다른 스트림의 전달까지 막을까

A의 앞 데이터가 손실되고 A의 뒤 데이터와 B의 필요한 데이터가 도착한 가정입니다. QUIC은 스트림별 순서를 유지하므로 A가 기다리는 동안에도 B는 전달될 수 있습니다.

같은 손실에서 TCP와 QUIC의 전달 대기 범위 비교TCP에서는앞의빈바이트구간때문에뒤에도착한A와B바이트의순서전달이대기한다. QUIC에서는A의빈offset구간은A전달을막지만필요바이트가갖춰진독립B스트림은전달가능하다. 상자는버퍼상태이고화살표는조건에따른앱전달관계이며실제네트워크홉이아니다.TCP하나의 바이트 순서A 앞: 미도착A 뒤·B 바이트 도착A·B 전달 대기QUIC스트림마다 순서A 앞: 미도착A 뒤: 도착A 전달 대기B 필요 바이트 도착B 전달 가능
같은 손실에서 TCP와 QUIC의 전달 대기 범위 비교TCP에서는앞의빈바이트구간때문에뒤에도착한A와B바이트의순서전달이대기한다. QUIC에서는A의빈offset구간은A전달을막지만필요바이트가갖춰진독립B스트림은전달가능하다. 상자는버퍼상태이고화살표는조건에따른앱전달관계이며실제네트워크홉이아니다.TCP하나의 바이트 순서A 앞: 미도착A 뒤·B 바이트 도착A·B 전달 대기QUIC스트림마다 순서A 앞: 미도착A 뒤: 도착A 전달 대기B 필요 바이트 도착B 전달 가능

점선은 앞 구간이 비어서 기다리는 관계, 실선은 도착한 바이트와 전달 상태의 관계입니다. 패킷 이동 경로가 아닙니다. B는 필요한 바이트가 갖춰지고 A의 업무 결과에 의존하지 않는 조건입니다.

한 스트림의 손실이 막는 전달 범위
같은 손실 가정HTTP/2 over TCPHTTP/3 over QUIC
A 앞 데이터 손실TCP 바이트 순서의 빈 구간이 생김A 스트림의 offset 빈 구간이 생김
A 뒤 데이터 도착손실 복구까지 순서 전달 대기A의 손실 복구까지 순서 전달 대기
B 데이터 도착같은 TCP의 빈 구간 뒤 바이트라면 함께 대기B에 필요한 데이터가 갖춰지면 전달 가능
A 앞 데이터 손실
HTTP/2 over TCP: TCP 바이트 순서의 빈 구간이 생김
HTTP/3 over QUIC: A 스트림의 offset 빈 구간이 생김
A 뒤 데이터 도착
HTTP/2 over TCP: 손실 복구까지 순서 전달 대기
HTTP/3 over QUIC: A의 손실 복구까지 순서 전달 대기
B 데이터 도착
HTTP/2 over TCP: 같은 TCP의 빈 구간 뒤 바이트라면 함께 대기
HTTP/3 over QUIC: B에 필요한 데이터가 갖춰지면 전달 가능

가정한 전달 순서의 비교이며 실행 추적이 아닙니다. 한 QUIC 패킷에 여러 스트림 데이터가 들어 있으면 그 패킷 손실은 모두에 영향을 주며, 혼잡 제어와 애플리케이션 의존성도 남습니다.

이 예의 조건

  • 본문과 전체 도표의 예를 따라 A 앞 손실부터 B 필요 데이터까지 진행합니다.

관계도의 보충 설명

전체 도표의 표기·관계·조건
구분전체 도표의 내용
관계 설명TCP에서는 앞의 빈 바이트 구간 때문에 뒤에 도착한 A와 B 바이트의 순서 전달이 대기합니다. QUIC에서는 A의 빈 offset 구간이 A 전달을 막지만 필요 바이트가 갖춰진 독립 B 스트림은 전달 가능합니다. 상자는 버퍼 상태이고 화살표는 조건에 따른 앱 전달 관계이며 실제 네트워크 홉이 아닙니다.
표의 값A 앞 데이터 손실 — HTTP/2 over TCP: TCP 바이트 순서의 빈 구간이 생김; HTTP/3 over QUIC: A 스트림의 offset 빈 구간이 생김. A 뒤 데이터 도착 — HTTP/2 over TCP: 손실 복구까지 순서 전달 대기; HTTP/3 over QUIC: A의 손실 복구까지 순서 전달 대기. B 데이터 도착 — HTTP/2 over TCP: 같은 TCP의 빈 구간 뒤 바이트라면 함께 대기; HTTP/3 over QUIC: B에 필요한 데이터가 갖춰지면 전달 가능.
예의 값과 변화
관찰·상황값·보충 정보변화·이유
A 앞 손실

앞 순서에 필요한 데이터가 손실됩니다.

  • A·B 수신 상태 1: TCP 바이트 gap
  • A·B 수신 상태 2: QUICAoffsetgap
  • A의 순서 전달을 기다림; TCP 바이트 gap과 QUIC A의 offset gap 구별
A 뒤 도착

A의 뒷부분이 와도 앞의 빈 구간은 남습니다.

  • A·B 수신 상태 1: A 뒤 버퍼 있음
  • A·B 수신 상태 2: A 전달 대기
  • A의 뒷부분을 보관하고 손실 구간 복구를 기다림
B 필요 데이터

독립적인 B의 필요 데이터가 모두 도착했습니다.

  • A·B 수신 상태 1: TCP gap 뒤 B 대기
  • A·B 수신 상태 2: QUIC B 전달 가능
  • QUIC B는 전달 가능; TCP는 앞 gap을 기다리며 앱의 A 의존성은 별도

어디의 순서가 비었는지 먼저 찾기: 그림의 QUIC 스트림 A에서 앞부분 offset이 비고 뒷부분만 도착했으면 A의 순서 있는 전달은 기다립니다. 독립적인 B 스트림은 B에 필요한 앞부분부터 바이트가 갖춰졌을 때 전달될 수 있습니다. UDP 데이터그램 경계가 QUIC 스트림의 메시지 경계로 그대로 바뀐 것도 아닙니다. RFC 9000 §2.2는 스트림 ID·offset으로 순서를 맞추며 STREAM 프레임 경계를 앱 전달에서 보존하지 않는다고 설명합니다.

독립 판단: 손실된 QUIC 패킷 하나에 A의 앞부분과 B의 앞부분이 함께 들어 있었습니다. 이후 A·B의 뒷부분만 도착했다면 “스트림이 다르므로 B는 곧바로 모두 전달된다”고 설명해도 될까요?

한 패킷 손실과 스트림별 빈 구간 대조

이 조건에서는 B의 앞부분도 비어 있어 B의 순서 있는 전달 역시 그 구간을 기다립니다. 스트림별 전달이라는 설계가 같은 패킷에 실린 B의 데이터를 복구해 주는 것은 아닙니다. 반대로 B 자체에 빈 구간이 없고 앱이 A에 의존하지 않는 조건이라면 A의 손실 때문에 B까지 순서 전달을 막을 필요는 없습니다. 연결 수준 혼잡 제어와 HTTP의 다른 의존성은 별도 조건입니다.

QUIC의 핵심 구조

QUIC은 UDP 데이터그램 위에서 동작하지만, 애플리케이션이 쓰기 편한 전송 기능을 자체적으로 제공합니다.

RFC 9000은 QUIC을 UDP 기반의 다중화되고 안전한 전송 프로토콜로 정의합니다.

기능전송 구현 비교
연결 수립TCP + TLS: TCP handshake 뒤 TLS handshake; QUIC: 전송 handshake와 TLS 1.3 handshake 통합
재연결TCP + TLS: TCP 연결과 TLS 재협상 필요; QUIC: 조건이 맞으면 0-RTT application data 가능
HOL BlockingTCP + TLS: 하나의 바이트 스트림 손실이 전체 전달 지연; QUIC: 스트림별 전달, 단 같은 스트림 안 HOL은 존재
암호화 범위TCP + TLS: TLS가 TCP payload 보호; QUIC: QUIC packet 대부분 보호, 일부 헤더는 노출
연결 식별TCP + TLS: IP/Port 4-tuple 중심; QUIC: Connection ID로 경로 변경 대응
구현 위치TCP + TLS: 주로 커널 TCP 스택; QUIC: 주로 사용자 공간 구현
배포 속도TCP + TLS: OS/커널 업데이트 영향 큼; QUIC: 라이브러리·애플리케이션 업데이트 가능
혼잡 제어TCP + TLS: 커널 TCP 구현; QUIC: QUIC 구현체가 손실 복구·혼잡 제어 수행

연결 수립 시간 비교

TCP + TLS에서는 먼저 TCP 연결을 만들고, 그 위에서 TLS 핸드셰이크를 진행합니다.

TLS 1.3 기준으로도 일반적으로 새 연결은 TCP 1 RTT와 TLS 1 RTT가 필요합니다.

QUIC은 전송과 암호화 협상을 통합해 일반적인 새 연결에서 클라이언트가 1 RTT 뒤 application data를 보낼 수 있습니다. 추가 Retry, 손실, 인증 지연이 없는 비교입니다.

재방문 또는 재연결 상황에서는 0-RTT가 가능할 수 있습니다.

0-RTT는 이전 연결에서 얻은 정보를 이용해 첫 왕복 전부터 application data를 보낼 수 있는 기능입니다.

하지만 replay attack 위험이 있으므로 메서드 이름이나 멱등성만으로 허용하지 않습니다. 리소스별로 재실행 부작용을 평가한 정책이 필요하며, 서버는 early data 처리를 핸드셰이크 뒤로 미루거나 425 Too Early로 거절할 수 있습니다.

RTT가 큰 해외 서버나 모바일 네트워크에서는 이 차이가 체감 성능에 영향을 줄 수 있습니다.

다만 실제 지연 시간은 DNS, TLS 인증서 검증, 서버 처리, 네트워크 손실, UDP 차단 여부의 영향을 함께 받습니다.

숫자로 비교하되 측정 범위를 정하기: RTT=40ms이고 DNS·서버 처리·검증 처리 지연·Retry·손실이 없는 새 연결을 가정합니다. 위 기본 비교에서 클라이언트가 첫 application data를 보내기까지 TCP+TLS 1.3은 2 × 40 = 80ms, QUIC은 1 × 40 = 40ms의 handshake 왕복 대기를 셉니다. 요청의 서버 도착·업무 처리·응답 수신까지 완료된 시간과는 다른 기준입니다.

독립 설명: 재연결의 early data를 허용해 클라이언트가 첫 왕복 전에 요청을 보냈습니다. 이 0-RTT라는 이름만으로 요청 결과가 0ms에 도착하고 재실행 부작용도 없다고 결론 낼 수 있나요?

먼저 보낼 수 있는 것과 성공 완료 구분

0-RTT는 이전 상태를 이용해 서버 응답을 기다리기 전 application data를 보낼 수 있다는 뜻입니다. 네트워크 전달·서버 처리·응답 시간은 남으며 서버가 early data를 거절할 수도 있습니다. replay 위험에 맞는 리소스 정책도 필요하므로 0ms 완료나 업무의 정확히 한 번 실행을 보장하지 않습니다. 이 계산은 주어진 왕복 횟수의 모형이며 실제 사이트의 지연 측정이나 TLS 구현 검증이 아닙니다.

연결 마이그레이션

TCP 연결은 보통 소스 IP, 소스 포트, 목적지 IP, 목적지 포트의 4-tuple로 식별됩니다.

스마트폰이 Wi-Fi에서 LTE로 바뀌면 소스 IP와 경로가 바뀌므로 기존 TCP 연결을 유지하기 어렵습니다.

QUIC은 Connection ID를 사용해 연결을 식별할 수 있고, 경로가 바뀌면 path validation을 통해 새 경로를 확인합니다.

경로를 바꿀 때 Connection ID도 새로 선택할 수 있으므로 같은 ID 문자열을 계속 쓰는 것이 연결 유지의 조건은 아닙니다.

단, 네트워크 정책, NAT, 방화벽, 서버 구현, path validation 결과에 따라 연결 유지 여부가 달라질 수 있습니다.

HTTP/3와 QUIC의 관계

HTTP/3는 HTTP semantics를 QUIC 전송 위에 올린 버전입니다.

HTTP/3는 HTTP/2의 개념을 이어받지만, TCP가 아니라 QUIC 스트림과 QUIC 연결을 사용합니다.

IETF 표준 기준으로 QUIC 핵심 전송은 RFC 9000(2021년), QUIC-TLS는 RFC 9001(2021년), 손실 복구와 혼잡 제어는 RFC 9002(2021년), HTTP/3는 RFC 9114(2022년)에 정의되어 있습니다.

HTTP/3 지원 확인
# curl이 HTTP/3를 지원하도록 빌드되어 있어야 함
curl -I --http3 https://www.google.com

# Alt-Svc 헤더로 HTTP/3 후보 확인
curl -sI https://www.google.com | grep -i alt-svc

# 예: h3=":443"; ma=2592000
# h3는 HTTP/3 엔드포인트를, ma는 Alt-Svc 유효 시간을 뜻함

curl --http3는 연결 실패나 지연 시 이전 HTTP 버전으로 진행할 수 있고, Alt-Svc는 서버의 후보 광고입니다. 명령 성공이나 광고만으로 실제 HTTP/3 사용을 확정하지 말고 협상 결과를 확인합니다. 실습 환경마다 협상 결과가 달라질 수 있습니다.

QUIC의 현실적 고려사항

QUIC은 지연 시간과 손실 회복, 모바일 이동성에서 장점이 있지만 모든 환경에서 더 빠르다고 단정할 수는 없습니다.

UDP 차단, 관측·디버깅 도구, CPU 비용, 서버/클라이언트 구현 품질, 0-RTT 정책을 함께 고려해야 합니다.

환경효과와 조건
높은 RTTQUIC 기대 효과: handshake RTT 절감 효과가 큼; 주의점: 0-RTT는 replay-safe 요청에 제한
손실이 있는 네트워크QUIC 기대 효과: 스트림 간 HOL Blocking 감소; 주의점: 손실 복구와 혼잡 제어 구현 품질
모바일 경로 전환QUIC 기대 효과: Connection ID 기반 migration 가능; 주의점: path validation과 정책에 좌우
저지연 LANQUIC 기대 효과: TCP 대비 체감 차이가 작을 수 있음; 주의점: CPU/구현 오버헤드가 더 보일 수 있음
기업·학교 네트워크QUIC 기대 효과: UDP/443 차단 또는 rate limit 가능; 주의점: TCP fallback 필요
대용량 파일 전송QUIC 기대 효과: 환경에 따라 TCP가 충분히 효율적일 수 있음; 주의점: 실제 측정으로 판단

멀티캐스트, 브로드캐스트, 애니캐스트

유니캐스트, 브로드캐스트, 멀티캐스트, 애니캐스트는 “누구에게 보내는가”를 나타내는 통신 패턴입니다.

엄밀히는 전송 계층만의 기능이라기보다 IP와 링크 계층 주소 지정, 라우팅, 애플리케이션 설계와 함께 이해해야 합니다.

통신 패턴수신 범위와 쓰임
유니캐스트수신자: 특정 1개; 범위: 전역; 주로 쓰는 맥락: TCP/UDP; 사용 사례: 웹, 이메일, 파일 전송
브로드캐스트수신자: 같은 네트워크의 모든 장치; 범위: 주로 LAN; 주로 쓰는 맥락: 링크 계층/IPv4 일부; 사용 사례: ARP, DHCP discovery
멀티캐스트수신자: 그룹 가입자; 범위: 설정에 따라; 주로 쓰는 맥락: IP multicast + UDP 등; 사용 사례: IPTV, 일부 실시간 배포
애니캐스트수신자: 라우팅이 선택한 하나의 인스턴스; 범위: 전역; 주로 쓰는 맥락: BGP 라우팅; 사용 사례: DNS, CDN edge

같은 데이터를 여러 수신자에게 보낼 때 멀티캐스트는 네트워크 효율을 높일 수 있습니다.

다만 공용 인터넷에서 임의 멀티캐스트가 널리 제공되는 것은 아니며, 라우팅과 네트워크 장비 지원이 필요합니다.

UDP는 연결 설정이 없고 데이터그램 단위로 보내므로 멀티캐스트·브로드캐스트와 함께 쓰이기 쉽습니다.

TCP는 연결 지향이라 기본적으로 1:1 통신에 맞춰져 있습니다.

전송 계층 면접 총정리

  • QUIC — 질문: QUIC이 UDP 위에 구현된 이유?; 핵심 답변: TCP는 커널·중간장비 영향이 커서 진화가 느리고, UDP 위 사용자 공간 구현은 배포가 빠름

  • QUIC — 질문: 0-RTT의 보안 위험?; 핵심 답변: replay 위험이 있어 리소스별 안전 정책과 지연 처리·425 거절 필요

  • QUIC — 질문: 연결 마이그레이션이란?; 핵심 답변: Connection ID와 path validation으로 IP/Port 변경 후에도 연결을 이어갈 수 있는 기능

  • HTTP/3 — 질문: HTTP/2 대비 장점?; 핵심 답변: QUIC 기반 스트림, TCP 수준 HOL Blocking 감소, 연결 설정 지연 감소

  • 통신 패턴 — 질문: 유니캐스트/멀티캐스트 차이?; 핵심 답변: 유니캐스트는 1:1, 멀티캐스트는 그룹 수신자에게 네트워크가 복제 전달

  • 애니캐스트 — 질문: CDN과 DNS에서 활용하는 이유?; 핵심 답변: 같은 IP를 여러 위치에서 광고하고 라우팅 정책이 선택한 인스턴스로 보냄

다음 장에서는 브라우저에 도메인 이름을 입력하면 벌어지는 일, DNS의 세계를 들여다보겠습니다.

TCP vs UDP 판단 기준

이전 문서

DNS의 구조와 동작

다음 문서

이 페이지 목차

이 페이지 목차

HTTP 버전별 진화와 한계QUIC의 핵심 구조연결 수립 시간 비교연결 마이그레이션HTTP/3와 QUIC의 관계QUIC의 현실적 고려사항멀티캐스트, 브로드캐스트, 애니캐스트전송 계층 면접 총정리