Конспект лекций «Компьютерные сети» — различия между версиями

Текущая версия на 10:15, 29 марта 2013

Введение

Базовые понятия

Компьютерная сеть — это совокупность компьютеров, которые могут обмениваться между собой информацией.

Source(s): Компьютерные сети

Компоненты компьютерной сети:

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

Сервер — компьютер или программа, предоставляющая некоторые услуги.

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

Клиент — это компьютер или программа, запрашивающая услуги.

Клиенты бывают толстыми, тонкими и сверхтонкими.

Source(s): Компьютерные сети

Source(s): Компьютерные сети

При доступе к почте через почтовую программу, например, Mozilla Thunderbird по протоколу IMAP (данные хранятся на сервере, а интерфейс обеспечивается почтовой программой-клиентом) можно сказать, что интерфейс строится программой-клиентом на клиенте. Если используется протокол POP3 — речь идет уже о толстом клиенте. В случае же доступа к почте через веб-интерфейс (данные хранятся на сервере и интерфейс (веб-странички) генерируются сервером) интерфейс строится на сервере и передается программе-клиенту.

Source(s): Компьютерные сети

Протокол определяет:

• формат сообщений;
• очередность сообщений;
• действия, которые необходимо выполнять при получении, приеме сообщений или при наступлении иных событий.

Пропускная способность канала связи (bandwidth) — наибольшая скорость передачи информации по каналу связи. Измеряется числом передаваемых двоичных символов в 1 с. Скорость передачи зависит от физических свойств канала связи, статистических свойств помех, способа передачи, приема сигналов и др..

Source(s): Компьютерные сети

Например:

• EDGE - до 474 кбит/с
• ADSL - 8 Mbit/s
• FastEthernet - 100 Mbit/s
• WiFi 802.11g - 54 Mbit/s
• Gigabit Ethernet - 1000 Mbit/s

<xh4> Особенности терминологии </xh4> Internet – Интернет
internet - несколько локальных сетей (сетевой комплекс)
intranet – частная ceть организации, использующие механизмы Интернета
extranet – объединение intranet-сетей различных компаний через Интернет
Ethernet – технология локальных сетей

Интранет (англ. Intranet) — в отличие от сети Интернет, это внутренняя частная ceть организации. Как правило, Интранет — это Интернет в миниатюре, который построен на использовании протокола IP для обмена и совместного использования некоторой части информации внутри этой организации. Intranet допускает использование публичных каналов связи, входящих в Internet, (VPN — Virtual Private Network), но при этом обеспечивается защита передаваемых данных и меры по пресечению проникновения извне на корпоративные узлы.

Source(s): Компьютерные сети

Классификация компьютерных сетей

Классификация компьютерных сетей по территории

• Local Area Network (LAN) — сети одной квартиры, дома, организации.
• Metropolian Area Network (MAN), городские — высокоскоростные каналы связи в пределах большого города.
• Региональные — объединяют компьютеры географической области.
• Wide Area Network (WAN), глобальные.

Пример 1. Пользователи Spark объединены в локальную сеть, которую можно назвать городской (MAN).

Пример 2. Рунет — региональная сеть.

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

Source(s): Компьютерные сети

Классификация компьютерных сетей по топологии

Source(s): Компьютерные сети

Классификация компьютерных сетей по типу среды передачи

• Проводные
  • витая пара;
  • коаксильный кабель;
  • оптоволокно.
• Беспроводные
  • радиосвязь (WiFi, WiMAX);
  • инфракрасная связь;
  • СВЧ-связь (Bluetooth).

Source(s): Компьютерные сети

Пример. Сеть мехмата имеет топологию дерево.  

Cеть мехмата. Красные линии – оптоволокно, синие – витая пара

Source(s): Компьютерные сети

Файлообменные P2P сети

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

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

Современные файлообменные сети позволяют скачивать один файл сразу с нескольких источников (так быстрее и надёжнее). Чтобы убедиться, что этот файл у всех источников одинаковый, производится сравнение не по названию файла, а по контрольным суммам или хэшам типа MD4, TTH, SHA-1. Во время (и после) скачивания файла пользователем, этот файл у него могут скачивать и другие клиенты сети, в результате чего файлы могут в итоге быть доступными для скачивания со многих источников одновременно.

Схема работы P2P-сети с централизованным каталогом

Source(s): Компьютерные сети

P2P-сети с централизованным каталогом. Napster

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

Самый известный пример P2P-сети с централизованным каталогом является сеть Napster.

Source(s): Компьютерные сети

Частично децентрализованные сети

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

Source(s): Компьютерные сети

eDonkey

eDonkey (eDonkey2000, eD2k, осел, ослик) была создана Джедом Мак Калебом, вышла в сентябре 2000 г. По сравнению с Napster у нее появилось несколько нововведений: множественная закачка (когда клиент может закачивать файл по частям, причем разные части у разных пиров). У Napster серверы, на которых хранится централизованный каталог, не связываются между собой. В последних версиях eDonkey200 0 серверы формируют поисковую сеть (каждый сначала ищет у себя, потом у других). Вместо имен файлов у Napster в eDonkey для идентификации используются хэш-суммы . Таким образом, один и тот же файл, имеющий разные имена у пиров, трактуется сервером как один файл.

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

Принцип работы: клиент Z имеет все части файла (символы строчных букв представляют части файла). Клиенты W, X, и Y хотят загрузить Файл. Клиенты X и Y имеют различные части файла, они могут не только получить файл от клиенты Z, но могут и посылать файл друг другу. Это позволяет файлу быть распределённо распространённым намного быстрее без того, чтобы использовать большее количество ширины канала клиента Z. Клиент W может запустить загрузку файла, даже если источник файла (Z) больше не имеет достаточной ширины канала для отсылки.

Source(s): Компьютерные сети

Source(s): Компьютерные сети

BitTorrent

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

Source(s): Компьютерные сети

Полностью децентрализованные сети

Gnutella — это пример полностью децентрализованные сети.

Source(s): Компьютерные сети

Gnutella

Gnutella построена по собственной особой технологии без центральных узлов gPulp. Узлами здесь служат сами пользователи, а саму программу вывести из строя невозможно. Работа сети: 1 шаг: To envision how Gnutella originally worked, imagine a large circle of users (called nodes), who each have Gnutella client software. On initial startup, the client software must bootstrap and find at least one other node. далее: Once connected, the client will request a list of working addresses. The client will try to connect to the nodes it was shipped with as well as nodes it receives from other clients until it reaches a certain quota. It will only connect to that many nodes, locally cache the addresses it has not yet tried and discarding addresses it tried which were invalid. поиск: Пользователь вводит запрос (например, название mp3-файла). Программа рассылает запрос на поиск файла всем узлам в списке, а далее просто ждет входящих сообщений. Каждый узел, получивший запрос на поиск, ищет в своем фонде указанный файл. Если файл не найден, то узел просто не отвечает. Если файл найден, узел отсылает инициатору запроса ответ с информацией о файле и о себе (IP-адрес). Получив ряд ответов, программа выбирает один из узлов, устанавливает с ним стандартное HTTP-соединение и загружает файл. При этом все сообщения (от Ping-запроса до скачивания файла) посылаются по HTTP, что затрудняет их отслеживание и блокировку.

При этом зависимость загрузки каналов от числа узлов экспоненциальная. Действительно, пусть компьютер хочет опросить все компьютеры в сети. Он посылает запрос 10 известным ему компьютерам. Каждый из них отправит по 10 запросов известным им компьютерам и т.д.. Итого получится 10+100+1000+..+10^d запросов, где d-расстояние до самого далекого компьютера. Таким образом, если количество компьютеров в сети увеличится в 2 раза, то увеличится количество запросов, примерно, возведётся в квадрат.

Now, when the user wanted to do a search, the client would send the request to each node it is actively connected to. The number of actively connected nodes for a client was usually quite small (around 5), so each node then forwards the request to all the nodes it is connected to, and they in turn forward the request, and so on, until the packet was a predetermined number of «hops» (прыжков) from the sender.

If a search request turns up a result, the node that had the result needs to contact the searcher. In the classic Gnutella protocol response messages were always sent back along the route the query came in through, as the query itself did not contain identifying information of the node. This scheme was later revised, so that search results are delivered over UDP directly to the node which initiated the search, respectively a proxying peer, usually an ultrapeer of the node. The queries do therefore carry the IP address and port number of either node. This lowers the amount of traffic routed through the Gnutella network, making it significantly more scalable.

In practice, this method of searching on the Gnutella network was often unreliable. Each node is a regular computer user; as such, they are constantly connecting and disconnecting, so the network is never completely stable. Also, the bandwidth cost of searching on Gnutella would grow exponentially to the number of connected users, often saturating connections rendering slower nodes useless. Therefore, search requests would often be dropped, and most queries reached only a very small percentage of the network. This observation identified the Gnutella network as an unscalable distributed system, and inspired the development of distributed hash tables, which are much more scalable but support only exact-match, rather than keyword, search.

Апгрейд: To address the problems of bottlenecks, Gnutella developers implemented a tiered system of ultrapeers and leaves. Instead of all nodes being considered equal, nodes entering into the network were kept at the 'edge' of the network as a leaf, not responsible for any routing, and nodes which were capable of routing messages were promoted to ultrapeers, which would accept leaf connections and route searches and network maintenance messages. This allowed searches to propagate further through the network, and allowed for numerous alterations in the topology which have improved the efficiency and scalability greatly.

Source(s): Компьютерные сети

Полностью децентрализованные сети

DHT (Distributed hash table) — децентрализованная распределенная система для объединения большого количества постоянно исчезающих и появляющихся узлов и эффективной передачи сообщений между ними. Она использует 160-битные хэши для идентификации узлов, файлов и имен файлов (ключевых слов). Каждый узел содержит информацию о месторасположении файлов с хешами, близкими к его хешу.

Поиск в Kad. Кружочками отмечены узлы.

Source(s): Компьютерные сети

Kad

Сеть Kad — это реализация DHT. Узлы, файлы и имена файлов (ключевые слова) кодируются алгоритмом SHA-1 160-битными числами. Если узел хочет расшарить файл, он обрабатывает его, получая хэш, который идентифицирует этот файл в сети. Затем узел ищет несколько узлов, ID которых близки к хэшу файла и его имени (размеры хешей файлов и узлов совпадают, расстояние вычисляется применением операции XOR к хешам). На эти узлы отдается информация об адресе узла, на котором хранится файл.

Source(s): Компьютерные сети

Поиск в Kad

В соответствии с хешами узлы можно разместить в двоичном дереве.

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

Когда узел хочет найти файл, он сравнивает хеш имени с хешами известных ему узлов, затем посылает запрос тому узлу, чей хеш наиболее близок к искомому. Тот узел возвращает ему адрес узла, чей хеш ещё ближе к искомому. Тогда наш узел посылает запрос тому новому узлу, и получает от него адрес следующего узла, чей хеш ещё ближе и т.д.. Таким образом, запросы постепенно стекаются к узлам, чьи хеши наиболее похожи на искомый. А эти узлы уже знают, где находится файл. Запросы итеративные. «Стоимость» такого поиска логарифмически зависит от количества узлов в сети и, если количество узлов удвоится, количество запросов возрастет на 1.

Source(s): Компьютерные сети

Другие приложения P2P-сетей

• мобильный P2P;
• распределенные вычисления SETI@home;
• совместное работа ( Groove );
• Skype.

Структура сети Интернет

Локальные, региональные, магистральные провайдеры

Локальный (местный) провайдер (ISP – Internet Service Provider) – поставщик услуг Интернета, работающий (как правило) в пределах одного города (ЮГИНФО, ЦТС, Интеркабель).

Региональный провайдер – одной страны, области, округа (ТрансТелекомКавказ, ЮТК, ЦТС).

Магистральный провайдер – страны, континента, земного шара (Global one Orange), Голден Телеком, Ростелеком, Verizon, Cogent)

Точки присутствия (POP), точки обмена трафиком (IX)

Ядро Интернета (или Core Backbone Network) составляют сети так называемых провайдеров первого уровня (Network Server Provider Tier-1) или магистральных провайдеров, наиболее крупными из которых являются UUNET(куплен Verizon), AT&T(в Америке), MCI (куплен Verizon), GTE/BBN (вместе с AT&T в SBC) и Sprint (названия часто меняются, из-за того что одни фирмы объединяются, другие кого-то покупают или входят в состав более крупных фирм, третьи переименовываются).

Эти сети построены в основном на базе технологий SONET/SDH, DWDM, ATM. Для их магистралей характерны каналы 622 и 2488 Мбит/с соответственно. Иногда встречаются каналы 9952 Мбит/с и даже более.
Сети магистральных провайдеров первого уровня свободно обмениваются между собой трафиком через IXP – Internet Exchange Point точки обмена трафиком. Страны получают доступ к ядру Интернета либо благодаря магистральным провайдерам первого уровня, имеющим точки присутствия (POP-Point of Presence) по всему миру, либо локальным магистральным провайдерам первого уровня. Сети NSP Tier-1 свободно обмениваются между собой трафиком, причем основная часть этого обмена сосредоточена в двух зонах (Metropolian Exchange Area,MAE), расположенных в Нью-Йорке и Сан-Франциско. Хотя наибольшая концентрация NSP первого уровня приходится на США, "ареал распространения" этих сетей не ограничивается только этой страной. Другие страны получают доступ к ядру Интернета либо благодаря NSP первого уровня, имеющим точки присутствия (POP-Point of Presence) по всему миру (например, UUNET "дотягивается" и до Европы, и до Юго-Восточной Азии), либо локальным NSP первого уровня (эта практика распроcтранена в Азии).

Ниже магистральных провайдеров по иерархии расположены сетевые провайдеры следующего уровня - региональные, соединенные между собой высокоскоростными каналами передачи данных, которые, в свою очередь предоставляют доступ к Интернету местным (локальным) провайдерам (Internet Service Privider, ISP). Индивидуальные пользователи и компании-клиенты получают доступ к ресурсам Интернета именно при помощи ISP. Соединение между ISP и пользователями (частными или корпоративными) обычно осуществляется при помощи: коммутируемых линий (обычных телефонных или ISDN), спутниковой связи, ADSL, VDSL, WiMAX, мобильной связи (2G, 2.5G, 3G) или посредством так называемых выделенных линий: FTTH (Fiber to the Home), ETTH (Ethernet to the Home).

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

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

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

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

Point Of Presence (POP), точка присутствия – место расположения оборудования оператора связи (провайдера), к которому возможно подключение клиентов.

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

Например, при предоставлении услуги подключения к сети Интернет последняя миля — участок от порта коммутатора провайдера на его узле связи до порта маршрутизатора клиента в его офисе. Для услуг коммутируемого (dial-up, диалапного) подключения последняя миля — это участок между модемом пользователя и модемом (модемным пулом) провайдера. В последнюю милю обычно не включается разводка проводов внутри здания. К технологиям последней мили обычно относят xDSL, Wi-Fi, WiMax. К оборудованию последней мили можно отнести xDSL-модемы, мультиплексоры доступа, оптоволоконные модемы и преобразователи, радиомультиплексоры. Есть специализированные компании и подразделения крупных компаний связи, которые занимаются исключительно построением последней мили.

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

IXPnternet eXchange Point (IXP), точка обмена трафиком – инфраструктура, которая позволяет различным провайдерам обмениваться трафиком.

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

Source(s): Компьютерные сети

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

Коммутация каналов

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

Основные способы организации каналов, по которым могут разговаривать много пользователей:

• частотное мультиплексирование (разделение) — для каналов выделяются частотные поддиапазоны. Например, этот метод используется в технологии X-DSL. По кабелю передаются сигналы различной частоты: телефонный разговор-0,3-3,4 Кгц а для передачи данных используется полоса от 28 до 1300 Кгц.
• временное мультиплексированиемультиплексирование — используются все частоты, но в определенное время, т.е. канал используется попеременно каждым абонентом. Вся пропускная способность выходного канала предоставляется в течение фиксированных интервалов времени каждому входному каналу. Недостаток: даже если какой-то входной канал не использует для передачи выделенный ему интервал, другие каналы не могут передавать данные в это время.

Source(s): Компьютерные сети

Коммутация пакетов

Сообщение разбивается на пакеты, которые могут идти независимо друг от друга (по разным маршрутам). В случае когда пакетов много, организуются очереди. Исключение: в сетях с режимом асинхронной передачи (Asynchronous Transfer Mode, ATM) коммутация каналов сочетается с коммутацией пакетов (см. главу 5 Куроуза и Росса).

Историческая справка. История развития сети Интернет  

1969 г. Рождение ARPAnet

Леонард Клейнрок рядом с первым интерфейсным процессором сообщений (коммутатором пакетов)

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

Alohanet — первая радиосеть с коммутацией пакетов.

Request for Comments, RFC — документ из серии пронумерованных информационных документов Интернета, содержащих технические спецификации и стандарты, широко применяемые во всемирной сети. Формат RFC появился в 1969 году при обсуждении проекта ARPANET. RFC 1 был опубликован 7 апреля 1969 г. и назывался «Host Software». Первые RFC распространялись в печатном виде на бумаге в виде обычных писем, но уже с декабря 1969 г., когда заработали первые сегменты ARPANET, документы начали распространяться в электронном виде. Несмотря на название, запросы комментариев RFC сейчас рассматриваются как стандарты Интернета (а рабочие версии стандартов обычно называют драфтами, от англ. draft здесь — черновик). Примеры популярных стандартов: IP, UDP, TCP, HTTP, SMTP, FTP, DNS, URL, NAT… Есть первоапрельские RFC, например, RFC 1149 «Internet Protocol посредством почтовых голубей» (между прочим, реализованный на практике).

В ARPAnet взаимодействие между компьютерами было многосоставным: модемы (IMP) общались между собой по своим правилам, использующим маршрутизацию пакетов, контроль потока и осуществляющим надежную передачу пакетов; существовало ПО для передачи информации между модемом и компьютером; поверх этих программ работала NCP - Network-Control Program (RFC 001) — программа для обмена информацией между компьютерами. Адреса в NCP включали в себя идентификатор пользователя, компьютера и соединения между программами (прообраз сокетов). В марте 1972г с использованием функций NCP были написаны первые сетевые программы электронной почты SNDMSG and READMAIL (электронная почта между пользователями мейнфреймов на самом деле родилась раньше) В июле 1972 вышел стандарт RFC 354 службы передачи файлов FTP, используемой повсеместно и сегодня.

ALOHAnet Одним из первых обитателей будущей Кремниевой Долины, увлекшимся созданием сетей, оказался профессор из Стэнфорда Норм Абрамсон. Так оказалось, что он был еще и заядлым серфингистом. Совместить две области интересов ему удалось на Гавайских островах, где, как известно, одно из лучших в мире мест для катания на доске, а компьютеры, находившиеся в ведении местного университета, были разбросаны по нескольким островам архипелага. Так вот, Абрамсон предложил связать их сетью с использованием радиоканалов. Это было сделано в 1970 году. На решение о создании сети в немалой степени повлияло личное знакомство Абрамсона с Робертсом. Впоследствии Абрамсон смог получить процессоры IMP и по радио подключить созданную им сеть Alohanet к ARPAnet. Сеть, названная по имени самого крупного из островов, оказалась первой радиосетью с коммутацией пакетов. Но самое большое достижение Абрамсона состояло в том, что он открыл возможность совместного использования эфира независимыми узлами сети. В первой версии протокола идея Абрамсона была интригующе простой: «Если у вас есть данные для передачи — передавайте, а если обнаружите, что частота занята… то подождите и пошлите позже». Суть идеи заключена именно в формулировке «пошлите позже»; сегодня о ней мало кто задумывается, а тогда она надолго захватила умы инженеров. В последующем схема был доведена до совершенства Робертом Меткалфом, автором Ethernet, и получила название «множественный доступ к среде с контролем несущей и обнаружением коллизий» (Carrier Sense Multiple Access with Collision Detection, CSMA/CD). Непосредственными преемниками Alohanet стали протокол Slotted Aloha, а позже — протоколы популярных беспроводных сетей передачи данных ARDIS, Mobitex, CDPD и даже GSM.

1970-1980 гг. Возникновение новых компьютерных сетей и Интернета

Параллельно с развитием ARPAnet появлялись другие компьютерные сети: ALOHAnet (радио сеть Гавайского университета, Telenet, Cyclades (во Франции), SNA и др. Возникла задача о соединении сетей с различной архитектурой. Нужно было придумать новую систему адресации компьютеров, которая бы работала для объединенной сети - Интернета. Старый протокол NCP был больше похож на драйвер устройства.

Роберт Канн совместно с Уинтоном Серфом разработал новую версию протокола, которая впоследствии была названа TCP/IP (Transmission Control Protocol, протокол управления передачей данных; IP — Internet Protocol). Изначально это был один протокол TCP, который осуществлял маршрутизацию и надежную доставку пакетов, использовал глобальную адресацию компьютеров. Эксперименты с пакетной передачей голосовых сообщений показали, что иногда требуется, чтобы протокол допускал потерю некоторых пакетов при передаче информации. Это привело к появлению протокола IP, несущего транспортные функции и протоколов TCP и UDP (User Datagram Protocol) для надежной и ненадежной передачи данных.

Еще одним выходцем из «могучей кучки» МТИ был француз Луи Пуссен. В середине 60-х он участвовал в разработке операционной системы Multics; ему принадлежит авторство термина shell для обозначения языка управления, используемого сегодня во многих операционных системах. А в начале 70-х с группой коллег он снова побывал в США и ознакомился с состоянием дел ARPAnet. Итогом этого визита стали несколько отчетов, стимулировавших французское правительство к финансированию работ по созданию собственной сети, получившей название Cyclades Packet Switching Network. Тогда во Франции активно развивались собственные сетевые решения, приведшие в частности к созданию уникальной телефонной сети с терминалами minitel, предоставлявшимися абонентам бесплатно. Под натиском Internet сеть Cyclades в середине 80-х прекратила свое существование, однако ее, как и Alohanet, нельзя рассматривать как тупиковые ветви. Из проекта Cyclades непосредственным образом вырос протокол TCP/IP. Сеть Cyclades была многоуровневой: первый уровень — уровень передачи данных (Data Transmission), второй — транспортный (Transport), третий — прикладной (Application). Авторы TCP/IP, Винт Серф и Роберт Канн ссылаются на Пуссена, как на своего предшественника. 

1980-1990 гг. Распространение компьютерных сетей

Разработана система доменных имен DNS (Domain Name System), связавшая IP адреса компьютеров с их мнемоническими именами

Середина 80-х. Создание NFSnet (сеть национального научного фонда США (NFS)

Основой сети NFSNET стали пять очень мощных компьютеров, соединенных между собой сверхбыстрыми (на тот момент) линиями связи. Пользователи подключались к сети и использовали мощности этих компьютеров. NFSNЕТ унаследовала от ARPANET принципы построения, обеспечивающие высокую надежность, а также три уровня протоколов (под протоколом в данном случае понимается соглашение о способе передачи информации; понятно, что если разные части сети будут использовать разные способы передачи, то они друг друга просто не поймут) — сетевой, транспортный и протокол приложений, а также добавила к ним протокол межсетевого уровня под названием IP (интернет-протокол). Полученный комплект протоколов получил название TCP/IP — как раз на нем-то и базируется передача информации в Интернете.

Сеть NFSNET была более прогрессивной и предоставляла намного более мощные возможности по сравнению с ARPANET, поэтому ARPANET была ликвидирована в конце восьмидесятых. NFSNET заняла место прародительницы Интернета, а это потребовало ее умощнения и некоторой реорганизации, в результате чего был создан так называемый Бекбон NFSNET (от англ. backbone — хребет), который состоял уже из тринадцати компьютеров (точнее, компьютерных центров), соединенных друг с другом теми же высокоскоростными линиями связи. Центры располагались в разных городах США и, по сути, являлись одновременно центрами местных компьютерных сетей, так что NFSNET стала сетью, объединяющей другие сети.

Тим Бернерс-Ли

1990 г. Ликвидирована ARPAnet

90-е годы. WWW

Тим Бернерс-Ли вместе со своими ассистентами создает первоначальную версию языка разметки гипертекста HTML, протокола HTTP передачи HTML-документов, web-сервера и браузера.

Многоуровневые сетевые модели

Глобальные сети объединяют в себе огромное количество географически распределённых узлов. Множество вариантов программно-технической реализации передачи информации породили необходимость создания открытых стандартов — стандартов, официально опубликованных и доступных для разработчиков программно-аппаратных компонентов.

Взаимодействие уровней

Взаимодействие приложений через сеть очень сложно. Разделение его на уровни позволяет понизть сложность. Каждый уровень взаимодействует через сеть с одноименным уровнем. Для этого уровень пользуется услугами нижележащего уровня и каждый уровень предоставляет услуги вышележащему уровню.

Сетевая модель

Сетевая модель определяет:

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

Source(s): Компьютерные сети

Как устроена сетевая модель

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

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

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

Протокол — это правила, которым должен следовать уровень, чтобы реализовать сетевую службу.

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

Пример. Почтовая служба. Чтобы отправить кому-либо письмо, мы пишем адрес на кон-верте. Таким образом, функция адреса заключается в обеспечении правильной доставки. Формат, в котором пишется адрес, строго определен: 1-я строка – кому, 2-я строка – улица, дом, 3-я строка – город. Почтовые работники ожидают, что на второй строке будет указана улица, а за ней – номер дома. Формат адреса на конверте следует определенному протоколу.

Пример трехуровневой модели. Архитектура «философ — переводчик — почта»

Source(s): Компьютерные сети

Пример трехуровневой модели

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

Source(s): Компьютерные сети

Передача сообщения

Передача сообщения

При передаче, информация делится на пакеты. Фактически, передаваемая информация формируется на самом верхнем уровне — уровне работающего приложения (прикладном). Далее пакет «спускается» по уровням модели и на каждом из них получает свой заголовок и концевик. Этот заголовок содержит функционально-специфичную для данного уровня информацию о пакете (например, адрес). При получении информации узлом-получателем большой (с заголовками всех уровней) блок информации начинает обрабатываться в обратной, восходящей, последовательности уровней, причём на каждом уровне происходит анализ и отщепление соответствующего заголовка. Таким образом, до процесса-получателя доходит исходный передаваемый блок. На уровнях зачастую сообщение M вместе с заголовками от верхних уровней подвергается изменениям: шифрованию, сжатию, разбиению на части,…, поэтому изображенная картинка с одной и той же часть M, вообще говоря, не совсем правильная (зато понятная).

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

Модель OSI имеет семиуровневую структуру, и можно говорить о взаимодействии узла-отправителя и узла-получателя на каждом уровне модели.

Source(s): Компьютерные сети

Функции уровней

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

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

Source(s): Компьютерные сети

Эталонная модель OSI

Эталонная модель взаимодействия открытых систем, Open Systems Interconnection Reference Model (OSI), создавалась как единый международный стандарт сетевых технологий.

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

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

ISO — международная организация по стандартизации.

OSI ISO — абстрактная модель для сетевых коммуникаций и разработки сетевых протоколов. Представляет уровневый подход к сети. Каждый уровень обслуживает свою часть процесса взаимодействия. Благодаря такой структуре совместная работа сетевого оборудования и программного обеспечения становится гораздо проще и понятнее.

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

1. Физический (Physical Layer) Передача битов данных по сети.
   Подробнее  

   Преобразует биты в исходящие сигналы, передает сигналы и, затем, преобразует входящие сигналы в биты. Определяет:

   • характеристики сигналов;
   • среды передачи;
   • физическую топологию среды передачи;
   • механические и физические (электрические, оптические) спецификации среды передачи;
   • интерфейсы (разъемы) оборудования.

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

2. Канальный (уровень передачи данных) (Data Link Layer) Передаёт кадры (наборов битов) между двумя узлами сети, непосредственно связанными между собой.
   Подробнее  

   Передает кадры (frames) — наборы битов — между двумя узлами сети, непосредственно связанными между собой Функции канального уровня:

   • взаимодействие со средой передачи данных (протокол MAC);
   • надежная доставка;
   • управление потоком.

   В протоколах канального уровня заложена определенная структура связей между компьютерами и способы их адресации. Для идентификации компьютеров на канальном уровне используются аппаратные адреса (MAC – адреса) в Ethernet. 802.Xx – номера описаний стандартов IEEE (институт инженеров по электротехнике и радиоэлектронике).

   Технологии: Ethernet (802.3), WiFi (802.11), Token Ring (802.5) и РРР.

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

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

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

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

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

   Исправление ошибок выполняет расширенная служба обнаружения ошибок. Такая служба способна не только обнаружить ошибку в кадре, но также определить, в каком именно разряде она произошла, и таким образом исправить некоторые ошибки. Услуга по исправлению ошибок предоставляется некоторыми протоколами канального уровня (например, ATM), но, как правило, не для всего пакета, а только для его заголовка.

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

3. Сетевой (Network Layer) Осуществляет управление подсетью, то есть совокупностью коммуникационного оборудования. Определяет маршруты следования данных. Соединяет разнородные сети.
   Подробнее  

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

   • адресация компьютеров во всей глобальной сети (IP-адреса);
   • выбор маршрута доставки сообщений.

   Не обеспечивает надежность доставки (искажения, потери, изменение порядка следования).

   Протоколы: IP (Internet Protocol), ARP, RARP, ICMP, DHCP.

   best-effort delivery – доставка пакетов с максимально возможной скоростью, без гарантии отсутствия задержек, потерь пакетов (при переполнении буферов на маршрутизаторах).

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

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

   При путешествии пакета из одной сети в другую также может возникнуть ряд проблем. Так, способ адресации, применяемый в одной сети, может отличаться от принятого в другой. Сеть может вообще отказаться принимать пакеты из-за того, что они слишком большого размера. Также могут различаться протоколы, и т. д. Именно сетевой уровень должен разрешать все эти проблемы, позволяя объединять разнородные сети. Для преобразования IP-адресов (адресов сетевого уровня) в MAC-адреса (адреса канального уровня) в сетях TCP/IP используется протоколы ARP (англ. Address Resolution Protocol — протокол разрешения адресов) и RARP (англ. Reverse Address Resolution Protocol — обратный протокол преобразования адресов).

   Протоколы маршрутизации RIP (в локальных сетях) и BGP (в магистральный сетях) работают на прикладном уровне.

4. Транспортный (Transport Layer) Доставляет данные непосредственно от программы-отправителя к программе-получателю с определёнными гарантиями (на сохранность информации, порядок передачи сообщений и др.), не имеет дела с узлами сети.
   Подробнее  

   Осуществляет надежную доставку данных от отправителя к получателю. Функции транспортного уровня:

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

   Протоколы: TCP, UDP.

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

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

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

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

5. Сеансовый (Session layer) Организует сеансы связи, то есть долговременного взаимодействия между абонентами. Определяет, порядок передачи сообщений. Решает задачу синхронизации между абонентами.
   Подробнее  

   Позволяет двум сторонам поддерживать длительное взаимодействие (сеанс) по сети. Функции сеансового уровня:

   • установление сеанcа;
   • поддержка/управление сеансом;
   • разрыв сеанса;
   • синхронизация передачи данных (можно помещать контрольные точки в поток данных и возвращаться назад к определенной точке).

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

6. Уровень предоставления данных (Presentation layer) Занимается согласованием синтаксиса и семантики данных, передающихся по сети.
   Подробнее  

   Уровень отвечает за:

   • преобразование форматов данных;
   • кодирование/декодирование.

   Примеры преобразования данных: форматирование, сжатие, перевод, кодирование, шифрование.

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

7. Прикладной (Application layer) Предоставляет службы для специфических потребностей пользователей (электронная почта, передача файлов и др.)
   Подробнее  

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

   Протоколы: HTTP, SMTP, POP3, IMAP, FTP.

   Обеспечивает взаимодействие сети и пользователя. Уровень разрешает приложениям пользователя иметь доступ к сетевым службам, таким как обработчик запросов к базам данных, доступ к файлам, пересылке электронной почты. Также отвечает за передачу служебной информации, предоставляет приложениям информацию об ошибках и формирует запросы к уровню представления. Пример: HTTP, POP3, SMTP.

   Содержит набор популярных протоколов, необходимых пользователям. Одним из наиболее распространенных является протокол передачи гипертекста HTTP (HyperText Transfer Protocol), который составляет основу технологии Всемирной Паутины. Когда браузер запрашивает веб-страницу, он передает ее имя (адрес) и рассчитывает на то, что сервер будет использовать HTTP. Сервер в ответ отсылает страницу. Другие прикладные протоколы используются для передачи файлов, электронной почты, сетевых рассылок.

   На этом уровне передаваемые данные называются сообщениями.

Source(s): Компьютерные сети

Общие замечания относительно OSI ISO

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

Сегодня это референтная (ссылочная) модель.

Хотя поддержка этого стека на правительственном уровне (США, Германия, Россия,…) продолжается, это маргинальное течение в современных сетевых технологиях.

Эталонная модель TCP/IP

Эталонные модели OSI и TCP

Согласно терминологии TCP/IP элементы сетевого уровня называются подсетями (subnetworks). Идеология TCP/IP допускает, чтобы в качестве «подсетей» выступали реальные сети с их собственными стеками протоколов, узлами, шлюзами и т. п.

Реализация протоколов TCP/IP оказалась наиболее удачной в версиях BSD4.2 и BSD4.3 операционной системы UNIX. Эта реализация является эталоном для всех последующих.

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

ARPANET была исследовательской сетью, финансируемой Министерством обороны США. В конце концов она объединила сотни университетов и правительственных зданий при помощи выделенных телефонных линий. Когда впоследствии появились спутниковые сети и радиосети, возникли большие проблемы при объединении с ними других сетей с помощью имеющихся протоколов. Понадобилась новая эталонная архитектура. Таким образом, возможность объединять различные сети в единое целое являлась одной из главных целей с самого начала. Позднее эта архитектура получила название эталонной модели TCP/IP в соответствии со своими двумя основными протоколами.

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

Source(s): Компьютерные сети

Стеки протоколов

Стеки протоколов

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

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

Пакеты сетевого протокола IP могут содержать код, указывающий, какой именно протокол следующего уровня нужно использовать, чтобы извлечь данные из пакета. Это число — уникальный IP-номер протокола. ICMP и IGMP имеют номера, соответственно, 1 и 2. Как система узнает, кому отдать пришедший пакет выше? Ведь на верхнем уровне может быть несколько протоколов. На межсетевом уровне эту проблему решает IP-код верхнего протокола, на транспортном – номер порта.

UDP (IP идентификатор 17) (служба ненадежной, но быстрой, передачи) – протокол передачи датаграмм без установления соединения. Также его называют протоколом «ненадёжной» передачи, в смысле невозможности удостовериться в доставке сообщения адресату, а также возможного перемешивания пакетов. Однако UDP-датаграммы имеют поле контрольная сумма сообщения, что гарантирует правильность доставки сообщения, в случае, если оно дошло до адресата.

TCP (IP идентификатор 6) (служба надежной передачи данных, устанавливающей логическое соединение) – «гарантированный» транспортный механизм с предварительным установлением соединения, предоставляющий приложению надёжный поток данных, дающий уверенность в безошибочности получаемых данных, перезапрашивающий данные в случае потери и устраняющий дублирование данных. TCP позволяет регулировать нагрузку на сеть, а также уменьшать время ожидания данных при передаче на большие расстояния. Более того, TCP гарантирует, что полученные данные были отправлены точно в такой же последовательности.

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

HTTP – протокол TCP-порт 80 или 8080.

Важнейшим направлением стандартизации в области вычислительных сетей является стандартизация коммуникационных протоколов. В настоящее время в сетях используется большое количество стеков коммуникационных протоколов. Наиболее популярны следующие стеки: TCP/IP, IPX/SPX, NetBIOS/SM, DECnet, SNA, OSI.

Все эти стеки, кроме SNA на нижних уровнях — физическом и канальном, — используют одни и те же хорошо стандартизованные протоколы Ethernet, Token Ring, FDDI и ряд других, которые позволяют задействовать во всех сетях одну и ту же аппаратуру. Зато на верхних уровнях все стеки работают по своим протоколам. Эти протоколы часто не соответствуют рекомендуемому моделью OSI разбиению на уровни. В частности, функции сеансового и представительного уровня, как правило, объединены с прикладным уровнем. Такое несоответствие связано с тем, что модель OSI появилась как результат обобщения уже существующих и реально используемых стеков, а не наоборот.

Приведены основные используемые в сетях Windows 2000 стеки протоколов. Для функционирования Windows 2000 достаточно стека TCP/ IP — стандарта передачи в сети Интернет. Поддерживаются также стек IPX/SPX — стек маршрутизируемых протоколов, появившийся в сетях NetWare, Microsoft — версия которого называется NWLink, а также NetBIOS/SMB — стек небольших и быстрых, но немаршрутизируемых протоколов.

Source(s): Компьютерные сети

Принципы работы служб прикладного уровня

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

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

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

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

Cетевой адрес процесса – это пара «IP адрес: номер порта» (например, 127.0.0.1: 80).

От 1 до 1023 – хорошо известные номера портов, от 1023 до 65 535 – другие.

По сетевому номеру сообщения, полученного по сети, ОС узнает какому процессу его передать.

Source(s): Компьютерные сети

Cетевое взаимодействие процессов

Процесс обращается к службам транспортного уровня: TCP и UDP.

Клиентская сторона приложения (службы).

Серверная сторона приложения (службы).

Протокол.

Клиенты и серверы – программы, т.е. процессы.

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

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

Примеры служб и протоколов. WWW (HTTP, 80), E-mail (SMTP, 25; POP3, 110; IMAP, 143), DNS (DNS, 53), FTP (FTP, 21,20), Telnet (Telnet, 23); SSH (SSH, 22), синхронизация часов (NTP, 123), передача мультимедиа (RTSP, 554), совместный доступ к файлам (SMB, 445 или NFS, 2049), DNS (Domain Name System), NTP (Network Time Protocol), RTSP (потоковый протокол реального времени (Real Time Streaming Protocol)), SMB (server message block) (см. Samba), NFS (network file system).

Прикладной уровень

Службы разрешения имен

• Файл hosts.txt – файл статического сопоставления имен компьютеров и их ip-адресов.
• Служба разрешения имен NetBIOS и ее реализация в Windows – WINS (Windows Internet Naming Service).
  • Файл lmhosts – файл статического сопоставления NetBIOS-имен и ip-адресов.
• DNS' (Domain Name System) – стандартная служба разрешения имен в Интернет.

Файлы hosts и lmhosts находятся в C:\WINDOWS\system32\drivers\etc\

Доменные имена компьютеров

Каждый компьютер в Интернете имеет свой IP-адрес. Сейчас распространены IP-адреса версии 4. Они представляют собой 4 числа, каждое из которых от 0 до 255. Такой адрес удобен при маршрутизации, так как определяет месторасположение компьютера в сети Интернет, однако, такие числа совсем неудобны для восприятия человеком. Более того, если, например, ваш e-mail: sasha007@207.176.39.176 и ваша почтовая служба решила сменить сервер, то вместе с ним изменится и e-mail. Гораздо лучше, когда компьютер имеет мнемоническое имя, например, mail.ru, sasha007@mail.ru. Существует файл hosts (и в UNIX, и в Windows), в котором можно прописывать адреса серверов, с которыми вы регулярно работаете.

Доменные имена компьютеров

DNS — иерархическая структура имен. Существует «корень дерева» с именем "." (точка). Так как корень един для всех доменов, то точка в конце имени обычно не ставится, но используется в описаниях DNS. Ниже корня лежат домены первого уровня.

Домены верхнего уровня разделяются на две группы: родовые домены и домены государств. К родовым относятся домены com (commercial — коммерческие организации), edu (educational — учебные заведения), gov (government — федеральное правительство США), int (international — определенные международные организации), net (network — сетевые операторы связи) и org (некоммерческие организации). За каждым государством в соответствии с международным стандартом ISO 3166 закреплен домен государства. Ниже находятся домены второго уровня, например, sfedu.ru. Еще ниже — третьего (math.sfedu.ru) и т.д.
В ноябре 2000 года ICANN было утверждено 4 новых родовых имени доменов верхнего уровня, а именно: biz (бизнес), info (информация), пате (имена людей) и pro (специали-сты, такие как доктора и адвокаты). Кроме того, по просьбе соответствующих отраслевых организаций были введены еще три специализированных имени доменов верхнего уровня: aero (аэрокосмическая промышленность), coop (кооперативы) и museum (музеи). В буду-щем появятся и другие домены верхнего уровня. Можно регистрировать домены на кириллице, вот пример работающего сайта: http://цюрих.com/. В конце 2008г. появится домен верхнего уровня .РФ. В принципе, получить домен второго уровня типа name-of-company.com несложно. Надо лишь проверить, не занято ли желаемое имя домена кем-то другим и не является ли оно чьей-нибудь торговой маркой

Имена доменов нечувствительны к изменению регистра символов. Так, например, edu и EDU означают одно и то же. Обычно разрешается регистрация доменов длиной до 63 символов, а длина полного пути не должна превосходить 255 символов. Размер доменного имени ограничивается по административным и техническим причинам.

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

Служба трансляции имен DNS

Клиенты DNS – специализированные библиотеки (или программы) для работы с DNS (в Windows – служба «DNS-клиент»).

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

Порт сервера – 53.

Серверное ПО: Berkeley Internet Name Domain (BIND) (демон named), NSD (name server daemon), Windows DNS Server

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

В общих чертах система DNS применяется следующим образом. Для преобразования имени в IР-адрес прикладная программа обращается к библиотечной процедуре, называющейся распознавателем, передавая ей имя в качестве параметра. Распознаватель посылает UDP-пакет локальному DNS-серверу, который ищет имя в базе данных и возвращает соответствующий IР-адрес распознавателю, который, в свою очередь, передает этот адрес вызвавшей его прикладной программе. Имея IР-адрес, программа может установить TCP-соединение с адресатом или послать ему UDP-пакеты.

Система DNS не только отыскивает IP-адрес по заданному имени хоста, но способна выполнять и обратную операцию, т.е. по IP-адресу определять имя хоста в сети. Многие веб- и FTP-серверы в сети Internet ограничивают доступ на основе домена, к которому принадлежит обратившийся к ним клиент. Получив от клиента запрос на установку соединения, сервер передает IP-адрес клиента DNS-серверу как обратный DNS-запрос. Если клиентская зона DNS настроена правильно, то на запрос будет возвращено имя клиентского хоста, на основе которого затем принимается решение о том, допустить данного клиента на сервер или нет.

Дополнительные функции DNS-сервера

1. Поддержка псевдонимов серверов. Пример: mmcs.sfedu.ru, web.mmcs.sfedu.ru и web.mmcs.rsu.ru имеют один и тот же ip-адрес
2. Поддержка почтового сервера домена.
3. Распределение нагрузки между серверами.
4. Кэширование (авторитетная и неавторитетная информация).
5. Поддержка почтового сервера домена. Можно узнать ip-адрес почтового сервера в домене (используется при пересылке почты).
6. Распределение загрузки между серверами. Одно доменное имя соответствует нескольким серверам, следовательно, по запросу служба может вернуть несколько IP–адресов. Наример, www.microsoft.com обслуживает несколько серверов. При этом первый по списку сервер меняется от запроса к запросу. Системы обычно берут первый IP-адрес. Загрузка происходит одновременно (то к одному серверу – то к другому), но мы, как пользователи, этого не замечаем.

Корневые серверы DNS — это серверы DNS, содержащие информацию о доменах верхнего уровня (edu, org, com, ru, …), конкретнее — указатели на серверы DNS, поддерживающие работу каждого из этих доменов.

Authoritative DNS-server — сервер, отвечающий за какую-либо зону.

Корневые серверы DNS обозначаются латинскими буквами от «A» до «М». Их всего 13 штук (+ куча зеркал). Они управляются различными организациями, действующими по согласованию с ICANN. Количество серверов ограничено в связи с максимальным объёмом UDP-пакета (большее количество серверов потребовало бы перехода на TCP-протокол для получения ответа, что существенно увеличит нагрузку).

У многих корневых серверов DNS существуют зеркала. В частности, российское зеркало сервера F расположено в РосНИИРОС. IP-адреса корневых DNS-серверов можно получить командой «dig. NS» (dig точка NS; точка – корневой домен).

The DNS Backbone DDoS Attacks have been several significant Internet events in which distributed denial of service attacks (DDoS) have targeted one or more of the thirteen DNS root servers. These attacks are extremely significant, as the root nameservers function as the Internet backbone, translating text-based Internet hostnames into IP addresses. As the nameservers provide this service for DNS lookups worldwide, attacks against the root nameservers are attempts to disable the Internet itself, rather than specific websites.

The first attack occurred on October 21, 2002, and lasted for approximately one hour. Of the thirteen servers, nine were disabled but the remaining four were able to cope. This was the second near-major failure of the root nameservers; the first large malfunction of them caused the failure of seven machines in July 1997, due to a technical problem. A second attack occurred on February 6, 2007. The attack began at 10:30 UTC, and lasted about five hours. Although none of the servers crashed, two of the root servers reportedly "suffered badly", while others saw "heavy traffic". The botnet responsible for the attack has reportedly been traced to the Asia-Pacific region. [2] There was some speculation in the press that the attack originated from South Korea. [3] On February 8, 2007 it was announced by Network World that "If the United States found itself under a major cyberattack aimed at undermining the nation’s critical information infrastructure, the Department of Defense is prepared, based on the authority of the president, to launch a cyber counterattack or an actual bombing of an attack source."[4]

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

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

Рассмотрим схему подачи запроса серверу. Студент Стэнфордского университета с университетского компьютера пытается зайти на сайт воскресной школы мехмата sunschool.math.sfedu.ru. Чтобы определить IP-адрес компьютера sunschool.math.sfedu.ru, браузер студента вызывает DNS-клиент (resolver) – функцию API операционной системы. Она, используя IP-адрес локального DNS-сервера из настроек сети на компьютере студента, посылает запрос в виде UDP-пакета DNS-серверу. Пусть сервер будет atalante.stanford.edu.

Предположим, что локальный сервер Стэнфордского университета имен не знает IP-адреса sunschool.math.sfedu.ru. Тогда он посылает запрос одному из корневых серверов, адреса которых содержатся в его базе данных, пусть это будет f.root-servers.net. Таким образом получается рекурсивный запрос: DNS-клиент студента обращается к локальному DNS-серверу, а тот к корневому.

Маловероятно, что корневой сервер знает адрес хоста sunschool.math.sfedu.ru. Скорее всего он даже не знает адреса сервера sfedu.ru, однако он должен знать все свои дочерние домены – домены верхнего уровня. Но продолжать рекурсию он не будет. Дело в том, что корневые домены сильно загружены запросами, поэтому сконфигирированы так, что возвращают список DNS-серверов, которые должны больше знать о sunschool.math.sfedu.ru – это DNS-серверы домена ru. Получив список DNS-серверов, локальный сервер Стэнфордского университета направляет запрос одному из серверов списка (обычно первому), например, ns.ripn.net. Тот тоже загружен и возвращает адреса DNS-серверов дочерней зоны sfedu.ru. Последние два запроса называются итеративными (от слова «итерация»). Затем локальный сервер Станфордского университета обращается к первому в списке серверу домена sfedu.ru. Пусть это будет ns.sfedu.ru. В данном примере оказалось, что он тоже не знает IP-адреса sunschool.math.sfedu.ru. DNS-сервер нашего университета не так загружен, как корневые серверы или серверы доменов верхнего уровня, поэтому его сконфигурировали выполнять рекурсивные запросы. Он обращается к серверу домена math.sfedu.ru – это ns.math.sfedu.ru, получает искомый IP-адрес и возвращает его в ответе локальному серверу Стэнфордского университета, который, в свою очередь, сообщает его компьютеру студента.

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

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

Отметим также, что использование файла hosts лежит в основе многих «ускорителей Интернета» — такие программы просто записывают адреса серверов, к которым вы обращаетесь, в файл hosts и при следующем обращении берут данные из него, не тратя время на запрос к DNS-серверу.

Структура DNS-сообщения

Запросы и ответы имеют один формат и состоят из:

• заголовка, включающего в себя идентификатор, размер сообщения, количество вопросов/ответов и т.д. (12 байтов);
• секции вопросов (название, тип);
• секции ответов (набор RR (resource record) — записей из БД DNS);
• секции полномочности, которая содержит ссылки на полномочные сервера («Не знаю, но знаю у кого спросить»);
• дополнительной информации (IP-адреса тех, у кого можно еще спросить).

Это часть описания DNS-протокола.

Результат, возвращаемый командой dig:

;; ->>HEADER<<-opcode: QUERY, status: NOERROR, id: 42772
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 7, ADDITIONAL: 7

;; QUESTION SECTION:
;sunschool.math.sfedu.ru.        IN   A

;; AUTHORITY SECTION:
ru.           172800 IN   NS   NS9.RIPN.NET.
ru.           172800 IN   NS   AUTH60.NS.UU.NET.
ru.           172800 IN   NS   NS.RIPN.NET.
ru.           172800 IN   NS   NS5.MSK-IX.NET.

;; ADDITIONAL SECTION:
NS.RIPN.NET.      172800 IN   A    194.85.105.17
NS5.MSK-IX.NET.     172800 IN   A    193.232.128.6
NS9.RIPN.NET.      172800 IN   A    194.85.252.62
AUTH60.NS.UU.NET.    172800 IN   A    198.6.1.181

dig @f.root-servers.net sunschool.math.sfedu.ru IN A — спрашиваем у одного из корневых серверов адрес воскресной школы мехмата. Сервер отсылает нас к DNS-серверам зоны ru. Секции ответов нет – она пустая, т.е. корневой сервер не знает адреса воскресной школы. Зато он знает у кого можно спросить еще. В дополнении указаны IP-адреса серверов, у которых можно спросить.

Сервер DNS для Linux

BIND (Berkeley Internet Name Domain) — программный пакет системы DNS для UNIX систем. Функции сервера DNS в этом пакете реализует программа named (от «name daemon»). На большинстве корневых серверов стоит BIND.

Конфигурационные файлы:
/etc/host.conf – определяются методы и порядок преобразования имен ОС Linux;
/etc/named.conf – опции программы named и список файлов, в которых находятся описания зон.

Пример файла /etc/host.conf

1 order hosts,bind
2 multi on

В первой строке указывается порядок преобразования имен хостов. Здесь операционной системе Linux указывается, что в первую очередь она должна обращаться к файлу /etc/hosts и искать хост там, а затем попытаться преобразовать имя с помощью системы DNS (bind), если не удалось этого сделать с помощью /etc/hosts.

Пример файла /etc/named.conf для кэширующего DNS-сервера

1 options {
2 directory "/var/named;
3 };
4
5 zone "." {
6 type hint;
7 file "root.cache";
8
9 };
10
11
12 zone "localhost" {
13 type master;
14 file "pri/localhost";
15 };
16
17 zone."0.0.127.in-addr.arpa" {
18 type master;
19 file "pri/127.0.0";
20 };

Дополнения к файлу /etc/named.conf с описанием зоны:

1 zone smallorg.org {
2 type master
3 file "pri/smallorg.org";
4 };
5
6 zone 0.163.192 in -addr.arpa {
7 type master;
8 file "pri/192.168.0";
9 };

Типы записей в базе данных DNS-сервера

Типы записей в базе данных DNS-сервера

DNS-сервер, отвечающий за имена хостов в своей зоне, должен хранить информацию о хостах в базе данных и выдавать ее по запросу с удаленных компьютеров. База данных DNS представляет собой текстовый файл, состоящий из исходных записей RR. Эти записи описывают компьютеры и их функции в локальной зоне. Для организации обмена информацией с удаленными серверами DNS на сервере Linux должно быть запущено программное обеспечение сервера DNS (обычно это программа named).

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

Зона и серверы имен

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

Консорциум Всемирной паутины

С 1994 года основную работу по развитию Всемирной паутины взял на себя Консорциум Всемирной паутины (англ. World Wide Web Consortium, W3C), основанный и до сих пор возглавляемый Тимом Бернерсом-Ли. Данный Консорциум — организация, разрабатывающая и внедряющая технологические стандарты для Интернета и Всемирной паутины. Миссия W3C: «Полностью раскрыть потенциал Всемирной паутины, путём создания протоколов и принципов, гарантирующих долгосрочное развитие Сети». Две другие важнейшие задачи Консорциума — обеспечить полную «интернационализацию Сети» и сделать Сеть доступной для людей с ограниченными возможностями.

W3C разрабатывает для Интернета единые принципы и стандарты (называемые «Рекомендациями», англ. W3C Recommendations), которые затем внедряются производителями программ и оборудования. Таким образом достигается совместимость между программными продуктами и аппаратурой различных компаний, что делает Всемирную сеть более совершенной, универсальной и удобной. Все Рекомендации Консорциума Всемирной паутины открыты, то есть не защищены патентами и могут внедряться любым человеком без всяких финансовых отчислений консорциуму.

Клиенты WWW

URL

Веб-браузеры

Веб-браузер (Web browser) 3 это программа для запросов и отображения вебстраниц, и перехода от одной страницы к другой.

URL (Uniform Resourse Locator) — универсальный адрес ресурса.

Acid3 — тест поддержки браузером веб-стандартов. Он осуществляет проверку 100 вероятно уязвимых мест в HTTP, HTML, CSS, ECMAScript, SVG и XML, а также проверяет работу с DOM. Намеренно выбирались такие тесты, которые не проходила сборка хотя бы одного из браузеров того времени (последние 16 тестов — Firefox или Safari).

Другие клиенты

• Мобильный телефон может получить доступ к ресурсам веб-сервера.
• Другие интеллектуальные устройства или бытовая техника.
• Специальное программное обеспечение может самостоятельно обращаться к веб-серверам для получения обновлений или другой информации.

Веб-серверы

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

Дополнительные функции веб-серверов

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

Стандартный порт: 80/TCP (8080).

Популярные веб-серверы

• Apache;
• Microsoft Internet Information Services (IIS);
• nginx;

Cвободный веб-сервер, пользующийся большой популярностью на крупных сайтах (yandex.ru).

• lighttpd

Cвободный веб-сервер, разрабатываемый с расчётом на быстроту и защищённость, а также соответствие стандартам (ya.ru).

Установка и настройка Apache

Файл apache\conf\httpd.conf
ServerName localhost
AddDefaultCharset windows-1251
Listen 80
DirectoryIndex index.php index.htm index.html

HomServ — дистрибутив для Microsoft Windows, включающий Apache, PHP, MySQL, phpMyAdmin.
Denwer — дистрибутив для Microsoft Windows, включающий Apache.
Apache после установки создает каталог, где хранятся странички.

Протокол HTTP (HyperText Transfer Protocol)

Порядок запроса страницы http://www.math.rsu.ru/index.html:

1. Браузер определяет IP-адрес сервера, по известному имени из URL.
2. Устанавливает TCP-соединение с сервером.
3. Отправляет текстовый запрос:

   GET /index.html HTTP/1.1
   User-Agent: Opera/9.24 (Windows NT 5.1; U; ru)
   Host: www.math.rsu.ru
   Connection: Keep-Alive

4. Сервер получает запрос и находит требуемый ресур.

Рассмотрим запрос поробнее.
GET – команда веб-серверу (тип запроса). Такие команды называются «методами».
/index.html – URI (Uniform Resource Identifier) – имя ресурса.
HTTP/1.1 – протокол HTTP версии 1.1.
Host: www.math.rsu.ru.
Connection: Keep-Alive – не разрывать TCP-соединение (еще есть close).

Протокол HTTP версии 1.0 поддерживал только непостоянные соединения. Для веб-страницы, состоящей, например, из текста и 10 картинок в случае непостоянного соединения приходится 11 раз устанавливать и разрывать TCP-соединения, а это долгая процедура (см. лекцию про TCP, транспортный уровень). В HTTP 1.1 добавили возможность устанавливать постоянные соединения, да еще с конвейеризацией. В соединениях без конвейеризации клиент посылает запрос серверу после того как закончит прием текущего объекта. В соединениях с конвейеризацией клиент запрашивает объекты (например, картинки) сразу после обнаружения ссылки на них в HTML-документе, не дожидаясь окончания приема текста.

При помощи сниффера (например, Wireshark) можно получить данные реальных запросов:

Приведем пример запроса браузера:

GET /index.html HTTP/1.1 // обязательная строка
User-Agent: Opera/9.24 (Windows NT 5.1; U; ru)
Host: www.math.rsu.ru // обязательная строка
Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
Accept-Language: ru,en;q=0.9
Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1
Connection: Keep-Alive

Ответ сервера мехмата: <pre><nowiki>HTTP/1.1 200 OK Date: Mon, 07 Jul 2008 15:10:06 GMT Server: Apache/1.3.37 (Unix) mod_perl/1.29 PHP/4.4.6 mod_ssl/2.8.28 OpenSSL/0.9.8e rus/PL30.22 Last-Modified: Tue, 17 Jun 2008 12:22:22 GMT ETag: "73619c-1d0d-4857ac7e" Accept-Ranges: bytes Content-Length: 7437 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title>Учебно-научный центр "Механика. Математика"</title> и т.д.</nowiki></pre>

HTTP-ответ сервера

Сервер формирует ответ, состоящий из заголовка и тела.

'''HTTP/1.1 200 OK
Server: Apache/1.3.37 (Unix) mod_perl/1.29 PHP/4.4.6 
Last-Modified: Tue, 17 Jun 2008 12:22:22 GMT
Content-Length: 7437
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html'''

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html><head> <title>Учебно-научный центр "Механика. Математика"...

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

Коды ошибок, возвращаемых веб-сервером.

200 OK: Запрос успешно обработан, объект получен и включен в ответ.
301 Moved Permanently: Объект был перемещен; новый URL-адрес указан в строке ответа Location:. Программа клиента автоматически выполнит запрос по новому адресу.
400 Bad Request: Общая ошибка, вызванная невозможностью интерпретации запроса сервером.
404 Not Found: Запрашиваемый документ не найден на сервере.
505 HTTP Version Not Supported: Указанная в запросе версия HTTP не поддерживается сервером.

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

Рендеринг – процесс отображения страницы.

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

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

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

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

CGI-приложения

CGI (Common Gateway Interface) — стандарт обмена данными между прикладной программой, выполняемой по запросу пользователя, и HTTP-сервером, который данную программу запускает.

Данные передаются программе:

• через переменные окружения;
• на стандартный вход.

Программа передает данные серверу через стандартный выход. Формат такой же как у HTTP-ответа.

Common Gateway Interface — «общий интерфейс шлюза». Здесь Gateway (шлюз) — программа, которая работает по такому интерфейсу совместно с веб-сервером (многие предпочитают названия «скрипт» (сценарий) или «CGI-программа»).

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

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

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

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

В веб-сервере Apache, например, такая настройка может производится при помощи общего файла настроек httpd.conf или с помощью файла.htaccess в том каталоге, где содержится этот скрипт. Также Apache позволяет запускать все скрипты, имеющие расширение.cgi.

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

GET – запрашивает содержимое указанного ресурса. В случае наличия у ресурса параметров, они передаются в URI: http://www.example.net/resource?param1=value1&param2=value2 POST – передает пользовательские данные (например, из HTML-формы) заданному ресурсу HEAD – запрашивает заголовок указанного ресурса PUT – загружает указанный ресурс на сервер DELETE – удаляет указанный ресурс

Методы

• OPTIONS

Возвращает методы HTTP, которые поддерживаются сервером. Этот метод может служить для определения возможностей веб-сервера.

• GET

Запрашивает содержимое указанного ресурса. Запрашиваемый ресурс может принимать параметры (например, поисковая система может принимать в качестве параметра искомую строку). Они передаются в строке URI (например: http://www.example.net/resource? param1=value1&param2=value2). Параметры – это и есть данные от клиента: имя и пароль, строка запроса к поисковой системе и т.п. Согласно стандарту HTTP, запросы типа GET считаются идемпотентными — многократное повторение одного и того же запроса GET должно приводить к одинаковым результатам (при условии, что сам ресурс не изменился за время между запросами). Это позволяет кэшировать ответы на запросы GET.

• HEAD

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

• POST

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

• PUT

Загружает указанный ресурс на сервер.

• DELETE

Удаляет указанный ресурс.

• TRACE

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

• CONNECT

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

В основном используются методы GET и POST.

Метод POST

После нажатия на кнопку «отправить» браузер посылает серверу сообщение. Приводим реальные данные, перехваченные сниффером. Запрос браузера к серверу, установленному на этом же компьютере:

(1) POST /action.php HTTP/1.1 
(2) Host: test1.ru
(3) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.11) Gecko/20070324 (Debian-1.8.0.11-2) Epiphany/2.14 
(4) Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
(5) Accept-Encoding: gzip,deflate
(6) Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
(7) Keep-Alive: 300
(8) Connection: keep-alive
(9) Referer: http://test1.ru/
(10) Content-Type: application/x-www-form-urlencoded 
(11) Content-Length: 18
(12)
(13) name=sergey&age=26

(1) action.php — это программа на сервере, которой передаются введенные данные. По этим данным она сгенерирует html-страницу, которая затем будет отправлена сервером браузеру.

(3) Это браузер ОС Linux Debian, установленной у клиента на виртуальной машине. Виртуальной машиной пришлось воспользоваться, так как сниффер не может перехватить запрос от браузера на локальной машине направленный к серверу на той же машине, т.е. через интерфейс 127.0.0.1.

(10) Тип передаваемого содержимого.

(11) Размер содержимого.

(12) Содержимое.

Приведем код HTML-странички (об HTML будем говорить позже):

<form action="action.php" method="POST">
 Ваше имя: <input type="text" name="name" /><br><br>
 Ваш возраст: <input type="text" name="age" /><br><br>
 <input type="submit" value="Отправить">
</form>

Передача данных CGI-приложению

Передача данных CGI-приложению может осуществляться методами GET и POST.

Кодирование и формат отправляемых данных

По умолчанию – application/x-www-form-urlencoded Все символы не из первой половины ASCII заменяются их кодами, например, “a” на “%E0”. Пробелы – на «+», «&» – на «%26».

multipart/form-data – используется для отправки двоичных данных и данных смешанного типа.

Существует два типа кодирования содержания (тела) HTTP-сообщения, которые можно определить в форме:

• application/x-www-form-urlencoded
• multipart/form-data

Первый тип кодирования выбирается по умолчанию и является основным способом. В URL документа можно использовать только символы набора Latin1. Это первая половина таблицы ASCII за вычетом первых 20 символов. Все остальные символы заменяются своими шестнадцатеричными эквивалентами. Кроме того, такие символы, как "+" или "&", играют роль разделителей или коннекторов. Если они встречаются в значении поля, то тоже заменяются на шестнадцатеричный эквивалент. Наиболее характерно это для работы с русским алфавитом. Поэтому скрипт, который принимает запросы, должен уметь эти символы декодировать.

Второй тип применяется для передачи двоичной информации в теле HTTP-сообщения. Если проводить аналогии с электронной почтой, то multipart/form-data обеспечивает присоединение файла данных (attachment) к HTTP-запросу. Наиболее типичным примером является передача файла с машины пользователя на сервер:

<FORM ACTION=script.cgi METHOD=post 
   ENCTYPE=multipart/form-data>
<INPUT NAME=n1 VALUE="Поле1">
<INPUT NAME=n2 TYPE=file>
<INPUT TYPE=BUTTON VALUE="Отправить">
</FORM>

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

Сообщение типа "multipart/form-data" состоит из нескольких частей, каждая их которых представляет успешный управляющий элемент. Части отправляются обрабатывающему агенту в том порядке, в котором соответствующие управляющие элементы представлены в потоке документа. Границы частей не должны находиться в данных.

Как и во всех составных типах MIME, каждая часть имеет необязательный заголовок "Content-Type", для которого по умолчанию устанавливается значение "text/plain". Агенты пользователей должны предоставлять заголовок "Content-Type" с параметром "charset".

Каждая часть должна содержать:

• заголовок "Content-Disposition", имеющий значение "form-data";
• атрибут именования, определяющий имя соответствующего управляющего элемента. Имена управляющих элементов, изначально закодированные с использованием наборов символов, отличных от ASCII, могут кодироваться с помощью метода, описанного в [RFC2045].

application/x-www-form-urlencoded
BigText= TextTextText&pol1= m
multipart/form-data
------------Gt1CO3wAR7XTbm1eE7LoA6
Content-Disposition: form-data; name="BigText "

TextTextText

------------Gt1CO3wAR7XTbm1eE7LoA6
Content-Disposition: form-data; name="pol1 "

m
------------Gt1CO3wAR7XTbm1eE7LoA6--

multipart/form-data – для отправки больших объемов данных или двоичных файлов

Пример CGI-скрипта (GET) на PascalABC

s:=Environment.GetEnvironmentVariable('QUERY_STRING');
writeln(file,'Переменная окружения QUERY_STRING: ',s);
writeln('Content-Type: text/html');
writeln(‘');
writeln('<html> <head> <title> OK </title> </head> <body> <h1> Введенные в форму данные успешно записаны в файл zapros_get.txt </h1></body>')

Пример CGI-скрипта (POST) на PascalABC

Val(Environment.GetEnvironmentVariable('CONTENT_LENGTH'),n,err);
writeln(file,'Размер: ',n);
writeln(file,'Данные:');
SetLength(s,n);
for i:=0 to n-1 do 
  read(s[i]);
for i:=0 to n-1 do
  write(f,s[i]);
writeln('Content-Type: text/html');
writeln('');
writeln('<html> <head> <title> OK </title> </head> <body> <h1> Введенные в форму данные успешно записаны в файл zapros_post.txt </h1></body>')

Недостатки и альтернативы CGI

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

Альтернативные технологии:

• встроенные в веб-сервер модули (mod_php, mod_perl в Apache);
• Fast CGI.

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

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

В то время как CGI-программы взаимодействуют с сервером через STDIN и STDOUT запущенного CGI-процесса. FastCGI-процессы используют Unix Domain Sockets или TCP/IP для связи с сервером. Благодаря этому, в отличие от обычных CGI-программами, FastCGI-программы могут быть запущены не только на этом же сервере, но и где угодно в сети. Также возможна обработка запросов несколькими FastCGI-процессами, работающими параллельно.

Языки программирования CGI-приложений

• PHP;
• Perl;
• Microsoft ASP.NET (на сервере IIS);
• JSP (Java Server Pages);
• Python;
• Ruby

и любые другие.

Cookies

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

Применяется:

• для отличия пользователей веб-сервером друг от друга;
• для сохранения данных о действиях пользователя.

Cookies были придуманы, чтобы реализовать «Корзину покупателя» — виртуальную корзину, в которую пользователь мог бы добавлять приобретенные на сайте вещи (как в супермаркете), а потом в конце расплачиваться за все.

Еще одна цель создания cookie – организация входа (log in) на сайт. Сервер различает пользователей именно по cookie, которые посылают ему браузеры при запросе каждой страницы с сайта.

Сторонние cookies

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

Механизм Cookies

Сервер ( CGI-программа) может установить cookie в ответ на запрос браузера. Для этого в заголовок ответа он добавляет строчку Set-Cookie, например,

Set-Cookie: sessionID=678893467800; lang= ru; domain=mydomain.com; expires=09-Nov-08 23:12:40

Браузер соxраняет cookie и затем посылает на этот сервер в виде строки Cookie в заголовке каждого запроса, например,

Cookie: sessionID=678893467800; lang= ru;

Куки также может быть установлена и самим браузером через JavaScript, который поддерживается большинством современных браузеров. Браузер должен соxранять куки на период определенный для ее времени жизни и посылать куки на сервер в заголовке запроса (request header) Cookie. В запросе посылаются только те куки, которые соответствуют домену, пути и протоколу для которых куки была установлена Клиент (браузер) имеет следующие ограничения для cookies, например: всего может храниться до 300 значений cookies, каждый cookie не может превышать 4Кбайт, с одного сервера или домена может храниться до 20 значений cookie.

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

Язык разметки гипертекста HTML

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

Пример 1. Простейший HTML-документ.

<html> Начало HTML-документа
  <head> Заголовок
  <title>
    Hello HTML  // Появится в заголовке окна рядом с названием браузера
  </title> 
  </head>
  <body>        // Тело документа
    <b>    
      Этот текст будет выведен полужирным,
      <i>а этот ещё и курсивом</i>
    </b>
    <a href="http://www.example.com">Так оформляется гиперссылка</a>
  </body>
</html>

Пример 2

Пример 2. Страница факультета психологии животных.

<html>
  <head> <title>ФПЖ</title> </head>
  <body>
    <h1>Факультет психологии животных</h1>
    <h2> О нас </h2>
    <h2> Персонал </h2>
    <h2> Популярные курсы </h2>
  </body> 
</html>

Регистр, в котором набрано имя элемента и имена атрибутов, в HTML значения не имеет (в отличие от XHTML). Элементы могут быть вложенными.

Кроме элементов, в HTML-документах есть и сущности (англ. entities) — «специальные символы». Сущности начинаются с символа амперсанда и имеют вид &имя; или &#NNNN;, где NNNN — код символа в Юникоде в десятеричной системе счисления. Например, © — знак авторского права (©). Как правило, сущности используются для представления символов, отсутствующих в кодировке документа, или же для представления «специальных» символов: & — амперсанда (&), < — символа «меньше» (<) и > — символа «больше» (>), которые некорректно записывать «обычным» образом, из-за их особого значения в HTML.

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
  "http://www.w3.org/TR/html4/strict.dtd">

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

Далее обозначается начало и конец документа тегами <html> и </html> соответственно. Внутри этих тегов должны находиться теги заголовка (<head></head>) и тела (<body></body>) документа.

Добавим информацию на страницу факультета психологии животных из второго примера.

Страница факультета психологии животных

<html>
  <head>
    <title>ФПЖ</title>
  </head>
  <body text=#00AA00 bgcolor=#EEFFEE>
    <h1 align=center> 
      <u> Факультет психологии животных </u>
    </h1>
    <h2> О нас </h2>
    <p> Наш факультет занимается... </p>
    <h2> Персонал </h2>
    <ul type=square>
      <li> 
        <a href="http://www.fpj.edu/teachers.html">
          <font color=#00AA00>Преподаватели </font>
        </a>
      </li>
      <li> 
        <a href="http://www.fpj.edu/postgrad.html"> Аспиранты </a> 
      </li>
      <li> 
        <a href="http://www.fpj.edu/muuuu.html"> 
          <b>Неакадемический штат</b>
        </a> 
      </li>
    </ul>
    <h2> Популярные курсы </h2>
Среди наших курсов особой популярностью пользуются <i>"Переговоря с вашей зверюшкой"</i>, <i>"Сооружение собачьей будки"</i>
  </body> 
</html>

Редакторы HTML

• Adobe Dream Weaver;
• Microsoft Expression Web;
• SharePoint Designer (бесплатный);
• Web Development Studio (бесплатная);
• Word;
• Microsoft Front Page (поддержка прекращена).

CSS – каскадные таблицы стилей

CSS1.0 вышла в 1996. Главная цель: заменить многократное использование тегов форматирования на лаконичные CSS-стили.

CSS (англ. Cascading Style Sheets — каскадные таблицы стилей) — технология описания внешнего вида документа, написанного языком разметки. Преимущественно используется как средство оформления веб-страниц в формате HTML и XHTML, но может применяться с любыми видами документов в формате XML, включая SVG и XUL.

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

CSS при отображении страницы может быть взята из различных источников:

1. внешних таблиц стилей, то есть отдельного файла.css, на который делается ссылка в документе.
2. встроенных стилей — блоков CSS внутри самого HTML-документа. Данный способ определения стилей идеально подходит для корректировки или внедрения стилей в отдельные HTML-документы, так как не затрагивает другие HTML-документы.
3. inline-стилей, когда в HTML-документе информация стиля для одного элемента указывается в его атрибуте style.
4. стандартный стиль, используемый браузером по умолчанию для представления элементов.

Стандарт CSS определяет приоритеты, в порядке которых применяются правила стилей, если для какого-то элемента подходят несколько правил одновременно. Это называется «каскадом», в котором для правил рассчитываются приоритеты или «веса», что делает результаты предсказуемыми.

Описание стиля

s1 [,s2] 
{
 св-во1: знач1;
 св-во2: знач2;
 св-во3: знач3;
}

Оформление:

p { font-size: 20px;}

h2  { 
 font-size: 110 %;
 font-weight: bold;
 color: red;
 }

Все ниже касается внешнего или встроенного описания стиля. Inline-описание выглядит так: <p style="font-size: 21px; color: green;">Текст абзаца</p>

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

Схематически это можно показать так:

селектор, селектор {
 свойство: значение;
 свойство: значение;
 свойство: значение;
}

Например:

p {
 font-family: "Garamond", serif;
}
h2 {
 font-size: 110 %;
 color: red;
 background: white;
}
.note {
 color: red;
 background: yellow;
 font-weight: bold;
}
p#paragraph1 {
 margin: 0;
}
a:hover {
 text-decoration: none;
}
#news p {
 color: blue;
}

Здесь приведено шесть правил с селекторами p, h2,.note, p#paragraph1, a:hover и #news p.

В первых двух правилах HTML-элементам p (параграфу) и h2 (заголовку второго уровня) назначаются стили. Параграфы будут отображаться шрифтом Garamond, или, если такой шрифт недоступен, каким-либо другим шрифтом с засечками («serif»). Заголовок второго уровня будет отображаться красным на белом фоне с увеличенным кеглем.

Третье правило будет применено к элементам, атрибут class которых содержит слово 'note'. Например:

Этот параграф будет выведен полужирным шрифтом красного цвета на желтом фоне.

Четвертое правило будет применяться только к элементам p, атрибут id которых равен paragraph1. Такие элементы не будут иметь внешних отступов (margin).

Пятое правило определяет стиль hover для гиперссылок. По умолчанию в большинстве браузеров текст гиперссылок подчеркивается. Это правило уберёт подчеркивание, когда указатель мыши находится над ними.

Последнее, шестое правило, применяется для элементов p, которые находятся внутри элемента с атрибутом id, равным «news».

Когда CSS используется вместе с XHTML, имена элементов и селекторы становятся чувствительны к регистру.

До изобретения CSS нужного расположения элементов на веб-странице добивались, применяя невидимые таблицы и массу тегов типа &nbsp. В CSS можно явно указывать расположение элементов.

Способы связывания с документом

Внешние таблицы стилей – в отдельном css-файле. Связывается с HTML-документом командой <link rel="stylesheet" href="/templates/template.css" type="text/css" /> внутри заголовка.

Встроенные – в теге <style> в заголовке HTML-документа Inline: <tag_name style="декларация стиля ”…>

Пример использования CSS

HTML:
<p class=“mystyle1”>текст абзаца</p>
CSS-файл:
.mystyle1  {  color: red;  background: yellow;  font-weight: bold;  }

JavaScript

Программы на JavaScript встраиваются в веб-страницу и могут как угодно менят ее содержимое.

JavaScript: пример

<script language="JavaScript">
 function FirstFunction() 
   { document.myForm1.myText.value ="Вы нажали первую кнопку";}
 function SecondFunction() 
   { document.myForm1.myText.value ="Вы нажали вторую кнопку";}
</script>
<form name="myForm1">
 <input type="text" name="myText" size=30 value="Нажмите одну из кнопок"><p>
 <input type="button" name="Button1" value="Первая кнопка"
 onclick="FirstFunction(); return true;">
 <input type="button" name="Button2" value="Вторая кнопка" onclick="SecondFunction(); return true;">
</form>

DOM

DOM (Document Object Model — объектная модель документов) — это не зависящий от платформы и языка программный интерфейс, позволяющий программам и скриптам получить доступ к элементам документа, а также изменять содержимое, структуру и оформление документа.

HTML-документ имеет иерархическую структуру, которая представлена в DOM в виде дерева, узлами которого являются теги и текст. Вложенным HTML-тегам соответствуют вложенные узлы дерева.

Модель DOM не накладывает ограничений на структуру документа. Любой документ известной структуры с помощью DOM может быть представлен в виде дерева узлов, каждый узел которого содержит элемент, атрибут, текстовый, графический или любой другой объект. Узлы связаны между собой отношениями родитель-потомок.

Изначально различные браузеры имели собственную модель DOM, не совместимую с остальными. Для того, чтобы обеспечить взаимную и обратную совместимость, специалисты международного консорциума W3C классифицировали эту модель по уровням, для каждого из которых была создана своя спецификация. Все эти спецификации объединены в общую группу, носящую название W3C DOM.

Пример.

HTML-код	Объектная модель документа
<html> <head> <title>ФПЖ</title> </head> <body> <h1>Факультет психологии животных</h1> <h2>О нас</h2> <h2>Персонал</h2> </body> </html>

Это дерево представляет собой нормализованный DOM, в котором не создаются узлы из пустого текста. Такого подхода придерживается браузер Internet Explorer. Firefox другого мнения, он создает DOM-элемент из каждого текстового фрагмента. Внутри <body>, между тегами <body> и <h1>, </h1> и <h2>, </h2> и <h2>, </h2> и </body> можно ведь помещать любой текст. Этим пустым местам соответствуют узлы дерева слева и справа от <h1> и <h2>. Opera же может добавить лишний пустой элемент просто «от щедрой души». На практике эта несовместимость не создает больших проблем, но нужно о ней помнить и делать необходимые проверки.

У каждого узла в DOM-модели есть тип. Всего в DOM различают 12 типов узлов. Его номер типа хранится в атрибуте elem.nodeType. Часто используются: Node.ELEMENT_NODE, номер которого равен 1. Узлам этого типа соответствуют HTML-тэги. Иногда полезен еще тип Node.TEXT_NODE, номер которого равен 3. Это текстовые элементы.

Любой доступ и изменения DOM происходит через объект document. Например: document.body. Свойства firstChild и lastChild показывают на первый и последний дочерние элементы и равны null, если детей нет. Свойство parentNode указывает на родителя. Например, для <body> таким элементом является <html>. Свойства previousSibling и nextSibling указывают на левого и правого братьев узла.

Некоторые из свойств элементов доступны только на чтение, другие — на чтение и запись. Например, свойство tagName есть у элементов-тэгов, содержит имя тэга в верхнем регистре и доступно только для чтения. style — свойство управляющее CSS-стилем, оно доступно на запись, например, можно установить element.style.width=50px. innerHTML содержит весь HTML-код внутри узла, и его можно менять. Применяется, в основном, для динамического изменения содержания страницы. onclick, onkeypress, onfocus... и другие свойства, начинающиеся на «on», хранят функции-обработчики соответствующих событий.

AJAX

AJAX (Asynchronous Javascript and XML — асинхронный JavaScript и XML) — подход к построению интерактивных пользовательских интерфейсов веб-приложений, заключающийся в «фоновом» обмене данными браузера с веб-сервером. В результате при обновлении данных веб-страница не перезагружается полностью, и веб-приложения становятся более быстрыми и удобными.

CMS

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

Электронная почта

Основные компоненты эектронной почты

• почтовые клиенты пользователей;
• почтовые серверы;
• протокол отправки почты: SMTP;
• протоколы доступа к почтовому ящику: POP3 или IMAP.

MS Outlook

Mozilla Thunderbird

The Bat

Клиенты

Функции клиента

• отправка и получение почты;
• создание, редактирование писем;
• просмотр писем.

Популярные клиенты

• Microsoft Outlook (входит в MS Office);
• Mozilla Thunderbird (бесплатная);
• The Bat (платная).

Почтовые серверы

Функции сервера

• хранение писем пользователей (почтовые ящики);
• отправка писем почтовому серверу получателя или клиенту пользователя (MTA, MDA);
• организация очереди сообщений.

Используют протокол TCP. Стандартные порты: 25 — SMTP, 110 — POP3, 143 — IMAP.

Почтовый сервер, сервер электронной почты, мейл-сервер — в системе пересылки электронной почты так обычно называют агент пересылки сообщений (англ. mail transfer agent, MTA). Это компьютерная программа, которая передаёт сообщения от одного компьютера к другому.

Обычно почтовый сервер работает «за кулисами», а пользователи имеют дело с другой программой — клиентом электронной почты (англ. mail user agent, MUA).

MDA (Mail Delivery Agent, агент доставки сообщений) — программа, доставляющая сообщения на электронный ящик получателя.

К примеру, в распространённой конфигурации агентом пользователя является Outlook Express. Когда пользователь набрал сообщение и посылает его получателю, почтовый клиент взаимодействует с почтовым сервером, используя протокол SMTP. Почтовый сервер отправителя взаимодействует с почтовым сервером получателя (напрямую или через промежуточный сервер-релей). На почтовом сервере получателя сообщение попадает в почтовый ящик, откуда при помощи агента доставки сообщений доставляется клиенту получателя. Часто последние два агента совмещены в одной программе (к примеру, sendmail), хотя есть специализированные MDA, которые в том числе занимаются фильтрацией спама. Для финальной доставки полученных сообщений используется не SMTP, а другой протокол — часто POP3 или IMAP — который также поддерживается большинством почтовых серверов. Хотя в простейшей реализации MTA достаточно положить полученные сообщения в личный каталог пользователя в файловой системе центрального сервера («почтовый ящик»).

Популярные серверы

• Sendmail (бесплатный, Linux / Windows)
  Подробнее  

  

  ExchangeServer Sendmail
• qmail (бесплатный, Linux)
  Подробнее  

  

  Qmail

  Программный пакет qmail, написанный Дэном Бернстейном (Dan Bernstein), является полноценным заменителем программного пакета sendmail. Основное внимание при его создании уделялось вопросам надежности и безопасности — двум довольно впечатляющим целям. Дэн организовал в Internet свой сервер на базе qmail и объявил приз в $1000 тому, кто сможет взломать его защиту. На момент написания книги никто не обратился за этой премией. Кроме того, в qmail предлагается улучшенный метод помещения корреспонденции в электронные почтовые ящики пользователей с использованием нового формата почтового ящика, более устойчивого к сбоям в системе. Возможно, главным преимуществом qmail является простота конфигурирования. Для ее настройки используются простые текстовые файла в формате ASCII. Программа qmail является удачным выбором для простого почтового сервера.

• Microsoft Exchange Server
  Подробнее  

  

  Microsoft Exchange Server

  Платформа для организации корпоративной системы электронной почты и групповой работы от корпорации Microsoft. Ориентирована, прежде всего, на крупных заказчиков, однако имеется и версия для небольших предприятий (в составе Microsoft Windows Small Business Server). Главная особенность продукта — тесная интеграция с инфраструктурой Microsoft и, в частности, со службой каталогов Active Directory.

• Postfix
  Подробнее  

  

  Postfix

  Система Postfix была создана Вейтсом Венемой (Wietse Venema), разработчиком исследовательского центра IBM им. Томаса Уотсона (IBM Thomas J. Watson Research Center), в конце 90-х годов прошлого века. Задумывалась как более простая, безопасная и быстрая альтернатива Sendmail. Postfix имеет продуманную модульную архитектуру — каждый модуль (демон) отвечает за минимальный набор простых функций. Как следствие, обеспечивается изолированность процессов (что положительно сказывается на безопасности), а также более высокая скорость работы в режиме простоя (за счет выгрузки ненужных модулей).

• MDA: procmail и maildrop
  Подробнее  

  
  

• Exim
  Подробнее  

  Система Exim была создана в 1995 году сотрудником Университета Кэмбриджа (University of Cambridge) Филиппом Хейзелом (Philip Hazel). Как и Sendmail, Exim имеет монолитную архитектуру, которая считается менее безопасной, чем модульная. Однако в отличие от Sendmail, Exim пока не испытывал серьезных проблем с безопасносностью.

  Ключевая особенность Exim заключается в логичной и прозрачной схеме обработки почты. Создатели продукта отказались от реализации ряда экзотических функций, что положительно отразилось на простоте решения. Кроме того, Exim считается быстрее и безопаснее все того же Sendmail. Exim входит в состав ряда дистрибутивов Linux/Unix систем. Поставляется по свободной лицензии GNU GPL.

Как происходит доставка писем?

Доставка писем

Рассмотрим процесс доставки писем на примере. Пусть Алиса хочет отправить письмо Бобу.

1. Почтовая программа Алисы (т.е. клиент или MUA – Mail User Agent ) отправляет письмо Бобу, ящик которого расположен на почтовом сервере в домене b.org.
2. По протоколу SMTP (Simple Mail Transfer Protocol) клиент Алисы посылает сообщение на ее почтовый сервер (smtp-сервер). Сервер помещает сообщение в очередь для отправки адресату.
3. SMTP-сервер Алисы узнает IP-адрес почтового сервера Боба, делая DNS-запрос типа MX для зоны b.org.
4. SMTP-сервер Алисы по протоколу SMTP посылает почтовому северу Боба сообщение. При этом SMTP-сервер Алисы выступает в роли клиента.
5. Почтовый сервер (Боба) помещает полученное сообщение в почтовый ящик Боба.
6. Почтовый клиент Боба забирает письмо с сервера по протоколу POP3 или IMAP.

Протокол SMTP

Протокол SMTP используется для транспортировки электронной почты на почтовый сервер. Работает поверх TCP, стандартный порт сервера 25. Команды – обычный ASCII текст.

Посылка почты осуществляется в 3 этапа:

1. приветствие (рукопожатие);
2. пересылка писем;
3. закрытие сессии.

Пример SMTP-сессии

Server:220 Mail.Ru ESMTP
Client:         HELO me.ru 
Server: 250 mx24.mail.ru ready to serve 
Client:         MAIL FROM: <I@me.ru> 
Server: 250 OK 
Client:         RCPT TO: <gudasergey@mail.ru> 
Server: 250 OK 
Client:         DATA 
Server: 354 Go ahead 
Client:         Privet, Gena!!! 
                Pozdravlyau tebya s dnem rojdeniya …
                . 
Server: 250 Message accepted for delivery 
Client:         QUIT 
Server: 221 mx24.mail.ru closing connection


$ telnet mxs.mail.ru 25  // подключаемся к 25 порту почтового сервера домена mail.ru
Trying 194.67.23.20...
Connected to mxs.mail.ru.
Escape character is '^]'.
220 Mail.Ru ESMTP                        // приветствие от mxs.mail.ru
HELO me.ru                                       // приветствие от меня ( me.ru -выдумка)
250 mx24.mail.ru ready to serve          // всегда готов! – от mx24.mail.ru
MAIL FROM: <I@me.ru>                     // я: отправляю письмо от себя (почтовый адрес -выдумка)
250 OK                                           //mail.ru:  понятно
RCPT TO: <gudasergey@mail.ru>            // я: получатель – мой почтовый ящик на mail.ru
250 OK                                           //mail.ru: такой почтовый ящик имеется
DATA                                            //я: посылаю данные
354 Go ahead                                    //mail.ru: давай!
Privet, Gena!!!
Pozdravl yau tebya s dnem rojdeniya …    // я: текст письма
.                                                        // я: единственная точка на строке -конец письма
250 Message accepted for delivery        //mail.ru: Сообщение принято для доставки
QUIT                                            //я: конец
221 mx24.mail.ru closing connection     //mail.ru: закрываю соединение

На самом деле было так:

Server:220 Mail.Ru ESMTP
Client:         HELO me.ru 
Server: 250 mx24.mail.ru ready to serve 
Client:         MAIL FROM: <I@me.ru> 
Server: 250 OK 
Client:         RCPT TO: <gudasergey@mail.ru> 
Server: 250 OK 
Client:         DATA 
Server: 354 Go ahead 
Client:         Privet, Gena!!! 
                Pozdravlyau tebya s dnem rojdeniya …
                . 
Server: 550 spam message discarded. If you think that the system is mistaken, please report details to abuse@corp.mail.ru 
Client:         QUIT 
Server: 221 mx24.mail.ru closing connection

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

550 spam message discarded. 
If you think that the system is mistaken, 
please report details to abuse@corp.mail.ru      //mail.ru: это спам! Жалобы посылайте на адрес: 
                                                                // оскорбления @corp.mail.ru

Проблема скрывается в формате нашего письма: отсутствует заголовок с полями From, To и Subject. Поэтому mail.ru расценивает это как спам.

Формат сообщения электронной почты

Сообщение электронной почты – это набор символов в семиразрядной кодировке ASCII (начинается с нуля (0-127)). Символы кодируются битами.

From: <адрес отправителя> // обязательное поле
To: <адрес получателя> // обязательное поле
Subject: <тема> // необязательное поле
CC: <список получателей, которым отправится копия> // необязательное поле
BCC: <список адресов> (это «слепая копия», то есть получатели не знают, что это письмо отправлено еще кому–то) // необязательное поле
<Пустая строка> 
<Текст письма в семибитной кодировке ASCII>

Если требуется передать символы, отличающиеся от ASCII, то используется кодирование. После получения сообщения сервер добавляет в заголовок строчку:

Received: from < отправитель > by < получатель >  < когда >

Пример

From: drug@yandex.ru
To: gena@mail.ru
Subject: Pozdravlyau!

Privet, Gena!!! 
Pozdravlyau tebya s dnem rojdeniya …
.

Кодирование сообщений

MIME (Multipurpose Internet Mail Extension – многоцелевое расширение почты Интернета) — стандарт, описывающий передачу различных типов данных по электронной почте.

В заголовок сообщения добавляются строки:

MIME–Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=“Windows-1251”

Поле заголовка Content-Type идентифицирует данные, заключенные в MIME-сообщение. В настоящее время используется семь основных классов данных, идентифицированных в MIME. В каждом классе имеются свои подклассы, которые более детально характеризуют тип данных, заключенных в сообщении.

Часто встречающиеся значения поля Content -Type (формат: Content -Type: тип / подтип; параметры):

• text / html или text/ enriched (с форматированием);
• image / gif или image/jpeg;
• multipart / mixed (для сообщений с вложениями).

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

Часто встречающиеся значения поля Content–Transfer–Encoding:

• 7bit;
• 8bit;
• binary;
• base64;
• quoted-printable.

Например, 8bit или base 64.

При кодировании увеличивается размер (как минимум, на 25%).

На сегодняшний день существует семь различных способов кодирования двоичных данных, однако наиболее часто встречается кодирование base64. При применении этого метода кодирования 6-битовые блоки двоичных данных преобразуются в 8-битовые блоки, воспринимаемые как текст ASCII. Таким образом, в base 64 для кодирования 3 байтов (24 бита) используются 4 байта (32 бита).

Значения Content-Transfer-Encoding "7bit", "8bit" и "binary" означают, что никакого преобразования не произведено.

Base64. В формате электронной почты MIME base64 — это схема, по которой произвольная последовательность байт преобразуется в последовательность печатных ASCII символов. Это определяет MIME как транспортное кодирование содержимого для использования в электронной почте. Используются только символы латинского алфавита в верхнем и нижнем регистре — символы (A—Z, a—z), цифры (0—9), и символы «+» и «/», с символом «=» в качестве специального кода суффикса.

Полная спецификация этой формы base64 содержится в RFC 1421 и RFC 2045. Эта схема используется для кодирования последовательности октетов (байт). Это соответствует определению файлов почти во всех системах. Результирующие закодированные по base64 данные имеют длину, большую оригинальной в соотношении 4:3, и напоминают по виду случайные символы.

Для того, чтобы преобразовать данные в base64, первый байт помещается в самые старшие восемь бит 24-битного буфера, следующие в средние восемь и третий в младшие значащие восемь бит. Если кодируется менее чем три байта, то соответствующие биты буфера устанавливаются в ноль. Далее каждые шесть бит буфера, начиная с самых старших, используются как индексы строки «ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123 456789+/» и её символы, на которые указывают индексы, помещаются в выходную строку. Если кодируются только один или два байта, используются только первые два или три символа строки и выходная строка дополняется двумя или одним символами «=». Это предотвращает добавление дополнительных битов к восстановленным данным. Процесс повторяется над оставшимися входными данными.

Например, исторический слоган Википедии,

Man is distinguished, not only by his reason, but by this singular passion from other animals, which is a lust of the mind, that by a perseverance of delight in the continued and indefatigable generation of knowledge, exceeds the short vehemence of any carnal pleasure.

закодирован в base64 следующим образом:

TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ5IGhpcyByZWFz b24sIGJ1dCBieSB0
aGlzIHNpbmd1bGFyIHBhc3Npb24gZnJvbSBvdGhlciBhbmltYWxzLCB3aGl jaCBpcyBhIGx1
c3Qgb2YgdGhlIG1pbmQsIHRoYXQgYnkgYSBwZXJzZXZlcmFuY2Ugb2Yg ZGVsaWdodCBpbiB0
aGUgY29udGludWVkIGFuZCBpbmRlZmF0aWdhYmxlIGdlbmVyYXRpb24 gb2Yga25vd2xlZGdl
LCBleGNlZWRzIHRoZSBzaG9ydCB2ZWhlbWVuY2Ugb2YgYW55IGNhcm 5hbCBwbGVhc3VyZS4=

Дополнения (attachments)

From: drug@yandex.ru 
To: gena@mail.ru 
Subject: Pozdravlyau! 
MIME-Version: 1.0 
Content-Type: multipart/mixed; boundary=“----------F9876678DDB9”

----------F9876678DDB9
Content-Type: text/plain; charset=Windows-1251
Content-Transfer-Encoding: 8bit

Privet, Gena!!!... 
----------F9876678DDB9
Content-Type: image/jpg; name=“otkritka.jpg”
Content-transfer-encoding: base64
Content-Disposition: attachment; filename=“otkritka.jpg”

base64 encoded data..... 
----------F9876678DDB9

Доступ к письмам в почтовом ящике

Доступ к письмам в почтовом ящике может осуществляться по протоколам:

• POP3 (Post Office Protocol)

  порт сервера 110;

  авторизация и скачивание сообщений с сервера;

  «толстый почтовый клиент».

• IMAP (Internet Mail Access Protocol [RFC 1730])

  порт сервера 143;

  больше возможностей, более сложный;

  позволяет управлять сообщениями на сервере;

  «тонкий почтовый клиент».

• HTTP

  используется на mail.ru, yandex.ru, gmail.com;

  «сверхтонкий почтовый клиент».

Протокол POP3

S: +OK
C: USER kto_to 
S: +OK Password required for user kto_to
C: PASS 123456
S: +OK
C: STAT
S: +OK 118 6286336
C: LIST 
S: +OK 118 messages (6286336 octets)
  1 1203
  2 534
  3 1200432
  и т.д.

. 

POP 3 – это текстовый протокол.

Команды клиента

Комбинация команд USER/PASS — самая простая в реализации, но в то же время самая опасная с точки зрения безопасности. Каждый раз при соединении клиента с сервером POP3 с целью проверки почты по сети посылается его идентификатор пользователя и пароль в виде текста в формате ASCII. Это просто находка для хакера! Один из выходов – использовать команду APOP и посылать пароль в зашифрованном виде, однако

APOP поддерживают не все серверы (судя по первому ответу сервера, mail.ru не поддерживает APOP. В противном случае он бы послал ключ). Другой выход, используемый gmail.com – безопасные (зашифрованные) соединения по протоколу SSL ( это вдвойне хорошо: от хакеров защищен как процесс авторизации так и прием отдельных сообщений ).

STAT Команда STAT применяется для получения текущего состояния почтового ящика пользователя. LIST Команда LIST используется для получения развернутого листинга почтового ящика. Развернутый листинг представляет собой краткое содержание почтового ящика, включая номер и объем сообщения в байтах. Когда команда LIST задается без параметров, то отображается развернутый листинг всех сообщений в почтовом ящике. Если же использовать в качестве параметров команды номер сообщения, то развернутый листинг будет производиться только для него.

UIDL Необязательная для всех серверов POP3 команда. Благодаря ей все сообщения, хранящиеся на сервере, получают уникальные номера, которые сохраняются для всех сеансов POP3. Как уже говорилось ранее, сообщения нумеруются по порядку в течение сеанса POP3. По завершении клиентом сеанса и с началом нового сеанса сообщения перенумеровываются. Таким образом, если клиент имел в своем ящике десять сообщений и удалил шестое сообщение в течение сеанса, то при следующем сеансе POP3 девять сообщений будут перенумерованы с первого по девятое. Как видите, у клиентского программного обеспечения довольно непростая задача — следить за перенумерацией сообщений. Для решения этой проблемы в некоторые серверы POP3 встроена поддержка команды UIDL или “листинг с уникальным идентификатором”. Каждому сообщению назначается уникальный идентификатор, который представляет собой строку символов формата ASCII (до 70 символов). Этот идентификатор сохраняется за сообщением все время, пока оно находится в почтовом ящике

RETR Команда RETR используется для получения сообщений из почтового ящика на компьютер клиента. Параметр, который можно использовать с этой командой, — это номер сообщения, полученный с помощью команды LIST.

DELE Команда DELE используется для удаления сообщений из почтового ящика на сервере. Единственный параметр, который можно в ней задавать, — это номер сообщения, полученный с помощью команды LIST. Команда DELE физически не удаляет сообщение, она лишь помечает его для удаления. Удаление сообщения происходит лишь после корректного завершения сеанса с помощью команды QUIT.

TOP [сообщение] [количество строк] – есть такая команда! на лекции я ошибся! Сервер возвращает заголовки указанного сообщения, пустую строку и указанное количество первых строк тела сообщения.

QUIT Команда QUIT используется для завершения сеанса POP3. Когда сервер получает команду QUIT, то он удаляет все помеченные для удаления в течение сеанса сообщения и закрывает TCP-соединение. Если сеанс POP3 завершить до того, как клиент выдаст команду QUIT, то все помеченные для удаления сообщения будут сохранены и удаляться не будут.

Ответы сервера начинаются с символов +OK и –ERR. Конец многострочного ответа обозначается строкой с одной точкой (.).

Протокол POP3

C: UIDL
S: +OK 118 messages (6286336 octets)
  1 4323549873
  2 5243509832
  3 9653582120
  и т.д.
 .
C: RETR 115 
S: +OK 2259 octets
  сообщение
 .
C: DELE 115 
C: QUIT 
S: +OK POP3 server at mail.ru signing off

Протокол IMAP

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

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

IMAP предоставляет пользователю богатые возможности для работы с почтовыми ящиками, находящимися на центральном сервере. Почтовая программа, использующая этот протокол, получает доступ к хранилищу корреспонденции на сервере так, как будто эта корреспонденция расположена на компьютере получателя. Электронными письмами можно манипулировать с компьютера пользователя (клиента) без необходимости постоянной пересылки с сервера и обратно файлов с полным содержанием писем. Для отправки писем используется протокол SMTP. Gmail и mail.ru поддерживают IMAP

Преимущества IMAP

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

Доступ к электронной почте через веб-интерфейс

• Клиент пользователя – веб-браузер.
• Письмо передается веб-серверу по протоколу HTTP (в виде содержимого HTML-форм).
• Веб-сервер вызывает CGI-скрипт (или др.), который отправляет письмо адресату.
• Пример: при нажатии кнопки «Отправить» на сайте mail.ru вызывается скрипт /cgi-bin/sentmsg.

Сведения о mail.ru получены при помощи сниффера.

Спам

Виды

• Реклама
• Антиреклама
• Нигерийские письма

• Фишинг

Средства борьбы

• Фильтрация

Служба передачи файлов FTP

Протокол FTP (File Transfer Protocol — протокол передачи файлов) обеспечивает

• просмотр содержимого каталогов;
• передачу файлов на сервер и обратно.

Клиентом выступает тот, кто инициирует передачу (веб-браузер, plugin’ы в файловых менеджерах, проводник, CuteFtp...). Распространенные FTP-серверы: ftpd, Serv-U, Titan FTP Server, freeFTPd. Стандартный порт сервера: 21. Запрос в браузере: ftp://user:password@ftp.server.ru

Клиент FTP в Total Commander

Чтобы установить TCP соединение с сервером (FTP для передачи данных использует транспортный протокол TCP) из браузера достаточно в строке адреса явно указать протокол: ftp://sun.mmcs.rsu.ru. Это будет означать, что имя пользователя – anonymous. Если ftp-сервер не допускает анонимной авторизации, браузер запросит у вас логин и пароль, также их можно явно указать в строке адреса: ftp://user:password@ sun.mmcs.rsu.ru.

Схема работы

Схема взаимодействия FTP-клиента и FTP-сервера

1. FTP-сеанс начинается с установления FTP-клиентом управляющего TCP-соединения с удаленным хостом (сервером) через порт с номером 21.
2. Клиент авторизуется.
3. Клиент просматривает содержимое каталогов на удаленном сервере, посылая соответствующие команды.
4. Когда сервер получает команду «Передать файл», он открывает новое TCP-соединение (т.н. соединение данных) с клиентом, по которому затем происходит передача.
5. После окончания передачи сервер закрывает соединение данных.

По установленному соединению осуществляется передача имени пользователя и пароля, а также команд смены текущего каталога и обмена файлами. Протокол не шифруется, при аутентификации передаёт логин и пароль открытым текстом. Если злоумышленник находится в одном сегменте сети с пользователем FTP, то, используя сниффер, он может перехватить логин и пароль пользователя, или, при наличии специального ПО, получать передаваемые по FTP файлы без авторизации. Чтобы предотвратить перехват трафика, необходимо использовать протокол шифрования данных SSL, который поддерживается многими современными FTP-серверами и некоторыми FTP-клиентами.

Протокол FTP использует два параллельных TCP-соединения: управляющее соединение и соединение данных. Управляющее соединение служит для пересылки управляющей информации между двумя хостами: имени пользователя и пароля, команд смены текущего удаленного каталога, передачи и запроса файлов. Соединение данных предназначено для передачи самих файлов. Поскольку управляющее соединение отделено от соединения данных, говорят, что передача управляющей информации осуществляется вне полосы (out-of-band). В отличие от FTP, протокол HTTP использует одно соединение для управляющих команд (в заголовке) и данных, т.е. HTTP передает свою управляющую информацию внутри полосы (in-band). Когда сервер получает команду передачи или приема файла, он устанавливает с клиентом TCP-соединение данных, затем осуществляет файловый обмен и закрывает соединение. Каждое соединение позволяет передать только один файл; таким образом, множественный обмен вызывает необходимость многократной установки соединения данных. При этом управляющее соединение остается открытым в течение всего сеанса и во время передачи файла по соединению данных управляющее соединение не используется.

Команды клиента и ответы сервера

S: 220 r321-01.mmcs.rsu.ru FTP server (NetBSD-ftpd) ready.
C: USER kto-nibud
S: 331 Password required for kto-nibud.
C: PASS 1234567
S: 230-
  FreeBSD 7.0-RELEASE (GENERIC) #0: Feb 24 10:35:36
  Welcome to FreeBSD!
S: 230 User kto-nibud logged in.
C: SYST
S: 215 UNIX Type: L8 Version: NetBSD-ftpd 20051124
C: PWD
S: 257 "/home/guda" is the current directory.
C: PASV
S: 227 Entering Passive Mode (212,193,209,241,240,214)

Активный и пассивный режимы работы

Клиент инициирует TCP-соединение с динамического порта (1024-65535) к порту номер 21 на FTP-сервере. Дальнейшие действия зависят от того, какой режим FTP (активный или пассивный) выбран. В активном режиме клиент также сообщает серверу номер порта (из динамического диапазона 1024-65535) для того, чтобы сервер мог подключиться к клиенту для установки соединения для передачи данных. FTP-сервер подключается к заданному номеру порта клиента, используя со своей стороны номер TCP-порта 20 для передачи данных. Для клиента такое соединение является входящим, так что зачастую работа в активном режиме клиентов, находящихся за файрволлом или NAT затруднена или требует дополнительных настроек. В пассивном режиме, после того как клиент инициировал сединение, сервер сообщает клиенту номер TCP-порта (из динамического диапазона 1024-65535), к которому можно подключится для установки соединения передачи данных. При этом порты в таком соединении как со стороны клиента, так и со стороны сервера оказываются произвольными. В пассивном режиме клиент легко может работать с сервером сквозь свой файрволл, но зачастую для поддержки пассивного режима сервером требуется соответствующая настройка файрволла уже на стороне сервера.

Главное отличие между активным режимом FTP и пассивным режимом — это сторона, которая открывает соединение для передачи данных. В активном режиме клиент должен суметь принять это соединение от FTP-сервера, в пассивном же клиент всегда инициирует это соединение сам, и принять его должен уже сервер.

Потоковое мультимедиа

Потоковое – это радио, телевидение. Не потоковое – книги, видеокассеты, DVD- диски. Attempts to display media on computers date back to the earliest days of computing, in the mid-20th century. However, little progress was made for several decades, primarily due to the high cost and limited capabilities of computer hardware.

From the late 1980's through the 1990's, consumer-grade personal computers became powerful enough to display various media. The primary technical issues with streaming were:

• having enough CPU power and bus bandwidth to support the required data rates;
• creating low-latency interrupt paths in the OS to prevent buffer underrun.

However, computer networks were still limited, and media was usually delivered over non-streaming channels, such as CD-ROMs. The late 1990's and 2000's, internet users saw:

• greater network bandwidth, especially in the last mile;
• increased access to networks, especially the Internet;
• use of standard protocols and formats, such as TCP/IP, HTTP, and HTML;
• commercialization of the Internet.

These advances in computer networking combined with powerful home computers and modern operating systems made streaming media practical and affordable for ordinary consumers. Stand-alone Internet radio devices are offering listeners a "no-computer" option for listening to audio streams.

In general, multimedia content is large, so media storage and transmission costs are still significant; to offset this somewhat, media is generally compressed for both storage and streaming.

A media stream can be on demand or live. On demand streams are stored on a server for a long period of time, and are available to be transmitted at a user's request. Live streams are only available at one particular time, as in a video stream of a live sporting event.

Research in streaming media is ongoing and representative research can be found at the Journal of Multimedia (http://www.academypublisher.com/jmm/index.html) .

Виды потокового мультимедиа

• записанное потоковое аудио и видео;
• потоковое аудио и видео реального времени (телерадиовещание через Интернет);
• интерактивное аудио и видео реального времени (IP-телефония).

Характеристики передачи мультимедиа:

• чувствительность к задержкам пакетов;
• устойчивость к потерям пакетов.

Записанное потоковое аудио и видео

К этому классу приложений относятся приложения, в которых клиент отправляет запрос на просмотр хранящегося на сервере аудио- или видеофайла, который передается ему, как правило, в сжатом виде и тут же воспроизводится.

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

• Сохранение мультимедийных данных на запоминающем устройстве. Аудио- или видеоданные заранее записываются и сохраняются на сервере в виде файлов. В результате пользователь может остановить, перемотать фильм вперед или назад, а также начать воспроизведение с начала любой части фильма. Время отклика системы на подобные команды пользователя не должно превышать десяти секунд.
• Потоковое воспроизведение. В приложениях записанного потокового аудио/видео клиент может воспроизводить аудио- и видеоданные уже через несколько секунд после того, как данные начнут поступать с сервера. Это означает, что клиент воспроизводит одну часть файла, в то же время принимая по сети следующие его части. Такой метод воспроизведения, называемый потоковым, позволяет не ждать загрузки всего файла (для чего может потребоваться довольно много времени) перед его воспроизведением.
• Непрерывное воспроизведение. Начавшись, воспроизведение мультимедиа должно продолжаться столько времени, сколько длится оригинальная запись. Это требование накладывает строгие ограничения на значение задержки в доставке данных. Данные с сервера должны доставляться вовремя. Хотя приложения записанного потокового мультимедиа предъявляют довольно высокие требования к службе доставки данных, накладываемые ими ограничения на сквозную задержку не столь строги, как для интерактивных приложений реального времени, например Интернет-телефонии или видеоконференций.

Потоковое аудио и видео реального времени

Этот класс приложений схож с традиционной трансляцией радио- и телепередач с той лишь разницей, что передача ведется не в эфире и не по специальному кабелю, а через Интернет. Эти приложения позволяют пользователю получать теле- или радиопрограммы из любого уголка мира. Поскольку «живое» потоковое аудио и видео не сохраняется на запоминающих устройствах, клиент не может осуществлять перемотку вперед. Однако некоторые приложения позволяют пользователю локально сохранять полученные данные и выполнять такие действия, как остановка и перемотка назад. Довольно часто у подобных радио- или телепередач бывает весьма широкая аудитория. Доставка данных сразу многим клиентам, принимающим в этот момент передачу одной и той же станции, может эффективно осуществляться путем групповой IP - маршрутизации. Однако чаще доставка мультимедийных данных выполняется путем выборочной рассылки нескольких отдельных потоков. Как и в случае записанного потокового мультимедиа, здесь требуется непрерывное воспроизведение, хотя временные ограничения не столь строги, как для интерактивных приложений реального времени. Допустимыми считаются задержки в десятки секунд от момента запроса пользователя до начала воспроизведения.

Интерактивное аудио и видео реального времени

Этот класс приложений дает возможность пользователям общаться друг с другом в режиме реального времени. Службу интерактивного аудио реального времени с передачей данных через Интернет часто называют Интернет-телефонией, поскольку с точки зрения пользователя она напоминает традиционную телефонную службу с коммутацией каналов. Интернет-телефония может использоваться для локальной и междугородной телефонной связи по очень низкой цене. Кроме того, Интернет-телефония позволяет упростить развертывание новых служб, которые плохо поддерживаются традиционными сетями с коммутацией каналов, таких как службы интеграции телефонии в web, видеоконференции, службы каталогов, службы фильтрации абонентов и т. д. На сегодняшний день созданы сотни программ поддержки Интернет-телефонии (http://www.von.com). Например, пользователи программы Instant Messenger компании Microsoft могут звонить с персонального компьютера на обычный телефон или с одного персонального компьютера на другой. Интерактивная видеосвязь в реальном времени (видеоконференции) позволяет пользователям не только слышать, но и видеть друг друга. Сегодня на рынке предлагается множество программных продуктов, обеспечивающих интерактивную видеосвязь через Интернет в реальном времени, включая программу NetMeeting корпорации Microsoft. Обратите внимание, что в интерактивных аудио- и видеоприложениях реального времени пользователь может двигаться и говорить. Для подобных приложений задержка в доставке данных не должна превышать нескольких десятых долей секунды. При передаче голоса задержки менее 150 мс не воспринимаются слушателем, задержки в пределах от 150 мс до 400 мс считаются приемлемыми, а задержки, превышающие 400 мс, могут восприниматься как существенные искажения и вести к неразборчивости речи.

Простейшая реализация

Установка TCP-соединения. Клиент посылает HTTP-запрос GET. Сервер находит файл на диске. Сервер посылает его клиенту. Браузер записывает его во временный файл. Браузер вызывает проигрыватель.

В Интернете есть множество музыкальных веб-сайтов, на многих из которых представлены списки песен, которые пользователь может прослушать, щелкнув на названии. Наиболее распространенный способ реализации такой системы «музыки по заказу» показан на рисунке. Процесс начинается, когда пользователь щелкает на названии песни. Вначале вступает в дело браузер. Первый шаг заключается в установке TCP-соединения с веб-сервером, на который указывает гиперссылка. На втором шаге ему направляется HTTP-запрос GET, содержащий заявку на получение файла. Шаги 3 и 4 выполняются сервером: он получает песню (которая представляет собой обычный файл в формате МР3 или каком-нибудь другом) с диска и отсылает ее браузеру.

По МШЕ-типу файла (например, audio/mpЗ) или по расширению браузер определяет способ его воспроизведения. Обычно запускается вспомогательное приложение, ассоциированное с данным типом файлов, например, RealOne Player, Windows Media Player или Winamp. Обычно браузер общается со вспомогательным приложением, записывая информацию, предназначенную для воспроизведения, во временный файл. Поэтому до начала проигрывания весь музыкальный файл будет записан во временный файл на диске (шаг 5). После этого будет запущен проигрыватель, которому браузер передаст имя временного файла. Шаг 6 заключается в поблочном считывании данных из файла и непосредственном воспроизведении музыки.

В принципе, такой подход совершенно корректен, и музыку пользователь услышит. Единственная серьезная проблема заключается в том, что вся запись должна быть предварительно передана по сети. Если музыкальный файл занимает 4 Мбайт (типичный размер аудиофайла с песней в формате МРЗ) и передается при помощи модема со скоростью 56 Кбит/с, пользователь будет наслаждаться тишиной в течение почти 10 минут, прежде чем услышит музыку. Далеко не все меломаны приходят от этого в восторг. К тому же не стоит забывать, что после окончания данной песни следующую можно будет услышать также только через 10 минут.

Как обойти эту проблему, не внося изменений в работу браузера?

Последовательное потоковое видео (progressive streaming)

Проигрыватели начинают показ видео, не дожидаясь полной загрузки файла. При этом файлы по частям могут передавать обычные http-серверы. FLV-формат (Flash Live Video) содержит метаинформацию для «перемотки» видео-потока.

Минусы:

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

With Apache or IIS, you add HTTP streaming through a server side script, which negatively impacts performance. One web server without this performance issue is the Lighttpd web server. It includes a module for HTTP FLV streaming, so if you use this server you can HTTP stream out-of-the-box.

Потоковое видео реального времени (со спецсерверов)

Дополнительное серверное ПО:

• Flash Media Server;
• Windows Media Services;
• QuickTime Streaming Server.

Преимущества:

• хорошая навигация даже для больших файлов;
• защищенность видео данных.

Удаленное управление потоком данных: RTSP

Удаленное управление потоком данных: RTSP

Музыкальные сайты пришли к следующей схеме. Файл, связанный гиперссылкой с названием песни, на самом деле является не музыкальным, а метафайлом. Метафайл обычно очень короткий, в типичной ситуации он состоит всего лишь из одной текстовой строки, которая выглядит примерно так: rtsp://joes-audio-server/song-0025.mp3 Получив такой однострочный файл, браузер записывает его во временный файл, запускает в качестве вспомогательного приложения проигрыватель и передает ему, как обычно, имя временного файла. Проигрыватель видит, что временный файл содержит URL, соединяется с сервером joes-audio-server и запрашивает песню. Браузер не принимает участия в этом процессе.

В большинстве случаев сервер, указанный в метафайле, не совпадает с веб-сервером, содержащим ссылку на метафайл. Более того, обычно это даже не HTTP-сервер, а специализированный мультимедийный сервер. В приведенном примере этот сервер использует протокол RTSP, это становится понятно при взгляде на ссылку — она начинается с названия протокола, rtsp. RTSP описан в RFC 2326.

Проигрыватель мультимедиа решает следующие 4 основные задачи:

1. Управление интерфейсом пользователя.
2. Обработка ошибок передачи.
3. Распаковка сжатых аудиоданных.
4. Устранение флуктуации (джиттера (в области телекоммуникаций джиттером называется первая производная задержки прохождения данных по времени)).

При передаче музыки в реальном времени редко используется протокол TCP, так как ошибки и повторные передачи могут приводить к недопустимо долгим паузам. Вместо этого передача осуществляется по протоколу типа RTP. Подобно большинству протоколов реального времени, RTP работает поверх UDP, то есть пакеты могут теряться по пути. Проблему потерянных пакетов решает проигрыватель.

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

Синтаксис RTSP-запросов очень похож на HTTP. Порт сервера — 554.

RTCP (RTP Control Protocol) — протокол, предоставляющий приложениям, работающим по протоколу RTP, механизм реагирования на изменения в сети. Например, получив информацию о повышении интенсивности трафика в сети и уменьшении выделенной этому приложению полосы пропускания, приложение может принять меры и умерить свои требования к полосе пропускания за счёт некоторой потери качества. После снижения нагрузки в сети приложение может восстановить исходную полосу пропускания и продолжить работу с тем качеством, которое оно предоставляло вначале.

Обработка ошибок

Проблемы при передаче мультимедиа

Проблемы при передаче мультимедиа

Потеря пакетов приводит к ухудшению качества, а не к промежуткам тишины

Обработка ошибок при передаче музыки

Иногда для упрощения обработки ошибок при передаче музыки применяется принцип чередования. Например, пакет может содержать 220 стереоотсчетов, каждый из которых содержит пару 16-разрядных чисел. Этого вполне достаточно для 5 мс звучания музыки. Однако протокол может посылать в одном пакете все нечетные отсчеты для 10 мс звучания, а в следующем — все четные отсчеты для того же интервала. Таким образом, потеря одного пакета не приведет к возникновению паузы длиной 5 мс, вместо этого будет потерян каждый второй отсчет 10- миллисекундного интервала. Эта утрата может быть восполнена, если проигрыватель произведет интерполяцию, используя предыдущий и следующий отсчеты (относительно каждого потерянного). Таким образом, примерные значения будут восстановлены.

Принцип чередования, используемый для восстановления ошибок, показан на рисунке. Здесь видно, что каждый пакет содержит чередующиеся отсчеты для 10-миллисекундного интервала. В результате потери пакета 3 (см. рисунок) не возникает паузы, а только лишь на некоторое время снижается частота следования отсчетов. Утерянные значения путем интерполяции могут быть восстановлены; это обеспечит непрерывность звучания. Данная конкретная схема работает только с несжатыми отсчетами, однако она показывает, как при помощи хитрого алгоритма кодирования превращать потерянные пакеты не в раздражающие паузы, а в непрерывные интервалы с пониженным качеством. Между тем в RFC 3119 описан метод, позволяющий применять аналогичную процедуру к сжатым аудиоданным.

IP-телефония

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

H.323 от ITU

Модель архитектуры H.323 для интернет-телефонии

С самого начала всем было понятно, что если каждый производитель станет изобретать собственный стек протоколов, система никогда работать не будет. Во избежание возникновения этой проблемы заинтересованные стороны объединились под покровительством Международного союза телекоммуникаций (ITU) и начали разработку единого стандарта. В 1996 году ITU (International Telecommunication Union - Международный союз электросвязи) выпустил рекомендации с индексом Н.323 под заголовком «Видеотелефонные системы и оборудование локальных вычислительных сетей, не предоставляющих гарантированное качество обслуживания». Такое название могло родиться только в телефонной индустрии. Данные рекомендации были пересмотрены в 1998 году, и новый вариант Н.323 стал основой построения первых глобальных систем интернет-телефонии.

Н.323 скорее дает общее представление об архитектуре систем интернет-телефонии, нежели описывает некий конкретный протокол. В документе можно найти множество ссылок на различные специализированные протоколы кодирования речи, установки соединения, передачи сигналов, данных и т. п., однако их описание не приводится. Общая модель изображена на рисунке. В центре находится шлюз, соединяющий Интернет с телефонной сетью. Он поддерживает протокол Н.323 со стороны Интернета и протоколы коммутируемой телефонной сети общего пользования с «телефонной» стороны. Устройства коммуникации называются терминалами. В локальной вычислительной сети может быть контроллер зоны, управляющий конечными узлами, находящимися под его юрисдикцией (в его зоне).

Терминал (terminal) — оконечное мультимедийное (голос, видео, данные) устройство, предназначенное для участия в конференции.

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

Устройство управления многоточечными конференциями (Multipoint Control Unit — MCU) предназначено для организации конференций с участием трех и более участников.

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

Семейство протоколов H.323

Семейство протоколов H.323

Работу телефонной сети обеспечивает множество протоколов. Во-первых, необходим протокол кодирования и декодирования речи. Поскольку разрешено использование нескольких алгоритмов сжатия, необходим отдельный протокол, который позволил бы терминалам договориться об использовании одного из этих протоколов. Такой протокол называется Н.245. Он позволяет согласовать также другие параметры соединения, например, битовую скорость. RTCP требуется для управления каналами RTP. Кроме того, нужны протоколы для установления и разрыва соединений, обеспечения тонального вызова, генерирования звуков звонков и других стандартных функций телефонной системы. Терминалам нужен протокол для ведения переговоров с машиной-вратарем (если такая присутствует в локальной сети). Для этого в системе работает протокол Н.225. Канал между ПК и вратарем, которым этот протокол управляет, называется каналом RAS (Registration/Admission/Status — Регистрация/Доступ/Статус). Он позволяет терминалам, кроме всего прочего, входить в зону и покидать ее, запрашивать и освобождать пропускную способность, обновлять данные о состоянии. Наконец, нужен протокол для непосредственной передачи данных. На этом участке работает RTP. Как обычно, управляется он RTCP. Иерархия всех этих протоколов показана на рисунке.

H.323. Логические соединения между абонентами

Логические соединения между абонентами

Чтобы понять, как эти протоколы взаимодействуют друг с другом, рассмотрим случай ПК, являющегося терминалом локальной сети (с вратарем) и звонящего на удаленный телефон. Вначале компьютеру нужно найти вратаря, поэтому он рассылает широковещательным образом специальный UDP-пакет через порт 1718. Из ответа вратаря ПК узнает его IP-адрес. Теперь компьютер должен зарегистрироваться у вратаря. Для этого он посылает ему сообщение RAS в пакете UDP. После регистрации компьютер обращается к вратарю с просьбой (сообщение доступа RAS) о резервировании пропускной способности. Только после выделения этого ресурса можно начинать установку соединения. Предварительное резервирование пропускной способности позволяет вратарю ограничить число соединений, устанавливаемых на исходящей линии, что, в свою очередь, служит для обеспечения необходимого качества обслуживания.

Теперь ПК устанавливает TCP-соединение с вратарем, чтобы осуществить телефонный звонок. При установлении телефонного соединения используются традиционные протоколы телефонной сети, ориентированные на соединение. Поэтому требуется протокол TCP. С другой стороны, в телефонной системе нет никаких RAS, которые позволяли бы телефонным аппаратам заявлять о своем присутствии, поэтому разработчики Н.323 могли применять как UDP, так и TCP.

SIP от IETF

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

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

Протокол SIP

• описывает порядок установления соединения с удалённым клиентом;
• согласовывает открытие дополнительных каналов обмена на основе других протоколов (например, RTP);
• допускает добавление или удаление таких каналов в течение сеанса (конференц-связь).

Схема работы по протоколу SIP

Схема работы по протоколу SIP

Протокол SIP позволяет устанавливать и двухсторонние соединения (то есть обычные телефонные соединения), и многосторонние (когда каждый из участников может как слушать собеседников, так и говорить), и широковещательные (когда один из участников говорит, а остальные могут только слушать). Во время сеанса связи могут передаваться аудио-, видео- или другие данные. Эта возможность используется, например, при организации сетевых игр с большим количеством участников в реальном времени. SIP занимается только установкой, управлением и разрывом соединений. Для передачи данных используются другие протоколы, например, RTP/RTCP.

Телефонные номера в SIP представляются в виде URL со схемой sip. Например, sip:ilse@cs.university.edu свяжет вас с пользователем по имени Use, хост которого определяется DNS -именем cs.university.edu. SIP URL могут содержать также адреса формата IPv4, IPv6 или реальные номера телефонов. Клиенты SIP традиционно используют порт 5060 TCP и UDP для соединения серверов и других элементов SIP.

Протокол SIP является текстовым, он построен по модели HTTP. Одна из сторон посылает ASCII-сообщение, в котором первая строка содержит имя метода, а ниже следуют дополнительные строки, содержащие заголовки для передачи параметров. Многие заголовки взяты из стандарта MIME, что позволяет SIP взаимодействовать с существующими интернет- приложениями.

Skype

Программа Skype основана на P2P технологиях и обеспечивает:

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

Skype — это бесплатное проприетарное программное обеспечение для VoIP, обеспечивающее бесплатную шифрованную голосовую связь через Интернет между компьютерами, а также платные услуги для связи с абонентами обычной телефонной сети.

Архитектура сети Skype

В отличие от многих других программ IP-телефонии, для передачи данных Skype использует P2P архитектуру. Каталог пользователей Skype распределён по компьютерам пользователей сети Skype, что позволяет сети легко масштабироваться до очень больших размеров (в данный момент более 100 миллионов пользователей, пять-десять миллионов онлайн) без дорогой инфраструктуры централизированных серверов. Однако, в процессе работы Skype генерирует типичный для P2P-сетей и неизбежный постоянный трафик, который может достигать 1 Гб в месяц. VoIP-протокол Skype закрыт и используется только оригинальным ПО Skype. При помощи API к его функциям могут получать доступ программы сторонних разработчиков.

При установке соединения между ПК данные шифруются. Случаев расшифровки и/или перехвата Skype на 2008 год не зафиксировано, большинство спецслужб выражают по этому поводу недовольство.

Одним из недостатков Skype считается использование проприетарного протокола, несовместимого с открытыми стандартами (такими, как SIP или H.323). Это приводит к тому, что сервис, основанный на этом протоколе, приносит доход только компании Skype.

Архитектура сети Skype

• сервер авторизации Skype;
• обычные узлы (пользователи);
• супер-узлы (имеют достаточно ресурсов и долго подключены к сети);
• супер-узлы Skype.

Транспортный уровень

Функции транспортного уровня

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

Сокеты

Сокет (socket, гнездо) — это структура данных, идентифицирующая сетевое соединение.

Зачем нужны сокеты? Сервер (программа) может одновременно поддерживать несколько TCP-соединений с другими компьютерами, используя один и тот же стандартный номер порта. Как это реализовать? Можно возложить эту задачу на программиста. Пусть он выбирает из буфера приема сетевого уровня пакеты, смотрит от кого они отправлены и отвечает соответствующим образом. Но можно сделать все это удобнее.

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

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

Сокеты были разработаны в университете Калифорнии в городе Berkeley, стали стандартом де-факто в противоположность OSI TLI (Transport Layer Interface).

Примитивы сокетов

Мультиплексирование и демультиплексирование

Мультиплексирование — сбор сообщений от сокетов всех приложений и добавление заголовков.

Демультиплексирование — распределение приходящих данных по сокетам.

Для UDP нужный сокет определяется номером порта получателя, для TCP — номером порта получателя, IP-адресом и номером порта отправителя.

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

На транспортном уровне действует два протокола: TCP (надежный) и UDP (ненадежный).

Протокол UDP

UDP (User Datagram Protocol) выполняет минимум действий, позволяя приложению почти напрямую работать с сетевым уровнем. Работает гораздо быстрее TCP, потому что не нужно устанавливать соединение и ожидать подтверждения доставки. Возможны потери сегментов. Осуществляет контроль корректности передаваемых данных (контрольная сумма).

Структура UDP-сегмента

Заголовок всего 8 байт.

Принципы надежной передачи данных

Спроектируем протокол myTCP, последовательно его усложняя.

• Состояния протокола myTCP 1.0. Передача по абсолютно надежному каналу
• Ошибка создания миниатюры: Файл не найден

  Отправитель

• Ошибка создания миниатюры: Файл не найден

  Получатель

• Состояния протокола myTCP 2.0. Передача по каналу, допускающему искажения битов. Потери пакетов невозможны
• Ошибка создания миниатюры: Файл не найден

  Отправитель

• Ошибка создания миниатюры: Файл не найден

  Получатель

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

Роль идентификаторов «повторный» и «новый» в TCP/IP играют номера пакетов (т.к. пакеты еще могут теряться).

• Состояния протокола myTCP 2.1. Передача по каналу, допускающему искажения битов. Потери пакетов невозможны
• Ошибка создания миниатюры: Файл не найден

  Отправитель

• Ошибка создания миниатюры: Файл не найден

  Получатель

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

Теперь пришло время вспомнить, что пакеты могут теряться.

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

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

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

Рассмотрим пример. Пусть имеется 1Гб-канал Ростов — Москва. Посчитаем время отправки 1000 байт (или 8000 бит):

8000 бит / 1 Гб/с = 8 мкс

Время распространения сигнала:

1000 км / 300 000 км/с = 3333 мкс

Итого: следующие 1000 байт будут отправлены более чем через 6674 мкс

Вывод: 99,9% времени канал не использует.

Путь решения — увеличить размер пакета. Но ведь если хотя бы 1 бит исказится, то весь пакет выкинут. Что тогда?

Протоколы скользящего окна

Решение проблемы: разрешить отправителю посылать не один кадр, а несколько прежде чем остановиться и перейти в режим ожидания подтверждений (квитанций). Такая техника называется конвейерной обработкой.

На рисунке зеленым обозначены те квитанции, которые уже получены, желтым — отправленные, но не полученные, голубые подготовлены к отправке, а белые нельзя отправлять, пока не получим квитанции на желтые. Окно: желтые и голубые — это пакеты, которые могут быть переданы без ожидания квитанций. Первый белый пакет может быть отправлен только после того, как получили подтверждение на первый желтый. Тогда окно подвигается на 1 вправо.

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

Есть два способа решить проблемы возникновения ошибок при конвейеризации кадров:

• GBN (Go Back N — возвращение на N пакетов назад);
• SR (Selective Repeat — выборочное повторение).

GBN

Получатель отправляет только положительные квитанции и только о получении тех пакетов, для которых выполняется условие: все пакеты с меньшими номерами уже получены. Таким образом, здесь используется групповое квитирование: получение отправителем квитанции с номером i означает, что все пакеты до i включительно доставлены успешно. Если по истечении некоторого времени отправитель не получает квитанции, он повторяет отправление всех N пакетов начиная со следующего за последним квитированным.

Метод GBN неэффективен при большом окне и долгом распространении пакетов по сети, в которой случаются потери. Пример: отправили 1000 пакетов, второй не пришел, приходится повторять отправку всех, начиная со второго. Мы «засоряем» сеть бесполезным трафиком.

SR

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

Часто выборочный метод комбинируют с отправкой получателем «отрицательного подтверждения» (NAK — Negative Acknowledgement) при обнаружении ошибки (например, при неверной контрольной сумме). При этом эффективность работы повышается.

При большом окне подход SR может потребовать значительного размера буфера.

Формат TCP-сегмента

Протокол TCP

Формат TCP-сегмента

TCP-сегмент состоит из поля данных и нескольких полей заголовка. Поле данных содержит фрагмент данных, передаваемых между процессами. Размер поля данных ограничивается величиной MSS (максимальный размер сегмента). Когда протокол осуществляет передачу большого файла, он, как правило, разбивает данные на фрагменты размером MSS (кроме последнего фрагмента, который обычно имеет меньший размер). Интерактивные приложения, напротив, часто обмениваются данными, объем которых значительно меньше MSS. Например, приложения удаленного доступа к сети, подобные Telnet, могут передать транспортному уровню 1 байт данных. Поскольку обычно длина заголовка ТСР-сегмента составляет 20 байт (что на 12 байт больше, чем в UDP), полный размер сегмента в этом случае равен 21 байт.

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

• 32-разрядные поля порядкового номера и номера подтверждения. Необходимы для надежной передачи данных.
• 4-разрядное поле длины заголовка определяет длину TCP-заголовка в 32-разрядных словах. Минимальный размер составляет 5 слов, а максимальный — 15, что составляет 20 и 60 байт соответственно. TCP-заголовок может иметь переменную длину благодаря полю параметров, описанному ниже (как правило, поле параметров является пустым; это означает, что длина заголовка составляет 20 байт).
• Поле флагов состоит из 6 бит. Бит подтверждения (АСК) указывает на то, что значение, содержащееся в квитанции, является корректным. Биты RST, SYN и FIN используются для установки и завершения соединения. Установленный бит PSH инструктирует получателя протолкнуть данные, накопившиеся в приемном буфере, в приложение пользователя. Бит URG показывает, что в сегменте находятся данные, помещенные верхним уровнем как «срочные». Расположение последнего байта срочных данных указано в 16-разрядном поле указателя срочных данных. На принимающей стороне протокол TCP должен уведомить верхний уровень о наличии срочных данных в сегменте и передать ему указатель на конец этих данных. На практике флаги PSH, URG и поле указателя срочных данных не используются. Мы упомянули о них лишь для полноты описания.
• 16-разрядное окно приема используется для управления потоком данных. Оно содержит количество байтов, которое способна принять принимающая сторона.
• Указатель важности — 16-битовое значение положительного смещения от порядкового номера в данном сегменте. Это поле указывает порядковый номер октета которым заканчиваются важные (urgent) данные. Поле принимается во внимание только для пакетов с установленным флагом URG.
• Необязательное поле параметров используется в случаях, когда передающая и принимающая стороны «договариваются» о максимальном размере сегмента, либо для масштабирования окна в высокоскоростных сетях. Также в этом поле определяется параметр временных меток. Дополнительную информацию можно найти в документах RFC 854 и RFC 1323.

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

Порядковый номер сегмента — это номер первого байта этого сегмента.

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

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

Протокол TCP рассматривает данные как неструктурированный упорядоченный поток байтов. Такой подход проявляется в том, что TCP назначает порядковые номера не сегментам, а каждому передаваемому байту. Исходя из этого, порядковый номер сегмента определяется как порядковый номер первого байта этого сегмента. Рассмотрим следующий пример. Пусть хост А желает переслать поток данных хосту В через TCP-соединение. Протокол TCP на передающей стороне неявно нумерует каждый байт потока. Пусть размер передаваемого файла составляет 500 000 байт, величина MSS равна 1000 байт, и первый байт потока имеет порядковый номер 0. TCP разбивает поток данных на 500 сегментов. Первому сегменту присваивается порядковый номер 0, второму сегменту — номер 1000, третьему сегменту — номер 2000, и т. д. Порядковые номера заносятся в поля порядковых номеров каждого TCP-сегмента.

Теперь рассмотрим номера подтверждения. Вспомним о том, что протокол TCP обеспечивает дуплексную передачу данных, то есть через единственное TCP-соединение данные между хостами А и В могут передаваться одновременно в обе стороны. Каждый сегмент, исходящий из хоста В, содержит порядковый номер данных, передающихся от хоста В к хосту А. Номер подтверждения, который хост А помещает в свой сегмент, — это порядковый номер следующего байта, ожидаемого хостом А от хоста В. Рассмотрим следующий пример. Предположим, что хост А получил все байты с номерами от 0 до 535, посланные хостом В, и формирует сегмент для передачи хосту В. Хост А ожидает, что следующие байты, посылаемые хостом В, будут иметь номера, начинающиеся с 536, и помещает число 536 в поле номера подтверждения своего сегмента.

Рассмотрим другую ситуацию. Пусть хост А получил от хоста В два сегмента, в первом из которых содержатся байты с номерами от 0 до 535, а во втором — байты с номерами от 900 до 1000. Это означает, что по какой-либо причине байты с номерами от 536 до 899 не были получены хостом А. В этом случае хост А ожидает появления отсутствующих байтов и в поле номера подтверждения своего сегмента помещает число 536. Поскольку TCP квитирует принятые данные до первого отсутствующего байта, говорят, что он поддерживает общее квитирование.

Последний пример демонстрирует очень важный аспект функционирования протокола TCP. Третий сегмент (содержащий байты 900-1000) принят хостом А раньше, чем второй (содержащий байты 536-899), то есть с нарушением порядка следования данных. Возникает вопрос: как протокол TCP реагирует на нарушение порядка? Если полученный сегмент содержит номер последовательности больший, чем ожидаемый, то данные из сегмента буферизируется, но номер подтвержденной последовательности не изменяется. Если в последствии будет принят сегмент, относящийся к ожидаемому номеру последовательности, то порядок данных будет автоматически восстановлен исходя из номеров последовательностей в сегментах. Таким образом TCP относится к протоколам SR, но у него используется общее квитирование как в GBN. Хотя SR – не совсем чистое. Если посылаемая сторона получает несколько (3) отрицательных квитанций на один и тот же сегмент x, то она догадывается, что произошла перегрузка сети и сегменты x+1, x+2, x+3,… тоже не были доставлены. Тогда посылается вся серия начиная с x – как в протоколах GBN.

Проблемы с максимальным размером сегмента

TCP требует явного указания максимального размера сегмента в случае если виртуальное соединение осуществляется через сегмент сети, где максимальный размер блока (MTU) менее чем стандартный MTU Ethernet (1500 байт). В протоколах туннелирования, таких как GRE, IPIP, а так же PPPoE MTU туннеля меньше чем стандартный, поэтому сегмент TCP максимального размера имеет длину пакета больше, чем MTU. Поскольку фрагментация в подавляющем большинстве случаев запрещена, то такие пакеты отбрасываются.

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

Установка TCP-соединения

Тройное рукопожатие

Чтобы установить соединение, хост 2 пассивно ожидает входящего соединения, выполняя примитив ACCEPT.

Хост 2 выполняет примитив CONNECT, указывая IP-адрес и порт, с которым он хочет установить соединение, максимальный размер TCP-сегмента и т.п.. Примитив CONNECT посылает TCP-сегмент «Connection request» с установленным битом SYN=1 и сброшенным битом АСК=0 и ждет ответа. Таким образом, хост 1 сообщает порядковый номер x последовательности битов от хоста 1 к 2.

Хост 2 отсылает в ответ подтверждение «Connection accepted» (функция accept). Последовательность TCP-сегментов, посылаемых в нормальном случае, показана на рис: SYN=1 ASK=1, хост 2 сообщает порядковый номер x последовательности битов от хоста 2 к 1 и сообщает, что он ожидает продолжения данных начиная с байта № x+1.

Хост 1 (Connect) отправляет подтверждение о получении согласия на установление соединения.

Борьба с перегрузкой в TCP

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

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

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

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

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

Борьба с перегрузкой в TCP

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

Решение, применяемое в Интернете, состоит в признании существования двух потенциальных проблем: низкой пропускной способности сети и низкой емкости получателя — и в раздельном решении обеих проблем. Для этого у каждого отправителя есть два окна: окно, предоставленное получателем, и окно перегрузки. Размер каждого из них соответствует количеству байтов, которое отправитель имеет право передать. Отправитель руководствуется минимальным из этих двух значений. Например, получатель говорит: «Посылайте 8 Кбайт», но отправитель знает, что если он пошлет более 4 Кбайт, то в сети образуется затор, поэтому он посылает все же 4 Кбайт. Если же отправитель знает, что сеть способна пропустить и большее количество данных, например 32 Кбайт, он передаст столько, сколько просит получатель (то есть 8 Кбайт).

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

Этот процесс экспоненциального роста продолжается до тех пор, пока не будет достигнут размер окна получателя или не будет выработан признак тайм-аута, сигнализирующий о перегрузке в сети. Например, если пакеты размером 1024, 2048 и 4096 байт дошли до получателя успешно, а в ответ на передачу пакета размером 8192 байта подтверждение не пришло в установленный срок, окно перегрузки устанавливается равным 4096 байтам. Пока размер окна перегрузки остается равным 4096 байтам, более длинные пакеты не посылаются, независимо от размера окна, предоставляемого получателем. Этот алгоритм называется затяжным пуском, или медленным пуском. Однако он не такой уж и медленный (Jacobson, 1988). Он экспоненциальный. Все реализации протокола TCP обязаны его поддерживать.

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

Механизмы надежной передачи. Обобщение

Особенности программирования

1. Потоковое соединение TCP
   • ситуация а) возможна при плохой связи, если промежуток времени между приходами групп дейтаграмм сетевого уровня велик:
     • компьютер1 один раз использует функцию send;
     • компьютер2 не получает всю информацию за один вызов recv (нужно несколько вызовов).
   • ситуация б) возможна, если интервал времени между вызовами функции send мал и размер данных мал:
     • компьютер1 использует функцию send несколько раз;
     • компьютер2 получает всю информацию за один вызов recv.
2. По протоколу UDP
   • ситуация а) - невозможна
     • компьютер1 один раз использует функцию send, на сетевом уровне UDP-сегмент разбивается на несколько пакетов;
     • компьютер2 получает сегмент всегда одним вызовом recv и только, если пришли все IP-дейтаграммы.
   • ситуация б) - невозможна
     • разные вызовы функции sendto на компьютере1 соответствуют разным UDP-датаграммам и разным вызовам recvfrom на компьютере2.
3. Если буфер в функциях recv и recvfrom меньше, чем размер присланных данных, то в случае UDP часть данных теряется, а в случае TCP – остаток сохраняется для последующего вызова recv.
4. У UDP-сервера 1 сокет, а TCP-сервер имеет много разных сокетов (по количеству одновременно подключенных клиентов) и каждому передается своя информация.

Сетевой уровень

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

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

Основные составляющие

• Протокол IP. Работает на всех компьютерах в цепочке передачи. На каждом решает кому отправить дальше (таблицы маршрутизации);
• Протоколы маршрутизации. Позволяют динамически менять таблицы маршрутизации;
• Иерархическая система адресации (IP-адреса).

IP-адреса

IP-адрес — это 4-байтовое число (32 разряда), например, 192.168.10.153. Он присваивается каждому интерфейсу. Примерами интерфейса являются сетевая карта, модем.

Считается, что IP-адрес состоит из двух частей:

• сетевая часть (номер подсети);
• интерфейсная часть (номер интерфейса узла).

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

В случае изолированной сети её адрес может быть выбран администратором из специально зарезервированных для таких сетей блоков адресов (192.168.0.0/16, 172.16.0.0/12 или 10.0.0.0/8). Если же сеть должна работать как составная часть Интернета, то адрес сети выдаётся провайдером либо региональным интернет-регистратором (Regional Internet Registry, RIR). Существует пять RIR:

• ARIN, обслуживающий Северную Америку;
• APNIC, обслуживающий страны Юго-Восточной Азии;
• AfriNIC, обслуживающий страны Африки;
• LACNIC, обслуживающий страны Южной Америки и бассейна Карибского моря;
• RIPE NCC, обслуживающий Европу, Центральную Азию, Ближний Восток.

Региональные регистраторы получают номера автономных систем и большие блоки адресов у IANA, а затем выдают номера автономных систем и блоки адресов меньшего размера локальным интернет-регистраторам (Local Internet Registries, LIR), обычно являющимся крупными провайдерами.

Разделение сетей на классы

Разделение IP-адресов на классы

Нетрудно посчитать, что всего в пространстве адресов IP — 128 сетей по 16 777 216 адресов класса A, 16384 сети по 65536 адресов класса B и 2 097 152 сети по 256 адресов класса C, а также 268 435 456 адресов многоадресной рассылки и 134 317 728 зарезервированных адресов. С ростом сети Интернет эта система оказалась неэффективной и была вытеснена CIDR (бесклассовой адресацией). Такое разделение на классы устарело.

Бесклассовая адресация

Бесклассовая адресация

Проблема нехватки IP-адресов решилась предоставлением сети возможности разделения на несколько частей. Например, вместо одного адреса класса В с 14 битами для номера сети и 16 битами для номера хоста было предложено использовать несколько другой формат — формировать адрес подсети из нескольких битов. Например, если в университете существует 35 подразделений, то 6-битным номером можно кодировать подсети, а 10-битным — номера хостов. С помощью такой адресации можно организовать до 64 сетей по 1022 хоста в каждой (адреса 0 и 1 не используются, как уже говорилось, поэтому не 1024 , а именно 1022 хоста).

Иерархия IP-адресов

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

255.255.255.255 – широковещательный.

127.0.0.0 / 8 – петля обратной связи.

10.0.0.0 / 8 и 192.168.0.0 / 16 – частные сети, подсоединенные к Интернету через NAT.

Пример

На рисунке NAT нет. Изображено всего 7 сетей: 3 (между маршрутизаторами) (192.168.2.0, 192.168.3.0 и 192.168.1.0) + 4 (172.17.0.0, 10.0.0.0, 172.16.0.0, 192.168.4.0).

Таблица маршрутизации. Результат команды route print

Чтобы понять, как функционируют подсети, следует рассмотреть процесс обработки IP-пакетов маршрутизатором. У каждого маршрутизатора есть таблица,содержащая IP-адреса сетей (вида <сетъ, 0>) и IP-адреса хостов (вида <эта_сеть, хост>). Адреса сетей позволяют получать доступ к удаленным сетям, а адреса хостов — обращаться к локальным хостам. С каждой таблицей связан сетевой интерфейс, применяющийся для получения доступа к пункту назначения, а также другая информация. Когда IP-пакет прибывает на маршрутизатор, адрес получателя, указанный в пакете, ищется в таблице маршрутизации. Если пакет направляется в удаленную сеть, он пересылается следующему маршрутизатору по интерфейсу, указанному в таблице. Если пакет предназначен локальному хосту (например, в локальной сети маршрутизатора), он посылается напрямую адресату. Если номера сети, в которую посылается пакет, в таблице маршрутизатора нет, пакет пересылается маршрутизатору по умолчанию, с более подробными таблицами. Такой алгоритм означает, что каждый маршрутизатор должен учитывать только другие сети и локальные хосты, а не пары <сеть, хост>, что значительно уменьшает размер таблиц маршрутизатора.

Формат IP-дейтаграммы

Формат IP-дейтаграммы

IP-дейтаграмма состоит из заголовка и текстовой части. Заголовок содержит обязательную 20-байтную часть, а также необязательную часть переменной длины. Формат заголовка показан на рисунке. Поле Версия содержит версию протокола, к которому принадлежит дейтаграмма. Включение версии в каждую дейтаграмму позволяет использовать разные версии протокола на разных машинах. Дело в том, что с годами протокол изменялся, и на одних машинах сейчас работают новые версии, тогда как на других продолжают использоваться старые. Сейчас происходит переход от версии IPv4 к версии IPv6. Он длится уже много лет, и не похоже, что скоро завершится. Длина заголовка является переменной величиной, для хранения которой выделено поле IHL (информация в нем представлена в виде 32-разрядных слов). Минимальное значение длины (при отсутствии необязательного поля) равно 5. Максимальное значение этого 4-битового поля равно 15, что соответствует заголовку длиной 60 байт; таким образом, максимальный размер необязательного поля равен 40 байтам. Для некоторых приложений, например, для записи маршрута, по которому должен быть переслан пакет, 40 байт слишком мало. В данном случае дополнительное поле оказывается бесполезным.

Поле Тип службы — единственное поле, смысл которого с годами несколько изменился. Оно было (впрочем, и до сих пор) предназначено для различения классов обслуживания. Возможны разные комбинации надежности и скорости. Для оцифрованного голоса скорость доставки важнее точности. При передаче файла, наоборот, передача без ошибок важнее быстрой доставки. Изначально 6-разрядное поле Тип службы состояло из трехразрядного поля Precedence и трех флагов — D, Т и R. Поле Precedence указывало приоритет, от 0 (нормальный) до 7 (управляющий сетевой пакет). Три флаговых бита позволяли хосту указать, что беспокоит его сильнее всего, выбрав из набора {Delay, Throughput, Reliability} (Задержка, Пропускная способность, Надежность). Теоретически, эти поля позволяют маршрутизаторам выбрать, например, между спутниковой линией с высокой пропускной способностью и большой задержкой и выделенной линией с низкой пропускной способностью и небольшой задержкой. На практике сегодняшние маршрутизаторы часто вообще игнорируют поле Тип службы. Поле Полная длина содержит длину всей дейтаграммы, включая как заголовок, так и данные. Максимальная длина дейтаграммы 65 535 байт. В настоящий момент этот верхний предел достаточен, однако с появлением гигабитных сетей могут понадобиться дейтаграммы большего размера. (когда Таненбаум это писал, гигабитных сетей еще не было) Поле Идентификатор позволяет хосту-получателю определить, какой дейта- грамме принадлежат полученные им фрагменты. Все фрагменты одной дейтаграммы содержат одно и то же значение идентификатора. Следом идет один неиспользуемый бит и два однобитных поля. Бит DF означает Don't Fragment (He фрагментировать). Это команда маршрутизатору, запрещающая ему фрагментировать дейтаграмму, так как получатель не сможет восстановить ее из фрагментов. Например, при загрузке компьютера его ПЗУ может запросить образ памяти в виде единой дейтаграммы. Пометив дейтаграмму битом DF, отправитель гарантирует, что дейтаграмма дойдет единым блоком, даже если для ее доставки придется избегать сетей с маленьким размером пакетов. От всех машин требуется способность принимать фрагменты размером 576 байт и менее.

Бит MF означает More Fragments (Продолжение следует). Он устанавливается во всех фрагментах, кроме последнего. По этому биту получатель узнает о прибытии последнего фрагмента дейтаграммы. Поле Смещение фрагмента указывает положение фрагмента в исходной дейтаграмме. Длина всех фрагментов в байтах, кроме длины последнего фрагмента, должна быть кратна 8. Так как на это поле выделено 13 бит, максимальное количество фрагментов в дейтаграмме равно 8192, что дает максимальную длину дейтаграммы 65 536 байт, на 1 байт больше, чем может содержаться в поле Полная длина.

Поле Время жизни (Число переходов) представляет собой счетчик, ограничивающий время жизни пакета. Предполагалось, что он будет отсчитывать время в секундах, таким образом, допуская максимальное время жизни пакета в 255 с. На каждом маршрутизаторе это значение должно было уменьшаться как минимум на единицу плюс время стояния в очереди. Однако на практике этот счетчик просто считает количество переходов через маршрутизаторы. Когда значение этого поля становится равным нулю, пакет отвергается, а отправителю отсылается пакет с предупреждением. Таким образом удается избежать вечного странствования пакетов, что может произойти, если таблицы маршрутизаторов по какой-либо причине испортятся.

Собрав дейтаграмму из фрагментов, сетевой уровень должен решить, что с ней делать. Поле Протокол сообщит ему, какому процессу транспортного уровня ее передать. Это может быть TCP, UDP или что-нибудь еще. Нумерация процессов глобально стандартизирована по всему Интернету. Номера протоколов вместе с некоторыми другими были сведены в RFC 1700, однако теперь доступна интернет-версия в виде базы данных, расположенной по адресу www.iana.org. Поле Контрольная сумма заголовка защищает от ошибок только заголовок. Подобная контрольная сумма полезна для обнаружения ошибок, вызванных неисправными микросхемами памяти маршрутизаторов. Алгоритм вычисления суммы просто складывает все 16-разрядные полуслова в дополнительном коде, преобразуя результат также в дополнительный код. Таким образом, проверяемая получателем контрольная сумма заголовка (вместе с этим полем) должна быть равна нулю. Этот алгоритм надежнее, чем обычное суммирование. Обратите внимание на то, что значение Контрольной суммы заголовка должно подсчитываться заново на каждом транзитном участке, так как по крайней мере одно поле постоянно меняется (поле Время жизни). Для ускорения расчетов применяются некоторые хитрости.

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

Служебные протоколы

ICMP

ICMP (Internet Control Message Protocol) — межсетевой протокол управляющих сообщений. Основная задача — передача информации об ошибках в дейтаграммах. Используется в программах ping (проверяет работает ли удаленный компьютер) и traceroute (определяет маршрут следования данных в сетях TCP/IP).

DHCP

DHCP (Dynamic Host Configuration Protocol — протокол динамического конфигурирования узлов) позволяет компьютерам автоматически получать IP-адрес и другие параметры.

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

Протокол DHCP предоставляет три способа распределения IP-адресов:

• Ручное распределение. При этом способе сетевой администратор сопоставляет аппаратному адресу (обычно MAC-адресу) каждого клиентского компьютера определённый IP-адрес. Фактически, данный способ распределения адресов отличается от ручной настройки каждого компьютера лишь тем, что сведения об адресах хранятся централизованно (на сервере DHCP), и потому их проще изменять при необходимости.
• Автоматическое распределение. При данном способе каждому компьютеру на постоянное использование выделяется произвольный свободный IP-адрес из определённого администратором диапазона.
• Динамическое распределение. Этот способ аналогичен автоматическому распределению, за исключением того, что адрес выдаётся компьютеру не на постоянное пользование, а на определённый срок. Это называется арендой адреса. По истечении срока аренды IP-адрес вновь считается свободным, и клиент обязан запросить новый (он, впрочем, может оказаться тем же самым).

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

Принципы работы DHCP

• Компьютер отправляет широковещательный UDP-пакет: «Кто может назначить мне IP-адрес?»
• DHCP-серверы сети отправляют в ответ DHCP-предложения.
• Клиент получает список предложений, выбирает нужное и отправляет DHCP-запрос на конкретный сервер.
• От сервера приходит DHCP-подтверждение (в нем указывается IP-адрес, присвоенный клиенту).

Решение проблемы нехватки IP-адресов (NAT)

NAT (Network Address Translation — «преобразование сетевых адресов») — это механизм в сетях TCP/IP, позволяющий преобразовывать IP-адреса транзитных пакетов.

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

Преобразование адресов методом NAT может производиться почти любым маршрутизирующим устройством — маршрутизатором, сервером доступа, межсетевым экраном. Суть механизма состоит в замене адреса источника (source) при прохождении пакета в одну сторону и обратной замене адреса назначения (destination) в ответном пакете. Наряду с адресами source/destination могут также заменяться номера портов source/destination.

NAT выполняет две важных функции:

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

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

Недостатки

• Не все протоколы могут «преодолеть» NAT. Некоторые не в состоянии работать, если на пути между взаимодействующими хостами есть трансляция адресов. Некоторые межсетевые экраны, осуществляющие трансляцию IP-адресов, могут исправить этот недостаток, соответствующим образом заменяя IP-адреса не только в заголовках IP, но и на более высоких уровнях (например, в командах протокола FTP). Из-за трансляции адресов «много в один» появляются дополнительные сложности с идентификацией пользователей и необходимость хранить полные логи трансляций.

• DoS со стороны узла, осуществляющего NAT — если NAT используется для подключения многих пользователей к одному и тому же сервису, это может вызвать иллюзию DoS атаки на сервис (множество успешных и неуспешных попыток). Например, избыточное количество пользователей ICQ за NAT’ом приводит к проблеме подключения некоторых пользователей из-за превышения допустимой скорости коннектов к серверу. Частичным решением проблемы является использование пула адресов (группы адресов), для которых осуществляется трансляция.

• Сложности в работе с пиринговыми сетями, в которых необходимо не только инициировать исходящие соединения, но также принимать входящие.

Маршрутизация

Маршрутизатор (устройство) получает пакет и должен отправить его дальше, но кому?

Маршрутизация (англ. routing) — это процесс определения маршрута следования информации в сетях связи.

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

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

Протоколы обмена маршрутной информацией (протоколы маршрутизации) реализуют следующие типов алгоритмов:

• дистанционно-векторный алгоритм (Distance Vector Algorithms, DVA);
• алгоритм состояния связей (Link State Algorithms, LSA);
• другие (например, гибридный протокол маршрутизации EIGRP от Cisco).

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

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

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

Наиболее распространенным протоколом, основанным на дистанционно-векторном алгоритме, является протокол RIP.

Алгоритмы состояния связей

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

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

Иерархическая маршрутизация

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

Протоколы:

• внутренняя маршрутизация: RIP (Routing Internet Protocol) и OPSF (Open Shortest Path First);
• внешняя маршрутизация: BGP (Border Gateway Protocol).

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

RIP

Протокол RIP (Routing Information Protocol) — это один из наиболее распространенных протоколов маршрутизации в небольших компьютерных сетях, который позволяет маршрутизаторам динамически обновлять маршрутную информацию (направление и дальность в хопах), получая ее от соседних маршрутизаторов.

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

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

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

Таблица 1. Начальная информация в узле 2 Сеть Расстояние Сосед A 1 — B 1 — C 1 —

Таблица 2. Информация в узле 2 после двух шагов Сеть Расстояние Сосед A 1 — B 1 — C 1 — D 2 3 E 2 5 D 3 5 F 3 5

На рисунке цифрами обозначены маршрутизаторы. Каждый маршрутизатор хранит у себя вектор дистанций. Вектор дистанций — это таблица, где указаны IP-адреса сетей (первый столбец), расстояние до этих сетей в хопах (хоп — это количество ребер на графе) (второй столбец) и какому следующему маршрутизатору нужно отправить, чтобы пакет дошел до нужной сети. Буквами A, B, C, D, E, F обозначены сети между каждыми двумя маршрутизаторами.

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

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

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

При использовании протокола RIP работает эвристический алгоритм динамического программирования Беллмана-Форда, и решение, найденное с его помощью является не оптимальным, а близким к оптимальному. Преимуществом протокола RIP является его вычислительная простота, а недостатками — увеличение трафика при периодической рассылке широковещательных пакетов и неоптимальность найденного маршрута.

Неустойчивая работа при изменении конфигурации

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

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

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

OSPF

Протокол OSPF (Open Shortest Path Firs) является достаточно современной реализацией алгоритма состояния связей (он принят в 1991 году) и обладает многими особенностями, ориентированными на применение в больших гетерогенных сетях.

Протокол OSPF вычисляет маршруты в IP-сетях, сохраняя при этом другие протоколы обмена маршрутной информацией.

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

Для распространения по сети данных о состоянии связей маршрутизаторы обмениваются сообщениями другого типа. Эти сообщения называются router links advertisement — объявление о связях маршрутизатора (точнее, о состоянии связей). OSPF-маршрутизаторы обмениваются не только своими, но и чужими объявлениями о связях, получая в конце-концов информацию о состоянии всех связей сети. Эта информация и образует граф связей сети, который, естественно, один и тот же для всех маршрутизаторов сети.

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

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

Представим себе один день из жизни транзитной локальной сети. Пусть у нас имеется сеть Ethernet, в которой есть три маршрутизатора — Джон, Фред и Роб (имена членов рабочей группы Internet, разработавшей протокол OSPF). Эти маршрутизаторы связаны с сетями в других городах с помощью выделенных линий.

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

На протяжении интервала отказа маршрутизаторы продолжают посылать сообщения HELLO. Когда какой-либо маршрутизатор посылает такое сообщение, другие его получают и отмечают, что в локальной сети есть другой маршрутизатор. Когда они посылают следующее HELLO, они перечисляют там и своего нового соседа. Когда период отказа маршрутизатора истекает, то маршрутизатор с наивысшим приоритетом и наибольшим идентификатором объявляет себя выделенным (а следующий за ним по приоритету маршрутизатор объявляет себя резервным выделенным маршрутизатором) и начинает синхронизировать свою базу данных с другими маршрутизаторами. С этого момента времени база данных маршрутных объявлений каждого маршрутизатора может содержать информацию, полученную от маршрутизаторов других локальных сетей или из выделенных линий. Роб, например, вероятно получил информацию от Мило и Робина об их сетях, и он может передавать туда пакеты данных. Они содержат информацию о собственных связях маршрутизатора и объявления о связях сети. Базы данных теперь синхронизированы с выделенным маршрутизатором, которым является Джон. Джон суммирует свою базу данных с каждой базой данных своих соседей — базами Фреда, Роба и Джеффа — индивидуально. В каждой cинхронизирующейся паре объявления, найденные только в какой-либо одной базе, копируются в другую. Выделенный маршрутизатор, Джон, распространяет новые объявления среди других маршрутизаторов своей локальной сети. Например, объявления Мило и Робина передаются Джону Робом, а Джон, в свою очередь, передает их Фреду и Джеффри. Обмен информацией между базами продолжается некоторое время, и пока он не завершится, маршрутизаторы не будут считать себя работоспособными. После этого они себя таковыми считают, потому что имеют всю доступную информацию о сети.

Посмотрим теперь как Робин вычисляет маршрут через сеть. Две из связей, присоединенных к его портам, представляют линии T-1, а одна - линию 56 Кб/c. Робин сначала обнаруживает двух соседей — Роба с метрикой 65 и Мило с метрикой 1785. Из объявления о связях Роба Робин обнаружил наилучший путь к Мило со стоимостью 130, поэтому он отверг непосредственный путь к Мило, поскольку он связан с большей задержкой, так как проходит через линии с меньшей пропускной способностью. Робин также обнаруживает транзитную локальную сеть с выделенным маршрутизатором Джоном. Из объявлений о связях Джона Робин узнает о пути к Фреду и, наконец, узнает о пути к маршрутизаторам Келли и Джеффу и к их тупиковым сетям.

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

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

BGP

BGP (Border Gateway Protocol — протокол граничного шлюза) — основной протокол динамической маршрутизации в Интернете. BGP, в отличие от других протоколов динамической маршрутизации, предназначен для обмена информацией о маршрутах не между отдельными маршрутизаторами, а между целыми автономными системами, и поэтому, помимо информации о маршрутах в сети, переносит также информацию о маршрутах на автономные системы.

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

Автономный пограничный маршрутизатор, который участвует в маршрутизации с использованием вектора путей, извещает о достижимости сетей в их собственной автономной системе для соседних автономных пограничных маршрутизаторов. Концепция окружения здесь та же самая, как в уже рассмотренных протоколах RIP и OSPF. Два пограничных маршрутизатора автономных систем, подключенные к той же самой сети, — соседи.

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

Устройство маршрутизатора

Основная задача маршрутизатора: получение дейтаграммы и отправка ее по одному из своих интерфейсов.

Задача маршрутного процессора: составление таблиц продвижения данных.

Дейтаграммы приходят по одному из входных портов и отправляются на какой-то выходной порт.

Устройство маршрутизатора

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

Чтобы получить представление о необходимой производительности операции поиска, рассмотрим линию, передающую данные на скорости 2,5 Гбит/с. При длине пакетов 256 байт входной порт должен успевать выполнять приблизительно миллион операций поиска в секунду.

Поскольку скорости передачи данных в современных линиях связи очень высокие, линейный поиск а таблице продвижения данных просто невозможен. Более разумный подход заключается в хранении таблицы продвижения данных в виде дерева, каждый уровень которого соответствует одному двоичному разряду адреса получателя. Поиск адреса начинается с вершины дерева. Если первый бит адреса равен нулю, тогда, дальнейший поиск ведется по левому поддереву, в противном случае адрес получателя должен находиться в правом поддереве. На каждом шаге просматривается один разряд адреса получателя и выбирается одна ветвь дерева из двух. Таким образом, всю таблицу продвижения данных можно просмотреть за N шагов, где N — количество двоичных разрядов в адресе. Такой поиск называется двоичным поиском в адресном пространстве размера 2^N.

Но даже при N=32 (например, для 32-разрядного IP-адреса) скорость просмотра таблицы методом двоичного поиска оказывается недостаточно высокой для маршрутизации в современных магистралях. Например, если на каждом шаге работы алгоритма требуется одно обращение к памяти, то при памяти со временем доступа 40нс уровня одного миллиона операций в секунду достичь не удастся. Для увеличения скорости поиска применяются несколько приемов. Один ни таких приемов заключается и использовании ассоциативной памяти.

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

Случайное раннее обнаружение (Random Early Detection, RED) представляет альтернативу очередям FIFO. Оно позволяет смягчить эффект от потери трафика даже при очень больших нагрузках, так что приложения не синхронизированы друг с другом, как это имело место в предыдущем случае. Такая очередь по-прежнему использует принцип FIFO, но, вместо того чтобы отбрасывать сообщения из конца очереди, RED отбрасывает трафик статистически, когда средняя длина очереди за данный промежуток времени превосходит некоторое значение. Таким образом, заполнение очереди оптимизировано для обеспечения большей устойчивости алгоритма. Этот процесс был придуман специально для TCP, но те, кто его изобрел, считают, что он применим к любому трафику, когда сеть не гарантирует доставки.

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

Очереди в соответствии с классом (Class-Based Queuing, CBQ) — это алгоритм, при котором трафик делится на несколько классов. Определение класса трафика в значительной мере произвольно. Класс может представлять весь трафик через данный интерфейс, трафик определенных приложений, трафик к заданному подмножеству получателей, трафик с качеством услуг, гарантированным RSVP. Каждый класс имеет собственную очередь, и ему гарантируется, по крайней мере, некоторая доля пропускной способности канала. Если какой-либо класс не исчерпывает предоставленный ему лимит пропускной способности, то остальные классы увеличивают свою долю пропорциональным образом.

Взвешенная справедливая очередь (Weighted Fair Queuing, WFQ) является частным случаем CBQ, когда отдельному классу соответствуют независимые потоки. Как и в случае CBQ, каждому классу WFQ соответствует одна очередь FIFO и гарантируется некоторая часть пропускной способности канала. Если некоторые потоки используют предоставленную им пропускную способность не полностью, то другие потоки увеличивают свою долю соответственно. Так как каждый класс - это отдельный поток, то гарантия пропускной способности эквивалентна в данном случае гарантии максимальной задержки. Зная параметры сообщения, вы можете по известной формуле вычислить его максимальную задержку при передаче по сети. Выделение дополнительной пропускной способности позволяет уменьшить максимальную задержку.

Структура Internet

Internet изначально строилась как сеть, объединяющая большое количество существующих систем. С самого начала в ее структуре выделяли магистральную сеть (core backbone network), а сети, присоединенные к магистрали, рассматривались как автономные системы (autonomous systems). Магистральная сеть и каждая из автономных систем имели свое собственное административное управление и собственные протоколы маршрутизации. Общая схема архитектуры сети Internet показана на рисунке. Далее маршрутизаторы будут называться шлюзами для следования традиционной терминологии Internet.

Шлюзы, которые используются для образования подсетей внутри автономной системы, называются внутренними шлюзами (interior gateways), а шлюзы, с помощью которых автономные системы присоединяются к магистрали сети, называются внешними шлюзами (exterior gateways). Непосредственно друг с другом автономные системы не соединяются. Соответственно, протоколы маршрутизации, используемые внутри автономных систем, называются протоколами внутренних шлюзов (interior gateway protocol, IGP), а протоколы, определяющие обмен маршрутной информацией между внешними шлюзами и шлюзами магистральной сети — протоколами внешних шлюзов (exterior gateway protocol, EGP).

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

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

В протоколе EGP определены три основные функции:

• установление соседских отношений;
• подтверждение достижимости соседа;
• обновление маршрутной информации.

Каждая функция работает на основе обмена сообщениями запрос-ответ.

Развитием протокола EGP является протокол BGP (Border Gateway Protocol), имеющий много общего с EGP и используемый наряду с ним в магистрали сети Internet.

Протокол IPv6

Причины перехода c IPv4 на IPv6

• недостаточность объёма 32-битного адресного пространства;
• разрастание таблиц маршрутизации;
• сложность массового изменения IP-адресов;
• относительная сложность обработки заголовков пакетов IPv4.

Адреса

Как правило, адрес стандарта IPv6 состоит из восьми шестнадцатеричных фрагментов по четыре цифры в каждом, разделенных двоеточиями. Полный адрес IPv6 выглядит следующим образом: 2001:0db8:0049:0000:ab00:0000:0000:0102. Он занимает 16 байт и записываются в виде 8 двухбайтных чисел. Первые четыре фрагмента (64 бита) адреса указывают на его сетевую принадлежность и называются сетевым префиксом. Поскольку адреса в формате IPv6 имеют иерархическую структуру, в сетевом префиксе последовательно указываются организация, провайдер и другие элементы цепочки распространения. Последние четыре фрагмента (64 бита) образуют уникальный идентификационный номер интерфейса, который чаще всего формируется на основе MAC-адреса устройства.

Поскольку полный адрес, показанный выше, оказывается довольно громоздким и неудобным в обращении, IPv6 предусматривает возможность сжатия адреса, которое осуществляется в два этапа. Сначала убираются все вводные нули в каждом из четырехзначных фрагментов. При этом адрес, показанный выше, примет вид 2001:db8:49:0:ab00:0:0:102. Кроме того, все состоящие из нулей фрагменты можно заменить двойным двоеточием — тогда мы получим окончательно сжатый адрес вида 2001:db8:49:0:ab00::102. Сокращению не могут быть подвергнуты 2 разделенные нулевые группы из-за возникновения неоднозначности.

Сокращения записи:

2001:0db8:0000:0000:0000:0000:1428:57ab
2001:0db8:0000:0000:0000::1428:57ab
2001:0db8:0:0:0:0:1428:57ab
2001:0db8:0:0::1428:57ab
2001:0db8::1428:57ab
2001:db8::1428:57ab

Типы адресов

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

:: ↔ 0.0.0.0
::1 ↔ 127.0.0.1
::a.b.c.d ↔ a.b.c.d
::FFF.a.b.c.d ↔ a.b.c.d
FF**:: - широковещательные

IPv6-адреса с вложенными IPv4-адресами

Алгоритмы IPv6 включают в себя механизм (для ЭВМ и маршрутизаторов) организации туннелей для IPv6-пакетов через маршрутную инфраструктуру IPv4. Узлам IPv6, которые используют этот метод, присваиваются специальные IPv6 уникастные адреса, которые в младших 32 битах содержат адрес IPv4. Этот тип адреса называется IPv4-compatible IPv6 address. Определен и второй тип IPv6 адреса, который содержит внутри IPv4 адрес. Этот адрес используется для представления IPv6 адресов узлам IPv4 (тем, что не поддерживают IPv6). Этот тип адреса называется IPv4-mapped IPv6 address.

Метки потоков

Поток — это последовательность пакетов, посылаемых отправителем определённому адресату.

Метки потоков — случайные 24-битные числа.

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

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

ПриоКурсивное начертаниеритезация пакетов обеспечивается маршрутизаторами на основе поля приоритета. Данное 4-битное поле содержит код требуемого приоритета. Множество значений этого поля разделено на два подмножества:

• от 0 до 7 — трафик с контролем перегрузки (например, протокол TCP снижает трафик при получении сигнала перегрузки);
• от 8 до 15 — трафик без контроля перегрузки (приложения реального времени с постоянной скоростью).

Формат заголовка пакета

Формат заголовка пакета IPv6

Переход с IPv4 на IPv6. Взаимодействие IPv6 и IPv4

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

Три основных способа обеспечения взаимодействия IPv6 и IPv4:

• туннелирование;
• двойной стек;
• трансляция протоколов.

Туннелирование

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

• "Маршрутизатор – Маршрутизатор";
• "Хост – Маршрутизатор";
• "Маршрутизатор – Хост".

Туннель, используемый в процессе передачи данных, должен иметь точку входа и точку выхода. Точка входа находится на границе инфраструктуры IPv4, а потому определить ее достаточно легко. Точка выхода может задаваться инкапсулятору как вручную (в этом случае туннелирование называется конфигурируемым), так и автоматически (так называемое автоматическое туннелирование). Во втором подходе декапсулятору присваивается совместимый IPv4/IPv6 адрес, в котором адрес IPv4 встроен в последние 32 бита адреса IPv6. Остаток IPv6-адреса в этом случае заполняется нулями.

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

Двойной стек

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

Трансляция протоколов

Трансляция протоколов заключается в преобразовании пакетов одной версии протокола в пакеты другой по определенным правилам. Она может осуществляться несколькими способами. Первый из них состоит в использовании протокол-шлюзов, которые размещаются на границах между IPv6-сетями и IPv4-сетями. Кроме того, трансляция может осуществляться с помощью транспортного ретранслятора, который обрабатывает в передаваемом пакете данных IP-заголовки и заголовки транспортного уровня. Наконец, трансляция протоколов возможна путем их преобразования на прикладном уровне через прокси-сервер.

Взаимодействие IPv6 и DNS

Еще одна проблема, связанная с внедрением IPv6, — ее несовместимость с DNS, которая используется сегодня в Интернете. DNS представлена в виде ресурсных записей, каждая из которых принадлежит конкретному доменному имени и содержит ряд сведений о нем, в том числе его IP-адрес. До начала внедрения IPv6 существовало 20 типов таких записей. Они относились к 32-разрядным IP-адресам (так называемые записи "A"), что делало DNS и IPv6 несовместимыми.

Однако затем был определен новый тип ресурсной записи "AAAA", который служит для хранения 128-битного IPv6-адреса. Сам адрес определен в информационной части этой записи и в виде имени представляется в специально созданном домене ip6.int. Это имя выглядит как набор символов, разделенных точками, и заканчивается суффиксом ip6.int.

Клиент, направляющий с устройства запросы на DNS-сервер, должен уметь распознавать записи как об адресах IPv4, так и об адресах IPv6. Получив запрос, DNS-сервер определяет тип ресурсной записи (A или AAAA) и отправляет ее устройству. Распознав запись, устройство выбирает для передачи данных либо протокол IPv4, либо протокол IPv6. При этом, когда IPv4-совместимый адрес назначается какому-либо узлу, в DNS создается две ресурсных записи: AAAA и A. Первая отображает этот адрес в 128-битном формате, а вторая – в 32-битном. Это позволяет устройствам, использующим только протокол IPv6, получать IPv6-адреса, а узлам, работающим только на IPv4 — IPv4 адреса.

Для полной совместимости с IPv6 DNS требует серьезной перестройки.

Канальный уровень

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

Основные задачи

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

Типы каналов (среды передачи данных)

• точка-точка (двухточечные);
• широковещательные (Ethernet, WiFi, Спутник);
• последовательные (переключаемые).

Широковещательные, т.е., когда один канал используется несколькими системами для взаимодействия. В случае широковещательного канала существует проблема доступа к передающей среде. Решение — управление доступом. Иногда говорят, что канальном уровне есть подуровень доступа к среде.

Обнаружение и исправление ошибок

Контроль четности

Вычисление контрольной суммы

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

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

При «правильном» выборе порождающего многочлена (делителя), остатки от деления на него будут обладать нужными свойствами хеширования — хорошей перемешиваемостью и быстрым алгоритмом вычисления. Второе обеспечивается тем, что степень порождающего многочлена обычно пропорциональна длине байта или машинного слова (например 8, 16 или 32).

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

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

Сеть Ethernet

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

Ни в одной из версий Ethernet не применяется прямое двоичное кодирование бита 0 напряжением 0 В и бита 1 — напряжением 5В, так как такой способ приводит к неоднозначности. Если одна станция посылает битовую строку 00010000, то другая может интерпретировать ее как 10000000 или 01000000, так как они не смогут отличить отсутствие сигнала (0 В) от бита 0 (0 В). Можно, конечно, кодировать единицу положительным напряжением +1 В, а ноль — отрицательным напряжением -1 В. Но при этом все равно возникает проблема, связанная с синхронизацией передатчика и приемника. Разные частоты работы их системных часов могу привести к рассинхронизации и неверной интерпретации данных. В результате приемник может потерять границу битового интервала. Особенно велика вероятность этого в случае длинной последовательности нулей или единиц. Таким образом, принимающей машине нужен способ однозначного определения начала, конца и середины каждого бита без помощи внешнего таймера. Это реализуется с помощью манчестерского кодирования. В манчестерском коде каждый временной интервал передачи одного бита делится на два равных периода. Бит со значением 1 кодируется высоким уровнем напряжения в первой половине интервала и низким — во второй половине, а нулевой бит кодируется обратной последовательностью — сначала низкое напряжение, затем высокое. Такая схема гарантирует смену напряжения в середине периода битов, что позволяет приемнику синхронизироваться с передатчиком. Недостатком манчестерского кодирования является то, что оно требует двойной пропускной способности линии по отношению к прямому двоичному кодированию, так как импульсы имеют половинную ширину. Например, для того чтобы отправлять данные со скоростью 10 Мбит/с, необходимо изменять сигнал 20 миллионов раз в секунду.

Формат кадра Ethernet

Преамбула (8 байт). Ethernet-кадр начинается с 8-байтового поля преамбулы. В каждый из первых 7 байт преамбулы записывается значение 10101010, а в последний байт — значение 10101011. Первые 7 байт должны «разбудить» принимающие адаптеры и помочь им синхронизировать свои таймеры с часами отправителя. Как уже отмечалось, адаптер А должен передать кадр со скоростью 10 Мбит/с, 100 Мбит/с или 1 Гбит/с в зависимости от типа локальной Ethernet-сети. Однако поскольку ничего не бывает абсолютно точным в реальном мире, скорость передачи всегда будет несколько отличаться от номинала. Величина этого отклонения скорости другим адаптерам локальной сети заранее не известна. Таким образом, первые 62 бита преамбулы, представляющие собой чередующиеся нули и единицы, позволяют приемнику с достаточной точностью настроиться на скорость передатчика, а последние два разряда (две единицы подряд) сообщают адаптеру В, что преамбула закончилась и следом идет уже первый информационный байт поля кадра. Адаптер В понимает, что следующие 6 байт содержат адрес получателя.

Адрес получателя (6 байт). Это поле содержит LAN-адрес принимающего адаптера. Получив Ethernet-кадр с адресом получателя, отличным от собственного физического адреса или широковещательного адреса локальной сети, адаптер отбрасывает кадр. В противном случае он передает содержимое поля данных сетевому уровню.

Адрес отправителя (6 байт). Это поле содержит LAN-адрес адаптера, передающего кадр в локальную сеть. Поле типа (2 байта). Поле типа позволяет локальной Ethernet-сети «мультиплексировать» протоколы сетевого уровня. Чтобы понять, что это означает, вспомним, что хосты могут помимо протокола IP использовать и другие протоколы. В самом деле, любой хост может поддерживать несколько протоколов сетевого уровня — разные протоколы для разных приложений. По этой причине, получив Ethernet-кадр, адаптер В должен знать, какому протоколу сетевого уровня он должен передать (то есть демультиплексировать) содержимое поля данных. Каждому сетевому протоколу (например, IP, Novell IPX или AppleTalk) присвоен зафиксированный в стандарте номер. Обратите внимание, что поле типа аналогично полю протокола в дейтаграмме сетевого уровня и полю номера порта сегмента транспортного уровня. Все эти поля служат для связи протокола одного уровня с протоколом уровнем выше.

Поле данных (от 46 до 1500 байт). Это поле содержит IP-дейтаграмму. Максимальная единица передачи (Maximal Transfer Unit, MTU) в Ethernet-сети составляет 1500 байт. Это означает, что если размер IP-дейтаграммы превышает 1500 байт, тогда хост должен разбить ее на отдельные фрагменты (см. подраздел «Фрагментация IP-дейтаграмм» в разделе «Интернет-протокол» главы 4). Минимальный размер поля данных равен 46 байт. Это означает, что если размер IP-дейтаграммы меньше 46 байт, то данные, помещаемые в это поле, дополняются байтами-заполнителями. При этом сетевой уровень получает дейтаграмму от канального уровня с этими дополнительными байтами и отсекает все лишнее сам, ориентируясь на поле длины в заголовке IP-дейтаграммы. Вот почему на практике в WireShark мы иногда получали 6 нулевых байтов в приходящем пакете.

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

Минимальный размер кадра

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

Связь характеристик канала

Пусть M — минимальный размер кадра

P – пропускная способность канала

M/P – время записи кадра в канал

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

M/P > 2T, где T=L/c

Примеры:

P=10 Mb/s M=64 B тогда L<7680 м

P=10 Gb/s M=64 B тогда L<7,68 м

Между тем, кроме верхней границы размера поля данных очень важна и нижняя граница. Поле данных, содержащее 0 байт, вызывает определенные проблемы. Дело в том, что когда приемопередатчик обнаруживает столкновение, он обрезает текущий кадр, а это означает, что отдельные куски кадров постоянно блуждают по кабелю. Чтобы было легче отличить нормальные кадры от мусора, сети Ethernet требуется кадр размером не менее 64 байт (от поля адреса получателя до поля контрольной суммы включительно). Если в кадре содержится меньше 46 байт данных, в него вставляется специальное поле Pad, с помощью которого размер кадра доводится до необходимого минимума. Другой (и даже более важной) целью установки ограничения размера кадра снизу является предотвращение ситуации, когда станция успевает передать короткий кадр раньше, чем его первый бит дойдет до самого дальнего конца кабеля, где он может столкнуться с другим кадром. Эта ситуация показана на рис. 4.17. В момент времени 0 станция А на одном конце сети посылает кадр. Пусть время прохождения кадра по кабелю равно т. За мгновение до того, как кадр достигнет конца кабеля (то есть в момент времени т - е), самая дальняя станция В начинает передачу. Когда станция В замечает, что получает большую мощность, нежели передает сама, она понимает, что произошло столкновение. Тогда она прекращает передачу и выдает 48-битный шумовой сигнал, предупреждающий остальные станции. Примерно в момент времени 2т отправитель замечает шумовой сигнал и также прекращает передачу. Затем он выжидает случайное время и пытается возобновить передачу. Если размер кадра будет слишком маленьким, отправитель закончит передачу прежде, чем получит шумовой сигнал. В этом случае он не сможет понять, произошло это столкновение с его кадром или с каким-то другим, и, следовательно, может предположить, что его кадр был успешно принят. Для предотвращения такой ситуации все кадры должны иметь такую длину, чтобы время их передачи было больше 2т. Для локальной сети со скоростью передачи 10 Мбит/с при максимальной длине кабеля в 2500 м и наличии четырех повторителей (требование спецификации 802.3) (мое: вероятно L=2500*5, где 5 – максимальное количество участков кабеля между компьютерами) минимальное время передачи одного кадра должно составлять в худшем случае примерно 50 мкс, включая время на прохождение через повторитель, которое, разумеется, отлично от нуля. Следовательно, длина кадра должна быть такой, чтобы время передачи было по крайней мере не меньше этого минимума. При скорости 10 Мбит/с на передачу одного бита тратится 1000 не, значит, минимальный размер кадра должен быть равен 500 бит. При этом можно гарантировать, что система сможет обнаружить коллизии в любом месте кабеля. Из соображений большей надежности это число было увеличено до 512 бит или 64 байт. Кадры меньшего размера с помощью поля Pad искусственно дополняются до 64 байт. По мере роста скоростей передачи данных в сети минимальный размер кадра должен увеличиваться, или должна пропорционально уменьшаться максимальная длина кабеля. Для 2500-метровой локальной сети, работающей на скорости 1 Гбит/с, минимальный размер кадра должен составлять 6400 байт. Или же можно использовать кадр размером 640 байт, но тогда надо сократить максимальное расстояние между станциями сети до 250 м. По мере приближения к гигабитным скоростям подобные ограничения становятся все более суровыми.

Сетевая безопасность

Виды нарушителей и цели их действия

Шифрование данных

Стандарты шифрования

Wired Equivalent Privacy (WEP) - первый стандарт (ключ: 5 или 13 ASCII-символов) – не является достаточно криптостойким.

Wi-Fi Protected Access (WPA) – включает протоколы 802.1х, TKIP, MIC и стандарт шифрования AES (Advanced Encryption Standard):

• 802.1х - протокол аутентификации пользователей (нужен спец. RADIUS-сервер);
• TKIP (Temporal Key Integrity Protocol) – динамические ключи шифрования (очень часто меняются);
• MIC (Message Integrity Check) - проверка целостности сообщений (для предотвращения перехвата).

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

Первым стандартом, использующимся для шифрования данных в беспроводных сетях, был стандарт WEP (Wired Equivalent Privacy). В соответствии со стандартом WEP шифрование осуществляется с помощью 40- или 104-битного ключа (некоторые модели беспроводного оборудования поддерживают и более длинные ключи), а сам ключ представляет собой набор ASCII-символов длиной 5 (для 40-битного) или 13 (для 104-битного ключа) символов. Набор этих символов переводится в последовательность шестнадцатеричных цифр, которые и являются ключом. Допустимо также вместо набора ASCII-символов напрямую использовать шестнадцатеричные значения (той же длины).

Как правило, в утилитах настройки беспроводного оборудования указываются не 40- или 104-битные ключи, а 64- или 128-битные. Дело в том, что 40 или 104 бита – это статическая часть ключа, к которой добавляется 24-битный вектор инициализации, необходимый для рандомизации статической части ключа. Вектор инициализации выбирается случайным образом и динамически меняется во время работы. В результате c учётом вектора инициализации общая длина ключа и получается равной 64 (40+24) или 128 (104+24) битам.

Протокол WEP-шифрования, даже со 128-битным ключом, считается не очень стойким, поэтому в устройствах стандарта 802.11g поддерживается улучшенный алгоритм шифрования WPA – Wi-Fi Protected Access, который включает протоколы 802.1х, EAP, TKIP и MIC.

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

Протокол TKIP (Temporal Key Integrity Protocol) – это реализация динамических ключей шифрования. Ключи шифрования имеют длину 128 бит и генерируются по сложному алгоритму, а общее количество возможных вариантов ключей достигает сотни миллиардов, и меняются они очень часто.

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

TKIP, MIC и 802.1X (части уравнения WPA) внесли свою лепту в усиление шифрования данных сетей, использующих WPA.

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

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

Другим важным механизмом является проверка целостности сообщений (Message Integrity Check, MIC). Ее используют для предотвращения перехвата пакетов данных, содержание которых может быть изменено, а модифицированный пакет вновь передан по сети. MIC построена на основе мощной математической функции, которая применяется на стороне отправителя и получателя, после чего сравнивается результат. Если проверка показывает на несовпадение результатов вычислений, данные считаются ложными и пакет отбрасывается.

При этом механизмы шифрования, которые используются для WPA и WPA-PSK, являются идентичными. Единственное отличие WPA-PSK состоит в том, что аутентификация производится с использованием пароля, а не по сертификату пользователя.

Понятие сетевой безопасности

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

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

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

В обоих случаях речь идет о сетевой безопасности. Ее основные аспекты:

• конфиденциальность;
• целостность данных;
• аутентификация;
• доступность.

Конфиденциальность

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

Целостность данных

Целостность данных – злоумышленник не должен иметь возможность изменить передаваемые данные.

Аутентификация

Аутентификация - установление подлинности пользователя.

Доступность

Доступность – злоумышленник не должен помешать передаче данных.

Угрозы безопасности

• Сниффинг пакетов (Wireshark, вардрайвинг, спутниковая рыбалка)
• IP-спуфинг (подмена IP-адреса).
  Подробнее  

  IP-спуфинг (spoof по-английски „мистификация“) — это вид хакерской атаки, заключающийся в использовании чужого IP-адреса с целью обмана системы безопасности. Метод, используемый в некоторых атаках. Состоит в проставлении в поле обратного (source) адреса IP-пакета неверного адреса. Применяется с целью сокрытия истинного адреса атакующего, с целью вызвать ответный пакет на нужный адрес и с иными целями.

  Протокол транспортного уровня TCP имеет встроенный механизм для предотвращения спуфинга — так называемые номера последовательности и подтверждения (sequence number, acknowledgement number). Протокол UDP не имеет такого механизма, следовательно, построенные на его основе приложения более уязвимы для спуфинга.

  Пример  

  Предположим, что A “доверяет” B (не требует пароля). Z блокирует B посылая кучу запросов (DoS-атака). Z посылает запрос на подключение (SYN) к A от имени B. A соглашается, посылая ACK к B. B не может сообщить об ошибке (он атакован). Z посылает команды A (например, отправить файл с паролями к B).

• Аутентификация (Authentication)
  • Перехват ключа/пароля
  • Подбор (Brute Force)
    Подробнее  

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

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

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

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

    Пример прямого подбора  

    Имя пользователя = Jon Пароли = smith, michael-jordan, [pet names], [birthdays], [car names], ...

    Пример обратного подбора  

    Пароль = 12345678 Имена пользователей = Jon, Dan, Ed, Sara, Barbara, ...

    }}
  • Недостаточная аутентификация (Insufficient Authentication)
    Подробнее  

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

    Примеры  

    Многие Web-приложения по умолчанию используют для административного доступа ссылку в корневой директории сервера (/admin/). Обычно ссылка на эту страницу не фигурирует в содержимом сервера, однако страница доступна с помощью стандартного браузера. Поскольку пользователь или разработчик предполагает, что никто не воспользуется этой страницей, так как ссылки на неё отсутствует, зачастую реализацией аутентификации пренебрегают. И для получения контроля над сервером злоумышленнику достаточно зайти на эту страницу.

    Другой пример – аутентификация по IP-адресу. IP-адрес можно подменить.

• Man-in-the-Middle - «человек посередине»
  Подробнее  

  Man-in-the-Middle - «человек посередине» — термин в криптографии, обозначающий ситуацию, когда атакующий способен читать и видоизменять по своей воле сообщения, которыми обмениваются корреспонденты, причём ни один из последних не может догадаться о его присутствии в канале.

  Пример: FTP, TelNet  

  Пример использования: для пересылки файла FTP-клиент может посылать команду PORT мой IP-адрес, порт , а потом RETR имя файла. Пусть администратор зашел на сервер по FTP. Тогда злоумышленник может послать IP-пакет с вышеуказанными командами FTP, указав в заголовке сетевого уровня IP-адрес администратора (чтобы пакет не заподозрили и отправили приложению FTP), а в параметрах FTP-команды – свой IP-адрес и имя файла с логинами и паролями. Готово! Один пакет – и удаленный компьютер полностью под нашим контролем (так как мы знаем логин и пароль администратора).

  Для TelNet – то же самое. Во время работы администратора, можно отправить команду операционной системе «скопировать файл с паролями на удаленный компьютер».

• Атаки типа: «отказ в обслуживании»
• ICMP пакеты длиннее 65 Кб (ping of death) (1996 г.)
  Подробнее  

  On the Internet, ping of death is a denial of service (DoS) attack caused by an attacker deliberately sending an IP packet larger than the 65,536 bytes allowed by the IP protocol. One of the features of TCP/IP is fragmentation; it allows a single IP packet to be broken down into smaller segments. In 1996, attackers began to take advantage of that feature when they found that a packet broken down into fragments could add up to more than the allowed 65,536 bytes. Many operating systems didn't know what to do when they received an oversized packet, so they froze, crashed, or rebooted. Ping of death attacks were particularly nasty because the identity of the attacker sending the oversized packet could be easily spoofed and because the attacker didn't need to know anything about the machine they were attacking except for its IP address. By the end of 1997, operating system vendors had made patches available to avoid the ping of death. Still, many Web sites continue to block Internet Control Message Protocol (ICMP) ping messages at their firewalls to prevent any future variations of this kind of denial of service attack.

• Лавинные атаки
• Недостаточное противодействие автоматизации
  Подробнее  

  Недостаточное противодействие автоматизации возникает, когда сервер позволяет автоматически выполнять операции, которые должны проводиться вручную. Для некоторых функций приложения необходимо реализовывать защиту от автоматических атак. Автоматизированные программы могут варьироваться от безобидных роботов поисковых систем до систем автоматизированного поиска уязвимостей и регистрации учетных записей. Подобные роботы генерируют тысячи запросов в минуту, что может привести к падению производительности всего приложения. Чтобы противодействовать ботам, используется CAPTCHA (от англ. «Completely Automated Public Turing test to tell Computers and Humans Apart» — полностью автоматизированный публичный тест Тьюринга для различия компьютеров и людей) Основная идея теста: предложить пользователю такую задачу, которую может решить человек, но которую крайне трудно научить решать компьютер. В основном это задачи на распознавание символов.

• Распределенные атаки (Distributed Denial of Service)
  Подробнее  

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

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

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

  Методы обнаружения можно разделить на несколько больших групп:

  • сигнатурные — основанные на качественном анализе трафика;
  • статистические — основанные на количественном анализе трафика;
  • гибридные — сочетающие в себе достоинства двух предыдущих методов.

  Пример  

  Mydoom (известен также как Novarg) — почтовый червь для Microsoft Windows и Windows NT, эпидемия которого началась 26 января 2004. Распространялся по электронной почте и через файлообменную сеть Kazaa. Файл-носитель червя имеет размер около 28 килобайт и содержит текстовую строку «sync-1.01; andy; I’m just doing my job, nothing personal, sorry». При заражении компьютера Mydoom модифицирует операционную систему, блокируя доступ к сайтам многих антивирусных компаний, новостным лентам и различным разделам сайта компании Microsoft. В период с 1 по 12 февраля Mydoom.A проводил DDoS‑атаку на сайт Microsoft, а Mydoom.B — на сайт SCO Group.

  За несколько дней до того SCO Group заявила, что подозревает в создании червя сторонников операционной системы GNU/Linux, в которой якобы использовался принадлежавший SCO код, и объявила награду в 250 тысяч долларов за информацию, которая поможет поймать создателей MyDoom.

• SYN-атака: отправка множества запросов (SYN) на установление TCP-соединения
  Подробнее  

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

• Эхо-атака: отправка серии широковещательных ICMP-запросов с IP-адресом отправителя, подмененным на IP жертвы. Ответы – переполнят сеть жертвы.
  Подробнее  

  In such an attack, a perpetrator sends a large amount of ICMP echo request (ping) traffic to IP broadcast addresses, all of which have a spoofed source IP address of the intended victim. If the routing device delivering traffic to those broadcast addresses delivers the IP broadcast to all hosts (for example via a layer 2 broadcast), most hosts on that IP network will take the ICMP echo request and reply to it with an echo reply, multiplying the traffic by the number of hosts responding. On a multi-access broadcast network, hundreds of machines might reply to each packet. In the late 1990s, many IP networks would participate in Smurf attacks (that is, they would respond to pings to broadcast addresses). Today, thanks largely to the ease with which administrators can make a network immune to this abuse, very few networks remain vulnerable to Smurf attacks.

• Вирусы
  Подробнее  

  Внедряют себя в исполняемый код других программ/документов.

• Сетевые черви
  Подробнее  

  Являются отдельные программами.

  Примеры  

  Kido, Conficker

• Троянские программы
  Подробнее  

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

• Сетевая разведка
  Подробнее  

  Сетевая разведка включает в себя сканирование портов, шпионские программы. Ее неотъемлимой частью является заметание следов (Rootkit). Rootkit (руткит, от англ. root kit, то есть «набор root'а») — программа или набор программ для скрытия следов присутствия злоумышленника или вредоносной программы в системе.

• Инъекция (SQL, PHP, XPath)
  • Переполнение буфера
  • Атака на функции форматирования строк
    Подробнее  

    При использовании этих атак путь исполнения программы модифицируется методом перезаписи областей памяти с помощью функций форматирования символьных переменных. Уязвимость возникает, когда пользовательские данные применяются в качестве аргументов функций форматирования строк, таких как fprintf, printf, sprintf, setproctitle, syslog и т.д. Если атакующий передает приложению строку, содержащую символы форматирования ("%f", "%p", "%n" и т.д.), то у него появляется возможность:

    • выполнить произвольный код на сервере;
    • считывать значения из стека;
    • вызывать ошибки в программе/отказ в обслуживании.
  • Выполнение команд ОС
    Подробнее  

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

• Человеческий фактор

Введение в сетевое программирование

Постановка задачи

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

Разработка протокола

Назовем наш протокол Calculation 0.1. Для начала определим формат запроса и ответа. Пусть запрос клиента должен начинаться со слова CALC, далее через пробел операция и потом два числа — аргументы. Тогда запрос клиента на вычисление произведения 12 и 6 будет выглядеть так:

CALC * 12 6 ENTER

Ответ сервера будет начинаться со слова OK, если запрос был корректен и далее через пробел число – результат вычислений. Если же запрос некорректен, ответом будет слово ERR.

ОК 72 ENTER (если все нормально)

ERR ENTER (если запрос неправильный)

ENTER нужен, чтобы узнать где конец строки.

После определения правил работы протокола, можно перейти к реализации. И тут встает вопрос: используем TCP или UDP? Мы разберем оба случая. И, для начала, разберем алгоритм взаимодействия сервера с клиентом, а потом реализуем его программно.

Алгоритм работы сервера (TCP)

1. Запускается заранее, до подключения клиентов.
2. Сообщает ОС, что будет ожидать сообщений, посланных на заранее утвержденный порт №12345.
3. Выделяет память для очереди подключений.
4. В цикле:

• устанавливает соединение с клиентом из очереди; если очередь пуста, то ждет подключения клиента;
• принимает/передает данные;
• закрывает соединение с клиентом.

Алгоритм работы клиента (TCP)

1. Получает от ОС случайный номер порта для общения с сервером.
2. Устанавливает соединение с сервером.
3. Передает/принимает данные.
4. Закрывает соединение с сервером.

Алгоритм работы сервера (UDP)

1. Запускается заранее, до подключения клиентов.
2. сообщает ОС, что будет ожидать сообщений, посланных на заранее утвержденный порт №12345.
3. В цикле:

• ждет прихода сообщения;
• обрабатывает данные;
• передает результат.

Основное отличие UDP от TCP — не нужно возиться с соединениями.

Алгоритм работы клиента (UDP)

1. Получает от ОС случайный номер порта для общения с сервером.
2. Передает/принимает данные.

TCP-сервер (C++)

Будем использовать winsock2.h

#include <winsock2.h>
#include <ws2tcpip.h>
#include <stdlib.h>
#include <stdio.h>

// В опциях проекта, в разделе Linker, в пункте Additional Dependancies укажите Ws2_32.lib

int __cdecl main(void) 
{
	WSADATA wsaData;
	SOCKET ListenSocket,ClientSocket;  // впускающий сокет и сокет для клиентов
	sockaddr_in ServerAddr;  // это будет адрес сервера
	int err, maxlen = 512;  // код ошибки и размер буферов
	char* recvbuf=new char[maxlen];  // буфер приема
	char* result_string=new char[maxlen];  // буфер отправки


	// Initialize Winsock
	WSAStartup(MAKEWORD(2,2), &wsaData);

	// Create a SOCKET for connecting to server
	ListenSocket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);

	// Setup the TCP listening socket
	ServerAddr.sin_family=AF_INET;
	ServerAddr.sin_addr.s_addr=inet_addr("127.0.0.1");
	ServerAddr.sin_port=htons(12345);
	err = bind( ListenSocket, (sockaddr *) &ServerAddr, sizeof(ServerAddr));
	if (err == SOCKET_ERROR) {
		printf("bind failed: %d\n", WSAGetLastError());
		closesocket(ListenSocket);
		WSACleanup();
		return 1;
	}

	err = listen(ListenSocket, 50);
	if (err == SOCKET_ERROR) {
		printf("listen failed: %d\n", WSAGetLastError());
		closesocket(ListenSocket);
		WSACleanup();
		return 1;
	}
	while (true) {
		// Accept a client socket
		ClientSocket = accept(ListenSocket, NULL, NULL);
		err = recv(ClientSocket, recvbuf, maxlen, 0);
		if (err > 0) {
			recvbuf[err]=0;
			printf("Received query: %s\n", (char* )recvbuf);
			// вычисляем результат
			int result=72;
			_snprintf_s(result_string,maxlen,maxlen,"OK %d\n",result);
			// отправляем результат на сервер
			send( ClientSocket,  result_string, strlen(result_string), 0 );
			printf("Sent answer: %s\n", result_string);
		}
		else if (err == 0)
			printf("Connection closing...\n");
		else  {
			printf("recv failed: %d\n", WSAGetLastError());
			closesocket(ClientSocket);
			WSACleanup();
			return 1;
		}

		// shutdown the connection since we're done
		closesocket(ClientSocket);
	}
}

TCP-клиент (C++)

#include <winsock2.h>
#include <ws2tcpip.h>
#include <stdlib.h>
#include <stdio.h>

// В опциях проекта, в разделе Linker, в пункте Additional Dependancies укажите Ws2_32.lib

int __cdecl main(void) 
{
	WSADATA wsaData;
	SOCKET ConnectSocket;  // впускающий сокет и сокет для клиентов
	sockaddr_in ServerAddr;  // это будет адрес сервера
	int err, maxlen = 512;  // код ошибки и размер буферов
	char* recvbuf=new char[maxlen];  // буфер приема
	char* query=new char[maxlen];  // буфер отправки


	// Initialize Winsock
	WSAStartup(MAKEWORD(2,2), &wsaData);

	// Connect to server
	ConnectSocket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);

	ServerAddr.sin_family=AF_INET;
	ServerAddr.sin_addr.s_addr=inet_addr("127.0.0.1");
	ServerAddr.sin_port=htons(12345);

	err = connect( ConnectSocket, (sockaddr *) &ServerAddr, sizeof(ServerAddr));

	if (err == SOCKET_ERROR) {
		printf("connect failed: %d\n", WSAGetLastError());
		closesocket(ConnectSocket);
		WSACleanup();
		return 1;
	}

	_snprintf_s(query,maxlen,maxlen,"CALC * 12 6\n");
	// отправляем запрос на сервер
	send( ConnectSocket,  query, strlen(query), 0 );
	printf("Sent: %s\n", query);

	// получаем результат
	err = recv(ConnectSocket, recvbuf, maxlen, 0);
	if (err > 0) {
		recvbuf[err]=0;
		printf("Result: %s\n", (char* )recvbuf);
	}
	else if (err == 0)
		printf("Connection closing...\n");
	else  {
		printf("recv failed: %d\n", WSAGetLastError());
		closesocket(ConnectSocket);
		WSACleanup();
		return 1;
	}

	// shutdown the connection since we're done
	closesocket(ConnectSocket);
	
}

UDP-сервер (C++)

#include <winsock2.h>
#include <ws2tcpip.h>
#include <stdlib.h>
#include <stdio.h>

// В опциях проекта, в разделе Linker, в пункте Additional Dependancies укажите Ws2_32.lib

int __cdecl main(void) 
{
	WSADATA wsaData;
	SOCKET SendRecvSocket;  // сокет для приема и передачи
	sockaddr_in ServerAddr, ClientAddr;  // это будет адрес сервера и клиентов
	int err, maxlen = 512, ClientAddrSize=sizeof(ClientAddr);  // код ошибки, размер буферов и размер структуры адреса
	char* recvbuf=new char[maxlen];  // буфер приема
	char* result_string=new char[maxlen];  // буфер отправки


	// Initialize Winsock
	WSAStartup(MAKEWORD(2,2), &wsaData);

	// Create a SOCKET for connecting to server
	SendRecvSocket = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);

	// Setup the TCP listening socket
	ServerAddr.sin_family=AF_INET;
	ServerAddr.sin_addr.s_addr=inet_addr("127.0.0.1");
	ServerAddr.sin_port=htons(12345);
	err = bind( SendRecvSocket, (sockaddr *) &ServerAddr, sizeof(ServerAddr));
	if (err == SOCKET_ERROR) {
		printf("bind failed: %d\n", WSAGetLastError());
		closesocket(SendRecvSocket);
		WSACleanup();
		return 1;
	}

	while (true) {
		// Accept a client socket
		err = recvfrom(SendRecvSocket,recvbuf,maxlen,0,(sockaddr *)&ClientAddr,&ClientAddrSize);
		if (err > 0) {
			recvbuf[err]=0;
			printf("Received query: %s\n", (char* )recvbuf);
			// вычисляем результат
			int result=72;
			_snprintf_s(result_string,maxlen,maxlen,"OK %d\n",result);
			// отправляем результат на сервер
			sendto(SendRecvSocket,result_string,strlen(result_string),0,(sockaddr *)&ClientAddr,sizeof(ClientAddr));
			printf("Sent answer: %s\n", result_string);
		}
		else  {
			printf("recv failed: %d\n", WSAGetLastError());
			closesocket(SendRecvSocket);
			WSACleanup();
			return 1;
		}
	}
}

UDP-клиент (C++)

#include <winsock2.h>
#include <ws2tcpip.h>
#include <stdlib.h>
#include <stdio.h>

// В опциях проекта, в разделе Linker, в пункте Additional Dependancies укажите Ws2_32.lib

int __cdecl main(void) 
{
	WSADATA wsaData;
	SOCKET SendRecvSocket;  // сокет для приема и передачи
	sockaddr_in ServerAddr;  // это будет адрес сервера и клиентов
	int err, maxlen = 512;  // код ошибки, размер буферов и размер структуры адреса
	char* recvbuf=new char[maxlen];  // буфер приема
	char* query=new char[maxlen];  // буфер отправки


	// Initialize Winsock
	WSAStartup(MAKEWORD(2,2), &wsaData);

	// Create a SOCKET for connecting to server
	SendRecvSocket = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);

	ServerAddr.sin_family=AF_INET;
	ServerAddr.sin_addr.s_addr=inet_addr("127.0.0.1");
	ServerAddr.sin_port=htons(12345);

	_snprintf_s(query,maxlen,maxlen,"CALC * 12 6\n");
	// отправляем запрос на сервер
	sendto(SendRecvSocket,query, strlen(query), 0, (sockaddr *)&ServerAddr,sizeof(ServerAddr));  
	printf("Sent: %s\n", query);

	// получаем результат
	err = recvfrom(SendRecvSocket,recvbuf,maxlen,0,0,0);
	if (err > 0) {
		recvbuf[err]=0;
		printf("Result: %s\n", (char* )recvbuf);
	}
	else {
		printf("recv failed: %d\n", WSAGetLastError());
		closesocket(SendRecvSocket);
		WSACleanup();
		return 1;
	}

	closesocket(SendRecvSocket);

}

TCP-сервер (C#, .NET)

using System;
using System.IO;
using System.Net;
using System.Net.Sockets;
using System.Text;

class TCP_Server
{
    public static void Main()
    {
        TcpListener server = null;
        try
        {
            Int32 port = 12345; //порт сервера
            IPAddress localAddr = IPAddress.Parse("127.0.0.1");//ip-адрес сервера (интерфейс)
            
            //TcpListener - класс TCP-сервера из .Net Framework Class Library
            server = new TcpListener(localAddr, port);

            // начинаем ожидание подсоединений клиентов на интерфейсе localAddr и порту port
            server.Start();

            // буффер для приема сообщений и соответствующая ему строка для вывода на экран
            Byte[] bytes = new Byte[1000];
            String data;
            
            //ответ клиенту
            String answer_message;

            //цикл обработки подсоединений клиентов
            while (true)
            {
                Console.Write("Waiting for a connection... ");
                // Ждем соединения клиента
                TcpClient client = server.AcceptTcpClient();
                //Ура! Кто-то подсоединился!
                Console.WriteLine("Connected!");
                // вводим поток stream для чтения и записи через установленное соединение
                NetworkStream stream = client.GetStream();
                int i = stream.Read(bytes, 0, bytes.Length);
                if (i > 0)
                {
                    // преобразуем принятые данные в строку ASCII string.
                    data = System.Text.Encoding.ASCII.GetString(bytes, 0, i);
                    //печатаем то, что получили
                    Console.WriteLine("Received: {0}", data);
                    //анализируем запрос клиента и вычисляем результат
                    int res = 72;
                    answer_message = "OK " + res.ToString() + (char)13 + (char)10;
                    //печатаем то, что будем отправлять
                    Console.WriteLine("Sent: {0}", answer_message);
                    //преобразуем строчку-ответ сервера в массив байт
                    byte[] msg = System.Text.Encoding.ASCII.GetBytes(answer_message);
                    // отправляем ответ
                    stream.Write(msg, 0, msg.Length);
                }

                // закрываем соединение
                client.Close();
            }
        }
        catch (SocketException expt)
        {
            Console.WriteLine("SocketException: {0}", expt);
        }
        finally
        {
            // Stop listening for new clients.
            server.Stop();
        }

        Console.WriteLine("\nHit enter to continue...");
        Console.Read();
    }
}

TCP-клиент (C#, .NET)

using System;
using System.Collections.Generic;
using System.Text;
using System.Net.Sockets;

namespace ClientCSharp
{
    class TCP_Client
    {
        static void Main(string[] args)
        {
            try
            {
                Int32 port = 12345;//порт сервера
                string message = "CALC * 12 6\n";//строка, которую пошлем серверу
                TcpClient client = new TcpClient("localhost", port);

                //преобразуем строчку в массив байт
                Byte[] data = System.Text.Encoding.ASCII.GetBytes(message);

                // вводим поток stream для чтения и записи через установленное соединение                
                NetworkStream stream = client.GetStream();

                // посылаем сообщение серверу 
                stream.Write(data, 0, data.Length);

                Console.WriteLine("Sent: {0}", message);//печатаем то, что отправили

                // буффер для приема сообщений
                data = new Byte[1000];

                // строка для приема сообщений сервера
                String responseData;

                // получаем сообщение от сервера
                Int32 bytes = stream.Read(data, 0, data.Length);
                responseData = System.Text.Encoding.ASCII.GetString(data, 0, bytes);
                //печатаем то, что получили
                Console.WriteLine("Received: {0}", responseData);

                // закрываем соединение
                stream.Close();
                client.Close();
            }
            catch (ArgumentNullException expt)
            {
                Console.WriteLine("ArgumentNullException: {0}", expt);
            }
            catch (SocketException expt)
            {
                Console.WriteLine("SocketException: {0}", expt);
            }

            Console.WriteLine("\n Press Enter to continue...");
            Console.Read();
        }
    }
}