Все про HyperText Transfer Protocol

Содержание

Hypertext Transfer Protocol Secure

Читайте также:

  1. Application Protocols Прикладные протоколы
  2. B) Transference based on contiguity
  3. Difference of two meanings or transfer by contrast when the two objects are opposed – E.g.: You are so punctual!
  4. HTTP — HyperText Transfer Protocol
  5. Humoral Immunity But Not Cellular Immunity Is Transferred with Antibody
  6. HyperText Transfer Prоtocоl
  7. Is transference of an idea expressed by a definite grammatical category in the SL by a different grammatical category of the TL.
  8. Metonymy is transference of a name of one object to another object. Metonymic transference of names is based upon the principle of conti­guity of the two objects.
  9. PROTOCOL
  10. The Revision of Conventions and Recommendation. Protocols
  11. TRANSFERENCE BASED ON CONTIGUITY. METONOMY

HTTPS (Hypertext Transfer Protocol Secure) — расширение протокола HTTP, поддерживающее шифрование, порт: 443/TCP. Данные, передаваемые по протоколу HTTPS, «упаковываются» в криптографический протокол SSL[31] или TLS[32], тем самым обеспечивается защита этих данных. В отличие от HTTP, для HTTPS по умолчанию используется TCP-порт 443.

Система была разработана компанией Netscape Communications Corporation, чтобы обеспечить аутентификацию и защищённое соединение. HTTPS широко используется в мире Веб для приложений, в которых важна безопасность соединения, например, в платежных системах.

HTTPS поддерживается всеми популярными браузерами.

HTTPS не является отдельным протоколом. Это обычный HTTP, работающий через шифрованные транспортные механизмы SSL и TLS. Он обеспечивает защиту от атак, основанных на прослушивании сетевого соединения — от снифферских атак и атак типа man-in-the-middle[33] при условии, что будут использоваться шифрующие средства и сертификат[34] сервера проверен и ему доверяют.

По умолчанию HTTPS URL использует 443 TCP-порт (для незащищённого HTTP — 80). Чтобы подготовить веб-сервер для обработки https-соединений, администратор должен получить и установить в систему сертификат для этого веб-сервера. Сертификат состоит из 2 частей (2 ключей) — public и private. Public-часть сертификата используется для зашифровывания трафика от клиента к серверу в защищённом соединении, private-часть — для расшифровывания полученного от клиента зашифрованного трафика на сервере. После того как пара ключей приватный/публичный сгенерированы, на основе публичного ключа формируется запрос на сертификат в Центр сертификации[35], в ответ на который ЦС высылает подписанный сертификат. ЦС, при подписывании проверяет клиента, что позволяет ему гарантировать что держатель сертификата является тем, за кого себя выдаёт (обычно это платная услуга) .

Существует возможность создать такой сертификат, не обращаясь в ЦС. Такие сертификаты могут быть созданы для серверов, работающих под Unix, с помощью таких утилит, как ssl-ca от OpenSSL или gensslcert от SuSE. Подписываются такие сертификаты этим же сертификатом и называются самоподписанными (self-signed). Без проверки сертификата каким-то другим способом (например, звонок владельцу и проверка контрольной суммы сертификата) такое использование HTTPS подвержено атаке man-in-the-middle.

Эта система также может использоваться для аутентификации клиента, чтобы обеспечить доступ к серверу только авторизованным пользователям. Для этого администратор обычно создаёт сертификаты для каждого пользователя и загружает их в браузер каждого пользователя. Также будут приниматься все сертификаты, подписанные организациями, которым доверяет сервер. Такой сертификат обычно содержит имя и адрес электронной почты авторизованного пользователя, которые проверяются при каждом соединении, чтобы проверить личность пользователя без ввода пароля.

В HTTPS для шифрования используется длина ключа 40, 56, 128 или 256 бит. Некоторые старые версии браузеров используют длину ключа 40 бит (пример тому — IE, версий до 4.0), что связано с экспортными ограничениями в США. Длина ключа 40 бит не является сколько-нибудь надёжной. Многие современные сайты требуют использования новых версий браузеров, поддерживающих шифрование с длиной ключа 128 бит, с целью обеспечить достаточный уровень безопасности. Такое шифрование значительно затрудняет злоумышленнику поиск паролей и другой личной информации.

| следующая лекция ==>
HyperText Transfer Prоtocоl | Механизм виртуальных хостов

Дата добавления: 2014-01-15 ; Просмотров: 396 ; Нарушение авторских прав? ;

Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет

Протокол HTTP — что такое HyperText Transfer Protocol

Протокол HTTP

Протокол HTTP или HyperText Transfer Protocol это главный прокол сервиса Интернет WWW (всемирной паутины). Основная задача протокола, обеспечить передачу гипертекста в сети. В протоколе точно описывается формат сообщений, для обмена клиентов и серверов.

Описан протокол HTTP в RFC 2616(HTTP1.1).

Основа протокола обеспечить взаимодействие клиента и сервера по средством одного ASCII-запроса, и следующего на него ответа в стандарте RFC 822 MIME.

На практике протокол HTTP работает на основе TCP/IP порт 80, но можно настроить и по-другому. И хоть TCP/IP не является обязательным, он остается предпочтительным, так как берет на себя разбиение и сборку сообщений на себя и не «напрягает» ни браузер, ни сервер.

Следует отметить, что протокол HTTP может использоваться не только в веб-технологиях, но и других ООП приложениях (объективно-ориентированных).

Основой веб-общения клиент-сервер является запрос. Запрос отправляется при помощи URL– единого указателя ресурсов Интернет. Напомню, что такое URL адрес.

Понятная и простая структура URL состоит из следующих элементов:

Примечание: Протокол http это протокол для простых, не защищенных соединений. Защищенные соединения работают по протоколу https. Он более безопасен для обмена данными.

Методы HTTP запросов

Один из параметров URL, определяет название хоста, с которым мы хотим общаться. Но этого мало. Нужно определить действие, которое нужно совершить. Сделать это можно при помощи метода определенного протоколом HTTP.

Методы HTTP

  • Метод/Описание
  • HEAD/Прочитать заголовок веб-страницы
  • GET/Прочитать веб-страницу
  • POST/Добавить к веб-странице
  • PUT/Сохранить веб-страницу
  • TRACE/Отослать назад запрос
  • DELETE/Удалить веб-страницу
  • OPTIONS/Отобразить параметры
  • CONNECT/Зарезервировано для будущего использования

Разберем методы HTTP подробнее

Метод GET. запрашивает страницу (файл, объект), закодированную по стандарту MIME. Это самый употребляемый метод. Структура метода:
GET имя_файла HTTP/1.1

Метод HEAD. Этот метод запрашивает заголовок сообщения. При этом страница не загружается. Этот метод позволяет узнать время последнего обновления страницы, что нужно для управления КЭШем страниц. Этот метод позволяет проверить работоспособность запрашиваемого URL.

Метод PUT. Этот метод может поместить страницу на сервер. Тело запроса PUT включает размещаемую страницу, которая закодирована по MIME. Это метод требует идентификации клиента.

Метод POST. Этот метод добавляет содержимое к уже имеющейся странице. Используется, как пример, для добавления записи на форум.

Метод DELETE. Этот метод уничтожает страницу. Метод удаления требует подтверждения прав пользователя на удаление.

Метод TRACE. Этот метод отладки. Он указывает серверу отослать запрос назад и позволяет узнать, искажается или нет, запрос клиента, вернувшись от сервера.

Метод CONNECT – метод резерва, не используется.

Метод OPTIONS позволяет запросить свойства сервера и свойства любого файла.

В общении клиента и сервера «запрос-ответ», сервер обязательно генерирует ответ. Это может быть веб-страница или строку состояния с кодом состояния. Код состояния вам хорошо известен. Один из кодов известный код 404 –Страница не найдена.

Группы кодов состояния

1хх: Готовность сервера, Код 100 – сервер готов обрабатывать запросы клиента;

  • Код 200 – запрос обработан успешно;
  • Код 204 – Содержимого нет.
  • Код 301 – Запрашиваемая страница перенесена;
  • Код 304 – Страница в КЭШе еще актуальна.

4хх: Ошибка клиента.

  • Код 403 – Ошибка доступа;
  • Код 404 – Страница не найдена.

5хх: Ошибки сервера

  • Код 500 – Ошибка сервера внутренняя;
  • Код 503 – Предпринять попытку запроса позже.

HTTP протокол: основные правила Интернета, которые должен знать каждый веб-разработчик. Как браузер взаимодействует с сервером.

Что нужно знать про HTTP протокол веб-разработчику. Правила HTTP протокола

Привет, читатель блога ZametkiNaPolyah.ru! Продолжим знакомиться с протоколом HTTP в рубрике Cерверы и протоколы и ее разделе HTTP протокол. Данная запись является завершающей в цикле заметок по протоколу HTTP, после нее я подготовлю навигацию и, возможно, будут некоторые записи, связанные с протоколом HTTP, но не имеющие непосредственного к нему отношения. В принципе, эта запись поможет тебе понять, как работает HTTP протокол, а если нужны будут подробности — переходи по ссылкам, которые я для тебя расставил по всей статье.

Всё, что тебе нужно знать про HTTP протокол

Что такое HTTP протокол?

Давайте дадим определение тому, что такое HTTP протокол, но, прежде чем дать определение термину HTTP протокол, давайте разберемся со словом протокол. Слово протокол переводится с греческого дословно, как первый и клей. В древности это был листок, который клеился к свитку и на нем автор писал свое имя, дату написания и прочую никому ненужную информацию, вернее, служебную. Почему я говорю ненужную? Да потому, что рядовому обывателю интереснее само содержание свитка, а не то, кто его написал. Так и в HTTP протоколе: среднестатистическому пользователю вообще неинтересно как он получает страницы сайта, он просто открывает свой браузер. Еще одно определение слова протокол – это алгоритм, либо последовательность действий. Протокол – это свод правил и предписаний, которые регламентируют то или иное мероприятие. Протокол передачи данных – это стандарт, описывающий правила взаимодействия функциональных блоков при передаче данных.

Итак, мы определились, что HTTP – это протокол передачи данных, но что означает аббревиатура HTTP? HTTP или HyperText Transfer Protocol – это протокол передачи гипертекста. А теперь я приведу наиболее интересные определение HTTP протокола, которые когда-либо встречал.

HTTP протокол – это правила дорожного движения в интернете, только если в жизни люди могут не соблюдать правила дорожного движения и им за это ничего не будет, то несоблюдение правил HTTP протокола ведет к тому, что пользователь не сможет работать в интернете.

HTTP протокол – это протокол передачи данных седьмого уровня модели OSI, работающий на основе технологии клиент-сервер.

HTTP протокол – это абстракция над третьи и четвертым уровнем эталонной модели, расширяющая возможности коммуникаций между людьми.

HTTP протокол – изначально простой протокол передачи гипертекста, по которому сейчас можно передавать все, что угодно.

HTTP протокол – это транспорт для других протоколов, например, так как JSON.

HTTP протокол – это технология, которую должен понимать любой веб-разработчик.

Что же, я думаю, мы разобрались с тем, что такое HTTP протокол и можем теперь посмотреть, где он используется.

Для чего используется HTTP протокол

Скажу прямо HTTP протокол – это основа интернета, точнее не так, это та основа, которую видит конечный потребитель: посетители сайтов. Поэтому HTTP протокол в интернете везде. Фраза странно звучит, но другой я придумать не смог. Читая новости на сайте, вы используете HTTP протокол. Слушая музыку Вконтакте, вы используете HTTP протокол. Когда вы смотрите видео на YouTube – вы используете HTTP протокол. Когда вы играете в браузерную игру, вы тоже используете HTTP протокол. Поэтому я и пишу, что HTTP протокол используется везде в интернете. Без него вы бы не смогли и этот текст прочитать. Подведем итог: HTTP протокол используется для передачи данных в интернете, изначально он использовался для передачи HTML документов, но сейчас он позволяет передавать различный контент и различные типы данных.

Характеристики HTTP протокола

Давайте перечислим технические характеристики HTTP протокола:

  1. HTTP протокол работает по технологии клиент-сервер.
  2. HTTP протокол относится к седьмому уровню модели OSI.
  3. HTTP протокол относится к семейству протоколов TCP/IP.
  4. Для передачи данных по протоколу HTTP используется порт 80 TCP или 8080.
  5. Спецификация протокола RFC 2616.
  6. Для идентификации ресурса HTTP протокол использует URI (читай про URI в HTTP).
  7. HTTP протокол не имеет промежуточных состояний между запросом и ответом, конечно, клиент может получить ответ с кодом 100, но это ведь уже ответ, а не промежуточное состояние.
  8. HTTP протокол синхронный, но позволяет клиенту отправлять несколько запросов подряд, не дожидаясь ответа сервера, при условии, что сервер даст ответы на запросы в том порядке, как они приходили.

Это лишь часть технических характеристик протокола, но на мой взгляд, самых важных характеристик для понимания его сути.

HTTP протокол работает по принципу клиент-сервер

Да, HTTP протокол работает по принципу клиент-сервер. Самый простой пример, что приходит мне сейчас в голову, дабы объяснить суть взаимодействия клиент-сервер, это пример покупателя и продавца в магазине. Покупатель приходит в магазин и говорит продавцу: Здрасти!. Если продавец грубый, он отвечает: забор покрасти!. Дальше покупатель улыбается, стоит, смотрит на витрину и выбирает: чего бы ему купить. А в это время продавец стоит и молчаливо ждет, пока клиент выберет. Клиент сделал выбор и говорит продавцу: а дайте мне вон ту коричневую хрень, что стоит на верхней полке в дальнем углу. Продавец говорит: щас. После чего берет табурет ставит его в дальний угол, снимает с полки коричневую хрень и несет покупателю. Покупатель берет коричневую хрень, отдает деньги и уходит. А продавец, получив деньги, кладет их в кассу.

Суть этой истории в том, чтобы показать взаимодействие клиент-сервер. Клиент (в данном случае покупатель) полностью управляет развитием событий, то есть сервер (в нашем примере продавец) ни в коем случае сам не устанавливает контакт, он терпеливо ждет действий клиента и каким-то образом на них реагирует. Я привел самый простой пример. Но его можно и усложнить, например, покупатель дает сто рублей, а коричневая хрень стоит 90, в этом случае продавец даст клиенту сдачу. Продавец мог отреагировать на слова клиента: Здрасти!, как-нибудь по-другому. Или коричневая хрень могла быть не для продажи или для продажи, но только для особых клиентов. Я это веду к тому, что HTTP протокол – это протокол передачи данных основанный на взаимодействие клиент-сервер и он, в принципе, довольно полно описывает алгоритмы действия как для клиента, так и для сервера в различных ситуациях.

История HTTP: стандарты HTTP протокола

Давайте теперь рассмотрим историю HTTP протокола на его стандартах.

  1. Стандарт HTTP/0.9 – версия протокола HTTP9 была разработана в 1991 году в ЦЕРН Тимом Бернерсом-Ли. Тим разработал HTTP протокол для облегчения доступа и создания навигации при помощи гипертекста. Стандарт HTTP/0.9 содержит в себе основы синтаксиса и семантики протокола HTTP.
  2. В 1996 году был выпущен информационный документ RFC 1945 (стандарт HTTP/1.0).
  3. В 1997 году была выпущена версия протокола HTTP1: был разработан стандарт HTTP/1.1 и описан он в документе RFC 2068. В 1999 году был доработан стандарт HTTP/1.1 (именно стандарт HTTP/1.1). На данный момент большинство приложений для своей работы используют HTTP протокол версии 1.1. Кстати, HTTP приложения могут себя идентифицировать, посылая информацию о себе в заголовке.
  4. 2015 году была опубликована финальная версия черновика протокола HTTP 2, это еще не стандарт, но черновик нам «показывает» куда будет двигаться развитие интернета.

Клиенты HTTP протокола

Самым распространенным примером клиента HTTP протокола является браузер, вот самые популярные клиенты HTTP протокола:

  • Google Chrome;
  • Mozilla FireFox;
  • Opera;
  • Internet Explorer;
  • Яндекс Браузер;
  • Safari.

Часто вместо термина клиент вы можете услышать агент пользователя, знайте, что HTTP протокол не делает никаких различий между терминами клиент и агент пользователя.

Серверы HTTP протокола

Серверы HTTP протокола можно условно разделить на два вида: исходные сервера и прокси-сервера. К исходным серверам относятся те сервера, к которым непосредственно обращается клиент, прокси-сервера HTTP – это транзитные сервера между клиентом и тем сервером, к которому он желает обратиться. Зачастую бывает так, что HTTP сервер выполняет одновременно функцию и конечного сервера, и прокси-сервера, а иногда и клиента.

Вот примеры конечных HTTP серверов:

Давайте посмотрим на прокси-сервера:

На самом деле список гораздо шире, хочу обратить ваше внимание на то, что внутренняя реализация у серверов может быть разной, но правила HTTP протокола они должны выполнять в точности. Для обычного пользователя работа сервера – это его интимное дело, а вот у веб-администратора есть необходимость знать тот или иной программный продукт, чтобы сделать работу пользователя или разработчика наиболее эффективной и комфортной.

Требования HTTP протокола

HTTP протокол имеет требования к приложениям, которые используют его для передачи данных. Требований в HTTP очень много, но требования можно разделить на три категории: необходимые требования, это такие требования, которые должны выполняться всеми программами; рекомендуемые требования, это те требования, которые следует выполнять приложениям и возможные требования, которые могут не выполняться приложениями.

Структура HTTP протокола

Структура HTTP протокола – словосочетание, не совсем точно описывающее то, о чем пойдет речь, правильнее было бы написать структура HTTP сообщения, но если к сообщению добавить HTTP соединение, то как раз получается цельная структура HTTP протокола. Итак, структура HTTP протокола очень простая – это сообщение плюс соединение. Сообщение обычно состоит из трех частей, которые передаются и клиентами, и серверами в следующем порядке:

  1. Стартовая строка или строка состояния, которая определяет тип HTTP сообщения. Стартовая строка обязательна для любого сообщения.
  2. Заголовок HTTP сообщения, который может включать одно поле Host или несколько полей для передачи различной служебной информации.
  3. Тело HTTP сообщения, которое содержит HTTP объекты. Тело сообщения служит для передачи пользовательской информации и есть не у каждого HTTP сообщения.

Терминология HTTP протокола

Создатели HTTP протокола не только разработали стандарт, которому необходимо следовать разработчикам клиентов и серверов, но и придумали термины HTTP протокола, со списком терминов HTTP вы сможете ознакомиться на моем блоге.

Параметры HTTP протокола

У HTTP протокола есть параметры, которые являются механизмом управления взаимодействия между клиентом и сервером. И которые определяют то, в каком виде информация будет передана по HTTP протоколу:

  1. Версия HTTP протокола является его обязательным параметром и указывается в первой строке любого HTTP сообщения.
  2. URI – это параметр, который позволяет однозначно идентифицировать ресурс, который хочет запросить клиент.
  3. Дата и время – это тоже параметр HTTP протокола.
  4. HTTP протокол имеет параметры кодирования сообщений и кодирования передачи.
  5. Тип данных или медиа тип – очередной параметр HTTP протокола.
  6. Лексемы программ позволяют определить разработчика HTTP приложения и версию приложения, а еще лексема является параметром HTTP протокола.
  7. HTTP протокол имеет параметры, которые позволяют определить язык сообщения, в HTTP это называется метка языка.
  8. А еще в HTTP есть единицы измерения диапазонов, которые позволяют запросить только часть ресурса.

Как происходит общение по протоколу HTTP: HTTP сообщение, HTTP запрос и HTTP ответ

Основной и единственной единицей измерения в HTTP протоколе является байт. Основным и единственным способом общения в HTTP протоколе является HTTP сообщение. Сообщения делятся на два вида: HTTP запрос – это сообщение, которое клиент посылает серверу и HTTP ответ – это сообщение, которое сервер посылает клиенту. В принципе, мы уже разобрались со структурой HTTP сообщения ранее, давайте теперь посмотрим примеры запросов и ответов в HTTP протоколе.

Давайте сначала посмотрим на то, что есть общего у любого сообщения в HTTP протоколе. Первое, что хочется выделить – это структура, она общая: статусная строка обязательна для всех сообщений, далее идет заголовок сообщения, в котором обязательное поле Host (в него записывается URI ресурса) и необязательное тело сообщения или, как его еще называют HTTP объект.

Статусная строка отделяется от заголовка символом CRLF в конце этой самой строки от HTTP заголовка (этот символ в Windows вы можете получить, нажав клавишу Enter – перенос строки), а HTTP заголовок отделяется от тела сообщения строкой, в которой только один символ – CRLF.

У запросов и ответов есть общие служебные заголовки, которые могут быть использованы, как при запросе, так и при ответе HTTP сервера. Так же хочу заметить, что есть группа заголовков относящихся к объектам (телу сообщения), они все могут быть использованы, как в запросах, так и в ответах, за исключением поля заголовка Allow, которое используется только в ответах сервера при взаимодействие по протоколу HTTP. У HTTP сообщения есть длина, которая измеряется в байтах, если у вашего HTTP сообщения есть тело, то для определения длины сообщения действуют следующие правила по порядку:

  1. Любое HTTP сообщение ответа сервера, которое не должно включать тело сообщения, всегда должно быть завершено пустой строкой после заголовков.
  2. Если в заголовках HTTP сообщений присутствует поле Transfer-Encoding (кодирование HTTP) при это у этого поля значение chunked, то длину HTTP сообщения следует определять методом кодирования по кускам (chunked encoding).
  3. Если у заголовка HTTP сообщения есть поле Content-Length, то значение, которое записано в Content-Length является длиной HTTP сообщения, измеряется в байтах.
  4. Если HTTP сообщение использует медиа типы «multipart/byteranges», который само разграничен, то он и определяет длину.
  5. Длина HTTP сообщения определяется закрытием соединения со стороны сервера.

Для ясности давайте рассмотрим примеры сообщений в HTTP протоколе и первое, что мы рассмотрим – пример запроса в HTTP протоколе:

Простой пример запроса в HTTP протоколе: сначала идет статусная строка, в которой мы указываем версию протокола HTTP и метод, который будет использован для обращения к ресурсу, а скрипт, находящийся по URL /cgi-bin/process.cgi будет использован для обработки данных. Статусная строка отделена символом CRLF в конце от заголовка, далее идет набор полей HTTP заголовка, которые отделяются друг от друга символом CRLF в конце строки. Если у одного поля есть несколько значений, то они отделяются друг от друга запятой. Тело сообщения отделено пустой строкой. Значение и описание всех полей заголовка HTTP протокола вы сможете найти на моем блоге в специальной записи: список полей HTTP заголовка.

А вот пример ответа в протоколе HTTP:

Синтаксис ответа в протоколе HTTP практически ничем не отличается, ключевым отличием является то, что в первой строке сервер посылает коды статуса, о которых мы поговорим чуть ниже.

Методы в HTTP протоколе

Методы в HTTP протоколе определяет способ обращения клиента к серверу и, соответственно, какую информацию хочет получить или передать клиент серверу. HTTP сервер можно настроить так, чтобы он выполнял некоторые методы, а некоторые игнорировал, это сделано в целях безопасности. Такие настройки можно производить, как для сервера целиком, так и для отдельных ресурсов на HTTP сервере.

Методы в HTTP протоколе делятся на безопасные и идемпотентные. К безопасным относятся методы GET и HEAD, потому что они используются лишь для получения содержимого или его характеристик от сервера, а идемпотентные методы, это такие методы HTTP протокола, которые в случае своего многократного использования к ресурсу на одном и том же URI от одного и того же клиента будут давать такую же нагрузку, как будто этот метод выполнился только один раз, к идемпотентным методам HTTP протокола относятся: GET, HEAD, PUT, DELETE, OPTIONS и TRACE.

Илон Маск рекомендует:  Шаблон сайта блог HTML, CSS, JavaScripts, 1 страница

Давайте коротко рассмотрим методы HTTP протокола и их назначение:

  1. Метода GET в HTTP протоколе используется для получения информации от сервера по заданному URI. Запросы клиентов, использующие метод GET должны получать только данные и не должны никак влиять на эти данные.
  2. Метод HTTP протокола HEAD работает точно так же, как GET, но в ответ сервер посылает только заголовки и статусную строку без тела HTTP сообщения.
  3. Метод HTTP протокола POST используется для отправки данных на сервер, например, из HTML форм, которые заполняет посетитель сайта.
  4. Метода HTTP протокола PUT используется для загрузки содержимого запроса на указанный в этом же запросе URI.
  5. Метод HTTP протокола DELETE удаляет указанный в URI ресурс.
  6. Метод HTTP протокола CONNECT преобразует существующее соединение в тоннель.
  7. Метод HTTP протокола OPTIONS используется для получения параметров текущего HTTP соединения/.
  8. Метод HTTP протокола TRACE создает петлю, благодаря которой клиент может увидеть, что происходит с сообщением на всех узлах передачи.

Как происходит соединение по HTTP протоколу

На данный момент для каждого HTTP соединения HTTP протокол поддерживает постоянные TCP соединения, это означает, что при повторном запросе к серверу с одним и тем же IP-адресом, соединение четвертого уровня рваться не будет, а будет использовано существующее. Раньше это было не так и, если в HTML документе были картинки, то для загрузки каждой картинки использовалось новое соединение TCP/IP.

Обсуждение содержимого в HTTP протоколе

HTTP сервера должны отдавать максимально удобную и понятную информацию для клиента, поэтому в проколе HTTP было введено понятие или механизм обсуждения содержимого. Обсуждение в HTTP, грубо говоря, можно представить, как переговоры между клиентской программой и HTTP сервером о том, в каком виде сервер должен отдавать полезную для пользователя информацию, так как не все клиенты способны одинаково визуализировать информацию.

Прокол HTTP имеет два вида обсуждения: обсуждение, управляемое сервером и обсуждение, управляемое клиентом. Стоит отметить, что эти два вида обсуждения HTTP независимы друг от друга и могут использоваться вместе.

Коды состояния в HTTP протоколе

Коды состояния в HTTP протоколе говорят клиенту о том, что произошло с его запросом, как сервер понял запрос и нужно ли делать что-нибудь клиенту, чтобы запрос был выполнен корректно. Коды состояния – это три цифры, например, 100, 301, 404, 503. Коды состояния в HTTP протоколе делятся на пять классов состояния: информационные коды (они начинаются с единицы), успешные коды (начинаются с двойки), коды перенаправления (начинаются с тройки), коды ошибок клиента (начинаются с четверки), коды ошибок сервера (начинаются с пятерки). Ниже приведена таблица классов кодов состояния их короткое описание. А еще вы можете посмотреть справочник кодов состояния.

Номер Класс кода состояния в HTTP протоколе и его описание
1 HTTP коды состояний 1xx: информационные

Такой код состояния сервер высылает в том случае, когда запрос получен, но еще не обработан.

2 HTTP коды состояний 2xx: успешные

Сервер отправит вам такой код в том случае, когда он успешно принял и обработал HTTP сообщение клиента.

3 HTTP коды состояний 3xx: перенаправление

Если вы получили от сервера код состояния, начинающийся на тройку, то это означает, что нужны дополнительные действия, чтобы завершить процесс обработки HTTP запроса.

4 HTTP коды состояний 4xx: ошибка клиента

Если вы увидели код состояния, который начинается с четверки, то это означает, что произошла ошибка по вине клиента.

5 HTTP коды состояний 5xx: серверная ошибка

Код состояния, начинающийся с пятерки, говорит о том, что произошла ошибка на стороне сервера.

Поля заголовка HTTP сообщения

В протоколе HTTP есть поля заголовка, которые позволяют настроить взаимодействие между клиентом и сервером, а так же то, как и в каком виде полезную информацию будет получать конечный пользователь. Общий синтаксис полей заголовка довольно прост:

Поля заголовка разделяются между собой символом CRLF. HTTP протокол делит поля заголовка на четыре группы:

  1. Общие поля заголовка. Такие заголовки могут быть использованы в любых сообщениях, передаваемых по HTTP протоколу.
  2. Поля заголовка запросов. Эти сообщения могут быть переданы только в запросах HTTP протокола.
  3. Поля заголовка ответов. Как понятно из названия, эти поля используются только при HTTP ответах.
  4. Поля заголовка тело сообщения. А эти поля используются тогда, когда необходимо определить, как и в каком виде будет представлена информация конечному пользователю, которая передается по HTTP.

Более подробно о полях заголовков HTTP сообщения смотрите справочник полей заголовка HTTP сообщения.

Кэширование HTTP протокола

С целью уменьшения нагрузки на сеть и повышения эффективности HTTP протокола был реализован механизм кэширования. Зачастую бывает так, что пользователь даже не догадывается о том, что страница, открытая в его браузере, подгрузилась не с сайта, к которому он обращался, а из кэша. Мы не будем вдаваться во внутренние механизмы кэширования того или иного сервера/клиента, а лишь посмотрим, что есть непосредственно у протокола HTTP для управления кэшированием. И, как вы наверное уже догадались, в HTTP протоколе кэшированием управляют поля заголовка и директивы, то есть значения этих самых полей.

Отмечу, что HTTP протокол реализован так, что этим директивам должны следовать все участники цепочки между клиентом и конечным сервером. Директивы условном можно поделить на клиентские и серверные. Давайте посмотрим на директивы HTTP протокола, предназначенные для управления кэшированием со стороны клиента.

Номер Директивы поля заголовка Cache Control для клиента и их описание
1 no cache

Директива HTTP протокола no-cache говорит серверу о том, что для последующего запроса ответ не должен отправляться из кэша без проверки с содержимым исходного сервера.

2 no store

Директива HTTP протокола no-store говорит серверу о том, что ни запрос клиента, ни ответ сервера не должны кэшироваться. Это сделано для безопасности.

3 max age = seconds

Директива HTTP протокола max-age говорит серверу о том, что кэш должен быть не старше времени, которое указано в секундах.

4 max stale [ = seconds ]

Директива HTTP протокола max-stale говорит серверу о том, что клиент примет кэшированный HTTP ответ в том случае, если его возраст не превышает времени, указанного в секундах.

5 min fresh = seconds

Директива HTTP протокола min-fresh говорит серверу о том, что клиент примет кэшированный HTTP ответ в том случае, если время жизни кэша не больше указанных секунд.

6 Директива HTTP протокола min-fresh говорит серверу о том, что к запрашиваемому ресурсу не должно применяться никаких преобразований.
7 only if cached
Директива HTTP протокола min-fresh говорит серверу о том, что клиент примет только кэшированный HTTP ответ, если подходящего ответа нет в кэше сервера, то делать ничего не надо.
Номер Директивы поля заголовка Cache Control для сервера и их описание
1 public

Директива HTTP протокола Public говорит о том, что ответ сервера можно сохранять в любом кэше.

2 private

Директива HTTP протокола private говорит о том, что ответ сервера нужно сохранять в закрытом кэше, который предназначен только для этого пользователя.

3 no cache

Директива HTTP протокола no cache говорит о том, что кэшированный ответ не должен отправляться клиенту без его предварительной проверки.

4 no store

Директива HTTP протокола no store говорит о том, что ответ сервера нельзя сохранять в кэше.

5 no transform

Директива HTTP протокола no transform говорит о том, что к ответу сервера не должно применяться никаких преобразований ни одним из узлов цепочки.

6 must revalidate

Директива HTTP протокола must revalidate говорит о том, что если HTTP сообщение сервера устарело, то к нему должна применяться предварительная проверка.

7 proxy revalidate

Директива HTTP протокола proxy revalidate говорит о том, что и предыдущая директива, но только для промежуточных серверов.

8 max age = seconds

Директива HTTP протокола max age говорит о том, сколько живет кэш на сервере.

9 Директива поля заголовка Cache Control ответа сервера: s maxage = seconds

Директива ответа сервера Public говорит о том, что и директива max-age, но для CDN-серверов

И клиентские, и серверные HTTP приложения должны уметь сравнивать данные из кэша, чтобы не гонять по сети лишний трафик и при этом конечный пользователь на свои запросы получал актуальную информацию. С этой целью в HTTP протокол было введено специальное поле Last-Modified и условные метода запроса с условными полям заголовка. В поле Last-Modified указывается дата и время создания кэшированной версии, значение этого поля может сравнивается со значением даты времени того момента, когда произошло последнее обновление оригинального ресурса и если значения совпадают, то данные клиенту поступают из кэша.

А если клиент делает повторный запрос к одному и тому же ресурсу, то браузер может включить в сообщение клиента условное поле заголовка, сервер, получив такое поле, проанализирует содержимое ресурса, сравнит с тем, что он посылал ранее и если сравнение будет эквивалентным, то браузеру он вернет сообщение с кодом 304 (не модифицировано), после чего браузер выплюнит содержимое страницы из своего кэша для пользователя.

А еще HTTP протокол позволяет присваивать каждому HTTP объекту тэг в поле заголовка ETag, по сути, это хэш сумма самого объекта и для каждого неповторяющегося объекта она уникальная, поэтому механизм кэширования HTTP протокола активно использует данное поле для проверки актуальности данных, которые хранятся в кэше.

Безопасность HTTP протокола

HTTP протокол предназначен для передачи данных и никаких гвоздей. В HTTP протоколе нет механизмов шифрования и механизмов безопасности, поскольку всевозможные механизмы кодирования HTTP протокола трудно назвать защитой данных, а базовая аутентификация по протоколу HTTP передает логин и пароль пользователя в незашифрованном виде.

Но у HTTP протокола есть расширение HTTPS, обратите внимание HTTPS – это не протокол, а расширение HTTP протокола, которое использует TCP порт 433. Это расширение является связкой двух протоколов: HTTP и SSL или HTTP и TLS (TLS и SSL, суть одно и то же).

What is a Hypertext Transfer Protocol Secure?

What doesВ Hypertext Transfer Protocol Secure mean?

Https is an acronym that stands for Hypertext Transfer Protocol Secure and it is a protocol that is used for the secure communication over computer networks. The secure transfer of data over the Internet is essential for all businesses to prevent wiretapping and attacks by middlemen. Although technically not a protocol, Secure HyperText Transfer is the result of layering the HTTP on top of the SSL/TLS protocol. A secure connection is preferred when transferring sensitive information, such as personal data, social security numbers, or credit card details.

The transfer of data becomes secure by ensuring that data is encrypted between the client and the server. A short term key will be converted into a long term asymmetric secret key that will be unreadable to anyone trying to intercept data which is being passed over the Internet.В The server holds the public key certificate, which is used to verify the entity and ensures the identity of the organization or person receiving any data sent.

Https is a great start to security on the web, but outside secure transfers there are limits to what can be accomplished with https. For example, the protection afforded by https is dependent on proper web browser implementation, server software used, and supported algorithms. Outside of man-in-the-middle attacks and eavesdropping, https provides no protection whatsoever. In addition, any information sent is only as secure as the server it is sent to and if any of the above is not being implemented correctly information can be siphoned off.

Most casual internet users understand that when they see https at the front of a URL it is affording them some sort of protection, and they may even know that it indicates a secure connection. This is positive as it is an easy way for people to know they have some protection for their personal information, which helps to instil trust. In general it is good advice to avoid entering any sensitive information on sites that do not use an https address.

Hypertext Transfer Protocol

Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. [1] Its use for retrieving inter-linked resources led to the establishment of the World Wide Web.

HTTP development was coordinated by the World Wide Web Consortium and the Internet Engineering Task Force (IETF), culminating in the publication of a series of Requests for Comments (RFCs), most notably RFC 2616 (June 1999), which defines HTTP/1.1, the version of HTTP in common use.

HTTP is a request/response standard of a client and a server. A client is the end-user, the server is the web site. The client making a HTTP request—using a web browser, sp >[2]

Typically, an HTTP client initiates a request. It establishes a Transmission Control Protocol (TCP) connection to a particular port on a host (port 80 by default). An HTTP server listening on that port waits for the client to send a request message. Upon receiving the request, the server sends back a status line, such as «HTTP/1.1 200 OK», and a message of its own, the body of which is perhaps the requested resource, an error message, or some other information.

Resources to be accessed by HTTP are identified using Uniform Resource Identifiers (URIs) (or, more specifically, Uniform Resource Locators (URLs)) using the http: or https URI schemes.

Request message Edit

The request message consists of the following:

  • Request line, such as GET /images/logo.gif HTTP/1.1, which requests a resource called /images/logo.gif from server
  • Headers, such as Accept-Language: en
  • An empty line
  • An optional message body

The request line and headers must all end with (that is, a carriage return followed by a line feed). The empty line must consist of only and no other whitespace. In the HTTP/1.1 protocol, all headers except Host are optional.

A request line containing only the path name is accepted by servers to maintain compatibility with HTTP clients before the HTTP/1.0 specification.

Request methods Edit

HTTP defines eight methods (sometimes referred to as «verbs») indicating the desired action to be performed on the identified resource. What this resource represents, whether pre-existing data or data that is generated dynamically, depends on the implementation of the server. Often, the resource corresponds to a file or the output of an executable residing on the server.

HEAD Asks for the response identical to the one that would correspond to a GET request, but without the response body. This is useful for retrieving meta-information written in response headers, without having to transport the entire content. GET Requests a representation of the specified resource. Note that GET should not be used for operations that cause side-effects, such as using it for taking actions in web applications. One reason for this is that GET may be used arbitrarily by robots or crawlers, which should not need to consider the side effects that a request should cause. See safe methods below. POST Submits data to be processed (e.g., from an HTML form) to the identified resource. The data is included in the body of the request. This may result in the creation of a new resource or the updates of existing resources or both. PUT Uploads a representation of the specified resource. DELETE Deletes the specified resource. TRACE Echoes back the received request, so that a client can see what intermediate servers are adding or changing in the request. OPTIONS Returns the HTTP methods that the server supports for specified URL. This can be used to check the functionality of a web server by requesting ‘*’ instead of a specific resource. CONNECT Converts the request connection to a transparent TCP/IP tunnel, usually to facilitate SSL-encrypted communication (HTTPS) through an unencrypted HTTP proxy. [3]

HTTP servers are required to implement at least the GET and HEAD methods [4] .

Safe methods Edit

Some methods (for example, HEAD, GET, OPTIONS and TRACE) are defined as safe, which means they are intended only for information retrieval and should not change the state of the server. In other words, they should not have side effects, beyond relatively harmless effects such as logging, caching, the serving of banner advertisements or incrementing a web counter. Making arbitrary GET requests without regard to the context of the application’s state should therefore be considered safe.

By contrast, methods such as POST, PUT and DELETE are intended for actions which may cause side effects either on the server, or external side effects such as financial transactions or transmission of email. Such methods are therefore not usually used by conforming web robots or web crawlers, which tend to make requests without regard to context or consequences.

Despite the prescribed safety of GET requests, in practice their handling by the server is not technically limited in any way, and careless or deliberate programming can just as easily (or more easily, due to lack of user agent precautions) cause non-trivial changes on the server. This is discouraged, because it can cause problems for Web caching, search engines and other automated agents, which can make unintended changes on the server.

Idempotent methods and web applications Edit

Methods PUT and DELETE are defined to be idempotent, meaning that multiple identical requests should have the same effect as a single request. Methods GET, HEAD, OPTIONS and TRACE, being prescribed as safe, should also be idempotent, as HTTP is a stateless protocol.

By contrast, the POST method is not necessarily idempotent, and therefore sending an identical POST request multiple times may further affect state or cause further side effects (such as financial transactions). In some cases this may be desirable, but in other cases this could be due to an accident, such as when a user does not realize that their action will result in sending another request, or they did not receive adequate feedback that their first request was successful. While web browsers may show alert dialog boxes to warn users in some cases where reloading a page may re-submit a POST request, it is generally up to the web application to handle cases where a POST request should not be submitted more than once.

Note that whether a method is idempotent is not enforced by the protocol or web server. It is perfectly possible to write a web application in which (for example) a database insert or other non-idempotent action is triggered by a GET or other request. Ignoring this recommendation, however, may result in undesirable consequences if a user agent assumes that repeating the same request is safe when it isn’t.

Status codes Edit

In HTTP/1.0 and since, the first line of the HTTP response is called the status line and includes a numeric status code (such as «404») and a textual reason phrase (such as «Not Found»). The way the user agent handles the response primarily depends on the code and secondarily on the response headers. Custom status codes can be used since, if the user agent encounters a code it does not recognize, it can use the first digit of the code to determine the general >[5]

Also, the standard reason phrases are only recommendations and can be replaced with «local equivalents» at the web developer’s discretion. If the status code indicated a problem, the user agent might display the reason phrase to the user to provide further information about the nature of the problem. The standard also allows the user agent to attempt to interpret the reason phrase, though this might be unwise since the standard explicitly specifies that status codes are machine-readable and reason phrases are human-readable.

Persistent connections Edit

In HTTP/0.9 and 1.0, the connection is closed after a single request/response pair. In HTTP/1.1 a keep-alive-mechanism was introduced, where a connection could be reused for more than one request.

Such persistent connections reduce lag perceptibly, because the client does not need to re-negotiate the TCP connection after the first request has been sent.

Version 1.1 of the protocol made bandwidth optimization improvements to HTTP/1.0. For example, HTTP/1.1 introduced chunked transfer encoding to allow content on persistent connections to be streamed, rather than buffered. HTTP pipelining further reduces lag time, allowing clients to send multiple requests before a previous response has been received to the first one. Another improvement to the protocol was byte serving, which is when a server transmits just the portion of a resource explicitly requested by a client.

HTTP session state Edit

HTTP is a stateless protocol. The advantage of a stateless protocol is that hosts do not need to retain information about users between requests, but this forces web developers to use alternative methods for maintaining users’ states. For example, when a host needs to customize the content of a website for a user, the web application must be written to track the user’s progress from page to page. A common method for solving this problem involves sending and receiving cookies. Other methods include server side sessions, hidden variables (when the current page is a form), and URL encoded parameters (such as /index.php?session_ >).

HTTPS URI scheme Edit

HTTPS: is a URI scheme syntactically identical to the http: scheme used for normal HTTP connections, but which signals the browser to use an added encryption layer of SSL/TLS to protect the traffic. SSL is especially suited for HTTP since it can provide some protection even if only one side of the communication is authenticated. This is the case with HTTP transactions over the Internet, where typically only the server is authenticated (by the client examining the server’s certificate).

HTTP 1.1 Upgrade header Edit

HTTP 1.1 introduced support for the Upgrade header. In the exchange, the client begins by making a clear-text request, which is later upgraded to TLS. Either the client or the server may request (or demand) that the connection be upgraded. The most common usage is a clear-text request by the client followed by a server demand to upgrade the connection, which looks like this:

The server returns a 426 status-code because 400 level codes indicate a client failure (see List of HTTP status codes), which correctly alerts legacy clients that the failure was client-related.

The benefits of using this method for establishing a secure connection are:

  • that it removes messy and problematic redirection and URL rewriting on the server side,
  • it allows virtual hosting of secured websites (although HTTPS also allows this using Server Name Indication), and
  • it reduces user confusion by providing a single way to access a particular resource.

A weakness with this method is that the requirement for a secure HTTP cannot be specified in the URI. In practice, the (untrusted) server will thus be responsible for enabling secure HTTP, not the (trusted) client.

Sample Edit

Below is a sample conversation between an HTTP client and an HTTP server running on www.example.com, port 80.

Client request (followed by a blank line, so that request ends with a double newline, each in the form of a carriage return followed by a line feed):

The «Host» header distinguishes between various DNS names sharing a single IP address, allowing name-based virtual hosting. While optional in HTTP/1.0, it is mandatory in HTTP/1.1.

Server response (followed by a blank line and text of the requested page):

The ETag (entity tag) header is used to determine if a cached version of the requested resource is >[6] of a resource sent by the server, which is called byte serving. When Connection: close is sent in a header, it means that the web server will close the TCP connection immediately after the transfer of this package.

Все про HyperText Transfer Protocol

Short for Hypertext Transfer Protocol, HTTP is a set of standards that allow users of the World Wide Web to exchange information found on web pages. When accessing any web page entering http:// in front of the address tells the browser to communicate over HTTP. For example, the URL for Computer Hope is https://www.computerhope.com. Today’s browsers no longer require HTTP in front of the URL since it is the default method of communication. However, it is kept in browsers because of the need to separate protocols such as FTP.

HTTP overview

Below are a few of the major facts on HTTP.

  • The term HTTP was coined by Ted Nelson.
  • HTTP is a stateless protocol.
  • The standard port for HTTP connections is port 80.
  • HTTP/0.9 was the first version of the HTTP, and was introduced in 1991.
  • HTTP/1.0 is specified in RFC 1945, and was introduced in 1996.
  • HTTP/1.1 is specified in RFC 2616, and was officially released in January 1997.

What is HTTPS?

Short for Hypertext Transfer Protocol Secure, HTTPS is a protocol which uses HTTP on a connection encrypted by transport-layer security. HTTPS is used to protect transmitted data from eavesdropping. It is the default protocol for conducting financial transactions on the web, and can protect a website’s users from censorship by a government or an ISP.

  • HTTPS uses port 443 to transfer its information.
  • HTTPS is first used in HTTP/1.1 and is defined in RFC 2616.

What are HTTP status codes?

Below is a listing of HTTP status codes currently defined by Computer Hope. These codes are error messages that allow a client accessing another computer or device over HTTP to know how to proceed or not proceed. For example, 404 tells the browser the request does not exist on the server.

HTTP — протокол передачи гипертекста.

HTTP — протокол передачи гипертекста.

Стандартный протокол для передачи данных по Всемирной паутине — это HTTP (HyperText Transfer Protocol — протокол передачи гипертекста). Он описывает сообщения, которыми могут обмениваться клиенты и серверы. Каждое взаимодействие состоит из одного ASCII-запроса, на который следует один ответ, напоминающий ответ стандарта RFC 822 MIME. Все клиенты и все серверы должны следовать этому протоколу. Он определен в RFC 2616. В этом разделе мы рассмотрим некоторые наиболее важные его свойства.

Соединения

Обычный способ взаимодействия браузера с сервером заключается в установке TCP-соединения с портом 80 сервера, хотя формально эта процедура не является обязательной. Ценность использования TCP — в том, что ни браузерам, ни серверам не приходится беспокоиться о потерянных, дублированных, слишком длинных сообщения и подтверждениях. Все это обеспечивается протоколом TCP.

В HTTP 1.0 после установки соединения посылался один запрос, на который приходил один ответ. После этого TCP-соединение разрывалось. В то время типичная веб-страница целиком состояла из HTML-текста, и такой способ взаимодействия был адекватным. Однако прошло несколько лет, и в странице оказалось множество значков, изображений и других украшений. Очевидно, что установка TCP-соединения для передачи одного значка нерациональна и слишком дорога.

Это соображение привело к созданию протокола HTTP 1.1, который поддерживал устойчивые соединения. Это означало, что появилась возможность установки TCP-соединения, отправки запроса, получения ответа, а затем передачи и приема дополнительных запросов и ответов. Таким образом, снизились накладные расходы, возникавшие при постоянных установках и разрывах соединения. Стало возможным также конвейеризировать запросы, то есть отправлять запрос 2 еще до прибытия ответа на запрос 1.

Методы

Несмотря на то что HTTP был разработан специально для использования в веб-технологиях, он был намеренно сделан более универсальным, чем это было необходимо, так как рассчитывался на будущее применение в объектно-ориентированных приложениях. По этой причине в дополнение к обычным запросам веб-страниц были разработаны специальные операции, называемые методами. Они обязаны своим существованием технологии SOAP. Каждый запрос состоит из одной или нескольких строк ASCII, причем первое слово является именем вызываемого метода. Встроенные методы перечислены в табл. 1. Помимо этих общих методов, у различных объектов могут быть также свои специфические методы. Имена методов чувствительны к регистру символов, то есть метод GET существует, а get — нет.

Таблица 1. Встроенные методы HTTP-запросов

Метод

Описание

Запрос чтения веб-страницы

Запрос чтения заголовка веб-страницы

Запрос сохранения веб-страницы

Добавить к именованному ресурсу (например, к веб-странице)

Отобразить входящий запрос

Зарезервирован для будущего использования

Опрос определенных параметров

Метод GET запрашивает у сервера страницу (под которой в общем случае подразумевается объект, но на практике это обычно просто файл), закодированную согласно стандарту MIME. Большую часть запросов к серверу составляют именно запросы GET. Вот самая типичная форма GET:

GET filename HTTP/1.1,

где filename указывает на запрашиваемый ресурс (файл), а 1.1 — на используемую версию протокола.

Метод HEAD просто запрашивает заголовок сообщения, без самой страницы. С помощью этого метода можно узнать время последнего изменения страницы для сбора индексной информации или просто для проверки работоспособности данного URL.

Метод PUT является противоположностью метода GET: он не читает, а записывает страницу. Этот метод позволяет создать набор веб-страниц на удаленном сервере. Тело запроса содержит страницу. Она может быть кодирована с помощью MIME. В этом случае строки, следующие за командой PUT, могут включать различные заголовки, например, Content-Type или заголовки аутентификации, подтверждающие права абонента на запрашиваемую операцию.

Метод POST несколько напоминает метод PUT. Он также содержит URL, но вместо замены имеющихся данных новые данные «добавляются» (в неком общем смысле) к уже существующим. Это может быть публикация сообщения в конференции или добавление файла к электронной доске объявлении BBS. На практике ни PUT, ни POST широко не применяются.

Метод DELETE, что неудивительно, удаляет страницу. Как и в методе PUT, здесь особую роль могут играть аутентификация и разрешение на выполнение этой операции. Даже при наличии у пользователя разрешения на удаление страницы нет никакой гарантии, что метод DELETE удалит страницу, так как даже при согласии удаленного HTTP-сервера сам файл может оказаться защищенным от изменения или перемещения.

Метод TRACE предназначен для отладки. Он приказывает серверу отослать назад запрос. Этот метод особенно полезен, когда запросы обрабатываются некорректно и клиенту хочется узнать, что за запрос реально получает сервер.

Метод CONNECT в настоящее время не используется. Он зарезервирован для будущего применения.

Метод OPTIONS позволяет клиенту узнать у сервера о его свойствах или о свойствах какого-либо конкретного файла.

В ответ на каждый запрос от сервера поступает ответ, содержащий строку состояния, а также, возможно, дополнительную информацию (например, веб-страницу или ее часть). Строка состояния может содержать трехразрядный код состояния, сообщающий об успешном выполнении запроса или о причинах неудачи. Первый разряд предназначен для разделения всех ответов на пять основных групп, как показано в табл. 2. Коды, начинающиеся с 1 (1хх), на практике используются редко. Коды, начинающиеся с 2, означают, что запрос был обработан успешно и данные (если их запрашивали) отосланы. Коды 3хх сообщают клиенту о том, что нужно попытать счастья в другом месте — используя либо другой URL, либо свой собственный кэш.

Таблица 2. Группы кодов состояния, содержащиеся в ответах сервера

Код

Значение

Примеры

100 — сервер согласен обрабатывать запросы клиента

200 — запрос успешно обработан;

204 — содержимое отсутствует

301 — страница перемещена;

304 — кэшированная страница все еще доступна

403 — ошибка доступа;

404 — страница не найдена

500 — внутренняя ошибка сервера;

503 — попробуйте еще раз позднее

Коды, начинающиеся с 4, означают, что запрос по какой-либо причине, связанной с клиентом, потерпел неудачу; например, была запрошена несуществующая страница или сам запрос был некорректен. Наконец, коды 5хх сообщают об ошибках сервера, возникших либо вследствие ошибки программы, либо из-за временной перегрузки.

Заголовки сообщений

За строкой запроса (например, содержащей название метода GET) могут следовать другие строки с дополнительной информацией. Они называются заголовками запросов. Эту информацию можно сравнить с параметрами, предоставляемыми при вызове процедуры. И свою очередь, ответы могут содержать заголовки ответов. Некоторые заголовки могут встречаться и там, и там. Наиболее важные из них перечислены в табл. 3.

Таблица 3. Некоторые заголовки сообщений протокола HTTP

Заголовок

Тип

Содержимое

Информация о браузере и его платформе

Тип страниц, поддерживаемых клиентом

Поддерживаемые клиентом наборы символов

Поддерживаемые клиентом типы кодирования

Естественные языки, понимаемые клиентом

Список персональных идентификаторов клиента

Отправка ранее принятого cookie-файла на сервер

Дата и время отправки сообщения

Протокол, на который хочет переключиться отправитель

Информация о сервере

Тип кодирования содержимого (например, gzip)

Естественный язык, используемый на странице

Размер страницы в байтах

Тип MIME страницы

Время и дата внесения последних изменений в страницу

Команда клиенту на пересылку его запроса по другому адресу

Сервер готов принимать запросы на страницы указанного размера

Сервер хочет, чтобы клиент сохранил cookie

Заголовок User-Agent позволяет клиенту информировать сервер о версии своего браузера, операционной системы или предоставлять другую информацию о себе. В листинге выше мы видели, что сервер каким-то волшебным образом получал эти данные и мог при необходимости использовать их в PHP-скрипте. Как раз с помощью заголовка User-Agent клиент и сообщил серверу о себе.

Четыре заголовка, начинающиеся с Accept, сообщают серверу о типах информации, которые он готов принять (если их набор ограничен). Первый приведенный в таблице заголовок определяет типы MIME, которые будут корректно приняты клиентом (например, text/html). Заголовок Accept-Charset сообщает о том, какой набор символов клиент хотел бы видеть (например, ISO-8859 или Unicode-1-1). В заголовке Accept-Encoding речь идет о приемлемых методах сжатия (например, gzip). Наконец, Accept-Language сообщает, на каком языке клиент готов читать документы (например, на испанском). Если сервер имеет возможность выбирать из нескольких страниц, он подберет наиболее подходящий для клиента вариант в соответствии с полученной информацией. Если запрос удовлетворить невозможно, возвращается код ошибки, и запрос считается неудавшимся.

Заголовок Host описывает сервер. Его значение берется из URL. Этот заголовок обязателен. Почему? Потому что некоторые IP-адреса могут обслуживать несколько имен DNS одновременно, и серверу необходимо каким-то образом различать, кому передавать запрос.

Заголовок Authorization требуется в тех случаях, когда запрашивается защищенная страница. С его помощью клиент может подтвердить свои права на просмотр запрашиваемой страницы.

Несмотря на то, что cookie описываются в RFC 2109, а не в RFC 2616, для их описания существуют два заголовка. В частности, заголовок Cookie применяется клиентом при возвращении на сервер cookie-файла, который ранее был послан какой-либо машиной из домена сервера.

Заголовок Date может применяться как в запросах, так и в ответах. Он содержит время и дату отправки сообщения.

Заголовок Upgrade может использоваться для облегчения перехода на будущие (возможно, несовместимые с предыдущими) версии протокола HTTP. Он позволяет клиенту объявлять о поддерживаемых им протоколах, а серверу — объявлять о применяемых им протоколах.

А теперь мы подошли к заголовкам, которые может устанавливать только сервер при создании ответов на запросы. Первый из них, Server, позволяет серверу сообщать информацию о себе. При желании он может указать некоторые свои параметры.

Следующие четыре заголовка, начинающиеся с Content-, дают серверу возможность описать свойства посылаемой им страницы.

Заголовок Last-modified содержит дату и время внесения последних изменений в отправляемую страницу. Он играет важную роль при кэшировании страницы.

Заголовок Location вставляется сервером для информирования клиента о том, что стоит попробовать осуществить свой запрос повторно по другому URL. Такая ситуация может возникать при «переезде» страницы или тогда, когда несколько URL ссылаются на одну и ту же страницу (возможно, на «зеркало» страницы, расположенное на другом сервере). Этот трюк нередко применяется теми компаниями, главная веб-страница которых прописана в домене .com, однако клиенты перенаправляются с нее на национальные или региональные страницы, имеющие свои IP-адреса или написанные на более приемлемом для клиента языке.

Если страница очень велика по размеру, клиент может не захотеть принимать ее сразу целиком. Некоторые серверы могут принимать запросы, ограничивающие размеры страниц, отсылаемых за один раз. Если страница оказывается слишком большой, она будет разбита на более мелкие единицы и выслана в несколько приемов. Заголовок Accept-Ranges сообщает о том, что сервер готов поддерживать такие запросы частей страниц.

Set-cookie — это второй заголовок, относящийся к cookie-маркерам. Если этот заголовок установлен сервером, предполагается, что, увидев его, клиент сохранит у себя cookie и вернет его вместе со следующим запросом на сервер.

Все про HyperText Transfer Protocol

Все упоминаемые здесь протоколы были в свое время (1960-е — 1970-е) разработаны спецально для UNIX.

Помните, что выбор UNIX как системы для важных хостов в Internet — лишь самый популярный, но отнюдь не единственный! Вы, работая на машине с Windows 95, OS/2, MS DOS или UNIX сможете с одинаковым успехом подключится к хосту, работающему как под UNIX, так и под любой другой верно настроенной операционной системой.

Telnet — удаленная консоль

    Telnet — так называется самый старый прикладной протокол Internet. Он позволяет делать то, что всегда оставалось сказкой для любого пользователя MS-DOS — «сесть» за другую машину, не вставая с кресла. Telnet позволяет Вам превратить свою клавиатуру и монитор в монитор и клавиатуру удаленного хоста. Все вводимые Вами команды будут исполняться именно на удаленном, а не на Вашем компьютере, а результаты их выполнения будут появляться на Вашем мониторе как если бы он был подключен непосредственно к удаленному хосту.

    Так же нужно помнить, что, как и все прикладные протоколы Internet, telnet представляет из себя воплощение технологии клиент-сервер, и всякий раз при работе с telnet Вам придется запускать программу-клиент telnet, в то время как на удаленном хосте обязательно должна работать программа — сервер telnet.

    Нельзя путать Telnet с другими протоколами (о которых мы поговорим позже), позволяющими Вам обмениваться файлами с удаленным хостом. Telnet НЕ предназначен для обмена информацией (файлами). Его назначение — возможность запускать программы на удаленном хосте и наблюдать результат их выполнения.

    Ниже приведен пример работы с telnet, на компьютерном жаргоне также именуемой сессией telnet. В данном случае мы работали с telnet-клиентом Windows 3.11, хотя в действительности, как мы уже говорили, с telnet можно работать в любой среде. Помните, что пункты меню, описываемые в этом разделе, относятся в первую очередь к Windows 3.11, во всех других операционных системах, Вам придется самостоятельно найти аналогичные пункты.

    В качестве примера, окно Windows 95, в котором работает клиент telnet, выглядит примерно так:
    (Нажмите на картинки, чтобы увидеть их «в полный рост»)



    А окно в Windows 3.х выглядит примерно так.


    Однако все по порядку. Любая работа в Internet начинается с запуска программы-клиента. В нашем случае — клиента telnet. В Windows 3.x пиктограмма клиента telnet находится в окне группы «Internet Software». Запустите ее двойным нажатием мыши.

    Второй этап — подключение к удаленному хосту, или начало сессии telnet. Практически всегда перед подключением возникнет запрос об имени или адресе хоста, к которому Вы хотите поключиться. Если Вы введете существующий в Internet адрес хоста, на котором работает telnet — сервер, после подключения перед Вами появится похожее приглашение telnet. В нашем случае мы подключаемcя к удаленному хосту inetdiv1.itcnet.ru и работающего под операционной системой FreeBSD (разновидность UNIX)

    FreeBSD (inetdiv1.itcnet.ru) (ttyp0)

    В целях безопасности, любой сервер telnet после внешнего подключения запрашивает Ваше имя регистрации и пароль. (Следует помнить, что Вы подключаетесь к удаленной машине, и Ваше имя регистрации и пароль должны существовать именно там. Любая попытка зарегистрироваться «наугад» может расцениваться как попытка взлома, и ничем хорошим Вам не светит)


      Примечание — имя регистрации и пароль необходимо получить у Вашего администратора.
      Строка login: требует ввода имени регистрации, после которого необходимо нажать клавишу «Enter». Вторая строка — password: подразумевает ввод пароля (не забудьте про «Enter»), который, однако, НЕ БУДЕТ ВИДЕН НА ЭКРАНЕ, дабы злоумышленники его не подсмотрели.

    Если у Вас появилось сообщение login failed(incorrect) , повторите все с вводом имени регистрации и пароля. Если же Вы со всем справились, на Вашем экране появится примерно такое сообщение:

    Copyright (C) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
    The Regents of the University of California. All rights reserved.

    FreeBSD-2.1.0-RELEASEа(LOCAL)а#0: Tue Jun 11 17:56:30 MSK 1996

    Welcome to FreeBSD!

    Erase set to delete.
    inetdiv1: <1>_

    С этого момента Вас можно поздравить! Вы фактически оказались на удаленном хосте!

    Приглашение inetdiv1 <1>— что-то вроде приглашения DOS, означающее, что теперь можно вводить команды. Помните, однако, что Вы теперь уже работете в UNIX, и команды тоже должны быть командами UNIX. Далее мы немного поговорим работе с этой операционной системой.

    Для того, чтобы понять особенности файловой системы UNIX, попробуйте набрать команду pwd (Print Working Directory = Напечатать Текущий Каталог). Вот пример из нашей работы:

    inetdiv1 <1>pwd
    /usr/home/std25
    inetdiv1 <2>_

    Набрав pwd и нажав Enter, мы получили ответ — /usr/home/std25 , а затем снова приглашение inetdiv1 <2>(эдесь 2 — это номер команды, введенной с начала сесcии telnet)

    Путь /usr/home/std25 , несколько непривычный для пользователя DOS и Windows, означает каталог, в котором мы находились при выполнении команды pwd. Основное отличие путей UNIX от путей в DOS и Windows — это отсутствие диска (скажем, C:). Просто существует один «диск», в котором и расположена вся система файлов и каталогов. Кроме того, символ разделения каталогов и файлов — «/» не такой, как в DOS и повернут в другую сторону — направо вверх. Имена как файлов, так и каталогов могут быть практически любой длины (обычно до 256 символов) и включать в себя любое количество точек, в отличие от MS-DOS.

    Так как UNIX — это многопользовательская система, у каждого ее пользователя, и у Вас в том числе, есть свой личный каталог. В нашем случае это /usr/home/std25 , и мы сейчас в нем находимся.

    Попробуйте сами ввести команду pwd и оцените результат.


      Если вместо имени каталога у Вас на экране появилась фраза вида:

    pdw: Command not found.

    Проверьте, правильно ли Вы набрали команду, и если нет — попробуйте снова!


Если Вы уяснили, как вводить команды и отслеживать результат их работы — дальше все для Вас будет просто.

Приведем несколько других команд UNIX (Помните, что прописные и заглавные буквы не взаимозаменяемы!):


    ls — [List] просмотреть содержание текущего каталога. (Аналог dir в MS DOS).

      ls -l — пролистать содержимое текущего каталога с подробной информацией о каждом файле и каталоге.

    cd — [Change Directory] смена текущего каталога. (Полный аналог cd из MS DOS.)

      cd mydir — перейти в каталог mydir

      cd .. — пререйти на каталог выше

      cd /home — перейти в каталог home, начиная с корневого


    cp — [Copy] скопировать файл (Как copy)

      cp myfile mynewfile — скопировать myfile в mynewfile

    mkdir — [Make Directory] создать каталог

      mkdir mydir — создать каталог mydir

    rmdir — [Remove Directory] удалить каталог

      rmdir mydir — удалить каталог mydir

    cat — пролистать содержимое файла. (Аналог type из MS DOS)

      cat myfile — пролистать файл myfile

    man — [Manual] показать описание какой-либо команды (как-бы help)

      man cat — показать описание команды cat


ПОМНИТЕ! Остановить выполнение любой программы можно посредством нажатия комбинации клавиш Ctrl — C .

Как в MS-DOS, в UNIX можно использовать так называемое перенаправление результата работы команд. Для простого понимания, мы приведем пример:


    ls > filelist

В данном случае компьютер выполнит команду ls (см. ее назначение выше) и вместо вывода информации на экран, запишет ее в файл с именем filelist . ОСТОРОЖНО! Если такой файл уже существует — после выполнения такой команды его старое содержимое исчезнет навсегда!

В связи с вышесказанным, можно сказать, что символ > явля ется знаком перенаправления.

Практически в любой версии UNIX существует элементарный набор клиентов Internet. Скажем, набрав команду telnet , Вы запустите новую сессию telnet, аналогичную той, с которой работаете (как, еще не запутались?), при этом, работая на первом хосте, Вы будете подключены к новому компьютеру, имя которого набрали вместо строки .

Не круто ли залезть на какую-то машину, а потом через нее — на совсем другую и так далее сколь угодно долго? Мощь telnet налицо.

В конце работы Вам необходимо будет набрать команду exit . Помните, что выйти Вам придется из всех сессий telnet, для чего может понадобиться набрать exit несколько раз.

File Transfer Protocol

    FTP — аббревиатура протокола, некогда бывшего самым популярным в Internet. Сегодня по популярности его опережают лишь электронная почта и http, о которых мы поговорим позже.

    В отличие от telnet, протокол ftp предназначен для передачи файлов между двумя хостами — Вашим и удаленным. Ftp НЕ ПОЗВОЛЯЕТ запускать удаленные программы.

    Как и в telnet, для работы с ftp необходимо наличие программы-клиента у Вас и программы-сервера на удаленном хосте. Существует множество реализаций клиентов и серверов этого протокола. Мы будем говорить о сервере, работающем в UNIX, и клиенте для Windows 3.x.

    Как конкретно работать с клиентом — мы расскажем потом. Сейчас немного о принципах его работы.

    Конечно, для любой работы с ftp необходимо подключение к удаленному хосту. При подключении Вам всегда необходимо будет указать имя удаленного хоста, а затем ввести имя регистрации на этом хосте и пароль.

    Надо сказать, что существует огромное количество хостов, к которым разрешен публичный доступ — это означает, что любой человек может подключиться к ним, используя имя регистрации anonymous (запомните его написание!) и свой почтовый адрес в качестве пароля (имейте в виду, что очень часто, хотя и не всегда, существование этого адреса не только сохраняется для администратора, но и проверяется на существование). Если Вас не пускают как anonymous и у Вас нет имени реистрации на удаленном хосте — лучше оставить все попытки подключения.

    После успешной регистрации Вы оказываетесь в каком-либо каталоге удаленного хоста. (Для anonymous — в корневом.) С этого момента Вы можете путешествовать по каталогам удаленного хоста, просматривать их содержимое, а также «скачивать» любые доступные файлы на свой компьютер или, наоборот, передавать свои. Помните, что не все области удаленного хоста (как каталоги, так и файлы) могут быть доступны даже для чтения, не говоря уже о записи.

    Теперь о том, как работать с ftp-клиентом под Windows 3.x.

    В качестве программы-клиента для выполнения лабораторной работы предлагается использовать программу «Cute FTP». Для запуска программы, необходимо в «Диспетчере программ» открыть группу «Internet» и дважды «щелкнуть» на иконке «CuteFTP».

    В отличие от своих предшественников данная программа позволяет более простым и удобным способом работать с удаленными ftp-серверами. Удобство заключается в том, что пользователю нет необходимости запоминать различные команды и вводить их для того, чтобы выполнить те или иные действия. Достаточно уметь пользоваться мышью и понимать принципы работы технологии ftp.

    Рабочая область программы «CuteFTP» состоит из двух основных панелей (как в Norton Commander) и еще одной (сверху), в которой отображаются те команды, которые за вас вводит сама программа.

    На левой панели отображается содержимое диска локального компьютера (того, на котором вы сейчас работаете), а на правой — содержимое удаленного компьютера, к которому вы подключены (если соединение не установлено, то правая панель пуста).
    Принцип работы с каталогами и файлами ничем не отличается от работы в Norton Commander или Диспетчере файлов. Единственное отличие, заключается в том, что для работы с файлами и каталогами на удаленном компьютере необходимо установить соединение с ним. Для этого необходимо:

    • либо, выполнить команду меню FTP| Quick connect.
    • либо, воспользоваться кнопкой на панели инструментов с изображением «молнии» (вторая слева).

    При этом на экране появляется окно, в котором необходимо указать:

    • Host Address — имя удаленного хоста (ftp-сервера)
    • User ID — имя пользователя для подключения (см. выше)
    • Password — пароль (если требуется).

    Остальные поля не являются необходимыми.

    Если соединение установлено, то на правой панели появится содержимое удаленного хоста. При этом в верхней панели вы можете увидеть все те команды, которые были посланы программой-клиентом серверу.

    Напомним основные принципы работы

    • просмотреть содержимое каталога («зайти» в каталог) — двойной щелчок левой кнопкой мыши на имени каталога;
    • перейти на каталог выше («выйти» из текущего каталога) — двойной щелчок на строке из двух точек
    • выделить группу файлов (каталогов) — удерживая нажатой клавишу Ctrl, щелкать левой кнопкой мыши на названии каждого файла (каталога).

    Копирование файлов осуществляется простым переносом выделенных файлов (каталогов) с помощью мыши с одной панели на другую (также как и в Диспетчере файлов). При этом необходимо помнить, что при копровании файлов на удаленный хост у вас должны быть права на запись в текущий каталог на удаленном ftp-сервере (а этого у вас может и не быть).

    После того, как вы выполнили все необходимые действия с удаленным компьютером, необходимо завершить соединение. Для этого нужно:

    • либо, выполнить команду меню FTP| Disconnect.
    • либо, воспользоваться кнопкой на панели инструментов (третья слева).

    Необходимо помнить, что при отсутствии активных действий при работе с ftp-сервером (копирование файлов, просмотр каталогов и т.д.) может произойти автоматическое отключение, через определенный промежуток времени.


E-mail — электронная почта

    Электронная почта (e-mail) на сегодня является первым по полулярности способом использования Internet. Об основных причинах этого мы уже говорили ранее, однако перечислим их еще раз.

    Прежде всего электронная почта исключительно дешева. При достаточном объеме корреспонденции стоимость одного письма, отправленного по электронной почте (не учитывая стоимость вашего компьютера, конечно :-) может составить всего несколько центов. При этом надо помнить, что электронная почта — часть Internet, поэтому доставка корреспонденции осуществляется в любую точку мира.

    Второе важное достоинство электронной почты — это скорость доставки. В принципе не отличаясь от обычной почты в плане создания и получения письма, электронная почта обеспечивает невероятную скорость передачи сообщений. На практике замечено, что письмо из штата Мичиган в Москву идет примерно 20 минут, что, на самом деле, даже не самый высокий показатель. В локальной компьютерной сети, такой, как сеть МГТУ, доставка письма занимает ровно одну секунду.

    Как и другие протоколы Internet, электронная почта тоже является воплощением структуры клиент-сервер, хотя иногда и не так явно, как в случае с ftp и telnet. В частности, непосредственно доставка (отправление писем по Сети и их прием) осуществляется специальными «почтовыми» хостами, делается это автоматически, обычно каждые 3 минуты. Поэтому чаще всего при отправке и получении почты Вы будете работать с программами (клиентами), которые уже сами будут связываться именно с таким почтовым хостом и расположенным на нем почтовым сервером.

    Как и в случае с обычной почтой, e-mail, конечно, подразумевает адресацию своих пользователей. Причина очевидна — письмо всегда должно попасть именно к тому человеку, которому было адресовано.

    Как же выглядит адрес пользователя (получателя или отправителя) электронной почты? Сейчас мы об этом поговорим.


      somerealuser @ some.existing.domain

    Этот пример демонстрирует типичный адрес электронной почты. Условно можно разбить его на две части (синюю и зеленую). Как и доменное имя хоста, адрес электронной почты проще читать с конца. Выделенная зеленым цветом часть адреса — это домен. (подробнее — см. адресация в Internet) Иными словами, some.existing.domain — это сеть, в которой зарегистрирован наш псевдо-пользователь.В нашем случае имя этого пользователя — somerealuser . Странный символ @ (в простонародье называется «собака», по-английски — «at») означает, что адрес этот — почтовый и доставляется по протоколу SMTP (Simple Mail Transfer Protocol). Не пугайтесь, запоминать этого Вам не нужно, просто примите к сведению.

    В сети МГТУ существуют несколько оличающиеся от приведенного почтовые имена, и выглядят они так:


      Ivan.Ivanov @ mstu.edu.ru

    Опытный пользователь (а Вы, я уверен, уже им стали!) сразу увидит два отличия — во-первых, Ivan и Ivanov начинаются с больших букв и во-вторых эти слова разделены точкой. В e-mail адресе большие буквы обычно можно безболезненно заменять маленькими и наоборот. Однако помните, что существуют другие сети, которые подключены к Internet и пользователям которых тоже можно отправлять e-mail; адрес таких «заСетевых» пользователей чаще всего выглядит несколько не так, как обычный адрес и в нем может существовать разница между большими и маленькими буквами. Точка, указанная в имени пользователя, просто заменяет пробел (использование которого, кстати, в адресе электронной почты запрещено).

    Существует другой стандарт передачи почты, в котором используется альтернативный формат e-mail адреса (вроде user!some!host ), но Вы наверняка уже никогда с ним не столкнетесь.

    Теперь о том, как выглядит электронной письмо и как можно его отправить или принять.

    В каждом письме существуют так называемые «поля», содержащие определенную информацию. Например, самое главное поле («To:») содержит адрес получателя письма. Вот элементарные поля, чаще всего использующиеся при составлении письма (обязательные поля отмечены звездочкой).


      *To:адрес получателя
      *From:Ваш e-mail адрес
      *Subject:тема (заголовок) письма
      Cc:адреса тех, кому отправляются копии письма;
      несколько адресов разделяются запятой
      Bcc:адреса тех, кому отправляются копии письма,
      однако получатель не увидит ни одного из
      перечисленных адресов кроме своего
      Текст письма.


    (Поле From: не может быть изменено — там записан Ваш адрес.)

    Зная адрес электронной почты человека, вы можете просто ввести его в поле «To:» и, заполнив поле «Subject:»,а также написав текст, отправить свежесоставленное письмо. Заполнение остальных полей необязательно.

    О том, как выглядит сам процесс написания и отправки письма, можно говорить очень долго. Дело в том, что существует огромное количество почтовых клиентов. Это неудивительно, если вспомнить, что электронная почта — самый популярный сервис Internet. Для нас это рождает огромное неудобство, так как все клиенты требуют особого подхода и перечислить все их особенности, а тем более попытаться запомнить их просто невозможно. В рамках этого курса мы поговорим о почтовом клиенте Netscape Navigator 3.0

    Почтовый клиент, встроенный в web-браузер Netscape Navigator 3.0 очень прост в обращении и наделен некоторыми возможностями, которые помогут вам работать с вашей корреспонденцией. Кроме основного своего назначения: отправлять и принимать вашу почту, Netscape поможет вам организовать адресную книгу, структурировать ваши письма (разложить по папкам) и т. д.

    Для запуска почтового клиента вам необходимо дважды щелкнуть «мышкой» на изображении конверта, находящемся справа в строке состояния Netscape Navigator (в правом нижнем углу окна). Программа автоматически подключается к почтовому серверу и пытается проверить пришла ли почта на ваше имя (конечно Netscape Navigator должен быть предварительно настроен для прочтения именно вашей почты). Для этого вы должны ввести ваш пороль для чтения почты (тот самый пароль, который дал вам ваш postmaster).

    И если пароль правильный Netscape Navigator немедленно(или чуть погодя) сообщит вам о наличии или отсутствии новых писем.

    Почтовый клиент как и любая программа под Windows имеет основное меню, панель инструментов (на которой расположены кнопки) и рабочее окно.

    Рабочее окно почтового клиента Netscape Navigator разделено на три части:

    В верхней левой трети расположены «папки», в которых хранятся письма. Щелкнув «мышкой» на любую из них вы увидите ее содержимое. Все письма, хранящиеся в этих «папках»показаны в верхней правой трети, и если щелкнуть на любое письмо, можно прочитать его содержимое. Само же содержимое выбранного письма появляется в нижней, самой большой трети рабочего окна.

    В Netscape Navigator существуют стандартные «папки» для писем:


      • INBOX — здесь находятся все вновь пришедшие письма
      • SENT — здесь находятся все посланные Вами письма
      • TRASH — а это «корзина для мусора», здесь храняться письма которые Вы удалили


    Все остальные «папки» Вы можете создать сами. Для создания новой «папки» необходимо воспользоваться пунктом меню File>>Add Folder

    Что касается панели инструментов, то на ней расположены несколько кнопок, назначение которых приведено ниже:


Нажав на эту кнопку Вы проверите не пришла ли к Вам новая почта (т. е. Вы как бы «заглядываете»в свой «почтовый ящик»)
Эта кнопка предназначена для удаления писем
С помощью этой кнопки вы можете отправить обычное электронное письмо
Эта кнопка позволит Вам отправить ответ на любое письмо (причем содержимое этого письма будет автоматически вставлено) в Ваш ответ
То же самое, что предыдущая кнопка, только ответ будет разослан всем адресатам, указанным в полях Сс, Вс
Нажав на эту кнопку Вы просто перенаправите письмо, пришедшее Вам, по другому адресу
А эта кнопка позволит Вам напечать любое Ваше письмо на принтере (если таковой имеется)

    С получением писем все очень просто. После того как вы «заглянете» в Ваш «почтовый ящик» Все новые письма автоматически появляются в «папке» INBOX. И все.

    А вот об отправке письма немного поговорим. При отправке письма (обычного или ответа) на экране появляется новое окно:

    А здесь все Вам уже должно быть знакомо. Родные всем поля заголовка письма и окно для ввода текста. Только обратите внимание, что могут присутствовать не все поля заголовка (из необязательных конечно же). Дело в том, что они тоже определенным образом настраиваются. Заполняете все необходимые поля, набираете текст и письмо готово. Теперь достаточно нажать на кнопку и. сообщение отправлено!

    Теперь несколько слов об адресной книге. Для того, чтобы просмотреть, добавить или изменить информацию в адресной книге необходимо выбрать пункт меню Windows>>Address book. А чтобы потом вставить адрес из адресной книги в нужное поле достаточно нажать соответствующую кнопку:

    Адрес для поля To:
    Адрес для поля Cc:
    Адрес для поля Bc:


HyperText Transfer Protocol — протокол передачи гипертекстовой информации

    Итак, мы подошли к кульминационному моменту нашего курса, в котором мы поговорим о новейшей технологии в мире телекоммуникаций, известной в Сети как WWW или World Wide Web (всемирная паутина). Как взаимосвязаны WWW и HTTP пока неважно; поверьте нам на слово, очень тесно. Позже мы еще поговорим об этом.

    С помощью технологии WWW любой неопытный пользователь (проще говоря, «чайник») сможет без проблем путешествовать в информационном океане — Internet. Для работы с WWW не надо знать ни команд UNIX, ни основ TCP/IP (как впрочем даже самого значения этих букв), ни даже, в общем-то, знания клавиатуры (расположения букв или вообще понимания что это такое). Впрочем, нужно уметь держать в руках «мышь» и быть в состоянии нажимать на ее кнопки. Все остальное сделает за Вас новейшая и самая популярная из технологий Internet — WWW.

    Что же такое WWW? Эта технология позволяет Вам получать информацию с удаленного хоста. На самом деле, это все. В чем же отличие WWW от FTP и т.п. — законно спросите Вы. А вот в чем.

    Прежде всего, информация, получаемая в WWW сразу же видна пользователю на экране — больше нет необходимости скачивать файлы, а затем разбираться, что же в них находится и как извлечь из них то, что Вам нужно.

    Основой WWW является довольно примитивный язык программирования, HTML (HyperText Markup Language). С его помощью в Сеть помещается разнообразная информация. Условно информация в WWW разбита на так называемые «HTML-страницы» (они же Web-страницы), каждая из которых содержит определенную информацию. Ключевой особенностью HTML являются «ссылки», или элементы представленной на экране страницы, которые позволяют Вам простым нажатием мыши перенестись в любой другой документ (страницу) WWW в любой точке мира. Иными словами, WWW есть огромное множество разбросанных по миру HTML — страничек, взаимосвязанных между собой «ссылками» самими немыслимыми способами. Получается эдакая «паутина», что вполне соответствует названию.

    На самом деле WWW позволяет Вам работать с различными хостами и протоколами Internet. Основной протокол WWW называется HTTP — протокол передачи гипертекстовой информации. Проще говоря, http просто передает файлы с удаленного хоста в рабочую область Вашего web-браузера. Файлы бывают разные, но чаще всего в WWW ходят файлы в формате HTML.

    Но это еще не все! HTML позволяет включать в странички самую разнообразную мультимедийную информацию — графику, анимацию, звуки и т.д. Причем, опять же, эта информация будет появляться сразу на экране пользователя.

    Мало того, в последнее время набирает ход новейший язык программирования — java — позволяющий включать в HTML-странички любое написанное на java приложение (при желании хоть текстовый редактор или иллюстрацию полета баллистической ракеты).

    Надо сказать, что через все перечисленные выше преимущества WWW красной нитью проходит одна важная особенность — для работы с WWW Вам необходима всего одна программа-клиент, называемая на Сетевом сленге web-browser, web-explorer или web-surfboard. Именно через web-браузер Вы сможете просмотреть любую информацию WWW или даже запустить java — приложение (апплет).

    В нашем курсе мы познакомим с самым популярным (на сегодня) web-браузером Netscape Navigator.

    Надо заметить, что, читая этот курс, Вы уже пользуетесь браузером и технологией World Wide Web. Соответственно, Вы уже представляете себе что такое ссылка и HTML-страница.

    Взгляните внимательно на окно web-браузера. Как и любое другое приложение, web-браузер ( в частности, Netscape Navigator), обладает рядом стандартных элементов, таких как меню, панель инструментов и рабочая область (в которой прежде всего отображаются HTML-страницы и прочая WWW информация).

    В любом web-браузере среди элементов интерфейса обязательно присутствует строка Location: или идентичная ей, в которой можно вводить URL (термин объяснен ниже)аресурса, к которому Вы желаете подключиться. По умолчанию эта строка содержит URL текущего ресурса.

    Теперь о URL. Для адресации в WWW используется несколько особая форма адреса, которая выглядит примерно так:


      http://www.itcnet.ru

    ftp://ftp.itcnet.ru/pub/unix/FreeBSD/2.1.7-RELEASE/HARDWARE.TXT


Обратите внимание, что в адресе слева направо указаны: название протокола, адрес удаленного хоста и путь к файлу на этом хосте (необязателен). Такая форма адреса называется Uniform Resource Locator (URL). Использование URL позволяет Вам легко ссылаться на различные ресурсы Internet.

Для работы с WWW Вам полезно будет знать формат URL. Постарайтесь его запомнить:


    :// /

Мы не будем подробно останавливаться на всех возможностях Netscape Navigator, поговорим лишь о самых насущных.

Несколько слов о панели инструментов. Ключевыми элементами на ней являются кнопки:

Эта кнопка предназначена для возврата к предыдущему документу (HTML странице)
Эта кнопка предназначена для перемещения на один документ вперед (если, конечно, Вы возвращались назад)
Эта кнопка предназначена для перехода к Вашей домашней странице (странице Вашей организации)
Эта кнопка предназначена для прекращения «скачивания» документа с удаленного хоста
Эта кнопка предназначена для обновления текущего документа.



    Любой документ, находящийся в рабочей области Netscape Navigator может быть сохранен на локальном диске с помощью пункта меню File >> Save As.

    Помните, что картинки и прочая нетекcтовая информация содержится в отдельных файлах и должна быть сохранена отдельно. Графические изображения могут быть сохранены в пункте меню, которое вызывается нажатием правой кнопкой мыши на этом изображении. Вообще правая кнопка мыши, нажатая на какой-либо части рабочего окна Netscape Navigator вызывает меню, относящееся именно к этой части.

    Кроме того, графика и мультимедиа занимает довольно много места, поэтому «скачивать» ее бывает иногда накладно. Для отмены или разрешения автоматического скачивания картинок существует пункт меню Options>>Auto Load Images.

    В любом web-браузере существуют так называемые «закладки» (bookmarks), которые позволяют легко подключаться к популярным URL. Редактирование Bookmarks осуществляется в пункте меню Window >> Bookmarks, тогда как доступ к ним — прямо в Bookmarks.

    Если Вы вдруг захотите одновременно работать с двумя Netscape Navigator’ами, не стоит второй раз запускать пентограмму в Windows, вместо этого выберите пункт меню File >> New Web Browser. При этом откроется новое окно со своей историей Вашего путешествия по URL.

    В заключении надо сказать о некоторых неудобствах, связанных с использованием русского языка в WWW. Дело в том, что в мире принято несколько разнообразных «кодировок» (методов представления) русских букв. Нам известно как минимум четыре, которые никак не совместимы.

    Hypertext Transfer Protocol —

    Related documents
    Add this document to collection(s)

    You can add this document to your study collection(s)

    Sign in Available only to authorized users

    Add this document to saved

    You can add this document to your saved list

    Sign in Available only to authorized users

    Products
    Support

    Make a suggestion

    Did you find mistakes in interface or texts? Or do you know how to improveStudyLib UI? Feel free to send suggestions. Its very important for us!

    Hyper_Text_Transfer_Protocol

    Hyper Text Transfer Protocol (HTTP)

    The Hyper Text Transport Protocol is a text-based request-response client-server protocol. A HTTP client (e.g. a web browser such as Mozilla) performs a HTTP request to a HTTP server (e.g. the Apache HTTP server), which in return will issue a HTTP response. The HTTP protocol header is text-based, where headers are written in text lines.

    HTTP/1.1 allows for client-server connections to be pipelined, whereby multiple requests can be sent (often in the same packet), without waiting for a response from the server. The only restriction is the server MUST return the responses in the same order as they were received. This enables greater efficiency, especially on reval >

    An encrypted variant named HTTPS is also available. This is often used where privacy of data is necessary, e.g. when using online banking. The HTTPS protocol is in fact two protocols running on top of each other. The first protocol is a security protocol like SSL, TLS or PCT. The second protocol, which runs on top of this security protocol, is HTTP. The URLs starting with https:// really are only a shorthand notation for the end user. The web browser will read the URI scheme (https://), initiate the security protocol to the server, and once this secure connection is established, issue a HTTP request over it with the URI specified in the request.

    History

    The Hyper Text Transfer Protocol (HTTP) was initiated at the CERN in Geneve (Switzerland), where it emerged (together with the HTML presentation language) from the need to exchange scientific information on a computer network in a simple manner. The first public HTTP implementation only allowed for plain text information, and almost instantaneously became a replacement of the GOPHER service. One of the first text-based browsers was LYNX which still exists today; a graphical HTTP client appeared very quickly with the name NCSA Mosaic. Mosaic was a popular browser back in 1994. Soon the need for a more rich multimedia experience was born, and the markup language prov >

    Support for multiple media types was already part of the informal HTTP/1.0 standard published as RFC1945 back in 1996. As the community using HTTP grew at an incredibly fast pace, and thanks to usage experience gathered by the community and processed by experts, the need for a more formal definition of the HTTP protocol emerged. Hence HTTP/1.1 was published, first as RFC2068 in January 1997, soon superseded by RFC2616 published in June 1999.

    Protocol dependencies

    MIME_multipart: HTTP uses MIME_multipart to encode its messages.

    TCP: Typically, HTTP uses TCP as its transport protocol. The well known TCP port for HTTP traffic is 80. A HTTP proxy often uses a different port; typical values are 81, 3128, 8000 and 8080. However, HTTP can use other transport protocols as well.

Example traffic

Request by an end-user’s browser

This user wants to access the web site «www.freebsd.org», so they type in http://www.freebsd.org into their browser and hit enter. After the usual DNS resolution to find the IP address for www.freebsd.org, a connection is initiated via TCP to the web server (SYN; SYN,ACK; ACK). The very next thing to be sent to the web server by the browser/client is the following plain text request:

The server knows the browser/client is done with its traffic when it receives a blank line with a carriage return + line feed (\r\n).

Response from the server

The response is also in plain text:

The browser/client now knows that text/html is coming, and here it is:

The browser/client knows the server is done sending its html (or data for non-html) when it receives a blank line with a carriage return + line feed (\r\n).

Wireshark

Wireshark’s HTTP dissector is fully functional (XXX — is that really true?). (XXX — add some words about MIME body data encoding/enchunking here). In addition, you can get basic statistics about HTTP requests/responses using Wireshark’s menu item: Statistics/HTTP.

Preference Settings

Example capture file

SampleCaptures/http.cap A simple HTTP request and response.

SampleCaptures/http_gzip.cap. A simple HTTP request and a one packet gzip Content-Encoded response. Try this capture if you are having problems decompressing Content-Encoded packets, as this works with the default preferences.

Display Filter

A complete list of HTTP display filter fields can be found in the display filter reference

Show only the http based traffic:

Show only the famous «404: page not found» responses:

Show only file data received over HTTP (the content of the responses):

Capture Filter

You cannot directly filter HTTP protocols while capturing. However, if you know the TCP port used (see above), you can filter on that one.

Capture HTTP traffic over the default port (80):

Capture HTTP traffic over the default SSL port (443):

RFC1945 Hypertext Transfer Protocol — HTTP/1.0

RFC2068 Hypertext Transfer Protocol — HTTP/1.1 (obsoleted by RFC2616)

RFC2616 Hypertext Transfer Protocol — HTTP/1.1

RFC2660 The Secure HyperText Transfer Protocol (S-HTTP)

Discussion

Hyper_Text_Transfer_Protocol (последним исправлял пользователь BillMeier 2011-02-22 12:56:00)

Илон Маск рекомендует:  MinsPerDay - Константа
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL