רשתות למפתחי תוכנה - מה חייבים לדעת, גם אם אתם "רק" כותבים קוד¶
יש בדיחה ישנה בין מהנדסי תשתית - "זה תמיד DNS". והאמת היא שהבדיחה הזאת נכונה יותר ממה שרוב המפתחים רוצים להודות. כתבתם קוד מושלם, הטסטים עוברים, ואז בפרודקשן שום דבר לא עובד - ולרוב זה לא הלוגיקה שלכם שקורסת, זו בעיית רשת שאין לכם כלים להבין. הנה מה שכל מפתח, גם כזה שמעולם לא רצה "לגעת בתשתית", חייב להכיר.
למה מפתחים בורחים מרשתות, וזו טעות¶
הרבה מפתחים חושבים ש-DevOps או צוות התשתית "יטפלו בזה". זה נכון בחלק מהמקרים, אבל כשאתם דיבאגים למה ה-API קורא נכשל, למה החיבור למסד הנתונים איטי פתאום, או למה שירות אחד לא מצליח לדבר עם שירות אחר בתוך אותה מערכת ענן, אין לכם ברירה - אתם חייבים להבין את שכבת הרשת, לפחות ברמה בסיסית.
פורטים - הדלת הספציפית לתוך השרת¶
כתובת IP מזהה מחשב, אבל מחשב יכול להריץ עשרות שירותים במקביל - שרת ווב, מסד נתונים, שירות API. פורט הוא בעצם המספר שאומר לאיזה שירות ספציפי בתוך המחשב מכוונת הבקשה. שרת ווב רגיל מאזין על פורט 80 (HTTP) או 443 (HTTPS), מסדי נתונים כמו PostgreSQL מאזינים בברירת מחדל על 5432, ו-MySQL על 3306.
כשמפתח רואה שגיאת "connection refused", זה כמעט תמיד אומר שהוא ניגש לכתובת נכונה אבל לפורט שגוי, או שהשירות בכלל לא רץ שם. כשהוא רואה "timeout", זה אומר שהחבילות בכלל לא מגיעות - חומת אש חוסמת, או שהכתובת פשוט לא נגישה מהמקום שממנו הוא מנסה.
DNS - הסיבה שהקוד שלכם "פתאום לא עובד"¶
כבר דיברנו על DNS במאמר נפרד, אבל למפתחים יש עוד סיבה חשובה להבין אותו - שירותים בענן משתמשים ב-DNS פנימי כדי שקומפוננטות שונות ימצאו זו את זו. אם השירות שלכם לא מצליח למצוא שירות אחר לפי שם (למשל בתוך קלאסטר קוברנטיס), הבעיה לרוב היא ברזולוציית DNS פנימית, לא בקוד שלכם. כשמפתח מבין את זה, הוא חוסך שעות של "דיבאגינג" על קוד תקין לגמרי.
TCP מול UDP - למה חשוב לבחור נכון¶
כשאתם בוחרים איך שני שירותים ידברו זה עם זה, אתם בעצם בוחרים בין אמינות למהירות. TCP מוודא שכל הודעה מגיעה, בסדר הנכון, ומתמודד עם אובדן חבילות. UDP שולח ולא בודק אם זה הגיע. לכן API רגיל של REST רץ על TCP - אתם רוצים לוודא שהבקשה שלכם תגיע. אבל סטרימינג וידאו בזמן אמת, או משחקים אונליין, לרוב משתמשים ב-UDP - עדיף לאבד פריים אחד מאשר לחכות שהוא יגיע באיחור.
Timeout, Retry, ו-Latency - למה הקריאה שלכם נתקעת¶
מפתחים נתקלים בזה כל הזמן - קריאת API "נתקעת" ואז נכשלת אחרי 30 שניות. זה לא באג בקוד, זה timeout - הגדרה שאומרת "אם לא קיבלתי תשובה תוך X זמן, תפסיק לחכות". להבין למה קורא הזמן הזה, ואיפה להגדיר אותו נכון, זה בדיוק ידע רשתי בסיסי. אותו דבר עם latency - הזמן שלוקח לחבילה להגיע וחזור. שירות שקורא לשירות אחר בקצה השני של העולם תמיד יהיה איטי יותר, לא משנה כמה הקוד שלו מהיר, פשוט בגלל מרחק פיזי ומהירות האור.
HTTP וקודי סטטוס - שפה שכל מפתח חייב לדעת¶
כל מפתח backend נוגע ב-HTTP כל יום, אבל לא כולם באמת מבינים אותו לעומק - מה ההבדל בין POST ל-PUT, למה יש 401 מול 403, מה זה CORS ולמה הוא תמיד תוקע אותך בדיוק כשאתה הכי לחוץ בזמן. הבנה טובה של HTTP חוסכת שעות של חיפוש בסטאק אוברפלו כל פעם שמשהו נראה מוזר.
למה בסופו של דבר זה מקצר לכם את הדיבאגינג¶
הרעיון המרכזי הוא זה - כשמשהו לא עובד, השאלה הראשונה שאתם צריכים לשאול היא "האם זו בעיית קוד, או בעיית רשת". בלי בסיס ברשתות, אתם תמיד תנחשו, תוסיפו לוגים בכל מקום, ותבזבזו זמן על השערות שגויות. עם בסיס ברשתות, אתם בודקים תוך דקות אם החבילות בכלל מגיעות, אם ה-DNS מסתדר, ואם הפורט פתוח - ורק אז חוזרים לחשוד בקוד שלכם.
זה בדיוק סוג הידע שקורס רשתות טוב נותן - לא כדי להפוך אתכם למהנדסי תשתית, אלא כדי שתפסיקו לפחד ברגע שהבעיה חוצה את הגבול בין הקוד לתשתית שמסביבו.
קורס הרשתות המלא נמצא כאן, חינם ובעברית, בנוי בדיוק כדי לתת למפתחים את הבסיס הזה בלי להפוך אתכם למומחי תשתית.
יש לכם באג שנראה כמו בעיית רשת ואתם לא בטוחים? שאלו בדיסקורד.
לסיכום¶
אתם לא צריכים להיות מנהלי רשת כדי לכתוב קוד טוב, אבל בסיס ברשתות הוא ההבדל בין מפתח שנתקע שעות על "באג מסתורי" לבין מפתח שמזהה תוך דקות ש-DNS פנימי לא מסתדר, שפורט חסום, או שזה סתם timeout רגיל. השקעה קטנה בבסיס הזה חוזרת אליכם בכל דיבאגינג עתידי.