Оглавление

1. Введение .................................................................................................................................................. 9
1.1 Компьютерная сеть. История развития. Основные понятия ......................................................... 9
1.1.1 История развития компьютерных сетей ................................................................................... 9
1.1.2 Понятие компьютерной сети ..................................................................................................... 9
1.1.3 Сетевые ресурсы .......................................................................................................................10
1.1.4 Классификация вычислительных сетей ..................................................................................10
1.2 Понятия трафика, сообщения .........................................................................................................10
1.3 Топологии компьютерных сетей ....................................................................................................11
2. Семиуровневая модель взаимодействия открытых систем (OSI – Open System Interconnection) .12
2.1 Схема OSI ..........................................................................................................................................12
2.2 Краткое описание уровней .............................................................................................................13
2.3 Описание взаимодействия уровней ..............................................................................................14
2.4 Коммутация каналов. Коммутация пакетов..................................................................................15
2.4.1 Сеть с коммутацией каналов ...................................................................................................15
2.4.2 Сеть с коммутацией пакетов ...................................................................................................15
3. Физический уровень (Physical layer). Виды сред передачи данных. Кодирование сигналов. ......17
3.1. Характеристики ...............................................................................................................................17
3.2. Классификация сигналов ...............................................................................................................17
3.3 Методы кодирования сигналов. Общие сведения.......................................................................18
3.4 Методы кодирования аналоговых сигналов ................................................................................18
3.4.1. Амплитудная модуляция ........................................................................................................18
3.4.2. Частотная модуляция ..............................................................................................................19
3.4.3. Фазово-импульсная модуляция .............................................................................................19
3.5 Затухание сигналов .........................................................................................................................20
3.5.1 Затухание аналоговых сигналов ..............................................................................................20
3.5.2 Затухание цифровых сигналов ................................................................................................20
3.6 Классификация связи ......................................................................................................................21
3.7.1 TTL-кодирование ......................................................................................................................22
3.7.2 NRZ-кодирование .....................................................................................................................22
3.7.3 Манчестерское кодирование ..................................................................................................23
4. Физическая среда передачи данных и ее разновидности.................................................................24
4.1 Классификация физической среды передачи данных .................................................................24
4.2 Проводная среда .............................................................................................................................24
 4.2.1 RG-58 (коаксиальный кабель)..................................................................................................24
4.2.2 Витая пара .................................................................................................................................24
4.2.3 Оптические линии связи ..........................................................................................................25
4.2.4 Сравнение скорости .....................................................................................................................26
4.3 Беспроводная среда ............................................................................................................................26
4.3.1 Радиосвязь ....................................................................................................................................26
5. Сравнительная характеристика физических топологий.....................................................................27
5.1. Топология «Шина» .........................................................................................................................27
5.2 Топология «Звезда» ........................................................................................................................28
5.3 Топология «Кольцо»........................................................................................................................29
5.4. Гибридная топология ....................................................................................................................30
6. Канальный уровень (Data link layer).....................................................................................................31
6.1 Характеристики ................................................................................................................................31
6.2 Подуровни канального уровня.......................................................................................................31
7. Способы организации и функционирования логических топологий ................................................32
7.1 CSMA/CD ...........................................................................................................................................32
7.1.1 Диаграмма перехода из состояния в состояние (характеризует логику работы сетевой
платы): ................................................................................................................................................32
7.2 CSMA/CA ...........................................................................................................................................33
7.2.1 Логика работы...........................................................................................................................33
7.3 Физическая «шина» и логическое «кольцо» ................................................................................33
7.3.1 Схема состояний .......................................................................................................................34
7.3.2 Установка NID при подключении узлов в сети.......................................................................34
7.4 Логическая топология «Кольцо» ....................................................................................................36
7.5 Топология с логическим «кольцом», физическая «звезда» ........................................................37
8. Устройства канального и сетевого уровня ..........................................................................................38
8.1 Устройства физического уровня .....................................................................................................38
8.1.1 Усилитель ..................................................................................................................................38
8.1.2 Повторитель ..............................................................................................................................38
8.1.3 Концентратор (HUB) .................................................................................................................38
8.2 Устройства канального уровня .......................................................................................................38
8.2.1 Коммутатор (switch) .................................................................................................................38
8.2.2 Сетевая плата ............................................................................................................................38
8.2.3 Типы коммутаторов ..................................................................................................................38
9. Сетевой уровень ....................................................................................................................................40
9.1 Основные характеристики ..............................................................................................................40
 9.2 Протокол IP ......................................................................................................................................40
9.3 Классовая модель............................................................................................................................40
9.4 Понятие маски .................................................................................................................................41
9.5 Зарезервированные IP адреса .......................................................................................................41
9.6. ARP, RARP протоколы .....................................................................................................................41
9.6.1 ARP (address resolution protocol) протокол.............................................................................41
9.6.2 RARP (reverse ARP) протокол ...................................................................................................42
9.6.4 Проблема безопасности: взлом сети методом ARP-ответа (ARP-spoofing, ARP-poisoning)
(man in the middle) .............................................................................................................................43
10.1 Формат пакета ...............................................................................................................................44
11. Конфигурирование узлов....................................................................................................................47
11.1 Общие сведения ............................................................................................................................47
11.2 DHCP (Dynamic Host Control Protocol) ..........................................................................................47
11.3 Конфигурирование сетей. Соединение n сетей с помощью n-1 мостов ..................................47
11.3.1 Соединение узлов внутри одной локально сети .................................................................48
11.3.2 Передача IP-дейтаграммы узлу в другой сети .....................................................................48
11.3.3 Соединение 3х сетей с помощью мостов .............................................................................50
11.3.4 Соединение 4х сетей с помощью мостов .............................................................................51
11.4 Маршрутизация и маршрутизатор...............................................................................................52
12. Транспортный уровень .......................................................................................................................53
12.1 Характеристики ..............................................................................................................................53
12.2 Протоколы транспортного уровня ...............................................................................................53
13. Протокол UDP......................................................................................................................................54
13.1 Общие сведения ............................................................................................................................54
13.2 Сферы использования протокола UDP ........................................................................................54
13.3 Формат пакета...............................................................................................................................55
13.4 Мультиплексирование/демультиплексирование логических каналов ...................................56
13.5 Работа под IP-протоколом ..........................................................................................................56
14. Протокол TCP.......................................................................................................................................57
14.1 Общие сведения ............................................................................................................................57
14.2 Работа протокола IP......................................................................................................................58
14.2.1 Особенности работы протокола IP .......................................................................................58
14.2.2 Алгоритм «скользящего окна» ..............................................................................................59
14.2.3 Структура пакета .....................................................................................................................60
14.3 Установка соединения в TCP («Трехкратное рукопожатие») ....................................................62
15. Гнезда (Socket) ....................................................................................................................................63
 15.1 Общие сведения ............................................................................................................................63
15.2 Принцип организации ...................................................................................................................63
15.3 Сценарии использования .............................................................................................................64
15.3.1 Использование протокола UDP .............................................................................................64
15.3.2 Использование протокола TCP ..............................................................................................65
16. Система доменных имен (DNS) .........................................................................................................70
16.1 Общие сведения ............................................................................................................................70
16.2 Принципы системы именований ................................................................................................70
16.3 Принципы работы DNS ..................................................................................................................72
16.3.1 Итеративный запрос ...............................................................................................................72
16.3.2 Рекурсивный запрос ..............................................................................................................73
17. Язык разметки HTML ..........................................................................................................................74
17.1 Общие сведения ............................................................................................................................74
17.2 Синтаксис HTML ............................................................................................................................74
17.3 Структура HTML-документа ..........................................................................................................75
18. Прокол FTP ...........................................................................................................................................77
18.1 Основные сведения .......................................................................................................................77
18.2 Особенности протокола FTP .........................................................................................................77
18.3 Команды FTP ..................................................................................................................................78
18.4 Пример сессии FTP ........................................................................................................................79
18.5 Примеры работы с FTP в С# с использованием FtpWebRequest , FtpWebResponse ................79
18.5.1 [Link] ........................................................................................................79
18.5.2 Организация скачивания файлов с FTP-сервера (C#) ..........................................................80
18.5.3 Организация загрузки файлов на FTP-сервер (C#)...............................................................81
18.5.4 Получение списка файлов директории FTP-сервера (C#) ...................................................82
19. Telnet ....................................................................................................................................................83
19.1 Общие сведения ............................................................................................................................83
19.2 Реализация, особенности функционирования ...........................................................................83
19.3 Опции..............................................................................................................................................85
19.4 Принтер и клавиатура NVT ...........................................................................................................85
19.5 Структура команд TELNET .............................................................................................................86
19.6 Безопасность ..................................................................................................................................87
20. Протокол POP3 (Post Office Protocol) .................................................................................................88
20.1 Общие сведения ............................................................................................................................88
20.2 Формат команд ..............................................................................................................................88
 20.3 Состояния сеанса ...........................................................................................................................89
20.4 Команды протокола POP3 ............................................................................................................89
20.5 Пример сессии ...............................................................................................................................90
21. Протокол IMAP (Internet Message Access Protocol) ...........................................................................91
21.1 Общие сведения ............................................................................................................................91
21.2 Преимущества IMAP перед POP3 .................................................................................................91
21.3 Общая схема взаимодействия .....................................................................................................92
21.4 Состояния сеанса ...........................................................................................................................92
21.5 Команды протокола IMAP ............................................................................................................93
21.6 Пример сеанса ...............................................................................................................................96
22. SMTP (Simple Mail Transfer Protocol) ..................................................................................................97
22.1 Общие сведения ............................................................................................................................97
22.2 Модель обработки почты .............................................................................................................97
22.3 Возможности протокола ...............................................................................................................99
22.3.1 Основные команды ................................................................................................................99
22.3.1 Дополнительные возможности...........................................................................................101
22.4 Коды ответов SMTP .....................................................................................................................101
22.5 Пример передачи сообщения по протоколу SMTP ..................................................................102
22.6 Промежуточные агенты ..............................................................................................................106
22.7 Безопасность в SMTP ...................................................................................................................108
23. NAT (Network Address Translation)....................................................................................................110
23.1 Общие сведения ..........................................................................................................................110
23.2 Статический NAT ..........................................................................................................................111
23.2.1 Общие сведения ...................................................................................................................111
23.2.2 Достоинства и недостатки статического NAT .....................................................................111
23.2.3 Сфера применения статического NAT.................................................................................112
23.3 Динамический NAT ......................................................................................................................112
23.3.1 Общие сведения ...................................................................................................................112
23.3.2 Работа в сочетании с протоколом TCP ................................................................................113
23.3.3 Работа в сочетании с протоколом UDP ...............................................................................116
23.3.4 Работа связки NAT и DHCP ...................................................................................................118
23.3.5 Достоинства и недостатки ...................................................................................................118
23.3.6 Сфера применения ...............................................................................................................119
24. Сетевые экраны .................................................................................................................................119
24.1 Общие сведения ..........................................................................................................................119
 24.2 Принцип работы ..........................................................................................................................119
24.3 Правила фильтрации ...................................................................................................................120
24.4 Семантические сетевые экраны .................................................................................................121
24.5 Пример создания правила для сетевого экрана Windows ......................................................122
24.6 Особенности фильтрации при использовании протокола UDP ..............................................129
25. UDP hole punching («Проделывание дырок в UDP») ......................................................................130
25.1 Введение ......................................................................................................................................130
25.2 Принцип работы технологии «UDP hole punching» ..................................................................130
25.3 Работа технологии при наличии NAT .........................................................................................133
26. Протокол IPv6.....................................................................................................................................136
26.1 Общие сведения ..........................................................................................................................136
27. VPN (Virtual Private Network) ............................................................................................................140
28. Протокол HTTP ...................................................................................................................................141
28.1 Введение ......................................................................................................................................141
28.2 Пример запроса (request) ...........................................................................................................141
28.3 Пример ответа (response) ...........................................................................................................142
28.4 Пример транзакции .....................................................................................................................143
28.5 Структура запроса........................................................................................................................144
28.5.1 Формат строки запроса ........................................................................................................144
28.5.2 HTTP-заголовки (headers).....................................................................................................144
28.3 Типы (методы) запросов .............................................................................................................144
28.4 HTTP и масштабируемость..........................................................................................................147
28.5 Cookie ............................................................................................................................................148
28.6 Синтаксис URL ..............................................................................................................................148
28.7 HTTP-ответ ....................................................................................................................................148
28.7.1 Строка статуса .......................................................................................................................149
28.7.2 Коды статуса..........................................................................................................................149
28.7.3 Виды заголовков...................................................................................................................149
28.7.4 Заголовок set-cookie .............................................................................................................150
28.8 Виды соединений ........................................................................................................................150
29. Аутентификация и авторизация .......................................................................................................152
29.1 Общие сведения ..........................................................................................................................152
29.2 Виды аутентификации .................................................................................................................152
29.2.1 Базовая аутентификация......................................................................................................153
29.2.2 Аутентификация на основе дайджеста ...............................................................................153
 29.3 Краткий обзор SSL........................................................................................................................155
29.3.1 Общие сведения ...................................................................................................................155
29.3.2 Сертификаты .........................................................................................................................155
29.3.3 Алгоритм работы SSL ............................................................................................................156
23.3.4 Программирование SSL........................................................................................................157
30. Передача данных по протоколу HTTP в режиме реального времени ..........................................158
31. Основы RPC (Remote Procedure Call) ................................................................................................158
31.1 Общие сведения ..........................................................................................................................158
31.2 Описание подхода .......................................................................................................................158
31.3 Технология CORBA .......................................................................................................................160
31.4 Ошибки технологий CORBA и RPC ..............................................................................................160
32. SOA (Service-Oriented Architecture) ..................................................................................................161
32.1 Общие сведения ..........................................................................................................................161
32.2 Сервис и транспорт ......................................................................................................................161
32.3 Использование разных технологий ...........................................................................................162
33. Технология веб-сервисов (веб-служб) .............................................................................................163
33.1 Особенности ................................................................................................................................163
33.2 Основные понятия .......................................................................................................................164
33.3 Принципы создания веб-службы. Применение WCF ...............................................................164
33.4 Пример веб-службы с применением WCF: клиент ..................................................................170
33.5 Пример веб-службы с применением WCF: атрибут ServiceBehavior ......................................173
33.5.1 Режимы создания экземпляра (InstanceContextMode).....................................................173
33.5.2 Режимы параллельного вызова(ConcurrencyMode) .........................................................174
33.6 Пример веб-службы с применением WCF: ручная конфигурация службы ...........................175
34 Веб-службы на основе REST ...............................................................................................................175
34.1 REST ...............................................................................................................................................175
34.2 Реализация собственного протокола взаимодействия клиента и службы ............................176
33.2.1 Пример запроса ....................................................................................................................176
34.2.2 Пример результата вызова ..................................................................................................176
34.2.3 Пример реализации службы ...............................................................................................176
34.2.4 Программа-клиент ...............................................................................................................178
34.3 Веб-службы на основе интерфейса REST (Representational State Transfer) ............................178
34.3.1 История возникновения. Общие сведения ........................................................................178
34.3.2 Отличия веб-служб на основе REST и SOAP........................................................................179
34.3.3 Пример REST веб-службы ....................................................................................................179
 34.3.4 Результат выполнения запроса ...........................................................................................182
34.4 RSS .................................................................................................................................................185
34.4.1 Общие сведения ...................................................................................................................185
34.4.2 Пример реализации RSS ......................................................................................................186
35. Облачные вычисления ......................................................................................................................189
35.1 История возникновения технологии .........................................................................................189
35.2 Возможности технологии виртуализации .................................................................................190
35.3 Суть облачных вычислений ........................................................................................................190
35.4 Разновидности облачных вычислений ......................................................................................190
35.5 Модели развертывания ..............................................................................................................193
36. Базы данных со многими арендаторами (Multi-tenant databases) ...............................................194
36.1 Подходы к организации хранения данных ...............................................................................194
36.2 Создание отдельных баз данных в рамках одной СУБД..........................................................194
36.3 База данных одна, схем данных много .....................................................................................195
36.4 База данных одна, схема данных общая для всех ...................................................................195
36.5 Экономический аспект использования баз данных со многими арендаторами ..................196
37. Распределенные системы.................................................................................................................197
37.1 Масштабирование .......................................................................................................................197
37.1.1 Вертикальное масштабирование ........................................................................................197
37.1.2 Горизонтальное масштабирование ....................................................................................197
37.1.3 Сравнение вертикального и горизонтального масштабирования ...................................198
37.2 Задача создания распределенного файлового хранилища ....................................................198
37.3 Основные требования к распределенным системам ..............................................................199
37.4 Понятие Базы Данных .................................................................................................................199
37.5 Теорема СAP (consistency, availability, partition tolerance) ......................................................200
37.6 Уровни изоляции и проблемы, которые возникают в базах данных .....................................201
37.7 Построение транзакционной распределенной системы .........................................................203
1. Введение

1.1 Компьютерная сеть. История развития. Основные понятия

1.1.1 История развития компьютерных сетей

Первоначально для связи использовались телефонные линии.

Первоначальная модель коммутации каналов:

A B C D

где А, D – абоненты, B,C – телефонные станции. Для коммутации необходимо

столько каналов, сколько нужно соединений. Неэффективно в плане использования
ресурсов.

Новая модель – коммутация пакетов как решение проблемы организации связи

между командными пунктами в ядерной войне.

1.1.2 Понятие вычислительной сети

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

Вычислительную сеть представляют в виде графа, узлами которого являются

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

Говорить о сети можно только в тех случаях, когда имеется обмен

данными между узлами и/или можно вводить/выводить данные.

В сети, в отличие от просто соединенных компьютеров, существует система

адресации, которая позволяет идентифицировать компьютеры в сети.

Сеть – это аппаратно-программный комплекс. Узлы отвечают за обработку

информации, соединения – за передачу информации. Узлом может быть не только
компьютер (например, маршрутизатор для перенаправления потока информации).
1.1.3 Сетевые ресурсы

Сетевые ресурсы(примеры)

Дисковая память
Принтер Модем Процессор
(файловое хранилище)

1.1.4 Классификация вычислительных сетей

Вычислительные сети

Глобальные Локальные
(WAN - Wide Area Network) (LAN – Local Area Network)

Для WAN и LAN существуют совершенно разные стандарты.

Различия между глобальными и локальными сетями

Количество узлов Принцип адресации Адрес компьютера

Локальная Несколько сотен, Физическая адресация Адрес компьютера уже

ограниченное узлов, адрес имеется, компьютер может
количество узлов компьютера – адрес узнать своих соседей путем
сетевого адаптера опроса
Глобальная Миллионы, Логическая адресация Нельзя узнать, кто есть в
неограниченное (IP-адрес) сети.
количество узлов

1.2 Понятия трафика, сообщения

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

Трафик – это количество сообщений, передаваемых во всей сети, в единицу

времени.

Пропускная способность – это предельное количество сообщений, которые могут

передаваться в единицу времени между двумя узлами.
 Чем больше трафик, тем меньше пропускная способность.

Задержка в сети – это время (среднее) доставки сообщения из точки A в точку B и

обратно.

1.3 Топологии компьютерных сетей

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

Топология характеризует свойства сетей, не зависящие от размеров. При этом не

учитывается производительность и принцип работы этих объектов, их типы, длины
каналов, хотя при проектировании эти факторы очень важны.

Топологии сетей:

1) Кольцо

2) Шина

3) Звезда
4) Гибридная

2. Семиуровневая модель взаимодействия открытых систем (OSI – Open

System Interconnection)
Системный подход:
1) Любая система – подэлементы и связи элементов;
2) При разработке каждого элемента его нужно рассматривать как систему;
3) Рассматриваемая система – элемент в системе более высокого порядка;
4) Анализ всех возможных вариантов построения и декомпозиции системы.

2.1 Схема OSI

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

Уровни OSI
Прикладной
Представительный
Сеансовый
Транспортный
Сетевой
Канальный
Физический

Уровень Задача Аналогия

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

Канальный Определяется логическая топология сети, Сетевая плата

правила получения доступа к среде передачи
данных, решаются вопросы, связанные с
адресацией физических устройств в рамках
логической сети и управлением передачей
информации (синхронизация передачи и сервис
соединений) между сетевыми устройствами.
Появляется физическая адресация.
Сетевой Определяет правила доставки данных между IP
логическими сетями, формирование логических (Internet Protocol)
адресов сетевых устройств, определение,
выбор и поддержание маршрутной
информации, функционирование шлюзов
(gateways). Как правило, это программный
уровень. Появляется понятие логической
адресации.
Транспортный Отвечает за надежную передачу пакетов или
потока данных между узлами сети. Он отвечает
за разбиения блока (потока) данных на пакеты,
передачу их по сети и сборку этих пакетов в
правильном порядке. Также он отвечает за TCP, UDP
надежность доставки и должен обеспечивать
повторную передачу при сбое. Появляется
понятие портов – для идентификации
программ.
Сеансовый Способствует взаимодействию между
устройствами, запрашивающими и
поставляющими услуги. Сеансы связи
контролируются посредством механизмов,
которые устанавливают, поддерживают,
синхронизируют и управляют диалогом между Socket
поддерживающими связь объектами. Этот
уровень также помогает верхним уровням
идентифицировать доступный сетевой сервис и
соединиться с ним.
Представитель Основная задача уровня представления
ный данных — преобразование данных во взаимно
согласованные форматы (синтаксис обмена),
понятные всем сетевым приложениям и
компьютерам, на которых работают MIME
приложения. На этом уровне также решаются
задачи компрессии и декомпрессии данных и их
шифрование.
Прикладной Содержит все элементы и функции, Telnet, HTTP, FTP,
специфичные для каждого вида сетевого POP3, SMTP
сервиса. Шесть нижних уровней объединяют
задачи и технологии, обеспечивающие общую
поддержку сетевого сервиса, в то время как
прикладной уровень обеспечивает протоколы,
необходимые для выполнения конкретных
функций сетевого сервиса.

Сеанс связи – это некоторое логическое соединение, в рамках которого

передаются данные.

2.3 Описание взаимодействия уровней

Протокол – правила и стандарты взаимодействия между узлами на одном

уровне.
Интерфейс – правила и стандарты взаимодействия между уровнями на
одном узле.

Информация, передаваемая из программного обеспечения одной

компьютерной системы программному обеспечению другой компьютерной системы,
должна проходить через все уровни модели OSI.
 Пусть, прикладному программному обеспечению в системе 1 необходимо
передать информацию прикладному программному обеспечению в системе 2.
Рассмотрим последовательность этапов передачи:
– прикладная программа системы 1 передаст его информацию на прикладной
уровень (уровень 7) системы 1;
– прикладной уровень передает информацию на уровень представления (уровень 6),
который коммутирует данные на сеансовый уровень (уровень 5), и т.д. вниз до
физического уровня (уровень 1);
– на физическом уровне информация помещается в физическую сетевую среду и
посылается через нее в систему 2;
– физический уровень системы В выбирает информацию из физической среды и
передает ее вверх на канальный уровень (уровень 2), который передает ее на сетевой
уровень (уровень 3), и т.д. вверх, до тех пор, пока информация не достигнет
прикладного уровня (уровень 7) системы В;
– Наконец, в завершение процесса обмена информацией прикладной уровень
системы В передает информацию приемнику – прикладной программе.

2.4 Коммутация каналов. Коммутация пакетов.

2.4.1 Сеть с коммутацией каналов

Рассмотрим компьютерную сеть:

A
D

B С E

G F

Необходимо установить соединение A-F: после установки соединения

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

2.4.2 Сеть с коммутацией пакетов

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

A A
D D

B С E B С E

G F G F
A 2 D

2
1 E Пакеты могут одновременно
B С
(параллельно) передаваться и прийти
1 к F различными путями.
2
1
G F
Такая сеть более эффективна за счет того, что каждый узел, получив данные,
буферизирует их и передает дальше, после чего канал может быть вновь
использован.

t буферизация

первый блок

второй блок

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

Особенности сети с коммутацией пакетов:

– меньшая стоимость, в сравнении со стоимостью сети с коммутацией каналов;

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

3. Физический уровень (Physical layer). Виды сред передачи данных.

Кодирование сигналов.

3.1. Характеристики Уровни OSI

– определяются стандарты кодирования, приема и передачи
Прикладной
сигнала;

– обеспечивает передачу битовых потоков без каких-либо Представительный

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

3.2. Классификация сигналов

Сигналы

Аналоговые Дискретные (цифровые)

(характеризуются непрерывным (характеризуются изменением физической
изменением какой-либо физической величины в ограниченном наборе
величины) значений)
3.3 Методы кодирования сигналов. Общие сведения.
Модуляция – это изменение какой-либо физической величины по закону другой
физической величины.

Демодуляция – это восстановление исходного сигнала.

Методы кодирования

Для аналоговых сигналов Для дискретных сигналов

Амплитудная модуляция TTL-кодирование

Частотная модуляция NRZ-кодирование
Фазово-импульсная модуляция Манчестерское кодирование

3.4 Методы кодирования аналоговых сигналов

3.4.1. Амплитудная модуляция

Амплитудная модуляция — это вид модуляции, при которой изменяемым

параметром несущего сигнала является его амплитуда.

Применение:
 в радиосвязи на длинных волнах;

Достоинства:
 узкая ширина спектра сигнала;
 простота получения сигналов;

Недостатки:
 низкая помехоустойчивость;
 неэффективное использование мощности передатчика.
3.4.2. Частотная модуляция
Частотная модуляция — это вид модуляции, при котором информационный
сигнал управляет частотой несущего колебания. В отличие от амплитудной модуляции,
амплитуда остаётся постоянной.

Применение:
 в радиосвязи на коротких и ультракоротких волнах;

Достоинства:
 высокая помехоустойчивость;
 более эффективное использование мощности передатчика;
 сравнительная простота получения сигналов;

Недостатки:
 более широкий спектр сигнала;

3.4.3. Фазово-импульсная модуляция

Краткое описание: замер мгновенных значений сигнала и передача этих значений
в фиксированные моменты времени.
[Link] Механическое представление:

24 1 24 1

2 2

3 3

Стрелка замыкает контакт. Она вращается с очень большой скоростью. Сигналы

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

Достоинства:
 высокая помехозащищенность линии связи;
 рациональное использование полосы пропускания приемного устройства;

Недостатки:
 необходимость выбора полосы пропускания по самому короткому импульсу.

3.5 Затухание сигналов

3.5.1 Затухание аналоговых сигналов

При затухании аналогового сигнала сохраняется его частота, но уменьшается
амплитуда.

Для удлинения линий связи в случае использования аналоговых сигналов

применяют усилители.

3.5.2 Затухание цифровых сигналов

Цифровой сигнал при затухании теряет свою форму.

Для удлинения линий связи в случае использования аналоговых сигналов

применяют повторители.
3.6 Классификация связи

Связь

Симплексная Полудуплексная Дуплексная

Связь Описание Аналогия

Симплексная Информация передаётся только в одном

направлении. Телевизор

Полудуплексная По одному и тому же каналу связи

прием и передача данных Рация
осуществляется поочередно (связь
расходится во времени).

Дуплексная Двусторонняя связь, которая может

осуществляться одновременно в два Телефон
направления. Необходим двукратный
объем кабеля.
3.7 Методы кодирования дискретных сигналов

3.7.1 TTL-кодирование
Транзисторно-транзисторная логика (ТТЛ, TTL) – это разновидность цифровых
логических микросхем, построенных на основе биполярных транзисторов и резисторов.
Название транзисторно-транзисторный возникло из-за того, что транзисторы
используются как для выполнения логических функций (например, И, ИЛИ), так и для
усиления выходного сигнала. Для синхронизации может быть использован тактовый
генератор.

1 0 1 1 0 1
5

0,1

Достоинства:
 подходит для работы на малых площадях (например, внутри микросхемы);

Недостатки:
 сильное затухание на больших площадях.

3.7.2 NRZ-кодирование
Код NRZ (Non-Return-to-Zero), т. е. без возврата к нулю, является простейшим
двухуровневым кодом. Нулю здесь соответствует нижний уровень сигнала, единице —
верхний. Информационные переходы совпадают с границей битов.

1 1 1 1
+12

-12
0 0 0
синхроимпульс
Особенности NRZ:
1) За счет «+»/«-» можно передавать на большие расстояния сигналы, даже с
учетом возможных потерь;
2) Для восстановления значений необходима линия связи синхроимпульсов, чтобы
приемник считывал все значения.

3.7.3 Манчестерское кодирование

1 и 0 кодируются не уровнем сигнала, а моментом перехода от «+» к «-».Для
синхронизации используются сами переходы.

При манчестерском кодировании каждый такт делится на две части. Информация

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

Нет передачи

0 1 0 1 1 0
Манчестерский
код

Прием идет
4. Физическая среда передачи данных и ее разновидности

4.1 Классификация физической среды передачи данных

Среды передачи данных

Проводные Беспроводные
(RG-58, витая пара) (Bluetooth, Wi-Fi)

4.2 Проводная среда

4.2.1 RG-58 (коаксиальный кабель)

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

тонкий – 25м
толстый – 500м
скорость передачи данных ≈ 10 Мбит/c

Используется для передачи аналогового сигнала. Оплетка необходима для

экранирования передаваемой волны.

4.2.2 Витая пара

Витая пара — это вид кабеля связи, который представляет собой одну или
несколько пар изолированных проводников, скрученных между собой, покрытых
пластиковой оболочкой. Имеет минимум 4 жилы (для дуплексной связи).

Скручивание обеспечивает защиту от помех.

 Как правило, применяются для передачи цифрового сигнала (например, с
использованием манчестерского кодирования).

Категорию витой пары определяет количество проводов, качество проводов,

экранированность (используется металлическая оплетка). В зависимости от категории
скорость может быть равна 4, 10, 100 Мбит/с, самые лучшие ≈ 1 Гбит/с.

Восьмижильная витая пара: 2 канала в одном направлении, два – в другом.

4.2.3 Оптические линии связи

Современные линии связи.

 сложнее в производстве и монтаже, следовательно – дороже;

 очень высокая помехозащищенность;
 высокая секретность;
 высокая скорость передачи данных (до сотен Гбит/c).

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

Пропускная способность линий связи измеряется в бит/c, а не байт/с, т.к.

передача байтов требует дополнительного учета.

4.2.4 Сравнение скорости

1) Оптические линии связи
2) Витая пара
3) Коаксиальный кабель

4.3 Беспроводная среда

4.3.1 Радиосвязь
Радиосвязь (например, Wi-Fi) имеет перспективы для беспроводной передачи
данных, хотя сейчас и имеет малую скорость передачи данных.

Достоинства:

 Приводит к намного более простому устройству компонентов.

5. Сравнительная характеристика физических топологий

5.1. Топология «Шина»

Коаксиальный кабель (сжатое в размер жилы пространство), с которым
выполняется врезка Т-разъемов.

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

Сервер
Сервер
ПК
ПК ПК
ПК

Шина

ПК
ПК ПК
ПК ПК
ПК

Способ передачи информации:

Данные в виде электрических сигналов передаются всем компьютерам сети.

Однако информацию принимает только тот компьютер, адрес которого

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

Достоинства топологии «Шина»

1) Вся информация находится в сети и доступна каждому компьютеру;

2) Рабочие станции можно подключать независимо друг от друга. Т.е. при
подключении нового абонента нет необходимости останавливать передачу информации в
сети;
3) Построение сетей на основе такой топологии является довольно дешевым,
т.к. отсутствуют затраты на прокладку дополнительных линий при подключении нового
клиента; не требуются дорогостоящие коммутаторы;
4) Сеть обладает высокой надежностью, т.к. работоспособность сети не зависит
от работоспособности отдельных компьютеров.
Недостатки топологии «Шина»

1) Низкая скорость передачи данных, т.к. вся информация циркулирует по одному

каналу (шине);
2) Быстродействие сети зависит от числа подключенных компьютеров. Чем
больше компьютеров подключено к сети, тем медленнее идет передача информации от
одного компьютера к другому;
3) Для сетей характерна низкая безопасность, так как информация на каждом
компьютере может быть доступна с любого другого компьютера.

5.2 Топология «Звезда»

Звезда – это топология сети, в которой информация между клиентами сети

передается через единый центральный узел. В качестве центрального узла может
выступать сервер или специальное устройство – концентратор (Hub).

ПК
ПК ПК
ПК

Сервер
Сервер

ПК
ПК ПК
ПК ПК
ПК

Достоинства топологии «Звезда»

1) Высокое быстродействие сети, так как общая производительность сети

зависит только от производительности центрального узла;
2) Отсутствие столкновения передаваемых данных, так как данные между
рабочей станцией и сервером передаются по отдельному каналу, не затрагивая другие
компьютеры.
3) Разрыв кабеля не приводит к остановке сети;

Недостатки топологии «Звезда»

1) Надежность всей сети ограничена надежностью центрального узла. Если

центральный компьютер выйдет из строя, то работа всей сети прекратится;
2) Высокие затраты на подключение компьютеров, так как к каждому новому
абоненту необходимо ввести отдельную линию (высокий расход кабеля).
5.3 Топология «Кольцо»
Кольцо – это топология сети, в которой все компьютеры подключаются к линии,
замкнутой в кольцо. Сигналы передаются по кольцу в одном направлении и проходят
через каждый компьютер.

Сервер
Сервер

ПК
ПК ПК
ПК

ПК
ПК ПК
ПК

ПК
ПК

Способ передачи информации:

Маркер (специальный сигнал) последовательно, от одного компьютера к другому,

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

Получив маркер, компьютер создает так называемый «пакет», в который

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

После этого компьютер, получивший данные, посылает отправителю

подтверждение факта получения данных.

Получив подтверждение, компьютер-отправитель создает новый маркер и

возвращает его в сеть.
Достоинства топологии «Кольцо»

1) Пересылка сообщений является очень эффективной, т.к. можно отправлять

несколько сообщений друг за другом по кольцу. Т.е. компьютер, отправив первое
сообщение, может отправлять за ним следующее сообщение, не дожидаясь, когда первое
достигнет адресата;
2) Значительная протяженность сети: компьютеры могут подключаться к друг к
другу на значительных расстояниях без использования специальных усилителей сигнала;
3) Отсутствие коммутатора

Недостатки топологии «Кольцо»

1) Низкая надежность сети, так как обрыв кабеля ведет к прекращению

функционирования сети;
2) Для подключения нового клиента необходимо остановить работу сети;
3) При большом количестве клиентов скорость работы в сети замедляется,
каждый компьютер должен пропустить через себя всю информацию, а их возможности
ограничены;
4) Общая производительность сети определяется производительностью самого
медленного компьютера.

5.4. Гибридная топология

Гибридная/смешанная топология – это комбинация нескольких различных топологий.
6. Канальный уровень (Data link layer) Уровни OSI
6.1 Характеристики Прикладной
– отвечает за организацию и совместное использование
среды передачи данных; Представительный
– стандартизируются методы доступа к среде передачи
данных; Сеансовый
– возникает физическая адресация узлов, следовательно,
Транспортный
обеспечивается адресная доставка в среде передачи
данных; Сетевой
– упорядочивается передача с целью обеспечения
возможности параллельного использования одного Канальный
физического канала несколькими парами абонентов;
– обеспечивается проверка ошибок, которые могут Физический
возникать при передаче данных физическим уровнем;
– большинство функций канального уровня выполняются устройствами передачи данных
(например, сетевым адаптером);
– каждому компьютеру выделяется свой уникальный адрес (MAC-адрес).

6.2 Подуровни канального уровня

Канальный уровень: подуровни

LLC MAC
(Logical Linking Control ) (Media Access Control)

Уровень управления логическими Уровень управления доступом к

связями среде передачи данных

MAC-адрес – это уникальный идентификатор, присваиваемый каждой единице

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

7.1 CSMA/CD
CSMA/CD (Carrier Sense Multiple Access with Collision Detection) – это метод доступа с
распознаванием несущей частоты, множественным доступом и обнаружением коллизий.
Используется в сетевой технологии Ethernet.

Сетевая технология – это набор стандартов, который используется для

создания общего решения.

7.1.1 Диаграмма перехода из состояния в состояние (характеризует логику работы

сетевой платы):

Условные обозначения

Состояние

Событие / коллизия
Прием кадра
MID My ID

MID Кадр
Коллизия
принят принят

Сброс
Прослушивание
Запуск
Среда занята Запрос на Передача
передачу завершена
кадра Среда свободна
Ожидание Передача

Время
Коллизия
задержки
истекло

Задержка

Все компьютеры слушают моноканал. Компьютер, которому необходимо передать

данные, дожидается, когда в канале наступит «тишина», и начинает передачу. Передача
идет небольшими кадрами, в заголовке которых указывается MAC-адрес целевого
компьютера.

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

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

1) генератор случайных чисел

2) пропорционально MAC-адресу

7.2 CSMA/CA

CSMA/CA (Carrier Sense Multiple Access With Collision Avoidance) – это метод доступа
с множественным доступом, контролем несущей частоты и избеганием коллизий.

7.2.1 Логика работы

Прежде чем начать передачу данных, сетевая плата посылает RTS-запрос (Request
to send). Он очень короткий, предупреждает сетевые узлы, чтобы они воздержались от
передачи данных.

Коллизии практически отсутствуют, однако существует вероятность столкновения

RTS-запросов. Такая ситуация обрабатывается аналогично CSMA/CD.

CSMA/CD, работает лучше CSMA/CA при малом трафике.

CSMA/CA работает лучше CSMA/CD при высоком трафике.

7.3 Физическая «шина» и логическое «кольцо»

Данный метод доступа – это метод с передачей маркера в топологии «шина».

MID = 2 MID = 3 MID = 5

NID = 3 NID = 5 NID = 2

Условные обозначения
MID My ID
NID Next ID

– шинная технология с передачей по моноканалу (т.е. все слышат, что передают другие);
– все узлы объединяются в логическую цепочку;
– происходит передача «права передачи» – маркера. Это право переходит от узла к узлу;
– каждый компьютер кроме собственного ID (MID) хранит ID следующего компьютера,
которому передается маркер (NID). Компьютер, который сейчас имеет маркер, передает
пакет с маркером в сеть. Компьютер NID, получив пакет от предыдущего компьютера,
смотрит, пустой ли пакет. Если пакет не пустой, то он передается дальше (с маркером).
Если пакет пустой, то этот компьютер «берет» маркер и начинает передачу.

7.3.1 Схема состояний

NID установлен

Прослушивание

Маркер передан

MID принят

Прием

Маркер принят и нет Маркер принят и

пакета для передачи есть пакет для
передачи

Передача маркера Пакет передан Передача пакета

7.3.2 Установка NID при подключении узлов в сети

Условие: Пусть сеть уже работает и необходимо включить в нее новый узел.

Старт

Сбой

Сбой завершен

Маркер Бездействие
потерян Сбой среды

Тайм-аут или
Нормальная работа маркер принят Ожидание ввода сбоя

NID установлен Нет никого

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

Все компьютеры переходят в состояние бездействия. В этом состоянии они

находятся некоторое время (время тайм-аута) и ожидают приема маркера. Время тайм-
аута пропорционально MID, следовательно, тайм-аут у компьютера с меньшим
номером истечет раньше.

Когда время тайм-аута истекло, компьютер из состояния бездействия переходит в

состояние опроса. В этом состоянии он начинает передавать маркер компьютеру с
номером на 1 больше, чем у него.

Компьютера с таким номером в сети может не быть. В таком случае после

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

Если обнаруживается компьютер, у которого такой номер, то он принимает

этот маркер и переходит из состояния бездействия в состояние опроса (сам начинает
передачу маркера компьютеру с номером на 1 больше). А предыдущий компьютер,
услышав, что маркер принят, запоминает номер компьютера в NID и переходит в
нормальную работу.

Когда NID доходит до максимального значения, то счетчик переполняется и

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

В любой сетевой плате передатчик и приемник разделены.

Условные обозначения
R – receiver - приемник R T

T – transmitter - передатчик

- Маркер

T R

R T

T R

Описание работы:
– циркулирует один или несколько маркеров;
– если необходимо передать данные, то передается маркер (в заголовке – получатель
данных) и данные;
– когда данные приняты узлом, для которого они предназначены, маркер передается
дальше с пометками, успешно ли принят пакет;
– когда маркер вернется к исходной плате, существует возможность определить, успешно
ли передан пакет.

Каждый маркер увеличивает способность передачи. Применяется при построении

оптоволоконных сетей.
7.5 Топология с логическим «кольцом», физическая «звезда»
Физическая топология может отличаться от логической топологии. Например,
физической топологией может быть «звезда».
При работе с такой топологией в сети может существовать несколько
маркеров одновременно. По сути, маркер постоянно циркулирует по сети, и пропускная
способность мало зависит от трафика, следовательно, она максимальна. Скорость
передачи маркера очень высокая.

Условные обозначения
R – receiver - приемник R T
T – transmitter - передатчик

T R

R T

T R
8. Устройства канального и сетевого уровня

8.1 Устройства физического уровня

8.1.1 Усилитель
Усилитель используется для удлинения линии связи аналогового сигнала с
частотной модуляцией.

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

8.1.3 Концентратор (HUB)

Концентратор ничего не знает о MAC, с одного входа на многие выходы.
Используется для соединения линий связи. Обеспечивает ретрансляцию сигнала с одного
входа на много выходов. Применяется в топологии «звезда». Работает на физическом
уровне (это физическая коммутация проводов).

8.2 Устройства канального уровня

8.2.1 Коммутатор (switch)

Коммутатор (switch) – знает о MAC. Интерпретирует пакеты канального уровня.

8.2.2 Сетевая плата

8.2.3 Типы коммутаторов

Логика коммутатора во многом повторяет логику сетевой платы.

D E F

Условные обозначения
HUB
Switch
A B C
1) Без буферизации пакетов. Принимает заголовок и перенаправляет в нужные
порты (использует MAC-адрес). Буферизация пакетов не производится;
 2) Буферизирующий. Принимает пакет в память, анализирует его и передает по
нужному MAC-адресу. Ускоряет работу сети и сокращает конфликты технологии Ethernet
за счет внутренней прокладки;
3) Маршрутизирующий. Также буферизирующий коммутатор, у которого имеется
дополнительная логика маршрутизации пакетов канального уровня. Обеспечивают
серьезное ускорение работы сети и сокращение конфликтов за счет внутренней изоляции
маршрутов. По этой причине используется CSMA/CD.

Коммутатор дает резкое увеличение безопасности сети, т.к. уменьшает проблему

«прослушивания» сети.
 9. Сетевой уровень

9.1 Основные характеристики Уровни OSI

Прикладной
– главная функция – это маршрутизация
сообщений в сети; доставка сообщений в глобальной Представительный
сети, минуя один или несколько узлов (не между
программами, а между узлами). Сеансовый
– вводится понятие логической адресации. Этот
адрес выдается через специальную организационную Транспортный
процедуру и может быть известен (в локальной сети,
Сетевой
например, можно выполнить опрос узлов и узнать MAC-
адрес). Канальный
Физический

9.2 Протокол IP

Internet Protocol (IP) — маршрутизируемый протокол сетевого уровня стека TCP/IP.

IPv4 (Internet Protocol version 4) – 32x-разрядное значение логических адресов.
IPv6 (Internet Protocol version 6) –128x-разрядное значение логических адресов.

IPv4
 4 байта для значения адреса;
 IP-адрес представляет собой набор десятичных чисел [0; 255], разделенных
точками.

IP = [Link]

9.3 Классовая модель

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

А 0 7-разрядный номер сети 24-разрядный номер узла

B 10 14-разрядный номер сети 16-разрядный номер узла

C 110 21-разрядный номер сети 8-разрядный номер узла

D 1110 28-разрядный номер группы

D используется для маршрутизаторов.

9.4 Понятие маски

Маска – это 32х-битное значение, старшие биты которого установлены в единицу,

младшие – в ноль. Маска определяет, какая часть IP-адреса узла сети относится к адресу
сети, а какая — к адресу самого узла в этой сети.

IP [Link]
Маска [Link]

IP and Маска = номер сети = [Link]

IP and (not Маска) = номер узла в сети = [Link] and [Link] = [Link]

9.5 Зарезервированные IP адреса

IP адрес Описание
0 IP-адрес с нулевым номером хоста используется для адресации ко всей
сети.
[Link] IP адрес своего же узла, по которому узел передает сообщение самому
себе, независимо от того, какой у него на самом деле IP-адрес.
[Link] Широковещательный адрес (адрес сообщений, направляемых всем
узлам текущей сети).
192.168.___.___ Некоторые IP-адреса зарезервированы для локальных сетей, т.е.
10.10.___.___ гарантируется, что в глобальной сети не будет узлов с такими адресами.

9.6. ARP, RARP протоколы

Работа протокола IP поверх Ethernet обеспечивается за счет следующих

протоколов:
1) ARP (address resolution protocol) – протокол определения адреса;
2) RARP (reverse ARP) – обратный протокол преобразования адресов.

9.6.1 ARP (address resolution protocol) протокол

Если какой-либо узел с IP адресом желает послать в локальную сеть сообщение

другому узлу, то он должен знать IP адрес получателя.

Т.к. для передачи на канальном уровне необходимо знать MAC-адрес узла,

которому предназначено сообщение, следовательно, нужно узнать MAC-адрес узла по его
IP адресу.
 Для этого используется ARP: узел посылает в сеть широковещательный пакет вида

IP отправителя IP адрес получателя

MAC отправителя Пусто

Узел получает ARP-ответ вида

IP отправителя IP адрес получателя

MAC отправителя МАС получателя

Узел по IP узнал MAC.

9.6.2 RARP (reverse ARP) протокол

RARP-протокол позволяет по MAC-адресу узнать IP адрес.

RARP применяется для удаленной загрузки компьютеров в сети, т.е. для

работы «бездисковых» компьютеров. Компьютеру при удаленной загрузке необходимо
узнать адрес сервера, с которого он загружается.

Диапазоны IP-адресов выдаются организацией NIC (Network Informational Center)

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

9.6.3 Подход для решения проблемы увеличения трафика

Каждый узел ведет у себя ARP-таблицу вида

IP адрес MAC-адрес Время, когда пришел ARP-ответ

После того как узел в первый раз посылает ARP-запрос, он сохраняет ответ в кэш-
таблице. Во второй раз поиск производится в таблице и ARP-запрос не выполняется. Если
прошло определенное время, то запись из таблицы удаляется.
9.6.4 Проблема безопасности: взлом сети методом ARP-ответа (ARP-spoofing, ARP-
poisoning) (man in the middle)

Условие: Узел A хочет взаимодействовать с узлом B.

A IPA, MACA

C IPC, MACC B IPB, MACB

1) Узел A хочет взаимодействовать с узлом B, посылает широковещательный ARP-

запрос, чтобы узнать МАС-адрес В.

2) Узел С посылает ARP-ответ со своим значением МАС-адреса.

IP MAC t отправления
IP адрес B MAC адрес C t отправления

Узел B также посылает ARP-ответ со своим значением MAC-адреса.

3) К узлу А вернется 2 ответа. Будет принят тот, который придет первым, а второй
ответ не будет подтвержден.

4) Далее узел С посылает ARP-запрос на IP адрес узла В и узнает MAC-адрес узла В.

5) Когда посылаются пакеты между узлами А и В, физически они попадают к узлу С.

Узел С после приема пакета отправляет его в сеть узлу В.

Результат: весь трафик между узлами А и В проходит через узел С. Узел С – узел-
посредник.

Попытки решения проблемы: имеется некоторый фильтр, который пытается

проанализировать, что делать в случае, если возвращается не один ARP-ответ.
10. Протокол IP

10.1 Формат пакета

IP пакет состоит из
–заголовок;
– данные.

Минимальный размер заголовка – 5 32х-разрядных слов. Может быть больше.

Заголовок всегда кратен 4 байтам.

Длина
Версия заголовка Тип службы Общая длина в байтах
версии
Флаг
IP Пакета (16 бит) (2 Смещение фрагмента (14 бит)
бита)

Время жизни (8 бит) Протокол (8 бит) Контрольная сумма (16 бит)

IP Адрес отправителя

IP Адрес получателя

Параметры Дополнение нулями до границы 4 байт

Данные

Обязательная часть

Область Описание
пакета
Версия Кодирует версию IP-протокола. Версия необходима для
интерпретации остального содержимого IP-пакета.
Длина заголовка Размер в 32х-разрядных словах минус минимальный размер
версии заголовка. 0 – длина заголовка 5, т.к. просто значения 0, 1 ,2 смысла
не имеют.
Тип службы Несколько битов, которые задают требования.

PR D T R

PR – высокоприоритетный пакет;
D (delay) – при передаче нужно минимизировать задержку;
T (трафик) – передавать пакет по пути с наименьшим трафиком;
R (reliability) – передавать по наиболее надежному пути.
 Биты наглядно показывают, что протокол IP разрабатывался именно в
военных целях.

Добраться к любому узлу можно разными маршрутами:

Общая длина в Общая дина пакета (IP дейтаграммы). Максимальное значение –

байтах 65535 байт – это значение иногда может использоваться, чтобы
показать, что размер IP дейтаграммы превышает 65535 байт, затем
происходит вычисление реальных размеров.
ID пакета Позволяет идентифицировать и отличать пакеты друг от друга.
Обеспечивает возможность фрагментации и сборки пакетов: длинная
дейтаграмма может быть разбита на несколько дейтаграмм с одним и
тем же ID пакета.
Флаги 0 – не фрагментировать,
М – больше нет фрагментов.

Если 0 не установлен, то для дейтаграммы была выполнена

фрагментация.
Если установлен флаг М, то это последний фрагмент дейтаграммы.
Смещение Логическое смещение байтов, которые нужно вложить в
дейтаграмму.

Дейтаграмма

Фрагмент
Фрагмент 1 Фрагмент 2
3

Можно пронумеровать фрагменты и собрать дейтаграмму.

Вопрос: приняли фрагмент 2, где его хранить?

Ответ: вместо нумерации используется позиция в байтах, где лежит
пакет. Смещение сразу показывает, куда вложить пакет.
TTL (time to life) – Показывает, сколько секунд/миллисекунд провел пакет в сети – это
время жизни было первоначальное предназначение. На данном этапе это значение
играет роль счетчика количества маршрутизаторов, через которые
прошел пакет. Максимальное количество – 255. Счетчик обратный.
 255 – это максимальное количество узлов, через которые два узла в
сети могут быть связаны. Когда значение поля достигает 0, пакет
выбрасывается. Это дает сети возможность «выжить» в случае
неправильной настройки (зацикливание пакета становится
невозможным).

A B

C
Протокол Код протокола (UPD, TCP, ICMP – internet control message protocol)
более высокого уровня, пакет которого передается в качестве данных
дейтаграммы. Протокол позволяет понять, как интерпретировать
данные, которые затем передаются на обработку драйверам UPD,
TCP, и т.д.
Контрольная Это дополнение к единице суммы всех байтов заголовка.
сумма Обеспечивает устойчивость, защиту от ошибок, наводок и т.д.
IP-адрес Значения необходимо читать как байты, а затем восстанавливать.
получателя
IP-адрес
отправителя
Параметры Дополнительные опции для управления дейтаграммой: код команды
(1,2 байта), 1,2,3 – дополнительные байты параметров. В сумме
параметры могут не быть кратны 4 байтам, тогда их следует
дополнять нулями.
11. Конфигурирование узлов

11.1 Общие сведения

При конфигурировании узлов каждый узел имеет следующие параметры

конфигурации протокола IP:

1) уникальный IP;
2) маска подсети, которая позволяет понять, куда направляется сообщение (в
локальную или глобальную сеть);
3) стандартный шлюз – это тот IP-адрес, на который передается сообщение, если оно
адресовано не в ту локальную сеть, к которой подключен узел.

Значения этих параметров могут быть заданы статически в конфигурации IP-

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

11.2 DHCP (Dynamic Host Control Protocol)

DHCP-сервер содержит у себя таблицу MAC-адресов и соответствующих им IP-

адресов. Клиенты, которые вошли в сеть и не имеют параметров протокола IP для работы,
обращаются с широковещательным запросом и обнаруживают DHCP-сервер, который им
отвечает, указывает свой IP адрес and MAC-адрес, на который узел посылает запрос с
просьбой выдать ему параметры конфигурации для работы в локальной сети.

DHCP-сервер ведет у себя таблицу IP-адресов и соответствующих им МАС-адресов.

Когда к серверу приходит запрос, то в таблице появляется новая запись. Из пула
свободных адресов выдается IP, в таблицу вписывается MAC адрес того узла, от которого
пришел запрос, а также время, до которого это соответствие является действительным
(«время аренды»).

В DHCP можно указать, что для определенных МАС адресов необходимо выдавать
определенные IP-адреса.

11.3 Конфигурирование сетей. Соединение n сетей с помощью n-1 мостов

Будем считать, что параметры конфигурации для узлов были установлены.

Условие: Возникает необходимость соединить несколько локальных сетей между

собой.
 11.3.1 Соединение узлов внутри одной локально сети

Условие: по IP-адресу нужно передать пакет какому-то узлу в локальной сети.

1) IP адрес отправителя [Link]

IP адрес получателя [Link]

2) На адреса накладывается маска (например, [Link]) с помощью логической

операции «И»:

[Link] + маска = [Link]

[Link] + маска = [Link]

В результате проделанной операции получили номер подсетей.

3) Номера подсетей совпали, следовательно, узел-отправитель и узел-получатель

находятся в одной локальной сети.

4) Драйвер протокола IP выполняет следующие действия:

– с помощью протокола ARP выясняет по IP-адресу MAC-адрес узла с IP адресом

[Link];
– упаковать IP-дейтаграмму в пакет Ethernet с указанием MAC-адреса;
– отсылает по локальной сети пакет к узлу с адресом [Link].

5) Узел [Link] проверяет, что указанный МАС-адрес совпадает с его собственным

адресом, извлекает пакет и его содержимое.

11.3.2 Передача IP-дейтаграммы узлу в другой сети

Условие: Передача IP-дейтаграммы узлу, который не находится в этой локальной сети.

K1 IP: [Link]
Default gateway: [Link] K1 [Link] – M1 IP для первой сети
[Link] – маска для первой сети
[Link] – номер первой подсети
M1 [Link] – М1 IP для второй сети
[Link] – маска для второй сети
[Link] – номер второй подсети

K2 IP: [Link]
Default gateway: [Link]
K2
 Свяжем 2 сети через узел М1, который будет являться мостом (стандартный шлюз,
default gateway, шлюз по умолчанию), т.е. он будет двумя сетевыми платами физически
подключен к двум сетям.

Предположим, узел К1 хочет передать пакет узлу К2. Если на узле М1 работает
автоматический маршрутизатор IP-дейтаграмм по нужной сети, то передача будет
происходить следующим образом:

1) Поскольку у узла М1 2 сетевых платы, для каждой сетевой платы будет указана своя
конфигурация протокола IP:

[Link] – IP-адрес для первой сети (сети, в которой находится узел K1)
[Link] – IP-адрес для второй сети (сети, в которой находится узел K2)

2) Узел K1 накладывает маску

на свой IP-адрес:

[Link] + маска = [Link]

на IP-адрес K2:
[Link] + маска = [Link]

Узел К1 понимает, что, поскольку подсети не совпадают, то узлы находятся в

разных подсетях, значит нет смысла выяснять МАС адрес.

4) К1 ([Link]) передает пакет для К2 на MAC-адрес стандартного шлюза c IP-адресом

[Link].

5) Узел М1 принимает пакет и понимает, что IP-адрес, указанный в качестве целевого, не

совпадает со своим IP-адресом (Сверяет с двумя IP-адресами).

6) М1 понимает, что пакет идет в другую сеть. В какую? М1 накладывает маску на свой
первый IP-адрес – [Link], на второй – [Link]. На адрес получателя М1 также
накладывает маску и видит, что [Link] подсети совпали. Тогда М1 осуществляет
перенаправление пакета во вторую сеть.

7) М1 выясняет МАC-адрес для узла [Link] (ARP-метод). На этот МАС-адрес

отправляется пакет, который пришел от К1.

8) К2 получает пакет, проверяет, что IP-адрес получателя совпал с его собственным

адресом и пакет считается принятым.

9) К2, получив пакет, его обрабатывает и, предположим, желает отослать ответ на адрес
[Link]. Процедура, описанная выше, повторяется.
11.3.3 Соединение 3х сетей с помощью мостов

K1 IP: [Link]
Default gateway: [Link] [Link] – M1 IP для первой сети
K1 [Link] – маска для первой сети
[Link] – номер первой подсети
[Link] – default gateway
M1
[Link] – М1 IP для второй сети
[Link] – маска для второй сети
[Link] – номер второй подсети

K2 IP: [Link] [Link] – M2 IP для второй сети

Default gateway: [Link] K2 [Link] – маска для второй сети
[Link] – номер второй подсети
[Link] – default gateway
M2
[Link] – М2 IP для третьей сети
[Link] – маска для третьей сети
[Link] – номер третьей подсети

K3 IP: [Link]
Default gateway: [Link] K3

1) Подключаем к сети еще один узел М2 с двумя сетевыми платами, одну из плат
подключаем к сети номер 3.

2) Конфигурируем мосты М1, М2, указывая у них в качестве стандартного шлюза друг
друга.

3) Если узел К1 начнет передавать пакет узлу К3, то передача будет осуществляться по
цепочке:
К1 -> М1 -> М2 -> К3
4) Ответ от узла К3 узлу К1 пройдет следующую цепочку:

К3 –> М2 –> М1 –> К1

11.3.4 Соединение 4х сетей с помощью мостов

Вопрос: что произойдет, если добавить четвертую сеть, соединенную через мост
М3? Для М3 в качестве шлюза прописывается М2 ([Link]).

K1 IP: [Link]
Default gateway: [Link] [Link] – M1 IP для первой сети
K1 [Link] – маска для первой сети
[Link] – номер первой подсети
[Link] – default gateway
M1
[Link] – М1 IP для второй сети
[Link] – маска для второй сети
[Link] – номер второй подсети

K2 IP: [Link] [Link] – M2 IP для второй сети

Default gateway: [Link] K2 [Link] – маска для второй сети
[Link] – номер второй подсети
[Link] – default gateway
M2
[Link] – М2 IP для третьей сети
[Link] – маска для третьей сети
[Link] – номер третьей подсети

K3 IP: [Link]
Default gateway: [Link] K4 IP: [Link]
K3 Default gateway: [Link]
M3

K4
[Link] – M3 IP для третьей сети
[Link] – маска для третьей сети
[Link] – номер третьей подсети
[Link] – default gateway

[Link] – М3 IP для четвертой сети

[Link] – маска для четвертой сети
[Link] – номер четвертой подсети

1) Если узел К4 хочет передать сообщение К1, произойдет следующее:

К1 –> М3 –> М2 –> М1 –> К1

2) Если узел К1 пожелает отправить ответ узлу К4, то произойдет следующее:

К1 –> М1 –> М2 –> М1 –> М2 –> М1 -> … ,

т.е. произойдет зацикливание пакета, который будет циркулировать, пока счетчик
TTL не уменьшится до 0 и пакет не будет выброшен.

Вывод: три сети могут быть соединены мостами, а 4 не могут, т.к. пакеты будут
проходить только в одну сторону (т.к. ни М1, ни М2 не ссылаются на М3). Невозможно
построить глобальную сеть Интернет без понятия маршрутизатора и маршрутизации.
11.4 Маршрутизация и маршрутизатор

Маршрутизатор – это устройство третьего сетевого уровня, он отличается от

коммутатора тем, что работает не с кадрами Ethernet, а с IP-дейтаграммами – пакетами
более высокого уровня, интерпретирует их.

Маршрутизатор содержит таблицу маршрутизации, которая показывает, что делать

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

Вывод: если бы М1, М2, М3 (см. пункт 6.5) были маршрутизаторами, то для
построения корректной сети нужно было бы сделать следующее: для узла М2 ввести
маршрутизацию и задать правило, согласно которому все пакеты, которые имеют в маске
192.168.4.х отправлять на узел [Link]. Т.е. для решения проблемы мост М2 нужно
превратить в маршрутизатор.
12. Транспортный уровень
Уровни OSI
12.1 Характеристики
Прикладной
Главная задача – это обеспечение надежной
адресной передачи сообщений между прикладными Представительный
программами (абонентами), работающими на узлах (на
Сеансовый
одном узле может быть много абонентов).
Транспортный
Сетевой
Канальный
Физический

Одна из наиболее сложных проблем, возникающих при создании распределенных

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

12.2 Протоколы транспортного уровня

Протоколы транспортного
уровня

С установкой соединения Без установки соединения

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

TCP UDP
 ICMP (Internet Control Message Protocol) – это сетевой протокол, входящий в
стек протоколов TCP/IP. ICMP-протокол имеет очень простой формат пакета
– состоит только из заголовка, в котором находится код команды, номер порта не
указывается. Данный протокол используется, чтобы проверить работоспособность
узла и оценить время передачи пакета до узла и обратно (например, используется
командой ping). Код протокола в IP-пакете будет ICMP.

13. Протокол UDP

13.1 Общие сведения

UDP – это протокол транспортного уровня без установки соединения,
обеспечивающий передачу дейтаграмм фиксированного размера без гарантий доставки,
без установки соединения (без «рукопожатий»), без подтверждения о доставке (без
квитирования пакетов), без упорядочивания принимаемых пакетов в порядке
отправления.

Вывод: UDP предоставляет ненадёжный сервис, и дейтаграммы могут прийти не

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

UDP, в сравнении с TCP, обеспечивает более высокую скорость передачи данных,

но не предоставляет гарантий надежности.

13.2 Сферы использования протокола UDP

Вопрос: когда хорошо применять протокол UDP?

Ответ: для передачи потока данных, где данные могут пропадать (например,
данные о погоде, передача мультимедийных данных).

Используется в:
1. Чувствительные ко времени приложения (программы для видео и аудио звонков и
прочие приложения, где не важна гарантия полной передачи данных, а важна
скорость их получения);
2. Сервера, отвечающие на большое количество запросов (DNS, IPTV, онлайн-игры).

Многие приложения, ориентирующиеся на UDP, вообще не используют систему

контроля над потерянными пакетами. Поэтому, если требуется большая
надежность, лучше использовать TCP.
13.3 Формат пакета
Имеется заголовок, кратный 4м байтам, за которым следуют данные.

IP-протокол позволяет передавать данные между узлами, но не между

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

Номер порта – это логический идентификатор программы (абонента), который

работает на узле. Номера портов являются сквозными (0, 1, 2, 3 и т.д.). На номер порта
выделяется 2 байта, следовательно, номера портов могут иметь значения из промежутка
[0..65535].

Смещение/
Биты 0 - 15 16 - 31

Порт отправителя Порт получателя

0-31
(Source port) (Destination port)
Длина дейтаграммы Контрольная сумма
32-63
(Length) (Checksum)

64-… Данные (Data)

Область пакета Описание

Номер порта отправителя. Предполагается, что это значение
Порт отправителя
задаёт порт, на который при необходимости будет посылаться
ответ. Иначе значение должно быть равным 0.
Порт получателя Номер порта получателя. Это поле является обязательным.
Длина дейтаграммы (заголовка и данных) в байтах.
Минимальная длина равна длине заголовка – 8 байт.
Длина Теоретически, максимальный размер поля — 65535 байт.
дейтаграммы Фактический предел для длины данных при использовании
IPv4 — 65507 (помимо 8 байт на UDP-заголовок, требуется ещё
20 на IP-заголовок).
Контрольная сумма UDP-заголовка и части IP-заголовка.
Контрольная сумма рассчитывается как добавление к единице
Контрольная суммы байтов заголовка UDP + значения полей в IP-заголовка,
сумма где содержатся IP-адреса.
Поле контрольной суммы используется для проверки заголовка
и данных на ошибки. Если сумма не сгенерирована
передатчиком, то поле заполняется нулями. Не является
 обязательным для IPv4.

13.4 Мультиплексирование/демультиплексирование логических каналов

Программа А Программа Б Программа А Программа Б

UDP TCP UDP TCP

IP IP
ARP RARP ARP RARP

Канал связи Канал связи

При взаимодействии двух программ (абонентов) по UDP можно выделить 4 числа,

которые идентифицируют логический канал связи:

1) IP-адрес первого узла;

2) порт первого узла;
3) IP-адрес второго узла;
4) порт второго узла.

13.5 Работа под IP-протоколом

Если UDP работает под IP -протоколом, то его заголовок помещается после
заголовка IP.
IP-адрес отправителя, IP-адрес получателя,
порт отправителя и порт получателя являются
уникальным идентификатором логического
Заголовок Заголовок
Данные канала связи в сети. На уровне IP происходит
IP UDP
мультиплексирование протокола. Чтобы узнать,
какой протокол используется, нужно проверить
код протокола в поле IP-пакета. По коду
протокола определяется, куда направляется
пакет, который идет наверх (в протоколы более высокого уровня) – UDP или TCP. Драйвер
протоколов UDP или TCP обеспечивает в свою очередь мультиплексирование канала
связи. Для этого используется понятие порт.
14. Протокол TCP
Задача: имеются армии А и В, противник С, между ними – лес. Армии А и В по
размерам уступают противнику С. Если армия А предпримет удар, то она потерпит
поражение, т.к., по правилам военного искусства, нападающая армия по численности
должна в 3 раза превосходить обороняющуюся (у армии В аналогичная ситуация). Но если
А и В одновременно ударят по неприятелю, то их шанс на победу увеличится.
Необходимо послать гонца от армии А в армию В с донесением о времени совместного
удара.
Проблема: в лесу орудуют диверсанты, которые могут перехватить донесение.
Командиру армии А необходимо подтверждение того, что командир армии В получил
сообщение, т.е. командир армии В должен отправить подтверждение (квитанцию). Что
будет, если гонца перехватят? Командир армии А не получит подтверждения и откажется
наносить удар, а командир армии В, получив сообщение, нанесет удар и будет разбит.
Получается, что необходимо отправить обратно подтверждение на подтверждение. Если
подтверждение на подтверждение не дойдет, то командир армии А будет наносить удар,
а В не нанесет удар.
Вопрос: сколько таких подтверждений на подтверждение нужно передавать?
Каково общее решение этой проблемы?

Aрмия А Армия B

Противник С

14.1 Общие сведения

Transmission Control Protocol (TCP) — это один из основных протоколов,
предназначенный для управления передачей данных в сетях и подсетях TCP/IP.
Обеспечивает гарантированную доставку как одиночных сообщений, так и потоков
данных, сборку фрагментов, квитирование, повторную передачу пакета и установку
приоритетов.
Выполняет функции протокола транспортного уровня в стеке протоколов TCP/IP.
14.2 Работа протокола IP

14.2.1 Особенности работы протокола IP

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

Начало

Выжидание (накопление данных)

Разделение данных на пакеты

Оправление пакетов

Отправленные пакеты остаются в

очереди, но помечаются как
«отправленные», хранятся в
ожидании подтверждения
Нет

Пришло подтверждение? Нет

Да
Подтвержденные пакеты удаляются
из очереди и считаются успешно
отправленными
Прошел заданный интервал
вемени?

Да

Пакеты считаются потерянными и

отправляются заново

Конец
14.2.2 Алгоритм «скользящего окна»
Окно TCP – это общий объем данных, которые могут быть отправлены и не
подтверждены. Размер окна изменяется динамически прямо во время работы и зависит
от условий сети.
Единицей подтверждения является байт. Пакеты могут быть любых размеров.
Размер пакета может динамически изменяться во время обмена данными, подстраиваясь
под пропускную способность сети.
Размер окна

Сегменты Сегменты Сегменты могут Сегменты, которые

отправлены, отправлены, быть отправлены. нельзя отправить.
квитанции квитанций
получены. Находятся пока не получены.
у получателя.
Отправитель уже
удалил их из
очереди.
Направление движения данных
Получатель Отправитель

После соединения размер окна устанавливается максимальным. Он влияет на

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

Принцип «скользящего окна»: окно по мере работы TCP смещается в правую

сторону: как только приходит квитанция, левая граница смещается вправо.

Задача: чтобы обеспечить надежность при передаче данных блоками,

необходимы подтверждения. Пусть на каждый блок посылается подтверждение,
что увеличивает трафик в 2 раза. Как решить данную проблему?
Решение: подтверждается не каждый блок данных. Вместо этого используется
отправление одного подтверждения на несколько сегментов – подтверждается логически
последний сегмент. Это интерпретируется как подтверждение всех остальных сегментов.

Соотношение между размером окна и характеристиками сети: если в сети

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

Размер окна рассчитывается динамически следующим образом: при передаче

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

Частый вопрос на экзамене

Бывают случаи, когда отправитель передает данные, а получатель не успевает их
принимать (для получения данных получатель должен прочитать их из буфера драйвера).
Что происходит в этом случае?
В этом случае TCP-драйвер получателя отправляет пакет, который подтверждает
последний принятый байт (флаг ACK), и устанавливая размер окна в 0. Размер окна 0 – это
указание отправителю приостановить передачу данных. Получив такой пакет, отправитель
приостанавливает передачу, а получатель продолжает посылать эти пакеты. Это
называется "зондирование нулевым окном" (получатель зондирует отправителя), смысл
зондирования – показать, что получатель "жив", соединение не разорвано, но пакеты в
данный момент не могут быть приняты.

14.2.3 Структура пакета

Бит/Смещение 0-3 4-9 10 - 15 16 - 31

0 Порт источника Порт назначения
32 Номер последовательности (порядковый номер)
64 Номер подтверждения
Длина
96 Зарезервировано Флаги Размер окна
заголовка
128 Контрольная сумма Указатель срочных данных
160 Опции
160/192+ Данные
Область пакета Описание
Идентифицирует приложение клиента, с которого отправлены
Порт источника пакеты. По возвращении данные передаются клиенту на
основании номера порта источника.
Порт назначения
Идентифицирует порт, на который отправлен пакет.
Порядковый номер Номер сегмента в общем потоке данных, номер данных и
идентификатор TCP-сегмента.
Порядковый номер может нести в себе следующий смысл:
– если установлен флаг SYN, то это начальное значение
порядкового номера — ISN (Initial Sequence Number), и первый
байт данных, которые будут переданы в следующем пакете, будет
иметь порядковый номер, равный ISN + 1;
– в противном случае, если SYN не установлен, первый байт
данных, передаваемый в данном пакете, имеет этот порядковый
номер.
По нему определяется, куда вложить фрагмент в буфере при
получении.
Поскольку поток TCP в общем случае может быть длиннее, чем
число различных состояний этого поля, то все операции с
номером последовательности должны выполняться по модулю
2^32. Это накладывает практическое ограничение на
использование TCP.
Номер подтверждения Смещение в общем потоке данных, которое показывает границу
данных, подтверждаемых получателем. Поле заполняется в
случае, если пакет представляет собой квитанцию –
подтверждение о доставке.
Если установлен флаг ACK, то это поле содержит номер
последовательности, ожидаемый получателем в следующий раз.
Помечает этот сегмент как подтверждение получения.
Длина заголовка Это поле определяет размер заголовка пакета TCP в 4-байтных
(смещение данных) (32-разрядных) словах. Минимальный размер составляет 5 слов,
максимальный — 15, что составляет 20 и 60 байт соответственно.
Смещение считается от начала заголовка TCP.
Зарезервировано Зарезервировано (6 бит) для будущего использования и должно
устанавливаться в ноль.
Флаги (управляющие Это поле содержит 6 битовых флагов.
биты)
SYN Синхронизация номеров последовательности, флаг
установки соединения.
FIN Признак завершения соединения.
RST Признак сброса соединения.
PSH Флаг проталкивания данных. Инструктирует получателя
протолкнуть данные, накопившиеся в приемном буфере,
в приложение пользователя.
URG Флаг, указывающий, что передаются срочные данные
(urgent). Если этот флаг установлен, то используется поле
«Указатель срочных данных».
 ACK Флаг подтверждения (acknowledgement). Поле «Номер
подтверждения» задействовано

Размер окна Число, определяющее в байтах размер данных, которые

отправитель пакета готов принять. Позволяет во время передачи
установить другой размер окна.
Контрольная сумма Считается по IP и TCP заголовку. Используется для нахождения
ошибок, возникших во время передачи данных.
Указатель срочных Номер байта внутри данных, с которого начинаются срочные
данных данные (смещение). Поле принимается во внимание только для
пакетов, в которых установлен флаг URG.
Опции В некоторых случаях применяются для расширения протокола.
Иногда используются для тестирования. После окончания
дополнительных данных поле дополняется нулями до 32 битов.

Чем отличается сброс соединения от упорядоченного завершения?

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

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

14.3 Установка соединения в TCP («Трехкратное рукопожатие»)

Сервер принимает запрос на установку

Клиент Сервер
соединения (пассивная сторона).
Клиент посылает запрос (активная сторона).
SYN, SN
1) Когда выполняется установка
соединения, клиент посылает на
Время

заданный порт пакет с флагом SYN, ACK

установки соединения (SYN). При этом,

когда посылается пакет SYN,
ACK
порядковый номер (SN) клиентом
выбирается случайным образом и
вписывается в пакет;
2) Сервер, получив запрос, отправляет на
него ответ. В этом ответе устанавливаются флаги SYN, ACK. Тот IP адрес и порт,
которые будут использоваться клиентом, берутся из ответного пакета, а для того
чтобы сопоставить первый пакет и ответный пакет и нужен Random SN. Диапазон
SN - Int32.
 3) Получив пакет, клиент отправляет пакет с флагом ACK, после чего сервер переходит
в состояние ESTABLISHED.

Уязвимость TCP: если какой-либо узел в глобальной сети начнет посылать

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

15. Гнезда (Socket)

15.1 Общие сведения

Для работы с протоколами стека протоколов TCP/IP предоставляется специальный

интерфейс прикладного программирования – Socket API.

Говорят, что ниже транспортного уровня (включая его) сообщения

управляются сетью, потому что нет прикладного интерфейса
программирования для работы непосредственно с сетевым уровнем, пакетами
Ethernet; есть драйверы с их функциональностью, но уровню программ возможности
управления не предоставлено. Так происходит потому, что на уровне IP, Ethernet-
пакетов программы не имеют способа идентификации, а также отсутствуют
гарантии безопасности.

15.2 Принцип организации

Введено специальное понятие – гнездо, или сокет.

Гнёзда являются интерфейсом для стека протоколов TCP/IP, предоставляют

возможность работы по протоколу TCP, UDP, с использованием «сырых» дейтаграмм IP.

Сокет (гнездо) – это точка подключения программы к сетевому интерфейсу.

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

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

Программный интерфейс Socket API поддерживается всеми ОС.

15.3 Сценарии использования

15.3.1 Использование протокола UDP

Схема работы с функциями по протоколу UDP для сервера и клиента одинаковая:

socket

bind

sendto recvfrom

close

Функция Описание
Socket Создание гнезда.
Bind Позволяет назначить IP-адрес и порт гнезду.
Sendto Послать кому-то.
Recvfrom (“Receive”) Получить от кого-то.
Close Завершение взаимодействия. Уничтожает само гнездо, освобождая
ресурсы драйвера для повторного использования.
15.3.2 Использование протокола TCP

Клиент Сервер

socket socket

bind bind

connect listen

send recv accept

shutdown send recv

close shutdown

close

Сервер
Функция Описание
Socket Создание гнезда.
Bind Привязка к гнезду IP-адреса и номера порта.
Listen Начинает прослушивание сокета на предмет входящих запросов на
установку соединения.
Accept Принимает входящий запрос на установку соединения, отправляя
подтверждение и обеспечивая механизм «трехкратного рукопожатия».
Результат функции Accept – создание нового сокета с установкой
соединения, в рамках которого можно вызывать функции Send и Recv.
Send Посылка данных.
Recv (“Receive”) Принятие данных.
Shutdown Упорядоченное закрытие дуплексного канала связи в одном, втором
или обоих направлениях. Гарантирует, что данные будут полностью
получены.
Close Закрывает гнездо, освобождая ресурсы.
Клиент
Функция Описание
Socket Создание гнезда.
Bind Привязка к гнезду IP-адреса и номера порта.
Connect Обеспечивает подключение клиента к серверу, инициирует установку
соединения.
Send Посылка данных по установленному дуплексному каналу связи.
Recv (“Receive”) Принятие данных по установленному дуплексному каналу связи.
Shutdown Упорядоченное закрытие дуплексного канала связи в одном, втором
или обоих направлениях. Гарантирует, что данные получены полностью.
Close Закрывает гнездо, освобождая ресурсы.

15.4 Функции работы с сокетами

Функция, structure Описание

int socket (int af, 1. Функция socket создает гнездо и
int type, возвращает номер гнезда в качестве
int protocol) результата. Этот идентификатор служит
идентификатором логической связи между
af: AF_UNIX компьютерами;
AF_INET
2. af (address family) – целочисленный
type: sock_stream идентификатор семейства адресов (вид
sock_dram адресации, которая будет использоваться
сокетом).
protocol: PROTO_TCP o AF_UNIX – используется
PROTO_UDP идентификация компьютера с
PROTO_XXX помощью символьного имени;
o AF_INET – используется система
адресов Internet;

3. type – целочисленный идентификатор типа.

 sock_stream – потоковый сокет,
используются средств для передачи с
подверждением потока данных;
 sock_dram – сокет с передачей дейтаграмм;

Обычно для TCP используется тип sock_stream, для

UPD – sock_dram.
4. Protocol – протокол. Константы помечают
не только TCP и UDP, но и WinSocket
(используется префикс WSA).

Стандартные комбинации:
AF_INET + sock_stream + PROTO_TCP
AF_INET + sock_dram + PROTO_UDP
union sockaddr Важно: объединение (union) в программировании
{ — это структура данных, члены которой
sockaddr_in sin; // для Internet расположены по одному и тому же адресу.
sockaddr_u su; // для Unix Поэтому размер объединения равен размеру его
}; наибольшего члена. В любой момент времени
объединение хранит значение только одного из
членов.
struct sockaddr_in 1. sin_family – семейство адресов. Позволяет
{ определить тип адресации и понять, как
short sin_family; дальше интерпретировать данные;
u_short sin_port; 2. sin_port – номер порта;
struct in_addr sin_addr; 3. sin_addr – структура, в которой
char sin_zero [8]; закодирован IP-адрес;
} 4. sin_zero[8] – дополнение нулями до общего
размера, т.к. в Unix имя занимает 13
символов.
struct sockaddr_u 1. su_family – семейство адресов. Позволяет
{ определить тип адресации и понять как
short su_family; дальше интерпретировать данные.
char su_name [13]; // имя host’а
UNIX’а
}

int bind (int socket, Используется, чтобы назначить гнезду «номер».

const struct sockaddr* name, Связывает с гнездом IP-адрес и порт, указанные в
int namelen) параметре name. В параметре namelen – длина
структуры sockaddr (фактически, sizeof()
структуры). По размеру можно проверить,
корректно ли передана структура (той ли версии).
Функция bind возвращает 0 или код ошибки.
int listen (int socket, Backlog определяет размер очереди входящих
int backlog) запросов на установку соединения. Физически
драйвер ограничивает данное значение.

Функция listen используется сервером: она

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

Входная очередь запросов – это количество

запросов с флагом SYN, которые одновременно
могут прийти и ожидать подтверждения установки
 соединения (функции accept).

Важно: Backlog – это внутренняя очередь на

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

Таким образом обеспечивается некоторая защита

от DDOS-атак (Distributed Denial of Service), которая
возникает в случае «бомбардирования» сервера
запросами на установку соединения.
int connect (int socket, const struct Используется клиентом.
sockaddr* name, int namelen) В нее передается номер сокета, структура адреса.
Для структуры используется слово name, т.к. в
UNIX это были имена и изредка IP-адреса, а сейчас
это прежде всего IP-адреса и очень редко имена.
namelen – размер структуры name, который
используется только для контроля. В структуре
передается IP-адрес и порт, на который
устанавливается соединение.

Возвращает 0 в случае успеха и код ошибки в

случае ошибки.
int accept (int socket, socket – номер сокета;
struct sockaddr* addr, sockaddr – указатель на IP-адрес и порт ( те IP-
int addrlen); адрес и порт, которые соответствуют клиенту).

Если соединения нет, то функция ждет. Если

запрос был поставлен в очередь, то он изымается
из очереди запросов и обрабатывается: создается
новое гнездо и в структуре sockaddr возвращается
его номер, IP-адрес и порт гнезда.
int shutdown (int socket, Выполняет закрытие входного и/или выходного
int how) канала связи (задается полем how).
При закрытии канала все отправленные данные
How: SD_SEND проталкиваются дальше.
SD_RECEIVE
SD_BOTH Если мы работаем с потоком данных, то вызов
этой функции на отправку фактически означает
получение клиентом признака конца файла при
чтении.
int send (int socket, const char* buf, При взаимодействии сервера с клиентом
int len, int flags) устанавливается дуплексная связь.
int recv (int socket, char* buf, int len,
int flags) send, resv используются в протоколах TCP и UDP.
int sendto (int socket, const char* sendto и resvfrom – только в UDP.
buf, int len, int flags, const struct socket – номер сокета
sockaddr* to, int tolen) buf - указатель на буфер данных, из которого или в
int recvfrom (int socket, char* buf, который пишутся данные
int len, int flags, struct sockaddr* from, len – длина буфера
int fromlen) flags – флаги:
MSG_OOB - out of band – срочные данные
MSG_XXX
sockaddr – непосредственно указываются IP-адрес
и порт куда (to)/откуда (from) отправляются
данные
recv, recvfrom возвращают реальное количество
байт. Когда вызывается функция recv, а канал
данных уже закрыт, функция возвращает 0. В
случае ошибки возвращает отрицательное
значение. Таким образом, отсутствует понятие
EndOfFile, т.е. нельзя проверить соединение на то,
что данные получены. Единственный способ
узнать о конце данных - это принять их. В функции
recv совмещены две функции: прием данных и
проверка на конец.

int closesocket (int socket) Закрывает гнездо, его дескриптор освобождается

для повторного использования. Закрыть сокет
можно и без функции shutdown, если вам не
важно, дошли ли последние данные. Система
выжидает некоторое время перед повторным
использованием. Это связано с особенностью
работы TCP.
16. Система доменных имен (DNS)
16.1 Общие сведения
IP-адрес трудно запоминать (ассоциация – телефонный номер, который пытаются
выбрать с «красивыми» цифрами, чтобы было проще запоминать), им неудобно
пользоваться, поэтому была придумана система доменных имен (DNS). Она решала
проблему отображения семьи выдачи.

DNS (Domain name system) – система управления некоторыми именами;

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

В глобальных сетях отсутствует понятие "главного (управляющего) узла", что

отличает их от локальных сетей (в локальных сетях существует понятие сервера и
клиента; сервер – это особый выделенный узел, который занимается предоставлением
какого-либо ресурса (жесткий диск, печать, вычислительные ресурсы, оперативное
хранилище, база данных), а клиент - потребитель ресурса). Исходя из этого, и создавалась
система доменных имен.

DNS стандартизирует форматы имен и запросы на получение каких-либо данных,

ассоциирующихся с этими именами.

Доменная система создавалась из расчета, что система является:

1) распределенной, т.е. нет узла, от которого зависит система и к которому все

обращаются;
2) иерархической. Иерархичность системы отражена в иерархичности самих имен
(структуре имен).

16.2 Принципы системы именований

‘ ‘

COM NET ORG RU BY

Microsoft Borland

MSDN Windows

1) В корне системы – пустое имя, не содержащее ни одного символа;

 2) От корня отходят домены первого уровня (COM, NET, ORG, RU, BY), которые
логически подчинены пустому имени;

3) Далее могут следовать поддомены второго и т.д. уровней.

– имена доменов не являются чувствительными к регистру;

– имена доменов пишутся через точку в обратном порядке (третий.второй.первый.),
например
[Link]. точка после com – корневое имя, которое принято не
писать.

– имена доменов пишутся через точку в обратном порядке из соображений удобства для
человека: человек, когда мыслит, всегда запоминает начало, + человеку важно, чтобы
главная информация была первой, а подчиненная – второй.

– имена доменов первого уровня оговорены заранее. И хотя их количество постепенно

изменяется, но совсем незначительно. Нельзя просто взять и добавить домен первого
уровня. Была принята следующая политика: это всё дерево доменных имен было
разделено на «зоны», с целью чтобы, разные организации могли за них отвечать;

– количество изменений на первом уровне должно быть минимально; изначально

система была придумана в Америке, поэтому предполагалось только национальное
использование.

Расширение Назначение
com Для коммерческих организаций
org Для некоммерческих организаций
net Для организаций, которые управляют самой сетью
mil Для военных организаций
 Затем возникла необходимость иметь домены для других стран. Эта проблема
решилась следующим образом: для всех стран были созданы соответствующие
двухбуквенные домены (например, ru, by, de).

Единственное, что вызывает нарекания у всех стран, кроме Америки, к системе

DNS, это то, что управление всеми доменами верхнего уровня выполняется только
американскими серверами. А управлением доменами верхнего уровня – это ключ к
управлению интернетом.

16.3 Принципы работы DNS

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

В DNS хранятся записи типа "А" (адрес) – соответствие имени какому-то IP-адресу.

16.3.1 Итеративный запрос

DNS-агент обращается к DNS-серверу с запросом предоставить значение типа “А”
для адреса, например [Link]. dns-сервер проверяет, есть ли у него в списке
такое имя (предположим, это dns-сервер [Link]). Если такого имени нет, он
возвращает ”не найдено” с указанием проверить на сервере .com. Агент спрашивает у
.com, есть ли такое имя. Сервер .com видит, что такого имени нет, но у него есть адрес
сервера [Link]. Он посылает этот адрес обратно в качестве ответа. После этого
агент посылает запрос на [Link], который находит [Link] и
возвращает нужный клиенту IP адрес.

[Link] -> IP (DNS server)

<- не найден (IP .com)

[Link] -> IP (.com)

<- не найден (IP [Link])

[Link] -> IP ([Link])

<- найден (IP [Link])

Этот запрос получил название итеративный, т.к. dns-агент в цикле обращается к

dns-серверам, каждый из серверов сообщает либо искомый IP-адрес, либо ссылку на
другой dns-сервер, который ниже по уровню и отвечает за определенную зону.

Когда клиент обращается к браузеру и открывает страницы, то постоянно идет

преобразование имени в IP-адрес (resolve). Чтобы не забивать сеть
повторяющимися запросами, используется кэширование: DNS-сервер запоминает имена и
кэширует их на некоторый промежуток времени.

Большое количество операций обновления может привести к возникновению

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

Почему на первом уровне домены зафиксированы? Они зафиксированы для того,

что не началось добавление или удаление и не повлияло на DNS-сервера других
уровней.

Все системы доступа к интернет-ресурсам используют систему доменных имен, а

не IP-адреса. Почему? Это связано с возможностью переносить (балансировать)
запросы с одного адреса на другой и менять IP-адреса.

16.3.2 Рекурсивный запрос

Когда DNS-агент обращается к DNS-серверу, он посылает запрос, где указывает
имя, для которого необходимо получить адрес. Сервер не может вернуть DNS-агенту
признак «не найден», поэтому он сам начинает обращаться к серверам, которые могут
знать этот адрес (они, в свою очередь, делают то же самое). Если сервера работают по
рекурсивному принципу, то запрос полностью делегируется на выполнение другому
серверу.

Какие запросы (итеративные/рекурсивные) используются на практике? Например,

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

В реальности для снижения нагрузки используется комбинированный запрос: у

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

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

Задание: рассмотреть пример работы с сокетами. [Код программы в приложении]

Постановка задачи: программа на языке С, которая представляет собой клиент сервиса

интернет-службы Whois, которая позволяет выяснить информацию о именах и IP-адресах.

К сожалению, для служб Whois до сих пор не определен формат возврата.

Исходные данные:

43 порт

[Link]
17. Язык разметки HTML

17.1 Общие сведения

HTML (HyperText Markup Language) — стандартный язык
разметки документов во Всемирной паутине. Большинство веб-
страниц содержат описание разметки на языке HTML (или XHTML).
Язык HTML интерпретируется браузерами и отображается в виде
документа в удобной для человека форме.

Язык XHTML является более строгим вариантом HTML, он

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

Некоторые ограничения XHTML:

 Все теги должны быть закрыты, незакрытые теги не допускаются. Одиночные теги
должны закрываться как “/>”;
 Всем атрибутам должно быть присвоено значение;
 Имена тегов и атрибутов должны быть записаны строчными буквами;
 В качестве кодировки по умолчанию используется UTF-8.

Во всемирной паутине HTML-страницы, как правило, передаются браузерам от

сервера по протоколам HTTP или HTTPS в виде простого текста или с использованием
сжатия.

17.2 Синтаксис HTML

HTML – теговый язык разметки документов. Любой документ на языке HTML
представляет собой набор элементов, причём начало и конец каждого элемента
обозначается специальными пометками — тегами. Элементы могут быть пустыми, то
есть не содержат текста и других данных (например, тег перевода строки <br>). В этом
случае закрывающий тег обычно не указывается.

Для XHTML тег перевода строки будет выглядеть как <br />.

Элементы могут иметь атрибуты, определяющие какие-либо их свойства

(например, размер шрифта для элемента font). Атрибуты указываются в открывающем
теге. Вот примеры фрагментов HTML-документа:

<strong>Текст между двумя тегами — открывающим и закрывающим.</strong>

<a href="[Link] элемент содержит атрибут href, то есть

гиперссылку.</a>
 Регистр, в котором набрано имя элемента и имена атрибутов, в HTML значения не
имеет (в отличие от XHTML). Элементы могут быть вложенными. Например,
следующий код:

<b>
Этот текст будет полужирным,
<i>а этот - ещё и курсивным</i>
</b>
даст такой результат:

Этот текст будет полужирным, а этот — ещё и курсивным

В HTML-документах также присутствуют сущности (англ. entities) — «специальные

символы». Сущности начинаются с символа амперсанда и имеют вид &имя; или
&#NNNN;, где NNNN — код символа в Юникоде в десятичной системе счисления.

Например, &copy; — знак авторского права (©). Как правило, сущности

используются для представления символов, отсутствующих в кодировке
документа, или же для представления «специальных» символов: &amp; —
амперсанда (&), &lt; — символа «меньше» (<) и &gt; — символа «больше» (>),
которые некорректно записывать «обычным» образом, из-за их особого значения в
HTML.

17.3 Структура HTML-документа

Каждый HTML-документ, отвечающий спецификации HTML какой-либо версии,
должен начинаться со строки объявления версии HTML <!DOCTYPE…>, которая обычно
выглядит примерно так:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"

"[Link]

Если эта строка не указана, то добиться корректного отображения документа в

браузере становится труднее.

Ранее использовалось много вариантов Doctype, но с приходом HTML 5 всё стало

проще:

Вариант DOCTYPE для HTML 5

<!DOCTYPE HTML>

Далее обозначается начало и конец документа тегами <html> и </html>

соответственно. Внутри этих тегов должны находиться теги заголовка (<head></head>)
и тела (<body></body>) документа.
<!DOCTYPE HTML>
<html>
<head>
<title>HTML 5 Page</title>
</head>
<body>
<h1>Hello, world!</h1>
</body>
</html>

С другими тегами можно ознакомиться, например, по следующей ссылке:

[Link]
%D1%8B_HTML
18. Прокол FTP

18.1 Основные сведения

FTP (File Transfer Protocol) – это протокол передачи файлов.

Протокол FTP – один из старейших протоколов прикладного уровня стека

TCP/IP. Его первые реализации относятся к началу 70-х годов, к 1985 году он уже
обрел современный вид.

Для хранения файлов в Интернет используются специальные FTP-серверы. FTP-

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

FTP-сервер

FTP

18.2 Особенности протокола FTP

Особенность протокола FTP – это использование раздельных каналов для
управления и передачи файлов. Канал управления образуется традиционным образом –
пассивное открытие со стороны сервера (порт 21 по умолчанию), активное – со стороны
клиента. По каналу передаются короткие текстовые команды и ответы на них (алфавитно-
цифровые команды). В то же время каналы для передачи файлов открываются по мере
необходимости.

После установления TCP-соединения клиент производит процедуру аутентификации,

особенностью которой является передача имени пользователя и пароля в оригинальном
виде, без какой-либо кодировки. Многие FTP-серверы допускают анонимный доступ
(имя пользователя ANONIMUS, пароль – адрес электронной почты). После авторизации
возможен обмен командами/откликами, в ходе которого клиент может просматривать
содержимое каталогов, менять текущие локальный и удаленный каталоги и т.д.

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

18.3 Команды FTP

Представим описание основных команд FTP:

Команда Описание
OPEN Присоединиться к указанному серверу. При этом сервер запросит
логин и пароль.
CLOSE / Закрыть соединение с текущим сервером.
DISCONNECT
BYE / QUIT Закрыть соединение и выйти из утилиты FTP.
USER Войти на данном сервер с использованием указанного пользователя
(подключение уже должно быть установлено). Далее FTP-сервер
запросит пароль.
LS / DIR Показать список файлов и директорий в текущей папке на сервере.
CD Перейти в указанную папку на сервере.
CDUP Перейти в родительскую директорию - то же самое, что и "CD ..".
PWD Показать текущий путь (текущую папку) на сервере.
GET / RECV Загрузить с сервера в текущую папку Вашего компьютера указанный
файл.
MGET Загрузить несколько файлов в текущую папку Вашего компьютера с
сервера.
PUT / SEND Загрузить на сервер указанный файл с Вашего компьютера.
MPUT Загрузить на сервер несколько файлов с Вашего компьютера.
DELETE Удалить указанный файл на сервере.
MDELETE Удалить несколько файлов на сервере.
MKDIR Создать директорию на сервере.
RMDIR Удалить директорию на сервере.
ABOR Прервать передачу файла.
CWD Сменить директорию.
HELP Возвращает список команд, принимаемых сервером.
LIST Возвращает список файлов директории.
MDTM Возвращает время модификации файла.
NLST Возвращает список файлов директории в более кратком формате,
чем LIST.
NOOP Пустая операция.
PASV Войти в пассивный режим. Сервер вернёт адрес и порт, к которому
нужно подключиться, чтобы забрать данные. Передача начнётся при
введении следующих команд: RETR, LIST и т.д.
PORT Войти в активный режим. Сервер сам подключается к клиенту, в
отличие от пассивного режима для передачи данных.
REIN Реинициализировать подключение.
RNFR и RNTO Переименовать файл. RNFR — что переименовывать, RNTO — во что.
SIZE Возвращает размер файла.
SYST Возвращает тип системы (UNIX, WIN, …).
TYPE Установить тип передачи файла (бинарный, текстовый).

18.4 Пример сессии FTP

Описание: происходит подключение к серверу, создается папка "newfiles" и в нее
загружается файл "[Link]".

$ ftp [Link]
ftp> mkdir newfiles
ftp> cd newfiles
ftp> put [Link]
ftp> bye

18.5 Примеры работы с FTP в С# с использованием FtpWebRequest ,

FtpWebResponse
Работу с FTP в С# можно обеспечить при помощи классов FtpWebRequest и
FtpWebResponse. Эти классы – наследники классов WebRequest и WebResponse
соответственно.

Источники:

[Link]
[Link]

18.5.1 [Link]
[Link] содержит команды, которые могут быть использованы в
качестве запроса к FTP-серверу. Этот класс не может быть унаследован.

Источник:

[Link]
us/library/[Link]%28v=vs.110%[Link]
18.5.2 Организация скачивания файлов с FTP-сервера (C#)
using System;
using [Link];
using [Link];
using [Link];

namespace [Link]
{
public class WebRequestGetExample
{
public static void Main ()
{
// Get the object used to communicate with the server.
FtpWebRequest request =
(FtpWebRequest)[Link]("[Link]
[Link] = [Link];

// This example assumes the FTP site uses anonymous logon.

[Link] = new NetworkCredential
("anonymous","janeDoe@[Link]");

FtpWebResponse response = (FtpWebResponse)[Link]();

Stream responseStream = [Link]();

StreamReader reader = new StreamReader(responseStream);
[Link]([Link]());

[Link]("Download Complete, status {0}",

[Link]);

[Link]();
[Link]();
}
}
}

Источник: [Link]
18.5.3 Организация загрузки файлов на FTP-сервер (C#)
using System;
using [Link];
using [Link];
using [Link];

namespace [Link]
{
public class WebRequestGetExample
{
public static void Main ()
{
// Get the object used to communicate with the server.
FtpWebRequest request =
(FtpWebRequest)[Link]("[Link]
[Link] = [Link];

// This example assumes the FTP site uses anonymous logon.

[Link] = new NetworkCredential
("anonymous","janeDoe@[Link]");

// Copy the contents of the file to the request stream.

StreamReader sourceStream = new StreamReader("[Link]");
byte [] fileContents =
[Link]([Link]());
[Link]();
[Link] = [Link];

Stream requestStream = [Link]();

[Link](fileContents, 0, [Link]);
[Link]();

FtpWebResponse response = (FtpWebResponse)[Link]();

[Link]("Upload File Complete, status {0}",

[Link]);

[Link]();
}
}
}
}

Источник: [Link]
18.5.4 Получение списка файлов директории FTP-сервера (C#)
using System;
using [Link];
using [Link];
using [Link];
namespace [Link]
{
public class WebRequestGetExample
{
public static void Main ()
{
// Get the object used to communicate with the server.
FtpWebRequest request =
(FtpWebRequest)[Link]("[Link]
[Link] = [Link];

// This example assumes the FTP site uses anonymous logon.

[Link] = new NetworkCredential
("anonymous","janeDoe@[Link]");

FtpWebResponse response = (FtpWebResponse)[Link]();

Stream responseStream = [Link]();

StreamReader reader = new StreamReader(responseStream);
[Link]([Link]());

[Link]("Directory List Complete, status {0}",

[Link]);

[Link]();
[Link]();
}
}
}

Источник: [Link]
19. Telnet

19.1 Общие сведения

TELNET (англ. TErminaL NETwork) — это сетевой протокол для реализации
текстового интерфейса по сети.

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

битного байт-ориентированного средства связи.

Основная задача: обеспечение стандартного метода взаимодействия

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

19.2 Реализация, особенности функционирования

TELNET строится как протокол приложения над транспортным протоколом TCP. В

основу TELNET положены три фундаментальные идеи:

 концепция сетевого виртуального терминала (Network Virtual Terminal), или NVT;

 принцип договорных опций (согласование параметров взаимодействия);
 симметрия связи "терминал-процесс";.

TELNET-клиент TELNET-сервер
Прикладные программы

...

TCP TCP
Терминальный IP IP Псевдотермина
драйвер Канальный Канальный льный драйвер
уровень уровень
Физический Физический
уровень уровень

Интернет
 При установке telnet-соединения программа, работающая с реальным
терминальным устройством, и процесс обслуживания этой программы используют для
обмена информацией спецификацию представления правил функционирования
терминального устройства, или Сетевой Виртуальный Терминал (Network Virtual Terminal
или NVT).

NVT – это стандартное описание наиболее широко используемых возможностей

реальных физических терминальных устройств. Он позволяет описать и преобразовать в
стандартную форму способы отображения и ввода информации. Терминальная
программа ("user") и процесс ("server"), работающий с ней, преобразовывают
характеристики физических устройств в спецификацию NVT, что позволяет, с одной
стороны, унифицировать характеристики физических устройств, а с другой – обеспечить
принцип совместимости устройств с разными возможностями. Характеристики диалога
диктуются устройством с меньшими возможностями.

Если взаимодействие осуществляется по принципу "терминал-терминал" или

"процесс-процесс", то "user" – это сторона, инициирующая соединение, а "server" –
пассивная сторона.

Принцип договорных опций или команд позволяет согласовать возможности

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

Симметрия взаимодействия по протоколу telnet позволяет в течении одной сессии

программе-"user" и программе-"server" меняться местами. Это принципиально отличает
взаимодействие в рамках telnet от традиционной схемы "клиент-сервер". Симметрия
взаимодействия тесно связана с процессом согласования формы обмена данными между
участниками telnet-соединения. Когда речь идет о работе на удаленной машине в режиме
терминала, то возможности ввода и отображения информации определяются только
конкретным физическим терминалом и договорной процесс сводится к заказу
терминальной программой характеристик этого терминала. Гораздо сложнее обстоит
дело, когда речь идет об обмене информацией между двумя терминальными
программами в режиме "терминал-терминал". В этом случае каждая из сторон может
выступать инициатором изменения принципов представления информации и здесь
проявляется еще одна особенность протокола telnet: протокол не использует принцип
"запрос-подтверждение", а применяет принцип "прямого действия". Это значит, что если
терминальная программа хочет расширить возможности представления информации, то
она делает это (например, вставляет в информационный поток Esc-последовательности),
если в ответ она получает информацию в новом представлении, то это означает, что
попытка удалась, в противном случае происходит возврат к стандарту NVT.
19.3 Опции

По умолчанию протокол предоставляет минимальную функциональность и набор

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

19.4 Принтер и клавиатура NVT

Принтер NVT имеет неопределённую ширину каретки и длину страницы и должен

иметь представление всех 95 печатных символов US-ASCII (коды с 32 по 126).
Управляющие символы имеют следующие значения:

Код
Название (десятичный/шестна Описание
дцатеричный)
NULL (NUL) * 0/0x00 Нет операции.
Переводит принтер на следующую
Line Feed (LF) * 10/0x0A строку печати, оставаясь на той же
горизонтальной позиции.
Перемещает принтер к левой границе
Carriage Return (CR) * 13/0x0D
текущей строки.
Производит аудио или видеосигнал
BELL (BEL) 7/0x07
(но НЕ перемещает головку принтера).
Перемещает головку принтера на
Back Space (BS) 8/0x08 один символ по направлению к левой
границе.
Перемещает принтер на следующую
остановку горизонтальной табуляции.
Horizontal Tab (HT) 9/0x09 Остается неопределённым как сторона
определяет и устанавливает эти
остановки табуляции.
Перемещает принтер на следующую
остановку вертикальной табуляции.
Vertical Tab (VT) 11/0x0B Остается неопределённым как сторона
определяет и устанавливает эти
остановки табуляции.
Перемещает принтер к верхней части
Form Feed (FF) 12/0x0C следующей страницы, оставаясь на той
же горизонтальной позиции.

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

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

– последовательность «CR LF» должна обрабатываться как единый символ перевода

строки и использоваться всякий раз, когда требуется их объединённое действие;

– последовательность «CR NUL» должна использоваться, когда необходим только возврат

каретки, следует избегать использования символа CR в других контекстах.

19.5 Структура команд TELNET

1) каждая команда TELNET является многобайтовой последовательностью, начинающейся

с кода \377 (десятичное: 255) «Interpret as Command» (IAC) и кода команды;

2) команды, отвечающие за договоренности по опции, являются трехбайтовыми

последовательностями, где третий байт является кодом опции.

Нижеперечисленные коды и кодовые последовательности имеют соответственный

смысл только когда следуют сразу за IAC.

Код
Название (десятичный/шестна Описание
дцатеричный)
Завершает согласование, начатое
SE 240/0xF0
командой SB.
NOP 241/0xF1 Нет операции.
Синхронизация (Synch) обмена
данными. Эта команда всегда
Data Mark 242/0xF2
сопровождается TCP Urgent
notification.
Нажата кнопка «Break» или
Break 243/0xF3
«Attention».
Приостанавливает, прерывает,
Interrupt Process 244/0xF4 аварийно прекращает или завершает
процесс.
Подавление вывода текущего
Abort output 245/0xF5 процесса. Также отправляет сигнал
Synch пользователю.
Отправляет обратно ответ терминала,
Are You There 246/0xF6
состоящий из печатных символов.
Получатель должен удалить
Erase character 247/0xF7 предыдущий символ, если это
возможно.
Стереть последнюю введённую строку,
Erase Line 248/0xF8 то есть все данные, полученные после
последнего перевода строки.
Go ahead 249/0xF9 Ожидается передача данных.
Начало согласования опции,
SB 250/0xFA
требующего передачи параметров.
 Указывает на желание исполнять или
WILL опция 251/0xFB подтверждает, что сейчас исполняется
указанная опция.
Указывает на отказ начать или
WON’T опция 252/0xFC продолжить исполнять указанную
опцию.
Запрос на то, чтобы другая сторона
DO опция 253/0xFD исполнила или подтвердила
исполнение указанной опции.
Требование на то, чтобы другая
сторона остановила исполнение или
DON’T опция 254/0xFE
подтвердила то, что указанная опция
более не исполняется.
IAC 255/0XFF Байт данных 255.

19.6 Безопасность

В протоколе не предусмотрено использование ни шифрования, ни проверки

подлинности данных, поэтому он уязвим для любого вида атак, к которым уязвим его
транспорт (т.е. протокол TCP). Для функциональности удалённого доступа к системе в
настоящее время применяется сетевой протокол SSH, при создании которого упор
делался именно на вопросы безопасности. Так что следует иметь в виду, что сессия Telnet
весьма беззащитна, если только не осуществляется в полностью контролируемой сети или
с применением защиты на сетевом уровне (различные реализации виртуальных частных
сетей). По причине ненадёжности от Telnet как средства управления операционными
системами давно отказались.
20. Протокол POP3 (Post Office Protocol)

20.1 Общие сведения

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

Клиенты независимо получают

POP почту. После завершения процесса
сервер загрузки почта удаляется с сервера.

POP клиент #1 POP клиент #2

Список Список
сообщений сообщений

1) Клиент начинает работать с установки TCP-соединения на порт 110. На этом порту

должен быть сервер, который прослушивает соединение;

2) Когда соединение установлено, сервер посылает клиенту приглашение;

3) После этого клиент и сервер обмениваются информацией, пока соединение не

будет закрыто или прервано.

20.2 Формат команд

– клиент посылает команды, состоящие из ключевых слов, через пробел идут

аргументы;
– длина ключевых слов составляет 3–4 символа;
– максимальная длина одного аргумента – 40 символов;
– каждая команда должна завершаться символами CRLF;
– ответы на некоторые команды могут состоять из нескольких строк. В этом случае
каждая строка разделена символом CRLF, а весь ответ – точкой и CRLF.
20.3 Состояния сеанса

В протоколе POP3 предусмотрено 3 состояния сеанса:

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

20.4 Команды протокола POP3

Возможные
Команда Аргументы Назначение Ограничения
ответы
* +OK maildrop
Служит для has n message
передачи серверу Её поддержка не * -ERR
APOP [имя] [digest] имени пользователя является password
и зашифрованного обязательной suplied for
пароля (digest). [имя] is
incorrect
* +OK name is a
valid mailbox
Передаёт серверу
USER [имя] — * -ERR never
имя пользователя.
heard of
mailbox name
* +OK maildrop
locked and
Работает после
Передаёт серверу ready
успешной
PASS [пароль] пароль почтового * -ERR invalid
передачи имени
ящика. password
почтового ящика
* -ERR unable
to lock maildrop
Сервер помечает * +OK message
Доступна после
указанное deleted
DELE [сообщение] успешной
сообщение для * -ERR no such
идентификации
удаления. message
* +OK scan
Выдает информацию Доступна после
listing follows
LIST [сообщение] о сообщении с успешной
* -ERR no such
указанным номером. идентификации
message
Сервер ничего не Доступна после
NOOP — делает. Всегда успешной +OK
отвечает идентификации
 положительно.
* +OK message
Сервер передаёт Доступна после
follows
RETR [сообщение] сообщение с успешной
* -ERR no such
указанным номером. идентификации
message
Доступна после
Откат транзакций
RSET — успешной +OK
внутри сессии
идентификации
Сервер возвращает
количество
Доступна после
сообщений в
STAT — успешной +OK a b
почтовом ящике и
идентификации
размер почтового
ящика в октетах
Сервер возвращает
заголовки
указанного
[сообщение] Доступна после * +OK n octets
сообщения, пустую
TOP [количество успешной * -ERR no such
строку и указанное
строк] идентификации message
количество первых
строк тела
сообщения.
Переводит POP3-
сервер в состояние
update (обновления).
В этом режиме
сервер удаляет
QUIT — — +OK
сообщения,
помеченные к
удалению, и
завершает POP3
сессию.

20.5 Пример сессии

S: <Сервер ожидает входящие соединения на порту 110>

C: <подключается к серверу>
S: +OK POP3 server ready <1896.697170952@[Link]>
C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
S: +OK mrose's maildrop has 2 messages (320 octets)
C: STAT
S: +OK 2 320
C: LIST
S: +OK 2 messages (320 octets)
S: 1 120
S: 2 200
S: .
C: RETR 1
S: +OK 120 octets
S: <сервер передаёт сообщение 1>
S: .
C: DELE 1
S: +OK message 1 deleted
C: RETR 2
S: +OK 200 octets
S: <сервер передаёт сообщение 2>
S: .
C: DELE 2
S: +OK message 2 deleted
C: QUIT
S: +OK dewey POP3 server signing off (maildrop empty)
C: <закрывает соединение>
S: <продолжает ждать входящие соединения>

21. Протокол IMAP (Internet Message Access Protocol)

21.1 Общие сведения

Протокол POP3 имеет ряд недостатков, наиболее серьезный из которых – отсутствие

возможностей по управлению перемещением и хранением сообщений на сервере (сообщения,
как правило, загружаются с почтового сервера все сразу, после чего удаляются с сервера).

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

21.2 Преимущества IMAP перед POP3

IMAP обладает следующими преимуществами:

 соединение не разрывается, пока пользовательский интерфейс активен, а

сообщения загружаются только по требованию клиента. Это позволяет уменьшить
время отклика для пользователей, в чьих ящиках имеется много сообщений большого
объёма;
 одновременный доступ нескольких клиентов к ящику;
 предоставление клиенту возможности отслеживать изменения, вносимые
другими клиентами, которые подключены одновременно с ним;
 клиент имеет возможность отслеживать состояние сообщения (прочитано,
отправлен ответ, удалено и т. д.), данные о флагах хранятся на сервере;
 клиенты IMAP могут создавать, переименовывать и удалять ящики, а также
перемещать сообщения между ящиками.
 можно использовать расширение IMAP4 Access Control List (ACL) Extension для
управления правами доступа к ящикам.
21.3 Общая схема взаимодействия

Множество клиентов могут общаться с

одного и того же аккаунта с одним и
тем же сервером из любого места мира.
Клиенты могут общаться
IMAP с несколькими серверами IMAP
сервер #1 сервер #2

Список Список
сообщений сообщений

IMAP клиент #2

Клиент имеет полный контроль над Список

своей почтой. Он может создавать, сообщений
Клиент сам решает
удалять, очищать или переносить
где хранить письма:
почту между аккаунтами разных
на сервере или у себя
серверов
на компьютере
IMAP клиент #2

Список
сообщений

21.4 Состояния сеанса

Сервер IMAP ожидает соединения от клиентов на порту 143. После установления

соединения сервер посылает свое приветствие клиенту и начинается диалог, в котором
клиент посылает серверу команды, а сервер сообщает о результатах их выполнения или
присылает информацию, запрошенную клиентов. Как и сеанс POP3, сеанс IMAP делится
на несколько состояний (states). Допустимый набор команд зависит от текущего
состояния сеанса. Сеанс может находиться в одном из следующих состояний:
 неаутентифицированное состояние (Not Authenticated State): клиент должен
пройти процедуру аутентификации прежде, чем сможет выполнять большинство
команд;
 аутентифицированное состояние (Authenticated State): клиент аутентифицирован и
должен выбрать почтовый ящик, прежде чем сможет работать с отдельными
сообщениями;
 выбранное состояние (Selected State): почтовый ящик выбран;
 состояние выхода (Logout State): сеанс завершается.

Схема переходов между состояниями сеанса IMAP представлена на рисунке ниже.

Переходы, обозначенные цифрами:

1 – соединение без предварительной аутентификации;
2 – соединение с предварительной аутентификацией;
3 – отвергнутое соединение;
4 – успешная аутентификация;
5 – успешное выполнение команды SELECT или EXAMINE;
6 – команда CLOSE или неудачное завершение команды SELECT или EXAMINE;
 7 – команда LOGOUT или потеря связи.

Установление соединения

Приветствие сервера

1
Неаутентифицированное
2
состояние
4
Аутентифицированное
состояние
3
5 6
7

7 Выбранное
состояние

Состояние выхода

Завершение соединения

21.5 Команды протокола IMAP

Команда Аргументы Флаги Назначение Ограничения
Перечисляет
возможности,
CAPABILITY —
поддерживаемые
сервером
Сервер ничего не
NOOP — делает. Всегда отвечает
положительно.
LOGOUT — Закрывает соединение
Запрашивает
альтернативный метод
AUTHENTICATE [механизм]
проверки
аутентичности
LOGIN [имя] [пароль] Указывает имя
 пользователя и пароль
для аутентификации с
передачей открытым
текстом
Открывает почтовый
SELECT [имя ящика]
ящик
Открывает почтовый
EXAMINE [имя ящика] ящик в режиме «только
для чтения»
Создает новый
CREATE [имя объекта]
почтовый ящик
DELETE [имя объекта] Удаляет почтовый ящик
[имя_ящика] Изменяет имя
RENAME
[новое_имя_ящика] почтового ящика
Добавляет почтовый
SUBSCRIBE [имя ящика] ящик в перечень
активных
Удаляет почтовый ящик
UNSUBSCRIBE [имя ящика]
из перечня активных
Отображает указанные
[путь к ящику] [имя имена почтовых
LIST
ящика] ящиков, выбирая из
полного набора имен
Отображает указанные
[путь к ящику] [имя имена почтовых
LSUB Доступна после
ящика] ящиков, выбирая из
успешной
набора активных
идентификаци
[имя ящика] (имена Отображает состояние и
STATUS
элементов) почтового ящика
\ Seen – прочитано;
\ Answered –
[имя_ящика] написан ответ;
(флаги_сообщения) \ Flagged – срочное; Добавляет сообщение в
APPEND [метка_времени \ Deleted – помечено конец указанного
сообщение] для удаления; почтового ящика
\ Draft – черновик;
\Recent – новое
сообщение
Команда производит
проверку выбранного
почтового ящика,
CHECK — характер которой
зависит от реализации
программного
обеспечения сервера.
Закрывает почтовый
ящик и стирает все
CLOSE —
сообщения,
отмеченные для
 удаления
Стирает из текущего
почтового ящика все
EXPUNGE — сообщения,
отмеченные для
удаления
Отображает все
сообщения почтового
[кодировка]
SEARCH ящика,
[критерий поиска]
соответствующие
критерию поиска
[от_№сообщения :
до_№сообщения] Извлекает сообщение
FETCH
[имя_элемента_сооб из почтового ящика
щения_или_макрос]
FLAGS – изменяет
значения указанных
флагов, кроме флага
\Recent;
[Link] –
аналогично FLAGS,
значения флагов не
возвращаются;
+FLAGS –
[от_№сообщения : устанавливает
до_№сообщения] значения указанных
Изменяет сообщение в
STORE [имя_элемента_данн флагов;
почтовом ящике
ых] (список_флагов) +[Link] –
аналогично +FLAGS,
значения флагов не
возвращаются;
–FLAGS – сбрасывает
значения указанных
флагов;
–[Link] –
аналогично –FLAGS,
значения флагов не
возвращаются;
Копирует указанные
[от_№сообщения :
сообщения в конец
COPY до_№сообщения]
указанного почтового
[имя ящика]
ящика
Находит сообщение по
[команда]
UID уникальному
[аргументы]
идентификатору
21.6 Пример сеанса

Условие: клиент помечает двенадцатое сообщение для удаления и завершает сеанс.

S: * OK IMAP4rev1 Service Ready

C: A001 login mrc secret
S: A001 OK LOGIN completed
C: A002 select inbox
S: * 18 EXISTS
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * 2 RECENT
S: * OK Message 17 is the first unseen message
S: * OK UIDs valid
S: A002 OK SELECT completed
C: A003 fetch 12 full
S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700"
[Link] 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)" "IMAP4rev1
WG mtg summary and minutes" (("Terry Gray" NIL "gray" "[Link]"))
(("Terry Gray" NIL "gray" "[Link]")) (("Terry Gray" NIL "gray"
"[Link]")) ((NIL NIL "imap" "[Link]")) ((NIL NIL
"minutes" "[Link]") ("John Klensin" NIL "KLENSIN" "[Link]")) NIL
NIL "<B27397-0100000@[Link]>") BODY ("TEXT" "PLAIN" ("CHARSET"
"US-ASCII") NIL NIL "7BIT" 3028 92))
S: A003 OK FETCH completed
C: A004 fetch 12 body
S: * 12 FETCH (BODY {342}
S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
S: From: Terry Gray gray@[Link]
S: Subject: IMAP4rev1 WG mtg summary and minutes
S: To: imap@[Link]
S: Cc: minutes@[Link], John Klensin KLENSIN@[Link]
S: Message-Id: B27397-0100000@[Link]
S: MIME-Version: 1.0
S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
S:
S: )
S: A004 OK FETCH completed
C: A005 store 12 +flags \deleted
S: * 12 FETCH (FLAGS (\Seen \Deleted))
S: A005 OK +FLAGS completed
C: A006 logout
S: * BYE IMAP4rev1 server terminating connection
S: A006 OK LOGOUT completed
22. SMTP (Simple Mail Transfer Protocol)

22.1 Общие сведения

SMTP (англ. Simple Mail Transfer Protocol — простой протокол передачи почты) —
это широко используемый сетевой протокол, предназначенный для передачи
электронной почты в сетях TCP/IP.

SMTP впервые был описан в RFC 821 (1982 год); последнее обновление в RFC 5321
(2008) включает масштабируемое расширение — ESMTP (англ. Extended SMTP). В
настоящее время под «протоколом SMTP», как правило, подразумевают и его
расширения.

Протокол SMTP предназначен для передачи исходящей почты с использованием

порта TCP 25.
В то время как электронные почтовые серверы и другие агенты пересылки
сообщений используют SMTP для отправки и получения почтовых сообщений,
работающие на пользовательском уровне клиентские почтовые приложения обычно
используют SMTP только для отправки сообщений на почтовый сервер для ретрансляции.
Для получения сообщений клиентские приложения обычно используют либо POP (англ.
Post Office Protocol — протокол почтового отделения), либо IMAP (англ. Internet Message
Access Protocol), либо патентованные системы (такие как Microsoft Exchange и Lotus
Notes/Domino) для доступа к учетной записи своего почтового ящика на сервере.

SMTP – текстовый протокол передачи почтовых сообщений, работающий в

сетях TCP/IP. Использует порт TCP 25.

22.2 Модель обработки почты

Простой протокол передачи почты обеспечивает двухсторонний обмен

сообщениями между локальным клиентом и удаленным сервером МТА. Данные
передаются в формате NVT ASCII.

NVT подобен виртуальному сетевому протоколу и необходим, чтобы скрыть

различия в восприятии разными компьютерами разных символов, например
переводов каретки, переводов строки, маркеров конца строки, очистки экрана и т. д.
Символ в NVT состоит из семи битов набора ASCII и является буквой, цифрой или
знаком пунктуации. Семибитный набор ASCII часто называется NVT ASCII.

Электронная почта представлена почтовым клиентом (MUA, mail user agent —

пользовательский почтовый агент) для почтового сервера (MSA, mail submission agent —
агент передачи электронной почты) с помощью SMTP по TCP-порту 587. Оттуда MSA
доставляет почту своим агентам пересылки сообщений (MTA, mail transfer agent). Часто
эти два агента являются просто различными образцами одного и того же программного
обеспечения, запущенного с разными параметрами на одном устройстве. Локальная
обработка может быть проведена как на отдельной машине, так и разделена между
различными устройствами; в первом случае вовлеченные процессы имеют общий доступ
к файлам, во втором случае SMTP используется для пересылки сообщения внутренне,
причем каждый хост настроен на использование следующего устройства в качестве
промежуточного хоста. Каждый процесс — сам по себе MTA, т. е. — SMTP-сервер.
Граничный MTA должен найти целевой хост. Он использует систему доменных
имен (DNS) для поиска записей почтового обменника (mail exchanger — MX) домена
получателя (часть адреса, находящаяся справа от символа @). Возвращаемая запись
почтового MX содержит имя целевого хоста. Затем MTA подключается к серверу обмена в
качестве SMTP-клиента.
Как только цель MX принимает входящее сообщение, она передает его агенту
доставки почты (mail delivery agent — MDA) для локальной доставки сообщения. MDA
предусматривает возможность сохранять сообщения в соответствующем формате
почтового ящика. Прием почты, опять же, может быть проведен как несколькими, так и
одним компьютером — изображение показывает два ближайших ящика для каждого
случая. MDA может доставлять сообщения прямо на хранение или передавать их по сети с
помощью SMTP или любых других средств, в том числе протокола локальной пересылки
почты (Local Mail Transfer Protocol — LMTP) — производного от SMTP, предназначенного
для этой цели.

Синие стрелки могут быть реализованы с использованием различных версий SMTP.

После доставки на локальный почтовый сервер сообщение хранится для пакетного

поиска по аутентифицированным почтовым клиентам (MUA). Сообщение извлекается
приложениями конечного пользователя (почтовыми клиентами) с использованием
протокола IMAP (Internet Message Access Protocol), который облегчает доступ к
сообщениям и управляет хранящейся почтой, или с помощью протокола POP (Post Office
Protocol), который обычно использует традиционный mbox-формат файлов, или
фирменными системами вроде Microsoft Exchange/Outlook или Lotus Notes/Domino.
Клиенты сетевой почты могут использовать любой метод, но протокол поиска часто не
соответствует официальным стандартам.
SMTP определяет передачу сообщения, а не его содержание. Таким образом, он
задает оболочку сообщения и её параметры (такие, как отправитель оболочки), но не
заголовок либо тело самого сообщения. STD 10 и RFC 5321 определяют SMTP (оболочку), в
то время как STD 11 и RFC 5322 — сообщение (заголовок и тело), официально называемый
форматом почтового сообщения (Internet Message Format).

SMTP — всего лишь протокол доставки. Он не может по требованию взять

сообщения с удаленного сервера. Для извлечения почты и управления
почтовым ящиком разработаны другие протоколы, такие как POP и IMAP. Тем не
менее, SMTP предоставляет возможность начать на удаленном сервере обработку
очереди сообщений, при которой запрашивающая система может получать все
направленные ей сообщения (см. Remote Message Queue Starting ниже). POP и IMAP
предпочтительны, когда компьютер пользователя включен не постоянно, или же
временно подключен к Интернету.

22.3 Возможности протокола

22.3.1 Основные команды

МТА-клиент шлет команды МТА-серверу, а он, в свою очередь, отвечает клиенту.

Другими словами, протокол SMTP требует получать ответы (они описаны в этой главе) от
приемника команд SMTP. Обмен командами и ответами на них называется почтовой
транзакцией (mail transaction).
– команды, как и само сообщение, передаются в формате NVT ASCII;
– команды передаются в форме ключевых слов, а не специальных символов, и
указывают на необходимость совершить ту или иную операцию.

В таблице ниже приведен список ключевых слов (команд), определенный в первой

спецификации SMTP - RFC 821.
Команда Обязательна ли Описание
HELO Идентифицирует модуль-передатчик для модуля-
да
приемника (hello).
Начинает почтовую транзакцию, которая завершается
MAIL да передачей данных в один или несколько почтовых ящиков
(mail).
 Идентифицирует получателя почтового сообщения
RCPT да
(recipient).
Строки, следующие за этой командой, рассматриваются
получателем как данные почтового сообщения. В случае
DATA нет
SMTP, почтовое сообщение заканчивается комбинацией
символов: CRLF-точка-CRLF.
RSET нет Прерывает текущую почтовую транзакцию (reset).
Требует от получателя не предпринимать никаких
NOOP нет действий, а только выдать ответ ОК. Используется главным
образом для тестирования.(No operation).
QUIT нет Требует выдать ответ ОК и закрыть текущее соединение.
нет (см. Требует от приемника подтвердить, что ее аргумент
VRFY
примечание) является действительным именем пользователя.
Начинает почтовую транзакцию, доставляющую данные на
SEND нет
один или несколько терминалов (а не в почтовый ящик).
Начинает транзакцию MAIL или SEND, доставляющую
SOML нет данные на один или несколько терминалов или в
почтовые ящики.
Начинает транзакцию MAIL и SEND, доставляющие данные
SAML нет
на один или несколько терминалов и в почтовые ящики.
Команда SMTP-приемнику подтвердить, действительно ли
EXPN нет аргумент является адресом почтовой рассылки и если да,
вернуть адрес получателя сообщения (expand).
Команда SMTP-приемнику вернуть сообщение-справку о
HELP нет
его командах.
Команда SMTP-приемнику либо сказать ОК и поменяться
TURN нет ролями, то есть стать STMP- передатчиком, либо послать
сообщение-отказ и остаться в роли SMTP-приемника.

Примечание: в RFC 821 сказано, что команда VRFY не является обязательной для
минимального набора команд SMTP. Однако в RFC 1123 <Требования для сетевых
компьютеров Internet - приложения и обеспечение работы> (Requirements for Internet
Hosts - Application and Support,Braden, 1989), команда VRFY фигурирует в списке
обязательных для Internet команд реализации SMTP.
В соответствии со спецификацией команды, отмеченные как обязательные в
таблице, должны присутствовать в любой реализации SMTP. Остальные команды SMTP
могут быть реализованы дополнительно. Каждая SMTP-команда должна заканчиваться
либо пробелом (если у нее есть аргумент), либо комбинацией CRLF. В описании команд
употреблялось слово <данные", а не <сообщение>. Этим подчеркивалось, что, кроме
текста, SMTP позволяет передавать и двоичную информацию, например графические или
звуковые файлы. Другими словами, SMTP способен передавать данные любого
содержания, а не только текстовые сообщения. Это значит, что, рассматривая вопросы,
касающиеся SMTP, не забывайте, что термин "сообщение" обозначает не только
текстовые данные.
 Команды HELO, MAIL и RCPT должны присутствовать в любой реализации SMTP.
Остальные команды SMTP могут быть реализованы дополнительно. Каждая
SMTP-команда должна заканчиваться либо пробелом (если у нее есть аргумент), либо
комбинацией CRLF.

22.3.1 Дополнительные возможности

Remote Message Queue Starting (запуск удаленной очереди сообщений) –

особенность SMTP, позволяющая удаленному хосту начать обработку очереди сообщений
на сервере так, что он может получать предназначенные ему сообщения с помощью
команды TURN. Однако эта особенность считалась небезопасной и была расширена в RFC
1985 командой ETRN, которая работает надёжнее благодаря основанному на информации
DNS методу аутентификации.
ODMR (On-Demand Mail Relay — ретрансляция почты по требованию) —
стандартизированное в RFC 2645 SMTP-расширение, позволяющее проводить
ретрансляцию сообщения аутентифицированному пользователю.
Многие пользователи, чей набор символов отличается от латиницы, сталкиваются с
требованием адреса электронной почты на латинице. Для решения этой проблемы был
создан RFC 6531, предоставляющий возможности для интернационализации для SMTP —
расширение SMTPUTF8. RFC 6531 предоставляет поддержку многобайтных и не-ASCII
символов в почтовом адресе, например: δοκιμή@παράδειγμα.δοκιμή или 测试@测试.测.
Текущая поддержка ограничена, но есть большой интерес в широком распространении
RFC 6531 и связанных с ним RFC в странах с обширной базой пользователей, для которых
латиница не является родным алфавитом.

Расширения SMTP позволяют удаленному хосту начать обработку очереди

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

22.4 Коды ответов SMTP

В спецификации SMTP требуется, чтобы сервер отвечал на каждую команду SMTP-

клиента. МТА-сервер отвечает трехзначной комбинацией цифр, называемой кодом
ответа. Вместе с кодом ответа, как правило, передается одна или несколько строк
текстовой информации.

Несколько строк текста, как правило, сопровождают только команды EXPN и HELP. В
спецификации SMTP, однако, ответ на любую команду может состоять из
нескольких строк текста.
 Каждая цифра в коде ответа имеет определенный смысл. Первая цифра означает,
было ли выполнение команды успешно (2), неуспешно (5) или еще не закончилось (3). Как
указано в приложении Е документа RFC 821, простой SMTP-клиент может анализировать
только первую цифру в ответе сервера, и на основании ее продолжать свои действия.
Вторая и третья цифры кода ответа разъясняют значение первой. Если вы разрабатываете
SMTP-приложение, обязательно изучите конструкцию всех кодов SMTP-ответа. То, как
коды составлены в самом SMTP - превосходный образец грамотного подхода к делу. В
таблице ниже приведены возможные значения кодов ответа SMTP, определенные в RFC
821.

Код Значение
211 Ответ о состоянии системы или помощь
214 Сообщение-подсказка (помощь)
220 <имя_домена> служба готова к работе
221 <имя_домена> служба закрывает канал связи
250 Запрошенное действие почтовой транзакции успешно завершилось
251 Данный адресат не является местным; сообщение будет передано по маршруту
<forward-path>
354 Начинай передачу сообщения. Сообщение заканчивается комбинацией CRLF-точка-
CRLF
421 <имя_домена> служба недоступна; соединение закрывается
450 Запрошенная команда почтовой транзакции не выполнена, так как почтовый ящик
недоступен
451 Запрошенная команда не выполнена; произошла локальная ошибка при обработке
сообщения
452 Запрошенная команда не выполнена; системе не хватило ресурсов
500 Синтаксическая ошибка в тексте команды; команда не опознана
501 Синтаксическая ошибка в аргументах или параметрах команды
502 Данная команда не реализована
503 Неверная последовательность команд
504 У данной команды не может быть аргументов
550 Запрошенная команда не выполнена, так как почтовый ящик недоступен
551 Данный адресат не является местным; попробуйте передать сообщение по
маршруту <forward-path>
552 Запрошенная команда почтовой транзакции прервана; дисковое пространство,
доступное системе, переполнилось
553 Запрошенная команда не выполнена; указано недопустимое имя почтового ящика
554 Транзакция не выполнена

22.5 Пример передачи сообщения по протоколу SMTP

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

передачи почты (МТА), клиентом и сервером. Клиенты шлют команды серверу, а серверы
отвечают клиентам. Однако SMTP оговаривает последовательность SMTP-команд.
Пример почтовой транзакции: Мистер Smith (на компьютере [Link]), посылающий
сообщения мистерам Jones, Green и Brown (на компьютере [Link]). Агент передачи
почты хоста [Link] принимает почту для мистеров Jones и Brown, однако не знает, где
расположен почтовый ящик мистера Green.

Пояснение к примеру:
– текст справа от слов <RECEIVER> или <SENDER> содержит действительно передаваемые
данные;
– трехзначные цифровые комбинации в начале передаваемых строк обозначают коды
ответа.
1 RECEIVER 220 [Link] Simple Mail Transfer Service Ready
2 SENDER HELO [Link]
3 RECEIVER 250 [Link]
4 SENDER MAIL FROM: <Smith@[Link]>
5 RECEIVER 250 OK
6 SENDER RCPT TO:<Jones@[Link]>
7 RECEIVER 250 OK
8 SENDER RCPT TO:<Green@[Link]>
9 RECEIVER 550 No such user here
10 SENDER RCPT TO:<Brown@[Link]>
11 RECEIVER 250 OK
12 SENDER DATA
13 RECEIVER 354 Start mail input; end with <CRLF>.<CRLF>
14 SENDER Blah blah blah...
15 SENDER ...etc. etc. etc.
16 SENDER .
17 RECEIVER 250 OK
18 SENDER QUIT
19 RECEIVER 221 [Link] Service closing transmission channel
Как видно из строки 1, когда SMTP-клиент устанавливает TCP-соединение с портом
протокола 25, SMTP-сервер отвечает кодом 220. Это означает, что соединение успешно
установлено:

1 RECEIVER 220 [Link] Simple Mail Transfer Service Ready

После того как MTA компьютеров [Link] и [Link] установили соединение и

обменялись приветствием, первой командой, согласно спецификации, должна быть
команда HELO. Как указано в строке 2, SMTP-клиент передает HELO, указывая имя своего
компьютера в качестве аргумента. Другими словами, он сообщает: <Привет, я - [Link]>.
Команда HELO употребляется с аргументом, как показано ниже:

2 SENDER HELO [Link]

 В ответ на HELO приемник выдает код 250, сообщая передатчику о том, что
команда принята и обработана:

3 RECEIVER 250 [Link]

После установления TCP-соединения и идентификации (при помощи HELO) SMTP-

клиент приступает к почтовой транзакции. Для начала он выполняет одну из следующих
команд: MAIL, SEND, SOML или SAML. В нашем примере использована команда MAIL:

4 SENDER MAIL FROM: <Smith@[Link]>

Все четыре команды, MAIL, SEND, SOML и SAML, имеют одинаковый синтаксис:

MAIL <пробел> FROM:<reverse-path> <carriage-return line-feed>

Команды SEND, SOML и SAML дополнительны и используются довольно редко.

Аргумент <обратный путь> (reverse path) указывает серверу, кому в случае ошибки
отослать соответствующее сообщение. Мы еще рассмотрим его подробнее в следующе й
главе. На данный момент для нас важно, что в аргументе содержится адрес источника
сообщения (в нашем случае, Smith@[Link]). После того как сервер выдал код ответа 250
(строка 5), согласившись обработать сообщение от Smith@[Link] необходимо указать
получателя сообщения. Это делается при помощи команды RCPT. Команда RCPT имеет
аргумент - имя получателя. На одну команду приходится только одно имя, поэтому, если
получателей несколько, команда RCPT выдается несколько раз. В нашем примере
команды RCPT выполняются в строках 6, 8 и 10. Синтаксис RCPT похож на синтаксис
команды MAIL:

RCPT <пробел> TO:<forward-path> <CRLF>

Однако, в отличие от MAIL, аргумент RCPT начинается со слова <ТО:>. Содержимое

аргумента - путь передачи сообщения (forward path), а не обратный путь. На данный
момент для нас важно, что в пути передачи сообщения указано имя почтового ящика
получателя. Выдав команду RCPT, МТА-клиент ожидает получить ответ с кодом 250.
Однако в ответ на восьмую строку

8 SENDER RCPT TO:<Green@[Link]>

сервер отвечает кодом 550:

9 RECEIVER 550 No such user here

 Код ответа 550 означает, что МТА не в состоянии выполнить запрос клиента,
поскольку не знает, как доставить почту указанному пользователю. То есть, скорее всего, у
мистера по фамилии Green нет почтового ящика (Green@[Link]) на этом компьютере. В
протоколе SMTP сказано, что сервер обязан информировать клиента об отсутствии
почтового ящика получателя сообщения. Однако в спецификации SMTP ничего не
говорится о том, как клиент должен реагировать на это сообщение.
После того как посланы все команды RCPT, клиент начинает передачу данных при
помощи команды DATA. В строке 12 показано, как МТА-клиент (передатчик) высылает
команду DATA, в строке 13 - как сервер отвечает кодом 354. Этот код означает, что
передача данных разрешена и должна заканчиваться комбинацией CRLF-<точка>-CRLF
(новой строкой, содержащей только точку).

12 SENDER DATA
13 RECEIVER 354 Start mail input; end with <CRLF>.<CRLF>

После того как получен код 354, клиент может начать передачу данных. МТА-
сервер, в свою очередь, помещает принятые данные в очереди входящих сообщений.
Сервер не высылает никаких ответов до тех пор, пока не получит комбинацию CRLF-точка-
CRLF от клиента, означающую конец передачи данных. Как показано в строках 16 и 17, в
ответ на полученную комбинацию CRLF-<точка>-CRLF, сервер выдает код 250. Как мы уже
говорили, код ответа 250 означает успешное окончание операции:

16 SENDER .
17 RECEIVER 250 OK

Для того чтобы закончить почтовую транзакцию, клиент, по правилам SMTP, обязан
послать команду QUIT. Сервер, в свою очередь, отвечает кодом 221. Этот код
подтверждает клиенту, что соединение будет закрыто, после чего соединение
действительно закрывается:

18 SENDER QUIT
19 RECEIVER 221 [Link] Service closing transmission channel

В любой момент во время транзакции клиент может использовать команды NOOP,

HELP, EXPN и VRFY. В ответ на каждую команду сервер высылает клиенту определенную
информацию. Конечно, в зависимости от ответа клиент может предпринять
определенные действия, однако спецификация SMTP ничего не говорит по этому поводу.
Например, клиент-МТА может передать команду VRFY для того, чтобы убедиться, что имя
пользователя действительно. Если сервер ответит, что данного имени не существует,
клиент МТА может не передавать почту для этого пользователя. В спецификации SMTP,
однако, на этот счет нет никаких указаний - клиент может ничего не делать в ответ на
команду VRFY. МТА-клиент может ничего не делать также в ответ на команды NOOP, HELP
и EXPN - ответственность целиком лежит на разработчике конкретной реализации МТА.
22.6 Промежуточные агенты

Термин "маршрут доставки" (forward-path) служит для того, чтобы отличать

почтовый ящик (mailbox), имя которого абсолютно, от пути (он может быть различным),
по которому следует почта. Предположим, что мы хотим доставить два почтовых
сообщения на один и тот же сетевой компьютер. Оба сообщения имеют один и тот же
адрес, однако не обязательно будут следовать по одному и тому же маршруту. Точно так
же, если на пришедшие сообщения выдаются ответы, они не обязательно будут следовать
по указанному обратному маршруту (reverse-path). Как правило, конкретный маршрут для
почты выбирается системным администратором. Чтобы направить почту по нужному пути,
используются значения маршрута доставки и обратного маршрута, в которых указываются
промежуточные агенты (relay agents). Промежуточный агент доставки - это МТА, так
называемый почтовый хаб (mail hub), настроенный на передачу транзитной почты. Чтобы
доставить сообщение, местный агент пользователя (UA) передает его местному МТА,
который, в свою очередь, передает его промежуточному агенту МТА. В следующем
примере Smith@[Link] является почтовым ящиком, a HOSTI, HOST2 и HOST3 -
промежуточными агентами:

MAIL FROM:<@HOSTI, @HOST2, @HOST3:Smith@[Link]>

В наше время промежуточные агенты присутствуют практически во всех сетях,

входящих в Internet. На рисунке ниже приведена типичная конфигурация почтовой
системы Internet с участием промежуточных агентов.
Чтобы упростить процесс конфигурации почтовой системы, в локальной сети
устанавливается один компьютер, служащий промежуточным агентом (relay host):
– вся почта пользователей сначала попадает на этот компьютер, который рассылает
сообщения по Internet;
– такой компьютер может служить защитой организации от взломщиков-хакеров из
Internet. Ограничивая общение локальной сети с внешним миром до уровня почты,
организация сводит до минимума риск нежелательного вторжения в свои собственные
системы;
– администрировать и защищать необходимо только этот компьютер.

SMTP в состоянии послать сообщение непосредственно с компьютера пользователя на

компьютер адресата в том случае, если между ними существует прямое почтовое
соединение. Как правило, между двумя компьютерами находится один или несколько
промежуточных агентов. Чтобы обеспечить доставку, в почтовом сообщении нужно
указать имя компьютера-получателя и точное наименование почтового ящика.
Аргументом команды MAIL является обратный маршрут, включающий имя источника
сообщения и имена всех промежуточных агентов. Аргумент команды RCPT – маршрут
доставки, содержащий имя получателя сообщения. Обратный маршрут описывает путь,
который прошло сообщение, тогда как маршрут доставки идентифицирует место
назначения. Обратный маршрут используется SMTP, когда нужно передать сообщение о
случившейся ошибке или о невозможности доставить сообщение, когда оно уже прошло
через промежуточный агент. По мере продвижения сообщения по Internet записи о его
маршрутах изменяются. В обязанности системных администраторов входит правильно
настраивать местные МТА на передачу сообщений промежуточному агенту, и наоборот,
промежуточные агенты на доставку сообщений местным МТА. Если у промежуточного
МТА изменится имя, все, что нужно сделать в конфигурации местного МТА - изменить имя
компьютера в системе DNS. Другие параметры конфигурации не изменяются.
Рассмотрим почтовую транзакцию между промежуточными агентами SMTP. До
того как сообщение будет передано следующему указанному в маршруте компьютеру (в
поле «ТО:»), имя данного компьютера удаляется из маршрута доставки и добавляется в
начало обратного маршрута. К тому моменту, когда сообщение достигнет пункта
назначения, маршрут доставки будет содержать только имя почтового ящика. В RFC 821
приведен пример того, как изменяется содержимое маршрутов по мере обработки
почтового сообщения. Когда промежуточный агент А получает почту со следующими
аргументами:

FROM: <USERX@[Link]>
TO: <@[Link], @[Link]: USERC@[Link]>

он переправляет почту сетевому компьютеру В со следующими аргументами:

FROM: <@[Link]: USERX@[Link]>

TO: <@[Link]: USERC@[Link]>

Как видим, промежуточный агент A ([Link]) убрал свое имя из заголовка

<ТО:> и добавил в заголовок <FROM:>. Промежуточный агент компьютера В совершит
аналогичное действие, и следующим пунктом назначения сообщения будет почтовый
ящик USERC на компьютере [Link].

Другими словами, обратные маршруты и маршруты доставки строятся

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

22.7 Безопасность в SMTP

Изначальная спецификация SMTP не включала средств для аутентификации

отправителей. Впоследствии, в RFC 2554 было введено расширение. Расширение SMTP
(ESMTP) предоставляет почтовым клиентам механизм задания механизма обеспечения
безопасности для сервера, аутентификации и профиля безопасности SASL (Simple
Authentication and Security Layer) для последующих передач сообщений.
Продукты Microsoft реализуют собственный протокол – SPA (Secure Password
Authentication) с помощью расширения SMTP-AUTH.
Однако, непрактичность широкого распространения реализации и управления
SMTP-AUTH означает, что проблема спама не может быть решена с его помощью.
Обширное изменение SMTP, так же как и полная его замена, считаются непрактичными
из-за огромной инсталлированной базы SMTP. Internet Mail 2000 был одним из
претендентов для такой замены.
Спам функционирует благодаря различным факторам, в том числе не
соответствующие стандартам реализации MTA, уязвимости в защите операционных
систем (усугубляемые постоянным широкополосным подключением), что позволяет
спамерам удаленно контролировать компьютер конечного пользователя и посылать с
него спам.
Существует несколько предложений для побочных протоколов, помогающих
работе SMTP. Исследовательская группа Anti-Spam (The Anti-Spam Research Group – ASRG)
– подразделение Исследовательской группы Интернет-технологий работает над почтовой
аутентификацией и другими предложениями для предоставления простой
аутентификации, которая будет гибкой, легковесной и масштабируемой. Недавняя
деятельность Инженерного совета Интернета (IETF) включает в себя MARID (2004),
приведший к двум утвержденным IETF-экспериментам в 2005, и DomainKeys Identified
Mail в 2006.

SMTP имеет собственное расширение для аутентификации, но оно не слишком

удобно, поэтому компании нередко создают собственные решения. Кроме того,
ведутся работы над побочными протоколами для SMTP, которые могли бы решить
проблему безопасности и блокирования спама.
23. NAT (Network Address Translation)

23.1 Общие сведения

NAT (Network Address Translation) – это разновидность технологии Proxy, в которой

существование посредника является прозрачным для взаимодействующих сторон.
На некотором этапе развития компьютерных сетей и систем стало понятно, что
диапазона четырехбайтных IP-адресов (IPv4) в будущем может оказаться недостаточно;
появилась потребность в предоставлении доступа в Интернет большому количеству узлов,
которые располагаются в локальной сети, но с предоставлением глобального уникального
IP-адреса только тому узлу (или маршрутизатору), через который идет подключение к
Интернету, что привело к созданию технологии NAT.

Основной принцип NAT: глобальные уникальные IP-адреса нужно выдавать

ограниченному количеству узлов-концентраторов, которые находятся в своих
локальных сетях. Для остальных узлов локальной сети можно использовать
уникальные только в пределах этой сети IP-адреса (обычно выбираются из диапазонов
10.*.*.* или 192.168.*.*).

ЛВС (LAN)
IP1
Интернет
локальный

IP2
IP
локальный
глобальный
*
IP лок

IP3 Узел Интернета

локальный (с глобальным
IP)

IP4
локальный

Каким образом узлам, не имеющим глобального уникального IP-адреса, но

подключенным к узлу-концентратору, выйти в Интернет? Ведь если они отправят
пакет, имея только локальный адрес, то не смогут получить ответ.
23.2 Статический NAT

23.2.1 Общие сведения

Статический NAT – это подход, при котором узлы в локальной сети разделяют
несколько глобальных IP-адресов, выделенных узлу-концентратору. Так происходит
разделение глобального адреса во времени (узлы используют глобальные IP-адреса
попеременно).
Узел, который одновременно подключен и к локальной сети, и к сети Интернет,
имеет два IP-адреса – глобальный и локальный. Через локальный адрес он работает в
локальной сети, через глобальный – в сети Интернет. Для узлов создается временное
соответствие вида

Локальный IP-адрес Глобальный IP-адрес

… …

Узел-концентратор выступает в роли стандартного шлюза (default gateway): выполняет

необходимое преобразование адресов. Для любых пакетов, приходящих ему, но
направленных в сеть Интернет, концентратор подменяет значение IP-адреса отправителя
(локальный -> глобальный) и отсылает пакет в Интернет. Когда концентратор принимает
пакеты из внешней сети, он изменят глобальный IP-адрес на локальный и отсылает пакет
узлу-временному владельцу глобального адреса в локальной сети.

Статический NAT позволяет разделять IP-адреса во времени с помощью

установки временного соответствия глобального и локального адресов.
Работает на сетевом (третьем) уровне семиуровневой модели ISO/OSI.

23.2.2 Достоинства и недостатки статического NAT

Недостаток: временное соответствие глобального и локального IP-адресов

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

Статический NAT обеспечивает экономию глобальных IP-адресов, но все узлы

локальной сети вынуждены работать в сети Интернет поочередно, что
доставляет неудобство.
23.2.3 Сфера применения статического NAT

Если узел из локальной сети выходит в сеть Интернет, у него выполняется

преобразование адресов. Точно так же преобразование выполняется, когда пакеты идут
из Интернета в локальную сеть, в том числе и пакеты на установку соединения. Поэтому
такое статическое временное соответствие адресов обеспечивает возможность установки
соединения из глобальной сети с сервером в локальной сети, у которого есть только
локальный IP-адрес. Примером использования статического NAT может послужить
подключение к провайдеру Интернет через модем или Ethernet, когда (обычно за
дополнительную плату) существует возможность получить статический IP-адрес –
статическое соответствие некоторого глобального IP-адреса, принадлежащего
провайдеру, и своего локального адреса. После получения статического IP-адреса
появляется возможность удаленно подключаться к компьютеру, имеющему такой адрес.

Статический NAT полезен для установки соединения из глобальной сети с

компьютером в локальной сети, у которого есть только локальный IP адрес.

23.3 Динамический NAT

23.3.1 Общие сведения

Динамический NAT или PAT (Port Address Translation) – второй вариант

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

Идея динамического NAT: на промежуточном узле, одновременно подключенном

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

Пусть, например,

Номера портов

<= 30000 > 30000

Зарезервированы для
Принадлежат узлу
использования NAT
23.3.2 Работа в сочетании с протоколом TCP

Отличие динамического и статического NAT: динамический NAT работает на

уровне прикладных протоколов. Если статический NAT – это работа на уровне
протокола IP (сетевой уровень), то динамический NAT – работа не на третьем, а на
четвертом (транспортном) уровне семиуровневой модели. Динамический NAT
требует интерпретации пакетов сетевого уровня.

Динамический NAT обеспечивает возможность прозрачной установки соединений

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

ЛВС (LAN)
Интернет
[Link]

[Link]
[Link], порт 80
[Link] (узел Интернета)
(глобальный)
*
[Link]
(локальный)

Маска
[Link]

Пусть есть локальная сеть:

[Link] и [Link] – узлы, не имеющие глобальных IP-адресов;
[Link] – концентратор, который имеет глобальный уникальный адрес
[Link];
[Link] – маска подсети.
Условие: узел [Link] хочет подключиться к узлу в Интернете [Link],
который является веб-сервером, прослушивающим порт 80, и посылает пакет на
установку соединения.

[Link]
[Link]
SYN TCP
2000 80
В пакете указывается:

Адрес отправителя [Link]

Адрес получателя [Link]
Флаг SYN SYN
Признак протокола TCP
Порт отправителя (выбирается первый 2000
свободный после 1024, например 2000)
Порт получателя 80

Номер подсети отправителя = [Link] + маска = [Link].

Номер подсети получателя = [Link] + маска = [Link].

Номера подсетей не совпадают.

Пакет отсылается на MAC-адрес стандартного шлюза для [Link] – [Link].

На этом узле работает динамический NAT и ведется следующая таблица:

Номер порта IP-адрес Порт отправителя На что подменять

отправителя
30001 [Link] 2000 [Link]

Для каждого пользователя в таблице создаются отдельные записи. Концентратор с

NAT в первую очередь проверяет, что пакет адресован не ему. По таблице маршрутизации
он определяет, куда пересылать пакеты. Концентратор помечает пакет как «пакет для
пересылки», затем выполняет подмену адресов (с использованием таблицы). Он
выделяет после 30000 некоторый свободный порт, например, 30001, и выполняет
подмену адреса отправителя по таблице. В нашем примере адрес [Link] заменяется
на [Link] (глобальный адрес концентратора). Адрес получателя и флаги остаются
прежними. Далее идет интерпретация пакета – извлекается порт отправителя,
полученный порт заменяется на выделенный концентратором. В нашем примере порт
2000 заменяется на 30001. Порт получателя не изменяется.

[Link]
[Link]
SYN TCP
30001 80
 Дальше пакет отправляется на MAC адрес маршрутизатора, через который
выполняется подключение.

Обратный пакет (подтверждения установки соединения) идет с адресом

отправителя [Link] и адресом назначения [Link]. Установлены флаги SYN и
ACK, протокол – TCP. Порт отправителя – 80, порт получателя – 30001.

[Link]
[Link]
SYN ACK TCP
80 30001

Этот пакет приходит к узлу-концентратору, на котором работает динамический

NAT. Он проверяет адрес получателя, который оказывается принадлежащим ему, затем
проверяет значение порта. Порт (30001) лежит за границей собственных портов
концентратора, значит он предназначен для трансляции, поэтому нужно выполнить
преобразование адресов и отправить данные какому-то из локальных узлов.

[Link]
[Link]
SYN ACK TCP
80 2000

По порту 30001 концентратор отыскивает нужную строку в таблице динамического

NAT и выполняет подмену IP-адреса получателя: [Link] -> [Link]. Флаги и адрес
отправителя остаются неизменными. Значение порта получателя также меняется по
таблице: 30001 –> 2000.

Далее преобразованный пакет отправляется на MAC адрес узла-получателя.

Таким образом, при использовании всего одного глобального уникального IP-

адреса появляется возможность дать одновременный доступ в сеть Интернет большому
количеству локальных узлов. Максимальное количество соединений, которые могут быть
установлены одновременно, равно количеству портов, выделенных для NAT. Для
приведенного примера это 65535 – 30000 = 35535 потенциальных соединений, однако
следует учитывать, что количество соединений ограничено не только количеством портов,
но также и аппаратными возможностями узла-концентратора.
 Динамический NAT, в отличие от статического, работает не на сетевом
(третьем), а на транспортном (четвертом) уровне семиуровневой модели
ISO/OSI, поскольку в нем выполняется анализ и модификация содержимого пакетов.
Динамический NAT не позволяет обеспечить установку соединения из сети
Интернет с локальным узлом, для получения такой возможности можно
использовать статический NAT вместе с динамическим.

23.3.3 Работа в сочетании с протоколом UDP

В случае UDP не существует понятия установки соединения, клиента и сервера. Как

должен вести себя NAT, когда с некоторого IP-адреса посылается UDP-пакет с выбранным
номером исходящего порта на другой, целевой, адрес с указанием порта?

Примером работы NAT с UDP служит программа Skype. Для работы этой
программы важна высокая скорость и одноранговая сеть без промежуточных
узлов, которые могут тормозить ее работу (неприемлемы понятия клиента и
сервера, используемые в TCP).

Устройство, на котором работает NAT, использует временное кэширование

соответствий для UDP аналогично соответствиям в таблице для протокола TCP. Для UDP
вводится виртуальное понятие установки соединений: если первый пакет идет из
локальной сети в глобальную, появляется запись в таблице.

[Link]
[Link]
UDP
2001 1050

Пусть идет пакет [Link] -> [Link], порт отправителя – 2001, порт
получателя – 1050. Пакет передается на MAC адрес узла [Link] (узел-концентратор с
NAT).

Номер порта IP-адрес отправителя Порт отправителя На что подменять

30002 [Link] 2001 [Link]

У себя в таблице концентратор фиксирует, что для UDP было выполнено

обращение с порта 2001, IP – [Link], концентратор выделяет и указывает порт для
этого соединения – пусть это будет 30002 (30001 уже занят) и указывает свой внешний
адрес – [Link]. Далее по этой записи в таблице выполняется подмена: [Link] –>
[Link], адрес и порт получателя не изменяются, протокол – UDP, порт отправителя
2001 -> 30002.
 [Link]
[Link]
UDP
30002 1050

Обратный пакет идет с [Link], порт 1050 -> порт 30002 адреса [Link].
При этом выполняется трансляция (выясняется номер порта получателя, указанный в
пакете - 30002), узел-концентратор получает из таблицы адрес и порт узла ([Link] и
2001 соответственно), который пользуется таким внешним портом, подменяет значения
получателя в пакете и отправляет ему пакет по MAC-адресу.

[Link]
[Link]
UDP
1050 30002

[Link]
[Link]
UDP
1050 2001

Таким образом, при использовании UDP также выполняется трансляция, но

основанием для нее является появление в динамической таблице NAT записи с
соответствием адресов и портов и указанием, что это UDP.

В таблице в случае UDP появляется дополнительная колонка со временем, которая

позволяет удалить запись, если логическое соединение не используется в течение
длительного промежутка времени. После удаления порт 30002 может быть использован
повторно. Такой подход применяется, поскольку в случае UDP из-за отсутствия
соединений нельзя с уверенностью сказать, используется ли внешний порт локальным
узлом. В TCP такой проблемы не существует, т.к. TCP-соединение активно всегда (если
пользовательской активности нет, то производится зондирование нулевым окном). Чтобы
логическое соединение для UDP не разрывалось, периодически нужно передавать
некоторую информацию.

Для работы динамического NAT с UDP вводится понятие логического

соединения. Такое соединение разрывается при отсутствии активности в
течение некоторого времени.
23.3.4 Работа связки NAT и DHCP

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

протокол DHCP – в сочетании с NAT эти технологии решают проблемы друг друга.
Например, DHCP призван выдавать IP-адреса автоматически из некоторого пула адресов.
Для локальной сети это всегда будут локальные адреса, имеющие префикс 192.168. Это
позволяет любому устройству, подключившись к локальной сети, получить по протоколу
DHCP адрес в этой сети и иметь возможность работать в локальной сети. А протокол NAT и
установка в рамках DHCP, кроме IP-адреса, еще и стандартного шлюза обеспечивает
возможность автоматически выходить в Интернет при подключении к локальной сети,
если стандартный шлюз использует NAT.
Например, пользователь мобильного телефона может подключиться к
беспроводной сети и тут же получить возможность выхода в Интернет, хотя, казалось бы,
выход в Интернет сопряжен с обязательной выдачей глобального уникального IP адреса.
Как это работает? В сети сконфигурирован DHCP, широковещательным запросом
устройство узнает MAC-адрес DHCP-сервера и, обратившись к нему, получает локальный
IP-адрес из пула адресов DHCP. DHCP также устанавливает стандартный шлюз, который
одновременно является NAT-транслятором. При обращении к ресурсам Интернета
произойдет перенаправление пакетов на маршрутизатор, подмена локальных IP-адреса и
порта; такую же трансформацию пройдут пакеты ответа. Для всего этого пользователю не
нужно вручную конфигурировать параметры сети, а достаточно просто подключиться к
точке доступа.

Связку NAT и DHCP можно встретить во многих домашних маршрутизаторах с

функцией точки доступа Wi-Fi: если такой маршрутизатор имеет доступ к
сети Интернет, все мобильные и стационарные устройства, подключаемые к нему,
объединяются в локальную сеть с помощью DHCP и получают доступ к Интернету
благодаря NAT.

23.3.5 Достоинства и недостатки

Достоинства динамического NAT – обеспечение высокой безопасности благодаря

изоляции локальной сети от входящих запросов на установку соединения.
Злоумышленник лишается возможности узнать IP-адрес и обратиться к службам,
работающим внутри локальной сети. Поэтому NAT обязательно применяется в сетевых
экранах, призванных изолировать локальную сеть от глобальной сети Интернет. Только по
инициативе узла локальной сети может быть выполнена установка соединения с
сервером в Интернете.
23.3.6 Сфера применения

Технология NAT используется для:

1) облегчения выдачи IP-адресов Интернета – чтобы работать в сети Интернет, не
нужно выдавать каждому узлу глобальный IP-адрес и следить за тем, кому он
выдан;
2) получения возможности централизованного администрирования – при
использовании NAT известно, что все глобальные адреса для сети выданы
одному узлу-концентратору.

Динамический NAT – это безопасно: злоумышленник не сможет подключиться

к локальному компьютеру из внешней сети. Кроме того, динамический NAT
дает возможность централизованного администрирования.

24. Сетевые экраны

24.1 Общие сведения

Сетевой экран – это неотъемлемая часть сетевого программного обеспечения,

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

В ОС Windows сетевые экраны появились только в версии XP (с выходом Service

Pack 1). В других операционных системах, в частности, Linux, сетевой экран был
дополнительной частью системы. Сейчас сетевой экран входит в стандартную
поставку любой операционной системы.

24.2 Принцип работы

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

Фильтрация пакетов – это анализ пакетов по некоторым критериям и

принятие решения о том, пропускать пакеты дальше или нет.

– сетевые экраны бывают разных уровней, часто программа-экран объединяет в себе

сетевые экраны нескольких уровней, которые работают вместе;
– уровни сетевых экранов соответствуют уровням семиуровневой сетевой модели ISO/OSI.
Естественно, на физическом уровне сетевые экраны не работают, но уже для второго,
канального уровня, они есть;
– у сетевых экранов выделяют два понятия – входящий (inbound) и исходящий (outbound)
трафик.

Трафик

Входящий (Inbound) Исходящий (Outbound)

Приходит на узел из сети от Данные, отправляемые с текущего

некоторого другого узла. узла сети на другой узел.

Сетевой экран анализирует входящие или исходящие пакеты, поступающие с

нижележащего или вышележащего уровня соответственно.

24.3 Правила фильтрации

Работа сетевых экранов построена на использовании правил фильтрации. Правила

бывают двух типов: разрешающие и запрещающие.

Правила

Разрешающие Запрещающие

– и для разрешающих, и для запрещающих правил используются системы работающих

вместе правил;
– выбирается приоритет – определяется, какие правила «выше»;
– для правил часто устанавливается порядок применения, т.к. они могут иметь
пересечение по параметрам;
– правила, работающие на любом из уровней, оперируют теми понятиями адресации,
которые существуют на этом уровне. Так, правила канального уровня оперируют MAC-
адресами, правила сетевого уровня – IP-адресами, правила транспортного уровня – IP-
адресами и номерами портов, а правила прикладного уровня – IP-адресами, номерами
портов и именами программ.
Пример: может быть создано правило для фильтрации входящего UDP-трафика и правило
для входящего UDP-трафика, идущего на порт 2048.
ка
ра фи
Очевидно, что второе правило является P-т
UD
го
подмножеством первого. Однако часто я ще
д
вх о
между правилами могут возникать д ля Правило для
ло входящего UDP-
ави
противоречия. В этом случае становится Пр трафика, который
идет на порт 2048
непонятным, какое из них должно
работать первым, а какое – вторым.
Управляя порядком, вы управляете
приоритетом срабатывания правил.

24.4 Семантические сетевые экраны

Семантический сетевой экран – это сетевой экран, который, исходя из анализа

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

Семантические сетевые экраны работают на эвристических методах, что влечет за

собой ряд недостатков. В системах, основанных на правилах, распространенной является
следующая проблема: в них существует понятие «обнаружения нарушения правил».

Поведение

Негативное Ложное позитивное (False positive)

Нарушения правила нет, но

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

Отсутствие должной реакции Ложное срабатывание системы

Эвристический алгоритм — алгоритм решения задачи, не имеющий строгого

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

Приведем пример создания нового правила на примере сетевого экрана ОС

Windows 7.

1. Панель Управления -> Брандмауэр Windows -> Дополнительные параметры.

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

исходящим трафиком.
 2. Мастер настройки правил упрощает их задание.

Режим Custom (настраиваемое правило) – режим, доступный при создании правил,

который позволяет указать новый параметр.
3. Существует возможность указать, к каким программам относится правило.

Программы Описание
Все программы Правило относится ко всем программам, т.е. оно не является
правилом прикладного уровня. В этом случае анализ по стеку
вызовов не выполняется, используются другие методы анализа.
Путь программы Правило относится к единичной программе. При анализе
обязательно выполняется проверка стека вызовов с анализом,
откуда идет вызов.
Когда в сеть посылается пакет, при вызове в точке анализа
разбирается стек вызовов. При проходе по стеку вызовов можно
увидеть адреса процессов, которые находятся в стеке, и
проанализировать, какая программа сделала вызов.
Взяв процесс по адресу, можно узнать, из какого места на диске он
был запущен (при запуске происходит отображение образа
скомпилированного exe-файла в память; ОС держит этот файл
(пока работает программа, его нельзя удалить), поэтому она точно
знает путь к этому образу).
 TCP, UDP

IP

Анализ стека вызовов

Грамотно настроенный сетевой экран с последними обновлениями способен

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

Если задать путь программы, то можно именно ей запретить посещать какой-

либо сервер, на который она отправляет некоторую информацию. Таким
образом, контролируя свои программы, можно запретить нежелательный исходящий
трафик. Это полезно в случае, если компьютер был заражен вирусом или была
установлена нежелательная шпионская программа. Грамотно настроенный сетевой
экран с последними обновлениями способен быстро заблокировать выход таких
программ в сеть, т.е. они будут работать на компьютере, но не смогут нанести
вред. Можно провести аналогию с заболеванием: болезнь еще не вылечена
(нежелательное ПО все еще на компьютере), но она никак себя не проявляет –
симптомов нет, болезнь навредить не может. Вредоносное ПО, заблокированное
сетевым экраном, считает, что узел не подключен к сети.
4. Существует возможность выбрать тип протокола, для которого будет выполняться анализ.

4. Можно указать, нужно ли применять правило ко всем локальным портам или только
к некоторым.
Через запятую можно указать множество портов, к которым будет применено
правило. Можно указать, на чьей стороне находятся эти порты. Если идет пакет, то будет
проанализировано, с какого порта он идет, – фактически, это правило на исходящий
трафик. Можно установить правило на входящий или исходящий трафик, в котором будет
анализироваться как информация отправителя, так и информация получателя (можно
указать конкретный порт получателя).
Кроме того, можно указать удаленный порт (remote port) – порт другого
удаленного узла.
5. Можно указать конкретные IP адреса – локальные или удаленные, один или
несколько.

– можно указывать IPv4 или IPv6 адреса;

– локальный адрес считается адресом получателя, если пакет идет к пользователю, и
адресом отправителя, если пакет идет от пользователя.
6. Можно выбрать домен, к которому применяется правило.

– можно выбрать локальный адрес и то, к какой сети правило применяется;

– можно управлять доступом через различные интерфейсы. Например, если есть Wi-Fi –
беспроводная связь и адаптер Ethernet, которыми можно отдельно управлять, потому что
у них разные IP-адреса.
– можно задать правило для определенного сетевого интерфейса.

Сетевой экран – машина для проверки правил: любые поступающие пакеты он

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

Хотя для UDP нет понятия соединения, в сетевых экранах оно всегда используется:
вводится виртуальное понятие соединения на уровне сетевого экрана.

При начале работы одна из сторон выступает в роли инициатора и отправляет

первый пакет (хотя стороны считаются равноправными, не существует понятия клиента и
сервера).

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

– если идет исходящий пакет, сетевой экран запоминает этот факт как установку
соединения и считает, что между компьютером пользователя (через определенный порт)
и другой стороной с определенным IP-адресом и портом могут беспрепятственно
передаваться данные в обоих направлениях;
– экран считает, что взаимодействие по UDP должно происходить постоянно.
Длительного бездействия быть не должно: если в течение некоторого промежутка
времени пакеты через соединение не передаются, то можно считать, что оно логически
разорвано.

Для работы сетевого экрана с UDP вводится понятие логического соединения.

Такое соединение разрывается при отсутствии пользовательской активности
в течение некоторого времени. Этот подход аналогичен применяемому при работе
NAT с UDP.
25. UDP hole punching («Проделывание дырок в UDP»)

25.1 Введение
Технология «UDP hole punching» («проделывание дырок в UDP») в настоящее
время является актуальной и популярной. Она нашла широкое применение по причине
распространения сетей, построенных по принципу «точка-точка».

«Точка-точка» – это принцип построения сетей, при котором центральный сервер

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

25.2 Принцип работы технологии «UDP hole punching»

Рассмотрим принцип работы программ обмена мгновенными сообщениями на
примере работы программы Skype.

Исходные данные:
1) сервер, имеющий глобальный уникальный IP-адрес;
2) узлы А и В, которые желают обмениваться между собой информацией. Предположим,
у этих узлов есть глобальные уникальные IP-адреса:

Узел IP-адрес
А [Link]
В [Link]

3) На каждом узле работает сетевой экран. Предположим, сетевой экран работает на

маршрутизаторе (на практике сетевой экран может работать на самом узле или на
маршрутизаторе);
4) Узлы А и В выбирают номера портов, которые будут участвовать в обмене данными
(могут быть выбраны случайно из некоторого диапазона).

Узел IP-адрес Порт для участия в обмене данными

А [Link] 2001
В [Link] 2020

Если на первоначальном этапе один узел попытается послать сообщение

другому узлу, то сообщение будет заблокировано.
Принцип организации взаимодействия:

Сервер, [Link], Порт 1024

A, Пароль В, Пароль
[Link] 2001 [Link] 2020

P Узлу В звонит узел А

UD

UD
А звонит В

P
Список активных контактов А:
В, С, Х. Список активных контактов В: А, С,
В – [Link], 2020 Т.
С – [Link], 2001 А – [Link], 2001
Х - ... С – [Link], 2001
Т - ...

Узел А, [Link], Порт 2001 Узел В, [Link], Порт 2020

1) Узел А посылает сообщение серверу:

Сетевой экран
Сервер
Узел

[Link], [Link],
порт 2001 порт 1024

Посылка сообщения может осуществляться с использованием UDP- или TCP-

протокола. Происходит авторизация пользователя А:
– сообщение от узла А серверу –сообщение вида «Я пользователь А с паролем *»;
– сервер узнает, какие IP-адрес и порт используются пользователем А (из
содержимого полученного пакета), и использует их для обмена сообщениями с клиентом
по UDP. Сообщения идут непрерывно;
2) Сетевой экран запоминает, что обратные сообщения разрешены (в сетевом экране как
бы проделывается «дырочка»);

3) Узел В выполняет действия, аналогичные действиям узла А;

4) После авторизации узлы А и В получают полный список своих контактов с указанием

соответствующих IP-адресов и портов.

5) Пусть узел А хочет позвонить узлу В.

Узел А сообщает серверу, что он звонит узлу В.

Узел А начинает звонить узлу В. В это же время сервер сообщает узлу В, что ему хочет
позвонить узел А.

Пакет узла А блокируется сетевым экраном узла В (стандартная настройка сетевого

экрана, которая не пропускает входящий сетевой трафик).

Узел В получает информацию о том, что узел А хочет ему позвонить, и начинает посылку
встречных пакетов (В -> А).

Образуется канал UDP («дырка» в сетевом экране, временное разрешающее правило), по

которому узлы А и В могут обмениваться сообщениями.

Таким образом, посылая встречные пакеты, узлы проделывают в своих сетевых экранах
дырки, через которые уходят их пакеты и приходят пакеты от других узлов.
25.3 Работа технологии при наличии NAT

Условие: программы обмена сообщениями находятся на узлах в локальной сети, где

используется NAT. За NAT находятся и узел А, и узел В.

Принцип организации взаимодействия:

Сервер, [Link], Порт 1024

[Link], Порт 1024

[Link], Порт 2001
A Звонит В A Звонит В

[Link], Порт 1024

A [Link], Порт 2001 [Link], Порт 30002

[Link], Порт 1024

[Link], Порт 1024
[Link], Порт 30001
NAT [Link], Порт 30001
NAT
[Link], Порт 30002

[Link] [Link], Порт 30002

[Link] B, Пароль
A, Пароль [Link], Порт 2020

Узел А, [Link], Порт 2001 Узел В, [Link], Порт 2020

1) Узел А посылает пакет серверу, чтобы пройти авторизацию.

Когда пакет отправляется, он проходит через NAT. NAT подменяет адрес отправителя,
устанавливая туда свой IP-адрес ([Link]), а также подменяет порт отправителя на
некоторый порт из пула портов (со значением, превышающим граничное). Пусть выбран
порт 30001.

Измененный пакет приходит на сервер. Сервер по заголовку пакета узнает, что он пришел
с узла [Link] и порта 30001, а по данным, вложенным в пакет, определяется
оригинальный узел-отправитель (узел А с адресом [Link], порт 2001);

2) Аналогично происходит авторизация узла В;

 Обмен пакетами происходит постоянно: клиент шлет серверу информацию,
сервер в ответ периодически шлет состояния.

Например, программа Skype отображает статус пользователей. Эта

функциональная возможность является следствием технической реализации:
через «дырки», образовавшиеся в сетевых экранах, сервер сообщает узлу
информацию об активных контактах.

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

Адрес Порт

[Link] 30002

[Link] 2020

4) Первый вариант: пакет от узла А идет на адрес [Link], порт 30002. Он проходит
через свой NAT и сетевой экран, проделывая «дырочки», однако сетевой экран узла
[Link] блокирует этот пакет.

В то же время узел В начинает посылать пакеты на адрес узла А (на 2 адреса:

[Link], порт 30001 и [Link], порт 20001). Пакеты проходят через сетевой экран и
NAT узла В. Когда пакет доходит до NAT узла A, у NAT уже имеется сохраненное
соответствие:

[Link], порт 30001 -> [Link], порт 2001,

поэтому становится возможной обратная трансляция адреса.

Получается, что пакет от узла В дойдет до узла А. То же самое произойдет со

следующим пакетом от А к В: он пройдет через сетевые экраны и попадет к узлу В.

Второй вариант: узлы А и В параллельно начинают посылать сообщения на

локальные адреса, которые не требуют трансляции. Если узлы находятся в одной
локальной сети, то посланный через локальную сеть пакет попадет к получателю
напрямую, минуя NAT, проделав «дырочки» в локальных сетевых экранах.

Очевидно, что более быстро выполняются процессы, которые не требуют

трансляции адресов, т.е. обмен данными по локальной сети произойдет быстрее, чем
через глобальную сеть. В таком случае узлы А и В откажутся от использовании адреса NAT
и будут использовать локальные адреса. Это позволяет обеспечить прямое
взаимодействие между узлами внутри локальной сети с максимальной скоростью.
 Если программа Skype работает в локальной сети, то внутри локальной сети
будет обеспечена высокая пропускная способность и безопасность, которая
является независимой от внешнего трафика.

Смысл подхода «UDP hole punching» состоит в том, чтобы разблокировать

сетевые экраны на любых уровнях: как локальные, так и глобальные сетевые
экраны.

Если установить правило на сетевом экране «Для программы Skype весь

исходящий UDP-трафик закрыть», то программа лишается возможности
отправки данных.

Узел А Узел В
26. Протокол IPv6

26.1 Общие сведения

IPv6 (англ. Internet Protocol version 6) — это новая версия протокола IP, призванная
решить проблемы, с которыми столкнулась предыдущая версия (IPv4) при её
использовании в интернете, за счёт использования адреса длиной 128 бит вместо 32.

Необходимость разработки протокола IPv6 была вызвана следующими предпосылками:

1. недостаточная разрядность IPv4;

2. отсутствие средств безопасности в IPv4;
3. большие накладные расходы на маршрутизаторах в IPv4.

26.2 Сравнение с IPv4

Из IPv6 были удалены функции, которые усложняли работу маршрутизаторов:

 Маршрутизаторы больше не разбивают пакет на части. Информация о

разбиении пакетов вынесена из основного заголовка в расширенные;
 Исчезла контрольная сумма. С учётом того, что канальные (Ethernet) и
транспортные (TCP и UDP) протоколы проверяют корректность пакета,
контрольная сумма на уровне IP является излишней.

Несмотря на огромный размер адреса IPv6, заголовок пакета удлинился всего лишь
вдвое: с 20 до 40 байт.

Улучшения IPv6 по сравнению с IPv4:

 В сверхскоростных сетях возможна поддержка огромных пакетов

(джамбограмм) — до 4 гигабайт;
 Time to Live переименовано в Hop Limit;
 Появились метки потоков и классы трафика;
 Появилось многоадресное вещание.
26.3 Структура адреса

При разработке была выбрана система, где на адрес отводится 16 байт (128 бит):

– принято написание в шестнадцатеричном виде;

– байты пишутся через двоеточия;
– повторяющиеся нули не пишутся.

Пример адреса:

2001:0db8:11a3:09d7:1f34:8a2e:07a0:765d

При использовании IPv6-адреса в URL его необходимо заключать в квадратные

скобки:

[Link]

Состоит адрес из следующих полей:

Биты Содержимое

0-2 Префикс формата FP (имеет значение 001)

3-15 Top Level Aggregation (TLA)

16-23 Зарезервировано

24-47 Next Level Aggregation (NLA)

48-63 Site Level Aggregation (SLA)

64-127 Идентификатор интерфейса узла

TLA, NLA, SLA - три уровня агрегации.

Суть уровней агрегации: эти значения выдаются организациям, которые, в свою

очередь, выдают их другим организациям.

 Top level закреплен за крупнейшими поставщиками сетевых узлов. Количество

организаций верхнего уровня ограничено этих значением (13 бит);
 Next level – провайдеры второго уровня;
 Site level – адреса конкретного абонента, например компании.
 Такая агрегация IP-узлов на три уровня сделана не только для удобства выдачи
IPv6, но и для снижения нагрузки на маршрутизатор за счет уменьшения размера таблиц
маршрутизации. Например, на верхнем уровне (TLA) может быть всего 8192 адреса,
соответственно таблица будет иметь малый размер. В четвертой версии же создавались
огромные словари адресов, но этот словарь состоял из полного диапазона адресов, а
обрабатывать его нужно при каждом запросе, что создавало огромную нагрузку.

Идентификатор узла является аппаратным адресом (для локальной сети – MAC-

адрес). В эти 64 бита вмещаются все аппаратные адреса, используемые на данный
момент. MAC-адреса, вписанные в IPv6, делают ненужным использование ARP.

В IPv6 существуют зарезервированные адреса, посмотреть полный список можно

здесь: [Link]

26.4 Заголовки

В заголовки IPv6 заложена расширяемость: в основном заголовке есть поле

следующего за пакетом заголовка.

Заголовки по содержанию упростились по сравнению с четвертой версией

протокола. Заголовок содержит:

 версию;
 приоритет (задает приоритет для дейтаграммы);
 метку потока (используется для мультиплексирования потоков);
 длину данных заголовка;
 следующий заголовок (код следующего заголовка);
 лимит переходов (Hop Limit, бывший TTL);
 исходный адрес;
 адрес назначения.


Минимальный размер заголовка - 40 байт.

Существуют заголовки:

 маршрутизации
 фрагментации
 аутентификации
 системы безопасности
 дополнительные данные для узла назначения
 пакет протокола верхнего уровня (всегда идет после всех заголовков)

Заголовок фрагментации (фрагментация в IPv6): если в протоколе IPv4 сразу

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

Поля заголовка фрагментации:

 i
Биты d Название Значение
Тип следующего расширенного заголовка или тип
0-7 e Next header
протокола, передаваемого в качестве полезных данных.
n
Зарезервировано, должно быть инициализировано
8-15 t Reserved
нулём.
i Смещение фрагмента в 64-битных блоках относительно
16-28 Fragment offset
f начала фрагментируемой части пакета.
Зарезервировано, должно быть инициализировано
29-30 i Res
нулём.
c
Будут ли ещё фрагменты. Если 0, то это последний
31 a M
фрагмент.
t
32-63 Identification Число, идентифицирующее оригинальный пакет.

Заголовок маршрутизации (и маршрутизация в целом):

«Разработчики просто молодцы, некоторые вещи, вот просто, вот сам

думаешь, как бы сделал, приходишь к идее, а в IPv6 так и сделано».
- Д.А. Сурков, 2013 :)

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

Биты Название Значение

Тип следующего расширенного заголовка или тип
0-7 Next header
протокола, передаваемого в качестве полезных данных.
Размер заголовка в 64-битных блоках, исключая первый
8-15 Hdr ext len
блок.
16-23 Routing type Подтип заголовка.

24-31 Segments left Количество ещё не посещенных узлов из списка.

Переменная Поле переменной длины, конкретный формат поля
длина Type-specific data
зависит от содержимого поля Routing Type.

Итого: в IPv6 введена агрегация адресов (три уровня), используется маршрутизация

от источника, отказ от не обязательных параметров заголовка, использование в
качестве номера узла его MAC-адреса.
27. VPN (Virtual Private Network)

VPN (Virtual Private Network, виртуальная частная сеть) – это технология, которая
решает задачу виртуализации и объединения физически различных сетей в одну
логическую сеть.

Такой подход позволяет получить доступ ИЗВНЕ к некоторой существующей сети.

логин/пароль
Global IP
шифр. соедиение
узел ЛВС
VPN VPN
клиент сервер

TCP

TCP
TCP

VPN-клиент устанавливает TCP соединение с VPN-сервером через глобальный IP-

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

Соединение между сервером и клиентом шифруется.

Когда клиент хочет отправить данные в некоторый VPN, он вкладывает в TCP-пакет

данные, которые передаются через сформированное соединение (VPN-клиент
перехватывает все пакеты стека протоколов TCP-IP). Другими словами, передается пакет
TCP, а сервер, в свою очередь, этот пакет «преобразует» и отправляет данные уже в
рамках своей сети. Обратная процедура является аналогичной прямой процедуре.

Когда TCP-пакет приходит, он извлекается и передается дальше, т.е. создается

впечатление того, что сообщение пришло из сети, хотя на самом деле это всего лишь
имитация.

VPN имитирует сетевой интерфейс.

Если раньше средства для создания VPN были дороги, то сейчас во многих
операционных системах имеются «внутренние» средства для организации
таких сетей.
28. Протокол HTTP

28.1 Введение
Протокол HTTP появился как инструмент в рамках технологии Веб, которая обеспечивает
доступ к контенту в глобальной сети Интернет.

Первоначально технология Веб развивалась как средство доступа к статическому

контенту. К статическому контексту можно отнести текст, картинки, гиперссылки.

Почему потребовался специальный протокол? Протокола TCP (транспортного уровня)

оказалось совершенно недостаточно для взаимодействия, т.к. при доступе к контенту
понятие порта отсутствует, но необходима инфраструктура именования ресурсов –
элементов контента.

IP

TCP

HTTP

Web content

Все протоколы, которые работают поверх TCP, – это протоколы текстового обмена. От
бинарного представления данных разработчики отказались, т.к. текстовое представление данных
решило проблему представления различных видов данных на различных компьютерах.

Во взаимодействии по http используется понятие транзакции: клиент подключается

к серверу -> клиент выдает запрос (request) -> сервер возвращает ответ (response) на
запрос.

28.2 Пример запроса (request)

GET / HTTP/1.1
Host: [Link]
User-Agent: Mozilla/5.0 Galeon/1.2.0 (X11; Linux i686; U;) Gecko/20020326
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,
text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,
text/css,*/*;q=0.1
Accept-Language: en
Accept-Encoding: gzip, deflate, compress;q=0.9
Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Keep-Alive: 300
Connection: keep-alive
28.3 Пример ответа (response)

HTTP/1.1 200 OK
Date: Tue, 21 May 2002 12:34:56 GMT
Server: Apache/1.3.22 (Unix) (Red-Hat/Linux) mod_python/2.7.8 Python/1.5.2
mod_ssl/2.8.5 OpenSSL/0.9.6b DAV/1.0.2 PHP/4.0.6 mod_perl/1.26
mod_throttle/3.1.2
Last-Modified: Thu, 01 Nov 2001 20:51:45 GMT
ETag: "df6b0-b4a-3be1b5e1"
Accept-Ranges: bytes
Content-Length: 2890
Connection: close
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

<html>
<head>
<title>Test Page for the Apache Web Server on Red Hat Linux</title>
</head>
<body bgcolor="#ffffff">
(...)
</body>
</html>

Визуализация http-ответа:
28.4 Пример транзакции
В качестве примера рассмотрим поиск в Google. Поисковый запрос: «HTTP».

Запрос:

GET /search?hl=en&q=HTTP&btnG=Google+Search HTTP/1.1

Host: [Link]
User-Agent: Mozilla/5.0 Galeon/1.2.0 (X11; Linux i686; U;) Gecko/20020326
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,
text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,
text/css,*/*;q=0.1
Accept-Language: en
Accept-Encoding: gzip, deflate, compress;q=0.9
Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Keep-Alive: 300
Connection: keep-alive

Ответ:

HTTP/1.1 200 OK
Server: GWS/2.0
Date: Tue, 21 May 2002 12:34:56 GMT
Transfer-Encoding: chunked
Content-Encoding: gzip
Content-Type: text/html
Cache-control: private
Set-Cookie:
PREF=ID=58c005a7065c0996:TM=1021283456:LM=1021283456:S=OLJcXi3RhSE;
domain=.[Link]; path=/; expires=Sun, 17-Jan-2038 19:14:07 GMT

(Web content compressed with gzip)

28.5 Структура запроса

HTTP request
Строка запроса

HTTP-заголовки

Содержимое запроса

28.5.1 Формат строки запроса

Пример строки запроса: GET / HTTP/1.1

Элемент Описание
GET Глагол, обозначающий тип действия.
/ Путь к элементу контента (ресурсу). В данном примере ресурс расположен в
корневом каталоге.
HTTP/1.1 Идентификатор версии протокола.

Существовали версии HTTP/0.9, HTTP/1.0, сейчас стандартно используется HTTP/1.1.

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

28.5.2 HTTP-заголовки (headers)

– заголовок – набор строк вида «Имя»:«значение», заканчивающихся переводом строки;
– заголовки от содержимого запроса отделяются пустым переводом строки.

Пример заголовка:

Host: [Link]
User-Agent: Mozilla/5.0 Galeon/1.2.0 (X11; Linux i686; U;) Gecko/20020326
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,
text/plain;q=0.8, video/x-mng,image/png,image/jpeg,image/gif;q=0.2,
text/css,*/*;q=0.1
Accept-Language: en
Accept-Encoding: gzip, deflate, compress;q=0.9
Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Keep-Alive: 300
Connection: keep-alive

28.3 Типы (методы) запросов

Методы запросов являются стандартными, но имеется возможность добавлять новые
методы (эти методы будет понимать только тот сервер, который их добавил).
 Методы

Обязательно поддерживаемые Необязательно поддерживаемые

серверами серверами

Для HTTP/1.1: GET, POST, PUT,

DELETE, HEAD, TRACE, OPTIONS,
CONNECT.

Основные методы, которые используются браузерами: GET, POST, PUT, DELETE, HEAD.

Метод Описание
GET Самый простой, популярный и известный метод. Запрашивается содержимое
некоторого ресурса. В запросе передается строка, идентифицирующая ресурс.
Результат – ответ, который включает в себя признак того, успешно или нет
завершился запрос, заголовки ответа и содержимое запрашиваемого ресурса
(например, html-текст).
HEAD Аналогичен методу GET, однако возвращает только метаинформацию
(например, заголовки), но не возвращает содержимое ресурса.
PUT Изменяет содержимого ресурса путем его установки. Операция, обратная по
смыслу GET.
POST Служит для отправки данных на сервер. Метод часто используется для
реализации редактируемых форм (введенные данные отправляются на сервер
для их обработки и показа нового содержимого).
Очень универсальный, т.к. позволяет реализовать любой тип взаимодействия,
включая вызов подпрограмм.
TRACE Используется для проверки работоспособности сервера.
OPTIONS Позволяет узнать функциональность, которую поддерживает сервер.
Возвращает список заголовков, в которых указаны значения – списки опций.
DELETE Позволяет удалить некоторый ресурс.
Дополнительные LOCK, COPY, MOVE и т.д.
методы
 Методы

Безопасные Небезопасные

Могут изменять состояние на

Не изменяют состояние на сервере.
сервере.

Основные: GET, HEAD. Например, метод POST

Cодержимое запросов этих методов

может кэшироваться.

Методы

Идемпотентные Не идемпотентные

Имеют одинаковый результат при При повторном выполнении дают

повторном выполнении. результат, отличный от предыдущего.

GET, HEAD, PUT, DELETE Например, метод POST

Например, если 2 раза удалить ресурс

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

Метод Post не является идемпотентным и безопасным, т.е. повторное выполнение для

одного и того же ресурса метода POST не приводит к одному и тому же результату
(например, можно выполнить бронирование билетов. Посылка метода POST 2 раза приведет к
бронированию 2х билетов). Поэтому для этого метода инфраструктура кэширования не
работает.

28.4 HTTP и масштабируемость

Инфраструктура HTTP очень хорошо продумана для того, чтобы обеспечить максимальную
масштабируемость системы.

Масштабируемость – это способность системы сохранять свои параметры по

времени ответа за счет увеличения количества элементов системы. Т.е. если один веб-
сервер обслуживал 200 клиентов со получением ответа в течение 1 секунды, то
масштабируемость – это способность системы за счет увеличения количества узлов
обеспечить сохранение параметров (ответ в течение секунды) при увеличивающемся
количестве пользователей.

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

HTTP является протоколом без состояния (stateless). Методы GET, HEAD и вся инфраструктура HTTP
работают, опираясь на это предположение. HTTP позволяет использовать инфраструктуру
кэширования: когда клиенты обращаются к некоторому адресу, за ним может стоять
балансировщик – физический узел, который случайным выбором по списку рассылает запросы
нескольким веб-серверам, которые являют собой кэши – они кэшируют контент, который сами
читают из некоторого главного сервера.

Веб-сервер «кэш»

Главный веб-сервер
Веб-сервер «кэш»
Кл
ие
нт

Клиент Веб-сервер «кэш»

Балансировщик

нт
Клие Веб-сервер «кэш»

HTTP рассчитан на наличие proxy – промежуточных звеньев, которые часто выполняют

кэширование данных. Методы GET and HEAD изначально рассчитаны на такое
кэширование, т.к. они не изменяют состояния.
28.5 Cookie
Протокол HTTP – протокол без состояния. Однако без состояния часто невозможно
обойтись. Например, если вы обращаетесь к веб-сайту и содержимое страницы должно быть
различным для разных пользователей (например, необходимо показать именно вашу
информацию на странице в социальной сети). Веб-сервера используют следующий подход: для
персонификации соединений используется понятие cookie, которые имеют формат
«имя:значение».

Cookie – это то состояние, которое должно сохраняться при взаимодействии между

клиентом и сервером и передаваться при их взаимодействии в рамках каждого запроса
(например, логин и пароль; токен безопасности). Сервер не должен хранить это состояние, оно
циркулирует между клиентом и сервером.

28.6 Синтаксис URL

Формат: <scheme> :// <user> : <password> @ <host> : <port> / <path> ; <params> ? <query>
# <frag>

Элемент Описание
<scheme> Протокол.
<path> Логический путь к ресурсу на веб-сервере.
<query> Строка запроса, параметризованный доступ к ресурсу (например, может быть
закодирован язык запрашиваемого ресурса).

#<frag> Подсказка, с какой позиции визуализировать.

Браузер разбирает URL, и в HTTP строка попадает в совершенно другом виде.

Стандартное ограничение на размер запроса – 2 КБ, некоторые веб-серверы могут

принимать запросы размером до 4 КБ.

28.7 HTTP-ответ
HTTP response
Строка статуса

HTTP-заголовки

Содержимое запроса (если

необходимо)
28.7.1 Строка статуса
Пример строки статуса: HTTP/1.1 200 OK

Элемент Описание
HTTP/1.1 Идентификатор версии протокола.
200 Трехзначное числовое значение статуса.
OK Текстовое сообщение – краткое описание кода статуса.

28.7.2 Коды статуса

Промежуток Описание
100..199 Информационные коды.
200..299 Коды успешного завершения.
300..399 Перенаправление (redirection). Признаки перенаправления на другой ресурс.
400..499 Ошибка клиента
500..599 Ошибка сервера

Примеры расшифровки возвращаемых кодов

Код статуса Описание

200 OK – «хорошо».
201 Create – «создано».
202 Accepted – «принято».
204 No content – «нет содержимого».
302 Found – «найдено».
400 Bad request –«плохой, неверный запрос».
401 Unauthorized – «неавторизован».
404 Not found – «не найдено».
405 Method not allowed – «метод не поддерживается».
500 Internal server error – «внутренняя ошибка сервера».
505 HTTP version is not supported – «версия HTTP не поддерживается».

28.7.3 Виды заголовков

Заголовки

Запроса Ответа Общие

Заголовки запроса:

1) Заголовок Accept.

Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,
text/plain;q=0.8, video/x-
mng,image/png,image/jpeg,image/gif;q=0.2,
text/css,*/*;q=0.1
*/* - все остальные форматы, кроме тех, что были описаны ранее.

Q – quality – коэффициент, с которым клиент желал бы получить контент. Чем выше

коэффициент, тем предпочтительнее получение контента в этом формате.
 2) Accept-Charset. Предоставляет возможность указать кодировку, в которой клиент желает
получить данные;
3) Accept-Encoding. Кодировка данных (например, использование алгоритма компрессии zip);
4) Accept-Language. Воспринимаемые языки;
5) Заголовки авторизации;
6) Cookie. Способ предоставить серверу возможность определить некоторое состояние,
специфичное для данного клиента. Состояние хранится у клиента;
7) Host. Позволяет указать, к какому хосту идет обращение (указать имя хоста);
8) If-Match. «Если совпадает»;
9) If-modified-since. «Если изменился с какого-то времени».
10) If-non-match. «Если не совпадает».

If-Match, If-modified-since, If-non-match позволяют наложить условия на показ

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

11) Range. Позволяет указать диапазон сайтов или фрагмент ресурса, который необходимо
прочитать, т.е. клиент получает возможность кусками за несколько запросов вычитывать
ресурс.

Range: 0-499
Range: bytes 0-499, 1000-1499

28.7.4 Заголовок set-cookie

Установка cookie. Строка, в которой через точку с запятой задаются параметры.

Set-Cookie: fname=chris; domain=.[Link]; path=/; expires=Tue, 21

May 2002 12:34:
56 GMT; secure

28.8 Виды соединений

HTTP имеет средство оптимизации трафика и ускорения взаимодействия клиента с

сервером за счет исключения избыточных действий.

С сервером по HTTP может устанавливаться:

1) отдельное соединение;
2) постоянное соединение («Keep alive connection»).
 Ресурсы сами могут ссылаться на другие ресурсы (картинки) – нужно загрузить все
ресурсы. Как можно это сделать?

1) установка параллельных соединений. При использовании этого варианта загрузка

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

2) постоянное соединение («Keep alive connection»). В версии HTTP 1.0 по умолчанию

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

3) Соединение в режиме трубы (системы массового обслуживания, СМО). В этом режиме

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

Т.е. запросы посылаются не в режиме запрос-ответ-запрос-ответ, а в режиме запрос-

запрос-запрос, ответ-ответ-ответ. Это позволяет более эффективно использовать трафик. Но этот
режим является сложным, т.к. порядок прихода ответов должен совпадать с порядком
отправления запросов (в ответе отсутствуют методы для идентификации запроса).

При использовании режимов постоянного соединения или СМО важно использование

таких заголовков, как content length и content type.

HTTP/1.1 200 OK
Date: Tue, 21 May 2002 12:34:56 GMT
Content-Type: text/html
Content-Length: 102

Content-length показывает размер содержимого в байтах и позволяет корректно читать

данные. Без этого размера использовать СМО или постоянное соединение невозможно, т.к.
необходимо знать правильное количество данных ответа.
Заголовки ответа content-type и content-length часто являются обязательными, если
используется постоянно открытое соединение. Такой подход может порождать дедлок браузера
не по вине браузера.

[Link]

Клиент
[Link]
[Link]

NAT Сервер

Очередь
[Link]
SYN

Клиент

ACK, а не SYN+ACK
 Когда клиенты, у которых есть только локальные IP-адреса, обращаются к серверу через
NAT по установленным и поддерживаемым постоянно соединениям, они получают один и тот же
глобальный IP-адрес (отличается только номер порта).

На сервере часто работает программное обеспечение, которое ограничивает количество

запросов, зная, что браузеры в большинстве своем работают в режиме keep alive (постоянно
открытое соединение). Например, может стоять ограничение на установку не более 2х
соединений с одного IP-адреса. Если приходит очередной запрос на установку соединения, то при
большой нагрузке на сервер может возникать следующая ситуация: запрос попадает в очередь,
отправляется подтверждение (флаг ACK), но Accept не делается. Получается, что каждое новое
соединение, которое приходит от клиента, устанавливается в очередь в надежде, что сейчас будет
закрыто предыдущее соединение.

29. Аутентификация и авторизация

29.1 Общие сведения

Аутентификация – это определение лица, которое запрашивает доступ и

подтверждение личности этого лица (проверка и удостоверение).
Авторизация – это предоставление прав на доступ к некоторому ресурсу на основе
аутентификации.
Указание имени пользователя и пароля – аутентификация.
Наделение пользователя, прошедшего аутентификацию, правами на доступ к
некоторому ресурсу – авторизация.

Для обеспечения авторизации вводится понятие защищаемой области или области

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

Аутентификация – это проверка личности пользователя, а авторизация –

предоставление ему прав.

29.2 Виды аутентификации

Аутентификация

Базовая На основе дайджеста

Эти виды аутентификации отличаются степенью безопасности.

29.2.1 Базовая аутентификация

Пользователь в открытом виде указывает имя и пароль, закодированные с помощью

base64 (имя и пароль через двоеточие представляются в этой кодировке).

1) GET / HTTP/1.1
Host: [Link]

2) HTTP/1.1 401 Unauthorized

WWW-Authenticate: Basic realm="HTTP Developer's Handbook"

3) GET / HTTP/1.1
Host: [Link]
Authorization: Basic bXluYW1lOm15cGFzcw==

Очевидно, что явное указание имени пользователя и пароля абсолютно

небезопасно.

29.2.2 Аутентификация на основе дайджеста

1) Вместо пароля указывается хэш-код, полученный с использованием алгоритма

MD5 –> этот хэш-код отправляется на сервер –> восстановить исходный пароль по хэш-
коду невозможно.

Увеличит ли такой способ передачи пароля защиту? Злоумышленник,

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

2) Вводится заголовок nonce, который добавляется к имени и паролю при расчете

хэш-кода по алгоритму MD5 («соль», примесь).
Объединение
P H(P, S)
Пароль || Хэширование

S
Соль

WWW-Authenticate: Digest realm="HTTP Developer's Handbook",

nonce="a4b8c8d7e0f6a7b2c3d2e4f5a4b7c5d2e7f"

Наличие nonce требует дополнительного взаимодействия с сервером. Чтобы не

было возможности записать трафик и воспроизвести его, «соль» является производной от
времени, которое знают клиент и сервер. Таким образом, сервер, проверяя значение
времени, постоянно изменяет «соль». Если попытаться записать трафик и воспроизвести
его, сервер заметит, что уже прошло некоторое время и не примет такую попытку
воспроизведения трафика.
Существует подход, позволяющий сделать nonce заранее вычисляемым по
некоторому алгоритму, чтобы он был известен как серверу, так и клиенту. Однако это
менее надежно и ставит в зависимость клиента от конкретного сервера.
Подход с аутентификацией дайджестом лишь частично решает проблему. Он
позволяет пользователю безопасно указать имя пользователя и пароль, чтобы
злоумышленник, используя прокси, не смог их узнать и воспроизвести для получения
доступа к серверу. Но это не лишает злоумышленника возможности получения доступа к
данным путем просмотра трафика. Если злоумышленник имеет прокси-сервер, который
располагается между клиентом и сервером (атака «Man in the Middle»), он имеет
возможность просматривать контент, с которым работает пользователь.
Достоинства подхода с аутентификацией дайджестом: сетевые экраны,
работающие на уровне протокола HTTP, могут просматривать трафик. Например, сетевые
экраны могут контролировать пределы указываемых значений, что лишает
злоумышленника возможности сформировать запросы с заголовками, которые приведут
к «падению» сервера из-за переполнения стека.

Атака «Man in the Middle» — термин в криптографии, обозначающий ситуацию,

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

29.3.1 Общие сведения

SSL (Secure Socket Layer) – специальный протокол, предназначенный для

обеспечения повышенного уровня безопасности. Это спецификация, позволяющая
использовать средства шифрации соединений на основе стойких алгоритмов.
Использование SSL c протоколом HTTP создает новое понятие и новый протокол – HTTPS.
HTTPS – это протокол HTTP, который работает по шифрованному соединению на
базе спецификации SSL.
Работа SSL основана на использовании сертификата x.509.

29.3.2 Сертификаты

Сертификат – это файл-хранилище симметричных и асимметричных ключей, который

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

В системе, использующей асимметричное шифрование, для шифрования

сообщений нужен открытый ключ, а для чтения сообщений – закрытый.

Для цифровой подписи ключи распределяются следующим образом: закрытым

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

Чтобы установить шифрованное соединение между двумя узлами, эти узлы

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

В сертификате указано:
1) кому выдан сертификат;
2) создатель сертификата;
3) кто подписал сертификат;
4) др. параметры сертификата.

Сертификат может быть подписан ограниченным числом организаций, которые

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

29.3.3 Алгоритм работы SSL

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

Наличие сертификата позволяет клиенту убедиться, что сервер, к которому он

подключается, - это действительно «правильный» сервер. Сервер злоумышленника
просто не сможет подписать данные своим сертификатом.
В подписи вписывается имя, подпись выполняется ключом корневого сертификата.
Если на сервере этого сертификата нет, то злонамеренный сайт, из-за взлома DNS
(например, может быть подменен IP, соответствующий адресу) начавший отвечать на
запросы клиентов, не сможет подписать нужным именем данные. Клиент проверит и
увидит, что автор цифровой подписи – не тот, кто должен быть. Таким образом, клиент
убеждается, что сервер – тот, который ему нужен, и стороны согласуют между собой
ключ, который будет использоваться для дальнейшей работы. Например, сервер
сообщает клиенту симметричный ключ, которым будет приводиться шифрация.

23.3.4 Программирование SSL

Существует определенный порядок выполнения подключения библиотеки SSL,
реализующей работу с сертификатами, к сокетам и посылки сертификатов. При
программировании веб-серверов с использованием HTTPS сложность обычно скрыта, т.к.
реализуется стандартным набором действий. Но эти действия также можно реализовать
самостоятельно на языках C#, C++, используя такие библиотеки, как OpenSSL.

Контейнеры для паролей и ключей определяются в стандарте x.509. Для них существуют
стандартные классы в .NET, Java, C++.
30. Передача данных по протоколу HTTP в режиме реального времени
Данная тема рассмотрена в презентации, которая находится в приложении к данному
конспекту («From Push Technology to the Real-Time [Link]»)

31. Основы RPC (Remote Procedure Call)

31.1 Общие сведения

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

Это попытка перенести взаимодействие между программой и библиотекой в

сетевую среду, где программа работает на одном узле, а библиотека – на другом.

31.2 Описание подхода

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

Идея разработчиков RPC: на основе интерфейса библиотеки автоматически

генерируются две подпрограммы-программы, называемые «Stub» и «Skeleton».

Прикладная
Библиотека
программа

Stub Skeleton

RPC RPC
runtime runtime

TCP/IP

«Stub» – это «заменитель библиотеки» для прикладной программы, который

обладает в точности таким же интерфейсом, как интерфейс библиотеки (с таким же
набором процедур и типов данных). Однако вместо реализации процедур, эти процедуры
обращаются к библиотеке «RPC runtime», для того чтобы по протоколу TCP/IP установить
соединение с сервером –> выполнить передачу по сети входных параметров -> дождаться
получения результатов –> получить результаты –> изъять из входного потока ->передать
программе. Это происходит с учетом того, кто библиотека как будто бы «физически»
находится на компьютере рядом с прикладной программой, в том же самом адресном
пространстве программы.

Передача данных из адресного пространства прикладной программы в адресное

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

Кроме программы «Stub», «заменителя библиотеки», автоматически генерируется

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

«Stub» и «Skeleton» генерируются автоматически по описанию интерфейса

библиотеки. Поэтому задача программиста – «прикрутить» программу к «переходнику»
(«Stub»), а «Skeleton» связать с исходной библиотекой.

Изначально технология RPC создавалась для языка C. Со временем она стала

поддерживаться в C++, «перекочевала» в другие языки. Однако, например, в C++
существовали заголовочные файлы и информация, расположенная в них, была
недостаточной для того, чтобы построить по ней заголовки (невозможно однозначно
определить, какие параметры являются входными, а какие – выходными).

char * str – это ссылка на буфер, в который данные надо вернуть, или это ссылка
на буфер входных данных? Если параметр является входным, то данные идут
от программы к библиотеке (от клиента к серверу), а если выходным – от сервера к
клиенту. Если параметр и входной, и выходной, он должен передаваться от клиента к
серверу и обратно.

Для решения описанной выше проблемы был придуман специальный язык,

называемый IDL (Interface Definition Language, язык описания интерфейсов).
IDL является C-подобным языком и предназначен исключительно для описания
интерфейсов. Указание метаинформации около параметров (например, [in] – входной
параметр, [out] – выходной параметр) позволяло проанализировать семантику данных,
чего не хватало в C/C++, и помогало сформировать необходимые заготовки. В
современных языках, таких как C# и Java, такая необходимость отсутствует, т.к. в этих
языках по интерфейсу можно определить, какие параметры являются входными, а какие –
выходными.
31.3 Технология CORBA
Появилась позднее RPC. По сути, CORBA – это технология RPC, но ориентированная
на объекто-ориентированные средства программирования.

31.4 Ошибки технологий CORBA и RPC

Технологии RPC и CORBA были концептуально ошибочны. Ошибки заключались в
следующем:

1) Наличие сети между двумя взаимодействующими узлами (разные компьютеры,

разные адресные пространства) нельзя скрывать за интерфейсами, поскольку это влияет
на сам интерфейс. Проектировать взаимодействие нужно с нуля, учитывая, что два
объекта находятся на разных узлах, а не в одном адресном пространстве;

2) RPC и CORBA не придавали значения возможности взаимодействовать с разными

программами (interoperability). Они исходили из того, что две программы, ранее
работавшие в одном адресном пространстве, теперь работают по отдельности. Но
прикладные задачи, как правило, требуют разрабатывать серверные приложения на
одном языке программирования, а приложения-клиенты – на другом языке. Например,
клиент может работать на Javascript в браузере или быть написанным на Java, сервер
может быть написан на C# и работать на платформе .NET. Т.к. средства программирования
могут быть совершенно разными, необходимо было стандартизировать формат обмена и
протокол обмена.

Технологии RPC/ CORBA постепенно отошли на второй план, пришло новое

решение – технология Web-служб.
32. SOA (Service-Oriented Architecture)

32.1 Общие сведения

Сервис-ориентированная архитектура (SOA, service-oriented architecture) — это

модульный подход к разработке программного обеспечения, который основан на
использовании распределённых, слабо связанных (loose coupling) заменяемых
компонентов, оснащённых стандартизированными интерфейсами для взаимодействия по
стандартизированным протоколам.
Программные комплексы, разработанные в соответствии с сервис-
ориентированной архитектурой, обычно реализуются как набор веб-служб, которые
взаимодействуют по протоколу SOAP, но существуют и другие реализации (например, на
базе CORBA, на основе REST).
Интерфейсы компонентов в сервис-ориентированной архитектуре инкапсулируют
детали реализации (ОС, платформу, язык программирования) от остальных компонентов,
обеспечивая комбинирование и многократное использование компонентов для
построения сложных распределённых программных комплексов, независимость от
используемых платформ и инструментов разработки, способствуя масштабируемости и
управляемости создаваемых систем.

Идея SOA – слабое связывание компонентов программы и внедрение

стандартизированных интерфейсов, что позволяет повысить повторное
использование компонентов.

32.2 Сервис и транспорт

SOA можно разделить на два больших понятия: сервис и транспорт.

Сервис – функция или определенная логика, или бизнес-логика, которая является
чётко определённой, автономной и не зависит от контекста или состояния других
сервисов. Например, сервис оформления кредита, который может быть автономным
приложением для обработки заявки на кредит. Другим примером может быть
метеорологическая служба, которая может быть использована для получения
информации о погоде. Любое приложение в сети может пользоваться услугами сервиса
погоды, чтобы получить прогноз.
Транспорт – это канал, соединяющий автономные распределенные сервисы между
собой. В случае веб-служб транспортом является передача SOAP через HTTP, однако
возможно использование и других технологий.
На рисунке ниже представлен типичный пример сервис-ориентированной архитектуры:
клиент посылает запрос на обслуживание; после принятия запроса, сервис услуг
отправляет сообщение клиенту; сервис может также может быть клиентом какого-то
другого сервиса.
 Запрос

Сервис Клиент
Ответ

Основные понятия SOA – сервис (некоторая независимая от состояния других

сервисов функциональность) и транспорт (способ коммуникации между
сервисом и клиентом).

32.3 Использование разных технологий

Архитектура не привязана к какой-то определённой технологии. Она может быть

реализована с использованием широкого спектра технологий, включая такие технологии
как REST, RPC, DCOM, CORBA или веб-сервисы.
Главное, что отличает SOA, – это использование независимых сервисов с чётко
определёнными интерфейсами, которые для выполнения своих задач могут быть
вызваны некоторым стандартным способом, при условии, что сервисы заранее ничего не
знают о приложении, которое их вызовет, а приложение не знает, каким образом сервисы
выполняют свою задачу.

SOA

Application Service
Service Service bus
frontend repository

Contract Implementation Interface

Business logic Data

Элементы сервис-ориентированной архитектуры

 SOA также может рассматриваться как стиль архитектуры информационных систем,
который позволяет создавать приложения, построенные путём комбинации слабо-
связанных и взаимодействующих сервисов. Эти сервисы взаимодействуют на основе
какого-либо строго определённого платформенно-независимого и языково-независимого
интерфейса (например, WSDL). Определение интерфейса скрывает языково-зависимую
реализацию сервиса.
Таким образом, системы, основанные на SOA, могут быть независимы от
технологий разработки и платформ (таких как Java, .NET и т. д.). Например, сервисы,
написанные на C#, работающие на платформах .NET и сервисы на Java, работающие на
платформах Java EE, могут быть с одинаковым успехом вызваны общим составным
приложением. Приложения, работающие на одних платформах, могут вызывать сервисы,
работающие на других платформах, что облегчает повторное использование
компонентов.
SOA может поддерживать интеграцию и консолидацию операций в составе
сложных систем, однако SOA не определяет и не предоставляет методологий или
фреймворков для документирования сервисов.
Языки высокого уровня, такие как BPEL, или спецификации, такие как WS-CDL и WS-
Coordination, расширяют концепцию сервиса, предоставляя метод оркестрации для
объединения мелких сервисов в более обширные бизнес-сервисы, которые, в свою
очередь, могут быть включены в состав технологических процессов и бизнес-процессов,
реализованных в виде составных приложений или порталов.

SOA – это архитектура, поэтому она не налагает на приложения никаких

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

33. Технология веб-сервисов (веб-служб)

33.1 Особенности

– при создании веб-служб были введены понятия протокола и формата данных;

– формат данных и протокол обмена были стандартизированы;
– в качестве протокола используется HTTP (теоретически может быть использован любой
другой протокол);
– формат данных – XML.

Выбор HTTP и XML обеспечил успех технологии веб-служб: благодаря HTTP они
могут проходить через все сетевые экраны, подключаться по принципу веб-
клиента к любым серверам (за которыми на самом деле стоят прикладные сервера,
выполняющие некоторые действия). Благодаря использованию XML любые программы
могут взаимодействовать друг с другом. Появился новый формат данных – SOAP.
33.2 Основные понятия

SOAP (Simple Object Access Protocol) – новый формат данных, XML определенного
стандарта, в котором имеются определенные теги, вкладываемые в HTTP.

WSDL (Web Service Definition Language) – XML формат, стандартизированный и

ориентированный на описание интерфейсов веб-служб.

Зачем появится WSDL? Веб-службы имеют некоторый интерфейс, через

который к ним можно обращаться, используя данные в формате SOAP.
Интерфейс должен иметь описание, т.е. необходима замена IDL. WSDL – замена IDL.

Разрешенные теги WSDL описаны в схеме для этого типа XML. Это позволяет,
подключиться к службе HTTP –> получить WSDL-схему с помощью запроса HTTP –>
сгенерировать прокси, через который будет выполняться запросы (для любого языка
программирования). Например, используя Java или C#, можно получить классы,
сгенерированные на основе WSDL. Интерфейсные модули могут быть сгенерированы для
любого языка программирования.

33.3 Принципы создания веб-службы. Применение WCF

I. Сервер и клиент разделяют контракт, а не интерфейс или бинарный

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

Существует инструментарий, способный перевести WSDL схему в код на

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

Пример оформления интерфейса веб-службы:

[ServiceContract(Name = "WeatherService",
Namespace = "[Link]
public interface IWeatherService
{
[OperationContract]
double GetTemperature(string location);

[OperationContract]
WeatherInfo GetWeatherInfo(string location);
}
 Представленный интерфейс – интерфейс службы погоды. Вызов GetTemperature
возвращает текущую температуру. Location – город, для которого необходимо узнать
температуру.

Интерфейс обязательно содержит атрибут ServiceContract – контракт вызовов.

Параметры представлены в таблице:

Параметр Описание
Name Имя веб-службы, с которым она будет публиковаться.
Namespace Пространство имен. Используется для исключения возможности
наложения имен. Уникальность обеспечивается за счет уникальности
адресов DNS.

Интерфейс может содержать методы, которые не являющиеся частью контракта.

При генерировании WDSL такие методы игнорируются.

II.
Только данные могут передаваться между службами и между клиентом и
службой. Интерфейс между службой и клиентом может оперировать только данными.
Программный код не должен передаваться между службой и клиентом.

В приведенном ранее примере есть метод GetWeatherInfo, который возвращает

структуру данных.

[DataContract]
public class WeatherInfo
{
public WeatherInfo()
{
}

[DataMember]
public double Temperature { get; set; }

[DataMember]
public double Humidity { get; set; }

[DataMember]
public double Pressure { get; set; }

public double GetTemperatureAsFahrenheit()

{
return Temperature * 9 / 5 + 32;
}
}

Сама структура помечена как DataContract (представляет собой часть контракта),

некоторые поля этой структуры помечаются как DataMember, т.е. они входят в контракт.
Следовательно, метод GetTemperatureAsFahrenheit не будет включен в контракт.
 После создания интерфейса необходимо создать класс, который его реализует.

[ServiceBehavior(InstanceContextMode = [Link],
ConcurrencyMode = [Link])]
public class WeatherService : IWeatherService
{
private string LastLocation;

public WeatherService()
{
[Link]("Создан экземпляр WeatherService");
}

public double GetTemperature(string location)

{
[Link]("Last location: {0}", LastLocation);
return +15;
}

public WeatherInfo GetWeatherInfo(string location)

{
[Link]("Last location: {0}", LastLocation);
var res = new WeatherInfo()
{
Temperature = 15, Humidity = 50, Pressure = 710,
};
return res;
}
}

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

Содержание файла [Link]:

<?xml version="1.0" encoding="utf-8" ?>

<configuration>
<[Link]>
<compilation debug="true" />
</[Link]>
<!-- When deploying the service library project, the content of the config
file must be added to the host's
[Link] file. [Link] does not support config files for
libraries. -->
<[Link]>
<services>
<service name="[Link]"

behaviorConfiguration="WcfServiceLibrary1.Service1Behavior">
<host>
<baseAddresses>
<add baseAddress =
"[Link]
e/" />
</baseAddresses>
</host>
 <!-- Service Endpoints -->
<!-- Unless fully qualified, address is relative to base address
supplied above -->
<endpoint address ="" binding="wsHttpBinding"
contract="[Link]">
<!--
Upon deployment, the following identity element should be
removed or replaced to reflect the
identity under which the deployed service runs. If removed,
WCF will infer an appropriate identity
automatically.
-->
<identity>
<dns value="localhost"/>
</identity>
</endpoint>
<!-- Metadata Endpoints -->
<!-- The Metadata Exchange endpoint is used by the service to
describe itself to clients. -->
<!-- This endpoint does not use a secure binding and should be
secured or removed before deployment -->
<endpoint address="mex" binding="mexHttpBinding"
contract="IMetadataExchange"/>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="WcfServiceLibrary1.Service1Behavior">
<!-- To avoid disclosing metadata information,
set the value below to false and remove the metadata endpoint above
before deployment -->
<serviceMetadata httpGetEnabled="True"/>
<!-- To receive exception details in faults for debugging purposes,
set the value below to true. Set to false before deployment
to avoid disclosing exception information -->
<serviceDebug includeExceptionDetailInFaults="False" />
</behavior>
</serviceBehaviors>
</behaviors>
</[Link]>
</configuration>

[Link] – стандартный файл конфигурации, которым может быть оснащен

проект решения Visual Studio. Файл содержит XML-конфигурацию прикладной программы
и включается в состав компилируемого пакета как метаданные, читается системой .NET
при загрузке программы. В случае с веб-службами создание ServiceHost обеспечивает
чтение всех параметров этого хоста из .config файла.

Описание содержимого файла конфигурации:

Объект Описание
[Link] Параметры конфигурации веб-служб.
services Cписок имеющихся служб (каждая из них описывается своим
тегом service).
serviceBehaviors Конфигурация поведения службы.
host Базовые адреса – адреса, которые прослушивает служба.
endpoint Точки доступа к службе.
 Сервисно-ориентированная архитектура и ее реализация в .NET позволяет
полностью отделить саму службу от привязки к точкам доступа. Запросы могут
приниматься одновременно по нескольким протоколам – и по TCP (в бинарном формате),
и по HTTP (в XML-формате), и по HTTPS. Разработка службы не зависит от этих протоколов.

Описание точки доступа:

<endpoint address ="" binding="wsHttpBinding"

contract="[Link]">

Точка доступа имеет адрес, по которому можно получить доступ. Пустой

адрес значит, что будет использован базовый адрес.

Точка доступа имеет binding – вид привязки. Вид привязки определяет используемый
транспортный протокол и формат данных. Например, HTTP + XML –> SOAP –>
wsHttpBinding.

Привязка Элемент конфигурации Описание

Привязка, которая подходит для

взаимодействия с веб-службами,
совместимыми с WS-Basic Profile,
например службами,
BasicHttpBinding <basicHttpBinding> основанными на веб-службах
[Link] Web. Эта привязка
использует HTTP как транспорт и
формат text/XML как кодирование
сообщений по умолчанию.
Безопасная привязка с
<wsHttpBinding> возможностью взаимодействия,
WSHttpBinding
которая подходит для
недуплексных контрактов службы.
Безопасная привязка с
возможностью взаимодействия,
которая подходит для дуплексных
WSDualHttpBinding <wsDualHttpBinding>
контрактов службы или
взаимодействия через
посредников SOAP.
Безопасная привязка с
возможностью взаимодействия,
WSFederationHttpBinding <wsFederationHttpBinding> которая поддерживает протокол
WS-Federation, позволяющий
организациям в федерации
эффективно проверять
 подлинность пользователей и
авторизовать их.
Привязка, предназначенная для
использования служб HTTP или
<netHttpBinding>
NetHttpBinding WebSocket и по умолчанию
использующая двоичное
кодирование.
Безопасная привязка,
предназначенная для
NetHttpsBinding использования служб HTTP или
<netHttpsBinding>
WebSocket и по умолчанию
использующая двоичное
кодирование.
Безопасная и оптимизированная
привязка, которая подходит для
<netTcpBinding>
NetTcpBinding обмена данными между
приложениями WCF на разных
компьютерах.
Безопасная, надежная и
оптимизированная привязка,
NetNamedPipeBinding
<netNamedPipeBinding> которая подходит для обмена
данными между приложениями
WCF на одном компьютере.
Поставленная в очередь привязка,
NetMsmqBinding <netMsmqBinding> которая подходит для обмена
данными между приложениями
WCF на разных компьютерах.
Привязка, которая обеспечивает
NetPeerTcpBinding <netPeerTcpBinding> безопасный обмен данными
между несколькими
компьютерами.
Привязка, которая подходит для
обмена данными между
MsmqIntegrationBinding <msmqIntegrationBinding> приложением WCF и
существующими приложениями
очереди сообщений (MSMQ) на
разных компьютерах.
Привязка, которая подходит для
обмена данными с веб-службами,
BasicHttpContextBinding <basicHttpContextBinding> совместимыми с WS-Basic Profile, и
позволяет использовать для
обмена контекстом файлы cookie
HTTP.
Безопасная и оптимизированная
привязка, которая подходит для
NetTcpContextBinding обмена данными между
<netTcpContextBinding>
приложениями WCF на разных
компьютерах и позволяет
использовать для обмена
 контекстом заголовки SOAP.
Привязка, используемая при
настройке конечных точек для веб-
WebHttpBinding
<webHttpBinding> служб WCF, предоставляемых
через HTTP-запросы, а не через
сообщения SOAP.
Безопасная привязка с
возможностью взаимодействия,
которая подходит для
WSHttpContextBinding <wsHttpContextBinding>
недуплексных контрактов служб и
позволяет использовать для
обмена контекстом заголовки
SOAP.
Привязка, используемая при
UdpBinding <udpBinding> отправке группы простых
сообщений большому количеству
клиентов одновременно.

Точка доступа с адресом “mex” (от Metadata Exchange) использует вид привязки
mexHttpBinding в сочетании с форматом передачи данных WSDL. Эта точка
доступа со специальным контрактом IMetadataExchange позволяет, обратившись к
службе с параметром mex, получить у веб-службы ее описание в формате WSDL. Сама
служба сгенерирует по своему контракту WSDL-описание. То есть веб-служба
позволяет клиенту после обращения за WSDL сгенерировать интерфейс обращения к
службе для того языка, на котором работает клиент (это не обязательно будет C#).

IV.
Автономность – важный принцип создания веб-службы. Службы должны быть
написаны в, исходя из предположения, что службы, от которых они зависят, могут быть
недоступны, при этом служба все равно должна продолжать работать.

33.4 Пример веб-службы с применением WCF: клиент

1) создать ссылку на сервис (service reference): выбрать пункт «Добавить ссылку на

службу…» контекстного меню обозревателя решений Visual Studio;
2) задать адрес WSDL схемы. После нажатия «Перейти» произойдет загрузка и служба
WeatherService, у которой есть интерфейс с двумя методами (GetTemperature и
GetWeatherInfo) будет найдена;
3) при нажатии кнопки «ОК» по схеме службы будет сгенерирован программный код
клиента. Сама ссылка появляется в папке “Service references”;
4) Для обновления ссылки на сервис (перечитать WSDL-сервиса и заново сгенерировать
программный код клиента) необходимо выбрать пункт «Обновить ссылку на сервис» в
контекстном меню созданной ссылки.
Сгенерированный класс WeatherServiceClient:

[[Link]()]
[[Link]("[Link]",
"[Link]")]
public partial class WeatherServiceClient :
[Link]<[Link]
ice>, [Link] {

public WeatherServiceClient() {
}

public WeatherServiceClient(string endpointConfigurationName) :

base(endpointConfigurationName) {
}

public WeatherServiceClient(string endpointConfigurationName, string

remoteAddress) :
base(endpointConfigurationName, remoteAddress) {
}

public WeatherServiceClient(string endpointConfigurationName,

[Link] remoteAddress) :
base(endpointConfigurationName, remoteAddress) {
}

public WeatherServiceClient([Link] binding,

[Link] remoteAddress) :
base(binding, remoteAddress) {
}

public double GetTemperature(string location) {

return [Link](location);
}

public [Link]
GetWeatherInfo(string location)
{
return [Link](location);
}
}

WeatherServiceClient – прокси на стороне клиента. Этот класс реализует интерфейс для

работы с созданной веб-службой.

static void Main(string[] args)

{
var client = new WeatherServiceClient(
new WSHttpBinding([Link], false),
new
EndpointAddress("[Link]://localhost:5555/Design_Time_Addresses/WcfServiceLib
rary1/WeatherService/"));
var t = [Link]("Minsk");
var w = [Link]("Minsk");
[Link]("Temperature: {0}, Humidity: {1}, Pressure: {2}",
[Link], [Link], [Link]);

var sw = [Link]();
var count = 1000;
for (int i = 0; i < count; i++)
var wh = [Link]("Minsk");
 [Link]("{0} calls of GetTemprature(\"Minsk\") took {1}",
count, [Link]);
[Link]("1 call of GetTemprature(\"Minsk\") takes {0} ms",
(double)[Link] / count);

[Link]();
client = new WeatherServiceClient(
new WSHttpBinding([Link]),
new
EndpointAddress("[Link]
y1/WeatherService/"));
t = [Link]("Minsk");
w = [Link]("Minsk");
[Link]("Temperature: {0}, Humidity: {1}, Pressure: {2}",
[Link], [Link], [Link]);

sw = [Link]();
for (int i = 0; i < count; i++)
var wh = [Link]("Minsk");
[Link]("{0} calls of GetTemprature(\"Minsk\") took {1}",
count, [Link]);
[Link]("1 call of GetTemprature(\"Minsk\") takes {0} ms",
(double)[Link] / count);

[Link]();
[Link]();
}
Представленная выше программа служит для проверки производительности: в
зависимости от конфигурации компьютера при расположении службы и клиента на одной
машине она показывает, что 1000 вызовов GetTemperature занимает около 7-8 секунд, то
есть один вызов метода занимает 0,007-0,008 секунды или 7-8 миллисекунд.

Результат работы программы показывает, что удаленные вызовы заметно

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

33.5 Пример веб-службы с применением WCF: атрибут ServiceBehavior

Рассмотрим, от чего зависит, как создаются экземпляры объекта WeatherService и в

каком режиме обслуживаются запросы. Управление этими параметрами осуществляется
декларативно с помощью параметров. Атрибут ServiceBehavior описывает режим
создания экземпляра (InstanceContextMode) и режим параллельного вызова
(ConcurrencyMode) экземпляра.

33.5.1 Режимы создания экземпляра (InstanceContextMode)

Режим Описание
Single Создается один экземпляр для всех клиентов, при этом он создается
только когда приходит первый вызов службы. Если вызовов нет, то и
объект экземпляра не создается.
PerCall Экземпляр создается на вызов каждого метода. При любом вызове не
просто объекта, а даже любого его метода, создается отдельный
экземпляр объекта. Позволяет не беспокоиться о синхронизации при
 режиме параллельного вызова Multiple.
PerSession Экземпляр объекта создается на одну сессию клиента. Когда клиент
создает объект WeatherServiceClient и делает первый вызов, создается
экземпляр объекта, т.е. когда клиент только создал объект, экземпляр
класса с функционалом службы на серверной стороне еще не создается.
WeatherService на стороне службы будет уничтожен, когда клиент
вызовет метод Close объекта WeatherServiceClient.

33.5.2 Режимы параллельного вызова(ConcurrencyMode)

Режим Описание
Single Все запросы обслуживаются одним потоком последовательно. Не возникает
проблемы синхронизации нескольких клиентов, вызывающих службу: они
образуют очередь, их запросы последовательно обрабатываются службой.
Multiple Режим параллельной обработки входящих запросов от всех клиентов с
помощью пула потоков. Все эти потоки для клиентов берутся из пула. Чтобы
не беспокоиться о синхронизации, можно использовать этот режим
совместно с режимом создания экземпляра PerCall.
Reentrant Предполагает вызов в одном потоке (аналог Single), но в этом режиме
допустимы рекурсивные вызовы. Пришедший рекурсивный запрос
обрабатывается тем же потоком и возвращается назад. Этот режим более
сложно устроен, т.к. требует сохранения контекста, чтобы понимать, когда
произошел рекурсивный вызов, и не ставить его в очередь. Поэтому этот
режим не используется по умолчанию.

Когда нужен режим Reentrant? Например, есть служба в режиме Single,

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

Клиент Single

Бесконечное
ожидание
33.6 Пример веб-службы с применением WCF: ручная конфигурация службы

Пример ручного конфигурирования службы:

static void Main()

{
var host = new ServiceHost(typeof(WeatherService));

var tcpBinding = new NetTcpBinding([Link], false);

[Link] = [Link];
[Link] = [Link];
[Link] = [Link];
[Link] = false;
[Link] =
[Link];
[Link]("[Link]", tcpBinding,
"[Link]://localhost:5555/Design_Time_Addresses/WcfServiceLibrary1/WeatherSer
vice/");
var wsHttpBinding = new WSHttpBinding([Link]);
[Link]("[Link]",
wsHttpBinding,
"[Link]
e/");

[Link]();
[Link]("Press ENTER to stop the service");
[Link]();
}

В примере создается служба с двумя точками доступа: одна точка доступа – по

протоколу HTTP через порт 8731, а вторая – по протоколу TCP в бинарном виде через порт
5555.

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

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

34 Веб-службы на основе REST

34.1 REST

REST (Representational State Transfer, «передача состояния представления» или «передача

репрезентативного состояния») — стиль построения архитектуры распределенного приложения.
Был описан и популяризован в 2000 году Роем Филдингом, одним из создателей протокола HTTP.
Самой известной системой, построенной в значительной степени по архитектуре REST, является
современная Всемирная паутина.
Данные в REST должны передаваться в виде небольшого количества стандартных
форматов (например, HTML, XML, JSON). Сетевой протокол (как и HTTP) должен поддерживать
кэширование, не должен зависеть от сетевого слоя, не должен сохранять информацию о
состоянии между парами «запрос-ответ». Утверждается, что такой подход обеспечивает
масштабируемость системы и позволяет ей эволюционировать с новыми требованиями.
34.2 Реализация собственного протокола взаимодействия клиента и службы

WCF предоставляет высокоуровневые средства, позволяющие выбрать тип привязки для

службы (протокол и формат передаваемых данных).

Используем IWeatherService интерфейс (был рассмотрен ранее) и реализуем возможность

приема параметров и выдачи результата в текстовом формате. Пусть результатом работы метода
будет XML.
Один из способов получить результат в виде XML – это определить необходимые
атрибуты: для класса – XmlRoot, для данных класса, которые необходимо преобразовать –
XmlAttribute или XmlElement (отличаются видом формируемых в XML сущностей).

[XmlRoot]
public class WeatherInfo
{
public WeatherInfo()
{
}

[XmlAttribute]
public double Temperature { get; set; }

[XmlAttribute]
public double Humidity { get; set; }

[XmlAttribute]
public double Pressure { get; set; }
}

33.2.1 Пример запроса

Ожидаемый службой запрос будет выглядеть следующим образом:

<?xml version="1.0" encoding="utf-8" ?>

<ServiceRequest>
<EntryPoint ClassName="WeatherService" MethodName="GetTemperature"/>
<Parameters>
<Parameter Value="Minsk"/>
</Parameters>
</ServiceRequest>

EntryPoint – точка доступа, которая содержит имя класса, вызываемый метод класса и
параметры метода.

34.2.2 Пример результата вызова

<?xml version="1.0" encoding="utf-8" ?>

<ServiceResponse>15</ServiceResponse>

34.2.3 Пример реализации службы

class Program
{
static Dictionary<string, Type> Services;
 static void Main(string[] args)
{
Services = new Dictionary<string, Type>();
Type type = typeof(WeatherService);
[Link]([Link], type);

IPAddress address = [Link]("[Link]");

int port = 8338;
TcpListener listener = new TcpListener(address, port);
[Link]();
try
{
while (true)
{
TcpClient client = [Link]();
try
{
ReceiveRequestAndSendResponse(client);
}
finally
{
[Link]();
}
}
}
finally
{
[Link]();
}
}

private static void ReceiveRequestAndSendResponse(TcpClient client)

{
NetworkStream stream = [Link]();
XElement request = [Link](stream);

XElement entryPoint = [Link]("./EntryPoint");

string className = [Link]("ClassName").Value;
string methodName = [Link]("MethodName").Value;
XElement parametersXml = [Link]("./Parameters");
string[] parameters = [Link]().Select(
x => [Link]([Link]("Value")).Value).ToArray();

Type serviceType;
if ([Link](className, out serviceType))
{
ConstructorInfo constructor = [Link](
new Type[0]);
object serviceInstance = [Link](null);
MethodInfo method = [Link](methodName);
if (method != null)
{
object result = [Link](
serviceInstance, parameters);
var response = new XElement("ServiceResponse", result);
[Link](stream);
[Link]([Link]);
}
}
}
}
 После записи вызывается Shutdown для окончания операции и закрытия потока, чтобы
клиент получил результат, прочитав признак конца файла.

Метод ReceiveRequestAndSendResponse вызывается в бесконечном цикле и обеспечивает

прием и обработку входящих запросов от пользователей. В данном примере используется режим
работы службы в один поток на каждого клиента, поскольку входящие запросы принимаются и
выполняются в цикле. На каждого клиента создается отдельный экземпляр объекта службы – на
каждый вызов конструируется отдельный объект.

34.2.4 Программа-клиент

static void Main(string[] args)

{
var request =
new XElement("ServiceRequest",
new XElement("EntryPoint",
new XAttribute("ClassName", "WeatherService"),
new XAttribute("MethodName", "GetTemperature")),
new XElement("Parameters",
new XElement("Parameter",
new XAttribute("Value", "Minsk"))));

IPAddress address = [Link]("[Link]");

int port = 8338;
TcpClient client = new TcpClient();
[Link](address, port);

NetworkStream stream = [Link]();

[Link](stream);
[Link]([Link]);
XElement response = [Link](stream);
[Link]();
[Link]();

[Link]("Результат вызова [Link] = {0}",

[Link]);
[Link]();
}

Рассмотренный пример показывает в миниатюре принцип работы технологии WCF. По

похожему принципу работает и WCF, и веб-службы вообще.

34.3 Веб-службы на основе интерфейса REST (Representational State Transfer)

34.3.1 История возникновения. Общие сведения

Развитие технологий HTTP и Web привело к тому, что сам способ адресации по HTTP стало
возможно использовать как некоторый стандартный интерфейс для работы с объектами.
Например, методы HTTP – это, фактически, методы получения значения некоторого объекта (GET,
POST), его изменения (PUT), выполнения над ним действий, удаления (метод DELETE). Этот факт
поспособствовал появлению принципа взаимодействия через HTTP с любыми объектами и
интерпретации сервера как службы хранения и управления объектами.
34.3.2 Отличия веб-служб на основе REST и SOAP

1) в REST есть некоторый ресурс, к которому можно применять стандартные операции. Путь в
строке HTTP – путь к самому ресурсу и его идентификация. В веб-службах SOAP путь дает доступ к
самой веб-службе, ее контракту;
2) В REST используется не SOAP (не XML), а HTTP;
3) SOAP полностью базируется на методе POST, который является небезопасным и не
идемпотентным, HTTP REST основан на использовании всей инфраструктуры HTTP с возможностью
кэширования и выполнения идемпотентных кэшируемых запросов, поэтому более безопасных
GET. REST позволяет использовать заголовки управления HTTP – if-match, if-none-match,
управление кэшированием.

Если HTTP REST служба возвращает данные, которые редко меняются, то они могут
кэшироваться инфраструктурой HTTP и программисту о кэшировании заботиться не
нужно. Веб-сервера с такими службами сами будут кэшировать страницы, и для следующих
запросов клиентов в случае, если не было превышено время кэширования, будет быстро
выдаваться страницы из кэша. Это то, чего нет при запросе POST в SOAP. Ради этой
возможности HTTP REST, собственно, и создавался.

Клиент

URL HTML, XML, JSON

Кэш

4) В REST стоит задача непосредственно указания значений передаваемых параметров в строке

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

Самое главное отличие REST и SOAP: если SOAP полностью базируется на методе POST,
который является небезопасным и не идемпотентным, то HTTP REST основан на
использовании всей инфраструктуры HTTP с возможностью кэширования и выполнения
идемпотентных кэшируемых запросов, поэтому более безопасных GET.

34.3.3 Пример REST веб-службы

Для управления отображением строки URL в параметры методов есть два

основных атрибута: WebGet и WebInvoke. WebInvoke успешно заменяет WebGet.

[ServiceContract(Name = "WeatherService",
Namespace = "[Link]
public interface IWeatherService
{
[WebGet(UriTemplate = "temperature/get?loc={location}")]
[OperationContract]
double GetTemperature(string location);

[WebInvoke(Method = "GET",
UriTemplate = "weather/get?loc={location}",
ResponseFormat = [Link])]
[OperationContract]
WeatherInfo GetWeatherInfo(string location);

[WebInvoke(Method = "GET",
UriTemplate = "weather2/get?loc={location}&type={resultType}")]
[OperationContract]
Stream GetWeatherInfo2(string location, string resultType);

[WebInvoke(Method = "GET",
UriTemplate = "weather/feed")]
[OperationContract]
[ServiceKnownType(typeof(Atom10FeedFormatter))]
SyndicationFeedFormatter GetWeatherInfoFeed();
}

WebInvoke имеет параметр Method – это имя метода HTTP. Можно указать POST, PUT,
READ, GET и другие методы. Это тот метод HTTP, который использует клиент.

WebGet отличается тем, что в нем сразу предопределен метод – GET. Для него указывается
строка шаблона адреса – UriTemplate. Здесь указываются имена параметров. В шаблоне
указывается имя (в примере это temperature/), имя метода – get, далее, после знака вопроса, идут
параметры запроса.

UriTemplate = "temperature/get?loc={location}" В имени параметра используется loc, а не

location, потому что в HTTP запросах строка ограничена по размеру, поэтому принято
сокращать имена параметров. Сокращение позволяет помещать больше параметров.
В фигурных скобках указывается имя передаваемого параметра. Это имя должно совпадать с
именем параметра метода, к которому применяется атрибут. В приведенном примере параметр в
атрибуте WebGet {location} будет ассоциирован с соответствующим параметром метода
GetTemperature, string location.

Пусть был вызван GetTemperature:

[Link]

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

public class WeatherService : IWeatherService

{
private string LastLocation;

public double GetTemperature(string location)

{
[Link]("Last location: {0}", LastLocation);
LastLocation = location;
if ([Link](location, "Minsk", true) == 0)
return +15;
else if ([Link](location, "Vitebsk", true) == 0)
return +13;
else
 return [Link];
}

public WeatherInfo GetWeatherInfo(string location)

{
[Link]("Last location: {0}", LastLocation);
LastLocation = location;
if ([Link](location, "Minsk", true) == 0)
{
var res = new WeatherInfo()
{
Temperature = 15,
Humidity = 50,
Pressure = 760,
};
return res;
}
else if ([Link](location, "Vitebsk", true) == 0)
{
var res = new WeatherInfo()
{
Temperature = 13,
Humidity = 48,
Pressure = 750,
};
return res;
}
else
return null;
}

<...>
}

GetTemperature проверяет пришедшее значение и в зависимости от него

возвращает температуру. Рассмотрим, в каком виде клиент получит ответ.

static void Main()

{
var host = new WebServiceHost(
typeof(WeatherService),
new Uri("[Link]
[Link]();
[Link]("Press ENTER to stop the service");
[Link]();
}

Для REST-служб нужно использовать не ServiceHost, а WebServiceHost. WebServiceHost

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

В параметрах конструктора указывается тип данных службы и URL, на котором разместится

служба. Драйвер HTTP обеспечивает возможность прослушивания на одном и том же порту (80й в
примере) запросов разными программами – несколько программ могут слушать запрос. Для этого
внутри HTTP реализована концепция мультиплексирования запросов в зависимости от строки
адреса. Эта же концепция использовалась в примере с ручным конфигурированием SOAP веб-
службы.
Фактически здесь происходит регистрация на 80м порту указанного URL, указание которого
в строке обеспечит дальнейшую маршрутизацию запросов HTTP программе, которая
зарегистрировала свой метод прослушивания входящих запросов. В этом ключевое отличие HTTP
от TCP. В TCP, который предоставляется ОС, такой возможности нет, т.к. в нем никак не оговорено
содержимое запроса. Единственная точка подключения при доступе по TCP – IP адрес и номер
порта. В HTTP всегда, кроме этих данных, после установки соединения происходит передача
запроса с заголовками, где обязательно есть заголовок запроса, в котором указывается метод и
URL. Он и используется для маршрутизации и мультиплексирования соединения.

Метод Main обязательно должен быть запущен с правами администратора, иначе

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

34.3.4 Результат выполнения запроса

После запуска метода Main можно открыть браузер и выполнить запрос к методу:
[Link] Результат – XML:

<?xml version="1.0"?>
<double xmlns="[Link]
15
</double>

В IWeatherService также есть метод GetWeatherInfo:

[WebInvoke(Method = "GET",
UriTemplate = "weather/get?loc={location}",
ResponseFormat = [Link])]
[OperationContract]
WeatherInfo GetWeatherInfo(string location);

Этот метод возвращает объект WeatherInfo. Объект WeatherInfo будет сериализован в XML.

[XmlRoot]
[DataContract]
public class WeatherInfo
{
public WeatherInfo()
{
}

[XmlAttribute]
[DataMember]
public double Temperature { get; set; }

[XmlAttribute]
[DataMember]
public double Humidity { get; set; }

[XmlAttribute]
[DataMember]
public double Pressure { get; set; }
}

Результат вызова метода GetWeatherInfo:

[Link]

<?xml version="1.0"?>
<WeatherInfo
xmlns="[Link]
xmlns:i="[Link]
<Humidity>50</Humidity>
<Pressure>760</Pressure>
<Temperature>15</Temperature>
</WeatherInfo>

Стандартное преобразование предполагает, что свойства превращаются в XML

элементы, несмотря на то, что они помечены как XmlAttribute.

Возникает вопрос: можно ли изменить ответ на свой XML? Это легко реализуемо –
выводом можно точно и гибко управлять. Кроме метода GetWeatherInfo, в интерфейсе определен
еще один метод – GetWeatherInfo2.

[WebInvoke(Method = "GET",
UriTemplate = "weather2/get?loc={location}&type={resultType}")]
[OperationContract]
Stream GetWeatherInfo2(string location, string resultType);

Параметры метода GetWeatherInfo2: location (loc), resultType (указывает, в каком

формате нужно возвращать результат). Результат возвращается в виде типа данных Stream. Если
результат имеет такой тип данных, содержимое этого потока будет возвращено клиенту как есть.
Если в поток (HTTP Response) был записан XML, клиент получит XML, если – HTML, то клиент
получит HTML и так далее.

[ServiceBehavior(
InstanceContextMode = [Link],
ConcurrencyMode = [Link])]
public class WeatherService : IWeatherService
{
private string LastLocation;

<...>

public Stream GetWeatherInfo2(string location, string resultType)

{
switch (resultType)
{
case "html":
return GetWeatherInfoAsHtml(location);
case "text":
return GetWeatherInfoAsText(location);
case "json":
return GetWeatherInfoAsJson(location);
case "xml":
default:
return GetWeatherInfoAsCustomXml(location);
}
}
}

private Stream GetWeatherInfoAsCustomXml(string location)

{
WeatherInfo res = GetWeatherInfo(location);
if (res != null)
{
 var stream = new MemoryStream();
var t = new XmlSerializer(typeof(WeatherInfo));
[Link](stream, res);
[Link](0, [Link]);
return stream;
}
else
return null;
}

Ни в коем случае нельзя использовать оператор using, т.к. нельзя вызывать метод
Dispose для потока. Dispose освободит и закроет поток, а здесь необходимо, чтобы он
оставался открытым. Его закрытие выполнит сама WCF после чтения и передачи
содержимого.

Форматирование будет применяться уже с учетом XmlAttribute, а не по DataContract.

Результат выполнения запроса:

[Link] /weather2/get?loc=Minsk&type=xml

<?xml version="1.0"?>
<WeatherInfo Pressure="760" Humidity="50" Temperature="15"
xmlns:xsd="[Link]
xmlns:xsi="[Link]

Результаты работы других методов в виде таблицы:

Строка запроса Результат

[Link] Temperature: 15
/WeatherService/weather2/g Humidity: 50
et?loc=Minsk&type=text Pressure: 760

[Link] <html><body>
/WeatherService/weather2/g Temperature: 15
et?loc=Minsk&type=html Humidity: 50
Pressure: 760
</body></html>
[Link] {"Humidity":50,"Pressure":760,"Temperature":15}
/WeatherService/weather2/g
et?loc=Minsk&type=json JSON – JavaScript Simple Object Notation. Результат приходит в виде
файла “get” – JSON интерпретируется самим браузером. Код
метода GetWeatherInfoAsJson приведен ниже.

private Stream GetWeatherInfoAsJson(string location)

{
WeatherInfo res = GetWeatherInfo(location);
if (res != null)
{
var stream = new MemoryStream();
DataContractJsonSerializer s =
new DataContractJsonSerializer(typeof(WeatherInfo));
[Link](stream, res);
[Link](0, [Link]);
[Link] =
 "application/json; charset=utf-8";
return stream;
}
else
return null;
}

DataContractJsonSerializer используется, чтобы вывести данные в формате JSON. Этот

объект создается на основе типа данных WeatherInfo и обеспечивает запись в поток
объекта, точнее, его свойств. Для использования с DataContractJsonSerializer класс должен
иметь атрибут DataContract и размеченные атрибутом DataMember поля.

WebOperationContext используется для хранения контекста операций. В нем есть

статические методы и статические данные. Свойство Current – объект, который хранит сам
контекст. Он нужен только на время работы потока по обработке запроса. Хранятся эти данные в
памяти потока. OutgoingResponse – исходящий ответ, кроме него есть IncomingRequest (входящий
запрос). Это объекты, где записаны HTTP заголовки. Некоторые из этих заголовков – стандартные,
они присутствуют в OutgoingResponse или IncomingRequest как свойства. Примеры таких
заголовков – Content-Length и Content-Type. Здесть такой стандартный заголовок, Content-Type,
для OutgoingResponse устанавливается в "application/json; charset=utf-8". Это формат данных с
указанием кодовой таблицы для их интерпретации, UTF-8. Заголовки IncomingRequest можно
менять аналогичным способом.

Кроме IncomingRequest и OutgoingResponse у Current есть свойства OutgoingRequest и

IncomingResponse. IncomingRequest – свойство, доступное для чтения серверу.
OutgoingResponse – тоже свойство сервера, помогающее ему формировать ответ. С
OutgoingRequest и IncomingResponse, в свою очередь, работает клиент: в OutgoingRequest он
записывает заголовки для своего исходящего запроса, а IncomingResponse – это пришедший
ему ответ сервера. Это сделано, чтобы служба не могла, получив входящий запрос, сделать
для себя же исходящий запрос. Аналогичная ситуация предотвращена и для ответов.

34.4 RSS

34.4.1 Общие сведения

Современный подход к реализации REST интерфейсов в службах предполагает

использование такого формата, как RSS, точнее его реализации Atom 1.0.

RSS – это специальный стандартизированный подход для получения заголовков новостей.

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

Например, стоит задача: имеется сайт, содержащий новости.

У сайта есть разделы: спорт, политика, культура, происшествия,
финансы. Существуют автоматические агрегаторы новостей: если
пользователя интересует раздел финансов, он следит за ним и мало
интересуется другими, агрегатор позволяет пользователю видеть не
весь список новостей, а только последние (изменившиеся и
появившиеся с последнего посещения) новости по интересующим
разделам. Кроме того, RSS позволяет не просто получать последние новости, а собирать их из
разных источников и формировать тематическую подборку.
 Многие сайты имеют возможность публикации метаинформации о самих себе через RSS
feeds (фиды). Часто сайты имеют значок RSS – это ссылка на XML, которая периодически
обновляется. В этом XML помечены все элементы, которые имеются на сайте. Этот подход можно
расширить любые объекты – предоставлять их список типов и подтипов, операции над ними,
интерфейсы и т.д. То есть метаинформацию RSS можно использовать для описания самой службы.
Главный недостаток HTTP REST – отсутствие полной информации о возможностей REST
службы (в отличие от SOAP, предоставляющего свою схему). RSS – это способ описания
возможностей REST-службы.

RSS, по сути, в некоторой степени заменяет WSDL. RSS описывает типы данных,
операции, ресурсы, объекты службы, и RSS можно применять при работе с самими
объектами. RSS, в отличие от JSON, предоставляет не только данные, но и метаинформацию.

34.4.2 Пример реализации RSS

Пусть служба WeatherService (была рассмотрена ранее) несет информацию о погоде по

некоторым городам, их количество конечно. Если информация о погоде какое-то время не
изменялась, в RSS-документе никаких обновлений не будет, а если изменялась – будут помечены
обновления. Каждый элемент в RSS помечается датой и временем изменения, поэтому, если
нужно обеспечить контроль за информацией о погоде, удобно сделать это в RSS, и все клиенты
будут читать RSS c информацией с пометкой, когда она поменялась. Это позволит, например,
отследить тенденции, например, изменения температуры: можно собрать и визуализировать
информацию, когда и насколько менялась температура.
Браузер тоже умеет интерпретировать RSS: он сразу в виде HTML показывает RSS – что
поменялось на странице с предыдущего визита. Все отображается уже в удобном для человека
виде (не XML. Человеку достаточно тяжело читать XML, хотя он и создавался для возможности
чтения и машиной, и человеком).

Есть две основных версии RSS – RSS 2.0 и Atom 1.0. Оба формата собирают обновленные
новости и метаинформацию с сайтов, но за ними стояли две противоборствующие
группы сторонников каждого формата. Поэтому осталось два основных стандарт: Atom 1.0,
который считается более удобным для HTTP REST, и RSS 2.0 – для новостных сайтов. Отличия
форматов проявляются в названиях тегов и в стандартном их наборе, но по возможностям
оба формата приблизительно равны.

Стандартом для веб-служб REST считается возвращать данные в формате Atom 1.0.
Библиотека WCF имеет средства, значительно облегчающие эту задачу.

public SyndicationFeedFormatter GetWeatherInfoFeed()

{
string[] locations = { "Minsk", "Vitebsk" };
//WhetherInfo res = GetWhetherInfo(location);
var feedData = new SyndicationFeed("WeatherInfo",
"Weather information for the given location",
new Uri("[Link]
List<SyndicationItem> items = new List<SyndicationItem>();
foreach (string location in locations)
{
SyndicationItem item = new SyndicationItem(location,
[Link]("{0} temperature: {1}",
location, GetTemperature(location)),
new Uri("[Link]
+ location), "ItemID", [Link]);
[Link](item);
}
 [Link] = items;
Atom10FeedFormatter feed = new Atom10FeedFormatter(feedData);
return feed;
}

Для создания RSS существует тип данных, который называется SyndicationFeedFormatter.

Это объект для форматирования данных в формате RSS. Если метод возвращает данные в этом
формате, WCF умеет использовать этот объект, чтобы вернуть не его свойства, а его содержимое,
то, что он возвращает в виде потока – SyndicationFeedFormatter умеет возвращать потока и WCF об
этом знает. Ситуация аналогична с примерами, где методы службы возвращали объекты типа
Stream: WCF также выводила не свойства самих объектов (открыт или закрыт, позиция и другие), а
их содержимое.
Как работает GetWeatherInfoFeed? Создается объект feedData класса SyndicationFeed. Для
него создается список элементов класса SyndicationItem. feedData и есть источник данных для
синдикации – для создания объекта RSS. В цикле создаются объекты класса SyndicationItem,
накапливаются в массиве созданных объектов. Для них задаются различные свойства, одно из
которых – URL для получения значений.
Мы формируем список ссылок и присваиваем его свойству Items ([Link] = items)
класса SyndicationFeed. После этого создается Atom10FeedFormatter на базе полученного объекта
SyndicationFeed. feedData – собственно данные RSS, так же, как и XML, в разобраном виде,
содержат просто данные определенного формата. Это еще не XML. А вот Atom10FeedFormatter –
это форматированный XML в формате Atom 1.0. Объект Atom10FeedFormatter с вложенным внутрь
SyndicationFeed обрабатывается WCF. WCF вызывает сериализацию объекта в поток. Это будет
XML документ, соответствующий стандарту Atom 1.0.
Чем хорош RSS? Он может содержать ссылки, которые может показывать браузер. Если
этот RSS отобразить на экране, он будет отформатирован и покажет ссылки. Можно приспособить
веб-службу для показа результата прямо в браузере. Рассмотрим результат вызова описанного
метода ([Link]
Так выглядит результат при просмотре в браузере Internet Explorer. Эту страницу сформатировал
сам браузер. Имена городов и зеленые стрелки работают как ссылки (пример ссылки – в нижней
части рисунка). Это ссылки, указанные в SyndicationFeed. Код ответа службы представлен ниже.

<feed xmlns="[Link]
<title type="text">
WeatherInfo
</title>
<subtitle type="text">
Weather information for the given location
</subtitle>
<id>
uuid:b71cda32-74cb-495f-bc38-21ed9f5bb22e;id=1
</id>
<updated>
2013-12-22T16:19:57Z
</updated>
<link rel="alternate" href="[Link]
<entry>
<id>
ItemID
</id>
<title type="text">
Minsk
</title>
<updated>
2013-12-22T19:19:57+03:00
</updated>
<link rel="alternate"
href="[Link]
<content type="text">
Minsk temperature: 15
</content>
</entry>
<entry>
<id>
ItemID
</id>
<title type="text">
Vitebsk
</title>
<updated>
2013-12-22T19:19:57+03:00
</updated>
<link rel="alternate"
href="[Link]
<content type="text">
Vitebsk temperature: 13
</content>
</entry>
</feed>

Наиболее полное представление о той или иной версии RSS можно получить, изучив
спецификацию.
35. Облачные вычисления

35.1 История возникновения технологии

До возникновения понятия облачных вычислений в больших организациях имелись

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

Например, есть некоторая большая компания, занимающаяся созданием корпусов для

судов и самолетов. В целом, эти направления мало связаны, администрирование их серверов
происходит по-разному. Значит, когда развертывается IT-инфраструктура, веб-службы, связанные
с закупками и продажами, то каждому подразделению необходимо совершать закупки серверов с
запасом (на случай увеличения количества заказчиков). Однако эти 2 подразделения с точки
зрения IT-инфраструктуры можно объединить, создать один общий отдел. Все сервера будут
расположены в одном датацентре. Такие изменения приведут к существенной экономии.

Если это дало выгоду одному предприятию, то вполне логично, что другие предприятия,
объединившись таким образом, также получили бы выгоду. Однако для успешного объединения
необходимы организации, специализирующиеся на создании, развертывании и предоставлении
заказчикам в пользование инфраструктур. Так появились хостинговые компании, которые
предоставляли возможность хостинга – места, где можно было бы расположить веб-сайт. Их
проблема заключалась в том, что они предоставляли сервер, сконфигурированный под
конкретную платформу.

Основные неудобства такого подхода:

1) ограничения пользователей в возможностях (из-за настройки сервера под конкретную
платформу. Например, Windows сервер с установленным IIS либо Red Hat Linux с nginx.);

2) каждому предприятию, выполняющему хостинг, выделялась в пользование физическая

машина, что делало цикл «развертки» более долгим, увеличивало стоимость аренды
оборудования.

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

Чтобы была возможность запускать сразу несколько ОС, нужна специальная поддержка
со стороны оборудования.

Система виртуальных машин существовала еще в 70е годы, но необходимые

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

1) Можно создать датацентр, который будет состоять из дорогих и мощных компьютеров

(многопроцессорных). На них установить операционную систему Supervisor и запускать под ее
управлением клиентские операционные системы. Это позволяет масштабировать операционные
системы, то есть поддерживать на одном многопроцессорном компьютере одновременную
работу нескольких систем;

2) Виртуальный узел легко перемещать с одного физического узла на другой. Если выполняются
backup-копии (snapshot’ы, т.е. снимок состояния работы в виде файла), то можно запустить эту
копию на другом физическом узле. Это дает то, что не дает отсутствие виртуализации в случае
сбоя или отказа оборудования – устойчивость работы;

3) Распределение мощностей.

35.3 Суть облачных вычислений

Некоторые IT-службы переносятся в централизованное место, где за счет технологий

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

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

35.4 Разновидности облачных вычислений

Первый уровень – IaaS (Infrastructure as a Service, инфраструктура как служба):

Пример –служба Amazon Web Services. Такого рода компании предоставляют возможность
создать некоторое количество виртуальных машин, объединенных в локальную сеть. То есть
инфраструктура предприятия развертывается не на самом предприятии, а у службы Amazon или
кого-либо иного поставщика.

Второй уровень – PaaS (Platform as a Service, платформа как служба):

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

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

Платформа предоставляет среду выполнения программ. Классический пример – Windows

Azure, [Link].

Windows Azure – это платформа для выполнения веб-служб. То есть можно написать
библиотеку, упаковать ее и отправить на сервер Microsoft, где для этой службы будет
обеспечиваться хостинг с указанием конфигурации точек доступа. При этом
автоматически будет обеспечиваться масштабирование веб-служб, если необходимо.
( нахождение на нескольких серверах, перемещение с одного сервера на другой,
взаимодействие веб-служб с веб-сайтами). Другими словами, Windows Azure – это пул
серверов, с предконфигурированной платформой .Net, сервером IIS и набором библиотек
коммуникации серверов между собой, с автоматическим «разбрасыванием»
экземпляров служб по этим серверам, что автоматически избавляет заказчика от
анализа того, сколько компьютеров ему потребуется и на каких компьютерах эти
службы должны работать.
 PaaS также предоставляет средства коммуникаций между программами, включая средства
для работы с базами данных, файловой системой, очередями, системами массового
обслуживания. Например, в рамках Windows Azure предоставляется работа с MSSQL.

Третий уровень – SaaS (Software as a Service, программа как служба):

Смысл состоит в том, что сама служба «виртуализует». Например, виртуализация службы
электронной почты: организация может зарегистрироваться, получить сервер для хранения
корреспонденции, почтовые ящики для своих сотрудников и работать с этой почтовой службой.
Аналогичную возможность эта служба предоставляет многим организациям, которые логически
обращаются к одному поставщику услуг, физически это работает на одних и тех же серверах, на
одной и той же платформе, но внутри масштабируется. С точки зрения каждого заказчика, служба
виртуализована, она работает только в его личных интересах. Получается, что на этом уровне не
только платформа общая, здесь общая инфраструктура создания на уровне программы, на более
высоком уровне и разделение идет на уровне заказчика. Это приводит к появлению понятия multi-
tenant (множественная аренда).
35.5 Модели развертывания

1) Private cloud (частное облако)

Облачная инфраструктура, подготовленная для эксклюзивного использования единой
организацией, включающей несколько потребителей. Такое облако может находиться в
собственности, управлении и обслуживании у самой организации, у третьей стороны и
располагаться как на территории предприятия, так и за его пределами.
2) Community cloud (общественное облако)
Облачная инфраструктура, подготовленная для эксклюзивного использования конкретным
сообществом потребителей от организаций, имеющих общие проблемы (например, миссии,
требования безопасности, политики). Облако может находиться в собственности, управлении и
обслуживании у одной или более организаций в сообществе, у третьей стороны, располагаться
как на территории организаций, так и за их пределами.
3) Public cloud (публичное (или общедоступное) облако)
Облачная инфраструктура, подготовленная для открытого использования широкой
публикой. Облако может находиться в собственности, управлении и обслуживании у деловых,
научных и правительственных организаций в любых их комбинациях. Облако существует на
территории облачного провайдера.
4) Hybrid cloud (гибридное облако)
Облачная инфраструктура представляет собой композицию из двух или более различных
инфраструктур облаков (частные, общественные или государственные), имеющих уникальные
объекты, но связанных между собой стандартизованными или собственными технологиями,
которые позволяют переносить данные или приложения между компонентами (например, для
балансировки нагрузки между облаками).

36. Базы данных со многими арендаторами (Multi-tenant databases)

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

36.1 Подходы к организации хранения данных

1) создание отдельных баз данных в рамках одной СУБД;

2) база данных одна, схем данных много;
3) база данных одна, схема данных общая для всех.

Разницу между подходами можно изобразить следующим образом:

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

36.2 Создание отдельных баз данных в рамках одной СУБД

Особенности:
– каждый арендатор имеет свой собственный набор данных, который логически изолирован от
данных других арендаторов;
– необходима дополнительная информация – метаданные, которые позволяют ассоциировать
базу данных с соответствующим арендатором;
– наличие отдельных баз данных в рамках одного сервера предотвращает доступ к данным
одного арендатора к данным другого;
– обеспечивает легкое расширение модели определенного арендатора в случае необходимости
(добавить таблицу/изменить связи между таблицами/ изменить тип колонки);

Достоинства:
1) легко осуществлять резервное копирование и восстановление данных конкретного арендатора,
т.к. эти операции происходят независимо от других арендаторов;
2) подходит для заказчиков, имеющих высокие требования к изоляции данных и их защите
(учетные записи для доступа, шифрование данные и т.д.).
Недостатки:
1) высокие затраты на оборудование для поддержки и создания резервных копий;
2) затраты оборудования и ограничения баз данных, которые поддерживаются одним сервером
СУБД.

36.3 База данных одна, схем данных много

Для нескольких арендаторов используется одна и та же база данных, но создается

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

Достоинства:
1) легкая настройка под конкретного арендатора: изначально имеется базовый набор таблиц,
который можно изменять (добавлять дополнительные колонки, индексы, типы данных и т.д.);
2) относительный уровень логической изоляции для приложений, которые заботятся о
безопасности;
3) количество поддерживаемых арендаторов значительно больше, чем в предыдущем подходе;
4) подходит для приложений, которые используют не слишком много таблиц (на одного
арендатора).

Недостатки:
1) намного сложнее происходит процесс восстановления данных, поскольку резервной единицей
становится БД целиком (выполнять резервное копирование отдельной таблицы невозможно, в
итоге необходимо делать резервное копирование всей БД, потом ее развертывание, копирование
таблиц, данных из backup-копий);
2) процесс восстановления по времени существенно возрастает;
3) ограничены лишь по количеству таблиц в рамках БД.

36.4 База данных одна, схема данных общая для всех

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

Достоинства:
1) низкие требования к оборудованию;
2) наибольшее количество арендаторов, обслуживаемых одним сервером;
3) удобно использовать при достаточно большом количестве таблиц;
4) БД наиболее эффективна в плане реализации по количеству арендаторов.

Недостатки:
1) для поддержания безопасности требуется дополнительное программирование, т.к. все данные
хранятся вместе;
2) усложняется работа с данными, если необходимо шифрование;
3) сложное восстановление данных из резервной копии (выполняется по той же схеме, что и во
втором подходе).
36.5 Экономический аспект использования баз данных со многими
арендаторами

«Shared approach» - разделяемые данные, «Isolated approach» - изолированные данные.

Анализ графиков: изначально в подходе с «изолированными данными» затраты

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

При выборе определенного подхода необходимо учитывать следующее:

– каково предельное количество пользователей у каждого арендатора;
– какое максимально возможное количество арендаторов;
– какой объем пространства будет выделено для баз данных на каждого арендатора;
–требования по безопасности.
37. Распределенные системы

Возникновение распределенных систем связано с тем, что мощность одного компьютера

ограничена, а по экономическим соображениям оказывается целесообразнее строить систему,
состоящую из N узлов, связанных между собой, и наращивать мощность системы добавлением
дополнительных узлов (N+1, N+2), а не увеличивать мощность единичного компьютера.

37.1 Масштабирование

37.1.1 Вертикальное масштабирование

Вертикальное масштабирование – это увеличение мощности вычислительной системы

путем добавления в нее более производительных компонентов (увеличение объема оперативной
памяти, увеличение дисковой памяти, увеличение количества процессоров), т.е. увеличение
качественно-количественных характеристик системы.

ЦП ЦП + ЦП ЦП

ОЗУ + ОЗУ

Жесткие диски

Жесткие диски
+
Жесткие диски

37.1.2 Горизонтальное масштабирование

Горизонтальное масштабирование – это увеличение мощности системы путем добавления

новых узлов, которые объединены в одну систему. Является альтернативой вертикальному
масштабированию.

ЦП ЦП

ОЗУ + ОЗУ

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

Главная проблема горизонтального масштабирования – это необходимость

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

37.1.3 Сравнение вертикального и горизонтального масштабирования

До определенного уровня вертикальное масштабирование лучше горизонтального, т.к.

1) горизонтальное масштабирование требует специального ПО;

2) увеличить количество компонентов существующего компьютера дешевле, чем купить новый
дополнительный компьютер;
3) энергопотребление системы ниже, т.к. у нее меньше энергопотребляющих компонентов;
4) занимаемый объем помещения меньше.

Однако у вертикальной масштабируемости есть предел по количеству памяти, количеству

процессоров. При использовании нескольких процессоров необходима модель общей памяти.
Варианты:
1) обеспечить синхронизацию (когерентность) кэшей процессоров;
2) применять подходы при программировании, обеспечивающие синхронизацию.

Когерентность бывает либо полная, как в процессорах Эльбрус, либо почти полная, как
в процессорах Intel, которые рассчитаны на поддержку многопроцессорности, но
максимум – на 4 процессора.

37.2 Задача создания распределенного файлового хранилища

Задача: Пусть Вам необходимо создать Youtube. Главная проблема: огромное количество
видеофайлов, которые нужно где-то хранить, а также обеспечивать к ним доступ.

Решение:

Создать систему, которая горизонтально масштабируется, и распределить файлы по узлам.

Когда место исчерпывается, добавлять новые узлы. Необходимо определить, по какому принципу
распределять (partitioning) файлы по узлам.

Partitioning – разбрасывание, распыление. Этот термин появился еще в реляционных БД

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

Варианты распределения файлов по узлам:

А) Есть дерево каталогов. Если в каком-то каталоге записаны файлы, то с большой вероятностью
эти файлы могут принадлежать одной программе и использоваться в ней. Можно нарезать
каталоги по именам и распределить куски каталогов по разным узлам;
В) Для каждого имени файла использовать некоторую функцию, которая вычисляет хэш и
группирует всё пространство имен по вычисленных значениям. Хэш определяет номер узла.
Термин для такого распределения – sharding.

Что делать в случае, если файл имеет объем, который не помещается на жесткий диск
(например, база данных)? Можно физически файл разбить на блоки и эти блоки
разбросать по узлам. Единицей распределения становится не файл, а файл и номер блока
внутри файла.

Если происходит распределение файлов, то при запросе на получение информации нужно

узнать, на каком узле находится файл. В первом случае (дерево каталогов) необходим
выделенный сервер, хранящий информацию о размещении файлов, который становится узким
местом системе. Выход этого узла из строя равносилен выходу из строя всей системы (single point
of value, критическая точка в системе). В случае использования хэш-значений нет необходимости
хранить дерево каталогов, т.к. хэш позволяет сказать, на каком узле хранится файл.

37.3 Основные требования к распределенным системам

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

1) масштабируемость;

2) надежность. Увеличение количества узлов может использоваться не только для наращивания

мощности системы, но и для обеспечения резервирования (например, в файловом хранилище
файлы можно сохранять не на 1м, а на 2х или 3х узлах).

Какой максимальный уровень резервирования(redundancy level) обычно используется?

Ответ: 3 или 4 уровень, т.к. вероятность одновременного сбоя в 3х узлах уже крайне
мала.

37.4 Понятие Базы Данных

В БД данные структурированы, между ними существует ссылочная целостность.

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

1) Atomicity – атомарность. Подразумевает, что транзакция либо полностью выполняется,

либо полностью не выполняется.

T: A, B –> A’, B’. Состояния A’,B, A,B’ невозможны.

2) Consistency – целостность, связность. Сохранение целостности данных. Если данные
между собой связаны, то связи не должны быть нарушены. Изменение объектов А и В может
означать неявное изменение объектов С или каких-нибудь еще объектов.

T: A, B –> A’, B’, C’.

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

3) Isolation – изоляция. Транзакции выполняются таким образом, что результат одной

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

T1: A,B –> A’,B’

T2: A,B –> A’’,B’’

Состояния A’,B’’ и A’’, B’ невозможны.

4) Durability – сохранность, постоянство. Если пользователь получил подтверждение
завершения транзакции, то он должен получить гарантии того, что транзакционные данные не
потеряны.

Если вернулась ошибка, то возможны 2 варианта: 1) транзакция выполнена; 2) транзакция

не выполнена. Но следует исходить из того, что транзакция не выполнена.

37.5 Теорема СAP (consistency, availability, partition tolerance)

В распределенной системе невозможно обеспечить согласованность и готовность

одновременно с устойчивостью системы к разделению.

Пусть распределенная система состоит из двух узлов. Транзакция Т1 охватывает объект А

на узле 1, объект В на узле 2 и переводит состояния объектов в А’ и B’.

T1: A, B –> A’, B’.

Согласованность подразумевает, что если транзакция Т1 выполняет действия, то
транзакция Т2 никогда не будет работать с данными А’ и В.

Устойчивость (терпимость) системы к разделению – поведение системы, при условии, что

связь между узлами может временно пропасть, временно один из узлов может выйти из строя.

В распределенной системе нет узкого места – единой точки напряжения.

Если происходит транзакция Т1, которая обновляет объект А на узле 1 и В на узле 2, а

связь между узлами потеряна, то транзакция Т1 может сохранить объект на узле 1, но не может
сохранить объект на узле 2, т.е. готовность системы не обеспечена при разделении. Это означает,
что для того чтобы обеспечить готовность, нужно обеспечить избыточность.

Пусть узлы 1 и 2 используют хранение данных, дублируя данные друг друга, с целью
обеспечения готовности. Тогда если между узлами 1 и 2 пропала связь, то изменения объекта А и
В обозначают изменения объекта А на одном из узлов и объекта В на одном из узлов.
 Обеспечивается репликация – копирование, перенос данных. В этом случае если мы
разделили систему, то транзакция, которая выполняет работу с объектом, сможет ее выполнить,
но если система будет разделена, то изменения произойдут только на узле, к которому обратился
пользователь. Однако в то же время другой пользователь может обратиться к другому узлу с
транзакцией Т2 при разделенной системе.

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

дублируют друг друга) и даже при разделении системы обеспечивается возможность выполнения
некоторого действия (чтения, изменения), но возникает дилемма: если вы изменили данные в
транзакции Т1 и Т2, пока система была разделена, когда связь будет восстановлена, в какое
состояние должна перейти система? Предположим, что было решено отдать приоритет второй
транзакции. Возникает возможность, что пока данные не перешли в состояние Т2, могут быть
прочтены разные значения А и В (А’, B’ , A’’, B’’). Худший вариант – когда клиент прочтет новые
данные (A’’, B’’), а затем – старые (А’, B’), что приведет к потере хронологии значений. Если
необходимо лишить пользователя возможности случайно видеть такие результаты, то на
некоторое время необходимо пожертвовать готовностью системы, т.е. пока система разделена,
запросы пользователя не должны обрабатываться.

Теорема показывает, что при разделении системы пропадает либо согласованность

данных, либо их готовность.

CAP–теорема была математически доказана. Но она не запрещает создание

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

1) она доказана для очень частного случая разделения системы;

2) система живет во времени, и существуют длительности интервалов, когда в системе
обеспечивается либо готовность, либо согласованность. Если эти интервалы достаточно малы, то
достаточно отложить выдачу ответа до следующего состояния готовности или согласованности.

Распределенные файловые хранилища, в отличие от распределенных баз данных,

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

Решение проблемы согласованности для БД привело к созданию систем БД, в которых не

обеспечивается распределенная транзакционность, но обеспечивается высокая
готовность (хранилище пар вида «ключ – значение»).

37.6 Уровни изоляции и проблемы, которые возникают в базах данных

Основные уровни изоляции:

1) serializable – упорядочивание всех транзакций;
2) repeatable read – обеспечение повторного чтения;
3) read committed – обеспечение чтения подтвержденных данных;
4) read uncommitted – чтение всех данных, включая неподтвержденные, т.е.
беспорядочное чтение.

Уровни изоляции введены, чтобы решить определенные проблемы.

Пусть есть таблица.

id name age
1 Joe 20
2 Jill 25

Рассмотрим проблемы баз данных на примере работы с указанной таблицей.

1) грязное чтение

Транзакция 1 Транзакция 2

SELECT age FROM users WHERE id = 1;

UPDATE users SET age = 21 WHERE id = 1;

SELECT age FROM users WHERE id = 1;

ROLLBACK;

2) неповторяющееся чтение

Транзакция 1 Транзакция 2

SELECT * FROM users WHERE id = 1;

UPDATE users SET age = 21 WHERE id = 1;

COMMIT;

SELECT * FROM users WHERE id = 1;

COMMIT;

3) фантомное чтение

Транзакция 1 Транзакция 2

SELECT * FROM users

WHERE age BETWEEN 10 AND 30;

INSERT INTO users VALUES ( 3, 'Bob', 27 );

COMMIT;
SELECT * FROM users
WHERE age BETWEEN 10 AND 30;

Уровень изоляции Грязное чтение Неповторяющееся Фантомное чтение

чтение
Read Uncommitted Возможно Возможно Возможно
Read Committed - Возможно Возможно
Repeatable Read - - Возможно
Serializable - - -

Работа БД в режиме Serializable требует не только блокировок на запись и чтение данных,

но и на диапазоны данных, сложна в реализации и неэффективна при работе.

Есть различные подходы, чтобы обеспечить эти уровни изоляции:

1) Использование блокировок;

2) MVCC (MultiVersion Concurrency Control) – управление конкурентным доступом с

помощью многоверсионности. Каждый элемент данных представляет собой ссылку на список;
изменение данных происходит следующим образом: когда происходит начало транзакции,
запоминается время t1(с точностью до тиков процессора), и это значение используется для
отсечения по времени новых изменений. Если для объекта приходит обновление, то происходит
засечка времени (t2). Если приходит запрос, то есть временной срез t1, который является
параметром любого запроса. Получается, мы не видим последних изменений. Этот подход
требует синхронизации транзакций по времени. Для этого используются системные часы и
единый механизм выдачи времени. Этот подход работает в системе, расположенной на одном
сервере. Иначе возникает проблема синхронизации времени на нескольких серверах.

37.7 Построение транзакционной распределенной системы

Существует мнение, что можно построить транзакционную распределенную систему путем

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

1) требует обеспечения распределенности;

2) требует обеспечения высокой готовности для узлов (т.е. это не должен быть один узел);
3) существует ограничение: транзакционное чтение может выполняться только в рамках
одного сервера;
4) невозможно обеспечить режим Serializable, т.к. нужно абсолютно точно упорядочить все
транзакции.