الوسيط الأمامي لا يحافظ على حدود مقاطع TCP

لنفترض أن استجابة HTTP ظهرت في عدة مقاطع TCP ملتقطة بعد مرورها عبر Squid. قد يكون هذا سلوك TCP العادي، لا دليلاً على أن الاستجابة قُسّمت بشكل خاطئ.

عادةً ما يمتلك الوسيط الأمامي اتصالين:

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

لكل اتصال حالته الخاصة في TCP وأرقام تسلسله وتقسيمه إلى حزم. يستطيع الوسيط قراءة البيانات من اتصال وكتابتها إلى الآخر دون الحفاظ على أحجام المقاطع الأصلية. وقد ينتج التخزين المؤقت وتوقيت الإرسال والازدحام وحدود حجم المسار تجميعاً مختلفاً.

ثلاثة حدود يجدر فصلها

قد تحتوي قراءة واحدة على جزء من ترويسة، أو ترويسة كاملة مع بايتات الجسم، أو بيانات تعبر أكثر من حد تطبيقي واحد. ولا يربط TCP «نهاية استجابة HTTP» بنهاية قراءة ناجحة.

لذلك يراكم محلل HTTP/1.1 الترويسات ويطبق قواعد تأطير الجسم المناسبة، بما فيها الطول أو ترميز النقل أو إغلاق الاتصال المسموح. وإطار HTTP/2 بنية بروتوكولية يمكنها هي نفسها عبور مقاطع TCP؛ وليس اسماً آخر لحزمة شبكة.

يحافظ نفق CONNECT الناجح على تدفق البايتات الممرَّر داخل النفق مع استعماله ساقين من TCP. وقد تختلف حدود مقاطعه حتى حين لا يكون الوسيط قد غيّر البايتات داخل النفق.

قارن بيانات التطبيق بعد إعادة التجميع عند التحقيق في تلف ما. أما مقارنة أعداد الحزم أو توقع أطوال حزم متطابقة على الجانبين فتطلب من TCP ضمانة حدودية لا يقدمها.