Ĉio, kion vi bezonas scii pri HTTP
HTTP (Hiperteksta Translokiga Protokolo) provizas reton-protokolon, kiun la retumiloj kaj serviloj uzas por komuniki. Estas facile rekoni ĉi tion vizitante retejon ĉar ĝi estas skribita ĝuste en la URL (ekz. Http: // www. ).
Ĉi tiu protokolo estas simila al aliaj kiel FTP, en kiu ĝi estas uzata de kliento-programo por peti dosierojn de izolita servilo. En la kazo de HTTP, ĝi kutime estas retumilo, kiu petas HTML-dosierojn de servilo retejo, kiuj tiam montras en la retumilo kun teksto, bildoj, hiperligoj, ktp.
HTTP estas kio nomiĝas "senforma sistemo". Kion tio signifas, estas, ke kontraste kun aliaj dosieraj protokoloj kiel FTP , la HTTP-konekto estas faligita post kiam la peto estas farita. Do, kiam via retumilo sendas la peton kaj la servilo respondas per la paĝo, la ligo estas fermita.
Pro la plej multaj retumiloj de HTTP, vi povas tajpi nur la domajnan nomon kaj la retumilo aŭtomate plenigu la parton "http: //".
Historio de HTTP
Tim Berners-Legas kreis la komencan HTTP komence de la 1990-aj jaroj kiel parto de sia laboro en difino de la originala Monda Retejo . Tri primaraj versioj estis vaste deplojitaj dum la 1990-aj jaroj:
- HTTP 0.9 (por subteno de bazaj hipertekstaj dokumentoj)
- HTTP 1.0 (etendoj por subteni riĉajn retejojn kaj skareblon)
- HTTP 1.1 (evoluigita por direkti rendimentajn limojn de HTTP 1.0, specifitaj en Interreto RFC 2068)
La plej nova versio, HTTP 2.0, iĝis aprobita normo en 2015. Ĝi subtenas malantaŭan kongruon kun HTTP 1.1 sed ofertas pliajn efikecajn pliboniĝojn.
Dum HTTP normo ne ĉifras trafikon senditan tra reto, la HTTPS-normo estis kreita por aldoni ĉifradon al HTTP per la uzo de (originale) Secure Sockets Layer (SSL) aŭ (poste) Transporta Tavola Sekureco (TLS).
Kiel HTTP-Verkoj
HTTP estas aplika protokolo bazita sur supro de TCP, kiu uzas modelon pri konekto-servilo . HTTP-klientoj kaj serviloj komunikas per HTTP-peto kaj respondaj mesaĝoj. La tri ĉefaj HTTP-mesaĝoj estas GET, POST, and HEAD.
- HTTP GET- mesaĝoj senditaj al servilo enhavas nur URL . Nulo aŭ pli laŭvolaj datumoj-parametroj povas esti aldonitaj al la fino de la URL. La servilo procesas la laŭvolajn datumojn de la URL, se ĝi ĉeestas, kaj redonas la rezulton (retpaĝon aŭ elementon de retpaĝaro) al la retumilo.
- HTTP-POST- mesaĝoj metas ajnajn laŭvolajn parametrojn en la korpo de la peta mesaĝo anstataŭ aldoni ilin al la fino de la URL.
- HTTP HEAD- peto funkcias same kiel GET-petoj. Anstataŭ respondi kun la plena enhavo de la URL, la servilo sendas reen nur la kaplinion de informo (enhavita en la HTML-sekcion).
La retumilo komencas komunikadon kun HTTP-servilo komencante rilaton TCP al la servilo. Retejaj sesioj uzas servilonporton 80 defaŭlte, kvankam aliaj portoj kiel 8080 estas uzataj foje.
Iam kunsido estas establita, la uzanto forigas la sendadon kaj ricevon de HTTP-mesaĝoj vizitante la retpaĝon.
Problemoj kun HTTP
Mesaĝoj transdonitaj per HTTP ne povas esti transdonitaj sukcese pro pluraj kialoj:
- eraro de uzanto
- Malfunkciigo de la retumilo aŭ servilo
- eraroj en la kreado de retpaĝoj
- provizora reto klakoj
Kiam ĉi tiuj malsukcesoj okazas, la protokolo kaptas la kaŭzon de la fiasko (se eble) kaj raportas eraran kodon reen al la retumilo nomata statuso / kodo de HTTP . Eraroj komencas kun certa nombro por indiki kia eraro ĝi estas.
Ekzemple, 4xx eraroj indikas, ke la peto por la paĝo ne povas esti kompletigita ĝuste aŭ ke la peto enhavas malĝusta sintakso . Ekzemple, 404 eraroj signifas, ke la paĝo ne troveblas; iuj retejoj eĉ havas amuzajn kutimajn 404 erarojn .