אופטימיזציה של TCP/IP כדי להפחית השהייה במשחקים

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

אופטימיזציה של TCP/IP עבור להפחית את השהייה זה לא רק עניין של כוונון של כמה הגדרות "קסומות". צריך להבין איך מושגים כמו... עובדים. MTU, MSS, חלון TCP, השהייה או נפיחות בנפחולאחר מכן יש להחיל שינויים ספציפיים במחשב, בנתב, ברשת ה-Wi-Fi ואפילו בשרתי ענן או במכונות וירטואליות. בואו נסתכל על זה שלב אחר שלב, אבל עם חשיבה מעשית: מהו כל דבר ומה אתם יכולים לעשות כדי לגרום לחיבור שלכם להגיב מהר יותר.

מושגי מפתח ב-TCP/IP המשפיעים על השהייה

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

MTU, פרגמנטציה ו-LSO

La MTU (יחידת שידור מקסימלית) זהו הגודל המקסימלי, בבתים, של חבילה שיכולה לעזוב ממשק רשת מבלי להתפרק. ברוב המכריע של רשתות Ethernet (ובמכונות וירטואליות ב-Azure או Google Cloud), ערך ברירת המחדל הוא 1500 בתים, הכולל כותרות רשת ונתונים.

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

בנוסף, יש את החלק המפורסם "אל תפרק" (DF) בכותרת ה-IP. אם מופעל, ונתב ביניים מקבל חבילה גדולה יותר מ-MTU שלו, במקום לפרק אותה, הוא משליך אותה ושולח בחזרה הודעת ICMP "דרושה פיצול". זה משמש ב- זיהוי מסלול MTU (PMTUD)אבל אם חומת אש חוסמת את חבילות ה-ICMP הללו, השולח ימשיך לנסות לשלוח חבילות גדולות מדי, מה שיגרום לעיכובים ושידורים חוזרים.

בסביבות כמו Azure או Google Cloud, חבילות מקוטעות נוטות גם לאבד את היתרונות של רשתות מואצותSR-IOV ו-SmartNICs. הם מעובדים דרך המסלול האיטי של ההיפר-ויזור, עם יותר ריצודהשהייה נמוכה יותר ופחות חבילות לשנייה. לכן, ההמלצה הכללית היא הימנעו מפיצול על ידי כוונון נכון של MTU ו-MSS ולא לנפח את ה-MTU יותר מדי אם יש חומות אש או VPN בין לבין.

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

MSS, PMTUD ו-VPN

El גודל מקטע מרבי של TCP MSS זה מגדיר כמה בתים של נתונים שמישים נכנסים בכל מקטע TCP, לא כולל כותרות IP ו-TCP. בדרך כלל, מערכות מחשבות את ה-MSS כך:

MSS = MTU - (tamaño cabecera IP + tamaño cabecera TCP)

עם MTU של 1500 וכותרות IPv4+TCP של 20+20 בתים, ה-MSS הטיפוסי הוא הבתים 1460ערך זה נקבע במהלך לחיצת יד תלת-כיוונית של TCP, וכל קצה מציע ערך משלו. החיבור משתמש בנמוך מבין השניים.

עם זאת, ייתכנו מכשירים בדרך (חומות אש, נתבים, שערי VPNוכו') עם MTU קטן יותר שכופה למעשה הפחתה ב-MSS. כאן ה גילוי MTU של נתיב (PMTUD)כאשר נתב אינו יכול להעביר חבילה מכיוון שהיא גדולה מדי ומוגדרת לה סיבית DF, הוא משמיט אותה ושולח הודעת ICMP "Fragmentation Needed" המציינת את ה-MTU המרבי שהוא תומך בו, כך שהמקור מקטין את גודלה.

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

ברשתות החברתיות עם VPN של IPsec או מנהרות אחרות, הכותרות הנוספות מפחיתות את השטח הזמין לנתונים, לכן מומלצים MTU ו-MSS קטנים יותר (למשל, MTU 1400 ו-MSS ~1350 במנהרות אופייניות) כדי למנוע פיצול מנהרות ועיכובים נלווים.

חלון השהייה, RTT ו-TCP

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

ב-TCP, התפוקה התיאורטית המרבית של חיבור יחיד נקבעת על ידי נוסחה בסיסית זו:

rendimiento máximo ≈ tamaño de ventana TCP / RTT

La חלון TCP זוהי כמות הנתונים שיכולה להיות לשולח "בתוך תעופה" מבלי שקיבל עדיין אישור (ACK). עם חלון של 65.535 בתים ו-MSS של 1460, ניתן לשלוח רק כ-45 חבילות לפני המתנה ל-ACK. אם ה-RTT גבוה (לדוגמה, 80-160 מילישניות בין יבשות), החלון הלא-מדרגי רחוק מלהפיק תועלת מקישורים בעלי קיבולת גבוהה.

כברירת מחדל, שדה החלון בכותרת ה-TCP הוא באורך 16 סיביות, מה שמגביל את ערכו המרבי ל-65.535 בתים. עבור רשתות מודרניות, זה מגוחך, אז לפני שנים הוצג [מידע חסר - כנראה תכונה או שיטה ספציפית]. קנה מידה של חלון TCP, אשר מחיל מקדם כפל 2^na על ערך זה ומאפשר חלונות של מאות מגה-בייט או אפילו ג'יגה-בייט.

במערכות כמו Windows או Linux, שינוי גודל החלונות מנוהל באופן אוטומטי באמצעות הגדרות מוגדרות מראש (כוונון אוטומטי), וניתן לצפות בו או לשנות אותו באמצעות פקודות כגון Get-NetTCPSetting o sysctlרמות אגרסיביות יותר (למשל, "ניסיוניות") מאפשרות חלונות ענק ויכולות לשפר מאוד את הביצועים ברשתות למרחקים ארוכים, בתנאי שאין אובדן חבילות גדול מדי.

רשתות מואצות, RSS ו-GRO/TSO

בפלטפורמות ענן (Azure, Google Cloud וכו'), ממשקי רשת מסורתיים מסתמכים במידה רבה על המעבד המארח כדי לעבד כל חבילה, להחיל כללים, לכלול ולפרק אותה. התוצאה היא... עומס אכזרי על ההיפר-ויזור כאשר יש הרבה תעבורה וזה יוצר השהייה לא יציבה.

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

זה מספק מספר יתרון:

• פחות השהייה, יותר PPS.
• פחות ריצוד
• צריכת CPU נמוכה יותר במארח ובמכונה הווירטואלית.

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

בצד של מערכת ההפעלה האורחת, חשוב להפעיל טכנולוגיות כגון . קנה מידה בצד הקבלה (RSS)אשר מפיצה את עיבוד החבילות הנכנסות על פני ליבות מעבד מרובות, והורדות פילוח וצבירה כגון TSO (קיזוז פילוח שידור) ו-GRO/LRO (קיזוז קליטה כללי)מה שמפחית את מספר החבילות שהמעבד צריך לטפל בהן ישירות.

TIME_WAIT ושימוש חוזר בשקע

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

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

טכניקה אגרסיבית יותר, הנתמכת על ידי כמה ליבות (לדוגמה, Windows Server ב-Azure), נקראת התנקשות ב-TIME_WAITאם מגיע SYN חדש עם מספר סידורי גבוה משמעותית מזה של החיבור הישן, המערכת יכולה לאלץ את ה-socket להיסגר במהלך TIME_WAIT ולקבל את החיבור החדש באופן מיידי. זה מגביר את יכולת ההרחבה, אך אם הוא מוגדר בצורה שגויה, זה יכול לגרום... בעיות פעולה הדדית עם ערימות TCP שמרניות יותר.

למה פינג כל כך חשוב בחיי היומיום שלך

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

משחקים מקוונים ורמות פינג "ניתנות למשחק"

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

מ ה 100-300 ms מתחילות בעיות רציניות: יריות שמגיעות באיחור, תנועות שרואות בעיכוב, מכוניות ש"קופצות" במשחק מרוצים וכו'. מעל 300 מילישניות, המשחק הופך לעינוי גדול יותר מכל דבר אחר, במיוחד במשחקי יריות, משחקי מרוצים או משחקי ספורט.

גם לסוג המשחק יש השפעה גדולה. משחקי FPS ומרוצים כמעט חובה להיות פחות מ-50 מילישניות כדי להתחרות; במשחקי ספורט מקוונים, רצוי גם להישאר מתחת ל-30-40 מילישניות. עם זאת, ב משחקי MMO או משחקי אסטרטגיה מבוססי תורותאפשר "לשרוד" עם פינגים של 150-200 מילישניות בלי להפריע למשחקיות, למרות שהחוויה לעולם לא תהיה חלקה כל כך. אם אתם משחקים ב-Windows, אולי יעניין אתכם ללמוד איך. הפחתת השהיית קלט ב-Windows 11 לשיפור התגובה במשחקים תחרותיים.

שיחות וידאו, שיתוף מסך ושיחות VoIP

בשיחות וידאו עם זום, טימס, סקייפ או פלטפורמות דומות, גם פינג הוא קריטי. באופן אידיאלי, הוא צריך לרחף סביב... 20-40 msשבו השיחה זורמת באופן טבעי, ללא חפיפות. רוב המשתמשים סובלים עד כ-100 מילישניות, אם כי עיכובים קלים כבר מורגשים בעת דיבור.

כאשר הפינג עולה על 100 msאתם מתחילים להפריע, בלי כוונה, לאדם השני. תגובות מגיעות עם "הד" זמני, ושתיקות מביכות הופכות תכופות. אם, בנוסף, לחיבור יש רוחב פס מוגבל או שה-Wi-Fi חלש, מתווספות נפילות וידאו ואודיו לתערובת.

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

האינטרנט של הדברים, אוטומציה ביתית ועבודה מרחוק

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

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

השהייה ואבטחה: השפעה עקיפה

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

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

הגורמים העיקריים להשהייה גבוהה ברשתות ביתיות

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

כיסוי WiFi גרוע והפרעות

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

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

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

נתב מיושן או עמוס יתר על המידה

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

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

הורדות ומכשירים אחרים הצורכים רוחב פס

אם ברשת שלך יש מספר מכשירים שמורידים הרבה (P2P, עדכונים, סטרימינג 4K, גיבויים בענן), זה נורמלי ש... קפיצות הפינג שלךהבעיה אינה כל כך ש"נגמרו המגה-בייטים", אלא איך הנתב מנהל את התורים היוצאים.

הפתרון כולל שני מסלולים:

• מצד אחד, שליטה טובה יותר על מה שמורד ברקע (מחשב אישי, טלפונים ניידים, קונסולות, NAS...).
• מצד שני, הפעל והתאם כראוי את QoS ו-anti-bufferbloat מהנתב כך שתעבורה אינטראקטיבית (משחקים, VoIP, שיחות וידאו) מקבלת עדיפות על פני הורדות המוניות.

VPN, פרוקסי, חומת אש ותוכנות רקע

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

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

תוכנות זדוניות ומכשירים שנפגעו

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

כלים למדידת השהייה וזיהוי בעיות

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

פינג בסיסי ו-traceroute

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

אם תוסיף א -t בווינדוס (ping 8.8.8.8 -tאתה יכול לתת לו לפעול כדי לראות אם יש קפיצות, נפילות או ריצוד. ועם מסלול מעקב/מעקב אתה בודק אילו קפיצות החבילות שלך עוברות ובאיזו נקודה ההשהיה מתחילה לעלות באופן חשוד.

כלים מתקדמים: WinMTR, PingPlotter ואחרים

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

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

מדידת פינג בנייד: אפליקציות לאנדרואיד ו-iOS

בסמארטפונים וטאבלטים ניתן גם למדוד השהייה באמצעות אפליקציות כמו Fing, כלי רשת He.net, NetX או כלי פינג ספציפיים ב-iOS. אלה מושלמים לבדיקה אם הבעיה היא ב-Wi-Fi של חדר מסוים, ברשת הסלולרית, או אם הקו הקווי עצמו מספק איכות ירודה.

אופטימיזציה מתקדמת של TCP/IP בשרתים ובענן

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

הגדרות ליבה ו-TCP במערכת ההפעלה לינוקס

בלינוקס, באמצעות sysctl וכלים כמו tc o ethtool ניתן ליישם אופטימיזציות מתקדמות כגון:

• הנמיך את ה-RTO המינימלי (net.ipv4.tcp_rto_min_us) לערכים בטוחים כגון 5000 מיקרו-שניות (5 מילישניות) ברשתות פנימיות בעלות השהיה נמוכה. כדי להתאושש מהר יותר מאובדן חבילות.
• להפעיל תור הוגן (FQ) עם tc qdisc replace dev <iface> root fq. כדי לחלק טוב יותר את רוחב הפס בין זרימות ולמנוע פרצים מוגזמים מחיבור יחיד.
• השבת התחלה איטית לאחר חוסר פעילות (net.ipv4.tcp_slow_start_after_idle=0) בשרתים המשתמשים בחיבורים קבועים. כך שהם לא יתחילו מחדש מרוחב פס נמוך באופן מגוחך בכל פעם שהם מתעוררים ממצב שינה.
• השבת את החלק הבעייתי של הייסטארט (זיהוי רכבת ACK) ב-TCP מעוקב. כדי למנוע תוצאות חיוביות שגויות של עומס יתר להאט את צמיחת החלון.
• הגדל את מאגרים של TCP (tcp_rmem, tcp_wmem, rmem_max, wmem_max). כדי להיות מסוגלים לשמור על תפוקה גבוהה בקישורים עם RTT גבוה, ולמנוע מחסור בזיכרון ב-sockets.
• לְהַגבִּיל tcp_notsent_lowat זה מונע הצטברות של יותר מדי נתונים שלא נשלחו בליבת המערכת, ובכך מגן על המערכת מפני צריכת זיכרון מוגזמת.
• אפשר חומרה GRO/LRO על כרטיסי רשת תואמים (ethtool -K <iface> rx-gro-hw on). כדי לקבץ חבילות ולהפחית את עומס המעבד לכל פסיקה.

MTU גדולים ורשתות בעלות ביצועים גבוהים

ברשתות ענן פנימיות (למשל, ספקי שירותי Google Cloud VPC) בהן ניתנת תמיכה MTU ג'מבו עד ~8900 בתיםמומלץ מאוד להגדיל את ה-MTU (לדוגמה לכ-4082 בתים התואמים לדפי זיכרון של 4 KB) כדי להקטין את מספר החבילות המעובדות בשנייה ולשפר את יעילות המעבד.

עם זאת, עליכם להיזהר עם תעבורה היוצאת לאינטרנט או שעוברת דרך VPN: במקרה כזה, עדיף לשמור על MTU סטנדרטי של 1500 או להתאים אותו לכל מסלול (ip route change עם mtu y advmss) כך שתקשורת חיצונית לא תסבול מפיצול או אובדן עקב חבילות גדולות מדי.

שרתי אינטרנט, HTTP/2/3 ואחסון במטמון

בשרתי אינטרנט (Nginx, Apache וכו'), בנוסף לכוונון TCP, ניתן להפחית משמעותית את ההשהיה הנתפסת על ידי הפעלת HTTP/2 ו-HTTP/3 (QUIC)אשר מאפשרים ריבוב של בקשות מרובות בחיבור יחיד ומפחיתים את עלות לחיצות הידיים.

מאפשר דחיסת GZIP או Brotli, להשתמש מטמון בזיכרון (Redis, Memcached), למזער CSS/JS ולהגיש תוכן סטטי דרך CDN עם ​​נקודות נוכחות סמוכות למשתמש. כל אלפית שנייה שאתם חוסכים ב-TTFB (זמן לבייט ראשון) וב-RTT של הרשת מתורגמת לאתר שמגיב "מהר יותר" בעיני המבקר.

ניטור רציף ומדדי השהייה

לבסוף, אם אתם רציניים לגבי ביצועים, עליכם למדוד אותם באופן רציף. כלים כמו ApacheBench, work, JMeter או חבילות תצפית (Prometheus + Grafana, New Relic, Datadog…) מאפשרות לך לנטר RTT, TTFB, אחוזוני השהייה, תפוקה ושיעור שגיאות תחת עומס.

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

עם כל המושגים וההגדרות הללו על הפרק, החל מ-MTU ו-MSS ועד QoS של נתבים, רשתות ענן מואצות ותצורת שרתי אינטרנט, ברור ש-lag אינו תוצאה של גורם קסם אחד. זהו סכום של רכיבי רשת רבים ו-TCP/IP עצמו, שכאשר הם מכוונים כראוי, מאפשרים למשחקים, שיחות וידאו, עבודה מרחוק ואתרי אינטרנט להגיב באותה תגובתיות. תחושה של מיידיות שכולנו מחפשים, ושמושג לעתים קרובות יותר על ידי התאמת והבנה של הרשת מאשר פשוט על ידי צבירה של "יותר מגה-בייט".