HTTP CONNECT გვირაბები Java Socket-ით OpenJDK 25-ში

მორგებულ 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 შეტყობინებებსაც ამუშავებს.