Java-Socket-HTTP-CONNECT-Tunnel in OpenJDK 25

Nutzen Sie den HTTP-Proxy-Socket-Pfad in OpenJDK 25, um einen erlaubten TCP-Dienst zu erreichen, während Proxy-Endpunkt und Ziel getrennt bleiben.

Ein eigenes TCP-Protokoll kann durch einen HTTP-Proxy laufen, wenn dieser Proxy CONNECT zum Ziel erlaubt. Das Anwendungsprotokoll muss nicht zu HTTP werden: HTTP baut den Tunnel auf, danach tauscht die Anwendung ihre eigenen Bytes darin aus.

OpenJDK 25 bietet einen HTTP-Proxy-Pfad in Socket(Proxy). Seine Implementierung führt den CONNECT-Austausch aus und gibt einen verbundenen Socket zur Nutzung durch die Anwendung zurück.

Proxy route = new Proxy(
    Proxy.Type.HTTP,
    new InetSocketAddress("proxy.example", 8080));

try (Socket socket = new Socket(route)) {
    socket.setSoTimeout(10000);
    socket.connect(
        InetSocketAddress.createUnresolved("tcp-service.example", 8443),
        5000);
    InputStream input = socket.getInputStream();
    OutputStream output = socket.getOutputStream();
}

Dieses Fragment verwendet Klassen aus java.net und java.io. Ersetzen Sie die beiden Endpunkte und führen Sie den Protokollaustausch aus, bevor Sie den try-Block verlassen. Für ein erlaubtes öffentliches TCP-Ziel wählen Sie HTTP-Kandidaten aus der HTTP-Proxy-Liste erst, nachdem Sie die CONNECT-Berechtigung für den Port dieses Ziels geprüft haben. Die Proxy-Adresse ist der Ort, an den Java zuerst verbindet; die an connect übergebene Adresse bezeichnet den Dienst, den der Proxy erreichen soll.

Das unaufgelöste Ziel behält seinen Hostnamen für die CONNECT-Anfrage dieser Implementierung. Ein aufgelöster InetSocketAddress übergibt dieser Anfrage stattdessen seine aufgelöste IP-Adresse. Dieser Unterschied zählt, wenn der Proxy den Dienstnamen auflösen oder eine hostnamenbasierte Richtlinie anwenden muss.

Was Ihnen eine erfolgreiche Verbindung lässt

Die entstehenden Streams tragen die Daten des getunnelten Dienstes. Sie legen keine separate HTTP-Antwort offen, die Ihre Anwendung lesen und verwerfen sollte. Ein zweiter CONNECT-Austausch würde HTTP-Text an den Dienst senden, nachdem das JDK den Tunnel bereits aufgebaut hat.

Das Beispiel setzt ein Verbindungszeitlimit und ein Socket-Lesezeitlimit; das sind getrennte Steuerungen, keine gemeinsame Gesamtfrist für die Anwendungssitzung.

Die CONNECT-Berechtigung liegt weiterhin beim Proxy. Ein Endpunkt, der gewöhnliche Webanfragen weiterleitet, kann den Port des Dienstes ablehnen oder vor dem Öffnen eines Tunnels eine Authentifizierung verlangen. Halten Sie diese Fehler getrennt von einem Server, der den Tunnel annimmt, aber später Ihr Anwendungsprotokoll ablehnt.

Wenn dieses Protokoll TLS benötigt, handeln Sie TLS über den verbundenen Socket mit dem vorgesehenen Hostnamen des Dienstes und den üblichen Zertifikatsprüfungen aus. CONNECT allein verschlüsselt den Stream nicht. Für eine echte HTTP-API bleibt ein HTTP-Client die bequemere Schnittstelle, weil er auch HTTP-Nachrichten verarbeitet.

Ähnliche Artikel