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 Whitepaper, die dies unterstützen?

Darauf gibt es eine sehr einfache Antwort: Profilieren Sie die Leistung Ihres Webservers, um festzustellen, wie hoch die Leistungseinbußen für Ihre spezielle Situation sind. Es gibt verschiedene Tools, mit denen Sie die Leistung eines HTTP- und eines HTTPS-Servers vergleichen können (JMeter und Visual Studio kommen in den Sinn), und sie sind recht einfach zu verwenden.

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

Wie andere bereits gesagt haben, wird es aufgrund der Verschlüsselung einen gewissen Overhead geben, der jedoch in hohem Maße von folgenden Faktoren abhängt:

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

Nach meiner Erfahrung sind Server mit hohem dynamischen Inhalt tendenziell weniger von HTTPS betroffen, da die für die Verschlüsselung aufgewendete Zeit (SSL-Overhead) im Vergleich zur Zeit für die Erstellung von Inhalten unbedeutend ist.

Server, die nur einen relativ kleinen Satz statischer Seiten bereitstellen, die leicht im Speicher 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 Sitzungen 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 Client-Caching kann in mehreren Schritten erfolgen, von einem großen Proxyserver bis hin 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 speichern HTTPS-Inhalte für die aktuelle Sitzung und häufig über Sitzungen hinweg zwischen. Die Auswirkung des Nicht-Caching oder weniger Caching bedeutet, dass Clients denselben Inhalt häufiger abrufen. Dies führt zu mehr Anforderungen und Bandbreite, um die gleiche Anzahl von Benutzern zu bedienen.

HTTPS erfordert einen ersten Handshake, der sehr langsam sein kann. Die tatsächliche Datenmenge, die im Rahmen des Handshakes übertragen wird, ist nicht sehr groß (normalerweise unter 5 kB). Bei sehr kleinen Anforderungen kann dies jedoch einen erheblichen Overhead bedeuten. 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 sind viel langsamer als über HTTP. Wenn Sie jedoch viele Daten in einer einzigen Anfrage übertragen, ist der Unterschied unbedeutend.

Keepalive ist jedoch das Standardverhalten in HTTP / 1.1, sodass Sie einen einzelnen Handshake und dann viele Anforderungen über dieselbe Verbindung ausführen. Dies macht einen signifikanten Unterschied für HTTPS. Sie sollten Ihre Site wahrscheinlich profilieren (wie von anderen vorgeschlagen), um sicherzugehen, aber ich vermute, dass der Leistungsunterschied nicht spürbar ist.

Um wirklich zu verstehen, wie HTTPS Ihre Latenz erhöht, müssen Sie verstehen, wie HTTPS-Verbindungen hergestellt werden. Hier ist ein schönes Diagramm . Der Schlüssel ist, dass anstatt dass der Client die Daten nach 2 "Etappen" erhält (eine Hin- und Rückfahrt, Sie senden eine Anfrage, der Server sendet eine Antwort), der Client Daten erst nach mindestens 4 Etappen (2 Hin- und Rückfahrten) erhält. . Wenn es also 100 ms dauert, bis ein Paket zwischen dem Client und dem Server verschoben wird, dauert Ihre erste HTTPS-Anforderung mindestens 500 ms.

Dies kann natürlich durch die Wiederverwendung der HTTPS-Verbindung (was Browser tun sollten) verringert werden, aber es erklärt einen Teil dieses anfänglichen Stillstands beim Laden einer HTTPS-Website.

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 erforderlichen Roundtrips gegenüber einer HTTP-Sitzung 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 wenige wie möglich - indem Sie Ressourcen nach Möglichkeit kombinieren (z. B. .js enthalten Dateien, CSS) und das clientseitige Caching fördern
• Reduzieren Sie die Anzahl der Seitenladevorgänge, z. B. indem Sie nicht erforderliche Daten in die Seite laden (möglicherweise in einem versteckten HTML-Element) und diese dann mithilfe eines Client-Skripts anzeigen.

Dezember 2014 Update

Mit der HTTP- und HTTPS-Test- Website von AnthumChris können Sie den Unterschied zwischen HTTP- und HTTPS-Leistung in Ihrem eigenen Browser problemlos testen : „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, über aktuelle Kenntnisse der HTTPS-Leistung zu verfügen, da die Let's Encrypt Certificate Authority dank Mozilla, Akamai, Cisco, Electronic Frontier Foundation und IdenTrust ab Sommer 2015 kostenlose, automatisierte und offene SSL-Zertifikate ausstellt.

Update Juni 2015

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

• Lassen Sie uns den Startplan verschlüsseln (16. Juni 2015)
• Verschlüsseln wir Root- und Zwischenzertifikate (4. Juni 2015)
• Entwurf der Vereinbarung zum Abonnieren von Abonnenten (21. Mai 2015)

Weitere Infos auf Twitter: @letsencrypt

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

• Ist TLS schon schnell?
• Hochleistungs-Browsernetzwerk, Kapitel 4: Sicherheit der Transportschicht
• SSL übertakten
• Anatomie und Leistung der SSL-Verarbeitung

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

• Warum HTTPS für alles? (Der Nur-HTTPS-Standard)
• Verschlüsseln (Internet Security Research Group)
• HTTPS Everywhere (Electronic Frontier Foundation)

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

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

Die aktuelle Top-Antwort ist nicht vollständig korrekt.

Wie andere hier bereits erwähnt haben, 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 etwa 200 ms betragen kann (Torundtrip-Zeit).

Sie können dies einfach (für den Einzelbenutzerfall) mit HTTPWatch messen .

Beachten Sie außerdem, dass einige (alle?) Webbrowser aus Sicherheitsgründen keine zwischen 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 Volumen der Anforderungen für statischen Inhalt über HTTPS höher ist als über HTTP.

Darauf gibt es keine einzige Antwort.

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

Teurer als die Massenkrypto sind die Handshake-Kosten. Neue Verbindungen verbrauchen viel mehr CPU. Dies kann durch die Wiederaufnahme der Sitzung verringert werden, wobei alte Sitzungsgeheimnisse bis zu ihrem Ablauf aufbewahrt werden müssen. 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 gering ist. Aber Sie werden es sicherlich bei der CPU-Auslastung auf einem ausgelasteten Server bemerken.

Ich kann Ihnen (als DFÜ-Benutzer) sagen, dass dieselbe Seite über SSL um ein Vielfaches langsamer ist als über normales HTTP ...

In einigen Fällen werden die Auswirkungen von SSL-Handshakes auf die Leistung durch die Tatsache gemindert, dass die SSL-Sitzung an beiden Enden (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 zwischenspeichern können, zu der die Sitzung zwischengespeichert wird.

Eine weitere zu berücksichtigende Auswirkung besteht darin, dass statische Inhalte, die über HTTPS bereitgestellt werden, nicht von Proxys zwischengespeichert werden. Dies kann die Leistung mehrerer Benutzer verringern, die über denselben Proxy auf die Site zugreifen. Dies kann durch die Tatsache gemindert werden, dass statische Inhalte auch auf Desktops zwischengespeichert werden. Internet Explorer-Versionen 6 und 7 zwischenspeichern statische HTTPS-Inhalte zwischen Cache, sofern nicht anders angegeben (Menü Extras / Internetoptionen / Erweitert / Sicherheit / Verschlüsselte Seiten nicht speichern) auf die Festplatte).

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

Natürlich hängen diese Zahlen von vielen Faktoren ab, wie Computerleistung, Verbindungsgeschwindigkeit, Serverlast, QoS-Pfad (der bestimmte Netzwerkpfad vom Browser zum Server), aber es zeigt die allgemeine Idee: HTTPS ist langsamer als HTTP, da es Es sind weitere Vorgänge erforderlich (SSL-Handshake und Codierung / Decodierung von Daten).

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

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

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

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

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

Ist TLS schon schnell? Ja.

• Beobachten Sie: https://www.youtube.com/watch?v=0EB7zh_7UE4
• Lesen Sie: https://istlsfastyet.com/

Es gibt viele Projekte, die darauf abzielen, die Grenzen zu verwischen und HTTPS genauso schnell zu machen. Wie SPDY und Mod-Spdy .

HTTP VS HTTPS LEISTUNGSVERGLEICH

Ich habe HTTPS immer mit langsameren Ladezeiten von Seiten 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, gibt Ihnen das folgende Diagramm eine grundlegende Vorstellung davon, was unter der Haube passiert, wenn Sie mithilfe von HTTPS eine Ressource anfordern.

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

Um die Auswirkungen auf die Leistung zu verstehen und selbst zu sehen, 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 mit HTTP zu vergleichen.

Wie Sie hier sehen können, ist Test Video Ergebnis mit HTTPS einen Einfluss auf die Ladezeiten meiner Seite. Der Unterschied ist jedoch vernachlässigbar und ich habe nur einen Unterschied von 300 Millisekunden festgestellt. Es ist wichtig zu beachten, dass diese Zeiten von vielen Faktoren abhängen, wie z. B. der Computerleistung, der Verbindungsgeschwindigkeit, der Serverlast und der Entfernung zum Server.

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

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

HTTPS hat einen Verschlüsselungs- / Entschlüsselungsaufwand, sodass es immer etwas langsamer ist. Die SSL-Beendigung ist sehr CPU-intensiv. Wenn Sie Geräte zum Auslagern von SSL haben, ist der Unterschied in den Latenzen je nach Auslastung Ihrer Server möglicherweise kaum spürbar.

Ein wichtigerer Leistungsunterschied besteht darin, dass eine HTTPS-Sitzung ketp-geöffnet ist, während der Benutzer verbunden ist. Eine HTTP-Sitzung dauert nur für eine einzelne Elementanforderung.

Wenn Sie eine Site mit einer großen Anzahl gleichzeitiger Benutzer betreiben, erwarten Sie, dass Sie viel Speicher kaufen.

Dies wird mit ziemlicher Sicherheit zutreffen, da für SSL ein zusätzlicher Verschlüsselungsschritt erforderlich ist, der für Nicht-SLL-HTTP einfach nicht erforderlich ist.

Das HTTPS beeinflusst tatsächlich die Seitengeschwindigkeit ...

Die obigen Zitate zeigen die Dummheit vieler Menschen in Bezug auf die Sicherheit und Geschwindigkeit der Website. Das Handshake von HTTPS / SSL-Servern führt zu einem anfänglichen Stillstand beim Herstellen von Internetverbindungen. Es gibt eine langsame Verzögerung, bevor etwas auf dem Browserbildschirm Ihres Besuchers gerendert wird. Diese Verzögerung wird in Informationen zur Zeit bis zum ersten Byte gemessen.

Der HTTPS-Handshake-Overhead wird in den Time-to-First-Byte-Informationen (TTFB) angezeigt. Übliche TTFB reichen von unter 100 Millisekunden (Best-Case) bis über 1,5 Sekunden (Worst-Case). Aber mit HTTPS sind es natürlich 500 Millisekunden schlimmer.

Drahtlose 3G-Roundtrip-Verbindungen können 500 Millisekunden oder länger dauern. Die zusätzlichen Fahrten verdoppeln die Verzögerungen auf 1 Sekunde oder mehr. Dies ist ein großer negativer Einfluss auf die mobile Leistung. Sehr schlechte Nachrichten.

Mein Rat: Wenn Sie keine vertraulichen Daten austauschen, benötigen Sie überhaupt kein SSL. Wenn Sie jedoch eine E-Commerce-Website mögen, können Sie HTTPS nur auf bestimmten Seiten aktivieren, auf denen vertrauliche Daten wie Anmelden und Auschecken ausgetauscht werden.

Quelle: Pagepipe

Browser können das HTTP / 1.1-Protokoll entweder mit HTTP oder HTTPS akzeptieren, Browser können jedoch nur das HTTP / 2.0-Protokoll mit HTTPS verarbeiten. Die Protokollunterschiede von HTTP / 1.1 zu HTTP / 2.0 machen HTTP / 2.0 im Durchschnitt 4-5 mal schneller als HTTP / 1.1. Von Websites, die HTTPS implementieren, tun dies die meisten über das HTTP / 2.0-Protokoll. Daher ist HTTPS aufgrund des unterschiedlichen Protokolls, das es im Allgemeinen verwendet, fast immer schneller als HTTP. Wenn jedoch HTTP über HTTP / 1.1 mit HTTPS über HTTP / 1.1 verglichen wird, ist HTTP im Durchschnitt etwas schneller als HTTPS.

Hier sind einige Vergleiche, die ich mit Chrome (Ver. 64) durchgeführt habe:

HTTPS über HTTP / 1.1:

• 0,47 Sekunden durchschnittliche Ladezeit der Seite
• 0,05 Sekunden langsamer als HTTP über HTTP / 1.1
• 0,37 Sekunden langsamer als HTTPS über HTTP / 2.0

HTTP über HTTP / 1.1

• Durchschnittliche Ladezeit von 0,42 Sekunden
• 0,05 Sekunden schneller als HTTPS über HTTP / 1.1
• 0,32 Sekunden langsamer als HTTPS über HTTP / 2.0

HTTPS über HTTP / 2.0

• 0,10 Sekunden durchschnittliche Ladezeit
• 0,32 Sekunden schneller als HTTP über HTTP / 1.1
• 0,37 Sekunden schneller als HTTPS über HTTPS / 1.1