Какой процент трафика является нагрузкой на сеть поверх запросов HTTP / S - PullRequest
Новая
       40

Какой процент трафика является нагрузкой на сеть поверх запросов HTTP / S

30 голосов
/ 01 сентября 2010

Если мы:
1) Подсчитать байты / биты на уровне сетевого адаптера (необработанное количество бит через NIC) и,
2) Подсчитать байты во всех запросах / ответах HTTP / S.

Предполагается, что на коробке находится только трафик HTTP / S, и предполагается, что статистически значимый объем «типичного» веб-трафика:

Я хочу знать, сколько трафика будет учитываться на уровне NIC, чемна уровне HTTP / S (считая заголовки http и все) из-за дополнительных сетевых издержек.

Ответы [ 3 ]

21 голосов
/ 01 сентября 2010

У вас нулевые знания о слоях ниже HTTP.Вы даже не можете предположить, что HTTP-запрос будет доставлен по TCP / IP.Даже если это так, вы ничего не знаете о накладных расходах, добавленных сетевым уровнем.Или какова будет надежность маршрута и какие накладные расходы будут возникать из-за пропущенных / повторно отправленных пакетов.

Обновление : на основе вашего комментария здесь приведены некоторые из нихоценки:

Максимальный размер сегмента (который не включает заголовки TCP или IP) обычно согласовывается между уровнями до размера MTU минус заголовкиразмер.Для Ethernet MTU обычно настраивается на 1500 байт.Заголовок TCP имеет размер 160 бит или 20 байтов.Фиксированная часть заголовка IPv4 составляет 160 бит или 20 байтов.Фиксированная часть заголовка IPv6 составляет 320 бит или 40 байтов.Таким образом:

  • для HTTP через TCP / IPv4

издержки = TCP + IP = 40 байтов

полезная нагрузка = 1500 - 40 = 1460 байтов

издержки% = 2% (40 * 100/1460)

  • для HTTP через TCP / IPv6

издержки = TCP + IP = 60 байтов

полезная нагрузка = 1500 - 60 = 1440 байтов

служебные данные% = 4% (60 * 100/1440)

Вот предположения:

  • Amazon считает полезную нагрузку NIC без заголовков Ethernet, а не весь пакет NIC
  • ваши ответы HTTP полностью используют пакет TCP / IP - ваш типичный размер страницы + заголовки HTTP приводит к одному или нескольким полным пакетам TCP / IPи один с более чем 50% используемой полезной нагрузкой
  • вы устанавливаете явную дату истечения срока действия для кэшированного содержимого, чтобы минимизировать 302 ответа
  • вы избегаете перенаправлений или ваши URL-адреса достаточно длинные для заполнения полезной нагрузки
10 голосов
/ 20 сентября 2013

При 100 Мбит / с Ethernet передача больших файлов со скоростью 94,1 Мбит / с.

Это 6% накладных расходов.Если вы также посчитаете, что TCP ACK течет в противоположном направлении, это ближе к 9%.Для гигабитного Ethernet накладные расходы (в процентах) остаются прежними.Допущения: TCP / IPv4 и размер файла> 100 КБ.(При таком размере мы можем пренебречь начальной настройкой HTTP и TCP.)

При сравнении скоростей загрузки учитывайте коэффициент 8 от битов до байтов.Я предполагаю, что никто не будет взимать плату за преамбулу Ethernet или межкадровый разрыв, но «полезная нагрузка» не должна восприниматься буквально.

Расчет: полезная нагрузка / в целом
полезная нагрузка = 1500 - 20 -32 (Ethernet_MTU - IPv4 - TCP)
в целом = 8 + 14 + 1500 + 4 + 12 (Преамбула + Ethernet_header + Ethernet_MTU + CRC + Interframe_gap)

Поскольку Ethernet всегда дуплексный, этидни, случайный TCP ACK, протекающий в другую сторону, не меняет скорость передачи.Если вы добавите один ACK для каждых двух фреймов данных в служебную информацию (это то, что я наблюдал в Wireshark), вы получите 8,5% общих служебных данных.И хотя размер MTU обычно составляет 1500 байт, он может быть меньше в некоторых сетях или намного больше, если для него настроен каждый элемент оборудования в пути.

1 голос
/ 01 сентября 2010

Какие дополнительные сетевые издержки? накладные расходы TLS поверх HTTP равносильны обмену ключами. В основном это накладные расходы на обработку.

http://en.wikipedia.org/wiki/HTTP_Secure#Difference_from_HTTP

Вниз (после сервера), ускоритель или прокси будут обрабатывать ваш трафик иначе, чем он не может быть кэширован или сжимаем.

...