[HTTP] HTTP 1.1 vs HTTP 2.0 (2)

💡https://gnuoyus.tistory.com/103 에서 발생했던 문제의 이유에 대해서 그냥 내 생각을 써보고 어떻게 해결할 수 있었는지도 생각해보기.

---

HTTP 1.1 vs HTTP 2.0

앞선 글에서 설명했던 HTTP 2.0은 1.1의 성능을 향상 시키고 개선한 프로토콜입니다.

HTTP 1.1의 문제점은 아래와 같습니다.

1. HOL Blocking

2. Header가 너무 무겁다.

 

HOL Blocking

HTTP 1.1을 이용할 때 HOL Blocking이라는 문제가 발생한 이유는 하나의 연결에서 더 많은 데이터를 주고 받고 싶은데 이를 해결하기 위해서 pipelining을 이용했기 때문입니다.

그럼 pipelining이 뭘까요?? 특정 명령어를 여러 개로 나누어서 단계별로 나누고 중첩적으로 실행해서 직렬적인 처리를 병렬적으로 수행함으로써 성능을 높인다는 개념입니다.

그럼 pipelining에서 발생할 수 있는 문제점을 알아봅시다. 

1. 구조적 헤저드 : 같은 클럭 사이클에서 실행하기 원하는 명령어의 조합을 구조적으로 하드웨어에서 지원하지 않는 경우 발생하는 헤저드입니다. 
2. 데이터 헤저드 : 이전 단계의 결과가 명령을 수행함에 있어 필수적인 경우에 다른 명령의 결과를 기다린 다음에 수행하기 때문에 파이프 라인이 지연되는 현상이 발생합니다.
3. 컨트롤 헤저드 : 분기 명령어처럼 다른 명령들이 실행 중에 한 명령어의 결과 값에 기반을 둔 결정을 할 필요가 있는 경우에 발생하는 헤저드입니다. 

Web의 관점에서 파이프라이닝을 사용한다고 가정했을 때 구조적 헤저드나, 컨트롤 헤저드는 발생할 수 없습니다. 왜냐면 요청 간에 독립적이기 때문에 발생할 수 없지만 데이터 헤저드는 발생합니다. 결국 파이프라이닝이 완벽한 병렬처리가 아니라서 하나의 커넥션에서 병렬적으로 처리하기 위해서 이렇게 구현한 것이기 때문에 이전의 요청에 대한 응답을 받아야 한다는 지연이 발생할 수 밖에 없습니다. 네트워크 간의 신뢰성을 위해선 하나의 연결에서의 요청이 동일한 순서로 응답되어야 하는 것도 당연합니다. 

그러다 보니까 앞의 요청이 겁나 오래 걸리면 당연히 지연이 발생할 것이고 HOL Blocking이 발생을 한다라고 생각합니다.

HTTP 2.0에서는 multiplexing을 이용해서 모든 걸 해결.

멀티플렉싱을 이용해서 여러 요청과 응답을 상호 독립적으로 받을 수 있게 구현했습니다.

멀티플렉싱이 뭐고 왜 해결할 수 있는거죠??

멀티플렉싱은 여러 데이터 스트림이 단일 통신 채널을 공유하는 통신 기술입니다. 그러니까 TCP/IP를 이용한 하나의 통신 연결을 이용해서 HTTP 요청이 여러 데이터 스트림을 이용해 요청되니까 이전 요청을 기다릴 필요가 없겠져? 그럼 요청에 대한 응답을 어떻게 판단하지?? 원래는 순서대로 오니까 판단하기 쉬웠는데,,, 요거는 스트림 식별자라는 고유한 식별자를 할당해서 순서에 상관없이 보내고 받을 수 있는 것 입니다. 

HTTP 2.0에서는 바이너리 프로토콜을 사용하고 스트림 멀티플렉싱을 지원해서 단일 TCP 연결을 통해서 여러 요청과 응답을 동시에 보내고 받는 형식으로 이용됩니다. 

멀티 플렉싱 이용해서 HOL Blocking만 해결한게 아니라 Header의 압축도 이를 통해서 결국 해결한 겁니다.

왜냐면 멀티 플렉싱을 이용하면 하나의 TCP 연결에서 여러 HTTP 요청이 가능하죠? 그럼 하나의 TCP 연결을 공유하니까 이전 HTTP 요청들에서 사용된 헤더들을 테이블에 저장하고 이후의 HTTP 요청에서는 이 동적 테이블을 참조해 인코딩하여 헤더 크기를 줄일 수 있는거죠.

그럼 헤더 크기가 줄어들면 전송 간 데이터 양이 줄고 로드하는 시간을 줄이니까 더 빠르게 웹 페이지가 로딩될 수 있겠져?

---

마무리

HTTP 1.1의 성능을 향상 시키고 개선한 HTTP 2.0에서 어떻게 할 수 있었는지를 그냥 제가 알고 있는 지식들이랑 제 생각대로 적어봤기 때문에 틀릴 가능성이 매우 높습니다 ,,,

그래서 만약 잘못된 정보가 있다면 댓글로 말해주세요!!