HTTP 3.0 est la troisième version majeure du protocole HTTP, les deux premières sont HTTP 1.0 et HTTP 2.0, mais en fait HTTP 1.1, je pense, est le vrai HTTP 1.0.
Si vous ne savez pas grand-chose sur HTTP 1.1 et HTTP 2.0, vous pouvez lire mes deux articles.
Après avoir lu ce HTTP, il n'y a aucun problème à discuter avec l'intervieweur
Nous savons tous que HTTP est un protocole de couche application, et les données générées par la couche application seront transmises à d'autres hôtes sur Internet via le protocole de couche transport en tant que transporteur, et le transporteur est le protocole TCP, qui est le mode principal avant HTTP2.
Cependant, avec l'exposition continue des lacunes du protocole TCP, la nouvelle génération de protocole HTTP - HTTP 3.0 a résolument coupé la connexion avec TCP et adopté le protocole UDP à la place. Il n'est pas exact de dire qu'en fait, HTTP 3.0 adopte en fait le protocole QUIC , et le protocole QUIC est basé sur le protocole UDP.
HTTP 3.0
HTTP 3.0 a été officiellement publié le 6 juin 2022. L'IETF a formulé la norme HTTP 3.0 dans la RFC 9114. Par rapport à HTTP 2.0, HTTP 3.0 est en fait beaucoup plus petit que HTTP 2.0 par rapport à HTTP 1.1. L'amélioration réside dans l'efficacité. protocole avec le protocole UDP, HTTP 3.0 a une latence plus faible et son efficacité est même plus de 3 fois plus rapide que HTTP 1.1.
En fait, le développement continu de chaque génération de protocole HTTP est basé sur les lacunes de la génération précédente de HTTP. Par exemple, le plus gros problème de HTTP 1.0 est la sécurité de la transmission et le manque de prise en charge des connexions persistantes. En réponse à cela, HTTP 1.1 est apparu et a introduit le Keep-Alive, des mécanismes pour maintenir les liens longs et TLS pour assurer la sécurité des communications. Mais à l'heure actuelle, la simultanéité du protocole HTTP n'est pas suffisante.
Alors que le Web continue de croître et que le nombre de ressources (CSS, JavaScript, images, etc.) requises pour chaque site Web augmente d'année en année, les navigateurs se retrouvent de plus en plus exigeants en matière de simultanéité pour récupérer et afficher les pages Web. Mais comme HTTP 1.1 ne pouvait autoriser qu'un échange client/serveur de requêtes HTTP, la seule façon d'obtenir la simultanéité au niveau de la couche réseau était d'utiliser plusieurs connexions TCP en parallèle vers la même origine, mais l'utilisation de plusieurs connexions TCP perdait la garde- Signification de Vivant.
Puis vint le protocole SPDY , qui résolvait principalement l'inefficacité de HTTP 1.1, y compris la réduction de la latence, la compression des en-têtes, etc., dont le navigateur Chrome a prouvé qu'il produisait des effets d'optimisation. Plus tard, HTTP 2.0 était basé sur SPDY et introduit ** concept de flux ( Stream )**, qui permet de multiplexer différents échanges HTTP sur une même connexion TCP, afin d'atteindre l'objectif de permettre au navigateur de réutiliser la connexion TCP.
Le rôle principal de TCP est de transférer l'intégralité du flux d'octets d'un point de terminaison à l'autre dans le bon ordre, mais lorsque certains paquets du flux sont perdus, TCP doit renvoyer ces paquets perdus et attendre que les paquets perdus ne puissent que être traité par HTTP lorsqu'il atteint le point de terminaison correspondant, ce qui est appelé le problème de blocage de tête de ligne TCP.
Certaines personnes peuvent alors envisager de modifier le protocole TCP, ce qui est en fait une tâche impossible. Parce que TCP existe depuis trop longtemps, il a été inondé dans divers appareils, et ce protocole est implémenté par le système d'exploitation, et il n'est pas réaliste de le mettre à jour.
Pour cette raison, Google a lancé un protocole QUIC basé sur le protocole UDP et l'a utilisé sur HTTP/3. HTTP/3 s'appelait auparavant HTTP-over-QUIC. De ce nom, nous pouvons également constater que HTTP /3 La plus grande transformation est l'utilisation de QUIC.
Protocole QUIC
QUIC 的小写是 quic，谐音 quick，意思就是快。它是 Google 提出来的一个基于 UDP 的传输协议，所以 QUIC 又被叫做快速 UDP 互联网连接。
首先 QUIC 的第一个特征就是快，为什么说它快，它到底快在哪呢？
我们大家知道，HTTP 协议在传输层是使用了 TCP 进行报文传输，而且 HTTPS 、HTTP/2.0 还采用了 TLS 协议进行加密，这样就会导致三次握手的连接延迟：即 TCP 三次握手（一次）和 TLS 握手（两次），如下图所示。
对于很多短连接场景，这种握手延迟影响较大，而且无法消除。毕竟 RTT 是人类和效率的终极斗争。
相比之下，QUIC 的握手连接更快，因为它使用了 UDP 作为传输层协议，这样能够减少三次握手的时间延迟。而且 QUIC 的加密协议采用了 TLS 协议的最新版本 TLS 1.3，相对之前的 TLS 1.1-1.2，TLS1.3 允许客户端无需等待 TLS 握手完成就开始发送应用程序数据的操作，可以支持1 RTT 和 0 RTT，从而达到快速建立连接的效果。
我们上面还说过，HTTP/2.0 虽然解决了队头阻塞问题，但是其建立的连接还是基于 TCP，无法解决请求阻塞问题。
而 UDP 本身没有建立连接这个概念，并且 QUIC 使用的 stream 之间是相互隔离的，不会阻塞其他 stream 数据的处理，所以使用 UDP 并不会造成队头阻塞。
在 TCP 中，TCP 为了保证数据的可靠性，使用了序号+确认号机制来实现，一旦带有 synchronize sequence number 的包发送到服务器，服务器都会在一定时间内进行响应，如果过了这段时间没有响应，客户端就会重传这个包，直到服务器收到数据包并作出响应为止。
那么 TCP 是如何判断它的重传超时时间呢？
TCP 一般采用的是自适应重传算法，这个超时时间会根据往返时间 RTT 动态调整的。每次客户端都会使用相同的 syn 来判断超时时间，导致这个 RTT 的结果计算的不太准确。
虽然 QUIC 没有使用 TCP 协议，但是它也保证了可靠性，QUIC 实现可靠性的机制是使用了 Packet Number，这个序列号可以认为是 synchronize sequence number 的替代者，这个序列号也是递增的。与 syn 所不同的是，不管服务器有没有接收到数据包，这个 Packet Number 都会 + 1，而 syn 是只有服务器发送 ack 响应之后，syn 才会 + 1。
比如有一个 PN = 10 的数据包在发送的过程中由于某些原因迟迟没到服务器，那么客户端会重传一个 PN = 11 的数据包，经过一段时间后客户端收到 PN = 10 的响应后再回送响应报文，此时的 RTT 就是 PN = 10 这个数据包在网络中的生存时间，这样计算相对比较准确。
虽然 QUIC 保证了数据包的可靠性，但是数据的可靠性是如何保证的呢？
QUIC 引入了一个 stream offset 的概念，一个 stream 可以传输多个 stream offset，每个 stream offset 其实就是一个 PN 标识的数据，即使某个 PN 标识的数据丢失，PN + 1 后，它重传的仍旧是 PN 所标识的数据，等到所有 PN 标识的数据发送到服务器，就会进行重组，以此来保证数据可靠性。到达服务器的 stream offset 会按照顺序进行组装，这同时也保证了数据的顺序性。
众所周知，TCP 协议的具体实现是由操作系统内核来完成的，应用程序只能使用，不能对内核进行修改，随着移动端和越来越多的设备接入互联网，性能逐渐成为一个非常重要的衡量指标。虽然移动网络发展的非常快，但是用户端的更新却非常缓慢，我仍然看见有很多地区很多计算机还仍旧使用 xp 系统，尽管它早已发展了很多年。服务端系统不依赖用户升级，但是由于操作系统升级涉及到底层软件和运行库的更新，所以也比较保守和缓慢。
QUIC 协议的一个重要特点就是可插拔性，能够动态更新和升级，QUIC 在应用层实现了拥塞控制算法，不需要操作系统和内核的支持，遇到拥塞控制算法切换时，只需要在服务器重新加载一边即可，不需要停机和重启。
我们知道 TCP 的流量控制是通过滑动窗口来实现的，如果你对滑动窗口不太熟悉，你可以看下我写的这篇文章
在文章后面有提到了滑动窗口的一些概念。
而 QUIC 也实现了流量控制，QUIC 的流量控制也是使用了窗口更新 window_update，来告诉对端它可以接受的字节数。
L'en-tête du protocole TCP n'est ni crypté ni authentifié, il est donc susceptible d'être falsifié lors de la transmission. Contrairement à cela, l'en-tête du message dans QUIC est authentifié et le message est crypté. De cette façon, tant qu'il y a une modification du message QUIC, le récepteur peut le découvrir à temps, ce qui garantit la sécurité.
En général, QUIC présente les avantages suivants
- En utilisant le protocole UDP, il n'y a pas besoin d'une poignée de main à trois voies, et cela réduit également le temps nécessaire à TLS pour établir une connexion.
- Problème de blocage de tête de ligne résolu.
- Réalisez une connectabilité dynamique et implémentez un algorithme de contrôle de la congestion au niveau de la couche application, qui peut être commuté à tout moment.
- L'en-tête et le corps du message sont respectivement authentifiés et chiffrés pour garantir la sécurité.
- Les connexions migrent en douceur.
Une migration de connexion fluide signifie que lorsque votre téléphone portable ou appareil mobile bascule entre les signaux 4G et le WiFi et d'autres conditions de réseau, il ne sera pas déconnecté et reconnecté, et les utilisateurs peuvent même ne pas avoir de perception et peuvent directement obtenir une commutation de signal fluide.
Le protocole QUCI a été écrit en RFC 9000 .
Lien d'origine : HTTP/3, le voici.
Il y a beaucoup de beaux articles sur le compte officiel, je recommande à tous de faire attention.