HTTP 1.1

2022. 3. 8. 17:13

HTTP/1.0은 client, server가 1:1인 구조로, TCP Connection 과정에서 매번 하나의 요청/응답 후 마다 연결을 해야 하기 때문에 속도가 느리다.

이로 인해 많은 양의 리소스를 요구할 시 HTTP서버의 부하를 증가 시키고 인터넷 트래픽 혼잡을 유발한다.

클라이언트와 서버 간의 요청과 응답을 어떻게 하면 좀 더 빨리 할 수 있을지 연구했고 Persistent Connection(Keep-alive), Pipelining 기법이 등장했다.

이로 인해 서버는 Multiple Requests를 응답할 수 있게 되었고 클라이언트의 응답 속도가 개선되었다.

HTTP Pipelining
- 클라이언트는 각 요청에 대한 응답을 기다리지 않고, 여러 개의 HTTP Request를 하나의 TCP/IP Packet으로 연속적으로 Packing해서 요청을 보냄
- → 커넥션 유지(Persistent Connection)과 달리 동시에 발생한 다수의 Requests를 순서에 상관없이 각각의 응답을 받아 처리한다.
- Pipelining이 적용되면 하나의 Connection으로 다수의 Request와 Response를 처리할 수 있게끔 Network Latency를 줄일 수 있음

Host Header
- HTTP1.0 에서는 HTTP통신 시 host주소를 주고 받지 않았는데, 같은 호스트에 여러 서버를 두는 가상 호스팅의 경우 어떤 호스트로 접근하는지를 알 수 있는 방법이 없었다. 이를 해결하기 위해 http1.1 Request/Response 메시지는 host 헤더 필드를 지원하며, 요청 메시지에 host 헤더 필드가 없으면 오류 코드(400)를 전송한다. http1.1 규약부터는 host header가 반드시 지정되어있어야 한다.

Improved Authentication Procedure
- HTTP1.0에서 서버에서 클라이언트의 인증을 요구하기 위해 www-authentication헤더가 지원되었으나 클라이언트와 서버 사이에 프록시가 위치하고 있는 경우 프록시가 사용자의 인증을 요구할 수 있는 방법이 없었다. 이를 위해 HTTP1.1에서 Proxy-authenticate, Proxy-authorization 2개의 헤더가 추가되었다.

Caching
- HTTP1.0은 Pragma, IF-Modified-Since헤더를 통해 단순한 캐싱을 지원했지만 HTTP1.1은 Etag를 지원하여 동일 태그값을 갖는 리소스에 대해 캐싱하여 네트워크 대역폭 면에서 효율적이다.
- ETag: 고유한 16진수 해쉬값, Response로 전송되며 클라이언트에서 동일 자원 재 요청 시 캐싱(서버 자원 X)한다. 주로 IF-(Un)modified-Since, If-Match, If-Node-Match 등의 조건부 헤더를 통해 확장된 캐싱 기능을 제공한다.
Content Negotiation
- 다수의 이용자가 동일한 자원에 대해 다른 응답(언어, 형식 등)방법을 사용할 수 있을 때 특정 응답에 대한 최상의 표현 방법을 선택하는 과정
- 서버가 주도하는 협상
  - 클라이언트의 특정 HTTP헤더(Accept, Accept-Charset, Accept-Encoding, Accpet-Language....) 를 통해 클라이언트의 선호에 맞게 정보를 Response해줌.
  - 단점: 서버가 클라이언트의 상태를 정확히 알지 못함(Response 정보의 정확도), 사생활 침해, 알고리즘 복잡성, 캐시 기능 제한

- 에이전트가 주도하는 협상
  - 서버가 애매한 요청을 맞닥뜨렸을 때 클라이언트에게 사용 가능한 대체 리소스들에 대한 링크를 포함하는 페이지(300상태코드)를 Response해줌.
  - 단점: 선택을 지원하는 페이지 형식의 메커니즘이 없음, 최적의 대체 표시 방법을 얻기 위한 추가적인 요구가 필요

HTTP/1.0 Method 종류에서 PUT, DELETE, TRACE, OPTIONS 메소드가 추가 되었다.

- PUT: 요청 메세지를 통해 서벗에서 새로운 리소스를 생성하거나 대상 리소스를 대체한다.
- DELETE: Request- URI가 식별하는 자원을 삭제하도록 요구할 수 있다. 단, 사용자의 개입에 의하여 무시될 수 있고, 안전상의 문제로 대부분 서버에서 비활성화 해 놓는다.
- TRACE: Request 메시지가 거쳐가는 프록시나 게이트웨이의 중간 경로부터 최종 수신 서버까지의 경로를 알아낼 수 있다. 주로 루프백 검사용으로 쓰인다.
- OPTIONS: 목표 리소스와의 통신 옵션이나 웹서버에서 지원되는 메소드의 종류를 확인할 때 사용한다.(Method, header, content type ..)

*deflate: Huffman알고리즘 기반 압축 방식(Huffman:문자열에서 자주 등장하는 문자는 짧은 비트, 많이 등장하는 문자는 긴 비트로 표현하여 전체 비트 수를 줄임)

http1.0: TCP Connection은 HTTP요청마다 3-way handshaking이 이루어짐
http1.1(persistent connection): 한번의 3 way handshaking 이후 연결이 끊이지 않고 끝까지 지속됨
- 하나의 Request에 대한 Response가 없을 시 다음 Request가 진행되지 않음