Comment le contrôle de flux hop-by-hop HTTP/2 est-il accompli?

Question

Comme le dit spec:

contrôle de flux est spécifique à une connexion. Les deux types de contrôle de flux se situent entre les points d'extrémité et un seul saut et non sur l'intégralité du chemin de bout en bout .

Et 6.9 WINDOW_UPDATE

Les deux types de contrôle de flux sont hop hop par, c'est seulement entre les deux extrémités . Les intermédiaires ne transmettent pas les trames WINDOW_UPDATE entre les connexions dépendantes. Cependant, l'étranglement du transfert de données par n'importe quel récepteur peut provoquer indirectement la propagation de l'information de contrôle de flux vers l'expéditeur d'origine.

Mais comment est-ce encore possible? Il semble qu'il exige que tous les intermédiaires pour comprendre h2 ou d'un protocole h2c, et j'ai deux questions:

1. HTTP/2 est une norme relativement nouvelle, et je l'ai vu de nombreux sites Web l'ont permis (mon blog inclus). Alors que je peux visiter ces sites sans problème, cela signifie-t-il que tous les périphériques intermédiaires comme les routeurs et hubs ont déjà implémenté leurs propres algorithmes de contrôle de flux et de pile HTTP/2 (puisque le RFC7540 ne stipule pas d'algorithme de contrôle de flux)?

2. La plupart des sites Web utilisent h2 plutôt que h2c, qui crypte les données de couche d'application. Le contrôle de flux de HTTP/2 est effectué par des récepteurs qui envoient une trame WINDOW_UPDATE, qui est également des données de couche d'application, puis comment les périphériques intermédiaires connaissent-ils ces données? S'ils ne peuvent pas déchiffrer les données et voir la partie Window Size Increment, comment accomplissent-ils le contrôle de flux sans transférer la trame WINDOW_UPDATE?

Answer 1

D'abord, quelques corrections.

Le jeton h2c fait référence à du texte en clair HTTP/2 (d'où le c dans h2c). Dans votre deuxième puce, vous dites que la plupart des sites l'utilisent, mais en fait très peu, parce que les navigateurs ne l'implémentent pas. La grande majorité des sites Web utilisent h2.

Le jeton h2 fait référence à h2c crypté, ou de manière équivalente à h2c sur TLS.

Lorsqu'un client et un serveur négocient pour parler , les octets envoyés par le client sont cryptés et acheminés jusqu'au serveur. Cela signifie que les intermédiaires n'ont pas la possibilité de déchiffrer le trafic (merci). Dans ce cas, le «saut» auquel se réfère la spécification HTTP/2 est l'ensemble du segment de réseau qui se trouve entre le client et le serveur.La spécification HTTP/2, cependant, doit être générique et ne pas se soucier de la façon dont les navigateurs et les serveurs Web interagissent lors de la définition d'un protocole fil tel que HTTP/2.

Imaginez une situation où le client effectue un HTTP/2 requête à l'aide h2 et doit appeler server2 pour répondre à la demande, cette fois en utilisant h2c. Par exemple, peut être un "proxy" frontal qui transmet les demandes au serveur principal "droit" en fonction d'une certaine logique.

Dans ce cas, vous avez 2 sauts: client-server1 et server1-server2. Chaque saut applique son propre contrôle de flux. Par exemple, imaginez que le client télécharge un fichier volumineux sur le serveur, par exemple. En règle générale, la fenêtre d'envoi du contrôle de flux client est petite, disons 65535 octets par défaut. Le client peut envoyer jusqu'à 65535 octets avant de bloquer le téléchargement. Ces 65535 octets sont reçus par . Maintenant devient un client afin de communiquer à server2. Imaginons que le client de a été configuré avec une fenêtre de contrôle de flux beaucoup plus petite lorsqu'il communique avec server2, disons seulement 16384 octets.

Dans cet exemple, le téléchargement stalles à server2 après 16384 octets, et doit réussir à maintenir autour des 65535-16384 octets restants en attente de server2 à Notify (via un cadre WINDOW_UPDATE) que les données téléchargées a été consommé.

Lorsque le client reçoit le WINDOW_UPDATE de server2, il peut envoyer plus de données à server2; mais aussi, il doit décider s'il faut envoyer au client un WINDOW_UPDATE (puisque sa fenêtre de contrôle de flux avec le client a maintenant de la place pour 16384 octets supplémentaires) ou attendre un peu plus. Par exemple, il pourrait envoyer 16384 autres octets à server2, et seulement à la réception de la deuxième WINDOW_UPDATE de server2 peut décider d'envoyer un WINDOW_UPDATE au client (avec une mise à jour de 16384 + 16384 octets).

Comme vous pouvez le voir dans l'exemple ci-dessus, le contrôle de flux entre le client et est lié à mais indépendant du contrôle de flux entre et server2.

Vous pouvez également lire this answer pour une discussion sur les implémentations de stratégie de contrôle de flux.

Answer 2

Cela dépend de la signification de hops/intermédiaires. Si les intermédiaires sont sur des niveaux inférieurs (passerelles TCP, NAT, commutateurs, etc.), ils sont transparents à HTTP/2, puisque le contrôle de flux HTTP/2 est appliqué de bout en bout entre un HTTP/2. client et serveur. Les sauts individuels entre eux peuvent utiliser des mécanismes de contrôle de flux de niveau inférieur.

Si votre intermédiaire est un proxy HTTP, il existe essentiellement deux requêtes HTTP séparées, chacune appliquant son propre contrôle de flux. L'application proxy a la responsabilité de connecter ces sauts individuels tout en conservant les propriétés de contrôle de flux. Par exemple. en ne lisant pas toute la réponse du second bond à la fois et seulement ensuite en l'envoyant au premier bond mais en diffusant des morceaux appropriés de données.

Dans le cas des proxies HTTP, vous arrivez même à des situations où vous souhaitez utiliser HTTP/1.1 à HTTP/2 et inversement. Dans ces situations, le proxy utiliserait les mécanismes de contrôle de flux HTTP/2 pour garantir le contrôle de flux pour ce saut et utiliser le contrôle de flux TCP pour fournir le contrôle de flux sur l'autre saut. Si le type de protocole est correctement encapsulé dans l'application proxy (ce qui signifie qu'il fournirait des opérations de streaming qui respectent le contrôle de flux pour les types Request et Response), les flux entre les différents types de protocole ne devraient pas être trop durs.