Протокол за пренос на хипертекст

(Пренасочено од HTTP)

Протоколот за пренос на хипертекст (англиски: Hypertext Transfer Protocol, скр. HTTP) е мрежен протокол. HTTP е основа за комуникација на World Wide Web. Создаден е како средство за објавување на HTML страници. Развивањето на стандардот е координирано од (IETF) Internet Engineering Task Force и World Wide Web Consortium.

HTTP-барање направено со telnet

За 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-то што следи името на методот.

Ова е најчестиот метод за барање ресурс. А ДОБИВАТЕ барање нема ефект на ресурси, би требало да биде можно да се повтори на барање без ефект.

Овој метод бара само информација за ресурс, без да се бара ресурсот себе.

Овој метод треба да се користи за додавање на нов извор (порака на форум или напис во едно мрежно место). На адреса се испорачува на адреса на ресурси во врска со новиот ресурс (како што се адреса на форум или мрежно место) и не ја отворам податотеката на новосоздадената ресурс.

ОПЦИИ

уреди
    Овој метод овозможува комуникација опции за ресурс или опслужувачот воопшто.

Овој метод овозможува да се користи прокси како комуникациска тунел.

Трага

уреди

Овој метод бара од опслужувач за да се врати она што го добил со цел да ги тестираат и вршење дијагностика на врската.

=Ставете

уреди

Овој метод може да ја замени или да додадете ресурси на опслужувачот. На адреса дадена е дека на ресурс.

Овој метод го отстранува ресурс од опслужувачот.

Овие последниве две методи обично бараат привилигиран пристап.

Некои опслужувачи овозможи алтернативни методи на управување со ресурсите на опслужувачот (на пр претпоставка).

Идентификација

уреди

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.com Referer: 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.4 Content-Type: text / html Content-Должина: 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 (обезбедени со "С", или "безбедна ") е едноставен Комбинацијата на HTTP со слој на енкрипција како SSL или TLS.

Тоа им овозможува на посетителите да се потврди идентитетот на мрежното место кое се пристапува преку сертификат за автентикација. Тоа го гарантира доверливост и интегритет на податоците доставена од страна на корисникот (вклучувајќи информации внесени во форми) и се добива од опслужувачот.

Тоа е генерално се користи за онлајн финансиски трансакции: електронската трговија, интернет банкарство, брокерски онлајн, итн. Тоа е исто така се користи за пребарување на приватни податоци, како што се пораки, на пример.

По default, HTTPS опслужувачите се поврзани со TCP порта 443.

HTTPS и пиратеријата

уреди

Безбедноста на информациите пренесени преку HTTPS се заснова на употреба на алгоритам за шифрирање и на сертификатот за автентичност.

Претпоставувајќи дека корисниците ретко наведете протоколот тип во URL (HTTP е избрана по дифолт) и едноставно следете ги линковите, безбедносната истражувач разви напад од таков вид човек во средината да се заобиколат HTTPS енкрипција [1]. Напаѓачот се наоѓа помеѓу клиентот и опслужувачот и промена на линкот https: http:, па на клиентот праќа податоци преку обичен HTTP и HTTPS не. Овој тип на напад е претставен од Moxie Marlinspike на Blackhat конференција 2009 година [2]. Во текот на оваа конференција се претстави не само на функционирањето на напад, но исто така и некои статистика за потрошувачката. Тој успеал да се опорави стотици идентификатори, лични информации и броеви на кредитни картички во 24 часа, никој не се сомнева дека сегашните напади.

Види детална статија Строга HTTP транспорт безбедност

Строги HTTP транспорт безбедност (HSTS) е механизам предложи безбедносна политика, дозволувајќи им на опслужувачот да го извести корисникот агенс (како прелистувач) компатибилен, тоа мора да комуницирате со неа на користење на безбедна врска (како Https). Политиката е соопштено на корисникот агент опслужувачот преку HTTP одговорот во заглавието поле со име "Строга-Превоз-безбедност". Политиката одредува на еден временски период за време на која и прелистувачот кој само што треба да пристапи до опслужувачот безбедно.

Пример за работа на HTTP

уреди

Ова е пример за разговор меѓу HTTP клиент и HTTP опслужувач на www.example.com, порта 80.

Клиент - прашање

уреди

GET /index.html HTTP/1.1 Host: www.example.com

Опслужувач-одговор

уреди

HTTP/1.1 200 OK Date: Mon, 23 May 2005 22:38:34 GMT Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux) Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT Etag: "3f80f-1b6-3e1cb03b" Accept-Ranges: bytes Content-Length: 438 Connection: close Content-Type: text/html; charset=UTF-8

Надворешни врски

уреди
  • „Историја на промената на HTTP“. W3.org. Посетено на 1 август 2010. (англиски)
  • „Прблеми при изработка на HTTP“. W3.org. Посетено на 1 август 2010. (англиски)
  • „Класични документи за HTTP“. W3.org. 14 мај 1998. Посетено на 1 август 2010. (англиски)