ការផុតកំណត់ពេលតភ្ជាប់ TCP បានបំពេញតួនាទីរបស់វានៅពេលដែលអតិថិជនភ្ជាប់ទៅប្រូកស៊ី។ ការរង់ចាំបន្ទាប់—ការទទួលការឆ្លើយតប CONNECT ពេញលេញ—អាចត្រូវបានគ្រប់គ្រងដោយឧបករណ៍កំណត់ពេលផ្សេង។

ប្រូកស៊ីអាចនៅតែភ្ជាប់ទៅខាងលើ កំពុងផ្លាស់ប្តូរសារផ្ទៀងផ្ទាត់ ឬកំពុងរង់ចាំសេវាផ្សេង។ ការឆ្លើយតបធម្មតារបស់គេហទំព័រមិនទាន់ចាប់ផ្តើមនៅឡើយទេ។

ជំហានចុងក្រោយដែលបានបញ្ចប់តើនៅរង់ចាំអ្វី?
TCP ភ្ជាប់ទៅប្រូកស៊ីការចាប់ដៃរបស់ប្រូកស៊ី រួមទាំងការទទួលយក CONNECT
CONNECT ត្រូវបានទទួលយកTLS របស់គោលដៅ នៅពេលគោលដៅប្រើវា
សំណើទៅគោលដៅត្រូវបានផ្ញើការឆ្លើយតបរបស់គោលដៅ

រកឧបករណ៍កំណត់ពេលដែលសកម្មនៅពេលឧបករណ៍ភ្ជាប់កំពុងអាន និងសរសេរការចាប់ដៃនោះ។ លក្ខណសម្បត្តិឈ្មោះ “response timeout” អាចចាប់ផ្តើមមានប្រសិទ្ធភាពបានតែបន្ទាប់ពីបង្កើតផ្លូវបាន។ ជាមួយ HttpClient 5 សូមបែងចែករវាង ConnectionConfig និងការផុតកំណត់ពេលសុខរបស់វា ការកំណត់រចនាសម្ព័ន្ធចាប់ដៃ TLS និងការផុតកំណត់ពេលឆ្លើយតបកម្រិតសំណើ។ អនុវត្តការកំណត់រចនាសម្ព័ន្ធតភ្ជាប់ពាក់ព័ន្ធតាមរយៈអ្នកគ្រប់គ្រងដែលអតិថិជនពិតប្រាកដប្រើ។ ជំនាន់ Apache HttpClient ចាស់ៗប្រើ API ផ្សេងៗគ្នា ដូច្នេះកូដចាស់មិនមែនជាផែនទីដែលអាចទុកចិត្តបាននៃការទទួលខុសត្រូវទាំងនេះទេ។

រក្សាការបដិសេធ CONNECT ចុងក្រោយជាការឆ្លើយតបរបស់ប្រូកស៊ី។ ការឆ្លើយតបជោគជ័យដែលបន្ទាប់មក TLS ជាប់គាំង គឺជាដំណាក់កាលបរាជ័យមួយទៀត។ «TCP ភ្ជាប់ហើយ; គ្មានការឆ្លើយតប CONNECT ពេញលេញមុនកាលកំណត់រៀបចំ» ពិពណ៌នាបញ្ហាបានច្បាស់ជាងការផុតកំណត់ពេលប្រូកស៊ីទូទៅ។

កាលកំណត់សរុប អាចកំណត់ការរង់ចាំរបស់អ្នកហៅ ទន្ទឹមនឹងដែនកំណត់ដំណាក់កាលទាំងនេះ។ នៅពេលវាផុតកំណត់ សូមបោះបង់ ឬបិទប្រតិបត្តិការតាមរយៈវដ្តជីវិតដែលអតិថិជនគាំទ្រ មុនពេលការព្យាយាមផ្សេងទៀតប្រើប្រាស់សមត្ថភាពតភ្ជាប់។

អត្ថបទពាក់ព័ន្ធ