HTTP/0.9부터 HTTP/3까지의 발전 과정을 이해하려면, 먼저 HTTP가 전체 네트워크 어디쯤에 있는지 알아야 한다. 개별 기술을 깊게 파다 보면 전체 구조를 놓치기 쉬워서, 네트워크를 공간·계층·시간 세 관점으로 나눠 본다.
아래 장면에서 노드를 누르거나 단계를 넘기며 요청 하나의 여정을 따라가 보자.
주소창 입력이 URL인지 판단하고, 캐시와 HSTS로 네트워크에 나갈 필요가 있는지 먼저 따진다.
글에서 자세히 읽기1. 공간적 관점: 어디를 지나가는가
클라이언트 to 로컬 네트워크 to 공유기 to ISP/인터넷 라우터 to 목적지 네트워크 to 서버전달 구간은 크게 세 가지다.
- 호스트 to 라우터
- 라우터 to 라우터
- 라우터 to 목적지 호스트
같은 로컬 네트워크의 호스트끼리는 라우터를 거치지 않고 직접 통신할 수도 있다.
2. 계층적 관점: 어떤 책임을 수행하는가
TCP/IP 4계층
| 계층 | 책임 | 대표 기술 |
|---|---|---|
| 응용 계층 | 애플리케이션 통신 의미 정의 | HTTP, DNS |
| 전송 계층 | 프로세스 간 통신, 전송 서비스 | TCP, UDP |
| 인터넷 계층 | 호스트 간 패킷 전달, 라우팅 | IP, ICMP |
| 네트워크 접근 계층 | 인접 장치 간 전달, 물리 신호 | Ethernet, Wi-Fi |
OSI 7계층(L7 응용, L6 표현, L5 세션, L4 전송, L3 네트워크, L2 데이터 링크, L1 물리)은 개념적 참조 모델이다. 실제 인터넷 기술이 각 계층에 일대일로 대응하지는 않는다.
왜 계층으로 나누는가
데이터 전송 방식이 바뀌어도 전부 뜯어고치지 않으려는 것이다. 책임을 분리해 변경의 영향 범위를 줄인다. 하위 계층이 제공하는 서비스 계약만 유지되면 상위 계층은 그대로 둘 수 있다. 객체지향의 인터페이스와 같은 발상이다. 다만 계층 사이의 의존성이 완전히 없어지는 것은 아니다.
계층별 주소 체계
| 구분 | 계층 | 역할 |
|---|---|---|
| MAC 주소 | L2 | 해당 링크에서 장치 인터페이스 식별 |
| IP 주소 | L3 | 목적지까지 패킷 전달 |
| 포트 번호 | L4 | TCP/UDP 통신 엔드포인트 구분 |
| HTTP 경로 | L7 | 서버에서 요청 대상 자원 식별 |
TCP 연결은 보통 네 가지 정보로 구별한다.
- 출발지 IP
- 출발지 포트
- 목적지 IP
- 목적지 포트
Java의 ServerSocket.accept()는 TCP 연결을 수락한다. HTTP 요청 하나를 받았다는 뜻이 아니다.
캡슐화와 역캡슐화
Ethernet + IPv4 + TCP 통신에서는 이렇게 감싸진다.
HTTP 데이터 to TCP 세그먼트 to IP 패킷 to Ethernet 프레임 to 물리 신호수신 측은 역순으로 벗긴다. 각 계층은 자기에게 필요한 헤더만 해석한다.
HTTP 메시지 하나와 TCP 세그먼트 하나가 반드시 대응하지는 않는다. TCP는 메시지 단위가 아니라 바이트 스트림을 제공하기 때문이다.
3. 라우팅에서 헷갈리는 것들
목적지 IP는 바뀌지 않는다
원격 서버로 요청할 때 IP 패킷의 목적지를 처음엔 공유기 IP로 두었다가 나중에 서버 IP로 바꾼다고 오해하기 쉽다. 그렇지 않다.
- 목적지 IP는 처음부터 최종 서버 IP다.
- 공유기 IP는 다음 홉을 정하는 데 쓰인다.
- Ethernet 링크마다 목적지 MAC 주소는 달라질 수 있다.
- 라우터는 기존 L2 프레임을 벗기고, 다음 링크에 맞는 새 프레임을 만든다. 다음 링크가 Ethernet이어야 하는 것도 아니다.
- TTL 같은 IP 헤더 일부 필드는 라우팅 중에 바뀐다.
가정용 공유기에서는 NAT가 동작해 출발지 IP와 포트가 변환될 수 있다. 라우팅과 NAT는 별개의 개념이다.
DNS, 라우팅, ARP
| 이름 | 하는 일 |
|---|---|
| DNS (Domain Name System) | 도메인 이름 to IP 주소 |
| 라우팅 | 목적지 IP를 기준으로 다음 홉 결정 |
| ARP (Address Resolution Protocol) | 현재 링크에서 다음 대상의 MAC 주소 확인 |
ARP의 일반적인 동작은 다음과 같다.
- ARP 캐시 확인
- 매핑이 없으면 ARP Request 브로드캐스트
- 해당 IP를 가진 장치가 ARP Reply 응답
- IP-MAC 매핑을 캐시에 저장
- 그 MAC 주소로 Ethernet 프레임 전송
스위치와 라우터
- L2 스위치: 출발지 MAC으로 MAC 테이블을 학습하고, 목적지 MAC으로 전달할 포트를 고른다. 목적지 MAC을 모르면 보통 같은 VLAN의 다른 포트로 플러딩한다.
- 라우터: 목적지 IP로 라우팅 테이블을 조회해 다음 홉을 정하고, 다음 링크에 맞는 프레임을 만든다.
4. 시간적 관점: 어떤 순서로 일어나는가
캐시와 기존 연결이 없는 HTTP/1.1 HTTPS 요청을 가정한 논리적 흐름이다.
- URL 해석
- DNS 조회로 목적지 IP 확인
- 라우팅 테이블 조회, 다음 홉 결정
- ARP 등으로 링크 계층 주소 확인
- TCP 연결 수립
- TLS 핸드셰이크
- HTTP 요청 전송
- 서버 OS와 Tomcat에서 요청 처리
- Spring MVC Controller 실행
- HTTP 응답 반환
- 클라이언트의 응답 처리
- 연결 재사용 또는 종료
주의할 점이 있다.
- DNS 조회 자체도 네트워크 통신이 필요하다.
- 실제 브라우저에서는 캐시, 기존 연결, 병렬 처리, CDN이 개입한다.
- HTTP/3는 TCP가 아니라 UDP 기반 QUIC을 쓰므로 연결 과정이 다르다.
5. HTTP 버전 개요
| 버전 | 핵심 |
|---|---|
| HTTP/0.9 | GET 기반 단순 문서 요청. 상태 코드, 헤더 없음 |
| HTTP/1.0 | 버전, 상태 코드, 요청·응답 헤더, Content-Type. 기본은 요청마다 연결 종료 (일부 구현에 Keep-Alive 확장) |
| HTTP/1.1 | 지속 연결이 기본. 연결 재사용, 메시지 길이 구분 메커니즘 |
| HTTP/2 | 바이너리 프레이밍, 스트림, 멀티플렉싱, 헤더 압축 |
| HTTP/3 | UDP 기반 QUIC. 전송 계층 HOL Blocking 완화, TLS 1.3 통합 |
이 표는 개요일 뿐이고, 각 버전의 내부 구조는 이후 글에서 다룬다.
6. 정리
요청 1개가 서버에 갔다가 돌아오는 과정이 전부다.
핵심은 맞다. 다만 HTTP 요청 한 번과 TCP 연결 한 번은 같지 않다.
- 하나의 TCP 연결에서 여러 HTTP 요청을 처리할 수 있다.
- HTTP/2는 하나의 연결 위에서 여러 스트림을 멀티플렉싱한다.
- HTTP/3는 TCP 대신 QUIC을 쓴다.
- DNS 조회 같은 준비 단계에도 별도의 네트워크 통신이 일어난다.
이 구분이 이후 HTTP 버전별 발전을 이해하는 기반이 된다.
다음에 다룰 주제
- URL 구조와 DNS
- 서브넷, CIDR, 라우팅 테이블, NAT
- TCP: 3-way handshake, 흐름 제어, 혼잡 제어, TIME_WAIT
- TLS 핸드셰이크와 HTTP 메시지 경계
- HTTP/0.9 to HTTP/3 내부 동작
- Java Socket, Tomcat, curl로 직접 확인하기