По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В 2013 году была опубликована версия OSPF для маршрутизации IPv6. Известный как OSPFv3, он был первоначально указан в RFC 2740, который позже был заменен на RFC 5340 и обновлен более поздними стандартами.
Маршаллинг данных в OSPF
Как и многие другие протоколы, разработанные на заре проектирования сетей, OSPF был разработан для минимизации вычислительной мощности, памяти и полосы пропускания, необходимых для передачи информации о маршрутизации IPv4 по сети. Два конкретных выбора, сделанных на ранних этапах процесса проектирования OSPF, отражают эту озабоченность по поводу использования ресурсов:
OSPF использует поля фиксированной длины для упорядочивания данных, а не TLV. Это экономит накладные расходы на перенос дополнительных метаданных в виде заголовков Type Length Value (TLV), снижает требования к обработке, позволяя сопоставлять структуры данных фиксированного размера в памяти с пакетами по мере их приема с канала связи, и уменьшает размер данных OSPF на линии.
OSPF разбивает базу данных топологии на несколько типов данных, а не полагается на один LSP с TLV. Это означает, что каждый вид информации - доступность, топология и т. д. - передается в уникальном формате пакета.
Каждый тип информации, которую OSPF может нести, переносится в разном типе Link State Advertisement (LSA). Вот некоторые из наиболее примечательных типов LSA:
Тип 1: код 0x2001, Router LSA
Тип 2: код 0x2002, Network LSA
Тип 3: код 0x2003, Inter-Area Prefix LSA
Тип 4: код 0x2004, Inter-Area Router LSA
Тип 5: код 0x4005, AS-external LSA
Тип 7: код 0x2007, Type-7 (NSSA) LSA
Существует ряд других типов LSA, включая непрозрачные данные, членство в группе многоадресной рассылки и LSA с лавинной рассылкой (например, для одного соседа, одного канала или одного домена лавинной рассылки).
Каждый маршрутизатор OSPF генерирует ровно один Router LSA (тип 1). Этот LSA описывает любых соседей, примыкающих к объявляемому маршрутизатору, а также любые подключенные достижимые пункты назначения. Состояние каналов связи на этих соседей и пунктов назначения определяется из объявления соседей и пункта назначения. Несмотря на фразу «состояние канала», каналы не объявляются как отдельная «вещь» (это часто вызывает путаницу). Если Router LSA становится слишком большим, чтобы поместиться в один IP-пакет (из-за MTU канала), он будет разделен на несколько IP-фрагментов для передачи от маршрутизатора к маршрутизатору. Каждый маршрутизатор повторно собирает весь Router LSA перед его локальной обработкой и лавинно рассылает весь Router LSA, если он изменяется.
OSPF также использует несколько разных типов пакетов - они не совпадают с типами LSA. Скорее, их можно рассматривать как разные «службы» в OSPF или, возможно, как разные «номера портов», выполняемые поверх протокола User Datagram Protocol (UDP) или протокола Transmission Control Protocol (TCP).
Hello - это тип 1. Они используются для обнаружения и сохранения соседей.
Database Descriptor (DBD) относится к типу 2. Они используются для описания таблицы локальной топологии.
Link State Request (LSR) относится к типу 3. Они используются для запроса определенных объявлений состояния канала от соседнего маршрутизатора.
Link State Update (LSU) относится к типу 4. Они используются для передачи объявлений состояния канала.
Link State Acknowledgment - это тип 5. Это просто список заголовков LSA. Любой LSA, указанный в этом пакете, подтверждается как полученный передающим маршрутизатором.
Обнаружение соседей и топологии
В качестве протокола состояния канала OSPF должен гарантировать, что каждый маршрутизатор в пределах области (flooding domain) имеет одну и ту же базу данных для расчета loop-free путей. Любое изменение в базе данных общей топологии может привести к возникновению зацикливания маршрутизации, который будет длиться до тех пор, пока существует изменение в базе данных общей топологии. Таким образом, одной из целей формирования соседей OSPF является обеспечение надежной flooding рассылки информации о топологии через сеть. Вторая причина формирования соседей OSPF - обнаружение топологии сети путем определения того, какие маршрутизаторы находятся рядом с локальным маршрутизатором. На рисунке 1 показан процесс формирования соседей OSPF.
На рисунке 1:
B отправляет пакет приветствия к A.
Поскольку приветствие B содержит пустой список видимых соседей, A переводит B в состояние инициализации и добавляет B в список видимых соседей.
A передает приветствие B в списке видимых соседей.
B получает приветствие от A и отправляет приветствие с A в списке видимых соседей.
A получает это приветствие. Поскольку сам A находится в списке соседей, A помещает B в двустороннее состояние. Это означает, что A проверил наличие двусторонней связи между собой и B.
Если по этой линии избираются DR и BDR, то выборы происходят после шага 5. Как только выборы завершены, DR и BDR переводятся в состояние exstart. Во время этого состояния ведущий и ведомый выбираются для обмена DBDS и LSA. По сути, мастер управляет потоком DBDS и LSA между новыми соседними маршрутизаторами. Соседние маршрутизаторы на канале point-to-point технически переходят непосредственно в состояние full state в этой точке.
B переведен в состояние обмена.
A отправляет B набор DBD с описанием своей базы данных. B отправляет набор DBD с описанием своей базы данных в A.
A отправляет запрос состояния канала B для каждого LSA, описанного B, и A не имеет его копии в своей локальной таблице топологии.
B отправляет LSA для каждого запроса Link State (LS) от A.
11. Как только базы данных синхронизируются, B переводится в full state.
Процесс формирования соседей OSPF проверяет MTU на обоих концах линии связи, передавая MTU исходящего интерфейса в hello сообщении. Если два hello-пакета не совпадают по размеру MTU, два маршрутизатора OSPF не образуют смежности.
Надежная лавинная рассылка.
OSPF должен не только гарантировать завершение первоначального обмена информацией о топологии, но также гарантировать, что текущие изменения в топологии сети будут переданы на каждый маршрутизатор во flooding domain. На рисунке 2 показан заголовок LSA OSPF. Изучение этого заголовка поможет нам понять, как OSPF надежно массово рассылает информацию о топологии и доступности через сеть.
На рисунке 2:
LS Age - это (примерно) количество секунд с момента создания Link State Advertisement. Это число идет увеличивается, а не уменьшается. Когда LS Age достигает значения MAXAGE (на любом маршрутизаторе, а не только на исходном маршрутизаторе), маршрутизатор увеличивает порядковый номер на 1, устанавливает для LS Age максимальное число и повторно загружает LSA по всей сети. Это позволяет удалить старую информацию о топологии и доступности, которая не обновлялась некоторое время. Маршрутизатор, который инициирует какой-либо конкретный LSA, обновит свои LSA за некоторое количество секунд до того, как это поле LSA Age достигнет максимума- это интервал обновления LS.
Link State Identifier - это уникальный идентификатор, присвоенный исходным маршрутизатором для описания этого LSA. Обычно это адрес канала или какой-либо адрес локального уровня канала (например, Ethernet Media Access Control (MAC-адрес).
Advertising Router - это идентификатор маршрутизатора-отправителя. Его часто путают с IP-адресом, поскольку он часто является производным от локально настроенного IP-адреса, но это не IP-адрес.
Link State Sequence Number указывает версию LSA. Как правило, более высокие числа означают более новые версии, хотя существуют более ранние версии OSPF, в которых используется круговое числовое пространство, а не абсолютно увеличивающееся. Реализации, которые используют абсолютно увеличивающееся числовое пространство, перезапускают процесс OSPF, если достигнут конец числового пространства.
Link State Checksum - это контрольная сумма, вычисляемая для LSA, используемая для обнаружения ошибок при передаче или хранении информации.
Рисунок 3 используется для изучения процесса flooding рассылки.
На рисунке 3:
Линия связи на 2001: db8: 3e8: 100 :: / 64 настроена, запущена, подключена и т. д.
A перестраивает свой Router LSA (тип 1), чтобы включить эту новую информацию о доступности, упаковывает его в LSU (который может быть фрагментирован при размещении в IP-пакеты) и лавинно рассылает его B.
B получает это LSA и подтверждает его получение подтверждением состояния канала (link state acknowledgment). A повторно отправит LSA, если B не подтвердит его достаточно быстро.
Теперь B проверит свою таблицу топологии, чтобы определить, является ли этот LSA новым или копией уже имеющегося. B определяет это в первую очередь путем изучения порядкового номера, включенного в сам LSA. Если это новый (или обновленный) LSA, B инициирует тот же процесс для лавинной рассылки измененного LSA в C.
Подведение итогов об OSPF
OSPF можно описать как:
Изучение доступных пунктов назначения через конфигурацию и локальную информацию (проактивный протокол)
Использование лавинной рассылки для синхронизации базы данных в каждой промежуточной системе в домене лавинной рассылки (протокол состояния канала)
Расчет путей без петель с использованием алгоритма SPF Дейкстры
Проверка двусторонней связи при формировании соседей путем переноса списка «видимых соседей» в своих пакетах приветствия.
Проверка MTU при формировании смежности путем переноса MTU в приветственном пакете
OSPF широко используется в малых и крупных сетях, включая розничную торговлю, поставщиков услуг, финансовые и многие другие предприятия.
Общие элементы OSPF и IS-IS
В предыдущих лекциях были рассмотрены аспекты, отличающие OSPF и IS-IS друг от друга. Однако есть ряд вещей, которые OSPF и IS-IS реализовали достаточно схожими способами, чтобы рассматривать их решения как простые варианты. К ним относятся обработка каналов с множественным доступом, концепция Shortest Path Tree и способ way two-way.
Каналы с множественным доступом
Каналы с множественным доступом, такие как Ethernet, - это каналы, по которым подключенные устройства «совместно используют» доступную полосу пропускания, и каждое устройство может отправлять пакеты напрямую любому другому устройству, подключенному к тому же каналу. Каналы с множественным доступом создают особые проблемы для протоколов, которые синхронизируют базу данных по каналу.
Рассмотрим рисунок 3 для понимания.
Один из вариантов, который протокол может использовать при работе по каналу с множественным доступом, - это просто сформировать смежности, как это обычно происходит по каналу «точка-точка» (point-to-point). Например, на рисунке 3:
A может образовывать смежность с B, C и D.
B может образовывать смежность с A, C и D.
C может образовывать смежность с A, B и D.
D может образовывать смежность с A, B и C
Если используется этот шаблон формирования смежности, когда A получает новый фрагмент LSP (IS-IS) или LSA (OSPF) от некоторого маршрутизатора, не подключенного к совместно используемому каналу:
A передаст новый фрагмент или LSA по отдельности B, C и D.
Когда B получает фрагмент или LSA, он передаст новый фрагмент или LSA в C и D отдельно.
Когда C получает фрагмент или LSA, он передает новый фрагмент или LSA D.
Учитывая передачу каждого фрагмента или LSA, а также следующий CSNP или подтверждение, чтобы гарантировать синхронизацию локальной базы данных на каждом маршрутизаторе, большое количество пакетов должно пересекать совместно используемый канал, чтобы гарантировать синхронизацию базы данных каждого устройства. Чтобы уменьшить переполнение каналов множественного доступа, IS-IS и OSPF выбирают одно устройство, которое отвечает за обеспечение того, чтобы каждое устройство, подключенное к каналу, имело синхронизированную базу данных. На рисунке 3 для IS-IS:
Одно устройство выбрано для управления лавинной рассылкой по каналу. В IS-IS это устройство называется выделенной промежуточной системой (Designated Intermediate System - DIS).
Каждое устройство с новой информацией о состоянии канала отправляет фрагмент на адрес многоадресной рассылки, чтобы каждое устройство в общем канале получило его. Ни одно из устройств, подключенных к каналу, не отправляет никаких подтверждений при получении обновленного фрагмента.
DIS регулярно отправляет копию своего CSNP на один и тот же адрес многоадресной рассылки, поэтому каждое устройство в канале множественного доступа получает его копию.
Если какое-либо устройство на общем канале обнаружит, что в нем отсутствует какой-то конкретный фрагмент, на основе описания базы данных DIS в CSNP, оно отправит PSNP в канал, запрашивая недостающую информацию.
Если какое-либо устройство в общем канале обнаружит, что у него есть информация, которой нет у DIS, на основе описания базы данных DIS в CSNP, оно перенаправит недостающий фрагмент в канал.
Таким образом, новая информация о состоянии канала передается по линии минимальное количество раз. На рисунке 3 для OSPF:
Для управления лавинной рассылкой по каналу выбирается одно устройство, называемое назначенным маршрутизатором (Designated Router - DR). Также выбирается резервное устройство, называемое резервным назначенным маршрутизатором (Backup Designated Router - BDR).
Каждое устройство с новой информацией о состоянии канала пересылает ее на специальный адрес многоадресной рассылки, контролируемый DR и BDR (маршрутизаторами, работающими только как DR).
DR получает этот LSA, проверяет его, чтобы определить, содержит ли он новую информацию, а затем повторно загружает его на многоадресный адрес, который прослушивают все маршрутизаторы OSPF на канале (все маршрутизаторы SPF).
Однако выбор DIS или DR не влияет только на лавинную передачу информации по каналу множественного доступа. Это также влияет на способ вычисления SPF через канал. Рисунок 4 показывает это.
На рисунке 4 A выбран в качестве DIS или DR для схемы множественного доступа. A не только гарантирует, что каждое устройство в канале имеет синхронизированную базу данных, но также создает псевдоузел или p-узел и объявляет его, как если бы это было реальное устройство, подключенное к сети. Каждый из маршрутизаторов, подключенных к совместно используемому каналу, объявляет о возможности подключения к p-узлу, а не к каждой из других подключенных систем.
В IS-IS A создает LSP для p-узла. Этот p-узел объявляет канал с нулевой стоимостью обратно каждому устройству, подключенному к каналу множественного доступа. В OSPF A создает Network LSA (тип 2).
Без этого p-узла сеть выглядит как full mesh (полная сетка) для других промежуточных систем в домене лавинной рассылки, как показано в левой части рисунка 4. С p-узлом сеть выглядит как hub-and-spoke с p-узлом в качестве концентратора. Каждое устройство объявляет канал на p-узел, при этом стоимость канала устанавливается равной стоимости локального интерфейса для совместно используемого канала. В свою очередь p-узел возвращает канал с нулевой стоимостью обратно на каждое устройство, подключенное к общему каналу. Это снижает сложность вычисления SPF для крупномасштабных каналов с множественным доступом.
Концептуализация связей, узлов и достижимости в протоколах состояний каналов
Один сбивающий с толку аспект протоколов состояния каналов - это то, как узлы, каналы и достижимость взаимодействуют друг с другом. Рассмотрим рисунок 5.
И в OSPF, и в IS-IS узлы и каналы используются как Shortest Path Tree, как показано более темными сплошными линиями. Пунктирные линии показывают, как информация о доступности прикрепляется к каждому узлу. Каждый узел, подключенный к конкретному достижимому пункту назначения, объявляет пункт назначения - не только один из двух узлов, подключенных к каналу точка-точка, но и оба. Почему так?
Основная причина в том, что это просто самое простое решение для объявления доступных мест назначения. Если вы хотите создать протокол маршрутизации, который объявлял бы каждое достижимое назначение только как подключенное к одному устройству, вам нужно было бы найти способ выбрать, какое из подключенных устройств должно объявлять достижимое назначение. Кроме того, если выбранное устройство выйдет из строя, то какое-то другое устройство должно взять на себя объявление достижимого пункта назначения, что может занять время и негативно повлиять на конвергенцию. Наконец, позволяя каждому устройству объявлять о доступности для всех подключенных пунктов назначения, вы фактически можете найти кратчайший путь к каждому пункту назначения.
Проверка двустороннего подключения в SPF
Двусторонняя связь является проблемой для плоскостей управления в двух разных местах: между соседними устройствами и при вычислении путей без петель через сеть. И IS-IS, и OSPF также обеспечивают двустороннюю связь при вычислении путей без петель.
Существенным элементом является проверка обратной связи.
Рисунок 6 используется для демонстрации этого.
На рисунке 6 направление каждого звена обозначено стрелкой (или набором стрелок). Связь [A,B] является однонаправленной по отношению к A. Остальные связи являются двусторонними (двунаправленными). При вычислении SPF D будет делать следующее:
При обработке информации о состоянии связи C обратите внимание, что C утверждает, что он подключен к B. D найдет информацию о состоянии связи B и проверит, чтобы убедиться, что B также утверждает, что он подключен к C. В этом случае B действительно утверждает, что подключен к C, поэтому D будет использовать канал [B, C].
При обработке информации о состоянии связи B обратите внимание, что B утверждает, что он подключен к A. Однако, изучая информацию о состоянии связи A, D не может найти никакой информации от A, утверждающего, что он подключен к B. Из-за этого D не будет использовать канал [A, B].
Эта проверка обычно выполняется либо до того, как линия связи будет перемещена в TENT, либо до того, как линия связи будет перемещена из TENT в PATH.
Третья статья будет посвящена поиску и устранению неисправностей EtherChannels. Большинство проблем с EtherChannels происходит из-за неправильной конфигурации.
Предыдущие статьи этого цикла:
Устранение неполадок коммутации Cisco
Траблшутинг STP (Spanning tree protocol)
Case #1
В этом сценарии есть только два коммутатора и два интерфейса. Идея состоит в том, чтобы сформировать etherchannel путем объединения интерфейсов FastEthernet 0/13 и 0/14, но это не работает
Сначала мы проверим, все ли интерфейсы работают. Да они все работают.
Мы можем проверить, что port-channel interface был создан, но он не работает.
Вот хорошая команда для проверки EtherChannel. Используйте суммарную информацию от команды show etherchannel summary, чтобы увидеть ваши port-channels. Мы видим, что коммутатор A настроен для LACP и коммутатор B для PAgP, а это никогда не будет работать.
Лучшая команда для использования это show etherchannel detail. Это дает вам много информации, но нам особенно интересно узнать, настроен ли LACP для пассивного или активного режима. Интерфейсы в активном режиме будут "активно" пытаться сформировать EtherChannel. Интерфейсы в пассивном режиме будут отвечать только на запросы LACP.
Вот вывод команды show etherchannel detail на коммутаторе B. Мы видим, что он был настроен для PAgP, и интерфейсы настроены для desirable режима. Если бы они были настроены на автоматический режим, мы бы увидели флаг А.
SwitchB(config)#no interface po1
SwitchB(config)#interface fa0/13
SwitchB(config-if)#channel-group 1 mode passive
SwitchB(config-if)#exit
SwitchB(config)#interface fa0/14
SwitchB(config-if)#channel-group 1 mode passive
Давайте сначала избавимся от port-channel interface. Если мы этого не сделаем, вы увидите ошибку при попытке изменить channel-group mode на интерфейсах.
После изменения конфигурации мы видим, что port-channel1 поднялся. Задача решена!
Извлеченный урок: убедитесь, что вы используете один и тот же режим EtherChannel с обеих сторон.
Case #2
Ну что же давайте рассмотрим другую ошибку! Та же топология и EtherChannel, который не функционирует:
Мы проверяем, что port-channel interface существует, но он не работает с обеих сторон.
Мы также видим, что интерфейс FastEthernet 0/13 и 0/14 были добавлены к port-channel interface.
Интерфейсы FastEthernet рабочие, поэтому мы знаем, что проблема не в этом. Давайте углубимся в конфигурацию EtherChannel.
Мы видим, что FastEthernet 0/13 и 0/14 на коммутаторе A оба настроены на автоматический режим PAgP (из-за флага "A").
FastEthernet 0/13 и 0/14 на коммутаторе B также настроены на автоматический режим PAgP. Это никогда не сбудет работать, потому что оба коммутатора теперь пассивно ждут сообщений PAgP.
SwitchB(config)#interface fa0/13
SwitchB(config-if)#channel-group 1 mode desirable
SwitchB(config-if)#interface fa0/14
SwitchB(config-if)#channel-group 1 mode desirable
Давайте изменим один из коммутаторов, чтобы он активно отправлял сообщения PAgP.
EtherChannel сейчас работает. Проблема решена!
Извлеченный урок: при использовании PAgP убедитесь, что хотя бы один из коммутаторов использует требуемый режим, или в случае LACP убедитесь, что один коммутатор находится в активном режиме.
Case #3
Еще одна ситуация: EtherChannel настроен между коммутатором A и коммутатором B, но клиент жалуется, что соединение медленное ... что может быть не так?
Быстрая проверка говорит нам, что port-channel interface работает.
Команда show etherchannel detail дает нам много выходных данных, но она так же нам говорит, что происходит. Вы видите, что интерфейс FastEthernet 0/13 и 0/14 были настроены для port-channel, но коммутатор не смог связать их, потому что FastEthernet 0/14 настроен на 10 Мбит. Возможно, что это основная причина медленной скорости передачи данных.
Мы будем использовать один из операторов для команды show. Нас интересует только то, чтобы увидеть вероятную причину, которую команда "show etherchannel detail" покажет.
SwitchA(config)#interface fa0/14
SwitchA(config-if)#speed auto
SwitchB(config)#interface fa0/14
SwitchB(config-if)#speed auto
Давайте изменим скорость на авто. Мы должны убедиться, что FastEthernet 0/13 и 0/14 имеют одинаковую конфигурацию.
Вероятно, вы увидите пару сообщений о том, что ваши интерфейсы переходят в состояние up и down.
Теперь мы видим, что оба интерфейса были добавлены в port-channel... проблема решена!
Извлеченный урок: убедитесь, что все интерфейсы, которые будут добавлены в port-channel, имеют одинаковую конфигурацию!
Рост статичных веб-сайтов является доказательством того, что старые вещи возвращаются раз за разом. Сегодня как малые, так и крупные предприятия используют статические веб-сайты и свои расширенные преимущества. Статические веб-сайты вернулись, сильнее, чем когда-либо.
Но в чем причина, которая стимулировала внезапный рост статических сайтов?
Ну, тенденции в веб-разработке приходят и уходят, но одно остается постоянным всегда - желание иметь высокоэффективный сайт. Кроме того, поведение конечных пользователей быстро меняется, поскольку они ожидают быстрой загрузки страницы и более привлекательного опыта без места для разочарования.
Чтобы удовлетворить этот спрос, веб-разработчики постоянно добавляют к веб-сайтам и приложениям больше функций. Но в процессе этого производительность веб-сайта оказывается под угрозой. Вот где статичные веб-сайты приходят на сцену!
Что такое статичный веб-сайт?
Существует распространенный миф, что статичные веб-сайты - это новая технология. На самом деле, статичные сайты – это самые первые сайты эпохи Интернета. Ранее для создания веб-сайта разработчики использовали чистый HTML, JavaScript и CSS без библиотек, плагинов или фреймворков.
Проще говоря, контент на статичном веб-сайте остается одинаковым после каждого посещения, в отличие от динамического, где он меняется. Сервер создает эти статичные файлы и возвращает их браузерам. Эти веб-сайты могут извлекать данные практически из любого места, включая API, CMS и другие файлы данных.
Такой веб-сайт отбрасывает ненужные сложности и в основном фокусируется на повышении эффективности и производительности. Она не опирается на базы данных; вместо этого он включает базовые HTML, JavaScript и CSS для создания невесомых бизнес-профилей и целевых страниц.
В результате это помогает избавиться от долгих загрузок и раздражающих задержек. Таким образом, разработчики могут создавать быстрые, надежные и эффективные приложения, предлагая пользователям хорошие впечатления от работы на вашем сайте с меньшим временем разработки.
Какие плюсы использования статичных веб-сайтов?
Скорость
Так как отсутствуют бэкэнд система, запросы клиент-сервер или запросы к базам данных, связанных с доставкой статического веб-сайта, такие сайты демонстрирует высочайшую производительность, поскольку его серверы всегда готовы к HTML-выводам. Кроме того, он может включать в себя функцию кэширования для устранения задержек.
Безопасность
Из-за отсутствия базы данных, а также подключаемых модулей и расширений статичные веб-сайты предлагают гораздо большую безопасность, чем динамический веб-сайт. Таким образом, вы избежите фишинговых кампаний, онлайн-отслеживаний, вредоносных программ или любой потери данных.
Расширяемость
Масштабирование статичных веб-сайтов относительно проще, в то время как сложные приложение более стабильны. Ввиду статичности файлов уменьшается нагрузка на серверы, а те легко справляются с обработкой огромного трафика.
Хостинг и доступность
Базовые HTML файлы требуют меньше места, что упрощает размещение этих веб-сайтов. Можно сократить расходы, направляя ресурсы на интеграцию автоматизированных сборок или Git для включения модификаций в систему.
Звучит круто? Если ответ утвердительный, давайте выясним лучшие платформы, где можно разместить статичный веб-сайт, чтобы начать использовать его преимущества.
1. Netlify
С помощью Netlify можно публиковать веб-проекты из репозиториев Git без сложных настроек и навыков обслуживания сервера. Поддерживается автоматизация процессов с помощью конвейера CI/CD для разработчиков веб-сайтов. Также есть возможность предварительного просмотра всего сайта, чтобы увидеть, как будет выглядеть веб-сайт, прежде чем публиковать его.
Развернув статичный веб-сайт в глобальной сети CDN с несколькими облаками – Edge, вы получите хорошую производительность. Netlify поддерживает множество сторонних приложений и инструментов, включая такие надстройки, как Analytics, Identity, Forms и база данных Fauna.
Netifly предоставляет удобные инструменты для автоматизации рабочих процессов, в том числе с помощью Atomic можно упростить развертывание новых сайтов, можно делать неограниченное количество снимков состояния и откатывать до них, можно назначать пользовательские заголовки, управлять DNS, перенаправлением и правилам прокси.
Netlify размещает веб-сайт в отказоустойчивой глобальной сети доставки приложений для непрерывного и быстрого обслуживания веб-страниц. Можно также управлять зонами DNS с помощью их панели мониторинга.
Автоматического HTTPS обеспечивает безопасность сайта, так как Netlify предлагает сертификат TLS бесплатно. Она обеспечивает расширенные функции, управляемые API, без сложных интеграций. Он предлагает шлюз API, управление доступом к данным на основе JWT, прокси-заголовки для аутентификации, сохраненные переменные и вебхуки.
Благодаря Netlify Analytics можно получить подробную информацию о посетителях веб-сайта, источниках, просмотрах страниц и т.д. Также можно использовать функции AWS Lambda, управлять подписями, восстановлением паролей, входами в систему и т. д. без развертывания службы аутентификации.
Управление отправками и формами без внедрения JavaScript или дополнительных кодов. Netlify Large Media позволяет управлять большими ресурсами и контролем версий файлов независимо от их размера.
2. Google Cloud Storage
Высокая безопасность и масштабируемость платформы Google Cloud расширяет возможности компаний любого размера, от индивидуальных разработчиков до крупных предприятий.
Возможность управления жизненным циклом объектов (Object Lifecycle Management OLM), которое можно использовать для настройки автоматического перехода всех данных на более недорогие хранилища. Можно легко устанавливать критерии для данных и управлять ими.
Google Cloud включает в себя растущий список глобальных центров обработки данных с достаточно большим количеством вариантов автоматического резервирования. Можно выбрать расположение и способ хранения данных, чтобы оптимизировать веб-сайт для быстрого реагирования и создать полный план аварийного восстановления.
С помощью класса хранения можно определить модель ценообразования, а также доступность, применимую к хранению данных. Вы можете выбрать из четырех возможных вариантов:
Стандарт
Nearline - один раз в месяц
Coldline - раз в квартал
Архивирование один раз в год
Google Cloud предлагает управление версиями объектов, которое позволяет хранить копии объектов в случае их перезаписи или удаления. Можно определить периоды хранения данных перед безвозвратным удалением. Можно даже прикрепить объект, чтобы предотвратить его удаление.
Шифрование и хранение объектных данных с помощью ключей шифрования, хранящихся в службе управления облачными ключами. Можно отключить ACL объектов для равномерного управления доступом к ресурсам в Google Cloud. Функция Bucket Lock включена для настройки политик хранения данных.
Отправка уведомлений при создании, удалении или обновлении объектов. Ведение журналов доступа к данным и активности, и управление разрешениями доступа с помощью облачного управления удостоверениями и доступом (IAM). Google Cloud предлагает интегрированные репозитории для машинного обучения и аналитики.
Альтернативы облачным хранилищам Google:
Amazon S3
Amazon S3 включает прямые функции управления, чтобы позволить Вам организовать и настроить данные. Он предназначен для обеспечения высокой долговечности и хранения данных для огромного числа приложений.
Amazon S3 может создать копии объекта, предлагает доступные тарифы для мест хранения, обладает возможностями аудита и утверждает, что соблюдает строгие меры безопасности как собственные в виде S3 Block Public Access, так и известные стандарты соответствия PCI-DSS, HITECH/HIPAA, FISMA, и т.д.
Vultr
Vultr поддерживает гибкую интеграцию через S3 API и предоставляет масштабируемому по требованию архитектуру, на которую вы можете полагаться. Она использует кэширование NVMe для обеспечения сверхпроизводительности и постоянной доступности данных.
Можно также хранить статические данные мультимедиа, такие как изображения, видео и аудио.
3. Surge
Surge предоставляет разработчику простой путь для развертывания проектов на высококачественном CDN через Grunt, NPM и Gulp.
С каждым проектом можно использовать поддержку настраиваемого домена, поддержку pushState, бесплатную сертификацию SSL для доменов Surge, пользовательские страницы ошибок 404, развертывание CLI без ограничений, интеграцию с цепью инструментов Grunt и перекрестную поддержку ресурсов.
Surge интегрируется с инструментом сборки, который используется для упрощения развертывания. Такие инструменты включают плагин Grunt, плагин Gulp, скрипт npm, хуки Git, Jekyll, Node.js, статические генераторы сайтов, службы CI и другие инструменты автоматического развертывания.
Пригласите своих коллег и сотрудников. Все, что вам нужно для публикации содержимого на вашем веб-сайте – это ввести одну команду.
4. Render
Легко разворачивайте статичный сайт в Render. Просто привяжите GitLab или репозиторий GitHub, и пусть он создаст ваш веб-сайт и обслуживает его на глобальном CDN. Лучше всего то, что статичные сайты с трафиком до 100 ГБ в месяц на Render можно размещать совершенно бесплатно.
После превышения данного лимита за каждый гигабайт придется платить $0,10 в месяц. Render предлагает автоматическое и непрерывное развертывание и превентивное аннулирование кэша. Можно бесплатно присоединять к проекту сотрудников, чтобы получить их помощь в управлении сайтом.
Render предлагает функцию Pull Request Preview, которая позволяет автоматически тестировать и просматривать введенные изменения перед публикацией. Хостинг предоставляет подробные графики пропускной способности, встроенную поддержку HTTP/2 для повышения скорости загрузки страниц, возможности перезаписи и перенаправления, поэтому для повышения производительности и безопасности не требуется писать дополнительный код и пользовательские заголовки HTTP.
Для повышения производительности Render предлагает автоматическое сжатие Brotli, которое уменьшает размеры страниц и ускоряет работу сайтов.
Render также включает автоматические перенаправления с HTTP на HTTPS, а также неограниченное количество пользовательских доменов. Помимо поддержки простых HTML/JavaScript/CSS сайтов, он предлагает мощные генераторы сайтов, такие как Create React Application, Jekyll, Vue.js, Gatsby, Hugo, Next.js и Docusaurus.
Его глобальная сеть CDN невероятно быстрая, безопасная и надежная, и они также кэшируют весь ваш контент по всему миру, чтобы обеспечить наилучшие возможности для пользователей.
5. GitHub Pages
Отдельные разработчики и желающие разместить статичные веб-сайты и развернуть коды онлайн могут использовать GitHub бесплатно. Добавить настраиваемый домен просто: для этого достаточно включить файл CNAM в свою учетную запись.
Для создания статичного кода можно создать новый репозиторий из панели управления учетными записями и развернуть его с помощью поддомена, чтобы протестировать его. GitHub предоставляет вам один веб-сайт для каждой учетной записи GitHub, а также организацию вместе с неограниченными сайтами проектов.
6. Firebase
Хотите статический хостинг сайта производственного уровня? Firebase - хороший вариант!
В дополнение к размещению сайта, вы можете использовать его базу данных в реальном времени вместе с хранилищем файлов. Он предлагает бесплатный SSL сертификат и индивидуальный домен, даже в бесплатном тарифном плане. Однако для увеличения пропускной способности и объема хранилища можно купить платную версию.
С помощью Firebase можно развернуть не только личный веб-сайт, но и одностраничное веб-приложение, прогрессивное веб-приложение и целевую страницу мобильного приложения без проблем.
Не имеет значения, откуда пользователь обращается к вашему сайту; Firebase обеспечивает высокую производительность с помощью твердотельных накопителей на эффективных CDN. Вы получаете автоматически настроенный SSL абсолютно бесплатно для каждого сайта.
Пользователи также могут подключать свои домены без нудной проверки. Развертывание сайта также возможно с помощью одной команды, и можно выполнить откат к предыдущей версии или просмотреть историю развертываний через консоль Firebase.
7. Vercel
Платформа Vercel, которую можно назвать платформой все в одном, предлагает развертывание JAMStack и Static веб-сайтов. Она не требует настройки и работает с любым типом веб-инфраструктуры. С каждым сайтом вы получаете предварительный URL-адрес, которым вы можете поделиться со своей группой для совместной работы.
Vercel обеспечивает высочайшую производительность сайта благодаря масштабируемым и упрощенным развертываниям. Просто перейдите в Git, чтобы оживить ваш сайт.
Он поддерживает популярные фронтэнд-фреймворки, такие как Next.js, Vue.js, React, Angular, Gatsby, Hugo, Nuxt, Ember и Svelte. На данной платформе можно запускать мгновенные тесты для каждого развертывания, а затем выпускать их с полной уверенностью. Это облегчает интеграцию с такими поставщиками Git, как GitHub, Bitbucket и GitLab.
Кроме того, Vercel предлагает динамическое восстановление сайта с помощью развертываемых хуков, что удобно при работе с CMS. Можно создать одну страницу за один раз, поэтому не нужно перестраивать весь сайт. Vercel благодаря своим сверхбыстрым глобальным CDN, расположенным в 70 городах, гарантирует доступность в 99,99%.
Заключение
Статичные сайты еще не забыты. Особенно сегодня, когда угрозы в Интернете вызывают наибольшую обеспокоенность во всем мире, статичные сайты становятся еще сильнее, чем когда-либо, чтобы снова управлять Интернетом и поддерживать ваш бизнес.