ប្រូកស៊ីខាងមុខមិនរក្សាព្រំដែននៃចម្រៀក TCP

បែងចែកការបែងចែក TCP ការអាន socket និងការដាក់ស៊ុម HTTP នៅពេលពិនិត្យចរាចរណ៍នៅសងខាងប្រូកស៊ីខាងមុខ។

ឧបមាថាការឆ្លើយតប HTTP បង្ហាញនៅក្នុងចម្រៀក TCP ជាច្រើនដែលបានចាប់យក បន្ទាប់ពីឆ្លងកាត់ Squid។ នេះអាចជាឥរិយាបថ TCP ធម្មតា មិនមែនជាសក្ខីភាពថាការឆ្លើយតបត្រូវបានបំបែកខុសទេ។

ប្រូកស៊ីខាងមុខជាធម្មតាមានការតភ្ជាប់ពីរ៖

client ⇄ TCP connection A ⇄ proxy ⇄ TCP connection B ⇄ origin

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

ព្រំដែនបីដែលគួររក្សាដោយឡែក

ព្រំដែនអ្វីកំណត់វា
ចម្រៀក TCPផ្លូវដឹកជញ្ជូន និងផ្លូវបណ្តាញ
លទ្ធផលនៃការអាន socketបៃស្ទ្រីមដែលមាន និងអង្គចងចាំរបស់អ្នកហៅ
សារ ឬស៊ុម HTTPច្បាប់ដាក់ស៊ុមរបស់ពិធីការ HTTP

ការអានមួយអាចមានផ្នែកនៃក្បាល ក្បាលពេញជាមួយបៃតួ ឬទិន្នន័យឆ្លងកាត់ព្រំដែនកម្រិតកម្មវិធីច្រើនជាងមួយ។ TCP មិនភ្ជាប់ «ចុងបញ្ចប់នៃការឆ្លើយតប HTTP» ទៅចុងបញ្ចប់នៃការអានជោគជ័យទេ។

ដូច្នេះឧបករណ៍ញែក HTTP/1.1 ប្រមូលក្បាល ហើយប្រើច្បាប់ដាក់ស៊ុមតួដែលអនុវត្ត រួមទាំងប្រវែង កូដបញ្ជូន ឬការបិទការតភ្ជាប់ដែលអនុញ្ញាត។ ស៊ុម HTTP/2 គឺជារចនាសម្ព័ន្ធពិធីការ ដែលខ្លួនវាអាចឆ្លងកាត់ចម្រៀក TCP; វាមិនមែនជាឈ្មោះផ្សេងសម្រាប់កញ្ចប់បណ្តាញទេ។

ផ្លូវរូង CONNECT ជោគជ័យរក្សាស្ទ្រីមបៃដែលឆ្លងកាត់ផ្លូវរូង ខណៈនៅតែប្រើជើង TCP ពីរ។ ព្រំដែនចម្រៀករបស់វាអាចខុសគ្នា ទោះបីជាប្រូកស៊ីមិនបានផ្លាស់ប្តូរបៃក្នុងផ្លូវរូងក៏ដោយ។

នៅពេលស៊ើបអង្កេតការខូចខាត សូមប្រៀបធៀបទិន្នន័យកម្មវិធីដែលបានផ្គុំឡើងវិញ។ ការប្រៀបធៀបចំនួនកញ្ចប់ ឬការរំពឹងប្រវែងកញ្ចប់ដូចគ្នានៅសងខាង គឺជាការសុំការធានាព្រំដែនពី TCP ដែលវាមិនផ្តល់ឱ្យ។

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