למה הורדה ב-VPN מוגבלת בהעלאה של השרת

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

המספר שקראתם היה בכיוון הלא נכון

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

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

כתבו את המסלול כתקציב

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

עם קישור העלאה של השרת ב-20 Mbit/s וקישור הורדה של הלקוח ב-100 Mbit/s, השרת מגביל את ההעברה הרבה לפני שהלקוח מבחין בכך. תקורת העטיפה וכל העברה במקביל לוקחות עוד נתח, וקישור העלאה רווי מעכב גם אישורים, מה שמאט העברת TCP מתחת לתקרה הגולמית. אף אחד משני ההשפעות אינו מופיע בהשוואת תוכניות.

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

איפה הלוח באמת עולה לכם

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

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

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

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

מדדו לפני שמחליפים צופן

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

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

iperf3 -c 10.44.0.1 -R -t 30
iperf3 -c 10.44.0.1 -t 30
ethtool eth0 | grep -i speed

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