Java Socket HTTP CONNECT тунели во OpenJDK 25

Користете ја патеката на HTTP прокси сокет во OpenJDK 25 за да стигнете до дозволена TCP услуга, а крајната точка на проксито и одредиштето држете ги одделно.

Сопствен TCP протокол може да патува низ HTTP прокси кога тоа прокси дозволува CONNECT кон одредиштето. Апликацискиот протокол не мора да стане HTTP: HTTP воспоставува тунел, а потоа апликацијата ги разменува своите бајти внатре во него.

OpenJDK 25 обезбедува патека низ HTTP прокси во Socket(Proxy). Неговата имплементација ја изведува CONNECT размената и враќа поврзан сокет за апликацијата да го користи.

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();
}

Овој фрагмент користи класи од java.net и java.io. Заменете ги двете крајни точки и изведете ја размената на протоколот пред да излезете од блокот try. За дозволена јавна TCP цел, изберете HTTP кандидати од списокот на HTTP прокси само откако ќе го проверите дозволата за CONNECT за портата на таа цел. Адресата на проксито е местото каде Java прво се поврзува; адресата што се пренесува на connect ја идентификува услугата до која проксито треба да стигне.

Неразрешеното одредиште го задржува своето име на домаќин за CONNECT барањето на оваа имплементација. Разрешеното InetSocketAddress пак додава својата разрешена IP адреса на тоа барање. Таа разлика е важна кога проксито мора да го разреши името на услугата или да примени политика заснована на име на домаќин.

Што ви остава успешната врска

Добиените текови ги носат податоците на тунелираната услуга. Тие не откриваат посебен HTTP одговор што вашата апликација треба да го прочита и отфрли. Додавањето втора CONNECT размена би испратило HTTP текст до услугата откако JDK веќе го воспоставил тунелот.

Примерот поставува временско ограничување за поврзување и временско ограничување за читање од сокетот; тоа се одделни контроли, а не еден заеднички рок за апликациската сесија.

Дозволата за CONNECT сè уште и припаѓа на проксито. Крајната точка што проследува обични веб барања може да ја одбие портата на услугата или да побара автентикација пред да отвори тунел. Држете ги тие неуспеси одделно од сервер што го прифаќа тунелот но подоцна го одбива протоколот на вашата апликација.

Ако на тој протокол му треба TLS, преговарајте TLS низ поврзаниот сокет со предвиденото име на домаќин на услугата и вообичаените проверки на сертификатот. Самиот CONNECT не го шифрира текот. За вистински HTTP API, HTTP клиентот останува попогоден интерфејс бидејќи ги обработува и HTTP пораките.

Поврзани статии