ការផុតកំណត់ពេល CONNECT របស់ប្រូកស៊ី បន្ទាប់ពីការតភ្ជាប់ TCP ជោគជ័យ
ស្វែងរកការផុតកំណត់ពេលដែលសកម្មអំឡុងពេល CONNECT ជំនួសឱ្យការសន្មតថាការតភ្ជាប់ TCP ដែលបានបញ្ចប់ក៏បានបញ្ចប់ការរៀបចំផ្លូវរូងក្រោមដីដែរ។
ការផុតកំណត់ពេលតភ្ជាប់ TCP បានបំពេញតួនាទីរបស់វានៅពេលដែលអតិថិជនភ្ជាប់ទៅប្រូកស៊ី។ ការរង់ចាំបន្ទាប់—ការទទួលការឆ្លើយតប CONNECT ពេញលេញ—អាចត្រូវបានគ្រប់គ្រងដោយឧបករណ៍កំណត់ពេលផ្សេង។
ប្រូកស៊ីអាចនៅតែភ្ជាប់ទៅខាងលើ កំពុងផ្លាស់ប្តូរសារផ្ទៀងផ្ទាត់ ឬកំពុងរង់ចាំសេវាផ្សេង។ ការឆ្លើយតបធម្មតារបស់គេហទំព័រមិនទាន់ចាប់ផ្តើមនៅឡើយទេ។
| ជំហានចុងក្រោយដែលបានបញ្ចប់ | តើនៅរង់ចាំអ្វី? |
|---|---|
| TCP ភ្ជាប់ទៅប្រូកស៊ី | ការចាប់ដៃរបស់ប្រូកស៊ី រួមទាំងការទទួលយក CONNECT |
| CONNECT ត្រូវបានទទួលយក | TLS របស់គោលដៅ នៅពេលគោលដៅប្រើវា |
| សំណើទៅគោលដៅត្រូវបានផ្ញើ | ការឆ្លើយតបរបស់គោលដៅ |
រកឧបករណ៍កំណត់ពេលដែលសកម្មនៅពេលឧបករណ៍ភ្ជាប់កំពុងអាន និងសរសេរការចាប់ដៃនោះ។ លក្ខណសម្បត្តិឈ្មោះ “response timeout” អាចចាប់ផ្តើមមានប្រសិទ្ធភាពបានតែបន្ទាប់ពីបង្កើតផ្លូវបាន។ ជាមួយ HttpClient 5 សូមបែងចែករវាង ConnectionConfig និងការផុតកំណត់ពេលសុខរបស់វា ការកំណត់រចនាសម្ព័ន្ធចាប់ដៃ TLS និងការផុតកំណត់ពេលឆ្លើយតបកម្រិតសំណើ។ អនុវត្តការកំណត់រចនាសម្ព័ន្ធតភ្ជាប់ពាក់ព័ន្ធតាមរយៈអ្នកគ្រប់គ្រងដែលអតិថិជនពិតប្រាកដប្រើ។ ជំនាន់ Apache HttpClient ចាស់ៗប្រើ API ផ្សេងៗគ្នា ដូច្នេះកូដចាស់មិនមែនជាផែនទីដែលអាចទុកចិត្តបាននៃការទទួលខុសត្រូវទាំងនេះទេ។
រក្សាការបដិសេធ CONNECT ចុងក្រោយជាការឆ្លើយតបរបស់ប្រូកស៊ី។ ការឆ្លើយតបជោគជ័យដែលបន្ទាប់មក TLS ជាប់គាំង គឺជាដំណាក់កាលបរាជ័យមួយទៀត។ «TCP ភ្ជាប់ហើយ; គ្មានការឆ្លើយតប CONNECT ពេញលេញមុនកាលកំណត់រៀបចំ» ពិពណ៌នាបញ្ហាបានច្បាស់ជាងការផុតកំណត់ពេលប្រូកស៊ីទូទៅ។
កាលកំណត់សរុប អាចកំណត់ការរង់ចាំរបស់អ្នកហៅ ទន្ទឹមនឹងដែនកំណត់ដំណាក់កាលទាំងនេះ។ នៅពេលវាផុតកំណត់ សូមបោះបង់ ឬបិទប្រតិបត្តិការតាមរយៈវដ្តជីវិតដែលអតិថិជនគាំទ្រ មុនពេលការព្យាយាមផ្សេងទៀតប្រើប្រាស់សមត្ថភាពតភ្ជាប់។