본문 바로가기

좋은 글

HTTP/3 출현

반응형

우리는 지금 대부분 HTTP/1.1을 쓰고 있다.
일부 HTTP/2를 쓰는 경우도 있지만 아직 보편적으로 쓰이지는 않고 있다고 보면 된다.
Fiddler나 WireShark를 돌려 보면 거의 모든 패킷의 헤더에 HTTP/1.1이라고 나온다. (사실 HTTP/2를 못 봤다.)

그런 상황에서 HTTP/3이 출현했다.

https://evan-moon.github.io/2019/10/08/what-is-http3/

 

HTTP/3는 왜 UDP를 선택한 것일까?

HTTP/3는 HTTP(Hypertext Transfer Protocol)의 세 번째 메이저 버전으로, 기존의 HTTP/1, HTTP/2와는 다르게 UDP 기반의 프로토콜인 QUIC을 사용하여 통신하는 프로토콜이다. HTTP/3와 기존 HTTP 들과 가장 큰 차이점이라면 TCP가 아닌 UDP 기반의 통신을 한다는 것이다.

evan-moon.github.io

 

게다가 전통적인 TCP(transmission control protocol) 방식이 아닌 UDP(user datagram protocol) 방식을 선택했다고 한다.
위 블로그에 자세히 설명되어 있지만 스압도 있고, 전문적인 내용이라 내가 요약해 봤다.

 

1. TCP는 통신을 시작할 때 준비하는 구간이 길다.
통신 준비 오바, 번호 1000번 -> 받을 준비 됐다 보내라 오바, 번호 1001번 -> 보내겠다 오바, 1002번
이렇게 준비가 된 후에야 보내게 된다.
준비할 때 보내는 번호는 순서인데, 이 순서를 지키면서 데이터를 보내야 받은 쪽에서 뒷 번호를 먼저 받는 일이 생기더라도 조립을 순서대로 할 수 있게 된다.

2. UDP는 준비하는 구간이 없거나 짧다.
통신 준비 오바, 데이터도 같이 보냄 -> 받을 준비 됐다 오바, 데이터도 같이 왔네. 처리해야지 끝
통신 준비 구간에 데이터도 같이 보낼 수 있기 때문에 준비없이 바로 통신 한 번으로 끝날 수도 있다.

3. 그럼 순서가 엉켜서 데이터가 보내지면? 아니면 중간에 손실이 있으면?
순서가 엉킨 부분은 잘 이해를 못 했는데, 아마 보내는 데이터에 순번이 있을 것 같다.
그렇게 모아서 데이터를 조립했는데 손실이 있는 경우라면 이레이저 코드라는 것을 같이 보내서 해결한다.

내 기억에는 외우주 탐사를 위한 위성과 통신할 때 이런 방법을 쓰는데,
패킷마다 패리티 비트와 보정 비트(?)를 보내서 패리티 체크에서 오류가 나면 보정 비트로 데이터를 살릴 수 있는데
8비트 데이터일 때 패리티 1비트, 보정 1비트, 데이터 6비트를 보내기 때문에 속도는 조금 느려지지만,
손실 패킷을 다시 받기 어려운 경우에 쓴다고 배운 기억이 있다. (20년 전이라 정확한 기억은 아닐 거다.)

4. 그럼 암호화는?
요즘 HTTPS라고 암호화 통신이 기본이 되었다.
HTTP/3도 암호화를 지원해야 할 텐데 UDP 기반으로 어떻게 암호화를 하나?

"첫 요청을 보낼 때는 서버의 세션 키를 모르는 상태이기 때문에 목적지인 서버의 Connection ID를 사용하여 생성한 특별한 키인 초기화 키(Initial Key)를 사용"하고, 이후에는 서버에서 제공하는 TLS 기반 공개키를 이용한다고 한다.

5. 그 외
한 번 통신을 연결한 후에는 해당 연결에 대한 정보를 저장하고 있다가 다음 연결에는 그 정보를 이용해서 통신한다.
안 그래도 짧은 준비 구간을 없앨 수 있다.

이 때 저장하는 정보 중에 서버의 Connection ID도 저장해 두고 이를 이용해 통신을 하기 때문에, 단말의 아이피가 바뀌더라도 서버에서는 같은 단말로 인식하고 통신이 끊기지 않게 된다.
휴대전화처럼 이동하면서 사용하는 경우, 아이피가 바뀌는 경우가 잦은데 그럴 경우 로그인을 다시 하는 등의 불편을 HTTP/3에서는 해결할 수 있게 된다.
물론 기존 사이트들이 그 방식을 지원해야겠지만.

 

내가 이해한 만큼 요약을 했는데, 잘 전달이 되었는지 모르겠다.
원본이 훨씬 정보가 많으니 일독을 권한다.

반응형