พร็อกซีนอกทางไม่ได้รักษาขอบเขตของ TCP segment

สมมติว่าการตอบกลับ HTTP ปรากฏใน TCP segment หลายชิ้นที่ดักจับไว้หลังจากผ่าน Squid นั่นอาจเป็นพฤติกรรมปกติของ TCP ไม่ใช่หลักฐานว่าการตอบกลับถูกแบ่งผิด

พร็อกซีนอกทางมักมีการเชื่อมต่อสองเส้น:

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

แต่ละการเชื่อมต่อมีสถานะ TCP เลขลำดับ และการสร้างแพ็กเก็ตของตัวเอง พร็อกซีอ่านข้อมูลจากการเชื่อมต่อหนึ่งและเขียนไปยังอีกการเชื่อมต่อหนึ่งได้ โดยไม่รักษาขนาด segment เดิม การบัฟเฟอร์ จังหวะการส่ง ความคับคั่ง และขีดจำกัดขนาดของเส้นทางอาจทำให้เกิดการจัดกลุ่มอีกแบบ

สามขอบเขตที่ควรแยกออกจากกัน

การอ่านหนึ่งครั้งอาจมีส่วนหนึ่งของเฮดเดอร์ เฮดเดอร์ทั้งก้อนพร้อมไบต์ของบอดี้ หรือข้อมูลที่ข้ามขอบเขตระดับแอปพลิเคชันมากกว่าหนึ่งขอบ TCP ไม่ได้ผูก «จุดสิ้นสุดของการตอบกลับ HTTP» ไว้กับจุดสิ้นสุดของการอ่านที่สำเร็จ

ดังนั้นตัวแยกวิเคราะห์ HTTP/1.1 จึงสะสมเฮดเดอร์และใช้กฎการใส่เฟรมบอดี้ที่เกี่ยวข้อง รวมถึงความยาว การเข้ารหัสการส่ง หรือการปิดการเชื่อมต่อที่อนุญาต เฟรม HTTP/2 เป็นโครงสร้างของโปรโตคอลที่สามารถข้าม TCP segment ได้เอง ไม่ใช่ชื่ออื่นของแพ็กเก็ตเครือข่าย

อุโมงค์ CONNECT ที่สำเร็จรักษากระแสไบต์ในอุโมงค์ไว้ แต่ยังใช้ขา TCP สองขา ขอบเขต segment ของมันอาจแตกต่างกันแม้พร็อกซีไม่ได้เปลี่ยนไบต์ภายในอุโมงค์

เมื่อตรวจสอบความเสียหาย ให้เปรียบเทียบข้อมูลแอปพลิเคชันที่ประกอบกลับแล้ว การเปรียบเทียบจำนวนแพ็กเก็ตหรือการคาดหวังความยาวแพ็กเก็ตเท่ากันทั้งสองด้านคือการขอการรับประกันขอบเขตจาก TCP ที่มันไม่ได้ให้