В последнее время я работал над загрузкой больших файлов на веб-сайт, эта загрузка съела всю полосу пропускания и нанесла ущерб моей сети. Итак, я реализовал разбиение одного фрагмента размером 1 МБ в секунду и его работу, но теперь я думаю, могу ли я использовать управление трафиком для достижения того же самого с лучшим результатом.
Мой вопрос: настолько ли умно управление трафиком и может ли различать просмотр www и массовая загрузка / скачивание больших файлов www.
tc qdisc add dev imq0 root handle 1:0 htb default 666
tc class add dev imq0 parent 1:0 classid 1:1 htb rate 90000kbit ceil 90000kbit
tc class add dev imq0 parent 1:1 classid 1:888 htb rate 10000kbit ceil 40000kbit prio 0 # browse www traffic
tc class add dev imq0 parent 1:1 classid 1:666 htb rate 10000kbit ceil 40000kbit prio 1 # bulk www traffic
tc filter add dev imq0 protocol ip parent 1:1 prio 2 u32 match ip tos 0x08 0xff flowid 1:666 # bulk www traffic
tc filter add dev imq0 protocol ip parent 1:0 prio 2 u32 match ip sport 80 0xffff flowid 1:888 # http
tc filter add dev imq0 protocol ip parent 1:0 prio 2 u32 match ip sport 443 0xffff flowid 1:888 # https
Хотелось бы, чтобы это сработало? (Не могу проверить сейчас.)
Ваше решение полагается на поведение веб-браузера для соответствующей установки поля IP ToS. На это можно положиться только в доверенной среде.
Я могу легко написать правила mangle на своей машине, чтобы сгладить все ToS в какое-то одно значение, и ваши правила TC не смогут отвлечь мою массу от просмотра.
Кроме того, я не был бы уверен, что все браузеры и другое программное обеспечение http (s) всегда используют одни и те же ToS для одних и тех же вещей. Такого софта предостаточно: wget и другие загрузчики; зеркалирование веб-сайтов (wget тоже может это делать, но есть специализированное программное обеспечение), которые загружают не только некоторые большие файлы, но и все реквизиты страницы; множество браузеров, включая firefox, lynx, links, т.е. edge, на основе хрома - все они используют разные движки и могут отображать разное сетевое поведение; Связанные с REsT вещи, которые просто отправляют небольшие сообщения по http туда и обратно. В веб-мире также существует решение Websocket, которое полностью отличается от того, что вы знаете о http.
Таким образом, использование ToS полезно только в том случае, если вы тщательно контролируете свою сеть.
В общем случае разница в том, что при просмотре используются короткие всплески трафика, а загрузка заполняет емкость канала. Вы можете установить довольно низкую среднюю скорость HTB, которая будет соответствовать средней скорости просмотра и загрузки, при этом сохраняя размер сегмента (размер пакета) достаточно большим, чтобы вместить всю веб-страницу. Тогда просмотр веб-страниц будет происходить так же быстро (из-за большого объема), но, поскольку выборка страниц происходит редко, будет достаточно времени, чтобы пополнить корзину для следующей страницы. С другой стороны, загрузка истощит ведро и не даст свободного времени для его пополнения, поскольку она будет такой же медленной, как и ваш лимит.
Многие популярные инструменты загрузки предоставляют механизм ограничения пропускной способности, которую разрешено использовать для передачи.
Если вы используете rsync чтобы загрузить свои большие файлы, используйте --bwlimit переключатель:
rsync --bwlimit=125k ...
Если вы просто используете scp, использовать -l переключатель:
scp -l 125k ...
Если вы используете wpu, он также распознает -l переключатель (также --limit-rate=):
wput -l 125k ...
или
wput --limit-rate=125k ...
Если вы используете что-то еще, обратитесь к man страницу для выбранного пользователем, чтобы узнать, предлагает ли он аналогичную возможность.