מחקר וטיוטות

מחקר TCP

ארגומנט להגדלת חלון העומס הראשוני של TCP

זרמי TCP מתחילים בחלון עומס ראשוני של עד ארבעה קטעים או כ-4KB של נתונים. מאחר שרוב הטרנזקציות באינטרנט הן לטווח קצר, חלון העומס הראשוני הוא פרמטר TCP קריטי לקביעת המהירות שבה הזרימה יכולה להסתיים. מהירויות הגישה לרשת הגלובליות גדלו באופן דרמטי בממוצע בעשור האחרון, אבל הערך הסטנדרטי של חלון העומס הראשוני של TCP לא השתנה. במאמר הזה, אנחנו מציעים להגדיל את חלון העומס הראשוני של TCP לעשרה קטעים לפחות (כ-15KB). באמצעות ניסויים בקנה מידה גדול באינטרנט, אנחנו מודדים את היתרונות של זמן האחזור ואת העלויות של שימוש בחלון גדול יותר, כפונקציות של רוחב פס ברשת, זמן הלוך ושוב (RTT), מוצר לעיכוב רוחב פס (BDP) ואופי האפליקציות. מראים שזמן האחזור הממוצע של תגובות HTTP השתפר בכ-10%, והיתרונות הגדולים ביותר מוצגים ברשתות RTT ו-BDP גבוהות. גם זמן האחזור של רשתות עם רוחב פס נמוך השתפר באופן משמעותי בניסויים שלנו. קצב ההעברה החוזרת הממוצע עלה ב-0.5% מתון, כשרוב הגידול הגיע מאפליקציות שעוקפות ביעילות את אלגוריתם ההפעלה האיטית של TCP על ידי שימוש במספר חיבורים בו-זמניים. על סמך התוצאות מהניסויים שלנו, אנחנו סבורים שחלון העומס הראשוני צריך להיות לפחות עשרה קטעים, ואותו מידע ייחקר על ידי ה-IETF.

פתיחה מהירה של TCP

שירותי האינטרנט של היום נשלטים על ידי זרימות TCP כל כך קצרות עד שהן מסיימים כמה פעולות "הלוך ושוב" לאחר לחיצת היד. לחיצת היד הזו היא מקור משמעותי לזמן האחזור לזרימות כאלה. במאמר זה נתאר את התכנון, היישום והפריסה של פרוטוקול TCP Fast Open, מנגנון חדש שמאפשר חילופי נתונים במהלך לחיצת היד הראשונית של TCP. בתוך כך, 'פתיחה מהירה של TCP' מקצרת את זמן האחזור של רשת האפליקציות פעם אחת מלאה הלוך ושוב, ומפחיתה את העיכוב שחוו העברות TCP קצרות כאלה. אנחנו מטפלים בבעיות האבטחה שמהן מתאפשרת חילופי נתונים במהלך לחיצת היד התלת-כיוונית, שבה אנחנו מצמצמים את הבעיה באמצעות אסימון אבטחה שמאמת את הבעלות על כתובת ה-IP. אנחנו מפרטים מנגנוני הגנה אחרים מסוג 'חזרה לאחור' ופותרים את הבעיות שבהן נתקלנו ב-middleboxs, בתאימות לאחור לסטאקים קיימים של רשתות ובפריסה מצטברת. על סמך ניתוח תעבורת נתונים ואמולציית רשת, מראים שפתיחה מהירה של TCP מפחיתה את זמן האחזור של רשת טרנזקציית HTTP ב-15%ואת זמן הטעינה של כל הדף ב-10% בממוצע, ובמקרים מסוימים עד 40%

הפחתת הקצב של יצירת התקשורת ב-TCP

חבילות שאבדו מאריכות את זמן האחזור של משתמשי האינטרנט. שחזור מהיר הוא מנגנון מרכזי שמאפשר ל-TCP להתאוששות מאובדן חבילות. במאמר הזה אנחנו בוחנים כמה מנקודות החולשה של האלגוריתם הסטנדרטי שמתואר ב-RFC 3517 ואת האלגוריתמים הלא סטנדרטיים שמיושמים ב-Linux. גילינו שהאלגוריתמים האלה סותרים מההתנהגות שהתכוונתם אליהם בעולם האמיתי בשל ההשפעה המשולבת של זרימות קצרות, דוכנים של אפליקציות, אובדן של רצפים, אובדן וסידור מחדש (ACK) ומתח ACK. ב-Linux יש עומס יתר בחלונות, בעוד ש-RFC 3517 משדר רצפים גדולים באובדן גבוה, ושני המצבים האלה פוגעים בהמשך התהליך ומאריכים את זמן האחזור של האינטרנט. התרומה העיקרית שלנו היא תכנון חדש לבקרה בתהליכי ההתאוששות המהירה, שנקרא 'הפחתת קצב של היחסים' (PRR). PRR מתאושש מהפסדים במהירות, באופן חלק ומדויק על ידי העברת שידורים חוזרים ל-ACK שהתקבלו. בנוסף ל-PRR, אנחנו בודקים את האלגוריתם של ההעברה החוזרת המוקדמת (ER) של TCP שמפחית את סף האישור הכפול עבור העברות קצרות, ומראים שעיכוב שידורים חוזרים מוקדם למשך מרווח זמן קצר עוזר למנוע שידורים חוזרים מיותרים בנוכחות מעט סידור מחדש. הפרוטוקולים PRR ו-ER מפחיתים את זמן האחזור של TCP של חיבורים עם אובדן בשיעור של 3-10%, בהתאם לגודל התגובה. על סמך המכשור שלנו על שרתי האינטרנט של Google ו-YouTube בארה"ב ובהודו, אנחנו מציגים גם נתונים סטטיסטיים עיקריים על אופי השידורים מחדש של TCP.

למינר TCP

Laminar היא מסגרת חדשה לבקרה על עומסים ב-TCP, שמפרידה בין תזמון שידור, שקובע בדיוק מתי הנתונים יישלחו, לבין בקרת עומס טהור, שקובעת את כמות הנתונים הכוללת שנשלחים במהלך כל RTT. טכנולוגיית Laminar צפויה להפעיל אלגוריתמים מתקדמים חדשים, כדי לפקח באופן מדויק יותר על תעבורת הנתונים ב-TCP.

טיוטות SSL ו-TLS

Transport Layer Security (TLS) – False Start

False Start היא התנהגות אופציונלית של הטמעות TLS. היא משפיעה רק על תזמון הפרוטוקול, ולא על נתוני פרוטוקולים בחיבור אלחוטי, וניתן ליישם אותה באופן חד-צדדי. התכונה TLS False Start גורמת לקיצור זמן האחזור של טיסה הלוך ושוב בלחיצות יד מסוימות.

תוסף משא ומתן לגבי פרוטוקול הבא של Transport Layer Security (TLS)

תוסף Transport Layer Security (TLS) למשא ומתן של פרוטוקול שכבת האפליקציה. כך שכבת האפליקציה יכולה לנהל משא ומתן על הפרוטוקול שיש לבצע דרך החיבור המאובטח, באופן שימנע "הלוך ושוב" נוסף ובלתי תלוי בפרוטוקולים של שכבת האפליקציה.

טיוטת DNS

תת-רשת של לקוח בבקשות DNS

טיוטה זו מגדירה תוסף EDNS0 שיעביר מידע על הרשת שממנה הגיעה שאילתת DNS, ועל הרשת שעבורה ניתן לשמור תשובה במטמון.