Поддержка PHP 8.1

Здравствуйте, уважаемые пользователи.



Добавили на всех тарифах виртуального хостинга hostiman.ru/hosting поддержку PHP 8.1

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

С уважением, Ваш хостинг-провайдер HostiMan.

Мы начали строительство собственного дата-центра



Дата-центр будет занимать выделенную территорию на юге Москвы. Проект расчитан для размещения современных высоконагруженных серверов и инфраструктуры для сверхплотных вычислений в соответствии с уровнем надежности Tier III. Сертификацию и вывод в эксплуатацию первой очереди планируем на вторую половину 2022 года.

Следите за новостями! В наших дайджетах мы расскажем о характеристиках ЦОД, планируемых сроках введения в эксплуатацию, а также будем выкладывать новые фото со стройки.

Как выбрать CDN для доставки динамического контента и не облажаться: 8 условий и must-have технологий

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



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

С динамическим контентом всё сложней, так как он уникален для каждого пользователя и его нельзя кешировать. Значит, и ускорить доставку не получится? Получится: если CDN отвечает ряду критериев, то она справится и с ускорением динамики.

1. Отличная связность
Быстрая доставка контента во многом зависит от связности сети. Чем больше у CDN пиринг-партнёров, тем лучше связность и тем более короткий маршрут от источника до пользователя может быть построен. А чем короче маршрут, тем быстрее данные будут доставлены. На это обязательно нужно обращать внимание при выборе сети доставки контента, идёт речь о статике или динамике.


2. Поддержка HTTP/2
HTTP/2 — это последняя версия протокола HTTP. Использование этой версии во многом помогает ускорить отдачу контента — главным образом за счёт мультиплексирования, то есть передачи нескольких потоков данных по одному каналу.

Чтобы отправить информацию, HTTP сначала должен установить TCP-соединение. Для этого требуется «тройное рукопожатие»:
  • Отправитель посылает запрос на установку соединения — сообщение SYN и порядковый номер переданного байта.
  • Получатель в ответ посылает сообщение SYN, подтверждает получение данных сообщением ACK и отправляет номер байта, который должен быть получен следующим.
  • Отправитель тоже подтверждает, что получил информацию, и посылает номер следующего ожидаемого байта.

После этих трёх шагов соединение считается установленным.


В предыдущих версиях HTTP для передачи каждого элемента (JаvaScript, CSS, изображений и других данных) открывалось отдельное TCP-соединение. «Тройное рукопожатие» нужно было проводить каждый раз, и это сильно замедляло доставку.

В HTTP/2 для всех этих данных устанавливается единое TCP-соединение. При этом разные типы информации могут отдаваться параллельно. Это значительно экономит время на передачу контента.


HTTP/2 помогает ускорить доставку и по другим причинам:
  • Это бинарный протокол. Использование бинарного формата вместо текстового значительно облегчает выполнение команд. В таких протоколах меньше ошибок, меньше нагрузка на сеть и, как следствие, меньше задержек.
  • Умеет сжимать заголовки. Заголовок — это тоже данные. А чем больше данных передаётся, тем медленнее они доходят до пользователя. HTTP/2 сжимает заголовки по алгоритму Хаффмана и опускает повторяющиеся.
  • Доступна приоритезация запросов. Определённую информацию можно назначить приоритетной — тогда она будут отдаваться в самом начале и загружаться быстрее. В первом приоритете можно отдавать самые важные элементы страницы, которые должны отобразиться у пользователя в первую очередь.
  • Есть функция Server Push. Она позволяет предугадывать, какие данные понадобятся клиенту, и отправлять их ещё до того, как поступил запрос. Это ускоряет загрузку, снижает количество запросов, а значит, уменьшает нагрузку на источник.

Мы заботимся не только о скорости доставки, но и о безопасности. Поэтому в G-Core Labs CDN есть функция принудительного редиректа на HTTPS. Это значит, что даже если передача по HTTPS не настроена на источнике, вы всё равно можете доставлять контент безопасно. Благодаря использованию HTTP/2 и TLS 1.3 безопасное подключение не будет замедлять отдачу контента, а то есть приложение будет работать быстро и безопасно.

3. Поддержка WebSocket
WebSocket — это независимый протокол на основе TCP. Он даёт возможность обмениваться сообщениями между клиентом и сервером в режиме реального времени.

Его принципиальное отличие от HTTP в том, что для получения информации клиенту не нужно каждый раз посылать запрос на сервер.

Возьмём для примера чат. Чтобы клиент узнал, что ему пришло новое сообщение, браузер должен периодически отправлять запросы на сервер и узнавать, нет ли новой информации.

Минусы такого подхода:
  • Увеличивается количество запросов к серверу. Из-за этого растёт нагрузка и падает скорость обработки запросов.
  • Данные обновляются медленнее. Так как браузер посылает запросы с определённой периодичностью, передать новое сообщение клиенту он может не сразу. Это создаёт задержки при доставке контента.

WebSocket же устанавливает постоянное соединение. И когда появится новое сообщение, сервер сразу отправит его клиенту.


Это сокращает количество запросов и увеличивает скорость отдачи данных.

Если вы хотите быстро доставлять часто меняющийся динамический контент (сообщения в чатах, push-уведомления и любые другие данные, которые постоянно обновляются на сайте), без WebSocket не обойтись.

4. Использование IPV6
IPv6 — более современная версия протокола IP. Он был разработан главным образом для того, чтобы решить проблему нехватки IP-адресов. Если в IPv4 для создания адреса используется 32-битная система, то в IPv6 — 128-битная.

Адрес IPv6 — это восемь 16-битных блоков, разделённых двоеточием. И общее количество IP-адресов, которые можно создать, составляет 2128 — это более 300 млн адресов на каждого жителя планеты. Такого количества должно хватить каждому устройству.

Но, кроме записи IP-адресов, в обновлённую версию протокола внесли и другие изменения, сделав его более эффективным для передачи информации.
  • Меньшая нагрузка на сетевое оборудование. Эта версия протокола не использует NAT — технологию для преобразования приватных адресов в публичные.
  • NAT был нужен в IPv4, так как там существовала проблема нехватки адресов. Внутри локальной сети у каждого устройства был приватный IP-адрес, который использовался для локальной передачи данных, например между устройствами внутри одной компании. Но для взаимодействия с другими ресурсами через глобальный интернет нужен был публичный, общедоступный адрес.
  • NAT преобразовывал приватный адрес в публичный — этот процесс называется трансляцией. При этом нужно было не только преобразовывать адреса, но и хранить информацию об установленных соединениях. Это увеличивало нагрузку на оборудование, и во время пиковых скачков трафика скорость падала. В IPv6 нет необходимости в трансляции, не нужно хранить информацию о соединениях, а значит, нагрузка на оборудование меньше и скорость остаётся стабильной.
  • Более простые заголовки пакетов. В новой версии из них убрали несущественные элементы. Это упростило обработку, снизило нагрузку на маршрутизаторы и в целом сократило объём передаваемых данных.
  • Более быстрая маршрутизация. Структура адреса IPv6 устроена так, что маршрутизаторы на каждом уровне сети (крупные провайдеры, подсети, сети организаций) обрабатывают не весь адрес, а его часть. Это уменьшает размер таблицы маршрутизации, а значит, сокращает время на обработку.
  • Определяет чувствительные к задержкам пакеты и передаёт их в первую очередь. Такую возможность даёт функция QoS (Quality of Service). Это специальная технология, которая умеет определять тип трафика и приоритизировать его на основании этого.

Получается, IPv6 во многом более эффективен, чем IPv4, и передаёт данные быстрее. Чтобы перейти на него, нужно серьёзно модернизировать свою инфраструктуру. Но если вы подключены к нашей CDN, то в этом нет необходимости. Мы используем IPv6 при доставке, даже если ваше оборудование ещё не обновлено до этого протокола. Таким образом, динамический контент доставляется быстро, а вы не тратите ресурсы на апгрейд.

5. Сжатие на лету
Чем меньше весит контент, тем быстрее он будет доставлен пользователям. Но жертвовать важными элементами в угоду размеру — не лучшая идея. Эту проблему решает использование современных алгоритмов сжатия: Gzip, Brotli и WebP.
  • Gzip предназначен для сжатия текстового контента. Он находит в файлах одинаковые строки и объединяет их. За счёт этого размер данных уменьшается на 60–70%.
  • Brotli уменьшает размер любого контента. Для сжатия он использует уже встроенный в браузеры пользователей словарь из более чем 100 000 самых часто встречающихся в интернете элементов. Алгоритм находит эти элементы в передаваемых данных, вычисляет уникальные фрагменты и передаёт только их, а неуникальные добавляет из словаря. Brotli на 20–25% эффективнее Gzip.
  • WebP — новый алгоритм для сжатия изображений. Он на 26% лучше PNG сжимает изображения без потерь и на 25–34% эффективнее JPG при сжатии изображений с потерями.

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


6. Гибкие настройки кеширования
Не весь динамический контент нельзя кешировать. Некоторые данные можно сохранять на короткий срок, и они не потеряют свою актуальность для пользователей. Однако, для этого важно настроить кеширование точно в соответствии с особенностями вашего веб-ресурса. Поэтому выбирать нужно ту CDN, которая позволяет установить любое время кеширования либо отключить его совсем. Не лишней будет и опция очистки кеша — полная или выборочная, для одного файла или для группы.

7. Функции аутентификации на стороне провайдера
Если вам нужно предоставлять ограниченный доступ к контенту, вы можете перенести функции аутентификации на CDN. Это позволит избавить сервер от дополнительной нагрузки, а значит, и увеличить скорость. В нашей CDN для этого доступна опция Secure Token. Она позволяет создавать временные ссылки, которые содержат специальный хеш-ключ, и контент получается загрузить только по запросам, содержащим этот ключ.

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

8. Облачное объектное хранилище
Контент важно не только эффективно доставлять, но и хранить. Возьмём, например, интернет-магазин. Чтобы отобразить покупателю индивидуальную подборку рекомендуемых товаров, вместе с остальными данными нужно загрузить и фото товаров. Для хранения такого контента требуются большие объёмы памяти. А при запросе клиента нужно быстро извлечь нужные файлы, сформировать ответ и отдать в нужном виде.

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

В отличие от других типов, в объектных хранилищах нет иерархии — файлы извлекаются напрямую, за счёт чего сокращается время на их отдачу.

Как это относится к CDN? У G-Core Labs есть объектное хранилище, в которое можно поместить данные практически любого объёма, максимально быстро извлекать и доставлять их. Хранилище оптимизировано под работу с динамическими веб-ресурсами. Подключить его можно вместе с CDN и управлять ими через единую панель.

Подведём итоги
  • Есть мнение, что CDN может ускорить доставку только статического контента и плохо работает с динамикой. Но на самом деле, если сеть поддерживает определённые функции, она отлично справится и с ускорением динамики.
  • Чтобы CDN могла построить лучший маршрут для доставки данных, у неё должно быть отличная связность. У G-Core Labs CDN больше 6 000 пиринг-партнёров, поэтому она позволяет передавать данные максимально быстро.
  • CDN должна поддерживать HTTP/2, так как он намного эффективнее предыдущих версий HTTP. Его главный плюс в том, что для передачи любых типов файлов он устанавливает только одно TCP-соединение.
  • В CDN должна быть поддержка WebSocket — этот протокол для передачи данных в реальном времени упрощает доставку часто меняющегося динамического контента, поэтому без него не обойтись.
  • Чтобы быстрее доставлять контент, CDN важно поддерживать протокол IPv6. Желательно, чтобы сеть позволяла использовать эту версию протокола, даже если её ещё не поддерживает оборудование пользователя.
  • Важно, чтобы провайдер умел сжимать контент на лету прямо на стороне CDN, в процессе доставки с помощью алгоритмов Brotli, Gzip и WebP.
  • У CDN должны быть гибкие настройки кеширования. Желательно, чтобы провайдер мог взять функции аутентификации пользователей на себя, чтобы снизить нагрузку на ваши ресурсы.
  • Вместе с CDN можно подключить объектное хранилище, чтобы эффективно доставлять и хранить данные.

G-Core Labs CDN отвечает всем этим критериям, поэтому доставляет динамику так же быстро, как и статику. За производительность сети отвечают технологии Intel: в апреле 2021 мы одними из первых в мире начали интеграцию процессоров Intel Xeon Scalable 3-го поколения (Ice Lake) в серверную инфраструктуру своих сервисов. Убедиться в высокой скорости доставки динамического контента с помощью нашей CDN вы можете бесплатно — для этого у нас предусмотрен бесплатный тариф, а также бесплатный пробный период на любом тарифном плане.
gcorelabs.com/ru/cdn/

Стримим Новый год в реальном времени: какой протокол выбрать (HESP, WebRTC, RTMP, HLS)

Наш клиент планирует стримить видео празднования Нового года на всех своих пользователей. Транслировать контент предстоит на сотни тысяч человек с минимальными задержками — так, чтобы зрители встретили 2022 год не позже соседей. Мы сравнили решения для быстрой доставки видео и делимся результатами: рассказываем, как организовать дешёвый стриминг медиаданных на большую аудиторию.



В прошлом году при трансляции Суперкубка представители видеоплатформ ожидали задержек вплоть до минуты. Это плохо сказывается на пользовательском опыте: крики более удачливых соседей и другие спойлеры портят игру болельщикам. Мы придумали, как решить ту же проблему в новогодние праздники. Для нашего клиента мы подобрали протокол для дешёвой realtime-трансляции видео на большую аудиторию. Это позволит зрителям встретить 2022 год в реальном времени — не позже, чем их соседи.

Выбираем протокол: WebRTC, HLS, MPEG-DASH
Для стриминга видео есть три ключевых протокола: HLS, MPEG-DASH и WebRTC. Наша инфраструктура поддерживает все эти технологии, но есть вопрос: какой протокол лучше подходит для дешёвого и быстрого стриминга видео на сотни тысяч или миллионы пользователей?

Быстро: WebRTC
С помощью RTMP видео до конечного зрителя не доставляется уже много лет, так что мы сразу перешли к WebRTC. Большой плюс: видео по этому протоколу передаётся быстро, хоть и без сохранения высокого качества. Однако, технология не подошла по другим причинам: для масштабирования она требует установки серверов по всему миру, а так как клиенту нужно транслировать видео на большую аудиторию, это приведёт к дополнительным тратам. Мы рассмотрели другие варианты.

Дёшево: HLS и MPEG-DASH
Чтобы клиент уложился в бюджет, мы обдумали ещё два решения: HLS и MPEG-DASH. Эти технологии отлично подходят для недорогого стриминга на сотни тысяч и даже миллионы пользователей. Но у клиента было важное требование: задержки должны быть минимальными. Скорость передачи данных с помощью этих технологий оказалась недостаточной, чтобы проводить интерактивное мероприятие и стримить праздник в режиме реального времени.

Дёшево и быстро: ?
Нам нужно было как-то объединить возможности первых двух вариантов — сделать всё и дёшево, и быстро. Для этого потребовалось новое решение.

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

1. Передача данных в два потока
В отличие от других протоколов, стриминг с помощью HESP происходит в два потока:
  • Поток инициализации может запрашивать изображения в любой момент для начала воспроизведения.
  • «Поток продолжения» может продолжить воспроизведение после любого изображения потока инициализации.

Это позволяет быстро и беспрерывно транслировать и воспроизводить видео в плеере пользователя. Пока один поток запрашивает изображения для начала воспроизведения, второй позволяет продолжать воспроизведение. Посмотрим, как это работает.

1. Сначала включается поток инициализации.

2. Затем в работу включается поток продолжения.

3. Это обеспечивает беспрерывное воспроизведение видео.

4. Потоки дополняют друг друга и работают один за другим.


2. HESP основан на HTTP и передаётся через CDN
HESP поддерживает передачу данных по протоколам HTTP/1.1 и HTTP/2. Это значит, что стримить видео с его помощью можно дёшево — по CDN. Это также относится и к HLS с MPEG-DASH, но с HESP задержки оказываются меньше: до 2 секунд даже при трансляции на миллионную аудиторию.

Что касается WebRTC, он не подходит для трансляций через CDN, поэтому стриминг на большую аудиторию с его помощью оказывается в 2–5 раз дороже, чем по HESP.

3. Низкие требования к полосе пропускания
Новому протоколу нужно на 10–20% меньше полосы пропускания, чем другим решениям с низкими задержками: LL-HLS, Chunked CMAF, WebRTC.

4. Поддержка адаптивного битрейта (ABR)
HESP совместим с технологией адаптивного битрейта. Это значит, что стримы доступны без буферизации на любых устройствах и при любом качестве интернета у пользователей.

… и другие отличия
Все отличия HESP от других технологий мы собрали в простую сравнительную таблицу:


В результате этих отличий новый протокол получил реальные преимущества перед другими технологиями:
  • Позволяет доставлять видео с задержками 0,4–2 секунды.
  • Требует меньшую полосу пропускания для передачи стрима.
  • Может передаваться через CDN миллионам зрителей на любые устройства, в любую точку мира и с сохранением качества хоть 8К.
  • Гарантирует минимальную стоимость трансляции в сравнении с WebRTC.

Где выгодно применять HESP
Трансляцией Нового года или спортивных событий всё не ограничивается: сократить задержки и бюджеты на стриминг важно многим. Вот пара возможных областей применения HESP:
  • Киберспорт и гейминг. Аудитории здесь большие, а высокие задержки в трансляциях быстро уводят пользователей к конкурентам. HESP помогает удерживать аудиторию и не тратить лишнее на стриминг.
  • Онлайн-образование и телемедицина. В MedTech и e-learning для трансляций с учениками и пациентами часто используют дорогие внешние решения. HESP позволяет отказаться от них и самостоятельно организовать стриминг с минимальными задержками.
  • Аукционы и онлайн-казино. В этих сферах видео нужно транслировать быстро и в высоком качестве. HESP даёт эту возможность.
  • Спорт и медиа. С новым протоколом трансляция спортивных и других мероприятий максимально приближается к реальному времени. При этом видео через интернет передаётся даже быстрее, чем по ТВ.
  • OTT и ТВ-вещание. HESP позволяет объединить IPTV- и OTT-решения для создания трансляций высшего качества. С его помощью издатели могут дёшево транслировать контент на самую крупную аудиторию.

Этот список можно продолжать долго: дешёвые и быстрые решения любят все. Нужно только разобраться с интеграцией протокола в процесс создания и доставки видео до пользователей.

Как перейти на HESP
Чтобы подключить новый протокол, мы вступили в HESP Alliance. Теперь наша инфраструктура поддерживает стриминг с низкими задержками с помощью этой технологии. Для перехода на неё клиентам достаточно подключиться к нашей сети доставки контента с поддержкой HESP. Эта инфраструктура включает больше 140 точек присутствия в 100 городах и гарантирует высокую производительность: в апреле 2021 мы одними из первых в мире начали интеграцию Intel Xeon Scalable 3-го поколения (Ice Lake) в серверную инфраструктуру своих сервисов.


Помимо CDN для подключения HESP достаточно внедрить ещё два элемента: HESP-упаковщик для кодирования видео перед передачей (есть у партнёров HESP Alliance) и плеер с поддержкой протокола — например, THEOplayer.
www.hespalliance.org/members

Подключение CDN без кода: как мы упростили интеграцию с помощью DNS-хостинга

Как бы хороша ни была ваша CDN, часть пользователей будет мучаться с её настройкой. Нам, как одному из топ-3 европейских CDN-провайдеров, очень хотелось сократить число таких пользователей до минимума. Для этого пришлось повозиться с интерфейсом личного кабинета, разработать плагины для CMS и, что самое главное, интегрировать CDN с DNS-хостингом. Теперь пользователи в no-code режиме подключают сеть доставки контента к своим сайтам за несколько минут. Рассказываем, как мы это сделали.

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

Обычно ссылки на файлы выглядят так:
https://gcorelabs.com/image.jpg 
https://gcorelabs.com/style.css 
https://gcorelabs.com/script.js

Если же ссылки ведут на кеш-сервер, они выглядят примерно так:
https://cdn.gcorelabs.com/image.jpg 
https://cdn.gcorelabs.com/style.css 
https://cdn.gcorelabs.com/script.js

Тут у пользователей и возникает проблема: многие не знают, как именно заменить все ссылки на статический контент. Мы решили упростить этот процесс.

Возможности глобальной CDN без погружения в код сайта
С нашей CDN работают многие: Lamoda, Утконос, Wargaming и десятки других крупных компаний. Как правило, у бизнеса проблем с интеграцией не возникает — подключением сети доставки контента там занимаются специализированные отделы. Совсем иначе обстоят дела у владельцев частных веб-ресурсов, особенно если они не разбираются в коде. Они нередко управляют высокопосещаемыми сайтами с пользователями из разных стран, и CDN бы им пришлась как нельзя кстати, но при подключении возникают проблемы.

Первым делом для таких пользователей мы разработали плагины для популярных CMS: WordPress и Битрикс. С их помощью подключить CDN к ресурсу можно без ручного изменения ссылок на контент в коде сайта. Это избавило от сложностей весомую долю веб-мастеров, но этим всё не ограничилось. Как минимум, потому что в нашу экосистему сервисов входит ещё и один из самых быстрых DNS-хостингов в мире, с помощью которого на поиск IP для запрошенного домена уходит менее 20 мс. Мы решили интегрировать его с CDN таким образом, чтобы наши NS-серверы могли использоваться для направления трафика клиента через сеть доставки контента. Результатом стали сразу несколько новых преимуществ для клиентов.

Используем DNS-хостинг для быстрого подключения CDN
В первую очередь новое решение упростило настройку CDN. Теперь владельцам сайтов не нужно вручную изменять ссылки на кешируемый контент или искать необходимый плагин для CMS при настройке CDN для своих сайтов. Весь процесс подключения веб-ресурса к сети выполняется в несколько простых шагов.


Пользователю достаточно кликнуть по кнопке создания ресурса и в визарде выполнить несколько простых действий:
  • Выбрать «ускорение и защиту всего сайта». Тогда ресурс будет интегрирован с нашим DNS-хостингом — для этого пользователю нужно только поменять настройки NS-серверов у своего доменного регистратора.
  • Ввести домен сайта.
  • Подтвердить DNS-записи своего домена, предложенные визардом (может потребоваться указать A-запись).

Всё остальное система сделает автоматически. Сначала она создаст CDN-ресурс, где в качестве персонального домена используется указанный домен, а в качестве origin — IP-адрес, подтверждённый или указанный пользователем в A-записи.

Затем создаст DNS-зону, через которую будет работать созданный CDN-ресурс, и добавит в неё подтверждённые или указанные пользователем DNS-записи. Для созданной A-записи система выполнит интеграцию CDN и в качестве домена укажет cl-hash зону клиента.

По окончании работ пользователь получит инструкцию, с которой он сможет обратиться к своему регистратору доменных имён для замены текущих namerservers на наши. В результате будет создан CDN-ресурс, полностью проксирующийся через созданную и делегированную нам DNS-зону, а пользователю для этого не придётся писать ни единой строчки кода.
Дополнительные преимущества интеграции CDN с DNS-хостингом
Простотой подключения всё не ограничилось. Направление трафика через нашу сеть открывает для владельцев сайтов и другие преимущества:
  • Кешироваться и доставляться быстрее будут все компоненты сайта: не только статический, но и динамический контент.
  • Статический и динамический контент сайта будет защищен от DDoS-атак благодаря нашей сети кэширующих серверов (на уровне L3, L4)

Помимо того, благодаря возможностям нашей сети посетители ресурса будут получать к нему доступ по протоколу HTTP/2 и защищенному SSL-соединению. Причём, это будет возможно даже если веб-сервер не будет иметь установленного SSL-сертификата и поддерживать HTTP/2.


Так интеграция с DNS-хостингом позволила нам не только предложить владельцам веб-ресурсов самый простой способ подключения CDN к сайтам, но и дать им дополнительные преимущества от её использования. Чтобы не верить нам на слово, все преимущества нашей CDN вы можете опробовать самостоятельно. Тем более, что это можно сделать бесплатно gcorelabs.com/ru/cdn/

Помимо сети доставки контента, мы предлагаем пользователям и другие решения, в числе которых хранилище, защита от DDoS и облако с виртуальными машинами и серверами bare metal. В их развитии нам помогают технологии Intel: в 2021 году мы одними из первых в мире начали интеграцию Intel Xeon Scalable 3-го поколения (Ice Lake) в серверную инфраструктуру своих облачных сервисов. Ознакомиться с полный списком наших решений можно gcorelabs.com/ru/cloud/

OVH.Ryzen 7-3800X TCP UDP

В начале осени сделали из новых тарифов — мощный тариф.
Ryzen 9 5900X — VM, на черную пятницу даже продавали вечные, и их даже покупали.



Теперь вот сделали слабее сервер. В наличии их мало, разберут быстро. Успеть купить. Потому что это с акций тариф, как были акции на 6700k когда-то и мы набрали серверов.
  • [GRA1-FR] Ryzen 7 3800X [16 vCore] / 32 ddr4 / 600 NVME / 4 IP — 4000р/мес
  • [GRA1-FR] Ryzen 7 3800X [16 vCore] / 16 ddr4 / 300 NVME / 4 IP — 2000р/мес
  • [GRA1-FR] Ryzen 7 3800X [16 vCore] / 8 ddr4 / 200 NVME / 4 IP — 1000р/мес

Можно садить много IP
Серверы поддерживают до 256 IP
1 IP — 200р разово, но продаем только сетками от 16 штук.

Заказывать автоматически тут
Локация GRA1 (в популярных)
asuka.onl/billmgr

Новогоднее расписание работы поддержки

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

С 29 декабря по 8 января 2022г. время ответа технического и консультационного отделов поддержки увеличивается до 72 часов. Отдел аварийной поддержки все так же работает в штатном режиме 24/7/365. Рекомендуем заранее продлить Ваши услуги.

Не забывайте про Новогодний конкурс!
vk.com/spacecore_pro?w=wall-171073991_1334

Выделенные серверы без установки:
n-install.spacecore.info

Остались вопросы? Мы с радостью ответим!
Сайт: https://spacecore.pro
Биллинг: https://billing.spacecore.pro
Email: support@spacecore.pro
Telegram: @spacecore_pro_chat
VK: vk.com/spacecore_pro

Not install

Здравствуйте.

Сервера без платы за установку:

Ryzen 5 3600 / 64 GB RAM / 2 x 512 GB NVMe (4 штуки) — 3900р

Заказать сервер можно написав в тикет: my.hshp.host/
Либо написать в Telegram: @roman_hosting