
Ich habe ein Problem mit einem langsamen Apache-Server mit SSL 256bit-Zertifikat
ab -n 500 https://example.com/
Time per request 29 ms
ab -n 500 http://example.com/
Time per request 10 ms
In beiden Anfragen werden 52 Bytes gesendet und die Tests werden von einem Server im selben Rechenzentrum aus durchgeführt
Konf
SSLEngine on
SSLProtocol All -SSLv2
SSLHonorCipherOrder On
SSLCipherSuite ALL:!ADH:!EXP:!LOW:!RC2:!3DES:!SEED:!RC4:+HIGH:+MEDIUM
Ist es normal, dass SSL dreimal langsamer ist als einfache HTTP-Anfragen?
Antwort1
Wie hast du deinen Server getestet? Welche Anwendung läuft hinter deinem HTTPS-Server? Welche CPU nutzt dein Server? Wie du siehst, fehlen deiner Frage viele wichtige Details...
Wie dem auch sei, SSL ist sicherlich etwas langsamer als „reines“ HTTP: Public-Key-Kryptographie ist viel langsamer als die symmetrische Schlüsselkryptographie, und genau aus diesem Grund wird Public Key nur zum Austausch eines privaten, symmetrischen Schlüssels und als Kanal für die Umstellung auf symmetrische Schlüsselkryptographie verwendet.
Antwort2
HTTPS ist langsamer, da mehr Daten ausgetauscht werden müssen (das X.509-Zertifikat vom Server), eine sichere Datenverbindung aufgebaut werden muss usw.
ab
kann „Verbinden“ Zeit geben und dort sehen Sie den Zeitunterschied. Die TLS-Einrichtung dauert länger als keine Einrichtung.
Antwort3
Sie müssen sich über den Unterschied zwischen dem, was ab
ein Browser tut, und dem, was er tut, im Klaren sein. (Ich werde nicht darauf antworten, was ein Browser tut ab
, da ich damit nicht vertraut genug bin.)
Zum Beispiel:
- Ist
ab
die Verwendung von TLS eine Wiederverwendung von Sitzungen? Ein Browser würde dies tun und dadurch (für nachfolgende Anfragen) viel schneller arbeiten. Sie können dies mit Wireshark überprüfen (vielleichthttps://ask.wireshark.org/questions/9007/ssl-session-reuseist nützlich) - Verwendet
ab
Chiffren, von denen bekannt ist, dass sie langsam sind (Sie können im ssl_request_log sehen, welche Chiffre ausgehandelt wird) - Unterstützen Sie HTTP-Keep-Alive bei der HTTPS-Verbindung? Das sollten Sie tun, und sei es nur so lange, bis alle Assets auf einer Seite abgerufen werden können. Dadurch wird die Anzahl der an den Server gesendeten SSL/TLS-Anfragen erheblich reduziert.
- Verfügt Ihre Site über cachefreundliche Inhalte (insbesondere für den Browser-Cache) – verwenden Sie Antwortheader wie
Cache-Control: public, max-age=3600, s-max-age=3600
?
Wenn Sie sich darauf konzentrieren, können Sie eine reine HTTPS-Site problemlos schnell und gut laufen lassen. Das mache ich beispielsweise für eine Video-Streaming-Site, die (tatsächlich) nur HTTPS verwendet, und ich musste mir keine Gedanken über SSL-Verbindungszeiten machen.
Antwort4
Gründe für die Verlangsamung der Website:
SSL-Zertifikate enthalten mehrere Zwischenzertifikate, die das Datenvolumen während des Handshakes erhöhen.
Die OCSP- und CRL-Leistung wird ebenfalls nicht korrigiert, da eine Website 1/3 Sekunde benötigt, um auf eine OCSP-Anfrage zu antworten und eine Verbindung herzustellen.
Empfehlungen für schnelle HTTPS-Verbindungen:
Die Nutzung der CPU-Ressourcen kann durch die Komprimierung von Textinhalten verringert werden, oder der aktuelle Prozess kann für die Verarbeitung der Verschlüsselungsaufgabe aktualisiert werden.
Sie müssen sicherstellen, dass alles auf der Seite über HTTPS abgerufen wird.
Nehmen Sie Hilfe vonSPDY– ein Open-Source-Netzwerkprotokoll von Google, das die Ladezeit von Webseiten minimiert.
Auf der Seite der Zertifizierungsstelle können CAsReduzieren Sie die OCSP- und CRL-Antwortzeitvon 300 ms bis 100 ms (Millisekunden).
Die Zertifizierungsstelle kann die Zwischenkettengröße in SSL-Zertifikaten reduzieren, da diese zusätzliche Bytes und Zeit verbraucht.