HTTP 메시지
HTTP 메시지에는 요청(request) 메시지 와 응답(response) 메시지가 있다.
HTTP 요청 메시지 (request)
요청 메시지는 1행의 리퀘스트 라인, 여러 HTTP 헤더로 구성된 메시지 헤더, 공백, 메시지 바디 로 구성된다.
리퀘스트의 헤더는 리퀘스트 헤더, 일반 헤더, 엔티티 헤더, 기타 헤더 의 4개 HTTP 헤더 중 하나로 구성되어 있고 어떤 HTTP 헤더로 구성되는지는 웹브라우저에 따라 다르다.
헤더는 '<field-name>:<field-value>' 으로 구성된다
1. start line 스타트 라인 (요청메시지: request line 리퀘스트 라인)
클라이언트가 서버에 처리를 요청하기 위한 행이다. 요청 메시지에만 존재하는 행이다.
1.1. method (메소드)
리퀘스트(요청) 의 종류를 나타낸다.
GET /search?q=네트워크&hl=ko HTTP/1.1
Host: www.google.com
◾메소드 종류
| 메소드 | 내용 | 버전 |
| GET | 서버로부터 데이터 취득 | HTTP/0.9~ |
| POST | 서버로 데이터 전송 | HTTP/1.0~ |
| PUT | 서버로 로컬 데이터 전송 | HTTP/1.1~ |
| PATCH | 리소스의 부분 수정 | HTTP/1.1~ |
| DELETE | 특정 리소스 삭제 | HTTP/1.1~ |
| HEAD | 메시지 헤더만 취득 | HTTP/1.0~ |
| OPTIONS | 서버가 지원하는 메소드나 옵션을 확인 | HTTP/1.1~ |
| TRACE | 서버로의 경로 확인 | HTTP/1.1~ |
| CONNECT | 프록시 서버에 터널링 요청 | HTTP/1.1~ |
1.2. request URI (리퀘스트 URI)
리소스 식별자를 나타낸다. URI 포맷에는 리소스에 액세스하기 위해 필요한 정보를 모두 기술하는 절대 URI , 기준이 되는 URI 로부터의 상대적인 위치를 나타내는 상대 URI 가 있다.
◾절대 경로 (Absolute-path[?query]) : "/" 으로 시작하는 경로
GET /search?q=네트워크&hl=ko HTTP/1.1
Host: www.google.com
1.3. HTTP version (HTTP 버전)
HTTP 버전을 나타낸다.
GET /search?q=네트워크&hl=ko HTTP/1.1
Host: www.google.com
2. 메시지 헤더 (message header)
2.1. 리퀘스트 헤더 (Request Header)
메시지 헤더 중에서도 리퀘스트 메시지를 제어하기 위한 헤더를 리퀘스트 헤더라 한다.
◾RFC2616에 정의된 리퀘스트 헤더
| 헤더 | 설명 |
| Accept | 텍스트 파일이나 동영상 파일 등 웹브라우저가 받을 수 있는 미디어 타입 |
| Accept-Charset | Unicode 나 ISO 등 웹브라우저가 처리할 수 있는 문자열 |
| Accept-Encoding | gzip , compress 등 웹브라우저가 처리할 수 있는 메시지 바디 압축 타입 |
| Accept-Language | 웹브라우저가 처리할 수 있는 언어셋 |
| Expect | 송신하는 리퀘스트의 메시지 바디가 클 때, 서버가 받을 수 있는지 확인 |
| From | 사용자의 메일 주소, 연락처를 전달하기 위해 사용 |
| Host | 웹브라우저가 요청하는 웹서버의 도메인 이름 (FQDN) 과 포트번호 HTTP/1.1 에서 필수 항목 헤더 * FQDN (Fully Qualified Domain Name) : 전체 주소 도메인 이름 |
| Referer | 직전에 링크되었던 URL (예) 구글에서 검색했을 경우, https://www.google.com/ → 웹서버의 액세스 로그에 기록/분석하여 세일즈 프로모션등의 전략 수립 가능 |
| User-Agent | 웹브라우저 정보 사용자의 환경을 나타내는 헤더 → 사용자가 이용하는 웹브라우저의 종류, 버전, OS 등을 분석하여 웹사이트의 콘텐츠를 최적화 하는데 이용 가능 |
※ 참고로 Referer , User-Agent 등의 헤더를 곧이곧대로 믿는 것은 위험하다. 각종 디버깅 도구나, 웹브라우저 확장 기능으로 간단하게 변조가능한 데이터이기 때문이다. 따라서 참고로 이용하는 것이 좋다.
※ 위에 기술된 이외의 헤더도 존재한다.
2.2 일반 헤더 (General Header)
리퀘스트 메시지, 리스폰스 메시지 모두에서 범용으로 사용하는 헤더
◾RFC2616에 정의된 일반 헤더
| 헤더 | 내용 |
| Cache-Control | 웹브라우저에 일시적으로 보존하는 캐시 제어, 캐시를 하지 않는 또한 캐시를 하는 시간을 설정할 수 있음 프라이빗 캐시(private cache) : 주로 웹브라우저에 저장 공유 캐시(shared cache) : 프록시 서버나 CDN의 에지 서버에 저장 |
| Connection (Keep-Alive) |
keep-alive (지속적 연결) 를 제어하는 헤더 keep-alive 에 대응하는 것을 알리고, TCP 커넥션을 클로즈할 때 사용 브라우저가 keep-alive 설정하여 요청하면, 웹서버도 마찬가지로 keep-alive 를 설정하여 응답한다. |
| Date | HTTP 메시지를 생성한 일시 |
| Pragma | 캐시에 관해 HTTP/1.0 과의 하위 호환성을 목적으로 사용 |
| Trailer | 메시지 바디의 뒤에 기술하는 HTTP 헤더를 알림. 청크(chunk) 전송 인코딩을 사용할 때 사용 가능 |
| Transfer-Encoding | 메시지 바디의 전송 코딩 타입 |
| Upgrade | 다른 프로토콜 또는 다른 버전으로 전환 |
| Via | 경유한 프록시 서버를 추가로 기술. 루프 회피를 목적으로 사용 |
| Warning | HTTP 메시지에 반영되지 않은 스테이터스나 메시지의 변화에 관한 추가 정보 |
※ 위에 기술된 이외의 헤더도 존재한다.
2.3. 엔티티 헤더 (Entity Header)
리퀘스트 메시지와 리스폰스 메시지에 포함되는 메시지 바디에 관련한 제어 정보를 포함하는 헤더
◾RFC2616에 정의된 엔티티 헤더
| 헤더 | 내용 |
| Allow | 서버가 클라이언트에게 대응하는 메소드를 알림 |
| Content-Encoding | 서버가 실행한 메시지 바디의 압축 타입 |
| Content-Language | 메시지 바디에 사용된 언어셋 |
| Content-Length | 메시지 바디 크기. 바이트 단위 HTTP/1.1 에서는 Keep-Alive 으로 하나의 커넥션를 사용하는 경우가 있기 때문에 반드시 TCP 커넥션이 클로즈 된다고 단언할 수 없다. 따라서 Content-Length 로 메시지길이를 확인해줘야 한다. |
| Content-Location | 메시디 바디의 URI |
| Content-Type | 텍스트 파일이나 이미지 파일 등 메시지 바디의 미디어 타입 |
| Expires | 리소스의 유효기간 일시 |
| Last-Modified | 리소스가 가장 마지막으로 업데이트 된 일시 |
※ 위에 기술된 이외의 헤더도 존재한다.
2.4. 기타 헤더
주요한 헤더로 분류되지는 않지만, 자주 사용하는 헤더
◾기타 헤더
| 헤더 | 내용 |
| Set-Cookie | 서버가 세션 관리에 사용하는 세선 ID나 사용자 개별 설정 등을 웹브라우저로 전송 웹브라우저가 로그인에 성공하면 서버는 세션 ID 를 발행하고 Set-Cookie 헤더에 설정해서 응답. 그뒤 요청은 Cookie 헤더에 세션 ID를 설정해서 수행한다. |
| Cookie | 웹브라우저가 Set-Cookie 를 통해 주어진 Cookie 정보를 서버에 전송 |
| X-Forwarded-For | 부하 분산 장치로 NAPT 되는 환경에서 변환 전의 IP 주소를 저장 어느 IP 주소로부터 액세스되었는지 특정할 수 있다. |
| X-Forwarded-Proto | 클라이언트가 사용하고 있는 프로토콜을 저장. 부하 분산 장치에서 SSL 오프로드하는 환경 등에서, 원 프로토콜(HTTP 또는 HTTPS) 를 특정할 때 사용 |
※ Cookie (쿠키) : HTTP 헤더와의 통신에서 특정한 정보를 브라우저에 저장시키는 구조 및 저장한 파일. 웹브라우저상에서 FQDN별로 관리된다.
3. CRLF 공백 (\r\n)
4. 메시지 바디 (message body)
실제로 보내는 데이터가 들어있는 필드이다. 메시지 바디는 옵션사항이므로 메소드에 따라 있거나 없을 수 있다.
정리
위의 내용은 HTTP/1.1 의 HTTP 메시지이다.
HTTP/1.1 은 헤더와 메시지 바디를 줄바꿈 (CRLF) 로 구분한 텍스트 형식의 메시지 단위로 TCP 커넥션으로 보낸다. 텍스트형식은 사람이 이해하기 쉽지만, 컴퓨터는 바이너리 형식으로 변환 처리가 필요하다.
HTTP/2 의 메시지 포맷
HTTP/2 는 메시지 헤더를 HEADERS 프레임 (HEADERS frame) 에, 메시지 바디를 DATA 프레임 (DATA frame) 에 각각 분할해서 저장하고 바이너리 형식의 프레임 단위로 스트림에 보낸다. 그때 프레임에 스트림을 식별하는 스트림 ID (stream ID) 를 부여한다. 즉 바이너리 형식이므로 변환 처리가 필요없어진다. 이렇게 하면 헤더를 압축할 수 있고(헤더압축), 스트림 여러개를 하나로 묶을 수 있게 된다.(멀티플렉싱)
1. HEADERS frame 헤더 프레임
HTTP/2 는 바이너리 형식으로 변경되면서 요청 메시지의 리퀘스트 라인도 헤더로 취급한다.
HTTP/1.1 의 리퀘스트 라인을 다음과 같이 저장한 뒤 HEADERS 프레임으로 송신한다.
- 메소드 → :method
- 리퀘스트 URI → :path
- HTTP 버전 → :version
◾HTTP/2 의 리퀘스트 메시지 포맷
