웹의 근간을 이루는 HTTP 프로토콜
우리가 매일 브라우저에 주소를 치고 접속하는 이면에는 서버와 클라이언트 간의 데이터 교환 규약인 HTTP가 존재합니다. 1990년대 초 제안된 최초 규격부터 오늘날의 초고속 HTTP/3에 이르기까지, 전송 지연 속도를 줄이고 데이터를 더욱 안전하게 나르기 위한 네트워크 엔지니어들의 분투 역사를 소개합니다.
1. HTTP/1.1: 연결 유지와 파이프라이닝
HTTP/1.1은 오랜 기간 인터넷 통신의 기본 규격이었습니다. 매번 통신할 때마다 3-Way Handshake 과정을 거쳐 TCP 연결을 맺고 끊는 리소스를 줄이기 위해 Keep-Alive 설정을 도입했습니다.
그러나 하나의 TCP 연결에서 요청에 대한 응답이 순차적으로 완료될 때까지 다음 요청이 대기하는 HOLB(Head-of-Line Blocking) 문제가 심각한 성능 병목을 일으켰습니다.
2. HTTP/2: 멀티플렉싱과 헤더 압축
2015년 공식 발표된 HTTP/2는 하나의 커넥션 내에서 여러 개의 독립적인 프레임(Frame)을 동시에 비순차적으로 전송할 수 있는 멀티플렉싱(Multiplexing) 기술을 도입했습니다. 또한 중복되는 헤더 영역을 HPACK 알고리즘으로 압축하여 패킷 크기를 크게 낮추었습니다.
3. HTTP/3: TCP를 넘어선 UDP와 QUIC 프로토콜
HTTP/2까지 해결하지 못했던 TCP 자체의 패킷 드롭 홀인(HOLB)을 근본적으로 개선하고자, HTTP/3은 전송 계층 프로토콜을 TCP에서 UDP 기반의 QUIC로 교체했습니다.
연결 수립 시간이 획기적으로 줄었으며, 와이파이에서 모바일 데이터로 이동하는 물리적 네트워크 환경 변화에서도 끊김 없이 매끄럽게 통신 세션을 유지할 수 있는 강력한 이동성을 자랑합니다.
버전 차이를 실제로 체감하는 지점
HTTP 버전은 브라우저 주소창에서 보이지 않지만, 이미지가 많은 페이지나 API 호출이 많은 화면에서는 사용자 체감 속도에 직접 영향을 줍니다. 다만 애플리케이션 코드만으로 해결할 수 있는 영역과 CDN, 서버, TLS 설정이 필요한 영역을 구분해야 합니다.
점검 포인트
- 정적 파일은 CDN을 통해 HTTP/2 이상으로 제공되는지 확인합니다.
- 불필요한 API 호출을 줄이고, 같은 데이터를 여러 번 요청하지 않도록 캐싱합니다.
- HTTP/3 도입은 서버와 CDN 지원, 실제 사용자 네트워크 비율을 함께 보고 결정합니다.
프로토콜 최적화는 프론트엔드 번들 최적화와 함께 볼 때 효과가 큽니다. 전송 계층이 좋아도 보내는 파일이 과하면 체감 성능은 개선되지 않습니다.
참고 자료와 업데이트 기준
이 글은 실무 적용 관점에서 작성했으며, 관련 기술의 공식 문서와 브라우저 지원 현황이 바뀌면 내용을 다시 점검합니다. 특히 프레임워크 버전, API 정책, 성능 측정 방식은 시간이 지나며 달라질 수 있으므로 배포 전에는 최신 문서를 함께 확인하는 것을 권장합니다.
- MDN Web Docs에서 웹 표준과 브라우저 동작을 확인합니다.
- web.dev에서 성능, 접근성, 사용자 경험 기준을 확인합니다.
- React 공식 문서에서 React 관련 API와 권장 패턴을 확인합니다.
