ផ្លូវរូង Java Socket HTTP CONNECT ក្នុង OpenJDK 25

ពិធីការ TCP ផ្ទាល់ខ្លួនអាចធ្វើដំណើរតាម proxy HTTP បាន នៅពេល proxy នោះអនុញ្ញាត CONNECT ទៅគោលដៅ។ ពិធីការកម្មវិធីមិនចាំបាច់ក្លាយជា HTTP ទេ៖ HTTP បង្កើតផ្លូវរូង បន្ទាប់មកកម្មវិធីផ្លាស់ប្ដូរ byte របស់ខ្លួននៅខាងក្នុង។

OpenJDK 25 ផ្ដល់ផ្លូវតាម proxy 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();
}

ផ្នែកនេះប្រើ class ពី java.net និង java.io។ ជំនួសចំណុចបញ្ចប់ទាំងពីរ ហើយធ្វើការផ្លាស់ប្ដូរពិធីការមុនពេលចាកចេញពីប្លុក try។ សម្រាប់គោលដៅ TCP សាធារណៈដែលបានអនុញ្ញាត សូមជ្រើសបេក្ខជន HTTP ពី បញ្ជី proxy HTTP តែបន្ទាប់ពីពិនិត្យការអនុញ្ញាត CONNECT សម្រាប់ port របស់គោលដៅនោះ។ អាសយដ្ឋាន proxy គឺជាកន្លែងដែល Java ភ្ជាប់មុនគេ។ អាសយដ្ឋានដែលផ្ដល់ទៅ connect កំណត់សេវាដែល proxy ត្រូវទៅដល់។

គោលដៅដែលមិនបានដោះស្រាយរក្សាឈ្មោះ host របស់វាសម្រាប់សំណើ CONNECT របស់ការអនុវត្តនេះ។ ផ្ទុយទៅវិញ InetSocketAddress ដែលបានដោះស្រាយផ្ដល់អាសយដ្ឋាន IP ដែលបានដោះស្រាយរបស់វាទៅសំណើនោះ។ ភាពខុសគ្នានេះសំខាន់នៅពេល proxy ត្រូវដោះស្រាយឈ្មោះសេវា ឬអនុវត្តគោលនយោបាយដោយផ្អែកលើឈ្មោះ host។

អ្វីដែលការតភ្ជាប់ជោគជ័យបន្សល់ទុកឱ្យអ្នក

លំហូរដែលទទួលបានដឹកទិន្នន័យរបស់សេវាដែលបានធ្វើផ្លូវរូង។ ពួកវាមិនបង្ហាញការឆ្លើយតប HTTP ដាច់ដោយឡែកដែលកម្មវិធីរបស់អ្នកត្រូវអាន ហើយបោះចោលនោះទេ។ ការបន្ថែមការផ្លាស់ប្ដូរ CONNECT ទីពីរនឹងផ្ញើអត្ថបទ HTTP ទៅសេវា បន្ទាប់ពី JDK បានបង្កើតផ្លូវរូងរួចហើយ។

ឧទាហរណ៍កំណត់កំណត់ពេលភ្ជាប់ និងកំណត់ពេលអាន socket។ ទាំងនោះជាការគ្រប់គ្រងដាច់ដោយឡែក មិនមែនជាកំណត់ពេលរួមតែមួយសម្រាប់សម័យកម្មវិធីនោះទេ។

ការអនុញ្ញាត CONNECT នៅតែជារបស់ proxy។ ចំណុចបញ្ចប់ដែលបញ្ជូនសំណើវេបធម្មតាអាចបដិសេធ port របស់សេវា ឬទាមទារការផ្ទៀងផ្ទាត់មុនពេលបើកផ្លូវរូង។ រក្សាការបរាជ័យទាំងនោះឱ្យដាច់ពី server ដែលទទួលយកផ្លូវរូង ប៉ុន្តែក្រោយមកបដិសេធពិធីការកម្មវិធីរបស់អ្នក។

ប្រសិនបើពិធីការនោះត្រូវការ TLS សូមចរចា TLS តាម socket ដែលបានភ្ជាប់ ជាមួយឈ្មោះ host ដែលបានបម្រុងទុករបស់សេវា និងការត្រួតពិនិត្យវិញ្ញាបនបត្រធម្មតា។ CONNECT តែម្នាក់ឯងមិនបំពាក់កូដលំហូរទេ។ សម្រាប់ HTTP API ពិតប្រាកដ អតិថិជន HTTP នៅតែជាចំណុចប្រទាក់ដែលងាយស្រួលជាង ព្រោះវាក៏គ្រប់គ្រងសារ HTTP ដែរ។