9일차 웹서비스 개발 기초

HTTP (HyperText Transfer Protocol)

텍스트 기반의 통신 규약으로 인터넷에서 데이터를 주고받을 수 있는 프로토콜이다. 규약을 정해두었기 때문에 모든 프로그램이 이 규약에 맞춰 개발해서 서로 정보를 교환할 수 있게 되었다. 전통적인 클라이언트-서버 모델에서 클라이언트가 HTTP messages 양식에 맞춰 요청을 보내면, 서버도 HTTP messages 양식에 맞춰 응답합니다.

 

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

 

Stateless(무상태성)

말 그대로 상태를 가지지 않는다는 뜻이며, 서버가 클라이언트의 상태를 보존하지않는다.

• 장점 : 서버의 확장성이 높다(스케일 아웃) 
• 단점 : 클라이언트가 추가 데이터를 전송하여야 한다.

자세한 정보는 : https://ojt90902.tistory.com/642

 

 

HTTP messages

HTTP messages 는 클라이언트와 서버 사이에서 데이터가 교환되는 방식이다.

• 요청 (Requests) : 클라이언트 > 서버 (선)
• 응답 (Responses) : 서버 > 클라이언트 (후)

 

요청(Requests)

 

요청과 응답은 유사한 구조를 가진다.

1. start line : 요청이나 응답의 상태를 나타냅니다. 항상 첫 번째 줄에 위치합니다. 응답에서는 status line이라고 부릅니다.
2. HTTP headers : 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합입니다.
3. empty line : 헤더와 본문을 구분하는 빈 줄이 있습니다.
4. body : 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함합니다. 요청과 응답의 유형에 따라 선택적으로 사용합니다.

 

 

Start Line

 

수행할 작업(GET, PUT, POST 등)이나 방식(HEAD or OPTIONS)을 설명하는 HTTP method를 나타냅니다. 예를 들어 GET method는 리소스를 받아야 하고, POST method는 데이터를 서버로 전송합니다.

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

• origin 형식 : ?와 쿼리 문자열이 붙는 절대 경로입니다. POST, GET, HEAD, OPTIONS 등의 method와 함께 사용합니다. 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 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

 

ex)GET /search HTTP/1.1

• HTTP Method
  해당 request가 의도한 action을 정의하는 부분.
  HTTP Methods에는 GET, POST, PUT, DELETE, OPTIONS 등등이 있다.
  주로 GET 과 POST과 쓰임.
• Request target
  해당 request가 전송되는 목표 uri.
  예를 들어 /login.
• HTTP Version
  말 그대로 사용되는 HTTP 버젼. 버젼에는 1.0, 1.1, 2.0 등이 있다.

 

Headers

요청의 Headers는 기본 구조를 따릅니다. 헤더 이름(대소문자 구분이 없는 문자열), 콜론( : ), 값을 입력합니다. 값은 헤더에 따라 다릅니다. 여러 종류의 헤더가 있고, 다음과 같이 그룹을 나눌 수 있습니다.

 

• General headers : 메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와는 관련이 없는 헤더입니다.
• Request headers : fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더를 의미합니다. User-Agent, Accept-Type, Accept-Language과 같은 헤더는 요청을 보다 구체화합니다. Referer처럼 컨텍스트를 제공하거나 If-None과 같이 조건에 따라 제약을 추가할 수 있습니다.
• Representation headers : 이전에는 Entity headers로 불렀으며, body에 담긴 리소스의 정보(컨텐츠 길이, MIME 타입 등)를 포함하는 헤더입니다.

Ex)

Accept: */*
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Type: application/json
Content-Length: 257
Host: google.com
User-Agent: HTTPie/0.9.3

• Host : 요청이 전송되는 target의 host url: 예를 들어, google.com
• User-Agent : 요청을 보내는 클라이언트의 대한 정보: 예를 들어, 웹브라우저에 대한 정보.
• Accept : 해당 요청이 받을 수 있는 응답(response) 타입.
• Connection : 해당 요청이 끝난후에 클라이언트와 서버가 계속해서 네트워크 컨넥션을 유지 할것인지 아니면 끊을것인지에 대해 지시하는 부분.
• Content-Type : 해당 요청이 보내는 메세지 body의 타입. 예를 들어, JSON을 보내면 application/json.
• Content-Length : 메세지 body의 길이.

 

Body

 

요청의 본문은 HTTP messages 구조의 마지막에 위치합니다. 모든 요청에 body가 필요하지는 않습니다. GET, HEAD, DELETE, OPTIONS처럼 서버에 리소스를 요청하는 경우에는 본문이 필요하지 않습니다. POST나 PUT과 같은 일부 요청은 데이터를 업데이트하기 위해 사용합니다. body는 다음과 같이 두 종류로 나눌 수 있습니다.

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

 

응답(Responses)

 

Status line

• HTTP 버젼 : 1.1
• Status code : 응답 상태를 나타내는 코드, 숫자로 되어 있는 코드. : 404
• Status text : 응답 상태를 간략하게 설명해주는 부분 : Not Found

Status line은 HTTP/1.1 404 Not Found. 처럼 생겼습니다.

 

Headers

 

 

• Response의 headers와 동일하다.
• 다만 response에서만 사용되는 header 값들이 있다.
• 예를 들어, User-Agent 대신에 Server 헤더가 사용된다.

Response headers : 위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 갖는 헤더로, Vary, Accept-Ranges와 같이 상태 줄에 넣기에는 공간이 부족했던 추가 정보를 제공합니다.

 

Body

• Response의 body와 일반적으로 동일하다.
• Request와 마찬가지로 모든 response가 body가 있지는 않다. 데이터를 전송할 필요가 없을경우 body가 비어있게 된다.

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

• 길이가 알려진 단일-리소스 본문은 두 개의 헤더(Content-Type, Content-Length)로 정의합니다.
• 길이를 모르는 단일 파일로 구성된 단일-리소스 본문은 Transfer-Encoding이 chunked 로 설정되어 있으며, 파일은 chunk로 나뉘어 인코딩되어 있습니다.

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

• 서로 다른 정보를 담고 있는 body입니다.

 

HTTP/2

 

HTTP 연대기

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

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

 

 

ㅍ

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

 

자세히) https://web.dev/performance-http2/