HTTP 메시지

HTTP 메시지

HTTP 메시지는 서버와 클라이언트 간에 데이터가 교환되는 방식이다. 메시지의 타입은 요청(request)와 응답(response)로 나뉘어진다.

메시지 특징

• ASCII로 인코딩된 텍스트 정보이며 여러 줄로 되어 있다.
• HTTP 초기와 HTTP1.1의 메시지는 사람이 읽을 수 있었지만, HTTP/2에서는 최적화와 성능 향상을 위해 HTTP 프레임으로 나누어졌다.
• HTTP 메시지는 개발자 대신 소프트웨어, 브라우저, 프록시 혹은 웹 서버가 대신 작성해준다. 프록시, 서버의 경우 설정 파일을 통해, 브라우저의 경우 API 혹은 다른 인터페이스를 통해 제공된다.

HTTP/2의 binary framing 매커니즘은 사용 중인 API나 설정 파일을 변경하지 않아도 되도록 설계되었기 때문에 사용자가 이해하기 쉽다.

HTTP 요청과 응답의 구조

• start-line: 실행되어야 할 요청, 요청 수행에 대한 결과
• option: HTTP 헤더 세트: 요청에 대한 설명, 메시지 본문에 대한 설명
• 빈 줄(blank line): 요청에 대한 모든 메타 정보가 전송되었음을 알린다.
• 요청과 관련된 내용, 응답과 관련된 문서 등이 옵션으로 들어간다.
  • 본문의 존재 유무 및 크기는 HTTP 헤더에 명시된다.

HTTP Request 구조

start line

• HTTP 메서드(GET, POST, PUT, HEAD, OPTIONS)
• 요청 타겟
  • origin 형식
    • 끝에 ?와 문자열이 붙는 절대 경로로, 가장 일반적인 형식이다.
    • GET, POST, HEAD, OPTIONS 메서드와 함께 사용한다.
  • absolute 형식
    • 완전한 URL 형식
    • 프록시에 연결하는 경우 GET과 함께 사용
  • authority 형식
    • 도메인 이름 및 옵션 포트로 이루어진 URL의 authority component
    • HTTP 터널을 구축하는 경우 CONNECT와 함께 사용
  • asterisk 형식
    • OPTIONS와 함께 *로 간단하게 서버 전체를 나타낸다
    • OPTIONS * HTTP/1.1
• HTTP 버전

Header

• General Header
  • 메시지 전체에 적용
  • Via
• Request Header
  • User-Agent, Accept-Type과 같은 헤더는 요청의 내용을 좀 더 구체화시키고(Accept-Language), 컨텍스트를 제공하기도 하며 (Referer), 조건에 따른 제약 사항을 가하기도 하면서(If-None) 요청 내용을 수정
• Entity Header
  • Content-Length와 같은 헤더는 요청 본문에 적용된다.

Body

본문(Body)는 있을 수도 있고, 없을 수도 있다. 리소스를 가져오는 요청은 본문이 필요 없지만 POST처럼 서버에 데이터를 전송하는 요청은 본문이 있다.

• 단일-리소스 본문(single-resource bodies)
• 다중-리소스 본문(multiple-resource bodies)

HTTP 응답

status line

• 예) HTTP/1.1 404 Not Found

• 프로토콜 버전, 상태 코드, 상태 텍스트로 구성되어 있다.

Header

응답 메시지 헤더와 마찬가지로 종류가 General Header, Response Header, Entity Header로 나뉘어진다.

Body

요청과 마찬가지로 모든 응답에 본문이 들어가지는 않는다. 201, 204와 같은 상태 코드를 가진 응답에는 보통 본문이 없다. 본문은 다음 세 가지로 나누어진다.

• 길이를 아는 단일-리소스 본문(single-resource bodies)
• 길이를 모르는 단일-리소스 본문
  • Transfer-Encoding이 chunked로 설정되어 있으멷, 파일은 청크로 나뉘어 인코딩되어 있다.
• 다중-리소스 본문(multiple-resource bodies)

HTTP/2 프레임

HTTP/1.x 메시지의 성능상의 결함

• 본문과 달리 header는 압축이 되지 않는다.
• 연속된 메시지는 비슷한 header 구조를 띄지만, 메시지마다 반복되어 전송된다.
• 다중 전송(multiplexing)이 불가능
  • 비효율적인 codl TCP 연결 사용: 서버 하나에 연결을 여러 개 열어야 한다.

HTTP/2

• HTTP/1.x 메시지를 프레임으로 나누어 스트림에 끼워 넣는다.

• 데이터와 헤더 프레임이 분리되었기 때문에 헤더를 압축할 수 있다.

• 스트림 여러개를 하나로 묶을 수 있어서 기저에 수행되는 TCP 연결이 좀 더 효율적으로 이루어진다.

출처

https://developer.mozilla.org/ko/docs/Web/HTTP/Messages