|
|
|
|
|
הקדמה
מאפייני השירות שמספק TCP
צורת הפעולה של TCP
מבנה סגמנט TCP
|
הקדמה
|
| TCP, או transmission control protocol, הוא פרוטוקול התעבורה המרכזי של משפחת פרוטוקולי האינטרנט. למעשה, פרוטוקול TCP אינו תלוי ב- IP, וניתן להשתמש בו גם ישירות מעל שכבת ממשק הרשת, אך שימושו העיקרי הוא כפרוטוקול תעבורה מעל IP.
|
|
כפי שראינו, IP מספק שירות בלתי מהימן וחסר קישור. חבילות יכולות ללכת לאיבוד, להגיע בסדר לא נכון, או להתעכב בדרך. כל זה מהווה פעמים רבות בעיה עבור שכבת האפליקציה: עבור אפליקציות רבות, חשוב מאוד שמידע לא ילך לאיבוד, שיגיע ללא עיכוב גדול, ושיגיע לפי הסדר. אפליקציות כאלה שולחות הרבה מאוד נתונים, והסיכון שמשהו ישתבש בדרך הוא גדול. TCP מאפשר לאפליקציות שמשתמשות בו להניח שהנתונים שהן שולחות יעברו ברשת ללא שיבושים.
|
| מאפייני השירות
שמספק TCP
|
| לשירות שמספק TCP יש מספר מאפיינים מרכזיים:
|
- זרם (stream) של
נתונים:
TCP מאפשר לאפליקציות להתייחס למידע שהן
שולחות ומקבלות כאל זרם רציף של ביטים (ולא כאל חבילות בדידות). TCP מעביר
לאפליקצית היעד את אותו זרם של ביטים, באותו סדר שיצא מהאפליקציה השולחת.
|
- קישור
של "מעגל וירטואלי" (virtual circuit connection):
בניגוד ל- IP,
שפועל בשיטת "שגר ושכח", צורת הפעולה של TCP דומה יותר לשיחת טלפון. לפני
שניתן להתחיל בשידור הנתונים, על המחשב היוזם "להתקשר" למחשב היעד, ומחשב
היעד חייב "לענות". רק לאחר שנותר הקשר הראשוני בין מודל ה- TCP במחשב
היוזם למודול המקביל לו במחשב היעד, ניתן להתחיל לשדר את הנתונים. גם תוך
כדי שליחת הנתונים, המודולים ממשיכים "לדבר" ביניהם, כדי לוודא שהנתונים
מגיעים כסדרם. כאשר יש נתק בתקשורת מסיבה כלשהי, שני המודולים מודעים לכך,
ומדווחים על הניתוק לאפליקציה הרלוונטית. ה"מעגל הוירטואלי" מאפשר לתוכנות
האפליקציה להתייחס לקישור שביניהן לבין האפליקציה במחשב היעד כאילו הוא
מעגל פיזי המחבר ביניהן.
|
- העברה מבוקרת
(buffered transfer):
תוכנת
האפליקציה מעבירה ל- TCP נתונים בגדלים שונים. משיקולי יעילות, נתונים אלה
נאספים במעין חוצץ (buffer), עד שיש מספיק נתונים למלא חבילה בגודל המתאים
לשליחה באינטרנט. גם בצד המקבל ישנו חוצץ, שרק כאשר הוא מתמלא מועברים
הנתונים שבו לאפליקציה. אם האפליקציה מוציאה נתונים בבלוקים גדולים מאוד,
TCP יכול לבחור לחלק את הנתונים לחבילות קטנות יותר. כיוון שהנתונים עוברים
בין האפליקציות בצורה של זרם ביטים, לאפליקציה לא משנה איך הנתונים הללו
נאספים לחבילות שמשודרות ברשת. עבור מקרה שבו אפליקציה מעונינת לשלוח
נתונים גם אם החוצץ עדיין אינו מלא, TCP מספק את מנגנון הדחיפה (push
mechanism), שמאפשר זאת. בצד המקבל, מנגנון הדחיפה מאפשר לאפליקציה לקבל
נתונים גם אם לא הצטבר שם חוצץ מלא.
|
- זרם בלתי
מובנה (unstructured stream):
TCP
אינו מגדיר את מבנה זרם הנתונים שהוא מעביר. אם, למשל, האפליקציה שולחת
נתונים של כוח אדם, TCP אינו יודע היכן נגמרים נתוניו של עובד אחד ומתחילים
נתוניו של עובד אחר. האפליקציות, ולא TCP, הן אלה שיודעות מהו מבנה הזרם.
|
- קישור דו
כיווני (דופלקס):
TCP מספק קישור
דו כיווני, כלומר מאפשר שליחת מידע בשני הכיוונים בו זמנית. שליחת מידע
בכיוון אחד יכולה להסתיים, ללא תלות בכיוון השני.
|
| צורת הפעולה של
TCP
|
| TCP מספק שירות מהימן: הנתונים מגיעים מהאפליקציה השולחת לאפליקציה המקבלת ללא שיבושים. כיוון שהשירות שמתחת ל-TCP (כלומר, IP) אינו מהימן, TCP צריך להבטיח את המהימנות בעצמו. המנגנון שמאפשר זאת הוא מנגנון של אישור קבלה ושליחה מחדש
(positive acknowledgemeny with retransmission). כאשר מחשב היעד מקבל נתונים מהמחשב השולח, הוא שולח חזרה אישור (acknowledgement, ןבקיצור ack). כאשר המחשב השולח לא מקבל אישור עבור חבילה מסוימת תוך פרק זמן קבוע מראש, הוא שולח אותה מחדש.
|
| מנגנון זה עלול לגרום לכך שחבילות ישלחו מספר פעמים - אם האישור עבור חבילה מסוימת נשלח לאחר שהיא כבר נשלחה מחדש ע"י המחשב השולח. כדי למנוע שכפול נתונים, לכל חבילה של TCP יש מספר מזהה, והמחשב המקבל זוכר את המספרים של החבילות שהתקבלו - ואם חבילה שכבר הגיעה מגיעה שוב, TCP לא יעביר את הנתונים פעמיים.
|
| TCP שולח נתונים בשיטה הנקראת "sliding window" ("החלון הנע"). במקום לשלוח חבילה, לחכות לקבל אישור ורק אז לשלוח את החבילה הבאה, TCP שולח כמות מסוימת של חבילות, הנקבעת לפי גודלו של החלון הנע, בלי לחכות לאישור קבלה עבור כל אחת. לאחר שנשלחה הכמות הזו, רק כשיתקבל אישור על קבלת החבילה הראשונה שנשלחה, תוכל להישלח עוד חבילה. ככל שהחלון גדול יותר, עד לגודל המקסימלי שהרשת מסוגלת להעביר, יש פחות בזבוז זמן, והרשת מנוצלת באופן יעיל יותר.
|
| TCP גם מספק flow control, או "שליטה בזרימה", כדי למנוע מצב בו מחשב היעד מקבל נתונים בקצב מהיר מדי, ואינו מצליח לטפל בהם, או לחילופין, מצב בו מחשב היעד מקבל נתונים בקצב איטי מדי ולא יעיל מספיק. כאשר המחשב המקבל שולח את אישור הקבלה, הוא שולח יחד איתו גם "window advertisement" - ערך המציין עוד כמה בתים של מידע הוא מוכן לקבל. אם הערך גדול יותר משהיה עד כה, המחשב השולח מגדיל את החלון הנע שלו, ושולח יותר חבילות ללא לחכות לאישור; אם הערך קטן יותר, המחשב השולח מקטין את החלון הנע שלו. מנגנון השליטה בזרימה הוא הכרחי באינטרנט, שמורכבת מרשתות וממחשבים בעלי קיבולות ויכולות שונות.
|
| כמו ב- UDP , גם ב- TCP יש פורטים (ports). אבל, בניגוד ל-UDP, שמקבל חבילות ומעביר אותן לאפליקציות אליהן הם מיועדות לפי מספר הפורט המצוין בהן, הפורטים ב- TCP משמשים להגדיר את ה"מעגל הוירטואלי" המבוסס על כתובת המקור, פורט המקור, כתובת היעד ופורט היעד. מודול TCP אחד על מחשב אחד יכול להיות מעורב בכמה מעגלים וירטואליים כאלה בבת אחת, וכמה מעגלים וירטואליים יכולים לכלול את אותו פורט עצמו. כך, אפליקציה אחת יכולה לתקשר עם כמה מחשבים מרוחקים במקביל, בלי שתצטרך לספק מספר פורט נפרד עבור כל קישור.
|
| מבנה סגמנט TCP
|
| 0....... |
8....... |
16...... |
24...... |
|
|
|
- מספר סידורי (sequence number, או בקיצור
seq):
המספר שמאפשר למודול ה- TCP במחשב המקבל לדעת אילו נתונים
הוא כבר קיבל, וכך למנוע כפילות נתונים במקרה שחבילה נשלחה פעמיים. המספר
הסידורי אינו מתייחס לחבילה, אלא למיקום של הנתונים שהתקבלו בתוך זרם
הביטים המקורי.
משיקולי אבטחת מידע, המספרים הסידוריים אינם מתחילים מ-
0, אלא ממספר רנדומלי שנקבע כאשר נוצר המעגל הוירטואלי של TCP.
|
|
|
- אורך פתיח:
אורכו של פתיח ה- TCP, בכפולות
של 4 בתים. שדה זה הוא הכרחי כיוון שאורך הפתיח אינו קבוע, ומשתנה לפי מספר
האופציות שכלולות בו.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- אופציות:
לרוב אינן בשימוש. אחת האופציות
היא אופציית "גודל סגמנט מקסימלי" (maximum segment size, MSS), המאפשרת
למודול ה- TCP לציין מהו גודל הסגמנט המקסימלי שהוא מוכן לקבל. כאשר גודל
זה הוא קטן, ניצול הרשת אינו אופטימלי: אם נניח שגודל הסגמנט המקסימלי כולל
רק בית אחד של נתונים, וכיוון שכל סגמנט כולל גם פתיח TCP ועובר
אינקפסולציה של IP ושל ממשק הרשת, יוצא שהנתונים תופסים רק כ- 1/55 מכל
התעבורה. גם כאשר גודל זה הוא גדול מדי, נוצר מצב בלתי אופטימלי: אם ה- MSS
גדול מה- MTU של הרשתות בהן עובר הסגמנט, שכבת ה- IP בדרך צריכה לבצע
פרגמנטציה. אם פרגמנט כזה הולך לאיבוד, TCP צריך לשלוח את כל הסגמנט מחדש,
ולא רק את הפרגמנט. תיאורטית, MSS אופטימלי הוא כזה שהסגמנט גדול ככל
האפשר, אך לא יצטרך לעבור פרגמנטציה בדרכו. כיוון ש-TCP אינו יכול לדעת מה
ה- MTU של כל הרשתות בהן יעבור הסגמנט, אי אפשר לדעת מהו הגודל האופטימלי.
|
|
|
 |
|
|
