HTTP 메세지

HTTP 메시지는 서버와 클라이언트 간에 데이터가 교환되는 방식입니다.

요청(request) 서버로 전달하는 메세지

응답(response) 요청에 대한 서버의 답변

 

HTTP 메시지는 ASCII로 인코딩된 텍스트 정보이며 여러 줄로 되어 있습니다

웹 개발자, 또는 웹 마스터가 손수 HTTP 메시지를 텍스트로 작성하는 경우는 드뭅니다. 대신에 소프트웨어, 브라우저, 프록시, 또는 웹 서버가 그 일을 합니다. HTTP 메시지는 설정 파일(프록시 혹은 서버의 경우), API(브라우저의 경우), 혹은 다른 인터페이스를 통해 제공됩니다.

HTTP/2의 이진 프레이밍 메커니즘(binary framing mechanism)은 사용 중인 API나 설정 파일 등을 변경하지 않아도 되도록 설계 되었기 때문에, 사용자가 보고 이해하기 쉽습니다.

HTTP 요청과 응답의 구조는 서로 닮았으며, 그 구조는 다음과 같습니다.

1. 시작 줄(start-line)에는 실행되어야 할 요청, 또은 요청 수행에 대한 성공 또는 실패가 기록되어 있습니다. 이 줄은 항상 한 줄로 끝납니다.
2. 옵션으로 HTTP 헤더 세트가 들어갑니다. 여기에는 요청에 대한 설명, 혹은 메시지 본문에 대한 설명이 들어갑니다.
3. 요청에 대한 모든 메타 정보가 전송되었음을 알리는 빈 줄(blank line)이 삽입됩니다.
4. 요청과 관련된 내용(HTML 폼 콘텐츠 등)이 옵션으로 들어가거나, 응답과 관련된 문서(document)가 들어갑니다. 본문의 존재 유무 및 크기는 첫 줄과 HTTP 헤더에 명시됩니다.

시작 줄과 http헤더를 묶어서 요청 head라고부른다 이와 반대로 http 메세지의 페이로드는 body라고한다

HTTP 요청

Start line

1.HTTP 매소드가 들어가는공간이다 (GET, PUT, POST)혹은 명사(HEAD,OPTIONS)를 사용해 서버가 사용해야 할동작을 나타낸다. GET은 리소스를 손님에게 가져가라라는뜻이며 POST는 데이터가 서버로 들어가야하는걸 의미한다(리소스를 생성,수정, 돌려보낼 임시문서를 생성)하기위해사용

2.주로 URL이 요청타겟이며 프로토콜, 포트, 도메인의 절대로 경로로 나타낼수있다. 

• origin 형식: 끝에 '?'와 쿼리 문자열이 붙는 절대 경로입니다. 이는 가장 일반적인 형식이며, GET, POST, HEAD, OPTIONS 메서드와 함께 사용합니다.
  POST / HTTP 1.1
  GET /background.png HTTP/1.0
  HEAD /test.html?query=alibaba HTTP/1.1
  OPTIONS /anypage.html HTTP/1.0
• absolute 형식: 완전한 URL 형식입니다. 프록시에 연결하는 경우 대부분 GET과 함께 사용됩니다.
  GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1
• authority 형식: 도메인 이름 및 옵션 포트(':'가 앞에 붙습니다)로 이루어진 URL의 authority component 입니다.​​​​ HTTP 터널을 구축하는 경우에만 CONNECT와 함께 사용할 수 있습니다.
  CONNECT developer.mozilla.org:80 HTTP/1.1
• asterisk 형식: OPTIONS와 함께 별표('*') 하나로 간단하게 서버 전체를 나타냅니다. ​​​​​
  OPTIONS * HTTP/1.1

3.마지막으로는 HTTP 버젼이 들어감!

Header

헤더가들어가는 이미지임

요청에 들어가는 HTTP 헤더는 HTTP 헤더의 기본 구조를 따릅니다. 대소문자 구분없는 문자열 다음에 콜론(':')이 붙는다.

• General 헤더: Via와 같은 헤더는 메시지 전체에 적용됩니다.
• Request 헤더: User-Agent (en-US), Accept-Type와 같은 헤더는 요청의 내용을 좀 더 구체화 시키고(Accept-Language), 컨텍스를 제공하기도 하며(Referer), 조건에 따른 제약 사항을 가하기도 하면서(If-None) 요청 내용을 수정합니다.
• Entity 헤더: Content-Length와 같은 헤더는 요청 본문에 적용됩니다. 당연히 요청 내에 본문이 없는 경우 entity 헤더는 전송되지 않습니다.

 

Body

본문은 요청의 마지막 부분에 들어갑니다. 모든 요청에 본문이 들어가지는 않습니다. GET, HEAD, DELETE , OPTIONS처럼 리소스를 가져오는 요청은 보통 본문이 필요가 없습니다. 일부 요청은 업데이트를 하기 위해 서버에 데이터를 전송합니다. 보통 (HTML 폼 데이터를 포함하는) POST 요청일 경우에 그렇습니다.

• 단일-리소스 본문(single-resource bodies): 헤더 두 개(Content-Type와 Content-Length)로 정의된 단일 파일로 구성됩니다.
• 다중-리소스 본문(multiple-resource bodies): 멀티파트 본문으로 구성되는 다중 리소스 본문에서는 파트마다 다른 정보를 지니게 됩니다. 보통 HTML 폼과 관련이 있습니다.
  
  

HTTP 응답(Response)

Status line

1. 프로토콜 버전: 보통 HTTP/1.1입니다.
2. 상태 코드: 요청의 성공 여부를 나타냅니다. 200, 404 혹은 302입니다.
3. 상태 텍스트: 짧고 간결하게 상태 코드에 대한 설명을 글로 나타내어 사람들이 HTTP 메시지를 이해할 때 도움이 됩니다.

상태 줄은 일반적으로  HTTP/1.1 404 Not Found. 같이 생겼습니다.

 

Header

• General 헤더: Via와 같은 헤더는 메시지 전체에 적용됩니다.
• Response 헤더: Vary와 Accept-Ranges와 같은 헤더는 상태 줄에 미처 들어가지 못했던 서버에 대한 추가 정보를 제공합니다.
• Entity 헤더: Content-Length와 같은 헤더는 요청 본문에 적용됩니다. 당연히 요청 내에 본문이 없는 경우 entity 헤더는 전송되지 않습니다.

Body
모든 응답(reponse)이 body에 꼭 들어가지는 않습니다.

1.길이가 정해진 단일 파일로 구성된 리소스본문(Contentp-Type),(Content-Length)로 정의

2.길이를 모르는 단일파일로 구성된 단일 리소스본문(Transfer-Encoding)은 chunked 가 설정, 파일은 청크로 나뉘어 인코딩되어 있습니다.

 

HTTP/2 프레임

 

 

TTP/1.x 메시지는 성능상의 결함을 몇가지 내포하고 있습니다.

• 본문은 압축이 되지만 헤더는 압축이 되지 않습니다.
• 연속된 메시지들은 비슷한 헤더 구조를 띄기 마련인데, 그럼에도 불구하고 메시지마다 반복되어 전송되고 있습니다.
• 다중전송(multiplexing)이 불가능합니다. 서버 하나에 연결을 여러개 열어야 합니다. 적극적인(warm) TCP 연결이 소극적인(cold) TCP 연결보다 효율적인데 말이죠.

 이러한 결함을 버전2에서는 HTTP/1.x 메시지를 프레임으로 나누어 스트림에 끼워 넣는과정을 통해 데이터와 헤더 프레임이 분리 되었기 때문에 헤더를 압축할 수 있습니다. 스트림 여러개를 하나로 묶을 수 있어서(이러한 과정을 멀티플렉싱이라 합니다), 기저에서 수행되는 TCP 연결이 좀 더 효율적이게 이루어집니다.

 

요약

HTTP 메세지는 매우 단순한구조이며 HTTP에서 핵심적인 역할을 한다.주로 봐야할부분은 Request와 Response의 Status line 과 Header부분을 주로 살펴보면된다스테이터스 라인은 명령을하고 헤더는 정보를 보여준다고 생각하자