חלק 3. HTTP/HTTPS

חומר זה הוא חלק מסדרת "מבוא לפיתוח ארגוני". מאמרים קודמים:

היי! היום נלמד על פרוטוקולי HTTP ו-HTTPS. אבל ראשית, בואו נבהיר נקודה אחת: אנחנו מדברים על פרוטוקולים לשליחת נתונים ברשת ברמת האפליקציה של מודל ה-OSI. אתם אולי זוכרים שהכרנו את דגם ה-OSI באחד המאמרים הקודמים. אם אתה לא זוכר את זה, הנה זה .

מהו פרוטוקול תקשורת נתונים?

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

המבנה של HTTP

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

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

פרוטוקול HTTP משמש לשליחת בקשות לשרת ולקבלת תגובות מהשרת. הפרמטרים של הבקשות והתגובות מעט שונות.

כך נראית בקשת HTTP פשוטה:

GET / HTTP/1.1
Host: codegym.cc
User-Agent: firefox/5.0 (Linux; Debian 5.0.8; en-US; rv:1.8.1.7)

קו ההתחלה מציין:

GET — שיטת הבקשה
/ — נתיב הבקשה
HTTP/1.1 - גרסת הפרוטוקול

ואז באות הכותרות:

מארח — המארח שאליו מופנית הבקשה
User-Agent - הלקוח ששולח את הבקשה

גוף ההודעה חסר. בבקשת HTTP, רק שורת ההתחלה והכותרת "מארח" נדרשות. עכשיו בואו נסתכל על הכל צעד אחד בכל פעם. בקשת HTTP חייבת להכיל שיטה כלשהי. יש תשעה מהם: GET, POST, PUT, OPTIONS, HEAD, PATCH, DELETE, TRACE, CONNECT. הנפוצים ביותר הם GET ו-POST. שתי השיטות הללו יספיקו בהתחלה. GET - שיטה זו מבקשת תוכן מהשרת. בהתאם, לבקשות בשיטת GET אין גוף הודעה. אבל אם אתה צריך, אתה יכול להעביר פרמטרים דרך הנתיב (בקו ההתחלה) בפורמט הבא:


https://cdn.codegym.cc/images/article/155cea79-acfd-4968-9361-ad585e939b82/original.pngsend?name1=value1&name2=value2

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

POST /user/create/json HTTP/1.1
Accept: application/json
Content-Type: application/json
Content-Length: 28
Host: codegym.cc

{
  "Id": 12345,
  "User": "John"
}

הבקשה נשלחת אל codegym.cc/user/create/json, וגרסת הפרוטוקול היא HTTP/1.1. "קבל" מציין את פורמט התגובה שהלקוח מצפה לקבל. "סוג תוכן" מציין את הפורמט של גוף ההודעה שנשלח בבקשה. "תוכן-אורך" הוא מספר התווים בגוף. בקשת HTTP יכולה להכיל הרבה כותרות שונות. למידע נוסף, עיין במפרט של הפרוטוקול .

תגובות HTTP

לאחר קבלת בקשה, השרת מעבד אותה ושולח תגובה ללקוח:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 98

<html>
  <head>
    <title>An Example Page</title>
  </head>
  <body>
    <p>Hello World</p>
  </body>
</html>

שורת ההתחלה של התגובה מכילה את גרסת הפרוטוקול (HTTP/1.1), קוד המצב (200) ותיאור המצב (אישור). הכותרות שלו כוללות את סוג ואורך התוכן. גוף התגובה מכיל קוד HTML שהדפדפן מעבד כדף HTML.

קודי מצב תגובה

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

1xx - מידע. הבקשה התקבלה. השרת מוכן להמשך.
2xx - מוצלח. הבקשה התקבלה, הובנה וטופלה.
3xx - הפנייה מחדש. יש לבצע פעולות נוספות לעיבוד הבקשה.
4xx - שגיאת לקוח. הבקשה מכילה שגיאות או שאינה תואמת את הפרוטוקול.
5xx - שגיאת שרת. הבקשה הורכבה כהלכה, אך השרת לא הצליח לעבד אותה.

הספרה השנייה והשלישית בקוד מציינת תגובה ספציפית יותר. לדוגמה:

200 בסדר - הבקשה התקבלה ועובדה בהצלחה.
201 נוצר - הבקשה התקבלה ועובדה בהצלחה, וכתוצאה מכך נוצר משאב או מופע חדש.
301 הועבר לצמיתות - המשאב המבוקש הועבר לצמיתות. פניות עוקבות אליו צריכות להיות באמצעות הכתובת החדשה.
307 הפניה זמנית - המשאב הועבר באופן זמני. לעת עתה, ניתן לגשת אליו באמצעות העברה אוטומטית.
403 אסור - הבקשה הובנה, אך נדרש אישור.
404 לא נמצא - השרת לא מצא את המשאב בכתובת זו.
501 לא מיושם - השרת אינו תומך בפונקציונליות הנדרשת כדי להגיב לבקשה.
505 גירסת HTTP לא נתמכת — השרת אינו תומך בגרסה שצוינה של פרוטוקול ה-HTTP.

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

ההבדל בין HTTPS ל-HTTP

מבחינת תחביר, HTTPS זהה לפרוטוקול HTTP. כלומר, הוא משתמש באותן שורות התחלה וכותרות. ההבדלים היחידים הם הצפנה נוספת ויציאת ברירת המחדל (443) . HTTPS מוצפן בין HTTP ו-TCP, כלומר בין שכבות האפליקציה וההובלה. אם שכחת מה זה אומר, עיין במאמר על מודל OSI . תקן ההצפנה של היום הוא TLS. לא ניכנס לנושא הזה יותר מדי, אבל זכרו שההצפנה מתרחשת לפני שמידע מגיע לשכבת התחבורה . ב-HTTPS, כל המידע מוצפן לחלוטין, מלבד המארח והיציאה שאליהם נשלחת הבקשה. החלפת שרת לשימוש בפרוטוקול HTTPS במקום HTTP אינה מצריכה שימוש לשינוי קוד השרת. תכונה זו מופעלת במיכלי servlet, עליהם נדון במאמרים הבאים. וזה הכל להיום. בעצם, חכה רגע. כדי לשים יד על כמה בקשות HTTP, פתח את Google Chrome, הקש F12 ובחר בכרטיסייה "רשת". כל הבקשות והתגובות שנשלחו/התקבלו על ידי הדפדפן שלך יוצגו כאן. חלק 4. היסודות של Maven Part 5. Servlets ו-Java Servlet API. כתיבת יישום אינטרנט פשוט חלק 6. מיכלי Servlet חלק 7. היכרות עם תבנית MVC (Model-View-Controller)