В характеристиках физического сервера рядом с процессором, памятью и дисками почти всегда указана ещё одна цифра: 100 Мбит/с, 1 Гбит/с, иногда 10 Гбит/с. Рядом может стоять безлимитный трафик, несколько десятков терабайт в месяц или условие, которое на первый взгляд вообще трудно связать со скоростью сайта. Из-за этого сетевой канал нередко выбирают по принципу чем больше, тем лучше, хотя для большинства веб-проектов гораздо важнее понять, какой объём данных сервер реально передаёт посетителям и насколько высокими бывают короткие пики нагрузки.
Скорость порта физического сервера показывает верхнюю границу пропускной способности его сетевого подключения. Это не обещание, что каждый посетитель сайта будет загружать данные на такой скорости, и не гарантия, что сервер постоянно сможет передавать весь заявленный объём во внешний интернет. На результат одновременно влияют сеть дата-центра, маршруты между операторами, местоположение пользователя, состояние внешних каналов и сама конфигурация сервера.
Тем не менее слишком медленный порт действительно способен стать узким местом. Особенно это заметно на проектах с большими изображениями, файлами, видео, резервными копиями, собственным облачным хранилищем или высокой одновременной посещаемостью. Поэтому сетевые параметры физического сервера стоит оценивать так же осмысленно, как процессор или дисковую подсистему.
Что означает скорость порта физического сервера
Если в тарифе указан порт 1 Гбит/с, это означает, что сетевой интерфейс сервера способен передавать данные через это подключение с пропускной способностью до одного гигабита в секунду. В идеальных условиях это примерно 125 мегабайт данных в секунду, но в реальной работе полезная скорость будет ниже из-за служебного трафика, особенностей протоколов и ограничений на других участках сети.
Порт 100 Мбит/с теоретически соответствует примерно 12,5 мегабайта в секунду. Для обычного сайта это совсем не обязательно мало. Если страницы относительно лёгкие, изображения оптимизированы, а большая часть статических файлов отдаётся через CDN, даже такой канал способен обслуживать довольно серьёзный веб-проект.
Проблема появляется тогда, когда большое количество посетителей одновременно начинает передавать значительный объём данных. Представим страницу весом 2 МБ. Если её открывает один человек, сетевой канал почти не замечает такой нагрузки. Если одновременно страницу загружают сотни пользователей, ситуация уже совершенно другая. К этому добавляются изображения, JavaScript, CSS, API-запросы, загрузки файлов и другие обращения.
При этом не стоит просто умножать вес страницы на число посетителей и считать получившуюся цифру необходимой скоростью порта. Пользователи заходят не одновременно, браузеры кэшируют часть файлов, статический контент может находиться в CDN, а некоторые данные сжимаются. Реальная нагрузка обычно значительно сложнее.
Почему 1 Гбит/с не делает сайт в десять раз быстрее
Если сервер сейчас подключён через 100 Мбит/с, а фактическое использование сети даже в часы пик не превышает 20 Мбит/с, переход на 1 Гбит/с практически не изменит время загрузки страниц. Сайт уже не ограничен сетевым каналом.
Задержка может находиться совсем в другом месте. PHP долго выполняет код, база данных медленно отвечает на запросы, процессор перегружен, не хватает оперативной памяти или сервер ждёт операции с диском. В такой ситуации увеличение пропускной способности похоже на расширение пустой автомобильной дороги: полос стало больше, но пробки на ней и раньше не было.
И наоборот, если мониторинг регулярно показывает загрузку порта около его предела, увеличение скорости действительно может дать заметный результат. В моменты насыщения канала данные начинают ждать своей очереди, загрузки растягиваются, а пользователи получают файлы медленнее.
Особенно хорошо это видно на файловых сервисах. Допустим, сервер раздаёт большие архивы или резервные копии. Несколько пользователей одновременно начинают скачивание, и 100-мегабитный канал быстро распределяется между ними. При 1 Гбит/с доступный запас оказывается значительно выше.
Для обычного интернет-магазина ситуация обычно спокойнее. Страница магазина может содержать много изображений, но если они правильно оптимизированы и значительная часть статики кэшируется, сетевой канал редко становится главным ограничением раньше процессора, базы данных или самого приложения.
Поэтому при переходе на физический сервер имеет смысл смотреть не только на красивую цифру скорости порта, но и на реальный профиль нагрузки проекта.
Порт сервера и скорость интернета дата-центра не одно и то же
Даже если сетевой интерфейс машины работает на 1 Гбит/с, данные всё равно проходят через инфраструктуру дата-центра. Сервер подключён к коммутаторам, затем к сети провайдера, а дальше трафик уходит к другим операторам и точкам обмена.
Хороший дата-центр имеет несколько независимых внешних подключений и достаточный запас общей пропускной способности. Если инфраструктура перегружена или маршрутизация построена неудачно, огромный порт конкретного сервера не решит проблему полностью.
Именно поэтому два сервера с одинаковой характеристикой 1 Гбит/с способны по-разному работать с пользователями из разных регионов. Для российского сайта значение имеет не только страна размещения, но и качество маршрутов до сетей, которыми пользуется его аудитория.
Если большинство посетителей находится в России, полезно проверить задержку и маршруты именно из российских сетей. Сервер может находиться географически относительно близко, но трафик идти сложным маршрутом через несколько операторов. Бывает и обратная ситуация, когда хорошо связанный зарубежный дата-центр показывает вполне нормальную задержку до части российской аудитории.
Для обычного сайта разница в несколько миллисекунд редко имеет решающее значение. Для игровых серверов, интерактивных приложений, телефонии и других чувствительных к задержке сервисов география и маршрутизация становятся значительно важнее.
Сколько трафика нужно физическому серверу
Скорость порта и объём трафика связаны между собой, но это разные характеристики. Скорость показывает, насколько быстро данные могут передаваться в конкретный момент. Трафик показывает, сколько данных сервер передал и получил за определённый период, обычно за месяц.
Провайдер может предложить порт 1 Гбит/с и при этом ограничить месячный объём, например несколькими десятками терабайт. Другой тариф использует те же 1 Гбит/с, но называется безлимитным. Третий может иметь ограничение средней полосы или особые правила для входящего и исходящего трафика.
Поэтому слово безлимитный необходимо читать вместе с условиями тарифа. Оно не всегда означает возможность круглосуточно загружать гигабитный канал на сто процентов без каких-либо ограничений. У провайдера могут существовать правила разумного использования, ограничения по средней полосе или другие технические условия.
Для большинства обычных сайтов десятки терабайт месячного трафика являются большим объёмом. Но медиасервисы, хранилища, сайты с крупными файлами и собственная раздача видео способны расходовать его значительно быстрее.
Оценить потребление можно по статистике существующего проекта. Панель сервера, система мониторинга или данные сетевого интерфейса показывают, сколько информации было передано за предыдущие месяцы. Это намного надёжнее универсальных таблиц.
Если проект только запускается, можно сделать приблизительную оценку. На трафик влияют средний вес страницы, количество просмотров, изображения и файлы, которые посетители загружают непосредственно с сервера. Но такой расчёт лучше воспринимать как ориентир, а не точный прогноз.
Представим небольшой корпоративный сайт, где большинство страниц весит относительно немного и посещаемость измеряется тысячами или десятками тысяч просмотров в месяц. Для него сетевой трафик обычно не становится проблемой физического сервера вообще. Выбирать дорогой расширенный канал только ради сайта такого масштаба нет необходимости.
Совсем другая картина у проекта, который раздаёт пользователям файлы по несколько гигабайт. Там один человек способен создать больше трафика, чем сотни посетителей обычного сайта. Аналогично работает видеоконтент: продолжительная передача потока каждому зрителю быстро увеличивает как текущую нагрузку на канал, так и месячный объём.
Большие изображения тоже имеют значение. Фотогалерея, где каждая фотография отдаётся непосредственно с сервера в исходном размере по 10-20 МБ, способна расходовать сетевые ресурсы совершенно иначе, чем тот же сайт с оптимизированными версиями изображений.
Поэтому экономить трафик зачастую правильнее не ограничениями, а архитектурой. Изображения оптимизируют, статические файлы кэшируют, тяжёлый контент переносят в специализированные хранилища, а популярные ресурсы отдают через CDN. В результате сам физический сервер занимается прежде всего приложением и базой данных, а не бесконечной раздачей одних и тех же файлов.
CDN особенно полезна для географически распределённой аудитории. Копии статических ресурсов размещаются на пограничных узлах ближе к пользователям, поэтому часть запросов вообще не доходит до исходного сервера. Это одновременно уменьшает нагрузку на его порт и способно ускорить доставку контента.
Но считать CDN обязательной для каждого физического сервера тоже не нужно. Если проект работает преимущественно для одной страны, страниц немного и сетевой канал имеет огромный запас, дополнительная инфраструктура может не дать заметной практической пользы.
Отдельно стоит учитывать резервное копирование. Если сервер каждую ночь отправляет сотни гигабайт на внешнее хранилище, этот объём тоже проходит через сеть. При больших базах данных и частых бэкапах служебный трафик способен стать заметной частью общего потребления.
То же относится к репликации. Если основная база постоянно передаёт изменения на второй сервер, данные между узлами создают постоянный поток. Провайдеры иногда не тарифицируют внутренний трафик между серверами в одном дата-центре или собственной сети, но это нужно уточнять отдельно.
Для инфраструктуры из нескольких машин наличие внутренней сети может оказаться не менее важным, чем скорость внешнего порта. База данных, файловое хранилище и веб-сервер могут обмениваться значительными объёмами информации, которую нет смысла отправлять через публичный интернет.
Есть ещё один параметр, который редко замечают при первом сравнении тарифов, — симметричность канала. Сервер сайта в основном отдаёт данные пользователям, поэтому исходящая пропускная способность особенно важна. В профессиональных дата-центрах серверные подключения обычно не похожи на домашний интернет, где скорость загрузки и отдачи может сильно различаться, но условия конкретной услуги всё равно стоит проверить.
Для проекта с большим количеством пользовательских загрузок важен и входящий поток. Например, облачное хранилище, сервис обмена файлами или система приёма видеоматериалов получает большие объёмы данных от клиентов, поэтому сеть работает активно в обе стороны.
Если сервер подвергается DDoS-атаке, размер его обычного порта тоже не следует путать с возможностями защиты. Атака может значительно превышать пропускную способность самой машины. В этом случае вредоносный трафик должен фильтроваться выше по сети провайдера, до того как он забьёт подключение сервера.
Поэтому для коммерческого проекта полезно узнать, входит ли базовая защита от сетевых атак в услугу и какие ограничения у неё существуют. Большая цифра 10 Гбит/с в характеристиках порта сама по себе не является защитой от DDoS.
Выбирать между 100 Мбит/с и 1 Гбит/с стоит исходя из нагрузки и разницы в стоимости. Если гигабитный порт является стандартной частью тарифа без существенной переплаты, обычно нет причин специально от него отказываться. Он создаёт хороший запас на кратковременные пики, резервное копирование, перенос больших файлов и дальнейший рост проекта.
Если же увеличение скорости стоит заметно дороже, сначала посмотрите мониторинг. Сервер, который месяцами использует в пике 15-20 Мбит/с, не получает практической выгоды от перехода на 10 Гбит/с. Эти деньги могут быть полезнее вложить в более быстрые диски, дополнительную память, резервное копирование или администрирование.
С другой стороны, физический сервер часто арендуют на несколько лет, а нагрузка проекта за это время меняется. Поэтому выбирать порт совсем без запаса тоже не стоит. Если текущие пики уже приближаются к 70-80 процентам доступной полосы, лучше подумать об увеличении пропускной способности до того, как пользователи начнут регулярно сталкиваться с ограничением.
Важно смотреть именно на пики, а не только на среднемесячное значение. Средняя загрузка в 5 Мбит/с может выглядеть смешной, но если каждый вечер во время массовой рассылки или публикации нового контента канал на несколько минут достигает 100 Мбит/с, проблема существует именно в эти минуты.
Современные системы мониторинга позволяют видеть график использования сети и быстро понять характер нагрузки. Если линия никогда даже близко не подходит к верхней границе порта, сеть пока не является узким местом. Если график регулярно упирается в потолок и некоторое время идёт горизонтально вдоль него, это уже повод разбираться.
Стоит также уточнить, является заявленная скорость гарантированной или максимальной. У физического сервера обычно гораздо меньше неопределённости, чем у дешёвого общего хостинга, но условия подключения у провайдеров всё равно различаются. Иногда один гигабит предоставляется на физическом интерфейсе, а фактическая внешняя полоса регулируется тарифом.
Перед заказом физического сервера достаточно проверить несколько вещей: скорость внешнего порта, месячный лимит трафика, правила безлимитного использования, стоимость превышения лимита, возможность увеличить канал без переезда на другую машину и наличие внутренней сети между серверами. Для проекта, чувствительного к атакам, сюда добавляются условия DDoS-защиты.
В большинстве случаев для обычного коммерческого сайта нет необходимости охотиться за максимально возможной сетевой скоростью. Гигабитный порт сегодня даёт очень большой запас многим веб-проектам, а иногда достаточно и меньшей полосы. Намного важнее, чтобы сеть дата-центра была стабильной, маршруты до основной аудитории были нормальными, а условия по трафику не преподносили неожиданных счетов после успешного месяца.
Хорошая конфигурация физического сервера вообще редко состоит из максимальных характеристик по каждому пункту. Она состоит из ресурсов, которые соответствуют реальной задаче. Процессор должен успевать обрабатывать запросы, памяти должно хватать приложениям и базе, накопители должны справляться с операциями, а сетевой канал — передавать данные без регулярного насыщения. Если порт имеет большой запас и почти всё время простаивает, это нормально. Если за этот запас приходится существенно переплачивать, уже стоит считать, действительно ли он нужен.
Поэтому скорость сети лучше выбирать не по впечатляющей цифре в тарифе, а по двум показателям: сколько данных проект передаёт в пиковый момент и сколько трафика набирается за месяц. Эти значения быстро показывают, нужен ли серверу гигабитный канал, действительно ли имеет значение безлимит и когда повышение скорости принесёт реальную пользу вместо красивой строки в характеристиках.
