Протоколът Hypertext Transfer Protocol (HTTP) е комуникационен протокол от приложния слой и се използва за предаване на информация между възлите на световната мрежа (World Wide Web). Първоначално е бил проектиран за публикуване и променяне на HTML уеб страници, но използването му не се ограничава само до хипертекст – той може да се използва за като сървъри за имена и управление на разпределени системи.

При всяка HTTP транзакция има четири стъпки:
1. Браузерът установява връзката.
2. Браузерът изпраща заявка към сървъра.
3. Сървърът изпраща отговор на браузъра.
4. Връзката се прекратява.

В Интернет HTTP използва TCP като транспортен протокол, но не е ограничен до използването му в Интернет или други мрежи, а само изисква надежден и гарантиращ доставката протокол.

HTTP комуникация

При повечето случаи инициативата за HTTP комуникация е на потребителския агент, който заявява ресурс на сървъра-източник. В най-простия случай, се установява връзка между потребителския агент и сървъра-източник. В някои случаи нямаме директна връзка между потребителския агент и сървъра – източник. Между тях има един или повече посредници, такива като прокси сървъри (proxy servers) и шлюзове (gateways), Заявките и отговорите се препредават между посредниците. Прокси сървърът може да обработва съдържанието на данните и да ги модифицира съответно.

Паралелни връзки

HTTP протокола позволява на клиентите да отворят множество връзки и да извършват паралелно транзакции по тях. Страниците, съставени от много обекти, могат да се зареждат по-бързо, ако се съкрати мъртвото време (dead time) на една връзка. Закъсненията могат да се препокрият и по този начин за се заредят допълнителни обекти. Въпреки това паралелните връзки не винаги са бързи.

Постоянни (persistent) връзки

Основният логически аргумент да бъдат въведени постоянните връзки е, че клиентите често отварят връзки към един и същи сървър. Например, повечето от образите в една страница са от един сървър и хипервръзките към други обекти също са насочени към този сървър. Така, приложението което инициира HTTP заявка към сървър, едва ли ще направи повече заявки към същия този сървър в близко бъдеще

Недостатъците на паралелните връзки са следните:

• Всяка транзакция установява и прекратява нова връзка, което ни струва време и честотна лента.
• Всяка нова връзка намалява производителността поради бавното стартиране на TCP.
• Има практическо ограничение на броя на установените връзки.

Постоянните връзки имат следните предимства пред паралелните:

Намаляват закъсненията и натоварванията при установяване на връзки поддържат връзките в настроен режим и намаляват потенциалния брой на отворени връзки. Постоянните връзки могат да бъдат по-ефективни, когато са комбинирани с паралелни връзки. Днес много уеб приложения установяват малък брой паралелни връзки, всяка от които е постоянна.

Параметри на протокола

HTTP версия

HTTP използва <major>.<minor> схема за да покаже версията на протокола. По- нататъшната връзка се извършва съгласно възприетата политика за версията на протокола.
Числото <major> се увеличава когато има съществени промени в протокола, например при промяна на формата на съобщенията.
Числото <minor> се увеличава когато промените не засягат формата на съобщенията.
Стандартни идентификатори на ресурс (Uniform Resource Identifiers – URI)
Стандартните идентификатори на ресурс най-общо ги наричаме WWW адреси, по своята същност URI представляват низ от символи, който показва местонахождението и името на ресурс намиращ се на сървъра.
Стандартни HTTP указатели за намиране на ресурс (URL)
Схемата на URL (HTTP_URL = “http” “//” host [ ":" port ] [ abs_path ])
позволява да намерите мрежов ресурс използвайки протокола HTTP.

Описание на съобщенията на HTTP

Съобщенията на HTTP са прости, форматирани блокове от данни. Всяко съобщение съдържа или заявка от клиента, или отговор от сървъра. Различаваме три части: начална линия, описваща съобщението, блок от хедъри, съдържащи атрибути, и евентуално тяло, съдържащо данни.

Хедър на съобщението

Полето за хедър на HTTP съобщението ще изглежда като някое от следващите:

• Общи хедъри- използват се и от клиенти, и от сървъри; имат общо предназначение.
• Хедъри на заявките- специфични са за съобщенията-заявки, дават на сървърите допълнителна информация
• Хедъри за одобрение (Accept headers)- дават на клиентите възможност да уведомят сървърите за техните възможности и предпочитания: какво искат, какво могат да използват и какво не искат.
• Хедъри на отговорите (Response headers)- снабдяват клиентите с допълнителна информация.
• Хедъри на същностната информация (Entity headers)- съобщават на получателя какво да прави с тези обекти.
• Тяло на съобщението (Message body)- просто предава същностната информация
• Дължина на съобщението (Message length)- показва дължината на тялото, ако такова тяло е включено в съобщението.
• Безопасни и идемпотентни методи (Safe and idempotent methods)
• GET -  използва се за да се помоли сървъра да ви изпрати ресурс.
• HEAD -  позволява на клиента да получи метаинформация за обект, като не изисква цялото тяло с информацията да бъде предадено.
• OPTIONS -  позволява на клиента да определи опциите или изискванията свързани с
• ресурс или възможностите на сървър, без да извлича някакви ресурси.
• POST -  проектиран за изпращане на данни към сървъра.
• PUT – URI в заявката PUT идентифицира ресурса, който ще обработва приложения обект.
• DELETE -  изисква сървърът да изтрие ресурсът, определен с URI в заявката.
• TRACE -  позволява на клиентите да видят как тяхната заявка изглежда, когато накрая стигне до сървъра.

HTTP кеширане (HTTP caching)

Една от най-важните характеристики на HTTP е възможността за кеширане. Понеже HTTP е протокол базиран на разпределена информация, кеширането може съществено да увеличи неговата производителност. Има множество функции в HTTP 1.1, които поддържат кеширането. В повечето случаи клиентските заявки и отговорите на сървърите могат да бъдат кеширани за определено, приемливо време, и да бъдат използвани при бъдещи събития. Ако отговорът е в кеша и е валиден, няма нужда да изискваме друг отговор от сървъра.  Определяне времето за изтичане на срока на данните (Expiration mechanism) За да определим дали данните са свежи или не, е въведено време за изтичане на техния срок. Обикновено сървърът-източник дефинира това време за всяко съобщение. Механизъм за потвърждаване (Validation mechanism) Когато срокът на данните е изтекъл, има вероятност те все още да са валидни. За да се увери във валидността на отговора, кешът трябва да провери при сървъра източник дали отговорът все още може да бъде използван. В HTTP 1.1 се използват условни методи за тази цел. Когато сървърът-източник изпраща пълен отговор, той присъединява към него някакъв вид валидатор на съобщението. Този валидатор може да се използва след това. Клиентът (потребителски агент или прокси кеш) генерира условна заявка с кеш валидатора прикачен към нея. Сървърът преглежда съобщението и отговаря със специален код (обикновено 304, Not Modified) и без тяло. Този подход избягва изпращането на пълни отговори в случай, че отговорът не е променян. Последователност на обработката в кеша (Cache Processing Steps) Съвременните кеширащи устройства са изключително сложни. Те трябва да бъдат с голяма производителност и да поддържат разширените функции на HTTP и на други технологии. Но основните стъпки на техния алгоритъм са по-скоро прости. Основната последователност на обработка на HTTP GET съобщение в кеша се състои от седем стъпки.

1. Receiving – Кешът чете постъпващото от мрежата съобщение.
2. Parsing – Кешът прави синтактичен разбор на съобщението, извличайки URL и хедърите.
3. Lookup – Кешът проверява дали съществува локално копие на съобщението, и ако не съществува запазва такова копие.
4. Freshness check – Кешът проверява дали информацията в кеша е достатъчно свежа, и ако не е моли сървъра за промени.
5. Response creation – Кешът създава съобщение за отговор с нови хедъри и кешираното тяло.
6. Sending – Кешът изпраща отговора обратно на клиента по мрежата.
7. Logging – Кешът евентуално създава входна точка в log файла, където описва транзакцията.

Прокси сървъри

Уеб прокси сървърите са посредници, които извършват транзакции от името и за сметка на клиента. Без прокси сървъри, HTTP клиентите говорят директно с HTTP сървърите. Когато имаме разрешени прокси сървъри, клиентите разговарят с тях, а те от своя страна разговарят със сървърите. HTTP прокси сървърите са едновременно и уеб сървъри и уеб клиенти. Понеже HTTP клиентите изпращат заявки към прокси сървърите, прокси сървърите трябва да обработят тези заявки и да върнат отговор по същия начин, както уеб сървър. В същото време прокси сървърите от своя страна изпращат заявки към сървърите, т.е. те трябва да се държат като коректен клиент, изпращащ заявки и получаващ отговори. Прокси сървърът може да обслужва един клиент или да обслужва множество клиенти. Прокси сървърите, обслужващи само един клиент се наричат частни прокси сървъри (private proxies). Прокси сървърите за няколко клиента се наричат обществени (public proxies). Повечето прокси сървъри са обществени. Много по-евтино и лесно е да се администрира централизиран прокси сървър. Понякога се използват и частни прокси сървъри, които са качени директно на персоналния компютър на потребителя и разширяват функциите на неговия браузър и подобряват производителността.

Вижте също:

• SNMP (Simple Network Management Protocol)
• UDP протокол. Протоколът UDP предлага бързо, но ненадеждно доставяне на съобщения между приложения
• TCP (Transmission Control Protocol)
• Бизнес софтуер и системи за управление
• Програмиране на бизнес софтуер за управление на търговията, бизнеса и продукцията