Die Anzahl der Streams, dass Client und Server initiieren nicht unbegrenzt ist, wird es durch die SETTINGS_MAX_CONCURRENT_STREAMS Parameter des SETTINGS Rahmen beauftragt ist, dass jeder Peer am Anfang der Verbindung sendet: siehe section 6.5.2 of RFC 7540 Der Standard unbegrenzt ist, und die RFC hat folgende Empfehlung:
Es wird empfohlen, dass dieser Wert nicht kleiner als 100 ist, damit die Parallelität nicht unnötig einschränkt.
Die Anzahl der Streams ist jedoch nicht der einzige Parameter, der bei der Berücksichtigung der Parallelität in HTTP/2 berücksichtigt werden muss. Gewichte und Stream-Abhängigkeiten kommen ebenfalls ins Spiel.
Jeder Stream erhält eine Gewichtung und der RFC empfiehlt, dass der Server Ressourcen basierend auf ihrem Gewicht Ressourcen zuweist. Clientseitig weist Firefox dem CSS höhere Gewichtung zu als Bildern. See this great presentation for more details about how each browser prioritizes and organizes its streams. Chrome verwendet Abhängigkeiten, sodass die wichtigsten Elemente (CSS, HTML) in der Abhängigkeitskette höher sind als andere. See this tool zeigt die Abhängigkeitsstruktur, die Chrome generiert. Die Serverseite H2O, a new and fast HTTP server implementiert einen O (1) Scheduler pro Verbindung, um die Streams basierend auf Abhängigkeiten und Gewichtungen an den Client zu senden. Das heißt, wenn Sie 500 Elemente mit Standardabhängigkeit anfordern, erhält jeder Stream 1/500 der Serverressourcen.
Es sollte keinen Nachteil geben, so viele Elemente wie möglich anzufordern (für regelmäßiges Surfen im Internet). Laut HTTPArchive enthalten 40% der Seiten mehr als 100 Elemente, und ich denke, es ist vernünftig, sie alle gleichzeitig zu fragen (vorausgesetzt, die Anzahl der Streams bleibt unter SETTINGS_MAX_CONCURRENT_STREAMS. Ich glaube, dass es wichtig ist, Anfragen zu stellen) sie in der Reihenfolge, in der der Browser sie so weit wie möglich rendern kann,