Gigabit Ethernet

Достаточно быстро после появления на рынке продуктов Fast Ethernet сетевые интеграторы и администраторы почувствовали определенные ограничения при построении корпоративных сетей. Во многих случаях серверы, подключенные по 100-мегабитному каналу, перегружали магистрали сетей, работающие также на скорости 100 Мбит/с - магистрали FDDI и Fast Ethernet. Ощущалась потребность в следующем уровне иерархии скоростей. В 1995 году более высокий уровень скорости могли предоставить только коммутаторы АТМ, а при отсутствии в то время удобных средств миграции этой технологии в локальные сети внедрять их в локальную сеть почти никто не решался. Кроме того, технология АТМ отличалась очень высоким уровнем стоимости.

Поэтому логичным выглядел следующий шаг, сделанный IEEE через 5 месяцев после окончательного принятия стандарта Fast Ethernet. В июне 1995 года исследовательской группе по изучению высокоскоростных технологий IEEE было предписано заняться рассмотрением возможности выработки стандарта Ethernet с еще более высокой битовой скоростью. Первая версия стандарта была рассмотрена в январе 1997 года, а окончательно стандарт 802.3z был принят 29 июня 1998 года на заседании комитета IEEE 802.3. Разработчики технологии Gigabit Ethernet сохранили большую степень преемственности с технологиями Ethernet и Fast Ethernet. Gigabit Ethernet использует те же форматы кадров, что и предыдущие версии Ethernet, работает в полнодуплексном и полудуплексном режимах, поддерживая на разделяемой среде тот же метод доступа CSMA/CD с минимальными изменениями.

Gigabit Ethernet был разработан для поддержки полнодуплексных операций, как основного режима обмена сигналами. Когда системы могут одновременно передавать и принимать данные, нет необходимости в механизме управления доступом к среде, подобном CSMA/CD. Тем не менее, для того, чтобы системы в сети 1000BaseX могли работать в полнодуплексном режиме, понадобилось внесение некоторых изменений в механизм CSMA/CD. Если скорость, с которой система передает данные, возрастает, интервал времени, отведенный на обнаружение коллизии (называемый задержкой подтверждения сигнала), уменьшается. Когда Fast Ethernet увеличил быстродействие сети Ethernet в десять раз, то это ускорение было скомпенсировано уменьшением максимального диаметра сети. С дальнейшим десятикратным ростом производительности, уменьшать максимальный диаметр сети было непрактично, так как в результате сеть была бы не длиннее 20 м. Поэтому стандарт 802.3z удлинил сигнал несущей CSMA/CD с 64 байт до 512 байт. Это означает, что, несмотря на то, что минимальный размер пакета в 64 байта остается прежним, подуровень MAC системы Gigabit Ethernet добавляет к маленьким пакетам сигнал расширения несущей для того, чтобы дополнить пакеты до 512 байт. Тем самым, минимальное время, требуемое для передачи каждого пакета, становится достаточным для правильной работы механизма выявления коллизий, даже если сеть имеет такой же диаметр, как Fast Ethernet.

Для сокращения накладных расходов при использовании слишком длинных кадров для передачи коротких квитанций разработчики стандарта разрешили конечным узлам передавать несколько кадров подряд, без передачи среды другим станциям. Такой режим получил название Burst Mode - монопольный пакетный режим. Станция может передать подряд несколько кадров с общей длиной не более 8192 байт. Если станции нужно передать несколько небольших кадров, то она может не дополнять их до размера в 512 байт, а передавать подряд до исчерпания предела в 8192 байт (в этот предел входят все байты кадра, в том числе преамбула, заголовок, данные и контрольная сумма). Предел 8192 байт называется Burst Length. Если станция начала передавать кадр и предел Burst Length был достигнут в середине кадра, то кадр разрешается передать до конца.

В стандарте 802.3z определены следующие типы физической среды:

· медный коаксиальный кабель;

· одномодовый волоконно-оптический кабель 8,3/125;

· многомодовый волоконно-оптический кабель;

· неэкранированная витая пара пятой категории.

1000BaseLX предназначен для прокладки сравнительно протяженных магистралей, в которых данные передаются длинноволновым лазером с длиной волны в диапазоне от 1270 до 1355 нанометров по многомодовому оптоволоконному кабелю внутри здания или одномодовому кабелю в качестве более протяженной линии связи. Многомодовый оптоволоконный кабель с диаметром сердечника 50 или 62,5 микрон поддерживает линии связи длиной до 550 м, в то время как 9-микронный оптоволоконный кабель - до 5000 м (5 км).

В 1000BaseSX оптический сигнал генерируется при помощи коротковолнового лазера с длиной волны в диапазоне от 770 до 860 нанометров. Этот стандарт ориентирован на короткие магистрали и горизонтальные кабельные системы протяженностью до 500 м. Он более экономичен, чем 1000BaseLX, так как берет за основу только относительно недорогой многомодовый оптоволоконный кабель.

1000BaseLH (LH - аббревиатура от Long Haul, дальняя связь) не является стандартом, утвержденным IEEE, и даже не находится в процессе рассмотрения. Это спецификация Физического уровня, разработанная группой производителей сетевого оборудования, включающей 3Com и Cisco. Какие-либо определенные кабеля за стандартом еще не закреплены, поэтому разные производители работают с различными реализациями.

В оригинальном документе 802.3z присутствует только один стандарт для медной кабельной системы. 1000BaseCX предназначен исключительно для коротких линий связи (до 25 м). Эти соединения требуют применения целевого 150-омного экранированного медного кабеля. По существу, 1000BaseCX направлен на соединения между оборудованием, таким как кластеры серверов и линии связи между коммутаторами, поскольку он дешевле и проще в установке, чем оптоволоконный кабель.

Хотя это и не включено в стандарт 802.3z, но одной из первоначальных целей команды, разрабатывающей Gigabit Ethernet, была поддержка стандартного кабеля UTP категории 5 с длиной соединений длиной до 100 м, что позволило бы существующим сетям Fast Ethernet быть модернизированными до Gigabit Ethernet без прокладки нового кабеля или изменения топологии сети. 1000BaseT был определен в отдельном документе, называемом 802.3ab, который был единогласно утвержден IEEE в июне 1999 г.

Чтобы достигнуть таких высоких скоростей для медного кабеля, 1000BaseT изменил способ использования протоколом кабеля UTP. Несмотря на то, что 1000BaseT разработан для такой же кабельной системы, что и в 100BaseTX, он задействует все четыре пары кабеля вместо традиционных двух, что фактически удваивает его пропускную способность. Также 1000BaseT для передачи данных по кабелю опирается на более подходящую схему кодирования сигналов, отличную от других стандартов 1000BaseX. В таком сочетании каждая из витых пар переносит данные уже со скоростью 250 Мбит/с, что в сумме дает 1000 Мбит/с. Упомянутая схема кодирования известна под названием амплитудно-импульсной модуляция 5 (РАМ-5, Pulse Amplitude Modulation 5).

TCP/IP

TCP/IP - это соответствующий промышленным стандартам набор протоколов, предназначенный для поддержки межсетевых связей между региональными сетями (WAN). TCP/IP разработан в 1969 году Управлением ARPA (Advanced Research Projects Agency) Министерства обороны США для экспериментальной сети, известной под названием ARPANET (ARPA Network). Цель разработки TCP/IP заключалась в том, чтобы обеспечить высокоскоростные коммуникационные соединения между отдельными сетями. Впоследствии ARPANET превратилась во всемирное сообщество сетей - Интернет.

Протоколы TCP/IP соответствуют четырехуровневой концептуальной модели, известной как модель DARPA. Уровни в этой модели называются так: прикладной, транспортный, межсетевой и сетевой интерфейс. Каждый уровень в модели DARPA соответствует одному или более уровням в семиуровневой модели OSI (Open Systems Interconnection). Архитектура протоколов TCP/IP показана на рис. 24.

Рис. 24. Архитектура TCP/IP

Уровень сетевого интерфейса (network interface layer), также известный как уровень сетевого доступа (network access layer), отвечает за передачу TCP/IP-пакетов в сетевую среду и прием этих пакетов из сетевой среды. TCP/IP независим от способа доступа к сети, формата кадров и сетевой среды. Благодаря этому TCP/IP можно использовать для соединения сетей разных типов, построенных, в частности, на технологиях LAN (Ethernet, Toking Ring) и WAN (X.25, Frame Relay). Независимость от сетевой технологии позволяет адаптировать TCP/IP к новым технологиям вроде ATM (Asynchronous Transfer Mode). Уровень сетевого интерфейса предоставляет функциональность канального и физического уровней в модели OSI.

Межсетевой уровень (internet layer) отвечает за поддержку адресации, пакетов и маршрутизации. Базовые протоколы этого уровня - IP, ARP, ICMP и IGMP. Межсетевой уровень аналогичен сетевому уровню в модели OSI.

Транспортный уровень (transport layer), также известный как уровень транспорта между хостами (host-to-host transport layer), предоставляет прикладному уровню сеансовые коммуникационные службы и обеспечивает поддержку дейтаграмм. Базовые протоколы этого уровня - TCP и UDP. Транспортный уровень предоставляет всю функциональность транспортного уровня в модели OSI и часть функциональности ее сеансового уровня.

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

· HTTP (Hypertext Transfer Protocol) - протокол для передачи файлов, образующих содержимое Web-страниц в World Wide Web;

· FTP (File Transfer Protocol) - протокол для интерактивной передачи файлов;

· SMTP (Simple Mail Transfer Protocol) - протокол для передачи почтовых сообщений и вложений.

Компонент поддержки протоколов TCP/IP, устанавливаемый в сетевой операционной системе, - это набор протоколов для подключения к сети, называемых базовыми протоколами TCP/IP. Все прочие приложения и протоколы из набора протоколов TCP/IP опираются на базовые сервисы, предоставляемые протоколами IP, ARP, ICMP, IGMP, TCP и UDP.

IP - это не требующий соединений ненадежный протокол, ответственный главным образом за адресацию и маршрутизацию пакетов между хостами. Поскольку этот протокол не требует соединений, перед обменом данными сеанс не устанавливается. А ненадежность заключается в том, что доставка пакетов не гарантируется. IP всегда предпринимает максимум усилий для доставки пакета. IP-пакеты могут быть потеряны, доставлены не в том порядке, продублированы или задержаны. Такого рода ошибки IP не исправляет. За подтверждение приема пакета и восстановление потерянных пакетов отвечает протокол более высокого уровня, например, TCP. Протокол IP определен в RFC 791.

ARP. При посылке IP-пакетов в средах, построенных на сетевых технологиях разделяемого доступа (Ethernet или Token Ring), необходимо преобразование МАС-адресов (media access control) в IP-адреса. Эта задача возлагается на протокол ARP, определенный в RFC 826.

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

IGMP - д анный протокол управляет членством хоста в группах IP-рассылки (IP multicast groups), также называемых группами хостов (host groups). Хосты, входящие в такую группу, «слушают» IP-трафик, направляемый на определенный адрес. Этот трафик поступает на единственный МАС-адрес, но обрабатывается несколькими IP-хостами. Протокол IGMP определен в RFC 1112 и 2236.

TCP - это надежный транспортный протокол, требующий соединения. Данные передаются сегментами. Перед обменом данными по этому протоколу хосты должны установить соединение. Надежность достигается за счет присвоения порядкового номера каждому передаваемому сегменту. Хост-получатель передает подтверждение о приеме (АСК) каждого сегмента. Такое подтверждение должно поступать в течение определенного периода. Если отправитель не получает АСК, он повторно передает соответствующие данные. TCP определен в RFC 793.

UDP предоставляет не требующую соединений службу дейтаграмм, которая обеспечивает ненадежную доставку данных, передаваемых в виде сообщений. Это означает, что UDP не гарантирует ни доставку дейтаграмм, ни правильную последовательность доставляемых пакетов. В UDP не поддерживается восстановление потерянных данных за счет их повторной передачи. UDP используется приложениями, которые не требуют подтверждения приема данных и обычно передают данные небольшими порциями. Данный протокол определен в RFC 768.

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

IP-адрес имеет длину 32 бита и изображается в виде четырех 8-битных десятичных чисел, разделенных точками, например, 192.168.2.45. Такая форма записи называется точечной десятичной записью (dotted decimal notation), каждое из 8-битных чисел иногда носит название октета (octet) или квадранта (quad). IP-адреса определяют не столько компьютеры, сколько сетевые интерфейсы. Система с двумя платами сетевых адаптеров или с одним сетевым адаптером и модемным соединением с сервером TCP/IP, имеет два IP-адреса.

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

Для того чтобы IP-адрес однозначно идентифицировал компьютер критически важно, чтобы никакие два интерфейса не могли иметь одинаковые IP-адреса. В частной сети администраторы должны убедиться, что каждый адрес уникален. Они могут выполнить это, отслеживая вручную все адреса, ассоциированные с их сетями и узлами, или используя сервис DHCP (Dynamic Host Configuration Protocol, протокол динамической конфигурации узла) для присвоения адресов автоматически. В Интернете процедура выделения IP-адресов возложена на Internet Assigned Numbers Authority (IANA, Агентство по выделению имен и уникальных параметров протоколов Интернета).

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

Адреса класса A назначаются сетям с очень большим количеством хостов. Старший бит в адресе класса A всегда равен 0. Следующие 7 битов (завершающие первый октет) образуют идентификатор сети. Остальные 24 бита (последние три октета) представляют идентификатор хоста. Таким образом, класс A допускает максимум 126 сетей, а в каждой из них - до 16 777 214 хостов.

Адреса класса B назначаются сетям среднего и большого размера. Два старших бита в адресе класса B всегда являются комбинацией двоичных чисел 1 и 0. Следующие, 14 битов (завершающие первые два октета) образуют идентификатор сети. Остальные 16 битов (последние два октета) представляют идентификатор хоста. Таким образом, класс B допускает максимум 16 384 сети, а в каждой из них - до 65 534 хостов.

Адреса класса C назначаются малым сетям. Три старших бита в адресе класса C всегда являются комбинацией двоичных чисел 1, 1 и 0. Следующие 21 бит (завершающие первые три октета) образуют идентификатор сети. Остальные 8 битов (последний октет) представляют идентификатор хоста. Таким образом, класс C допускает максимум 2 097 152 сети, а в каждой из них - до 254 хостов.

Адреса класса D резервируются для адресов групповой IP-рассылки. Четыре старших бита в адресе класса D всегда являются комбинацией двоичных чисел 1,1,1 и 0. Остальные биты содержат адрес, известный заинтересованным хостам.

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

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

Таблица 2.

Нерегистрируемые IP-адреса

Класс сети	Диапазон адресов
Класс А	От 10.0.0.0 до 10.255.255.255
Класс В	От 172.16.0.0 до 172.31.255.255
Класс С	От 192.168.0.0 до 192.168.255.255

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

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

Например, можно создать подсеть на базе адреса сети класса B, используя третий квадрант, изначально предназначенный для адреса узла, в качестве адреса подсети. Изменение маски подсети с 255.255.0.0 на 255.255.255.0 позволяет разделить адрес класса B на 254 подсети по 254 узла в каждой. Затем можно присвоить каждому физическому сегменту сети индивидуальное значение третьего квадранта, выделив для адресов индивидуальных компьютеров только четвертый квадрант. В результате, маршрутизаторы будут направлять трафик в нужный сегмент сети, ориентируясь на значение третьего квадранта.

Для идентификации компьютеров аппаратное и программное обеспечение в сетях TCP/IP полагается на IP-адреса, поэтому для доступа к сетевому ресурсу в параметрах программы вполне достаточно указать IP-адрес, чтобы программа правильно поняла, к какому хосту ей нужно обратиться. Например, команда https://203.23.106.33 откроет начальную страницу на корпоративном Web-сервере. Однако пользователи обычно предпочитают работать с символьными именами компьютеров, и операционные системы локальных сетей приучили их к этому удобному способу.

В операционных системах, которые первоначально разрабатывались для работы в локальных сетях, таких как Novell NetWare, Microsoft Windows или IBM OS/2, пользователи всегда работали с символьными именами компьютеров. Так как локальные сети состояли из небольшого числа компьютеров, то использовались так называемые плоские имена, состоящие из последовательности символов, не разделенных на части. Примерами таких имен являются: NW1_1, mail2. Для установления соответствия между символьными именами и МАС - адресами в этих операционных системах применялся механизм широковещательных запросов.

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

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

Рис. 25. Пространство доменных имен

Иерархия доменных имен аналогична иерархии имен файлов, принятой во многих популярных файловых системах. Дерево имен начинается с корня, обозначаемого здесь точкой «.». Затем следует старшая символьная часть имени, вторая по старшинству символьная часть имени и т. д. Младшая часть имени соответствует конечному узлу сети.

Совокупность имен, у которых несколько старших составных частей совпадают, образуют домен имен (domain). Например, имена wwwl.zil.mmt.ru, ftp.zil.mmt.ru, yandex.ru и sl.mgu.ru входят в домен ru, так как все эти имена имеют одну общую старшую часть - имя ru. Необходимо подчеркнуть, что компьютеры входят в домен в соответствии со своими составными именами, при этом они могут иметь различные IP-адреса, принадлежащие к различным сетям и подсетям.

Соответствие между доменными именами и IP-адресами может устанавливаться как средствами локального хоста, так и средствами централизованной службы. На раннем этапе развития Internet на каждом хосте вручную создавался текстовый файл с известным именем hosts. Этот файл состоял из некоторого количества строк, каждая из которых содержала одну пару «IP-адрес - доменное имя», например 102.54.94.97 - rhino.acme.com.

По мере роста Internet файлы hosts также росли, и создание масштабируемого решения для разрешения имен стало необходимостью. Таким решением стала специальная служба - система доменных имен (Domain Name System, DNS). DNS - это централизованная служба, основанная на распределенной базе отображений «доменное имя - IP-адрес».

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

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

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