20. Структурированные кабельные системы
Структурированная кабельная система (Structured Cabling System, SCS) - это набор коммутационных элементов (кабелей, разъемов, коннекторов, кроссовых панелей и шкафов), а также методика их совместного использования, которая позволяет создавать регулярные, легко расширяемые структуры связей в вычислительных сетях.
Структурированная кабельная система представляет своего рода «конструктор», с помощью которого проектировщик сети строит нужную ему конфигурацию из стандартных кабелей, соединенных стандартными разъемами и коммутируемых на стандартных кроссовых панелях. При необходимости конфигурацию связей можно легко изменить - добавить компьютер, сегмент, коммутатор, изъять ненужное оборудование, а также поменять соединения между компьютерами и концентраторами.
При построении структурированной кабельной системы подразумевается, что каждое рабочее место на предприятии должно быть оснащено розетками для подключения телефона и компьютера, даже если в данный момент этого не требуется. То есть хорошая структурированная кабельная система строится избыточной, В будущем это может сэкономить средства, так как изменения в подключении новых устройств можно производить за счет перекоммутации уже проложенных кабелей.
Структурированная кабельная система планируется и строится иерархически, с главной магистралью и многочисленными ответвлениями от нее (рис. 3.1).
Рис. 3.1. Иерархия структурированной кабельной системы
Эта система может быть построена на базе уже существующих современных телефонных кабельных систем, в которых кабели, представляющие собой набор витых пар, прокладываются в каждом здании, разводятся между этажами, на каждом этаже используется специальный .кроссовый шкаф, от которого провода в трубах и коробах подводятся к каждой комнате и разводятся по розеткам. К сожалению, в нашей стране далеко не во всех зданиях телефонные линии прокладываются витыми парами, поэтому они непригодны для создания компьютерных сетей, и кабельную систему в таком случае нужно строить заново.
Типичная иерархическая структура структурированной кабельной системы (рис. 3.2) включает:
Рис. 3.2. Структура кабельных подсистем
горизонтальные подсистемы (в пределах этажа);
вертикальные подсистемы (внутри здания);
подсистему кампуса (в пределах одной территории с несколькими зданиями).
Горизонтальная подсистема соединяет кроссовый шкаф этажа с розетками пользователей. Подсистемы этого типа соответствуют этажам здания. Вертикальная подсистема соединяет кроссовые шкафы каждого этажа с центральной аппаратной здания. Следующим шагом иерархии является подсистема кампуса, которая соединяет несколько зданий с главной аппаратной всего кампуса. Эта часть кабельной системы обычно называется магистралью (backbone).
Использование структурированной кабельной системы вместо хаотически проложенных кабелей дает предприятию много преимуществ.
Универсальность. Структурированная кабельная система при продуманной организации может стать единой средой для передачи компьютерных данных в локальной вычислительной сети, организации локальной телефонной сети, передачи видеоинформации и даже передачи сигналов от датчиков пожарной безопасности или охранных систем. Это позволяет автоматизировать многие процессы контроля, мониторинга и управления хозяйственными службами и системами жизнеобеспечения предприятия.
Увеличение срока службы. Срок морального старения хорошо структурированной кабельной системы может составлять 10-15 лет.
Уменьшение стоимости добавления новых пользователей и изменения их мест размещения. Известно, что стоимость кабельной системы значительна и определяется в основном не стоимостью кабеля, а стоимостью работ по его прокладке. Поэтому более выгодно провести однократную работу по прокладке кабеля, возможно, с большим запасом по длине, чем несколько раз выполнять прокладку, наращивая длину кабеля. При таком подходе все работы по добавлению или перемещению пользователя сводятся к подключению компьютера к уже имеющейся розетке.
Возможность легкого расширения сети. Структурированная кабельная система является модульной, поэтому ее легко расширять. Например, к магистрали можно добавить новую подсеть, не оказывая никакого влияния на существующие подсети. Можно заменить в отдельной подсети тип кабеля независимо от остальной части сети. Структурированная кабельная система является основой для деления сети на легко управляемые логические сегменты, так как она сама уже разделена на физические сегменты.
Обеспечение более эффективного обслуживания. Структурированная кабельная система облегчает обслуживание и поиск неисправностей по сравнению с шинной кабельной системой. При шинной организации кабельной системы отказ одного из устройств или соединительных элементов приводит к трудно локализуемому отказу всей сети. В структурированных кабельных системах отказ одного сегмента не действует на другие, так как объединение сегментов осуществляется с помощью концентраторов. Концентраторы диагностируют и локализуют неисправный участок.
Надежность. Структурированная кабельная система имеет повышенную надежность, поскольку производитель такой системы гарантирует не только качество ее отдельных компонентов, но и их совместимость.
Первой структурированной кабельной системой, имеющий все современные черты такого типа систем, была система SYSTIMAX SCS компании Lucent Technologies (ранее - подразделение AT&T). И сегодня компании Lucent Technologies принадлежит основная доля мирового рынка. Многие другие компании также выпускают качественные структурированные кабельные системы, например АМР, BICC Brand-Rex, Siemens, Alcatel, MOD-TAP. На российском рынке успешно завоевывает себе место под солнцем отечественная структурированная кабельная система АйТи-СКС московской компании «АйТи».
Транспортные протоколы. Протоколы tcp и udp.
Транспортный уровень отвечает за доставку сообщений в том порядке, в каком они были отправлены, без потерь и дублирования. Сложность транспортного протокола определяется возможностями сети и Канальных уровней. В случае надежного Сетевого уровня от Транспортного уровня требуется лишь передать данные на следующий уровень. Если же Сетевой или Канальный уровень ненадежен, то Транспортный уровень должен контролировать последовательности пакетов, а также подтверждать их прием, обнаруживать и исправлять ошибки. Транспортный уровень отвечает за следующие функции.
Прием сообщений с более высокого уровня и их сегментацию (если это необходимо).
Надежную доставку сообщений с передачей подтверждений о приеме.
Слежение за тем, чтобы компьютер-отправитель не передавал данные, если приемные буферы полностью заполнены.
Мультиплексирование нескольких потоков межпроцессных сообщений или сеансов для одного логического соединения и отслеживание принадлежности сообщений сеансам.
Транспортные протоколы с установлением соединения разработаны для передачи большого количества данных, при этом информация должна быть разбита на сегменты, умещающиеся в отдельных пакетах. Сегментация данных и нумерация сегментов являются важным элементом процесса передачи и помимо этого делают осуществимым выполнение других функций, таких как исправление ошибок. Процесс маршрутизации, выполняемый на Сетевом уровне, является динамическим, и в случае передачи данных возможно возникновение ситуации, когда сегменты следуют до места назначения разными путями и приходят не в том порядке, как они были отправлены. Нумерация сегментов позволяет принимающей системе восстановить исходный порядок следования сегментов. Эта нумерация также дает возможность системе-получателю сообщить отправителю, какой из пакетов был поврежден или потерян. В результате, отправитель может не повторять целиком всю передачу, а повторно переслать только потерянные сегменты. Управление потоком данных (flow control) - это одна из функций, обычно предоставляемая протоколами Транспортного уровня с установлением соединения. Она представляет собой механизм, согласно которому система, принимающая данные, может сообщить отправителю о том, что он должен снизить скорость передачи данных, или об опасности перегрузки системы получателя и потери данных. Эталонная модель OSI определяет две формы исправления ошибок, которые могут быть реализованы протоколами Транспортного уровня с установлением соединения. Одна из них - это реакция на ошибки, обнаруженные другими протоколами стека. Данный механизм не предусматривает поиска ошибок передачи самим протоколом Транспортного уровня. Вместо этого, протокол Транспортного уровня получает извещение от протоколов Сетевого или Канального уровня о том, что возникла ошибка, и определенный пакет был потерян или поврежден. Ему остается только послать сообщение, содержащее перечень пакетов и запрос на их повторную пересылку обратно системе-отправителю. Другая, форма исправления ошибок на Транспортном уровне представляет собой законченный процесс, начинающийся с обнаружения ошибок и заканчивающийся их коррекцией. Этот процесс охватывает и ошибки, которые еще не были обнаружены каким-либо другим способом. Механизм выявления ошибок Транспортного уровня обеспечивает контроль ошибок на всем участке между двумя конечными системами и включает в себя возможность исправления ошибок, которая осуществляется путем запроса у отправителя повторной передачи определенных пакетов.
Концепция портов. Мультиплексирование и демультиплексирование
Как уже было отмечено, главная задача транспортного уровня заключается в передаче данных между прикладными процессами. Эту задачу решают протокол управления передачей (Transmission Control Protocol, TCP) и протокол пользовательских дейтаграмм (User Datagram Protocol, UDP). Протоколы TCP и UDP имеют много общего. Тот и другой обеспечивают интерфейс с вышележащим прикладным уровнем, передавая данные, поступающие на входной интерфейс хоста, соответствующему приложению. При этом, оба протокола используют концепции «порт» и «сокет». Оба они также поддерживают интерфейс с нижележащим сетевым уровнем IP, упаковывая свои PDU в IP-пакеты. Однако, как мы увидим далее, различий между TCP и UDP гораздо больше, чем сходств.
Каждый компьютер может выполнять несколько процессов, более того, прикладной процесс тоже может иметь несколько точек входа, выступающих в качестве адреса назначения для пакетов данных. Поэтому после того, как пакет средствами протокола IP доставлен на сетевой интерфейс компьютера-получателя, данные необходимо переправить конкретному процессу получателю.
Существует и обратная задача: пакеты, которые отправляют в сеть разные приложения, работающие на одном конечном узле, обрабатываются общим для них протоколом IP. Следовательно, в стеке должно быть предусмотрено средство «сбора» пакетов от разных приложений для передачи протоколу IP. Эту работу выполняют протоколы TCP и UDP.
Процедура приема данных протоколами TCP и UDP, поступающих от нескольких различных прикладных служб, называется мультиплексированием. Обратная процедура – процедура распределения протоколами TCP и UDP поступающих от сетевого уровня пакетов между набором высокоуровневых служб – называется демультиплексированием.
Рис. 1. Мультиплексирование и демультиплексирование на транспортном уровне.
Протоколы TCP и UDP ведут для каждого приложения две очереди: очередь пакетов, поступающих к данному приложению из сети, и очередь пакетов, отправляемых данным приложением в сеть. Пакеты, поступающие на транспортный уровень, организуются операционной системой в виде множества очередей к точкам входа различных прикладных процессов. В терминологии TCP/IP такие системные очереди называются портами, причем входная и выходная очереди одного приложения рассматриваются как один порт. Для однозначной идентификации портов им присваивают номера. Номера портов используются для адресации приложений.
Если процессы представляют собой популярные общедоступные службы, такие как FTP, telnet, HTTP, TFTP, DNS и т.п., то за ними закрепляются стандартные, назначенные номера, также называемые хорошо-известными (популярными) (well-known) номерами портов. Так, номер 21 закреплен за службой удаленного доступа к файлам FTP, а 23 – за службой удаленного управления telnet. Назначенные номера являются уникальными в пределах Интернета и назначаются приложениям централизованно из диапазона от 0 до 1023.
Для тех приложений, которые еще не стали столь распространенными, чтобы закреплять за ними стандартные номера, номера портов назначаются разработчиками этих приложений или операционной системой локально в ответ на поступление запроса от приложения. На каждом компьютере операционная система ведет список занятых и свободных номеров портов. При поступлении запроса от приложения, выполняемого на данном компьютере, операционная система выделяет ему первый свободный номер. Такие номера называют динамическими. В дальнейшем все сетевые приложения должны адресоваться к данному приложению с указанием назначенного ему порта. После того как приложение завершит работу, выделенный ему локальный номер порта возвращается в список свободных и может быть назначен другому приложению. Динамические номера являются уникальными в пределах каждого компьютера, но при этом обычной ситуацией является совпадение номеров портов приложений, выполняемых на разных компьютерах. Как правило, клиентские части известных приложений (DNS, WWW, FTP, telnet и др.) получают динамические номера портов от ОС.
Все, что было сказано о портах, в равной степени относится к обоим протоколам транспортного уровня (TCP и UDP). В принципе нет никакой зависимости между назначением номеров для приложений, использующих протокол TCP, и приложений, работающих с протоколом UDP. Приложения, которые передают данные на уровень IP по протоколу UDP, получают номера, называемые UDP-портами. Аналогично приложениям, обращающимся к протоколу TCP, выделяются TCP-порты. В том и другом случаях это могут быть как назначенные, так и динамические номера. Диапазоны чисел, из которых выделяются TCP- и UDP-портов, совпадают: от 0 до 1023 для назначенных и от 1024 до 65535 для динамических. Однако никакой связи между назначенными номерами TCP- и UDP-портов нет.
Протокол UDP, являясь дейтаграммным протоколом, реализует сервис по возможности, то есть не гарантирует доставку своих сообщений, а, следовательно, никоим образом не компенсирует ненадежность дейтаграммного протокола IP.
Единица данных протокола UDP называется UDP-пакетом или пользовательской дейтаграммой (user datagram). Каждая дейтаграмма переносит отдельное пользовательское сообщение. Это приводит к естественному ограничению: длина дейтаграммы UDP не может превышать длины поля данных протокола IP, которое, в свою очередь, ограничено размером кадра технологии нижнего уровня. Поэтому если UDP-буфер переполняется, то данные приложения отбрасываются. Заголовок UDP-пакета, состоящий из четырех 2-байтовых полей, содержит поля порт источника, порт получателя, длина UDP и контрольная сумма. Поля порт источника и порт получателя идентифицируют передающий и получающий процессы.
Поле длина UDP содержит длину пакета UDP в байтах.
Поле контрольная сумма содержит контрольную сумму пакета UDP, вычисляемую по всему пакету UDP с добавленным псевдозаголовком.
Псевдозаголовок формируется исключительно для работы с контрольной суммой и имеет следующую структуру.
Поле протокол (длина 8 бит) идентифицирует протокол из заголовка пакета IP. Для UDP это значение равно 17.
Судя по простоте заголовка, протокол UDP очень сложным не является. Здесь стоит прямо сказать о том, чего UDP не делает. Итак, UDP не занимается контролем потока, контролем ошибок, повторной передачей после приема испорченного сегмента. Его функции сводятся к мультиплексированию и демультиплексированию данных между сетевым и прикладным уровнями. Для процессов, которым хочется управлять потоком, контролировать ошибки и временные интервалы, протокол UDP – это как раз то, что нужно. Одной из областей, где UDP применяется особенно широко, является область клиент-серверных приложений. Зачастую клиент посылает короткий запрос серверу и надеется получить короткий ответ. Если запрос или ответ теряется, клиент по прошествии определенного интервала может попытаться еще раз. Это позволяет не только упростить код, но и уменьшить требуемое количество сообщений по сравнению с протоколами, которым требуется начальная настройка.
Давайте рассмотрим, как протокол UDP решает задачу демультиплексирования. Казалось бы, для этой цели достаточно использовать номера портов. Кадры, несущие UDP-дейтаграммы, прибывают на сетевой интерфейс хоста, последовательно обрабатываются протоколами стека и, наконец, поступают в распоряжение протокола UDP. UDP извлекает из заголовка номер порта назначения и передает данные на соответствующий порт соответствующему приложению, то есть выполняет демультиплексирование.
Протокол TCP (Transmission Control Protocol) обеспечивает надежную транспортировку данных между прикладными процессами путем установления логического соединения.
Информация, поступающая к протоколу TCP от протоколов более высокого уровня, рассматривается протоколом TCP как неструктурированный поток байтов. Поступающие данные буферизируются средствами TCP. Для передачи на сетевой уровень из буфера «вырезается» некоторая непрерывная часть данных, которая называется сегментом. Сегмент состоит из фиксированного 20-байтного заголовка (плюс необязательная часть), за которой могут следовать байты данных. Размер сегментов определяется программным обеспечением TCP. Оно может объединять в один сегмент данные, полученные в результате нескольких операций записи, или, наоборот, распределять результата одной записи между несколькими сегментами. Размер сегментов ограничен двумя пределами. Во-первых, каждый сегмент, включая TCP-заголовок, должен помещаться 65 515-байтное поле полезной нагрузки IP-пакета. Во-вторых, в каждой сети есть максимальная единица передачи (MTU, Maximum Transfer Unit), и каждый сегмент должен помещаться в MTU. На практике размер максимальной единицы передачи составляет обычно 1500 байт (что соответствует размеру поля полезной нагрузки Ethernet), и таким образом определяется верхний предел размера сегмента.
4.1. Формат TCP-пакета
Заголовок TCP-сегмента содержит значительно больше полей, чем заголовок UDP, что отражает более развитые возможности первого протокола.
Рис.
5. Формат заголовка сегмента TCP.
Поле порт источника (Source Port) занимает 2 байта и идентифицирует процесс-отправитель.
Поле порт получателя (Destination Port) занимает 2 байта и идентифицирует процесс-получатель.
Поля порядковый номер (Sequence Number) (длина 4 байта) и номер подтверждения (acknowledgement number) (длина 4 байта) нумеруют каждый отправленный или полученный байт данных. Реализуются как целые числа без знака, которые сбрасываются, когда достигают максимального значения. Каждая сторона ведет собственную порядковую нумерацию.
Поле длина заголовка занимает 4 бита и представляет собой длину заголовка TCP-сегмента, измеренную в 32-битовых словах. Длина заголовка не фиксирована и может изменяться в зависимости от значений, устанавливаемых в поле параметры.
Поле резерв (Reserved) занимает 6 бит.
Поле флаги (Code Bits) занимает 6 бит и содержит шесть 1-битовых флагов:
флаг URG (Urgent Pointer – указатель точности) устанавливается в 1 в случае использования поля указатель на срочные данные;
флаг ACK (Acknowledgment – подтверждение) устанавливается в 1 в случае, если поле номер подтверждения содержит данные. В противном случае это поле игнорируется;
флаг PSH (Push – выталкивание) означает, что принимающий стек TCP должен немедленно информировать приложение о поступивших данных, а не ждать пока буфер заполнится;
флаг RST (Reset – сброс) используется для отмены соединения: из-за ошибки приложения, отказа от неверного сегмента, попытки создать соединение при отсутствии затребованного сервиса;
флаг SYN (Synchronize – синхронизация) устанавливается при инициировании соединения и синхронизации порядкового номера;
флаг FIN (Finished – завершение) используется для разрыва соединения. Он указывает, что отправитель закончил передачу данных.
Поле размер окна (Window) (длина 2 байта) содержит количество байт, которое может быть послано после байта, получение которого уже подтверждено.
Поле контрольная сумма (Checksum) (длина 2 байта) служит для повышения надежности. Оно содержит контрольную сумму заголовка, данных и псевдозаголовка, показанного на рис. 7. При выполнении вычислений поле контрольная сумма устанавливается равным нулю, а поле данных дополняется нулевым байтом, если его длина представляет собой нечетное число. Алгоритм вычисления контрольной суммы просто складывает все 16-разрядные слова в дополнительном коде, а затем вычисляет дополнение для всей суммы. В результате, когда получатель считает контрольную сумму всего сегмента, включая поле контрольная сумма, результат дожжен быть равен нулю.