🌍

bb7.1.1.4. title: HTTP가 주로 사용하는 TCP의 오버헤드를 최소화하기 위해 연결이 지속가능하게 하거나(HTTP2.0) UDP를 기반으로 새로운 프로토콜을 정의하여 HTTP의 기본 전제인 신뢰성(reliablity)을 확보하려는 시도도 있다(HTTP3.0).

생성

🚀 prev note

♻️ prev note

bc9.3_1. title: OSI 7계층 구조를 단순화한 TCP IP 모델은 TCP 또는 UDP 시스템 위에서 HTTP가 작동함을 시사한다. 예를 들어 브라우저는 자신이 받은 데이터가 TCP를 통해 받은 것인지 UDP를 통해 받은 것인지 신경쓰지 않아도 된다.

🚀 next note

♻️ next note

14 more properties

HTTP는 TCP를 강제하지 않으나, 신뢰성을 요구한다. 그래서 모두가 ‘TCP 위에 쌓아올렸다’ 라고 이해하고 있고(ref1), 대부분의 경우 이러한 생각은 틀리지 않는다. 한편 사람들은 점점 웹으로 실시간 스트리밍을 하는 등 더 많은 것들을 하고자 하지만, TCP 위에 쌓아올린 HTTP라는 프로토콜은 TCP의 한계를 그대로 떠안는다는 문제가 있었다(ref2).

HTTP2.0 에서는 HTTP가 주로 사용하는 TCP의 오버헤드를 최소화하는 방식으로 발전했다(ref2,ref3). 한편, HTTP3.0 에서는 UDP를 기반으로 완전히 새로운 프로토콜을 정의하여 HTTP의 기본 전제인 신뢰성(reliablity)을 확보하는 동시에 TCP의 속도 문제에서 자유로워지기 위해 노력하고 있다(ref2).

parse me : 언젠가 이 글에 쓰이면 좋을 것 같은 재료을 보관해 두는 영역입니다.

None

from : 과거의 어떤 원자적 생각이 이 생각을 만들었는지 연결하고 설명합니다.

•

HTTP는 기본적으로 느리다. 하지만 웹이 보편화되며 사람들이 HTTP를 이용해 많은 것들을 하려고 하다 보니 빨라질 필요가 생겨난 것이다.

bc9.3_1. title: OSI 7계층 구조를 단순화한 TCP IP 모델은 TCP 또는 UDP 시스템 위에서 HTTP가 작동함을 시사한다. 예를 들어 브라우저는 자신이 받은 데이터가 TCP를 통해 받은 것인지 UDP를 통해 받은 것인지 신경쓰지 않아도 된다.

•

애플리케이션 레이어의 HTTP는 전송 계층 프로토콜을 골라 사용할 수 있다. 만약 새로운 전송 계층 프로토콜을 정의한다면, 그것을 사용하면 된다. 대부분의 HTTP 오버헤드는 TCP에서 온다.

supplementary : 어떤 새로운 생각이 이 문서에 작성된 생각을 뒷받침하는지 연결합니다.

None

opposite : 어떤 새로운 생각이 이 문서에 작성된 생각과 대조되는지 연결합니다.

None

to : 이 문서에 작성된 생각이 어떤 생각으로 발전되거나 이어지는지를 작성하는 영역입니다.

None

ref : 생각에 참고한 자료입니다.

HTTP 명세에 TCP를 사용해야 한다고 명세되어 있다. 따라서 HTTP프로토콜을 사용할 때 TCP를 이용하는 것은 불가능하다. 하지만 최근에는 TCP도 아니고, UDP도 아니지만, UDP에 영감을 받아 만들어진 QUIC이라는 전송 계층 프로토콜이 있다. 이를 이용하면 HTTP를 이용하면서도 TCP와 UDP의 장점을 살릴 수 있다.

HTTP/3이 UDP 기반인 QUIC 프로토콜을 사용하는 이유가 바로 이런 제약 조건을 뛰어넘기 위해 프로토콜 자체를 손보는 방법을 택한 것이다. 하지만 TCP는 워낙 오래된 프로토콜이기도 하고 커널까지 내려가는 로우 레벨에서 정의되어 있기 때문에 이걸 뜯어고치는 것도 만만치 않은 대작업이라 UDP를 선택한 것이다. … TCP는 굉장히 친절한 프로토콜이다. 통신을 시작할 때와 종료할 때 서로 준비가 되어있는지를 반드시 먼저 물어보고 패킷을 전송할 순서를 정하고 나서야 본격적인 통신을 시작하기 때문이다. 이때 통신을 시작할 때 거치는 과정을 3 Way Handshake, 통신을 마칠 때 거치는 과정을 4 Way Handshake라고 한다. … TCP를 사용하는 이상 본격적인 통신을 시작하기 전에 무조건 저 번거로운 통신 과정을 거쳐야한다는 것이다. … HTTP/1은 하나의 TCP 연결에 하나의 요청만 처리하고 연결을 끊어버렸기 때문에 매 요청마다 이 번거로운 핸드쉐이크를 거쳐야 했다. 그래서 HTTP/2에서는 핸드쉐이크를 최소화하기 위해서 단일 TCP 연결을 유지하면서 여러 개의 요청을 처리할 수 있도록 변경된 것이다. 결국 HTTP/1에서 HTTP/2로 넘어갈 때도 핸드쉐이크 과정 자체는 건드리지 않았고 단지 핸드쉐이크가 발생하는 횟수를 최소화함으로써 레이턴시를 줄인 것이다. 이는 TCP를 사용하는 이상 핸드쉐이크가 반드시 필요한 과정이기 때문에 건드리지 못한 것이다.

http/1.1은 기본적으로 클라이언트의 요청이 올때만 서버가 응답을 하는 구조로 매 요청마다 connection을 생성해야만 합니다. cookie 등 많은 메타 정보들을 저장하는 무거운 header가 요청마다 중복 전달되어 비효율적이고 느린 속도를 보여주었습니다. 이에 http/2에서는 한 connection으로 동시에 여러 개 메시지를 주고 받으며, header를 압축하여 중복 제거 후 전달하기에 version1에 비해 훨씬 효율적입니다.