Протокол за пренос на хипертекст
Протоколот за пренос на хипертекст (англиски: Hypertext Transfer Protocol, скр. HTTP) е мрежен протокол. HTTP е основа за комуникација на World Wide Web.Создаден е како средство за објавување на HTML страници. Развивањето на стандардот е координирано од (IETF) Internet Engineering Task Force и World Wide Web Consortium.
За HTTP
HTTP е протокол за комуникација помеѓу опслужувачот и клиентот, кој функционира на принцип барање-одговор. HTTP клиентот, кој обично е прелистувач, иницира пренос на податоци по создавањето на TCP / IP врска со оддалечен опслужувач на одредена порта. Клиентот го поднесува HTTP барањето на опслужувачот. Опслужувачот кој содржи податоци, обезбедува ресурси, како што се HTML податотеки, или врши други работи во име на клиентот, и на крај враќа одговор порака на клиентот. А одговор на проектот содржи информации за статусот на барањето и може да содржи барања за клиентот.
Историја
HTTP бил измислен од страна на Тим Бернерс-Ли со адреси и HTML за да се создаде World Wide Web. Во тоа време, File Transfer Protocol (FTP) е веќе достапен за пренос на податотеки, но тој не можеше да поднесе поимот на формат на податоци како воведен од страна на повеќенаменското Интернет пошта Екстензии (мимика). Првата верзија на HTTP беше многу основни, но веќе обезбедија поддршка за MIME заглавја да се опише на податоци пренесени. Оваа прва верзија е сè уште се користи делумно во 2007 година, познат под името HTTP/0.9.
Во мај 1996 година, HTTP/1.0 на крајот стана стандард во IETF и е опишана во RFC 1945. Оваа верзија на HTTP поддржува виртуелни опслужувачи, кеш за управување и за идентификација.
Во јануари 1997 година, HTTP/1.1 е опишана во RFC 2068 ИЕТФ, RFC 2616 и во јуни 1999 година. Оваа верзија носи поддршка за pipelined трансфер и преговори за типот на содржина (формат на податоци, јазикот).
Од клиентот до опслужувачот
Врската помеѓу клиентот и опслужувачот не е секогаш лесна, може да има машини кои користат средно реле:
- А прокси (посредник или) да ги менувате реакции и барања кои ги добива и да управува со кеш на ресурси побара.
- А портал (или портал) е средство за измена на протокол се користи.
- А тунел пренесува нивните барања и одговори без никакви измени, или кеширање.
Метод
Страна на HTTP протоколот, методот е команда да одредува видот на барањето, односно да се каже, го прашува опслужувачот да се изврши некоја акција. Во општата акција се однесува на ресурс идентификувани од страна на URL-то што следи името на методот.
GET
Ова е најчестиот метод за барање ресурс. А ДОБИВАТЕ барање нема ефект на ресурси, би требало да биде можно да се повтори на барање без ефект.
HEAD
Овој метод бара само информација за ресурс, без да се бара ресурсот себе.
POST
Овој метод треба да се користи за додавање на нов извор (порака на форум или напис во едно мрежно место). На адреса се испорачува на адреса на ресурси во врска со новиот ресурс (како што се адреса на форум или мрежно место) и не ја отворам податотеката на новосоздадената ресурс.
ОПЦИИ
Овој метод овозможува комуникација опции за ресурс или опслужувачот воопшто.
CONNECT
Овој метод овозможува да се користи прокси како комуникациска тунел.
Трага
Овој метод бара од опслужувач за да се врати она што го добил со цел да ги тестираат и вршење дијагностика на врската.
=Ставете
Овој метод може да ја замени или да додадете ресурси на опслужувачот. На адреса дадена е дека на ресурс.
DELETE
Овој метод го отстранува ресурс од опслужувачот.
Овие последниве две методи обично бараат привилигиран пристап.
Некои опслужувачи овозможи алтернативни методи на управување со ресурсите на опслужувачот (на пр претпоставка).
Идентификација
HTTP овозможува идентификација на посетителот со испраќање име и лозинка. Има два модови: Основни и билтени (RFC 2617). Првиот метод го испраќа лозинка во текстот јасно, и затоа треба да се користи со HTTPS. Вториот начин ви дозволува идентификација без пренесување на лозинка во јасно. За идентификација е, сепак, често се изведуваат од страна на некоја апликација слој над HTTP.
Верзии
HTTP 0.9
На почетокот на World Wide Web, што беше планирано да додадете капацитет за содржината на HTTP преговори, цртање посебно на пантомима. Во меѓувреме, на HTTP 0.9 е крајно едноставно.
1. HTTP клиент врска2. Испраќање на GET методот барање3. HTTP опслужувач одговор4. опслужувачот затвора врската да го сигнализира крајот на одговор.
Пребарување:
ГЕТ / станица.html
GET методата е можно само една. опслужувачот признава дека се занимаваат со HTTP 0.9 верзија е дека не е одреден по URI.
Одговор:
<html><head><title> Пример </ title></ head><body>Ако ја изберете оваа е пример страница.
</ Body></ html>Како одговор на HTTP 0.9, опслужувачот испраќа содржини директно на одговорот, без метаподатоци. Никогаш не треба да се однесуваат добро за HTTP барањата од повисоко.
Не барај верзии пред 0,9 на HTTP: тие не постојат, бидејќи за HTTP 0.9 беше првично не бројот на верзијата. Го зеде наградата кога HTTP 1.0 е надвор.
HTTP 1.0
HTTP 1.0, опишан во RFC 1945 година, предвидува користење на заглавија инспириран од MIME. Врската на управување е идентична со HTTP 0.9: клиентот се поврзува, испраќа барање, опслужувачот одговара и ја затвора врска веднаш.
HTTP барање има следниот формат:Командната линија (команда, URL, протокол верзија)
Заглавието барање [празна линија] Барам тело
HTTP одговорите имаат следниот формат:
Статус линија (верзија, код-Reply-текст одговор)Како одговор на ова заглавје[празна линија]Одговор телоПребарување:
ГЕТ / станица.html HTTP/1.0Домаќин: example.comReferer: http://example.com/Корисникот Агент: CERN-LineMode/2.15 libwww/2.17b3
Верзијата на HTTP е одреден по URI. Во пријавата мора да се заврши со двојна линија (CRLFCRLF). HTTP 1.0 исто така поддржува и POST методи и главата. Таму е употребата на заглавјата инспириран од MIME за пренос на податоците:
ДомаќинотОдредува веб засегнати од прашањето, која е неопходна за опслужувачко вдомување на повеќе мрежни места на истата IP-адреса (името врз основа виртуелен домаќин, виртуелен хост име врз основа). Тоа е само насловот навистина важно.RefererСпецифицира адреса на документот што го даде линк до бараниот ресурс. Овој наслов му овозможува на администратори да се види таму каде што посетителите доаѓаат од.Корисникот АгентУкажува на софтверот што се користи за да се поврзиш. Тоа е обично прелистувач или роботот.
Одговор:HTTP/1.0 200 OKДатум: Fri, 31 ДЕКЕМВРИ 1999 23:59:59 GMTопслужувач: Apache/0.8.4Content-Type: text / htmlContent-Должина: 59Истекува на: чет, 1 јануари 2000 00:59:59 GMTПоследен-промена: пет, 9 август 1996 година 02:21:40 GMT
<title> Пример </ title>Ако ја изберете оваа е пример страница.
Во првиот ред се поставува статус HTTP код (200 во овој случај).
ДатумВремето во кое е генерирана порака.опслужувачУкажува на кој модел на HTTP опслужувач на одговори на барањето.Должина содржинаЈа одредува големината во бајти на ресурс.Content-TypeУкажува на MIME типот на ресурс.ИстекуваГо одредува времето после кое ресурси треба да се смета застарени овозможува прелистувачи за да се утврди колку долго да се задржи ресурс кеш.Последен ИзменетоПокажува последната модификација денот на бараниот ресурс.
HTTP 1.1
HTTP 1.1 е опишан од RFC 2616 кој го прави застарени RFC 2068. Разликата со HTTP 1.0 е подобро управување со кеш. Домаќинот на заглавието е задолжително во кверија.
Главните преокупации на првите две верзии на HTTP се прво на голем број на врски при вчитување на комплексни страница (кои содржат илјадници слики или анимации) и второ, на отворањето на време врска помеѓу клиентот и опслужувачот (воспоставување на TCP врска е време трипати повеќе од латенција помеѓу клиентот и опслужувачот). Експериментите на постојаните врски, сепак, беа извршени со HTTP 1.0 (вклучувајќи го и користењето на насловот Врската: Чувајте-Alive), но ова е завршена со HTTP 1.1.По default, HTTP 1,1 користи упорни врски, т.е. врската не е затворен веднаш по барањето, но уште е на располагање за нов пребарување. Ова е често нарекуван задржи-жив функционалност. Тоа исто така е дозволен на клиентот да испрати повеќе HTTP барања на истата врска без да се чека за одговор. Оваа функција се нарекува групирање. Постојани поврзувања овозможува побрзо вчитување на страниците со повеќе ресурси, со истовремено намалување на мрежата на товарот.
На управувањето со упорни врска се постапува од страна на поврзување насловот.
HTTP 1.1 поддржува содржина преговори. На HTTP 1.1 клиентот може да го придружуваат барањето за ресурс насловот укажува кои јазици и форматите за податоци најпосакувана. Овие заглавија, чии имиња почнуваат со-Прифати.
Дополнителни хедери се поддржани од страна на HTTP 1.1:ВрскаОвој наслов може да бидат испратени од страна на клиентот или опслужувачот и содржи список на имиња за одредување на опциите за користење со сегашната врска. Ако има опција параметри овие се специфицирани од страна на заглавието на истото име како опција (Не-Alive на пример, да одредите максималниот број на барања за врска). Кликнете на името е резервиран да се каже дека врската треба да биде затворена по обработката на тековната барање.ПрифатиОвој наслов листи на MIME типови на содржини прифатена од страна на клиентите. Ѕвездата карактер * може да се користи за одредување на сите видови / поттипови.Прифати-МножзнациОдредува карактерот енкодирања прифатени.Прифати-јазикОдредува јазици прифатени.
Редоследот на приоритетот за секоја опција (тип, кодирање или јазик) е определен од додате параметар q содржат децимална вредност помеѓу 0 (неприфатливо) и 1 (прифатливо) вклучени (3 цифри по запирката), еднаква на 1 стандардно .
Поддршка за постојаните врски, исто така, треба да работат во случаите каде што од големината на ресурси не е однапред познат (динамички генерирани од страна на ресурси на опслужувачот, надворешна текови на опслужувачот, ...).
За ова, назначен chunked трансфер кодирање се користи за пренос на ресурси piecewise последователни пред секоја линија од текст со давање на големината на тоа во хексадецимални. Преносот завршува кога парче од нула големина, каде што последната заглавја може да биде испратена.
Дополнителни хедери во врска со овој трансфер кодирање се:Трансфер-EncodingОдредува трансфер кодирање. Единствената вредност, дефинирана од RFC 2616 е chunked.
ТрејлерСписок на сите заглавија се појавува после последната трошка префрлени.ТЕИспратени од страна на клиентот да ја наведе содржината кодирање поддржана (Content-Encoding не е исто како трансфер-Кодирање chunked е нужно поддржан од страна на клиентите и опслужувачите за спроведување на HTTP/1.1 стандард), и одредува дали клиентот поддржува во Заглавието Кориснички шлепери со додавање на листата.
HTTPS
HTTPS (обезбедени со "С", или "безбедна ") е едноставен Комбинацијата на HTTP со слој на енкрипција како SSL или TLS.
Тоа им овозможува на посетителите да се потврди идентитетот на мрежното место кое се пристапува преку сертификат за автентикација. Тоа го гарантира доверливост и интегритет на податоците доставена од страна на корисникот (вклучувајќи информации внесени во форми) и се добива од опслужувачот.
Тоа е генерално се користи за онлајн финансиски трансакции: електронската трговија, интернет банкарство, брокерски онлајн, итн. Тоа е исто така се користи за пребарување на приватни податоци, како што се пораки, на пример.
По default, HTTPS опслужувачите се поврзани со TCP порта 443.
HTTPS и пиратеријата
Безбедноста на информациите пренесени преку HTTPS се заснова на употреба на алгоритам за шифрирање и на сертификатот за автентичност.
Претпоставувајќи дека корисниците ретко наведете протоколот тип во URL (HTTP е избрана по дифолт) и едноставно следете ги линковите, безбедносната истражувач разви напад од таков вид човек во средината да се заобиколат HTTPS енкрипција [1]. Напаѓачот се наоѓа помеѓу клиентот и опслужувачот и промена на линкот https: http:, па на клиентот праќа податоци преку обичен HTTP и HTTPS не. Овој тип на напад е претставен од Moxie Marlinspike на Blackhat конференција 2009 година [2]. Во текот на оваа конференција се претстави не само на функционирањето на напад, но исто така и некои статистика за потрошувачката. Тој успеал да се опорави стотици идентификатори, лични информации и броеви на кредитни картички во 24 часа, никој не се сомнева дека сегашните напади.
HSTS
Види детална статија Строга HTTP транспорт безбедност
Строги HTTP транспорт безбедност (HSTS) е механизам предложи безбедносна политика, дозволувајќи им на опслужувачот да го извести корисникот агенс (како прелистувач) компатибилен, тоа мора да комуницирате со неа на користење на безбедна врска (како Https). Политиката е соопштено на корисникот агент опслужувачот преку HTTP одговорот во заглавието поле со име "Строга-Превоз-безбедност". Политиката одредува на еден временски период за време на која и прелистувачот кој само што треба да пристапи до опслужувачот безбедно.
Пример за работа на HTTP
Ова е пример за разговор меѓу HTTP клиент и HTTP опслужувач на www.example.com, порта 80.
Клиент - прашање
GET /index.html HTTP/1.1Host: www.example.com
Опслужувач-одговор
HTTP/1.1 200 OKDate: Mon, 23 May 2005 22:38:34 GMTServer: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)Last-Modified: Wed, 08 Jan 2003 23:11:55 GMTEtag: "3f80f-1b6-3e1cb03b"Accept-Ranges: bytesContent-Length: 438Connection: closeContent-Type: text/html; charset=UTF-8
Надворешни врски
- „Историја на промената на HTTP“. W3.org. Посетено на 1 август 2010. (англиски)
- „Прблеми при изработка на HTTP“. W3.org. Посетено на 1 август 2010. (англиски)
- „Класични документи за HTTP“. W3.org. 14 мај 1998. Посетено на 1 август 2010. (англиски)