Слайд 2
Предмет и задачи курса Основы Интернет-технологий
Предметом данного курса
являются технологии глобальной сети World Wide Web
В рамках
курса будут рассмотрены такие вопросы как:
Структура и принципы Веб (базовые понятия, архитектура, стандарты и протоколы);
Технологии сети Веб (языки разметки и программирования веб-страниц – HTML, CSS и JavaScript, PHP, инструменты разработки и управления веб-контента и приложений для Веб, средства интеграции веб-контента и приложений в Веб).
Сеть Веб представляет собой глобальное информационное пространство, основанное на физической инфраструктуре Интернета и протоколе передачи данных HTTP. Зачастую, говоря об Интернете, подразумевают именно сеть Веб.
Слайд 4
Стандартизация в Интернет
Результат работы по стандартизации воплощается в
документах RFC.
RFC (англ. Request for Comments) — документ из
серии пронумерованных информационных документов Интернета, содержащих технические спецификации и Стандарты, широко применяемые во Всемирной сети.
Слайд 5
Консорциум W3C
Консорциум W3C — организация, разрабатывающая и
внедряющая технологические стандарты для Интернета и WWW. Миссия W3C
формулируется следующим образом: "Полностью раскрыть потенциал Всемирной паутины путем создания протоколов и принципов, гарантирующих долгосрочное развитие Сети". Две другие важнейшие задачи Консорциума — обеспечить полную "интернационализацию Сети" и сделать ее доступной для людей с ограниченными возможностями.
W3C разрабатывает для WWW единые принципы и стандарты, называемые "Рекомендациями", которые затем внедряются разработчиками программ и оборудования. Благодаря Рекомендациям достигается совместимость между программными продуктами и оборудованием различных компаний, что делает сеть WWW более совершенной, универсальной и удобной в использовании.
Все Рекомендации W3C открыты, то есть, не защищены патентами и могут внедряться любым человеком без каких-либо финансовых отчислений Консорциуму.
Для удобства пользователей Консорциумом созданы специальные программы-валидаторы (англ. Online Validation Service), которые доступны по сети и могут за несколько секунд проверить документы на соответствие популярным Рекомендациям W3C.
Слайд 6
Метод аналізу граничних умов
Загальні правила методу аналізу
граничних умов:
побудувати тести для границь множини допустимих значень
вхідних даних і тести з недопустимими значеннями, що відповідають незначному виходу за межі цієї множини.
Наприклад,
для множини [-1.0; 1.0] будуються тести
-1.0; 1.0; -1.001; 1.001;
На практиці з метою локалізації несправностей створюють також тести, що відповідають допустимим значенням, тобто є внутрішніми для множини та ті, що незначно відхиляються від граничних значень:
-1.0; 1.0; -1.001; 1.001;0.999;- 0.999
Слайд 7
Структура и принципы WWW
Сеть WWW образуют миллионы веб-серверов,
расположенных по всему миру. Веб-сервер является программой, запускаемой на
подключенном к сети компьютере и передающей данные по протоколу HTTP.
Для идентификации ресурсов (зачастую файлов или их частей) в WWW используются идентификаторы ресурсов URI (Uniform Resource Identifier). Для определения местонахождения ресурсов в этой сети используются локаторы ресурсов URL (Uniform Resource Locator). Такие URL-локаторы представляют собой комбинацию URI и системы DNS.
Доменное имя (или IP-адрес) входит в состав URL для обозначения компьютера (его сетевого интерфейса), на котором работает программа веб-сервер.
На клиентском компьютере для просмотра информации, полученной от веб-сервера, применяется специальная программа — веб-браузер. Основная функция веб-браузера - отображение гипертекстовых страниц (веб-страниц). Для создания гипертекстовых страниц в WWW изначально использовался язык HTML. Множество веб-страниц образуют веб-сайт.
Слайд 8
Прокси-серверы
Прокси-сервер (proxy-server) — служба в компьютерных сетях, позволяющая
клиентам выполнять косвенные запросы к другим сетевым службам.
Сначала
клиент подключается к прокси-серверу и запрашивает какой-либо ресурс, расположенный на другом сервере. Затем прокси-сервер либо подключается к указанному серверу и получает ресурс у него, либо возвращает ресурс из собственного кеша (если имеется). В некоторых случаях запрос клиента или ответ сервера может быть изменен прокси-сервером в определенных целях. Также прокси-сервер позволяет защищать клиентский компьютер от некоторых сетевых атак.
Слайд 9
Прокси-серверы применяются для следующих целей:
обеспечение доступа с компьютеров
локальной сети в Интернет;
кеширование данных: если часто происходят
обращения к одним и тем же внешним ресурсам, то можно держать их копию на прокси-сервере и выдавать по запросу, снижая тем самым нагрузку на канал во внешнюю сеть и ускоряя получение клиентом запрошенной информации.
сжатие данных: прокси-сервер загружает информацию из Интернета и передает информацию конечному пользователю в сжатом виде.
защита локальной сети от внешнего доступа: например, можно настроить прокси-сервер так, что локальные компьютеры будут обращаться к внешним ресурсам только через него, а внешние компьютеры не смогут обращаться к локальным вообще (они "видят" только прокси-сервер).
ограничение доступа из локальной сети к внешней: например, можно запретить доступ к определенным веб-сайтам, ограничить использование интернета каким-то локальным пользователям, устанавливать квоты на трафик или полосу пропускания, фильтровать рекламу и вирусы.
анонимизация доступа к различным ресурсам. Прокси-сервер может скрывать сведения об источнике запроса или пользователе. В таком случае целевой сервер видит лишь информацию о прокси-сервере, например, IP-адрес, но не имеет возможности определить истинный источник запроса. Существуют также искажающие прокси-серверы, которые передают целевому серверу ложную информацию об истинном пользователе.
Слайд 10
Протоколы Интернет прикладного уровня
Самый верхний уровень в иерархии
протоколов Интернет занимают следующие протоколы прикладного уровня:
DNS - распределенная
система доменных имен, которая по запросу, содержащему доменное имя хоста сообщает IP адрес;
HTTP - протокол передачи гипертекста в Интернет;
HTTPS - расширение протокола HTTP, поддерживающее шифрование;
FTP (File Transfer Protocol - RFC 959) - протокол, предназначенный для передачи файлов в компьютерных сетях; FTP позволяет подключаться к серверам FTP, просматривать содержимое каталогов и загружать файлы с сервера или на сервер; кроме того, возможен режим передачи файлов между серверам; FTP позволяет обмениваться файлами и выполнять операции над ними через TCP-сети. Данный протокол работает независимо от операционных систем.
Telnet (TELecommunication NETwork - RFC 854) - сетевой протокол для реализации текстового интерфейса по сети; Протокол telnet работает в соответствии с принципами архитектуры "клиент-сервер" и обеспечивает эмуляцию алфавитно-цифрового терминала, ограничивая пользователя режимом командной строки. Приложение telnet предоставило язык для общения терминалов с удаленными компьютерами.
SSH (Secure Shell - RFC 4251) - протокол прикладного, позволяющий производить удаленное управление операционной системой и передачу файлов. В отличие от Telnet шифрует весь трафик; Сходен по функциональности с протоколами telnet и rlogin, но, в отличие от них, шифрует весь трафик, включая и передаваемые пароли. SSH-клиенты и SSH-серверы имеются для большинства операционных систем.
Слайд 11
Почтовые протоколы.
POP3(Post Office Protocol Version 3 -
RFC 1939) – протокол почтового клиента, который используется почтовым
клиентом для получения сообщений электронной почты с сервера;
IMAP (Internet Message Access Protocol - RFC 3501) - протокол доступа к электронной почте в Интернет. Аналогичен POP3, однако предоставляет пользователю богатые возможности для работы с почтовыми ящиками, находящимися на центральном сервере. Электронными письмами можно манипулировать с компьютера пользователя (клиента) без необходимости постоянной пересылки с сервера и обратно файлов с полным содержанием писем;
SMTP(Simple Mail Transfer Protocol — RFC 2821) – протокол, который используется для отправки почты от пользователей к серверам и между серверами для дальнейшей пересылки к получателю. Для приема почты почтовый клиент должен использовать протоколы POP3 или IMAP;
.
Слайд 12
Протокол HTTP
HTTP (HyperText Transfer Protocol - RFC 1945,
RFC 2616) - протокол прикладного уровня для передачи гипертекста.
Все
программное обеспечение для работы с протоколом HTTP разделяется на три основные категории:
Серверы - поставщики услуг хранения и обработки информации (обработка запросов).
Клиенты - конечные потребители услуг сервера (отправка запросов).
Прокси-серверы для поддержки работы транспортных служб.
Основными клиентами являются браузеры например: Internet Explorer, Opera, Mozilla Firefox, Google Chrome, Safari и другие. Наиболее популярными реализациями веб-серверов являются: Internet Information Services (IIS), Apache, lighttpd, nginx. Наиболее известные реализации прокси-серверов: Squid, UserGate, Multiproxy, Naviscope.
Слайд 13
Cхема HTTP-сеанса
Установление TCP-соединения.
Запрос клиента.
Ответ сервера.
Разрыв
TCP-соединения.
Таким образом, клиент посылает серверу запрос, получает от
него ответ, после чего взаимодействие прекращается. Обычно запрос клиента представляет собой требование передать HTML-документ или какой-нибудь другой ресурс, а ответ сервера содержит код этого ресурса.
В состав HTTP-запроса, передаваемого клиентом серверу, входят следующие компоненты.
Строка состояния (строка-статус или строка запроса).
Поля заголовка.
Пустая строка.
Тело запроса.
Строку состояния вместе с полями заголовка иногда называют также заголовком запроса.
Слайд 14
Структура запроса клиента.
Строка состояния имеет следующий формат:
метод_запроса URL_pecypca
версия_протокола_НТТР
Слайд 15
Методы запроса
Метод, указанный в строке состояния, определяет способ
воздействия на ресурс, URL которого задан в той же
строке. Метод может принимать значения GET, POST, HEAD, PUT, DELETE и т.д. Несмотря на обилие методов, для веб-программиста по-настоящему важны лишь два из них: GET и POST.
GET - предназначается для получения ресурса с указанным URL. Получив запрос GET, сервер должен прочитать указанный ресурс и включить код ресурса в состав ответа клиенту. Ресурс, URL которого передается в составе запроса, не обязательно должен представлять собой HTML-страницу, файл с изображением или другие данные. URL ресурса может указывать на исполняемый код программы, который, при соблюдении определенных условий, должен быть запущен на сервере. В этом случае клиенту возвращается не код программы, а данные, сгенерированные в процессе ее выполнения. Несмотря на то что, по определению, метод GET предназначен для получения информации, он может применяться и в других целях. Метод GET вполне подходит для передачи небольших фрагментов данных на сервер.
POST - основное назначение - передача данных на сервер. Однако, подобно методу GET, метод POST может применяться по-разному и нередко используется для получения информации с сервера. Как и в случае с методом GET, URL, заданный в строке состояния, указывает на конкретный ресурс. Метод POST также может использоваться для запуска процесса.
Методы HEAD и PUT являются модификациями методов GET и POST.
Слайд 16
Элементы заголовка запроса (продолжение)
Версия протокола HTTP, как правило,
задается в следующем формате:
HTTP/версия.модификация
Поля заголовка, следующие за
строкой состояния, позволяют уточнять запрос, т.е. передавать серверу дополнительную информацию.
Поле заголовка имеет следующий формат:
Имя_поля: Значение
Назначение поля определяется его именем, которое отделяется от значения двоеточием.
Слайд 18
Пример HTML-запроса, сгенерированного браузером
GET http://oak.oakland.edu/ HTTP/1.0
Connection: Keep-Alive
User-Agent:
Mozilla/4.04 [en] (Win95; I)
Host: oak.oakland.edu
Accept: image/gif, image/x-xbitmap, image/jpeg,
image/pjpeg, image/png, */*
Accept-Language: en
Accept-Charset: iso-8859-l,*,utf-8
Получив от клиента запрос, сервер должен ответить ему. Знание структуры ответа сервера необходимо разработчику веб-приложений, так как программы, которые выполняются на сервере, должны самостоятельно формировать ответ клиенту.
Слайд 19
Ответ сервера
Ответ сервера также состоит из четырех перечисленных
ниже компонентов.
Строка состояния.
Поля заголовка.
Пустая строка.
Тело ответа.
Ответ сервера клиенту начинается со строки состояния, которая имеет следующий формат:
Версия_протокола Код_ответа Пояснительное_сообщение
Версия_протокола задается в том же формате, что и в запросе клиента, и имеет тот же смысл.
Код_ответа - это трехзначное десятичное число, представляющее в закодированном виде результат обслуживания запроса сервером.
Пояснительное_сообщение дублирует код ответа в символьном виде. Это строка символов, которая не обрабатывается клиентом. Она предназначена для системного администратора или оператора, занимающегося обслуживанием системы, и является расшифровкой кода ответа.
Слайд 20
Код ответа сервера
Из трех цифр, составляющих код ответа,
первая (старшая) определяет класс ответа, остальные две представляют собой
номер ответа внутри класса. Например, если запрос был обработан успешно, клиент получает следующее сообщение:
HТТР/1.0 200 ОК
За версией протокола HTTP 1.0 следует код 200. В этом коде символ 2 означает успешную обработку запроса клиента, а остальные две цифры (00) — номер данного сообщения.
В используемых в настоящее время реализациях протокола HTTP первая цифра не может быть больше 5 и определяет следующие классы ответов:
1 - специальный класс сообщений, называемых информационными. Код ответа, начинающийся с 1, означает, что сервер продолжает обработку запроса. При обмене данными между HTTP-клиентом и HTTP-сервером сообщения этого класса используются достаточно редко.
2 - успешная обработка запроса клиента.
3 - перенаправление запроса. Чтобы запрос был обслужен, необходимо предпринять дополнительные действия.
4 - ошибка клиента. Как правило, код ответа, начинающийся с цифры 4, возвращается в том случае, если в запросе клиента встретилась синтаксическая ошибка.
5 - ошибка сервера. По тем или иным причинам сервер не в состоянии выполнить запрос.
Слайд 22
Поля заголовка ответа веб-сервера.
Слайд 23
Пример ответа на запрос
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.1
X-Powered-By: ASP.NET
Date:
Mon, 20 OCT 2008 11:25:56 GMT
Content-Type: text/html
Accept-Ranges: bytes
Last-Modified: Sat,
18 Oct 2008 15:05:44 GMTE
Tag: "b66a667f948c92:8a5«
Content-Length: 426
Слайд 24
Безопасность передачи данных HTTP
Протокол HTTP предназначен для передачи
символьных данных в открытом (незашифрованном) виде. Для защиты передаваемых
данных от несанкционированного доступа исполюзуют расширения протокола, самым простейшим из которых является расширение HTTPS, при котором данные, передаваемые по протоколу HTTP, "упаковываются" в криптографический протокол SSL или TLS, тем самым обеспечивая защиту этих данных. В отличие от HTTP, для HTTPS по умолчанию используется TCP-порт 443. Чтобы подготовить веб-сервер для обработки HTTPS соединений, администратор должен получить и установить в систему сертификат для этого веб-сервера.
SSL (Secure Sockets Layer) - криптографический протокол, обеспечивающий безопасную передачу данных по сети Интернет. При его использовании создается защищенное соединение между клиентом и сервером. SSL изначально разработан компанией Netscape Communications. Впоследствии на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший название TLS. Этот протокол использует шифрование с открытым ключом для подтверждения подлинности передатчика и получателя. Поддерживает надежность передачи данных за счет использования корректирующих кодов и безопасных хэш-функций. На нижнем уровне многоуровневого транспортного протокола (например, TCP) он является протоколом записи и используется для инкапсуляции различных протоколов (POP3, IMAP, SMTP или HTTP).
Слайд 25
3 типа аутентификации
Для доступа к веб-страницам, защищенным протоколом
SSL, в URL вместо схемы http, как правило, подставляется
схема https, указывающая на использование SSL-соединения. Стандартный TCP-порт для соединения по протоколу https — 443. Для работы SSL требуется, чтобы на сервере имелся SSL-сертификат.
В сети Веб поддерживаются 3 типа аутентификации при клиент-серверных взаимодействиях:
Basic - базовая аутентификация: имя пользователя и пароль передаются в заголовках http-пакетов. Пароль не шифруется и присутствует в чистом виде в кодировке base64. Для Basic использование SSL является обязательным.
Digest- дайджест-аутентификация: пароль пользователя передается в хешированном виде. По уровню конфиденциальности паролей этот тип мало чем отличается от предыдущего, так как атакующему все равно, действительно ли это настоящий пароль или только хеш от него: перехватив удостоверение, он все равно получает доступ к конечной точке. Для Digest использование SSL является обязательным.
Integrated - интегрированная аутентификация, при которой клиент и сервер обмениваются сообщениями для выяснения подлинности друг друга с помощью протоколов NTLM или Kerberos. Этот тип аутентификации защищен от перехвата удостоверений пользователей, поэтому для него не требуется протокол SSL. Только при использовании данного типа аутентификации можно работать по схеме http, во всех остальных случаях необходимо использовать схему https.
Слайд 26
Cookie
Поскольку HTTP-сервер не помнит предыстории запросов клиентов, то
каждый запрос обрабатывается независимо от других, и у сервера
нет возможности определить, исходят ли запросы от одного клиента или разных клиентов.
Механизм cookie позволяет серверу хранить информацию на компьютере клиента и извлекать ее оттуда.
Инициатором записи cookie выступает сервер. Если в ответе сервера присутствует поле заголовка Set-cookie, клиент воспринимает это как команду на запись cookie. В дальнейшем, если клиент обращается к серверу, от которого он ранее принял поле заголовка Set-cookie, помимо прочей информации он передает серверу данные cookie. Для передачи указанной информации серверу используется поле заголовка Cookie.
Слайд 27
Пример обмена данными Cookie
Предположим, что клиент передает запросы
на серверы А, В и С. Предположим также, что
сервер В, в отличие от А и С, передает клиенту команду записать cookie. Последовательность запросов клиента серверу и ответов на них будет выглядеть приблизительно следующим образом.
Передача запроса серверу А.
Получение ответа от сервера А.
Передача запроса серверу В.
Получение ответа от сервера В. В состав ответа входит поле заголовка SetCookie. Получив его, клиент записывает cookie на диск.
Передача запроса серверу С. Несмотря на то что на диске хранится запись cookie, клиент не предпринимает никаких специальных действий, так как значение cookie было записано по инициативе другого сервера.
Получение ответа от сервера С.
Передача запроса серверу А. В этом случае клиент также никак не реагирует на тот факт, что на диске хранится cookie.
Получение ответа от сервера А.
Передача запроса серверу В. Перед тем как сформировать запрос, клиент определяет, что на диске хранится запись cookie, созданная после получения ответа от сервера В. Клиент проверяет, удовлетворяет ли данный запрос некоторым требованиям, и, если проверка дает положительный результат, включает в заголовок запроса поле Cookie.