חלק 3. פרוטוקולי HTTP/HTTPS

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

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

מהו פרוטוקול העברת נתונים

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

מבנה HTTP

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

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

באמצעות פרוטוקול HTTP ניתן לשלוח בקשה לשרת (בקשה) ולקבל תגובה מהשרת (תגובה). לבקשות ולתגובות יש פרמטרים מעט שונים.

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

GET / HTTP/1.1
Host: javarush.com
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.javarush.com/images/article/155cea79-acfd-4968-9361-ad585e939b82/original.pngsend?name1=value1&name2=value2 כאן: javarush .com — מארח, /שלח — נתיב בקשה, ? - מפריד המציין כי פרמטרי הבקשה הבאים. בסוף, הפרמטרים רשומים בפורמט key=value, מופרדים באמצעות אמפרסנד. POST - מפרסם מידע בשרת. בקשת POST יכולה להעביר מידע מגוון: פרמטרים בפורמט key=value, JSON, קוד HTML, או אפילו קבצים. כל המידע מועבר בגוף ההודעה. לדוגמה:

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

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

הבקשה נשלחת אל javarush.com/user/create/json, גרסת הפרוטוקול היא HTTP/1.1. Accept מציין באיזה פורמט תגובה הלקוח מצפה לקבל, Content-Type מציין באיזה פורמט נשלח גוף ההודעה. Content-Length - מספר התווים בגוף. בקשת 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, כך שכאשר אתה רואה כתובת שמסתיימת ביציאה 80, אתה יכול להיות בטוח שיש לגשת אליה באמצעות HTTP. עם התפתחות הטכנולוגיה והתנועה הפעילה של נתונים אישיים באינטרנט, היינו צריכים לחשוב כיצד לספק הגנה נוספת למידע שהלקוח מעביר לשרת. התוצאה הייתה פרוטוקול HTTPS.

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

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

הערות

TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION