По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Bellman-Ford - один из наиболее простых для понимания протоколов, поскольку он обычно реализуется путем сравнения недавно полученной информации о пункте назначения с существующей информацией о том же пункте назначения. Если вновь обнаруженный маршрут лучше, чем известный в настоящее время, маршрут с более высокой стоимостью просто заменяется в списке путей - в соответствии с правилом кратчайшего пути для поиска путей без петель в сети. Таким образом, перебирая всю топологию, можно найти набор кратчайших путей к каждому месту назначения. Рисунок 7 используется для иллюстрации этого процесса.
Примечание. Хотя Bellman-Ford в основном известен своим распределенным вариантом, реализованным в широко распространенных протоколах, таких как Routing Information Protocol (RIP), он изначально был разработан как алгоритм поиска, выполняемый в единой структуре, описывающей топологию узлов и ребер. Беллман-Форд рассматривается здесь как алгоритм.
Алгоритм Bellman-Ford
Bellman-Ford рассчитывает Shortest Path Tree к каждому достижимому пункту назначения в наихудшем случае O (V * E), где V - количество узлов (вершин) в сети, а E - количество каналов (ребер). По сути, это означает, что время, необходимое Bellman-Ford для работы с топологией и вычисления Shortest Path Tree, линейно зависит от количества устройств и каналов. Удвоение количества любого из них удвоит время, необходимое для выполнения. Удвоение обеих одновременно увеличит время работы в 4 раза.
Таким образом, алгоритм Bellman-Ford является умеренно медленным при использовании против более крупных топологий, когда узлы в таблице топологии начинаются в порядке от самого дальнего от корня до ближайшего к корню. Если таблица топологии отсортирована от ближайшего к корню до самого дальнего, Bellman-Ford может завершить работу за O(E), что намного быстрее. В реальном мире трудно обеспечить любой порядок, поэтому фактическое время, необходимое для построения Shortest Path Tree, обычно находится где-то между O(V * E) и O(E).
Bellman-Ford - это greedy алгоритм, предполагающий, что каждый узел в сети, кроме локального, доступен только по бесконечным стоимостям, и заменяющий эти бесконечные стоимости фактическими стоимостями по мере прохождения топологии. Предположение, что все узлы бесконечно удалены, называется ослаблением вычислений, так как он использует приблизительное расстояние для всех неизвестных пунктов назначения в сети, заменяя их реальной стоимостью после ее расчета.
Фактическое время выполнения любого алгоритма, используемого для расчета Shortest Path Tree, обычно ограничивается количеством времени, требуемым для передачи информации об изменениях топологии по сети. Реализации всех этих протоколов, особенно в их распределенной форме, будут содержать ряд оптимизаций, чтобы сократить время их выполнения до уровня, намного меньшего, чем наихудший случай, поэтому, хотя наихудший случай дается в качестве контрольной точки, он часто имеет мало влияющие на производительность каждого алгоритма в реальных развернутых сетях.
Чтобы запустить алгоритм Bellman-Ford в этой топологии, ее необходимо сначала преобразовать в набор векторов и расстояний и сохранить в структуре данных, такой как показано в Таблице 1.
В этой таблице девять записей, потому что в сети девять звеньев (граней). Алгоритмы кратчайшего пути вычисляют однонаправленное дерево (в одном направлении вдоль графа). В сети на рисунке 7 показано, что SPT берет начало в узле 1, а расчет показан удаленным от узла 1, который будет точкой, из которой будут выполняться вычисления. Алгоритм в псевдокоде следующий:
// создаем набор для хранения ответа, по одной записи для каждого узла
// первый слот в результирующей структуре будет представлять узел 1,
// второй узел 2 и т. д.
define route[nodes] {
predecessor // как узел
cost // как целое число
}
// установите для источника (меня) значение 0
// позиция 1 в массиве - это запись исходной точки.
route[1].predecessor = NULL
route[1].cost = 0
// таблица 1, приведенная выше, содержится в массиве под именем topo
// Обходим таблицу вершин (граней) один раз для каждой записи в маршруте
// (результаты) таблица, замены более длинных записей на более короткие
i = nodes
while i > 0 {
j = 1
while j <= nodes { // перебирает каждую строку в топологии
table
source_router = topo[j].s
destination_router = topo[j].d
link_cost = topo[j].cost
if route[source_router].cost == NULL {
source_router_cost = INFINITY
} else {
source_router_cost = route[source_router].cost
}
if route[destination_router].cost == NULL {
destination_router_cost = INFINITY
} else {
destination_router_cost = route[destination_router].cost
}
if source_router_cost + link_cost <= destination_router_cost {
route[destination_router].cost = source_router_cost + link_
cost
route[destination_router].predecessor = source_router
}
j = j + 1 //or j++ depending on what pseudocode this is
representing
}
i = i - 1
}
Этот код обманчиво выглядит сложнее, чем есть на самом деле. Ключевой строкой является сравнение if route [topo [j] .s] .cost + topo [j] .cost route [topo [j] .d] .cost. Полезно сосредоточиться на этой строке в примере. При первом прохождении внешнего цикла (который выполняется один раз для каждой записи в таблице результатов, здесь называется маршрутом):
Для первой строки topo-таблицы:
j равно 1, поэтому topo[j] .s - это узел 6 (F), источник вектора в таблице граней
j равно 1, поэтому topo[j] .d - это узел 7 (G), адресат вектора в таблице граней.
route[6].cost = infinity, topo[1].cost = 1, and route[7].cost = infinity (где infinity - бесконечность)
infinity + 1 == infinity, поэтому условие не выполняется и больше ничего не происходит
Любая запись в topo-таблице с исходной стоимостью infinity даст тот же результат, что и infinity + все, что всегда будет равно infinity. Остальные строки, содержащие источник со стоимостью infinity, будут пропущены.
Для восьмой строки topo-таблицы (восьмая грань):
j равно 8, поэтому topo[j].s - это узел 1 (A), источник вектора в таблице граней
j равно 8, поэтому topo[j].d - это узел 2 (B), место назначения вектора в таблице граней.
route [1].cost = 0, topo[8].cost=2 и route[2].cost = infinity.
0 + 2 = infinity, поэтому условие выполняется
route[2].predecessor установлен на 1, а route [2].cost установлен на 2
Для девятой строки topo -таблицы (девятая грань):
j равно 9, поэтому topo[j].s - это узел 1 (A), источник вектора в таблице граней
j равно 9, поэтому topo[j].d - это узел 3 (C), место назначения вектора в таблице граней.
route[1].cost=0, topo[9].cost=1 и route[3].cost = infinity.
0 + 1 = infinity, поэтому условие выполняется
route[3].predecessor установлен на 1, а route[3].cost установлен на 1
Во втором прогоне внешнего цикла:
Для пятой строки topo-таблицы (пятая грань):
j равно 5, поэтому topo[j].s - это узел 2 (B), источник вектора в таблице граней
j равно 5, поэтому topo[j].d - это узел 6 (F), место назначения вектора в таблице граней.
route[2].cost=2,topo[5].cost=1 и route[6].cost = infinity.
2 + 1 = infinity, поэтому условие выполняется
route[6].predecessor установлен на 2, а route[6].cost установлен на 3
Для шестой строки topo -таблицы (шестая грань):
j равно 6, поэтому topo[j].s равно 2 (B), источник вектора в таблице граней
j равно 6, поэтому topo[j].d равно 5 (E), место назначения вектора в таблице граней
route[2].cost=2, topo[6].cost=2 и route[5].cost = infinity.
2 + 2 = infinity, поэтому условие выполняется
route[5].predecessor установлен на 2, а route[5].cost установлен на 4
Окончание этого прогона показан в Таблице 2.
В третьем прогоне внешнего цикла узел 8 представляет особый интерес, поскольку есть два пути к этому месту назначения. Для второй строки topo -таблицы (вторая грань):
j равно 2, поэтому topo[j].s - это узел 5 (E), источник вектора в таблице граней
j равно 2, поэтому topo[j].d - это узел 8 (H), место назначения вектора в таблице граней
route[5].cost=4, topo[2].cost=1 и route[8].cost = infinity.
4 + 1 = infinity, поэтому условие выполняется
route[8].predecessor установлен на 5, а route[8].cost установлен на 5
Для третьей строки topo -таблицы (третья грань):
j равно 3, поэтому topo[j].s - это узел 4 (D), источник вектора в в таблице граней
j равно 3, поэтому topo[j].d - это узел 8 (H), источник вектора в таблице граней
route[4].cost=2,topo[3].cost=2 и route[8].cost = 5.
2 + 2 = 4, поэтому условие выполняется
route[8].predecessor установлен на 4, а route[8].cost установлен на 4
Интересным моментом в третьем цикле в topo-таблице является то, что запись для грани [5,8] обрабатывается первой, которая устанавливает передатчик 8 (H) на 5 и стоимость на 5. Однако когда обрабатывается следующая строка в таблице topo [4,8], алгоритм обнаруживает более короткий путь к узлу 8 и заменяет существующий. Таблица 2 показывает состояние таблицы маршрутов при каждом проходе через таблицу topo.
В таблице 2 верхняя строка представляет запись в таблице маршрутизации и узел, доступный в сети. Например, A (1) представляет лучший путь к A, B (2) представляет лучший путь к B и т. д. Столбец P представляет предшественника или узел, через который A должен пройти, чтобы достичь указанного пункта назначения. C представляет собой стоимость достижения этого пункта назначения. Рассмотренный пример сети может быть завершен за три цикла, если алгоритм настроен так, чтобы обнаруживать завершение дерева. Псевдокод, как показано, не имеет никакого теста для этого завершения и в любом случае будет выполнять полные 8 циклов (по одному для каждого узла).
Теперь почитайте про алгоритм диффузного обновления DUAL.
Почитать лекцию №19 про Connection-oriented protocols и Connectionless протоколы можно тут.
Протоколы передачи данных часто бывают многоуровневыми, причем нижние уровни предоставляют услуги по одному переходу, средний набор уровней предоставляет услуги от конца до конца между двумя устройствами и, возможно, набор уровней предоставляет услуги от конца до конца между двумя приложениями или двумя экземплярами одного приложения. Рисунок 1 иллюстрирует это.
Каждый набор протоколов показан как пара протоколов, потому что, как показано в модели рекурсивной архитектуры Интернета (RINA), рассмотренной в предыдущих лекциях, транспортные протоколы обычно входят в пары, причем каждый протокол в паре выполняет определенные функции. В этой серии лекций будут рассмотрены физические протоколы и протоколы передачи данных, как показано на рисунке 1. В частности, в этой лекции будут рассмотрены два широко используемых протокола для передачи данных "точка-точка" в сетях: Ethernet и WiFi (802.11).
Ethernet
Многие из ранних механизмов, разработанных для того, чтобы позволить нескольким компьютерам совместно использовать один провод, были основаны на проектах, заимствованных из более ориентированных на телефонные технологии. Как правило, они фокусировались на передаче токенов и других более детерминированных схемах для обеспечения того, чтобы два устройства не пытались использовать одну общую электрическую среду одновременно. Ethernet, изобретенный в начале 1970-х Bob Metcalf (который в то время работал в Xerox), разрешал перекрывающиеся разговоры другим способом-с помощью очень простого набора правил для предотвращения большинства перекрывающихся передач, а затем разрешал любые перекрывающиеся передачи путем обнаружения и обратного отсчета.
Первоначальное внимание любого протокола, который взаимодействует с физической средой, будет сосредоточено на мультиплексировании, поскольку до решения этой первой проблемы можно решить лишь несколько других проблем. Поэтому эта лекция будет начинаться с описания мультиплексирующих компонентов Ethernet, а затем рассмотрены другие аспекты работы.
Мультиплексирование
Чтобы понять проблему мультиплексирования, с которой столкнулся Ethernet, когда он был впервые изобретен, рассмотрим следующую проблему: в сети с общим носителем вся общая среда представляет собой единую электрическую цепь (или провод).
Когда один хост передает пакет, каждый другой хост в сети получает сигнал. Это очень похоже на беседу, проводимую на открытом воздухе- звук, передаваемый через общую среду (воздух), слышен каждому слушателю. Нет никакого физического способа ограничить набор слушателей во время процесса передачи.
CSMA/CD
В результате система, получившая название множественного доступа с контролем несущей и обнаружением коллизий (CSMA/CD), работает с использованием набора шагов:
Хост слушает среду, чтобы увидеть, есть ли какие-либо существующие передачи; это часть процесса со стороны оператора связи.
Узнав, что другой передачи нет, хост начнет сериализацию (передача битов сериями) битов кадра в сеть.
Эта часть проста - просто слушать перед передачей. Конечно, передачи двух (или более) хостов могут конфликтовать, как показано на рисунке 2. На рисунке 2:
В момент времени 1 (T1) A начинает передачу кадра на совместно используемый носитель. Для прохождения сигнала от одного конца провода к другому требуется некоторое время - это называется задержкой распространения.
В момент времени 2 (T2) C прослушивает сигнал на проводе и, не обнаружив его, начинает передачу кадра на совместно используемый носитель. В этот момент уже произошла коллизия, поскольку оба A и C передают кадр в один и тот же момент, но ни один из них еще не обнаружил коллизию.
В момент времени 3 (T3) два сигнала фактически сталкиваются в проводе, в результате чего они оба деформируются и, следовательно, не читаются.
Столкновение можно обнаружить в точке А в тот момент, когда сигнал от С достигает точки А, прослушав свой собственный сигнал, передаваемый по проводу. Когда сигнал от С достигнет А, А получит искаженный сигнал, вызванный комбинацией этих двух сигналов (результат столкновения). Это часть обнаружением столкновений (участок СD) работы локальные сети CSMA/CD.
Что должен сделать хост при обнаружении столкновения? В оригинальном конструкции Ethernet хост будет посылать сигнал блокировки достаточно долго, чтобы заставить любой другой хост, подключенный к проводу, обнаружить конфликт и прекратить передачу. Длина сигнала блокировки изначально была установлена таким образом, чтобы сигнал блокировки потреблял, по крайней мере, время, необходимое для передачи кадра максимального размера по проводу по всей длине провода. Почему именно столько времени?
Если при определении времени передачи сигнала помехи использовался более короткий, чем максимальный кадр, то хост со старыми интерфейсами (которые не могут посылать и принимать одновременно) может фактически пропустить весь сигнал помехи при передаче одного большого кадра, что делает сигнал помехи неэффективным.
Важно дать хозяевам, подключенным на самом конце проводов, достаточно времени, чтобы получить сигнал помехи, чтобы они почувствовали столкновение и предприняли следующие шаги.
Как только сигнал помехи получен, каждый хост, подключенный к проводу, установит таймер обратного отсчета, так что каждый из них будет ждать некоторое случайное количество времени, прежде чем пытаться передать снова. Поскольку эти таймеры установлены на случайное число, когда два хоста с кадрами, ожидающими передачи, пытаются выполнить свою следующую передачу, столкновение не должно повториться.
Если каждый хост, подключенный к одному проводу, получает один и тот же сигнал примерно в одно и то же время (учитывая задержку распространения по проводу), как любой конкретный хост может знать, должен ли он на самом деле получать определенный кадр (или, скорее, копировать информацию внутри кадра из провода в локальную память)? Это работа Media Access Control (MAC).
Каждому физическому интерфейсу назначается (как минимум) один MAC-адрес. Каждый кадр Ethernet содержит MAC-адрес источника и назначения; кадр форматируется таким образом, что MAC-адрес назначения принимается раньше любых данных. После того, как весь MAC-адрес назначения получен, хост может решить, следует ли ему продолжать прием пакета или нет. Если адрес назначения совпадает с адресом интерфейса, хост продолжает копировать информацию с провода в память. Если адрес назначения не совпадает с адресом локального интерфейса, хост просто прекращает прием пакета.
А как насчет дубликатов MAC-адресов? Если несколько хостов, подключенных к одному и тому же носителю, имеют один и тот же физический адрес, каждый из них будет получать и потенциально обрабатывать одни и те же кадры. Существуют способы обнаружения повторяющихся MAC-адресов, но они реализуются как часть межслойного обнаружения, а не самого Ethernet;
MAC-адреса будут правильно назначены системным администратором, если они назначены вручную.
MAC-адреса назначаются производителем устройства, поэтому дублирование MAC-адресов исключено, независимо от того, сколько хостов подключено друг к другу.
(Поскольку MAC-адреса обычно перезаписываются на каждом маршрутизаторе, они должны быть уникальными только в сегменте или широковещательном домене. В то время как многие старые системы стремились обеспечить уникальность каждого сегмента или широковещательного домена, это обычно должно быть обеспечено с помощью ручной конфигурации, и поэтому в значительной степени было отказано в пользу попытки предоставить каждому устройству глобальный уникальный MAC-адрес, "вшитый" в чипсете Ethernet при создании.)
Первое решение трудно реализовать в большинстве крупномасштабных сетей- ручная настройка MAC-адресов крайне редка в реальном мире вплоть до ее отсутствия. Второй вариант, по существу, означает, что MAC-адреса должны быть назначены отдельным устройствам, чтобы ни одно из двух устройств в мире не имело одного и того же MAC-адреса. Как такое возможно? Путем назначения MAC-адресов из центрального хранилища, управляемого через организацию стандартов. Рисунок 3 иллюстрирует это.
Рис. 3 Формат адреса MAC-48/EUI-48
MAC-адрес разбит на две части: уникальный идентификатор организации (OUI) и идентификатор сетевого интерфейса. Идентификатор сетевомого интерфейса присваивается заводом-изготовителем микросхем для Ethernet. Компаниям, производящим чипсеты Ethernet, в свою очередь, присваиваются уникальный идентификатор организации Институтом инженеров электротехники и электроники (Institute of Electrical and Electronic Engineers -IEEE). До тех пор, пока организация (или производитель) назначает адреса чипсету с его OUI в первых трех октетах MAC-адреса и не назначает никаким двум устройствам один и тот же идентификатор сетевого интерфейса в последних трех октетах MAC-адреса, никакие два MAC-адреса не должны быть одинаковыми для любого набора микросхем Ethernet.
Два бита в пространстве OUI выделяются, чтобы сигнализировать, был ли MAC-адрес назначен локально (что означает, что назначенный производителем MAC-адрес был переопределен конфигурацией устройства), и предназначен ли MAC-адрес в качестве одного из следующих:
Unicast адрес, означает, что он описывает один интерфейс
Multicast-адрес, означает, что он описывает группу получателей
MAC-адрес состоит из 48 бит- при удалении двух битов пространство MAC-адресов составляет 46 бит, что означает, что оно может описывать 246-или 70,368,744,177,664- адресуемых интерфейсов. Поскольку этого (потенциально) недостаточно, чтобы учесть быстрое количество новых адресуемых устройств, таких как Bluetooth-гарнитуры и датчики, длина MAC-адреса была увеличена до 64 бит для создания MAC-адреса EUI-64, который построен таким же образом, как и более короткий 48-битный MAC-адрес. Эти адреса могут поддерживать 262-или 4,611,686,018,427,387,904-адресуемые интерфейсы.
Конец эпохи CSMA / CD
Модель развертывания Ethernet с разделяемой средой в значительной степени (хотя и не полностью!) заменена в большинстве сетей. Вместо общей среды большинство развертываний Ethernet теперь коммутируются, что означает, что одна электрическая цепь или один провод разбивается на несколько цепей путем подключения каждого устройства к порту на коммутаторе. Рисунок 4 демонстрирует это.
На рисунке 4 каждое устройство подключено к разному набору проводов, каждый из которых оканчивается одним коммутатором. Если сетевые интерфейсы на трех хостах (A, B и C) и сетевые интерфейсы коммутатора могут отправлять или получать в любой момент времени вместо того, чтобы делать и то, и другое, A может отправлять, пока коммутатор тоже отправляет. В этом случае процесс CSMA / CD все равно должен соблюдаться для предотвращения коллизий, даже в сетях, где только два передатчика подключены к одному проводу. Такой режим работы называется полудуплексом.
Однако, если наборы микросхем Ethernet могут одновременно прослушивать и передавать данные для обнаружения коллизий, эту ситуацию можно изменить. Самый простой способ справиться с этим - разместить сигналы приема и передачи на разных физических проводах в наборе проводов, используемых в кабеле Ethernet. Использование разных проводов означает, что передачи от двух подключенных систем не могут конфликтовать, поэтому набор микросхем может передавать и принимать одновременно. Чтобы включить этот режим работы, называемый полнодуплексным, витая пара Ethernet передает сигнал в одном направлении по одной паре проводов, а сигнал в противоположном направлении - по другому набору проводов. В этом случае CSMA / CD больше не нужен (коммутатор должен узнать, какое устройство (хост) подключено к каждому порту, чтобы эта схема работала).
Контроль ошибок
CSMA/CD предназначен для предотвращения одного вида обнаруживаемой ошибки в Ethernet: когда коллизии приводят к искажению кадра. Однако в сигнал могут входить и другие виды ошибок, как и в любой другой электрической или оптической системе. Например, в кабельной системе с витой парой, если скрученные провода слишком сильно "разматываются" при установке коннектора, один провод может передавать свой сигнал другому проводу через магнитные поля, вызывая перекрестные помехи. Когда сигнал проходит по проводу, он может достигать другого конца провода и отражаться обратно по всей длине провода.
Как Ethernet контролирует эти ошибки? Оригинальный стандарт Ethernet включал в себя 32-битную циклическую проверку избыточности (Cyclic Redundancy Check-CRC) в каждом кадре, которая позволяет обнаруживать большой массив ошибок при передаче. Однако на более высоких скоростях и на оптических (а не электрических) транспортных механизмах CRC не обнаруживает достаточно ошибок, чтобы повлиять на работу протокола. Чтобы обеспечить лучший контроль ошибок, более поздние (и более быстрые) стандарты Ethernet включили более надежные механизмы контроля ошибок.
Например, Gigabit Ethernet определяет схему кодирования 8B10B, предназначенную для обеспечения правильной синхронизации часов отправителя и получателя; эта схема также обнаруживает некоторые битовые ошибки. Ten-Gigabit Ethernet часто реализуется аппаратно с помощью Reed-Solomon code Error Correction (EC) и системы кодирования 16B18B, которая обеспечивает прямое исправление ошибок (FEC) и синхронизацию часов с 18% -ными издержками.
Схема кодирования 8B10B пытается обеспечить наличие примерно одинакового количества битов 0 и 1 в потоке данных, что позволяет эффективно использовать лазер и обеспечивает встроенную в сигнал тактовую синхронизацию. Схема работает путем кодирования 8 бит данных (8B) в 10 передаваемых битов по проводу (10B), что означает около 25% накладных расходов на каждый передаваемый символ. Ошибки четности одного бита могут быть обнаружены и исправлены, потому что приемник знает, сколько "0" и "1" должно быть получено.
Маршалинг данных
Ethernet передает данные пакетами и кадрами: пакет состоит из преамбулы, кадра и любой конечной информации. Фрейм содержит заголовок, который состоит из полей фиксированной длины и переносимых данных. На рисунке 5 показан пакет Ethernet.
На рисунке 5 преамбула содержит маркер начала кадра, информацию, которую приемник может использовать для синхронизации своих часов для синхронизации с входящим пакетом, и другую информацию. Адрес назначения записывается сразу после преамбулы, поэтому получатель может быстро решить, копировать этот пакет в память или нет. Адреса, тип протокола и передаваемые данные являются частью кадра. Наконец, любая информация FEC и другие трейлеры добавляются в кадр, чтобы составить последний раздел (ы) пакета.
Поле type представляет особый интерес, поскольку оно предоставляет информацию для следующего уровня-протокола, предоставляющего информацию, переносимую в поле data - для идентификации протокола. Эта информация непрозрачна для Ethernet-чипсет Ethernet не знает, как интерпретировать эту информацию (только где она находится) и как ее переносить. Без этого поля не было бы последовательного способа для передачи переносимых данных в правильный протокол верхнего уровня, или, скорее, для правильного мультиплексирования нескольких протоколов верхнего уровня в кадры Ethernet, а затем правильного демультиплексирования.
Управление потоком
В исходной CSMA / CD реализации Ethernet сама совместно используемая среда предоставляла своего рода базовый механизм управления потоком. Предполагая, что никакие два хоста не могут передавать одновременно, и информация, передаваемая по какому-то протоколу верхнего уровня, должна быть подтверждена или отвечена, по крайней мере, время от времени, передатчик должен периодически делать перерыв, чтобы получить любое подтверждение или ответ. Иногда возникают ситуации, когда эта довольно грубая форма регулирования потока не работает- спецификация Ethernet предполагает, что некоторый протокол более высокого уровня будет контролировать поток информации, чтобы предотвратить сбои в этом случае.
В коммутируемом полнодуплексном Ethernet нет CSMA/CD, так как нет общей среды. Два хоста, подключенные к паре каналов передачи, могут отправлять данные так быстро, как позволяют каналы связи. Фактически это может привести к ситуации, когда хост получает больше данных, чем может обработать. Чтобы решить эту проблему, для Ethernet был разработан фрейм паузы. Когда получатель отправляет фрейм паузы, отправитель должен прекратить отправку трафика в течение определенного периода времени.
Фреймы паузы массово не применяются.
Важно
Многие протоколы не содержат все четыре функции, описанных как часть модели рекурсивной архитектуры Интернета (RINA): контроль ошибок, управление потоком, транспортировка и мультиплексирование. Даже среди тех протоколов, которые реализуют все четыре функции, все четыре не всегда используются. Обычно в этой ситуации разработчик протокола и/или сети передает функцию на более низкий или более высокий уровень в стеке. В некоторых случаях это работает, но вы всегда должны быть осторожны, предполагая, что это будет работать без ошибок. Например, существует разница между hop-by-hop шифрованием и end-to-end шифрованием. End-to-end передача хороша для приложений и протоколов, которые выполняют шифрование, но на самом деле не каждое приложение шифрует передаваемые данные. В этих случаях hop-by-hop шифрование может быть полезно для менее безопасных соединений, таких как беспроводные соединения.
Своевременное резервное копирование данных – это критически важная процедура для любой компьютерной системы, ведь именно от этого зависит, как скоро вы сможете восстановить её работоспособность, в случае внештатной ситуации или восстановить важные данные. Хорошо, когда этот процесс автоматизирован и администратору или инженеру не нужно проводить его вручную. Вместо этого система сама осуществляет резервное копирование по расписанию.
Как можно догадаться, речь в сегодняшней статье пойдёт о модуле, позволяющем проводить резервное копирование настроек и конфигурационных файлов IP-АТС Asterisk - Backup & Restore. Бэкапирование – это ключевой шаг процесса установки IP-АТС, есть несколько путей его автоматизации, а также имеется возможность проводить резервное копирование вручную, если это необходимо.
Рассмотрим возможности данного модуля и базовые параметры. Все примеры в данной статье будем приводить на FreePBX 13.
Итак, для того чтобы попасть в модуль Backup & Restore, с главной страницы, необходимо перейти по следующему пути Admin - > Backup & Restore. Перед вами откроется страница с текущими созданными бэкапами, а также бэкапами системы по умолчанию
В нашем случае, никаких бэкапов создано не было, поэтому меню отображает только бэкап по умолчанию. Если нажать на кнопку справа на скриншоте выше (выделена красным) , то перед вами откроются секции данного меню - Backups, Restore, Servers и Templates.
Секция Backups открывается сразу и показана на рисунке выше. В данной секции вы можете полностью определить работы по резервному копированию данных, их количество, частоту и объем информации, который должен быть скопирован.
Restore
Секция Restore позволяет указать место хранения файлов резервных копий и проводить восстановление системы. Можно указать как путь к файлу резервной копии на локальном компьютере, нажав кнопку Browse напротив опции Upload File или же, если файл хранится в другом месте, указать путь к FTP, SSH или локальному серверу, переместившись на вкладку Browse
Servers
В данной секции определяются серверы IP-АТС или таблицы баз данных, конфигурации которых должны быть подвергнуты процедуре резервного копирования. С помощью кнопки Add Server, можно добавить новый сервер на котором будет храниться бэкап
Templates
Данная секция предназначена для создания групп файлов, директорий или баз данных, которые необходимо включить в будущий бэкап. По умолчанию, уже доступны некоторые шаблоны, такие как бэкап только CDR записей, только конфигурационных файлов, полный бэкап системы и другие.
Вы можете создавать свои шаблоны при помощи кнопки New Template, необходимо будет только определить тип нового шаблона и заполнить соответствующие параметры. Для того чтобы сохранить новый шаблон, необходимо нажать Save.
При создании нового бэкапа можно будет включать в него данные шаблоны, это сильно упростит процедуру резервного копирования, поскольку не нужно будет определять параметры каждого бэкапа, все они уже будут в шаблонах.
Настройка бэкапа
Итак, переходим к настройке. Как показано на первом скриншоте, нажмите на кнопку Add Backup:
Пробежимся по настройкам:
Backup Name - дайте понятное имя процессу бэкапирования, что его можно было идентифицировать среди прочих процессов.
Description - описание бэкапа. Например, ежедневный, или еженедельный. Или бэкап CDR, или бэкап конфигурации.
Status Email - адрес электронной почты, на который необходимо отправлять информацию о выполнении данного процесса резервного копирования.
On Failure Only - отправлять письма только в случае, если процесс бэкапа завершился неудачно.
Далее, модуль предлагает нам выбрать сегменты нашей АТС, которые мы хотим копировать. В данном поле действует принцип drag and drop. Это означает, что вам достаточно просто мышкой перенести необходимые объекты справа, в поле Items. Если у вас небольшая компания, до 20 или 30 человек, рекомендуем делать Full Backup, который регламентирует полное резервное копирование IP – АТС Asterisk.
Hooks
Данный раздел позволяет подключать собственные скрипты в процесс выполнения бэкапа. Например, это может скрипт, который будет делать отметку о бэкапе в базе данных, или будет формировать особое письмо, или будет вносить данные в систему учета. Данный раздел позволяет определить, в какой момент резервного копирования или восстановления из копии подключать данные скрипты:
Pre-Backup Hook - в этом поле можно указать путь к скрипту, который необходимо запускать перед проведением резервного копирования.
Post-Backup Hook - путь к скрипту, который необходимо выполнить после процесса бэкапа
Pre-Restore Hook скрипт запускаемый перед началом процесса восстановления сервера из бэкапа.
Post-Restore Hook - запуск скрипта после проведения восстановления.
Backup Server - сервер, на котором необходимо произвести процесс бэкапирования Это может быть как сервер с вашей АТС (This server), либо это может быть любой другой сервер, который доступен по протоколу SSH. Данные сервера можно настроить в разделе Servers
Важно, чтобы исполняемые скрипты имели достаточно прав доступа. Так же, не забудьте сделать пользователем этих файлов юзера asterisk
Storage Location
В данном меню производится настройках хранилища для файлов резервного копирования. Вы можете настроить различные FTP, SSH, Email, MySQL и даже Amazon сервера для хранения там различных экземпляров копий (бэкапов). Чтобы выбрать сервер, перенесите его из правой части (Available Servers) в поле слева, которое называется Storage Servers
Расписание
В данной секции необходимо определить, с какой периодичностью мы желаем проводить бэкапы. Доступны следующие опции:
Never - не запускать данный скрипт.
Hourly - запускать ежечасно. Скрипт запускается с самого начала нового часа. Как пример, в 13:00:01.
Daily скрипт запускается ежедневно в полночь.
Weekly - запуск скрипта происходит еженедельно в воскресение в полночь.
Monthly - ежемесячно каждое первое число в полночь.
Annually - ежегодно каждое первое января в полночь.
Reboot - проводить бэкап при команду перезагрузки.
Custom - собственное расписание бэкапов, позволяет определить конкретное время проведения бэкапа. Настройка касается минут, часов, дней недели, месяцев или дней месяца
Удаление старых файлов
В данном разделе вы можете указать количество копий, которое необходимо хранить, а также, когда удалять старые файлы резервного копирования:
Delete After - укажите возраст файла, который необходимо будет удалить. Например, можно удалять файлы после 1 месяца хранения.
Delete After Runs -данное поле определяет количество копий, которое будет хранить сервер. Например, если вы укажите цифру 5, то после того, как сервер сделает 5 бэкапов, на 6 копирование будет удален самый старый файл. Тем самым, сервер будет поддерживать постоянное количество копий в размере 5, удаляя самый старый из них файл.
Настройка восстановления (Restore)
Перейдя во вкладку Restore, вам будут показаны все доступные резервные копии.
В навигации между директориями, выберите необходимые файлы. Они буду иметь расширение .tgz:
Выбрав необходимый файл, нажмите Go. Сразу после этого, вам будет предложено галочкой отметить какие сегменты бэкапа вы хотите восстановить (CDR, голосовую почту, конфигурацию и так далее). После выбора нажмите кнопку Restore и процесс будет запущен. Отметим, что процесс восстановления из локально файла абсолютно аналогичен. Просто необходимо нажать на копку Browse и выбрать необходимый файл.
Добавление сервера
В данной секции вы можете добавить новые сервер, на которые вам необходимо будет складывать резервные копии:
Email - отправлять резервную копию на электронную почту в качестве вложения.
FTP - отправлять бэкап – файлы на FTP сервер.
Local - сохранять файлы бэкапов локально на сервере.
MySQL Server - указать внешний MySQL сервер, на который Asterisk будет складывать копии базы данных.
SSH Server -это может быть любая другая АТС, с которой вы можете также делать резервные копии (бэкапы).
Шаблоны
Шаблоны (templates) показывает готовые к работе заранее созданные в системы процессы проведения бэкапов с тем, или иным сегментом IP – АТС. Чтобы создать новый шаблон, нажмите New Template:
Template Name - имя для шаблона.
Description - описание шаблона, которое поможет вам проще ориентироваться среди прочих настроек.
Чтобы добавить в бэкап файлы, папки или базы данных, нажмите на крестик (выделен красным на скриншоте выше). Откроется следующее меню:
Добавьте необходимые вам файлы. По окончанию настроек, нажмите кнопку Save