តើផតប្រូកស៊ីមួយអាចទទួល HTTP និង SOCKS យ៉ាងដូចម្តេច

អ្នកស្តាប់ប្រូកស៊ីចម្រុះអាចទទួល HTTP និង SOCKS នៅលើផត TCP តែមួយ ព្រោះម៉ាស៊ីនមេពិនិត្យបៃពិធីការដំបូង។ លេខផតមិនធ្វើការកំណត់អត្តសញ្ញាណនោះទេ។

សំណើប្រូកស៊ី HTTP ចាប់ផ្តើមដោយវិធីសាស្ត្រ HTTP ដូចជា GET ឬ CONNECT។ ការស្វាគមន៍ SOCKS ចាប់ផ្តើមដោយវាលពិធីការគោលពីរ។ កម្មវិធីដែលរចនាសម្រាប់ការបញ្ចូលទាំងនេះអាចបញ្ជូនការតភ្ជាប់ទៅអ្នកគ្រប់គ្រងសមស្រប។

នេះជាលក្ខណៈអនុវត្តច្បាស់លាស់។ អ្នកស្តាប់ HTTP ធម្មតារបស់ Squid មិនក្លាយជាចម្រុះដោយសារតែផតរបស់វាត្រូវបានប្តូរទៅ 1080 ទេ ហើយអ្នកស្តាប់ SOCKS តែមួយមិនរៀន HTTP ពីការកំណត់កម្មវិធីរុករកទេ។

TLS បន្ថែមព្រំដែនមួយទៀត៖ ការតភ្ជាប់ប្រូកស៊ីដែលបានអ៊ិនគ្រីបចាប់ផ្តើមដោយ TLS មិនមែនដោយវិធីសាស្ត្រ HTTP ដែលអាចមើលឃើញទេ។ ការគាំទ្រវានៅលើចំណុចចុងក្រោយដូចគ្នាត្រូវការការគ្រប់គ្រងដោយចេតនាបន្ថែម។ ការស្គាល់ HTTP អត្ថបទធម្មតា និង SOCKS មិនបញ្ជាក់សមត្ថភាពនោះទេ។

ប្រើពិធីការអតិថិជនដែលបានចងក្រងឯកសារសម្រាប់ចំណុចចុងក្រោយ។ ប្រសិនបើទាំងពីរដំណើរការ នោះជាភស្តុតាងអំពីអ្នកស្តាប់ចម្រុះរបស់ម៉ាស៊ីនមេនោះ មិនមែនជាហេតុផលដើម្បីទុកពិធីការមិនបានបញ្ជាក់នៅក្នុងអតិថិជនគ្រប់រូបទេ។

អ្នកស្តាប់ចម្រុះរបស់ Glider ផ្តល់ឧទាហរណ៍ជាក់លាក់៖ វាមើលបៃមួយដោយមិនប្រើប្រាស់វា បញ្ជូន 0x05 ទៅអ្នកគ្រប់គ្រង SOCKS5 របស់វា ហើយបើមិនដូច្នេះទេវាហៅកម្មវិធីញែក HTTP របស់វា។ កម្មវិធីញែកនោះនៅតែផ្ទៀងផ្ទាត់សំណើដែលចូលមក។ ជម្រើសបញ្ជូនមិនធ្វើឱ្យការបញ្ចូលតាមអំពើចិត្តក្លាយជា HTTP ត្រឹមត្រូវទេ។

ការចែករំលែកអ្នកស្តាប់ TCP មិនផ្តល់ការភ្ជាប់ UDP របស់ SOCKS5 ដោយខ្លួនឯងទេ។ Glider ចាប់ផ្តើមអ្នកស្តាប់ UDP របស់វាដោយឡែក។ ការជ្រើសរើសពិធីការ TCP និងការបញ្ជូនដាតាក្រាមនៅពេលក្រោយគឺជាសមត្ថភាពដោយឡែក។