TIL 7주차 4일 - HTTP/네트워크 기초(2)

HTTP

• HTTP : HyperText Transfer Protocol

• HTML 과 같은 문서를 전송하기 위한 Application Layer 프로토콜

• 웹 브라우저와 웹 서버의 소통을 위해 디자인 되었음.

• 클라이언트가 HTTP messages 양식에 맞춰 요청을 보내면, 서버도 HTTP messages 양식에 맞춰 응답합니다.

• HTTP는 특정 상태를 유지하지 않는 특징이 있습니다. (Statelee : 무상태성)

• 무상태성 : 클라이언트의 상태 , 서버의 상태를 확인하지 않는다.
  왜?? 하나의 서버로 다수의 클라이언트에 대응하기 위하여 사용한다.

1. HTTP messages

• mdn 설명
  https://developer.mozilla.org/ko/docs/Web/HTTP/Messages

• 클라이언트와 서버 사이에서 데이터가 교환되는 방식
  두 가지 유형 : 1) 요청(requests), 2) 응답(response)
  

1.1 문서의 구조

• start line

  1. 실행되어야 할 요청, 또는 요청 수행에 대한 성공 또는 실패가 기록되어 있습니다.

  2. 항상 한줄로 첫 번쨰 줄에 위치합니다.

  3. 응답에서는 status line 이라고 부릅니다.

• HTTP headers

  1. 요청에 대한 설명, 메시지 본문을 설명하는 헤더의 집합입니다.

  2. start line 과 HTTP headers 를 묶어 응답의 헤드(HEAD)라고 부릅니다.

• empth line : 헤더와 본문을 구분하는 빈 줄이 있습니다.

• body

  1. 요청에 관련된 내용이 옵션으로 들어가거나

  2. 응답과 관련된 데이터 또는 문서를 포함합니다.

  3. 요청과 응답의 유형에 따라 선택적으로 사용합니다.

2. 요청 (Request)

• HTTP 요청은 클라이언트가 서버에 보내는 메시지입니다.

2.1 start line

• 세 가지 요소가 있습니다.

• 첫쨰로 메서드를 기입하여 수행 할 작업(동사, get, put, post 등)이나 방식(명사, HEAD or OPTIONS)을 사용해 서버가 수행해야 할 동작을 나타냅니다.
  예를 들어 GET method는 리소스(데이터)를 클라이언트로 가져다 달라는 것을 뜻하며, POST method는 데이터를 서버로 전송합니다.

• 둘쨰로 요청 대상(일반적으로 URL 이나 URI) 또는 프로토콜, 포트, 도메인의 절대 경로로 나타낼 수도 있으며 이들은 요청 컨텍스트에 작성됩니다.
  이 요청 형식은 HTTP method 마다 다릅니다.

  1. origin 형식 : ? 와 쿼리 문자열이 붇는 절대 경로 입니다.
  2. absolute 형식 : 완전한 URL 형식으로, 프록시에 연결하는 경우 대부분 GET method와 함께 사용합니다.
  3. authority 형식 : 도메인의 이름과 포트 번호로 이루어진 URL의 authority component 입니다.
  4. asterisk 형식 : OPTIONS 와 함께 별표(*) 하나로 서버 전체를 표현합니다.
     

• 셋째로 HTTP 버전이 들어갑니다.
  HTTP 버전은 메시지의 다른 구조를 결정합니다. 이를 위해 HTTP 버전을 함께 입력합니다.

2.2 Headers

• 요청의 Headers는 기본 구조를 따릅니다.
  대소문자 구분 없는 문자열과 콜론(:), 값을 입력합니다.
  예시) 헤더 : 값

• 값은 헤더에 따라 다르며 값까지 포함해 한줄로 구성되지만 꽤 길어질 수 있습니다.

• 다양한 종류의 헤더가 있는데, 이들은 다음과 같이 몇몇 그룹으로 나눌 수 있습니다.

  1. General Headers : 메시지 전체에 적용 됩니다.
     예시) via

  2. Request Headers : User-Agent, Accept-Type, Accept-Language 과 같은 헤더는 요청을 보다 구체화합니다. Referer처럼 컨텍스트를 제공하거나
     If-None 과 같이 조건에 따라 제약을 추가하는 등 요청 내용을 수정합니다.

  3. Entity Headers : Content-Length와 같은 헤더는 body에 적용됩니다. body가 비어있는 경우. Entity Headers는 전송되지 않습니다.

2.3 body

• 요청의 본문(body)은 HTTP messages 구조의 마지막에 위치합니다. 모든 요청에 body가 필요하지는 않습니다.

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

• POST나 PUT과 같은 일부 요청은 데이터를 업데이트하기 위해 사용합니다.

• body는 다음과 같이 두 종류로 나눌 수 있습니다.

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

  2. Multiple-resource bodies(다중-리소스 본문)
     여러 파트로 구성된 본문에서는 각 파트마다 다른 정보를 지닙니다.
     보통 HTML form과 관련이 있습니다.

3. 응답 (Request)

3.1 status line(상태 줄)

• 응답의 첫 줄은 Status line 이라고 부르며, 다음의 정보를 포함합니다.

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

  2. 상태 코드 - 요청의 성공 여부를 나타냅니다.(200,302,404등)

  3. 상태 텍스트 - 짧고 간결하게 상태 코드에 대한 설명을 글로 나타내어 HTTP 메시지를 이해할 때 도움이 됩니다.
     예시) HTTP/1.1 404 Not Found.
     

3.2 Headers

• 요청 헤더와 동일한 구조를 가지고 있습니다.

• 대소문자 구분 없는 문자열과 콜론(:), 값을 입력합니다. 값은 헤더에 따라 다릅니다.

• 헤더는 값을 포함해 전체를 한 줄로 표시합니다.

• 요청의 헤더와 마찬가지로 몇 그룹으로 나눌 수 있습니다.

  1. General headers : 메시지 전체에 적용됩니다.
     예시) via

  2. Response headers : Vary, Accept-Ranges와 같은 헤더는 상태 줄(status line)에 넣기에는 공간이 부족했던 서버에 대한 추가 정보를 제공합니다.

  3. Entity headers : Content-Length와 같은 헤더는 body에 적용됩니다. body가 비어있는 경우, entity headers는 전송되지 않습니다.
     

3.3 body

• 응답의 본문은 HTTP messages 구조의 마지막에 위치합니다.

• 모든 응답에 body가 필요하지는 않습니다.

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

• 응답의 body는 다음과 같이 세 가지 종류로 나눌 수 있습니다.

  1. Single-resource bodies(단일-리소스 본문) : 길이가 알려진 단일-리소스 본문은 두 개의 헤더(Content-Type, Content-Length)로 정의합니다.

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

  3. Multiple-resource bodies(다중-리소스 본문) : 서로 다른 정보를 담고 있는 body입니다.

4. 무응답성 (Stateless)

• 말 그대로 상태를 가지지 않는다는 뜻입니다.

• HTTP로 클라이언트와 서버가 통신을 주고 받은 과정에서, HTTP가 클라이언트나 서버의 상태를 확인하지 않습니다.

• HTTP 는 통신 규약일 뿐이므로, 상태를 저장하지 않습니다.
  따라서, 필요에 따라 다른 방법(쿠키-세션, API 등)을 통해 상태를 확인할 수 있습니다.
  

• 왜?? 하나의 서버로 다수의 클라이언트에 대응하기 위하여 사용한다.

5. HTTP/2 프레임

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

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

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

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

• 스트림 여러개를 하나로 묶을 수 있어서(multiplexing), 기저에서 수행되는 TCP 연결이 효율적이게 이루어집니다.

6. HTTP 요청 메서드

• mdn : https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods

  GET : 표시를 요청합니다.

  HEAD : GET 과 동일한 응답을 요청합니다.

  POST : entity 를 제출한다.

  PUT : 모든 현재 표시를 교체한다.

  DELETE : 삭제한다.

  CONNECT : 연결한다.

  OPTIONS : 통신 옵션을 표시한다.

  TRACE : 메시지 루프-백을 수행한다.

  PATCH : 변경 부분을 적용한다.

7. HTTP 상태 코드

• mdn : https://developer.mozilla.org/ko/docs/Web/HTTP/Status

• 2xx : Success
  ex) 200 => OK

• 3xx : Redirect
  ex) 302 => Found

• 4xx : Client Error
  ex) 404 => Not Found, 400 => Bad Request

• 5xx : Server Error
  ex) 500 => Internal Server Error, 502 => Bad Gateway