HTTP(HyperText Transfer Protocol)
- W3 상에서 정보를 주고 받을 수 있는 프로토콜. 주로 HTML 문서를 주고 받는 데에 쓰인다.
- HTTP는 클라이언트와 서버 사이에 이루어지는 요청/응답(Request/Response) 프로토콜이다.
- 80번 Port를 사용.
- HTTP, Header + Body 로 구성.
- 사람이 읽을 수 있는 문자열이 그대로 전송 됨.
HTTP 1.0 과 HTTP 1.1
HTTP 1.1의 가장 큰 특징은 다음 3가지이다.
- 커넥션 유지 (Persistent Connection)
- 호스트 헤더 (Host Header)
- 강력한 인증 절차 (Improved Authentication Procedure)
1. 커넥션 유지 (Persistent Connection)
HTTP 프로토콜은 Client-Server 간 데이터를 주고 받는 응용 계층의 프로토콜이다.
HTTP 를 이용한 데이터 전달은 TCP 세션(3-Way Handshake & 4-Way Handshake) 기반으로 이루어진다.
HTTP 1.0 과 1.1 의 차이는 TCP 세션을 지속적으로 유지할 수 있느냐? 이다.
HTTP 1.0 초기에는 Client와 Server 간의 요청의 3-Way handshake(SYN, SYN+ACK, ACK) 로 이루어졌다. 예를 들어, 10개의 오브젝트를 가진 웹 페이지가 존재한다면 Client와 Server 사이에 10 번의 3-Way Handshake 과정을 통해 TCP 연결을 맺고 끊는 과정을 반복해야 했다.
HTTP 1.0 기반에서 Persistence Connection을 원하고 이를 지원하는 Client는 Server에게 HTTP 요청 시 아래와 같은 메시지를 헤더에 추가하면 Keep-Alive가 생성된다.
connection:keep-alivePersistence Connection 을 지원하는 Server는 Client 의 요청을 수용하고 응답 이전까지 TCP 연결을 끊지 않는다. 이때 응답 헤더(Response Header) 에도 동일한 헤더를 응답 메시지에 포함시킨다.
HTTP 1.1 에서는 기본적으로 Persistent Connection 을 지원한다. 즉, 굳이 Connection Header 를 사용하지 않아도 모든 요청과 응답은 기본적으로 Persistent Connection을 지원하도록 되어 있으며 필요 없을 경우(HTTP 응답 완료 후 TCP 연결을 끊어야 하는 경우) Connection Header를 사용한다.
Keep-Alive 를 통해 얻을 수 있는 장점으로는 단일 시간 내의 TCP 연결을 최소화 함으로써 CPU와 메모리 자원을 절약할 수 있고 네트워크 혼잡이나 Latency 에 대한 경우의 수를 줄일 수 있다는 점이다.
1-1. 파이프라이닝 (Pipelining)
HTTP 1.1 에서는 Client와 Server 간의 요청/응답(Request/Response) 효율성을 개선하기 위해 HTTP Pipelining이 등장했다.
HTTP 1.0 에서는 HTTP 요청들의 연결을 반복적으로 끊고 맺음으로서 서버 리소스적으로 비용을 요구한다.
HTTP 1.1 에서는 다수의 HTTP Request 들이 각각의 서버 소켓에 Write 된 후, Browser는 각 Request들에 대한 Response를 순차적으로 기다리는 문제를 해결하기 위해 여러 요청들에 대한 응답 처리를 뒤로 미루는 방법을 사용한다.
즉, HTTP 1.1 에서 Client는 각 요청에 대한 응답을 기다리지 않고, 여러 개의 HTTP Request를 하나의 TCP/IP Packet으로 연속적으로 Packing 해서 요청한다.
Pipelining이 적용되면 하나의 Connection으로 다수의 Request와 Response를 처리할 수 있고 Network Latency를 줄일 수 있게 된다.
그러나, 결국 완전한 멀티플렉싱(Multiplexing)이 아닌 응답처리를 미루는 방식이므로 각 응답의 처리는 순차적으로 처리되며, 결국 후순위의 응답은 지연될 수 밖에 없다.
※ Multiplexing
: 여러가지의 리소스를 한번의 Request로 받을수 있어 client마다 하나의 TCP connection이면 충분하다는 새로운 방법
2. 호스트 헤더 (Host Header)
HTTP 1.0 환경에서는 하나의 IP에 여러 개의 도메인을 운영할 수 없었지만 HTTP 1.1 부터 가능하게 된다.
HTTP 1.1 에서 Host 헤더의 추가를 통해 비로소 Virtual Hosting이 가능해졌다.
3. 강력한 인증 절차 (Improved Authentication Procedure)
HTTP 1.1 에서 다음 2개의 헤더가 추가된다.
- proxy-authentication
- proxy-authorization
실제 Server에서 Client 인증을 요구하는 www-authentication 헤더는 HTTP 1.0 에서부터 지원되어 왔으나, Client와 Server 사이에 프록시가 위치하는 경우 프록시가 사용자의 인증을 요구할 수 있는 방법이 없었다.
※ HTTP Method
- HTTP 1.0에서는 GET, HEAD, POST의 method가 사용된다.
- GET : Request-URI에서 지정한 정보를 Entity Body로 전달해달라는 요청
- HEAD : Header의 정보만 요구
- POST : Request 메시지의 body에 포함된 자원을 Request-URI로 넘겨주는 경우 사용
- HTTP 1.1에서는 OPTION, PUT, DELETE, TRACE의 method가 사용된다.
- OPTION : 통신과 관련된 선택사항들에 대한 정보를 요구하는 경우
- PUT : Request 메시지에 포함되어 있는 data를 지정한 Request-URI로 저장하기 위함
- DELETE : 특정 resource를 지우기 위함
- TRACE : 최종 destination까지의 Loopback을 테스트하기 위함
HTTP 2.0
HTTP 1.1 은 기본적으로 연결 당 하나의 요청/응답을 처리하기 때문에 동시 전송 문제와 다수의 리소스를 처리하기에 속도와 성능 이슈를 가지고 있다.
이렇다 보니, HOL(Head of Line) Blocking-특정응답지연, RTT(Round Trip Time) 증가, 헤비한 Header 구조라는 문제점을 가지고 있다. 그러던 중 HTTP 2가 소개되었고 아래와 같은 특징을 갖고 있다.
- Multiplexed Streams (한 커넥션에 여러개의 메세지를 동시에 주고 받을 수 있음)
- 요청이 커넥션 상에서 다중화 되므로 HOL(Head Of Line) Blocking 이 발생하지 않음
- Stream Prioritization (요청 리소스간 의존관계를 설정)
- Header Compression (Header 정보를 HPACK 압축 방식을 이용하여 압축 전송)
- Server Push (HTML문서 상에 필요한 리소스를 클라이언트 요청없이 보내줄 수 있음)
- 프로토콜 협상 메커니즘 - 프로토콜 선택, 예. HTTP / 1.1, HTTP / 2 또는 기타.
- HTTP / 1.1과의 높은 수준의 호환성 - 메소드, 상태 코드, URI 및 헤더 필드
- 페이지 로딩 속도 향상
HTTP 2.0은 2010년에 구글이 실험적인 SDPY(구글 제안 프로토콜) 프로토콜을 구현한 것에 기초하여 등장하였다.
기존 HTTP는 Body가 문자열로 이루어져 있지만, HTTP 2.0 부터는 Binary framing layer 라고 하는 공간에 이진 데이터로 전송된다.
Reference
'Web Server' 카테고리의 다른 글
| [WEB] NginX - Tomcat 연동 (1) | 2022.08.12 |
|---|---|
| 공부 정리 (0) | 2021.12.06 |
| [WEB] Proxy - Forward Proxy & Reverse Proxy (0) | 2021.12.02 |
| [WEB] DNS (0) | 2021.12.01 |
| [WEB] SSL / TLS (0) | 2021.11.27 |
