HTTPS חם מול VPN חם: השוו את אותו נתיב בקשה

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

מה ששימוש חוזר באמת דורש

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

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

בדקו את הלקוח הנתמך של הספרייה ואת מחזור החיים של מאגר החיבורים במקום להניח שהאיגוד פועל או כבוי. רשמו גם את גרסת ה-HTTP שנדונה, מפני ש-HTTP/2 ו-HTTP/3 מטפלות בשימוש חוזר בחיבורים אחרת מ-HTTP/1.1. התייחסו לגרסה שנדונה כחלק מהמדידה ולא כהערת שוליים.

מדוע ההשוואה מודדת מחזור חיים

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

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

הפרידו הקמה קרה מבקשות חמות

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

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

תכננו לקראת החיבור שנסגר

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

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

בחרו קודם את הגבול ואז כווננו

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

הפרק על התמדה ב-RFC 9112 הוא המקור למה ששימוש חוזר באמת מבטיח, כולל התנאים שמסיימים חיבור. קראו אותו פעם אחת לפני שתסמכו על מדידה שמתעלמת מהם.