Unterschiede zwischen HTTP und HTTPS
HTTP vs. HTTPS im Überblick
Hypertext Transfer Protocol (HTTP) ist ein Protokoll, das verwendet wird, wenn Ihr Webbrowser (Client) Informationen von einem Server anfordert.
- URL beginnt mit "http://"
- verwendet Port 80 für die Kommunikation
- ist ungesichert
- keine Verschlüsselung vorhanden
- keine Zertifikate erforderlich
Hypertext Transfer Protocol Secure (HTTPS) ist eine Kombination aus Hypertext Transfer Protocol (HTTP) sowie den Protokollen Secure Sockets Layer (SSL) und Transport Layer Security (TLS).
- URL beginnt mit "https://"
- verwendet Port 443 für die Kommunikation
- ist ein sichererer Weg, Daten von einem Client zu einem Server und zurück zu senden
- Kommunikation ist verschlüsselt
- SSL-Verschlüsselungszertifikate sind erforderlich
Warum das Protokoll beim Lasttest wichtig ist
Das Schema in Ihrer Ziel-URL, http:// versus https://, ist nicht kosmetisch. Es sagt dem Lasttest-Agenten, welches Protokoll er sprechen und auf welchem Port er standardmäßig verbinden soll, 80 für HTTP und 443 für HTTPS. Das Testen von http://example.com und https://example.com sind zwei unterschiedliche Anfragen, die möglicherweise von zwei unterschiedlichen Serverkonfigurationen behandelt werden. Stellen Sie daher sicher, dass die eingegebene URL mit der übereinstimmt, die Ihre echten Nutzer tatsächlich aufrufen.
TLS-Handshake-Overhead
HTTPS fügt vor dem Austausch jeglicher Anwendungsdaten einen TLS-Handshake hinzu: Client und Server handeln eine Verschlüsselung aus, tauschen Zertifikate aus und validieren sie und einigen sich auf Sitzungsschlüssel. Diese Aushandlung kostet zusätzliche Round-Trips und CPU-Zeit im Vergleich zu einfachem HTTP, besonders bei der ersten Verbindung. Zwei Dinge reduzieren diese Kosten in der Praxis:
- Verbindungswiederverwendung (Keep-Alive): Sobald eine TLS-Verbindung aufgebaut ist, überspringen nachfolgende Anfragen über dieselbe Verbindung den Handshake, sodass der Großteil des Overheads einmalig pro Verbindung anfällt, nicht pro Anfrage.
- Session Resumption: Modernes TLS erlaubt es einem Client, eine vorherige Sitzung ohne vollständigen Handshake wiederaufzunehmen, was die Kosten bei wiederholten Verbindungen weiter senkt.
Bei hoher Nebenläufigkeit, wenn viele virtuelle Benutzer gleichzeitig viele neue Verbindungen öffnen, werden TLS-Handshakes auf der Serverseite CPU-intensiv. Wenn Sie die Performance von HTTP und HTTPS für denselben Endpunkt vergleichen, ist zu erwarten, dass HTTPS bei verbindungsintensiven Tests etwas langsamer aussieht. Verwechseln Sie diesen Unterschied nicht mit einer Regression auf Anwendungsebene.
Zertifikatsvalidierung
Da HTTPS ein gültiges Zertifikat erfordert, muss ein Lasttest-Agent, der sich mit Ihrem Endpunkt verbindet, in der Lage sein, dieses zu validieren. Ein abgelaufenes, selbstsigniertes oder von einer privaten bzw. internen Zertifizierungsstelle ausgestelltes Zertifikat kann Verbindungsfehler verursachen, die nichts mit der tatsächlichen Performance Ihrer Anwendung zu tun haben. Wenn Sie Verbindungsfehler nur bei der HTTPS-Variante eines Endpunkts sehen, prüfen Sie die Zertifikatskette, bevor Sie von einem Last- oder Kapazitätsproblem ausgehen.
Weiterleitungen zwischen HTTP und HTTPS
Viele Seiten leiten den gesamten HTTP-Traffic mit einer 301- oder 302-Antwort auf HTTPS um. Wenn Sie einen Lasttest auf die HTTP-URL richten und erwarten, dass er direkt Ihre Anwendung erreicht, messen Sie tatsächlich den Weiterleitungs-Hop plus die anschließende HTTPS-Anfrage, was zusätzliche Latenz verursacht, die bei einem direkten Test des HTTPS-Endpunkts nicht entstehen würde. Für genaue Baseline-Werte testen Sie die endgültige HTTPS-URL, auf der Ihre Nutzer landen. Testen Sie die HTTP-URL nur dann direkt, wenn Sie gezielt das Weiterleitungsverhalten selbst messen wollen.
Was als gültige Ziel-URL zählt, einschließlich des http- oder https-Präfixes, erfahren Sie unter https://loadfocus.com/docs/de-de/knowledge-base/using-valid-url-endpoints.