OSI 7계층과 TCP/IP 5계층: 그림으로 이해하는 데이터 전달

네트워크 계층을 처음 배우면 ‘응용·표현·세션…’이라는 이름부터 외우게 됩니다. 하지만 실제 문제를 풀 때는 데이터의 의미, 프로그램 사이의 전달, 네트워크 사이의 경로, 가까운 장치로의 전달, 물리 신호를 구분하는 편이 더 도움이 돼요. 이 다섯 가지 역할을 나누어 설명하는 것이 이 글에서 사용할 TCP/IP 5계층 모델입니다.

OSI 7계층과의 대응 관계를 먼저 잡고, 웹 요청이 서버에 도착하는 과정을 따라가겠습니다. IP 주소, MAC 주소, 포트가 각각 어디에 쓰이는지와 장애가 났을 때 어떤 정보를 확인할지도 함께 다룹니다.

이 글의 목차

OSI는 7계층인데 TCP/IP는 왜 4계층, 5계층으로 설명할까

OSI(Open Systems Interconnection)는 통신 기능을 일곱 계층으로 구분하는 참조 모델입니다. 서로 다른 시스템의 통신 기능을 공통된 틀로 설명하는 데 목적이 있습니다. OSI 모델 자체를 인터넷에서 사용하는 특정 프로토콜 하나와 동일하게 보면 안 됩니다. ITU-T X.200: OSI 기본 참조 모델

인터넷 프로토콜 구조를 설명하는 RFC 1122에는 응용, 전송, 인터넷, 링크라는 계층 구분이 나옵니다. 여기서 응용 계층의 상세 요구사항은 짝을 이루는 RFC 1123에서 다룹니다. 이 구분이 TCP/IP 4계층 설명의 근거가 됩니다. RFC 1122 §1.1.3

네트워크 교육에서는 링크 아래의 물리 전달을 따로 보기 위해 응용 → 전송 → 네트워크 → 데이터 링크 → 물리의 5계층으로 설명하기도 합니다. Kurose·Ross의 네트워크 교재 학습 자료도 이 다섯 역할을 구분합니다. 이 글은 이 학습 모델을 사용하며, ‘IETF가 유일한 표준 모델로 5계층을 정했다’는 뜻은 아닙니다. Kurose·Ross: 인터넷 프로토콜 계층 학습 자료

구분	위에서 아래로 본 계층	사용할 때의 관점
OSI 7계층	응용·표현·세션·전송·네트워크·데이터 링크·물리	통신 기능을 세분화한 참조 모델
TCP/IP 4계층	응용·전송·인터넷·링크	인터넷 프로토콜 구조 설명
이 글의 TCP/IP 5계층	응용·전송·네트워크·데이터 링크·물리	링크 전달과 물리 신호를 나누어 학습

OSI의 응용·표현·세션 역할은 5계층 모델에서는 응용 측 기능으로 묶어 이해합니다. 다만 이것은 역할을 비교하는 방법이지 모든 프로토콜 구현이 그림의 상자와 일대일로 나뉜다는 뜻은 아닙니다. 같은 기능이 라이브러리, 운영체제, 장치에 걸쳐 구현될 수도 있습니다.

OSI 7계층은 어떤 역할을 나누는가

OSI의 상위 세 계층은 통신으로 주고받는 내용과 대화의 표현·관리 방식을 구분합니다. 아래 네 계층으로 내려가면 전송, 경로, 링크, 신호의 문제가 됩니다. 처음에는 구체적인 제품 이름보다 계층이 답하는 질문을 기억하는 편이 좋아요.

OSI 계층	주된 역할	이해를 돕는 질문	5계층 모델에서의 대응
7 응용 Application	응용에 필요한 통신 서비스 제공	무엇을 요청하고 어떤 응답을 받는가	5 응용
6 표현 Presentation	데이터 표현과 전송 형식의 조정	서로 같은 의미로 데이터를 해석하는가	5 응용 측 기능
5 세션 Session	대화의 구성·제어와 동기화	대화를 어떻게 시작·관리·동기화하는가	5 응용 측 기능
4 전송 Transport	종단 사이의 데이터 전송 서비스	어떤 전송 서비스를 제공하는가	4 전송
3 네트워크 Network	여러 네트워크를 거치는 전달과 경로	목적지 네트워크로 어디를 거쳐 가는가	3 네트워크
2 데이터 링크 Data Link	하나의 링크에서 프레임 전달	가까운 상대에게 어떻게 전달하는가	2 데이터 링크
1 물리 Physical	전기·광·무선 등의 신호 전달	비트를 어떤 신호로 실어 보내는가	1 물리

표현 계층을 ‘암호화만 하는 계층’, 세션 계층을 ‘로그인 정보를 저장하는 계층’으로 외우면 범위가 너무 좁아집니다. 데이터의 표현과 대화 제어라는 역할이 먼저입니다. 웹 로그인 세션, TCP 연결, OSI 세션 계층은 이름이 비슷해도 같은 개념이 아닙니다.

또한 응용 계층은 브라우저의 버튼이나 화면 전체를 뜻하지 않습니다. 응용 프로그램이 통신할 때 사용하는 규칙과 서비스라는 관점으로 봅니다. 브라우저는 HTTP를 사용하지만 화면 렌더링과 사용자 인터페이스를 모두 네트워크 계층 모델에 넣는 것은 아닙니다.

TCP/IP 5계층을 실제 통신에 연결하기

5계층 응용: 데이터의 의미와 통신 규칙

응용 계층은 프로그램이 주고받는 메시지의 형식과 의미를 정합니다. 웹에서는 HTTP 요청과 응답, 이름 조회에서는 DNS 질의와 응답을 만날 수 있습니다. SSH는 원격 접속에 필요한 통신 규칙을 제공합니다.

이 계층에서 중요한 것은 ‘전달받은 바이트를 어떤 요청으로 해석할 것인가’입니다. 같은 네트워크에 연결되어 있어도 클라이언트와 서버가 서로 다른 메시지 형식을 기대하면 업무는 정상 처리되지 않습니다. 네트워크 연결 성공과 애플리케이션 처리 성공을 구분해야 하는 이유예요.

DNS가 응용 계층 프로토콜이라는 점도 기억할 만합니다. DNS는 IP 주소를 알아내는 데 쓰이지만, 그렇다고 DNS 자체가 네트워크 계층 프로토콜이 되는 것은 아닙니다. 일반적인 DNS 통신은 UDP뿐 아니라 TCP도 사용합니다. 암호화된 DNS처럼 다른 전달 방식을 사용하는 구성도 있으므로 ‘DNS는 언제나 UDP 53’이라고 단정하지 않습니다. RFC 7766: DNS의 TCP 지원

4계층 전송: 어떤 서비스와 통신할 것인가

전송 계층은 종단의 프로그램이 이용할 데이터 전달 서비스를 제공합니다. TCP와 UDP는 포트를 이용해 같은 호스트에서 오가는 여러 흐름을 구분합니다. 예를 들어 서버의 TCP 443과 UDP 443은 숫자가 같더라도 서로 다른 전송 프로토콜의 포트입니다.

TCP는 순서가 있는 신뢰성 높은 바이트 스트림을 제공합니다. 순서 번호, 확인 응답, 재전송 등을 사용하며 흐름 제어와 혼잡 제어도 수행합니다. 다만 상대가 장시간 사라지거나 네트워크가 끊기면 연결이 실패할 수 있습니다. TCP를 쓴다고 업무 요청이 반드시 완료되거나 한 번만 실행된다는 보장은 생기지 않습니다. RFC 9293: TCP의 서비스와 기능

UDP는 데이터그램 단위로 데이터를 전달하는 간단한 전송 프로토콜입니다. UDP 자체는 TCP와 같은 순서 복원이나 재전송을 보장하지 않습니다. 애플리케이션이나 UDP 위의 다른 프로토콜이 필요한 기능을 구현할 수 있으므로, UDP를 쓴다는 사실만으로 전체 서비스가 신뢰성을 포기했다고 판단하면 안 됩니다. RFC 768: UDP

구분	TCP	UDP
애플리케이션에 제공하는 단위	순서 있는 바이트 스트림	데이터그램
순서·재전송	프로토콜에서 제공	UDP 자체에서는 제공하지 않음
연결 관리	연결 상태를 유지	TCP와 같은 연결 수립 절차 없음
판단 기준	필요한 서비스와 애플리케이션 설계	지연·손실 처리와 상위 프로토콜 설계

포트 번호는 서비스를 찾는 단서이며 신원 보증은 아닙니다. 서버가 다른 포트에서 HTTPS를 제공할 수도 있고, 443 포트에 기대와 다른 프로그램이 떠 있을 수도 있습니다. 방화벽과 애플리케이션 설정을 볼 때 주소·포트·프로토콜을 함께 확인합니다.

3계층 네트워크: 다른 네트워크까지 어떻게 갈 것인가

네트워크 계층에서는 IP 주소와 라우팅을 중심으로 봅니다. 호스트는 라우팅 정보를 이용해 데이터를 직접 연결된 대상에게 보낼지, 다음 라우터로 보낼지 결정합니다. 라우터는 목적지 IP에 맞는 다음 경로를 선택해 패킷을 전달합니다.

IP는 기본적으로 최선형 전달을 제공합니다. IP 자체가 종단 간 재전송, 순서 보장, 흐름 제어를 모두 제공하는 것은 아닙니다. 이러한 기능을 필요에 따라 TCP 같은 상위 프로토콜이 맡습니다. RFC 791: IP의 범위와 역할

패킷이 계속 순환하는 것을 제한하는 정보도 있습니다. IPv4에는 TTL, IPv6에는 Hop Limit이 있으며 라우터를 지날 때 감소합니다. IPv6 라우터가 전달하면서 Hop Limit을 줄인 결과가 0이 되면 패킷을 폐기합니다. ICMP와 ICMPv6는 오류 보고와 진단 등에 사용되며 TCP나 UDP 위에 올라가는 프로토콜이 아닙니다. RFC 8200: IPv6 헤더

2계층 데이터 링크: 다음 장치까지 어떻게 전달할 것인가

데이터 링크 계층은 하나의 링크에서 프레임을 전달하는 역할입니다. Ethernet에서는 출발지·목적지 MAC 주소와 EtherType 같은 정보를 프레임에 사용합니다. IP 패킷을 Ethernet 프레임의 데이터 부분에 넣어 보내는 방식도 이 계층과 연결됩니다. RFC 894: Ethernet에서 IP 데이터그램 전달

여기서 ‘목적지 MAC’은 인터넷 반대편 서버의 MAC일 필요가 없습니다. 다른 네트워크로 가는 통신에서는 보통 현재 링크의 다음 홉, 예를 들어 기본 게이트웨이 인터페이스의 MAC으로 프레임을 보냅니다. IP의 최종 목적지와 링크의 다음 상대가 서로 다를 수 있습니다.

일반적인 L2 스위치는 MAC 주소 정보를 바탕으로 프레임을 전달합니다. VLAN은 논리적으로 L2 브로드캐스트 도메인을 나누는 데 사용합니다. 다만 스위치라는 제품이 무조건 L2 기능만 하는 것은 아니며, L3 스위치는 라우팅 기능도 수행할 수 있습니다.

Ethernet의 FCS(Frame Check Sequence)는 프레임 오류 검출에 쓰입니다. Cisco의 Ethernet 프레임과 FCS 설명 오류를 검출하는 것과 손실된 데이터를 종단까지 재전송하는 일은 다른 기능입니다. 유선 Ethernet과 Wi-Fi도 링크 동작이 같지 않으므로 모든 링크가 같은 방식으로 오류를 복구한다고 가정하지 않습니다.

1계층 물리: 비트를 신호로 전달하기

물리 계층은 비트를 전기·빛·무선 등의 신호로 표현하고 전달하는 역할입니다. 케이블, 광 모듈, 커넥터, 무선 채널과 물리 인터페이스의 조건이 이 계층의 점검 대상이 됩니다. NIC나 스위치 포트라는 장치는 물리 계층과 데이터 링크 계층 양쪽 기능을 포함할 수 있습니다.

‘링크가 올라왔다’는 것은 물리 연결을 확인하는 중요한 단서입니다. 그러나 이것만으로 VLAN, IP, 라우팅과 애플리케이션까지 정상이라는 뜻은 아닙니다. 반대로 케이블과 신호가 불안정하면 위 계층의 설정이 맞아도 손실과 재전송 때문에 서비스가 느려질 수 있습니다.

데이터는 캡슐화되어 내려가고, 해석되며 올라갑니다

캡슐화는 위 계층의 데이터를 아래 계층이 자신의 전달 정보와 함께 담는 과정입니다. TCP 통신을 Ethernet으로 전송하는 예에서는 응용 데이터에 TCP 헤더가 붙고, 이를 IP 패킷에 담은 뒤 Ethernet 프레임으로 전달합니다. 물리 계층에서는 그 정보를 매체에 맞는 신호로 실어 보냅니다.

처리 단계	통신 단위의 예	이 단계에서 보는 정보
응용	메시지·응용 데이터	요청 의미, 형식, 상태 코드 등
TCP 전송	TCP 세그먼트	출발지·목적지 포트, 순서·확인 정보 등
IP 네트워크	IP 패킷·데이터그램	출발지·목적지 IP, 다음 프로토콜 등
Ethernet 링크	Ethernet 프레임	출발지·목적지 MAC, EtherType, FCS 등
물리 전달	비트와 신호의 흐름	신호 방식과 매체 조건

PDU(Protocol Data Unit)는 각 계층에서 다루는 프로토콜 데이터 단위를 말합니다. TCP에서는 세그먼트, UDP에서는 UDP 데이터그램이라는 용어를 사용합니다. 운영자가 여러 종류의 전달 단위를 편하게 ‘패킷’이라고 부를 때도 있지만, 분석할 때는 어느 계층의 단위인지 구분하면 좋습니다.

그림의 데이터 한 덩어리는 구조를 보여 주는 예시입니다. 실제 HTTP 요청 하나가 언제나 TCP 세그먼트 하나나 IP 패킷 하나에 담기지는 않습니다. TCP는 바이트 스트림이므로 애플리케이션 메시지의 경계와 세그먼트 경계가 일치하지 않을 수 있습니다.

수신 측에서는 링크와 IP, 전송 정보를 해석하고 상위 데이터로 넘기는 과정을 거칩니다. 이를 역캡슐화라고 설명합니다. 각 계층이 조건과 오류를 확인하므로, 데이터가 들어왔다는 사실만으로 애플리케이션에 정상 전달되었다고 판단해서는 안 됩니다.

MTU와 MSS를 구분하는 이유

링크 MTU는 해당 링크에서 한 번에 운반할 수 있는 IP 패킷 등의 최대 크기입니다. TCP MSS는 TCP 헤더를 제외한 세그먼트 데이터의 최대 크기를 나타냅니다. Ethernet MTU가 1,500바이트이고 IPv4 헤더 20바이트, TCP 헤더 20바이트만 있다고 가정하면 TCP 데이터에 남는 공간은 1,460바이트입니다. 이 값은 Ethernet 프레임 전체 길이가 아닙니다.

실제 구성에서는 IP·TCP 옵션, IPv6, 터널과 경로의 MTU 등이 조건을 바꿉니다. TLS 같은 추가 프로토콜 정보가 있으면 TCP 데이터 안에서 순수한 응용 데이터가 차지하는 양도 달라집니다. 1,460이라는 값을 모든 환경의 고정값으로 외우기보다 어떤 계층의 정보를 뺀 값인지 보는 편이 정확합니다. RFC 9293: MSS 계산

웹 요청 한 번에서 IP·MAC·포트는 어떻게 쓰일까

설명을 위해 IPv4와 Ethernet을 사용하고, 다른 네트워크의 웹 서버에 TCP 기반 HTTPS로 접속하는 상황을 가정합니다. 이름 조회는 이미 끝났고, 기본 경로를 통해 게이트웨이로 나가며 NAT·프록시·VPN은 없다고 하겠습니다. 실제 패킷을 캡처한 결과가 아니라 계층의 역할을 설명하기 위한 예입니다.

먼저 게이트웨이와 통신할 준비를 합니다

클라이언트는 라우팅 정보를 확인해 다음 홉을 정합니다. 이 예에서는 목적지 서버가 직접 연결된 서브넷 밖에 있으므로 기본 게이트웨이가 다음 홉이 됩니다. 게이트웨이의 Ethernet MAC을 모르면 ARP로 해당 IPv4 주소에 대응하는 MAC 정보를 알아낼 수 있습니다. 이미 캐시에 있으면 매번 새 ARP 요청을 보내지는 않습니다. RFC 826: ARP

ARP는 인터넷 전체에서 서버의 MAC을 찾아 주는 서비스가 아닙니다. 현재 링크에서 필요한 IPv4 주소와 링크 주소의 관계를 알아내는 데 사용합니다. IPv6는 ARP 대신 ICMPv6 기반 Neighbor Discovery를 사용하므로 같은 명령과 패킷 흐름을 그대로 적용할 수 없습니다. RFC 4861: IPv6 Neighbor Discovery

TCP 연결과 TLS 협상 뒤 HTTP를 주고받습니다

새 TCP 연결을 만드는 기본 흐름은 SYN, SYN-ACK, ACK의 3방향 핸드셰이크로 설명할 수 있습니다. 일반적인 HTTPS의 새 연결에서는 이어서 TLS 협상을 수행하고 인증서와 암호화 조건 등을 확인한 뒤 HTTP 요청을 전송합니다. 이 설명은 TCP 기반 HTTPS를 가정하며 연결 재사용이나 다른 전송 방식의 모든 절차를 나타내지는 않습니다.

클라이언트에서 나가는 첫 Ethernet 구간을 보면 다음 세 주소 정보의 목적이 다릅니다. 전송 계층의 목적지 포트는 서버의 수신 서비스를, IP 목적지는 최종 서버를, Ethernet 목적지 MAC은 현재 링크의 다음 홉을 가리킵니다.

정보	이 예의 목적지	적용되는 범위
TCP 목적지 포트	웹 서버의 HTTPS 수신 포트, 보통 443	전송 흐름과 수신 서비스 구분
IP 목적지 주소	최종 웹 서버의 IP	네트워크를 거치는 전달
Ethernet 목적지 MAC	현재 링크에 있는 게이트웨이의 MAC	해당 Ethernet 링크의 전달

라우터는 들어온 프레임에서 IP 패킷을 받아 경로를 판단하고, 나가는 링크에 맞는 새 프레임으로 전달합니다. 따라서 라우터를 거치는 구간에서는 링크 헤더가 새로 만들어집니다. 일반적인 IP 라우팅만 수행하고 NAT 같은 변환이 없다면 출발지·목적지 IP는 유지되지만 TTL 또는 Hop Limit 등은 변할 수 있습니다. RFC 1812: IPv4 라우터의 전달 동작

같은 VLAN 안에서 일반적인 L2 스위치를 통과할 때와 라우터를 거쳐 다른 링크로 나갈 때를 구분해야 합니다. ‘스위치나 장비를 지날 때마다 목적지 MAC이 무조건 바뀐다’는 설명은 정확하지 않습니다. 처리하는 기능과 경계를 기준으로 봅니다.

장비와 프로토콜을 한 계층에만 고정하지 않기

계층 이름은 장비의 역할을 설명하는 도구입니다. 하나의 장비가 여러 계층을 처리할 수 있고, 터널은 어떤 계층의 데이터를 다른 프로토콜 안에 담을 수 있습니다. 그래서 제품 이름만 보고 패킷을 어떻게 처리하는지 단정하면 분석이 어려워져요.

대상	계층을 읽는 출발점	함께 볼 부분
NIC·스위치 포트	물리 신호와 링크 프레임	링크 협상, 오류, MAC·VLAN
일반 L2 스위치	MAC 기반 프레임 전달	VLAN, 브리지 동작, 관리용 IP
라우터·L3 스위치	IP 경로와 다음 홉	인터페이스의 물리·링크 조건
방화벽·로드밸런서	주소·포트·연결 또는 응용 처리	정책, 상태 추적, TLS 종료 여부

TLS를 OSI 표현 계층의 암호화 역할에 빗대어 설명할 수는 있습니다. 하지만 ‘TLS는 어떤 구현에서도 정확히 OSI 6계층에만 존재한다’고 고정하면 실제 스택을 설명하기 어렵습니다. TCP/IP에서는 TLS 같은 상위 프로토콜 기능과 응용 프로토콜의 관계를 구체적으로 보는 편이 좋습니다.

HTTP도 언제나 TCP를 사용하지는 않습니다. HTTP/3는 QUIC을 사용하며 QUIC은 UDP 위에서 동작하는 전송 프로토콜입니다. QUIC은 스트림과 보안, 손실 처리 등의 기능을 제공하므로 ‘UDP 위에 있으니 재전송이나 신뢰성이 없다’는 결론도 맞지 않습니다. RFC 9114: HTTP/3, RFC 9000: QUIC

장애를 계층별로 좁혀 가는 방법

사용자가 ‘인터넷이 안 된다’고 말해도 실제 원인은 신호 단절, VLAN 불일치, 경로 누락, 포트 차단, 이름 조회, TLS 인증서와 서버 오류처럼 다양합니다. 계층 모델은 이 문제들을 나누어 확인하는 틀로 사용할 수 있습니다. 아래에서 위로 항상 같은 순서를 반복하기보다, 확인된 증거에서 다음 범위를 정하는 편이 효율적입니다.

관찰한 증상	먼저 확인할 대상	단정하면 안 되는 내용
링크가 내려가 있음	케이블·광 모듈·포트·NIC·무선 연결	IP를 바꾸면 해결된다는 판단
같은 VLAN의 상대와도 통신 불가	VLAN, MAC·ARP 또는 ND, 인터페이스·주소	케이블만 연결되면 L2가 정상이라는 판단
게이트웨이는 되지만 원격 서비스 불가	경로, 정책, 반환 경로, 목적지 상태	로컬 구간 성공이 전체 경로 성공이라는 판단
IP 통신은 되지만 이름 조회 실패	DNS 서버 접근과 DNS 응답	네트워크 전체가 단절되었다는 판단
TCP 연결은 되지만 HTTPS 실패	TLS 협상·인증서·서버 이름·HTTP 처리	포트 연결 성공이 웹 업무 성공이라는 판단
ping은 실패하지만 웹 접속 성공	ICMP 정책과 서비스별 허용 조건	ping 실패만으로 서버가 꺼졌다는 판단

ping 성공은 해당 ICMP 교환이 가능하다는 증거입니다. HTTP 요청, 인증, DB 조회까지 정상이라는 증거는 아닙니다. 반대로 ICMP가 차단된 환경에서는 웹 서비스가 정상이어도 ping이 응답하지 않을 수 있습니다.

하나의 증상도 여러 계층의 영향을 받을 수 있습니다. 예를 들어 물리 오류 때문에 손실이 발생하면 TCP 재전송이 늘어나 응용 프로그램이 느려질 수 있습니다. 응용 로그에 시간 초과가 찍혔다는 사실만으로 원인을 응용 계층에 고정하지 않는 것이 좋습니다.

다음 패킷을 볼 때 기억할 세 가지

패킷 분석 화면에서 주소가 여러 개 보이면 ‘최종 목적지 IP’, ‘현재 링크의 다음 상대 MAC’, ‘전송 흐름의 포트’를 구분해 보세요. 그다음 어떤 프로토콜이 무엇을 담고 있는지와, 지금 보고 있는 위치가 라우터 전인지 후인지를 확인합니다. 계층 이름을 모두 외우는 것보다 실제 전달을 이해하는 데 더 직접적인 도움이 됩니다.

OSI 7계층은 역할을 세밀하게 나누는 참조 틀로, TCP/IP 5계층은 인터넷 통신을 다섯 가지 역할로 연결하는 학습 틀로 사용하면 됩니다. 이후 VLAN, 라우팅, 방화벽을 공부할 때도 같은 흐름을 따라가면 각 기능이 해결하는 문제를 구분하기 쉬워집니다.

참고 문서와 그림 안내

공식 표준 문서와 학습 자료는 2026년 10월 18일 기준으로 확인했습니다. 예시의 통신 흐름과 신호 파형은 개념을 설명하기 위해 단순화했으며 실제 패킷 캡처나 장비 측정 결과가 아닙니다. 그림 두 장은 이 글을 위해 GPT 이미지 서비스로 생성했고, 계층 대응과 헤더 순서를 본문과 대조했습니다.

• ITU-T X.200: OSI 기본 참조 모델
• RFC 1122: 인터넷 호스트의 계층 구조
• Kurose·Ross: 5계층의 역할 학습
• RFC 9293: TCP
• RFC 768: UDP
• RFC 791: IPv4 · RFC 8200: IPv6
• RFC 894: Ethernet의 IP 캡슐화
• RFC 826: ARP · RFC 4861: IPv6 Neighbor Discovery
• RFC 7766: DNS의 TCP 지원
• RFC 1812: IPv4 라우터 요구사항
• RFC 9114: HTTP/3 · RFC 9000: QUIC