HTTP Requests ohne Subdomain reduzieren (SSL)

[rongador]

@ayngush HTTP2 werde ich angehen, sobald ich auf SSL umstelle.

 

[DubZ]

kann mich jmd. netterweise aufklären wieso das Laden von Resourcefiles schneller geht, wenn diese von verschiedenen (Sub-)Domänen geladen werden? So wirklich verstehen tue ich das nicht... zudem erhöht sich dadurch doch auch die DNS Anfragen

 

[rongador]

Deswegen muss man ein Gleichgewicht zwischen der Nutzung von Subdomains, den damit aufgeteilten HTTP-Requests und DNS-Auflösungen finden. Grundsätzlich ist vom Browser (bei HTTP/1) die Anzahl gleichzeitiger Requests pro Domain begrenzt. Bei Aufteilung auf mehrere Subdomains passieren die Requests also parallel. Aber wie gesagt, man darf wegen den DNS-Auflösungen dann auch nicht übertreiben.

 

[DubZ]

interessant... war mir gar nicht bewusst und wieso limitieren die Browserentwickler das unterschiedlich und bei http2 dann nicht mehr?

 

[rongador]

@DubZ Weil Http/2 (nach meinen Recherchen jetzt) wohl mehr auf parallele Nutzung ausgelegt ist. Möglicherweise eben wegen der Beschränkungen von Http/1, die einfach nervig sind und waren. Aber zur Nutzung von Http/2 wird SSL vorausgesetzt.

 

[DubZ]

Ja, aber erklärt ja nicht wieso jeder Browser unterschiedlich viele parallelverbindungen öffnet. Naja ich lese mir das morgen mal in Ruhe durch

 

[rongador]

@DubZ Das kann ich Dir leider auch (im Moment) nicht erklären.

 

[Piktogramm]

interessant... war mir gar nicht bewusst und wieso limitieren die Browserentwickler das unterschiedlich

Der Unterschied ich zwischen verschiedenen Browsern eher klein und aus div. Abwägungen heraus wurden verschiedene Werte gewählt.
Ansonsten bedeuten zig offene parellele Verbindungen allerhand Overhead, Last auf dem Server, Last auf der Leitung und Last beim Clienten und alles in der Regel nur weil die Betreiber von Webseiten ihren Job nicht beherrschen.
HTTP2 nutzt pipelining, dass hätte es unter HTTP1 auch gegeben. Hat nur kaum jemand genutzt. Im Groben ist Pipelining, dass man nicht für jedes Element eine eigene Verbindung aufbaut, sondern dass über eine Verbindung alle Elemente angefragt werden. Damit bleibt für die zusätzlichen Verbindungen weg.

 

[snaxilian]

Neben multiplen Zertifikaten oder Wildcard gibt es auch noch den Subject Alternative Name, da kannst mehrere Domains in ein Zertifikat packen aber auch das muss dein Hoster unterstützen wenn du ein reines Webhosting nutzt.

 

[DubZ]

Im Groben ist Pipelining, dass man nicht für jedes Element eine eigene Verbindung aufbaut, sondern dass über eine Verbindung alle Elemente angefragt werden. Damit bleibt für die zusätzlichen Verbindungen weg.

Wenn ich das richtig verstehe dann wird dadurch lediglich verhindert, dass Verbindungen ständig auf- und abgebaut werden. Aber parallel ist dadurch ja noch immer nichts?!

 

[Piktogramm]

Wenn ich das richtig verstehe [...]

https://en.wikipedia.org/wiki/HTTP_pipelining

 

[ayngush]

Der Hauptunterschied zwischen HTTP/1.1 und HTTP/2.0 ist der, dass bei HTTP/2.0 die einmal aufgebaute Verbindung für mehrere (parallele) Anfragen auf Ressourcen genutzt wird, während bei HTTP/1.1 pro Anfrage eine neue Verbindung aufgebaut werden muss (sofern man nicht irgendwelche "Abweichungen" vom Standard verwendet, wie HTTP-Pipelining).
Die Anzahl an gleichzeitig aufgebauten Verbindungen zu ein und der selben Domain sind jedoch limitiert, weswegen man vor über 10 Jahren angefangen hat das ganze dahingehend zu optimieren, dass man Bilder von img.tld.com Javascript von js.tld.com Stylesheets von css.tld.com und den Hypertext von www.tld.com geladen hat usw.
Gleichzeitig hat man "DNS prefetch" betrieben, um schon mal js. css. img. ... im DNS-Cache zu haben und alle JS und CSS und Piktogramm-Bilder als Sprite / Image Map zusammengefasst, damit man möglichst wenig Verbindungen aufbauen muss, weil die Anzahl an Verbindungen das war, was "Leistung" gefressen hatte.

Bei HTTP/2.0 und den ganzen Mobile First / PWA Ansätzen für moderne Browser optimiert man aber mittlerweile anders. Man sieht zu, dass möglichst wenig Zeug am Anfang den Renderpfad des Browsers blockiert, also möglichst kleine, optimierte Ressourcen, die schnell geladen werden können und sich gegenseitig nicht zu "Warteschlangen im Renderpfad" zwingen.
Die reine Anzahl der Ressourcen spielt dann durch HTTP/2.0 und der parallelen, asynchronen Verarbeitung über ein und derselben Verbindung keine große Rolle mehr.