HTTP?
WWW 상에서 정보를 주고 받을 수 있는 프로토콜이다.
- 클라이언트가 HTTP를 통해 서버로 정보를 요청한다.
- 서버는 요청에 필요한 정보를 클라이언트에 전달한다.
- HTTP 1.1이 모든것의 기반이 된다.
HTTP 0.9
원라인 프로토콜이다. 요청 메서드가 GET만 존재하기 때문이다.
- HTML 파일 유형만 전송할 수 있다.
/* 요청 */
GET /page.html
/* 응답 */
<HTML>
A very simple HTML page
</HTML>
HTTP 1.0
확장성 있게 진화되었다. 헤더 개념이 도입되어 메타 데이터를 주고 받을 수 있게 되었다.
- 버전 정보와 요청 메서드가 함께 전송된다.
- 상태코드가 응답의 시작에 붙어 전송된다.
- HTML 이외에 Content-Type의 데이터를 전송할 수 있다.
/* 요청 */
GET /page.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>
HTTP 1.1
1.0 버전에서 모호했던 내용을 개선하고 추가적인 기능들을 도입했다.
- 커넥션을 재사용할 수 있다. (지속성)
- 파이프라이닝이 추가되어 요청에 대한 응답이 끝나기 전에 다른 요청을 전송할 수 있다.
- 캐시된 데이터를 사용하여 서버에 대한 요청의 수를 줄인다.
- 응답을 여러 청크로 나누어 전송하기 때문에 전체 크기를 미리 알지 못한다.
/* 요청 */
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)
HTTP 1.0과 HTTP 1.1의 차이
1. 지속성
1.0 버전과의 가장 큰 차이점은 지속성이다.
HTTP 1.0 에서는 요청/수신 마다 새로운 TCP 세션을 연결해야 한다.
HTTP 1.1 부터는 한번의 연결으로 여러 개의 요청을 보내고 응답을 수신할 수 있다.
== "TCP 세션을 처리하는 비용은 줄어들고 응답속도는 빨라진다"
2. 파이프 라이닝
HTTP 1.0에서는 요청에 대한 응답을 받아야 다음 요청을 전송할 수 있다.
HTTP 1.1 에서는 파이프라이닝 기능이 추가되어 요청을 병렬로 처리할 수 있다.
== "여러 개의 요청을 처리하는 응답속도가 훨씬 빨라진다"
HTTP 2.0
기존 HTTP 1.X 버전의 성능을 향상시키는데 초점을 맞췄다. (대체가 아닌 확장)
- HTTP 메시지 전송방신이 전환되었다.
- 다중 스트림 전송이 가능하다.
- 스트림의 우선순위를 결정할 수 있다.
- 하나의 클라이언트 요청에 여러 응답을 보낼 수 있어 클라이언트에서 필요한 추가적인 자원을 push 할 수 있다.
- 요청과 응답의 헤더 메타데이터를 압축해서 오버헤드를 감소 시킬 수 있다.
HTTP 2.0의 한계
서로 다른 스트림이 전송될 때, 하나의 스트림에서 유실과 같은 문제가 발생하면
다른 스트림도 문제가 해결되기 전까지 전송이 지연된다.
[참고 - HOL Blocking]
TCP는 패킷을 전송할 때, 전달을 보장하기 때문에 패킷이 도중에 손실되면 재전송한다.
재전송이 발생하면 패킷의 순서가 바뀌지 않도록 후속 패킷이 대기한다.
즉, 먼저 보낸 패킷이 손실되면 후속 패킷은 계속 대기해야 한다.
이러한 문제(HOL Blocking)을 해결하기 위해서 HTTP 3.0이 등장한다.
HTTP 3.0
HTTP 2.0의 한계를 개선하기 위해 등장했다.
- TCP 대신 UDP 위에서 QUIC 프로토콜을 사용한다.
- 보안 연결 설정에 소요되는 시간을 단축시킬 수 있다.
- 각 스트림이 독립적으로 처리된다. (서로 영향을 주지않아 2.0 버전의 문제를 해결한다)
- TLS를 내장하고 있어서, 별도의 보안 계층을 사용하지 않고도 안전한 전송이 가능하다.
'CS' 카테고리의 다른 글
| [Network] TCP와 UDP의 차이점 (0) | 2023.06.06 |
|---|---|
| [Network] OSI 7 Layer (2) | 2023.06.05 |
| [정보처리기사] 신처기 요약 (3) | 2022.12.12 |
| [SQLD] SQLD 대비 요약 (2) | 2022.12.12 |
| [컴퓨터일반] 전자계산기 구조론 요약 (1) | 2022.12.12 |
댓글