Stoppen. Hör einfach auf. HTTPS ist nicht schneller als HTTP.
Ja, Lori hat wieder im Internet gelesen. Und was sie gesehen hat, macht Baby Lori wütend. Auch dieser ehemaligen Testdesignerin und Technikredakteurin kommen die Tränen. Wirklich, ich weine angesichts der Entschuldigungen für diese Tests und der irreführenden Schlagzeile.
Ich habe in den letzten zwei Wochen nicht weniger als zwei konstruierte Vergleiche zwischen „HTTPS“ und „HTTP“ gelesen, die angeblich beweisen sollten, dass sicheres HTTP unbestreitbar schneller sei als sein Gegenstück im Klartext, HTTP.
Oh, wenn das nur wahr wäre.
Sehen Sie, der Trick besteht darin, dass in beiden Vergleichen (und zweifellos werden noch viele weitere folgen) das sichere HTTP/2 mit dem unsicheren HTTP/1.1 verglichen wird. Aus dem oben genannten Vergleich: „Klartext HTTP/1.1 wird mit verschlüsseltem HTTP/2 HTTPS verglichen .“
Wie wir alle bereits wissen, ist HTTP/2 selbst (konstruktionsbedingt) schneller als HTTP/1.1, und zwar aus verschiedenen Gründen, die absolut nichts mit Sicherheit zu tun haben. Multiplexing, „intelligente“ Header und ein binärer Bitstrom sorgen zusammen für ein schnelleres und effizienteres Protokoll, Punkt. Obwohl es wahrscheinlich ist, dass das Aufsetzen einer Sicherheitsschicht (TLS oder SSL) auf HTTP/2 zu einer leichten Verschlechterung der Leistung führt (weil die Mathematik dies vorhersagt), reicht dies nicht aus, um die Leistung auf das Niveau zu senken, das wir von HTTP/1.1 gewohnt sind, selbst im ungesicherten Zustand.
Leider werden diese Ergebnisse als unwiderlegbarer Beweis dafür angepriesen, dass HTTPS schneller als HTTP sei. Was einfach nicht stimmt. Das Argument gegen den Test der Sicherheit von HTTP/2 gegenüber HTTP/2-Klartext besteht darin, dass Browser HTTP/2 ohne Sicherheit nicht unterstützen und es daher keine Möglichkeit gibt, einen solchen Test durchzuführen. Daher wurde ein Test konstruiert, der vorgibt, die Unterschiede zu veranschaulichen, der aber in Wirklichkeit nichts dergleichen tut.
Es stimmt, dass ein Vergleich von sicherem HTTP/2 mit unsicherem HTTP/2 äußerst schwierig, wenn nicht gar unmöglich wäre. Während HTTP/2 von seiner Anforderung ausschließlich sicherer Verbindungen Abstand nahm und Klartext zulässt, weigerten sich alle wichtigen Browser, Klartext zu unterstützen und bieten bislang nur Unterstützung für HTTP/2 über TLS/SSL . Sogar beliebte Befehlszeilentools wie curl lassen unsichere HTTP/2-Verbindungen nicht zu. Damit wird HTTPS letztlich zum De-facto-Standard, auch wenn die Spezifikation dies nicht vorsieht. Das heißt aber nicht, dass Sie die beiden vergleichen und dann auf der Grundlage dieses Tests absolut lächerliche Behauptungen aufstellen können, die mit einfacher Mathematik widerlegt werden können.
Nehmen wir an, das Laden einer per HTTP/2-Klartext übertragenen Webseite dauerte genau 1,2 Sekunden. Fügen wir jetzt TLS hinzu. Das Hinzufügen von TLS (oder auch SSL) bedeutet, dass mehr Verarbeitungsvorgänge stattfinden, insbesondere die Ver- und Entschlüsselung der Daten. Selbst wenn das nur 0,3 Sekunden dauert, bedeutet das immer noch, dass HTTPS ein kleines bisschen langsamer ist als HTTP. Zeitraum. Die Mathematik sagt das, und Mathematik ist rein. Sie hat keine Agenda, die Ergebnisse sind ihr egal, sie sagt einfach: „Hier ist es.“
Und die Mathematik besagt, dass wenn Sie X berechnen und dann Y hinzufügen, Sie Z erhalten und Z immer größer als X oder Y ist.
Ich verstehe den Wunsch, die Leute zu HTTP/2 zu drängen, weil es schneller ist und das erste echte „Upgrade“ für HTTP seit sehr langer Zeit darstellt, aber es braucht Zeit, insbesondere wenn zahlreiche Upgrades und Änderungen an der Infrastruktur erforderlich sind, die zu Unterbrechungen führen, da jeder, von der Anwendungsentwicklung über den Betrieb und Netops bis hin zur Sicherheit, seine aktuelle Arbeit unterbrechen und testen, bereitstellen und nochmals testen muss. Und dabei werden die Änderungen bei der Modifizierung von Apps, die seit langem auf HTTP/1.1 und seiner Protokollspezifikation basieren, noch nicht berücksichtigt. HTTP/2 ändert alles. Und seine Auswirkungen erstrecken sich auf das gesamte Rechenzentrum. Während Gateways die mit der Migration verbundenen Schwierigkeiten und Störungen abmildern, sieht nicht jeder zwangsläufig eine Notwendigkeit, auf den HTTP/2-Zug aufzuspringen.
Die Leistungssteigerung, die Unternehmen feststellen werden, bedeutet ganz einfach, dass HTTP/2 die von seinen Entwicklern vorgesehene Leistung mit höherer Geschwindigkeit und Effizienz erbringt. Das bedeutet, dass Unternehmen die für die Migration erforderlichen Upgrades der App- und Netzwerkinfrastruktur planen sollten , um den neuen Standard zu unterstützen, unabhängig davon, ob dies über HTTP-Gateways erfolgt oder nicht . Das bedeutet nicht, dass HTTPS schneller ist als HTTP.
Das Aufstellen nachweislich falscher Behauptungen, um klickköderartige Schlagzeilen über eine angeblich bessere Leistung zu erstellen, ist einfach inakzeptabel. Ja, Sie werden mit ziemlicher Sicherheit eine Leistungssteigerung feststellen, wenn Sie von HTTP/1.1 auf HTTP/2 umsteigen, sogar bei erzwungener Sicherheit. Aber das bedeutet in keiner Welt, in der Logik und Mathematik existieren, dass HTTPS schneller ist als HTTP. Wenn Sie Organisationen helfen möchten, vermitteln Sie ihnen einen reibungslosen Übergang vom Alten zum Neuen. Stellen Sie ihnen aussagekräftige Daten zur Verfügung, damit sie einen Business Case erstellen können, der ihnen ein Upgrade auf die neueste und beste Technologie ermöglicht. Geben Sie ihnen die Möglichkeit zu zeigen, dass sich die Investition in die Umstellung von HTTP/1.x auf HTTP/2 langfristig auszahlt.
Bieten Sie Richtlinien und bewährte Vorgehensweisen, keine schlagkräftigen Schlagzeilen und eine versteckte Einleitung.