WEB-технологии

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И  НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

Федеральное государственное бюджетное образовательное учреждение

высшего профессионального образования

«НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ

ТОМСКИЙ ПОЛИТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ»

 

Кафедра Автоматики и компьютерных систем

Специальность «Информационные системы и технологии»

 

«WEB - ТЕХНОЛОГИИ»

 

Учебно-исследовательная работа студента

 

 

Студент группы 8и11

         

Назмутдинов Р.Т.

             

Руководитель работы

         

Мартынова Ю.А.

   

 

 

 

 

 

 

       

Томск 2013 г.

Содержание

Введение 3

Всемирная паутина (WWW) 4

1 Клиент-серверная архитектура 6

1.1. Сторона клиента 6

1.2. Сторона сервера 9

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

1.3.1. Соединения 14

1.3.2. Методы 14

1.3.3. Пример использования HTTP 16

2 Установка и настройка локального веб-сервера «OpenServer» 18

2.1. Установка (распаковка) сервера 18

2.2. Настройка сервера 20

3 Настройка веб-сервера на операционной системе «Debian» 25

3.1. Установка веб-сервера 25

3.2. Установка MySQL 27

3.3. Подключение модулей 28

3.4. Проверка результата 28

3.5. Установка phpMyAdmin 29

3.6. Настройка PHP 32

3.7. Настройка веб-сервера и виртуальных хостов 33

3.8. Изменение локального хоста 34

3.9. Создание главной страницы сайта 35

3.10. Создание нового виртуального хоста 36

Список используемой литературы 38

Заключение 38

 

 

Введение

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

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

Также в основе практической работы в рамках данной УИРС будет  рассмотрена установка и настройка  локального веб-сервера OpenServer, а также установка и настройка веб-сервера на операционной системе «Debian», включающая в себя установку самого сервера, установку MySQL и подключение к ней необходимых модулей, установку phpMyAdmin, а также его настройку.

 

Всемирная паутина (WWW)

Всемирная паутина (WWW, World Wide Web) — это архитектура, являющаяся основой для доступа к связанным между собой документам, находящимся на миллионах машин по всему Интернету. За 10 лет своего существования из средства распространения информации на тему физики высоких энергий она превратилась в приложение, о котором миллионы людей с разными интересами думают, что это и есть «Интернет». Огромная популярность этого приложения стала следствием цветного графического интерфейса, благодаря которому даже новички не встречают затруднений при его использовании. Кроме того, Всемирная паутина предоставляет огромное количество информации практически по любому вопросу.

Всемирная паутина была создана в 1989 году в Европейском  центре ядерных исследований CERN в  Швейцарии. В этом центре есть несколько  ускорителей, на которых большие  группы ученых из разных европейских  стран занимаются исследованиями в  области физики элементарных частиц. В эти команды исследователей часто входят ученые из пяти-шести  и более стран. Эксперименты очень  сложны, для их планирования и создания оборудования требуется несколько  лет. Программа Web (паутина) появилась  в результате необходимости обеспечить совместную работу находящихся в  разных странах больших групп  ученых, которым нужно было пользоваться постоянно меняющимися отчетами о работе, чертежами, рисунками, фотографиями и другими документами.

Изначальное предложение, создать паутину из связанных  друг с другом документов пришло от физика центра CERN Тима Бернерс-Ли (Tim Berners-Lee) в марте 1989 года. Первый (текстовый) прототип заработал спустя 18 месяцев. В декабре 1991 году на конференции Hypertext'91 в Сан-Антонио в штате Техас была произведена публичная демонстрация. Эта демонстрация, сопровождаемая широкой рекламой, привлекла внимание других ученых. Марк Андрессен (Marc Andreessen) в университете Иллинойса начал разработку первого графического браузера, Mosaic. Программа увидела свет в феврале 1993 года и стала настолько популярной, что год спустя ее автор Марк Андрессен решил сформировать собственную компанию Netscape Communications Corp., чьей целью была разработка клиентов, серверов и другого программного обеспечения для веб-приложений. Когда в 1995 году корпорация Netscape получила известность, инвесторы, полагая, очевидно, что появилась еще одна корпорация типа Microsoft, заплатили за пакет ее акций 1,5 млрд. долларов.

С точки зрения пользователя Всемирная паутина состоит из огромного собрания документов, расположенных  по всему миру. Документы обычно называют для краткости просто страницами. Каждая страница может содержать ссылки (указатели) на другие связанные с ней страницы в любой точке мира. Пользователи могут следовать по ссылке (например, просто щелкнув на ней мышью), при этом страница, на которую указывает ссылка, загружается и появляется в окне браузера. Этот процесс можно повторять бесконечно. Идея страниц, связанных между собой гиперссылками (гипертекст), была впервые пророчески предложена в 1945 году, задолго до появления Интернета, Ванневаром Бушем, профессором из Массачусетского университета, занимавшимся электротехникой.

Основной принцип работы Паутины показан на рис. 1. Браузер  отображает веб-страницу на клиентской машине. Когда пользователь щелкает  на строке, которая является ссылкой  на страницу, расположенную на сервере  «abcd.com», браузер следует по этой гиперссылке. Реально при этом на «abcd.com» отправляется служебное сообщение  с запросом страницы. Получив страницу, браузер показывает ее. Если на этой странице содержится гиперссылка на страницу с сервера «xyz.com», то браузер  обращается с запросом к «xyz.com», и  так далее до бесконечности.

Рисунок 1 - части всемирной паутины

 

  1. Клиент-серверная  архитектура

    1. Сторона клиента

Необходимо детально рассмотреть  сторону клиента, основываясь на рис. 1. По сути дела, браузер — это  программа, которая может отображать веб-страницу и распознавать щелчки мыши на элементах активной страницы. При выборе элемента браузер следует  по гиперссылке и получает с сервера  запрашиваемую страницу. Следовательно, гиперссылка внутри документа должна быть устроена так, чтобы она могла  указывать на любую страницу Всемирной  паутины. Страницы именуются с помощью URL (Uniform Resource Locator — унифицированный указатель информационного ресурса). Типичный указатель выглядит так: «http://www.abcd.com/products.html».

URL состоит из трех  частей: имени протокола (http), DNS-имени машины, на которой расположена страница (www.abcd.com), и (обычно) имени файла, содержащего эту страницу (products.html).

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

Когда пользователь щелкает  мышью на гиперссылке, браузером  выполняется ряд действий, приводящих к загрузке страницы, на которую  указывает ссылка. Например, пользователь, блуждая по Интернету, находит ссылку на документ, рассказывающий про интернет-телефонию, а конкретно — на домашнюю страницу ITU, расположенную по адресу http://www.itu.org/home/index.html. Далее описывается каждое действие, происходящее после выбора этой ссылки.

1. Браузер определяет URL (по выбранному элементу страницы).

2. Браузер запрашивает  у службы DNS IP-адрес www.itu.org.

3. DNS дает ответ 156.106.192.32.

4. Браузер устанавливает  TCP-соединение с 80-м портом машины 156.106.192.32.

5. Браузер отправляет  запрос на получение файла  /home/index.html.

6. Сервер www.itu.org высылает  файл /home/index.html.

7. TCP-соединение разрывается. 

8. Браузер отображает  весь текст файла /home/indexhtml.

9. Браузер получает и  выводит все изображения, прикрепленные  к данному

файлу.

10. Многие браузеры отображают  текущее выполняемое ими действие  в строке 

состояния внизу экрана. Это позволяет пользователю понять причину низкой

производительности: например, не отвечает служба DNS или сервер или  про-

сто сильно перегружена  сеть при передаче страницы.

11. Для отображения каждой  новой страницы браузер должен  понять ее формат.

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

Вместо того чтобы наращивать возможности и размеры браузеров, встраивая в них интерпретаторы для различных типов файлов (количество которых быстро растет), обычно применяется более общее решение. Когда сервер возвращает в ответ на запрос какую-либо страницу, вместе с ней высылается некоторая дополнительная информация о ней. Эта информация включает MIME-тип страницы. Страницы типа text/html выводятся браузером напрямую, как и страницы некоторых других встроенных типов. Если же для данного MIME-типа внутренняя интерпретация невозможна, браузер определяет, как выводить страницу, по своей таблице MIME-типов. В данной таблице в соответствие каждому типу ставится программа просмотра.

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

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

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

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

Рисунок 2 - модель работы браузера

 

    1. Сторона сервера

Когда пользователь вводит URL или щелкает на гиперссылке, браузер  производит структурный анализ URL и  интерпретирует часть, заключенную  между http:// и следующей косой чертой, как имя DNS, которое следует искать. Вооружившись IP-адресом сервера, браузер  устанавливает ТСР-соединение с  портом 80 этого сервера. После этого  отсылается команда, содержащая оставшуюся часть URL, в которой указывается  имя файла на сервере. Сервер возвращает браузеру запрашиваемый файл для  отображения. Этому серверу, как  и настоящему веб-серверу, передается имя файла, который следует найти  и отправить.

В обоих случаях в  основном цикле сервер выполняет  следующие действия:

1. Принимает входящее TCP-соединение  от клиента (браузера).

2. Получает имя запрашиваемого  файла. 

3. Получает файл (с диска).

4. Возвращает файл клиенту. 

5. Разрывает ТСР-соединение.

Современные веб-серверы  обладают более широкими возможностями, однако существенными в их работе являются именно перечисленные шаги. Проблема данного подхода заключается  в том, что каждый запрос требует  обращения к диску для получения  файла. В результате число обращений  к веб-серверу за секунду ограничено максимальной скоростью обращений  к диску. Среднее время доступа  к высокоскоростному диску типа SCSI составляет около 5 мс, то есть сервер может обрабатывать не более 200 обращений  в секунду. Это число даже меньше, если часто запрашиваются большие  файлы. Для крупных веб-сайтов это слишком мало. Очевидным способом решения проблемы является кэширование в памяти последних запрошенных файлов. Прежде чем обратиться за файлом к диску, сервер проверяет содержимое кэша. Если файл обнаруживается в кэше, его можно сразу выдать клиенту, не обращаясь к диску. Несмотря на то, что для эффективного кэширования требуются большие объемы памяти и некоторое дополнительное время на проверку кэша и управление его содержимым, суммарный выигрыш во времени почти всегда оправдывает эти накладные расходы и стоимость.

Следующим шагом, направленным на повышение производительности, является создание многопоточных серверов. Одна из реализаций подразумевает, что сервер состоит из входного модуля, принимающего все входящие запросы, и k обрабатывающих модулей, как показано на рис. 3. Все k + 1 потоков принадлежат одному и тому же процессу, поэтому у обрабатывающих модулей есть доступ к кэшу в адресном пространстве процесса. Когда приходит запрос, входящий модуль принимает его и создает краткую запись с его описанием. Затем запись передается одному из обрабатывающих модулей. Другая возможная реализация подразумевает отсутствие входного модуля; все обрабатывающие модули пытаются получить запросы, однако здесь требуется блокирующий протокол, помогающий избежать конфликтов.

Рисунок 3 - Многопоточный веб-сервер с входным и обрабатывающими модулями

 

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

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

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

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

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

  • вычисление имени запрашиваемой веб-страницы;
  • регистрация клиента;
  • осуществление контроля доступа для клиента;
  • осуществление контроля доступа для веб-страницы;
  • проверка кэша;
  • получение запрошенной страницы с диска;
  • определение типа MIME для включения этой информации в ответ клиенту;
  • аккуратное выполнение различных дополнительных задач;
  • возвращение ответа клиенту;
  • добавление записи в журнал активности сервера.

Шаг 1 необходим, потому что  входящий запрос может и не содержать реального имени файла в виде строкового литерала. Например, URL может быть вот таким: http://www.cs.vu.nl. Здесь имя файла отсутствует. Этот URL необходимо дополнить неким именем файла по умолчанию. К тому же современные браузеры могут указывать язык пользователя по умолчанию (например, итальянский или английский), что позволяет серверу выбирать веб-страницу на соответствующем языке, если таковая существует. Вообще говоря, расширение имени - задача не такая уж тривиальная, как может показаться, поскольку существует множество соглашений об именовании файлов.

Шаг 2 состоит в проверке идентификационных данных клиента. Это нужно для отображения  страниц, недоступных для широкой  публики.

Шаг 3 проверяет наличие  каких-либо ограничений, накладываемых на данного клиента и его местоположение.

На шаге 4 проверяются  ограничения на доступ к запрашиваемой  странице. Если определенный файл (например, .htaccess) присутствует в том же каталоге, что и нужная страница, он может ограничивать доступ к файлу. Например, можно установить доступ к странице только для сотрудников компании.

Шаги 5 и 6 включают в себя получение страницы. Во время выполнения шага 6 должна быть обеспечена возможность одновременного чтения с нескольких дисков.

Шаг 7 связан с определением типа MIME, исходя из расширения файла, первых нескольких байтов, конфигурационного файла или каких-то иных источников.

Шаг 8 предназначен для различных  задач, таких как построение профиля  пользователя, сбор статистики и т. д.

На шаге 9, наконец, отсылается результат, что фиксируется в журнале активности сервера на шаге 10. Последний шаг требуется для нужд администрирования. Из подобных журналов можно впоследствии узнать ценную информацию о поведении пользователей — например, о том, в каком порядке люди посещают страницы на сайте. Если приходит слишком много запросов в секунду, центральный процессор может перестать справляться с их обработкой вне зависимости от того, сколько дисков параллельно работают на сервере. Решается эта проблема установкой на сервере нескольких узлов (компьютеров). Их полезно укомплектовывать реплицированными (содержащими одинаковую информацию) дисками во избежание ситуации, когда узким местом становится дисковый накопитель. В результате возникает многомашинная система, организованная в виде серверной фермы. Входной модуль по-прежнему принимает входящие запросы, однако распределяет их на сей раз не между потоками, а между центральными процессорами, снижая тем самым нагрузку на каждый компьютер. Отдельные машины сами по себе могут быть многопотоковыми с конвейеризацией, как и в рассматриваемом ранее случае.

Рисунок 4 - серверная форма

 

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

Другая проблема, возникающая  при использовании серверных  ферм, состоит в том, что TCP-соединение клиента заканчивается на входном  модуле, то есть ответ в любом  случае должен пройти через входной  модуль. Эта ситуация показана на рис. 5, а. Здесь как входящий запрос A), так и исходящий ответ B) проходят через входной модуль. Иногда для  обхода этой проблемы применяется хитрость под названием передача TCP. Суть ее в том, что TCP-соединение продлевается до конечного (обрабатывающего) узла, и он может самостоятельно отправить ответ напрямую клиенту (рис. 5, б). Эта передача соединения для клиента незаметна.

Рисунок 5 - Обычный запрос-ответный обмен (а); обмен запросами и ответами при передаче TCP (б)

 

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

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

      1. Соединения

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

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

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

      1. Методы

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

Рисунок 6 - Встроенные методы HTTP-запросов

 

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

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

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

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

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

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

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

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

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

Рисунок 7 - Группы кодов состояния, содержащиеся в ответах сервера

 

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

      1. Пример  использования HTTP

Поскольку HTTP является текстовым  протоколом, взаимодействие с сервером посредством терминала (который  в данном случае выступает как  противоположность браузеру) можно  организовать достаточно просто. Необходимо лишь установить TCP-соединение с портом 80 сервера. Читателю предоставляется  возможность самому посмотреть, как  работает этот сценарий (предпочтительнее запускать его в системе UNIX, поскольку  некоторые другие системы могут  не отображать статус соединения). Итак, последовательность команд такова:

Рисунок 8 - последовательность команд HTTP-протокола

 

Эта последовательность команд устанавливает telnet-соединение (то есть ТСР- соединение) с портом 80 веб-сервера IETF, расположенного по адресу www.ietf.org.

Результат сеанса связи  записывается в файл log, который затем  можно просмотреть. Далее следует  команда GET. Указывается имя запрашиваемого файла и протокол передачи. Следом идет обязательная строка с заголовком Host. Пустая строка, которая находится за ней, также обязательна. Она сигнализирует серверу о том, что заголовки запросов закончились. Командой close (это команда программы telnet) соединение разрывается.

WEB-технологии