[웹 성능 최적화] 웹 프로토콜 최적화

1. HTTP의 발전

 

(1)  : 

 

- HTTP/0.9 :  웹 콘텐츠를 요청하는 GET 메소드만 존재하고 HTML만 읽을 수 있고, 클라이언트의 정보를 서버에 전달할 방법은 없었다. 

 

- HTTP/1.0 : HTTP 페이로드 외에도 헤더를 통해 클라이언트와 서버의 정보를 전달할 수 있다. 또한 이미지나 동영상 등 다양한 정보를 주고받을 수 있게 되었다. POST 메소드를 추가하여 클라이언트의 정보를 웹 서버로 전달하는 방법도 지원하기 시작했다. Content-Encoding 헤더를 통해 클라이언트 - 서버 간 지원하는 압축 알고리즘 정보를 서로 공유함으로써 압축을 지원한다.

 

(2) HTTP/1.1 : 

- HTTP의 첫 번째 공식 표준 버전이다. GET, POST 외에 PUT, DELETE를 이용해 파일 업로드, 웹 서버의 내용을 삭제 가능해졌다. 

 

- Via 헤더를 사용해 중계 서버 정보를 공유하고 Accept 헤더로 클라이언트가 어떤 형식의 콘텐츠를 지원하는지 미리 서버에 알려줄 수 있게 된다.

 

- 하나의 TCP를 재사용해 많은 콘텐츠를 전달할 수 있는 지속적 연결 기술이 추가되었다.

 

- 파이프라이닝 : 브라우저가 웹 서버에 여러 개의 콘텐츠를 요청했을 때, 이전 요청에 대한 응답을 완전하게 받지 않더라고 하나의 TCP 연결 내에서 미리 다음 요청에 대한 처리를 시작하면서 전체적인 전달 시간을 줄이는 방식이다.

 

- HTTP/1.1의 문제점(HOL) :

통신에 순서가 있다. 서버가 하나의 요청에 응답을 지연하면 나머지 모든 요청 역시 지연되는 문제가 있다.

 

(3) HTTP/2 : 텍스트 방식의 프로토콜 메시지를 과감히 버리고 이진 포맷을 사용하여 프로토콜 자체를 경량화 하였다. 

 

- 멀티플렉싱, 스트림 우선순위 설정, 헤더 압축, 서버푸시 같은 프로토콜 최적화 기능이 추가되었다.

 

- HTTP의 HOL 문제를 해결했지만, TCP의 HOL문제는 해결하지 못했다.

 

(4) HTTP/3 : QUIC을 사용하는 HTTP 최상위 버전이다.

 

- QUIC의 가장 큰 특징은 UDP를 사용한다는 점이다. UDP 프로토콜 구조가 최적화를 진행하기 더 쉬운 형태이기 때문에 HTTP/3은 UDP를 사용한다.

 

- QUIC 연결을 최대한 재사용하는 구조이므로 클라이언트와 서버 간 연결을 만드는 과정에서 소모되는 시간이 대폭 줄었다.

 

 

 

 

2. HTTP/2의 최적화 기술

 

(1) : HTTP/2의 가장 큰 목표는 클라이언트와 서버가 콘텐츠를 주고받는 시간을 줄이고, 서버 응답이 느린 콘텐츠가 다른 정상적인 콘텐츠의 전달을 방해하지 않도록 하는 것이다.

 

- 이를 위해 이진 프레임으로 바꾸어 프로토콜을 좀 더 가볍고 유연하게 만들었다.

 

- 중복 헤더 값을 걸러내고, 전송해야 하는 값을 기존과 다르게 압축해 헤더의 크기를 최소화했다.

 

- 서버 푸시 : 서버 푸시 통해 클라이언트가 요청하지 않은 콘텐츠도 서버가 미리 빠르게 전송하여 RTT를 더욱 최소화했습니다.

 

(2) HTTP/2의 이진 프레임 : 

 

- HTTP/2 구성 :

기존 1.1 버전의 메시지 단위 외에도 프레임, 스트림이라는 단위가 추가되었다. 3개의 단위의 구조를 이해해야 한다.

1. 프레임 :  HTTP/2 통신상 제일 작은 정보 단위이며 헤더나 데이터 중 하나이다.

2. 메시지 : HTTP/1.1 마찬가지로 요청 혹은 응답 단위이며 다수의 프레임으로 이루어져 있다.

3. 스트림 : 클라이언트와 서버 사이 맺어진 연결을 통해 양방향으로 주고받는 하나 혹은 복수의 메시지다.

 

- 여러 개의 프레임이 모여 메시지가 되고, 여러 개의 메시지가 모여 스트림이 되는 구조이다.

 

- HTTP/2에서는 스트림이라는 단위를 통해 요청과 응답이 하나의 단위로 묶일 수 있는 구조가 만들어졌다.

 

- 스트림 방식을 사용함으로써 동시 요청 및 응답할 수 있는 오브젝트의 개수가 많아졌다.

 

- 스트림을 통해 웹상에서도 콘텐츠를 연속적으로 주고받음으로써 더 유연한 요청관 응답 구조를 가진다.

 

- HTTP/2에서는 하나의 TCP 연결을 통해 다수의 클라이언트 요청과 서버 응답이 비동기 방식으로 이루어지는 멀티플렉싱이 사용됩니다.

 

(3) 멀티플렉싱 :

 

- 파이프라이닝 기능을 개선한 것이다. 먼저 요청한 콘텐츠 전달이 완료되지 않아도 다음 콘텐츠를 미리 처리하면서 웹 성능을 더욱 빠르게 만들기 위해 개발된 기능이다. 하지만 여전히 선입 선출 방식이다. 

- 응답 프레임들은 요청 순서에 상관없이 만들어진 순서대로 클라이언트에 전달될 수 있다.

 

- 하나의 TCP 연결상에서 다수의 클라이언트 요청과 서버의 응답이 비동기 방식으로 이어지는 기술을 멀티플렉싱이라 한다. 

 

(4) 헤더 압축 :

- HTTP.2는 클라이언트와 서버 사이에 가상 테이블을 만들어서 동일하고 중복되는 헤더 값들을 테이블에 저장하고 참고하는 방식을 사용해 중복 전달을 제거한다. 가상 테이블은 정적 테이블과 동적 테이블로 나눌 수 있다.

 

- 정적 테이블 : 미리 정의된 자주 사용되는 헤더 필드를 저장한다.

 

- 동적 테이블 : 클라이언트와 서버가 통신하며 주고받는 값들을 업데이트한다.

 

- HPACK : 허프만 알고리즘 방식으로 헤더를 압축하여 좀 더 경량의 데이터를 주고받을 수 있게 되었다.

 

(5) 서버 푸시 : 

 

- 서버 푸시는 클라이언트가 특정 콘텐츠를 요청하면 서버는 이후 추가될 요청을 미리 예상하고 요청 없이도 응답한다는 의미이다.

 

- 서버 푸시 대상은 웹 서버 관리자나 개발자가 미리 정할 수 있다.

 

 

 

 

3. HTTP/3의 최적화 기술

(1) QUIC : 

구글이 개발한 전달 계층 프로토콜이다. UDP를  채택해 전달 속도 향상과 클라이언트와 서버의 연결 수를 최소화하고 대역폭을 예상해 패킷 혼잡을 피한다.

 

- QUIC은 이전에 클라이언트가 한 번이라도 접속했더 서버라면, 별도의 정보 교환 없이 바로 데이터를 보내는 기술이다.

 

(2) HTTP/3의 등장 배경 : HTTP/3은 새로운 기능을 추가하기보다 QUIC이라는 UDP 기반의 프로토콜을 사용해 TCP가 가지고 있는 HTTP/2의 단점을 보완하는데 중점을 두었다.

 

(3) HTTP/3의 특징 : 

 

- 

HTTP/3의 가장 큰 특징은 HTTP를 QUIC  위로 위치시켰다는 것이다.

 

- UDP의 빠른 성능, QUIC의 효율성, TLS 1.3의 보안성까지 갖는다.

 

(4) HTTP/3의 지원하는 제품군 : HTTP/3 사용하려면 클라이언트와 서버 모두  HTTP/3을 지원해야 한다.