HTTP

성훈·2021년 7월 29일
0

OiMW

목록 보기
8/12
post-thumbnail

HTTP

HTTP는 HyperText Transfer Protocol의 약자로 HTML 문서를 전송하기 위한 Application Layer 프로토콜이다.


무상태성(stateless)

이 HTTP의 대표적인 특징은 무상태성(stateless)이다

무상태성은 말 그대로 상태를 가지고 있지 않다는 뜻으로, HTTP로 클라이언트와 서버가 통신을 주고 받는 과정에서 HTTP가 클라이언트나 서버의 상태를 확인하지 않는다.
유저가 클라이언트로 발생시키는 모든 상태를 추적하지 않기에 정보를 저장하는 등의 상태를 저장하려면 다른 방법(쿠키-세션, API 등)으로 상태를 확인해야 한다.


무연결성(connectionless)

응답이 완료가 되면 클라이언트와 서버의 연결이 끊어지는 특징이다.


HTML Message

HTML 메세지는 클라이언트와 서버 사이 데이터를 주고 받는 방식이며 요청(Requests)과 응답(Responses)으로 나누어진다.

그리고 두 방식은 다음과 같은 구조를 가지고있다.

  • start line - 요청에선 Request Line, 응답에선 Status Line 이라고 한다.
    요청이나 응답의 상태를 나타내며 항상 첫번째 줄에 위치한다.
  • HTTP headers - 요청을 지정하거나 메세지의 본문을 지정하는 Header의 집합이다.
  • empty line - HTTP headers와 body를 구분해주는 빈 선.
  • body - 요청, 응답과 관련된 데이터나 문서를 포함하며 요청, 응답에 따라 사용하지 않을 수도 있다.

여기서 startlineHTTP headers를 합쳐 head라 하고, Payloadbody라 한다.

  • Payload - 전송의 근본적인 목적이 되는 데이터의 일부분으로 그 데이터와 함께 전송되는 헤더와 메타데이터와 같은 데이터는 제외한 데이터이다.

요청 (Requests)

  • Request Line
    Request Line에는 세가지 요소가 있다.
    1. 수행할 작업(CRUD)나 방식을 설명하는 HTTP메소드를 나타낸다.
    2. 요청 대상(URL, URI) 또는 절대경로(프로토콜, 호스트, 포트)는 요청 컨텍스트에 작성되며 이 형식은 메소드에 따라 다르다.
      • origin 형식 - ?와 쿼리 문자열이 붙는 절대 경로이다. 메소드와 함께 사용한다.
        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 버전은 메세지의 다른 구조를 결정하기에 반드시 HTTP 버전을 함께 입력한다.

  • Headers
    요청의 Headers는 대소문자 구분없는 문자열과 값을 입력하며, 콜론으로 구분한다.
    Headers는 세 그룹으로 나눌 수 있다.

  1. General Headers - HTTP 메세지 전체에 적용한다.
  2. Request Headers - User-Agent, Accept-Type, Accept-Language와 같은 Header는 요청을 구체화하며, Referer처럼 컨텍스트를 제공하거나 If-None처럼 조건에 따라 제약을 걸 수도 있다.
  3. Entity Headers - Content-Length와 같은 헤더는 body에 적용된다. 만약 body가 비어있다면 Entity Headers는 전송되지 않는다.

  • Body
    요청의 본문은 메세지의 마지막에 위치하며 POST, PUT 같은 요청에서 데이터를 업데이트하기 위해 사용하며, 나머지 메소드들에선 생략될 수 있다.

    이 Body 역시 두 종류로 나눌 수 있다.

    • Single-resource bodies(단일 리소스 본문) - 헤더 두 개(Content-Type, Content-Length)로 정의된 단일 파일로 구성된다.
    • Multiple-resource bodies (다중 리소스 본문) - 여러 파트로 구성된 본문에서는 각 파트마다 다른 정보를 지니며, 보통 HTML form 과 관련이 있다.

응답 (Responses)

  • State Line
    State Line은 보통 다음 세가지 정보를 포함한다.
  1. 현재 프로토콜의 버전 정보
  2. 상태 코드 - 요청의 결과를 나타낸다.
  3. 상태 텍스트 - 코드에 대한 설명

  • Header
    Header의 경우 요청의 헤더와 동일한 구조를 가지고 있으며 역시 대소문자 없는 문자열과 값을 입력하며 콜론으로 구분한다.
    역시 세가지 그룹으로 나눌 수 있으며 Require Header대신 Response Header로 구분하는 것 말고 큰 차이가 없는데, 여기서 Response Header는 Vary, Accept-Ranges와 같이 상태 줄에 넣기에는 공간이 부족했던 추가 정보를 제공한다.

  • Body
    역시 요청의 Body와 비슷하며 Single-resource bodies가 구분되는 점에서 차이가 있다.
    길이가 알려진 단일 리소스 본문은 요청의 그것과 같이 정의한다.
    그런데, 길이가 알려지지 않은 단일 파일 본문 같은 경우는 Transfer-Encoding이 chucked로 되며, 파일은 chuck으로 나뉘어 인코딩된다.
profile
어떻게 이걸 풀어낼 수 있을까

0개의 댓글