HTTP

от Уикипедия, свободната енциклопедия
Направо към: навигация, търсене
OSI модел
7. Приложен слой
NNTP • SIP • SSI • DNS • FTP • Gopher • HTTP • NFS • NTP • SMPP • SMTP • DHCP • SNMP • SSH • Telnet • Netconf • други...
6. Представителен слой
MIME • XDR • TLS • SSL
5. Сесиен слой
Named Pipes • NetBIOS • SAP • L2TP • PPTP
4. Транспортен слой
TCP • UDP • SCTP • DCCP • SPX
3. Мрежов слой
IP (IPv4, IPv6) • ICMP • IPsec • IGMP • IPX  • AppleTalk  • OSPF • RIP • BGP • IGRP • EIGRP
2. Канален слой
ATM • SDLC • HDLC • ARP • CSLIP • SLIP • PLIP • IEEE 802.3 • Frame Relay • ITU-T G.hn DLL • PPP • X.25 • Суич
1. Физически слой
EIA/TIA-232 • EIA/TIA-449 • ITU-T V-Series • I.430 • I.431 • POTS • PDH • SONET/SDH • PON • OTN • DSL • IEEE 802.3 • IEEE 802.11 • IEEE 802.15 • IEEE 802.16 • IEEE 1394 • ITU-T G.hn PHY • USB • Bluetooth • Хъб

Протокол за трансфер на хипертекст (англ.: 'hypertext transfer protocol', съкр. HTTP) е мрежов протокол, от приложния слой на OSI модела, за пренос на информация в компютърни мрежи. Създаден като средство за публикуване на HTML страници, протоколът довежда до формирането на Световната уеб мрежа. Разработването на протокола е било координирано от Уеб консорциума (World Wide Web Consortium) и IETF (Internet Engineering Task Force), завършвайки с публикуването на серия от заявления за обсъждане (RFC), от които RFC 2616 (от юни 1999) е със статут на стандарт и описва HTTP/1.1 — най-новата и с най-широка употреба HTTP версия.

Основни понятия[редактиране | edit source]

В HTTP протокола се използват понятия като клиент (обикновено това са Web-браузърите (или web навигаторите)- т.е. самите приложения, a не физически хостовете в мрежата) и сървър (това са Web-сървърите - т.е. самите приложения, а не хостовете в мрежата).

Методи на заявките[редактиране | edit source]

HTTP определя 8 различни клиентски метода за заявки:

  • HEAD — иска изпращане на заглавията отговарящи на посочения с URL ресурс. Отговорът на сървъра е идентичен с този на GET, но е с липсващо тяло. По този начин може да се вземе само метаинформацията, свързана с ресурса, спестявайки трансфера на целия файл.
  • GET — с него клиентът прави заявка за ресурс, зададен чрез URL. Могат да се изпращат и ограничено количество данни, закодирани директно в самия URL (отделени чрез въпросителен знак).
  • POST — позволява клиентът да изпрати данни на сървъра. Тази заявка обикновено се генерира при изпращането на уеб формуляр, а данните могат да бъдат: текст, написан от потребителя във формуляра; файл на клиентския компютър и др.
  • PUT — качва файл, който в бъдеще ще отговаря на посочения URL.
  • DELETE — изтрива посочения ресурс.
  • TRACE — сървърът връща получената заявка със статус OK. Позволява да се провери в какъв вид пристига заявката при сървъра и дали (и как) е била модифицирана по трасето от междинни прокси сървъри.
  • OPTIONS — сървърът трябва да отговори с поддържаните от него клиентски методи, съответстващи на зададения URL ,или с поддържаните от сървъра методи като цяло, ако е зададено * вместо URL.
  • CONNECT — използва се при комуникация през прокси.

Стандартът, описан в RFC2616, изисква HTTP сървърите да поддържат задължително GET и HEAD методите[1]. Повечето съвременни сървъри поддържат и POST метода.

Механизъм на действие[редактиране | edit source]

GET заявка на клиента[редактиране | edit source]

Браузърът изпраща GET заявка към сървъра, която съдържа необходимите данни за сървъра да я изпълни, в следния пример са обяснени най-съществените данни:

  • GET http://bg.wikipedia.org/wiki/HTTP --- достави мрежовият ресурс (файл , скрипт и т.н. които е асоцииран с този URL
  • Host: fi.wikipedia.org определя Интернет хоста и номера на порта на ресурса, който е заявен.
  • User-Agent: съдържа информация за приложението на клиент-хоста, извършващо заявката.
  • Referer: от коя страница е пристигнато на заявения ресурс (от търсачка, друг сайт, ако не е изрично забранено в настройките на браузъра)

Отговор на сървъра[редактиране | edit source]

Уеб сървърът изпраща ресурса, който е поискан, със следните заглавки:

  • статус код: обозначава успешното или неуспешно извършване на заявката.
  • Date: датата и часа на сървъра
  • Expires: „време на годност“ - времето, до което страницата е валидна, т.е. може да бъда „кеширана (запазена локално на клиента или друг прокси или кеш сървър“
  • Server: името на сървърното приложение и версията му
  • Content-type: тип на документа
  • Set-Cookie: запазва бисквитка (cookie), която бива върната към сървъра при последваща заявка

Изходният код на един сайт представлява чист текст, който се разпознава от уеб-браузъра и се интерпретира от него, за да излязат на екрана видимите обекти за потребителите — таблици, полета и т.н.

Сесии[редактиране | edit source]

HTTP е безсесиен протокол - това означава, че резултата на всяка следваща заявка не зависи от резултата на предишната и така всички клиенти получават равноправно еднакви ресурси. Тази функционалност би създала проблем например в един електронен магазин, където потребителите би трябвало да бъдат идентифицирани с различните си потребителски имена и покупки.

Съществуват различни способи за приложението на сесии в HTTP. Най-надеждният от тях е употребата на бисквитки (cookies). При този способ сървърът залага бисквитките на клиентите със Set-Cookie в хедъра.

Постоянни връзки[редактиране | edit source]

Във версиите 0.9 и 1.0 на HTTP, сървърът затваря връзката с клиента след всяка заявка. С версия 1.1. е въведен нов механизъм за поддържане на връзката наречен "keep alive", при който връзката може да бъде използвана многократно. Този тип постоянна връзка премахва забавянето, получено при установяването на TCP връзката след първата http заявка. Това свойство на протокола обикновено трябва изрично да бъде настроено на сървърния софтуер (напр. директивата Keep-Alive в Apache уеб сървъра

Източници[редактиране | edit source]

  1. RFC2616 раздел 5.1.1 - Метод