អ្នកគ្រប់គ្រង CONNECT របស់ Node.js ត្រូវរក្សា head buffer
គ្រប់គ្រង CONNECT socket និង head buffer របស់ Node នៅព្រំដែន HTTP ទៅ tunnel ដោយរក្សា byte ដែលបានអានរួចហើយហួសពី headers។
HTTP server របស់ Node គ្រប់គ្រងសំណើ proxy ធម្មតាតាមរយៈ request callback របស់វា។ CONNECT ដើរផ្លូវផ្សេង៖ server បញ្ចេញ connect ជាមួយសំណើ, client socket និង head buffer។
ព្រឹត្តិការណ៍នោះគឺការផ្ទេររវាងការញែក HTTP និង tunnel។ មិនមានវត្ថុ ServerResponse ធម្មតាដែលត្រូវបន្តប្រើសម្រាប់ចរាចរណ៍ tunnel នោះទេ។
| អាគុយម៉ង់ | អ្វីដែលវាផ្ទុក |
|---|---|
req | សំណើ CONNECT រួមទាំងអាជ្ញាធរគោលដៅ និង headers |
clientSocket | ការតភ្ជាប់ត្រឡប់ទៅ client |
head | ទិន្នន័យ tunnel ដែល Node បានអានរួចហើយហួសពី headers HTTP អាចទទេ |
បញ្ចប់ការសម្រេចចិត្ត HTTP មុនពេលបញ្ជូន byte
ផ្ទៀងផ្ទាត់ host និង port ដែលបានស្នើ, អនុវត្តគោលនយោបាយចូលប្រើ និងផ្ទៀងផ្ទាត់អត្តសញ្ញាណរបស់ proxy ហើយបង្កើតការតភ្ជាប់ឡើងលើ។ CONNECT កំណត់អាជ្ញាធរដូចជា service.example:443; វិភាគទម្រង់នោះដោយគិតដល់អាជ្ញាធរ IPv6 ជាជាងបំបែកដោយខ្វាក់ភ្នែកនៅរាល់សញ្ញាចុចពីរ។
នៅពេល tunnel ត្រូវបានទទួលយក, ផ្ញើការឆ្លើយតប HTTP ជោគជ័យ បន្ទាប់មកជួរទទេបញ្ចប់របស់វា។ បន្ទាប់មកបញ្ជូន byte head ណាមួយឡើងលើ មុនពេលបន្តជាមួយ byte បន្ទាប់ពី client socket។ ការភ្ជាប់អ្នកស្តាប់ទិន្នន័យថ្មីមិនអាចយក buffer ដែលបានផ្តល់ដោយឡែកទៅអ្នកគ្រប់គ្រងរួចហើយមកវិញបានទេ។
ឧទាហរណ៍ tunnel ផ្លូវការរបស់ Node អនុវត្តការផ្ទេរនោះដោយ serverSocket.write(head) មុនពេលភ្ជាប់ទិសដៅ stream ទាំងពីរ។ ឧទាហរណ៍តូចរបស់វាបង្ហាញការផ្លាស់ប្តូរ; proxy ដែលបានដាក់ពង្រាយក៏ត្រូវការការប៉ុនប៉ងតភ្ជាប់មានកំណត់, ការគ្រប់គ្រងការចូលប្រើ និងការគ្រប់គ្រងវដ្តជីវិត។
បន្ទាប់ពីជោគជ័យ byte ជាកម្មសិទ្ធិរបស់ពិធីការសេវាកម្ម
ការឆ្លើយតប CONNECT ជោគជ័យប្តូរការតភ្ជាប់ទៅជា byte stream។ ប្រសិនបើគោលដៅជាគេហទំព័រ HTTPS ការផ្លាស់ប្តូរ TLS របស់វាធ្វើដំណើរនៅក្នុង stream នោះ។ ការធ្វើ tunnel តែម្នាក់ឯងមិនតម្រូវឱ្យ proxy ចេញវិញ្ញាបនបត្រគេហទំព័រជំនួសទេ។
មុនពេលទទួល CONNECT កំហុស HTTP អាចពន្យល់ពីមូលហេតុដែលត្រូវបានបដិសេធ។ បន្ទាប់ពីទទួលយក, ការសរសេរ HTTP 500 ចូល stream នឹងចាក់ byte ចូលពិធីការ tunnel។ ជំនួសវិញ បញ្ចប់ ឬបំផ្លាញការតភ្ជាប់សមស្របនៅពេលបរាជ័យបន្ទាប់។
ភ្ជាប់ទិសដៅទាំងពីរជាមួយ ការគ្រប់គ្រង stream ដែលដឹងពី backpressure, ហើយសម្រេចថាតើព្រឹត្តិការណ៍ end, error និង close បញ្ចប់ដៃគូដោយរបៀបណា។ រក្សា head buffer ដំបូងជាផ្នែកនៃគំរូកម្មសិទ្ធិដូចគ្នា; វាជាទិន្នន័យកម្មវិធី មិនមែន headers HTTP លើសដែលត្រូវបោះចោលទេ។