QoS - HTTP nagy fájlok letöltése

Hálózatok általános

A windows update az utóbbi időben rettentő agresszív lett, rosszabb mint a torrent. Sok szálon tölt, és hát ugye egy-egy frissítés több száz MB is lehet. Egyszerűen az összes sávszélességet meg tudja enni, kimarad a ping, darál az ssh, megáll a netrádió, kihajít az RDP. OK, priorizáljuk valahogy, de hogy? Az icmp-t meg az SSH-t ki lehet venni a képletből. De mondjuk egy netrádiót, ami szintén 80-as portról jön, valamint egy sima böngészést hogy tudok megkülönböztetni egy hosszú letöltéstől qos szintjén?
Első körben az az ötlet, hogy a HTTP-t besoroljuk egy queue-ba, majd ha a letöltési mennyiség eléri a 10MB-ot, akkor átsorolni azt a sessiont egy alacsonyabb prioritású queue-ba. De ezt hogy lehet megvalósítani?
Vagy más ötlet?
Linux és TC adott.

  • 1051 megtekintés

Nagy háló elé jó lehet... Bár akkor meg már inkább wsus indokolt.
De itt most 1 gépről van szó. A probléma nálunk az irodában keletkezik, ahol van egy 15/15-ös net, meg egy ügyfél gépe, amit épp telepít valaki, és amint első indulásnál elindul a win10 és elkezd frissíteni, azonnal megáll mindenünk. Legjobb, hogy van hogy hiába állítjuk le az update servicet, tölt tovább. Csak hálókábel kihúzás és "akkor rohadj meg" segít, aztán majd visszadugjuk mikor jövünk el, este ráér frissíteni.
--
"Sose a gép a hülye."

( PistiSan | 2017. 03. 28., k – 17:41 )

Ismerős probléma, az hogy nem látom a letöltendő adat méretét külön idegesít.
Egyszer csak észlelem az általad leírtakat,rá nézek a gépházban..... Windows update.

( gemnon v | 2017. 03. 28., k – 17:45 )

Marciék darabokba töltenek :D 


xx/xx/2017-12:21:13.215479 7.tlu.dl.delivery.mp.microsoft.com [**] /filestreamingservice/files/e488e507-91a5-4b53-a9a2-e45dc0d52510?P1=1489754742&P2=301&P3=2&P4=bxIcbmphIrEqhG8MVXBbSkA2WgWWLnwYr53tQusB7Wk%3d [**] Microsoft-Delivery-Optimization/10.0 [**] <no referer> [**] GET [**] HTTP/1.1 [**] 206 [**] 1048576 bytes [**] x.x.x.x:55561 -> 13.107.4.50:80
xx/xx/2017-12:21:13.273822 7.tlu.dl.delivery.mp.microsoft.com [**] /filestreamingservice/files/e488e507-91a5-4b53-a9a2-e45dc0d52510?P1=1489754742&P2=301&P3=2&P4=bxIcbmphIrEqhG8MVXBbSkA2WgWWLnwYr53tQusB7Wk%3d [**] Microsoft-Delivery-Optimization/10.0 [**] <no referer> [**] GET [**] HTTP/1.1 [**] 206 [**] 1048576 bytes [**] x.x.x.x:55565 -> 13.107.4.50:80
xx/xx/2017-12:21:14.290774 2.tlu.dl.delivery.mp.microsoft.com [**] /filestreamingservice/files/0bde7b14-ed50-4379-901c-3ff19c7190f8?P1=1489752802&P2=301&P3=2&P4=OEG3QQEZPUTAvXs0nF9668%2fKs5wHzX1jomComjKWiWs%3d [**] Microsoft-Delivery-Optimization/10.0 [**] <no referer> [**] GET [**] HTTP/1.1 [**] 206 [**] 1048576 bytes [**] x.x.x.x:55521 -> 92.123.226.152:80
xx/xx/2017-12:21:14.341860 2.tlu.dl.delivery.mp.microsoft.com [**] /filestreamingservice/files/0bde7b14-ed50-4379-901c-3ff19c7190f8?P1=1489752802&P2=301&P3=2&P4=OEG3QQEZPUTAvXs0nF9668%2fKs5wHzX1jomComjKWiWs%3d [**] Microsoft-Delivery-Optimization/10.0 [**] <no referer> [**] GET [**] HTTP/1.1 [**] 206 [**] 1048576 bytes [**] x.x.x.x:55527 -> 92.123.226.163:80


tc qd add dev $lanif root handle 1: htb
tc cl add dev $lanif parent 1: classid 1:1 htb rate 5Mbit ceil 5Mbit
iptables -A FORWARD -p tcp --dport http -m string --algo bm --string delivery.mp.microsoft.com -j CONNMARK --set-mark 0x666
iptables -A FORWARD -m connmark --mark 0x666 -j CLASSIFY --set-class 1:1

ez?

( hrgy84 | 2017. 03. 28., k – 18:21 )

IP alapu TC. A netradio meg a surubben latogatott oldalak fix IP-kre esnek, azokat besorolod magasabb prioba. A YT meg a CDN cuccok trukkosek, de nem lehetetlen az se.
--
Blog | @hron84
Üzemeltető macik

Az ötlet nem rossz, de külső IP-ket lehetetlen nyomon követni. Ami google, amazon, ms, cloudflare vagy bármilyen felhő, és akár 5 percenként más ip-je lehet, teljesen lehetetlen naprakészen tartani.
Viszont, a belső ip alapján lehet nem hülyeség. Valami példád van?
--
"Sose a gép a hülye."