האם שני פרוקסים יכולים להוריד קובץ אחד מהר יותר?
הפרדה בין פיזור חיבורים רבים לבין איחוד כמה נתיבי רשת להורדה אחת.
שני מוצאים דרך פרוקסי, שלכל אחד מהם רוחב פס פנוי, נראים דרך קלה להכפיל את מהירות ההורדה. אבל מאגר פרוקסים רגיל אינו פועל כך.
לקוח פותח חיבור דרך פרוקסי אחד נבחר. אותו פרוקסי פותח את החיבור הבא. הוספת כתובת נוספת מרשימת פרוקסים למאגר נותנת לחיבורים עתידיים אפשרות נוספת; היא אינה משחילה את הפרוקסי השני לזרם הבתים שכבר נמצא בעיצומו.
גם לאיזון רגיל בין כמה רשתות WAN המבוסס על חיבורים יש מגבלה דומה. הוא יכול לפזר חיבורים שונים בין קישורים, ובכך לשפר את הקיבולת הכוללת או להפחית תחרות. חיבור אחד נשאר חיבור אחד, אלא אם מנגנון אחר מספק כמה נתיבים במפורש.
כשהורדות מקבילות הן עניין אחר
לקוח יכול לבקש טווחים שונים של קובץ דרך חיבורים נפרדים ולהרכיב אותם מקומית. זה יכול להשתמש ביותר מנתיב אחד אם הלקוח תומך בסידור והשרת מתיר את הבקשות.
זה מוסיף דרישות: הטווחים חייבים לתאר את אותה הצגה, תשובות השרת חייבות להתאים להיסטים שהתבקשו, ושינויים באובייקט אינם רשאים ליצור קובץ מעורבב. אימות, מגבלות שרת ומדיניות לכל מוצא יכולים גם הם להפוך בקשות טווח מקבילות לבלתי מתאימות. עשר הורדות שלמות אינן עשרה חלקים של הורדה אחת.
הנתיב האחרון אל הלקוח עדיין חשוב. כמה מוצאים מהירים אינם יכולים לשלוח דרך קישור גישה רווי אחד יותר נתונים ממה שהקישור הזה יכול לשאת.
ריבוי נתיבים צריך תמיכה אמיתית
Multipath TCP הוא מנגנון תעבורה מפורש שיכול לשאת חיבור באמצעות כמה תת-זרמים כאשר נקודות הקצה וסידור הרשת תומכים בכך. הוא אינו מופעל רק על ידי רישום שני פרוקסים לא קשורים של HTTP או SOCKS.
בהעברה איטית, קבעו תחילה אם התקרה נמצאת בקישור הלקוח, בפרוקסי, בנתיב הבא או ביעד. מאגר שימושי לפיזור חיבורים. התייחסו לטענה על הכפלת מהירות של קובץ אחד כאל תכונה נפרדת שזקוקה למנגנון ולהוכחות משלה.