ការផ្សាយតាមរយៈប្រូកស៊ីខាងមុខ ធៀបនឹងការធ្វើប៊ូហ្វ័រចម្លើយពេញ

នៅពេលការទាញយកហាក់ដូចជារង់ចាំ សូមបែងចែកព្រឹត្តិការណ៍បី៖ ការមកដល់នៃក្បាលចម្លើយ ការមកដល់នៃបៃតួ និងសមត្ថភាពរបស់កម្មវិធីក្នុងការប្រើ ឬបង្ហាញលទ្ធផល។ សូចនាករផ្ទុកតែមួយមិនអាចកំណត់ថាតើមួយណាយឺតបានទេ។

ដំណាក់កាលផ្សាយធម្មតាអាចត្រួតគ្នា៖

origin produces a chunk → proxy forwards bytes → client consumes them

ប្រូកស៊ីអាចសរសេរមាតិកាដែលសមស្របទៅឃ្លាំងសម្ងាត់ ខណៈកំពុងបញ្ជូនបន្ត។ ការធ្វើឃ្លាំងសម្ងាត់មិនតម្រូវឱ្យរង់ចាំឯកសារទាំងមូលទេ។ read_ahead_gap របស់ Squid គ្រប់គ្រងការទាញយកដែលដើរនាំមុខការបញ្ជូន ដែលជាប្រភេទប៊ូហ្វ័រមួយទៀត។

សម្ពាធបញ្ច្រាសអាចបញ្ឈប់ការអានពីខាងលើជាបណ្តោះអាសន្ន នៅពេលអតិថិជនយឺតបំពេញជួរបញ្ចេញ។ Content-Length ក៏ផ្តល់ប្រវែងដោយមិនត្រូវការប៊ូហ្វ័រពេញដែរ។ ការសរសេរកូដ HTTP/1.1 chunked អនុញ្ញាតការបញ្ជូនជាដំណាក់ៗ ប៉ុន្តែមិនអាចសន្យាពេលវេលាឆ្លើយតបទាប ប្រសិនបើសមាសភាគមុនកាន់ទិន្នន័យ។

បន្ទាប់មក ពិនិត្យដំណាក់កាលដំណើរការ។ ការសរសេរឡើងវិញ ឬការត្រួតពិនិត្យអាចត្រូវការផ្នែកមួយ ឬតួទាំងមូល។ ការបង្ហាប់ និងការធ្វើស៊ុមកម្មវិធីអាចពន្យារលទ្ធផលមានប្រយោជន៍។ នៅខាងអតិថិជន វិធីសាស្ត្រដែលរង់ចាំអារេបៃពេញវិញនឹងត្រឡប់យឺតជាង ហើយកម្មវិធីរុករកអាចទទួលបៃមុនពេលបង្ហាញបាន។

បន្ទាប់ពី CONNECT ជោគជ័យ ប្រូកស៊ីធម្មតាបញ្ជូនលំហូរសេវាដោយមិនត្រូវការប្រវែងចុងក្រោយនៃឯកសារដែលបានផ្លូវរូង។ សូមតាមដានព្រឹត្តិការណ៍ដំបូងដែលបាត់ខាងលើ មុនពេលផ្លាស់ប្តូរការកំណត់ប៊ូហ្វ័រ ឬពេលវេលាកំណត់។ នៅពេល curl ជាអ្នកសង្កេត ជម្រើស no-buffer របស់វាផ្លាស់ប្តូរដំណាក់កាលបញ្ចេញក្នុងម៉ាស៊ីន។