it-swarm.com.de

Wie kann die Ladezeit der ersten Verbindung und der SSL-Handshake-Phase einer Webseite in einem 3G-Netzwerk optimiert werden?

Meine Website www.example.com (SSL aktiviert) wird auf Amazon EC2 Shared Hosting gehostet. Es lädt schneller (Ladezeit <2 Sekunden) auf eine WLAN-/Breitbandverbindung. Problem ist im 3G-Netz im Mobilfunk ** (H-Modus und nicht H + -Modus) **. Initiieren Sie eine Verbindungsphase, und der SSL-Handshake-Vorgang dauert sehr lange - 12 Sekunden. Überwachte die Timing-Parameter über die Registerkarte Chrome Network. Unten sehen Sie den gemessenen Ladezeitpunkt für die Webseite.

Page load Network Timing Stats

Art der auf der Seite verarbeiteten Daten: Die getestete Webseite empfängt 5 mit Schlüsselwerten gepaarte JSON-Daten über AJAX und zeigt sie im Web an Seite. Es ist eine sehr leichte Seite mit nur 5-6 Textinhalten.

Ich habe gesehen, dass viele Websites in einem 3G-Mobilfunknetz (H-Modus) schneller geladen werden. Meine Website ist während der anfänglichen Verbindungsaufbauphase in einem 3G-Netzwerk zu langsam. Kann mir bitte jemand helfen, wie die Verzögerung in der anfänglichen Verbindungsphase behoben/optimiert werden kann? Behebt der Umstieg auf dediziertes Hosting das vorliegende Problem?

Der Webserver ist nicht ausgelastet und es ist immer viel CPU- UND Arbeitsspeicher verfügbar.

Serverkonfiguration: Amazon EC2-Instanz - Shared Hosting (32 CPU und 60 GB RAM). Webserver - Apache. SSL - Symantec.

9
User234334

Erstverbindung

Sie werden feststellen, dass die anfängliche Verbindung das Aushandeln des SSL umfasst. Da der Handshake also hoch ist, ist dies ein guter Indikator dafür, dass bei der Einrichtung des SSL ein schwerwiegender Fehler aufgetreten ist.

Google Chrome: Grundlegendes zum Ressourcen-Timing

Zeit, die zum Herstellen einer Verbindung benötigt wurde, einschließlich TCP Handshakes/Wiederholungen und Aushandeln eines SSL.

SSL Handshake und TTFB

Sie haben zwei Hauptprobleme: die Zeit, die Sie für den Abschluss eines SSL-Handshakes aufgewendet haben, und die Server, die auf TTFB warten (Zeit bis zum ersten Byte).

  • TTFB: 4079 ms (sollte kürzer als 1000 ms sein)
  • SSL-Handshake 11830 ms (sollte kürzer als 100 ms sein)

Es ist auch zu beachten, dass beim Testen mit 3G/4G-Geräten längere erste Bytes auftreten können, da die Stärke der Telefonsignale unterschiedlich ist. Dies kann zu zeitweiligen Verbindungsproblemen und unterschiedlichen Latenzzeiten führen.

Schritt 1: Untersuchung des SSL-Problems

Es ist ziemlich offensichtlich, dass Sie ein ernstes SSL-Problem haben und höchstwahrscheinlich auf eine fehlerhafte Installation von OpenSSL oder ähnlichem zurückzuführen sind. Testen Sie zunächst Ihr SSL-Zertifikat mit SSL Labs und korrigieren Sie dann alle darin enthaltenen Probleme oder Warnungen.

Wenn SSL immer noch langsam arbeitet, liegt höchstwahrscheinlich ein überlasteter Server oder ein Serverfehler vor. Wenn es das spätere ist, müssen Sie versuchen, den Fehler einzugrenzen. Verwenden Sie den Stapel Serverfehler , falls Sie in dieser Angelegenheit weitere Unterstützung benötigen. Ein Benutzer hat gemeldet, dass das Erstellen neuer Schlüssel ein langsames SSL-Problem behebt. ist möglicherweise nicht relevant.

Load Balancer können helfen, wenn es sich um ein Problem mit Serverressourcen handelt.

Schritt 2: Untersuchung des TTFB

Nachdem Sie das Problem mit dem SSL untersucht haben und die TTFB immer noch erhöht ist, sollten Sie Ihren Server testen, indem Sie sicherstellen, dass er über genügend Ressourcen verfügt.

Die Zeit des ersten Bytes wird beeinflusst von:

  • Die Entfernung vom Benutzer zum Rechenzentrum, in dem sich der Server befindet, kann die TTFB erhöhen
  • Nicht zwischengespeichertes GZIP kann die TTFB erhöhen
  • Überlastete Netzwerke können die TTFB erhöhen
  • Überlastete Server können die TTFB erhöhen

Manchmal ist es nicht immer die beste Option, die CPU und den RAM zu erhöhen. Manchmal ist es besser, einen Load Balancer einzuführen, da dadurch nicht nur mehrere Server nebeneinander ausgeführt werden können, sondern auch Caching- und SSL-Anforderungen ausgelagert werden. Einige andere Vorteile sind:

SOURCE

  • Caching: Die Appliance kann unveränderte Inhalte (z. B. Bilder) speichern und diese direkt an den Client senden, ohne Datenverkehr an den Webserver zu senden.
  • Komprimierung: Reduziert den Datenverkehr für HTTP-Objekte, indem Dateien vor dem Senden komprimiert werden.
  • SSL-Offloading: Die Verarbeitung des SSL-Datenverkehrs stellt hohe Anforderungen an die CPU eines Webservers, sodass ein Load Balancer diese Verarbeitung durchführen kann.
  • Hohe Verfügbarkeit: Bei Ausfall einer Appliance können zwei Load Balancing-Appliances verwendet werden.

Tipps zum Absenken Ihres TTFB:

  • Stellen Sie sicher, dass sich Ihre Datenbank im selben Netzwerk oder in einer Qualität befindet SQL Cloud .
  • Stellen Sie sicher, dass Ihre Datenbank aus dem Speicher gelesen wird und NIEMALS den SWAP Datei!
  • Verwenden Sie ein Content Delivery Network , um Serveranforderungen und Komprimierungsaufgaben auszulagern.
  • Verwenden Sie Varnish Cache , um die Datenbankbelastung durch Zwischenspeichern von Seiten zu verringern
  • Vergleichen Sie Ihre statischen Dateien auf der Festplatte mit HDParm
  • Benchmarking Ihres Servers mit Apache HTTP Server Benchmarking Tool
  • Mit WebPageTest ​​können Sie die Website mit 10 Durchläufen an mehreren entfernten Standorten vergleichen
8
Simon Hayter

Wenn Sie den Titel Ihrer Frage lesen , können Sie zwei Dinge tun, um die anfängliche Verbindung und den SSL/TLS-Handshake zu beschleunigen. Diese funktionieren für jede Verbindung, nicht nur für 3G. Sie sollten sie daher trotzdem als bewährte Methode verwenden.

Verwenden Sie zunächst HTTP/2, um die Site bereitzustellen. Dies erfordert Apache 2.4.17 oder höher .

Zweitens konfigurieren Sie Apache für die Verwendung der OCSP-Heftung. Dies erfordert Apache 2.3.3 oder höher plus OpenSSL 0.9.8h oder höher, mit einer guten Anleitung, um es hier einzurichten . Das OCSP-Heften beschleunigt die Dinge nicht, erledigt jedoch einen Teil der Arbeit für den Client und erspart ihm die Mühe, eine OCSP-Suche durchzuführen.

Wenn Sie den Haupttext Ihrer Frage lesen , haben Sie meines Erachtens ein viel größeres Problem mit Ihrer Hosting-Umgebung. Diese Ladezeiten sind nicht akzeptabel. Sie erwähnen, dass es sich um 'Shared Hosting' handelt. Wenden Sie sich an denjenigen, der das Shared Hosting verwaltet, und fragen Sie, warum sein Server so ungewöhnlich langsam ist. Sie sind wahrscheinlich besser dran, einen anderen gemeinsam genutzten Host zu testen oder einen VPS selbst auszuführen (dies ist mehr Arbeit, bietet jedoch eine höhere Geschwindigkeit und Flexibilität).

Da Sie bereits auf AWS sind, warum nicht testen Sie die kostenlose Stufe , um Dinge zu testen und Ihren eigenen Server zum Laufen zu bringen und zu optimieren? Verwenden Sie es mit einer Unterdomäne und einigen statischen HTML-Seiten zum Testen, und verschieben Sie dann Ihre primäre Site (wobei Sie bei Bedarf die Grenzen der freien Ebenen überschreiten).

6
Tom Brossman