Хостинг (Hosting)

Что такое хостинг

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

Физическим хостингом (хостинг серверов, сервер хостинг) называют услуги по размещению серверного или иного телекоммуникационного оборудования на специализированной площадке провайдера с обеспечением подключения его к каналам связи – Colocation, если оборудование принадлежит клиенту или Dedicated, если оборудование арендуется у провайдера.

Услуги Хостинга можно разделить на:

• Виртуальный Хостинг (или просто Хостинг)
• Виртуальный выделенный сервер (или VPS, он же VDS)
• Аренда выделенного сервера

Чем могут различаться Хостинговые компании, на что стоит обратить внимание при выборе?

Очень просто, и в то же время сложно ответить на данный вопрос. Обычно, для большинства, первым фактором является, конечно, цена услуги. Но, если изучить этот вопрос, сравнить разные предложения, то, в условиях рынка, и достаточно большого количества Хостинг-Провайдеров можно прийти к выводу, что цены очень схожи.Обзор российского рынка банковской цифровизации: импортозамещение, искусственный интеллект и собственные экосистемы 6.8 т

Хорошим советом будет посмотреть отзывы о Хостинговых компаниях, что думают другие? Отсутствие отзывов показывает, что компания новая, обычно таких обходят стороной. Присутствие только позитивных отзывов тоже настораживает, в большой нормальной компании всегда будут разные мнения, нужно их изучить и попробовать понять, прийти к промежуточному выводу о компании. И после этого зададимся вопросом о качестве предоставляемых услуг хостинга, и подходе хостинговой компании к реализации хостинга.

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

Чтобы сайты работали быстро и без перебоев, должно быть современное и качественное оборудование в хостинговой компании, с реализацией резервного восстановления всего, чего только используется при предоставлении Хостинг услуг (электропитание, интернет каналы связи, охлаждение оборудования, сами сайты).

Залогом успеха хостинговой компании является собственный Дата-центр (ЦОД), который оборудован дорогостоящим оборудованием и отвечает самым высоким современным стандартам качества. Многие компании, не имеющие собственного Дата-центра, арендуют оборудование в крупнейших Дата-центрах Москвы или Санкт-Петербурга. Минусы такой схемы работы в том, что свободный доступ в такие Центры ограничен, и если что-то сломалось нужно выписывать пропуск, ехать туда, решать проблему самостоятельно. Все это увеличивает время простоя сайтов, как следствие отрицательно отражается на seo-продвижении и неэффективности рекламной кампании или SMM проводимых в данный период. Соответственно привлекательность предоставляемых услуг виртуального хостинга такими компаниями снижается.

А теперь, давайте рассмотрим технические варианты реализации хостинга:

Первый вариант создания хостинга, это взять обычный сервер и разместить все сервисы на нем, в большинстве случаев это типовое решение для нескольких сайтов, не требует много затрат, все сервисы размещены вместе, такие как: веб сервер, сервер баз, почтовая система.

<a name="1"></a>
(рис. 1)

Более сложный вариант, это когда сервис базы данных выносится на отдельный сервер, то есть нагрузка на обработку запросов к базе данных вынесена на отдельный сервер, тем самым разгрузив непосредственно сервер контента и почты.

<a name="2"></a>
(рис. 2)

Еще сложнее система, это когда все основные сервисы разнесены по отдельным физическим серверам не мешая друг другу в работе.

<a name="3"></a>
(рис. 3)

Из всех выше перечисленных систем есть свои минусы и плюсы.
Например, на <a href="#1" class="dotted">рис. 1</a> все находится на одном сервере, удобно администрировать и контролировать, но это так же дает и минусы. Предположим на сервер начинают поступать множество запросов, которые заставляют сервер генерировать динамический контент, причем для создания контента требуется задействовать ресурсы базы данных, так вот в этом случает при плохой разработке может случиться весьма неприятный казус.
Суть его в том, что пришедший запрос на веб-сервер порождает запрос к базе данных, который по разным причинам может выполняться достаточно долгое время, при этом потребляя достаточно большое количество ресурсов системы в целом. И так приходит еще один запрос на веб-сервер, и еще, и еще, в результате сервер работает все медленней и медленней, пытаясь обработать все запросы. В итоге работа всего сервера будет парализована, и даже пользователи который запросят контент не связанный с динамической конфигурацией могут его и не получить из-за перегруженной системы в целом.

Второй вариант (<a href="#2" class="dotted">рис. 2</a>), тоже на первый взгляд решает проблемы первого случая, но тут можно получить другую проблему. Как-то в своей практике, я наблюдал работу CMS-системы, которая требовала выполнить около 17000 запросов к базе данных. В связи с тем, что на обработку одного запроса к базе уходило менее 0.01 сек., в сумме это выходило порядка 120-200 секунд, что, в общем-то, совсем не приемлемо. Если страница сайта будет открываться более, чем нескольких секунд, вероятней всего посетитель покинет сайт. На этом примере я показал, что при большом количестве запросов к базе данных, накладные расходы, как бы не заметные в большинстве случаев, вызывают очень большую проблему.
А вот как раз в первом случае (<a href="#1" class="dotted">рис. 1</a>) запросы могли бы выполняться раз в 10 быстрей, так как было бы затрачено гораздо меньше сетевых служб, так как запросы проходили напрямую через сетевой стек операционной системы.

Третий вариант (<a href="#3" class="dotted">рис. 3</a>), кажется вообще идеалом совершенства, но обратите внимание, администратору надо контролировать уже три сервера, у каждого из которых могут быть свои проблемы, которые могут повлиять на работу всего комплекса. Хотя конечно уже все лучше, если вдруг вас завалит Спамом, и почтовый сервер не выдержит, сайт(ы) будут работать как и раньше, это им не помешает.

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

Сюрпризы вас будут ожидать немного позднее, предположим, один из сайтов начинает расти и становится весьма популярным и вам придется делать выбор, или вы бьетесь с утра до вечера над стабильной работой всей системой, или вам придется отказать владельцу популярного ресурса, чтобы сохранить нормальную работу других ресурсов.

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

Ко всем нашим ресурсам стоит добавить новые системы, системы мониторинга, которые, кстати, тоже требуют слежения за собой.

На первый взгляд жизнь налаживается, но, увы, это еще не все сюрпризы, чем больше становится клиентов, тем больше нагрузка на системы, и может случиться так, что одного сервера баз данных будет не достаточно, необходима установка нового.
Клиенты не особо стремятся вникать в искусство программирования и допускают достаточно серьезные ошибки, которые вызывают перегрузку систем. Как у нас принято иногда говорить: «На таких серверах можно жарить яичницу» :-)

Вы встаете перед выбором, что же делать дальше?
Что делать дальше, это достаточно сложный вопрос, поскольку он завязан, как и на коммерческой части, так и на морально-этической, я думаю это тема отдельной статьи, где можно философствовать над всеми аспектами данного вопроса.

Вернемся же к техническим вопросам. «Что можно еще улучшить?» — спросите вы. В принципе нет предела совершенства, давай для начала разделим вашу систему на две части «front-end» и «back-end» (<a href="#4" class="dotted">рис. 4</a>)

<a name="4"></a>
(рис. 4)

Все запросы приходят на «front-end» и дальше этим сервером распределяются между остальными «back-end» серверами. Можно подумать какая же это хорошая схема, а на самом деле, что будет, если «front-end» сломается? Правильно, никакое кол-во «back-end» не поможет спасти ситуацию, если нет «front-end» сервера. Значит нужно предусмотреть какой-то альтернативный вариант для такого случая.

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

Кстати, это место достаточно интересное и имеет множество решений.
Как пример, если у вас роутер имеет поддержку WCCP (Web Cache Communication Protocol), то можно использовать его для этих целей. Его суть будет сводиться к тому, что если ваш «front-end» жив и регулярно отвечает на запросы роутера или уведомляет его о своей жизни, роутер перехватывает пакет и направляет его именно на «front-end». Если же связь с «front-end» утеряна, то роутер направляет запросы напрямую на один или множество «back-end», все зависит от вашего желания и типа настроек.

Даже если у вас и нет дорогого роутера, то и тут остается большое поле для действий. Обычный сервер можно превратить в роутер, используя различные системы, такие как ipfw, iptables, pf можно достигнуть похожего результата, я бы сказал даже большего, чем в выше описанном случае. Управлять правилами тут можете вы сами при написании достаточно простых программок. Если же к этому еще и подключить, например CARP (Common Address Redundancy Protocol), то можно сделать дубль такого сервера, в случае выхода из строя одного сервера, работу подхватит другой, тем самым увеличив надежность системы в целом.
Более того, имея вышеперечисленные системы, вам будет проще бороться с такой частой проблемой в последнее время, как DDOS(Distributed Denial of Service). Так как вы не допустите попадания негативного трафика на основные сервера системы, тем самым защитив их.

И опять возник вопрос — «Что можно еще улучшить?»
Да не проблема, давайте возьмемся за почтовую систему, на первом этапе, когда вы еще все только начинали, самое важно не допустить простых ошибок. Например, для всех почтовых протоколов выдать клиентам одно и тоже имя вида mail.domain.ru, все равно же один сервер скажете вы. Но в дальнейшем в случае расширения вам придется сложней разделять это имя по разным протоколам, поэтому не ленитесь, сделайте отдельные имена на разные протоколы: smtp, pop, imap, даже если они пока и ведут на один сервер.

Следующим шагом можно разделить протоколы smtp от pop и imap, причем для большей надежности, можно разделить smtp на два отдельных сервера для входящей и исходящей почты.
Так же с увеличением кол-ва входящих или исходящих сообщений, можно будет увеличивать кол-во серверов smtp. В случае сервера исходящих сообщений можно использовать указание нескольких ip адресов в dns сервере, и тогда по алгоритму round-robin исходящий сервер клиентом будет выбираться по принципу перебора адресов по круговому циклу, тем самым распределяя нагрузку между серверами.

Точно так же можно поступить и с серверами входящей почты, но у вас есть еще один инструмент для управления процессом, куда же доставлять почту идущую на домены ваших клиентов. Этот параметр MX тип записи в dns, который указывает на mail-exchange сервера, которые обслуживают почту для домена. У этого типа записи можно указывать приоритет для каждого сервера или множества серверов, тем самым контролируя в каком порядке и на какой сервер будет доставлено письмо для вашего клиента.

Imap и pop протоколами немного проще, по сути, они должны жить рядом с достаточно большим хранилищем почты, чтобы не лимитировать клиентов размерами ящиков. То есть для этой цели подойдет любой сервер с большими дисками, в дальнейшем конечно лучше использовать raid системы для надежного хранения почты, если вы будете брать с клиентов деньги за это то вы должны обязательно задуматься о надежном хранении.

С почтой развлеклись, чем бы нам заняться еще...
И тут есть тоже варианты, например CRON (планировщик задач для выполнения ваших программ). Обычно в него помещают энергоемкие и сложные задачи по обработке какой-то аналитики или операций обслуживания систем. И это может тоже вызывать проблему, если не по дискам, так по памяти или процессору, что может помешать выдачи контента с веб-сервера. Тут как вариант можно предложить следующее.

Файловую систему можно вынести на другой сервер, например по NFS, и на нем обслуживать cron задания. Так же на этот сервер можно вынести ssh доступ, так как работа этого сервера не связана с работой основного веб-сервера. Тут можно позволить клиентам пользоваться различными программами, которые вы раньше не позволяли использовать, например различные компиляторы. Ftp нет смысла сюда выносить, все же загрузка файлов должна быть ближе к хранилищу и как правило ftp не вызывает проблем ни по диску, ни по процессору, ни по памяти.

Если стало опять скучно, то можно заняться модернизацией «back-end» серверов.
Чаще всего на таких серверах происходит реконфигурация, дабы не заставлять этого делать, есть несколько путей.
Первый — это создания виртуального мапинга имен сайтов, через пути в файловой системе в которых будет фигурировать имя сайта, но в этом случае крайне сложно будет регулировать настройки определенных сайтов.
Второй вариант, это написание своего модуля который будет динамически создавать и кешировать конфигурацию на основе базы данных. Тут тоже не стоит особо увлекаться, так как если выбрать базу данных mysql или pgsql, можно будет парализовать или их работу или в случае их поломки парализовать работу сайтов, тут лучше использовать или BDB или CDB. То есть использовать промежуточную базу для хранения настроек и обновлять их, если произошли изменения в центральной базе.

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

Тут у себя мы выбрали немного другое решение, это создание reverse-proxy c хитрым мапингом, суть его сводится к следующем, на роутере создается маршрут для достаточно большой сети, которая направляется на адрес нашего прокси сервера. На самом проксе сервере, прописывается правило все пакеты идущее к нам в этой сети перенаправлять в определенный порт, причем именно перенаправлять, то есть оставляя в пакетах информацию о src и dst адресе. Дальше наш прокси сервер, получая этот пакет, видит куда он направлен, опять же через промежуточно сформированный CDB файл, и определяет на каком из «back-end» находится контент по данному запросу, направляет этот запрос туда и передает ответ клиенту.

По такой же аналогии можно вообще раздать всем сайтам IPV6 адреса, наверняка в вашей базе, где хранится список сайтов, у каждого сайта есть свой уникальный числовой идентификатор, как правило, это integer, а это всего лишь 32 бита, для ipv6 это сущая мелочь. То есть на все ваши проделки хватит сети /96, 4 млрд. адресов. :-)
Суть идеи такова, пакеты перехватываются и направляются опять же в порт проки сервера, только в этом случае мы берем последние 4 байта адреса ipv6, которые и есть уникальный идентификатор сайта, дальше не составит опять заглянуть в базу и найти, куда направить этот запрос уже по верх ipv4.

Если вам еще не надоело все это читать, то в итоге мы получим следующую картину:

Источник: Что такое Хостинг и зачем он нужен сайту?

Реестр провайдеров хостинга в России

Основная статья: Реестр провайдеров хостинга в России

Хроника

2024: В России на 20-30% подорожали услуги хостинга

18 октября 2024 года стало известно о том, что крупнейшие российские хостинг-провайдеры объявили о значительном повышении цен на свои услуги. Рост стоимости в среднем составил от 20% до 30%, что является самым резким скачком цен в отрасли за последние годы.

По данным Forbes, компания Мастерхост повысила цены на 20% с 4 октября 2024 года, Ru-Center планирует увеличение стоимости услуг для физических лиц с 12 ноября 2024 года, а Timeweb уже в июне поднял расценки в среднем на 30%. Эксперты прогнозируют, что вслед за лидерами рынка остальные провайдеры также будут вынуждены пересмотреть свою ценовую политику.

𝓲

Freepik

Руководитель департамента хостинга и профессиональных сервисов компании Reg.ru Сергей Рыжков отметил, что на повышение цен повлияли несколько факторов. Среди них – рост стоимости оборудования на 20-30% в годовом исчислении, увеличение цен на программное обеспечение, особенно в сфере информационной безопасности, а также необходимость соответствия новым законодательным требованиям.

В декабре 2023 года вступил в силу закон, обязывающий хостинг-провайдеров размещать свою инфраструктуру в России, проводить идентификацию клиентов и устанавливать оборудование для доступа силовых служб. По оценкам Рыжкова, затраты на выполнение этих требований составили около ₽100 млн для крупных компаний и ₽10-20 млн для небольших хостеров.

Генеральный директор хостинг-провайдера RUVDS Никита Цаплин указал на дополнительные факторы, влияющие на рост цен. Среди них – повышение курса доллара, усложнение логистических цепочек из-за вторичных санкций, увеличение налоговой нагрузки и рост ставок по кредитам.

Российская ассоциация электронных коммуникаций (РАЭК) прогнозирует, что новые требования приведут к консолидации рынка и уходу мелких игроков, которые не смогут выполнить установленные требования. В 2023 году рынок хостинга в России показал рост на 20% и достиг объема в ₽12,7 млрд.^[1]

2023

Иностранные хостинг-провайдеры и регистраторы доменов отключают российских клиентов

Несколько иностранных компаний, предоставляющих услуги хостинга, прислали своим российским клиентам сообщения, что их услуги не будут доступны в России. В частности, об этом объявил хостинг-провайдер Hetzner^[2], который разослал сообщение своим пользователям, что с 31 января 2024 года провайдер не сможет оказывать услуги хостинга. Провайдер разослал своим клиентам следующий текст:

Мы с сожалением сообщаем вам, что из-за напряженной геополитической ситуации с Россией мы прекращаем наши договорные отношения с клиентами из России. Политические решения привели к изменениям в законодательстве, которые влияют на наш бизнес с российскими клиентами. К сожалению, мы больше не можем заключать контракты с клиентами с российскими почтовыми адресами. Это затронет всех, у кого российский адрес сохранен в аккаунтах Hetzner. После того, как мы проанализируем базы данных клиентов, мы отправим затронутым клиентам уведомление о прекращении действия всех продуктов и услуг в пятницу, 15 декабря 2023 года. Оно вступит в силу с 31 января 2024 года. Мы рекомендуем вам принять соответствующие меры сейчас.

Сообщение иностранного хостинг-провайдера Hetzner

Сообщение аналогичного содержания было разослано и одним из крупных иностранных регистраторов Godaddy^[3], который также предоставляет услуги хостинга. В его сообщении клиентам написано следующее:

В наших записях указано, что вы или контакт, указанный в вашей учетной записи, можете находиться в Российской Федерации. Если наши записи верны, ваша учетная запись и/или затронутый продукт будут заблокированы с 31 декабря 2023 года. Что касается регистрации доменов, у вас есть время до 31 декабря 2023 года, чтобы инициировать передачу любого затронутого домена регистратору по вашему выбору с учетом ограничений на входящую передачу, установленных другими регистраторами. Инструкции по передаче доменов см. в разделе https://www.godaddy.com/help/transfer-my-domain-away-from-godaddy-3560 Для всех остальных продуктов ваш доступ ко всем данным и контенту, хранящимся у нас, будет прекращен с 31 декабря 2023 года, и мы не сможем предоставить вам резервные копии. Соответственно, мы с уважением просим вас восстановить ваши данные и передать все продукты, которые у вас есть, новому поставщику до этой даты.

Скорее всего, речь в сообщении Hetzner идет о принятом в России летом 2023 года законе №406-ФЗ, который с одной стороны легализует деятельность хостеров, а с другой – с 1 февраля 2024 года вводит запрет на предоставление услуг хостинга операторами, которые не зарегистрируются в реестре хостинг-провайдеров Роскомнадзора. Понятно, что сделать это иностранным операторам хостинга будет затруднительно. Причем дата 15 декабря 2023 года указана в законе как последний срок для подачи заявлений на включение оператора в соответствующий реестр.

Минцифры РФ введет идентификацию клиентов хостинг-провайдеров по СБП и банковским картам

9 октября 2023 года Минцифры РФ обнародовало обновленный проект постановления об идентификации клиентов хостинг-провайдеров. При подготовке документа учтены пожелания и мнения участников российской ИТ-отрасли и заинтересованных ведомств.

Проект постановления входит в число подзаконных актов к принятым в июле 2023-го поправкам к законам «О связи» и «Об информации». Обязанность хостеров устанавливать личность клиентов появится с 1 декабря 2023 года. Изначально планировалось, что идентификация будет осуществляться через «Госуслуги» и Единую биометрическую систему (ЕБС), с использованием усиленной квалифицированной электронной подписи, а также через личное представление документов. Позднее Минцифры занялось рассмотрением возможности введения «упрощенной идентификации», в том числе для иностранных клиентов.

Минцифры обнародовало обновленный проект постановления об идентификации клиентов хостинг-провайдеров

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

Идентификация необходима для обеспечения безопасности ИТ-инфраструктуры. Однако участники рынка говорят, что новые требования создадут дополнительную нагрузку на компании, в том числе финансовую. Кроме того, как отмечается, предложенные поправки не решают проблему идентификации иностранных пользователей. Дело в том, что при работе с СБП клиент должен зарегистрироваться в системе и подтвердить личность с помощью специального кода, который отправляется на мобильный номер. Однако у иностранных пользователей иные номера телефонов и зарубежные счета.^[4]

Хостинг-провайдеры просят Минцифры отложить размещение инфраструктуры в РФ

Крупные ИТ-компании, оказывающие услуги виртуального размещения данных и сайтов (хостинг-провайдеры), попросили Минцифры РФ отложить вступление в силу ведомственного приказа, который ужесточает их ответственность за действия хакеров. Об этом стало известно 10 октября 2023 года. Подробнее здесь.

Опубликован проект правил идентификации клиентов хостинга

Минцифры опубликовало проект постановления правительства «Об утверждении Правил идентификации и (или) аутентификации лиц, обратившихся к провайдеру хостинга в целях получения вычислительной мощности для размещения информации в информационной системе, постоянно подключенной к информационно-телекоммуникационной сети «Интернет» для общественного обсуждения. Об этом 27 сентября 2023 года сообщила пресс-служба депутата ГосДумы РФ Антона Немкина.

Проект постановления определяет порядок идентификации провайдеров хостингов как для физических, так и для юридических лиц через четыре возможных способа: посредством инфраструктуры Госуслуг и Единой биометрической системы (ЕБС), подтверждения через усиленную квалифицированную электронную подпись (УКЭП), через перевод со счета в банке России или другие страны ЕАЭС, а также посредством личного обращения.

Для тех, кто захочет авторизоваться лично, потребуется ряд документов. Для ИП необходим паспорт и выписка из ЕГРИП, для представителей юридических лиц потребуется выписка из ЕГРЮЛ и документ, который подтверждает их полномочия на заключение договора с хостером. Для физических лиц потребуется документ, удостоверяющий личность.

Помимо идентификации, будет реализовано ведение реестра провайдеров хостинга, а также внедрение правил ведения реестра и требований к провайдерам для включения в реестр. Что важно – провайдеры будут обязаны предоставить необходимую информацию для проведения оперативно‑розыскных мероприятий. Считаю, что такие действия положительно скажутся на снижении количества киберпреступлений в России, – сказал Антон Немкин.

Регулирование деятельности хостинг–провайдеров ужесточается в связи с поправками в федеральные законы «О связи» и «Об информации», подписанные президентом 31 июля 2023 года.

Госдума утвердила создание реестра провайдеров хостинга. Только его участники смогут оказывать услуги

26 июля 2023 года Государственная дума утвердила создание реестра провайдеров хостинга. Только его участники смогут оказывать услуги. Соответствующие поправки в закон «Об информации, информационных технологиях и о защите информации» и закон «О связи» одобрены в третьем (окончательном) чтении.

Как сообщает издание РБК со ссылкой на принятый документ, провайдеры хостинга теперь будут иметь право предоставлять вычислительные мощности только тем, кто прошел процедуру идентификации. Те компании, которые не попадут в специальный реестр провайдеров хостинга, который будет обязан вести Роскомнадзор, станут в России незаконными и не смогут легально оказывать услуги. Если провайдер нарушит какое-либо положение закона, Роскомнадзор должен будет направить ему соответствующее уведомление, и, если нарушение не будет устранено в течение 10 дней, его исключат из реестра.

Госдума приняла законопроект о регулировании хостинга в России

Мы хотим сделать рынок прозрачным, собрать информацию о его участниках, определить условия взаимодействия с органами власти, — пояснил замруководителя комитета Госдумы по информационной политике Антон Горелкин в конце июля 2023 года. — Сейчас этот рынок находится в довольно хаотичном состоянии: он насыщен виртуальными организациями, которые не обладают собственными мощностями, а по факту перепродают услуги хостинга зарубежных провайдеров, что в сложившейся геополитической ситуации влечет за собой серьезные риски безнаказанного распространения противоправной информации, ставит под угрозу безопасность российских граждан и компаний.

Чтобы дать рынку возможность адаптироваться к новым требованиям, для этой части законопроекта установят переходный период — предполагается, что реестр хостинг-провайдеров начнет действовать только с 1 февраля 2024 года.^[5]

2022: Россия вошла в топ-5 стран Европы по объему услуг хостинга интернет-магазинам

Россия вошла в пятерку стран Европы по объему услуг хостинга интернет-магазинам. Об этом этом свидетельствуют обнародованные в январе 2023 года данные немецкой компании InterNetX, специализирующейся на услугах хостинга, регистрации доменов и кибербезопасности.

Согласно исследованию, к ноябрю 2022 года на РФ приходилось 6,7% услуг хостинга интернет-магазинов в Европе. Более высокие доли имели лишь Германия (20,7%), Нидерланды (13,2%), Британия (11,5%) и Франция (9,5%). С точки зрения городов на рынке лидируют Берлин (7,2%), Лондон (5,5%), Москва (4,8%) и Париж (4,5%).

Если говорить о доменных именах, предпочитаемых интернет-магазинами, то положение дел в Европе разительно отличается от картины на рынке Северной Америки или Азии. В этих регионах на долю общих доменов верхнего уровня – во главе с .COM – приходится 86,2% и 67,6% всех доменных имен, используемых интернет-магазинами. В Европе же 69,6% онлайн-магазинов работают на доменах в национальных доменных зонах. Лидером, впрочем, и здесь является домен .COM – 25,8% всех доменов европейских онлайн-магазинов. 15,5% приходятся на национальный домен Германии .DE, 8% – на национальный домен Нидерландов .NL. Пятерку замыкают национальные домены Великобритании .UK и России .RU – 7,6% и 4,6% соответственно. Что касается новых общих доменов верхнего уровня, то их доля весьма скромна – порядка 3%. Лидером здесь является домен .SHOP, за ним идут .STORE и .ONLINE.

Среди новых географических доменов верхнего уровня лидируют .berlin (0,7%), .london (0,5%) и .paris (0,5%).

В целом, как следует из отчёта, число граждан, покупающих онлайн, по-прежнему растёт. Если в 2016 году покупки в интернет-магазинах делали 63% интернет-пользователей, то в 2022 году это доля выросла до 75%.^[6]

2021: 1 марта - день хостинг-провайдера в России

В 2021 году праздник был учрежден при участии Российской ассоциации электронных коммуникаций (РАЭК) и проекта «ХостОбзор». Эта инициатива была поддержана всеми крупными участниками отрасли.

«Данное решение не пришло спонтанно. Дело в том, что о хостинге, как услуге и технической платформе, мало кто знает, только специалисты, но наша работа хоть и незаметна, но незаменима, и за время своего существования, мы не раз доказывали качество российского хостинга, и его надежность. И создание нашего собственного праздника, есть не что иное, как дань уважения тем, кто днями и ночами работает над усовершенствованием систем хранения и передачи информации», – прокомментировал идею создания праздника Матвей Алексеев, председатель комиссии хостер-провайдеров при РАЭК.

Примечания