передача данных

[sphht.livejournal.com]

Туплю маленько. Допустим, где-то на http-сервере лежит файл, весом в 7 Кб, на его доставку с сервера до моего компьютера, я потрачу около 9 Кб, это включая затраты на исходящие и входящие запросы — служебный трафик протоколов.

Т.е. в итоге, я потрачу на доставку на ~28% больше, чем размер файла хранящийся на сервере. Можно ли утверждать, что при скачивании скажем 1Гб, мне придется потратить в общей сложности трафика ~1,28Гб? Или если не так, то как тогда можно высчитать затраты на скачивание какго-то произвольного размера данных?

(это не для практических целей сокращения моего трафика, это так, задачка мне интересная)

Спасибо ;)

Comments

[darthserge.livejournal.com]

По-моему есть такая вещь как "размер пакета", и соответственно чем меньше размер пакета, тем больше запросов. Но там точно не треть - на треть больше только при отправке по почте получается.
Но лучше вообще пусть специалисты ответят =)

[pieceofsummer.livejournal.com]

Ну, треть — это очень, очень-очень грубая прикидка.

Если, например, слать английский текст, то почти не будет разницы в размере. А если слать бинарники, то и в два раза может вырасти :)

[sunnycat.livejournal.com]

"(это не для практических целей сокращения моего трафика, это так, задачка мне интересная)"
и в чем практическая польза этого вопроса?

[sphht.livejournal.com]

Эммм... ну это необходимая мне для решения задача, которая правда не является практической ситуацией из моей жизни.

[sunnycat.livejournal.com]

ок

[madcat.livejournal.com]

нельзя.
Курить семиуровневую модель OSI. Вопросы отпадут.

[sphht.livejournal.com]

Ну хоть подскажите, еще чего. Я уже и OSI смотрел и снифером трафик TCPIP-протокола изучал. Но не пойму, почему нельзя высчитать таким способом размер трафика для произвольного объема загружаемых данных.

Ведь по сути при передаче 1 Гб данных, ничего не изменится в самих пакетах, просто возрастет их количество, т.к. данных надо прислать больше.

[madcat.livejournal.com]

снифер до олдного места.
Можно.
Максимальный размер данных во фрейме Ethernet составляет 1500 байт. Для верности бы брал 1492.
Размер заголовка IP - 20 байт. Размер заголовка TCP - еще 20 байт. Остальное - данные. Итого, на на 1452 байта - 40 байт служебной информации. Плюс пакет подтверждения приема уходит обратно - 40 байт.
Итого на 1452 байта - 80 байт служебной информации. Для выкачивания 1 гб нам потребуется где-то 740 тыс пакетов. Служебной информации будет получено/отправлено 56 мегабайт. Что составляет около 5%. Но это при выкачке одного большого файла и при нормальном соединении без потерь пакетов.

В среднем же, когда-то выводил, размер пакета - около 1000 байт, что дает около 8% служебного траффика. Т.е. для подсчета нормальной, среднестатистической работы эти данные подходят.(исключаем чисто качальщиков или онлайн-геймеров)

[pieceofsummer.livejournal.com]

Что-то вы перебрали с 28%.

Если принять MTU за 1500 (стандартный для локалки), размер Ethernet-заголовков ~15 байт, IP - 20 байт, TCP - еще от 20 до 60 байт.

Итого на заголовки — от 3.5 до 6 процентов.

Ну, еще добавьте к размеру файла размер HTTP запроса и ответа, но это тоже копейки (не больше килобайта).

[sphht.livejournal.com]

Спасибо, прояснили кое-что. Так рассчитать-прогнозировать опираясь на результаты запроса маленького файла нельзя? Я например хочу узнать, сколько потребуется потратить общего трафика на Гб доставки.

А такая картина нормальная: размер файла — 7069 байт, итого затрачено на доставку — 8570 байт?

И еще а если увеличить IP-заголовок и довести его до неизменного размера 40 байт, а MTU = 1280. То такие результаты будут нормальными: размер файла — 7069 байт, итого затрачено на доставку — 9002 байт?

Я совсем затупил что-то.

[haviras.livejournal.com]

7069 байт - 4,60 пакета, при MTU 1500 (пусть будет так) это будет 4 пакета и 0.7 еще от полного MTU

Заголовки и служебка, если вообще по максимуму флагами забить то получим еще 20+20+60=100 байт, да на 5 пакетов и еще 500 байт.

Ну и еще видать на обратные квитанции 500 кб

[haviras.livejournal.com]

Тьфу.. 500 байт

[sphht.livejournal.com]

Спасибо! Но мне интересно, можно ли предсказать по моим затратам (7097 —> 9002) ситуацию, когда мне нужно выкачать файл большего размера?

Т.е. если мне нужно будет узнать, сколько вообще потребуется трафика для выкачивания 1 Гб файла, в соответствии с вышеозначенными условиями, — как это можно рассчитать?

[haviras.livejournal.com]

Избыточность в IP сетях до 15%.
Ну вот 150 метров слить придется.
Вот только не в курсе считают ли это траффиком провайдеры.

[haviras.livejournal.com]

MTU для локалки вроде 1492, кстати... или то для PPP\PPTP ... кстати

[pieceofsummer.livejournal.com]

Из вики:

For example, the maximum size of an IP packet is 65,535 bytes while the typical MTU for Ethernet is 1,500 bytes. Since the IP header consumes 20 bytes (without options) of the 1,500 bytes leaving 1,480 bytes of IP data per Ethernet frame (this leads to an MTU for IP of 1,480 bytes). Therefore, a 65,535-byte data payload would require 45 packets (65535/1480 = 44.28).

[haviras.livejournal.com]

Значит то в PPTP и PPP
Благодарю

[neoromantic.livejournal.com]

Для маленьких данных процент протокольных согласований больше. Потому что кроме собственно вещей транспортного уровня (TCP пакетов), есть накладки от HTTP, например.

Если вы качаете 100 маленьких картинок общей массой на 100кб – вы получите 100 раз HTTP-запросы и HTTP-ответы и все такое.

Если вы качаете 1 большой файл на 100мб - будет один HTTP запрос.

[haviras.livejournal.com]

9 кб ~ 5,8 пакетов
5 целых и еще один будет неполный. В чем проблема то?
Биллинг то все равно по TCP\IP снимается