פרוקסי קדמי אינו משמר גבולות של מקטעי TCP
הפרידו בין פילוח TCP, קריאות סוקט ותיחום HTTP כאשר בודקים תעבורה משני צדי פרוקסי קדמי.
נניח שתגובת HTTP מופיעה בכמה מקטעי TCP שנלכדו לאחר מעבר דרך Squid. זה יכול להיות התנהגות TCP רגילה, ולא הוכחה שהתגובה פוצלה באופן שגוי.
לפרוקסי קדמי יש בדרך כלל שני חיבורים:
client ⇄ TCP connection A ⇄ proxy ⇄ TCP connection B ⇄ origin
לכל חיבור מצב TCP משלו, מספרי רצף משלו ופילוח משלו. הפרוקסי יכול לקרוא נתונים מחיבור אחד ולכתוב אותם לאחר, בלי לשמר את גדלי המקטעים המקוריים. אגירה, עיתוי שליחה, עומס וגדלי נתיב יכולים ליצור קיבוץ אחר.
שלושה גבולות שכדאי להפריד
| גבול | מה קובע אותו |
|---|---|
| מקטע TCP | מסלול התעבורה והרשת |
| תוצאה של קריאת סוקט | בייטי הזרם הזמינים והמאגר של הקורא |
| הודעת HTTP או פריים | כללי התיחום של פרוטוקול HTTP |
קריאה אחת יכולה להכיל חלק מכותרת, כותרת שלמה עם בייטי גוף, או נתונים שחוצים יותר מגבול אחד ברמת היישום. TCP אינו מצמיד „סוף תגובת HTTP” לסוף קריאה מוצלחת.
לכן מנתח HTTP/1.1 צובר כותרות ומיישם את כללי תיחום הגוף הרלוונטיים, ובהם אורך, קידוד העברה או סגירת חיבור מורשית. פריים HTTP/2 הוא מבנה פרוטוקול שיכול בעצמו לחצות מקטעי TCP; הוא אינו שם אחר לחבילת רשת.
מנהרת CONNECT מוצלחת משמרת את זרם הבייטים המנהרתי ועדיין משתמשת בשתי רגלי TCP. גבולות המקטעים שלה יכולים להיות שונים גם כאשר הפרוקסי לא שינה את הבייטים בתוך המנהרה.
בבדיקת שחיתות, השוו את נתוני היישום לאחר הרכבה מחדש. השוואת מספרי חבילות או ציפייה לאורכי חבילה זהים משני הצדדים דורשת מ־TCP הבטחת גבולות שהוא אינו מספק.