Http3

Http2의 단점

TCP 고유의 문제

Http2 까지 모든 Http 프로토콜은 신뢰성을 높이기 위해 TCP를 사용하고 있었습니다. 신뢰성을 높이기 위해 TCP는 몇 가지 방법을 사용하는데 이 방법을 또한 클라이언트와 서버 간의 통신이기 때문에 레이턴시가 발생할 수 밖에 없습니다. 대표적으로 3 Way Handshake와 4 Way Handshake가 있습니다. 물론 Http2 에서 많이 개선되었지만 TCP를 사용하는 이상 Handshake는 반드시 있어야 하는 과정이기 때문에 레이턴시는 여전히 존재합니다.

Head of line Blocking(HOLB)

TCP를 사용한 통신에서 패킷은 무조건 정확한 순서대로 처리되어야 합니다. 수신 측은 송신 측과 주고받은 시퀀스 번호를 참고하여 패킷을 재조립해야하기 때문입니다. 그래서 통신 중간에 패킷이 손실되면 완전한 데이터로 다시 조립할 수 없기 때문에 해당 패킷을 다시 받아야합니다. 또한 패킷이 처리되는 순서도 정해져 있어서 이전에 받은 패킷을 파싱하기 전까지는 다음 패킷을 처리할 수도 없습니다.

Http3

Http3는 UDP를 기반으로하는 QUIC를 사용합니다. QUIC는 TCP의 핸드쉐이크 과정을 최적화 하는 것에 초점을 맞추어 설계되었습니다.

QUIC 도입으로 Http3가 가지는 장점

연결 설정 레이턴시 감소

QUIC는 TCP를 사용하지 않기 때문에 3Way Handshake 과정을 거치지 않고 클라이언트가 서버에 요청을 한번 보내면 서버도 바로 응답하면서 본 통신을 시작할 수 있습니다. TCP + TLS는 데이터를 보내기 전에 신뢰성있는 연결과 암호화에 필요한 모든 정보를 교환하고 유효성 검사를 한 이후에 데이터를 교환합니다. 하지만 첫 Handshake를 거칠 때 연결 설정에 필요한 정보와 함께 데이터도 전송합니다.

단, 클라이언트가 서버로 첫 요청을 보낼 때는 서버의 세션 키를 모르는 상태이기 때문에 목적지인 서버의 Connection ID를 사용하여 생성한 Initial Key를 사용하여 통신을 암호화합니다. 그리고 연결에 성공하면 서버는 설정을 캐싱하고 있다가 다음 연결 때는 캐싱해놓은 설정을 사용하여 바로 연결을 성립시킵니다.

패킷 손실 감지에 걸리는 시간 단축

TCP는 여러 ARQ 방식 중에서 Stop And Wait 방식을 사용합니다. 이 방식은 송신 측이 패킷을 보낸 후 타이머를 사용해 시간을 재고 일정 시간이 경과해도 수신 측이 적절한 답변을 주지 않는다면 패킷이 손실된 것으로 판단하는 방식입니다. 그리고TCP에서 패킷 손실 감지를 하는 방법은 타임스탬프를 사용해 타임아웃을 동적으로 계산하는 방법을 사용합니다.

QUIC는 헤더에 별도의 패킷 번호 공간을 부여합니다. 이 패킷 번호는 패킷의 전송 순서 자체만을 나타내며 재전송시 동일한 번호가 전송되는 시퀀스 번호와는 다르게 매 전송마다 패킷 번호가 증가하기 때문에 패킷의 전송 순서를 명확하게 파악할 수 있습니다. TCP의 경우 타임스탬프를 통해 패킷의 전송 순서를 파악하지만 이를 사용할 수 없는 경우 시퀀스 번호에 기반하여 암묵적으로 전송 순서를 추론할 수 밖에 없습니다. 하지만 QUIC는 패킷 번호를 통해 감지 시간을 단축할 수 있습니다.

클라이언트의 IP가 바뀌어도 연결이 유지됨

TCP의 경우 소스의 IP 주소와 포트, 연결 대상의 IP 주소와 포트로 연결을 식별하기 때문에 클라이언트의 IP가 바뀌는 상황이 발생하면 연결이 끊어지고 다시 3 Way Handshake 과정을 거치며 latancy가 발생합니다. 요즘에는 모바일로 인터넷을 상요하는 경우가 많기 때문에 Wifi에서 셀룰러로 전환되거나 하는 등 클라이언트의 IP가 변경되는 일이 잦아서 이 문제가 더 눈에 띕니다.

반면 QUIC는 Connection ID를 사용하여 서버와 연결을 생성합니다. Connection ID는 랜덤한 값일 뿐 클라이언트의 IP와는 전혀 무관한 데이터이기 때문에 클라이언트의 IP가 변경되더라도 기존의 연결을 계속 유지할 수 있습니다.