HTTP

smc2315·2024년 3월 20일

Network

목록 보기

2/4

1. HTTP

1-1. HTTP란?

HTTP(Hypertext Transfer Protocol)는 클라이언트와 서버 간 통신을 위한 통신 규칙 세트 또는 프로토콜이다. 사용자가 웹 사이트를 방문하면 사용자 브라우저가 웹 서버에 HTTP 요청을 전송하고 웹 서버는 HTTP 응답으로 응답한다.

1-2. HTTP의 특징

요청과 응답
- TTP 통신은 클라이언트의 요청(Request)과 그에 대한 서버의 응답(Response)으로 이루어진다.
TCP/IP 통신 위에서 동작
- P 통신 위에서 동작하며 80번 포트를 사용합니다.

어떤 종류의 데이터라도 전송 가능
- 서 외에도 단순 텍스트나 이미지, 오디오 등의 미디어 데이터도 전송 가능하다.

Connectionless(비연결성)
- 비연결성을 가지는 HTTP에서는 실제로 요청을 주고받을 때만 연결을 유지하고 응답을 주고 나면 TCP/IP 연결을 끊는다.
- 장점 : 연결에 대한 리소스를 줄일 수 있다.
- 단점 : 같은 클라이언트에서 오는 요청도 계속 연결/해제 해야 한다.
Stateless(무상태)
- HTTP에서는 서버가 클라이언트의 상태를 보존하지 않는다.
- 장점 : 서버 확장성이 높다.
- 단점 : 클라이언트가 추가 데이터를 전송해야 한다

1-3. HTTP 메시지 구조

HTTP 메시지는 다음과 같은 구조를 가지고 있다.

HTTP Request 메시지 구조

Start Line
- HTTP 메소드 : 요청의 의도를 담고 있는 GET, POST, PUT, DELETE 등
- Request target : HTTP Request가 전송되는 목표 주소
- HTTP version : version에 따라 Request 메시지 구조나 데이터가 다를 수 있어서 version을 명시
Header
- Header에는 HTTP Request 그 자체에 대한 정보를 담고 있다.
- key : value 형태로 이루어져 있다.
- Request Header 정보
  - Host : 요청하려는 서버 호스트 이름과 포트번호
  - User-agent : 클라이언트 프로그램 정보. 이 정보를 통해 서버는 클라이언트 프로그램(브라우저)에 맞는 최적의 데이터를 보내줄 수 있다.
  - Referer : 바로 직전에 머물렀던 웹 링크 주소
  - Accept : 클라이언트가 처리 가능한 미디어 타입 종류 나열
  - If-Modified-Since : 여기에 쓰여진 시간 이후로 변경된 리소스 취득. 페이지가 수정되었으면 최신 페이지로 교체한다.
  - Authorization : 인증 토큰을 서버로 보낼 때 쓰이는 Header
  - Origin : 서버로 Post 요청을 보낼 때 요청이 어느 주소에 시작되었는지 나타내는 값. 이 값으로 요청을 보낸 주소와 받는 주소가 다르면 CORS(Cross-Origin Resource Sharing) 에러가 발생한다.
  - Cookie : 쿠키 값이 key-value로 표현된다.
Body
- HTTP Request가 전송하는 데이터를 담고 있는 부분

HTTP Response 메시지 구조

Start Line
- HTTP version
- Status Code : Response 상태를 나타내는 코드
- Status Text : Response 상태를 간략하게 글로 설명

Header
- Response Header 정보
  - Location : 301, 302 상태코드일 때만 볼 수 있는 Header로 서버의 응답이 다른 곳에 있다고 알려주면서 해당 위치(URI)를 지정
  - Server : 웹 서버의 종류
  - Age : max-age 시간내에서 얼마나 흘렀는지 초 단위로 알려주는 값
  - Referrer-policy : 서버 referrer 정책을 알려주는 값 ex) origin, no-referrer, unsafe-url
  - WWW-Authenticate : 사용자 인증이 필요한 자원을 요구할 시, 서버가 제공하는 인증 방식
  - Proxy-Authenticate : 요청한 서버가 프록시 서버인 경우 유저 인증을 위한 값

3) Body
HTTP Request 메시지의 Body와 동일

Date : 현재시간
Cache-Control : 캐시 제어
- no-store : 캐시를 저장하지 않겠다.
- no-cache : 모든 캐시를 쓰기 전에 서버에 해당 캐시를 사용해도 되는지 확인하겠다.
- must-revalidate : 만료된 캐시만 서버에 확인하겠다.
- public : 공유 캐시에 저장해도 된다.
- private : '브라우저' 같은 특정 사용자 환경에만 저장하겠다.
- max-age : 캐시의 유효시간을 명시하겠다.
Transfer-Encoding : Body 내용 자체 압축 방식을 지정
Content-Encoding : Body의 리소스 압축 방식 (Transfer-Encoding은 Body 자체이므로 다름)
Content-type : Body의 미디어 타입 ex) application/json, text/html
Content-Length : Body의 길이
Content-language : Body를 이해하는데 가장 적절한 언어 ex) ko
Connection : 클라이언트와 서버의 연결 방식 설정.

1-4. HTTP Method

HTTP Method를 사용하여 어떠한 목적으로 요청을 하는 것인지 정의를 내릴 수 있다.

안전
- 리소스를 변경 X
멱등
- 호출 횟수에 관계없이 같은 결과
캐시 가능
- 응답 결과 리소스 캐싱 가능 여부

GET
- 리소스를 검색하고, 반환받기 위해 사용되는 메소드이다.
- 원하는 정보를 서버에 요청할 때 쓰인다.
- (일반적으로) 리소스의 위치를 URL에서 쿼리로 표현하기 때문에 RequestBody가 없다.
HEAD
- 서버의 각종 정보를 확인하기 위해 사용되는 메소드이다.
- GET과 동일하지만, response에 Body가 없고 response Code와 Head만 응답받는다.

POST
- 요청된 자원을 생성하기 위해 사용되는 메소드이다.
- POST로 정보를 전송하면 URL에 파라미터가 나타나지 않으므로 각종 데이터를 전송하는데 쓰인다.

PUT
- 요청된 자원을 수정하기 위해 사용되는 메소드이다.

PATCH
- 요청된 자원을 수정하기 위해 사용되는 메소드라는 점에서 PUT과 같지만,
- 해당 자원 전체를 수정하는 PUT과는 다르게 PATCH는 해당 자원의 일부 부분을 수정한다.

DELETE
- 요청한 자원을 삭제하기 위해 사용되는 메소드이다.
- 클라이언트에서 서버의 자원을 삭제할 수 있도록 허가하는 것은 매우 위험하다.
- 그러므로 현실적으로는 사용될 일이 거의 없고, 대부분의 서버는 이 메소드를 비활성화 시킨다.

TRACE
- 루프백 메시지를 호출하기 위해 테스트용으로 사용되는 메소드이다.

OPTION
- 웹서버에서 지원하는 메소드를 알기위해 사용되는 메소드이다.

CONNECT
- 프락시 기능을 요청할 때 사용되는 메소드이다.

1-5. HTTP 상태 코드

HTTP 상태 코드는 서버가 응답을 전송할 때 같이 전송하는 코드다.

1XX - 정보 응답

100 Continue : 현재 요청이 진행중이며 문제 없다

2XX - 성공 응답

200 OK : 요청이 성공적으로 완료
201 Created : 요청이 성공적으로 완료되었고 새로운 리소스가 생성됨

3XX - 리다이렉션 메시지

300 Multiple Choice : 요청에 대해 하나 이상의 응답이 가능함
301 Moved Permanently : 요청한 리소스의 URI가 변경 되었음

4XX - 클라이언트 에러 응답

400 Bad Request : 잘못된 문법으로 인해 서버가 요청을 이해하지 못했음
401 Unauthorized : 요청을 보낸 클라이언트가 인증되지 않았음
403 Forbidden : 요청을 보낸 클라이언트가 리소스에 접근할 권리가 없음
404 Not Found : 서버가 요청받은 리소스를 찾을 수 없음
408 Request Timeout : 요청 중 시간이 초과되었음
418 I'm a Teapot : 서버는 커피를 찻 주전자에 끓이는 것을 거절

5XX - 서버 에러 응답

500 Internal Server Error : 서버에 문제가 있지만 서버가 해당 문제를 처리할 줄 모름
502 Bad Gateway : 서버가 게이트웨이로부터 잘못된 응답을 받았음
503 Service Temporarily Unavailable : 일시적으로 서버를 이용할 수 없음
504 Gateway Timeout : 서버가 게이트웨이 역할을 하고 있으며 다른 서버로부터 적시에 응답을 받지 못했음

1-6. HTTP 버전별 차이

HTTP의 역사

HTTP/0.9 (1991년)

HTTP/1.0 (1996년)

HTTP/1.1 (1997년) : 가장 많이 사용중

RFC2068 (1997) -> RFC2616 (1999) -> RFC7230~7235 (2014)

HTTP/2.0 (2015년) : HTTP 1.1의 성능 개선 및 확장

HTTP/3.0 (진행중)

1. HTTP/0.9

요청은 단일 라인으로 구성되며, 리소스에 대한 method는 GET만 존재
응답도 극도로 단순 (파일 내용 자체로만 구성)
HTTP헤더가 없었으며, HTML 파일만 전송 가능
상태 혹은 오류 코드가 없었음

/* 요청 */
GET /mypage.html
/* 응답 */ 
<HTML>
A very simple HTML page
</HTML>

2. HTTP/1.0

HTTP Header 개념이 도입되어 요청과 응답에 추가되며, 메타데이터를 주고 받고 프로토콜을 유연하고 확장 가능하도록 개선됨 (1996년)
버전 정보와 요청 method가 함께 전송되기 시작
상태 코드 라인도 응답의 시작부분에 추가되어 브라우저 요청의 성공과 실패를 파악 가능해짐(해당 결과에 대한 로컬 캐시 갱신 등의 사용이 가능해짐)
Content-Type 도입으로 HTML 이외의 문서 전송 기능이 가능해짐

한계

커넥션 하나당 요청 하나와 응답 하나만 처리 가능
- 매우 비효율적인 동작으로 보이며, 서버 부하도 문제

/* 요청 */
GET /mypage.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

/* 응답 */
200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
A page with an image
  <IMG SRC="/myimage.gif">
</HTML>

3. HTTP/1.1

Persistent Connection 추가
- 지정한 timemout 동안 커넥션을 닫지 않는 방법을 통해 커넥션의 사용성이 높아짐
Pipelining 추가
- 앞 요청의 응답을 기다리지 않고 순차적인 여러 요청을 연속적으로 보내고 그 순서에 맞춰 응답을 받는 방식이 등장
- 순차적으로 하나씩 요청 / 응답이 처리되는 기존 방식을 개선
- 하나의 커넥션에 여러개의 요청이 들어 있을 뿐, 동시에 여러개의 요청을 처리해 응답으로 보내주는 것은 아니다 (multiplexing 되지는 않음)
Multiple Connections 추가
- 한 번에 여러 개의 병렬 TCP 연결을 통해 여러 리소스를 동시에 요청 가능
- 일반적으로 웹 페이지에서 여러 개의 자원(예: HTML 문서, CSS 파일, JavaScript 파일, 이미지 등)을 불러오는 경우에 사용된다.

한계

Head Of Line Blocking (HOL)
- 앞 요청의 응답이 너무 오래걸리면 뒤 요청은 Blocking 되어버림
RTT(Round Trip Time)
- 하나의 Connection에 하나의 요청을 처리하는 특성 상, 3 way handshake 반복 등 latency가 증 가하게 됨
Fat Message Headers
- 매 요청 시 많은 데이터가 담긴 Header를 중복으로 보냄

/* 요청 */
GET /en-US/docs/Glossary/Simple_header HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header

/* 응답 */
200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Wed, 20 Jul 2016 10:55:30 GMT
Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
Keep-Alive: timeout=5, max=1000
Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
Server: Apache
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding

(content)

4. HTTP/2.0

Binary Framing
- Binary Framing 계층을 추가해서 보내는 메시지를 프레임(frame)이라는 단위로 분할하며 추가적으로 바이너리로 인코딩을 한다.
- 바이너리 형식 사용으로 파싱속도 및 전송 속도가 빠르고 오류 발생 가능성이 낮아짐

Multiplexed Stream
- 구성된 연결 내에 전달되는 바이트의 양방향 흐름을 의미하는 stream으로 요청과 응답이 교환된다.
- 메시지가 이진화된 텍스트인 프레임(frame)으로 나뉘어 요청마다 구분되는 Stream을 통해 전달
- 프레임이 각 요청의 스트림을 통해 전달되며, 하나의 커넥션 안에 여러개의 스트림을 가질 수 있게되어 동시에 여러 요청을 처리하는 다중화가 가능해짐
  - 동시에 여러 요청을 처리하는 것이 가능해짐
  - stream을 통해서 각 요청의 응답의 순서가 의미가 없어져서 HOL Blocking이 자연스럽게 해결됨
Stream Prioritization
- 리소스간 우선순위를 설정하는 기능
- Stream에 우선순위를 부여해서 인터리빙되고 전달하는 것이 가능
  중요한 데이터를 우선적으로 보낼 수 있다.
Server Push
- 단일 클라이언트 요청에 여러 응답을 보낼 수 있는 특징을 통해 Server에서 Client에게 필요한 추가적인 리소스를 push해주는 기능

Header Compression
- 요청과 응답의 헤더 메타데이터를 압축해서 오버헤드를 감소

5. HTTP/3.0 QUIC

Google에서 UDP 기반의 전송 프로토콜인 QUIC(Quick UDP Internet Connections)을 개발
Google에서 TCP의 구조적 문제로 성능 향상이 어렵다고 판단하여 UDP 기반을 선택하였다고 한다.
QUIC는 TCP의 3-Way Handshaking 과정을 최적화 하는 것에 초점을 두고 개발하였다.
TCP의 Stream은 하나의 chain으로 연결되는 것과는 다르게 QUIC는 각 Stream당 독립된 Stream chain을 구성하여 TCP HOL Blocking을 해결하였다.
HTTP 3.0은 QUIC을 기반으로 나온 새로운 HTTP 메이저 버전이다.

참고

HTTP Header 정리, 각 Http Header가 갖는 의미를 알아야 Http를 배운 것이다.

smc2315

개발일지

이전 포스트

TCP vs UDP

다음 포스트

HTTP

Network

1. HTTP

1-1. HTTP란?

1-2. HTTP의 특징

1-3. HTTP 메시지 구조

HTTP Request 메시지 구조

HTTP Response 메시지 구조

공통 Header

1-4. HTTP Method

GET

HEAD

POST

PUT

PATCH

DELETE

TRACE

OPTION

CONNECT