Gidhub BE Developer

HTTP/1.1

2018-10-26
goodGid

HTTP/1.1 동작방식

  • HTTP는 웹상에서 Client( Internet Explorer, Chrome, Firefox) 와 Server( 웹서버 eg: httpd, nginx, etc…)간 통신을 위한 Protocol이다.

  • HTTP 1.1 프로토콜은 클라이언트와 서버간 통신을 위해 다음과 같은 과정을 거치게 된다.

  • HTTP/1.1는 기본적으로 Connection당 하나의 요청을 처리 하도록 설계 되어있다.

  • 그래서 위 그림과 같이 동시 전송이 불가능하고 요청과 응답이 순차적으로 이루어 지게된다.

  • 그렇다 보니 HTTP문서안에 포함된 다수의 리소스 (Images, CSS, Script)를 처리하려면
    요청할 리소스 개수에 비례해서 Latency(대기 시간)는 길어지게 된다.


HTTP1.1의 단점

HOL (Head Of Line) Blocking - 특정 응답의 지연

  • Web환경에서 HOLB는 실제로 두 종류가 존재한다.
  1. HTTP의 HOL Blocking

  2. TCP의 HOL Blocking

  • 우리의 관심은 HTTP의 HOLB이고 이에 대해 알아보자.
    TCP의 HOLB는 개념적으로 HTTP의 HOLB 비슷하지만 실체는 다르므로 자세한건 직접 찾아도록하자

  • HTTP/1.1의 Connection당 하나의 요청 처리를 개선할 수 있는 기법중 Pipelining이 존재한다.

  • 이것은 하나의 Connection을 통해서 다수개의 파일을 요청/응답 받을 수 있는 기법을 말하는데
    이 기법을 통해서 어느정도의 성능 향상을 꾀 할 수 있으나 큰 문제점이 하나 있다.

  • 하나의 TCP연결에서 3개의 이미지(a.png, b.png, c.png)를 얻을려고 하는경우 HTTP의 요청순서는 다음 그림과 같다.

  • 순서대로 첫번째 이미지를 요청하고 응답받고 다음 이미지를 요청하게 되는데

  • 만약 첫번째 이미지를 요청하고 응답이 지연되면
    아래 그림과 같이 두,세번째 이미지는 당연히 첫번째 이미지의 응답처리가 완료되기 전까지 대기하게 되며
    이와 같은 현상을 HTTP의 Head of Line Blocking 이라 부르며 Pipelining의 큰 문제점 중 하나이다.

RTT( Round Trip Time ) 증가

  • 앞서 말한것처럼 http/1.1의 경우 일반적으로 하나의 Connection에 하나의 요청을 처리 한다.

  • 이렇다 보니 매 요청별로 Connection을 만들게 되고
    TCP상에서 동작하는 HTTP의 특성상 3-way Handshake 가 반복적으로 일어나게 된다.

  • 이로인해 불필요한 RTT 증가네트워크 지연을 초래하여 성능을 저하 시키게 된다.

  • http/1.1의 헤더에는 많은 메타 정보들이 저장되어져 있다.

  • 사용자가 방문한 웹 페이지는 다수의 HTTP 요청이 발생하게 된다.

  • 이 경우 매 요청시 마다 HTTP 메세지의 헤더에는 중복된 헤더값을 전송하게 되며
    (별도의 domain sharding을 하지 않았을 경우)
  • 해당 Domain에 설정된 Cookie 정보도 매 요청시 마다 헤더에 포함되어 전송된다.

  • 실제로 요청을 통해서 전송하려는 값보다 헤더 값이 더 큰 경우도 비일비재 하다.
    심지어 User-Agent 정보 하나만 해도 대략 120Byte가 넘는다.

HTTP/1.1 단점 극복을 위한 노력

Image Spriting

  • 웹페이지를 구성하는 다양한 아이콘 이미지 파일의 요청 횟수를 줄이기 위해 아이콘을 하나의 큰 이미지로 만든 다음

  • CSS에서 해당 이미지의 좌표 값을 지정해 표시한다.

Domain Sharding

  • 요즘 브라우저들은 http/1.1이 단점을 극복하기 다수의 Connection을 생성해서 병렬로 요청을 보내기도 한다.

  • 하지만 브라우저 별로 Domain당 Connection개수의 제한이 존재하고 이 또한 http/1.1의 근본 해결책은 아니다.

Minify CSS/Javascript

  • http를 통해서 전송되는 데이터의 용량을 줄이기 위해 CSS, Javascript 코드축소하여 적용하기도 한다.

Data URI Scheme

  • Data URI 스킴은 HTML문서내 이미지 리소스Base64로 인코딩된 이미지 데이터로 직접 기술하는 방식이고

  • 이를 통해 요청 수를 줄이기도 한다.


HTTP/1.1 단점 극복 결과

  • 이런 노력들도 HTTP/1.1 단점을 근본적으로 해결 할 수 없었다.

  • 구글은 더 빠른 Web을 실현하기 위해 Throughput 관점이 아닌
    Latency 관점에서 HTTP를 고속화한 SPDY(스피디)라 불리는 새로운 프로토콜을 구현하였다.

  • 다만 SPDY는 HTTP를 대치하는 프로토콜이 아니고
    HTTP를 통한 전송을 재 정의하는 형태로 구현이 되었다.

  • SPDY는 실제로 HTTP/1.1에 비해 상당한 성능 향상과 효율성을 보여줬고
    이는 HTTP/2 초안의 참고 규격이 되게 된다.


참고


Next : HTTP/2.0

Comments

Content