אופטימיזציה של TCP לשיפור ביצועי הרשת

הרשת הגלובלית ב- Google Cloud מספקת אמינות גבוהה וזמן אחזור נמוך על ידי חיבור אפליקציות בין אזורים ואזורי זמינות בלי לצאת מהרשת של Google. עם זאת, הגדרות ברירת המחדל של Linux TCP/IP מותאמות לרוב לסביבות מקומיות, ויכולות לגרום לצווארי בקבוק בביצועים בענן.

כדי להשיג את הביצועים הכי טובים ב- Google Cloud, מומלץ להשתמש בהגדרות TCP/IP שמופיעות במסמך הזה, שעברו אופטימיזציה במיוחד לסביבת הענן.

ההגדרות שמוזכרות במסמך הזה נבדקו לשימוש בסביבתGoogle Cloud . ההגדרות האלה מיועדות בעיקר לתקשורת פנימית בין מופעים, ולא בהכרח לתקשורת בין מופעים של Compute Engine לבין כתובות חיצוניות.

הסבר על מגבלת התפוקה

פרוטוקול TCP משתמש במנגנון של 'חלונות' כדי לנהל את זרימת הנתונים בין השולח לבין המקבל. התפוקה המקסימלית שאפשר להשיג נקבעת לפי הקשר הבא:

Throughput <= window size / round-trip time (RTT) latency

בעיצוב המקורי של TCP, גודל החלון המקסימלי מוגבל ל-65,535 בייט (64KiB – 1), ולכן לעיתים קרובות רשתות מודרניות מהירות לא מנוצלות מספיק, כי השולח מחכה לעדכוני חלון.

סקריפט Shell לאופטימיזציה של ביצועי TCP

מומלץ להשתמש בהגדרות ה-TCP הבאות כדי לשפר את הביצועים:

• הקטנת MinRTO: כדי להתאושש מהר יותר מאובדן חבילות, צריך להקטין את העיכובים בהעברה מחדש.
• הפעלת תור הוגן: צמצום העומס והניתוקים בגלל פרצי תעבורה באפליקציות.
• השבתת התחלה איטית אחרי מצב בלי פעילות: הפעלה מחדש בקצב ההעברה האחרון הידוע כטוב אחרי תקופה של חוסר פעילות בחיבור.
• השבתה של TCP Cubic HyStart ACK train: התעלמות מאותות גודש חיוביים כוזבים כשמגבירים את קצב העברת הנתונים.
• הגדלת תקציבי הזיכרון של השקעים: הגדלת הכמות המקסימלית המותרת של נתונים בתהליך לכל חיבור.
• הפעלת GRO בחומרה: שיפור היעילות של עיבוד קבלת TCP/IP לזרימות גדולות על ידי שילוב נתונים בפחות מנות גדולות יותר.
• הגדלת ה-MTU ל-4,082 בייט: הגדלת יעילות ההעברה לזרימות גדולות של תפוקה.

אפשר להפעיל את ההגדרות המוצעות האלה באמצעות סקריפט מעטפת הבא. לפני שמריצים את הסקריפט, חשוב להחליף את eth0 בממשק הרשת הראשי של מופע המחשוב.

# Set DEV to your primary network interface
DEV=eth0

# 1. Reduce MinRTO
sysctl -w net.ipv4.tcp_rto_min_us=5000

# 2. Enable Fair Queueing
tc qdisc replace dev $DEV root fq

# 3. Disable slow start after idle
sysctl -w net.ipv4.tcp_slow_start_after_idle=0

# 4. Disable TCP Cubic HyStart ACK train
echo 2 > /sys/module/tcp_cubic/parameters/hystart_detect

# 5. Increase socket memory budgets
echo 4194304 > /proc/sys/net/core/rmem_max
echo 4194304 > /proc/sys/net/core/wmem_max
echo 4194304 > /proc/sys/net/ipv4/tcp_notsent_lowat
echo "4096 262144 16777216" > /proc/sys/net/ipv4/tcp_rmem
echo "4096 262144 33554432" > /proc/sys/net/ipv4/tcp_wmem

# 6. Enable hardware GRO
ethtool -K $DEV rx-gro-hw on

בקטעים הבאים מפורטות כל אחת מההגדרות המומלצות.

הפחתת MinRTO

הפחתת העיכובים בהעברה מחדש מאפשרת התאוששות מהירה יותר מאובדן חבילות נתונים.

הזמן הקצוב לתפוגה (RTO) של שידור חוזר של TCP קובע כמה זמן שולח TCP ממתין לאות ACK לפני שידור חוזר. מערכת Linux מאתחלת את ה-RTO לשנייה אחת (בהתאם לסעיף 2.1 ב-RFC 6298), ואז משנה אותו לאורך זמן בהתאם לזמן הלוך ושוב (RTT) בתוספת מרווח ביטחון.

ההגדרה 'זמן התאוששות מינימלי' (MinRTO) מטמיעה גבול תחתון להתאמה הזו. אם ההערכה של RTO נמוכה מדי, היא עלולה לגרום לשידור חוזר שגוי, שבו השולח משדר מחדש מנות בזמן שהתגובה עדיין בתהליך.

ערך ברירת המחדל של MinRTO הוא 200 ms, שהוא ערך שמרני מדי עבור רשתות ענן מודרניות. הערך 5 ms נבדק באופן נרחב ב-Google Cloud והוא ערך ברירת מחדל בטוח לחיבורים בין שרתי Linux מודרניים ב- Google Cloud.

גורם נוסף הוא אישורי קבלה (ACK) מושהים, שבהם העמית מעכב ACK תגובות. העיכוב הזה מאפשר לשלוח אישורי קבלה (ACK) בקבוצות על פני כמה מנות נתונים, או לשלב אישור קבלה עם מנת נתונים בכיוון ההפוך.ACK טיימרים של אישור (ACK) מושהה מבוססים על זמן הלוך ושוב (RTT), בדומה לטיימר של פסק זמן (RTO).

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

הגדרת MinRTO

אפשר להגדיר את MinRTO באחת משתי דרכים:

1. באמצעות sysctl (Linux 6.11 ואילך):

   אפשר להגדיר את ברירת המחדל של MinRTO באמצעות הפקודה sysctl:

   sysctl -w net.ipv4.tcp_rto_min_us=5000
   

2. שימוש ב-ip route (שליטה בכל מסלול, או גרסאות Linux מוקדמות יותר מ-6.11):

   לחלופין, בגרסאות ישנות יותר של Linux או כדי לשלוט בכל מסלול בנפרד, אפשר להגדיר את MinRTO לכל מסלול בנפרד:

   ip route change default rto_min 5ms
   

הגישה של הגדרת מסלול לכל חיבור עדיפה בסביבות שבהן יכול להיות שחיבורים יצאו Google Cloud או יתקשרו עם מחסניות TCP/IP שאינן Linux. יכול להיות שבמערכות האלה יש טיימרים שונים של אישור (ACK) מושהה. לפריסה רחבה באינטרנט הציבורי, מומלץ להשתמש בהגדרת ברירת המחדל השמרנית של minRTO ולהחיל את ההגדרה של 5 ms רק על מסלולים בתוך Google Cloud הענן הווירטואלי הפרטי (VPC).

הפעלת תור הוגן

לצמצם את העומס ואת אובדן המנות שנגרמים כתוצאה מפרצי פעילות של האפליקציה.

בניגוד לתורים רגילים מסוג FIFO (ראשון שנכנס, ראשון שיוצא), תורי FQ (Fair Queueing) מחלקים את רוחב הפס באופן הוגן בין זרימות שונות. היא גם מאפשרת להגביל את נפח התנועה על ידי חישוב קצב המסירה האופטימלי וזמן המסירה האופטימלי של כל מנה (packet) בכל חיבור TCP. אם FQ קיים, מחסנית ה-TCP מסתמכת על FQ כדי להשהות חבילות עד לזמן המסירה האופטימלי שלהן. הקצב הזה מפחית את פרצי התנועה בזרימה, וכך מצמצם את נפילת המנות ואת השידור החוזר שלהן.

כדי להגדיר את FQ traffic shaper ככלי לעיצוב תעבורה של מכשיר הרשת, משתמשים בפקודה הבאה של tc (traffic control):

tc qdisc replace dev $DEV root fq

במופעים גדולים עם רוחב פס גבוה של יציאה, יכול להיות שלמכשיר הרשת יש כמה תורים להעברה. במקרים כאלה, עדיף לפצל את ניהול התנועה בין תורי שידור על ידי התקנת הכלי Multi Queue (MQ) traffic shaper. זהו מרבב שמצרף מעצב תנועה עצמאי לכל תור שידור. הגדרת מגבילי תנועה לכל תור מפחיתה את התחרות על נעילות ועל שורות מטמון בין המעבדים.

השבתת ההתחלה האיטית אחרי מצב המתנה

שמירה על קצב העברה גבוה אחרי שהחיבור היה במצב לא פעיל.

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

כברירת מחדל, פרוטוקול TCP חוזר להגדרות השמרניות של 'התחלה איטית' אחרי תקופה של חוסר פעילות. תקופת חוסר פעילות יכולה להיות קצרה כמו פסק זמן אחד של שידור חוזר (RTO), כפי שמוגדר ב-RFC 2581. השבתה של התכונה הזו מאפשרת לחדש את החיבור באופן מיידי בקצב הידוע האחרון.

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

כדי להשבית את התכונה 'התחלה איטית אחרי חוסר פעילות', משתמשים בפקודה הבאה:

sysctl -w net.ipv4.tcp_slow_start_after_idle=0

השבתה של רצף אישורים של TCP Cubic HyStart

להגדיל במהירות את קצב ההעברה על ידי התעלמות מאותות שווא של עומס.

קצב הגידול האקספוננציאלי בשלב 'התחלה איטית' יכול להיות אגרסיבי, ויכול להיות שהוא יעבור את קצב היעד האופטימלי. התחלה היברידית (HyStart) היא מנגנון נוסף שנועד לצאת משלב ההתחלה האיטית מוקדם יותר באמצעות שני אותות מרכזיים של עומס:

• עיכוב של זמן הלוך ושוב (RTT): מדד לעיכוב ההתפשטות של חבילות נתונים ברשת. במהלך תקופות של עומס ברשת, תורי חבילות נתונים מצטברים בקישורים שיוצרים צוואר בקבוק. כתוצאה מכך, זמן ה-RTT עולה, וזה יכול להצביע על עומס.
• מרווח בין אישורי קבלה (ACK): מסתמך על אותות שלפיהם יש עיכוב בחבילות בצוואר בקבוק, אבל מתמקד באישור הקבלה של התגובה. המנגנון הזה מניח שאם אין עומס, אישורי ה-ACK יגיעו עם אותו מרווח כמו מנות הנתונים המקוריות. הדפוס הזה נקרא לעיתים קרובות ACK train (רכבת אישורי קבלה). אם אישורי ה-ACK מתעכבים מעבר לתבנית הצפויה הזו, יכול להיות שיש עומס ברשת.

כדי לבצע אופטימיזציה של הביצועים, משביתים את הזיהוי של רצף מנות ACK, אבל משאירים את מנגנון העיכוב של RTT מופעל.

echo 2 > /sys/module/tcp_cubic/parameters/hystart_detect

הגדלת תקציבי הזיכרון של שקע

כדי להגדיל את התפוקה המקסימלית בקישורים עם RTT גבוה, צריך לאפשר יותר נתונים בהעברה.

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

BDP (bits) = bandwidth (bits/second) * RTT (seconds)

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

ב-Linux, מגבלות הזיכרון של שקע TCP מוגדרות באמצעות ההגדרות הבאות: sysctl(8)

• net.core.rmem_max
• net.core.wmem_max
• net.ipv4.tcp_rmem
• net.ipv4.tcp_wmem

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

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

שני הפרמטרים הראשונים שניתנים להתאמה משפיעים על הגודל המקסימלי של חלון TCP לאפליקציות שמגדירות את הגודל של חלון TCP באופן ישיר. יש יחסית מעט אפליקציות כאלה. ההגבלות האלה מגדירות את מה שאפליקציה יכולה לבקש באופן מפורש באמצעות אפשרויות של שקע SO_RCVBUF ו-SO_SNDBUF.

בגרסאות ליבה של Linux‏ 6.18 ואילך, ערכי ברירת המחדל של net.core.rmem_max ושל net.core.wmem_max הם 4 MB. ההגדרות האלה נחשבות בטוחות על סמך ניסיון של שנים. בגרסאות קודמות של Linux, מומלץ להגדיל את המגבלות האלה ל-4 MB בפלטפורמות מודרניות:

echo 4194304 > /proc/sys/net/core/rmem_max
echo 4194304 > /proc/sys/net/core/wmem_max

הקבוצה השנייה של המגבלות, net.ipv4.tcp_rmem ו-net.ipv4.tcp_wmem, מנהלת את המגבלות של כוונון אוטומטי של מאגרים זמניים לשליחה ולקבלה של TCP.

לכל אחת מההגדרות האלה יש שלושה ערכים: גודל זיכרון המינימום, גודל זיכרון ברירת המחדל הראשוני וגודל זיכרון המקסימום של שקע. ערכי ברירת המחדל המקסימליים הם לרוב שמרניים יותר מהנדרש בפלטפורמות מודרניות, למשל:

• ‫tcp_rmem: 4096, 131072, 6291456
• ‫tcp_wmem: 4096, 16384, 4194304

מערך TCP משנה את הגודל של מאגרי הנתונים הזמניים של TCP לשליחה ולקבלה באופן אוטומטי, על סמך אומדנים של זמן הלוך ושוב (RTT) וחלון העומס. גודל מקסימלי של שטח אחסון זמני לכתיבה של 4, 194,304 או 4 MB הוא קטן לחיבורים עם RTT גבוה. עם RTT של 100 ms, ההגדרה הזו מגבילה את התפוקה ל-40 MB/s במקרה הטוב. במקום לנסות לחשב את הערכים שבהם צריך להשתמש, גישה פשוטה יותר היא להשתמש בערכי ברירת מחדל בטוחים לשרתים מודרניים עם הרבה זיכרון RAM.

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

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

echo 4194304 > /proc/sys/net/ipv4/tcp_notsent_lowat

echo "4096 262144 16777216" > /proc/sys/net/ipv4/tcp_rmem
echo "4096 262144 33554432" > /proc/sys/net/ipv4/tcp_wmem

הפעלת GRO בחומרה

שיפור היעילות של עיבוד קבלת TCP/IP לזרימות גדולות. צמצום התקורה של המעבד (CPU) באמצעות אצווה של חבילות שהתקבלו

ברוב הפעולות של TCP/IP, העלות של מחזור CPU עולה בהתאם לקצב החבילות, ולא לקצב הבייטים. כדי לצמצם את התקורה הזו בהעברה, מערכות הפעלה מודרניות שולחות נתוני TCP דרך נתיב ההעברה בחבילות גדולות שמכילות כמה פלחי TCP. הגודל שלהם יכול להגיע עד 64KB, או אפילו מאות קילובייט עם Linux BIG-TCP.

חבילות גדולות כאלה חורגות מגודל החבילה המקסימלי ברשת, ה-MTU. האופטימיזציה הזו של מערכת ההפעלה מסתמכת על תמיכה במכשיר הרשת כדי לפצל את החבילות האלה ולשלוח אותן כרצף של חבילות קטנות יותר, שכל אחת מהן מכילה פלח TCP אחד. התמיכה הזו, TCP Segmentation Offload ‏ (TSO), זמינה באופן נרחב ומופעלת כברירת מחדל.

כשמכשירים של GVNIC בפלטפורמות מהדור השלישי ומעלה מקבלים נתונים, הם יכולים לבצע את הפעולה ההפוכה: הם שומרים זמנית במאגר נתונים זמני פלחים כדי לבדוק אם מגיעים פלחים עוקבים. אם כן, הם משלבים אותם ומעבירים אותם כמנות מרובות פלחים למארח. התכונה הזו נקראת Receive Segment Coalescing (RSC)‎ ב-Windows, ‏ Large Receive Offload (LRO)‎ או Hardware Generic Receive Offload (HW-GRO)‎ ב-Linux. ‫HW-GRO הוא שיפור מחמיר יותר של LRO.

אפשר להפעיל את HW-GRO כברירת מחדל בבטחה. האפשרות הזו תהיה זמינה בסופו של דבר.

בינתיים, בפלטפורמות עם מכשירי GVNIC שתומכים בתכונה, צריך להפעיל את HW-GRO באמצעות ethtool. בהתאם לגרסת הליבה והדרייבר, התכונה מוצגת כ-LRO או כ-HW-GRO. ההטמעה זהה, בלי קשר לשם.

    ethtool -K $DEV large-receive-offload on
    ethtool -K $DEV rx-gro-hw on

הגדלת גודל ה-MTU ל-4,082 בייטים

שיפור היעילות של העברת נתונים ברצפי פעולות עם נפח נתונים גדול.

הגדלת גודל המנה, בדומה לאופטימיזציות של TSO ו-HW-GRO, משפרת את יעילות ההעברה כי רוב העיבוד מתבצע לכל מנה ולא לכל בייט.

Google Cloud רשתות VPC יכולות לתמוך במנות בגודל של עד 8,898 בייט, שהוא גדול משמעותית מה-MTU שמוגדר כברירת מחדל של 1,460 בייט. שימוש בגודל גדול יותר של מנות נתונים ברשת מפחית את מחזורי ה-CPU שמושקעים בכל בייט של תפוקה (goodput).

שיקולים לגבי גודל חבילה אופטימלי

בדרך כלל, עדיף להשתמש במנות גדולות יותר, אבל לא תמיד כדאי לבחור בערך ה-MTU המקסימלי האפשרי. היעילות שמושגת משליחת פחות מנות צריכה להיות מאוזנת עם העלויות הבאות:

• השימוש בזיכרון: מאגרי נתונים זמניים גדולים יותר דורשים יותר זיכרון שמוקצה למכשיר הרשת לקליטת חבילות נתונים. אם יש לכם הרבה תורים, יכול להיות שתישאר כמות גדולה של זיכרון ללא שימוש.
• טיפול בחבילות קטנות: מאגרי נתונים גדולים יותר מטפלים בחבילות קטנות, כמו אישורי קבלה (ACK) טהורים, בצורה פחות יעילה.
• עלויות הקצאת CPU: עלויות נתיב הנתונים מושפעות באופן משמעותי מהקצאה ומשחרור של זיכרון. התאמת גודל המנה למכפלה של דפי זיכרון עוזרת לבצע אופטימיזציה של עלות המעבד.
• אינטראקציה של TSO: גודל המנה משפיע באופן עדין על TCP Segmentation Offload ‏(TSO). כדי ליצור את חבילת ה-TSO הגדולה ביותר שאפשר, יכול להיות שתצטרכו לבחור בגודל מקסימלי קטן יותר של פלח (MSS). לדוגמה, אם חבילת ה-IP הגדולה ביותר האפשרית היא 64 KB כולל כותרות, ערך MSS של 4 KB יוביל למטען ייעודי גדול יותר (60 KB) מאשר ערך MSS של 8 KB (56 KB).

ברוב עומסי העבודה, ההבדל ביעילות בין יחידות MTU בגודל 4KB,‏ 8KB או 9KB הוא קטן. עם זאת, כל אחד מהערכים האלה מייצג שיפור משמעותי לעומת מנות ברירת המחדל של 1,460 בייט.

המלצה לגבי מנות בגודל דף

כאפשרות חזקה ויעילה בדרך כלל, אנחנו ממליצים להגדיר את גודל ה-MTU ברשת ה-VPC ל-4,082 בייט. מומלץ להשתמש בגודל הזה כי הוא מאפשר לכל חבילת הנתונים של Ethernet להיכנס לדף זיכרון בגודל 4,096 בייט, וכך מתבצעת אופטימיזציה של הקצאת דפי זיכרון. ההמלצה הזו מתייחסת ל-MTU בשכבה 3, שכולל את כותרת ה-IP, אבל לא כולל את שכבת הקישור של Ethernet בגודל 14 בייט.

הגדרת IP MTU

אפשר להגדיר את ה-MTU לכל רשת VPC ישירות דרך מסוף Google Cloud .

ברוב הפצות Linux ב- Google Cloud, לא נדרשת הגדרה ידנית במופע החישוב. המופע לומד באופן אוטומטי את ה-MTU של הרשת באמצעות DHCP במהלך האתחול (באמצעות אפשרות 26). לאחר מכן המופע מגדיר את ה-MTU של מכשיר הרשת כך שיתאים. מומלץ להשתמש בהגדרה האוטומטית הזו.

אם נדרשת הגדרה ידנית, אפשר להגדיר את ה-MTU של מכשיר הרשת לערך נמוך יותר מה-MTU של רשת ה-VPC באמצעות הפקודה הבאה:

ip link set dev $DEV mtu 4082

הגדרת גדלים שונים של MTU למסלולים ספציפיים

אם מופעלת תקשורת חיצונית של מופע מחשוב מחוץ ל-VPC, שבה ה-MTU של הנתיב עשוי להיות נמוך יותר, עדיף להגדיר MTU בנתיבים ספציפיים. במקרה כזה, צריך להגדיר את ה-MTU שמוגדר כברירת מחדל ל-1,460 בייט, שהוא ערך שמרני, ולהחיל את ה-MTU הגבוה יותר, למשל 4,082 בייט, רק על נתיבים בתוך ה-VPC:

#Set intra-VPC route MTU:
ip -4 route change $SUBNET/$MASK dev $DEV mtu 4082
#Set default route MTU:
ip -4 route change default dev $DEV mtu 1460

הגדרת הגודל המקסימלי של פלח TCP‏ (MSS)

הגודל המקסימלי של פלח TCP‏ (MSS) קובע את גודל המטען הייעודי (payload) של החבילה לחיבור TCP. מכיוון שגודל חבילות TCP/IP לא יכול לחרוג מגודל ה-MTU כדי למנוע פיצול או השמטה של חבילות, צריך לשנות את גודל ה-MSS בהתאם.

בדרך כלל, לא צריך להגדיר את TCP MSS באופן ידני, כי מערכת ההפעלה גוזרת אותו באופן אוטומטי מ-MTU של הנתיב.

ה-MSS מכסה את המטען הייעודי (payload) ואת אפשרויות ה-TCP, אבל לא כולל את כותרת ה-IPv4 בגודל 20 בייט ואת כותרת ה-TCP בגודל 20 בייט. לכן, ברשת IPv4, ‏ ה-MSS בדרך כלל קטן ב-40 בייט מה-MTU.

אם אתם מעדיפים MSS קטן יותר לתנועה ספציפית, אתם יכולים להגדיר אותו על בסיס כל נתיב. לדוגמה, אם רשת ה-VPC וה-MTU של המכשיר משתמשים במקסימום (8,896 בייט) לתנועה כללית, אבל אתם רוצים להשתמש ב-MTU של 4 KB לתנועת TCP, אתם יכולים להשתמש בפקודה הבאה:

ip -4 route change default dev $DEV advmss 4042

מצב פיצול הכותרת

מנהל ההתקן gVNIC gve בגרסאות ליבת Linux‏ 6.9 ואילך תומך בפיצול נתוני כותרת TCP ‏ (tcp-data-split), שמושבת כברירת מחדל.

פיצול הכותרת מפריד בין כותרות החבילות לבין הנתונים למאגרי נתונים נפרדים. הפעולה הזו מאפשרת למלא דף זיכרון שלם ב-4,096 בייט של נתונים. ההפרדה הזו מאפשרת לבצע אופטימיזציות חשובות, כמו החלפה של פעולות יקרות של העתקה ממרחב הליבה למרחב המשתמש בפעולות זולות יותר של מיפוי דפי זיכרון (לדוגמה, באמצעות Linux TCP_ZEROCOPY_RECEIVE).

כשמפעילים את התכונה של פיצול כותרת הקבלה, החישוב של MTU משתנה. ה-MTU האופטימלי הוא כזה שבו כל הכותרות ממופות למאגר הכותרות, ומאגר המטען הייעודי ממלא דף שלם של נתונים. אם האפשרות 'פיצול כותרת' מופעלת:

• מאגר כותרות מכיל:
  • אתרנט (14 בייט)
  • ‫IPv4 (20 בייטים)
  • כותרות TCP (20 בייט)
  • אפשרויות נפוצות של TCP (12 בייט להגדרת ברירת מחדל עם חותמות זמן של TCP )
• מאגר הנתונים הזמני מכיל 4096 בייטים של נתוני מטען ייעודי.

התוצאה היא גודל מסגרת כולל של 4,162 בייטים, ולכן MTU של 4,148 בייטים.

המאמרים הבאים

• כדאי לקרוא את הפוסט בבלוג בנושא 5 שלבים לשיפור הביצועים של Google Cloud הרשת.
• מידע נוסף על Global Networking Products
• מידע על מסלולי רשת ב- Google Cloud
• איך משווים את ביצועי הרשת