9. МАРШРУТИЗАЦИЯ ПРОТОКОЛА IP 9.1.  Сетевая маршрутизация   Большинство сетей, работающих в государственном или частном секторе в нашей стране, давно превратились в серьезный инструмент. За сравнительно быстрое время они выросли из небольших локальных сетей в большие распределенные сети с огромным числом пользователей. В таких сетях ключевой характеристикой является надежность, так как задачи, решаемые с их помощью, зачастую напрямую влияют на успешность работы всей организации. Существует несколько методов повышения надежности сети. Например, разделение всей сети на подсети и введение маршрутизации способно обеспечить требуемую надежность и достаточно простую схему поиска нужного абонента. Другой метод использует виртуальные локальные сети, которые позволяют повысить надежность за счет объединения пользователей в широковещательные домены. Для расширения таких доменов (сегментов или подсетей) с включением в них разнообразных сетевых устройств обычно применяются коммутаторы и протоколы остовых деревьев (spanning tree). И хотя такие схемы по заявлениям производителей позволяют практически неограниченно расширять подсети, при этом получается сеть, которой намного труднее управлять и в которой сложнее устранять неисправности. В реальной жизни именно маршрутизаторы являются основными узлами сложных сетей, например Internet. В подавляющем большинстве случаев именно они, а не широко рекламируемые коммутаторы ATM, Ethernet или FDDI, являются базовыми устройствами распределенных корпоративных сетей. Это особенно справедливо в российских условиях. В данной связи разговор о маршрутизации чрезвычайно актуален. Как известно, протокол IP работает на сетевом уровне. Именно на этом уровне реализуется межсетевое взаимодействие, в частности, маршрутизация дейтаграмм в Internet. Но главное, что именно на сетевом уровне принимается решение о маршрутизации. Маршрутизатор соединяет несколько различных физических сетей. Для каждого поступающего пакета маршрутизатор принимает решение о том, куда его переслать. Пакет «летает» от маршрутизатора к маршрутизатору, пока не достигнет сети, в которой находится станция-адресат. В роли маршрутизатора может выступать специальный компьютер. В большинстве реализаций стека TCP/IP рабочая станция с несколькими сетевыми интерфейсами также может выполнять функции маршрутизатора, однако для этого она должна быть специальным образом сконфигурирована. Программное обеспечение протокола IP выполняет функции маршрутизации, выбирая путь для передачи информации в сложной схеме физических сетей. На маршрутизаторах и на конечных станциях для определения маршрута поддерживаются специальные таблицы маршрутизации. Выбор маршрута осуществляется на основе адреса сети назначения, который определяется по адресу получателя. Протокол IP определяет маршрут отдельно для каждой дейтаграмммы, не гарантируя надежной доставки в нужном порядке. Он непосредственно отображает данные на нижележащий физический уровень. Тем самым достигается высокая эффективность доставки дейтаграмм. Распределенную сеть можно рассматривать как набор сетевых устройств и сетей, связанных между собой маршрутизаторами. Стек протоколов TCP/IP разработан для взаимодействия удаленных систем в сложных, распределенных сетях. Отдельные сети с коммутацией пакетов связываются маршрутизаторами. Два устройства, подключенные к одной сети, могут посылать пакеты друг другу. Кроме того, сеть получает пакеты из удаленной сети и доставляет их определенному получателю в локальной сети или передает дальше, другим сетям. Если два устройства, расположенные в разных сетях, хотят переслать друг другу информацию, отправитель посылает пакеты определенному маршрутизатору. Тот передает пакет через систему маршрутизаторов и сетей до тех пор, пока пакет не достигнет маршрутизатора, который подключен напрямую к сети получателя. Этот конечный маршрутизатор затем передаст пакет получателю по известному физическому адресу. Маршрутизаторы передают пакеты, основываясь на номере (адресе) сети получателя, а не на его физическом адресе. Поэтому информация, необходимая маршрутизатору, зависит от числа сетей, составляющих общую распределенную сеть, но не от числа устройств. Выделяют два типа маршрутизации: прямую и косвенную. При прямой мар­шрутизации отправитель в определенной IP-сети может напрямую передавать кадры любому получателю в той же сети. При этом не требуется функциональность IP-маршрутизации. Для передачи дейтаграммы с использованием прямой маршрутизации, отпра­витель инкапсулирует эту дейтаграмму в кадр канального уровня, определяет с помощью протокола ARP физический адрес получателя по известному IP-адресу и, используя сетевое аппаратное обеспечение, доставляет дейтаграмму. Косвенная маршрутизация происходит в том случае, если отправитель и получатель находятся в разных IP-сетях. Косвенная маршрутизация требует, чтобы отправитель передавал дейтаграммы маршрутизатору для доставки их через рас­пределенную сеть. Косвенная маршрутизация — это процесс более сложный, чем прямая маршрутизация, ввиду следующих двух причин: q       Отправитель должен определить маршрутизатор, которому необходимо адресовать дейтаграммы для доставки; q       Маршрутизатор должен уметь доставлять дейтаграммы к целевой сети, в которой располагается получатель. Поясним на простом примере отличия прямой и косвенной маршрутизации. Предположим, что какой-либо маршрутизатор связывает две сети и, следовательно, он имеет два IP-адреса и два физических адреса для каждого из своих портов, присоединенных к этим сетям. Когда отправитель в любой из сетей направляет свой пакет маршрутизатору, то это будет прямой маршрутизацией. Если маршрутизатор отправляет пакет получателю в любой из сетей — это также прямая маршрутизация. Однако, если рассматривать взаимную работу отправителя и получателя через маршрутизатор, то их взаимодействие осуществляется с помощью косвенной маршрутизации. Маршрутизация выполняется маршрутизатором на уровне протокола IP. Этот процесс полностью прозрачен для протоколов TCP, UDP и сетевых приложений. Перед отправкой пакета отправитель проверяет сетевой префикс IP-адреса получателя, сравнивая его с префиксом своей сети. Совпадение означает, что дейтаграмма может быть послана напрямую. Если номера сетей не совпадают, отправитель должен послать дейтаграмму маршрутизатору. Обычно параметр «маршрутизатор по умолчанию» (default router) настраивается на каждой рабочей станции сетевым администратором. Маршрутизатор по умолчанию отвечает за доставку дейтаграмм всем устройствам, которые не подключены к сети отправителя. Маршрутизатор принимает решение о передаче каждой дейтаграммы на основании своей таблицы маршрутизации. В качестве индекса таблицы используется номер сети, полученный из поля «Адрес получателя» в заголовке IP-дейтаграммы. Если получатель располагается в сети, подключенной к одному из портов маршрутизатора, последний может доставить дейтаграмму напрямую, не посылая ее другим маршрутизаторам. В противном случае маршрутизатор должен отослать дейтаграмму другому маршрутизатору, который находится ближе к получателю. Существует два подхода к выбору маршрута: q       одношаговый подход; q       маршрутизация от источника. Согласно методу одношаговой маршрутизации каждый маршрутизатор и конечный узел принимает участие в выборе только одного шага передачи дейтаграммы. В каждой строке таблицы маршрутизации указывается не весь маршрут (в виде последовательности IP-адресов маршрутизаторов, через которые должна пройти дейтаграмма), а только один IP-адрес следующего маршрутизатора (маршрутизатора на том пути, по которому нужно передать дейтаграмму). Вместе с дейтаграммой этому маршрутизатору передается и ответственность за выбор следующего шага. Такой подход распределяет задачу выбора маршрута и снимает ограничение на максимальное количество маршрутизаторов в пути. Кроме того, за счет использования маршрутизатора по умолчанию (который обычно занимает в таблице маршрутизации последнюю строку) существенно сокращается объем таблицы. Все дейтаграммы, номера сетей которых отсутствуют в таблице маршрутизации, передаются маршрутизатору по умолчанию. Подразумевается, что маршрутизатор по умолчанию передает дейтаграмму в магистральную сеть, а маршрутизаторы, подключенные к магистральной сети, имеют полную информации о ее топологии. Существуют различные алгоритмы построения таблиц для одношаговой маршрутизации. Их делят на три класса: q       Алгоритмы фиксированной маршрутизации. Они применяются в сетях с простой топологией и основаны на составлении таблиц маршрутизации «вручную» администратором сети. q       Алгоритмы простой маршрутизации. Они разделяются на три подкласса: ·        случайная маршрутизация (дейтаграммы передаются в любом случайном направлении, кроме исходного); ·        лавинная маршрутизация (дейтаграммы передаются во всех направлениях, кроме исходного); ·        адаптивная маршрутизация (таблица маршрутизации составляется на основании данных, содержащихся в проходящих через маршрутизатор дейтаграммах). q       Алгоритмы адаптивной маршрутизации. Основные алгоритмы, применяемые в современных сетях. Маршрутизаторы периодически обмениваются между собой информацией о сетевой топологии. При маршрутизации от источника выбор маршрута производится конечным узлом или первым маршрутизатором на пути следования дейтаграммы. Все остальные маршрутизаторы только отрабатывают выбранный маршрут. Этот метод в сетях IP применяется только в целях отладки. Управление таблицей маршрутизации на маршрутизаторах в большой распределенной сети является сложной задачей. Таблицы маршрутизации для отображения текущей сетевой топологии должны быть динамическими. Маршрутизатор обменивается с другими маршрутизаторами информацией о маршрутах. К протоколам маршрутизации, обменивающимися информацией о маршрутах в сетях IP, относятся: Routing Information Protocol (RIP), Open Shortest Path First Protocol (OSPF), Integrated Intermediate System to Intermediate System (ISIS), Exterior Gateway Protocol (EGP) и Border Gateway Protocol (BGP). Сегодня Internet значительно отличается от той сети, которая была создана в 1980 году. Internet стала мировой, общедоступной информационной сетью, которая удваивается в размерах каждые девять месяцев. Однако столь бурный рост Internet неизбежно привел к выявлению большого количества проблем, связанных с маршрутизацией. При этом: q       Производительность протоколов маршрутизации значительно снизилась; q       Размер сообщений, которыми обмениваются маршрутизаторы для поддержания своих таблиц маршрутизации растет, что требует все больших ресурсов маршрутизаторов и все большей пропускной способности сети; q       Большое число маршрутизаторов, работающих с протоколами маршрутизации, делают поддержку механизмов обнаружения и изоляции сбоев практически невозможной. Для того чтобы в какой-то степени снизить влияние этих факторов, сеть Internet разделили на отдельные автономные системы (Autonomous System). Автономная система (АС) представляет собою группу сетей и маршрутизаторов, управляемую уполномоченным. АС позволяет независимо управлять различными частями Internet и разрешает маршрутизаторам внутри различных АС использовать разные протоколы маршрутизации. Каждая сеть внутри АС должна быть доступна из Internet. Маршрутизаторы внутри одной АС взаимодействуют, используя динамические протоколы маршрутизации. Протоколы, управляющие маршрутной информацией внутри АС, относятся к классу так называемых протоколов IGP (Interior Gateway Protocol, внутренний шлюзовой протокол). Главной задачей протоколов класса IGP является поддержание необходимой производительности. Эти протоколы должны немедленно подстраиваться под изменения в сетевой топологии и находить маршрут с наименьшей стоимостью. Отдельные протоколы класса IGP это: RIP, NLSP, OSPF, IGRP, EIGRP и IS-IS. Взаимодействие между маршрутизаторами, принадлежащими к различным АС, требует дополнительного протокола, который называется EGP (Exterior Gateway Protocol, внешний шлюзовой протокол). Так как различные АС управляются совершенно независимо, в протоколе предприняты меры, предотвращающие влияние сбоев в других АС. Необходимо учитывать, что для связи с маршрутизаторами внутри АС корневой маршрутизатор (см. ниже), кроме поддержки EGP, должен также поддерживать протоколы класса IGP, так как всю информацию о своей АС протокол EGP получает через IGP.   9.2 Протокол RIP Протокол RIP (Routing Information Protocol) описан в документе RFC 1058. Протокол RIP относится к классу протоколов IGP. Этот протокол является одним из первых протоколов обмена маршрутной информацией между маршрутизаторами в IP-сети. Существует также версия этого протокола для сетей IPX/SPX компании Novell. Впервые протокол RIP появился в 1982 году как часть стека протокола TCP/IP для UNIX, разработанной Berkley Software Distribution. Исторически протокол RIP близко связан с семейством сетевых протоколов фирмы Xerox. Преимуществом протокола RIP является его простота. Недостатком — увеличение трафика за счет периодической рассылки широковещательных сообщений. Протокол RIP стал стандартным протоколом маршрутизации внутри отдельной автономной системы (АС), хотя он существенно ограничивает размер автономной системы. Это связано с тем, что протокол RIP не поддерживает длинные пути, которые содержат более 15 переходов. Протокол RIP использует алгоритм длины вектора (Distance vector algorithm). Этот алгоритм основывается на тех же принципах, что и алгоритм Беллмана-Форда, который был применен в первом протоколе маршрутизации для сетей ARPANET и исходит из предположения, что каждый маршрутизатор может вычислить самый короткий маршрут и соответствующее расстояние до каждой сети. То есть, каждый маршрутизатор выбирает ближайший соседний маршрутизатор, который расположен на этом самом коротком маршруте до получателя. Выбор осуществляется на основании информации о стоимости путей (выбирается путь с меньшей стоимостью). Стоимость вычисляется по информации, имеющейся в таблицах маршрутизации всех соседних маршрутизаторов (маршрутизаторы регулярно обмениваются между собой таблицами маршрутизации). Этот алгоритм хорошо работает в небольших сетях. В больших сетях он заполняет сеть широковещательным трафиком. Протокол не всегда точно и быстро учитывает изменения сетевой топологии, так как маршрутизаторы не имеют точного представления о топологии сети, а располагают только информацией, полученной от своих соседей. Протокол RIP использует в качестве метрики маршрута количество переходов, то есть число маршрутизаторов, которые должна миновать дейтаграмма, прежде чем она достигнет получателя. Маршрутизаторы с поддержкой протокола RIP всегда выбирают маршрут с наименьшим числом переходов. Таблица маршрутизации RIP содержит следующие поля: q       IP-адрес целевой сети; q       Количество переходов до целевой сети; q       Адрес первого маршрутизатора на пути к целевой сети; q       Идентификатор соседнего маршрутизатора, который является источником данной адресной информации в таблице маршрутизации; q       Таймер для отслеживания времени, прошедшего с момента последнего обновления записи. При включении маршрутизатора таблица маршрутизации заполняется описанием сетей, которые напрямую подключены к данному маршрутизатору. Затем соседние маршрутизаторы шлют ему свою информацию. Периодически каждый маршрутизатор посылает сообщения об обновлении маршрута всем своим соседям. Эти сообщения содержат информацию из таблицы маршрутизации. Если объем информации слишком велик и не помещается в одно сообщение протокола RIP, она будет разделена на части и помещена в несколько сообщений. Перед передачей сообщений об обновлении маршрута соседним маршрутизаторам маршрутизатор увеличивает количество переходов до получателя на единицу. Когда сообщения об обновлении маршрута приходят на маршрутизатор, он обновляет свою таблицу маршрутизации в соответствии со следующими правилами: q       Если новое количество переходов меньше, чем текущее (для конкретной записи), маршрутизатор примет новый маршрут. Эта новая запись будет храниться в таблице до тех пор, пока не появится маршрут с еще меньшей метрикой; q       Если передающий маршрутизатор является источником информации для существующей записи, то принявший сообщение маршрутизатор будет использовать новое значение количества переходов, даже если оно больше, чем старое.  Реакция протокола RIP на изменения в топологии сети зависит от того, как маршрутизатор информирует своих соседей о модификации его таблицы маршрутизации. Однако следует учитывать, что если сетевая топология изменяется, то соседи могут перестать быть соседями. Кроме того, если маршрутизатор выходит из строя, он не может известить своих соседей об изменениях в топологии. Таким образом, в случае отсутствия сообщений об обновлении маршрутизации предполагаемый маршрут может не отражать произошедшие изменения. Все маршрутизаторы, участвующие в обмене сообщениями об обновлении маршрута по протоколу RIP, посылают эти сообщения через определенный интервал, который по умолчанию составляет 30 с. Если маршрутизатор не получает сообщения от маршрутизатора, который отвечает за определенную запись в таблице маршрутизации за временной интервал, равный увеличенному в шесть раз интервалу обмена (по умолчанию 180 с), он предполагает, что либо его соседний маршрутизатор вышел из строя, либо между ними нарушилась связь. Затем маршрутизатор помечает отказавший маршрут как некорректный и, в конечном счете, удаляет его из своей таблицы маршрутизации. Когда маршрутизатор получит информацию о новом маршруте от другого своего соседа, он будет использоваться вместо старого удаленного маршрута. Шестикратное увеличение интервала необходимо для того, чтобы избежать исключения маршрута при случайной потере одного сообщения об обновлении. Кроме того, маршрутизатору чрезвычайно важно оповестить своих соседей о том, что не существует корректного маршрута к определенному получателю. Протокол RIP позволяет выполнить это с помощью стандартных сообщений об обновлении маршрутизации. Для обозначения недостижимости получателя количество переходов устанавливается равным 16. Это значение можно считать «бесконечностью», так как допустимые маршруты не могут иметь более 15 переходов. Если какая-либо сеть становится недостижимой, все соседние маршрутизаторы установят метрику для этой сети равной 16. В следующем цикле посылки сообщений об обновлении маршрутизаторы передадут эти данные всем своим соседям, указав для них число переходов к недостижимой сети равным 16. На рис. 9.1 показан пример сетевой топологии с вышедшим из строя каналом связи. Рис 9.1 Обрыв канала связи Протокол RIP гарантирует, что таблицы маршрутизации за определенное время (время сходимости) станут правильными. Однако алгоритм в текущем своем состоянии не гарантирует, что время сходимости будет мало. Может оказаться так, что до истечения времени сходимости в сеть будут внесены изменения, и тогда все начнется заново. Вопрос о том, сколько времени требуется для сходимости процесса извещения об изменении маршрутов, является достаточно сложным. Когда происходит выход из строя канала связи или возникают другие проблемы в сети, некоторые из существующих маршрутов становятся недоступными или менее подходящими для передачи. Проблема в том, что, в принципе, соседние маршрутизаторы могут обмениваться между собой не вполне правильной информацией. Эта информация будет передана дальше по сети. Она будет исправлена только при следующих итерациях. Медленная сходимость может иметь достаточно серьезные последствия. В частности, может увеличиться объем трафика сообщений об изменениях маршрутов, которыми обмениваются маршрутизаторы, могут образовываться логические петли маршрутизации и т. д. На рис. 9.2  показана логическая петля, образованная маршрутизаторами М2 и М3. Рис. 9.2.  Пример образования логической петли маршрутизации Маршрутизатор М2 может достигнуть целевой сети через маршрутизатор Ml за 1 переход. Маршрутизатор М3 получает эту информацию из периодических сообщений об обновлении от маршрутизатора М2. Поэтому МЗ может достигнуть целевую сеть через маршрутизатор М2 за 2 перехода. В следующем цикле посылки сообщений об обновлении маршрутизатор МЗ известит маршрутизатор М2 о достижимости целевой сети за 3 перехода. В результате маршрутизатор М2 будет иметь два маршрута в целевую сеть: первый маршрут с использованием маршрутизатора Ml и количеством переходов 1, а второй маршрут с использованием маршрутизатора МЗ и количеством переходов 3. Маршрутизатор М2 выберет маршрут через маршрутизатор Ml, так как он имеет наименьшую метрику. В случае, если канал связи между маршрутизаторами Ml и М2 выйдет из строя, М2 не получит сообщение об обновлении в требуемый интервал времени и удалит из своей таблицы запись о маршруте в целевую сеть через Ml. В результате у маршрутизатора М2 будет сформирована запись о маршруте в целевую сеть через маршрутизатор МЗ за 3 перехода. Следовательно, М2 будет пересылать весь трафик маршрутизатору МЗ, тот его пошлет обратно М2 и т. д. Таким образом образуется логическая петля маршрутизации. Обмен пакетами между маршрутизаторами будет продолжаться до тех пор, пока поле TTL в заголовке IP-дейтаграммы не станет равно 0. Тогда дейтаграмма будет удалена одним из маршрутизаторов. Существует несколько технологий, которые ускоряют сходимость протокола RIP IP и повышают его производительность. К ним относятся: - расщепление горизонта (Split-Horizon), - обратное исправление (Poison Reverse), - мгновенное изменение (Triggered Update) - временный отказ от приема информации Hold-Down (приостановка) - Garbage-Collection (сборка мусора). Описанная проблема «обоюдного обмана» может быть решена путем определения направления посылки маршрутной информации. Согласно технологии Split-Horizon маршрутизатор не будет распространять информацию об определенном маршруте через порт, который явился источником данной информации. Другими словами, маршрутизатор не будет информировать о достижимости получателя своего соседа, от которого была получена информация о маршруте к получателю. На рис. 9.3 показано, каким образом Split-Horizon устранит образовавшуюся петлю. Рис. 9.3 Результат работы технологии Split-Horizon Процедура обмена сообщениями об обновлении маршрута остается такой же, как и выше, за исключением того, что маршрутизатор М3 не будет посылать информацию о маршруте к целевой сети маршрутизатору М2. В результате маршрутизатор М2 имеет только один маршрут в целевую сеть, и, если произойдет обрыв канала связи между маршрутизаторами Ml и М2, он удалит из своей таблицы маршрутизации маршрут в целевую сеть, и петля не возникнет. Технология Poison Reverse решает те же задачи, что и Split-Horizon, однако немного другим способом. Маршрутизаторы распространяют информацию о маршрутах через порты, которые явились источниками информации. Но эти маршруты указываются как недостижимые — количество переходов устанавливается равным 16 (рис. 9.4 ). Рис. 9.4 Результат работы технологии Poison Reverse По сути, сообщения о маршрутах с числом переходов, равным 16, — это то же самое, что отсутствие сообщений (не считая увеличения нагрузки на сеть). Однако при изменении сетевой топологии скорость сходимости в этой схеме может увеличиться, так как упоминаются и достижимые, и недостижимые маршруты. Основным недостатком этой технологии является то, что она увеличивает нагрузку на сеть. Во многих случаях администратор может согласиться с медленной сходимостью ради уменьшения загрузки сети, вызываемой потоком сообщений об обновлении. Технологии Split-Horizon и Poison Reverse хорошо работают в случае двух маршрутизаторов в петле. Однако возможны ситуации, когда три или более маршрутизаторов «обманывают друг друга». Например, маршрутизатор Ml полагает, что имеет маршрут к какой-либо сети через маршрутизатор М2, маршрутизатор М2 — через МЗ, МЗ — через М4, а М4 — снова через Ml. Для ускорения сходимости в подобных ситуациях служит технология Triggered Update, которая требует, чтобы маршрутизатор немедленно посылал сообщения об обновлении своим соседям, если он обнаружил изменение в метрике маршрута. Сообщение должно быть послано, даже если не пришло время для регулярных сообщений. Естественно, это ускорит сходимость, но увеличит трафик в сети. Поэтому технология Triggered Update может вызвать чрезмерную загрузку сети с ограниченной пропускной способностью. Все реализации протокола RIP должны предусматривать предел частоты немедленной посылки сообщений об обнов­лении (скажем, не чаще чем раз в секунду), чтобы не загружать сеть. Простым решением данной проблемы является установка таймера на случайное число между одной и пятью секундами. После обнуления таймера происходит посылка сообщения об обновлении. Если произошли другие изменения в сети, при которых немедленно высылаются дополнительные сообщения, маршрутизатор должен выждать обнуление таймера и только затем посылать новое сообщение. Таймер после этого устанавливается в другое случайное число в заданном интервале. Например, маршрутизатор М будет устанавливать тайм-аут для своего маршрута в целевую сеть. Это заставит его, после обнуления таймера, сформировать сообщения об обновлении и посылать их через свои порты. Сообщения будут распространяться через все пути, обновляя метрику для целевой сети до бесконечности. Такой каскад сообщений об обновлении останавливается только тогда, когда он достигает маршрутизатора, который использует путь до целевой сети, не проходящий через маршрутизатор М. Маршруты в таблице маршрутизации, создаваемой с помощью протокола RIP, могут иметь различные состояния. Например, для маршрутизаторов фирмы 3Com маршруты могут находиться в одном из следующих состояний: q       UP — маршрут достижим с определенной метрикой, меньшей 16. Маршрут остается в данном состоянии в течение шестикратного интервала времени между посылками сообщений об обновлении — это время называется таймером маршрута. Данный таймер сбрасывается каждый раз, когда поступает новое сообщение об обновлении этого маршрута. По обнулении таймера маршрут считается недействительным и переводится в состояние Garbage- Collection; q       Hold-Down — маршрут имеет метрику, равную бесконечности (больше или равно 16). Маршрут будет оставаться в данной стадии в течение времени, равного четырехкратному интервалу между посылками сообщений об обновлении. В этом состоянии с маршрутом связывают таймер Hold-Down. Когда таймер Hold-Down обнулится, маршрутизатор перейдет в состояние Garbage-Collection. Если до обнуления таймера для этого маршрута будет получено сообщение с метрикой меньше 16, маршрут перейдет в стадию UP. Цель состояния Hold-Down — оповестить все маршрутизаторы в автономной системе о том, что маршрут не функционирует. Таймер препятствует маршрутизатору в этом состоянии принимать сообщения, содержимое которых устарело; q       Garbage-Collection — маршрут с обнуленным таймером, который до этого был в стадии UP. Маршрут может оставаться в этом состоянии на протяжении четырехкратного интервала времени между посылками об обновлении. Это время отсчитывает таймер Garbage-Collection. Если до обнуления таймера Garbage-Collection для этого маршрута не будет получено сообщений об обновлении, маршрут удаляется из таблицы маршрутизации. Если до обнуления таймера соседний маршрутизатор информирует об изменении этого маршрута с метрикой меньше 16, маршрут будет изменен, а его удаление отменено. Таймер будет сброшен, а маршрут перейдет в состояние UP. На рис. 9.5 показана смена состояний маршрута в таблице маршрутизации. Рис. 9.5 Алгоритм смены состояний маршрута Сетевому администратору в автономной системе требуется контроль за использованием ресурсов сети. В частности, желательно ограничить поток сообщений о маршрутизации. Существует набор средств, которые позволяют администратору контролировать содержимое сообщений об обновлении маршрута. Перечислим их на примере маршрутизатора NetBuilder II фирмы 3Com. В частности: q       Для уменьшения размера сообщений об обновлении маршрутизатор может не включать информацию о локальных сетях, к которым подключен он или его соседи; q       Если маршрутизатор поддерживает технологию Split-Horizon, он не будет оповещать о маршрутах, через которые была получена соответствующая информация; q       Устанавливая параметр Poison/No Poison, маршруты можно указывать как недостижимые или просто не включать их в сообщения; q       Задав сетевые правила (Network Policy), можно четко очертить список сетей, о которых оповещает протокол RIP. По умолчанию протокол должен сообщать обо всех сетях; q       Внутренние правила (Interior Policy) могут указывать на появление сообщений протокола RIP, информирующих о маршрутах, за которые отвечали другие протоколы класса IGP (например, OSPF или IS-IS); q       Внешние правила (Exterior Policy) служат для управления списком сетей, оповещаемых протоколом RIP, который получен от протоколов политики маршрутизации, таких как EGP или BGP. По умолчанию информация о таких маршрутах не должна рассылаться; q       Настраиваемые статические правила (Static Policy) служат для определения того, будут ли рассылаемые сообщения об обновлении включать информацию о статических маршрутах. Следует отметить, что все маршруты, определяемые сообщениями протокола RIP IP, будут рассматриваться как «собственность» этого протокола; q       Настраиваемые метрики по умолчанию (Default Metric) помогают отслеживать сообщения RIP о маршруте по умолчанию. Сетевой администратор может выбрать метрику, которая будет использоваться с маршрутом по умолчанию; q       Правила получения (Receive Policy) служат для фильтрации сообщений от соседних маршрутизаторов. Это позволяет администратору принимать не всю информацию, получаемую от соседей и предназначенную для обновления таблицы маршрутизации. Протокол RIP для передачи сообщений использует дейтаграммы UDP и про­токольный порт 520. Полное сообщение протокола RIP, включая заголовок и данные, инкапсулируется в поле данных дейтаграммы UDP, которая, в свою очередь, инкапсулируется в IP-дейтаграмму (рис. 9.6 ).   Рис 9.6  Инкапсуляция сообщений протокола RIP Все сообщения протокола RIP состоят из заголовка фиксированной длины и следующей за ним таблицы маршрутизации (точнее, ее подмножества) передающего маршрутизатора. В таблице представлен список достижимых сетей (рис. 9.7 ). Цифра 0 на рис. 9.7  означает, что это поле, согласно спецификации, должно быть нулевым. Команда (8 бит)   Версия (8 бит)     0(16 бит)   Идентификатор адресной схемы (16 бит)       0(16 бит)   IP-адрес (32 бита)   0(32 бита)   0(32 бита)   Количество переходов (32 бита)   Идентификатор адресной схемы (16 бит)        0(16 бит)   IP-адрес (32 бита)   0(32 бита)   0(32 бита)   Количество переходов (32 бита)   ...   Идентификатор адресной схемы (16 бит)       0(16 бит)   IP-адрес (32 бита)   0(32 бита)   0(32 бита)   Количество переходов (32 бита)     Рис. 9.7 . Формат сообщения протокола RIP Часть сообщения (запись из таблицы маршрутизации), начинающаяся с поля «Идентификатор адресной схемы» и заканчивающаяся полем «Количество переходов», может повторяться в сообщении до 25 раз. Это позволяет каждому сообщению протокола RIP переносить до 25 адресов, которые занимают до 500 байтов. Это ограничение вызвано тем, что максимальный размер сообщений составляет 521 байт, не включая заголовков протоколов IP и UDP. Маршрутизатору может потребоваться передать несколько сообщений для рассылки всей таблицы маршрутизации своим соседям. Не существует специальных требований к последовательности посылки сообщений, так как все маршруты обрабатываются независимо. Поля в сообщении протокола RIP имеют следующие значения: q       Поле «Команда» указывает назначение дейтаграммы. Команда может быть либо запросом протокола RIP (1), либо ответом (2). Существуют и другие команды, однако в настоящее время они не используются; q       Поле «Версия» — версия протокола RIP; q       Поле «Идентификатор адресной схемы» указывает тип адреса для каждой записи. Сообщения RIP могут переносить адреса любого формата различных протоколов. Идентификатор IP-адреса равен 2; q       Поле «IP-адрес» занимает четыре байта. В нем могут указываться адрес устройства, номер сети, номер подсети или ноль, что означает маршрут по умолчанию;        q       Поле «Количество переходов» указывает текущую метрику для данного сетевого адреса.  Поля, которые должны быть заполнены нулями, являются частью адресного поля, но не используются, так как адреса IP занимают только 4 байта. Протокол RIP может работать с сетевыми адресами длиной до 12 байт. Выше рассматривался протокол маршрутизации RIP версии 1 (RIP-1 IP). Однако существует версия 2 этого популярного протокола (RIP-2 IP), описанная в документе RFC 1388. Версия 2 поддерживает CIDR, аутентификацию, подсети и групповую передачу. На рис. 9.8 показан формат сообщений протокола RIP-2. Команда (8 бит) Версия (8 бит) Домен маршрутизации (16 бит) Идентификатор адресной схемы (16 бит) Метка маршрута (16 бит) IP-адрес (32 бита) Маска подсети (32 бита) Следующий переход (32 бита) Метрика (32 бита) Рис. 9.8 . Формат сообщения протокола RIP-2 IP Сообщения версии 1 содержат нулевые неиспользуемые поля. Это позволяет задействовать их для расширений, предлагаемых в версии 2. Протокол RIP-2 IP наследует все поля первой версии и добавляет следующие: q       Поле «Домен маршрутизации» используется вместе с полем «Следующий переход» для совместной работы нескольких АС в едином домене маршрутизации; q       Поле «Маска подсети» — двоичное число, содержащее единицы в тех разрядах, которые относятся к расширенному сетевому префиксу. Маска подсети делит IP-адрес на номер подсети и номер устройства в этой подсети и позволяет выполнять маршрутизацию в сформированной структуре подсетей; q       Поле «Метка маршрута» служит для идентификации внешних маршрутов и задействуется в протоколах политики маршрутизации (EGP или BGP). Номер версии для протокола RIP-2 IP равен 2. При получении такого сообщения маршрутизатором, поддерживающим протокол RIP-1 IP, он просто проигнорирует любые поля, которые согласно версии 1 протокола должны содержать нули. Поэтому он будет корректно обрабатывать все записи, не использующие расширений RIP-2 IP (например, простое поле с IP-адресом по­лучателя без указания маски подсети). Протокол RIP-1 IP не поддерживает безопасность. Любое устройство (рабочая станция или сервер), посылающее сообщение UDP через порт 520, будет рассматриваться маршрутизатором как его сосед. Отсутствие аутентификации возлагает на администратора дополнительные задачи по управлению правилами. Например, администратору может понадобиться вручную настроить список авторизованных соседей. Протокол RIP-2 IP поддерживает аутентификацию. Стандарт допускает замену первой записи в сообщении на сегмент аутентификации. Таким образом, сообщение может содержать сегмент аутентификации и 24 записи из таблицы маршрутизации в стандартной форме RIP-2 IP. На рис. 9.9 показан формат сегмента аутентификации протокола RIP-2 IP. %FFFFF Тип аудентификации (16 бит) Аудентификация (16 бит) Рис. 9.9 Формат сегмента ауденитфикации RIP -2 IP Сегмент аутентификации определяется тем, что поле «Идентификатор адресной схемы» равно %FFFFF. Затем указывается тип схемы аутентификации, и следующие 16 байт отводятся под данные аутентификации. После получения сообщения маршрутизаторы проверят сегмент аутентификации (если протокол RIP-2 IP работает в безопасном режиме) и будут игнорировать любые сообщения с некорректной аутентификацией. Так как протокол RIP был разработан достаточно давно и практически не изменялся за это время, он обладает существенными недостатками, которые ограничивают его применение в сложных сетях: q       RIP допускает 15 переходов между отправителем и получателем. Если количество переходов превышает 15, получатель рассматривается как недостижимый, что очень сильно ограничивает размеры автономной системы. q       Использование в качестве метрики маршрута количества переходов приводит к тому, что протокол RIP не всегда выбирает самый эффективный и экономный маршрут. Например, может оказаться так, что выбранный маршрут содержит медленный и дорогой канал связи. Протоколы маршрутизации, которые используют в качестве метрики количество переходов, не принимают во внимание такие важные характеристики, как скорость канала, его надежность и т. д. q       Механизм обмена сообщениями RIP основан на широковещательной рассылке всей таблицы маршрутизации. В средних и больших сетях это может сильно загрузить каналы связи, особенно если распределенная сеть состоит из удаленных сетей, соединяемых по коммутируемым каналам связи. q       Так как протокол RIP работает по алгоритму вектора расстояния, он обладает медленной сходимостью. В случае, если канал связи выйдет из строя, потребуется несколько минут для того, чтобы маршрутизаторы скорректировали свои таблицы. В течение этого времени могут образоваться петли маршрутизации. 10. ПРОТОКОЛ OSPF Спецификация протокола OSPF (Open Shortest Path First) описана в документе RFC 1247. Протокол принят в 1991 году. Он ориентирован на применение в больших распределенных сетях. OSPF вычисляет маршруты в сетях IP, работая совместно с другими протоколами обмена маршрутной информацией. Протокол OSPF основан на алгоритме состояния канала. Суть этого алгоритма состоит в том, что он должен вычислить кратчайший путь. При этом «кратчайший» не означает, что путь физически самый короткий. Имеется в виду, что информация пройдет по этому пути быстрее, чем по другим. Маршрутизатор, работающий с этим протоколом, отправляет запросы всем соседним маршрутизаторам, находящимся в одном с ним домене маршрутизации, для выявления состояния каналов до них и далее от них. Состояние канала при этом характеризуется несколькими параметрами, которые называются метриками. Метрикой может быть пропускная способность канала, его загрузка на текущий момент, задержка информации при ее прохождении по этому каналу и т. д. Обобщив полученные сведения, этот маршрутизатор сообщает их всем соседям. После этого им строится ориентированный граф, который повторяет топологию домена маршрутизации. Каждому ребру этого графа назначается оценочный параметр (метрика). После построения графа используется алгоритм Дейкстры, который по двум заданным узлам находит набор ребер с наименьшей суммарной стоимостью, то есть, по сути, выбирает оптимальный маршрут. По совокупной информации (полученной и найденной в результате вычислений) создается таблица маршрутизации. Сообщения протокола OSPF передаются в IP-дейтаграммах с полем «Протокол» равным 89. Протокол OSPF отвечает за IP-маршрутизацию и относится к классу протоколов IGP. Он может заменить протокол маршрутизации RIP в больших и сложных сетях. Протокол OSPF решает многие из перечисленных выше проблем, присущих протоколу RIP. Кроме того: q       Протокол OSPF обладает большей скоростью сходимости, что предотвращает возникновение петель маршрутизации; q       При работе протокола не генерируется большой сетевой трафик; q       Информация, которой обмениваются маршрутизаторы, проходит процедуру аутентификации. Это позволяет участвовать в процессе маршрутизации только авторизованным маршрутизаторам. Аутентификация устраняет возможность случайного или преднамеренного искажения маршрутной информации; q       Протокол OSPF использует групповую передачу вместо широковещательной. Такой подход позволяет исключить передачу маршрутной информации тем устройствам, которым она не нужна; q       Протокол поддерживает распределение нагрузки (load balancing) по мар­шрутам, имеющим одинаковые стоимости; q       Протокол поддерживает маски подсетей переменной длины (VLSM). Данные о масках подсетей передаются в сообщениях LSA (Link-State Advertisement,- объявление о состоянии канала), таким образом маршрутизаторы получают эту информацию динамически, что позволяет более гибко использовать выделенное организации адресное пространство; q       Протокол поддерживает области маршрутизации. Это позволяет администраторам разделять автономную систему на отдельные части с изоляцией сетевого трафика и маршрутизации; q       Протокол OSPF поддерживает передачу внешней маршрутной информации через автономные системы. Протокол OSPF хорошо подходит для современных, больших, динамически изменяющихся сетей. Например, в отличие от протокола RIP, который по умолчанию рассылает всю свою таблицу маршрутизации каждые 30 с, протокол OSPF посылает информацию о состоянии каналов каждые 30 мин. При обнаружении изменения сетевой топологии протокол OSPF сразу же посылает небольшие (порядка 75 байт) сообщения. В начале работы каждый маршрутизатор передает сообщения LSA на все свои порты. Эти сообщения позволяют однозначно идентифицировать передающий маршрутизатор и определить состояние всех его портов: IP-адрес, маску подсети, метрику, присвоенную каналу связи порта, и статус канала связи. Сообщение LSA передается во всем домене маршрутизации. Поэтому маршрутизаторы обладают информацией о состоянии каналов других маршрутизаторов в домене. Каждый маршрутизатор на основе сообщений LSA формирует базу данных состояния каналов (Link-State Database). Эта база данных одна и та же на всех маршрутизаторах в одном домене. Алгоритм маршрутизации поддерживает синхронизацию этих баз данных. После того как все базы данных синхронизированы, каждый маршрутизатор начинает создавать свою таблицу маршрутизации. Эта таблица базируется на информации, содержащейся в базе данных состояния каналов. Сначала создается карта сетевой топологии. Непосредственно связанные маршрутизаторы по терминологии протокола OSPF называются соседями. Каждый маршрутизатор хранит информацию о том, в каком состоянии, по его мнению, находится сосед. Маршрутизатор полагается на соседние маршрутизаторы и передает им дейтаграммы только в том случае, если он уверен, что они полностью работоспособны. После создания карты сетевой топологии маршрутизатор формирует дерево кратчайших путей ко всем возможным получателям. Рис. 10.1 Множество сетей Это дерево строится таким образом, чтобы путь от корня — маршрутизатора, формирующего дерево, — до конечных объектов — целевых сетей — имел наименьшую стоимость. На рис.10.1 показано множество сетей, для которого формируется дерево кратчайших путей, изображенное на рис. 10.2  . Мы считаем, что метрики пути до каждой из сетей равны 10.   Рис. 10.2 Дерево кратчайших путей После того как дерево построено, маршрутизаторы формируют локальные таблицы маршрутизации. Дерево путей показывает, что маршрутизатор Ml напрямую подключен к сетям #2 и #3. В таблицу маршрутизации для сетей, подключенных напрямую, в качестве значения метрики заносится 0. В табл.10.1 показаны данные таблицы маршрутизации для маршрутизатора Ml. Таблица10.1. Таблица маршрутизации маршрутизатора М1 Сеть   Следующий маршрутизатор в сети   Метрика маршрута   Сеть #1 Маршрутизатор М5 20 Сеть #2 Подключена напрямую Сеть #З Подключена напрямую Сеть #4 Маршрутизатор М2 20 Сеть #5 Маршрутизатор М4 20 Так как маршрут в сеть #4 состоит из двух путей (от маршрутизатора Ml к М2, а затем от М2 к сети #4), а метрика каждого пути равна 10, то метрика маршрута до сети #4 равна 20. Аналогично вычисляются метрики остальных маршрутов. Следует отметить, что к сети #5 от маршрутизатора Ml имеются два пути — через маршрутизаторы М4 и М2. Путь через маршрутизатор М4 имеет метрику 20, а путь через маршрутизатор М2 — 30. Алгоритм состояния канала будет всегда выбирать кратчайший маршрут в целевую сеть. В результате в таблицу маршрутизации в качестве следующего маршрутизатора в пути будет включен маршрутизатор М4. Если маршрутизатор обнаружит изменения в состоянии одного из подключенных к нему каналов, он должен разослать сообщения LSA всем своим соседям, которые ретранслируют их далее по всему домену маршрутизации. С момента посылки сообщения базы данных маршрутизаторов теряют синхронизацию и, следовательно, должны быть синхронизованы вновь. После выполнения синхронизации каждый маршрутизатор должен заново построить карту сетевой топологии, дерево кратчайших путей и таблицу маршрутизации. Хотя протокол OSPF решает все проблемы, присущие RIP, он тоже далек от идеала. В очень больших сетях протокол OSPF порождает чрезвычайно много маршрутной информации. Например, в распределенной сети с сотнями маршрутизаторов изменение состояния одного канала (скажем, обрыв линии связи) вызывает распространение тысяч сообщений LSA через всю сеть. База данных состояния канала в таких сетях может достигать нескольких мегабайт. В то же время, при изменениях в сетевой топологии все маршрутизаторы должны заново сформировать таблицу маршрутизации. Поэтому в очень больших сетях время сходимости может значительно возрасти (хотя медленная сходимость неизбежна в больших распределенных сетях при любом протоколе маршрутизации). Кроме того, значительный объем вычислений предъявляет серьезные требования к аппаратным ресурсам маршрутизатора (скорости обработки и объему памяти). Частично протокол OSPF решает эти проблемы, вводя понятие области маршрутизации, иначе называемые областями OSPF. Тем самым большая сеть как бы разбивается на несколько областей с независимой маршрутизацией. Такой областью может быть сеть в одном здании, корпусе и т. д. В сети может существовать практически неограниченное число областей маршрутизации. Маршрутизаторы внутри одной области OSPF не обмениваются информацией с маршрутизаторами другой области. Это уменьшает объем служебного трафика между маршрутизаторами и сокращает размер баз данных маршрутизаторов. Например, в большой распределенной сети, состоящей из 500 маршрутизаторов, создание. 10 областей, в каждой из которых работает 50 маршрутизаторов, означает, что каждому маршрутизатору необходимо поддерживать информацию о состоянии каналов только для 50 маршрутизаторов, а не для 500. Области OSPF связываются друг с другом с помощью специально выделенных маршрутизаторов, которые должны содержать базу данных с информацией об обеих областях. Эти маршрутизаторы называются граничными маршрутизаторами областей (Area Border Routers). Они работают как фильтры для сообщений маршрутизации, не выпуская их из области. Граничные маршрутизаторы взаимодействуют между собой, используя специальные сообщения LSA, которые содержат краткую информацию об IP-адресах, содержащихся в области. Граничные маршрутизаторы сохраняют эти сообщения в специальной базе данных, которая используется для определения маршрута между областями (такой способ взаимодействия называется inter-аrеа). Граничные маршрутизаторы должны быть достаточно мощными. В протоколе OSPF введено понятие автономных систем маршрутизации, которые представляют собой домены маршрутизации, находящиеся под общим административным управлением и использующие единый протокол маршрутизации. Маршрутизатор, соединяющий две автономные системы, одна из которых использует протокол маршрутизации, отличный от OSPF, называется пограничным маршрутизатором автономной системы — ASBR (Autonomous System Boundary Router). Внешние маршруты обрабатываются в два этапа. Сначала маршрутизатор выбирает оптимальный внешний маршрут. Если таких маршрутов несколько (то есть метрики этих маршрутов примерно одинаковы), то выбирается маршрут, который имеет наименьшую стоимость внутреннего пути до ASBR. Протокол OSPF поддерживает настраиваемые метрики, предоставляя администратору возможность присваивать метрику маршрута, основываясь на различных характеристиках, таких как стоимость передачи, надежность, задержка или количество переходов. Число, используемое в качестве метрики пути, может быть задано произвольным образом. По умолчанию в качестве метрики используется время передачи бита, измеряемое в десятках наносекунд. Так линии Ethernet назначается значение 10, а линии со скоростью 56 Кбит/с — 1785. Вычисляемая протоколом OSPF метрика маршрута представляет собой сумму метрик по всему маршруту.   Рис. 10.3 Топология с настраиваемыми метками Рассмотрим пример (рис. 10.3). Предположим, что станции А необходимо передать данные станции Б и администратор вручную настроил метрики для протокола OSPF. Протокол RIP не учитывает при выборе маршрута скорость каналов связи. Поэтому при использовании протокола RIP данные будут передаваться через низкоскоростной (56 Кбит/с) канал связи, так как он имеет наименьшее количество переходов. В отличие от протокола RIP протокол OSPF принимает во внимание скорость канала связи (если она выбрана в качестве метрики). Поэтому будут задействованы именно высокоскоростные каналы, так как их суммарная стоимость составит 20. Протокол OSPF способен работать в сетях следующих типов: q       Сети точка-точка. Используются для связи двух маршрутизаторов. Обычно, для организации такой связи используются коммутируемые или выделенные каналы связи; q       Широковещательные сети. Примером может служить Ethernet. В этой сети с помощью широковещательной адресации можно передавать информацию одновременно всем маршрутизаторам. q       Нешироковещательные сети (NBMA, Non-Broadcast Multiple Access Networks, нешироковещательные сети со множественным доступом). Примером таких сетей могут служить Х.25, Frame Relay или ATM. При включении маршрутизатору необходимо синхронизовать свою базу данных со всеми маршрутизаторами локальной сети. Так как база данных на всех маршрутизаторах одинакова, достаточно провести синхронизацию с одним из них. Этот маршрутизатор называется назначенным маршрутизатором — Designated Router (DR). Его «заместитель» называется резервным назначенным маршрутизатором — Backup Designated Router (BDR). При этом DR и BDR будут единственными маршрутизаторами, с которыми новый маршрутизатор должен синхронизировать свою базу. После синхронизации базы с назначенным маршрутизатором, новый маршрутизатор будет синхронизован со всеми маршрутизаторами данной сети. Кроме того, назначенный маршрутизатор делает объявления о сетевых связях, перечисляя своих соседей по подсети. Остальные маршрутизаторы просто объявляют о своей связи с назначенным маршрутизатором. BDR занимает место DR в тех случаях, когда последний выходит из строя. Достоинство этого метода в том, что после назначения DR значительно уменьшается количество маршрутной информации, передаваемой по сети. Протокол OSPF состоит из трех внутренних протоколов: Hello, Exchange и Flooding. Протокол Hello использует сообщения Hello. Периодически маршрутизаторы обмениваются между собой этими сообщениями. Сообщение Hello посылается через все порты маршрутизатора и содержит следующую информацию: q       приоритет маршрутизатора, который используется для выбора DR и BDR; q       интервал между сообщениями Hello в секундах; q       интервал ожидания сообщения; q       список маршрутизаторов, от которых недавно были получены сообщения Hello; q       маршрутизаторы, которые в настоящий момент являются DR и BDR. Наиболее важны интервал между сообщениями Hello и интервал ожидания сообщения. В сообщениях Hello маршрутизатор передает некоторые сведения о себе и говорит о том, кого он рассматривает в качестве своих ближайших соседей. Маршрутизаторы с разными рабочими параметрами игнорируют сообщения Hello друг от друга, поэтому маршрутизаторы с некорректно настроенными параметрами не влияют на остальные. Маршрутизаторы посылают сообщения Hello всем своим соседям, по крайней мере, один раз на протяжении интервала времени Hello. Если интервал ожидания сообщения истек, а сообщение Hello от соседа не пришло, то считается, что сосед неработоспособен, и рассылается объявление о сетевых каналах, для того чтобы в сети произошел пересчет маршрутов. На рис. 10.4  показан формат сообщения Hello. Общий заголовок OSPF (поле «Тип» равно) Маска подсети (32 бита) Интервал Hello (32 бита) Опции (8 бит) Приоритет (8 бит) Интервал Dead (32 бита) DR  32 бита) BDR  (32 бита) Сосед  (32 бита) Сосед (32 бита) Рис. 10.4  Формат сообщения Hello   Поле «Маска подсети» указывает маску подсети порта, через который посылается сообщение. Это поле устанавливается в шестнадцатеричное значение %FF000000 для сетей класса A, %FFFF0000 для сетей класса В и %FFFFFF00 для сетей класса С. Значения «Интервал Hello» и «Интервал Dead» устанавливаются администратором. Поле «Приоритет» используется при выборе DR и BDR. Каждому маршрутизатору назначается приоритет в пределах от 0 до 255. Выбирается маршрутизатор, имеющий наибольший приоритет. Если маршрутизатор с наибольшим приоритетом выходит из строя или просто отключен, выбирается другой маршрутизатор с наибольшим приоритетом. Он будет оставаться маршрутизатором DR, даже если старый DR вновь будет функционировать. Но маршрутизаторы, у которых приоритет равен нулю, никогда не будут избраны DR. В сетях точка-точка выбор DR не производится. Начальная синхронизация баз данных нового маршрутизатора и DR выполняется с помощью протокола Exchange. Работу данного протокола можно разделить на два этапа. На первом этапе определяются роли двух маршрутизаторов: один становится доминирующим, другой — доминантным. После этого на втором этапе происходит взаимный обмен базами данных с помощью пакетов DDP (Database Description Packet, пакет описания базы данных). После начальной синхронизации с помощью протокола Exchange ответственность за поддержку синхронизации баз данных состояния каналов связи всех маршрутизаторов несет протокол Flooding. В широковещательных сетях и сетях точка-точка сообщения Hello посылаются соседям с использованием групповой IP-адресации. В этом случае соседние маршрутизаторы обнаруживаются динамически. В сети, в которой широковещательная передача не поддерживается, сообщения Hello посылаются по списку адресов маршрутизаторов в сети. Данный список ведется на каждом маршрутизаторе, который может (потенциально) стать DR. Для распространения по сети данных о состоянии каналов связи маршрутизаторы обмениваются специальными сообщениями LSA, называемыми Network Links Advertisement (объявления о каналах сети, NLA), — объявлениями о каналах и их состоянии. Маршрутизаторы обмениваются не только своими, но и чужими объявлениями о каналах, получая, в конце концов, информацию о состоянии всех каналов в сети. По этой информации строится ориентированный граф связей сети (он один и тот же для маршрутизаторов). Кроме информации о соседях маршрутизаторы в своих объявлениях перечисляют IP-подсети, с которыми они связаны непосредственно. Маршрутизатор вычисляет путь не до подсети, а до маршрутизатора, к которому эта подсеть подключена. Каждый маршрутизатор имеет уникальный идентификатор, который передается в объявлении о состоянии каналов. Для обмена маршрутной информацией протокол OSPF использует групповую адресацию. В этих целях зарезервированы два IP-адреса класса D: q       224.0.0.5 — все маршрутизаторы, работающие по протоколу OSPF, должны поддерживать передачу и получение дейтаграмм по этому групповому адресу; q       224.0.0.6 — все DR и BDR должны поддерживать получение дейтаграмм с данным групповым адресом. В соответствии с уже рассмотренными правилами преобразования групповых адресов протокола IP в физические адреса канального уровня используемые групповые адреса преобразуются в следующие физические адреса (табл. 10.2). Таблица 10.2. Соответствие между групповыми и физическими адресами протокола OSPF Адрес класса D   Физический адрес   224.0.0.5   %01-00-5Е-00-00-05   224.0.0.6   %01-00-5Е-00-00-06   Необходимо отметить, что протокол OSPF не использует групповую передачу в сетях NBMA. Все сообщения протокола OSPF начинаются со стандартного заголовка (рис.10.5). Версия (8 бит) Тип (8 бит) Длина сообщения (16 бит) Идентификатор маршрутизатора (32 бита) Идентификатор области (32 бита) Контрольная сумма (16 бит) Идентификатор алгоритма аутентификации (16 бит) Аутентификация (32 бита) Аутентификация (продолжение предыдущего поля — 32 бита) Рис. 10.5  . Формат заголовка сообщений OSPF Поля в заголовке имеют следующие значения: q       «Версия» указывает на версию протокола OSPF. Текущая версия — 2; q       «Тип» указывает на тип сообщения протокола OSPF; q       «Длина сообщения» — длина сообщения в байтах; q       «Идентификатор маршрутизатора» — это может быть IP-адрес, выбранный для идентификации маршрутизатора; q       «Идентификатор области» используется для указания области. Общей практикой является выбор IP-адресов в качестве идентификаторов; q       «Контрольная сумма» вычисляется для всего сообщения, исключая 8- байтовое поле «Аутентификация»; q       «Идентификатор алгоритма аутентификации» может принимать только два значения: 0 — аутентификация не используется, 1 — простая аутентификация. При простой аутентификации поле «Аутентификация» содержит пароль, состоящий из восьми символов. Администратор может задать различные пароли для каждой сети. Это является хорошей гарантией защиты от случайных ошибок, например, от некорректной настройки маршрутизатора. Однако это не очень надежный метод защиты от намеренного вмешательства. Практика показывает, что не существует сетей, в которых используется ис­ключительно протокол OSPF. Совместно с ним применяются протоколы EGP, BGP, RIP IP или фирменные протоколы производителей.   11. ЗАГОЛОВОК И ПРОТОКОЛ UDP 11.1 Протокол UDP Протокол пользовательских дейтаграмм (User Datagram Protocol, UDP) описан в документе RFC 768. Протокол разработан для предоставления прикладным программам транспортных услуг. UDP, так же, как и IP, обеспечивает негарантированную доставку дейтаграмм получателю и не поддерживает установку соединений. В модели стека TCP/IP он располагается над протоколом IP. Взаимодействие между прикладными программами и протоколом UDP осуществляется через так называемые протокольные порты. Протокольные порты определяют соответствие между абстрактными точками доступа к протоколу UDP и конкретными прикладными программами. Механизм протокольных портов позволяет рабочей станции одновременно поддерживать несколько сеансов связи с удаленными компьютерами и программами в сети. Можно также сказать, что протокольный порт служит для указания программы-получателя информации. Когда рабочая станция получает дейтаграмму с ее IP-адресом, она направляет эту дейтаграмму конкретной программе, используя номер протокольного порта, который определяется во время установки сеанса связи. Следует отметить, что протокольные порты протокола UDP отличаются от протокольных портов протокола TCP. Назначение портов происходит при участии сетевой операционной системы. Большинство операционных систем обеспечивают параллельный доступ к протокольным портам. Протокольный порт идентифицируется целым положительным числом. Для связи с протокольным портом на другой рабочей станции, отправитель должен знать IP-адрес получателя и номер порта на этой рабочей станции. Каждое сообщение содержит также номер протокольного порта отправляющей рабочей станции. Таким образом, прикладная программа, получающая сообщения, может напрямую ответить отправителю.  В стеке протоколов TCP/IP протокол UDP обеспечивает транспортный механизм, используемый прикладными программами для передачи дейтаграмм другим приложениям. Протокол UDP предоставляет протокольные порты, используемые для раздельной работы нескольких приложений, выполняющихся на одной рабочей станции. При этом приложения, использующие транспорт протокола UDP, должны сами обеспечивать надежность передачи сообщений. Каждое сообщение протокола UDP называется пользовательской дейтаграммой. Она состоит из двух частей: заголовка и области данных. Заголовок содержит четыре 16-битных поля, которые определяют протокольный порт отправителя, протокольный порт получателя, длину сообщения и контрольную сумму (рис. 11.1). Рис. 11.1 Формат пользовательской дейтаграммы протокола UDP Поля «Порт отправителя» и «Порт получателя» содержат 16-битные номера портов. Поле «Порт отправителя» может не использоваться, тогда оно должно содержать нули. Поле «Длина сообщения» указывает количество байтов в пользовательской дейтаграмме. При этом учитывается длина заголовка протокола UDP и длина поля данных. Контрольная сумма пользовательской дейтаграммы может вычисляться, а может и не вычисляться. Нулевое поле «Контрольная сумма» означает, что контрольная сумма не вычислялась. Контрольная сумма, как правило, не вычисляется при работе протокола UDP в высоконадежной локальной сети. Однако в ненадежной сети только контрольная сумма может указать на достоверность и целостность пришедших данных — ведь протокол IP не вычисляет контрольную сумму поля данных IP-дейтаграмм. Для расчета контрольной суммы пользовательской дейтаграммы необходима дополнительная информация. Для этой цели к началу пользовательской дейтаграммы приписывают псевдозаголовок и добавляют в конец этой дейтаграммы байт, заполненный нулями, так, чтобы число бит во всем сообщении было кратно 16. После этого вычисляется контрольная сумма полученной дейтаграммы. Концевое дополнение из нулей и псевдозаголовок не передаются вместе с пользовательской дейтаграммой. Для вычисления контрольной суммы полученной пользовательской дейтаграммы сначала сохра­няется ноль в поле «Контрольная сумма», затем вычисляется 16-битная сумма, включая псевдозаголовок, заголовок самой дейтаграммы и данных. При получении пользовательской дейтаграммы контрольная сумма должна проверяться. При этом используется IP-адрес назначения, полученный из заголовка IP-дейтаграммы, которая содержала пользовательскую дейтаграмму протокола UDP. Если контрольные суммы одинаковы, то пользовательская дейтаграмма действительно достигла нужного получателя и нужный протокольный порт на станции получателя. На рис. 11.2   показан формат псевдозаголовка.   Рис. 11.2 Формат псевдозаголовка Псевдозаголовок имеет длину 12 байт. Поле «Протокол» содержит код типа протокола. Для проверки контрольной суммы получатель должен извлечь эти поля из IP-заголовка, сформировать свой псевдозаголовок и вычислить контрольную сумму. Данные протокола UDP инкапсулируются в IP-дейтаграммах при передаче их по сети (рис. 11.3 ). Рис. 11.3 Cхема инкапсуляции сообщений UDP Это означает, что только IP-заголовок определяет отправителя и получателя, а заголовок пользовательской дейтаграммы протокола UDP определяет протокольные порты приложений. Протокол UDP принимает дейтаграммы от многих прикладных программ и передает их соответствующим прикладным программам на устройствах-получателях. Программное обеспечение UDP обеспечивает мультиплексирование и демультиплексирование дейтаграмм. Операционная система должна выделить каждой прикладной программе порт и сообщить ей его номер. После этого прикладная программа может посылать дейтаграммы с указанием номера прото­кольного порта. Протокол UDP принимает приходящие с уровня IP (в работе UDP принимают участие и сами дейтаграммы IP, см. выше) пользовательские дейтаграммы протокола UDP и демультиплексирует их по протокольным портам назначения. На рис. 11.4 показан пример демультиплексирования. Рис. 11.4 общая схема демультиплексирования пользовательской дейтаграммы Порт UDP можно представить в виде очереди. Операционная система создает внутреннюю очередь, которая хранит приходящие сообщения. Если поступило сообщение с номером протокольного порта, которого нет среди используемых протокольных портов, оно удаляется и высылается сообщение протокола ICMP «Получатель недостижим» с кодом «Порт недостижим». Некоторые номера протокольных портов стандартизированы. Эти номера выделяет центральный орган — организация IANA (Internet Assigned Numbers Authority). Она регулярно публикует список назначений. Эти протокольные порты зарезервированы и их использование контролируется IANA. В большинстве систем они могут использоваться только системными процессами или программами, выполняемыми привилегированными пользователями. Несколько лет назад эти протокольные порты использовали диапазон номеров от 0 до 255. Однако недавно IANA расширила этот диапазон — теперь она отвечает за назначение портов с номерами от 0 до 1023. Остальные порты могут назначаться динамически. Сетевое программное обеспечение назначает протокольный порт, когда программа в нем нуждается. Такие протокольные порты не контролируются IANA и могут свободно использоваться пользовательскими процессами. Номера этих протокольных портов лежат в диапазоне от 1024 до 65 535. Протокольные порты в диапазоне от 1024 до 5000 называются временными (ephemeral). Хотя IANA не контролирует использование этих протокольных портов, она поддерживает информацию о них в интересах сообщества пользователей Internet. Для получения информации о текущем назначении протокольных портов необходимо послать соответствующий запрос.   12.  ПРОТОКОЛ TCP Для достижения высокой производительности конечных систем и сети в целом очень важно правильно выбрать транспортный протокол. Транспортный протокол обеспечивает интерфейс между приложениями и сетевым оборудованием. Он выполняет несколько функций, в том числе, позволяет приложениям запрашивать желаемое качество обслуживания. Сетевые приложения фирмы Microsoft требуют, чтобы сетевые драйверы обеспечивали как режим передачи данных с гарантией доставки, так и негарантированную доставку. При передаче с гарантией доставки потеря данных исключается, так как постоянно проводится подтверждение успешности приема. Если подтверждение не получено, производится повторная посылка данных. Ориентированные на предварительное установление соединения транспортные протоколы, такие как TCP (Transmission Control Protocol), делят общий поток данных приложения на раздельные логические потоки и могут дифференцированно распределять ресурсы между ними, что позволяет эффективно использовать общую пропускную способность. Протокол управления передачей данных TCP описан в документе RFC 793. Протокол TCP — это основной транспортный протокол стека протоколов TCP/IP. Он обеспечивает надежную передачу данных, базируясь на услугах протокола IP. На протокол TCP, в частности, возложена задача управления потоками и перегрузками, что подразумевает согласование скорости передачи данных с техническими возможностями рабочей станции-получателя и промежуточных устройств. Поступающие к получателю данные буферизуются средствами протокола TCP. Перед отправкой данные также буферизуются. Для достижения необходимой для данного логического соединения пропускной способности важно правильно выбрать реализацию протокола TCP и оптимально настроить его параметры, влияющие на производительность. В конечном счете пропускная способность логических соединений определяет, насколько быстро приложения обмениваются данными по сети. Такие протоколы прикладного уровня, как HTTP и FTP, передают протоколу TCP свои данные для транспортировки. Поэтому скоростные характеристики TCP оказывают непосредственное влияние на производительность приложений. Кроме того, на уровень перегрузок, возникающих в сети, очень влияют правила транспортного протокола для передачи и повторной передачи данных. Протокол TCP активно используется и поддерживается большинством приложений, которые опираются на стек протоколов TCP/IP. Протокол TCP входит в состав транспортных протоколов, поддерживаемых операционной системой Microsoft Windows NT 5.0 (Windows 2000). На рис. 12.1  схематично показана сетевая модель этой операционной системы и место протокола TCP в ней.   Рис. 12.1 Протокол ТСР в операционной системе Microsoft Windows NT 5.0   Поддержка TCP позволяет пользователям Microsoft Windows NT совместно работать через сеть с использованием всех доступных сервисов. В операционной системе Microsoft Windows NT 5.0 поддержка TCP значительно расширена. Реализация стека протоколов TCP/IP для операционных систем Microsoft Windows NT 4.0/5.0 пользуется параметрами, которые хранятся в системном реестре. Эти параметры можно корректировать вручную, но, вообще говоря, данные реализации протоколов являются самонастраивающимися. Коротко рассмотрим основные расширения протокола TCP в операционной системе Microsoft Windows NT 5.0: q       Выборочное подтверждение (TCP Selective Acknowledgment, SACK — RFC 2018). Это расширение сравнительно недавно утвердил консорциум IETF. Оно позволяет подтверждать прием данных не в порядке их поступления, как это было раньше, а выборочно. Этот подход имеет два главных преимущества. Во-первых, повышается эффективность повторных передач дейтаграмм протокола TCP благодаря сокращению времени повторной передачи. Протокол TCP использует алгоритм повторной передачи, который учитывает, в каком порядке поступают подтверждения. Такой подход вполне приемлем, однако в этом случае на восстановление каждого потерянного сегмента уходит примерно один цикл обращения. Механизм SACK позволяет осуществлять повторную передачу сразу нескольких потерянных сегментов в одном цикле. Во-вторых, благодаря выборочным подтверждениям, протокол TCP, как показали проведенные исследования, точнее оценивает доступную ширину полосы пропускания в условиях не­скольких последовательных потерь пакетов и способен обойтись без вы­полнения алгоритма «Медленного старта»; q       Подтверждение с задержкой (Delayed Acknowledgments — RFC 1122). В соответствии с этим алгоритмом подтверждения высылаются, если не было выслано подтверждение на предыдущий принятый сегмент, или если после получения сегмента в течение 200 мс не поступил следую­щий; q       Механизмы масштабирования окон (TCP Receive Window Size Calculation and Window Scaling — RFC 1323). Протокол не использует жестко заданный размер окна. Он может увеличивать его размер на величину максимального размера сегмента (Maximum Segment Size, MSS), величина которого определяется при установлении соединения. Размер окна приема по умолчанию равен 8 Кбайт. Этот размер выставляется в настройках реестра для протокола TCP, а именно, в параметре TcpWindowSize. Максимальный размер окна — 64 Кбайт. Для сетей Ethernet размер окна обычно равен 8760 байт для версии Microsoft Windows NT 4.0 и 17 520 байт (16 Кбайт, размещенные в двенадцати сегментах по 1460 байт) для версии Microsoft Windows NT 5.0; q       Временные штампы (TCP Timestamps - RFC 1323); q       Обнаружение PMTU (PMTU (Path Maximum Transmission Unit) Discovery — RFC 1191). Обычно величина MSS равна величине MTU за вычетом 40 байт на заголовки IP и TCP. Сегмент в распределенную сеть отправляется с запретом фрагментации. На отдельных участках сети может быть принят другой MTU. Маршрутизатор, который настроен на этот размер, отсылает сообщение протокола ICMP о недоступности пункта назначения с указанием действующего размера MTU. На основании этого сообщения отправитель изменит значение MTU так, чтобы сегменты смогли достичь получателя. Максимальный размер MTU составляет 68 байт. Предусмотрена возможность работы с маршрутизаторами, которые не совместимы с алгоритмом определения MTU. Для работы с ними в реестре предусмотрены два параметра. PMTU можно определить и вручную — командой ping с ключом запрета фрагментации; q       Обнаружение неработающего шлюза — маршрутизатора по умолчанию — (Dead Gateway Detection). Метод описан в документе RFC 816. Проводятся необходимые действия для поиска работающего маршрутизатора взамен отключенного с соответствующей корректировкой таблицы маршрутизации; q       Политика повторной передачи (TCP Retransmission Behavior). Число попыток повторной передачи определяется параметром реестра ТсрМахDataRetransmission. По умолчанию этот параметр равен 5. Добавление единицы к этому параметру удваивает значение таймера повторной передачи, которое в начальный период работы соединения равно 3 с; q       Алгоритмы медленного старта и предотвращения перегрузки (Slow Start Algorithm and Congestion Avoidance — RFC 1122); q       Предотвращение синдрома «глупого» окна (Silly Window Syndrome, SWS — RFC 1122). Получатель всегда старается увеличить окно приема, если имеет свободное буферное пространство. Отправитель также старается увеличить окно передачи при малейшей возможности. В такой ситуации говорить о стабильном потоке сегментов не приходится. Для того чтобы уберечь отправителя и получателя от соблазна «втиснуть в канал лишний сегмент», используется алгоритм предотвращения SWS. Большой объем данных не отправляется до тех пор, пока получатель не объявит размер окна, достаточный для посылки полного сегмента. Кроме того, может производиться настройка, не позволяющая увеличивать окно приема меньше, чем на сегмент; q       Алгоритм Nagle (Nagle Algorithm, RFC 896). Алгоритм предназначен для уменьшения количества небольших сегментов в сети. Предпочтение при передаче отдается полноразмерным сегментам. В данном разделе подробно рассматриваются лишь некоторые из этих расширений. Для того чтобы понять основные механизмы работы всех существующих расширений, остановимся на базовых принципах протокола. За подробностями заинтересованный читатель может обратиться к документам RFC, приведенным в табл. 12.1. Следует отметить, что глубокое понимание существующих механизмов протокола TCP и того, как они влияют на производительность сети, необходимо для разработки, внедрения, эксплуатации или сопровождения сетей. Это обусловлено тем, что TCP лежит в основе всех современных сетевых операционных систем — и в первую очередь, Windows NT. Так, если внедряется крупная, распределенная сеть на базе этой операционной системы, то проектировщику стоит обратить самое пристальное внимание на планирование загрузки сетевых каналов. Таблица12.1. Стандарты RFC, поддерживаемые операционной системой Microsoft Windows NT 5.0 Документ RFC   Название   768   User Datagram Protocol (UDP)   783   Trivial File Transfer Protocol (TFTP)   791   Internet Protocol (IP)   792   Internet Control Message Protocol (ICMP)   793   Transmission Control Protocol (TCP)   816   Fault Isolation and Recovery   826   Address Resolution Protocol (ARP)   854   Telnet Protocol (TELNET)   862   Echo Protocol (ECHO)   863   Discard Protocol (DISCARD)   864   Character Generator Protocol (CHARGEN)   865   Quote of the Day Protocol (QUOTE)   867   Daytime Protocol (DAYTIME)   894   IP over Ethernet   919,922   IP Broadcast Datagrams (broadcasting with subnets)   950   Internet Standard Subnetting Procedure   959   File Transfer Protocol (FTP)   1001,1002   NetBIOS Service Protocols   1009   Requirements for Internet Gateways   1034,1035   Domain Name System (DNS)   1042   IP over Token Ring   1055   Transmission of IP over Serial Lines (IP-SLIP)   1112   Internet Group Management Protocol (IGMP)   1122,1123   Host Requirements (communications and applications)   1134   Point-to-Point Protocol (PPP)   1144   Compressing TCP/IP Headers for Low-Speed Serial Links   1157   Simple Network Management Protocol (SNMP)   1179   Line Printer Daemon Protocol   1188   IP over FDDI   1191   Path MTU Discovery   1201   IP over ARCNET   1231   IEEE 802.5 Token Ring MIB (MIB-II)   1256   ICMP Router Discovery Messages   1323   TCP Extensions for High Performance   1332   PPP Internet Protocol Control Protocol (IPCP)   1334   PPP Authentication Protocols   1518   An Architecture for IP Address Allocation with CIDR   1519   Classless Inter-Domain Routing (CIDR): An Address Assignmentand Aggregation Strategy   1533   DHCP Options and BOOTP Vendor Extensions   1534   Interoperation Between DHCP and BOOTP   1541   Dynamic Host Configuration Protocol (DHCP)   1542   Clarifications and Extensions for the Bootstrap Protocol   1547   Requirements for Point-to-Point Protocol (PPP)   1548   Point-to-Point Protocol (PPP) .   1549   PPP in High-level Data Link Control (HDLC) Framing   1552   PPP Internetwork Packet Exchange Control Protocol (IPXCP)   1825   Security Architecture for the Internet Protocol   1826   IP Authentication Header (AH)   1827   IP Encapsulating Security Payload (ESP)   1828   IP Authentication using Keyed MD5   1829 ESP DES-CBC Transform 1851   The ESP Triple DES-CBC Transform   1852   IP Authentication using Keyed SHA   2014   HMAC: Keyed Hashing for Message Authentication   2085   HMAC-MD5 IP Authentication with Replay Prevention   2136   Dynamic Updates in the Domain Name System (DNS UPDATE)   2205   Resource Reservation Protocol (RSVP) — Version 1 Functional Specification   2236   Internet Group Management Protocol, Version 2     12.1 Формат заголовка ТСР Протокол TCP — это основной транспортный протокол в стеке протоколов TCP/IP. Он обеспечивает надежную передачу потока данных, опираясь при этом на ненадежный сервис транспортировки дейтаграмм, предоставляемый протоколом IP. В сетях IP протокол TCP используется для обработки запросов на вход в сеть, разделения ресурсов (файлов и принтеров), репликации информации между контролерами доменов, передачи списков ресурсов и т. д. На протокол TCP, в частности, возложена задача управления потоками и перегрузками. Он отвечает за согласование скорости передачи данных с техническими возможностями рабочей станции-получателя и промежуточных устройств в сети. Рассмотрим пример использования TCP в неоднородной сети. На рис. 7.2 показана схема движения информации по цепочке: отправитель, сеть Frame Relay, маршрутизатор, получатель. Маршрутизатор является связующим звеном между сетью Frame Relay и сетью Ehternet 802.2, в которой работает получатель. Как видно из рис. 12.2, протокол TCP выполняет основную задачу по доставке информации. Рис. 12.2 Схема прохождения информации при использовании протокола ТСР С течением времени в протокол TCP постоянно добавляются расширения и появляются более современные его реализации. Этот протокол использует только один тип протокольного блока данных (PDU — Protocol Data Unit), который называется сегментом TCP. Сегмент состоит из заголовка и поля данных (полезной нагрузки). На рис. рис. 12.3  показан формат заголовка сегмента TCP. Минимальная длина составляет 20 байт. Такая большая величина обусловлена тем, что один и тот же заголовок используется протоколом для самых различных целей. Для определения назначения большинства полей предназначены контрольные биты. Формат и значения поля «Контрольные биты» описаны в табл.11.2. Рис. 12.3 Формат заголовка протокола ТСР Таблица 11.2. Формат и значения поля «Контрольные биты» Бит   1   2   3   4   5   6   Сокращение   URG   АСК   PSH   RST   SYN   FIN   Назначение   Поле «Указатель срочности» задействовано Поле «Номер подтверждения» задействовано Включена функция проталкивания Перезагрузка данного  соединения Синхрониза­ция номеров  в очереди Данных  для пере-дачи нет   Из рис.12.3 видно, что протокол TCP использует следующие поля: q       Поле «Номер в последовательности» (Sequence Number) определяет номер первого байта в очереди (последовательности) байтов в текущем сегменте. Исключение составляют случаи, когда установлен бит (флаг) синхронизации SYN. Тогда это поле обозначает начальный номер в по­следовательности (Initial Sequence Number, ISN), и первый байт данных имеет номер в очереди ISN+1. q       Поле «Номер подтверждения» (Acknowledgment Number) содержит сле­дующий номер в последовательности получаемых подтверждений, который ожидает отправитель в ответ на отосланный сегмент. Иными словами, на отосланный сегмент с данными отправитель ожидает сегмент с под­тверждением его успешного приема. В заголовке в поле «Номер в после­довательности» занесен указанный номер подтверждения. При этом должен быть установлен контрольный бит подтверждения АСК. Подтверждения (или, как часто говорят, АСК) посылаются постоянно, как только соединение будет установлено. q       Поле «Смещение данных» (Data Offset) определяет количество 32-битных слов в заголовке TCP. Тем самым указывается начало поля данных. Заголовок протокола TCP всегда заканчивается на 32-битной границе, даже если он содержит опции. q       Поле «Резерв» (Reserved) должно быть заполнено нулями и предназначено для будущего расширения протокола. q       Поле «Окно» (Window) содержит объявляемый размер окна в байтах. q       Поле «Контрольная сумма» (Checksum) рассчитывается по сегменту, при этом определяется 16-битное дополнение суммы всех 16-битных слов в заголовке и в поле данных. Если сегмент содержит нечетное количество байтов, то он будет дополнен нулями справа до образования 16-битного слова. Этот выравнивающий байт не передается с сегментом по сети, так как может быть «восстановлен» получателем. Контрольная сумма учитывает также 96-битный псевдозаголовок, который ставится перед заголовком протокола TCP. Псевдозаголовок включает следующие поля из заголовка протокола IP: IP-адреса отправителя и получателя, протокол и длину сегмента. С помощью добавления псевдозаголовка протокол TCP защищает самого себя от ошибочной доставки протоколом IP. Так, если протокол IP доставляет сегмент, не предназначенный данному работающему приложению, то модуль протокола TCP на принимающей стороне обнаружит некорректность доставки. q       Поле «Указатель срочности» (Urgent Pointer) сообщает текущее значение указателя срочности. Эта положительная величина определяет смещение относительно номера в очереди данного сегмента. Этот указатель сообщает номер байта, следующего за срочными данными, то есть, начиная с этого байта, данные имеют обычный статус срочности. Поле используется совместно с контрольным битом URG. q       Поле «Опции» (Options) имеет переменную длину и может вообще отсутствовать. Опции располагаются в конце заголовка протокола TCP и их длина кратна 8 битам. Протокол TCP должен быть готов обрабатывать все виды опций. Опции используются для решения вспомогательных задач, например, для выбора максимального размера сегмента. q       Поле «Выравнивание» (Padding) может иметь переменную длину и представляет собой фиктивное поле, используемое для доведения размера заголовка до целого числа 32-битных слов. Некоторые поля в заголовке сегмента протокола TCP могут быть использованы при его дальнейшем развитии. «Номер в последовательности» и «Номер подтверждения» выравниваются по числу байтов в поле данных, а не по длине всего сегмента. Например, если сегмент содержит в поле «Номер в последовательности» значение 1000 и несет в поле данных 600 байт данных, то поле «Номер в последовательности» указывает на номер первого байта в поле данных. Следующий (в логическом порядке) сегмент будет иметь в поле «Номер в последовательности» значение 1601. Мы видим, что протокол TCP изначально логически ориентирован на работу с потоком данных. Он принимает байты от пользовательского приложения, группирует их, а затем распределяет по сегментам и формирует поток сегментов с нумерацией каждого байта. Флаги PSH (Push) и URG (Urgent) реализуют две службы протокола TCP: продвижение (проталкивание) потока данных и сигнализацию о срочных данных. Обычно протокол TCP передает данные, когда количество предназначенных для передачи байтов равно длине поля данных очередного сегмента. Приложение может потребовать, чтобы протокол передал все оставшиеся данные и пометил их флагом PSH. На принимающей стороне модуль протокола TCP доставит эти данные приложению сразу (то есть данные не будут ждать своей очереди в буфере). Приложение может прибегнуть к проталкиванию, если достигнут логический конец данных. Поле «Указатель срочности» позволяет информировать приложения на принимающей стороне о том, что в принимаемый ими поток помещены важные данные. Связь модуля протокола TCP и пользовательского приложения осуществляется при помощи специального интерфейса. Приложение использует ряд команд для управления модулем протокола. Если пользовательское приложение формирует команду SEND для передачи блока данных модулю протокола TCP, то он помещает эти данные в буфер отправки. Если при этом был установлен флаг PSH, любые оставшиеся в буфере данные, включая данные, которые только что были помещены в него, будут немедленно посланы (в одном или нескольких сегментах), а последний сегмент будет помечен флагом PSH. Если этот флаг не установлен, то протокол TCP может держать данные в буфере и посылать их в подходящее время. Например, протокол может ожидать до тех пор, пока в буфере накопится такое количество данных, которое позволит отсылать сегменты с предельно большим полем данных, повышая тем самым эффективность передачи. Данные в сегменте проходят через соединение к точке входа в модуль протокола TCP и сохраняются в буфере приема, который ассоциируется с этим соединением. Если входящие данные помечены флагом PSH, то они вместе с данными, уже имеющимися в буфере, немедленно доставляются приложению по команде RECEIVE. Если данные не помечены флагом PSH, то протокол TCP доставляет эти данные в подходящее время. Например, протокол может ожидать накопления большего количества данных для уменьшения прерываний в системе. Документ RFC 793 определил только одну опцию — максимальный размер сегмента. Поле этой опции с размером 16 бит может быть использовано только в сегменте, который посылается при запросе на создание логического соединения. Опция определяет максимальный размер сегмента в байтах, который будет использоваться будущим соединением. За время, прошедшее после публикации документа RFC 793, широкое распространение получили две другие опции: «Параметр масштабирования окна» (Window scale factor) и «Временной штамп» (Timestamp). Обычно, поле «Окно» в заголовке протокола TCP определяет некий лимит или кредит, выданный отправителю на размещение его данных в отсылаемых сегментах и измеряемый в байтах. Когда используется опция «Параметр масштабирования окна», количество байтов данных, размещаемых в поле «Окно» должно быть кратно 2F, где F — это параметр масштабирования окна. Максимальное значение F, которое может быть использовано протоколом TCP, — 14. Следует отметить, что эта опция включается только на время установления соединения. Полное описание этого метода приведено в разделе 2.2 документа RFC 1323. В этом же документе описан алгоритм «Временной штамп». Этот алгоритм используется для соединений, работающих с окнами большого размера. Опция «Временной штамп» используется для того, чтобы проводить точное измерение времени прохождения сигнала до получателя и обратно, то есть времени обращения (Round Trip Time, RTT). Такие замеры необходимы для корректировки времени повторной передачи при отсутствии подтверждения приема определенного сегмента. «Временной штамп» реально может быть использован в любом сегменте с данными и определяет два дополнительных поля: «Timestamp Value» (значение временного штампа) и «Timestamp Echo Reply» (ответ на временной штамп получен). Протокол TCP может включить поле «Timestamp Value» в любой исходящий сегмент. Когда этот сегмент подтверждается принимающей стороной, то отвечающий модуль протокола TCP включает в ответный сегмент поле «Timestamp Echo Reply» с тем же самым значением, что было в поле «Timestamp Value» в сегменте, который был подтвержден. Это позволяет протоколу TCP выполнять постоянный мониторинг времени обращения. В операционной системе Windows 2000 предусмотрен режим использования алгоритма «Временной штамп» по умолчанию.   12.2. Протокол TCP. Установление соединения Состояние системы Соединения протокола TCP переходят из одного состояния в другое в ответ на определенные события — запросы клиента, приход сегментов с флагами SYN, АСК, RST, FIN — или по истечении заданного времени. Соединение может находиться в одном из следующих состояний: qLISTEN — ожидание запроса на соединение со стороны внешних (чужих) портов и внешних (чужих) программ TCP. qSYN-SENT — ожидание парного запроса на установление соединения (со стороны отправителя запрос уже сделан). qSYN-RECEIVED — ожидание подтверждения после того, как запрос на установление соединения уже принят и отправлен. qESTABLISHED — соединение установлено. Принимаемые от приложения данные можно передать пользователю. qFIN-WAIT-1 — ожидание запроса от чужой программы TCP или подтверждение ранее отправленного запроса на закрытие соединения. qFIN-WAIT-2 — ожидание запроса на закрытие соединения со стороны чужой программы TCP. qCLOSE-WAIT — ожидание запроса на закрытие соединения со стороны своего клиента. qCLOSING — ожидание подтверждения запроса о закрытии соединения со стороны чужой программы TCP. qLAST-ACK — ожидание ответного запроса на закрытие соединения на посланный запрос о закрытии соединения, который был ранее отправлен чужой программе TCP. qTIME-WATT — соединение находится в этом состоянии на протяжении времени, достаточного для того, чтобы быть уверенным, что чужая программа TCP получила подтверждение своего запроса на закрытие соединения. qCLOSED — соединение закрыто. Основное состояние соединения — ESTABLISHED (соединение установлено). В этом состоянии происходит обмен данными между абонентами. 12.3 Протокол TCP. Передача данных. Блок управления передачей Для обеспечения надежной передачи данных по установленным логическим со­единениям между прикладными программами протокол TCP должен обеспечивать следующие функции: q       передачу данных; q       проверку достоверности данных при передаче; q       управление потоком данных; q       разделение каналов связи; q       обслуживание установленных соединений; q       соблюдение установленного приоритета пользователей; q       обеспечение соответствующего уровня безопасности. Для одновременного использования протокола TCP несколькими прикладными программами на одном компьютере он представлен набором адресов и портов. Поскольку идентификаторы портов выбираются каждой программой протокола TCP независимо, то они не будут уникальны. Уникальна совокупность идентификатора порта и IP-адреса. Эта совокупность называется сокет. Соединение между отправителем и получателем полностью определяются двумя сокетами на его концах. Это соединение можно использовать для передачи данных в обоих направлениях, то есть оно поддерживает дуплексный режим передачи. Существует несколько основополагающих концепций связи портов с прикладными программами при любой реализации протокола TCP. Для сохранения всей совокупности информации, необходимой для создания и поддержки соединения, каждый раз при установлении соединения создается структура данных, называемая блоком управления передачей (Transmission Control Block, TCB). Блок управления передачей ТСВ хранит всю постоянную информацию по созданному соединению и текущие значения нескольких переменных, например, определяющих очередность отправления. К постоянной информации относятся: номера локального и удаленного сокетов, флаги безопасности и приоритета для данного соединения, указатели на буферы отправки и приема. Блок ТСВ поддерживает несколько переменных, определяющих очередность отправления и получения сегментов. К ним относятся переменные, связанные с отправкой: q       SND.UNA — посылка не подтверждена; q       SND.NXT — послать следующий сегмент; q       SND.WND — отправить окно; q       SND.UP — отправить срочный указатель; q       SND.WL1 — номер в очереди сегмента, использованный для обновления последнего окна; q       SND.WL2 — номер подтверждения в сегменте, используемый для обновления последнего окна; q       ISS — первоначальный номер в очереди отправки; и переменные, связанные с получением: q       RCV.NXT — получить следующий сегмент; q       RCV.WND - получить окно; q       RCV.UP — получить срочный указатель; q       IRS — первоначальный номер в очереди получения. Часто используются переменные, берущие свое значение из полей очередного сегмента. К ним относятся: q       SEG.SEQ — номер в очереди для сегмента; q       SEG.ACK — номер подтверждения для сегмента; q       SEG.LEN — длина сегмента; q       SEG.WND — окно для сегмента; q       SEG.UP — срочный указатель для сегмента; q       SEG.PRC — приоритет для сегмента. На рис. 12.4  показана последовательность этапов отправки и приема данных. На примере рис.12.4 рассмотрим принцип использования некоторых переменных. Отправитель данных с помощью переменной SND.NXT отслеживает следующий номер сегмента в очереди, подлежащего отправке. Получатель данных с помощью переменной RCV.NXT отслеживает номера прибывающих сегментов. В поле переменной SND.UNA отправитель данных помещает самый старый номер сегмента, который уже был отправлен, но на который еще не получено подтверждение (АСК). Когда отправитель создает и посылает новый сегмент, он увеличивает значение своей переменной SND.NXT. Адресат при получении этого сегмента увеличивает значение своей переменной RCV.NXT и отправляет подтверждение. Рис. 12.4 Процесс: а) передачи данных; б) прием данных   При получении подтверждения увеличивается значение переменной SND.UNA отправителя. Разность значений переменных SND.NXT и SND.UNA может служить мерой задержки сегментов в сети. Переменные увеличиваются на длину поля данных в сегменте. Установление и закрытие соединений При открытии и закрытии соединений в зависимости от поведения сторон могут возникать самые различные ситуации (но так или иначе соединение всегда будет находиться в одном из состояний, перечисленных выше). Упрощенно же процесс открытия соединения можно представить следующей последовательностью действий: q       Инициатор соединения посылает запрос к протоколу TCP на открытие порта для передачи. q       После открытия порта протокол TCP на стороне приложения-инициатора посылает запрос приложению, с которым требуется установить соединение (принимающей стороне). q       Протокол TCP на принимающей стороне открывает порт для приема данных и отсылает квитанцию, подтверждающую прием запроса. q       Принимающая сторона открывает порт для передачи и также передает запрос к противоположной стороне. q       Приложение-инициатор открывает порт для приема и возвращает квитанцию. С этого момента соединение считается установленным. После этого начинается обмен информацией по данному соединению. При передаче данных по соединению каждый байт информации нумеруется. Нумерация ведется и в очереди отправления и в очереди получения. Первоначальный номер байта в очереди отправки указывается модулем TCP посылающей стороны, а первоначальный номер байта в очереди приема выясняется во время установления соединения. В это время оба модуля протокола TCP должны синхронизировать друг с другом первоначальные номера байтов в очередях. Синхронизация производится путем обмена сегментами, которые используются при установке соединения. Эти сегменты несут флаг синхронизации SYN и исходные номера для обоих очередей. Синхронизация требует, чтобы каждая сторона послала свой собственный первоначальный номер в очереди и получила подтверждение о принятии этого номера. Нумеруются и сами сегменты: номером сегмента считается номер первого байта в поле полезной нагрузки этого сегмента. Рассмотрим синхронизацию номеров на примере создания соединения между станцией А и станцией Б. Для синхронизации необходимо выполнить следующие действия: 1.     Станция А посылает сегмент с флагом SYN и своим номером в очереди N станции Б; 2.     Станция Б посылает  подтверждение — «ваш номер в очереди N» — станции А; 3.     Станция Б посылает сегмент с флагом SYN и своим номером в очереди (обозначим его К) станции А; 4.     Станция А посылает подтверждение — «ваш номер в очереди К» — станции Б. Шаги 2 и 3 можно объединить, поэтому такой обмен называется открытием соединения с подтверждением трех сообщений. Эту же процедуру открытия соединения с подтверждением трех сообщений можно показать с фиксацией состо­яний соединения и переходов между ними (рис. 7.5). Каждая строка на рис. 7.5 пронумерована и показывает состояние соединения. Стрелки «→» означают отправление сегмента от модуля TCP станции А в модуль TCP станции Б. Стрелки «←» показывают отправку сегментов в противоположном направлении. Промежуточное состояние соединения соответствует моменту посылки или по­лучения сегмента. На рис. Рис. 12.5  показано не все содержание сегментов — приведены только номера в очереди, флаги управления и АСК. Рис. 12.5 Процедура подтверждения трех сообщений для синхронизации соединения Станция А указывает, что она будет использовать номер в очереди 100. В ответ станция Б посылает свой номер в очереди 300 и говорит, что ожидает получения номера 101. В последней строке после установления соединения модуль TCP станции А передает некоторую порцию данных. На рис. 12.6  показана нормальная, штатная процедура закрытия соединения. Рис. 12.6  Нормальная процедура закрытия соединения Как видно, при закрытии соединения происходит обмен сегментами, несущими управляющий флаг FIN, указывающий на отсутствие данных для передачи.   12.4 Механизм окна TCP. Управление потоком данных .Плавающее окно Как и большинство протоколов, осуществляющих управление потоком данных (например, HDLC и Х.25), протокол TCP использует механизм плавающих окон. Протоколы HDLC и Х.25 используют этот механизм в классическом виде — на каждый отправленный блок данных должно быть получено подтверждение. Протокол TCP несколько отходит от классической схемы. Основной недостаток классической схемы заключается в том, что только один сегмент может быть передан за один сеанс. В данном случае под сеансом понимается посылка сегмента и получение подтверждения на его успешный прием. Такая схема не позволяет работать с максимальной производительностью. Эффективность может быть значительно повышена, если разрешить передачу множества сегментов за один сеанс с группировкой всех подтверждений для них в одно. Рассмотрим схему работы этого метода на примере двух станций — А и Б, которым необходимо обмениваться данными. Станция Б выделяет буферное пространство для приема п сегментов. Поэтому станция Б может принять п сегментов, а станция А может послать те же п сегментов без необходимости ожидания подтверждений об их приеме. Для отслеживания подтверждений о принятых сегментах каждый из них помечается номером в последовательности. Станция Б подтверждает получение сегмента посылкой подтверждения на него, которое содержит номер в последовательности следующего ожидаемого сегмента. Это подтверждение также косвенным образом извещает станцию А о том, что станция Б готова получить следующие п сегментов, начиная с указанного номера. Такая схема работы годится для подтверждения получения множества сегментов. Например, станция Б получает сегменты 2, 3 и 4, но воздерживалась от отправки подтверждения на сегменты 2 и 3 до получения сегмента 4. Посылая подтверждение с номером в последовательности 5, станция Б подтверждает получение сегментов 2, 3 и 4 за один раз. Таким образом, можно сказать, что станция А ведет список номеров в последовательности сегментов, которые ей разрешено посылать, а станция Б поддерживает список номеров в последовательности сегментов, которые она готова принять. Эти списки называют окнами сегментов, а такую схему передачи сообщений часто называют управлением потоком с использованием плавающего окна. Так как номер в последовательности занимает одно поле в сегменте, то очевидно, что номер не может быть слишком большим. Например, если это поле занимает 3 бита, то номер в последовательности сегментов может иметь значения от 0 до 7. Соответственно, сегменты нумеруются по модулю 8, то есть за номером в последовательности 7 следует номер в последовательности 0. Таким образом, для поля номера в последовательности, состоящего из k бит, границы изменения номера равны 0 и 2k-l, а сегменты нумеруются по модулю 2k. С учетом приведенных рассуждений на рис.12.7 показаны значения передаваемых и принимаемых сегментов на принимающей и передающей сторонах с фиксацией границ плавающего окна. В этом примере для простоты размер поля «Номер в последовательности» принят равным 3 битам. Серые прямоугольники указывают сегменты, которые могут быть посланы. В соответствии с рис. 12.7 отправитель может послать 5 сегментов, начиная с сегмента с номером 0. Каждый раз, когда сегмент посылается, ширина окна (серого прямоугольника) уменьшается. При получении подтверждения ширина окна увеличивается. Сегменты, находящиеся между черной вертикальной чертой и серым прямоугольником (окном) уже были посланы, но еще не были подтверждены. Отправитель должен хранить копии этих сегментов в своем буфере на случай, если потребуется их повторная передача. Рассмотрим следующий пример (рис. 12.8), позволяющий проследить последовательность обмена информацией. В этом примере для наглядности поле номера в последовательности имеет длину три бита, следовательно, максимальный номер равен 7 и окно не может содержать более семи номеров сегментов. В начале работы станции А и Б имеют окна длиной семь сегментов. То есть, станция А может передать семь сегментов, начиная с сегмента SO, а станция Б — принять такое же количество сегментов. После передачи трех сегментов (SO, S1 и S2) без подтверждения станция А сокращает размер своего окна до четырех сегментов и сохраняет в буферной памяти копию трех посланных сегментов. Новый размер окна указывает на то, что станция А может передать четыре сегмента, начиная с сегмента S3. Станция Б после получения сегментов передает сообщение RR3, в котором заложена следующая информация: «Я приняла все сегменты до номера S2 включительно и готова принять сегмент S3; в действительности я готова принять семь сегментов, начиная с сегмента S3».   Рис.12.7 Сегменты в потоке данных на передающем и принимающем устройствах   После получения подтверждения с такой информацией станция А считает себя вправе передать семь сегментов, начиная с сегмента S3. Кроме того, станция А может очистить свою буферную память от копий первых трех сегментов, так как они были успешно приняты. Теперь станция А передает сегменты S3, S4, S5 и S6. Станция Б в ответ на получение сегмента S3 отправляет подтверждение RR4 и позволяет производить передачу сегментов с номерами от S4 до S2 (этот сегмент относится уже к следующей последовательности из семи сегментов). На момент получения станцией А этого подтверждения сегменты S4, S5 и S6 уже были посланы и, следовательно, станция А может расширить свое окно и послать четыре сегмента, начиная с сегмента S7.   Рис. 12.8 Пример работы механизма плавающего окна   Пропускная способность Рассмотрим методы определения максимально возможной пропускной способности соединения протокола TCP. Пропускная способность зависит от размера окна передачи, задержки и скорости пересылки данных. Используем следующие обозначения: q       W — размер окна передачи в байтах; q       R — скорость передачи данных (бит/с) по определенному соединению, доступная на стороне отправителя; q       D — задержка (в секундах) при передаче данных между отправителем и получателем через определенное соединение. Для простоты рассуждений проигнорируем влияние служебных битов в сегменте TCP. Предположим, что отправитель начинает передавать последовательность байтов получателю через установленное соединение. Для того чтобы первый байт достиг получателя, потребуется время, равное D. Такое же время — D секунд — потребуется для получения подтверждения. В течение этого времени отправитель может передать 2RD бит, или RD/4 байт. На самом деле, отправитель ограничен размером окна в W байт и не может сдвигать окно, пока не получит подтверждение. Только при W> RD/4 на этом соединении достигается максимально возможная пропускная способность. Если W                   Основы создания сокетов          При создании сокета, необходимо определить три параметра: стиль взаимодействия, пространство имен, и пртокол. Стиль взаимодействия контролирует, как сокет обрабатывает передаваемые данные, и определяет количество партнеров взаимодействия. Через сокеты данные передаются блоками (пакетами). Стиль взаимодействия определяет, как эти пакеты будут обработаны и как они передаются от отправителя к получателю.  Стили соединения гарантируют доставку всех пакетов в том порядке, в каком они были отправлены. Если во время передачи пакеты были потеряны или доставлены в неправильном порядке, получатель автоматически отправляет запрос на их повторную передачу. Стиль соединения напоминает телефонный звонок: адреса отправителя и получателя фиксируются в начале соединения, при установке подключения.  Стили датаграм не гарантирует доставки и правильного порядка прибытия. Пакеты могут быть потеряны или переупорядочены в пути из-за сетевых ошибок. Каждый пакет должен быть помечен его адресатом, и нет гарантии, что он будет доставлен. Система гарантирует только "максимальные усилия", поэтому пакеты могут исчезнуть или прибыть в различном порядке. Сокет стиля датаграмы ведет себя сходно с почтой. Отправитель определяет адрес получателя для каждого индивидуального сообщения.            Пространство имен определяет, как записаны адреса сокета (socket addresses). Адрес сокета идентифицирует один конец подключения сокета. Например, адреса сокета в локальном пространстве имен являются обычными именами файлов. В пространстве имен Интернет адрес сокета состоит из Интернет адреса ( IP  адрес) главного компьютера, присоединенного к сети и номера порта, который идентифицирует сокет среди множества сокетов на том же главном компьютере.    Протокол определяет, как передаются данные. Существуют следующие виды протоколов:  TCP/IP  , первичные сетевые протоколы, используемые Интернетом; сетевой протокол  AppleTalk ; локальный  UNIX  протокол взаимодействия. Не все комбинации стилей, пространств имен и протоколов поддерживаются.   Системные вызовы Виды системных вызовов:  socket - создать сокет  closes - уничтожить сокет  connect - создать соединение между двумя сокетами  bind - привязать сокет к порту сервера  listen - настройка сокета для принятия подключений  accept - принять запрос на соединение и создать сокет для процесса взаимодействия  Сокеты представляются дескрипторами файлов. Создание и уничтожение сокетов  С помощью функций  socket и  close создаются и уничтожаются сокеты. При создании сокета, необходимо определить три параметра сокета: пространство имен, стиль взаимодействия и протокол.  Для указания пространства имен используются константы, начинающиеся с  PF_  (сокращение "семейство протокола"). Например,  PF_LOCAL  или  PF_UNIX  определяют локальное пространство имен, и  PF_INET  определяет Интернет пространство имен.  Второй параметр, стиль взаимодействия, представляет собой константу, начинающуюся с  SOCK_ . SOCK_STREAM определяет стиль взаимодействия соединение,  SOCK_DGRAM  - стиль датаграмы.  Третий параметр, протокол, определяет механизм нижнего уровня для передачи и получения данных. Для каждой комбинации пространство имен - стиль взаимодействия существует свой протокол.  Для каждой пары существует лучший протокол, поэтому можно указать 0, что соответствует этому протоколу. Если команда  socket выполнена успешно, в качестве результата возвращается дескриптор файла для сокета. С помощью команд  read  и  write , можно читать и записывать данные в сокет. Вызов connect  Для создания соединение между двумя сокетами, клиент вызывает  connect  , передавая адрес сокета сервера для подключения. Клиент - процесс, инициализирующий соединение, а сервер - процесс, ожидающий разрешения соединения. Клиент посылает запрос  connect , чтобы инициализировать соединение между локальным сокетом и сокетом сервера, переданным в качестве второго параметра. В качестве третьего параметра передается длина, в байтах, адресной структуры, на которую указывает второй параметр. Отправка данных    Любая техника записи в дескриптор файла, может использоваться при записи в сокет. Функция  send , определенная для дескрипторов файлов сокета, аналогична функции  write  с несколькими дополнительными параметрами.   13.2 Серверы  Цикл жизни сервера состоит из: - создания сокета, - привязки сокета к адресу,  -вызова  listen , разрешающего соединение с сокетом, вызова  accept , принимающего входящие соединения, - закрытия сокета. Данные не читаются и не записываются непосредственно через сокет сервера; вместо этого, каждый раз когда программа принимает новое соединение,  Linux  создает отдельный сокет, используется при передаче данных по этому соединению. В этом разделе рассматриваются вызовы  bind, listen  и  accept .          С помощью команды  bind  адрес сервера должен быть привязан к сокету. Первый параметр команды - дескриптор файла сокета. Второй параметр - указатель на структуру адреса сервера; формат которого зависит от семейства адреса. Третий параметр - длина структуры адреса, в байтах.          Когда адрес связан с сокетом стиля соединение, необходимо вызвать  listen , чтобы указать, что это - сервер. Первый параметр команды - дескриптор файла сокета. Второй параметр определяет, длину очереди ожидающих соединений. Если очередь заполнена, дополнительные соединения будут отвергнуты. Это не ограничивает общее количество соединений, которые сервер может обработать; это ограничивает только число клиентов, пытающихся соединиться и не получивших подтверждение.          С помощью команды  accept  сервер принимает запрос на соединение от клиента. Первый параметр вызова - дескриптор файла сокета. Второй параметр указывает на структуру адреса сокета, в которой хранится адрес клиентского сокета. Третий параметр - длина, в байтах, структуры адреса сокета. Сервер может использовать адрес клиента, чтобы определить, требуется ли действительно взаимодействовать с клиентом.          Вызов  accept  создает новый сокет для взаимодействия с клиентом и возвращает соответствующий дескриптор файла. Оригинальный сокет сервера продолжает принимать новые клиентские соединения.            Для чтения данных из сокета, без удаления их из входной очереди, используется команда  recv . В качестве параметров передаются теже аргументы, что и в команде read , плюс дополнительный параметр  FLAGS . Флаг  MSG_PEEK указывает, что данные должны быть прочитаны, но не удалены из входной очереди. 13.3 Локальные сокеты          Сокеты, подключающие процессы на одном компьютере могут использовать локальное пространство имен, представляющий собой синоним для  PF_LOCAL и  PF_UNIX . Они называются локальными сокетами или сокетами UNIX-домена. Адреса этих сокетов, определяемые именами файлов, используются только при создании соединения.    Имя сокета указывается в структуре  sockaddr_un . Если в  AF_LOCAL установлено поле  sun_family , это указывает на то, что адрс в докальном пространстве имен. Поле  Sun_path  указывает, что используется имя файла; максимальная длина поля - 108 байт. Для вычисления длины  struct sockaddr_un используется макрокоманда  SUN_LEN . Может использоваться любое имя файла, но для процесса должно быть установлено право на запись в каталог. Чтоб соединениться с сокетом, процесса должен иметь право на чтения файла. Хотя различные компьютеры могут совместно использовать одну файловую систему, только процессы, запущенные на этом компьютере, могут взаимодействовать используя сокеты локального пространства имен.            Единственный допустимый протокол для локального пространства имен - 0. Поскольку он находится в файловой системе, локальный сокет представлен как файл.            Например, обратите внимание на начальную s:          % ls -l /tmp/socket          srwxrwx--x 1 user group 0 Nov 13 19:18 /tmp/socket            Вызов  unlink удаляет локальный сокет, при завершении работы с ним. Пример использования локальных сокетов    В листинге 13.1 представлена программа сервера, в которой создается локальный сокет и слушает запросы на соединения с сервером. При получении запроса на соединение, сервер читает текстовые сообщения, передаваемые через соединение и печатает их. Если одно из этих сообщений - "выход", программа сервера удаляет сокет и завершается. Программа socket-server предполагает, что путь к сокету передается через параметр командной строки.    Листинг 13.1 (socket-server.c)          #include          #include          #include          #include          #include          #include           /*       Чтение текста из сокета и вывод его на печать. Продолжение цикла до закрытия сокета.           *       В качестве результата возвратит не ноль, если клиент передал сообщение "quit", иначе 0 */          int server (int client_socket)          {                    while (1) {                             int length;                             char* text;                             /* Сначала из сокета прочитать длину текстого сообщения. Если в качестве результата возвратиться 0,                                то клиент закрыл соединение */                             if (read (client_socket, &ength, sizeof (length)) == 0)                                       return 0;                             /* выделить место в буфере для хранения текста */                             text = (char*) malloc (length);                             /* Чтение текста и распечатка */                             read (client_socket, text, length);                             printf ("%s\n", text);                             /* Освободить буфер */                             free (text);                             /* Если от клиента поступило сообщение "quit", завершить работу */                             if (!strcmp (text, "quit"))                                       return 1;                    }          }          int main (int argc, char* const argv[])          {                    const char* const socket_name = argv[1];                    int socket_fd;                    struct sockaddr_un name;                    int client_sent_quit_message;                    /* Создать сокет */                    socket_fd = socket (PF_LOCAL, SOCK_STREAM, 0);                    /* Определить что это сервер */                    name.sun_family = AF_LOCAL;                    strcpy (name.sun_path, socket_name);                    bind (socket_fd, &name, SUN_LEN (&name));                    /* Слушать (ожидать) соединения */                    listen (socket_fd, 5);                    /* Неоднократно принимать соединения, создавая для каждого клиента server().                       Продолжать до получения от клиента сообщения "quit" */                    do {                             struct sockaddr_un client_name;                             socklen_t client_name_len;                             int client_socket_fd;                             /* Принимать соединение */                             client_socket_fd = accept (socket_fd, &client_name, &client_name_len);                             client_sent_quit_message = server (client_socket_fd);                             /* Закрыть соединение с нашей стороны */                             close (client_socket_fd);                    }                    while (!client_sent_quit_message);                    /* Удалить файл сокета */                    close (socket_fd);                    unlink (socket_name);                    return 0;          }    Клиент-программа, представленная в листинге 13.2, соединяется с локальным сокетом и посылает сообщения. Путь к сокету и сообщения передаtтся через командную строку.    Листинг13.2  (socket-client.c)          #include          #include          #include          #include          #include          /* Записать TEXT в сокет, переданный дескриптором файла SOCKET_FD */          void write_text (int socket_fd, const char* text)          {                    /* Записать в строку количество байт, включая NUL-терминал */                    int length = strlen (text) + 1;                    write (socket_fd, &length, sizeof (length));                    /* Записать строку */                    write (socket_fd, text, length);          }          int main (int argc, char* const argv[])          {                    const char* const socket_name = argv[1];                    const char* const message = argv[2];                    int socket_fd;                    struct sockaddr_un name;                    /* Создать сокет */                    socket_fd = socket (PF_LOCAL, SOCK_STREAM, 0);                    /* Сохранить имя сервера в адресе сокета */                    name.sun_family = AF_LOCAL;                    strcpy (name.sun_path, socket_name);                    /* Соединиться с сокетом */                    connect (socket_fd, &name, SUN_LEN (&name));                    /* Записать текст командной строки в сокет */                    write_text (socket_fd, message);                    close (socket_fd);                    return 0;          }            Перед передачей сообщения, посылается размер сообщения в байтах в качестве переменной length. Сервер сохраняет размер сообщения, для выделения памяти под сообщение. Чтобы выполнить этот пример, необходимо запустить сервер-программу в одном окне, определить путь к сокету.    Например,  /tmp/socket .          % ./socket-server /tmp/socket    В другом окне запустить клиент-программу несколько раз, опеределяя один и тот же путь сокета и посылая клиенту сообщение:          % ./socket-client /tmp/socket "Hello, world."          % ./socket-client /tmp/socket "This is a test."    Сервер-программа получает и печатает эти сообщения. Для закрытия соединения, клиент посылает сообщение "quit":          % ./socket-client /tmp/socket "quit"    Сервер-программа завершена.   13.4 Internet-Domain сокеты  Cокеты UNIX-domain использоваться только для взаимодействия двух процессов только на одном компьютере. Сокеты Internet, используются для соединения нескольких процессов на различных машинах, подключенных к сети.    Для соединения процессов через Интернет сокеты используют пространство имен Интернет указываемое с помощью  PF_INET . Большинство протоколов являются  TCP/IP . Интернет протокол ( IP), протокол нижнего уровня, отправляет пакеты через Интернет, разбивая на меньшие пакеты, в случае необходимости. Он гарантирует только доставку "лучшего усилия", так что пакеты могут быть потеряны или переупорядочены во время транспортировки. Каждый компьютер имеет  IP адрес. Протокол управления передачей ( TCP ), который следует за  IP  протоколом, обеспечивает надежное подключение. Это позволяет установить между компьютерами соединение, наподобие телефонного и гарантирует доставку данных в правильном порядке.    Интернет адрес сокета состоит из двух частей: номера компьютера и номера порта. Эта информация хранится в переменной структуры  sockaddr_in . Для идентификации того, что это адрес Интернет пространства имен, необходимо установить поле  sin_family в  AF_INET . В поле  Sin_addr  хранится Интернет адрес компьютера, как 32-разрядное целое число  IP . Каждому сокету на одном компьютере присваивается номер порта. Поскольку различные машины сохраняют многобайтовые значения в различном порядке байта, используют  htons , чтобы преобразовать число порта к сетевому порядку байтов.    Команда gethostbyname преобразовывает удобочитаемые имена хоста, числа со стандартной точечной нотацией (типа 10.0.0.1) или  DNS имена (такие как www.codesourcery.com) в 32-разрядные IP адреса. В качестве результата возвращается указатель на структуру  struct hostent ; в поле  h_addr хранится IP адрес главного компьютера.    Листинг 13.3 иллюстрирует использование Internet-domain сокетов. Программа получает домашнюю страницу от Web сервера, имя хоста которого определено в командной строке.    Листинг 13.3  (socket-inet.c)          #include          #include          #include          #include          #include          #include          #include          /* Печать содержимого домашней страницы.           * В качестве результата передать флаг успешного завершения процесса.*/          void get_home_page (int socket_fd)          {                    char buffer[10000];                    ssize_t number_characters_read;                    /* Передать команду HTTP GET для домашней страницы */                    sprintf (buffer, "GET /\n");                    write (socket_fd, buffer, strlen (buffer));                    /* Читать данные из сокета. Не все данные могут быть возвращены одновременно,                     * продолжать попытку до завершения процесса */                    while (1) {                             number_characters_read = read (socket_fd, buffer, 10000);                             if (number_characters_read == 0)                                       return;                             /* Записать данные в стандартный вывод */                             fwrite (buffer, sizeof (char), number_characters_read, stdout);                    }          }          int main (int argc, char* const argv[])          {                    int socket_fd;                    struct sockaddr_in name;                    struct hostent* hostinfo;                    /* Создать сокет */                    socket_fd = socket (PF_INET, SOCK_STREAM, 0);                    /* Сохранить адрес сервера в адрессе сокета */                    name.sin_family = AF_INET;                    /* Преобразовать строку в число */                    hostinfo = gethostbyname (argv[1]);                    if (hostinfo == NULL)                             return 1;                    else                             name.sin_addr = *((struct in_addr *) hostinfo->h_addr);                    /* Web сервер использует 80 порт */                    name.sin_port = htons (80);                    /* Установить соединение с Web сервером */                    if (connect (socket_fd, &name, sizeof (struct sockaddr_in)) == -1) {                             perror ("connect");                             return 1;                    }                    /* Получить домашнюю страницу */                    get_home_page (socket_fd);                    return 0;          }    Имя хоста Web сервера задается в командно строке (без "http: //"). Команда  gethostbyname  преобразовывает имя хоста в числовой IP адрес и затем подключает поток (TCP) сокета к порту 80 на главном компьютере. Серверы используют Гипертекстовый Транспортный Протокол ( HTTP ), поэтому передается команда  HTTP GET , сервер в качестве ответа передает текст домашней страницы.    Для отображения страницы www.codesourcery.com, необходимо задать следующую команду          % ./socket-inet www.codesourcery.com                            ... 13.5 Пары сокетов  Как упоминалось ранее, функция  pipe , создает два дескриптора файлов для начала и конца канала. Каналы ограничены, потому что дескрипторы файлов используются только связанными процессами и потому что взаимодействие однонаправлено. Функция  socketpair  создает два дескриптора файлов для двух сокетов, подключенных на одном компьютере. Эти дескрипторы файлов разрешают двухстороннее взаимодействие двух связанных процессов. Первые три параметра команды - идентичны параметрам команды  socket : они определяют домен, стиль подключения и протокол. Последний параметр - массив с двумя целыми числами, в котором хранятся характеристики файлов этих двух сокетов. При использовании команды  socketpair  , необходимо определить  PF_LOCAL как пространство имен.       14 WWW 14.1. Концепция Word Weide Web (Web или WWW)  . К 1989 году гипертекст представлял новую, многообещающую технологию, которая имела относительно большое число реализаций с одной стороны, а с другой стороны делались попытки построить формальные модели гипертекстовых систем, которые носили скорее описательный характер и были навеяны успехом реляционного подхода описания данных. Идея Т. Бернерс-Ли заключалась в том, чтобы применить гипертекстовую модель к информационным ресурсам, распределенным в сети, и сделать это максимально простым способом. Он заложил три краеугольных камня системы из четырех существующих ныне, разработав: ·       язык гипертекстовой разметки документов HTML (HyperText Markup Lan-guage); ·       универсальный способ адресации ресурсов в сети URL (Universal Resource Locator); ·       протокол обмена гипертекстовой информацией HTTP (HyperText Transfer Protocol).  Позже команда NCSA добавила к этим трем компонентам четвертый: ·       универсальный интерфейс шлюзов CGI (Common Gateway Interface).  Идея HTML -- пример чрезвычайно удачного решения проблемы построения гипертекстовой системы при помощи специального средства управления отображением. На разработку языка гипертекстовой разметки существенное влияние оказали два фактора: исследования в области интерфейсов гипертекстовых систем и желание обеспечить простой и быстрый способ создания гипертекстовой базы данных, распределенной на сети. 14.2  Гипертексты  В 1989 году активно обсуждалась проблема интерфейса гипертекстовых систем, т.е. способов отображения гипертекстовой информации и навигации в гипертекстовой сети. Значение гипертекстовой технологии сравнивали со значением книгопечатания. Утверждалось, что лист бумаги и компьютерные средства отображения/воспроизведения серьезно отличаются друг от друга, и поэтому форма представления информации тоже должна отличаться. Наиболее эффективной формой организации гипертекста были признаны контекстные гипертекстовые ссылки, а кроме того было признано деление на ссылки, ассоциированные со всем документом в целом и отдельными его частями.  Самым простым способом создания любого документа является его набивка в текстовом редакторе. Опыт создания хорошо размеченных для последующего отображения документов в CERN€е был - трудно найти физика, который не пользовался бы системой TeX или LaTeX. Кроме того к тому времени существовал стандарт языка разметки -- Standard Generalised Markup Language (SGML).  Следует также принять во внимание, что согласно своим предложениям Т. Бернерс-Ли предполагал объединить в единую систему имеющиеся информационные ресурсы CERN, и первыми демонстрационными системами должны были стать системы для NeXT и VAX/VMS. Word Weide Web (Web или WWW) предоставляет легкий в управлении графический интерфейс Internet. Эти документы, а также ссылки между ними образуют информационную «паутину» (Web). Рис. 14.1 Схема организации Web   Web предоставляет ссылки одной страницы на другие страницы (рис. 14.1). Web можно представить в виде большой библиотеки. Узлы Web подобны книгам, а «страницы» Web подобны страницам этих книг. Страницы могут содержать новости, рисунки, кинофильмы, страницы звукозаписи, объемные миры – все что угодно. Эти страницы могут размещаться на компьютерах в любой части света. При подключении к  Web пользователь получает равный доступ к сведениям, распределенным по всему миру. Обычно гипертекстовые системы имеют специальные программные средства построения гипертекстовых связей. Сами гипертекстовые ссылки хранятся в специальных форматах или даже составляют специальные файлы. Такой подход хорош для локальной системы, но не для распределенной на множестве различных компьютерных платформ. В HTML гипертекстовые ссылки встроены в тело документа и хранятся как его часть. Часто в системах применяют специальные форматы хранения данных для повышения эффективности доступа. В WWW документы -- это обычные ASCII- файлы, которые можно подготовить в любом текстовом редакторе. Таким образом, проблема создания гипертекстовой базы данных была решена чрезвычайно просто.  В качестве базы для разработки языка гипертекстовой разметки был выбран SGML (Standard Generalised Markup Language). Следуя академическим традициям, Бернерс-Ли описал HTML в терминах SGML (как описывают язык программирования в терминах формы Бекуса-Наура). Естественно, что в HTML были реализованы все разметки, связанные с выделением параграфов, шрифтов, стилей и т. п., т.к. реализация для NeXT подразумевала графический интерфейс. Важным компонентом языка стало описание встроенных и ассоциированных гипертекстовых ссылок, встроенной графики и обеспечение возможности поиска по ключевым словам.   14.3 HTML  С момента разработки первой версии языка (HTML 1.0) произошло довольно серьезное развитие языка. Почти вдвое увеличилось число элементов разметки, оформление документов все больше приближается к оформлению качественных печатных изданий, развиваются средства описания не текстовых информационных ресурсов и способы взаимодействия с прикладным программным обеспечением. Совершенствуется механизм разработки типовых стилей. Фактически, в настоящее время HTML развивается в сторону создания стандартного языка разработки интерфейсов как локальных, так и распределенных систем.    Язык HTML HyperText Markup Language (HTML) является стандартным языком, предназначенным для создания гипертекстовых документов в среде WEB. Такие документы могут просматриваться различными типами WEB-броузеров. Использование HTML позволяет форматировать документы для их представления с использованием шрифтов, линий и других графических элементов на любой системе, их просматривающей. Большинство документов имеют стандартные элементы, такие, как заголовок, параграфы или списки. Используя тэги HTML вы можете обозначать данные элементы, обеспечивая WEB-браузеры минимальной информацией для отображения данных элементов, сохраняя в целом общую структуру и информационную полноту документов. Основное преимущество HTML заключается в том, что ваш документ может быть просмотрен на WEB-браузерах различных типов и на различных платформах. HTML-документы могут быть созданы при помощи любого текстового редактора или специализированных HTML-редакторов и конвертеров. Выбор редактора зависит исключительно от понятия удобства и личных пристрастий каждого автора. Например, HTML редакторы, такие, как "Netscape Navigator Gold" компании Netscape позволяют создавать документы графически с использованием технологии WYSIWYG (What You See Is What You Get). С другой стороны, большинство традиционных средств для создания документов имеют конвертеры, позволяющие преобразовывать документы к формату HTML. Основные положения Все тэги HTML начинаются с "<" (левой угловой скобки) и заканчиваются символом ">" (правой угловой скобки). Как правило, существует стартовый тэг и завершающий тэг. Завершающий тэг выглядит так же, как стартовый, и отличается от него прямым слешем перед текстом внутри угловых скобок. Пример тэга заголовка, определяющий текст, находящийся внутри стартового и завершающего тэга и описывающий заголовок документа: Некоторые тэги, такие, как

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

 и 

. Структура документа HTML-документ представляет собой тэговую модель, то есть совокупность элементов, каждый из которых окружён тэгами. По своему значению тэги близки к понятию скобок «begin/end» в универсальных языках программирования, Тэги определяют области действия правил интерпретации текстовых элементов документа. В своём наиболее общем виде структура документа HTML выглядит следующим образом:                       < HTML>              Содержание документа                          Команда должна быть первой в документе. Она всегда используется в паре с , завершающей документ. Между этими двумя командами располагается текст страницы и другие команды.   Сам элемент HTML состоит из двух частей: заголовка (HEAD) и тела документа (BODY):                                                           Содержание заголовка                                                           Содержание тела документа                                                      Тэг заголовочной части документа должен быть использован сразу после тэга и более нигде в теле документа Стартовый тэг помещается непосредственно перед тэгом , размещается внутри -тэгов. HTML позволяет вставлять в тело документа комментарии, которые сохраняются при передаче документа по сети, но не отображаются броузером.  Комментарии могут встречаться в документе где угодно и в любом количестве. Тэги тела документа идентифицируют отображаемые в окне компоненты HTML-документа. Тело документа может содержать ссылки на другие документы, текст и другую форматированную информацию. Тело документа должно находиться между тэгами и . Это та часть документа, которая отображается как текстовая и графическая (смысловая) информация вашего документа.  Например: тело документа ,

,

,

, 

Когда пишется HTML-документ, текст структурно делится на просто текст, заголовки частей текста, заголовки более высокого уровня и т.д. Первый уровень заголовков (самый большой) обозначается цифрой 1, следующий - 2, и т.д. Большинство броузеров поддерживает интерпретацию шести уровней заголовков, определяя каждому из них собственный стиль. Стиль верхнего уровня имеет признак "1".
 Заголовок первого уровня 
В отличие от большинства текстовых процессоров, в HTML-документе обычно игнорируются символы возврата каретки. Физический разрыв абзаца может находиться в любом месте исходного текста документа. Однако броузер разделяет абзацы только при наличии тэга 
. Дополнительные параметры тэга 
:
 позволяют выравнивать абзац по левому краю, центру и правому краю.
Можно центрировать все элементы документа в окне браузера. Для этого можно использовать тэг 
.  Все элементы между тэгами  и  будут находиться в центре окна.
Тэг преформатирования, 
, позволяет представлять текст со специфическим форматированием на экране. Предварительно сформатированный текст заканчивается завершающим тэгом 
. Внутри предварительно сформатированного текста разрешается использовать: перевод строки, символы табуляции (сдвиг на 8 символов вправо) и непропорциональный шрифт, устанавливаемый броузером
Использование тэгов, определяющих формат абзаца, таких как  или 
, будет игнорироваться броузером при помещении их между тэгами 
 и 
.
Тэг 
 извещает броузер о разрыве строки.
Наилучший пример использования данного тэга - форматированный адрес или любая другая последовательность строк, где броузер должен отображать их одну под другой. Дополнительный параметр позволяет расширить возможности тэга 
. 

Он позволяет разместить следующую строку, начиная с чистой левой (left), правой (right) или обоих (all) границ окна броузера. Например, если рядом с текстом слева встречается рисунок, то можно использовать тэг 
 для смещения текста ниже рисунка:
Если вы не хотите, чтобы броузер автоматически переносил строку, то вы можете обозначить ее тэгами  и . В этом случае броузер не будет переносить строку даже если она выходит за границы экрана; вместо этого броузер позволит горизонтально прокручивать окно.
, данный тэг предназначен для обозначения в документе цитаты из другого источника. Текст, обозначенный тэгом 
, отступает от левого края документа на 8 пробелов
, стили шрифтов, размер и цвет шрифта.
Используя тэг 
 можно разделить текст горизонтальной чертой. Формат тэга: 

Параметры тэга:
SIZE           Толщина линии в пикселях.
WIDTH                Ширина линии в пикселях или процентах от ширины окна броузера.
ALIGN                 Расположение на экране (слева | по центру | справа).
NOSHADE По умолчанию линия представлена в 3D виде с тенью. NOSHADE позволяет представить линию просто однотонной темной полоской.
HTML позволяет использовать различные стили шрифтов для выделения текстовой информации в ваших документах. Вы можете комбинировать различные виды стилей.
Стиль                  Элемент или тэг                              Результат
Bold             Этот текст жирный                   Этот текст жирный
Italic            Этот текст наклонный                  Этот текст наклонный
Mono spaced         Текст с непроп. шрифтом     Текст с непроп. шрифтом
Комбинирование стилей позволяет вам отображать в одной строке несколько элементов различными стилями. Дополнительные стили:
big (большой)                большой 
small (маленький)                    маленький 
sub (подстрочник)                  подстрочник 
sup (надстрочник)                  надстрочник 
Можно изменять размер шрифта при помощи тэга: 
Шрифт может иметь размер от 1 до 7. Вы можете прямо указать размер шрифта цифрой, или указать смещение относительно базового значения (по умолчанию - 3) в положительную или отрицательную сторону. Базовое значение можно изменить при помощи тэга:  .
Можно изменить цвет шрифта при помощи тэга:  Красный 
 Зеленый 
 Синий 
Специальные тэги HTML
Тэг 
 используется для выделения автора документа и его адреса (например, e-mail). Синтаксис: 
 Адрес-автора 
Escape-последовательности.
Некоторые символы являются управляющими символами в HTML и не могут напрямую использоваться в документе: левая угловая скобка "<"  правая угловая скобка ">" амперсант "&"  двойные кавычки """
Чтобы использовать данные символы в документе, необходимо заменить их escape-последовательностями:  <     <   >     >   &     &   "     "
Список базовых тэгов HTML
    Стартовый
Завершающий
Описание


Обозначение HTML-документа


Заголовочная часть документа

Заголовок документа


Тело документа


Заголовок абзаца первого уровня


Заголовок абзаца второго уровня


Заголовок абзаца третьего уровня


Заголовок абзаца четвертого уровня


Заголовок абзаца пятого уровня


Заголовок абзаца шестого уровня


Абзац

Форматированный текст


 
Перевод строки без конца абзаца


Цитата

 
Горизонтальная черта


Жирный шрифт


Наклонный шрифт


Непроп. шрифт

 
Размер шрифта
 и < LINK HREF=URI >. Встраиваемые графические объекты также адресуются по спецификации URI в тагах < IMG SRC=URL > и . Реализация URI для WWW называется URL(Uniform Resource Locator). Точнее, URI -- это реализация схемы URL, отображенная на алгоритм доступа к ресурсам по сетевым протоколам. Существует еще и URN (Uniform Resource Name), которое отображает URL в пространство имен на сети. Вообще говоря, на мой взгляд это уже перебор. Собственно, появление URN связано с желанием адресовать части почтового сообщения MIME. Но здесь есть момент, который находится в стадии дебатов. Сообщение "живет" не более 5 дней. Если оно сохранено, то его можно превратить в другой информационный ресурс, например WWW страницу. Поэтому судьба URN еще не решена.
 
          При разработке URI преследовались следующие принципы:
o      Расширяемость -- новые адресные схемы должны были легко вписываться в существующий синтаксис URI.
o      Полнота -- по возможности, любая из существовавших схем должна была описываться посредством URI.
o      Читаемость -- адрес должен был быть легко читаем человеком, что вообще характерно для технологии WWW -- документы вместе с ссылками могут разрабатываться в обычном текстовом редакторе.
Полнота и Читаемость порождали коллизию, связанную с тем, что в некоторых схемах используется двоичная информация. Эта проблема была решена за счет формы представления такой информации. Символы, которые несут служебные функции и двоичные данные отображаются в URI в шестнадцатеричном коде и предваряются символом "%".
 Прежде, чем рассмотреть различные схемы представления адресов, приведем пример простого адреса URI:
 http://polyn.net.kiae.su/polyn/index.html  
 Перед двоеточием стоит имя схемы адреса -- "http". Это имя отделено двоеточием от остатка URI, который называется путь. В данном случае путь состоит из доменного адреса машины, на которой установлен сервер HTTP и пути от корня дерева сервера к файлу "index.html".
          Кроме представленной выше полной записи URI, существует упрощённая. Она предполагает, что к моменту ее использования многие параметры адреса ресурса уже определены (протокол, адрес машины в сети, некоторые элементы пути). При таких предположениях автор гипертекстовых страниц может указывать только относительный адрес ресурса, т.е. адрес относительный базовых определенных ресурсов.
Ссылки
Гипертекстовые ссылки являются ключевым компонентом, делающим WEB привлекательным для пользователей. Ссылки могут указывать на другой документ, специальное место данного документа или выполнять другие функции, например запрашивать файл по FTP-протоколу для отображения его браузером. URL может указывать на специальное место по абсолютному пути доступа, или указывать на документ в текущем пути доступа, что часто используется при организации больших структурированных WEB-сайтов. Вы можете использовать ссылки как для перемещения по документу, так и для перемещения от одного документа к другому.
 Однако, HTML не поддерживает возврат на предыдущую ссылку, если перемещение происходило внутри документа.
HTML использует URL (Uniform Resource Locator) для представления гипертекстовых ссылок и ссылок на сетевые сервисы внутри HTML-документа. Первая часть URL (до двоеточия) описывает метод доступа или сетевой сервис. Другая часть URL (после двоеточия) интерпретируется в зависимости от метода доступа. Обычно, два прямых слэша после двоеточия обозначают имя машины: method://machine-name/path/foo.html
URL имеет следующий формат:  method://servername:port/pathname#anchor
METHOD Имя операции, которая будет выполняться при интерпретации данного URL. Наиболее часто используемые методы:
file: чтение файла с локального диска. Данный метод используется для отображения какого-либо файла, находящегося на машине пользователя.
http: доступ к WEB-странице в сети с использованием HTTP-протокола.
ftp: запрос файла с анонимного FTP-сервера.
mailto: активизирует почтовую сессию с указанным пользователем и хостом.
telnet: обращение к службе telnet
news: вызов службы новостей, если броузер ее поддерживает.
SERVERNAME Необязательный параметр, описывающий полное сетевое имя машины.
PORT Номер порта TCP на котором функционирует WEB-сервер.
PATHNAME Частичный или полный путь к документу, который должен вызваться в результате интерпретации. Если после сетевого имени машины сразу идет имя документа, то он должен находиться в корневом каталоге на удаленной машине или (что чаще) в каталоге, выделенном WEB-сервером в качестве корневого. Если же URL заканчивается сетевым именем машины, то в качестве документа запрашивается документ из корневого каталога удаленной машины с именем, установленным в настройках WEB-сервера (как правило, это index.html).
#ANCHOR Данный элемент является ссылкой на строку (точку) внутри HTML-документа. Большинство броузеров, встречая после имени документа данный элемент, размещают документ на экране таким образом, что указанная строка документа помещается в верхнюю строку рабочего окна броузера. Точки, на которые ссылается #anchor, указываются в документе при помощи тэга NAME, как это будет описано далее.
Для того, чтобы броузер отобразил ссылку на URL, необходимо отметить URL специальными тэгами в HTML-документе.
 текст-который-будет-подсвечен-как-ссылка 
Тэг открывает описание ссылки, а тэг  - закрывает его. Любой текст, находящийся между данными двумя тэгами подсвечивается специальным образом Web-браузером. Текст, обозначающий URL, не отображается браузером, а используется только для выполнения предписанных им действий при активизации ссылки
Вот пример сегмента HTML-документа:
 
Для получения дополнительной информации смотри
 страницу компании СофтСервис 
Данная строка будет выглядеть на экране следующим образом:
http://nenwork-journal.mpei.ac.ru
 
Ссылки на точки внутри документа.
Можно делать ссылки на различные участки или разделы одного и того же документа, используя специальных скрытый маркер для этих разделов. Для создания такой ссылки необходимо выполнить следующие шаги:
1. Создайте маркер раздела.
 Текст в первой строке броузера 
2. Создайте ссылку на данный маркер:
 Текст 
 
Например
 


   


Список разделов
 
Раздел 1
Раздел 2
 
Раздел 1
 
Текст раздела 1
 
Раздел 2
 
Текст раздела 2 



 
         а)                                                                                 б)
Рис. 14.3 Текст (а) и  вид (б)отображаемой страницы примера
 
Маркер раздела может быть поставлен как в том же документе, который просматривается в текущий момент, так и в другом документе. Во втором случае браузер осуществит загрузку другого документа и перейдет к указанному для него разделу.
14.6 Протокол HTTP
HTTP (англ. HyperText Transfer Protocol — «протокол передачи гипертекста») — протокол прикладного уровня передачи данных (изначально — в виде гипертекстовых документов). Основой HTTP является технология «клиент-сервер», то есть предполагается существование потребителей (клиентов), которые инициируют соединение и посылают запрос, и поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом.
HTTP в настоящее время повсеместно используется во Всемирной паутине для получения информации с веб-сайтов. В 2006 году в Северной Америке доля HTTP-трафика превысила долю P2P-сетей и составила 46 %, из которых почти половина — это передача потокового видео и звука[1].
К концептуальным понятиям относится также протокол обмена данными в World Wide Web -- HyperText Transfer Protocol (HTTP), который предназначен для обмена гипертекстовыми документами и учитывает специфику такого обмена. Так в процессе взаимодействия, клиент может получить новый адрес ресурса на сети (relocation), запросить встроенную графику, принять и передать параметры и т. п. Управление в HTTP реализовано в виде ASCII-команд. Реально разработчик гипертекстовой базы данных сталкивается с элементами протокола только при использовании внешних расчетных программ или при доступе к внешним относительно WWW информационным ресурсам, например базам данных.
HTTP используется также в качестве «транспорта» для других протоколов прикладного уровня, таких как SOAP, XML-RPC, WebDAV.
Основным объектом манипуляции в HTTP является ресурс, на который указывает URI (англ. Uniform Resource Identifier) в запросе клиента. Обычно такими ресурсами являются хранящиеся на сервере файлы, но ими могут быть логические объекты или что-то абстрактное. Особенностью протокола HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и т. д. (В частности для этого используется HTTP-заголовок.) Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым.
         HTTP — протокол прикладного уровня, аналогичными ему являются FTP и SMTP. Обмен сообщениями идёт по обыкновенной схеме «запрос-ответ». Для идентификации ресурсов HTTP использует глобальные URI. В отличие от многих других протоколов, HTTP не сохраняет своего состояния. Это означает отсутствие сохранения промежуточного состояния между парами «запрос-ответ». Компоненты, использующие HTTP, могут самостоятельно осуществлять сохранение информации о состоянии, связанной с последними запросами и ответами (например, «куки» на стороне клиента, «сессии» на стороне сервера). Браузер, посылающий запросы, может отслеживать задержки ответов. Сервер может хранить IP-адреса и заголовки запросов последних клиентов. Однако сам протокол не осведомлён о предыдущих запросах и ответах, в нём не предусмотрена внутренняя поддержка состояния, к нему не предъявляются такие требования.
Структура протокола
Каждое HTTP-сообщение состоит из трёх частей, которые передаются в указанном порядке:
-         Стартовая строка (англ. Starting line) — определяет тип сообщения;
-         Заголовки (англ. Headers) — характеризуют тело сообщения, параметры передачи и прочие сведения;
-         Тело сообщения (англ. Message Body) — непосредственно данные сообщения. Обязательно должно отделяться от заголовков пустой строкой.
Заголовки и тело сообщения могут отсутствовать, но стартовая строка является обязательным элементом, так как указывает на тип запроса/ответа. Исключением является версия 0.9 протокола, у которой сообщение запроса содержит только стартовую строку, а сообщения ответа только тело сообщения.
Стартовая строка
Стартовые строки различаются для запроса и ответа. Строка запроса выглядит так:
GET URI — для версии протокола 0.9.
Метод URI HTTP/Версия — для остальных версий.
Здесь:
Метод (англ. Method) — название запроса, одно слово заглавными буквами. В версии HTTP 0.9 использовался только метод GET, список запросов для версии 1.1 представлен ниже.
URI определяет путь к запрашиваемому документу.
Версия (англ. Version) — пара разделённых точкой цифр. Например: 1.0
Стартовая строка ответа сервера имеет следующий формат: HTTP/Версия КодСостояния Пояснение, где:
Версия — пара разделённых точкой цифр как в запросе.
Код состояния (англ. Status Code) — три цифры. По коду состояния определяется дальнейшее содержимое сообщения и поведение клиента.
Пояснение (англ. Reason Phrase) — текстовое короткое пояснение к коду ответа для пользователя. Никак не влияет на сообщение и является необязательным.
Методы
Метод HTTP (англ. HTTP Method) — последовательность из любых символов, кроме управляющих и разделителей, указывающая на основную операцию над ресурсом. Обычно метод представляет собой короткое английское слово, записанное заглавными буквами. Обратите внимание, что название метода чувствительно к регистру.
Каждый сервер обязан поддерживать как минимум методы GET и HEAD. Если сервер не распознал указанный клиентом метод, то он должен вернуть статус 501 (Not Implemented). Если серверу метод известен, но он неприменим к конкретному ресурсу, то возвращается сообщение с кодом 405 (Method Not Allowed). В обоих случаях серверу следует включить в сообщение ответа заголовок Allow со списком поддерживаемых методов.
Кроме методов GET и HEAD, часто применяется метод POST.
OPTIONS
Используется для определения возможностей веб-сервера или параметров соединения для конкретного ресурса. В ответ серверу следует включить заголовок Allow со списком поддерживаемых методов. Также в заголовке ответа может включаться информация о поддерживаемых расширениях.
Предполагается, что запрос клиента может содержать тело сообщения для указания интересующих его сведений. Формат тела и порядок работы с ним в настоящий момент не определён. Сервер пока должен его игнорировать. Аналогичная ситуация и с телом в ответе сервера.
Для того, чтобы узнать возможности всего сервера, клиент должен указать в URI звёздочку — «*». Запросы «OPTIONS * HTTP/1.1» могут также применяться для проверки работоспособности сервера (аналогично «пингованию») и тестирования на предмет поддержки сервером протокола HTTP версии 1.1.
Результат выполнения этого метода не кэшируется.
GET
Используется для запроса содержимого указанного ресурса. С помощью метода GET можно также начать какой-либо процесс. В этом случае в тело ответного сообщения следует включить информацию о ходе выполнения процесса.
Клиент может передавать параметры выполнения запроса в URI целевого ресурса после символа «?»:
GET /path/resource?param1=value1¶m2=value2 HTTP/1.1
Согласно стандарту HTTP, запросы типа GET считаются идемпотентными.
Кроме обычного метода GET, различают ещё условный GET и частичный GET. Условные запросы GET содержат заголовки If-Modified-Since, If-Match, If-Range и подобные. Частичные GET содержат в запросе Range. Порядок выполнения подобных запросов определён стандартами отдельно.
HEAD
Аналогичен методу GET, за исключением того, что в ответе сервера отсутствует тело. Запрос HEAD обычно применяется для извлечения метаданных, проверки наличия ресурса (валидация URL) и чтобы узнать, не изменился ли он с момента последнего обращения.
Заголовки ответа могут кэшироваться. При несовпадении метаданных ресурса с соответствующей информацией в кэше копия ресурса помечается как устаревшая.
POST
Применяется для передачи пользовательских данных заданному ресурсу. Например, в блогах посетители обычно могут вводить свои комментарии к записям в HTML-форму, после чего они передаются серверу методом POST и он помещает их на страницу. При этом передаваемые данные (в примере с блогами — текст комментария) включаются в тело запроса. Аналогично с помощью метода POST обычно загружаются файлы на сервер.
В отличие от метода GET, метод POST не считается идемпотентным[4], то есть многократное повторение одних и тех же запросов POST может возвращать разные результаты (например, после каждой отправки комментария будет появляться одна копия этого комментария).
При результате выполнения 200 (Ok) в тело ответа следует включить сообщение об итоге выполнения запроса. Если был создан ресурс, то серверу следует вернуть ответ 201 (Created) с указанием URI нового ресурса в заголовке Location.
Сообщение ответа сервера на выполнение метода POST не кэшируется.
PUT
Применяется для загрузки содержимого запроса на указанный в запросе URI. Если по заданному URI не существовало ресурса, то сервер создаёт его и возвращает статус 201 (Created). Если же был изменён ресурс, то сервер возвращает 200 (Ok) или 204 (No Content). Сервер не должен игнорировать некорректные заголовки Content-*, передаваемые клиентом вместе с сообщением. Если какой-то из этих заголовков не может быть распознан или не допустим при текущих условиях, то необходимо вернуть код ошибки 501 (Not Implemented).
Фундаментальное различие методов POST и PUT заключается в понимании предназначений URI ресурсов. Метод POST предполагает, что по указанному URI будет производиться обработка передаваемого клиентом содержимого. Используя PUT, клиент предполагает, что загружаемое содержимое соответствует находящемуся по данному URI ресурсу.
Сообщения ответов сервера на метод PUT не кэшируются.
PATCH
Аналогично PUT, но применяется только к фрагменту ресурса.
DELETE  - Удаляет указанный ресурс.