Ang materyal na ito ay bahagi ng seryeng "Introduction to Enterprise Development". Mga nakaraang artikulo: Bahagi 3. HTTP/HTTPS - 1Hi! Ngayon, matututunan natin ang tungkol sa mga protocol ng HTTP at HTTPS. Ngunit una, linawin natin ang isang punto: pinag-uusapan natin ang tungkol sa mga protocol para sa pagpapadala ng data sa isang network sa antas ng aplikasyon ng modelong OSI. Maaari mong maalala na nakilala namin ang modelo ng OSI sa isa sa mga nakaraang artikulo. Kung hindi mo naaalala iyon, narito ito .

Ano ang isang data communication protocol?

Ito ang tinatawag naming napagkasunduang hanay ng mga panuntunan na nagpapahintulot sa mga developer ng iba't ibang serbisyo na magpadala ng impormasyon sa isang format na mauunawaan ng iba. Halimbawa, maaari mong gamitin ang Google Chrome upang makakuha ng impormasyon mula sa parehong Facebook at Twitter, dahil ipinapadala ito ng mga developer gamit ang karaniwang HTTP protocol, na nagpapahintulot sa iyong browser na iproseso ito. Ang mga pare-parehong panuntunan ay napaka-maginhawa para sa mga taong bumubuo ng bahagi ng server: maraming mga aklatan na maaaring mag-convert ng impormasyon para sa iyo at ipadala ito gamit ang naaangkop na protocol. Ang HTTP ay unang naisip bilang isang protocol para sa pagpapadala ng mga pahina ng HTML. Iyan ang paraan na ginamit ito sa mahabang panahon, ngunit ngayon ay madalas itong ginagamit ng mga programmer upang magpadala ng parehong mga string at media file. Sa pangkalahatan, ang protocol na ito ay pangkalahatang tinatanggap at maraming nalalaman, at ito ay talagang madaling gamitin. At ngayon, sisiyasatin natin kung paano ito gamitin.

Ang istraktura ng HTTP

Dapat nating tandaan kaagad na ang HTTP protocol ay binubuo lamang ng teksto. Ang pinaka-interesante sa atin ay ang istruktura ng tekstong ito. Ang bawat mensahe ay binubuo ng tatlong bahagi:
  1. Panimulang linya — Tinutukoy nito ang ilang data ng housekeeping.
  2. Mga Header — Inilalarawan nito ang mga parameter ng mensahe.
  3. Katawan — Ito ang nilalaman ng mensahe. Ang katawan ay dapat na ihiwalay mula sa mga header ng isang walang laman na linya.
Ang HTTP protocol ay ginagamit upang magpadala ng mga kahilingan sa isang server at makatanggap ng mga tugon mula sa server. Ang mga parameter ng mga kahilingan at tugon ay bahagyang naiiba.

Narito ang hitsura ng isang simpleng kahilingan sa 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)
Ang panimulang linya ay nagpapahiwatig ng:
  • GET — Paraan ng kahilingan
  • / — Ang landas ng kahilingan
  • HTTP/1.1 — Ang bersyon ng protocol
Pagkatapos ay dumating ang mga header:
  • Host — Ang host kung saan tinutugunan ang kahilingan
  • User-Agent - Ang kliyente na nagpapadala ng kahilingan
Nawawala ang katawan ng mensahe. Sa isang kahilingan sa HTTP, tanging ang panimulang linya at ang "Host" na header ang kinakailangan. Ngayon tingnan natin ang lahat nang paisa-isa. Ang isang kahilingan sa HTTP ay dapat maglaman ng ilang paraan. Siyam sa mga ito: GET, POST, PUT, OPTIONS, HEAD, PATCH, DELETE, TRACE, CONNECT. Ang pinakakaraniwan ay GET at POST. Ang dalawang pamamaraan na ito ay magiging sapat sa una. GET — Ang pamamaraang ito ay humihiling ng nilalaman mula sa server. Alinsunod dito, ang mga kahilingan na may pamamaraang GET ay walang katawan ng mensahe. Ngunit kung kailangan mo, maaari mong ipasa ang mga parameter sa pamamagitan ng landas (sa panimulang linya) sa sumusunod na format: 

https://cdn.codegym.cc/images/article/155cea79-acfd-4968-9361-ad585e939b82/original.pngsend?name1=value1&name2=value2
kung saan ang codegym.cc ang host, ang /send ay ang path ng kahilingan, at ? ay isang separator na nagsasaad na sumusunod ang mga parameter ng query. Sa dulo, nakalista ang mga pares ng key-value ("key=value"), na pinaghihiwalay ng ampersand. POST — Ang pamamaraang ito ay naglalathala ng impormasyon sa server. Ang isang kahilingan sa POST ay maaaring magpadala ng iba't ibang uri ng impormasyon: mga parameter bilang mga pares na "key=value", 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: codegym.cc

{
  "Id": 12345,
  "User": "John"
}
Ang kahilingan ay ipinadala sa codegym.cc/user/create/json, at ang bersyon ng protocol ay HTTP/1.1. Ipinapahiwatig ng "Tanggapin" ang format ng tugon na inaasahan na matatanggap ng kliyente. Isinasaad ng "Content-Type" ang format ng katawan ng mensahe na ipinadala sa kahilingan. Ang "Content-Length" ay ang bilang ng mga character sa katawan. Ang isang kahilingan sa HTTP ay maaaring maglaman ng maraming iba't ibang mga header. Para sa higit pang impormasyon, tingnan ang detalye ng protocol .

Mga tugon sa HTTP

Pagkatapos makatanggap ng kahilingan, ipoproseso ito ng server at magpapadala 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 linya ng pagsisimula ng tugon ay naglalaman ng bersyon ng protocol (HTTP/1.1), code ng katayuan (200), at paglalarawan ng katayuan (OK). Kasama sa mga header nito ang uri at haba ng nilalaman. Ang katawan ng tugon ay naglalaman ng HTML code na ini-render ng browser bilang isang HTML na pahina.

Mga status code ng tugon

Malinaw ang lahat tungkol sa katawan ng mensahe at mga header, ngunit dapat tayong magsabi ng ilang salita tungkol sa mga status code. Ang mga status code ng tugon ay palaging tatlong digit. Ang unang digit ng code ay nagpapahiwatig ng kategorya ng tugon:
  • 1xx — Pang-impormasyon. Natanggap ang kahilingan. Ang server ay handa nang magpatuloy.
  • 2xx - Matagumpay. Ang kahilingan ay natanggap, naunawaan at naproseso.
  • 3xx - Pag-redirect. Kailangang magsagawa ng mga karagdagang pagkilos upang maproseso ang kahilingan.
  • 4xx — Error sa Kliyente. Ang kahilingan ay naglalaman ng mga error o hindi sumusunod sa protocol.
  • 5xx — Error sa Server. Ang kahilingan ay nabuo nang tama, ngunit hindi ito maproseso ng server.
Ang pangalawa at pangatlong digit sa code ay nagpapahiwatig ng mas tiyak na tugon. Halimbawa:
  • 200 OK — Ang kahilingan ay natanggap at matagumpay na naproseso.
  • 201 Created — Ang kahilingan ay natanggap at matagumpay na naproseso, na nagresulta sa paglikha ng isang bagong mapagkukunan o halimbawa.
  • 301 Permanenteng Inilipat — Ang hiniling na mapagkukunan ay permanenteng inilipat. Ang mga kasunod na kahilingan dito ay dapat gawin gamit ang bagong address.
  • 307 Temporary Redirect — Ang mapagkukunan ay pansamantalang inilipat. Sa ngayon, maaari itong ma-access gamit ang awtomatikong pagpapasa.
  • 403 Forbidden — Naunawaan 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 kinakailangan para tumugon sa kahilingan.
  • 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 din ang paglalarawan ng katayuan. Nakakatulong ito na linawin kung ano ang ibig sabihin ng bawat partikular na katayuan. Napakapraktikal ng HTTP protocol: nagbibigay ito ng malaking bilang ng mga header, na magagamit mo upang ayusin ang napaka-flexible na komunikasyon sa pagitan ng isang kliyente at server. Ang buong pagsasaalang-alang sa lahat ng mga header ng kahilingan at tugon, mga paraan ng kahilingan, at mga code ng status ng tugon ay magiging labis para sa isang artikulo. Kung kailangan mo, maaari mong basahin ang opisyal na detalye ng protocol, na naglalarawan sa lahat ng mga nuances. Nakaugalian na gamitin ang HTTP protocol sa port 80, kaya kapag nakakita ka ng URL na nagtatapos sa port 80, maaari kang magtiwala na kailangan mong gumamit ng HTTP para ma-access ito. Habang umuunlad ang teknolohiya at nagsimulang maipadala ang personal na data sa Internet, naging kinakailangan na isipin kung paano magbigay ng karagdagang proteksyon para sa impormasyong ipinapadala ng kliyente sa server. Ang resulta ng pag-iisip na ito ay ang HTTPS protocol.

Ang pagkakaiba sa pagitan ng HTTPS at HTTP

Sa mga tuntunin ng syntax, ang HTTPS ay kapareho ng HTTP protocol. Iyon ay, ginagamit nito ang parehong mga linya ng pagsisimula at mga 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 ang ibig sabihin nito, tingnan ang artikulo sa modelo ng OSI . Ang pamantayan sa pag-encrypt ngayon ay TLS. Hindi kami masyadong tatalakay sa paksang ito, ngunit tandaan na nangyayari ang pag-encrypt bago makarating ang impormasyon sa layer ng transportasyon. Sa HTTPS, ganap na naka-encrypt ang lahat ng impormasyon, maliban sa host at port kung saan ipinadala ang kahilingan. Ang paglipat ng server upang gamitin ang HTTPS protocol sa halip na HTTP ay hindi nangangailangan ng paggamit upang baguhin ang server code. Ang tampok na ito ay pinagana sa mga lalagyan ng servlet, na tatalakayin natin sa mga susunod na artikulo. At iyon lang para sa araw na ito. Sa totoo lang, sandali. Upang makuha ang iyong mga kamay sa ilang kahilingan sa HTTP, buksan ang Google Chrome, pindutin ang F12, at piliin ang tab na "Network." Ang lahat ng mga kahilingan at tugon na ipinadala/natanggap ng iyong browser ay ipapakita dito. Bahagi 4. Ang mga pangunahing kaalaman ng Maven Part 5. Servlets at ang Java Servlet API. Pagsusulat ng simpleng web application Part 6. Mga lalagyan ng Servlet Part 7. Ipinapakilala ang pattern ng MVC (Model-View-Controller)