Հատուկ TCP արձանագրությունը կարող է անցնել HTTP փրոքսիով, երբ այդ փրոքսին թույլատրում է CONNECT դեպի նպատակակետը։ Հավելվածի արձանագրությունը պարտավոր չէ դառնալ HTTP. HTTP-ն ստեղծում է թունելը, ապա հավելվածը փոխանակում է իր սեփական բայթերը դրա ներսում։

OpenJDK 25-ը տրամադրում է HTTP փրոքսիի ուղի Socket(Proxy)-ում։ Դրա իրականացումը կատարում է CONNECT փոխանակումը և վերադարձնում է միացված socket՝ հավելվածի օգտագործման համար։

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-ն արդեն ստեղծել է թունելը։

Օրինակը սահմանում է միացման ժամկետ և socket-ի ընթերցման ժամկետ. դրանք առանձին կառավարման միջոցներ են, ոչ թե հավելվածի սեսիայի մեկ ընդհանուր վերջնաժամկետ։

CONNECT-ի թույլտվությունը դեռ պատկանում է փրոքսին։ Սովորական վեբ հարցումներ փոխանցող վերջնակետը կարող է մերժել ծառայության պորտը կամ պահանջել նույնականացում՝ նախքան թունել բացելը։ Այդ ձախողումները առանձին պահեք այն սերվերից, որն ընդունում է թունելը, բայց հետագայում մերժում է ձեր հավելվածի արձանագրությունը։

Եթե այդ արձանագրությանը TLS է անհրաժեշտ, բանակցեք TLS-ը միացված socket-ի միջոցով՝ ծառայության նախատեսված հոսթի անվամբ և սովորական վկայագրերի ստուգումներով։ Միայն CONNECT-ը չի գաղտնագրում հոսքը։ Իրական HTTP API-ի համար HTTP հաճախորդը մնում է ավելի հարմար ինտերֆեյս, քանի որ այն նաև մշակում է HTTP հաղորդագրությունները։

Առնչվող հոդվածներ