|
Ранее...
Дополнительно к уже описанному подробнее уточним причины появления отказов и их последствия уже применительно к рассматриваемым сетям. Схему соединений с рисунка 1 можно применять без изменений.
Здесь, для лучшего понимания, нам придётся погрузиться в историю. Стек TCP/IP был придуман не в самой отрасли связи, а в смежной — программировании. Изначальной его задачей было соединение компьютеров. Поэтому вопрос сохранения совместимости с уже работающими сетями связи, как например, пропуск голоса, перед архитекторами не стоял. Генераторами трафика должны были быть компьютерные программы. В качестве же каналов связи изначально использовались модемы. Эти особенности привели к достаточно раннему использованию технологии временного хранения данных перед передачей (то, что в англоязычной литературе называется store‑and‑forward). Кроме того, данная технология могла позволить легко организовать повторную пересылку при отсутствии подтверждения доставки от получателя, что в условиях ненадёжных каналов являлось хорошим подспорьем.
Дополнительной архитектурной особенностью сетей TCP/IP стал программный интерфейс для создания соединений по сети. Он был отвязан от знаний о будущей среде передачи и для программы выглядел как некая «труба» произвольной ёмкости, в которую с одной стороны помещались данные, а с другой — извлекались. Поэтому в теории программа‑инициатор соединения могла занять весь доступный канал, а честный арбитраж между программами возлагался на сам стек. В традиционных сетях связи оборудование специально проектировалось под нужную задачу, здесь же программы были общего назначения, а операционные системы проектировались многозадачными, поэтому вопрос арбитража трафика становился особенно необходимым.
Ещё одной специфической характеристикой сетей TCP/IP является сознательный выбор архитекторов эквивалентности между любыми устройствами сети. То есть для одних целей точка CE может становиться PE или P, а для других сохранять роль CE. При том встаёт вопрос — как хранить транзитные соединения, не относящиеся к собственным. Скорее всего в целях экономии ресурсов, была выбрана модель хранения состояния соединения только на конечных точках (CE1 и CE2), а на транзитных подобное знание отсутствует, и они просто пропускают трафик согласно установленным маршрутам, при этом, разумеется, возможен и «мусорный» трафик.
Не будем забывать, что основной единицей передачи в стеке TCP/IP является пакет данных. Учитывая всё вышеизложенное, попытаемся повторно решить за архитекторов важный вопрос: что делать с теми пакетами, которые либо не помещаются в очередь, хотя уже сформированы для отправки программой, либо по арбитражу ядром стека фиксируются как излишние, либо по маршрутным таблицам отсутствует следующая транзитная точка доставки. В традиционных сетях с коммутацией пакетов подобные случаи приводят к так называемым «отказам», которые транслируются на конечные точки соединений CE1 и CE2. В сетях же TCP/IP подобная «трансляция» весьма ограничена, а вопрос «мусорной» загрузки каналов с невысокой пропускной способностью встал ещё при первых опытах. Иногда самая простая идея — самая эффективная. Поэтому решение, которое просится первым, и было выбрано в итоге, став своего рода фирменной особенностью стека TCP/IP. А именно:
«Если пакет по каким-то причинам не может быть добавлен или доставлен, его следует просто отбросить»
Теперь, понимая все эти особенности, начнём учитывать источники создания проблем для пользовательского трафика.
При создании запроса на соединение от CE1 к CE2 на рисунке 1 имеются следующие потенциальные точки отказа:
-
нет маршрута от CE1 к CE2,
-
не хватает места в очереди на отправку данных к PE1,
-
нет свободной ёмкости в канале между CE1 и PE1,
-
не хватает места в очередях на приём в PE или P,
-
пакет принят с ошибкой на приёме,
-
нет маршрута к CE2 на PE или P,
-
не хватает места в очереди на отправку от PE или P,
-
нет свободной ёмкости в канале от PE или P,
-
не хватает места в очередях на приём в CE2,
-
пакет принят с ошибкой на приёме,
-
нет процесса, который отвечает на CE2 за выбранный на CE1 сервис.
Видно, что точки a, b, d, f, g, i , k сразу ведёт к событию «потеря пакета».
Точки c и h так же опосредованно ведут к тому же. При этом, заметим, не каждая среда передачи умеет заранее это сообщать.
А в точках e и j формируются события ошибок на канале. В современных условиях это достаточно большая редкость ввиду применения нужных технологий на физическом уровне, однако, всё-таки встречается. События ошибок также ведут к потере.
С учётом того, что со времён создания сетей TCP/IP по нынешнее время, основным устройством пропуска трафика является маршрутизатор, имеющий предком компьютер общего назначения с многозадачной операционной системой, перегрузка любой точки c рисунка 1 ввиду нехватки ресурсов процессора или памяти для обработки трафика не только возможна, но и достаточно часто встречается в реальной жизни. Не забудем, что проектирование сетей TCP/IP и миграция между поколениями оборудования всё ещё далеки от индустриального пути, и по большей части служба эксплуатации остаётся один на один с одним из производителей, который часто и сам слабо представляет себе, сколько именно пользовательского трафика нужного вида может пропустить NoName XX-1029-VV в реальных условиях, а не в лаборатории. Это также источник потерь.
Резюмируя вышенаписанное и памятуя, что основной читатель — служба эксплуатации, мы можем распределить отказы на сетях TCP/IP по важности следующим образом:
-
Наиболее часто возникают отказы ввиду отсутствия транзитной ёмкости.
-
Отказы из-за ошибок на каналах и отказы оборудования, связанные с производительностью, можно рассматривать вместе.
-
Обе данные причины ведут в первую очередь к потерям пакетов.
cc: lj, telegraph, vk, telegram: 1,2,3,4,5,6,7, zen, AT, MMM
Далее...
|
