Что такое сервер? (Программное обеспечение)
Приветствую! Понятие «сервер» можно интерпретировать с
двух точек зрения: 1. Под понятием «сервер» можно подразумевать компьютер. Про такое понятие сервера у меня есть отдельная статья. 2. Под понятием «сервер» так-же может подразумеваться специальное программное обеспечение.
Важно не путать, и четко ощущать разницу между двумя понятиями. Бывает что в различных определениях непонятно, что именно подразумевается под сервером, то ли это физический компьютер, то ли программное обеспечение. Часто в различных определениях понятие «сервер» можно интерпретировать и как компьютер, выполняющий роль сервера, и как программное обеспечение, выполняющее роль сервера. Но бывает, что под сервером подразумевают только программное обеспечение.
Что же из себя представляет серверное программное обеспечение? Это программа, которая получает запросы от клиента, обрабатывает их, выполняет вычисления, и отправляет ответ клиенту. Более подробно взаимодействие клиента и сервера описано в отдельной статье.
Существует множество серверного программного обеспечения: веб-сервер, почтовый сервер, сервер баз данных (MySQL), VPN сервер, FTP сервер, и т. д. На компьютере может быть установлено сразу несколько такого ПО, например сразу веб-сервер, почтовый SMTP сервер, и сервер баз данных.
Как работают веб-приложения
Веб-приложения, которыми мы пользуемся каждый день, хоть и сильно отличаются под капотом, на высоком уровне по большей части похожи.
В этой статье мы рассмотрим, как работают веб-приложения, что такое клиент-серверная архитектура и какие технологии используются для общения клиента и сервера.
Любое веб-приложение, если оно работает в браузере, работает на 3 основных технологиях: HTML, CSS и JS. Ещё есть WASM, но о нём в этой статье мы говорить не будем.
Все приложения, которыми вы пользуетесь в браузере: GoogleDocs, Notion, Яндекс.Карты, Spotify, YouTube — сделаны с помощью этих технологий.
Но любое сложное приложение — это не только картинка в браузере, это ещё и данные, которые пользователи используют или создают. Эти данные нужно уметь хранить, обрабатывать и выводить.
Хранением и обработкой данных обычно занимается сервер или бэкенд.
Бэкенд — область веб-технологий, работающих на сервере, а также внутренняя часть серверной системы, занимается обработкой данных.
А архитектура, в которой участвуют сервер (бэкенд) и клиент (браузер, фронтенд) называется клиент-серверной.
Клиент-серверная архитектура
Начнём с самого понятия.
Архитектура — это описание системы на самом высоком уровне.
То есть при описании архитектуры мы не вдаёмся в подробности каждого конкретного модуля, а скорее описываем их взаимодействие между собой, «фиксируем договорённости» поведения каждого из них.
Клиент-серверная архитектура описывает, как взаимодействуют между собой клиент (в нашем случае фронтенд) и сервер (бэкенд).
Самый канонический вид такой архитектуры таков:
Клиент
Клиент обращается с запросами к серверу.
Запросы могут быть разные. Клиент может попросить сервер отдать какие-то данные или попросить их как-то подготовить перед отдачей. Или же может попросить сервер сохранить что-то, что передаст вместе с запросом сам.
Роль клиента для сервера в том, чтобы сообщить серверу, что нужно сделать с данными, которые хранятся в базе, или с данными, которые он передаёт.
Роль клиента для пользователя в том, чтобы представить данные в удобном виде и предоставить механизмы для их обновления.
Для веба клиент почти всегда браузер.
Сервер
Сервер принимает запросы от клиента.
Его роль в том, чтобы сохранять информацию от клиента в базе данных, обрабатывать её и предоставлять к ней доступ по некоторым правилам. Такие правила обычно называются бизнес-логикой.
На сервере помимо общения с клиентом могут запускаться какие-то фоновые задачи, например, индексирование информации в базе данных для более быстрого поиска, или запуск автоматических email-рассылок.
База данных
База данных (БД) — это хранилище всей пользовательской и служебной информации.
Её роль в том, чтобы обеспечивать быстрый и бесперебойный доступ к этой информации и собственно хранение.
Пример
Возьмём Твиттер. В этом приложении клиентом будет выступать весь его фронтенд: HTML-страницы, CSS-стили, JS-скрипты для взаимодействия пользователя с UI.
Сервером будет его бэкенд. Все технологии, которые используются, чтобы предоставлять информацию из баз данных клиенту через API.
Базами данных (в множественном числе, потому что их много) будут все технологии, которые занимаются хранением, дупликацией, резервированием данных и обеспечением бесперебойной работы.
Развитие веб-приложений
На клиент-серверной архитектуре построена большая часть приложений. Однако первые приложения всё же немного отличались от нынешних в деталях реализации. Главным отличием была полная перезагрузка страницы в ответ на любое действие.
Первые приложения
Самые первые веб-приложения не сильно отличались от обычных сайтов.
По сути это и были сайты, потому что вся бизнес-логика реализовывалась на сервере. Клиент лишь показывал результат в виде HTML-страниц пользователю и посылал запросы на другие страницы.
Банальный выбор сортировки списка или таблицы требовал перезагрузки страницы. Сейчас это кажется анахронизмом, но первые приложения работали исключительно таким образом просто потому, что в браузерах не было инструмента для альтернативного общения.
В начале нулевых появился так называемый «Веб 2.0», с которым пришёл AJAX.
AJAX (Asynchronous JavaScript and XML) — общение между клиентом и сервером без перезагрузки страницы.
Когда мы говорим, что какое-то приложение использует AJAX, мы имеем в виду, что при нажатии, например, на кнопку сортировки списка или таблицы, страница не перезагрузится, а сортировка произойдёт как бы «в фоне».
При нажатии браузер пошлёт запрос на сервер, в котором сообщит, что ему необходимо отсортировать такой-то список по такому-то критерию.
Сервер обработает запрос, достанет нужные данные, отсортирует их и отправит клиенту готовый кусок интерфейса, который клиент уже вставит в документ.
Заметьте, что мы всё ещё не передаём данные в чистом виде. Сейчас на клиенте мы принимаем кусок HTML-разметки, который потом встраиваем в нужное место в документе.
Это, безусловно, удобнее для пользователя, чем перезагружать страницу в целом, но всё ещё не идеальный вариант для разработчиков.
Современные приложения
В современных приложениях между клиентом и сервером общение строится именно на данных, а не на отрендеренных кусках разметки. Чаще всего для такого общения выбирают JSON.
Сейчас большая часть приложений работает так:
- Клиент делает первичный запрос на сервер.
- Сервер отвечает HTML-страницей, иногда с набором каких-то данных внедрённых в виде JS-объекта в конце страницы.
- Страница может быть либо отрисована на сервере и тогда клиенту придёт готовый HTML.
- Либо отрисовкой будет заниматься сам клиент с помощью какой-нибудь библиотеки, например, React. В этом случае от сервера приходит просто набор необходимых данных.
Плюсов такого общения (когда передаются только данные) несколько:
- Сервер и клиент становятся независимыми друг от друга. Сервер может ничего не знать об устройстве страниц, ему достаточно лишь уметь работать с БД и обрабатывать данные (первичная отрисовка может быть сделана самим сервером с помощью SSR).
- Количество информации, которое приходится передавать и принимать, меньше — а это уменьшает объём трафика.
- Логика приложения на сервере может быть проще, потому он и клиент становятся менее зависимы друг от друга в плане формата данных.
Разделение ответственности
Такое общение между сервером и клиентом очень напоминает паттерн MVC.
MVC (Model-View-Controller) — структура приложения, в которой за данные, их обработку и их вывод отвечают три разных сущности.
- Модель (model) отвечает за данные и их структуру.
- Представление (view) — за их отображение.
- Контроллер (controller) — за их обработку.
Если попробовать сравнить классическую клиент-серверную архитектуру с MVC, то можно сравнить БД с моделью, сервер с контроллером, а клиент с представлением.
В самых первых приложениях, в принципе, так и было. Сейчас, однако, клиент стал сложнее, поэтому MVC может быть и часть архитектуры клиентского приложения.
MVC на клиенте
Возьмём для примера Notion. Его веб-версия работает прямо в браузере, однако это полноценный текстовый редактор.
Большая часть работы при вводе текста происходит на клиенте. Чтобы такие сложные приложения работали, а в их коде можно было разобраться, клиентский код разработчики тоже стараются писать по правилам и следуя лучшим архитектурным практикам.
Одной из таких практик как раз является разделение данных и представления.
Как бы текстовый редактор сделали 20 лет назад
Если забыть про невозможность сохранить написанное на сервере, то попробовать написать текстовый редактор можно было и тогда. Но, скорее всего, результатом был бы кусок разметки с инлайновыми стилями и текстом внутри.
Работать такими данными, которые перемешаны с особенностями представления, не удобно, а иногда и невозможно.
Текстовые редакторы сейчас
. чаще всего делают, разделяя данные от их представления.
Так нам больше не нужно находить текст и чистить его от стилей, потому что в нём содержится только текст и некоторые его атрибуты.
- Это делает работу с данными сильно проще — можно выгрузить документ в разных форматах: . md , . html , . txt .
- С таким представлением проще работать в самом коде — отчего и сам код становится проще для понимания.
- Его удобнее хранить в памяти, как состояние приложения.
Состояние приложения
Текстовый редактор из нашего примера выше — это приложение с состоянием.
Состояние приложения — это все данные этого приложения на текущий момент.
В случае с текстовым редактором — это весь текст, который пользователь ввёл, а также результаты преобразований над этим текстом.
Разумеется, текстовые редакторы не единственный вид таких приложений. Любое приложение, которое хранит что-то перед отправкой (или даже без отправки) на сервер — это приложение с состоянием.
Плюсы в выделении состояния те же:
- данные перестают зависеть от того, как мы хотим их представлять;
- их проще обрабатывать и хранить;
- представление проще менять.
Как правило, состояние в приложениях на JS — это какой-то объект или массив объектов в памяти.
Такой вид состояния не только удобен в использовании внутри приложения, но ещё и прост в сохранении с помощью JSON.
Кроме этого приложения, в которых за состояние отвечает отдельный модуль, проще развивать и изменять.
Сейчас есть много подходов и инструментов для управления состоянием. Из самых популярных можно назвать: Redux (и основанные на его подходе Vuex, NgRx), MobX, Overmind.
JSON — один из самых популярных форматов данных. Он немногословен, понятен и человеку, и компьютеру, много языков с ним уже умеют работать.
В вебе JSON, можно сказать, стандарт, потому что используется как формат по умолчанию во многих фреймворках.
Состояние из примера выше в формате JSON выглядело бы так:
. и мы могли бы прямо в таком виде отправить его на сервер, чтобы сохранить в БД.
Запросы и ответы
Как мы помним, клиент-серверная архитектура строится на запросах и ответах. Разберёмся, что использует браузер, чтобы послать на сервер какой-то запрос.
fetch
На уровне приложения мы используем встроенное браузерное API, а именно — fetch . Это глобальный метод для отправки запросов.
В примере выше, чтобы сохранить состояние на сервере, мы бы использовали его примерно так:
Здесь мы отправляем запрос по адресу / api / save — text с телом JSON . stringify ( State ) . Адрес и тело (данные) — понятно, а что такое method : «POST» ?
HTTP-глаголы
Поле method — это так называемый HTTP-глагол.
HTTP-глагол, потому что его значениями могут быть лишь GET , POST , PATCH , PUT , DELETE и ещё несколько не так часто и явно используемых глаголов.
Они указывают, какое действие мы хотим выполнить. В примере method : «POST» сообщит серверу, что мы хотим создать новый ресурс и сохранить в него содержимое body .
Если бы мы хотели получить какой-то ресурс, мы бы использовали GET . Для редактирования — PATCH , для замены — PUT , а для удаления — DELETE .
HTTP-глагол, потому что используется в протоколе HTTP — протоколе передачи данных, которым по умолчанию пользуются браузеры при общении с сервером.
Описывать сам протокол мы не будем, это большая спецификация, для которой бы понадобилась отдельная статья.
Внимательные читатели могли заметить, что список HTTP-глаголов выше похож на список методов из RESTful API .
REST (Representational State Transfer) — стиль общения компонентов, при котором все необходимые данные указываются в параметрах запроса.
Отличительная особенность этого стиля — это стиль построения адресов и выбор метода.
Как мы можем видеть, основа адреса не меняется, а желаемое действие выражается методом.
Списки HTTP-глаголов и REST-методов действительно похожи, потому что REST основывается на HTTP 1.0. Метод — это один из параметров запроса в REST.
Сейчас именно на основе REST работает множество сервисов и приложений.
Развитие веба и объёмы данных
С развитием веба и интернета в целом пришло время больших объёмов данных. Картинки по 10 МБ уже никого не удивляют.
Вместе с большими объёмами пришли и проблемы с их передачей, потому что трафик поначалу был очень дорогим. Он и сейчас в некоторых случаях не дешёвый.
Кэширование
Отчасти решением стало кэширование ресурсов. С картинками это помогло — картинки из кэша не съедают трафик, потому что не гонятся по сети.
Со скриптами и стилями — помогло отчасти, потому что объём лишь одна часть проблемы. Вторая часть — это парсинг и исполнение. Особенно остро эта проблема стоит со скриптами, потому что скрипты весом в 10 МБ уже тоже не редкость.
Сейчас разработчики всеми силами стараются уменьшать количество кода, которое браузеру необходимо скачать и исполнить, чтобы сделать приложения быстрее и легче.
Код-сплиттинг
Одним из решений стал код-сплиттинг. Это техника, при которой в скрипте оказывается только необходимый на конкретной странице код, а остальной код догружается по мере необходимости.
Middle-end
Кэширование и код-сплиттинг решают большую часть проблем, однако остаётся ещё одно место, где мы можем передавать слишком много лишней информации — сами запросы.
REST известен не только своим удобством, но и (иногда) чрезмерной избыточностью.
Проблема в том, что REST система проектируется так, чтобы как можно реже меняться при изменении клиента. Из-за этого данные, отдаваемые в ответ, могут содержать детали, которые клиентом использоваться не будут.
Просто так их убрать зачастую бывает нельзя, потому что это противоречит обратной совместимости. Плодить много однотипных эндпоинтов, которые будут отличаться небольшой деталью — дорого и нецелесообразно.
Поэтому сейчас сообщество смотрит в сторону некого мидл-энда — такого слоя между клиентом и сервером (или сразу БД), который бы удалял всё лишнее, что клиенту не требуется, и отдавал бы лишь необходимые данные, таким образом сократив объём. Как, например, GraphQL.
Заключение
В этой статье мы рассмотрели лишь самые основы работы веб-приложений, не затрагивая деталей.
Мы узнали о клиент-серверной архитектуре, разделении данных от представления и том, как они используются в современных приложениях. Также мы рассмотрели, что такое состояние приложения и поговорили о REST, как одном из распространённых способов построения API.
Эти понятия помогут вам понять работу большей части приложений, с которыми вы можете столкнуться.
Что такое сервер и как он работает
Каждый сайт, который вы посещаете, каждое отправленное в интернете письмо, каждый персонаж в игровой вселенной любимой MMO – все эти цифровые сущности живут на серверах. Давайте разберемся, что представляют собой серверы и почему так важны для работы всего интернета.
Разбираем понятие «сервер»
Изначально сервером называли приложение или процесс, запущенный на компьютере. Термин появился в 1969 году в документации, описывающей ARPANET (это предшественник интернета). Он произошел от слова serving, то есть «служить», которое хорошо описывает деятельность сервера в общих чертах.
Со временем термин немного расширился и теперь описывает любое устройство, на котором запущены серверные приложения. То есть те, что обслуживают пользователей в той или иной стези.
Если говорить чуть более ясно, то это ПК, который беспрерывно работает и выступает в качестве площадки для разработки, базирования сетевых шлюзов, создания игровых платформ или хранения данных на постоянной основе.
Такие устройства делятся на категории по различным параметрам. В связи с этим обретают новые имена. Например, VDS, VPS, виртуальный хостинг. О том, что эти названия под собой подразумевают, поговорим позже. Говорю об этом, чтобы вы не смущались, если в дальнейшем буду называть сервер просто компьютером, VPS или «машиной».
Для чего нужны серверы?
Основное направление — поддержка интернет-ресурсов. Количество задач, возлагаемых на сервер велико. Вот несколько сценариев, в которых необходимы подобные устройства:
- хостинг сайтов;
- разработка веб-приложений;
- платформа для приема и отправки электронных писем;
- дистанционное управление принтерами;
- хранение файлов;
- создание общего рабочего пространства для сотрудников одной фирмы;
- организация среды для совместной игры в MMORPG и другие онлайн-видеоигры;
- создание шлюзов (proxy или VPN), заменяющих информацию о подключившемся компьютере на другую;
- добыча криптовалюты.
Почему их никогда не выключают?
Все описанные выше задачи подразумевают наличие аппаратной и программной платформы, которая постоянно находится в активном состоянии, обеспечивает высокую скорость и достаточную стабильность, чтобы сайты, приложения, почта и видеоигры неожиданно не отключались. Весь интернет держится на таких компьютерах.
Люди всегда хотят играть в любимые ММО, круглосуточно переписываются по электронной почте, работают и заходят на сайты. Это не физический магазин или компьютерный клуб. Нельзя просто взять и закрыть сайт на ночь и открыть к утру. Они должны быть доступны круглосуточно, а любое временное отключение считается критической ошибкой администрации ресурса, которая сильно бьет по репутации.
На серверы полагаются банковские службы, мессенджеры, такси, сервисы доставки еды, курьеры, государственные службы. Можно представить себе масштаб трагедии, если какой-то из удаленных компьютеров, поддерживающих инфраструктуру страны, вырубится.
Поэтому ими занимаются профессиональные компании, называемые хостинг-провайдерами. Они закупают мощное «железо», нанимают команду инженеров, обслуживающих все накупленное, и обеспечивают людей бесперебойным доступом к нужному им оборудованию.
Типы серверов
Есть несколько вариантов разделения серверов на группы. Мы рассмотрим две конкретные системы сортировки.
По назначению
- Веб-сервер — компьютерная программа, нон-стоп обрабатывающая запросы пользователей и показывающая им HTML-страницы. Проще говоря, это любое устройство, на базе которого работает сайт.
- Сервер приложения — программа, поддерживающая определенную сетевую логику в полноценном приложении. То есть хранение и перенос данных в том же Evernote осуществляется через такие «машины».
- Прокси-сервер — шлюз между пользователем и ресурсом, к которому он пытается подключиться. Часто подменяет IP-адрес и местоположение клиента, что делает его полезным при посещение заблокированных сайтов.
- Почтовый — получает письма, отправляет и хранит их на встроенных жестких дисках.
- Файловый — хранилище любых документов, медиа-контента и всего, что можно хранить и чем можно делиться. Примеры таких серверов – Dropbox или iCloud Drive.
- Виртуальный — утилита-гипервизор, определяющая себя как отдельный компьютер, но таковой не являющаяся. С точки зрения пользователей и администратора — обычный физический сервер, но чисто технически — определенное количество ресурсов компьютера, выделенное под арендатора с помощью технологии виртуализации.
- Сервер сетевой политики — шлюз безопасности, через которой подключаются сотрудники одной компании, чтобы начальство могло контролировать их поведение в интернете, смотреть загружаемые файлы и тому подобное.
- Сервер баз данных (SQL) — отвечает за безопасное хранение одной или нескольких баз данных. Также помогает изменять и передавать информацию, системно хранящуюся в тех самых базах.
- Компьютер для удаленного управления принтером — программа на любом ПК, которая контролирует очередь печати документов, отправленных с разных устройств в офисе или учебном заведении.
По техническим характеристикам
Теперь разберемся, почему серверы имеют разные названия.
Физический выделенный сервер
Первичный вариант. Компьютер, который расположен в хостинге. Полноценный ПК. Мало чем отличающийся от того, что стоит у вас дома. Разве что он мощнее и никогда не выключается. Любой тип сервера в плане назначения может базироваться на таком PC.
Блейд-сервер
Примерно то же самое, только в ультракомпактном корпусе. Это попытка выдать каждому арендатору полноценное выделенное «железо», но при этом сократить издержки. Это делается за счет общего питания и некоторых других компонентов, которые можно делить между клиентами.
Виртуальный хостинг
Общее пространство на одном компьютере, которое регулируется единственным администратором и предлагает клиентам пользоваться ресурсами выбранной машины дешевле, но вместе с тем лишиться ряда функций и независимости.
VDS
Виртуальный выделенный сервер. Имитация реального «железа» с помощью гипервизора. Каждый арендатор получает практически полноценный ПК, несмотря на то, что чисто технически и физически это не так. Ограничений VDS практически не имеет. Можно ставить Windows Server и даже контролировать параметры BIOS.
VPS
То же самое, что и VDS. Только с иной технологией виртуализации. Более дешевой и ограниченной даже в плане программного обеспечения. Сюда нельзя установить Windows, только дистрибутивы Linux.
Как другие компьютеры подключаются к серверу?
VPS, VDS и любой другой сервер так же, как и обычные компьютеры, подключается к сети через кабельное соединение. Попав в интернет, он тут же становится доступен другим пользователям.
Подключение со стороны клиентов происходит разными путями в зависимости от того, что представляет собой сервер. Если на нем базируется веб-сайт, то в роли клиента выступает браузер, который через доменное имя подключается к VDS и получает от него нужную пользователю информацию. Доменное имя, естественно, моментально транслируется в стандартный IP-адрес. И адрес может оставаться прежним, даже если домен был в какой-то момент изменен.
В других случаях это работает похожим образом. Разве что аспекты работы программ, подключаемых к удаленным «машинам», могут слегка варьироваться.
Где находятся серверы?
Я уже упомянул выше хостинг-провайдеров. У них. Хостинг — это компания, которая фокусируется на обеспечении своих клиентов серверными мощностями. Обычно они арендуют крупное здание, в котором располагаются сотни и тысячи ПК с различными видами «железа» и виртуальными «машинами» на них.
Эти компьютеры надежно охраняются наемной охраной, датчиками движения, системами защиты от пожара и прочими решениями в зависимости от того, какие угрозы предвидит провайдер.
Программная защита тоже играет роль. Хостинг обязан сохранять конфиденциальность клиентов, оберегать их VDS от вирусов и атак извне. Регулярно делать резервные копии данных каждого арендатора, чтобы даже в случае форс-мажора можно было бы восстановить максимум полезной информации и файлов.
Также значимую роль играет геолокация. От расположения дата-центра зависит скорость работы проектов, базированных на удаленном ПК. Игровой сервер, расположенный в Варшаве, будет быстрее и стабильнее для жителей Европы, чем аналогичный в условном Мурманске. Ну и подчиняются такие серверы законам разных стран.
Можно ли использовать любой компьютер в качестве сервера?
Да. Хоть ноутбук в сервер превращайте. Всего-то надо установить подходящее программное обеспечение. Поставил FTP-клиент, вот тебе и хранилище файлов. Поставил ПО для старта игровых платформ, вот тебе очередная площадка для игры в World of Warcraft. С хостингом веб-сайтов ситуация аналогичная.
Правда, нужно учесть ряд моментов:
- Придется держать ПК в рабочем состоянии постоянно. Иначе пользователи сразу потеряют доступ к вашим проектам.
- PC должен быть мощным. Очень мощным. Далеко не каждый ноутбук вытянет даже небольшой сайт, не говоря уже об игровых серверах или чем-то в подобном духе.
- Превращение личного PC в общедоступную платформу подвергает его новым угрозам. Придется заморочиться по поводу обеспечения безопасности.
- Ну и не стоит забывать, что ресурсы, требующиеся на поддержку серверных функций, лишат владельца компьютера возможности использовать его для решения своих задач.
Отличия сервера от обычного компьютера
И тот, и другой работают на идентичной архитектуре процессора. Только в серверные «машины» устанавливается несколько гнезд под чипы. То есть на одной материнской плате «живут» 2, 3, 4, а то и более процессора. Также на них используется память с системой коррекции ошибок.
На них устанавливаются запасные компоненты с предохранителями. На тот случай, если один из сетевых кабелей выйдет из строя, его работу на себя возьмет второй. С блоками питания схожая история. Лишившись питания от него, ПК получит нужную энергию от запасного. Предусмотреть подобное в домашних условиях на обычном компьютере тяжело.
Визуально серверы тоже отличаются. В дата-центрах их монтируют в компактные блоки. Дизайн же домашних системных блоков не предусматривает портов, систем быстрой замены компонентов и других особенностей удаленных «машин».
Программное обеспечение тоже отличается. Нужна платформа, лицензированная для работы в качестве виртуальной машины. Ну и зачастую на них стоят дистрибутивы Linux без графической оболочки с минимальным необходимым набором приложений.
Как выбрать подходящий сервер?
Есть куча аспектов, на которые надо обращать внимание. Но я бы предложил положиться на хорошего хостинг-провайдера. Он знает свое дело. Предложит подходящее «железо», обеспечит необходимым программным обеспечением.
Можно зайти на главную страницу Timeweb и спокойно выбрать доступный вариант. Можно купить виртуальный хостинг, если грядет мелкий проект, не требующий особого контроля. Можно купить VDS, чтобы сэкономить на покупке выделенного сервера, но при этом получить доступ к расширенным функциям. Для тех, кто строит онлайн-магазин или собрался открывать игровой сервер, есть выделенные «машины». Причем все они учитывают современные реалии. Есть защита от DDoS-атак, ежедневное резервное копирование, круглосуточная техподдержка и физическая защита дата-центров от любой неприятности.
Так что в первую очередь обращайте внимание на репутацию хостинга. Затем рассматривайте его предложения и не беспокойтесь о других технических аспектах.