Bahagi 3. Mga protocol ng HTTP/HTTPS

Ang materyal na ito ay bahagi ng seryeng "Introduction to Enterprise Development". Mga nakaraang artikulo:

• tungkol sa network ;
• tungkol sa arkitektura ng software .

Kamusta! Ngayon ay mauunawaan natin ang mga protocol ng HTTP at HTTPS. Ngunit una, linawin natin ang isang punto: pinag-uusapan natin ang tungkol sa mga protocol ng paglilipat ng data sa network sa layer ng aplikasyon ng modelo ng OSI. Tulad ng naaalala mo, tinalakay namin ang modelo ng OSI sa isa sa mga nakaraang artikulo. At kung hindi mo maalala, narito ito .

Ano ang data transfer protocol

Ito ang pangalang ibinigay sa pangkalahatang tinatanggap na kasunduan, salamat sa kung saan ang mga developer ng iba't ibang serbisyo ay nagpapadala ng impormasyon sa isang solong form. Halimbawa, gamit ang Google Chrome, maaari kang makakuha ng impormasyon mula sa Facebook at Twitter, dahil ipinapadala ito ng mga developer gamit ang karaniwang HTTP protocol, at maaaring iproseso ito ng iyong browser. Ang mga pare-parehong panuntunan ay napaka-maginhawa para sa mga developer mismo ng server-side: maraming mga library na maaaring mag-convert ng impormasyon para sa iyo at ipadala ito gamit ang kinakailangang protocol. Ang HTTP ay orihinal na naisip bilang isang protocol para sa paglilipat ng mga pahina ng HTML. Ito ang kaso sa loob ng mahabang panahon, ngunit ngayon ay madalas na inililipat ng mga programmer ang parehong mga string at media file sa ibabaw nito. Sa pangkalahatan, ang protocol na ito ay maraming nalalaman at nababaluktot, at ito ay talagang madaling gamitin. Ngayon alamin natin kung paano ito gagawin.

istraktura ng HTTP

Kaagad na dapat tandaan na ang HTTP protocol ay binubuo lamang ng teksto. Well, kami ay pinaka-interesado sa istraktura kung saan matatagpuan ang tekstong ito. Ang bawat mensahe ay binubuo ng tatlong bahagi:

1. Panimulang linya—tumutukoy sa data ng serbisyo.
2. Mga header - paglalarawan ng mga parameter ng mensahe.
3. Katawan ng mensahe (Katawan) - data ng mensahe. Dapat na ihiwalay sa mga heading ng isang blangkong linya.

Gamit ang HTTP protocol, maaari kang magpadala ng kahilingan sa server (kahilingan) at makatanggap ng tugon mula sa server (tugon). Ang mga kahilingan at tugon ay may bahagyang magkaibang mga parameter.

Ano ang hitsura ng isang simpleng kahilingan sa 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)

Ang panimulang linya ay naglalaman ng:

• GET - paraan ng kahilingan;
• / — humiling ng landas (path);
• HTTP/1.1 - bersyon ng data transfer protocol.

Pagkatapos ay dumating ang mga pamagat:

• Host — ang host kung saan tinutugunan ang kahilingan;
• Ang User-Agent ay ang kliyenteng nagpapadala ng kahilingan.

Walang katawan ng mensahe. Sa isang kahilingan sa HTTP, tanging ang panimulang linya at ang header ng Host ang kinakailangan. Ngayon tingnan natin ang lahat sa pagkakasunud-sunod. Ang isang kahilingan sa HTTP ay dapat maglaman ng ilang paraan. May siyam sa mga ito sa kabuuan: GET, POST, PUT, OPTIONS, HEAD, PATCH, DELETE, TRACE, CONNECT. Ang pinakakaraniwan ay GET at POST. Ang dalawang pamamaraan na ito ay magiging sapat sa simula. GET - humihiling ng nilalaman mula sa server. Samakatuwid, ang mga kahilingan na may pamamaraang GET ay walang katawan ng mensahe. Ngunit kung kinakailangan, maaari kang magpadala ng mga parameter sa pamamagitan ng path sa format na ito: https://cdn.javarush.com/images/article/155cea79-acfd-4968-9361-ad585e939b82/original.pngsend?name1=value1&name2=value2 Dito: javarush .com — host, /send — humiling ng landas, ? — isang separator na nagsasaad na sumusunod ang mga parameter ng kahilingan. Sa dulo, ang mga parameter ay nakalista sa key=value format, na pinaghihiwalay ng isang ampersand. POST - nag-publish ng impormasyon sa server. Ang isang kahilingan sa POST ay maaaring maglipat ng iba't ibang impormasyon: mga parameter sa key=value format, JSON, HTML code, o kahit na mga file. Ang lahat ng impormasyon ay ipinadala sa katawan ng mensahe. Halimbawa:

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

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

Ang kahilingan ay ipinadala sa javarush.com/user/create/json, ang bersyon ng protocol ay HTTP/1.1. Tinutukoy ng Accept kung anong format ng tugon ang inaasahan na matatanggap ng kliyente, ang Uri ng Nilalaman ay tumutukoy kung anong format ang ipinadala sa katawan ng mensahe. Content-Length - ang bilang ng mga character sa katawan. Ang isang kahilingan sa HTTP ay maaaring maglaman ng maraming iba't ibang mga header. Higit pang mga detalye ay matatagpuan sa detalye ng protocol .

Mga tugon sa HTTP

Pagkatapos matanggap ang kahilingan, pinoproseso ito ng server at nagpapadala ng tugon sa kliyente:

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>

Ang panimulang linya sa tugon ay naglalaman ng bersyon ng protocol (HTTP/1.1), Status Code (200), Status Description (OK). Ang mga heading ay nagpapahiwatig ng uri at haba ng nilalaman. Ang katawan ng tugon ay naglalaman ng HTML code na dadalhin ng browser sa HTML page.

Mga Code ng Status ng Tugon

Malinaw ang lahat sa katawan ng mensahe at mga header, ngunit sulit na magsabi ng ilang salita tungkol sa mga status code. Ang Mga Code ng Status ng Tugon ay palaging tatlong digit, at ang unang digit ng code ay nagpapahiwatig ng kategorya ng tugon:

• 1xx - impormasyon. Ang kahilingan ay natanggap, ang server ay handa nang magpatuloy;
• 2xx - matagumpay. Ang kahilingan ay natanggap, naunawaan at naproseso;
• 3xx - pag-redirect. Ang mga sumusunod na hakbang ay dapat gawin upang maproseso ang kahilingan;
• 4xx - error sa kliyente. Ang kahilingan ay naglalaman ng mga error o hindi sumusunod sa protocol;
• 5xx - error sa server. Hindi nagawang iproseso ng server ang kahilingan, bagama't ito ay nabuo nang tama;

Ang pangalawa at pangatlong digit sa code ay nagdedetalye ng sagot. Halimbawa:

• 200 OK — ang kahilingan ay natanggap at matagumpay na naproseso;
• 201 Nilikha — ang kahilingan ay natanggap at matagumpay na naproseso, na nagreresulta sa paglikha ng isang bagong mapagkukunan o halimbawa nito;
• 301 Permanenteng Inilipat - ang hiniling na mapagkukunan ay inilipat nang permanente, at ang mga kasunod na kahilingan dito ay dapat mangyari sa bagong address;
• 307 Temporary Redirect - pansamantalang inilipat ang mapagkukunan. Sa ngayon, maa-access mo ito gamit ang awtomatikong pag-redirect;
• 403 Ipinagbabawal - malinaw ang kahilingan, ngunit kailangan ang awtorisasyon;
• 404 Not Found - hindi nahanap ng server ang mapagkukunan sa address na ito;
• 501 Not Implemented - hindi sinusuportahan ng server ang functionality na tumugon sa kahilingang ito;
• 505 HTTP Version Not Supported - hindi sinusuportahan ng server ang tinukoy na bersyon ng HTTP protocol.

Bilang karagdagan sa code ng status ng tugon, ipinapadala rin ang paglalarawan ng status, na ginagawang madaling maunawaan kung ano ang ibig sabihin ng isang partikular na status. Napakapraktikal ng HTTP protocol: nagbibigay ito ng malaking bilang ng mga header, kung saan maaari kang mag-set up ng flexible na komunikasyon sa pagitan ng client at ng server. Ang lahat ng mga header ng kahilingan at tugon, mga paraan ng kahilingan at mga code ng status ng tugon ay hindi maaaring isaalang-alang sa isang artikulo. Kung kinakailangan, maaari mong basahin ang opisyal na detalye ng protocol , na naglalarawan sa lahat ng mga nuances. Ang HTTP protocol ay karaniwang ginagamit sa port 80, kaya kapag nakakita ka ng isang address na nagtatapos sa port 80, maaari mong tiyakin na dapat itong ma-access sa pamamagitan ng HTTP. Sa pag-unlad ng teknolohiya at aktibong paggalaw ng personal na data sa Internet, kailangan naming isipin kung paano magbigay ng karagdagang proteksyon para sa impormasyong ipinapadala ng kliyente sa server. Ang resulta ay ang HTTPS protocol.

Ano ang pagkakaiba sa pagitan ng HTTPS at HTTP

Ang HTTPS ay syntactically magkapareho sa HTTP protocol, iyon ay, gumagamit ito ng parehong mga panimulang linya at header. Ang tanging pagkakaiba ay karagdagang pag-encrypt at ang default na port (443) . Ang HTTPS ay naka-encrypt sa pagitan ng HTTP at TCP, iyon ay, sa pagitan ng application at transport layer. Kung nakalimutan mo kung ano ito, tingnan ang artikulo tungkol sa modelo ng OSI . Ang modernong pamantayan sa pag-encrypt ay TLS. Hindi kami tatalakay sa paksang ito, ngunit tandaan na nangyayari ang pag-encrypt bago makarating ang impormasyon sa layer ng transportasyon . Ganap na ini-encrypt ng HTTPS ang lahat ng impormasyon maliban sa host at port kung saan ipinadala ang kahilingan. Upang ilipat ang server upang gamitin ang HTTPS protocol sa halip na HTTP, hindi namin kailangang baguhin ang server code. Ang tampok na ito ay pinagana sa mga lalagyan ng servlet, na pag-uusapan natin sa mga sumusunod na artikulo. Yan lamang para sa araw na ito. Pero sandali lang. Upang maramdaman ang mga kahilingan sa HTTP, buksan ang Google Chrome, pindutin ang F12, piliin ang tab na Network. Lahat ng mga kahilingan at tugon na ipinadala/natanggap ng iyong browser ay ipapakita dito. Part 4. Maven Basics Part 5. Servlets. Pagsusulat ng simpleng web application Part 6. Servlet container Part 7. Introducing the MVC (Model-View-Controller) pattern Part 8. Pagsusulat ng maliit na spring-boot application