[네트워크] HTTP 심화-(2)HTTP/2 vs HTTP/3

1. HTTP/2

2009년 구글은 HTTP/1.1의 한계를 극복하기 위해 SPDY 프로토콜을 개발했습니다. 이후 2015년, SPDY를 기반으로 하는 HTTP/2 프로토콜을 만들었습니다. 

(1) 바이너리 포맷 계층

 

애플리케이션 계층과 전송 계층 사이에 바이너리 포맷 계층을 추가합니다.

HTTP 1.0은 일반 텍스트 메시지를 전송하고 줄바꿈으로 데이터를 나눴다면,

HTTP 2.0은 0과 1로 이루어진 바이너리 데이터로 변경되었고, 더 작은 메시지가 프레임으로 캡슐화되어 전송됩니다.

 

 

(2) 멀티플렉싱

단일 TCP연결의 여러 스트림에서 여러 HTTP 요청과 응답을 비동기적으로 보낼 수 있습니다. 이를 통해 HOL을 해결합니다. 

1.1에서는 병렬요청을 하려면 다중TCP연결을 통해서 하고 일반적으로는 TCP연결 하나당 병렬요청은 불가능했습니다.

2에서는 리소스를 작은 프레임으로 나누고 이를 스트림을 프레임을 전달합니다. 각각의 프레임은 스트림ID, 해당 chunk의 크기를 나타내는 프레임이 추가되었기때문에 작게 나눠서 다운로드가 되더라도 결과적으로 응답데이터에서는 올바른 순서로 재조립할 수 있게 됩니다.

(3) 서버푸시

 

서버가 리소스를 클라이언트에 푸시를 할 수 있습니다.

요청된 html파일과 함꼐 다른 개체를 별도로 보낼 수 있습니다.

만약 요청한 html에 Css 포함되어있다면 별도 요청 없이 css를 같이 보낼 수 있습니다. 

 

 

(4) 헤더 압축

1.1에서는 무거운 헤더가 있었지만 이를 허프만 인코딩 압축방법 등으로 압축시킵니다. 똑같은 서버에서 2개의 이미지를 준다고 했을 때 중복되는 헤더는 제외한채 보내고 해당 공통필드로 헤더를 재구성하며 중복되지 않은 헤더값은 허프만 인코딩 압축방법으로 압축해 전송합니다

** 허프만 인코딩: 문자열을 문자 단위로 쪼개 빈도수를 세어 빈도가 높은 정보는 적은 비트수를 사용해 표현하고, 빈도가 낮은 정보는 비트 수를 많이 사용하여 전체 데이터 표현에 필요한 비트 양을 줄이는 알고리즘

(5) 우선순위

서버에서 원하는 순서대로 우선순위를 정해 리소스를 전달할 수 있습니다. 

2. HTTP/3

드디어 HTTP마지막 3 입니다!! 

2는 여전히 TCP를 사용하기 때문에 초기 연결에 대한 RTT로 인한 지연시간이라는 문제점이 있었고 이를 해결하기 위해 나온게 3입니다!!

QUIC(Quick UDP Internet Connections)라는 계층 위에서 돌아가며, TCP기반이 아닌 UDP기반으로 돌아가며 2에서 장점이었던 멀티플렉싱 등을 가지고 있으며, 초기연결설정시 지연시간 감소라는 대표적 특징을 가지고 있습니다. 

2의 경우 3-RTT가 필요했다면, QUIC는 1-RTT만 필요하다는 장점이 있습니다!!

2의 경우 클라이언트와 서버간의 연결을 맺어 세션을 만드는데 필요한 핸드셰이크, 암호화통신을 구축하기 위한 TLS핸드셰이크가 각각 필요했습니다. 

3에서는 TLS로 암호화통신을 구축할 때 단 한번의 핸드셰이크를 활용해 클라이언트와 서버간의 연결, 암호화 통신 모두 다 구축을 합니다. 이를 통해 1-RTT만에 모든 연결을 성립할 수 있었습니다.

또한, 전송된 패킷이 손실되었다면 수신측에서 에러를 검축하고 수정하는 방식이며 열악한 네트워크 환경에서도 낮은 패킷손실률을 자랑하는 순방향 오류 수정 매커니즘(FEC, Forward Error Correction)이라는 특징을 가집니다. 

---

이렇게 1.0부터 시작해서 3까지 HTTP의 역사에 대해서 알아보았습니다. 사실 HTTP안에서 개념이 더 있고 헤더,바디만해도 다뤄야 할 내용이 엄청 많은데, 이것들도 다음에 한번 정리해서 올려보도록 하겠습니다 ^^7

 

다음 포스팅에서는 3차프로젝트에서 사용했던 HTTPs에 대해 올려보도록 하겠습니다 ㅎㅎ