אני ממש אוהב את זה שמזמינים ממני פוסטים וקיבלתי שתי בקשות, אחת במייל (תודה Zod!) והשניה פה בתגובות (תודה אדם!) עם בקשה להסבר על udp ועל tcp. נכון שבאופן עקרוני כל אחד יכול להכנס לאיזה LLM ולבקש הסבר, אבל אני מסביר כמו בן אדם לבני אדם והסגנון שלי הוא ייחודי. אז הנה הסבר שיכול להיות רלוונטי על שני הפרוטוקולים האלו שאנחנו עושים בהם שימוש תמידי אבל לא רואים אותם.
כרגיל, כשאני רוצה לראות משהו ממש לעומק, אני משתמש ב-wireshark ואשתמש בו גם פה.
רגע, באיזה שכבה אנחנו?
מקובל לציין 7 שכבות במודל Open Systems Interconnection – ראשי תבות של OSI שזה בעצם המודל של התקשורת המודרנית שאנחנו מכירים. אני מאמין שרובכם שמעתם על שבע השכבות. אבל אני
שכבה ראשונה – השכבה הפיזית – כלומר ליטרלי הכבלים שמחברים את המחשבים אחד לשני או גלי הרדיו. זה מימד מאד מעניין שכבר חקרתי אותו כמה פעמים בבלוג הזה אבל לרוב המפתחים זה באמת… מימד משמים.
שכבה שניה – שכבת חיבור המידע – כלומר הפרוטוקול שבו מתקשרים באופן הכי ראשוני כדי להעביר מידע גולמי. קל להסביר את זה זו שזו בעצם השכבה שבה יש לנו Mac Address. הכתובות הפיזיות של כרטיסי הרשת שלנו (הפיזיים או WiFi).
שכבה שלישית – הרשת – בעצם השכבה שבה יש לנו את כתובת ה-IP ובה אנחנו מתקשרים עם מחשב אחר ודרך DHCP שנותן לנו כתובת IP.
השכבה הרביעית – שכבת התעבורה – השכבה שבה יש את הפרוטוקולים שמעבירים את המידע. זו השכבה שבה UDP ו-TCP חיים בה. זו השכבה שעוסקת בהעברת מידע אבל לא בפרוטוקול של איך שרת וקליינט (שיכול להיות דפדפן או תוכנה אחרת) מתקשרים. כלומר שרת וקליינט יכולים לתקשר ב-http או ב-ftp או בווטאבר אבל המידע שעובר יכול להיות בכל פרוטוקול. רואים את זה ב-HTTP. פרוטוקול HTTP עוסק בתקשורת בין קליינט, שזה דפדפן רוב הזמן, לבין שרת אינטרנט. אבל HTTP נמצא בשכבה השביעית ומשתמש בכל מה שיש מתחתיו. הוא יכול להשתמש ב-TCP או ב-UDP. זה לא מאד משנה לו. ב-HTTP V1/2 משתמשים ב-TCP אבל ב HTTP V3 משתמשים ב-UDP.
אז אנחנו בשכבה הרביעית, מתחת לחמישית ומעל לשלישית. כלומר יש לנו כתובות IP ואנחנו מטפלים בהעברת המידע פרופר. יש כמה דרכים להעביר מידע בין שתי כתובות IP. אנחנו נדבר על TCP בפוסט הזה.
מה זה בכלל? ראשי תבות של Transmission Control Protocol. זה פרוטוקול מובנה שמוודא באמצעות לחיצות יד שיש חיבור אמין בין הצדדים ששולח את המידע באמצעות פקטות (שזה חבילות מידע) סדורות, לפי הסדר, תוך שהוא גם מקפיד על הקצב. אפשר לומר שזה הגרמנים של פרוטוקול 4. הכל מסודר ומובנה.
אפשר לומר ש-TCP זה בעצם הקמת הצינור שדרכו עובר המידע של השכבות העליונות יותר ובראשן http.
בואו ונראה איך זה נראה!
הדרך הכי טובה, לפחות עבורי, לראות את זה הוא ממש להפעיל wireshark ולראות את מה שקורה. תראו איזה יופי זה נראה! הפעילו wireshark, ושלחו בקשה ל http://example.com. עדיף לעשות את זה עם curl כי לפעמים הדפדפן משאיר את החיבור פתוח וזה מפריע לסיום.
$curl -v --http1.1 http://example.comנכניס ב-Wireshark את הפילטר:
tcp.port == 80 and not httpונוכל לראות רק את הפקטות של TCP. שימו לב שבשביל הנוחות אני לא עובד פה עם https (למרות שאפשר) כי אנחנו רוצים לראות את ה-TCP בעצמנו. בעיניים שלנו.
אז אם תעשו את הכל כמו שצריך, תוכלו לראות רשימה נאה של פקטות בפרוטוקול tcp, בלי בלגן של http שזו השכבה למעלה שתפריע לנו.
השלב הראשון! הקליינט שולח הודעה!
הדבר הראשון שאני לפחות מתרשם ממנו הוא כמה תנועה יוצאת וחוזרת! וכל זה מול שרת שיושב בחו״ל ובבקשה פשוטה. אפשר לראות עד כמה התשתית הזו מורכבת! אם נלחץ על הבקשה הראשונה נוכל לבחון אותה. יש המון מה לומר עליה!
זו הבקשה הראשונה מכתובת ה-IP שלי 192.168.2.62 אל כתובת ה-IP של example.com שהיא 22.192.228.80. אפשר לראות כמה דברים מעניינים. קודם כל, יש לנו מיפוי של המספור וב-TCP יש לנו מספור מסודר ואם יש פספוס? יש שליחה מחדש. מה שיותר מעניין מבחינתנו הוא ה-FLAGS. מדובר ב-9 ביטים שאפשר להפעיל או לכבות. פה יש שלושה דולקים ומה שרלוונטי הוא ה-SYN – אני רוצה להתחבר! זה הכל.
שני הפלאגים האחרים הם הצהרה על יכולות. לא נכנס לזה פה כי זה לא מעניין בהקשר שלנו.
השלב השני – השרת אומר שלום!
הבקשה השניה מגיעה מ-example.com אלי! זה כל כך מרגש!
אם נסתכל על הפלאגים, נראה שיש לנו גם SYN וגם ACK זה השלב השני של לחיצת היד. השרת מאשר ואומר ״אני רוצה להמשיך!״. ממש שידוך משמים. וכמו בכל שידוך יש פה משא ומתן באמצעות ה-OPTIONS שיש בפקטה. שם השרת מצהיר על יכולות שונות שיש לו. אצלנו מופיעות חמש אופציות עיקריות: Maximum Segment Size, SACK Permitted, Timestamps, No-Operation ו-Window Scale. אני אפרט עליהן קצת אבל אפשר גם לדלג לפסקה הבאה. האופציה הראשונה, MSS בגודל 1460 בתים, מגדירה את גודל המקטע המקסימלי שהשרת מוכן לקבל ומונעת פיצול חבילות (fragmentation) ברשת. “SACK Permitted” מאפשרת ל־TCP לשלוח אישורי קבלה חלקיים (Selective Acknowledgments) ובכך לשחזר רק חבילות שאבדו ולא את כל הרצף, מה שמייעל מאוד את הביצועים. “Timestamps” מוסיפה חותמות זמן לחבילות כדי למדוד באופן מדויק את זמן הסיבוב (RTT) ולזהות חבילות ישנות או משוכפלות. שדה “No-Operation” משמש כרווח ליישור ביטים בלבד ואינו נושא מידע לוגי. לבסוף, “Window Scale” מגדיל את גודל חלון הקבלה פי 2⁷ (128) ומאפשר לשרת לקבל עד כ-8 מגהבייט נתונים לפני צורך ב־ACK נוסף, דבר החיוני לרשתות מהירות עם זמן השהיה גבוה.
אחרי שקיבלנו את זה, זה הזמן לענות עם הפקטה השלישית שבעצם מאשרת את הכל!
השלב השלישי – האישור הסופי!
פה אין מידע, מה שרלוונטי הוא שיש לנו ACK. זהו! אפשר להעביר מידע! הושלמה לחיצת היד עם שלושת השלבים. תואמו האפשרויות בין הלקוח לשרת ואפשר להעביר מידע. הבקשה הבאה תהיה של HTTP שהיא בקשת GET. כאן כבר המידע יכול לזרום. אני יכול לבחון אותה גם ב-wireshark אם אני אוריד את הפילטור של not http. מה שיפה הוא ש Wireshark כבר תראה לי את המידע יפה. אבל בפועל זה עדיין פקטה גדולה של מידע. אחרי כל פקטה שנשלחת ממני לשרת, השרת שולח ACK והפוך – כשהשרת שולח משהו, הקליינט שולח לו ACK.
סוף הקשר
אחרי זרימת המידע, הגיע הזמן לסוף הקשר בין שני האוהבים. כל אחד מהם יכול לסגור את הקשר. אם למשל ביצעתי את הבקשה עם פקודת curl, אחרי שהוא קיבל את המידע, הוא יכול לומר ״זהו״. אבל גם השרת יכול לומר ״זהו״. הבקשה היא באמצעות פלאג FIN שאומר – ״אין לי מה לשלוח יותר״. אנחנו נראה בקשה כזו (אם השתמשתם ב-curl אז הקליינט יזום אותה)
השרת יחזיר לכם FIN ACK ואז הקליינט יחזיר ACK. סיפור האהבה נגמר. כיוון שאין לנו state אז פה נגמר הקשר. הקליינט והשרת מסיימים את התקשורת ויש שקט. סיפור אהבה יפה נגמר לו.
למה זה חשוב?
אם אתם מממשים קליינט ושרת בעצמכם. פרוטוקול TCP לא יסגור חיבור אם אף צד לא שלח לו FIN ויש לזה משמעויות כלכליות לא מבוטלות בסקייל גבוה. אם יש לכם עלות גבוהה של שרת בגלל CPU גבוה והפרופיילר שלכם מעלה חרס בידו, לפעמים כן שווה להציץ בשכבה הזו כדי לראות שהחיבורים נסגרו. מי אמר שלא כיף ב-low level של הרשת?
סיכום
אפשר לראות איזה יופי ומורכבות יש בפעולה יומיומית שנעשית מאות מיליארדי פעמים על ידי כל האנשים על הפלנטה. זה ממש פלא מודרני מבחינתי ומשהו שאני נהנה לבחון אותו שוב ושוב. אני תמיד צוחק שאני כותב את הפוסטים האלו בשבילי וזה באמת פוסט מורכב, לא יודע כמה אנשים יקראו אותו אבל אני מאד נהניתי לכתוב אותו.
