Session – הבדלי גרסאות

תוכן שנמחק תוכן שנוסף
סיום עבודה
מ סקריפט החלפות (ישו, ייחודי)
שורה 12:
 
== מימושי תוכנה ==
סשנים בפרוטוקול [[TCP]] בדרך כלל [[מימוש|ממומשים]] ברמת ה[[תוכנה]], באמצעות יצירת [[תהליך (מדעי המחשב)|תהליכים]] בנים (child processes) או על ידי שימוש בריבוי [[תהליכון|תהליכונים]] (multithreading). במקרה זה, עבור כל סשן חדש שנוצר נפתח תהליך או תהליכון חדש. סשנים בפרוטוקול [[HTTP]] בדרך כלל לא ממומשים על ידי שימוש בתהליכון עבור כל סשן, אלא על ידי שימוש ב[[בסיס נתונים]] אשר שומר מידע אודות ה[[מצב (מדעי המחשב)|מצב]] של כל סשן. היתרון בשימוש בריבוי תהליכים או תהליכונים הוא בכך שהלוגיקה של התוכנה יכולה להיות פשוטה יחסית, מכיוון שכל תהליכון הוא יישותישות בעלת היסטוריה משלה ועם [[משתנה (תכנות)|משתנים]] משלה שהיא [[כימוס|מכמסת]]. החיסרון הוא בתקורת משאבים גבוהה, ובכך שהסשן יכול לאבד במקרה של הפעלה מחדש של המערכת (ראו: [[persistence]]).
 
במקרים בהם הלקוח עשוי להתחבר לכל אחד מהשרתים ב[[אשכול מחשבים|אשכול]] (cluster) של שרתים, נוצרת בעיה מיוחדת בשימור ההמשכיות כאשר השרתים חייבים לשמור מידע אודות מצב הסשן. במקרה כזה חייבים להכווין את הלקוח לאותו השרת למשך כל זמן הקיום של הסשן, או שהשרתים חייבים להעביר את נתוני הסשנים בצד השרת באמצעות [[מערכת קבצים]] משותפת או [[בסיס נתונים]] משותף. אחרת הלקוח עשוי להתחבר מחדש לשרת שונה מזה שהתחיל איתו את הסשן, מה שיגרום לבעיות כאשר לשרת החדש אין גישה אל נתוני הסשן שנשמרו בשרת הקודם.
 
== HTTP Sessions ==
תחילה היה נחשב שגרסה 1.1 של פרוטוקול ה-[[HTTP]] מאפשרת רק בקשה ותגובה (request and response) אחת במהלך סשן HTTP יחיד. עם זאת, בשנת [[1996]] דייוויד הוסטטלר ויין יצר פתרון שעקף מגבלה זו, כך שניתן יהיה להשתמש ב-session IDs על מנת לאפשר עיבוד רב-שלבי של טרנזקציות רשת (multiple phase web transaction processing). הגרסה הראשונה של מערכת לניהול סשנים נקראה Deity ("אלוהות"). גרסה 1.1 של פרוטוקול ה-HTTP שופרה עוד יותר על ידי השלמת ה-([[Common Gateway Interface]] (CGI ובכך אפשרה שימור קל יותר של סשן רשת ותמיכה ב[[עוגייה (אינטרנט)|עוגיות]] והעלאת [[קובץ|קבצים]].
 
רוב הסשנים שנפתחים בין [[שרת-לקוח|שרת ללקוח]] מנוהלים ב[[שכבת התעבורה של מודל ה-OSI|שכבת התעבורה]] – עבור כל סשן נפתח חיבור אחד. עם זאת, כל '''שלב''' (phase) בסשן של [[תנועה (מערכות מידע)|טרנזקציית]] רשת בפרוטוקול HTTP יוצר חיבור נפרד (חיבור נפרד עבור כל זוג של בקשה-תגובה). שימור ההמשכיות בין שלבים דורש שימוש במזהה סשן (session ID). המזהה מוטבע בתוך האלמנטים <code><”…”=a href></code> ו-<code><form></code> של שפת ה-[[HTML]] ב[[דף אינטרנט דינמי|דפי אינטרנט דינמיים]], כך שהוא מועבר חזרה אל ה-[[Common Gateway Interface|CGI]] ב[[צד-שרת|צד השרת]]. לאחר מכן ה-CGI משתמש ב-session ID על מנת להבטיח את המשכיות הסשן בין שלבי הטרנזקציה. אחד היתרונות של חיבור נפרד עבור כל שלב הוא בכך שזה עובד טוב על פני חיבורים עם [[רוחב פס]] נמוך.
שורה 31:
על מנת להשיג [[אבטחת מידע]] כזאת, על השרת להצפין את נתוני הסשן לפני שליחתם אל הלקוח, ויש למנוע את השינוי של מידע זה על ידי כל גורם אחר חוץ מהשרת, גם כן באמצעות שימוש בשיטות הצפנה.
 
העברת מידע אודות המצב קדימה ואחורה בין השרת ללקוח עבור כל בקשה שנשלחת, היא פרקטית רק כאשר הגודל של העוגייה הוא קטן. למעשה, סשנים של צד הלקוח חוסכים בשטח דיסק על השרת בתמורה ל[[רוחב פס]] גדול יותר הנדרש עבור כל בקשת רשת. יתר על כן, דפדפנים מגבילים את מספר וגודל העוגיות ש[[אתר אינטרנט]] מורשה לשמור. על מנת לשפר את היעילות וכדי לאפשר שליחת כמות גדולה יותר של נתוני סשן, השרת יכול [[דחיסת נתונים|לדחוס]] את הנתונים לפני יצירת העוגייה, ואז לפרוס אותם חזרה כאשר העוגייה מוחזרת מהלקוח.
 
== HTTP session token ==
 
session token הוא מזהה יחודיייחודי הנוצר על ידי השרת ונשלח אל הלקוח לצורך זיהוי הסשן הנוכחי. הלקוח בדרך כלל שומר את ה-token ושולח אותו חזרה לשרת בצורה של [[עוגייה (אינטרנט)|עוגייה]] או כפרמטר בבקשות מסוג GET או POST של פרוטוקול HTTP. היתרון בשימוש ב-session tokens הוא בכך שהלקוח צריך לטפל רק במזהה הסשן – כל נתוני הסשן המקושרים לאותו מזהה מאוחסנים בשרת (בדרך כלל ב[[בסיס נתונים]], שללקוח אין גישה ישירה אליו).
 
דוגמאות לשמות ששפות תכנות נותנות לעוגיות שהן יוצרות: