پروکسی پیشرو مرزهای بخش TCP را حفظ نمی‌کند

فرض کنید پاسخ HTTP پس از عبور از Squid در چند بخش TCP ضبط‌شده دیده می‌شود. این می‌تواند رفتار معمول TCP باشد، نه شاهدی بر اینکه پاسخ نادرست تقسیم شده است.

پروکسی پیشرو معمولاً دو اتصال دارد:

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

هر اتصال وضعیت TCP، شماره‌های ترتیب و بسته‌بندی خود را دارد. پروکسی می‌تواند داده را از یک اتصال بخواند و در دیگری بنویسد، بدون حفظ اندازه‌های اصلی بخش‌ها. بافر کردن، زمان ارسال، ازدحام و محدودیت‌های اندازه مسیر می‌توانند گروه‌بندی دیگری پدید آورند.

سه مرزی که ارزش جدا نگه داشتن دارند

یک خواندن می‌تواند بخشی از سرآیند، تمام سرآیند همراه با بایت‌های بدنه، یا داده‌ای فراتر از یک مرز سطح برنامه را در بر گیرد. TCP «پایان پاسخ HTTP» را به پایان یک خواندن موفق نمی‌چسباند.

بنابراین تحلیلگر HTTP/1.1 سرآیندها را انباشته می‌کند و قواعد قالب‌بندی بدنه را به کار می‌برد، از جمله طول، کدگذاری انتقال یا بسته شدن مجاز اتصال. قالب HTTP/2 ساختاری پروتکلی است که خود می‌تواند از بخش‌های TCP بگذرد؛ نام دیگری برای بسته شبکه نیست.

یک تونل CONNECT موفق جریان بایتی تونل‌شده را حفظ می‌کند، اما همچنان از دو پای TCP استفاده می‌کند. مرزهای بخش‌های آن می‌تواند متفاوت باشد، حتی وقتی پروکسی بایت‌های درون تونل را تغییر نداده است.

هنگام بررسی خرابی، داده‌های برنامه را پس از بازمونتاژ مقایسه کنید. مقایسه شمار بسته‌ها یا انتظار طول‌های یکسان بسته در دو سو، از TCP تضمین مرزی می‌خواهد که آن را نمی‌دهد.