it-swarm.com.de

HTTP vs HTTPS-Leistung

Gibt es wesentliche Leistungsunterschiede zwischen http und https? Ich erinnere mich an die Lektüre, dass HTTPS ein Fünftel so schnell sein kann wie HTTP. Gilt dies für die Webserver/Browser der aktuellen Generation? Wenn ja, gibt es Whitepapers, die dies unterstützen?

358
Jim Geurts

Darauf gibt es eine sehr einfache Antwort: Profilieren Sie die Leistung Ihres Webservers, um zu sehen, wie hoch die Leistungseinbußen für Ihre spezielle Situation sind. Es gibt verschiedene Tools, mit denen die Leistung eines HTTP- mit der eines HTTPS-Servers verglichen werden kann (JMeter und Visual Studio fallen ein). Sie sind recht einfach zu verwenden.

Niemand kann Ihnen eine aussagekräftige Antwort ohne einige Informationen über die Art Ihrer Website, Hardware, Software und Netzwerkkonfiguration geben.

Wie bereits erwähnt, wird die Verschlüsselung einen gewissen Overhead verursachen, der jedoch in hohem Maße von Folgendem abhängt:

  • Hardware
  • Serversoftware
  • Verhältnis von dynamischem zu statischem Inhalt
  • Clientabstand zum Server
  • Typische Sitzungsdauer
  • Usw. (mein persönlicher Favorit)
  • Caching-Verhalten von Clients

Nach meiner Erfahrung sind Server mit hohem Anteil an dynamischen Inhalten weniger von HTTPS betroffen, da der Zeitaufwand für die Verschlüsselung (SSL-Overhead) im Vergleich zur Zeit für die Inhaltserstellung unbedeutend ist.

Server, die eine relativ kleine Menge statischer Seiten bedienen, die leicht im Arbeitsspeicher zwischengespeichert werden können, haben einen viel höheren Overhead (in einem Fall wurde der Durchsatz in einem "Intranet" beeinträchtigt).

Bearbeiten: Ein Punkt, der von mehreren anderen angesprochen wurde, ist, dass SSL-Handshake die Hauptkosten von HTTPS sind. Das ist richtig, weshalb "typische Sitzungslänge" und "Caching-Verhalten von Clients" wichtig sind.

Viele, sehr kurze Sessions bedeuten, dass die Handshake-Zeit alle anderen Leistungsfaktoren überfordert. Längere Sitzungen bedeuten, dass die Handshake-Kosten zu Beginn der Sitzung anfallen, nachfolgende Anforderungen jedoch einen relativ geringen Overhead haben.

Das Zwischenspeichern von Clients kann in mehreren Schritten erfolgen, von einem großen Proxyserver bis zum einzelnen Browser-Cache. Im Allgemeinen werden HTTPS-Inhalte nicht in einem gemeinsam genutzten Cache zwischengespeichert (obwohl einige Proxyserver ein Man-in-the-Middle-Verhalten ausnutzen können, um dies zu erreichen). Viele Browser zwischenspeichern HTTPS-Inhalte für die aktuelle Sitzung und häufig sitzungsübergreifend. Die Auswirkung des Nicht-Caching oder des geringeren Caching bedeutet, dass Clients den gleichen Inhalt häufiger abrufen. Dies führt zu mehr Anforderungen und Bandbreite, um die gleiche Anzahl von Benutzern zu bedienen.

228
James Schek

HTTPS erfordert einen anfänglichen Handshake, der sehr langsam sein kann. Die tatsächliche Datenmenge, die im Rahmen des Handshakes übertragen wird, ist nicht sehr groß (in der Regel weniger als 5 KB). Bei sehr kleinen Anforderungen kann dies jedoch zu einem erheblichen Mehraufwand führen. Sobald der Handshake abgeschlossen ist, wird jedoch eine sehr schnelle Form der symmetrischen Verschlüsselung verwendet, sodass der Overhead dort minimal ist. Fazit: Viele kurze Anfragen über HTTPS zu stellen, ist etwas langsamer als HTTP, aber wenn Sie viele Daten in einer einzigen Anfrage übertragen, ist der Unterschied unbedeutend.

Keepalive ist jedoch das Standardverhalten in HTTP/1.1. Sie führen also einen einfachen Handshake aus und dann viele Anfragen über dieselbe Verbindung. Dies macht einen signifikanten Unterschied für HTTPS. Sie sollten Ihre Website wahrscheinlich mit einem Profil versehen (wie andere vorgeschlagen haben), um dies sicherzustellen, aber ich vermute, dass der Leistungsunterschied nicht spürbar ist.

218
Graeme Perrow

Um wirklich zu verstehen, wie HTTPS Ihre Latenz erhöht, müssen Sie verstehen, wie HTTPS-Verbindungen hergestellt werden. Hier ist ein Nettes Diagramm . Der Schlüssel ist, dass der Client die Daten nicht nach 2 "Strecken" erhält (eine Rundreise, Sie senden eine Anfrage, der Server sendet eine Antwort), sondern erst nach mindestens 4 Strecken (2 Rundreisen). . Wenn es also 100 ms dauert, bis sich ein Paket zwischen dem Client und dem Server bewegt, dauert Ihre erste HTTPS-Anforderung mindestens 500 ms.

Dies kann natürlich durch die erneute Verwendung der HTTPS-Verbindung (die von den Browsern verwendet werden sollte) verringert werden, erklärt jedoch einen Teil dieses anfänglichen Stillstands beim Laden einer HTTPS-Website.

101
twk

Der Overhead ist NICHT auf die Verschlüsselung zurückzuführen. Auf einer modernen CPU ist die für SSL erforderliche Verschlüsselung trivial.

Der Overhead ist auf die langwierigen SSL-Handshakes zurückzuführen, die die Anzahl der für eine HTTPS-Sitzung über eine HTTP-Sitzung erforderlichen Roundtrips drastisch erhöhen.

Messen Sie (mit einem Tool wie Firebug) die Ladezeiten der Seite, während sich der Server am Ende einer simulierten Verbindung mit hoher Latenz befindet. Es gibt Tools, um eine Verbindung mit hoher Latenz zu simulieren - für Linux gibt es "netem". Vergleichen Sie HTTP mit HTTPS im selben Setup.

Die Latenz kann bis zu einem gewissen Grad verringert werden durch:

  • Stellen Sie sicher, dass Ihr Server HTTP-Keepalives verwendet. Auf diese Weise kann der Client SSL-Sitzungen wiederverwenden, sodass kein weiterer Handshake erforderlich ist
  • Reduzieren Sie die Anzahl der Anforderungen auf so wenig wie möglich, indem Sie nach Möglichkeit Ressourcen kombinieren (z. B. Dateien, CSS) und die clientseitige Zwischenspeicherung fördern
  • Reduzieren Sie die Anzahl der Seitenladevorgänge, z. indem Sie nicht benötigte Daten in die Seite laden (möglicherweise in einem versteckten HTML-Element) und diese dann mit einem Client-Skript anzeigen.
76
MarkR

Dezember 2014 Update

Sie können den Unterschied zwischen HTTP- und HTTPS-Leistung in Ihrem eigenen Browser ganz einfach testen, indem Sie die Website HTTP vs. HTTPS-Test verwenden: AnthumChris : „Diese Seite misst die Ladezeit über unsichere HTTP- und verschlüsselte HTTPS-Verbindungen. Auf beiden Seiten werden 360 eindeutige, nicht zwischengespeicherte Bilder geladen (insgesamt 2,04 MB). “

Die Ergebnisse können Sie überraschen.

Es ist wichtig, aktuelle Kenntnisse über die HTTPS-Leistung zu haben, da die Let's Encrypt Zertifizierungsstelle ab sofort kostenlos und automatisch ausgestellt wird und öffnen Sie SSL-Zertifikate im Sommer 2015 dank Mozilla, Akamai, Cisco, Electronic Frontier Foundation und IdenTrust.

Juni 2015 Update

Updates zu Let’s Encrypt - Ankunft im September 2015:

Weitere Infos auf Twitter: @ letsencrypt

Weitere Informationen zur HTTPS- und SSL/TLS-Leistung finden Sie unter:

Weitere Informationen zur Bedeutung der Verwendung von HTTPS finden Sie unter:

Lassen Sie mich zusammenfassend Ilya Grigorik : "TLS hat genau ein Leistungsproblem: Es wird nicht häufig genug verwendet. Alles andere kann optimiert werden."

Vielen Dank an Chris - Autor des HTTP vs HTTPS Test Benchmarks - für seine Kommentare unten.

25
rsp

Die aktuelle Top-Antwort ist nicht ganz korrekt.

Wie bereits erwähnt, erfordert https Handshake und führt daher mehr TCP/IP-Roundtrips durch.

In einer WAN Umgebung wird normalerweise die Latenz zum begrenzenden Faktor und nicht die erhöhte CPU-Auslastung auf dem Server.

Denken Sie daran, dass die Latenz von Europa in die USA ca. 200 ms betragen kann (Torundtrip-Zeit).

Sie können dies (für den Einzelfall) leicht mit HTTPWatch messen.

23
kohlerm

Beachten Sie, dass einige (alle?) Webbrowser aus Sicherheitsgründen keine über HTTPS erhaltenen zwischengespeicherten Inhalte auf der lokalen Festplatte speichern. Dies bedeutet, dass aus Sicht des Benutzers Seiten mit viel statischem Inhalt nach dem Neustart des Browsers langsamer geladen werden und aus Sicht Ihres Servers das Anforderungsvolumen für statischen Inhalt über HTTPS höher ist als über HTTP.

12
Alexander

In einigen Fällen wird die Auswirkung von SSL-Handshakes auf die Leistung dadurch gemindert, dass die SSL-Sitzung auf beiden Seiten (Desktop und Server) zwischengespeichert werden kann. Auf Windows-Computern kann die SSL-Sitzung beispielsweise bis zu 10 Stunden zwischengespeichert werden. Siehe http://support.Microsoft.com/kb/247658/EN-US . Einige SSL-Beschleuniger verfügen auch über Parameter, mit denen Sie die Zeit einstellen können, zu der die Sitzung zwischengespeichert wird.

Ein weiterer zu berücksichtigender Effekt ist, dass statische Inhalte, die über HTTPS bereitgestellt werden, nicht von Proxys zwischengespeichert werden. Dies kann die Leistung mehrerer Benutzer beeinträchtigen, die über denselben Proxy auf die Site zugreifen. Dies kann durch die Tatsache abgemildert werden, dass statische Inhalte auch auf Desktops zwischengespeichert werden. Internet Explorer 6 und 7 zwischenspeichern statische HTTPS-Inhalte, sofern nicht anders angewiesen (Menü Extras/Internetoptionen/Erweitert/Sicherheit/Verschlüsselte Seiten nicht speichern) auf Festplatte).

6
ZX81

Dafür gibt es keine einzige Antwort.

Durch die Verschlüsselung wird immer mehr CPU verbraucht. Dies kann in vielen Fällen auf dedizierte Hardware ausgelagert werden, und die Kosten variieren je nach ausgewähltem Algorithmus. 3des ist beispielsweise teurer als AES. Einige Algorithmen sind für den Verschlüsseler teurer als für den Entschlüsseler. Einige haben die gegenteiligen Kosten.

Teurer als die Massen-Krypto sind die Handshake-Kosten. Neue Verbindungen verbrauchen viel mehr CPU. Dies kann durch die Wiederaufnahme der Sitzung reduziert werden, wobei die alten Sitzungsgeheimnisse bis zu ihrem Ablauf beibehalten werden. Dies bedeutet, dass kleine Anfragen von einem Kunden, der nicht mehr zurückkommt, am teuersten sind.

Bei Cross-Internet-Verkehr bemerken Sie diese Kosten möglicherweise nicht in Ihrer Datenrate, da die verfügbare Bandbreite zu niedrig ist. Aber Sie werden es sicherlich bei der CPU-Auslastung auf einem ausgelasteten Server bemerken.

6
Darron

Ich kann Ihnen (als Einwählbenutzer) sagen, dass dieselbe Seite über SSL um ein Vielfaches langsamer ist als über normales HTTP ...

6
Brian Knoblauch

Ich habe ein kleines Experiment durchgeführt und 16% Zeitunterschied für dasselbe Bild von flickr (233 kb) erhalten:

http://farm8.staticflickr.com/7405/13368635263_d792fc1189_b.jpg

https://farm8.staticflickr.com/7405/13368635263_d792fc1189_b.jpg

enter image description here

Natürlich hängen diese Zahlen von vielen Faktoren ab, wie der Computerleistung, der Verbindungsgeschwindigkeit, der Serverauslastung und der QoS auf dem Pfad (dem bestimmten Netzwerkpfad, der vom Browser zum Server genommen wird), aber es zeigt die allgemeine Idee: HTTPS ist Slowser, dann HTTP, da es Es sind weitere Vorgänge erforderlich (SSL-Handshake und Kodierung/Dekodierung von Daten).

4
Khachatur

Hier ist ein großartiger Artikel (ein bisschen alt, aber immer noch großartig) über die Latenz von SSL-Handshakes. Ich konnte SSL als Hauptursache für Langsamkeit bei Kunden identifizieren, die meine App über langsame Internetverbindungen verwendeten:

http://www.semicomplete.com/blog/geekery/ssl-latency.html

3
OrPo

HTTP VS HTTPS-LEISTUNGSVERGLEICH

Ich habe immer HTTPS mit langsameren Seitenladezeiten im Vergleich zu einfachem altem HTTP in Verbindung gebracht. Als Webentwickler ist mir die Leistung von Webseiten wichtig und alles, was die Leistung meiner Webseiten verlangsamt, ist ein Nein-Nein.

Um die Auswirkungen auf die Leistung zu verstehen, finden Sie in der folgenden Abbildung eine grundlegende Vorstellung davon, was unter der Haube passiert, wenn Sie eine Ressource mithilfe von HTTPS anfordern.

enter image description here

Wie Sie aus dem obigen Diagramm ersehen können, müssen bei der Verwendung von HTTPS einige zusätzliche Schritte ausgeführt werden, verglichen mit der Verwendung von einfachem HTTP. Wenn Sie eine Anfrage über HTTPS stellen, muss ein Handshake erfolgen, um die Authentizität der Anfrage zu überprüfen. Dieser Handshake ist im Vergleich zu einer HTTP-Anfrage ein zusätzlicher Schritt und verursacht leider einen gewissen Overhead.

Um die Auswirkungen auf die Leistung zu verstehen und selbst festzustellen, ob die Auswirkungen auf die Leistung erheblich sind oder nicht, habe ich diese Website als Testplattform verwendet. Ich ging zu webpagetest.org und benutzte das visuelle Vergleichstool, um das Laden dieser Site mit HTTPS und HTTP zu vergleichen.

Wie Sie aus ersehen können, wirkte sich das Ergebnis des Testvideos mit HTTPS auf die Ladezeiten meiner Seite aus, der Unterschied ist jedoch vernachlässigbar und ich bemerkte nur eine 300 Millisekunden Unterschied. Es ist wichtig zu beachten, dass diese Zeiten von vielen Faktoren abhängen, wie z. B. der Computerleistung, der Verbindungsgeschwindigkeit, der Serverauslastung und der Entfernung vom Server.

Ihre Site kann unterschiedlich sein, und es ist wichtig, Ihre Site gründlich zu testen und die Auswirkungen auf die Leistung bei der Umstellung auf HTTPS zu überprüfen.

CAN WE IMPROVE THE PERFORMANCE? besuchen Sie hier , um detaillierte Informationen zu erhalten

2
Sunny S.M

Ist TLS schon schnell? Ja.

Es gibt viele Projekte, die darauf abzielen, die Linien zu verwischen und HTTPS genauso schnell zu machen. Wie SPDY und mod-spdy .

2

Hier scheint es einen bösen Edge-Fall zu geben: Ajax über überlastetes WLAN.

Ajax bedeutet normalerweise, dass das KeepAlive nach etwa 20 Sekunden abgelaufen ist. Das WLAN bedeutet jedoch, dass die (im Idealfall schnelle) Ajax-Verbindung mehrere Hin- und Rückflüge durchführen muss. Schlimmer noch, das WLAN verliert oft Pakete und es gibt TCP Neuübertragungen. In diesem Fall ist HTTPS wirklich sehr, sehr schlecht!

2
Richard

Da ich das gleiche Problem für mein Projekt untersuche, habe ich diese Folien gefunden. Älter aber interessant:

http://www.cs.nyu.edu/artg/research/comparison/comparison_slides/sld001.htm

2
Mircea Stanciu

Es gibt eine Möglichkeit, dies zu messen. Das Apache-Tool namens jmeter misst den Durchsatz. Wenn Sie in einer kontrollierten Umgebung mit und ohne SSL eine große Stichprobe Ihres Dienstes mit jmeter einrichten, sollten Sie einen genauen Vergleich der relativen Kosten erhalten. Ihre Ergebnisse würden mich interessieren.

0
dacracot