HTTP 1.1/2.0/3.0

HTTP 1.1/2.0/3.0

HTTP 1.1

HTTP/1.1은 1999년에 발표된 HTTP 프로토콜의 최신 버전이며, 이전 버전인 HTTP/1.0보다 개선된 기능을 제공한다. HTTP/1.1에서는 커넥션 관리, 캐시, 프락시 지원, 인증 등의 기능이 개선되었으며, 보안 기능도 추가되었다.

또한, HTTP/1.1은 기본적으로 지속 커넥션(Persistent Connection)을 사용하므로, 클라이언트와 서버 간의 연결을 유지하고, 한 번의 연결로 여러 개의 요청과 응답을 처리할 수 있다. 이로 인해 네트워크 부하를 줄이고, 웹 페이지 로딩 속도를 높일 수 있다.

현재도 많은 웹 브라우저와 웹 서버가 이 버전을 지원하고 있다.

---

HTTP 2.0

2015년 IETF에 의해 공식적으로 발표된 HTTP/1.1의 후속 버전이다. HTTP/2의 차기 버전은 HTTP/3이다.

표준에서 TLS를 요구하는 것은 아니지만, SPDY에서 TLS를 요구했던 여파로 인해 모든 메이저 브라우저들이 TLS없이는 HTTP/2를 지원하지 않고 있다. 즉,TLS가 없으면 무조건 HTTP/1.1로 요청한다.

웹2.0과는 전혀 관계가 없다. 웹2.0은 2004년 나온 웹의 포괄적 개념으로 현재는 사문화되었다. HTTP/2는 프로토콜로 분야가 다르다.

2020년부터 HTTP/3 규격도 진행되고 있으며, 구글이나 유튜브 등의 주요 웹사이트들에서는 이미 적용 중이다.

바이너리 프로토콜을 사용한다.

---

HTTP/1.1에서의 개선점

① Head of line blocking(HOL)

HTTP/1.1까지는 한 번에 한 파일밖에 보내지 못했다. 그래서 특정 파일의 로딩이 늦어지면 다른 파일까지 줄줄이 느려지는 병목 현상이 생기게 된다. 그래서 여러 파일을 한꺼번에 병렬 전송을 하는 식으로 로딩 시간을 줄이는 방법을 사용한다.

② 중복 헤더의 제거

같은 내용의 헤더를 보낼 경우, 생략해버리는 식으로 처리함으로써 속도를 높이는 방식이다.

③ Header compression

이전까지는 HTTP 헤더가 평문이었지만, HTTP/2에서는 헤더를 압축하여 용량 대비 처리 효율성을 높이는 방법을 사용한다. 압축을 하기 때문에 헤더 크기 자체도 크게 줄어든다.

④ Server push

특정 파일을 서버에 지정해서 HTTP 전송 시 같이 밀어 넣는 방식이다. 주로 JavaScript나 CSS, 글꼴, 이미지 파일 등을 지정한다.

⑤ Prioritization

웹 페이지를 구성하는 파일의 우선순위를 둘 수 있다. 로딩이 빨리 되어야 하는 파일과 그렇지 않은 파일을 구분해줄 수 있고, 이들 사이에서도 중요도를 차등 배분할 수 있다.

---

이전까지는 HTTP/2를 지원하는 한국 사이트는 손에 꼽힐 정도였으나, 2020년을 기점으로 꾸준히 증가하여 현재는 대부분의 웹사이트가 지원하고 있다.

하지만, HTTP/2.0을 지원하지 않는 서버나 브라우저가 여전히 많이 사용되고 있다.

HTTP/2.0을 사용하는 경우 일부 사용자들이 웹사이트를 제대로 사용할 수 없는 경우도 있다. 또한, HTTP/2.0은 TCP 커넥션을 유지하는 동안 메모리 사용량이 증가하는 문제가 있을 수 있다.

HTTP/2.0을 사용하기 위해서는 SSL/TLS 암호화가 필수적이다. HTTP/2.0은 바이너리 프로토콜을 사용하여 데이터를 전송하므로, 데이터의 보안성이 중요합니다. 따라서, HTTP/2.0은 반드시 SSL/TLS 암호화된 연결을 사용해야 한다.

실제로, 모든 주요 브라우저에서 HTTP/2.0을 지원할 때는 SSL/TLS 암호화된 연결을 사용해야만 한다. 이를 위해 HTTPS 프로토콜을 사용하여 웹사이트의 보안을 강화하고, HTTP/2.0의 장점을 최대한 활용할 수 있다.

따라서, HTTP/2.0을 사용하려면 SSL/TLS 암호화된 연결을 설정해야 한다. SSL/TLS 인증서를 구매하거나, Let's Encrypt와 같은 무료 인증 기관을 통해 SSL/TLS 인증서를 발급받을 수 있다.

HTTP/1,HTTP/2 성능 비교

---

                              HTTP version 확인 하기

이렇게 Protocol tap에 오른쪽 클릭 후, protocol을 누르면, 해당 웹사이트의 HTTP 버전을 확인가능하다.

안 보인다면 Name tap에서 오른쪽 클릭 하면,

프로토콜을 체크하면 된다.

---

HTTP/3

HTTP의 3번째 메이저 버전으로 HTTP/2의 차기 버전이다. 2022년 6월 6일, IETF RFC 9114로 표준화되었다.

HTTP/1 및 HTTP/2가 TCP로 통신하는 것과는 달리 HTTP/3는 UDP 기반의 QUIC 프로토콜을 사용하여 통신한다. 원래는 이름이 HTTP-over-QUIC였지만, IETF 내에 있는 QUIC 작업 그룹의 의장인 마크 노팅업이 HTTP/3라는 이름을 제안하여 변경되었다. HTTP/3의 기반이 되는 QUIC도 역시 웹 표준이며 RFC 9000으로 표준화되어 있다.

HTTP/2 대비하여 가장 큰 장점 3가지는, Zero RTT(Round Trip Time), 패킷 손실에 대한 빠른 대응, 사용자 IP가 바뀌어도 연결이 유지되는 것이다. 일반적인 웹 환경에서는 HTTP/2와 HTTP/3의 차이가 크지 않을 수 있으나, 동영상 서비스 등에서는 큰 차이를 보인다. 예를들어, 모바일 기기처럼 인터넷 연결 상태가 고르지 못한 경우라든지, WiFi에 연결하여 동영상을 시청하는 도중에 자리를 이탈하여 셀룰러 신호로 바뀌더라도 HTTP/3로 연결되어 있으면 영상을 끊김없이 시청할 수 있다. 패킷 전송에 있어서 제약이 거의 없는 비연결성 전송 계층을 기반으로 TCP 프로토콜의 무결성 보장 알고리즘과 SSL이 이식됨으로써 높은 성능과 동시에 충분히 괜찮은 정확성과 부인방지 특성을 충족시켰다.

HTTP/3와 그 기반 기술인 QUIC은 TLS 암호화를 기본적으로 사용한다. 다만, TLS가 TCP를 염두에 두고 설계되어 있기 때문에 QUIC의 원저작자인 구글의 알고리즘대로 일부 수정을 거쳐서 사용한다. UDP와 TLS가 결합된 기술로는 DTLS라는 기술도 있지만 'TCP의 재구현'이 목표 중 하나인 QUIC와는 지향하는 바가 다르다.

구글 자체 프로토콜이었던 QUIC가 HTTP/3로 표준화됨에 따라서 IETF 측에서는 구글이 독자적으로 개발했던 QUIC 프로토콜의 파편화된 구현 알고리즘을 기존의 다른 프로토콜과 상호운용이 용이하도록 대폭 수정하는 과정을 진행중이다. QUIC 내에서 IETF 표준 대비 가장 큰 파편화를 보인 부분이 보안 소켓이다. IETF는 구글이 자체적으로 개발한 보안 소켓을 IETF 표준 프로토콜인 DTLS로 대체하는 QUIC over DTLS 표준을 만들고 있었지만 QUIC 워킹 그룹에서 다른 방법을 모색하는 것으로 결론짓고 해당 표준의 제작을 중단했다. #

성능이 떨어지는 컴퓨터는 QUIC 프로토콜로 인해 크롬 브라우저가 느려진다. 그럴 때는 주소창에 "chrome://flags/"를 입력해 Experiments로 들어간 다음 Experimental QUIC protocol을 검색하여 비활성화해주면 빨라질 수 있다.

---

HTTP/3가 적용된 사이트

HTTP/3를 지원하는 주요 웹사이트로는,

구글

유튜브

구글이 제공 중인 대부분에 서비스에 적용되어 있다.

네이버

나무위키

페이스북

인스타그램

넷플릭스

줌 비디오 커뮤니케이션

 

 

 

 

 

참고 사이트

1.https://blog.bespinglobal.com/post/http1-1-http2/

HTTP1.1, HTTP2 비교 - BESPIN Tech Blog

2.https://developnote-blog.tistory.com/entry/HTTP20-%EC%A0%81%EC%9A%A9

HTTP/2.0 적용

3.https://pythonblog.co.kr/blog/79/

73 HTTP/2 적용 및 확인하기-curl