HTTP 프로토콜

HTTP(HyperText Transfer Protocol)는 웹 통신을 위한 응용 계층 프로토콜이다. 이름은 HTML 문서 전송에서 왔지만, 이미지·JSON 등 웹 표준으로 정의된 여러 종류의 데이터를 주고받을 수 있다. 동작은 단순하게 "요청하면 응답한다". 브라우저·프론트엔드·백엔드가 이 규약 위에서 어떻게 대화하는지는 웹 앱의 요청·응답 구조에 정리했다.

웹(World Wide Web)과 인터넷은 다르다. 인터넷은 패킷을 실어 나르는 망이고, 웹은 메신저·게임처럼 그 위에서 도는 응용 하나다. 웹은 다른 문서로 건너가는 링크(하이퍼링크)를 품은 문서, 즉 하이퍼텍스트(hypertext)를 서로 잇는 거대한 분산 응용이며, 세 표준이 떠받친다. 문서마다 고유한 주소를 주는 URL, 하이퍼텍스트를 주고받는 HTTP, 텍스트에 제목·링크 같은 구조를 표시하는 HTML이다. 이 표준이 공개돼 있어서 누구나 웹 서버와 브라우저를 만들 수 있다.

Stateless와 Connectionless

HTTP를 설명하는 두 성질은 기억하지 않는 대상이 다르다.

HTTP가 무상태를 고른 이유는 확장성과 단순함이다. 서버가 클라이언트별 상태를 들고 있지 않으면 어느 서버가 어느 요청을 받아도 같은 답을 낼 수 있다. 그래서 로드 밸런서 뒤에 서버를 마음대로 늘리고, 한 대가 죽어도 다른 서버가 이어 받고, 중간 캐시·프록시가 요청 하나만 보고 응답을 재사용할 수 있다. 상태가 필요한 부분만 세션 저장소·토큰처럼 따로 관리하면 된다.

지금의 HTTP는 연결을 재사용하므로 엄밀히는 Connectionless가 아니다. 하지만 연결을 재사용해도 무상태는 그대로다. 같은 연결로 온 두 요청도 서버는 서로 무관한 요청으로 해석한다.

요청 메시지

GET /company/location HTTP/1.1      ← Request Line
Host: test.com                      ← Headers
Accept: text/html
                                    ← 빈 줄
(Body)                              ← 필요할 때만

• Request Line: 메서드 + 공백 + URI + 공백 + HTTP 버전
• Headers: 요청에 대한 부가 정보
• 빈 줄: 헤더의 끝 표시
• Body: 서버로 보낼 데이터

줄 끝은 CRLF

HTTP/1.1의 시작줄과 헤더는 각 줄을 \r\n(CRLF) 으로 끝내고, 헤더의 끝은 빈 줄 \r\n\r\n으로 표시한다. SMTP 같은 오래된 텍스트 프로토콜도 같다.

타자기에서 "다음 줄 첫 칸"은 두 동작을 함께 해야 했다. 그래서 터미널에서 printf("aa\rbb\n")을 하면 \r이 커서를 줄 앞으로 돌려 bb가 aa를 덮어쓴다. 운영체제마다 줄바꿈 관례가 다르다. UNIX·macOS는 LF, Windows는 CRLF를 쓴다. 저장소에서는 .gitattributes로 줄바꿈을 통일한다. 헤더 값에 사용자 입력을 그대로 넣으면 공격자가 CRLF를 끼워 헤더를 추가로 만들 수 있다(HTTP 응답 분할). HTTP/2·3은 메시지를 이진 프레임으로 보내므로 줄 구분 문자가 없다.

주요 메서드

안전(safe) 은 서버의 상태를 바꾸지 않는다는 뜻이고, 멱등(idempotent) 은 같은 요청을 여러 번(또는 동시에) 보내도 결과가 한 번 보낸 것과 같다는 뜻이다. 멱등한 요청은 네트워크 오류 때 그대로 재시도해도 된다. TRACE는 쿠키 같은 헤더를 그대로 되돌려 주므로 운영 서버에서는 보통 꺼 둔다.

본문을 싣는 세 메서드는 뜻이 다르다. PUT은 대상 URI의 자원을 보낸 표현으로 통째로 바꾸고, 없으면 그 URI에 만든다. 같은 본문을 몇 번 보내도 결과가 같아 멱등이고, 보낸 표현이 자원 전체가 되므로 빠진 필드는 비워진다. PATCH는 자원의 일부를 고치는 변경 명령을 보낸다. 「나이를 1 올려라」 같은 상대적 변경이면 보낼 때마다 결과가 달라지므로 멱등을 보장하지 않는다. POST는 대상 자원이 본문을 자기 규칙대로 처리하게 한다. 컬렉션에 POST해 새 자원을 만들면 서버가 URI를 정해 201 Created의 Location 헤더로 알리고, PUT은 클라이언트가 URI를 정한다. POST는 두 번 보내면 두 개가 생길 수 있어 그대로 재시도하면 위험하다. 안전하게 재시도하는 법은 REST API 설계의 멱등 키에 있다.

GET은 가져오기만 하고, 상태를 바꾸는 일은 POST 이상으로 한다. 브라우저의 링크 미리 가져오기(prefetch), 검색 엔진 크롤러, 링크 미리보기 봇은 GET 링크를 사람 대신 마구 따라간다. /delete?id=42 같은 GET 링크로 삭제를 만들면 이런 도구가 지나가기만 해도 데이터가 사라진다. 반대로 GET으로 가져오는 자원은 URL만으로 공유·북마크·캐시할 수 있다. GET의 쿼리 문자열은 URL 길이 제한을 받고 서버 로그·브라우저 기록에 남으므로, 큰 데이터와 민감한 값은 본문으로 보낸다.

GET에 본문을 싣는 것은 문법상 막혀 있지 않지만 쓰지 않는다. HTTP 표준(RFC 9110)은 GET 요청의 본문에 정해진 의미가 없다고 하고, 출처가 미리 합의하지 않았다면 보내지 말라고 한다. 의미가 없으니 처리가 제각각이다.

검색 조건이 너무 길어 URL에 담기 어려우면 POST로 「검색 요청」을 보낸다. 조회처럼 안전·멱등하면서 본문을 받는 메서드로 QUERY가 IETF에서 표준화 중이다.

HTML <form>도 결국 HTTP 요청을 만드는 도구다. action에 보낼 URL을, method에 메서드를 지정하면 각 <input>의 name이 key, 입력값이 value가 되어 서버로 전달된다. 단, <form>의 method는 GET과 POST만 지원하므로 PUT·PATCH·DELETE는 JavaScript(fetch)로 보내야 한다.

응답 메시지

HTTP/1.1 200 OK                     ← Status Line
Content-Type: text/html             ← Headers
                                    ← 빈 줄
<html>...</html>                    ← Body

• Status Line: HTTP 버전 + 공백 + 상태 코드 + 공백 + 상태 문구

상태 코드

앞자리는 먼저 누구 잘못인가를 알린다. 4xx는 클라이언트가 요청을 고쳐야 하므로 그대로 다시 보내도 소용없다. 5xx는 서버 문제라 같은 요청을 나중에 다시 보내면 성공할 수 있다. API에서 자주 고르는 코드는 다음과 같다.

표준이 아니거나 사연이 있는 코드도 있다.

비표준 코드는 프록시·라이브러리가 제대로 다루지 못한다. 직접 만든 API에서는 표준 코드만 쓰고, 세부 사유는 응답 본문의 오류 코드로 전한다.

상태 코드는 결과를 그대로 말해야 한다. 실패를 200 OK에 {"success": false}로 감싸면 HTTP 클라이언트 라이브러리·모니터링·캐시가 모두 성공으로 처리한다. 비슷해 보이는 코드는 원인이 어디에 있는지로 가른다.

301과 302는 역사적으로 브라우저가 POST를 GET으로 바꿔 다시 요청하는 경우가 있었다. 메서드를 반드시 유지해야 하면 307·308을 쓴다. 검색 엔진은 301·308을 영구 이동으로 보고 새 URL로 신호를 옮긴다(SEO 기초).

리다이렉트

리다이렉트 방법은 세 가지이고 먼저 적용되는 순서가 있다.

• 리다이렉트는 왕복을 하나 더 만든다. 사이트 안의 링크는 리다이렉트에 기대지 말고 최종 주소로 고친다.
• 리다이렉트가 돌고 돌아 처음으로 돌아오면 리다이렉트 루프다. 브라우저가 감지해 오류 페이지를 띄운다. 설정을 바꾼 직후 생기면 서버 규칙(HTTPS 강제와 프록시의 X-Forwarded-Proto 불일치가 흔한 원인)을 의심한다.
• Nginx에서는 return 301 https://$host$request_uri;처럼 쓴다.

헤더의 종류

헤더는 요청·응답 본문에 대한 설명서다. 클라이언트는 헤더로 "무엇을 보내고, 무엇을 받고 싶고, 나는 누구인지"를 알리고, 서버는 "무엇을 보내는지, 어떻게 다뤄야 하는지"를 알린다. REST API를 만들 때 자주 다루는 헤더는 다음과 같다.

본문 형식: MIME 타입

Content-Type의 값은 MIME 타입(미디어 타입) 으로, type/subtype;parameter=value 모양이다. 브라우저는 파일 확장자가 아니라 이 값으로 본문을 해석한다.

• 서버가 타입을 잘못 보내면(스크립트를 text/plain으로) 브라우저가 실행을 거부하거나 내용을 보고 추측한다. 이 추측(MIME 스니핑)은 업로드한 파일이 스크립트로 실행되는 공격에 쓰이므로 X-Content-Type-Options: nosniff로 끈다.
• text/plain은 「아무 텍스트」가 아니다. 형식이 정해진 텍스트는 그 타입(text/csv, application/json)으로 보낸다.

압축

• 알고리즘은 gzip(어디서나 지원), Brotli(br, 텍스트에서 gzip보다 작다), Zstandard(zstd, 압축·해제가 빠르다. Chrome·Edge·Firefox가 지원)가 있다. 서버는 클라이언트가 보낸 목록에서 고르고, 정적 파일은 빌드 때 미리 높은 레벨로 압축해 둔다.
• Vary: Accept-Encoding을 빠뜨리면 캐시가 br 응답을 br을 모르는 클라이언트에게 줄 수 있다(HTTP 캐시).
• 압축 사전 전송(Compression Dictionary Transport)은 이전에 받은 자원(예: app.v1.js)을 사전으로 삼아 새 버전(app.v2.js)의 차이만 보내는 방식이다. Content-Encoding: dcb(Brotli), dcz(Zstandard)를 쓰며 Chromium 계열에서 먼저 지원한다.
• HTTPS에서 비밀값(CSRF 토큰)과 공격자가 넣은 입력을 한 응답에 같이 압축하면 압축 길이로 비밀을 추측하는 공격(BREACH)이 가능하다. 비밀은 요청마다 무작위로 가린다.

URI, URL, URN

scheme:[//authority]path[?query][#fragment]
 
https://user@shop.example.com:8443/products/42?color=red&size=m#reviews
 
scheme     https
authority  user@shop.example.com:8443   (userinfo@host:port)
path       /products/42
query      color=red&size=m
fragment   reviews

주소창에 URL을 넣는 것은 웹 페이지가 아니라 자원(resource) 에 접근하는 일이다. 같은 방식으로 이미지, JSON, 파일을 가리킨다.

정리하면 URI는 식별하고, URL은 위치를 가리킨다. AWS는 URN 개념을 확장해 리소스를 ARN(Amazon Resource Name)으로 명명·관리한다.

HTTP 버전

위의 텍스트 메시지 형식은 HTTP/1.1 기준이다. 메서드·상태 코드·헤더의 의미는 버전과 상관없이 같고, 메시지를 실어 나르는 방식만 다르다.

HTTP/1.1·2가 TCP 위에서 도는 이유는 메시지가 빠짐없이, 순서대로 도착해야 하기 때문이다. HTML·JSON은 한 바이트만 빠지거나 뒤바뀌어도 해석할 수 없다. TCP가 재전송·순서 맞춤·흐름·혼잡 제어를 해 주므로 HTTP는 요청·응답의 의미만 정하면 된다. HTTP/3도 이 신뢰성을 포기하지 않았다. UDP 위의 QUIC이 같은 일을 사용자 공간에서 다시 구현했을 뿐이다(아래 「HTTP/3가 UDP를 고른 이유」).

연결 관리와 왕복 줄이기

HTTP 성능의 이상은 「필요한 데이터만, 가장 적은 왕복으로」다. 모바일 망에서는 왕복 한 번(RTT)이 100ms를 넘기 쉬워, 바이트 수보다 왕복 횟수가 체감 속도를 정하는 경우가 많다. HTTP의 진화는 대부분 이 왕복을 줄이는 과정이다.

Connection, Keep-Alive는 홉 단위(hop-by-hop) 헤더다. 클라이언트–프록시 구간과 프록시–서버 구간의 연결 방식이 다를 수 있고, 프록시는 이 헤더를 다음 홉에 넘기지 않는다. HTTP keep-alive는 「응답 뒤에 연결을 닫지 않고 다음 요청에 재사용한다」는 뜻이고, 이름이 같은 TCP keepalive(유휴 연결이 살아 있는지 확인하는 탐침)와는 다른 기능이다(전송 계층의 「연결이 살아 있는지 확인하기」).

연결을 여는 비용도 왕복이다. TCP 핸드셰이크 1 RTT에 TLS 1.2는 2 RTT를 더했고, TLS 1.3은 1 RTT(재방문은 0-RTT), QUIC은 TCP와 TLS 핸드셰이크를 합쳐 1 RTT(재방문 0-RTT)로 줄였다. 0-RTT 데이터는 재전송·재생(replay) 공격으로 두 번 도착할 수 있어 멱등한 요청에만 쓴다. 연결 수립을 기다리는 동안 필요한 자원을 미리 알리는 일은 103 Early Hints와 preload가 맡는다(리소스 힌트).

HTTP/2가 빠른 이유

HTTP/1.1 시절에는 브라우저가 호스트당 연결을 6개 안팎만 열고 요청마다 무거운 헤더가 반복됐다. 그래서 요청 수를 줄이는 우회법이 성능 최적화의 정석이었다. HTTP/2 이후로는 대부분 필요 없거나 오히려 손해다.

HTTP/2도 TCP 위의 멀티플렉싱이라 패킷 하나가 손실되면 그 연결의 모든 스트림이 기다린다. 이 TCP 수준의 HOL blocking을 없애려고 HTTP/3는 TCP를 버리고 UDP 위의 QUIC으로 옮겼다. QUIC은 구글이 처음 만들어 IETF에서 표준(RFC 9000)으로 다듬었다.

HTTP/3가 UDP를 고른 이유

TCP를 고치지 않고 UDP 위에 새 전송 프로토콜(QUIC)을 올린 데는 이유가 있다.

대신 UDP를 막거나 느리게 다루는 네트워크가 있어, 브라우저는 서버의 Alt-Svc 헤더나 DNS HTTPS 레코드로 HTTP/3 지원을 알아낸 뒤 시도하고, 안 되면 HTTP/2로 돌아간다.

HTTPS는 HTTP를 TLS로 암호화한 것이다(HTTPS와 TLS). 응답 재사용은 HTTP 캐시에 정리했다. 아래에서 받쳐 주는 전송 계층은 전송 계층: 포트, TCP, UDP에 정리했다. 웹 서비스 관점의 요청 흐름과 API 설계는 REST API 설계, 상태를 유지하는 방법은 쿠키와 세션을 참고한다.

핵심 정리

• 요청 = Request Line + Headers + 빈 줄 + Body, 응답 = Status Line + Headers + 빈 줄 + Body.
• HTTP는 Stateless다. 상태는 쿠키·세션·토큰으로 따로 유지한다.
• 상태 코드 앞자리: 1 정보, 2 성공, 3 리다이렉트, 4 클라이언트 잘못, 5 서버 잘못.
• URI ⊃ URL(위치), URN(이름).
• HTTP/1.1·HTTP/2는 TCP 위에서, HTTP/3는 UDP 기반 QUIC 위에서 동작한다.

관련 노트: HTTPS와 TLS, 프록시: 포워드 프록시와 리버스 프록시, RFC와 요구 수준 키워드, REST API 설계, API 아키텍처 스타일