HTTP 메시지

HTTP 메시지 (HTTP/1.1)

• 서버와 클라이언트 간에 데이터가 교환되는 방식
• 요청(request) - 클라이언트 to 서버 / 서버의 액션이 일어나게끔 하는 메시지
• 응답(response) - 요청에 대한 서버의 답변

구조

1. 시작 줄 - 요청, 성공 여부를 한줄로 표현
2. 옵션 - HTTP 헤더 세트 / 요청과 메시지 본문에 대한 설명
3. 빈 줄 - 모든 메타 정보가 전달되었음을 알림
4. 본문 - 요청과 응답에 관련된 문서 / 존재 유뮤는 첫 줄과 헤더에 명시

시작 줄 + 헤더를 합쳐 요청 head라 부르며, 메시지의 페이로드는 body라 부름

요청 (request)

시작 줄

1. HTTP 메소드 - GET, POST, PUT, ,HEAD, OPTIONS 등..
2. 타겟 - URL, 프로토콜, 포트, 절대경로로 나타냄
   • origin 형식 - 쿼리스트링이 붙는 절대경로 / 일반적인 형식 HEAD /test.html?query=alibaba HTTP/1.1
   • absolute 형식 - 완전한 URL 형식 / 프록시에 연결하는 경우 대부분 GET과 함께 사용 GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1
   • authority 형식 - 도메인 이름 및 옵션포트로 이루어진 형식 / HTTP 터널을 구축하는 경우에만 CONNECT와 함께 사용 developer.mozilla.org:80 HTTP/1.1
   • asterisk 형식 - OPTIONS과 함께 사용하며 *로 서버 전체를 나타냄 OPTIONS * HTTP/1.1
3. HTTP 버전

헤더

• 대소문자 구분없는 문자열 + 콜론 + a
• 한 줄로 구성되어있으며, 길어질 수 있음

1. General header - Via와 같은 헤더는 메시지 전체에 적용
2. Request header - User-Agent, Accept-Type 과 같은 헤더로 요청의 내용을 구체화하고, 컨텍스트를 제공하며, 조건에 따른 제약을 걸 수 있음
3. Entity header - 본문이 있을 경우 Content-Length와 같은 entity에 대한 설명

본문

• 요청의 마지막 부분에 들어가며, 모든 요청에 들어가지는 않음
• 일반적으로 데이터를 업데이트를 하는 요청에 포함됨 (POST)

두 가지 종류

1. single-resource bodies - 헤더(Content-Type, Content-Length)로 정의된 단일 파일 구성
2. multiple-resource bodies - 멀티파트 본문 / HTML Form과 관련되어 있으며 파트마다 다른 정보로 구성

응답 (response)

시작 줄

• 응답의 시작 줄(start line)은 상태 줄(status line)이라 불림

1. 프로토콜 버전
2. 상태 코드 - 요청의 성공 여부 (200, 404, 302)
3. 상태 텍스트 - 코드에 대한 짧은 설명

HTTP/1.1 404 Not Found.

헤더

• 요청의 헤더와 같은 형식

1. General header - Via와 같은 헤더는 메시지 전체에 적용
2. Response header - Vary, Accept-Ranges와 같은 헤더는 상태 줄에 들어가지 못한 서버에 대한 추가 정보 제공
3. Entity header - 본문이 있을 경우 Content-Length와 같은 entity에 대한 설명

본문

• 응답의 마지막 부분에 들어가며, 모든 응답에 들어가지는 않음(201, 204 같은 경우)

세 가지 종류

1. 길이가 알려진 단일 파일 단일 리소스 본문
   • 헤더 두개로 정의
2. 길이를 모르는 단일 파일 단일 리소스 본문
   • 파일이 청크로 나뉘어 인코딩 되어있음
3. 멀티파트 다중 리소스 본문

HTTP/2 프레임

HTTP/1.x의 단점

• 본문은 압축이 되지만 헤더는 압축이 되지 않음
• 연속된 메시지에서 비슷한 헤더 구조임에도 반복해서 전송
• 다중 전송(multiplexing)이 불가능, 서버 하나에 여러개의 TCP 연결이 필요

개선 방안

메시지를 프레임으로 나누어 스트림에 끼워넣으면서, 이를 통해 데이터와 헤더 프레임을 분리시켜 헤더를 압축시킬 수 있으며, 스트림 여러개를 묶을 수 있어(multiplexing) 효율적인 TCP 연결이 가능

결론

HTTP/1.x 에서 설계된 단순하고 확장성이 좋은 HTTP 메시지 구조를 HTTP/2 프레이밍을 통해 구문 사이에 새로운 중간 단계가 추가시키는 매커니즘으로, 이미 입증된 기존 구조를 발전시켰음.

출처: MDN