איך TCP עובד?

פרוטוקול ה-TCP הוא אחת השכבות בפרוטוקול האינטרנט (IP) וכולנו משתמשים בו על בסיס יומי. הפרוטוקול מאפשר לנו ליצור ולתחזק תקשורת בין מחשבים שונים באינטרנט, או במילים אחרות אחראי על התעבורה.

יש שלושה שלבים לפרוטוקול ה-TCP:

  1. הקמת הקשר (session starting).

  2. תעבורת מידע (data transmission).

  3. סגירת הקשר (session ending).

  4. נניח שאנחנו רוצים להתחבר לשרת כלשהו. בשביל להתחיל את התקשורת, קודם כל יש צורך להקים את הקשר. את זה המחשב עושה באמצעות לחיצת יד משולשת (Three-way handshake). בשלב הראשון אנחנו (ה-client) שולחים לשרת פקטה (packet) יחידה לשרת שנקראת SYN עבור synchronize (סנכרן) ובה אנו אומרים לשרת: ”היי, אתה יכול לפתוח קשר עבורנו?”. בשלב הבא השרת מגיב עם פקטה שנקראת SYN-ACK עבור synchronize-acknowledge (סנכרן-הכר). כאן השרת עונה לנו:”כן. האם גם אתם יכולים לפתוח קשר בשבילי?”. בשלב השלישי והאחרון אנחנו שולחים לו פקטת ACK ובעצם עונים לו “כן.” ונוצר קשר דו כיווני ביננו לשרת.

אבל איך זה נראה בפועל? כאשר אנו שולחים לשרת הודעת SYN אנחנו שולחים פקטה שמורכבת ממספר חלקים- SEQ, ACK, SYN. ה-SEQ הוא למעשה Sequence Number שכולל איזשהו מספר אקראי, נניח 1001. המספר הזה הוא המספור ההתחלתי של חתיכות המידע שישלחו. לאחר מכן יש את ה-SYN ו-ACK שהם דגלים שנושאים את הערך 1 או 0. אז בשלב הזה ה-SYN יהיה 1, שמסמל שאנחנו שולחים הודעת SYN, וה-ACK יהיה 0. כלומר ההודעה תראה כך: 1001-0-1 כאשר 1001 הוא המספר האקראי, ה-0 מסמל שזו לא הודעה ACK וה-1 מסמל שזו כן הודעת SYN. בשלב הבא השרת עונה לנו עם הודעת SYN-ACK, אבל היא נראית קצת אחרת. אם ניקח את הדוגמה הקודמת, ההודעה תראה כך: 2001-1002-1 תחילה נסתכל על האמצע, או ה-ACK. השרת לוקח את ה-SEQ ששלחנו לו, מוסיף לו 1 ומחזיר לנו אותו בתור ה-ACK. כך השרת מכיר בהודעה הקודמת שלנו שבה ביקשנו שיפתח עבורנו קשר. ה-1 מסמל את ה-SYN וה-2001 בתחילת ההודעה הוא ה-SEQ של השרת, שמביא לנו מספר SEQ משלנו. בשלב האחרון אנחנו מחזירים לשרת את ההודעה: 1002-2002-0 ה-0 בסוף מסמל את ה-SYN. מאחר שזו הודעת ACK ואין לנו SYN, אז הוא 0. באמצע יש לנו את ה-ACK. בדומה לשלב השני, אנחנו לקחנו את ה-SEQ שהשרת שלח לנו, 2001, והוספנו לו 1 כדי להכיר בבקשה שלנו.

  1. לאחר שסיימנו את ה-handshake אנחנו עוברים לשלב השני, וכאן מתחילה העברת הנתונים בין שני הצדדים. היתרון הגדול של ה-TCP על פני ה-UDP (עליו בפעם אחרת) הוא אמינות החיבור- אין דבר כזה packet loss ואנחנו מקבלים בוודאות את כל המידע שנשלח אלינו לפי הסדר. ה-SEQ מסמל את המספר הסידורי של הפקטות, מה שמאפשר לנו לדעת לפי איזה סדר אנחנו אמורים לקבל את המידע. זה מאפשר לנו גם לקבל את כל המידע בסדר הנכון ולא לערבב אותו וגם לקבל את כל המידע. על כל פקטה שקיבלנו אנחנו מחזירים הודעת ACK שמאשרת לשרת שקיבלנו. אם קרה ולא קיבלנו את המידע, השרת לא יקבל הודעת ACK וימשיך לשלוח לנו את המידע עד שנאשר שקיבלנו אותו. ככה אנחנו יכולים להיות בטוחים שהכל הגיע ולא פספסנו שום דבר. בפקטת TCP יש עוד חלקים שלא ציינו עד עכשיו, אחד מהם הוא גודל חלון השליחה (Window size). החלק הזה מציין כמה יחידות מידע אנחנו יכולים לקבל בכל פעם מהשרת והוא משתנה בהתאם לרוב הפס. כך נמנע מצב שהשרת שולח 100 יחידות בזמן שאנחנו יכולים לקבל רק 10 יחידות ונוצר צוואר בקבוק.

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

  1. לאחרי שהשרת סיים להעביר נתונים, מגיעים לשלב האחרון והוא סגירת הקשר. קודם כל, השרת שולח לנו פקטת FIN-ACK שבה הוא מעדכן אותנו שהוא סיים להעביר את המידע ומעוניין לסגור את הקשר. אנחנו עונים לו עם פקטת ACK שבה אנו מאשרים שקיבלנו את ההודעה שלו. לאחר שסיימנו להוריד את הנתונים (השרת מסיים לשלוח לפני שהלקוח מסיים לקבל שהרי יש דרך לעבור בינם, ככה שסיום הורדת הנתונים מצד הלקוח וסיום העברת הנתונים מצד השרת הם לא אותו הדבר) אנו שולחים לשרת הודעת FIN-ACK שבה מעדכנים אותו שסיימנו להוריד ושואלים אותו אם הוא שמע אותנו. בשלב הזה השרת שולח לנו הודעת ACK שמאשרת שהוא קיבל את ההודעה ואפשר לסגור את הקשר.
לטעון תגובות?