Domain-Sharding: Eine Technik die Sie 2016 vergessen können
Philipp Zeder
Kategorie:in
Entwicklung & Performance
Veröffentlicht am 8. Jan. 2016
Aktualisiert am 10. Sept. 2024
2016 wird dank kostenlosen SSL-Zertifikaten das Jahr von HTTP/2. Zumindest bei Hostinganbietern die HTTP/2 bereits unterstützen ;) Eine der Techniken, die HTTP/2 obsolet macht, nennt sich Domain-Sharding. Wir zeigen Ihnen heute, was Domain-Sharding ist und warum Sie die Technik aus Ihrer Webentwickler-Trickkiste verbannen können.
HTTP/2 ist die neuste Version des «Hypertext Transfer Protocol», merzt Schwächen der Vorgängerversion HTTP/1.1 aus und wird von vielen Browsern bereits unterstützt. Einen Überblick zum Thema erhalten Sie in unserem Blogpost zu HTTP/2.
Was ist Domain-Sharding?
«Shards» ist das englische Wort für Bruchstücke oder Scherben. Domain-Sharding bedeutet, dass auf einer Website eingebundene Inhalte auf mehrere Hostnamen aufgeteilt werden.
Die Anzahl Verbindungen, die ein moderner Browser parallel zu einem Hostnamen öffnet, ist im Durchschnitt auf sechs begrenzt. Gleichzeitig sind für die Darstellung einer durchschnittlichen Website aber mittlerweile 100 Requests nötig. Und für jeden dieser Requests baut der Browser über HTTP/1.1 eine neue Verbindung auf. Die Folge: Verbindungen werden in eine Warteschlange verbannt, bis eine der bereits benutzten Verbindungen wieder frei ist. Die aufgerufene Website lädt langsamer.
Um dieses Problem zu umgehen, haben sich Webentwickler bis anhin mit Domain-Sharding beholfen. Denn mit der Technik kann die Verbindungslimitierung in Browsern ausgehebelt werden. Browser bauen die Verbindungen, dank unterschiedlichen Hostnamen, parallel auf.
Darum wird Domain-Sharding verschwinden
Mit HTTP/1.1 bringt Domain-Sharding Geschwindigkeitsvorteile, keine Frage. Kommt HTTP/2 zum Einsatz, ist Domain-Sharding jedoch kontraproduktiv und wird zum Anti-Pattern:
- Aufgrund der verschiedenen Limiten in Browsern gibt es nicht die ideale Anzahl Shards. Die Folge: Verlorene Datenpakete, die nochmals gesendet werden müssen, die wiederum die Leitungen mit unnötigem Datenverkehr verstopfen.
- Jede Verbindung die aufgebaut wird kostet Rechenzeit, Arbeitsspeicher und dergleichen.
- Jede einzelne Verbindung konkurriert mit anderen Verbindungen um Bandbreite.
- Domain-Sharding verkompliziert den Code von Websites und Applikationen.
- Domain-Sharding verhindert die Ressourcenpriorisierung und Flow-Control, die in HTTP/2 eingebaut sind.
- Die Vorteile, die durch die komprimierten Kopfzeilen (Header) in HTTP/2 erzielt werden, gehen verloren.
HTTP/2 verbindet
Noch beträgt die Unterstützung von HTTP/2 in Browsern keine 100% und je nach Zielpublikum kann es noch eine Weile dauern, bis die eingesetzten Browser auf modernere Versionen aktualisiert werden. Auch daran haben die HTTP/2-Entwickler gedacht. HTTP/2 kann nämlich Verbindungen zusammenführen, wenn zwei Bedingungen erfüllt sind:
1. Das eingesetzte SSL-Zertifikat beinhaltet die Hostnamen der verschiedenen Shards.
2. Die Shards zeigen auf die gleiche IP-Adresse.
In den meisten Fällen sind diese zwei Voraussetzungen automatisch erfüllt. Wenn Sie unsere kostenlosen SSL-Zertifikate von Let’s Encrypt für Ihre Domain aktiviert haben und die Subdomains auf das gleiche Verzeichnis zeigen, beinhaltet das SSL-Zertifikat automatisch alle passenden Hostnamen.
Domain-Sharding ja oder nein?
Die meisten Experten empfehlen, Ressourcen nicht auf mehr als zwei Hostnamen zu verteilen. Ein kleiner Test zeigt, warum:
Google Chrome öffnet pro Domain maximal sechs Verbindungen. Die Anzahl aller gleichzeitiger offenen Verbindungen (also über mehrere Hostnamen) beträgt zehn. Eine Verteilung auf drei Shards macht deshalb wenig Sinn, weil der Browser erst gar nicht die über zwei Shards möglichen zwölf Verbindungen aufbaut.
Unser Tipp: Prüfen Sie in den Statistiken Ihrer Website, welche Browser Ihre Besucher nutzen. Entscheiden Sie dann, ob die Unterstützung von Performance-Tricks wie Domain-Sharding überhaupt noch nötig ist. Wenn Sie das Beste aus HTTP/1.1 und HTTP/2 herausholen möchten, verwenden Sie nicht mehr als zwei Shards und achten Sie darauf, ob das genutzte SSL-Zertifikat alle Hostnamen der Shards beinhaltet.
Beteilige dich an der Diskussion
4 Kommentare
Hi Urs. Der frühere «offizielle» Client heisst mittlerweile Certbot und wird unter der Schirmherrschaft der EFF weiterentwickelt. Dieser Client benötigt für gewisse Operationen noch root-Rechte: https://certbot.eff.org/faq/#does-certbot-require-root-administrator-privileges. Es gibt Alternativen wie z.B. https://github.com/diafygi/letsencrypt-nosudo, die keine (bzw. praktisch keine) root-Rechte benötigen.
Spricht aber nicht gegen CDNs, oder? Dabei geht es auch um den Vorteil, dass Ressourcen sich aus Besuchen anderer Websites evtl. bereits im Cache befinden.
Nein, gegen CDNs spricht natürlich nichts. Sie bringen statische Inhalte näher an den Besucher und unter Umständen kann von gecachten Bibliotheken profitiert werden. Domain-Sharding wurde aber in der Vergangenheit gerne genutzt, um die Limite der maximalen Verbindungen zu umgehen. Bei der Wahl des CDNs würde ich darauf achten, dass TLS und HTTP/2 ebenfalls unterstützt werden. Die Schweizer Kollegen von KeyCDN tun das zum Beispiel.
Ich bin immer noch nicht 100% von let’s encrypt überzeugt. Läuft es inzwischen ohne root-rechte? In dem Sinne, ja https ist ok, aber kostet. Da leider startssl ihre Reputation durch den Verkauf an WoSign versaut hat, wird es sogar noch teurer.