[네트워크] HTTP/1.1 와 HTTP/2 의 차이점

CS/Network

GaGah 2023. 4. 22. 16:43

👩‍💻 HTTP란?

Hypertext Transfer Protocol 의 약자로, HTML 등의 문서를 주고 받는 프로토콜이다.

WEB에서 이루어지는 모든 데이터 전송 및 응답의 기본이라고 생각하면 된다.

추가) OSI계층의 Application Layer 프로토콜

하나의 데이터를 전송하기 위해서 하나의 TCP Connection을 맺어야 한다.

TCP는 신뢰성 있는 데이터 전송을 위해 연결 시 3-way handshake, 연결 해제 시 4-way handshake 과정을 거치며

결국, 여러 API 호출 시 Latency 증가 는 너무 당연한 얘기다.

너무 비효율이여서 HTTP Header 에 Keep-alive 옵션을 사용하여 일정 시간동안 Connection을 끊지 않는 방식도 사용이 되었다.

그러나, HTTP/1.0 에서는 표준이 아니었기 때문에 지원이 안되는 곳도 있었다.

Connection : keep-alive

HTTP/1.0의 단점을 해소하고자, HTTP/1.1이 등장하였다.

지정한 timeout 시간 동안 Connection을 끊지 않는다는 컨셉

하나의 Connection에 여러 개의 요청과 응답을 주고 받을 수 있다.

HTTP/1.0에서는 해당 기능을 사용하기 위해 Header에 keep-alive를 Client가 작성해줘야 되지만,

HTTP/1.1에서는 기본적으로 keep-alive 기능을 지원하고(Client가 작성하지 않아도), 필요 없는 경우만 작성해주면 된다.

Connection : close

첫 번째 요청을 보낸 뒤, 응답을 받지 않아도 두 번째 Request 를 보낼 수 있게 한다.

단, 요청을 보낸 순서에 맞도록 응답이 와야한다.(순서보장)

그렇기 때문에, 첫 번째 응답이 느리게 오면, 두 번째/세 번째 응답에도 지연이 발생한다.

대부분의 서버는 멀티 스레드 구조로 1,2,3번째 응답을 동시에 처리하게 되는데, 서버에서도 1번째 응답을 제공해주기 전까지는 2,3번 데이터를 가지고 있어야 해서 리소스 낭비도 함께 일어난다.

이 문제가 바로 Head of Line Bloking 이다.

Header 프레임과 데이터 프레임으로 나눈 후, 압축하여 데이터를 전송한다.

파이프라이닝과 다르게 요청의 순서대로 응답을 제공해줄 필요 없이

병렬적으로 진행하며 빨리 끝난 요청부터 처리하여 전송해준다.

HTTP/1.1 에 비해 latency가 줄어들었지만, TCP 특성에 따른 TCP Head of Line Bloking 문제가 발생했다.

아래 그림의 TCP Connection을 주목해보자.

TCP 전송을 할 때, 데이터가 나뉘어져 전송이 되는데

만약, 3번의 패킷이 전송 중 누락(?)되어 재전송이 일어나면 그 뒤에 있는 모든 패킷들은 지연이 된다.

TCP의 신뢰성 있는 데이터를 전송하기 위한 특성에서 발생하는 TCP Head of Line Bloking 문제이다.

HTTP/2의 TCP Head of Line Blocking 문제를 보완하기 위해서 나타난 Application 계층 프로토콜

UDP 사용을 하여 신뢰성 있는 데이터 전송하는 컨셉으로 구글에서 만들었다.

UDP 가 신뢰성있는 데이터를 전송한다고? 어떻게 하는거지?

QUIC은 독립 스트림을 만들어 데이터를 전송한다.

즉, 3번이 지연 발생이 된다면, 나머지들은 영향이 없게된다.

LIST