최근 IETF (Internet Engineering Task Force)는 인터넷의 프로토콜과 아키텍처를 개발하고, 그것을 알렸다 그 소식 HTTP/3.0 프로토콜을 위한 RFC 형성 완료 RFC 9114 및 RFC 9204 식별자로 관련 사양을 게시했습니다.
HTTP/3.0 사양 "제안된 표준" 상태를 받았으며, 그 후에 작업은 RFC에 초안 표준(표준 초안)의 상태를 제공하기 시작합니다. 이는 실제로 프로토콜의 완전한 안정화를 의미하고 작성된 모든 의견을 고려합니다.
프로토콜 HTTP/3은 QUIC 프로토콜의 사용을 정의합니다. (빠른 UDP 인터넷 연결) HTTP/2를 위한 전송으로. QUIC는 다중 연결의 다중화를 지원하고 TLS/SSL과 동등한 암호화 방법을 제공하는 UDP 프로토콜에 대한 플러그인입니다.
이 프로토콜은 Google에서 2013년에 만들었습니다. 웹용 TCP + TLS의 대안으로 TCP의 긴 연결 설정 및 협상 시간 문제를 해결하고 데이터 전송 중 패킷 손실로 인한 지연을 제거합니다.
현재, QUIC 및 HTTP/3.0 지원은 이미 모든 브라우저에서 구현되었습니다. 인기있는 웹사이트. 서버 측에서 HTTP/3 구현은 nginx(별도 분기 및 별도 모듈), Caddy, IIS 및 LiteSpeed에 사용할 수 있습니다. HTTP/3는 Cloudflare의 콘텐츠 전송 네트워크에서도 지원됩니다.
QUIC의 주요 기능:
- TLS와 유사한 높은 보안(사실 QUIC은 UDP를 통한 TLS 사용 기능 제공)
- 패킷 손실을 방지하기 위한 전송 무결성 제어
- 즉시 연결을 설정하고 요청 전송과 응답 수신 사이의 지연을 최소화하는 기능(RTT, 왕복 시간)
- 패킷을 재전송할 때 다른 시퀀스 번호를 사용하여 수신된 패킷을 결정할 때 모호성을 피하고 시간 초과를 제거할 수 있습니다.
- 패킷 손실은 연관된 스트림의 전달에만 영향을 미치며 현재 연결을 통해 병렬로 전송되는 스트림의 데이터 전달을 중지하지 않습니다.
- 손실된 패킷의 재전송으로 인한 지연을 최소화하는 오류 수정 도구. 손실된 패킷 데이터의 재전송이 필요한 상황을 줄이기 위해 특수 패킷 수준 오류 수정 코드를 사용합니다.
- 암호화 블록 경계는 QUIC 패킷 경계와 정렬되어 패킷 손실이 후속 패킷의 콘텐츠 디코딩에 미치는 영향을 줄입니다.
- TCP 대기열 차단 문제 없음
- 모바일 클라이언트의 재연결 시간을 줄이기 위한 연결 식별 지원
- 연결 과부하 제어를 위한 고급 메커니즘 연결 가능성
- 각 방향에서 대역폭 예측 기술을 사용하여 최적의 패킷 전달 속도를 보장하고 패킷이 손실되는 혼잡 상태를 방지합니다.
- TCP보다 눈에 띄는 성능 및 성능 향상. YouTube와 같은 비디오 서비스의 경우 QUIC는 비디오 버퍼링 작업을 30% 줄이는 것으로 나타났습니다.
이 외에도 동시에 HTTP/1.1(RFC 9112) 및 HTTP/2.0(RFC 9113) 프로토콜 사양의 업데이트된 버전과 HTTP 요청(RFC)의 의미를 정의하는 문서가 게시되었습니다. 9110) 및 HTTP 캐싱 제어 헤더(RFC 9111).
변화의 사양 HTTP/1.1, 당신은 금지를 알 수 있습니다 캐리지 리턴 문자를 별도로 사용하여 (CR) 내용이 있는 본문 외부즉, 프로토콜 요소에서 CR 문자는 개행 문자(CRLF)와 함께만 사용할 수 있습니다.
El 청크 요청 레이아웃 알고리즘이 개선되었습니다. 헤더가 있는 섹션과 첨부된 필드의 분리를 단순화합니다. 프론트엔드와 백엔드 사이의 흐름에서 다른 사용자의 요청 콘텐츠에 침입할 수 있는 "HTTP 요청 밀수" 클래스 공격을 차단하기 위해 모호한 콘텐츠를 처리하기 위한 지침이 추가되었습니다.
사양 업데이트 HTTP/2.0은 TLS 1.3에 대한 지원을 명시적으로 정의합니다. 더 이상 사용되지 않는 우선 순위 체계 및 관련 헤더 필드 및 업데이트 메커니즘 더 이상 사용되지 않는 HTTP/1.1 연결이 사용되지 않습니다.
마지막으로, 그것에 대해 더 알고 싶으시면 자세한 내용을 참조하십시오. 다음 링크.