Session
במדעי המחשב ובייחוד בתקשורת נתונים, session (סשן), ובעברית שיח[1], היא החלפת מידע אינטראקטיבית חצי-קבועה, הידועה גם כ"שיחה", "התקשרות", "דיאלוג" או "פגישה", בין שני מכשירים מתקשרים או יותר, או בין מחשב למשתמש קצה. סשן מוקם או מבוסס (established) בנקודה מסוימת בזמן, ונהרס בנקודה מאוחרת יותר. סשן תקשורת מבוסס יכול לכלול יותר ממסר אחד בכל כיוון. בדרך כלל, אבל לא תמיד, סשן הוא stateful, כלומר, לפחות אחד מהצדדים המתקשרים צריך לשמור מידע אודות ההיסטוריה של השיחה על מנת שיוכל לתקשר, וזאת בניגוד לתקשורת stateless, המורכבת מבקשות ותגובות נפרדות.
סשן תקשורת (communication session) ניתן למימוש כחלק מפרוטוקולים ושירותים בשכבת היישום, בשכבת השיחה או בשכבת התעבורה של מודל ה-OSI.
דוגמאות לסשנים בפרוטוקולי תקשורת שונים:
- סשן HTTP, המאפשר לשרת web לשייך מידע למשתמשים ספציפיים (לדוגמה, מבקר באתר אינטרנט).
- סשן Telnet להתחברות למחשב מרוחק.
- שיחת VoIP מבוססת (Session Initiation Protocol (SIP.
- סשן TCP, הנקרא גם TCP virtual circuit, חיבור TCP, או שקע TCP מבוסס.
במקרה של פרוטוקולי תעבורה שאינם מממשים שכבת סשן פורמלית (לדוגמה: UDP), או במקרים בהם זמן החיים של סשנים בשכבת השיחה הוא בדרך כלל קצר ביותר (לדוגמה: HTTP), סשנים מנוהלים על ידי תוכנה שהיא high-level יותר, באמצעות שיטות המוגדרות בנתונים המועברים עצמם. לדוגמה, העברת נתונים בפרוטוקול HTTP בין דפדפן לשרת מרוחק יכולה לכלול עוגייה (cookie) המשמשת לזיהוי מצב, כגון מזהה סשן (session ID), מידע אודות העדפות המשתמש או רמת הרשאות.
מימושי תוכנה
סשנים בפרוטוקול TCP בדרך כלל ממומשים ברמת התוכנה, באמצעות יצירת תהליכים בנים (child processes) או על ידי שימוש בריבוי תהליכונים (multithreading). במקרה זה, עבור כל סשן חדש שנוצר נפתח תהליך או תהליכון חדש. סשנים בפרוטוקול HTTP בדרך כלל לא ממומשים על ידי שימוש בתהליכון עבור כל סשן, אלא על ידי שימוש במסד נתונים אשר שומר מידע אודות המצב של כל סשן. היתרון בשימוש בריבוי תהליכים או תהליכונים הוא בכך שהלוגיקה של התוכנה יכולה להיות פשוטה יחסית, מכיוון שכל תהליכון הוא ישות בעלת היסטוריה משלה ועם משתנים משלה שהיא מכמסת. החיסרון הוא בתקורת משאבים גבוהה, ובכך שהסשן יכול לאבד במקרה של הפעלה מחדש של המערכת (ראו: persistence).
במקרים בהם הלקוח עשוי להתחבר לכל אחד מהשרתים באשכול (cluster) של שרתים, נוצרת בעיה מיוחדת בשימור ההמשכיות כאשר השרתים חייבים לשמור מידע אודות מצב הסשן. במקרה כזה חייבים להכווין את הלקוח לאותו השרת למשך כל זמן הקיום של הסשן, או שהשרתים חייבים להעביר את נתוני הסשנים בצד השרת באמצעות מערכת קבצים משותפת או מסד נתונים משותף. אחרת הלקוח עשוי להתחבר מחדש לשרת שונה מזה שהתחיל איתו את הסשן, מה שיגרום לבעיות כאשר לשרת החדש אין גישה אל נתוני הסשן שנשמרו בשרת הקודם.
HTTP Sessions
תחילה היה נחשב שגרסה 1.1 של פרוטוקול ה-HTTP מאפשרת רק בקשה ותגובה (request and response) אחת במהלך סשן HTTP יחיד. גרסה 1.1 של פרוטוקול ה-HTTP שופרה על ידי השלמת ה-(Common Gateway Interface (CGI ובכך אפשרה שימור קל יותר של סשן רשת ותמיכה בעוגיות והעלאת קבצים.
רוב הסשנים שנפתחים בין שרת ללקוח מנוהלים בשכבת התעבורה – עבור כל סשן נפתח חיבור אחד. עם זאת, כל שלב (phase) בסשן של טרנזקציית רשת בפרוטוקול HTTP יוצר חיבור נפרד (חיבור נפרד עבור כל זוג של בקשה-תגובה). שימור ההמשכיות בין שלבים דורש שימוש במזהה סשן (session ID). המזהה מוטבע בתוך האלמנטים <”…”=a href> ו-<form> של שפת ה-HTML בדפי אינטרנט דינמיים, כך שהוא מועבר חזרה אל ה-CGI בצד השרת. לאחר מכן ה-CGI משתמש ב-session ID על מנת להבטיח את המשכיות הסשן בין שלבי הטרנזקציה. אחד היתרונות של חיבור נפרד עבור כל שלב הוא בכך שזה עובד טוב על פני חיבורים עם רוחב פס נמוך.
סשנים של צד לקוח בפרוטוקול HTTP
סשנים של צד לקוח בפרוטוקול HTTP משתמשים בעוגיות (cookies) ובטכניקות הצפנה על מנת לשמור מידע אודות המצב (state), מבלי שיהיה צורך לשמור כמויות גדולות של נתונים בצד השרת. כאשר השרת מציג דף אינטרנט דינמי, הוא שולח ללקוח (הדפדפן) נתונים אודות המצב הנוכחי בצורה של עוגייה. הלקוח שומר את העוגיה בזיכרון או על הדיסק. בכל בקשה (request) עוקבת שהלקוח שולח חזרה אל השרת, הוא מצרף את העוגייה, והשרת משתמש בנתונים שבעוגייה כדי "לזכור" את המצב של היישום עבור אותו לקוח ספציפי, וכדי ליצור תגובה (response) מתאימה.
מכניזם זה עובד טוב ברוב המקרים. עם זאת, נתונים אשר מאוחסנים בצד הלקוח חשופים לשינויים זדוניים על ידי הלקוח או על ידי תוכנה שיש לה גישה למחשב הלקוח. על מנת להשתמש בסשנים בצד הלקוח במקרים בהם נדרשת סודיות ואמינות, יש להבטיח את הבאים (CIA):
- סודיות (Confidentiality): שום דבר חוץ מהשרת לא אמור להיות מסוגל לפרש את הנתונים של הסשן.
- אמינות (Integrity): שום דבר חוץ מהשרת לא אמור להיות מסוגל להכניס שינויים בנתוני הסשן (בטעות או עם כוונה זדונית).
- אותנטיות (Authenticity): שום דבר חוץ מהשרת לא אמור להיות מסוגל ליזום יצירה של סשנים חוקיים.
על מנת להשיג אבטחת מידע כזאת, ראשית על הלקוח לאמת את זהותו של השרת (נעשה לרוב על ידי הצגת Public key certificate מצד השרת), לאחר מכן על השרת להצפין את נתוני הסשן לפני שליחתם אל הלקוח, ויש למנוע את השינוי של מידע זה על ידי כל גורם אחר חוץ מהשרת, גם כן באמצעות שימוש בשיטות הצפנה.
העברת מידע אודות המצב קדימה ואחורה בין השרת ללקוח עבור כל בקשה שנשלחת, היא פרקטית רק כאשר הגודל של העוגייה הוא קטן. למעשה, סשנים של צד הלקוח חוסכים בשטח דיסק על השרת בתמורה לרוחב פס גדול יותר הנדרש עבור כל בקשת רשת. יתר על כן, דפדפנים מגבילים את מספר וגודל העוגיות שאתר אינטרנט מורשה לשמור. על מנת לשפר את היעילות וכדי לאפשר שליחת כמות גדולה יותר של נתוני סשן, השרת יכול לדחוס את הנתונים לפני יצירת העוגייה, ואז לפרוס אותם חזרה כאשר העוגייה מוחזרת מהלקוח.
HTTP session token
session token הוא מזהה ייחודי הנוצר על ידי השרת ונשלח אל הלקוח לצורך זיהוי הסשן הנוכחי. הלקוח בדרך כלל שומר את ה-token ושולח אותו חזרה לשרת בצורה של עוגייה או כפרמטר בבקשות מסוג GET או POST של פרוטוקול HTTP. היתרון בשימוש ב-session tokens הוא בכך שהלקוח צריך לטפל רק במזהה הסשן – כל נתוני הסשן המקושרים לאותו מזהה מאוחסנים בשרת (בדרך כלל במסד נתונים, שללקוח אין גישה ישירה אליו).
דוגמאות לשמות ששפות תכנות נותנות לעוגיות שהן יוצרות:
ראו גם
הערות שוליים
36317979Session