עודכן לפני חודש
כשאנשים מדברים זה עם זה, הם כל הזמן מאלתרים. מישהו מגמגם — אתה מבקש ממנו לחזור. למילה יש שתי משמעויות — ההקשר מבהיר. הצד השני נראה מבולבל — אתה מנסח מחדש. בני אדם מצליחים לתקשר למרות חוסר הבהירות, כי אנחנו יכולים להסתגל בזמן אמת.
מכונות לא יכולות לעשות זאת.
מחשב שמקבל נתונים אין לו אינטואיציה. הוא לא יכול לנחש מה כנראה התכוונת. הוא לא יכול לשאול שאלות בירור באמצע השידור. אם סיבית מגיעה פגומה, אין למכונה דרך לדעת מה היה אמור להיות שם. כל מצב אפשרי — כל מקרה קצה, כל תרחיש כשל, כל דו-משמעות — חייב להיות צפוי ומוגדר מראש.
המפרטים האלה נקראים פרוטוקולים. הם הכללים המפורטים עד דקדקנות שמאפשרים תקשורת בין מכשירים שאין להם יכולת אילתור.
מדוע מכונות זקוקות לכללים מפורשים
תארו לעצמכם שאתם מנסים לתאם עם מישהו שיבצע את ההוראות שלכם בדייקנות מוחלטת אך ללא שיקול דעת. אי אפשר לומר "שלח לי את הקובץ." צריך לפרט: באיזה פורמט? באיזה גודל נתחים? מה קורה אם נתח אחד אובד? כיצד מאותת המקבל שהוא מוכן לקבל עוד? מה קורה אם שני מכשירים מנסים לשדר בו-זמנית? מה מציין שהשידור הושלם?
פרוטוקולים עונים על כל השאלות האלו — ועל אלפים נוספות — לפני שמתחילה כל תקשורת. הם חייבים לעשות זאת, כי ברגע שהנתונים מתחילים לזרום, אין מקום ל"רגע, למה התכוונת בזה?"
זו הסיבה שפרוטוקולים מדויקים עד כדי פרנויה. הם מגדירים מיקומי בתים מדויקים, משך פסקי זמן מדויקים, רצפי הודעות מדויקים. הדיוק הזה אינו עומס בירוקרטי. הוא הדרך היחידה שבה מכונות שאין להן אינטואיציה משותפת יכולות להבין זו את זו.
מה פרוטוקולים באמת פותרים
יכולת פעולה הדדית היא היתרון הברור. הטלפון שלך יכול לטעון דף אינטרנט משרת במדינה אחרת, משום ששני המכשירים מממשים את אותו מפרט HTTP. יצרנים שונים, מערכות הפעלה שונות, חומרה שונה — אף אחד מאלה לא משנה אם שני הצדדים מקיימים את הפרוטוקול.
אמינות מתמודדת עם האמת הלא נוחה שרשתות נכשלות כל הזמן. בסדר גודל של האינטרנט, כבלים נחתכים, מנות מגיעות פגומות, נתבים קורסים באמצע שידור. פרוטוקולים כמו TCP יוצאים מנקודת הנחה שהכל ישתבש, וכוללים מנגנונים לאיתור בעיות והתאוששות מהן: סכומי ביקורת תופסים שחיתות, מספרי סדר מזהים נתונים חסרים, אישורים מאשרים קבלה. הפרנויה מוצדקת.
יעילות מונעת בזבוז מיותר. במקום לשלוח קובץ גדול כיחידה שבירה אחת, פרוטוקולים מפצלים נתונים למנות שיכולות לנסוע בנתיבים שונים ולהיות מורכבות מחדש ביעד. אם מנה אחת אובדת, רק אותה מנה צריכה להישלח שוב — לא הקובץ כולו.
תיאום פותר את בעיית המשאבים המשותפים. כשמספר מכשירים חולקים רשת, משהו חייב למנוע מכולם לשדר בו-זמנית. פרוטוקולים מגדירים מי יכול לשלוח ומתי, מה קורה במהלך התנגשויות, וכיצד מכשירים מפנים מקום זה לזה.
מחסנית הפרוטוקולים: שכבות בעלות תפקיד מוגדר
אין פרוטוקול יחיד שמטפל בהכל. במקום זאת, פרוטוקולים מאורגנים בשכבות, כאשר כל אחת פותרת קטגוריה אחת של בעיות ומסתמכת על השכבות שמתחתיה לשירותים שאינה מספקת.
למחסנית TCP/IP יש ארבע שכבות:
שכבת הקישור מטפלת במציאות הפיזית הישירה: כיצד סיביות הופכות לאותות חשמליים, כיצד מכשירים על אותו הכבל מחלקים תורות לשידור, כיצד מכשיר מזהה עם איזה שכן הוא מדבר. Ethernet שולטת כאן ברשתות קוויות; Wi-Fi — ברשתות אלחוטיות.
שכבת האינטרנט פותרת כתובות וניתוב בין רשתות. פרוטוקול האינטרנט (IP) מקצה כתובות לוגיות ומעביר מנות לכיוון יעדן, אך אינו מבטיח דבר. מנות עשויות להגיע שלא לפי הסדר. מנות עשויות שלא להגיע כלל. IP פשוט עושה כמיטב יכולתו.
שכבת התחבורה מוסיפה את הערבויות שיישומים זקוקים להן. TCP בונה מסירה אמינה ומסודרת על גבי השירות הלא-אמין של IP — מקיים חיבורים, עוקב אחר מה שהתקבל, ומשדר מחדש מה שאבד. UDP מוותר על האמינות עבור יישומים שבהם מהירות חשובה יותר מהשלמות.
שכבת היישומים מכילה פרוטוקולים למטרות ספציפיות: HTTP לתוכן רשת, SMTP לדואר אלקטרוני, DNS לתרגום שמות דומיין לכתובות IP. כל אחד מניח ששכבת התחבורה מתחתיו מטפלת במסירה.
להפרדה הזו יש יתרון מעשי: ניתן להחליף שכבות מבלי לשכתב הכל. יישום המשתמש ב-HTTP יכול לפעול על TCP היום ועל QUIC מחר, מבלי לשנות שורת קוד אחת ביישום עצמו.
בקשה נעה דרך המחסנית
כשאתה מבקר באתר אינטרנט, פרוטוקולים מופעלים בכל שכבה.
הדפדפן שלך משתמש תחילה ב-DNS כדי להמיר את שם הדומיין לכתובת IP — שאילתה שנשלחת דרך UDP, כי היא קטנה ומהירות חשובה יותר ממסירה מובטחת עבור חיפוש שניתן פשוט לנסות שוב.
עם כתובת ה-IP ביד, הדפדפן יוצר חיבור TCP: לחיצת יד של שלוש הודעות שבה שני הצדדים מסכימים על מספרי סדר התחלתיים וגדלי חיץ. רק לאחר ההגדרה הזו זורמים הנתונים בפועל.
דרך חיבור ה-TCP, הדפדפן שולח בקשת HTTP — הודעה מעוצבת בדייקנות עם שורת בקשה, כותרות המכילות מטא-נתונים, ולעיתים גם גוף ההודעה. השרת מנתח זאת לפי כללי HTTP ושולח בחזרה תגובה באותו פורמט.
אם האתר משתמש ב-HTTPS, TLS יושב בין HTTP ל-TCP, מצפין את הודעות ה-HTTP לפני ש-TCP משדר אותן. זה ממחיש כיצד ניתן להכניס פרוטוקולים למחסנית כדי להוסיף יכולות — אבטחה, במקרה זה — מבלי לדרוש שינויים מעל או מתחת.
לאורך כל זאת, Ethernet או Wi-Fi מטפלים בתנועה הפיזית הממשית של סיביות ברשת המקומית שלך, כשכל מנה עטופה בפורמט המסגרת המתאים עם כתובות MAC המזהות מקור ויעד.
כיצד פרוטוקולים מתפתחים
פרוטוקולים מתוקננים דרך תהליכים פתוחים. ה-IETF מפרסמת את רוב פרוטוקולי האינטרנט כ-RFC — בקשות להערות. השם נשמע מסויג, אבל המסמכים האלה הם המפרטים הסמכותיים. TCP, IP, HTTP, DNS — כולם מוגדרים ב-RFC.
תהליך ה-IETF מדגיש קוד עובד על פני אלגנטיות תיאורטית. פרוטוקול שקיים רק על הנייר אינו יכול להיות מתוקנן. הגישה המעשית הזו שמרה על פרוטוקולי האינטרנט מעוגנים במציאות.
ה-IEEE מטפל בתקנים של שכבות הפיזית והקישור — Ethernet ו-Wi-Fi נכנסים תחת מפרטי 802 שלהם. ה-W3C מתחזק תקנים ספציפיים לרשת.
מכיוון שפרוטוקולים חייבים להתפתח תוך שמירה על תאימות עם מכשירים קיימים, הם כוללים מנגנוני משא ומתן. כשמתחיל חיבור TLS, לקוח ושרת מחליפים רשימות של גרסאות נתמכות ומסכימים על הגרסה הגבוהה ביותר שניהם מבינים. זה מאפשר אימוץ הדרגתי של שיפורים מבלי לשבור תקשורת עם מערכות ישנות יותר.
שאלות נפוצות על פרוטוקולים
מה ההבדל בין TCP ל-UDP?
TCP מספק מסירה אמינה ומסודרת — הוא מבטיח שהנתונים שלך מגיעים שלמים ולפי הסדר, ומשדר מחדש כל דבר שאבד. UDP מספק מסירה מהירה וחסרת חיבור ללא ערבויות. השתמש ב-TCP כשהנכונות חשובה (דפי רשת, העברות קבצים). השתמש ב-UDP כשמהירות חשובה יותר מהשלמות (שיחות וידאו, משחקים).
מדוע יש כל כך הרבה פרוטוקולים במקום פרוטוקול אחד?
בעיות שונות דורשות פתרונות שונים. פרוטוקול שמותאם להעברת קבצים אמינה יהיה מבזבז עבור וידאו בזמן אמת. פרוטוקול שמטפל בתזמון אותות פיזיים אין לו עניין בעיצוב דפי רשת. גישת השכבות מאפשרת לכל פרוטוקול לעשות דבר אחד — ולעשות אותו היטב.
מה קורה כשלפרוטוקול יש באג או פגם אבטחה?
גופי התקינה מפרסמים עדכונים, ויישומים חייבים לקבל תיקונים. זו הסיבה שעדכוני אבטחה חשובים — הם לעיתים קרובות מתקנים פגיעויות ברמת הפרוטוקול. מנגנוני המשא ומתן המובנים בפרוטוקולים עוזרים כאן: ברגע שפגם ידוע, ניתן להגדיר מערכות לסרב לגרסה הפגיעה.
האם אני יכול ליצור פרוטוקול משלי?
כן, אבל תצטרך שכל מי שאתה רוצה לתקשר איתו יממש אותו גם. הערך של פרוטוקולים מתוקננים הוא בדיוק שכולם כבר מדברים אותם. פרוטוקולים מותאמים אישית הגיוניים רק בסביבות מבוקרות שבהן אתה שולט בכל נקודות הקצה.
האם דף זה היה מועיל?