Веб-трафик

Веб-трафик появился вместе со всемирной паутиной. Проект «Всемирная паутина» был предложен Тимом Бернерсом-Ли в ЦЕРН в марте 1989 года, к концу 1990 года работали первый браузер и первый веб-сервер, а в августе 1991 года проект был анонсирован в группе новостей alt.hypertext, и сайт info.cern.ch стал доступен за пределами ЦЕРН^[5]. Каждое обращение к узлу порождало поток HTTP-запросов и ответов, объём которого регистрировался в журналах сервера, — так возникли первые данные о трафике, использовавшиеся преимущественно для технического контроля^[4]. По мере коммерциализации Интернета в середине 1990-х годов появились счётчики посещений и анализаторы журналов, а трафик стал оцениваться и с точки зрения аудитории сайтов^[6]. К середине 1990-х годов трафик всемирной паутины превысил потоки конкурировавших сервисов, которые Всемирная паутина затем вытеснила^[3].

На рубеже 1990-х и 2000-х годов методы измерения трафика, существовавшие в сетевой инженерии, были активно применены к Всемирной паутине. В 1994 году исследование трафика Ethernet показало статистическое самоподобие сетевых нагрузок, опровергшее привычные модели телефонии^[7]; вскоре самоподобие и распределения размеров файлов с тяжёлыми хвостами были обнаружены и в трафике всемирной паутины^[8]. Эти работы заложили основу моделей нагрузки, применяемых при проектировании сетей и тестировании серверов; на их идеях построен, в частности, генератор нагрузочных тестов SURGE^[9]. Темпы роста трафика систематически анализировались в работах Коффмана и Одлызко, которые исследовали устойчивое удвоение объёмов за сравнимые интервалы времени и задали вопрос о существовании образного «закона Мура для данных»^[3].

Практика учёта посещаемости оформилась в конце 1990-х годов: простые счётчики посещений уступили место специализированным анализаторам журналов и системам статистики, а владельцы сайтов начали сопоставлять трафик с доходами от рекламы; именно в этот период сложились базовые категории анализа — визит, посетитель, источник перехода^[6]. Одновременно измерение трафика стало предметом отраслевого аудита: сопоставимые методики подсчёта были необходимы рекламному рынку для покупки и продажи аудитории^[4]. Массовое распространение шифрования в 2010-е годы перераспределило сферы применения методов: содержательный анализ остался доступен конечным участникам соединения, тогда как сетевые наблюдатели перешли к учёту объёмов и адресов^[4].

2000-е и 2010-е годы изменили структуру трафика. В июле 2001 года червь Code Red за считанные дни поразил сотни тысяч серверов и породил аномальные всплески обращений, впервые наглядно показав связь трафика с информационной безопасностью^[10]. Развёртывание сетей доставки контента перенесло значительную часть трафика ближе к пользователям^[11], а переход аудитории к потоковому видео сделал видеосервисы крупнейшим источником нагрузки: исследование трафика YouTube на границе кампусной сети показало масштаб явления уже в 2007 году^[12]. По прогнозу Cisco Visual Networking Index, опубликованному в 2018 году, глобальный IP-трафик должен был вырасти с 122 эксабайт в месяц в 2017 году до 396 эксабайт в месяц в 2022 году, а доля видео — приблизиться к 82 %. Эти значения являются прогнозом, а не измерением фактического трафика 2022 года^[13]. Если рост сохраняет экспоненциальный характер с периодом удвоения ${\displaystyle T_{2}}$, объём трафика описывается соотношением ${\displaystyle V(t)=V_{0}\cdot 2^{(t/T_{2})}}$^[3].

Веб-трафик складывается из множества индивидуальных обращений к ресурсам^[14]. Пользователь вводит адрес или переходит по ссылке; браузер по доменному имени узнаёт адрес узла через DNS, устанавливает транспортное соединение, при необходимости шифрует канал и посылает HTTP-запрос; сервер возвращает документ, после чего браузер запрашивает недостающие элементы страницы — таблицы стилей, сценарии, изображения^[1][15]. Одна страница, таким образом, порождает десятки и сотни отдельных запросов, и именно их совокупность образует наблюдаемый трафик. Ранние версии протокола открывали новое соединение для каждого запроса; HTTP/1.1 ввёл постоянные соединения, HTTP/2 передаёт множество запросов и ответов в рамках одного соединения (мультиплексирование), а HTTP/3 работает поверх протокола QUIC, снижающего задержки установки связи^[16][17]. Предшественник современных спецификаций, RFC 2616, действовал с 1999 года и в 2022 году утратил силу с принятием новых документов^[18].

Методы запроса и служебные заголовки влияют на объём и структуру потока. Семантика методов (например, GET для получения представления ресурса или POST для передачи данных на обработку) определяет, в какой части сообщения (запрос или ответ) передаётся основная полезная нагрузка. Повторное использование соединения избавляет от затрат на установку связи; файлы cookie и сопутствующие заголовки добавляются к каждому запросу, и их объём суммируется при каждом обращении к элементам страницы^[4][15]. Поэтому одно и то же содержимое при разной технической реализации способно порождать различающийся в разы объём трафика^[19].

Перед установлением соединения клиенту необходимо знать сетевой адрес узла. Если подходящей DNS-записи ещё нет в локальном или промежуточном кэше, выполняется разрешение доменного имени; закэшированный результат может использоваться повторно в пределах срока действия записи. Поэтому отдельный DNS-обмен происходит не для каждого HTTP-запроса. Кэширование имён сокращает служебный трафик и задержки, но осложняет учёт: IP-адрес не является надёжным идентификатором пользователя: несколько пользователей за NAT или корпоративным шлюзом могут иметь один внешний адрес, а адрес одного пользователя может меняться. Поэтому системы веб-аналитики применяют дополнительные идентификаторы и правила формирования сеансов, учитывая при этом ограничения приватности и доступности таких данных^[1][4].

Объём трафика определяется размерами передаваемых документов и числом обращений, а его распределение во времени — режимом поведения аудитории: суточными колебаниями, пиками в часы наибольшей активности, сезонными волнами^[8][7]. Эмпирические исследования показали, что веб-нагрузка обладает свойством самоподобия: структура всплесков повторяется на разных масштабах времени, а распределение размеров передаваемых файлов имеет тяжёлые хвосты. Следствием становится сохранение всплесков нагрузки при агрегировании множества пользователей, что отличает веб-трафик от моделей с пуассоновским распределением и требует запаса пропускной способности^[8][9]. Массовый переход к шифрованию изменил возможности наблюдения: содержимое запросов скрыто от промежуточных узлов, поэтому сетевые системы измеряют соединения в целом, а содержательный анализ остаётся на стороне конечных участников^[4].

Классификация трафика опирается на несколько независимых оснований^[20][21]. По направлению различают входящий (нисходящий) поток — данные, получаемые пользователю, и исходящий (восходящий) — запросы и отправляемые материалы; для большинства пользовательских сценариев нисходящий поток многократно превосходит восходящий^[1]. По источнику посещений, принятому в веб-аналитике, выделяют трафик из поисковых систем, прямой (набор адреса и закладки), реферальный (переходы по ссылкам с других сайтов), из социальных сетей, платный (привлечённый рекламой) и почтовый. Следует учитывать, что конкретная классификация источников (source/medium) зависит от используемой аналитической системы и выбранной модели атрибуции^[6]. По природе участников трафик делится на человеческий и автоматический: последний создают поисковые роботы, мониторы доступности и вредоносные программы, поэтому корректные измерения аудитории требуют фильтрации роботизированных обращений^[4]. Наконец, различают трафик фиксированных и мобильных сетей: мобильные устройства вносят особенности в суточные ритмы потребления и требуют адаптации страниц^[13][19].

Существенны и временные закономерности. Нагрузка следует суточным и недельным ритмам аудитории; прогноз Cisco исходил из того, что к 2022 году самый загруженный час сети станет в шесть раз интенсивнее среднего уровня, и планирование ёмкости ведётся именно под пиковые значения^[13]. Мобильные сети добавляют географическую неравномерность и смену стереотипов потребления, а часть мобильного взаимодействия с сервисами приходится на приложения, потоки которых не регистрируются средствами веб-аналитики и учитываются только сетевыми методами^[13][6].

Граница понятия подвижна вместе с технологиями. Веб-трафик образует часть общего интернет-трафика наряду с потоками обмена файлами, играми и служебными протоколами, однако современные приложения отображают веб-содержимое, а веб-страницы, в свою очередь, работают как приложения, поэтому учёт трафика ведётся по приложениям и категориям потребления, а не по классическим сервисам^[13][1]. Для статистики сети существенно именно это разделение: вклад всемирной паутины оценивается вместе с потоковым видео, социальными сетями и другими категориями нагрузки^[13].

Структура передаваемых данных отражает эволюцию технологий веб-разработки. В медианной настольной веб-странице по данным HTTP Archive за октябрь 2024 года изображения занимают около 1054 килобайтов, сценарии JavaScript — 613, шрифты — 131, таблицы стилей — 78, а сам HTML — лишь 18 килобайтов; общий медианный вес страницы достигает 2652 килобайтов на настольных устройствах и 2311 килобайтов на мобильных^[19]. Основную долю нагрузки современных сетей образует потоковое видео: по данным отчёта Sandvine Global Internet Phenomena Report, видеотрафик стабильно составляет подавляющую часть глобального интернет-трафика (около 65 % и более в отчётные периоды)^[22].

Измерение веб-трафика ведётся тремя основными методами, каждый со своими границами применимости. Серверные журналы фиксируют каждый обработанный запрос: время, запрошенный ресурс, адрес клиента, объём ответа и код результата; они обеспечивают полноту данных для сервера, но не различают пользователей за общими адресами, искажаются кэшированием и требуют фильтрации автоматических обращений^[4]. Журналы исходного (origin) сервера не содержат обращения, которые полностью обслужены промежуточным кэшем или CDN без обращения к origin. Поэтому для полной картины доставки контента данные origin-логов при необходимости сопоставляют с журналами кэширующих узлов/CDN и клиентской аналитикой. Счётчики на странице, устанавливаемые аналитическими системами, собирают данные прямо в браузере и позволяют строить отчёты о визитах, посетителях, глубине просмотра, длительности и конверсиях; их слабые стороны — блокировки, ограничения на хранение данных и зависимость от исполнения сценариев^[6]. Сетевые средства — опрос устройств по SNMP, анализ потоков NetFlow, зеркалирование портов — дают объективную картину объёмов на каналах, но не видят содержимого зашифрованных соединений^[1].

На основе измерений сложилась система метрик посещаемости: визиты и уникальные посетители характеризуют аудиторию, просмотры страниц и запросы — нагрузку, а глубина и длительность визита, а также показатель отказов характеризуют качество вовлечения. Следует учитывать, что точные определения таких метрик, как показатель отказов (bounce rate) или длительность сеанса, зависят от методологии конкретного аналитического продукта^[6]. Для сетевого планирования применяются объёмные и временные показатели: эксабайты за период, пиковая интенсивность, соотношение среднего и пикового значений, суточные профили нагрузки^[3][13]. Сопоставимость данных между системами обеспечивают отраслевые методологии учёта, фиксирующие порядок отнесения визитов к источникам и фильтрации автоматических обращений^[6].

Между методами неизбежны расхождения: серверные журналы не фиксируют запросы, обслуженные внешним кэшем; счётчики теряют пользователей с включёнными блокировщиками, а сетевые средства учитывают и посторонний трафик канала. Поэтому к данным применяют фильтрацию автоматических обращений, дедупликацию визитов, корректировку на отключённые сценарии; качество измерений проверяют сопоставлением независимых методов^[6][4].

Доля попаданий в кэш по запросам определяется как ${\displaystyle h=N_{h}/N}$. Она показывает долю запросов, обслуженных из кэша, но сама по себе не определяет долю сэкономленного объёма данных: для этого используют также byte hit ratio, поскольку размеры объектов различаются^[11].

Управление трафиком направлено на сокращение объёма и времени доставки при сохранении содержимого. Ключевой механизм — кэширование на всех уровнях: браузер хранит ранее полученные ресурсы, сети доставки контента размещают копии популярных материалов на узлах, близких к пользователям, а обратные прокси разгружают исходные серверы. При попадании в пригодную к использованию кэшированную копию ответ может быть передан без получения полного представления от исходного сервера. В зависимости от директив кэширования и свежести объекта может потребоваться проверка актуальности (revalidation); данные при этом всё равно передаются от кэширующего узла клиенту. Дополняют кэширование сжатие передаваемых данных, минимизация и объединение таблиц стилей и сценариев, современные форматы изображений, отложенная загрузка материалов за пределами первого экрана и приоритизация критических ресурсов^[19]. Протокольные нововведения снижают накладные расходы: HTTP/2 мультиплексирует несколько HTTP-потоков в одном соединении и тем самым устраняет необходимость последовательной обработки запросов на уровне HTTP. Однако использование одного TCP-соединения означает, что потеря TCP-сегмента способна временно задержать данные разных HTTP/2-потоков. HTTP/3 работает поверх QUIC, где потоки имеют независимую доставку и потеря данных одного потока не блокирует остальные на транспортном уровне^[17].

Оптимизация имеет и социальное измерение. В сетях с оплатой за объём каждый лишний мегабайт прямо увеличивает расходы пользователя, а на медленных соединениях избыточный вес страницы сдвигает время загрузки, сокращая фактическую доступность ресурса. Исследования в области цифровой доступности (digital accessibility) рассматривают сокращение веса страниц как фактор обеспечения равенства доступа к информации для пользователей с ограниченными каналами связи или устаревшими устройствами^[19][3].

Потребность в оптимизации объясняется не только экономией: вес страниц устойчиво растёт, и каждый дополнительный мегабайт увеличивает время загрузки, расход заряда устройств и нагрузку на сети^[19]. Сети доставки контента, начавшиеся с раздачи изображений, превратились в платформы, обслуживающие целые приложения и значимую долю глобального веб-трафика^[11]. Для операторов структуры трафика определяют архитектуру сети: вынесение контента и вычислений к краю сокращает транзит и разгружает магистрали^[13].

Трафик исторически был мерилом оплаты доступа: повременные и объёмные тарифы постепенно уступали место безлимитным предложениям, однако в мобильных и хостинговых сегментах объёмные ограничения сохраняются, а операторы применяют приоритизацию и лимиты отдельных классов нагрузки^[3][13]. Рост потокового видео и вынос контента к краю сети меняют экономику операторов: расходы на модернизацию агрегируются при сравнительно узком наборе источников нагрузки, что порождало общественные дискуссии о распределении затрат и нейтральности сети^[22]. Для владельцев сайтов трафик прямо связан с доходами рекламы и электронной торговли, поэтому привлечение и удержание аудитории образуют отдельную отрасль маркетинга^[6].

Модель потребления трафика определяет и устройство инфраструктуры хостинга. Тарифные планы часто ограничивают месячный объём передачи или пропускную способность канала; планирование мощностей ведётся по профилю нагрузки с запасом на пики и сезонные события, а неожиданные наплывы посетителей, способные вывести сервис из строя, выделяются в отдельный класс задач^[1][11]. Для крупных сервисов географическое распределение узлов позволяет приблизить контент к аудитории и сократить транзит через магистральные сети, что напрямую снижает издержки всех участников доставки^[11][13].

Механизм повторного использования регулируется заголовками кэширования: сервер указывает срок годности ответа, после истечения которого клиент обязан проверить свежесть, а условные запросы позволяют не передавать документ заново при отсутствии изменений, ограничиваясь коротким подтверждением^[15][4]. Правильная разметка ресурсов превращает повторные посещения страницы из полной перезагрузки в обмен служебными подтверждениями и на посещаемых сайтах сокращает исходящий трафик в разы^[11].

Сбор данных о посетителях, лежащий в основе аналитики трафика, регулируется законодательством о персональных данных и тайне связи. В Европейском союзе общий режим задаёт Регламент GDPR, применяемый с 25 мая 2018 года^[23], а правила хранения информации на устройстве пользователя и доступа к ней устанавливает статья 5(3) Директивы 2002/58/EC в изменённой редакции. Для необязательных технологий хранения, включая многие аналитические и рекламные cookies, требуется предварительное информированное согласие; исключение предусмотрено, в частности, когда хранение или доступ строго необходимы для предоставления услуги, явно запрошенной пользователем^[24]. В России обработку персональных данных, включая сведения, собираемые системами аналитики, регулирует Федеральный закон от 27 июля 2006 года № 152-ФЗ «О персональных данных», действующий в актуальной редакции^[25]. Требования согласия и информирования изменили облик сети, породив механизмы согласия на сбор данных и повысив ответственность сервисов за обработку сведений о посетителях^[24].

Наряду с полезной нагрузкой сеть передаёт аномальный трафик: массовые автоматические запросы вредоносных программ, подбор паролей, сбор контента, а также распределённые атаки типа «отказ в обслуживании», цель которых — исчерпать каналы или ресурсы сервера. Аномалии обнаруживаются статистически — по резким отклонениям интенсивности от обычного профиля, рассогласованию источников и нехарактерным признакам запросов; защита строится на фильтрации, ограничении частоты обращений и рассредоточении нагрузки по сети доставки контента^[1][11]. Историческим примером служит червь Code Red: за сутки он поразил около 359 тысяч серверов и создал различимые всплески обращений, которые использовались для оценки масштабов эпидемии^[10].

Отражение атак опирается на рассредоточение и фильтрацию: распределение приёма по множеству адресов и узлов размывает атакующий поток, очистка трафика на границе сети отделяет вредоносные запросы от легитимных, а ограничение частоты и проверка подлинности клиентов сдерживают автоматизированный сбор контента^[11][1]. Заметную долю аномальных обращений создаёт и конкурентная активность — мониторинг цен, копирование материалов, накрутка статистики, — которую отличить от поведения человека тем труднее, чем совершеннее автоматика^[6].

Поисковые роботы и другие боты, не являясь вредоносными, вносят заметный вклад в объём трафика и осложняют измерение аудитории, поэтому отделение автоматических обращений от обращений людей — постоянная задача аналитики^[4].