socket .NET ត្រូវការការចាប់ដៃ SOCKS

ការចង្អុល Socket.Connect() ទៅកាន់ម៉ាស៊ីនមេ SOCKS បើកការតភ្ជាប់ TCP ទៅកាន់ម៉ាស៊ីនមេនោះ។ bytes បន្ទាប់នៅតែត្រូវនិយាយ SOCKS។ ការផ្ញើ protocol របស់កម្មវិធីភ្លាមៗ ធ្វើឱ្យម៉ាស៊ីនមេរង់ចាំការសន្ទនាមួយផ្សេងទៀត។

ជាមួយ SOCKS5 ការបង្កើតការតភ្ជាប់រួមមានការចរចាវិធីសាស្ត្រ ការផ្លាស់ប្តូរការផ្ទៀងផ្ទាត់ដែលបានជ្រើសរើស និងសំណើដែលដាក់ឈ្មោះគោលដៅ។ មានតែការឆ្លើយតបដែលជោគជ័យទេ ទើបបើកផ្លូវសម្រាប់ bytes របស់កម្មវិធី។ ដំណាក់កាលទាំងនេះត្រូវបានកំណត់ក្នុង RFC 1928។

រក្សាការចរចានៅក្នុងស្រទាប់តភ្ជាប់

កម្មវិធីដែលមាន protocol TCP ផ្ទាល់ខ្លួនអាចប្រើ connector ដែលដឹងអំពី proxy ហើយត្រឡប់ stream ដែលបានបង្កើតរួច។ បន្ទាប់មកផ្នែកដែលនៅសល់របស់កម្មវិធីអាន និងសរសេរតាម stream នោះ។ connector ត្រូវគិតដល់ការអានមិនពេញលេញ អាសយដ្ឋានប្រវែងអថេរ ការបរាជ័យផ្ទៀងផ្ទាត់ និងកាលកំណត់សម្រាប់ការចរចា។

ការអនុវត្តដែលសរសេរដោយដៃ ដែលអាន buffer ទំហំថេរមួយ ហើយសន្មតជោគជ័យ គឺផុយស្រួយ។ TCP មិនរក្សាព្រំដែននៃសារ SOCKS។ អានការឆ្លើយតបពេញលេញដែលបានពិពណ៌នាដោយប្រភេទអាសយដ្ឋានរបស់វា មុនពេលចាប់ផ្តើម protocol របស់កម្មវិធី។ ឧបករណ៍អានការឆ្លើយតប CONNECT សម្រាប់ .NET 7+ បង្ហាញដំណាក់កាលនោះ។

ប្រសិនបើបណ្ណាល័យដែលថែទាំរួចផ្តល់ស្រទាប់តភ្ជាប់នេះហើយ សូមពិនិត្យកំណែ SOCKS ដែលគាំទ្រ វិធីសាស្ត្រផ្ទៀងផ្ទាត់ និង target framework របស់វា។ តំណវេទិកាដប់ឆ្នាំគឺជាចំណុចចាប់ផ្តើមសម្រាប់ការស៊ើបអង្កេត មិនមែនជាភស្តុតាងនៃភាពឆបគ្នាបច្ចុប្បន្នទេ។

ការកំណត់រចនាសម្ព័ន្ធ client HTTP មានវិសាលភាពដោយឡែក

ការកំណត់ proxy របស់ client HTTP កំណត់ client HTTP នោះ។ វាមិនកែប្រែរាល់ socket ដើមនៅក្នុងដំណើរការទេ។ API Socket ទទួលយកចំណុចបញ្ចប់បណ្តាញ ហើយទុកការចរចាកម្រិតខ្ពស់សម្រាប់អ្នកហៅ។

សម្រាប់ protocol កម្មវិធីដែលបានអ៊ិនគ្រីប សូមធ្វើការចាប់ដៃ TLS របស់វា បន្ទាប់ពីរូង proxy ត្រូវបានបង្កើត។ ផ្ទៀងផ្ទាត់អត្តសញ្ញាណគោលដៅដែលបានបម្រុងនៅដំណាក់កាលនោះ។ ការផ្ទៀងផ្ទាត់ proxy និងការផ្ទៀងផ្ទាត់គោលដៅនៅតែដាច់ដោយឡែក ទោះបីពួកវាប្រើ stream មូលដ្ឋានដូចគ្នាក៏ដោយ។