SOCKS- und HTTP-Proxies: Unterschiede, Geschwindigkeit und Protokollwahl
HTTP- und SOCKS-Proxies verbinden eine Anwendung über einen Vermittler mit dem Ziel. Für Browser, Scraper oder API-Clients ist ein HTTP-Proxy mit CONNECT ein praktischer Ausgangspunkt. SOCKS5 hilft, wenn die Anwendung SOCKS erwartet, andere TCP-Protokolle benötigt oder UDP-Weiterleitung unterstützt. Beide können Datenverkehr zu HTTPS-Websites transportieren.
Das Protokoll bestimmt, wie das Programm mit dem Proxy spricht. Herkunft der Ausgangs-IP-Adresse, Rotation und gemeinsamer oder dedizierter Zugang sind getrennte Entscheidungen, die der Leitfaden zu Proxytypen und ihrer Auswahl erklärt. Der Wechsel von HTTP zu SOCKS ändert diese Eigenschaften nicht automatisch.
Wie HTTP und SOCKS eine Verbindung behandeln
HTTP-Weiterleitung: Der Proxy verarbeitet eine Webanfrage
Bei einer gewöhnlichen unverschlüsselten HTTP-Anfrage sendet der Client Ziel-URL, Methode und Header an den Proxy. Dieser verarbeitet die Anfrage und holt die Antwort vom Ziel. Er kann HTTP-Regeln anwenden, Header ändern oder bei entsprechender Einrichtung einen Cache verwenden. Das sind mögliche HTTP-Proxyfunktionen; ein Dienst aktiviert nicht zwangsläufig alle.
SOCKS5: Der Proxy öffnet eine Verbindung für die Anwendung
Der Client vereinbart ein Authentifizierungsverfahren, authentifiziert sich bei Bedarf und übermittelt Zieladresse und Port. Der Proxy baut die angeforderte TCP-Verbindung auf und leitet die Bytes der Anwendung weiter. Derselbe Mechanismus kann HTTPS, SSH oder ein anderes unterstütztes TCP-Anwendungsprotokoll transportieren. Der Proxy muss dafür keine HTTP-Anfragen auswerten.
HTTPS über CONNECT: Beide Verfahren nähern sich an
Beim Öffnen einer HTTPS-Website über einen herkömmlichen HTTP-Proxy sendet der Client normalerweise eine CONNECT-Anfrage. Nach Annahme des Tunnels baut der Client darin TLS zur Website auf. Der Proxy leitet verschlüsselte Daten weiter. SOCKS5 kann denselben TLS-Austausch nach seinem eigenen Verbindungsaufbau weiterleiten.
Das ist für Geschwindigkeits- und Datenschutzvergleiche wichtig: Ein HTTP-Proxy mit HTTPS-Tunnel analysiert nicht jede verschlüsselte Seitenanfrage. Beide Typen leiten geschützten Datenverkehr weiter. Ablauf sowie Unterschied zwischen HTTP-Weiterleitung und Tunnel erklärt HTTP- und HTTPS-Proxies.
HTTP und SOCKS5 im Überblick
Der folgende Vergleich verwendet SOCKS5. Die älteren Varianten SOCKS4 und SOCKS4a haben weniger Funktionen und sind hauptsächlich relevant, wenn bestehende Software sie benötigt.
| Funktion | HTTP- / HTTPS-Proxy | SOCKS5-Proxy |
|---|---|---|
| Webanfragen | HTTP-Weiterleitung; HTTPS verwendet gewöhnlich einen CONNECT-Tunnel. | Die Anwendung sendet HTTP oder HTTPS durch die aufgebaute Verbindung. |
| Andere TCP-Anwendungen | Über CONNECT möglich, wenn der Client dies unterstützt und der Zielport erlaubt ist. | Passend für Anwendungen mit SOCKS-Unterstützung; Dienstregeln gelten weiterhin. |
| DNS des Ziels | Der Proxy kann den Hostnamen aus Anfrage oder CONNECT-Ziel auflösen. | Der Client kann einen Hostnamen zur entfernten Auflösung senden oder ihn vorher lokal auflösen. |
| Schutz bis zum Proxy | Ein HTTPS-Proxy verwendet für diese Verbindung TLS. Ein einfacher HTTP-Proxy nicht. | Übliche Verfahren ohne Authentifizierung oder mit Benutzername/Passwort verschlüsseln diese Verbindung nicht. |
| Zugangskontrolle | HTTP-Authentifizierungsverfahren und/oder Zugangsregeln wie eine IP-Zulassungsliste. | Ausgehandelte Authentifizierungsverfahren und/oder Zugangsregeln wie eine IP-Zulassungsliste. |
| UDP | Gewöhnliches CONNECT reicht nicht. UDP benötigt einen zusätzlich unterstützten Tunnelmechanismus. | Im Protokoll definiert, muss aber von Client und Dienst implementiert sein. |
| Leistung | Ein neuer HTTPS-Tunnel kann weniger Umläufe zum Aufbau benötigen. Die Übertragungsrate hängt auch von Implementierung und Weg ab. | Hat einen eigenen Verbindungsdialog. Fehlende HTTP-Auswertung garantiert keine schnelleren HTTPS-Übertragungen. |
Was ist schneller: HTTP oder SOCKS5?
Eine neue HTTPS-Verbindung kann über HTTP CONNECT früher bereit sein, weil der übliche Aufbau weniger Dialoge mit dem Proxy verlangt. Der folgende Vergleich zeigt die zugrunde liegenden Annahmen. Ein offener Tunnel kann für lange Downloads oder spätere Anfragen wiederverwendet werden. Kein Protokoll hat einen festen Vorteil bei dauerhafter Übertragungsgeschwindigkeit.
Neue Verbindungen: die Dialoge zählen
Gezählt werden die Aufbau-Nachrichten, nachdem die TCP-Verbindung zum Proxy steht, wobei jede Anfrage auf ihre Antwort wartet. Dieser Vergleich verwendet kein TLS zum Proxy. HTTP-Authentifizierung ist entweder unnötig oder gelingt mit Zugangsdaten in der ersten CONNECT-Anfrage.
| Verbindungsverfahren | Dialoge bis zum fertigen Tunnel |
|---|---|
HTTP CONNECT | 1: CONNECT-Anfrage und erfolgreiche Antwort. |
| SOCKS5 ohne Protokollauthentifizierung | 2: Verfahrensauswahl, danach Verbindungsanfrage und Antwort. |
| SOCKS5 mit Benutzername und Passwort | 3: Verfahrensauswahl, Prüfung von Benutzername/Passwort, danach Verbindungsanfrage und Antwort. |
Unter diesen Annahmen benötigt SOCKS5 ohne Authentifizierung einen zusätzlichen Client-Proxy-Umlauf und mit üblicher Benutzername-Passwort-Authentifizierung zwei. Ein Umlauf, auch RTT, ist die Zeit einer Nachricht zum Proxy und ihrer Antwort zurück. Bei einer beispielhaften RTT von 50 ms verursachen die zusätzlichen Dialoge ungefähr 50 oder 100 ms. Das ist eine Schätzung aus dem Protokollablauf, kein Dienst-Benchmark und keine gesamte Anfragedauer.
Beide Wege verlangen außerdem eine Proxyverbindung zum Ziel und den TLS-Aufbau des Clients zur Website. DNS-Zeit, Verarbeitung und Überlastung können unterschiedlich sein. Eine HTTP-Authentifizierungsanforderung fügt Dialoge hinzu; TLS zu einem HTTPS-Proxy benötigt einen eigenen Aufbau. Diese Fälle gehören in den Vergleich der tatsächlichen Konfigurationen.
Wiederverwendete Verbindungen: Der anfängliche Unterschied verteilt sich auf Anfragen
Ein Verbindungspool hält geeignete Verbindungen für spätere Anfragen bereit. Die Wiederverwendung einer HTTPS-Verbindung vermeidet erneutes TCP, Proxy-Aushandlung und TLS-Handshake zur Website je Anfrage. Unterstützen Client und Ziel HTTP/2, können mehrere Anfrageströme eine bestehende Verbindung teilen. Das funktioniert sowohl in einem HTTP-CONNECT-Tunnel als auch über SOCKS5. Der Proxy muss die HTTP/2-Nachrichten innerhalb von TLS nicht auswerten.
Ein neues HTTP-Clientobjekt je URL kann dessen Verbindungspool verwerfen. Wiederverwendung eines Clients bedeutet hier das Beibehalten des Softwareobjekts und seiner Verbindungen, keine Anforderung zur IP-Beibehaltung beim Proxy. Bei wiederholten Anfragen an dieselben Hosts kann dies mehr Aufbauarbeit sparen als ein Protokollwechsel. Neue Ziele, geschlossene Verbindungen und geänderte Proxyeinstellungen können weiterhin neue Tunnel verlangen.
Große Übertragungen: die verfügbare Bandbreite betrachten
Nach dem Tunnelaufbau hängt die Downloadgeschwindigkeit von Übertragungsweg, Paketverlust, verfügbarer Bandbreite, Proxylast und Dienstlimits ab. Die Weiterleitung von HTTPS durch CONNECT ist bereits reine Byteweiterleitung. SOCKS5 wegen fehlender HTTP-Auswertung pauschal als schneller zu bezeichnen, übersieht diesen Fall.
Bei unverschlüsseltem HTTP können eingerichtetes Caching oder Inhaltsverarbeitung das Ergebnis verändern. Eine Cacheantwort ist eine andere Aufgabe als der Download desselben Inhalts vom Ursprungsserver. Ein fairer Vergleich berücksichtigt diesen Unterschied.
Welches Protokoll eignet sich für ein großes Webskript?
Auch mit SOCKS5 stellt ein Webskript HTTP-Anfragen; die Proxyeinstellung verändert den Weg zum Server. Beginnen Sie bei einem neuen Skript für Webseiten oder HTTPS-APIs mit einem ausgereiften HTTP-Client und HTTP CONNECT, sofern keine konkrete Anforderung dagegenspricht. Halten Sie die Proxyauswahl konfigurierbar, um SOCKS5 mit derselben Anfragelogik testen zu können. Ist dieser Vergleich wichtig, wählen Sie eine Bibliothek mit Unterstützung beider Varianten.
| Aufgabe | Praktischer Ausgangspunkt |
|---|---|
| Viele kurze Anfragen, häufig an neue Hosts | Zuerst HTTP CONNECT testen. Die kürzere Aushandlung kann bei häufigen neuen Tunneln helfen. Messen Sie vollständig erfolgreiche Anfragen. |
| Viele Anfragen an wenige APIs oder Websites | Einen dauerhaften Client, Verbindungspooling und gegebenenfalls HTTP/2 verwenden. HTTP und SOCKS5 nach Prüfung der Wiederverwendung vergleichen. |
| Große Dateien oder langlebige TCP-Sitzungen | Das gut unterstützte Protokoll wählen und dauerhaften Durchsatz sowie Unterbrechungen testen. Die Aufbauzeit macht einen kleineren Aufgabenanteil aus. |
| Andere TCP-Protokolle oder eine benötigte UDP-Funktion | SOCKS5 erwägen, wenn die Anwendung den benötigten Modus unterstützt. Ist UDP unverzichtbar, den Datagrammaustausch über den Proxy in Anwendung und Dienst prüfen. |
Asynchrone Software kann HTTP und SOCKS5 verwenden. Das Proxyprotokoll entscheidet nicht über parallele Anfragen. Prüfen Sie, ob die Clientbibliothek den gewählten Modus parallel verwenden, den Verbindungspool erhalten und laufende Vorgänge begrenzen kann. Erhöhen Sie die Parallelität unter Beobachtung abgeschlossener Aufgaben und Fehler. Erreichen Proxy, Netzwerk oder Ziel ihre Grenze, können zusätzliche Verbindungen längere Warteschlangen und mehr Wiederholungsversuche verursachen.
Die Geschwindigkeit vor der Erweiterung vergleichen
- Verwenden Sie dasselbe Programm, dieselben Zielanfragen, Antwortgrößen und dieselbe Parallelität. Vergleichen Sie möglichst Protokollendpunkte mit derselben Ausgangs-IP-Adresse und demselben Weg. Andernfalls halten Sie Ausgangsregion und Dienstlimits vergleichbar und dokumentieren den Unterschied.
- Führen Sie eine Reihe mit neuen Verbindungen und eine weitere nach Aufwärmphase mit gewöhnlichem Pooling aus. Halten Sie DNS-Verhalten, TLS-Schutz, Authentifizierung, HTTP-Version und Wiederholungsregeln gleich oder begründen Sie Unterschiede.
- Messen Sie erfolgreiche abgeschlossene Vorgänge pro Sekunde und die Dauer der gesamten Reihe einschließlich Wiederholungsversuchen. Erfassen Sie außerdem Median und 95. Perzentil der Abschlusszeit, Zeitüberschreitungen und fehlgeschlagene Vorgänge. Das 95. Perzentil zeigt die Zeit, innerhalb der 95% der gemessenen Vorgänge abgeschlossen sind.
- Erfassen Sie bei Downloads nutzbare Bytes pro Sekunde. Trennen Sie bei kurzen Anfragen Verbindungsaufbau, Zeit bis zum ersten Byte und vollständige Antwortzeit. Die Zeit bis zum ersten Byte umfasst auch das Warten auf die Antworterzeugung beim Ziel.
- Wiederholen Sie abwechselnd beide Konfigurationen und prüfen Sie den vorgesehenen Proxyweg. Nutzt ein Test einen anderen Ausgangspool oder eine direkte Ersatzverbindung, isoliert sein Ergebnis das Proxyprotokoll nicht.
Wählen Sie die Konfiguration, die die tatsächliche Aufgabe bei akzeptabler Fehlerquote schneller erledigt. Ein schneller Authentifizierungsfehler oder eine unvollständige Antwort ist kein nutzbarer Durchsatz. Bei ähnlicher Leistung bevorzugen Sie die in der Anwendung einfacher betreubare Variante.
Warum Anwendungsunterstützung zuerst kommt
Ein Feld namens „Proxy“ verspricht nicht jedes Protokoll oder Authentifizierungsverfahren. Beispielsweise unterstützt die eingebaute SOCKS5-Verarbeitung von Chrome TCP-Anfragen, implementiert aber weder SOCKS5-Benutzername-Passwort-Authentifizierung noch UDP-Weiterleitung. Ein entsprechend ausgestatteter SOCKS5-Dienst kann einen nicht unterstützten Browsermodus nicht dazu befähigen.
Für SSH, Dateitransfer oder andere TCP-Anwendungen kann native SOCKS-Unterstützung praktisch sein. Auch HTTP CONNECT kann andere TCP-Protokolle transportieren, sofern das Programm den Tunnel aufbauen kann und der Proxy den Zielport erlaubt. „HTTP-Proxy“ bedeutet deshalb nicht immer „nur Webdatenverkehr“.
Browser-Proxyeinstellungen erfassen nicht automatisch andere Programme oder jede Browserfunktion. Externe Adapter haben eigene Abdeckung und Einschränkungen. Versionsunterschiede und Aushandlung behandelt SOCKS5- und SOCKS4-Proxies.
Wer löst den Zielhostnamen auf?
Bei SOCKS5 kann die Anwendung das Ziel lokal auflösen und eine IP-Adresse senden oder einen Hostnamen zur Auflösung durch den Proxy übermitteln. In curl wählt socks5:// lokale Zielauflösung, während socks5h:// Auflösung durch den Proxy anfordert. Der zusätzliche Buchstabe steuert den Client; er erzeugt kein neues SOCKS-Protokoll.
HTTP-Proxies können Zielnamen aus URLs oder CONNECT-Anfragen ebenfalls auflösen. Entfernte Ziel-DNS-Auflösung ist daher bei beiden Protokollen verfügbar. Eine Auflösung auf Proxyseite kann eine andere Serveradresse liefern und vermeidet die lokale Auflösung dieses Ziels. Der Client muss möglicherweise weiterhin den Proxyhostnamen auflösen; andere Anwendungen behalten eigene DNS-Einstellungen. Wählen Sie das DNS-Verhalten im Client, statt es aus dem Protokoll abzuleiten.
Welche Verbindung ist verschlüsselt?
Unterscheiden Sie den Schutz des Websiteinhalts vom Schutz der Verbindung zum Proxy. Eine HTTPS-Website verschlüsselt Anwendungsdaten normalerweise zwischen Client und Website durch beide Tunnelarten. Vorausgesetzt sind gewöhnliche Zertifikatsprüfung und keine eingerichtete TLS-Entschlüsselung durch einen Vermittler.
Ein HTTPS-Proxy ergänzt TLS zwischen Client und Proxy. Es schützt Proxyanfrage und Zugangsdaten auf diesem Wegabschnitt. In einer Proxyadresse bezeichnet https:// gewöhnlich diese geschützte Verbindung. Eine Einstellung namens „Proxy für HTTPS-Websites“ kann dagegen einen einfachen HTTP-Proxy mit CONNECT-Unterstützung meinen.
HTTP-Basic-Zugangsdaten an einen einfachen HTTP-Proxy und der übliche SOCKS5-Benutzername-Passwort-Austausch sind für Beobachter dieses ungeschützten Netzwerkwegs lesbar. Die spätere TLS-Verbindung zur Website schützt die Proxyanmeldung nicht nachträglich. Gewöhnliches SOCKS5 benötigt einen zusätzlichen sicheren Transport, wenn dieser Schutz erforderlich ist.
Der Proxy bleibt Endpunkt seiner eigenen TLS-Verbindung und kennt das gewünschte Verbindungsziel. Verwendet das endgültige Ziel einfaches HTTP, verschlüsselt TLS zum Proxy die weiterführende HTTP-Verbindung nicht. Ebenso versteckt SOCKS-Weiterleitung keine Klartextinhalte, nur weil der Proxy sie nicht auswerten muss.
Ändern UDP oder HTTP/3 die Auswahl?
Für Anwendungen mit tatsächlichem UDP-Bedarf definiert SOCKS5 UDP ASSOCIATE. Client und Dienst müssen es implementieren, und der Netzwerkweg muss die Datagramme transportieren. Gewöhnliches HTTP CONNECT trägt einen TCP-Tunnel. HTTP-basierte UDP-Weiterleitung ist über Zusatzverfahren wie CONNECT-UDP möglich, die beide Seiten unterstützen müssen.
HTTP/3 verwendet QUIC über UDP. Eine erfolgreich über den Proxy geladene HTTPS-Seite beweist keine HTTP/3-Funktion: Der Client könnte HTTP/2 oder HTTP/1.1 über TCP verwendet haben. Das kann für ein Webskript passen, ersetzt aber UDP nicht bei Funktionen mit Datagrammbedarf. UDP und QUIC über Proxies erklärt Weiterleitungswege und Grenzen.
Verbirgt SOCKS den Client besser?
Bei unverschlüsselter HTTP-Weiterleitung kann ein Proxy Header wie Forwarded mit Informationen über den ursprünglichen Client ergänzen. Ein herkömmlicher HTTPS-CONNECT-Tunnel kann diesen Header nicht in die verschlüsselte Anfrage einfügen, ohne die TLS-Verbindung zur Website zu beenden. Auch SOCKS5 fügt nicht automatisch HTTP-Header hinzu.
Das garantiert bei keinem Protokoll Anonymität oder Websiteakzeptanz. Der Proxybetreiber kann Verbindungsmetadaten beobachten; das Ziel kann Konto, Cookies oder Anwendungsverhalten erkennen. Der Ruf der Ausgangs-IP-Adresse und die Anzahl ihrer Mitnutzer sind getrennte Faktoren. Ein Wechsel von HTTP zu SOCKS beim selben Dienst entfernt nicht automatisch Sperren und setzt keine Websitesitzung zurück.
Die endgültige Wahl treffen
Beginnen Sie mit den Protokollen und Zugangsverfahren der Anwendung. Für gewöhnliche Webautomatisierung ist HTTP CONNECT ein guter erster Ansatz. Für SOCKS-basierte Anwendungen oder unterstützte UDP-Modi kann SOCKS5 besser passen. Wählen Sie anschließend das benötigte DNS-Verhalten und den Schutz zum Proxy und vergleichen Sie die tatsächliche Aufgabenleistung.
Verwenden Sie den echten Hostnamen und Port des Dienstes für das gewählte Protokoll. Der Austausch von http:// gegen socks5:// in einer Konfiguration aktiviert kein SOCKS auf einem Server, der es nicht anbietet. Bestätigen Sie vor der Erweiterung den erwarteten Proxyweg und prüfen Sie, dass ein ausgefallener Proxy keinen unerwünschten direkten Weg auslöst.