티스토리 뷰

Network/HTTP

HTTP 이야기

gluecode 2021. 2. 4. 17:44

HTTP는 TCP위에서 동작하는 Application Layer의 프로토콜이며, 웹 데이터를 주고 받는데 사용되는 프로토콜이다.

정식 명칭은 HTTP/1.1 처럼 프로토콜 뒤에 슬래시(/) 후, 버전명을 적는다고 한다.

 

HTTP/0.9

 - HTTP/0.9는 최초 고안된 프로토콜로서, 헤더와 바디가 없고, GET Method와 단순한 html 응답만 존재한다.
 - 단순하기 때문에 one-line 프로토콜이라고도 부른다.

  - 1개의 커넥션 당 1개의 리소스(데이터)만 요청하고 처리한다. 이게 무슨말이냐 하면.. 아래와 같다.

===TCP 3-Way-handshake ESTABLISHED===

===HTTP Request===
Header)
GET /mypage.html


===HTTP Reponse===
Body)
<HTML>
A very simple HTML page
</HTML>

===TCP 3-Way-handshake close===

 - 0.9는 써본적이 없을 뿐더러 쓰는 곳도 거의 없을거라 생각된다.

 

HTTP/1.0

 - HTTP/1.0에서는 0.9에선 없었던 헤더와 바디가 생겼다. 또한 응답 코드도 함께 사용되도록 구현되었다.

 - Method는 GET, HEAD, POST를 사용할 수 있으며, 연결 특성은 요청에 대하여 응답 직후 바로 종료한다.

 - 그리고, HTML이외의 콘텐츠도 받을 수 있게 되었다.

===TCP 3-Way-handshake ESTABLISHED===

===HTTP Request===
Header)
GET /mypage.html
User-Agent: curl/7.54.0

===HTTP Reponse===
HTTP/1.0 200 OK 
Content-Type: text/html 
Content-Length: 154
Server: Apache

===TCP 3-Way-handshake close===

 - 1.0은 요청에 대하여 리소스당 1개의 커넥션을 무조건 열고 닫아야한다.

HTTP/1.0

 - 또한, index.html이 모두 처리되지 않는다면, 그 다음 리소스들인 common,script 리소스들은 처리되지 못한다. 이게 바로 HTTP의 고질적인 문제였던 HOL(Head of Line Blocking)이다. 이 문제는 HTTP/1.0뿐만 아니라 HTTP/1.1도 해당된다.

HTTP의 고질적인 문제였던 HOL(Head of Line Blocking)

HTTP/1.1

Connection)

 - HTTP/1.1에서는 정말 여러가지 헤더들이 추가되었다.

===TCP 3-Way-handshake ESTABLISHED===

===HTTP Request===
> GET / HTTP/1.1
> Host: www.naver.com
> User-Agent: curl/7.54.0
> Accept: */*
>
===HTTP Response===
< HTTP/1.1 302 Moved Temporarily
< Server: NWS
< Date: Thu, 04 Feb 2021 10:28:33 GMT
< Content-Type: text/html
< Transfer-Encoding: chunked
< Connection: keep-alive
< Location: https://www.naver.com/
< Vary: Accept-Encoding,User-Agent
===TCP 3-Way-handshake close===

 

Persistent Connection)

- HTTP/1.0의 1개 커넥션 당, 1개의 리소스만 처리되는 구조를 개선하기 위하여 Persistent-Connection 기법이 적용되었다.

 - Persistent Connection은 Connection Header에 Keep-alive를 넣으면 수행 된다.

 - HTTP/1.0처럼 일반적인 건-바이-건의 열고 닫는 과정은 Connection : close로 헤더에 표기하면 된다.

HTTP/1.1 Persistent Connection

Pipelining)

 - 하지만, 아직도 요청에 대하여 응답을 받아야만 다음 요청을 하는 구조가 있다. 이를 개선하기 위해 Pipelining이라는 기법을 적용하여 응답없이도 여러 요청을 할 수 있게 되었다. 

HTTP/1.1 Keep alive + Pipelining

 

문제점)

 - 이제 Persistent connection과 Pipelining을 통하여 문제가 없어졌을 것 같지만, 여전히 HOL 문제가 존재했다.

왜냐하면, 아래와 같이 index.html이 먼저 처리되지 않는다면.. 다음 리소스들을 처리할 수 없게 된다.

HTTP/1.1 HOL 문제점

 

HTTP/1.1 HOL 문제점의 반쪽짜리 대처 방법

 

도메인 샤딩)

 - HOL의 문제를 해결하기 위해 도메인 단위로 병렬처리하는 기법이 HTTP/1.1에 존재한다. 하지만, 이 기법은 브라우저마다 최대 개수가 제한(크롬은 6 connection)되어 있으며 상당한 자원이 소모된다.

 - HTTP/1.1을 사용하는 CDN은 대부분 도메인 샤딩을 사용한다. 물론, 요새는 HTTP/2로 넘어가는 추세이므로 HTTP/2를 사용한다면 도메인 샤딩은 사용할 필요가 없어졌다.

Domain sharding example1)
domain sharding example2)

 

이미지 스프라이트)

 - 이미지의 경우, 리소스 하나에 여러 이미지를 만들어 두고, 좌표를 통해 처리하는 방식이다. 이 방법은 리소스 1개의 필요한 이미지를 좌표를 통해 얻는 케이스로, 서버에 좌표 설정이 필요하다.

 - 아래를 예로 들자면, A.jpg라는 리소스에 5개의 이미지를 넣어두었다. 1개의 도메인 커넥션을 A.jpg로 연결 한다. 만약, 서버의 html에 설정이 A좌표로 설정되어 있다면, A의 이미지를 Client에게 주게 된다.

 - 원래라면 A~E까지 5개의 리소스를 썼겠지만, 이미지 스프라이트로 1개의 커넥션으로 선택하여 사용할 수 있게 되었다.

 

Image sprite

 

이외에도 많은 방법들이 있지만, 네트워크 엔지니어로서 직접 사용했던 것들만 나열했다.

 

HTTP 그 외 특징들

 - HTTP는 그 외의 표준으로 캐리지리턴 + 뉴라인을 통한 헤더 구분과 뉴라인x2를 통한 바디 구분이 있다.

 - cleartext라는 특징이 있다. 사람이 읽을 수 있는(Human-readible) 특징이 있는데, 컴퓨터는 2진수로 처리하기 때문에 2진수로 변환하는 과정을 거쳐야 한다. 때문에 HTTP/2에선 binary protocol(이진 프로토콜)이라는 기법으로 처리 성능을 향상 했다.

 - ALPN과 upgrade header를 통해 프로토콜을 스위칭하거나 h2냐 h2c냐를 구분하며 우선순위를 두며 사용할 수 있는데, 이건 나중에 HTTP/2 작성 때 함께 포스팅 하려 한다.

 - SSL에 대해서도 다음 포스팅에 자세히 작성

 

 

 

참고링크

 - HTTP : medium.com/platform-engineer/evolution-of-http-69cfe6531ba0

 - 도메인 샤딩 : www.etondigital.com/domain-sharding-for-optimization/

 

공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/12   »
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31
글 보관함