האם VPN באמת מוריד את הפינג שלך במשחקים מקוונים?

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

קבעו את האזור ואת השרת לפני ההשוואה

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

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

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

פינג ממוצע מסתיר את מה שאתם באמת מרגישים

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

ping -c 20 <game-server>
mtr -rwc 50 <game-server>

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

עומס מקומי גובר על כל בחירת יציאה

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

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

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

UDP בתוך מנהרה הוא עדיין UDP בתוך מנהרה

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

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

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

רשמו את המספרים לפני ששופטים לפי תחושה

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

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