ID nuk kaloi me uri çfarë të bëni. URI Uniform Identifikuesi i Burimeve

Për të hyrë në çdo burim rrjeti, duhet të dini se ku ndodhen dhe si t'i aksesoni ato. World Wide Web përdor një skemë të standardizuar adresimi dhe identifikimi, duke marrë parasysh përvojën e adresimit dhe identifikimit të e-mail, Gopher, WAIS, telnet, ftp, etj. - URL, Gjetësi Uniform i Burimeve.

URI(Identifikuesi Uniform i Burimeve) (RFC 2396, gusht 1998) është një varg karakteresh kompakt që përdoret për të identifikuar një burim abstrakt ose fizik. Një burim kuptohet si çdo objekt që i përket një hapësire të caktuar. Përfshin dhe anashkalon URL-të e përcaktuara më parë (RFC 1738 / RFC 1808) dhe URN-të (RFC 2141, RFC 2611).

URI është krijuar për të identifikuar në mënyrë unike çdo burim.

Disa nëngrupe të URI-ve:

URN(Uniform Resource Emri) - Një "urn:" private URI me një nëngrup të "namespace" që duhet të jetë unike dhe e pandryshueshme edhe kur burimi nuk ekziston më ose nuk është i disponueshëm.

Supozohet se, për shembull, shfletuesi e di se ku ta kërkojë këtë burim.

Sintaksë:

urn: namespace: data1.data2, more-data, ku hapësira e emrit përcakton se si përdoren të dhënat pas ":"-së së dytë.

Shembull URN:

urna: ISBN: 0-395-36341-6

ISBN - klasifikues tematik për botuesit

0-395-36341-6 - një numër specifik i subjektit të një libri ose reviste

Pas marrjes së URN-së, programi i klientit kthehet në ISBN (drejtoria "Klasifikuesi aktual për botuesit" në internet). Dhe ai merr një deshifrim të numrit të lëndës "0-395-36341-6" (për shembull: "kimia kuantike").

URN përdoret gjerësisht në rrjetet P2P (si edonkey).

Shembull URN që tregon imazhin e diskut Adobe Photoshop v8.0 në rrjetin edonkey:

urna: ed2k: // | skedar | AdobePhotoshopv8.0.iso | 940769280 | | /

ed2k - tregon rrjetin

Adobe Photoshop v8.0.iso - emri i skedarit

940769280 - madhësia në bajt

- identifikuesi i skedarit (llogaritur duke përdorur një funksion hash)

Gjetësi i Uniform i Burimeve të URL-së:

Url(Uniform Resource Locator, RFC 1738) është një gjetës i unifikuar i burimeve (lokator), një mënyrë e standardizuar e regjistrimit të adresës së një burimi në WWW dhe në internet. URL-ja ka një strukturë fleksibël dhe të zgjerueshme për të treguar vendndodhjen e burimeve në rrjet sa më natyrshëm të jetë e mundur, e cila identifikon një burim nga mënyra se si aksesohet (p.sh. "vendndodhja e tij e rrjetit") në vend që ta identifikojë atë me emër ose atribute të tjera të atë burim.

Shembuj të URL-ve:

http://www.ipm.kstu.ru/index.php

ftp://www.ipm.kstu.ru/

Një grup i kufizuar karakteresh ASCII përdoret për të përfaqësuar adresën.

Forma e përgjithshme adresat mund të përfaqësohen si kjo:

<схема>://<логин>:<пароль>@<хост>:<порт>/<полный-путь-к-ресурсу >

skema e aksesit të burimeve: http, ftp, gopher, mailto, news, telnet, file, man, info, whatis, ldap, wais, etj.

Hyrja: Fjalëkalimi- emri i përdoruesit dhe fjalëkalimi i përdorur për të hyrë në burim

mikpritës- emri i domenit të hostit ose adresa IP e tij.

Port- porta pritës për lidhje

rruga e plotë drejt burimit - sqarimi i informacionit në lidhje me vendndodhjen e burimit (varet nga protokolli).

Shembuj të URL-ve:

http://example.com # kërkesë për faqen fillestare të paracaktuar

http://www.example.com/site/map.html # kërkoni një faqe të caktuar në një direktori të caktuar

http://example.com:81/script.php # lidheni me një port jo standard

http://example.org/script.php?key=value # kërkesë me kalimin e parametrave në skript

ftp: // përdorues: [email i mbrojtur]# lidheni me serverin ftp me autorizim

http://192.168.0.1/example/www # lidhuni me adresën e rrjetit

skedari: ///srv/www/htdocs/index.html # hap skedarin lokal

gopher: //example.com/1 # lidhuni me serverin gopher

URL - Locatorët e njëtrajtshëm të burimeve përshkruajnë në mënyrë eksplicite se si të arrish te një objekt.

Ardhja e URL-ve është një risi e rëndësishme në internet. Sidoqoftë, që nga momenti i shpikjes së tij deri në ditët e sotme, standardi URL ka një pengesë serioze - ai mund të përdorë vetëm një grup të kufizuar karakteresh, madje edhe më pak se në ASCII: letra, numra dhe vetëm disa shenja pikësimi-.

Nëse duam të përdorim karaktere cirilike, ose hieroglife, ose, të themi, karaktere specifike të gjuhës frënge në URL, atëherë karakteret që na duhen duhet të rikodohen në një mënyrë të veçantë.

Në Wikipedia në gjuhën ruse, ju duhet të shihni shembuj të kodimit të URL-ve çdo ditë, pasi gjuha ruse përdor karaktere cirilike. Për shembull, një linjë si kjo:

http://ru.wikipedia.org/wiki/Microcredit

URL e koduar si:

http://ru.wikipedia.org/wiki/%D0%9C%D0%B8%D0%BA%D1%80%D0%BE%D0%BA%D1%80%D0%B5%D0%B4%D0 % B8% D1% 82

Ky konvertim bëhet në dy faza: së pari, çdo karakter cirilik kodohet në Unicode (UTF-8) në një sekuencë prej dy bajtësh, dhe më pas çdo bajt i kësaj sekuence shkruhet me shënim heksadecimal:

M → D0 dhe 9C →% D0% 9C

dhe → D0 dhe B8 →% D0% B8

k → D0 dhe BA →% D0% BA

p → D1 dhe 80 →% D1% 80, etj.

Çdo kod i tillë heksadecimal bajti paraprihet nga një shenjë përqindjeje (%) sipas specifikimit të URL-së - prandaj termi anglisht "përqind-encoding", i cili tregon se si kodohen karakteret në URL dhe URI.

Meqenëse shkronjat e të gjitha alfabeteve, përveç alfabetit bazë latin, i nënshtrohen një transformimi të tillë, URL-ja me fjalë në shumicën dërrmuese të gjuhëve (përveç anglisht, italisht, latinisht) mund të bëhet e palexueshme për një person.

E gjithë kjo është në kundërshtim me parimin e internacionalizmit, të shpallur nga të gjitha organizatat kryesore në internet, përfshirë W3C dhe ISOC. Ky problem është krijuar për të zgjidhur standardin IRI (Identifikuesi i Burimeve Ndërkombëtare) - identifikuesit e burimeve ndërkombëtare në të cilat do të ishte e mundur të përdorni karaktere Unicode pa probleme, dhe për këtë arsye nuk do të cenonin të drejtat e gjuhëve të tjera.

Skema të tjera url

Skema HTTP.

Skema specifikon identifikuesin e saj, adresën e makinës, portin TCP, shtegun në drejtorinë e serverit, variablat dhe vlerat e tyre, etiketën.

Sintaksë:

http:// [:@][:][?]]

http - emri i skemës

përdorues - emër përdoruesi

host - emri i hostit

port - numri i portit

pyet (<имя-поля>=<значение>{&<имя-поля>=<значение>) - varg pyetjesh

Përcaktuar në RFC 2068. Si parazgjedhje, porta = 80.

Shembuj:
http://ipm.kstu.ru/internet/index.php

Ky është lloji më i zakonshëm i URI-së që përdoret në dokumentet WWW. Emri i skemës (http) ndiqet nga një shteg që përbëhet nga adresa e domenit të makinës dhe adresa e plotë e dokumentit HTML në pemën e serverit HTTP.

Adresa IP mund të përdoret gjithashtu si adresë e makinës:

http://195.208.44.20/internet/index.php

Nëse serveri HTTP funksionon në një port TCP të ndryshëm nga 80, kjo pasqyrohet në adresën:

http://195.208.44.20:8080/internet/index.php

http://195.208.44.20/internet/index.php#metka1
Karakteri "#" ndan emrin e dokumentit nga emri i etiketës.

Variablat dhe vlerat e tyre kalohen si më poshtë:
http://ipm.kstu.ru/internet/index.php?var1=value1&vard2=value2

Vlerat "var1" dhe "var2" janë emrat e ndryshoreve, dhe "vlera1" dhe "vlera2" janë vlerat e tyre.

Skema FTP

Kjo skemë ju lejon të adresoni arkivat e skedarëve FTP.

Sintaksë:

ftp: // [ [:@][:]

ftp - emri i skemës

përdorues - emër përdoruesi

fjalëkalimi - fjalëkalimi i përdoruesit

host - emri i hostit

port - numri i portit

url-path - shtegu i skedarit dhe vetë skedari

Përcaktuar në RFC 1738. Si parazgjedhje, porta = 21, përdoruesi = anonim, fjalëkalimi = adresa e emailit, nëse emri është specifikuar, por fjalëkalimi nuk është, atëherë kërkohet në dialog.

duket si:

//...//[; lloji = ], ku :

Shembuj: ftp://ipm.kstu.ru/students/name/

Për të specifikuar një emër përdoruesi dhe fjalëkalim, duhet ta shkruani në këtë mënyrë:
ftp: // emri: [email i mbrojtur]: //ipm.kstu.ru/students/name/

Në këtë rast, këta parametra ndahen nga adresa e makinës me simbolin "@" dhe nga njëri-tjetri me një dy pika.

Skema MAILTO

Kjo skemë ka për qëllim dërgimin e postës.

Sintaksë:

mailto: [ {,,...}][?]

mailto - emri i skemës

e-mail-1 ( @) - adresa e parë e emailit

përdorues - emër përdoruesi

host - emri i hostit

e-mail-2 - adresa e dytë e postës elektronike

pyet (<имя-поля-заголовка>=<значение>{&<имя-поля-заголовка>=<значение>) - varg pyetjesh

mailto: [email i mbrojtur]

Në këtë skemë kalohen fushat dhe vlerat e tyre:

mailto: [email i mbrojtur]? subjekt = Subject_Email & body = Tekst_which_do_be_inserted_in_the_mail

Adresa e marrësit mund të shkruhet gjithashtu si vlera e fushës për:

mailto: [email i mbrojtur]? subjekt = Subject_Email & body = Tekst_which_do_be_inserted_in_the_mail

Çfarë është HTTP?

Dokumenti i parë (por jo standardi) është RFC1945 (Hypertext Transfer Protocol - HTTP / 1.0 T. Berners-Lee, R. Fielding, H. Frystyk maj 1996)

Versioni i fundit është RFC2616 (Hypertext Transfer Protocol - HTTP / 1.1 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee qershor 1999)

Protokolli i Transferimit të Hipertekstit është një protokoll transferimi hiperteksti, një protokoll i nivelit të lartë (përkatësisht, shtresa e aplikacionit). Përdoret nga shërbimi WWW për të transferuar faqe në internet.

HTTP (HyperText Transfer Protocol, RFC 2616, versioni aktual është HTTP / 1.1) është një protokoll transferimi hiperteksti. Ky protokoll fillimisht ishte menduar për shkëmbimin e dokumenteve të hipertekstit, tani aftësitë e tij janë zgjeruar ndjeshëm (në veçanti, është shtuar mbështetja për transmetimin).

HTTP është një protokoll tipik klient-server; mesazhet shkëmbehen sipas skemës "kërkesë-përgjigje" në formën e komandave ASCII. Një tipar i protokollit HTTP është aftësia për të specifikuar në një kërkesë dhe një përgjigje mënyrën e paraqitjes së të njëjtit burim me parametra të ndryshëm: formati, kodimi, gjuha etj. Kjo është falë mundësisë së specifikimit të metodës së kodimit të një mesazhi. që klienti dhe serveri mund të shkëmbejnë të dhëna binare, megjithëse ky protokoll është tekst.

HTTP është një protokoll i shtresës së aplikacionit, por përdoret gjithashtu si "transport" për protokollet e tjera të aplikacionit si SOAP, XML-RPC, WebDAV.

Protokolli HTTP përcakton një mënyrë ndërveprimi kërkesë-përgjigje midis një programi klient dhe një programi serveri brenda teknologjisë botërore. Ueb i gjerë.

Për të ngarkuar një faqe interneti në një shfletues klienti, ai dërgon një kërkesë në një program të veçantë të instaluar në kompjuterin e serverit, i quajtur server http, dhe përpunon të dhënat e marra prej tij. Në këtë rast, funksioni i shfletuesit është të pyesë serverin një faqe specifike, merrni dhe shfaqeni në ekranin e përdoruesit. Serveri, nga ana tjetër, pranon kërkesën, kërkon dokumentin e kërkuar dhe i jep klientit ose përmbajtjen e skedarit të gjetur ose një mesazh gabimi nëse një skedar i tillë nuk u gjet ose qasja në të u refuzua për ndonjë arsye. . Një pikë e rëndësishme për të kuptuar këtë proces është se serveri http nuk analizon përmbajtjen e dokumentit të transmetuar. Përafërsisht, http-server nuk i intereson se çfarë është brenda skedarit të kërkuar, ai vetëm e transferon atë në shfletues dhe e gjithë puna për strukturimin dhe shfaqjen e informacionit të marrë është marrë tashmë.

Kërkimi për faqen e kërkuar kryhet në një drejtori specifike, e cila është ndarë në kompjuterin e serverit për këtë faqe - një lidhje me këtë drejtori është e pranishme në adresën e futur nga përdoruesi. Në rastin kur referenca nuk bëhet për një dokument specifik, por për sitin në tërësi, serveri http zëvendëson automatikisht të ashtuquajturin " faqja e fillimit", i cili quhet index.htm ose index.html (në disa raste, default.htm ose default.html). Ky dokument duhet të gjendet në direktoriumin rrënjësor të caktuar për të pritur faqen tuaj, ose, nëse specifikohet ndryshe, në një drejtori të quajtur WWW. Të gjithë skedarët e tjerë mund të vendosen ose në të njëjtën direktori ose në nëndrejtori, gjë që ndonjëherë është e përshtatshme, veçanërisht kur faqja përmban disa seksione ose tituj tematikë.

Përveç nëndosjeve që krijoni, në të cilët jeni i lirë të vendosni pothuajse çdo përmbajtje që ju nevojitet, direktoria e serverit zakonisht përmban disa drejtori të tjera që duhen përmendur veçmas. Së pari, kjo është dosja CGI-BIN, ku ndodhen skriptet CGI dhe aplikacionet e tjera interaktive të nisura nga faqja juaj, si dhe disa drejtori shërbimesh të kërkuara për punë normale server. Në fazën fillestare, thjesht nuk duhet t'u kushtoni vëmendje atyre. Ndonjëherë në të njëjtin direktorium ku ruhet index.html, ka një numër skedarësh shtesë: not_found.html - një dokument që shfaqet nëse serveri http nuk mund ta gjejë skedarin e kërkuar nga përdoruesi, forbidden.html - shfaqet si një mesazh gabimi, nëse qasja në dokumentin e kërkuar refuzohet dhe, së fundi, robots.txt është një skedar që përshkruan në mënyrë specifike rregullat për indeksimin e faqes tuaj nga motorët e kërkimit.

Në shumicën e rasteve, dhe veçanërisht kur publikoni një faqe kryesore në serverë që ofrojnë pritje falas, përdoruesve u mohohet qasja në drejtoritë e shërbimeve dhe dosjen CGI-BIN; ndryshimi i përmbajtjes së skedarëve not_found dhe të ndaluar.html është gjithashtu i pamundur. Kjo duhet të merret parasysh nëse planifikoni të përfshini ndonjë përmbajtje ndërvepruese në burimin tuaj që kërkon të paktën aftësinë për të vendosur skedarë në një nga dosjet e shërbimit... Në disa raste, mund t'ju ndalohet të krijoni drejtori të ndërlidhura në server, atëherë përdoruesi do të duhet të jetë i kënaqur me vetëm një drejtori të caktuar për nevojat tuaja.

Nga gjithçka që u tha, bëhet e qartë se shfletuesi i klientit mund të marrë dhe përpunojë informacione nga serveri, dhe ta vendosë dhe modifikojë atë vetëm nëse ngarkimi i skedarëve në server zbatohet bazuar në protokollin HTTP duke përdorur skriptet speciale CGI të përfshira. në ndërfaqen web të serverit. Në të gjitha rastet e tjera, duhet të përdorni të ashtuquajturin server ftp, në të cilin mund të transferoni skedarët e nevojshëm duke përdorur softuer special, duke i ngarkuar automatikisht në drejtorinë e caktuar për faqen tuaj. Në të dyja rastet, do t'ju duhet të dini emrin tuaj të hyrjes dhe fjalëkalimin për të hyrë në sistem. Duhet mbajtur mend gjithashtu se shumica e programeve të serverëve (në veçanti, Apache për platformat e përputhshme me UNIX) bëjnë dallimin midis karaktereve të vogla dhe të mëdha, kështu që të gjithë emrat e skedarëve dhe shtesat e tyre duhet të shkruhen me shkronja të vogla dhe gjithmonë në latinisht, për të shmangur gabimet. Kjo e fundit është për shkak të dallimeve në përpunimin e kodimeve të gjuhës ruse, tipike për serverë të caktuar.

Puna mbi protokollin HTTP është si më poshtë: programi i klientit krijon një lidhje TCP me serverin (numri standard i portit është 80) dhe lëshon një kërkesë HTTP për të. Serveri përpunon këtë kërkesë dhe lëshon një përgjigje HTTP për klientin.

Komunikimi ndërmjet klientit dhe Web serverit bëhet përmes shkëmbimit të mesazheve. Mesazhet HTTP ndahen në kërkesa klient-server dhe përgjigje server-to-klient.

Mesazhet e kërkesës dhe përgjigjes kanë një format të përbashkët. Të dy llojet e mesazheve duken kështu: fillimisht vjen linja e fillimit, pastaj ndoshta një ose më shumë fusha të kokës, të quajtura thjesht tituj, pastaj vijë bosh(d.m.th., një varg i përbërë nga karakteret CR dhe LF) që tregon fundin e fushave të kokës, dhe më pas ndoshta trupin e mesazhit:

vija e fillimit

fusha e kokës 1

fusha e kokës 2

fusha e kokës N

trupi i mesazhit

Titujt e protokollit HTTP

Formati i linjës fillestare të klientit dhe serverit është i ndryshëm dhe do të diskutohet më poshtë. Ekzistojnë katër lloje titujsh:

Titujt e përgjithshëm (general-headers), të cilët mund të jenë të pranishëm si në kërkesë ashtu edhe në përgjigje;

Krerët e kërkesave, të cilat mund të jenë të pranishme vetëm në një kërkesë;

Titujt e përgjigjes, të cilat mund të jenë të pranishme vetëm në një përgjigje;

Titujt e entitetit që i referohen trupit të një mesazhi dhe përshkruajnë përmbajtjen e tij.

Çdo titull përbëhet nga një titull, një dy pika ":" dhe një vlerë. Titujt më të rëndësishëm janë paraqitur në tabelën 1.

Tabela 1

Titujt e protokollit HTTP

Drejtimi	Emërimi
Kokat e objekteve
Lejo	Liston metodat e mbështetura nga serveri
Përmbajtja-Enkodimi	Mënyra se si është koduar trupi i mesazhit, për shembull për të zvogëluar madhësinë
Përmbajtja-Gjatësia	Gjatësia e mesazhit në bajt
Lloji i përmbajtjes	Përmban përcaktimin e llojit të përmbajtjes MIME të përgjigjes. Në varësi të llojit të përmbajtjes, shfletuesi e interpreton përgjigjen si një faqe HTML, një imazh gif ose jpeg, një skedar që do të ruhet në disk ose diçka tjetër dhe ndërmerr veprimet e duhura. Disa lloje të përmbajtjes: tekst / html - tekst në Formati HTML(faqe interneti); tekst / i thjeshtë - tekst i thjeshtë (i ngjashëm me "Notepad"); imazh / jpeg - foto në Formati JPEG; imazh / gif - i njëjtë, në formatin GIF; Ai gjithashtu mund të kalojë kodimin për të dhënat e tekstit. Për shembull: charset = windows-1251 charset = koi8-rus Content-Length - gjatësia e përmbajtjes së përgjigjes në bajt (madhësia e skedarit). Last-Modified - data dhe ora kur dokumenti është modifikuar për herë të fundit.
ETag	Një etiketë unike e burimeve në server që ju lejon të krahasoni burimet
Skadon	Data dhe ora kur burimi në server do të ndryshohet dhe ai duhet të merret përsëri
E modifikuara e fundit	Data dhe ora e modifikimit të fundit të përmbajtjes
Titujt e përgjigjes
Mosha	Numri i sekondave pas të cilave duhet të riprovohet kërkesa për të marrë përmbajtje të re
Vendndodhja	URI-ja e burimit që duhet konsultuar për të marrë përmbajtjen
Riprovo-Pas	Data dhe ora ose numri i sekondave pas së cilës kërkesa duhet të përsëritet për të marrë një përgjigje të suksesshme
Serveri	Emri i softuerit të serverit që u përgjigj
Titujt e kërkesës
Pranoje	Një listë e llojeve të përmbajtjes të mbështetura nga shfletuesi në rendin e preferencës së tyre për këtë shfletues, për shembull: Prano: imazh / gif, imazh / x-xbitmap, imazh / jpeg, imazh / pjpeg, aplikacion / vnd.ms-excel, aplikacioni / msword, aplikacioni / vnd. ms-powerpoint, * / * Kjo është padyshim e nevojshme për rastin kur serveri mund të shërbejë të njëjtin dokument në formate të ndryshme. Vlera e këtij parametri përdoret kryesisht nga skriptet CGI për të gjeneruar një përgjigje të përshtatur për një shfletues të caktuar.
Prano-Charset	Kodimet e karaktereve në të cilat klienti mund të pranojë përmbajtje teksti
Prano-Enkodim	Mënyra se si serveri mund të kodojë mesazhin
Mikpritës	Numri i hostit dhe portit nga i cili kërkohet dokumenti
If-Modified-Since If-Match If-None-Match If-Range If-Unmodified-Since	Kërkoni titujt për akses në burim të kushtëzuar
Gama	Kërkoni një pjesë të një dokumenti
Përdorues-Agjent	Emri i softuerit të klientit - vlera është "emri i kodit" i shfletuesit, për shembull: Mozilla / 4.0 (i pajtueshëm; MSIE 5.0; Windows 95; DigExt)
Titujt e përgjithshëm
Lidhje	Lidhja - mund të jetë Keep-Alive dhe mbyll. Keep-Alive do të thotë që pas lëshimit të këtij dokumenti lidhja me serverin nuk ndërpritet dhe mund të lëshohen më shumë kërkesa. Shumica e shfletuesve punojnë në modalitetin Keep-Alive, pasi ju lejon të "shkarkoni" një faqe html dhe fotografi në të në një lidhje me serverin. Pasi të vendoset, modaliteti Keep-Alive ruhet deri në gabimin e parë ose derisa të tregohet në mënyrë eksplicite në kërkesën tjetër Lidhja: mbyllje. mbyll - lidhja mbyllet pasi t'i përgjigjet kësaj kërkese.
Data	Data dhe ora e formimit të mesazhit
Pragma	Komandat specifike të zbatimit për përmbajtjen e transferuar
Transferimi-Enkodimi	Metoda e kodimit të mesazhit për transmetim

Në disa tituj, vlera është data dhe ora. Ato duhet të jenë në formatin e përshkruar në RFC 1123, për shembull:

Trupi i mesazhit përmban informacionin aktual që transmetohet - ngarkesën e mesazhit. Trupi i mesazhit është një sekuencë oktetesh (bajt). Trupi i mesazhit mund të kodohet, me kodimin e specifikuar në kokën e objektit Content-Encoding.

Një mesazh kërkese nga klienti në server përbëhet nga një linjë kërkese, tituj (të përgjithshëm, kërkesë, objekt) dhe ndoshta një trup mesazhi.

Linja e kërkesës fillon me një metodë, e ndjekur nga identifikuesi i burimit të kërkuar, versioni i protokollit dhe karakteret e fundit të linjës:

<Метод> <Идентификатор> <Версия HTTP>

Metoda specifikon metodën për t'u aplikuar në burimin e kërkuar. Për shembull, metoda GET thotë se klienti dëshiron të marrë përmbajtjen e burimit. Identifikuesi identifikon burimin e kërkuar. Versioni HTTP tregohet nga një rresht si ky:

HTTP /<версия>.<подверсия>

Metodat e protokollit HTTP

Le të shohim metodat kryesore të protokollit HTTP.

Metoda OPTIONS kërkon informacion në lidhje me opsionet e lidhjes (për shembull, metodat, llojet e dokumenteve, kodimet) që serveri mbështet për burimin e kërkuar. Kjo metodë i lejon klientit të përcaktojë opsionet dhe / ose kërkesat që lidhen me burimin, ose aftësitë e serverit, pa ndërmarrë asnjë veprim mbi burimin ose pa nisur një shkarkim.

Nëse përgjigja e serverit nuk është një mesazh gabimi, atëherë titujt e objekteve përmbajnë informacion që mund të mendohet si opsione lidhjeje. Për shembull, titulli Lejo liston të gjitha metodat e mbështetura nga serveri për një burim të caktuar.

Nëse identifikuesi i burimit të kërkuar është një yll ("*"), atëherë kërkesa OPTIONS synon t'i drejtohet serverit në tërësi.

Nëse identifikuesi i burimit të kërkuar nuk është një yll, atëherë kërkesa OPTIONS zbatohet për opsionet e disponueshme kur lidheni me burimin e specifikuar.

Metoda GET ju lejon të merrni çdo informacion në lidhje me burimin e kërkuar. Në shumicën e rasteve, nëse identifikuesi i burimit të kërkuar tregon një dokument (për shembull, dokument teksti, imazh grafik, video), atëherë serveri kthen përmbajtjen e këtij dokumenti (përmbajtja e skedarit). Nëse burimi i kërkuar është një aplikacion (program) që gjeneron të dhëna, atëherë të dhënat e gjeneruara kthehen në trupin e mesazhit të përgjigjes, dhe jo një imazh binar i skedarit të ekzekutueshëm. Kjo përdoret, për shembull, kur krijohen aplikacione CGI. Nëse identifikuesi i burimit të kërkuar tregon në një direktori (direktori, dosje), atëherë, në varësi të cilësimeve të serverit, ose përmbajtja e drejtorisë (lista e skedarëve) ose përmbajtja e një prej skedarëve të vendosur në këtë direktori (zakonisht index.html ose Default.htm). V rastin e fundit emri i dosjes mund të specifikohet ose me simbolin "/" në fund, ose pa të. Nëse ky simbol mungon në fund të identifikuesit, serveri lëshon një nga përgjigjet me ridrejtim (me kodet e statusit 301 ose 302).

Dalloni midis "GET me kusht", në të cilin mesazhi i kërkesës përfshin titujt e kërkesës If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match ose If-Range. Metoda e kushtëzuar GET kërkon transferimin e një objekti vetëm nëse ai plotëson kushtet e përshkruara në kokat e dhëna. Metoda e kushtëzuar GET është krijuar për t'u ulur shkarkim i panevojshëm rrjeti, pasi ju lejon të mos shkarkoni të dhënat e ruajtura tashmë nga klienti për herë të dytë.

Bëhet gjithashtu një dallim midis "GET-it të pjesshëm", në të cilin mesazhi i kërkesës përfshin një kokë të kërkesës Range. Një GET i pjesshëm kërkon transferimin e vetëm një pjese të objektit. Metoda e pjesshme GET është projektuar për të reduktuar ngarkesën e panevojshme të rrjetit duke kërkuar vetëm një pjesë të objektit kur pjesa tjetër është shkarkuar tashmë nga klienti. Vlera e kokës së diapazonit është diapazoni i bajteve për të marrë. Bajtet numërohen duke filluar nga 0. Bajtet e fillimit dhe mbarimit të diapazonit ndahen me një karakter "-". Nëse keni nevojë të merrni disa vargje, ato renditen të ndara me presje.

Metoda HEAD është identike me GET, përveç se serveri nuk e kthen trupin e mesazhit në përgjigje. Informacioni meta i përmbajtur në titujt HTTP të përgjigjes ndaj një kërkese HEAD është identik me informacionin e dhënë në përgjigjen ndaj një kërkese GET. Kjo metodë mund të përdoret për të marrë informacion rreth objektit të kërkesës pa përcjellë drejtpërdrejt trupin e objektit. Metoda HEAD përdoret shpesh për të testuar lidhjet e hipertekstit.

Metoda POST përdoret për një kërkesë, në të cilën serveri i adresuar merr të dhëna të përfshira në trupin e mesazhit (objekt) të kërkesës dhe i dërgon ato për përpunim në aplikacionin e specifikuar si burimi i kërkuar. POST është krijuar për të zbatuar funksionet e mëposhtme në një mënyrë të përgjithshme:

Shënimi i burimeve ekzistuese;

Postimi i një mesazhi në një bord elektronik buletinesh (BBS), grupe lajmesh, lista postare ose grupe të ngjashme artikujsh;

Kalimi i një blloku të dhënash, të tilla si rezultati i një hyrjeje në një formë, në një proces përpunimi;

Ekzekutimi i pyetjeve në bazat e të dhënave (DB);

Në fakt, funksioni i kryer nga metoda POST përcaktohet nga aplikacioni i treguar nga ID-ja e burimit të kërkuar. Së bashku me metodën GET, metoda POST përdoret gjatë ndërtimit të aplikacioneve CGI. Shfletuesi mund të formojë kërkesa me metodën POST kur dorëzon formularët. Për këtë, elementi FORMA dokument HTML që përmban formularin duhet të ketë një atribut METHOD me një vlerë POST.

Një veprim POST mund të kryejë një veprim në server dhe të mos kalojë asnjë përmbajtje si rezultat. Në këtë rast, në varësi të faktit nëse përgjigja përfshin një trup mesazhi që përshkruan rezultatin apo jo, kodi i statusit në përgjigje mund të jetë ose 200 (OK) ose 204 (Pa përmbajtje).

Nëse burimi është krijuar në server, përgjigja përmban një kod statusi 201 (Krijuar) dhe përfshin kokën e përgjigjes Vendndodhja.

Trupi i mesazhit, i cili transmetohet në një kërkesë me metodën PUT, ruhet në server dhe identifikuesi i burimit të kërkuar do të jetë identifikuesi i dokumentit të ruajtur. Nëse identifikuesi i burimit të kërkuar tregon për një burim tashmë ekzistues, atëherë objekti i përfshirë në trupin e mesazhit trajtohet si një version i modifikuar i burimit të vendosur në server. Nëse krijohet një burim i ri, atëherë serveri informon agjentin e përdoruesit për të me një përgjigje me një kod statusi 201 (Krijuar).

Dallimi thelbësor midis metodave POST dhe PUT është kuptim të ndryshëm identifikuesin e burimit të kërkuar. URI në kërkesën POST identifikon burimin që trajton objektin e përfshirë në trupin e mesazhit. Ky burim mund të jetë një aplikacion që merr të dhëna. Në të kundërt, URI në Kërkesa PUT identifikon objektin e përfshirë në kërkesë si një trup mesazhi, domethënë agjenti i përdoruesit i cakton URI-në e dhënë burimit të përfshirë.

Metoda DELETE i kërkon serverit të fshijë një burim që ka identifikuesin e kërkuar. Një kërkesë me këtë metodë mund të refuzohet nga serveri nëse përdoruesi nuk ka leje për të fshirë burimin e kërkuar.

Metoda TRACE përdoret për të kthyer kërkesën e paraqitur në nivelin e protokollit HTTP. Marrësi i kërkesës (Web serveri) ia dërgon mesazhin e marrë klientit si trupi i një objekti përgjigjeje me një kod statusi 200 (OK). Një kërkesë TRACE nuk duhet të përmbajë një trup mesazhi.

TRACE lejon klientin të shohë se çfarë po merr serveri në anën tjetër dhe t'i përdorë ato të dhëna për testim ose diagnostikim.

Nëse kërkesa është e suksesshme, atëherë përgjigja përmban të gjithë mesazhin e kërkesës në trupin e mesazhit të përgjigjes, dhe kreu i objektit Content-Type është "mesazh / http".

Kodet e përgjigjeve

Pas marrjes dhe interpretimit të mesazhit të kërkesës, serveri përgjigjet me një mesazh përgjigjeje HTTP.

Rreshti i parë i përgjigjes është linja e statusit. Ai përbëhet nga një version i protokollit, një kod statusi numerik, një frazë shpjeguese, e ndarë me hapësira dhe karaktere në fund të rreshtit:

<Версия HTTP> <Код состояния> <Поясняющая фраза>

Versioni i protokollit ka të njëjtin kuptim si në kërkesë.

Elementi Status-Code është një kod i plotë treshifror (treshifror) i rezultatit të të kuptuarit dhe plotësimit të kërkesës. Arsyeja-fraza është një përshkrim i shkurtër tekstual i kodit të statusit. Kodi i statusit është për përpunimin e softuerit dhe fraza shpjeguese është për përdoruesit.

Shifra e parë e kodit të statusit identifikon klasën e përgjigjes. Dy shifrat e fundit nuk kanë ndonjë rol specifik në klasifikim. Ka 5 vlera për shifrën e parë:

1xx: Kodet e informacionit - kërkesa e marrë, përpunimi vazhdon.

2xx: Kodet e suksesit - Veprimi u mor me sukses, u kuptua dhe u përpunua.

3xx: Kodet e ridrejtimit - Duhet të ndërmerren veprime të mëtejshme për të përfunduar kërkesën.

4xx: Kodet e gabimit të klientit - Kërkesa ka një gabim sintaksor ose nuk mund të plotësohej.

5xx: Kodet e gabimit të serverit - Serveri nuk është në gjendje të përmbushë një kërkesë të vlefshme.

Fraza-arsyeja për çdo kod statusi është renditur në RFC 2068 dhe rekomandohet, por mund të zëvendësohet me ekuivalentin pa ndikuar në protokollin. Për shembull, në versionet e lokalizuara në gjuhën ruse të serverëve HTTP, këto fraza zëvendësohen nga ato ruse. Tabela 2 liston kodet e përgjigjes së serverit HTTP.

tabela 2

Kodet e përgjigjes së serverit HTTP

Kodi	Fraza shpjeguese sipas RFC 2068	Fraza ekuivalente shpjeguese në rusisht
1xx: Kodet e informacionit
	Vazhdoni	Vazhdoni
2xx: Kodet e suksesit
	Ne rregull	Ne rregull
	Krijuar	Krijuar nga
	Nuk ka përmbajtje	Nuk ka përmbajtje
	Rivendos përmbajtjen	Rivendos përmbajtjen
	Përmbajtje e pjesshme	Përmbajtja e pjesshme
3xx: Kodet e ridrejtimit
	Lëvizur përkohësisht	Lëvizur përkohësisht
	Nuk është modifikuar	I pa modifikuar
4xx: Kodet e gabimit të klientit
	Kerkese e keqe	Kërkesë e korruptuar
	I paautorizuar	I paautorizuar
	Nuk u gjet	Nuk u gjet
	Metoda nuk lejohet	Metoda nuk lejohet
	Përfundimi i kërkesës	Koha e kërkesës mbaroi
	Konflikti	Konflikti
	Gjatësia e kërkuar	Gjatësia e kërkuar
	Kërkoni një subjekt shumë të madh	Objekti i kërkesës është shumë i madh
5xx: Kodet e gabimit të serverit
	Server i brendshëm Gabim	Gabim i brendshëm server
	Nuk është zbatuar	Nuk zbatohet
	sherbim i padisponueshem	Shërbimi është i padisponueshëm
	Versioni HTTP nuk mbështetet	Versioni i pambështetur HTTP

Shiriti i statusit ndiqet nga titujt (e përgjithshme, përgjigja dhe objekti) dhe ndoshta nga trupi i mesazhit.

Nje nga funksionet thelbësore një server në internet duhet të sigurojë akses në një pjesë të sistemit lokal të skedarëve. Për ta bërë këtë, në cilësimet e serverit specifikohet një direktori e caktuar, e cila është rrënja për këtë server. Të publikosh një dokument, domethënë ta bësh atë në dispozicion të përdoruesve i cili "e ka vizituar" këtë server (pasi keni bërë një lidhje me të nëpërmjet protokollit HTTP), ju duhet ta kopjoni këtë dokument në direktoriumin rrënjë të serverit të uebit ose në një nga nëndrejtoritë e tij. Kur lidheni përmes protokollit HTTP, në server krijohet një proces me të drejtat e përdoruesit, i cili, si rregull, nuk ekziston në realitet, por është krijuar posaçërisht për të parë burimet e serverit. Duke konfiguruar të drejtat dhe lejet e këtij përdoruesi, ju mund të kontrolloni aksesin në burimet e Uebit.

Le të shohim shembullin më të thjeshtë të një kërkese HTTP. Nëse në dritaren e adresës së shfletuesit shkruajmë adresën http://yandex.ru, atëherë shfletuesi do të përcaktojë adresën IP të serverit yandex.ru dhe do t'i dërgojë kërkesën e mëposhtme HTTP në portën e 80-të:

MERRNI http://yandex.ru/ HTTP / 1.0

Prano: imazh / gif, imazh / x-xbitmap, imazh / jpeg, imazh / pjpeg, aplikacion / vnd.ms-excel, aplikacion / msword, aplikacion / vnd.ms-powerpoint, * / *

Prano-Gjuha: ru

Cookie: yandexuid = 2464977781018373381

Agjenti i përdoruesit: Mozilla / 4.0 (i pajtueshëm; MSIE 5.5; Windows 98)
Pritësi: yandex.ru

Referues: narod.ru

Proxy-Connection: Keep-Alive

Kërkesa dërgohet në mënyrë të pakriptuar formë teksti... Pjesa më e rëndësishme e kërkesës ndodhet në rreshtin e parë: Ky është lloji i kërkesës (GET), adresa URL e dokumentit të kërkuar (http://yandex.ru) dhe versioni i protokollit HTTP (HTTP / 1.0 ). Më poshtë janë parametrat e kërkesës. Çdo rresht korrespondon me një parametër. Rreshti fillon me emrin e parametrit, i ndjekur nga një dy pika dhe vlerën e parametrit.

Prano është lloji i të dhënave që shfletuesi mund të pranojë (i koduar MIME).

Accept-Language është gjuha e preferuar në të cilën shfletuesi dëshiron të pranojë të dhëna. User-Agent - lloji i programit që dërgoi kërkesën.

Host - Emri DNS (ose IP) i hostit të cilit i drejtohet kërkesa.

Cookie - cookie (të dhënat që u ruajtën nga serveri në diskun lokal të klientit kur vizituan këtë host herën e fundit).

Referues - hosti nga faqja e të cilit po dërgojmë kërkesën. Kështu, për shembull, nëse jemi në faqen http://narod.ru dhe klikojmë lidhjen http: //yandex.ru atje, atëherë kërkesa do të dërgohet te hosti yandex.ru, dhe në fushën e kërkesës së referuesit do të përmbajë emrin e hostit të narod.ru.

Grupi i parametrave të pyetjes nuk është i fiksuar. Përveç sa më sipër, mund të ketë parametra të tjerë.

Parametrat më interesantë janë referuesi dhe cookie. Këto parametra përdoren kryesisht për të vërtetuar përdoruesin në server.

GET kërkesë mund të përmbajë të dhëna të transmetuara nga klienti në server. Ato kalohen direkt përmes URL-së duke përdorur protokollin CGI. Të dhënat ndahen nga URL-ja me një "?" dhe janë të lidhura me shenjën "&":

MARR ?<параметр 1>=<значение 1>&<параметр 2>=<значение 2>&…

Ky lloj transferimi i të dhënave në server është i përshtatshëm, por ka kufizime në vëllim. Sasi shumë të mëdha të dhënash nuk mund të transferohen përmes URL-së. Për qëllime të tilla, ekziston një lloj tjetër kërkese: një kërkesë POST. Një kërkesë POST është shumë e ngjashme me një kërkesë GET, me ndryshimin e vetëm që të dhënat në kërkesën POST transmetohen veçmas nga vetë kreu i kërkesës:

Trupi i kërkesës duhet të ndahet nga kreu me një rresht bosh. Nëse serveri ndeshet me një varg të zbrazët në një kërkesë POST, atëherë gjithçka që e ndjek atë e konsideron trupin e kërkesës (të dhënat e transmetuara). Vini re sa më poshtë: formati i të dhënave në trupin e kërkesës POST është arbitrar. Megjithëse formati CGI përdoret më së shpeshti, ai nuk kërkohet. Për më tepër, një kërkesë POST nuk kërkon një trup kërkese dhe gjithashtu mund të transferojë të dhëna përmes një URL.

Përveç formatit CGI, ndonjëherë të ashtuquajturat. formati shumëpjesësh (formati i të dhënave të transmetuara përcaktohet nga parametri Content-Type):

Shfletuesit modernë përmbajnë mjete për zhvilluesit e uebit për të marrë disa informacione rreth dërgimit të kërkesave për postim. Nëse duhet të shikoni titujt e vetëm disa kërkesave, përdorimi i tyre do të jetë më i lehtë dhe më i shpejtë se metodat e tjera.

Nëse jeni duke përdorur Firefox-in, mund të përdorni tastierën e tij në internet. Ai shfaq titujt e kërkesës dhe përmbajtjen e skedarëve të skedarëve të transmetuar. Për ta nisur atë, hapni menunë e shfletuesit, klikoni në artikullin "Zhvillimi i Uebit" dhe zgjidhni "Konsola e Uebit". Në panelin që shfaqet, aktivizoni butonin "Rrjeti". Shkruani emrin e metodës - postoni në fushën e filtrit. Në varësi të qëllimeve tuaja, klikoni në butonin e formularit të dorëzimit kërkesë e kërkuar ose rifresko faqen. Konsola shfaq kërkesën e paraqitur. Klikoni mbi të me miun për të parë më shumë detaje.

Shfletuesi Google Chrome ka mjete të fuqishme korrigjimi. Për t'i përdorur ato, klikoni në ikonën me imazhin e një çelësi dhe më pas hapni artikullin "Konfiguro dhe menaxho Google Chrome". Zgjidhni "Tools" dhe hapni "Developer Tools". Në shiritin e veglave, zgjidhni skedën Rrjeti dhe paraqisni kërkesën tuaj. Gjeni kërkesën e kërkuar në listë dhe klikoni mbi të për të studiuar detajet.

Shfletuesi Opera ka mjete të integruara zhvilluesish për Opera Dragonfly. Për t'i hapur ato, kliko me të djathtën në faqen e kërkuar dhe zgjidhni artikullin e menysë së kontekstit "Inspect Element". Shkoni te skeda Rrjeti i Veglave të Zhvilluesve dhe dorëzoni kërkesën tuaj. Gjeni atë në listë dhe zgjeroni atë për të ekzaminuar titujt dhe përgjigjet e serverit.

Internet Explorer 9 përmban një komplet të quajtur F12 Developer Tools që ofron informacion të detajuar mbi kërkesat e ekzekutuara. Ato nisen duke shtypur butonin F12 ose duke përdorur menynë "Shërbimi" që përmban artikullin me të njëjtin emër. Për të parë kërkesën, shkoni te skeda "Rrjeti". Gjeni pyetjen e dhënë në përmbledhje dhe klikoni dy herë për të zgjeruar detajet.

Shfletuesit Chrome dhe Internet Explorer 9 përmbajnë mjete të integruara që ju lejojnë të ekzaminoni një kërkesë postimi të dorëzuar në detaje të plota. Për detaje të plota, përdorni ato ose Firefox me plugin i instaluar Zjarri. Është shumë i dobishëm për ekzaminimin e shpeshtë të pyetjeve, për shembull, kur korrigjoni faqet.

Nëse dëshironi të shihni një kërkesë të dërguar nga një program i ndryshëm nga një shfletues, përdorni korrigjuesin HTTP Fiddler. Ai funksionon si një server proxy dhe përgjon kërkesat nga çdo program, dhe gjithashtu ofron informacion shumë të detajuar mbi titujt dhe përmbajtjen e tyre.

Një URI (Uniform Resource Identifier) ​​është një varg kompakt karakteresh që përdoren për të identifikuar një burim abstrakt ose fizik. Një burim kuptohet si çdo objekt që i përket një hapësire të caktuar. Nevoja për një URI është kuptuar nga zhvilluesit e WWW që nga fillimi i sistemit, që nga ajo kohë supozohej të kombinonte në një mjedis të vetëm informacioni mjetet e përdorimit të metodave të ndryshme të identifikimit të burimeve të informacionit. U zhvillua një specifikim që përfshinte thirrjet drejt FTP, Gopher, WAIS, Usenet, E-mail, Prospero, Telnet, X.500 dhe sigurisht HTTP (WWW). Si rezultat, u zhvillua një specifikim universal që lejon zgjerimin e listës së burimeve të adresueshme për shkak të shfaqjes së skemave të reja.

Aty ku përdoren URI janë lidhjet e hipertekstit që shkruhen në etiketa dhe ... Grafikat e integruara trajtohen gjithashtu nga specifikimi URI në etiketa dhe ... Zbatimi i një URI për WWW quhet URL (Uniform Resource Locator). Më saktësisht, një URL është një zbatim i një skeme URI të hartuar në një algoritëm për aksesin e burimeve përmes protokolleve të rrjetit. Ekziston gjithashtu një URN (Emri Uniform i Burimit), i cili harton një URI në një hapësirë ​​emri në rrjet.

Shfaqja e URN-ve rrjedh nga dëshira për të adresuar pjesët MIME të një mesazhi postar. Parimet e ndërtimit të një adrese WWW. URI bazohej në parimet e mëposhtme:

· Zgjerimi - Skemat e reja të adresimit duhet të përshtaten lehtësisht në sintaksën ekzistuese URI.

· Plotësia - kurdoherë që është e mundur, ndonjë nga skemat ekzistuese duhet të përshkruhet duke përdorur një URI.

· Lexueshmëria - adresa duhej të ishte lehtësisht e lexueshme nga përdoruesi, gjë që është përgjithësisht tipike për teknologjinë WWW - dokumentet, së bashku me lidhjet, mund të zhvillohen në një redaktues teksti të rregullt.

Përpara se të shikoni skemat e ndryshme të përfaqësimit të adresave, këtu është një shembull i një URI të thjeshtë:

http://polyn.net.kiae.su/polyn/index.html

Dy pika paraprihet nga identifikuesi i skemës së adresave - "http". Ky emër ndahet me dy pika nga pjesa e mbetur e URI, e cila quhet shtegu. Në këtë rast, shtegu përbëhet nga adresa e domenit të makinës në të cilën është instaluar serveri HTTP dhe shtegu nga rrënja e pemës së serverit deri te skedari "index.html". Përveç shënimit të plotë URI të treguar më sipër, ekziston një i thjeshtuar. Ai supozon se në kohën kur përdoret, shumë parametra të adresës së burimit janë përcaktuar tashmë (protokolli, adresa e makinës në rrjet, disa elementë të rrugës). Sipas supozimeve të tilla, autori i faqeve të hipertekstit mund të tregojë vetëm adresën relative të burimit, d.m.th. një adresë në lidhje me burime të caktuara themelore.

Një URL (Uniform Resource Locator) është një nëngrup i skemave URI që identifikon një burim nga mënyra se si aksesohet (për shembull, "vendndodhja e tij në ueb") në vend që ta identifikojë atë me emër ose atribute të tjera të atij burimi. URL-ja përshkruan në mënyrë eksplicite se si të arrini te objekti.

Sintaksë: :, ku:

skema = "http" | "Ftp" | "Gopher" | "Mailto" | "Lajme" | "Telnet" | "Dosja" | "Njeriu" | "Info" | "Çfarë" | "Ldap" | "Wais" | ...- emri i skemës

skema – specifike – pjesë- varet nga skema. Vlerat heksadecimal mund të përdoren në pjesën specifike të skemës në formën:% 5f. Oktetet jo të printueshme duhet të kodohen: 00-1F, 7F, 80-FF.

Shembuj të URL-ve:

Http://www.ipm.kstu.ru/index.php

Ftp://www.ipm.kstu.ru/

URN (Uniform Resource Name) është një "urn:" private URI me një nëngrup të "namespace" që duhet të jetë unike dhe e pandryshueshme edhe kur burimi nuk ekziston më ose është i paarritshëm.

Supozohet se, për shembull, shfletuesi e di se ku ta kërkojë këtë burim.

Sintaksë: urn: hapësira e emrit: data1.data2, më shumë – të dhëna ku hapësira e emrave përcakton se si përdoren të dhënat pas ":"-së së dytë.

Shembull URN:

urna: ISBN: 0–395–36341–6

ISBN - klasifikues tematik për botuesit,

0–395–36341–6 - një numër specifik i subjektit të një libri ose reviste

Pas marrjes së URN-së, programi i klientit kthehet në ISBN (drejtoria "Klasifikuesi aktual për botuesit" në internet). Dhe ai merr një deshifrim të numrit të lëndës "0-395-36341-6" (për shembull: "kimia kuantike"). URN është relativisht i ri, HTML nuk përfshihet në versionet aktuale dhe shërbimet e direktoriumit nuk janë zhvilluar ende, kështu që URN nuk është aq i përhapur sa URL.

Skemat e adresimit të burimeve të internetit

Ekzistojnë 3 skema për adresimin e burimeve të internetit. Skema specifikon identifikuesin e saj, adresën e makinës, portin TCP, shtegun në drejtorinë e serverit, variablat dhe vlerat e tyre, etiketën.

Skema HTTP... Ky është faqosja bazë për WWW. Skema përmban identifikuesin e saj, adresën e makinës, portin TCP, shtegun në drejtorinë e serverit, kriterin e kërkimit dhe etiketën.

Sintaksë: http:// [:@][:][?]]

http- emri i qarkut

përdorues- Emri i përdoruesit

fjalëkalimin- fjalëkalimi i përdoruesit

mikpritës- emri i hostit

port- numri i portit

url – shteg- rruga për në skedar dhe vetë skedari

pyetje (<имя–поля>=<значение>{&<имя–поля>=<значение>) - varg pyetjesh

Si parazgjedhje, porta = 80.

Këtu janë disa shembuj të URI-ve për skemën HTTP:

http://polyn.net.kiae.su/polyn/manifest.html

Ky është lloji më i zakonshëm i URI-së që përdoret në dokumentet WWW. Emri i skemës (http) ndiqet nga një shteg që përbëhet nga adresa e domenit të makinës dhe adresa e plotë e dokumentit HTML në pemën e serverit HTTP.

Adresa IP mund të përdoret gjithashtu si adresë e makinës:

http://144.206.160.40/risk/risk.html

Nëse serveri HTTP funksionon në një port TCP të ndryshëm nga 80, kjo pasqyrohet në adresën:

http://144.206.130.137:8080/altai/index.html

http://polyn.net.kiae.su/altai/volume4 .html # së pari

Skema FTP... Kjo skemë lejon që arkivat e skedarëve FTP të adresohen nga programet e klientëve të World Wide Web. Në këtë rast, programi duhet të mbështesë protokollin FTP. Në këtë skemë, është e mundur të specifikoni jo vetëm emrin e skemës, adresën e arkivit FTP, por edhe ID-në e përdoruesit dhe madje edhe fjalëkalimin e tij.

Sintaksë: ftp: // [ [:@][:]

ftp- emri i qarkut

përdorues- Emri i përdoruesit

fjalëkalimin- fjalëkalimi i përdoruesit

mikpritës- emri i hostit

port- numri i portit

url – shteg- rruga për në skedar dhe vetë skedari

Si parazgjedhje, porti = 21, përdoruesi = anonim, fjalëkalimi = adresa e emailit.

Kjo skemë përdoret më shpesh për të hyrë në arkivat publike FTP:

ftp://polyn.net.kiae.su/pub/0index.txt

Në këtë rast, regjistrohet një lidhje në arkivin "polyn.net.kiae.su" me identifikuesin "anonim" ose "ftp" (qasje anonime). Nëse ka nevojë të specifikoni ID-në e përdoruesit dhe fjalëkalimin e tij, atëherë mund ta bëni këtë përpara adresës së makinës:

ftp: // askush: [email i mbrojtur]/ përdoruesit / lokale / pub

Në këtë rast, këta parametra ndahen nga adresa e makinës me simbolin @ dhe nga njëri-tjetri me dy pika.

Skema TELNET... Kjo skemë përdoret për të hyrë në burim në modalitetin e terminalit në distancë. Në mënyrë tipike, klienti thërret një program shtesë në telnet. Kur përdorni këtë skemë, duhet të specifikoni një ID të përdoruesit, lejohet një fjalëkalim.

Sintaksë: telnet: // [ [:@][:]/

telnet- emri i qarkut

përdorues- Emri i përdoruesit

fjalëkalimin- fjalëkalimi i përdoruesit

mikpritës- emri i hostit

port- numri i portit

Si parazgjedhje, porta = 23.

Shembull: telnet: // emri: [email i mbrojtur]

Në realitet, qasja kryhet në burimet publike, dhe identifikuesi dhe fjalëkalimi janë përgjithësisht të njohur, për shembull, ato mund të gjenden në bazat e të dhënave Hytelnet.

telnet: // i ftuar: [email i mbrojtur]

Siç mund ta shihni nga shembujt e mësipërm, specifikimi i adresës së burimit URI është mjaft i përgjithshëm dhe ju lejon të identifikoni pothuajse çdo burim në internet. Në këtë rast, numri i burimeve mund të zgjerohet duke krijuar skema të reja.

Shërbimi WWW

Shërbimi WWW (World Wide Web) - i projektuar për shkëmbimin e informacionit të hipertekstit, i ndërtuar sipas skemës "klient-server". Shfletuesi (Internet Explorer, Opera ...) është një klient me shumë protokolle dhe përkthyes HTML. Dhe si një përkthyes tipik, klienti kryen funksione të ndryshme në varësi të komandave (tags). Gama e këtyre funksioneve përfshin jo vetëm vendosjen e tekstit në ekran, por shkëmbimin e informacionit me serverin ndërsa analizohet teksti i marrë HTML, gjë që më qartë ndodh kur shfaqen imazhe grafike të ngulitura në tekst.

Serveri HTTP (Apache, IIS ...) trajton kërkesat e klientit për të marrë skedarin. Në fillim, shërbimi WWW bazohej në tre standarde:

· HTML (HyperText Markup Lan – guage) - gjuha e shënjimit të hipertekstit të dokumenteve;

· URL (Universal Resource Locator) - një mënyrë universale e adresimit të burimeve në rrjet;

· HTTP (HyperText Transfer Protocol) - një protokoll për shkëmbimin e informacionit të hipertekstit.

Skema e funksionimit të serverit WWW

Një server WWW është një pjesë e një globale ose intraneti që u mundëson përdoruesve të rrjetit të aksesojnë dokumentet e hipertekstit të vendosura në këtë server. Për të bashkëvepruar me serverin WWW, një përdorues i rrjetit duhet të përdorë softuer të specializuar - një shfletues (nga shfletuesi anglisht) - një shikues.

Le të hedhim një vështrim më të afërt në skemën e funksionimit të serverit WWW:

1. Përdoruesi i rrjetit lëshon një shfletues, funksionet e të cilit përfshijnë:

· Vendosja e lidhjes me serverin;

· Marrja e dokumentit të kërkuar;

· Shfaqja e dokumentit të pranuar;

· Përgjigja ndaj veprimeve të përdoruesit - qasja në një dokument të ri. Pas nisjes së shfletuesit, me komandën e përdoruesit, ose vendos automatikisht një lidhje me serverin e specifikuar WWW - dhe i dërgon atij një kërkesë për të marrë dokumentin e specifikuar.

2. Serveri WWW kërkon dokumentin e kërkuar dhe i kthen rezultatet në shfletues.

3. Shfletuesi, pasi ka marrë dokumentin, e shfaq atë tek përdoruesi dhe pret reagimin e tij. Opsionet e mundshme:

· Futja e adresës së një dokumenti të ri;

· Printimi, kërkimi, operacione të tjera në dokumentin aktual;

· Aktivizimi (shtypja) e zonave të veçanta të dokumentit të marrë, të quajtura lidhje dhe të shoqëruara me adresën e dokumentit të ri. Në rastin e parë dhe të tretë, bëhet ankim për një dokument të ri.

URI (Identifikues Uniform i Burimeve) është një identifikues i unifikuar (uniform) i burimit. URI është një varg karakteresh që ju lejon të identifikoni çdo burim: dokument, imazh, skedar, shërbim, kuti e-mail, etj. Para së gjithash, po flasim, natyrisht, për burimet e internetit dhe World Wide Web . Një URI ofron një mënyrë të thjeshtë dhe të zgjeruar për të identifikuar burimet. Zgjerimi i URI do të thotë që disa skema identifikimi ekzistojnë tashmë brenda një URI dhe do të krijohen të tjera në të ardhmen.

Marrëdhënia midis URI, URL dhe URN

Diagrami i Venit që tregon nëngrupet e skemës URI: URL dhe URN.

URI është ose një URL, një URN ose të dyja.

• Një URL është një URI që, përveç identifikimit të një burimi, gjithashtu ofron informacion për vendndodhjen e atij burimi.
• Një URN është një URI që identifikon vetëm një burim në një hapësirë ​​të caktuar emri (përkatësisht, në një kontekst specifik), por nuk tregon vendndodhjen e tij. Për shembull, urn URN: ISBN: 0-395-36341-1 është një URI që tregon një burim (libër) 0-395-36341-1 në hapësirën e emrit ISBN, por ndryshe nga një URL, URN nuk tregon vendndodhjen i atij burimi: nuk thotë se në cilin dyqan mund ta blini ose në cilën faqe interneti ta shkarkoni.

Meqenëse URI nuk tregon gjithmonë se si të merret një burim, ndryshe nga një URL, por vetëm e identifikon atë, kjo bën të mundur përshkrimin e burimeve duke përdorur RDF (Resource Description Framework) që nuk mund të merren nëpërmjet internetit (për shembull, një person, një makinë, qytet, etj.).

Histori

Në vitin 1990, në Gjenevë, Zvicër, brenda mureve të Këshillit Evropian për Kërkime Bërthamore, shkencëtari britanik Tim Berners-Lee shpiku URL-në e vendndodhjes së burimeve. Meqenëse URL-ja është nëngrupi më i përdorur i URI-ve, viti 1990 konsiderohet të jetë viti i lindjes së URI-së. Por, në mënyrë rigoroze, koncepti i URI u dokumentua vetëm në qershor 1994 në RFC 1630.

Versioni i ri i URI u përcaktua në 1998 në RFC 2396, në të njëjtën kohë fjala Universale në titull është ndryshuar në Uniformë.

Të metat

URL-ja ishte një risi themelore në internet, kështu që parimet e URI u dokumentuan për të siguruar përputhshmërinë e plotë të URL-së. Këtu vjen disavantazhi i madh i URI-ve, trashëgimi nga URL-të. Në një URI, si në një URL, mund të përdoret vetëm një grup i kufizuar karakteresh latine dhe shenjash pikësimi (madje më pak se në ASCII). Me fjalë të tjera, nëse duam të përdorim karaktere cirilike, ose hieroglife, ose, le të themi, karaktere specifike të gjuhës frënge, në URI, do të duhet të kodojmë URI-në në të njëjtën mënyrë që Wikipedia kodon URL-të me karaktere Unicode. Për shembull, një linjë si kjo:

https://ru.wikipedia.org/wiki/Cyrillic

URL e koduar si:

https://ru.wikipedia.org/wiki/%D0%9A%D0%B8%D1%80%D0%B8%D0%BB%D0%BB%D0%B8%D1%86%D0%B0

Meqenëse shkronjat e të gjitha alfabeteve, përveç alfabetit latin të përdorur në anglisht, i nënshtrohen një transformimi të tillë, URI-të me fjalë në gjuhë të tjera (madje edhe evropiane) humbasin aftësinë e tyre për t'u perceptuar nga njerëzit. Dhe kjo është në kundërshtim të madh me parimin e internacionalizmit, të shpallur nga të gjitha organizatat kryesore të internetit, përfshirë W3C dhe ISOC. Ky problem është krijuar për të zgjidhur standardin IRI (eng. Identifikuesi i Burimeve të Ndërkombëtarizuara) - identifikues të burimeve ndërkombëtare në të cilët do të ishte e mundur të përdoren karakteret e Unicode pa probleme dhe që nuk do të cenonin të drejtat e gjuhëve të tjera. Gjithashtu, krijuesi i URI-së, Tim Berners-Lee, tha se sistemi i emrave të domenit që qëndron në themel të URL-ve është një vendim i keq, duke detyruar burimet në një arkitekturë hierarkike që nuk është e përshtatshme për ueb-in e hipertekstit.

Struktura URI

URI = [skema ":"] hierarkike - pjesa [ "?" kërkesë] [pjesë "#"]

Në këtë hyrje:

Skema

skema për të hyrë në një burim (shpesh tregon një protokoll rrjeti), për shembull, http, ftp, skedar, ldap, mailto, urn

Hierarkike-pjesa

përmban të dhëna, të organizuara zakonisht në një formë hierarkike, të cilat, kur kombinohen me të dhëna në një komponent johierarkik hetim, shërbejnë për të identifikuar burimin brenda objektit të skemës URI. Zakonisht pjesë hierarkike përmban shtegun drejt burimit (dhe, ndoshta, përpara tij, adresën e serverit në të cilin ndodhet) ose identifikuesin e burimit (në rastin e URN).

hetim

ky komponent opsional URI është përshkruar më sipër.

Fragment

(gjithashtu një komponent opsional)

Ju lejon të identifikoni në mënyrë indirekte një burim dytësor duke iu referuar burimit parësor dhe duke specifikuar informacion shtesë. Një burim dytësor i identifikueshëm mund të jetë një pjesë ose nëngrup i primarit, një përfaqësim i tij, ose një burim tjetër i përcaktuar ose përshkruar nga një burim i tillë.

Analiza e strukturës së URI. Për të ashtuquajturin "parsing" të URI-ve (eng. analizë), domethënë, për të zbërthyer URI-të në pjesët e tyre përbërëse dhe identifikimin e tyre pasues, është më e përshtatshme të përdoret sistemi i shprehjes së rregullt, i cili tani është i disponueshëm në pothuajse të gjitha gjuhët moderne të programimit. Modeli i mëposhtëm rekomandohet për analizimin e URI-ve në RFC 3986:

Ky model përfshin 9 grupe të treguara më sipër me numra (për më shumë informacion mbi modelet dhe grupet, shihni Shprehjet e rregullta), të cilat analizojnë plotësisht dhe saktë një strukturë tipike URI, ku:

• grupi 2 - skema,
• grupi 4 - burimi,
• grupi 5 - rruga,
• grupi 7 - kërkesa,
• grupi 9 - fragment.

Kështu, nëse, duke përdorur këtë shabllon, analizojmë, për shembull, një URI të tillë tipike:

http://www.ics.uci.edu/pub/ietf/uri/#I ngjashëm

atëherë 9 grupet e mësipërme të shablloneve do të japin respektivisht rezultatet e mëposhtme:

1. http:
2. //www.ics.uci.edu
3. www.ics.uci.edu
4. / pub / ietf / uri /
5. asnjë rezultat
6. asnjë rezultat
7. #I lidhur
8. Të lidhura

Shembuj të URI-ve:

URI absolute

• https://ru.wikipedia.org/wiki/URI
• ftp://ftp.is.co.za/rfc/rfc1808.txt
• skedar: // C: \ Emri i përdoruesit.HostName \ Projektet \ Wikipedia_Articles \ URI.xml
• skedari: /// C: /file.wsdl
• skedari: ///Users/John/Documents/Projects/Web/MyWebsite/about.html
• ldap: /// c = GB?objektKlasa?një
• mailto: [email i mbrojtur]
• gllënjka: [email i mbrojtur]
• lajme: comp.infosystems.www.servers.unix
• të dhënat: tekst / e thjeshtë; grupi i karaktereve = iso-8859-7,% be% be% be
• tel: + 1-816-555-1212
• telnet: //192.0.2.16: 80 /
• urna: oazë: emrat: specifikimet: docbook: dtd: xml: 4.1.2

2) URI-të relative

• /relative/URI/with/absolute/path/to/resource.txt
• //example.org/scheme-relative/URI/with/absolute/path/to/resource.txt
• relative / shteg / në / burim.txt
• ../../../resource.txt
• burimi.txt
• /resource.txt#frag01
• # frag01

[vargu bosh] - është e barabartë me analizimin e identifikuesit nga analizuesi me rezultatin [vargu bosh], domethënë lidhja të çon në objektin e paracaktuar në skemën e paracaktuar

Shërbimi DNS

DNS qëndron për Domain Name System. Emrat e domeneve DNS janë sinonime për adresat IP, ashtu si emrat në librin e adresave të telefonit tuaj janë sinonime për numrat e telefonit. Ato janë simbolike, jo numerike; ato janë më të përshtatshme për memorizimin dhe orientimin; ato mbartin një ngarkesë semantike. www.irnet.ru → tabelat DNS → 193.232.70.36 Emrat e domeneve janë gjithashtu unikë, d.m.th. nuk ka dy emra domenesh identike në botë. Emrat e domenit, ndryshe nga adresat IP, janë opsionale, ato blihen shtesë.

Oriz. 2. Hierarkia në DNS.

Gjithashtu unike janë adresat që tregohen në zarfe kur dërgoni letra me postë të rregullt. Nuk ka shtete në botë me të njëjtin emër. Dhe nëse emrat e qyteteve përsëriten ndonjëherë, atëherë në kombinim me ndarjen në njësi më të mëdha administrative si rrethe dhe rajone, ato bëhen unike. Dhe emrat e rrugëve nuk duhet të përsëriten brenda të njëjtit qytet. Kështu, adresa, bazuar në emrat gjeografikë dhe administrativë, identifikon në mënyrë unike destinacionin. Domenet kanë një hierarki të ngjashme. Emrat e domeneve ndahen nga njëri-tjetri me pika: lingvo.yandex.ru, krkime.com.

DNS ka karakteristikat e mëposhtme:

• Administrata e shpërndarë... Njerëz ose organizata të ndryshme janë përgjegjëse për pjesë të ndryshme të hierarkisë.
• Shpërndarja e ruajtjes së informacionit... Çdo nyje e rrjetit duhet domosdoshmërisht të ruajë vetëm të dhënat që përfshihen në të fushën e përgjegjësisë, dhe (ndoshta) adresat serverët DNS rrënjë.
• Memoria e informacionit... Nyjë ndoshta ruajnë disa të dhëna jashtë zonës së tyre të përgjegjësisë për të reduktuar ngarkesën në rrjet.
• Struktura hierarkike, në të cilën të gjitha nyjet janë të kombinuara në një pemë, dhe secila nyje mund të përcaktojë në mënyrë të pavarur punën e nyjeve të nivelit të ulët, ose deleguar(transferoni) ato në nyje të tjera.
• Rezervimi... Për ruajtjen dhe mirëmbajtjen e nyjeve (zonave) të tyre janë (zakonisht) disa serverë, të ndarë fizikisht dhe logjikisht, gjë që garanton sigurinë e të dhënave dhe vazhdimin e punës edhe në rast të dështimit të njërit prej nyjeve.

Nivelet e domenit. Ekzistojnë tre nivele domenesh.

Domenet niveli i parë ose i lartë ndahen ne dy grupe:

1) Këto janë domene me përkatësi territoriale, për shembull: .ru .by .ua .de .us, etj. Domethënë, këto janë domene që i janë caktuar një vendi të caktuar. Me anë të tyre, për shembull, mund të përcaktoni se cilit shtet i përket një sajt i caktuar.

2) Grupi i dytë i domeneve të nivelit të parë janë domene të një qëllimi specifik. Për shembull: .com - për organizatat tregtare, .info - për faqet informative, .tv - për kompanitë televizive, etj. Këto domene mund të përdoren për të përcaktuar fokusin specifik të faqes. Ndonëse, me thënë të drejtën, së fundmi ato përdoren gjithnjë e më shumë në çdo mënyrë dhe shpesh nuk i përmbahen qëllimit të tyre.

Domenet e nivelit të parë nuk mund të përdoren si adresa e faqes suaj. Ato shërbejnë për të krijuar domene niveli i dytë , prandaj, në cilindo nga domenet e nivelit të parë, mund të regjistroni një domen të nivelit të dytë. Domeni i nivelit të dytë përbëhet nga elementët e mëposhtëm: www.site_name.domeni i nivelit të parë. Për shembull: www.webmastermix.ru. Rekomandohet përdorimi i emrave të domenit të nivelit të dytë për adresën e faqes. Ata lexohen dhe mbahen mend më së miri nga njerëzit, si dhe perceptohen nga motorët e kërkimit. Prandaj, shumica e faqeve kanë emra domenesh në këtë nivel.

Përveç kësaj, ka domene niveli i tretë ... Ato janë krijuar në bazë të domeneve të nivelit të dytë. Domeni i nivelit të tretë duket si ky: www.forum.webmastermix.ru. Pasi të keni regjistruar një domen të nivelit të dytë, mund të krijoni në mënyrë të pavarur mbi bazën e tij sa më shumë domene të nivelit të tretë që dëshironi. Ju mund të regjistroni një emër domaini për faqen tuaj duke përdorur shërbime speciale.

TEKNOLOGJI WEB: HTML, JAVASCRIPT

Pjesa e parë e bllokut didaktik të temës së mësipërme iu kushtua teknologjive të internetit. Tani po fillojmë të studiojmë teknologjitë e përdorura në World Wide Web, ose teknologjitë e internetit.

Së pari, ju duhet të kuptoni konceptet bazë të teknologjive të internetit: uebsajti dhe uebfaqja. Një faqe interneti është njësia minimale logjike e World Wide Web, e cila është një dokument që identifikohet në mënyrë unike nga një URL unike. Një faqe interneti është një koleksion i faqeve të internetit të lidhura tematikisht të vendosura në të njëjtin server dhe në pronësi të të njëjtit pronar. Në një rast të veçantë, një faqe interneti mund të përfaqësohet nga një faqe interneti e vetme. World Wide Web është koleksioni i të gjitha faqeve të internetit.

Baza e të gjithë World Wide Web është gjuha e shënjimit të hipertekstit HTML - Hyper Text Markup Language (Fig. 3). Shërben për shënimin logjik (semantik) të një dokumenti (faqe web). Ndonjëherë përdoret në mënyrë të pahijshme për të kontrolluar mënyrën se si përmbajtja e faqeve të internetit shfaqet në një ekran monitori ose kur jepet në një printer, gjë që bie ndesh thelbësisht me ideologjinë e adoptuar në World Wide Web.

Oriz. 3. Teknologjitë e internetit

Sheets Style Cascading (CSS) kanë për qëllim të kontrollojnë shfaqjen e përmbajtjes në faqet e internetit. CSS është i ngjashëm në shumë mënyra me stilet e përdorura në përpunuesin popullor të fjalëve, Word.

Gjuhët e skriptimit përdoren për të shtuar dinamizëm në faqet e internetit (menytë me zbritje, animacion). Gjuha standarde e skriptimit në rrjetin botëror është JavaScript. Thelbi i JavaScript është ECMAScript.

HTML, CSS, JavaScript janë gjuhë me të cilat mund të krijoni çdo faqe interneti komplekse. Por kjo është vetëm mbështetje gjuhësore, ndërsa në shfletues dokumentet përfaqësohen si një koleksion objektesh, shumë prej të cilave janë modeli i objektit të shfletuesit (BOM). Modeli i objektit të shfletuesit është unik për secilin model, dhe për këtë arsye lindin probleme gjatë ndërtimit të aplikacioneve ndër-shfletues. Prandaj, Konsorciumi i Uebit propozoi Modelin e Objektit të Dokumentit (DOM), i cili është mënyra standarde për të përfaqësuar faqet e internetit duke përdorur një koleksion objektesh.

Sintaksa e HTML-së moderne përshkruhet duke përdorur gjuhën e shënjimit të zgjeruar. XML do t'ju lejojë të krijoni gjuhët tuaja të shënjimit të ngjashme me HTML në formën e DTD-ve. Ka shumë gjuhë të tilla: për paraqitjen e formulave matematikore dhe kimike, njohuritë etj.

Siç mund ta shihni nga sa më sipër, të gjitha teknologjitë e uebit janë të ndërlidhura ngushtë. Kuptimi i këtij fakti do ta bëjë më të lehtë për të kuptuar qëllimin e një mekanizmi të veçantë të përdorur për krijimin e aplikacioneve në internet.

EMAIL

Posta elektronike (email, e-mail, nga posta elektronike angleze) është një teknologji dhe shërbimet që ajo ofron për dërgimin dhe marrjen e mesazheve elektronike (të quajtura "letra" ose "email") përmes një rrjeti kompjuterik të shpërndarë. Dallimi kryesor nga sistemet e tjera të mesazheve është mundësia e dërgimit të vonuar dhe një sistem i zhvilluar i ndërveprimit midis serverëve të pavarur të postës.

E-mail bën të mundur dërgimin dhe marrjen e mesazheve, përgjigjen automatikisht në letrat e korrespondentëve duke përdorur adresat e tyre, dërgimin e kopjeve të letrës tek disa marrës në të njëjtën kohë, përcjelljen e letrës së marrë në një adresë tjetër, përdorimin e emrave logjikë në vend të adresave (numerike ose emrat e domain), krijoni disa nënseksione të kutisë postare për të gjitha llojet e korrespondencës, përfshini skedarët e tekstit me shkronja, përdorni sistemin "reflektuesit e postës" për të zhvilluar diskutime me një grup korrespondentësh tuaj, etj. Për të dërguar një mesazh postar me e-mail, është e nevojshme të tregoni adresën e kutisë postare. Kutia postare e një pajtimtari e-mail është një zonë në hard diskun e një serveri postar të rezervuar për përdoruesin.

Zhvillimi i teknologjisë së internetit ka çuar në shfaqjen e protokolleve moderne të mesazheve, të cilat ofrojnë mundësi të mëdha për përpunimin e letrave, një shumëllojshmëri shërbimesh dhe lehtësinë e përdorimit. Kështu, për shembull, protokolli SMTP, i cili funksionon në parimin klient-server, është krijuar për të dërguar mesazhe nga një kompjuter te adresuesi. Në mënyrë tipike, qasja në serverin SMTP nuk mbrohet me fjalëkalim, kështu që çdo server i njohur në rrjet mund të përdoret për të dërguar email. Ndryshe nga serverët për dërgimin e letrave, qasja në serverë për ruajtjen e mesazheve është e mbrojtur me fjalëkalim. Prandaj, është e nevojshme të përdorni serverin ose shërbimin në të cilin ekziston llogaria. Këta serverë përdorin protokollet POP dhe IMAP, të cilat ndryshojnë në mënyrën se si i ruajnë mesazhet.

Në përputhje me protokollin POP3, mesazhet që mbërrijnë në një adresë specifike ruhen në server derisa të shkarkohen në kompjuter gjatë sesionit të ardhshëm. Pas shkarkimit të mesazheve, mund të shkëputeni nga rrjeti dhe të filloni të lexoni postën. Kështu, përdorimi i postës POP3 është më i shpejti dhe më i përshtatshëm për t'u përdorur.

Protokolli IMAP është i përshtatshëm për ata njerëz që përdorin një lidhje të përhershme me rrjetin. Mesazhet e marra nga adresa ruhen gjithashtu në server, por, ndryshe nga POP3, kur kontrolloni postën, së pari do të shkarkohen vetëm titujt e mesazheve. Vetë letra mund të lexohet pasi të keni zgjedhur titullin e mesazhit (ajo do të shkarkohet nga serveri). Është e qartë se me një lidhje dial-up, puna me postë duke përdorur këtë protokoll çon në humbje të panevojshme kohe.

Ekzistojnë disa protokolle për marrjen dhe transferimin e postës ndërmjet sistemeve me shumë përdorues.

Një përshkrim i shkurtër i disa prej tyre:

1) SMTP (Simple Mail Transfer Protocol)është një protokoll rrjeti i krijuar për transmetimin e postës elektronike në rrjetet TCP / IP, dhe transmetimi duhet domosdoshmërisht të iniciohet nga vetë sistemi transmetues.

MTA (Mail Transfer Agent) - agjenti i transferimit të postës - është komponenti kryesor i sistemit të transferimit të postës në Internet, i cili përfaqëson këtë kompjuter rrjeti për sistemin e postës elektronike në rrjet. Në mënyrë tipike, përdoruesit nuk punojnë me MTA, por me programin MUA (Mail User Agent) - një klient email. Parimi i ndërveprimit është paraqitur në mënyrë skematike në figurë.

2) POP, POP2, POP3 (Protokolli i Postës)- tre protokolle mjaft të thjeshta jo të këmbyeshme, të zhvilluara për dërgimin e postës tek një përdorues nga një server qendror i postës, fshirjen e tij prej tij dhe për identifikimin e një përdoruesi me emër / fjalëkalim. POP përfshin SMTP, i cili përdoret për të transferuar postën nga një përdorues. Mesazhet e postës mund të merren në formën e titujve, pa marrë të gjithë mesazhin.

Pas vendosjes së lidhjes, protokolli POP3 kalon në tre gjendje të njëpasnjëshme

1. Autorizimi që klienti kalon përmes procedurës së vërtetimit
2. Transaksioni i klientit merr informacion për gjendjen e kutisë postare, pranon dhe fshin postën.
3. Përditësimi i serverit fshin emailet e zgjedhura dhe mbyll lidhjen.

3) IMAP2, IMAP2bis, IMAP3, IMAP4, IMAP4rev1 (Protokolli i Qasjes së Mesazheve në Internet) - i ofron përdoruesit mundësi të pasura për të punuar me kuti postare të vendosura në një server qendror

o IMAP ruan postën në server në drejtoritë e skedarëve dhe gjithashtu i ofron klientit mundësinë për të kërkuar vargje në mesazhet e postës në vetë serverin.

o IMAP2 - përdoret në raste të rralla.

o IMAP3 - zgjidhje e papajtueshme, e pa përdorur.

o IMAP2bis - një zgjerim i IMAP2, i lejon serverët të analizojnë mesazhet në strukturën MIME (Zgjerime të postës në internet me shumë qëllime), ende në përdorim.

o IMAP4 është një IMAP2bis i ripunuar dhe i përmirësuar që mund të përdoret kudo.

o IMAP4rev1 - Zgjeron IMAP me një gamë të gjerë funksionesh, duke përfshirë ato të përdorura nga DMSP (Sistemi i shpërndarë i postës për kompjuterë personalë).

4) ACAP (Application Configuration Access Protocol) - një protokoll i zhvilluar për të punuar me IMAP4; shton mundësinë për të kërkuar abonimin dhe abonimin në tabelat e mesazheve, kutitë postare dhe përdoret për të kërkuar libra adresash.

5) DMSP (ose PCMAIL) është një protokoll për marrjen / dërgimin e postës, e veçanta e të cilit është se përdoruesi mund të ketë më shumë se një stacion pune në përdorim. Stacioni i punës përmban informacione të statusit për postën, direktorinë përmes së cilës bëhet shkëmbimi, i cili, kur lidhet me serverin, përditësohet në gjendjen aktuale në serverin e postës.

6) MIME është një standard që përcakton mekanizmat për dërgimin e të gjitha llojeve të informacionit përmes postës elektronike, duke përfshirë tekstin në gjuhë të ndryshme nga anglishtja, për të cilat përdoren kodime të karaktereve të ndryshme nga ASCII, si dhe përmbajtje binare 8-bit si fotografi, muzikë, filma dhe programe.

Punë e pavarur.

Ekzekutoni shembullin e dhënë në tekst (prospekte) dhe ruajeni në dosjen tuaj në desktopin tuaj.

9.2. Puna me një mësues:

Në rast vështirësish ose veprimesh të gabuara, kontaktoni mësuesin për të korrigjuar gabimet.

Në fund të orës së mësimit, tregoni mësuesit një raport mbi punën e kryer dhe merrni një kredi për këtë punë.

9.3. Kontrolli i nivelit fillestar dhe përfundimtar të njohurive:

Testimi në një kompjuter .

Informacione të ngjashme.

URI Uniform Identifikuesi i Burimeve. URI-të njihen me shumë emra adresa WWW, Identifikues Universal të Dokumentit, URI, dhe së fundi si një kombinim i Lokatorëve Uniform të Burimeve, URL-ve dhe Emrave Uniform të Burimeve, URN-ve. HTTP përcakton një URL thjesht si një varg të formatuar që identifikon një burim me emër, vendndodhje ose ndonjë karakteristikë tjetër. 3.2.1 Sintaksë e përgjithshme. URI-të në HTTP mund të paraqiten në formë absolute URI absolute ose URI relative në lidhje me disa URI të njohura bazë, në varësi të kontekstit të përdorimit të tyre. Dallimi midis dy formave është se URI-të absolute fillojnë gjithmonë me një emër skeme të kolonizuar.

URI absoluteURI relativeURI fragment Skema absoluteURI uchar e rezervuar relativeURI shtegu neto abs shtegu rel shtegu neto shtegu neto loc abs shtegu abs shtegu rel shtegu rel paramet e shtegut? shtegu i pyetjes fsegment segment fsegment 1 pchar segment pchar params param param param pchar skema 1 ALPHA DIGIT neto loc pchar? pyetje uchar rezervuar fragment uchar rezervuar pchar uchar uchar arratisje pa rezervë e parezervuar ALPHA DIGIT i sigurt ekstra kombëtar ikje HEX HEX rezervuar? ekstra i sigurt i pasigurt CTL SP kombëtare çdo OCTET përveç okteteve ALPHA, DIGIT, të rezervuara, shtesë, të sigurta dhe të pasigurta Detajet e plota të sintaksës dhe semantikës së URL-së përmbahen në RFC 1738 dhe RFC 1808. Shënimi normal Backus-Naur përfshin karaktere kombëtare që nuk lejohen në URL të vlefshme të përcaktuara nga RFC 1738, sepse serverët HTTP lejojnë një grup karakteresh të pa rezervuar për të përfaqësuar pjesën e rrugës rel të adresave, dhe për këtë arsye përfaqësuesit HTTP mund të marrin kërkesa URI që nuk përputhen me RFC 1738. Protokolli HTTP nuk imponon çdo kufizim në gjatësinë URI ... Serverët duhet të trajtojnë URI-të e çdo burimi, të çdo gjatësie, që ata shërbejnë, dhe ata duhet të trajtojnë URI-të me gjatësi të pakufizuar nëse u shërbejnë serverëve të bazuar në GET që mund të gjenerojnë një URI të tillë. Serveri DUHET të kthejë një kod statusi 414 të URI-së së kërkesës shumë e gjatë, kërkesa-URI shumë e gjatë nëse URI është më i gjatë sesa mund të trajtojë serveri.

Serverët duhet t'i kushtojnë vëmendje URI-ve që janë më të gjata se 255 bajt, sepse disa klientë ose përfaqësues të vjetër mund të mos i mbështesin saktë këto gjatësi. 3.2.2 URL HTTP. Skema Http përdoret për të hyrë në burimet e rrjetit duke përdorur protokollin HTTP. Ky seksion përcakton sintaksën dhe semantikën e përcaktuar nga skema për URL-të HTTP. http URL http shtegu i portit pritës abs pritës i një emri të vlefshëm domeni të makinës ose adresës IP në shënimin dhjetor me pika, siç përcaktohet në seksionin 2.1 të portit RFC 1123 DIGIT Nëse porta është bosh ose nuk specifikohet, përdoret porta 80. Kjo do të thotë që burimi është pritur në server, duke pritur për lidhje TCP në portin, hostin e specifikuar dhe URI i burimit të kërkuar është shtegu abs. Përdorimi i adresave IP në URL duhet të shmanget sa më shumë që të jetë e mundur nga RFC 1900. Nëse rruga abs nuk është e pranishme në URL, ajo DUHET të trajtohet si kur llogaritet burimi i kërkuar Request-URI. 3.2.3

Fundi i punës -

Kjo temë i përket seksionit:

Protokolli HTTP 1.1

Sipas RFC 1945, HTTP 1.0 ishte një përmirësim i këtij protokolli, ai lejonte një format si MIME të mesazheve që përmbanin meta-informacione për ato të transmetuara. Megjithatë, HTTP 1.0 nuk merrte parasysh veçoritë e punës me ato hierarkike. .. 1.1 ..

Nëse keni nevojë për materiale shtesë për këtë temë, ose nuk keni gjetur atë që po kërkoni, ju rekomandojmë të përdorni kërkimin në bazën tonë të punimeve:

Çfarë do të bëjmë me materialin e marrë:

Nëse ky material doli të jetë i dobishëm për ju, mund ta ruani në faqen tuaj në rrjetet sociale:

Tweet

Të gjitha temat në këtë seksion:

Terminologjia
Terminologjia. Lidhja e lidhjes. Kanal virtual shtresa e transportit, e vendosur midis dy programeve me qëllim të mesazhit të komunikimit. Moduli kryesor i komunikimit HTTP, i përbërë nga strukturore

Parametrat e protokollit
Parametrat e protokollit. Versioni HTTP.HTTP përdor një skemë kryesore numërimi. i vogël për të treguar versionin e protokollit. Strategjia e versionimit të protokollit është krijuar për të lejuar dërgimin

Krahasimi UR
Krahasimi i UR. I. Kur krahasojmë dy URI për të vendosur nëse ato përputhen apo jo, klienti DUHET të përdorë një krahasim oktet për oktet të ndjeshëm ndaj rasteve të vogla të këtyre URI-ve, me

Data e plotë
Data e plotë. Aplikacionet HTTP kanë lejuar historikisht tre formate të ndryshme për përfaqësimin e datave të orës së Diellit, 06 nëntor 1994 08 49 37 GMT RFC 822 i ndryshuar në RFC 1123 E diel, 06-Nëntor-94 08 49 37 GMT

Komplete karakteresh
Komplete karakteresh. HTTP përdor të njëjtin përkufizim të termit tabela e kodeve i cili është përcaktuar për MIME Termi libër kodesh përdoret për t'iu referuar një metode që përdor

Kodimet e përmbajtjes
Kodimet e përmbajtjes që kodojnë përmbajtjen. Vlera e kodimit të përmbajtjes tregon se cili transformim kodues është aplikuar ose do të zbatohet në objekt. Përdoret kodimi i përmbajtjes

Kodimet e transferimit
Kodimi i transferimit Kodimet e transferimit. Vlerat e kodimit të transferimit përdoren për të treguar një transformim kodues që është aplikuar ose duhet të zbatohet në njësinë-trup në mënyrë që të

Llojet e mediave
Llojet e mediave Llojet e mediave. HTTP përdor Llojet e mediave të Internetit në fushat e titullit Content-Type dhe Accept për të ofruar të dhëna të hapura dhe të zgjerueshme dhe shtypje të tipit. media-tip t

Kanonizim dhe vlera të paracaktuara të tekstit të tipit
Kanonizim dhe vlera të paracaktuara të tekstit të tipit. Llojet e mediave në internet regjistrohen në formë kanonike. V rast i përgjithshëm trupi i objektit të transmetuar nga mesazhi HTTP duhet të jetë

Llojet me shumë pjesë
Llojet me shumë pjesë. MIME ofron një numër llojesh shumëpjesësh që formojnë një paketë me një ose më shumë objekte brenda trupit të një mesazhi të vetëm. Të gjitha llojet shumëpjesëshe ndajnë një sintaksë të përbashkët, o

Shenjat e produktit
Shenjat e produktit. Shenjat e produktit përdoren për të mundësuar që aplikacionet e komunikimit të identifikohen me emrin dhe versionin e softuerit.

Vlerat e cilësisë
Vlerat e cilësisë. HTTP përdor numra të shkurtër me pikë lundruese për të treguar rëndësinë relative të peshës së parametrave të ndryshëm të negociuar. Pesha është një substancë e normalizuar

Etiketat e gjuhës Etiketat e gjuhës
Etiketat e gjuhës Etiketat e gjuhës. Etiketa gjuhësore identifikon një gjuhë natyrore të folur, shkruar ose të përdorur ndryshe nga njerëzit për të shkëmbyer informacione me njerëz të tjerë. Gjuhët e makinerisë janë

Etiketat e entitetit
Etiketat e entitetit. Etiketat e objekteve përdoren për të krahasuar dy ose më shumë objekte të të njëjtit burim të kërkuar. HTTP 1.1 përdor etiketat e objekteve në fushat e kokës ETag

Njësitë Range Njësitë Range
Njësitë Range Njësitë Range. HTTP 1.1 lejon një klient të kërkojë vetëm një pjesë të një objekti. HTTP 1.1 përdor njësitë e diapazonit në fushat e kokës Range dhe Content-Rang

Llojet e mesazheve
Llojet e mesazheve. Mesazhet HTTP ndahen në kërkesa klient-server dhe përgjigje server-to-klient. HTTP-message Kërkesë Përgjigje Mesazhet HTTP 1.1 Mesazhet e kërkesës dhe përgjigjes përdorin format gjenerik

Titujt e postimit
Titujt e postimit. Fushat e kokës HTTP, të cilat përfshijnë fushat e titullit të përgjithshëm, kokës së kërkesës, kokës së përgjigjes dhe kokës së entitetit-h

Trupi i mesazhit
Trupi i mesazhit. Trupi i trupit të mesazhit HTTP, nëse është i pranishëm, përdoret për të përcjellë trupin e objektit të lidhur me kërkesën ose përgjigjen. Trupi i mesazhit-trup është i ndryshëm nga trupi rreth

Gjatësia e mesazhit
Gjatësia e mesazhit. Kur një trup mesazhi është i pranishëm në një mesazh, gjatësia e atij trupi përcaktohet me një nga metodat e mëposhtme, sipas rendit të përparësisë 1. Çdo mesazh përgjigjeje që nuk duhet

Metoda Metoda
Metoda Metoda. Shenja e metodës specifikon metodën për t'u aplikuar në burimin e identifikuar nga Kërkesa-URI e kërkuar. Metoda është e ndjeshme ndaj rasteve. Metoda OPTIONS GET HEAD PO

Kodi i statusit dhe fraza shpjeguese
Kodi i statusit dhe fraza shpjeguese. Elementi Status-Code është një kod i plotë treshifror për rezultatin e një përpjekjeje për të kuptuar dhe ekzekutuar një kërkesë. Këto kode janë të përcaktuara plotësisht në seksion

Lidhjet e vazhdueshme
Lidhjet e vazhdueshme. Synimi. Përpara prezantimit të lidhjeve të vazhdueshme, një URL e veçantë u vendos për çdo kërkesë URL. Lidhja TCP, e cila rriti ngarkesën në HTTP që nga ajo kohë

Diskutim Negocim
Diskutim Negocim. Një server HTTP 1.1 mund të supozojë se një klient HTTP 1.1 nuk mbështet një lidhje të vazhdueshme nëse kreu i lidhjes i dërguar në kërkesë përmban kodin e lidhjes

Tubacionet e përpunimit të transportuesit
Përpunimi i transportuesit Tubacionet. Klienti që mbështet lidhjet e vazhdueshme di si të përpilojë kërkesat, domethënë të dërgojë disa kërkesa pa pritur një përgjigje për secilën

Konsiderata praktike
Konsiderata praktike. Serverët zakonisht kanë një vlerë të skadimit pas së cilës ata nuk mbajnë një lidhje joaktive. Proxies mund ta vendosin atë më lart

Kërkesat për transferimin e mesazheve
Kërkesat për transmetimin e mesazheve. Kërkesat e përgjithshme- Serverët HTTP 1.1 DUHET të mbajnë lidhje të vazhdueshme dhe të përdorin mekanizmat e kontrollit të rrjedhës TCP për të reduktuar të përkohshmen

Metoda të sigurta
Metoda të sigurta. Programuesit duhet të kuptojnë se softueri, kur ndërvepron me internetin, përfaqëson përdoruesin dhe programi duhet të informojë përdoruesin për çdo veprim.

Përkufizimi i kodeve të statusit
Përkufizimi i kodeve të statusit. Çdo kod statusi, i përshkruar më poshtë, përfshin një përshkrim të metodës ose metodave që mund të ndjekë dhe informacionin meta të kërkuar në përgjigje. 10.1 1xx - Informo

Hyni në Autentifikimin
Hyni në Autentifikimin. Për të vërtetuar aksesin, HTTP ofron një mekanizëm të thjeshtë reagimi ndaj sfidës që mund të përdoret nga

Skema bazë e vërtetimit
Skema bazë e vërtetimit. Skema bazë e vërtetimit bazohet në faktin se agjenti i përdoruesit duhet të provojë identitetin e tij duke përdorur një ID.

HTTP memorie
HTTP memorie. HTTP përdoret zakonisht për të shpërndarë sistemet e informacionit e cila performancë mund të përmirësohet duke përdorur përgjigjet e ruajtura në memorie. Protokolli HTTP 1.1 përfshin f

Korrektësia e cache-it
Korrektësia e cache. Cache e saktë duhet t'i përgjigjet kërkesës me përgjigjen më të përditësuar, që korrespondon me kërkesën, të ruajtur nga cache që plotëson një nga kushtet e mëposhtme 1. Ishte e vlefshme

Mekanizmat e kontrollit të cache
Mekanizmat e kontrollit të cache. Mekanizmat bazë të cache-së në HTTP 1.1, koha e skadimit dhe verifikuesi i specifikuar nga serveri janë direktiva të nënkuptuara

Paralajmërime të qarta të agjentëve të përdoruesit
Paralajmërime të qarta të agjentëve të përdoruesit. Shumë agjentë përdoruesi bëjnë të mundur që përdoruesit të anashkalojnë mekanizmat bazë të memorizimit. Për shembull, një agjent përdoruesi mund të lejojë p

Përjashtimet nga rregullat dhe paralajmërimet
Përjashtimet nga rregullat dhe paralajmërimet. Në disa raste, operatori i cache-it mund ta konfigurojë atë për të kthyer përgjigjet e skaduara, edhe nëse ato nuk kërkohen nga klienti.

Sjellja e kontrolluar nga klienti
Sjellja e kontrolluar nga klienti. Ndërsa serveri i origjinës dhe, në një masë më të vogël, cache-të e ndërmjetme dhe kontributi i tyre në moshën e përgjigjes janë burimi kryesor i informacionit rreth vjetërsimit

Modeli i vjetërsisë
Modeli i zhvlerësimit. Vjetërimi, specifikuar nga serveri... Memoria e memories HTTP funksionon më mirë kur memoriet e fshehta mund të shmangin plotësisht kërkesat për serverin e origjinës. Mekanizmi primar dhe

Vjetërsimi heuristik
Vjetërsimi heuristik. Meqenëse serverët e origjinës nuk ofrojnë gjithmonë kohë të qarta skadimi, memoriet e fshehta HTTP zakonisht caktojnë kohë skadimi heuristik duke përdorur algoritme që përdoren

Llogaritja e moshës
Llogaritja e moshës. Për të ditur nëse një objekt në cache është i freskët, cache duhet të dijë nëse është më i vjetër se data e freskisë. Hostët që përdorin HTTP, veçanërisht hos

Llogaritja e vjetërsisë
Llogaritja e vjetërsisë. Për të vendosur nëse një përgjigje është e freskët apo e vonuar, duhet të krahasojmë jetëgjatësinë e saj me moshën. Mosha llogaritet duke përdorur algoritmin e përshkruar në seksionin 13.2.3

Fazat e zhvillimit të traditës hesikaste
Fazat e zhvillimit të traditës hesikaste. Tradita hesikaste nga greqishtja. term - paqe, heshtje - një shkollë e caktuar e praktikës shpirtërore, e zhvilluar nga shekulli IV. deri më sot. 7 Në këtë kohë të gjatë udhëtimi