TCP

 Transmission Control Protocol

TCP הוא פרוטוקול הנמצא בשכבת התעבורה “Transport” נוסף הוא עובד מעל לIP פירוש: Internet Protocol ולכן נקרא TCP/IP הוא פרוטוקול אמין לעומת UDP שאינו אמין, מה הכוונה לאמין, פרוטוקול זה משתמש ב Windowing על מנת לוודא את הגעת החבילות אליו ולהגביר את מהירות העברה ככל שהרשת אמינה יותר, זאת אומרת כאשר הרשת אמינה יותר TCP\IP יפעל מהר יותר הסבר:
ננסה להסביר זאת כך: מחשב1 שולח הודעה למחשב2 ההודעה מחולקת ל Segments (לקריאה מורחבת על Segments לחצו כאן או חפשו באתר) עכשיו מחשב1 שולח את 3 הSegments הראשונים למחשב2, מחשב2 שולח הודעתACK שאומרת למחשב1 שההודעה התקבלה, אם ההודעה התקלה שולח מחשב1 את הSegments הבאים ונאמר שהפעם מחשב1 לא מקבל ACK ממחשב2 אז מחשב1 שולח שוב את אותם Segments.

לפני שליחת המידע חייב להיווצר קודם כל התקשורת יותר נכון ה Session בין 2 המחשבים בו.

מינוחים:

כל הזכויות שמורות לטל בן שושן – Shushan.co.il

Socket Pair

מוכנס לתוך ה Segment ואז ה Segment מוכנס לתוך IP Packet בתוך זה נמצא ה Source IP וה Destination IP על מנת לדעת מה ביקש הלקוח מהשרת ואיזה שירות הוא מעוניין  מוצמד פורט ל Source IP ול Destination IP :

Source IP: 192.168.1.10:5455

Destination IP: 192.168.1.200:80 (Web Server For Example)

תארו לכם שפתחתם פעמיים את התוכנה MSN ופתוח לכם כמה חלונות צ’ט, כאשר תשלחו לשרת הודעה השרת ידע איזה שירות אתם מחפשים נאמר פורט 80 וכאשר החבילה תחזור היא תדע לחזור לחלון 5455 בדיוק ולא לחלון אחר בו אתם מתכתבים.

Windowing

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

דוגמה: מחשב PC1 יוצר “חלון” בנפח של 10,000 Bytes וMTU או בשמו האחר MSS קיצור של Maximum Segment Size, חלון זה מוטמע בכל Segment ולכן גודלו ניתן לשינוי בכל זמן נתון.
בתרשים ניתן לראות שה Byte הראשון הוא 1 וה Byte האחרון הוא 10,000.

גודל החלון נקבע במהלך ה Three Way-Handshake מחשב PC1 אומר למחשב PC2 את גודל החלון שהוא 10,000 והMTU המירבי שהוא 1,500, זכרו היעד הוא זה שקובע את ה MTU!
כעת מחשב PC2  שולח את ה 1,500 Bytes הראשונים ונותן Sequence Number 1, מחשב PC1 מקבל את ה 1,500 Bytes.
כעת PC2 מגדיל את ה Seq Number בכמות ה Bytes שנשלחו + ה Seq Number הראשון, ואז הוא שולח את זה לPC1, מחשב PC1 מקבל את ה 1,500 Bytes הנוספים, והתוצאה היא עד כה שמחשב PC1 קיבל 3,000 Bytes.
כעת מחשב PC1 מודיע לPC2 שהוא קיבל 3,000 Bytes + ה Seq הראשון, והתוצאה היא שהוא שולח ACK (קיצור של Acknowledge ) שהוא קיבל 3,001, ואז מחשב PC2 שולח את ה Windowing  הבא שהוא עוד 10,000 והתוצאה היא שהוא מתחיל לשלוח את “חלון” 13,000, זיכרו 10,000 + ה 3,000 שהוא כבר קיבל.
כעת מחשב PC2 שולח Seq Number שהוא 3,001 ה3,000 שכבר קיימים + ה 1 Seq שנשלח בתחילת השיחה, כעת הוא שולח עוד 1,500 Bytes והתוצאה היא 3,000 + 1500 והתוצאה היא 4,500
מחשב PC1 אומר למחשב PC2 שהוא קיבל עד כה 4,500 +1 של Sequence Number ואז מחשב PC2 יודע שעד כה PC1 קיבל 13,000 + 1,500 שזה 14,500 ואת כל זה שולח PC1 כ ACK בשביל ליידע אותו
*חשוב לדעת ה Sequence הראשון ששלחו שהוא 1 (בתחילת ה Windows הוא למעשה Bytes אחד בלבד ובגלל זה הוא נספר בקבלת המידע

TCP Congestion Control

על מנת למנוע ממידע ליפול על ידי ראוטר שמקבל יותר מידי מידע הTCP מפעיל Congestion, במצב זה כאשר מחשב PC1 מקבל את הSegment הראשון ואז את השני ואז את השלישי ופתאום לא מקבל את הSegment הרביעי והחמישי, אז כדי שPC2 לא ישלח שוב באותה המהירות את ה Segments והם שוב יפלו, ה TCP מפעיל מנגון זה שמונע ממנו לשלוח באותה המהירות ובכך להקטין את הסיכוי ל Discarded Segments

TCP Header

TCP Header

הוא הצורה בה נשלח ה Segment או יותר נכון מה המבנה של ה Segment.
Source Port:
ברמת 16 סיביות – 16 Bits והוא מציין את המקור של החבילה (האפליקציה שממנה נשלח)
Destination Por:
ברמת 16 סיביות – 16 Bits והוא מציין את היעד של החבילה (האפליקציה שמקבלת את החבילה)
Sequence Number:
מספרו של ה Segment ועל ידי מספר זה יהיה ניתן לחבר את כל ה Segments כאשר יגיעו

Acknowledgment Number:
מספרו של ה Segment הבא שצריך להתקבל

Offset and Reserved:

Offset: אורך ה Header ב32Bit  (כך יוכל בהמשך לבדוק שהמידע לא פגום)
Reserved: לשימוש עתידי אמור להיות מסומן על 0

Flags:

מכיל 9 דגלים
NS: ניסיוני CWR: דגל להודעה בה השולח שולח למקבל על מנת להודיע על עומס בשליחה שהוא: ECE: מוגדר כ0 או כ1 אם כ-1 אז התווך מקבל ECN ואם 0 אז הוא לא ECN הURG: מציין שהשדה Urgent הוא חשוב ACK: מציין שהשדה Acknowledgment הוא שדה חשוב PSH: מציין למה יש עדיפות בשליחה RST: אומר לו לאפס את השליחה ולהתחיל אותה מההתחלה SYN: מספר הסנכרון ב TWH (Three Way-Handshake) :FIN השיחה הסתיימה אין יותר מידע להעביר

CWR וECE: משתמשים באלגוריתם למניעת עומס Congestion Avodiance.

Window:

מגדיר את גודל ה Segment שיכול להתקבל באותו הרגע

Checksum:

הוא בנוי מ16 סיביות והוא בודק אם קיים שגיאה במקטע (Segment) הוא משתמש ב CRC פירוש: Cyclic redundancy check בכל הודעה הוא מוסיף ל Header מידע האומר לו שהחבילה הגיעה ללא שינוי והיא תקינה ואם לא בשליחה הבאה הוא מסמן לו שהחבילה הגיע לא תקינה ויש לשלחה שוב.

Urgent:

מצביע איפה נמצא המידע החשוב בSegment

Padding:

הוא תוחם את ה Header ואחראי לכך שלא יחרוג מ32Bit

Option:

מכיל מידע אופציונלי שיכול השולח לשלוח

Three Way Handshake

לחיצת היד המשולשת, הוא תצורה של תחילת השיחה בהקמת הקשר בין השולח ובין המקבל
כעת נראה את השרטוט ונוכל לראות שעל מנת להתחיל בשיחה: השולח, שולח הודעה לפתיחת הקשר, דגל SYN עם מספר הרצף של המקטע שהוא Y (מספר רנדומלי) , המקבל שולח בחזרה SYN-ACK  שהוא המספר הרנדומלי שהוא קבע נאמר 1 ומוסיף אותו ל ACK שהוא קיבל והתחיל לפתוח שיחה ואומר לו X+1 , השולח מקבל את ה ACK ושולח בחזרה שהוא קיבל את ההודעה ומודיע לו על  Y+1 וכך מתחיל הקשר בין התחנות:

three way handshake

לאחר מכן עליהם לסיים את השיחה בניהם:

המחשב Sender שולח Fin ואז המחשב Receiver מקבל אותו וכעת אחרי Receiver קיבל את ה FIN הוא שולח הודעת ACK לSender שהוא קיבל את ה Fin, כעת סיים הסתיים התקשורת בין Sender לבין Receiver אבל התקשורת חייבת להסתיים גם בין Receiver  לבין Sender ואותו תהליך מתחיל שוב Receiver  שולח הודעת Fin ל Sender ואז Sender שולח ACK שהוא קיבל את הFIN שלו וכך יוצא ש4 הודעות נשלחות 2 הודעות של כל צד שרוצה לסגור את השיחה על ידי שליחה של FIN ועוד 2 ACK של כל צד שאומר קיבלתי את ההודעת סגירה שלך

*למרות שמצוייר 3 הודעות בסרטוט למטה הכוונה הייתה של אותו קו באמצע נשלח פעמיים ACK

סגירת שיחה

UDP

User Datagram Protocol

הוא פרוטוקול להעברת נתונים באופן לא אמין, הוא לא מספק תהליך שבו הוא בודק אם המידע אמין או לא אלא מכיל בתוכו את המקור, היעד, אורך החבילה וCRC או Checksum לבדיקה שהחבילה מגיע ללא שגיאות, אך אם היא מגיע עם שגיאות הוא זורק את החבילה וממשיך הלאה. ולמה אתם שואלים צריך פרוטוקול כזה? לא אמין? השימוש שלו הוא רחב מאוד החל מתוכנות כמו Skype, תארו לכם שאתם מדברים עם משתמש בשיחה קולית והמידע שמגיע מהמשתמש חייב להגיע שלם ואמין כמו ב TCP אתם עלולים לשמוע את השיחה באיחור עצום דוגמה נוספת היא מנגנון בוירטואליזציה שקיים בסיטריקס שאומר שאם משתמש פתח חלון לשרת או מחשב (טרמינל) והוא מנסה לפתוח תיקייה אך קיימת באותו הרגע איטיות או בעיה ברשת אז הSession (השיחה) תתקע ועד שלא תקבל אישור המשתמש לא יוכל להפעיל או לגעת בחלון, אז משתמשים ב TCP בהתחלה על מנת ליצור את הקשר ואז בUDP בחלון המשתמש.

Source Port:
ברמת 16 סיביות – 16 Bits והוא מציין את המקור של החבילה
Destination Por:
ברמת 16 סיביות – 16 Bits והוא מציין את היעד של החבילה

Checksum:

הוא משתמש ב CRC לבדיקה שהמידע אינו פגום אך אם הוא פגום המידע נזרק ואינו נשלח שוב.

UDP Header