문서 간 링크로 연결되는 하이퍼텍스트를 전송하려고 만든 프로토콜. 시작은 그랬지만 지금은 거의 모든 것을 HTTP 메시지에 담아 보낸다. HTML과 텍스트, 이미지와 음성과 영상과 파일, API가 주고받는 JSON과 XML까지 전부다. 서버끼리 통신할 때도 대부분 HTTP를 쓴다. 실무에서 TCP를 직접 연결해 데이터를 보내는 경우는 드물다.
요청과 응답
HTTP는 요청과 응답으로 도는 클라이언트-서버 구조다. 클라이언트가 HTTP 메시지로 요청을 보내고 응답을 기다리면, 서버가 결과를 HTTP 메시지로 만들어 돌려준다.
이 둘을 개념적으로 갈라두는 데는 이유가 있다. 비즈니스 로직과 데이터를 전부 서버에 두면 클라이언트는 UI와 사용성에 집중할 수 있다. 양쪽이 각자의 분야에 붙어 독립적으로 발전한다.
무상태(stateless)는 서버가 클라이언트의 상태를 보존하지 않는다는 뜻이다. 점원 비유가 명쾌하다. 상태를 유지하는 쪽에서는 고객이 “노트북”, “2개”, “신용카드로”를 나눠 말하는 동안 점원이 바뀌면 대화가 끊긴다. 바꾸려면 앞의 대화를 인계해야 한다. 무상태 쪽에서는 고객이 매번 필요한 정보를 다 말하므로 점원이 바뀌어도 상관없다.
그래서 갑자기 요청이 늘어도 서버를 대거 투입할 수 있다. 응답할 서버를 아무거나 골라도 되니 수평으로 무한히 늘릴 수 있고, 중간에 한 대가 죽어도 다른 서버가 이어받는다. 대가는 클라이언트가 매번 데이터를 더 보내야 한다는 것이다.
연결을 유지하지 않는 것도 기본 성질이다. 비연결성에서 따로 본다. 통신은 모두 HTTP 메시지로 이루어지고, 스펙 자체가 단순한 대신 확장할 자리를 열어두었다.
버전과 기반 프로토콜
| 버전 | 연도 | 무엇이 바뀌었나 |
|---|---|---|
| 0.9 | 1991 | GET만 있고 헤더가 없다 |
| 1.0 | 1996 | 메서드와 헤더가 추가됐다 |
| 1.1 | 1997 | 가장 많이 쓰인다 |
| 2 | 2015 | 성능 개선 |
| 3 | 2022 | TCP 대신 UDP를 쓴다 |
1.1은 RFC 2068에서 시작해 RFC 2616을 거쳐 RFC 7230부터 7235까지로 다시 정리되었다. 기반 프로토콜은 1.1과 2가 TCP, 3이 UDP다. TCP의 연결 수립 과정을 줄이려고 갈아탄 것이다.
무상태의 한계
완전한 무상태는 불가능하다. 로그인이 필요 없는 소개 화면은 무상태로 만들 수 있지만, 로그인한 사용자는 로그인했다는 사실을 어딘가에 붙들고 있어야 한다. 그럴 때는 브라우저 쿠키와 서버 세션, 토큰으로 상태를 클라이언트나 별도 저장소로 밀어내고, 서버가 직접 들고 있는 상태는 최소한으로 줄인다.
이 판단이 결정적으로 갈리는 순간은 같은 시각에 대용량 트래픽이 몰릴 때다. 선착순 이벤트, 명절 기차표 예매, 수강 신청처럼 저녁 여섯 시에 수만 명이 동시에 요청하는 상황이다. 무상태로 설계되어 있으면 서버를 늘려 받아내면 되지만, 상태를 서버가 들고 있으면 늘려도 소용없다. 이벤트의 첫 페이지를 로그인도 필요 없는 정적 HTML 하나로 두는 것도 같은 이유다. 사람들이 그것을 보다가 버튼을 누르므로 요청 시각이 조금씩 흩어진다.
참고
HTTP/3는 2022년 6월 RFC 9114로 표준화가 끝났다. 원본을 옮길 당시에는 진행 중이었다. RFC 9114