티스토리 뷰
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개의 커넥션을 무조건 열고 닫아야한다.
- 또한, index.html이 모두 처리되지 않는다면, 그 다음 리소스들인 common,script 리소스들은 처리되지 못한다. 이게 바로 HTTP의 고질적인 문제였던 HOL(Head of Line Blocking)이다. 이 문제는 HTTP/1.0뿐만 아니라 HTTP/1.1도 해당된다.
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로 헤더에 표기하면 된다.
Pipelining)
- 하지만, 아직도 요청에 대하여 응답을 받아야만 다음 요청을 하는 구조가 있다. 이를 개선하기 위해 Pipelining이라는 기법을 적용하여 응답없이도 여러 요청을 할 수 있게 되었다.
문제점)
- 이제 Persistent connection과 Pipelining을 통하여 문제가 없어졌을 것 같지만, 여전히 HOL 문제가 존재했다.
왜냐하면, 아래와 같이 index.html이 먼저 처리되지 않는다면.. 다음 리소스들을 처리할 수 없게 된다.
HTTP/1.1 HOL 문제점의 반쪽짜리 대처 방법
도메인 샤딩)
- HOL의 문제를 해결하기 위해 도메인 단위로 병렬처리하는 기법이 HTTP/1.1에 존재한다. 하지만, 이 기법은 브라우저마다 최대 개수가 제한(크롬은 6 connection)되어 있으며 상당한 자원이 소모된다.
- HTTP/1.1을 사용하는 CDN은 대부분 도메인 샤딩을 사용한다. 물론, 요새는 HTTP/2로 넘어가는 추세이므로 HTTP/2를 사용한다면 도메인 샤딩은 사용할 필요가 없어졌다.
이미지 스프라이트)
- 이미지의 경우, 리소스 하나에 여러 이미지를 만들어 두고, 좌표를 통해 처리하는 방식이다. 이 방법은 리소스 1개의 필요한 이미지를 좌표를 통해 얻는 케이스로, 서버에 좌표 설정이 필요하다.
- 아래를 예로 들자면, A.jpg라는 리소스에 5개의 이미지를 넣어두었다. 1개의 도메인 커넥션을 A.jpg로 연결 한다. 만약, 서버의 html에 설정이 A좌표로 설정되어 있다면, A의 이미지를 Client에게 주게 된다.
- 원래라면 A~E까지 5개의 리소스를 썼겠지만, 이미지 스프라이트로 1개의 커넥션으로 선택하여 사용할 수 있게 되었다.
이외에도 많은 방법들이 있지만, 네트워크 엔지니어로서 직접 사용했던 것들만 나열했다.
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
- HTTP
- VXLAN
- ping
- vlan
- multiple ping
- date 시간 지정
- Windows
- date 과거
- link aggregation
- dns 동작 방식
- ping multi
- iso8601
- 802.1ax
- date 미래
- docker logs
- vtep
- http/0.9
- dns 동작
- ssh
- 윈도우
- Switch
- bash
- tag
- date 시간 변경
- http/1.0
- data plane
- 802.3ad
- vni
- head end replication
- HTTP/1.1
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 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 |