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

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

Предполагая, что в поле установлен только HTTP/S-трафик и предполагается статистически значимое количество "типичного" веб-трафика:

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

Ответ 1

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

Обновление. На основе вашего комментария, вот некоторые оценки на основе салфеток:

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

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

overhead = TCP + IP = 40 байт

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

накладные расходы% = 2% (40 * 100/1460)

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

overhead = TCP + IP = 60 байт

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

накладные расходы% = 4% (60 * 100/1440)

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

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

Ответ 2

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

Это 6% накладных расходов. Если вы также подсчитаете ACK TCP, которые протекают в противоположном направлении, это приближается к 9%. Для гигабитного Ethernet накладные расходы (в процентах) остаются неизменными. Предположения: TCP/IPv4 и размер файлa > 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 всегда является полнодуплексным, иногда ACK ACK, протекающий другим способом, не меняет скорость передачи. Если вы добавите один ACK для каждых двух фреймов данных к накладным расходам (что я наблюдал в Wireshark), вы получаете 8,5% от общей суммы затрат. И хотя размер MTU обычно составляет 1500 байт, он может быть меньше в некоторых сетях или намного больше, если для него настроена каждая часть оборудования в пути.

Ответ 3

Какие дополнительные сетевые издержки? TLS накладные расходы превышают количество HTTP для обмена ключами. Это в основном обработка накладных расходов, которые вы заметили.

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

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