티스토리 뷰
내용 구성
- HTTP 개요
- HTTP Message
- Start Line
a. Request Line
b. Status Line - Header
- Message Body
- 마무리
참고 자료
- https://datatracker.ietf.org/doc/html/rfc7230
- https://developer.mozilla.org/ko/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP
1. HTTP 개요
HyperText Transfer Protocol
HTTP는 클라이언트와 서버가 서로 통신하는 통신 프로토콜입니다. 프로토콜은 쉽게 말하면, 메시지를 주고받는 두 곳에서 미리 어떻게 데이터를 교환하자고 정한 규칙, 약속입니다.
데이터를 주고받는 대부분의 곳에서 HTTP를 사용하고 있습니다. 클라이언트와 서버뿐만 아니라, 서버와 서버끼리 통신할 때도 사용되죠.
HTTP가 전송할 수 있는 데이터 종류도 다양합니다. 초기에는 HTML만 전송할 수 있었지만, 현재는 멀티미디어 (이미지, 음성, 파일, 영상)와 JSON, XML 형태의 데이터까지 가능합니다.
전송 가능 데이터 종류가 점차 다양해지는 것에서 알 수 있듯, HTTP는 진화해 왔습니다. 이 포스팅은 HTTP 메시지 스펙에 관한 내용을 다룰 것이므로, 각 HTTP 버전의 특징은 아래 표로 간단히 넘어가겠습니다.
| 버전 | 특징 | HTTP 요청 메시지 |
| HTTP/0.9 | - GET 요청만 존재 - HTML만 존재하므로 별도의 HTTP Header 없음 |
GET /example.html |
| HTTP/1.0 | - HTTP Header 도입 ⇒ 프로토콜의 유연성 및 확장성 향상 - 상태 코드 도입 ⇒ 브라우저가 요청 성공/실패 여부 확인 가능 |
GET /example.gif HTTP/1.0 User-Agent: NCSA_Mosaic/2.0 (Windows 3.1) |
| HTTP/1.1 | - 표준 프로토콜 | GET /resources/2 HTTP/1.1 Host: www.example.org |
| HTTP/2 | - 성능 개선 - 기존과 달리 이진 프로토콜이라서 사람이 읽을 수 없음 |
|
| HTTP/3 | - 성능 개선 - TCP 대신 UDP 사용 |
2. HTTP Message
RFC-7230에 정의된 HTTP 요청 메시지의 형식입니다. 헤더는 여러 개가 올 수 있으며, 메시지 바디는 상황에 따라 있을 수도, 없을 수도 있습니다.
하나씩 자세히 살펴봅시다.
3. Start Line
클라이언트가 서버에게 전송하는 HTTP 요청 메시지도, 서버가 클라이언트에게 전송하는 HTTP 응답 메시지도, 기본적으로 동일한 형식을 가지고 있습니다. 딱 한 가지 다른 점은 Start Line이죠. Start Line은 HTTP 요청 메시지에서는 Request Line이라고 하며, HTTP 응답 메시지에서는 Status Line이라고 불립니다.
a. Request Line
RFC-7230에 정의된 Request Line의 구성 요소입니다. SP는 Single Space, 띄어쓰기 한 칸이고, CRLF는 개행 문자의 한 종류입니다. 아래는 형식대로 갖춰진 Request Line에 대한 예시입니다.
GET /where?q=now HTTP/1.1
- method
메서드는 클라이언트가 서버에게 수행하도록 요청하는 동작의 종류를 나타냅니다. 아래 표에 있는 메서드 외에 HEAD, CONNECT, OPTIONS, TRACE 메서드가 존재합니다.
| 메서드 | 동작 |
| GET | 자원 조회 |
| POST | 자원 생성 |
| PUT/PATCH | 자원 수정 |
| DELETE | 자원 삭제 |
- request target (요청 타겟)
해당 HTTP 요청 메시지가 전달되는 요청 대상입니다. 총 4가지 형식으로 요청 대상의 경로를 지정할 수 있습니다.
| 종류 | 형식 | 특징 |
| origin form | GET /where?q=now HTTP/1.1 Host: www.example.org |
- 가장 많이 사용되는 방식 |
| absolute form | GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 | - 전체 URI 작성 - 프록시 연결 시 사용 |
| authority form | CONNECT www.example.com:80 HTTP/1.1 | - CONNECT 메서드에서만 사용 |
| asterisk form | OPTIONS * HTTP/1.1 Host: www.example.org:8001 |
- OPTIONS 메서드에서만 사용 - 서버 전체를 나타냄 |
- HTTP Version
HTTP 개요 부분에 있는 HTTP 버전 표를 참고해주세요.
b. Status Line
RFC-7230에 정의된 Status Line의 구성 요소이며, 아래는 Status Line 예시입니다.
HTTP/1.1 200 OK
- status code (상태 코드)
클라이언트 요청에 대한 서버의 처리 결과를 3자리 숫자로 나타냅니다. 상태 코드를 통해 요청의 성공 여부를 확인할 수 있습니다.
| 상태 코드 | 카테고리 | 설명 |
| 1xx | Informational | 요청을 전달 받았고, 현재 진행 중임 |
| 2xx | Successful | 요청이 성공적으로 처리됨 |
| 3xx | Redirection | 요청을 완수하기 위해 더 다른 작업이 필요함 |
| 4xx | Client Error | 클라이언트가 유효하지 않은 요청 전달 |
| 5xx | Server Error | 유효한 요청에 대해 서버가 제대로 처리할 수 없음 |
https://datatracker.ietf.org/doc/html/rfc7231#section-6
- reason phrase (이유 문구)
숫자로 된 상태 코드에 대한 간단한 설명(텍스트)입니다.
4. Header
RFC-7230에 정의된 Header의 형식입니다. 클론(:)을 기준으로 왼쪽에는 field name, 오른쪽에는 field value가 옵니다. 키-밸류 형식이죠.
주의할 점은 field name 이후에 띄어쓰기 없이 곧바로 콜론이 붙는다는 것입니다. 반면 콜론과 field value 사이에는 띄어쓰기를 해도 되고, 안 해도 상관없습니다. OWS가 Optional White Space로, 띄어쓰기를 해도 되고 안 해도 된다는 의미이기 때문입니다.
참고로 field name은 대소문자를 구분하지 않지만, field value는 구분합니다. 아래는 헤더 예시입니다.
Host: www.example.com
Accet-Language: kr
5. Message Body
요청이나 응답의 페이로드를 전달하는 데 사용됩니다. HTML, 이미지, 영상, 파일, JSON 등 바이트로 표현 가능한 모든 데이터가 전송됩니다.
Message Body가 없을 수도 있는데요. 기본적으로 HEAD 메서드는 GET과 동일하지만, 아예 Status Line과 Header만 존재한다고 정의되어 있습니다. 또한 클라이언트와 서버 간 TCP/IP 터널을 설정하는 CONNECT 메서드에 대한 성공 응답 (2xx) 시엔 메시지 본문 대신 터널 모드로 전환됩니다. 그 외 Message Body가 없는 경우는 다음과 같습니다.
- 1xx 응답 시
- 204 No Content 응답 시
- 304 Not Modified 응답 시
위에 언급된 응답을 제외하곤 모두 Message Body를 가지고 있습니다. 그 길이가 0일 수도 있는 것뿐이죠.
6. 마무리
어렴풋이 기억하고 있던 HTTP에 대해 글을 작성하면서 다시 한 번 내용을 정리할 수 있었습니다. 내용이 너무 얕은 것 같은 느낌이 들기도 하지만, 차차 메서드며 TCP며 다룰 기회가 있을 것이라고 기대합니다.
추가로 이번에 처음으로 IETF 공식 도큐먼트도 읽어 보았는데요. SP(Single Space)나 OWP(Optional White Space), CRLF 등을 정확하게 명시하는 것에 놀랐습니다. 어떤 모호함도 없이 프로토콜 표준을 작성하고자 노력한 것이 느껴지는 대목이었네요!