DevOps/DevOps

HTTP Message 구성 및 특징

chanstory 2022. 12. 8. 18:07
반응형

HTTP - Hyper Text Transfer Protocol

- HTML과 같은 문서를 전송하기 위한 응용계층 프로토콜 이다.

- 웹 브라우저와 웹 서버의 통신에 사용됨 (서버와 클라이언트가 HTTP Messages 양식에 맞춰 요청 및 응답 실시)

- HTTP는 특정 상태를 유지하지 않는 특징이 있다. (Stateless : 무상태성)

 

HTTP Messages

- HTTP Message는 요청(Requests) 과 응답(Responses)으로 구성되어 있다.

- 구성파일, API (Application Programming Interface), 기타 인터페이스에서 HTTP Messages를 자동으로 생성한다.

 

HTTP Messages 구조

요청과 응답은 서로 유사한 구조를 갖는다.

- Start Line(요청), Status Line(응답) : 요청이나 응답의 상태를 나타낸다.

- HTTP Headers : 요청을 지정하거나 멤시지에 포함된 본문을 설명하는 헤더의 집합

- Empty Line : 헤더와 본문을 구분하는 빈 줄

- Body : 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함 (요청과 응답 유형에 따른 선택적 사용)

 

Start Line과 HTTP Headers를 묶어 요청이나 응답의 헤드(head)라고 하고, payload는 body라고 한다.

 

 

 

 

요청 (Requests)

 

* Start Line (클라이언트가 서버에게 보내는 메시지)
  1. GET, PUT, POST, DELETE 등 수행될 작업이나 방식을  설명하는 method가 있다.

      (GET = 리소스 받기, POST = 리소스 전송)

  2. 요청 대상 (URL, URI) 또는 프로토콜, 포트, 도메인의 절대경로는 요청 컨텍스트에 작성됨 (HTTP method 마다 다름)

      - origin 형식 :  ? 와 쿼리 문자열이 붙는 절대 경로 (POST, GET, HEAD, OPTIONS 등의 메소드와 함께 사용)

     - absolute 형식 : 완전한 URL 형식, 프록시에 연결하는 경우 대부분 GET method와 함께 사용함.
        (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 버전에 따라 HTTP messages의 구조가 달라진다. (Start Line에 HTTP 버전 함께 입력)

 

* Header (요청 지정, 메시지 본문 설명 헤더 포함)

 1. 요청의 헤더는 기본 구조를 따른다. 

     헤더이름 (대소문자 구분 X) -> 콜론(:) -> 입력 값      // 값은 헤더에 따라 다르다.

 

     - Request headers : fatch 를 통해 가져올 리소스 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더

     - General headers : 메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와는 관련이 없는 헤더

     - Representation headers (Entity headers) : body에 담긴 리소스의 정보(컨텐츠 길이, MIME타입 등)를 포함하는 헤더

 

* body (모든요청에 필요한건 아님)

  1. GET, HEAD, DELETE, OPTIONS 처럼 서버에 리소스를 요청하는 경우에는 본문이 필요하지 않다.

  2. POST나 PUT과 같은 일부 요청은 데이터 업데이트를 위해 사용 

 

     - Single-resource bodies (단일-리소스 본문) : 헤더 두 개(Content-Type 과 Content-Length)로 정의된 단일 파일로 구성된다.

     - Multiple-resource bodies (다중-리소스 본문) : 여러 파트로 구성된 본문에서는 각 파트마다 다른 정보를 지닌다.

 

응답 (Responses)

 

* Status Line (상태 표시)

  1. 현재 프로토콜의 버전 (HTTP/1.1)

  2. 상태 코드 - 요청의 결과 (200, 302, 404 등  =>  100번 대 마다 요청의 결과에 대한 정보가 다름)

  3. 상태 텍스트 - 상태 코드에 대한 설명

 

* Headers Line (요청과 동일한 구조)

  - General headers : 메시지 전체에 적용, body를 통해 전송되는 데이터와 관련 없는 헤더

  - Response headers : 위치 또는 서버 자체에 대한 정보 (이름, 버전 등)와 같이 응답에 대한 부가적 정보를 갖는다.

                                        Vary, Accept-Ranges와 같이 상태 줄에 넣기에는 공간이 부족했던 추가 정보 제공

  - Representation headers Entity headers) : body에 담긴 리소스의 정보 (컨텐츠의 길이, MIME 타입 등)를 포함

 

* body (모든 응답에 필요한건 아님)

  1. 201,204와 같은 상태 코드를 가지는 응답에는 본문이 필요하지 않음

     

     - Single-resource bodies (단일-리소스 본문)

         -> 길이가 알려진 단일-리소스 본문은 두 개의 헤더 (Content-Type, Content-Length)로 정의 한다.

         -> 길이가 모르는 단일 파일로 구성된 단일-리소스 본문은 Transfer-Encoding이 chunked로 설정되어 있다.

              (파일은 chunk로 나뉘어 인코딩 되어있음 - 각 chunk 마다 길이가 적혀있다.)

     - Multuple-resource bodies (다중-리소스 본문)

         -> 서로 다른 정보를 담고 있는 body 이다.

 

 

 

*** Stateless (상태를 가지지 않는다.)

 - HTTP 통신 중 클라이언트나 서버의 상태를 확인하지 않는다. HTTP는 프로토콜일 뿐 상태를 저장하진 않음

 - 필요에 따라 쿠키-세션, API 등을 통해 상태를 확인할 수 있다. 

 

반응형