Comme HTTP2 supporte le multiplexage, avons-nous encore besoin d'un pool de connexions pour la communication des microservices ? Si oui, quels sont les avantages d'un tel pool ?
Exemple : Service A => Service B
Les deux services ci-dessus n'ont qu'une seule instance disponible.
Les connexions multiples peuvent aider à surmonter la limitation de la taille de la mémoire tampon du système d'exploitation pour chaque connexion (socket) ? Quoi d'autre ?
Oui, vous avez toujours besoin d'un pool de connexion dans un client qui contacte un microservice.
Tout d'abord, en général, c'est le serveur qui contrôle la quantité de multiplexage. Un serveur de microservices particulier peut décider qu'il ne peut autoriser qu'un très petit multiplexage.
Si un client veut utiliser ce microservice avec une charge plus élevée, il doit être prêt à ouvrir plusieurs connexions et c'est là que le pool de connexion est utile. Cela est également utile pour gérer les pics de charge.
Deuxièmement, HTTP/2 comporte un contrôle de flux, ce qui peut limiter considérablement le débit de données sur une seule connexion. Si la fenêtre de contrôle de flux est petite (la valeur par défaut définie par la spécification HTTP/2 est de 65535 octets, ce qui est généralement très petit pour les microservices), le client et le serveur passeront un temps considérable à échanger des données. WINDOW_UPDATE trames pour agrandir les fenêtres de contrôle de flux, ce qui est préjudiciable au débit.
Pour y remédier, il faut soit un plus grand nombre de connexions (ce à quoi le client doit être préparé), soit des fenêtres de contrôle de flux plus grandes.
Troisièmement, en cas de fenêtres de contrôle de flux HTTP/2 de grande taille, vous risquez d'être confronté à une congestion TCP (ce qui est différent de la taille du tampon de la socket) car le consommateur est plus lent que le producteur. Il peut s'agir d'un serveur lent pour un téléchargement client (demande REST avec une charge utile importante), ou d'un client lent pour un téléchargement serveur (réponse REST avec une charge utile importante).
Là encore, pour surmonter la congestion TCP, la solution consiste à ouvrir plusieurs connexions.
Si l'on compare HTTP/1.1 et HTTP/2 pour le cas d'utilisation d'un microservice, il est typique que les pools de connexion HTTP/1.1 soient beaucoup plus grands (par exemple 10x-50x) que les pools de connexion HTTP/2, mais vous voulez toujours des pools de connexion dans HTTP/2 pour les raisons ci-dessus.
[Disclaimer Je suis le responsable de l'implémentation de HTTP/2 en Jetée ].
Nous avons eu une implémentation initiale où le système Jetty HttpClient utilisait le transport HTTP/2 avec une connexion unique par domaine codée en dur, car c'est ce que HTTP/2 préconisait pour les navigateurs.
Lorsque nous avons été exposés à des cas d'utilisation réels, notamment des microservices, nous avons rapidement réalisé à quel point c'était une mauvaise idée et nous sommes revenus à l'utilisation de la mise en commun des connexions pour HTTP/2 (comme l'a fait la Commission européenne). HttpClient toujours pour HTTP/1.1).
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
