Google은 이미 Chrome에서 IETF QUIC 및 HTTP / 3 활성화를 시작했습니다.

Google 발표 며칠 전에 이미 시작되었습니다 Chrome에서 HTTP / 3 및 IETF QUIC 배포 발표에서 그는이 업데이트가 특히 QUIC에 대한 지원과 함께 추가적인 성능 향상을 가져올 것으로 기대한다고 말했습니다.

QUIC는 새로운 네트워크 전송 프로토콜입니다. TCP, TLS 등의 기능을 결합합니다. HTTP / 3은 최신 버전의 HTTP입니다., 대부분의 웹 트래픽을 전달하는 프로토콜입니다. HTTP / 3는 QUIC에서만 작동합니다.

Internet Engineering Task Force (IETF)는 2 년에 HTTP / 2015를 도입했으며, 그 중 가장 큰 개선 사항 중 하나는 멀티플렉싱 지원입니다.

그러나 TCP를 전송 프로토콜로 사용하고 TCP의 손실 복구 메커니즘을 사용했기 때문에 손실 된 패킷으로 인해 모든 활성 트랜잭션에서 지연이 발생할 수 있습니다.

QUIC를 채택함으로써 HTTP / 3는 전송 프로세스를 더욱 향상시킬 수 있습니다.,이 경우 손실 된 패킷은 직접 영향을받는 트랜잭션에만 영향을 미치기 때문입니다.

사실, QUIC는 원래 Google에서 개발했습니다. 2013 년에 처음 발표되었습니다. 그 이후로 프로토콜이 노후화되었으며 현재 Google 트래픽의 XNUMX/XNUMX을 담당하고 있습니다.

그런 다음 2015 년에 QUIC 개발은 인터넷 프로토콜 유지를 담당하는 표준 기관인 IETF의 손에 넘겨졌습니다. IETF는 몇 가지 변경 사항으로 QUIC를 개선했습니다. 현재까지 Google QUIC 및 IETF QUIC의 두 가지 유사하지만 다른 프로토콜이 있습니다.

Google은 항상 자체 버전의 QUIC를 사용했다고 발표했습니다.,하지만 그의 QUIC 팀은 IEFT의 독점 버전 구현에도 관여하고 있습니다. "우리는 IETF의 변경 사항을 따라 잡기 위해 지난 XNUMX 년 동안 Google QUIC을 발전시키기 위해 상당한 노력을 기울였습니다. 현재 최신 버전의 Google QUIC은 IETF QUIC와 많은 유사점을 가지고 있습니다."Google의 블로그 게시물은 다음과 같습니다. 게다가, 일부 항목이 아직 누락되었음을 명확히했습니다.

예를 들어 지금까지 대부분의 Chrome 사용자는 IETF QUIC 서버와 통신 할 수 없습니다. 일부 명령 줄 옵션을 활성화하지 않고. 마찬가지로, Google은 이제 IETF QUIC가 HTTP를 훨씬 능가한다는 사실을 발견했다고 덧붙였습니다. TCP에 비해 TLS 1.3과 비교됩니다.

특히 구글의 검색 엔진 지연 시간이 2 % 이상 줄었다 고 밝혔다. YouTube의 버퍼링 시간이 9 % 이상 단축되었습니다. 또한 데스크톱 컴퓨터에서 클라이언트 성능이 3 % 이상 향상되었습니다.

휴대폰에서 고객 성과가 7 % 이상 증가했습니다.. 이러한 이유와 기타 이유는 Chrome이 IETF의 QUIC 버전으로 전환 한 뒤에 있습니다. “Chrome이 IETF QUIC (특히 h3-29 파일럿 버전)에 대한 지원을 구현하고 있음을 발표하게되어 기쁘게 생각합니다.

현재 Chrome의 안정적인 버전 사용자의 약 25 %가 h3-29를 사용하고 있으며 성능 데이터를 지속적으로 모니터링하여 향후 몇 주 내에이 숫자를 늘릴 계획입니다.”라고 회사는 블로그 게시물에서 밝혔다.

"Chrome은 IETF QUIC h3-29 및 Google QUIC (Q050) 버전을 모두 적극적으로 지원하여 Q050을 지원하는 서버가 IETF QUIC로 업그레이드 할 수있는 시간을 확보 할 것입니다."라고 그는 덧붙였습니다. Chrome m85는 아직 IETF QUIC 0-RTT를 지원하지 않으며 Google은 향후 몇 달 내에 IETF QUIC 0-RTT에 대한 지원을 출시하면이 성능이 더욱 향상 될 것으로 예상합니다. 또한 IETF QUIC 버전 30 및 31에는 호환성을 손상시킬 수있는 변경 사항이 포함되어 있지 않기 때문에 회사는 "over-the-wire"식별자를 변경할 계획이 없습니다.

이것은 IETF 버전의 변경 사항을 계속 추적 할 것이며 하지만 h3-29 / 0xff00001d로 구현됩니다.

따라서 서버가 Chrome과 상호 운용하려는 경우 최종 RFC가 완료 될 때까지 h3-29를 계속 지원하는 것이 좋습니다. 그러나 IETF가 향후 프로젝트에서 호환성을 깨는 변경을하면 Chrome은 그 결정을 뒤집을 것입니다.

출처 : https://blog.chromium.org


기사의 내용은 우리의 원칙을 준수합니다. 편집 윤리. 오류를보고하려면 여기에.

코멘트를 첫번째로 올려

코멘트를 남겨주세요

귀하의 이메일 주소는 공개되지 않습니다. 필수 필드가 표시되어 있습니다 *

*

*

  1. 데이터 책임자 : Miguel Ángel Gatón
  2. 데이터의 목적 : 스팸 제어, 댓글 관리.
  3. 합법성 : 귀하의 동의
  4. 데이터 전달 : 법적 의무에 의한 경우를 제외하고 데이터는 제 XNUMX 자에게 전달되지 않습니다.
  5. 데이터 저장소 : Occentus Networks (EU)에서 호스팅하는 데이터베이스
  6. 권리 : 귀하는 언제든지 귀하의 정보를 제한, 복구 및 삭제할 수 있습니다.