"תואר החלומות" - הסערה

וואהו. אני חייב להודות שהופתעתי!

לפעמים יש פוסטים שאני מצפה שיהיו פופולריים - והם לא. לפעמים יש כאלו שאני כמעט מתנצל שאני מפרסם - והם זוכים לעניין רב. אני לא מצליח לחזות את התגובות.

את הפוסט על "תואר החלומות בהנדסת תוכנה" כתבתי עם ציפיות נמוכות: הייתה לי שעה פנויה והחלטתי "לזרוק" את המצגת שהכנתי לכנס במכללת כנרת (זה הזמן קצת לפרסם אותו) - לפוסט בבלוג ולראות מה יקרה.

גיקטיים, שיש לי הסכם איתם שמתיר להם לפרסם פוסטים שלי באתר שלהם, החליטו לפרסם את פוסט-הבוסר הזה. לא הבנתי למה.... 

מה קרה?

• כ 50 תגובות (רובן בגיקטיים)
• מעל 700 שיתופים של הפוסט (בערך פי 10 מהמספר הגבוה ביותר שאני זוכר לפוסט יחיד)
• 6 מיילים אישיים
• תגובות בעבודה
• שיחת טלפון (ממישהו שלא הכרתי)
• הרבה רגשות

שני לקחים אישיים:

1. העורך של גיקטיים מבין משהו בבחירת תכנים.
2. נגעתי בנושא טעון למדי. הייתי מנסח אותו כ: "עד כמה תואר אקדמי הוא יעיל?"

מפה לשם היו הרבה רעיונות, דעות (חלק קטן מהן נראו פשוט מקובעות: "תואר בהנדסה חייב  ל... <משהו>") ופרשנויות.
יופי! אני שמח מאוד על הדיון.

מה לקחתי מהתגובות? (לטווח המיידי - הכנס)

אני מודה לכולכם על התגובות - אני חושב שהפקתי מהן כמה המלצות משמעותיות.

אני כותב את הפוסט בתחושת מחויבות לספק כמה הבהרות: כמה רעיונות שניסיתי להעביר בצורה מסוימת פורשו ע"י רבים בצורה שונה + הצלחתי לשפר כמה רעיונות אחרים.

הנה תקציר:

• "תואר החלומות" הוא איננו תוכנית מבושלת - הוא היה אמצעי טכני להציג רעיונות (שדווקא בהם התמקדתי) בצורה מוחשית יותר. רעיונות כגון:
• התמקדות בצרכים של רוב הסטודנטים - ולא של מיעוט (לו ניתן להקדיש תואר מיוחד, נקרא לו "מדעי-המחשב")
• הכרה בכך שידע הפך זמין יותר מבעבר, וכנראה שניתן וכדאי להסתגל בהתאם ולקצר את מחזור ההשכלה (כמה זמן לוקח עד שמתחילים לעבוד).
• בחינה מחדש של הערך (value) של כל נושא שנלמד, ללא הגנות מיוחדות, וצמצום ה waste.
• מהנדסי תוכנה (שאני חוויתי) מתמודדים הרבה יותר עם בעיות ארגוניות / מערכתיות / אנושיות - מאשר עם אלגוריתמים. למה להשקיע בשני פי X יותר מבראשון? (יצירת השכלה שעונה על הצרכים המעשיים)
• כמה רעיונות טכניים שנראים לי לא אופטימליים באוניברסיטה (לימוד ה stack הטכנולוגי מהברזלים למתכנת - ולא להיפך, שמהניסיון שלי הוא כיוון יותר יעיל; התמקדות בשכבת הפשטה אחת מתחת לעבודה השוטפת - ולא שלושה, כפי שמקובל לעתים רבות וכו'...). 
• לא הייתה שום מחשבה / רמיזה על הפחתת הרמה האקדמית של החומר הנלמד. אמנם זרקתי כמה באזזים על שמות הקורסים - המטרה הייתה לחדד את משמעות הקורס.
• אכן נתתי משקל רב יותר לפיתוח ווב / מערכות מידע ממה שיש צורך (תודה לכל המגיבים). אני מניח שזו הייתה הטיה אישית שלי לנושאים שהתעסקתי בהם בתקופה האחרונה.
• אכן חתכתי את המתמטיקה לגמרי - ובהחלט אפשר לתת לה מקום של כבוד כנושא לבחירה (בכלל, תואר אקדמי הוא מנגנון עם מעט התאמה אישית לסטודנט - וזה נראה לי פספוס).

לצורך התרשמות בלבד

בדוגמה מעשית יש יתרונות וחסרונות, במיוחד כשהיא לא מלוטשת היטב.

הדרך הכי פשוטה להראות כיצד הפידבק שקיבלתי שינה, ולנסות לתקן אי-הבנות קודמות הוא בעזרת הצגת "השקף", כפי שעדכנתי אותו על המחשב שלי:

זכרו:

• זה לא מלוטש
• עכשיו אחת בלילה :)
• זו דעתי - ואני לא טוען שזו אמת מוחלטת.

"אז מה אתה מציע?"

אני מאמין שמי ש"פותח את הפה להתלונן" - אמור לבוא עם הצעה קונקטית כלשהי לפתרון. לפחות לנסות.

הנה מייל מעניין ורלוונטי שקיבלתי (פרטי השולח שמורים במערכת) - והתשובה שנתתי. ניסיתי.

שלום ליאור,

שמי מיסטר-X, ואני מתעתד להתחיל בשנה הבאה לימודים אקדמיים בתחום.

הכיוון כרגע הוא לימודי הנדסת מחשבים בבר אילן, מתוך הנחה שגם כך את רב הידע בתכנות ארכוש לבד ולמה לא לרכוש בנוסף ידע בחשמל, כמו גם מתוך שיקולי נוחות.

לאור מה שכתבת בפוסט ומהיכרותך עם השטח, היכן ומה היית ממליץ לי ללמוד? האם יש טעם בלימודי ההנדסה בכלל, או שעדיף ללמוד מדעי המחשב ולחסוך שנה? האם יש דברים שמומלץ ללמוד בעצמי תוך כדי התואר שלא כלולים בתוכנית הלימודים?

אודה לעזרתך בנושא,

מיסטר-X.

תגובתי:

היי מיסטר-X,

זו שאלה לא פשוטה. לא בגלל החומר הנלמד בתואר, אלא בגלל היוקרה של התארים האקדמיים.

תואר אקדמי יוקרתי (אוניברסיטה טובה) + ציונים גבוהים (בעיקר במקצועות המחשב) - פותחים דלתות בחברות רבות.

החלטה ללכת בלי תואר היא פחות סטנדרטית ולמרות שהיא יכולה לחסוך כמה שנים - היא יותר קשה באופן אישי (לפחות במצב הקיים).

עובד איתי בחור שלא עשה תואר, הגיע ל SAP (חברה מכובדת) על בסיס הכשרה בצבא. למרות שהוא מצוין דווקא בנושאים "אקדמיים" (תכנון, יעילות וכו') - הוא הרגיש צורך להשלים תואר בגלל "מה שהוא מפסיד שלא עשה תואר". הוא התחיל תואר השנה - ובנתיים מאוד מתבאס ממנו.

אני חושב שבמצב היום יש עדיפות לבוגרי אוניברסיטה.

אני לא רואה כמעט שום תועלת לבוגרי "הנדסת תוכנה" בקבלה לעבודה על פני "מדעי המחשב" - זה עניין אישי אם אתה מוכן להשקיע הרבה זמן בלימודי מתמטיקה לא-קלים (יש כאלו שפשוט נהנים מעיסוק במתמטיקה).

מה אני יכול להמליץ?

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

למצוא מסגרת העשרה עכשווית ש"מדליקה" אותך, כגון:

• meetups כלשהם (ניתן למצוא ב http://www.meetup.com/ או http://www.geektime.co.il/eventsboard/) - אל תחשוש להגיע כי "אתה עדיין סטודנט".
• למצוא בעל עסק קטן שישמח להשתמש בתוכנה כלשהי - ולכתוב לו אפילו במחיר זעום (הניסיון של כתיבה ללקוח אמיתי - היא מעשירה ומתגמלת יותר מכל כתיבת תוכנה "למגירה"). יכול גם מאוד לעזור בקבלה לעבודה.
• לקרוא כמה ספרי מופת בהנדסת תוכנה (גם אם יעברו על הרעיונות שהספר מבטא בתואר, הם לרוב יכוסו בצורה רדודה יחסית למקור).
• משהו אחר...

מקווה שעזרתי,

ליאור

סיכום

הנה עוד פוסט חפוז שהתחלתי לכתוב ב 12 וחצי בלילה... ואין לי מושג איך הוא יסתיים :)

תואר החלומות ב"הנדסת תוכנה"

היי,

בחודש פבואר אעביר session בכנס להוראת הנדסת התוכנה בישראל שיתקיים במכללת כנרת - כנס אקדמי מעיקרו, שמשלב גם קולות מהתעשייה.

נתבקשתי לתת לחברי סגל נכבדים מתוכניות להנדסת תוכנה / מדעי המחשב, מבט על החוויה שלנו מהתארים. כיצד אנו רואים אותם? מה טוב? מה ניתן לשפר וכו'?

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

את "תואר חלומות" זה הרכבתי בעזרת כמה עמיתים לעבודה: ראשי צוותים, ארכיטקטית ותוכניתן בכיר (תודה רחלי, גדי, נילי ואביחי). זוהי תוכנית שהיינו ממליצים למכללות / אוניברסיטאות לאמץ - בכדי לחנך מהנדסי תוכנה טובים יותר.

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

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

נושאים

חילקנו את המקצועות הנלמדים המקובלים לקבוצות: "חמים" (מעולה - המשיכו כך) ו"קרים" (הסטודנט יכול להתמקד בקבלת ציון סביר+ - הידע עצמו פחות יעזור לו).

לפני שאתם "קופצים" על מה שנאמר על קורס האלגוריתמים (נושא טעון), עברו על השקף הבא:

אנו רואים שינויים משמעותיים בעולם הידע המקצועי: שינוי שאם האוניברסיטאות / מכללות לא יפנימו, הן עלולות למצוא את עצמן הופכות מ"מיינסטרים" ל"נישה". אם פעם הדרך היחידה כמעט לרכוש ידע יסודי על רשתות תקשורת היה לעשות קורס במדעי המחשב - היום יש ספרות מקצועית רבה ואיכותית וזמינה (תוך דקה אצלי על ה iPad), קורסים מעולים בוידאו, בתשלום או ברשת בחינם, או סתם גיגול ל StackOverflow שיפתור לי את הבעיה באופן רגעי ואלמד משם טיפה אחר טיפה.

לגבי האלגוריתמים והמתמטיקה: אנו מאמינים שזהו נושא חשוב לאלגוריתמאים / חוקרים, שמהווים לא יותר מ5% מסך אנשי התוכנה. לשאר אנשי התוכנה - אין שימוש ממשי בידע זה. גם ידע מתמטי עמוק, כדרך אגב, ניתן כיום להשלים מהבית בעזרת Coursera / iTunesU ואחרים.

התוכנית

כמו כל "קביעה" - ברגע שהיא ספציפית תהיה דעתנות רבה על פרטים רבים. אשמח אם תוכלו להתייחס לתמונה זו כנקודה למחשבה ולא כ"קביעה עובדתית" כזו או אחרת.

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

התמונה הגדולה של התוכנית

הנה כמה רעיונות שרציתי להעביר:

איפה שנה ג'? אנו מאמינים שלמידה היום יכולה להיות קצרה יותר. עדיף ללמוד מעט - ואז להתחיל לעבוד, מאשר לשבת שלוש-ארבע שנים ורק ללמוד. יותר Agile ופחות Waterfall. השלמות ותוספות יתרחשו מעצמן תוך כדי העבודה ואם ממש רוצים - אולי כתואר שני (של שנה?). חשוב שהבוגר יקבל בסיס ומיומנויות למידה, אבל זה יהיה בזבוז (waste) להמשיך ולתת לו עוד ידע, בלי שברור שהוא זקוק לו.

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

Domain Knowledge הוא ידע יקר ערך שאוניברסיטה לא תוכל לספק, אבל היא כנראה יכולה לתת הצצה אליו - ולפתוח צוהר לסטודנטים ללמוד אותו. ב Domain Knowledge אני מדבר על ההיבטים שתוכנה לגופי IT שונה מתוכנה לחברות של תשתיות או רפואה, ביטוח או פיננסים. זה להבין בגדול כיצד ה"ביזנס" שעבורו אנו כותבים מערכות עובד, אלו צרכים מיוחדים יש לו (לפעמים בעקבות רגולציה) וכיצד מתנהלים ארגונים שעוסקים בתחומים אלו? מה מטריד ומעסיק אותן? אלו Patterns של תוכנה מקובלים להתמודד עם הבעיות הללו?

לדוגמה:

• בשוק החשבונאי חשוב דיוק מלא בכל הנוגע לכסף. אסור לחלק מיליון דולר ל 7 חלקים - ולאבד סנט אחד, בגלל עיגולים שעשה המחשב.
• בשוק הביטוח כדאי להבין את כל ההסכמים של ביטוח ההדדי בין חברות - וכיצד עסקי הביטוח עובדים.
• בשוק הרפואי יש רגולציות רבות יש אבטחת מידע רפואי פרטי. יש הרים של מידע ומינוחים שונים רבים לאותו הדבר - שיש להתמודדד איתם וכו'....

אם יש ידע שעדיין לא ניתן לקנות ספר טוב ללמוד אותו ממנו, או שאין קורסים באינטרנט ותשובות ב StackOverflow לגביו -  זהו כנראה ה Domain Knowledge - ומשתלם מאוד ללמוד אותו, בתחום בו אתם עוסקים.

שבירת הסדר בין "יסודות" ל "ידע מעשי" - באוניברסיטה מקפידים על סדר של bottom up, מלמדים שכבה אחר שכבה. למשל: לומדים את מבנה המחשב, לפני שלומדים מערכות הפעלה. לומדים ממשק משתמש (UX) רק אחרי שלומדים לפתח UI - וכו'.

הבעיה היא ש:

1. התוכנית מתארכת - ולא מגיעים כמעט ל"תוכן משמעותי" לפני שנה שנייה.
2. מנסיוני האישי - לעתים יותר קל להתחיל בכתיבת תוכנה, ורק מאוחר יותר להעמיק ב"יסודות" כיצד דברים עובדים.

נקודה זו היא פחות חד-משמעית, אך עדיין נראה שש כאן עקרון שכדאי לשקול מחדש.

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

סיכום

סיכמתי את המצגת שלי לפוסט. אני מקווה שהיה מעניין ואני מקווה לקבל מכם פידבק ולקבל תגובות.
אותי אישית, נושא התואר ותרומתו העסיקה לאורך השנים - העסיקה לא מעט.

HTTPS חלק ג': שיקולים ליישום באפליקציה

בפוסטים הקודמים עסקנו בסקירה כללית על HTTPS ובחינה עמוקה יחסית של מנגנון אימות הזהות. בחלק זה, אחרון בסדרה, ארכז כמה נושאים שלא כיסיתי בפוסטים הקודמים - אך עדיין נראים לי חשובים ורלוונטיים.

הנושאים מאורגנים בתפזורת, ללא חשיבות מיוחדת לסדר.

Default Port שונה

בניגוד ל HTTP בו פורט (port) ברירת המחדל הוא 80, ב HTTPS, פורט ברירת המחדל הוא 443. כלומר: אם ב URL של HTTPS לא צויין port - אזי מדובר בפורט 443.



Overhead

כפי שציינתי בפוסט הראשון בסדרה, ל TLS ,בסה"כ, אין תקורה משמעותית:

• כ 6% יותר נתונים עוברים ברשת (Headers נוספים וחתימה דיגיטלית מוסיפים, TLS דוחס את ה HTTP headers - מה שקצת חוסך).
• שרת מודרני, משקיע כ 2.5ms זמן CPU לצורך TLS handshake של מפתח א-סימטרי ארוך (2K) - לא זמן משמעותי. בעבר היה מקובל להוציא את משימת ה TLS handshake לחומרה חיצונית (Load Balancer או CDN) שעשתה עבודה זו בעלות נמוכה יותר - אך נראה שמגמה זו פוחתת.
• עבודת ה CPU בצד הלקוח היא לא משמעותית, אולי מלבד מכשירי מובייל (?!)

הנקודה היחידה בה יש הבדל ביצועים משמעותי בין HTTP ל HTTPS הוא יצירת ה connection ההתחלתי.

בפוסט הקודם הסברתי על מנגנון שנקרא Session Ticket שפוטר מהצורך שלנו לבצע TLS handshake לכל connection, כך שבסך הכל אנו יכולים לצפות ל 2 roundtrips נוספים לכל origin איתו אנו יוצרים קשר.

האמנם?

מקור: הבלוג של איליה גריגוריק. שווה לעקוב.

פעמים רבות תתקלו ב TLS שהעלות שלו גדולה מ"התאוריה".

הנה, בתרשים למעלה, רואים גישה לאותו המשאב ב HTTP (שורה עליונה) מול HTTPS (שורה תחתונה), בהינתן RTT של כ 380ms.
ע"פ התאוריה, ניתן לצפון לעלות נוספת של 760ms (פעמיים 380ms) בביצוע TLS handshake, אבל הנה בדוגמה למעלה, ההפרש בפועל הוא כמעט 2000ms, כמעט פי 3 (!) ממה שציפינו.

בפוסט מעניין ויפה איליה גריגוריק מראה כיצד הוא מנתח ומתקן את המצב המתואר לעיל. הוא מזהה, ומתקן, "באפר" (congestion window) שקונפג בשרת בצורה שלא מטיבה עם ה TLS Handshake ואז הוא מוסיף עוד אופטימיזציה של TLS בכדי לצמצם את התקורה ל roundtrip בודד. סה"כ 2000ms הופכים ל 380ms - שיפור מרשים מאוד!
לא צריך להכיר את nginx (השרת המדובר) בכדי לקרוא את הפוסט.

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

עוד גורם שיכול לעכב קריאות HTTPS הוא הפעלה של פרוטוקול בשם Online Certificate Status Protocol (בקיצור: OCSP). זהו פרוטוקול המגביר את אמינות וידוא הזהות של HTTPS - במחיר ביצועים. ע"פ הפרוטוקול, כאשר הדפדפן מקבל Certificate הוא פונה ל CA שהנפיק אותו ומבקש לוודא שה Certificate עדיין תקף. סיבה ש Certificate לא יהיה תקף הוא אם המפתח הפרטי שהיה בשימוש ליצירת ה Certificate נגנב איכשהו, או שהתגלה שבעל ה Certificate הוא מתחזה / פועל בצורה לא כשרה. בחלק ב' של הפוסט שעסק ב Certificates לא כיסיתי את נושא ביטול (revocation) של Certificates - מפאת חוסר מקום / עניין נמוך לקורא.
אם המשתמשים שלכם מפעילים OCSP - אתם יכולים לבדוק את ה CA שלכם, עד כמה הוא מהיר בתגובות שלו לבקשת OCSP באזורים הגאוגרפים הרלוונטיים עבורכם. במידת הצורך, ניתן להחליף CA באחד זמין / מהיר יותר.

שווה לציין ששירותי (CDN (Content Delivery Networks, יכולים לקצר את זמני ה TLS handshake. ל CDNs יש תחנות הקרובות גאוגרפית למשתמש הקצה (ולכן יש להן latency נמוך יותר). משתמש הקצה מבצע TLS handshake מול התחנה הקרובה, של ה CDN, בה כל round-trip הוא זול יותר. מרגע שנוצר ה connection התחנה משתמשת כפרוקסי (מאובטח) לשרת שלכם (על גבי connection מאובטח שנפתח מבעוד מועד) או סתם מעבירה לכם TLS Session Ticket שאתו תוכלו לעבוד. ייתכן ובכלל התוכן זמין על cache של ה CDN ואין טעם להגיע בכלל לשרת היעד.
שירות זה נקרא TLS Early Termination, כאשר הכוונה במילה Termination היא "קיצור המסלול" ולא "סיום התקשורת".
שירות זה, עולה כסף - כמובן, ולא תמיד הוא זמין בכל אתר (או Point of Presence, בקיצור PoP) בה ה CDN פעיל.

משתמש הנמצא באירופה יכול לחסוך כחצי מזמן ה TLS handshake אם הוא מבצע אותו מול תחנה בחוף המזרחי, שרק לאחר מכן מעבירה את התעבורה לחוף המערבי (שם נמצא שרת היעד).

Connection Termination

מתי שהוא, סיימנו את העבודה המאובטחת מול השרת, ואנו רוצים לסיים את תקשורת ה HTTPS.
דרך מחשבה אחת אומרת כך: "HTTPS חי על גבי TCP, לכן פשוט אפשר לסיים את connection ה TCP בעזרת הודעת TCP FIN - ולסיים עניין".
אולם, הודעת TCP FIN יכולה בעצם להישלח ע"י כל אחד, גם תוקף פוטנציאלי המנסה לשבש את התקשורת. לצורך כך נקבע שתקשורת TLS תסתיים ע"י הודעה ברמת ה TLS (הדלקת flag בשם close_notify) ורק לאחר מכן TCP FIN.

לא לבלבל נושא זה עם Early Termination.



הימנעות מ Mixed Content

אם אתם זוכרים את הפוסט הקודם, נרצה להימנע באתר שלנו מ mixed content: תוכן HTTP בתוך דף HTTPS.
כיצד עושים זאת?
הרבה פעמים ראיתי שפשוט כותבים קוד דומה לזה:

var url = location.url.startsWith('https')) ? HTTPS_URL : HTTP_URL 

זה עובד, אבל זה מעט מסורבל. ניתן פשוט לכתוב url יחסי יחיד שלא מגדיר פרוטוקול - והוא ישתמש, בהגדרה, בפרוטוקול של הדף, יהיה זה HTTP או HTTPS. למשל:

var url = "//myserver/resources/style.css";

זה נראה קצת מוזר, אבל זה תקני לחלוטין. ניתן למצוא עוד פרטים על URL יחסי בפוסט שלי על URLs.
מעניין לציין ששירותים שונים (למשל Google Libraries API) מגישים לנוחיותכם את אותם המשאבים גם על גבי HTTP וגם על גבי HTTPS - וממליצים פשוט להשתמש בסכמה שתארתי.

כדאי לציין שחלק משירותי האירוח יציעו לינק HTTPS כברירת מחדל (כדי להבטיח שקיבלתם מהם אכן את הקובץ שביקשתם, ולא ממתחזה). HTTPS בתוך HTTP לא יוצר בעיית "Mixed Content" - אך הוא פוגע בביצועים של הדף (כפי שצוין למעלה בפוסט).

HTTPS כפרוטוקול "VPN"

למרות ש HTTPS הוא לא פרוטוקול VPN, יש לו יתרון שהוא "עובר מסך" אצל firewalls ורכיבי רשת שונים בקלות יחסית:
"אם הצלחת ליצור קשר על גבי TLS עם השרת שלי - אני סומך עליך. אפילו שאין לי מושג (או יכולת לדעת) מה אתם מדברים ביניכם" אומר ה Firewall או ה Transparent Proxy לעצמו.

לאחר שה TLS Connection נוצר הוא מוצפן - ולכן הוא שקול לפרוטוקול בינרי, low level, בין הצדדים. לדוגמה: ניתן להפוך את כיוון התקשורת, להעביר מידע בינרי, להעביר הודעות בחלקים לא מסודרים וכו'. סוג של "TCP על גבי HTTPS" (ה HTTPS משמש בעיקר ל handshake, אח"כ ניתן לרדת חזרה לרמת ה TLS היותר בסיסית).

תכונה זו של HTTPS בשימוש ע"י רכיבים של Content Delivery Networks, תקשורת בין Cloud למערכת ארגונית, ופרוטוקולים כגון SPDY (שהופך להיות HTTP 2.0) ו Web Sockets.



קצרים

• האם זה נכון שהדפדפן לא עושה Caching לתוכן HTTPS?
  לא. לכו בדפדפן ל about:cache לראות בעצמכם. אפשר בעזרת HTTP Headers מתאימים להגביל את ה Cache ואת אופן השמירה שלו ע"י הדפדפן / ה CDN.
• האם רכישת Certificate הוא דבר יקר? אלפי דולרים בשנה?
  תלוי בסוג ובמקור ה Certificate, אבל זה יכול להיות גם עשרות דולרים בשנה.
• האם זה נכון ש HTTPS מונע Virtual Hosting (לארח כמה אתרים עם Hostnames שונים על אותו שרת פיסי)?
  לא. עקרונית יש בעייה, אבל פותרים אותה בעזרת הרחבה ל TLS בשם Server Name Indication (בקיצור SNI). אולי יש פתרונות נוספים.
• האם HTTPS מבטיח פרטיות למשתמש הקצה?
  נו, אתם אמורים לענות על זה לבד בשלב זה: הוא מגן מפני sniffing ברשת, או בפני התחזות (phishing) - אבל אין לו קשר לאיזה מידע השרת שומר עליכם, כיצד הוא מגן על מידע זה או מה הוא עושה אותו (אולי הוא מפרסם אותו לכולם בגוגל על גבי HTTP ...?)

סיכום

זה לא היה בדיוק פוסט סטנדרטי, אלא רשימת השלמות על נושא ה HTTPS מפוסטים קודמים.
מן הסתם לא כיסינו את כל מה שיש לומר על HTTPS, אבל אני חושב שכיסינו את רוב הנושאים הנפוצים - וסיפקנו מספיק מידע לבנות תמונה לא רעה על מהות הפרוטוקול והיתרונות / חסרונות ביישום שלו.

שיהיה בהצלחה!


----

לינקים רלוונטים:

• ניתוח מעמיק, על גבי wireshark, של שלבי פרוטוקול ה TLS בהבאת byte ראשון לדפדפן.
• TLS Deployment Best Practices
• The fundamentals of TLS