HTTP/1.0, HTTP/1.1

HTTP/1.0

HTTP/1.0은 기본적으로 한 연결당 하나의 요청을 처리하도록 설계되었다. 이로인해 RTT가 증가한다.

 

서버에서 파일을 가져올 때마다 TCP의 3-way handshake를 열어야해서 RTT가 증가한다.

• RTT: 패킷이 목적지까지 갔다가 돌아오는 시간, 즉 패킷 왕복 시간

RTT 증가 해결 방법

연결할 때마다 RTT가 증가하면 서버에 부담이 많아지고 응답 시간이 길어진다. 이를 해결하기 위해 이미지 스플리팅, 코드 압축, 이미지 Base64 인코딩을 사용했다.

 

-이미지 스플리팅

이미지를 많이 다운 받으면 과부하가 걸려서 많은 이미지가 합쳐져 있는 하나의 이미지를 받고 이를 기반으로 background-image의 position을 이용해 이미지를 표기하는 법이다.

 

-코드 압축

코드 압축은 개행 문자, 빈칸을 없애 코드를 최소화 한다. 사진 처럼 압축하며 배포할 때 코드를 이렇게 압축한다.

 

-이미지 Base64 인코딩

이미지 파일을 64진법으로 이루어진 문자열로 인코딩 하는 방법이다. 

장점: 서버와 연결을 열고 이미지에 대해 HTTP 요청을 할 필요가 없음 

• 인코딩: 정보의 형태나 형식을 표준화, 보안, 처리 속도 향상, 저장 공간 절약 등을 위해 다른 형태나 형식으로 변환하는 처리 방식

HTTP/1.1

HTTP/1.0에서 업그레이드 된 것이 HTTP/1.1이다. 매번 TCP를 연결하지 않고 처음에 한번만 TCP 초기화를 하고 keep-alive 옵션으로 여러 개의 파일을 송수신 할 수 있다. 

keep-alive는 HTTP/1.0에도 있었지만 HTTP/1.1부터 표준화 되어 기본 옵션이 되었다.

 

사진을 보면 HTTP/1.1은 한번 3-way-handshake가 발생하면 더 발생하지 않는다. 

하지만 단점으로는 문서 안에 포함된 리소스(이미지, css, script 파일)를 처리하려면 리소스 개수에 비례해서 대기 시간이 길어진다.

HOL Blocking(Head Of Line Blocking)

HOL Blocking은 네트워크에서 같은 큐에 있는 패킷이 다른 패킷에 의해 지연될 때 발생하는 성능 저하 현상을 말한다.

사진 처럼 image 파일 다운이 느려지면 다른 파일도 다운로드가 지연된다.

무거운 헤더 구조

HTTP/1.1 헤더에는 쿠키 등 많은 메타데이터가 있어서 압축되지 않아 무거웠다.