Draytek Vigor 2860 e FTTH

LATIITAY perche' su quella porta ci si aspetterebbe di vedere solo traffico in chiaro

Da quando? HTTPS non è mai stato limitato alla 443 - quella è solo la convenzione della porta di default - specialmente da quando HTTPS è divento il protocollo ubiquo di trasporto. Un router/firewall non dovrebbe mai fare ipotesi di questo tipo - per di più dispositivi di livello prosumer o professionali.

Fino a prova contraria, io sono dell'idea che l'implementazione web è meno efficiente dal punto di vista del profilo del traffico di rete - ha sicuramente un maggior overhead di protocollo e questo significa più pacchetti a parità di payload trasferito. Se poi quel router è single core, un test con connessioni multiple sarà svantaggiato non potendo processarle in parallelo - un po' come accade con pfSense che con PPP usa un singolo core associato alla singola coda della scheda di rete usata dal traffico PPP (perché non hashato su più code in hardware).

Sarebbe interessante vedere la differenza fra un download da xs4all.nl e il test Ookla a singola connessione o multiple.

Poi si potrebbe anche scoprire che hanno pasticciato con il firmware - ogni tanto mi chiedo chi lo sviluppi in DrayTek....

[cancellato] Da quando? [...] Un router/firewall non dovrebbe mai fare ipotesi di questo tipo - per di più dispositivi di livello prosumer o professionali.

Eh, lo so, pero' alla fine invece queste assunzioni vengono fatte fin troppo spesso... Non solo Wireshark ma ad esempio anche Vodafone fa la stessa assunzione: mette il proxy trasparente non solo sulla 80 ma anche sulla 8080 (e non ricordo piu' quali altre porte)... Poi se il traffico non e' HTTP allora lo passa intatto (dopo aver cmq controllato se c'e' credito oppure se e' zero rated tutto l'IP e non solo host headers specifici, altrimenti non fa passare nulla dall'altra parte).

[cancellato] Fino a prova contraria, io sono dell'idea che l'implementazione web è meno efficiente dal punto di vista del profilo del traffico di rete - ha sicuramente un maggior overhead di protocollo e questo significa più pacchetti a parità di payload trasferito.

Questo senza dubbio, pero' il problema qui credo sia un altro: il primo router sembra non faccia passare quel traffico per la fastpath hardware, mentre il secondo direi che lo fa.

L'offloading probabilmente e' uno "shortcut" nel chip dello switch per le connessioni che il conntrack di Linux vede ESTABLISHED, come fanno gli SDK dei AR83x7N oppure dei MediaTek ad esempio, e quindi la CPU non vede proprio quel traffico.

Se ci pensa il chip dello switch a fare il forwarding, spesso (ma non sempre) lo puo' fare a line-rate anche per tutti pacchetti piccoli. Quindi il problema del potenziale collo di bottiglia si sposta a valle, sulla scheda di rete/CPU/etc del computer E allora si' che diventa poco efficiente "wrappare" il tutto in HTTPS/WebSocket/whatever, ma e' un "male necessario" se si vuol far fare il test da dentro il browser...

Pero' se appunto l'offloading non accade, bisognerebbe capire perche', e l'ipotesi che facevo io e' che eventuali filtri "parental control" o similari che potrebbero essere attivi sul primo router, potrebbero star dissezionando traffico considerato HTTP sulle porte considerate "comuni" per quel protocollo, quali 80 e appunto 8080. Questi filtri sarebbero incompatibili con l'offloading, e quindi lo switch non verrebbe mai configurato per "cortocircuitare" il traffico di quelle connessioni, ed ecco che passa tutto per la CPU. Certo, se fosse cosi', basterebbe fare in modo di fare offloading una volta che il filtro si "arrende" perche' il protocollo non e' appunto HTTP... Ma beh facile a dirsi pero' va implementato

[cancellato] Poi si potrebbe anche scoprire che hanno pasticciato con il firmware - ogni tanto mi chiedo chi lo sviluppi in DrayTek....

Magari il problema e' che su quel router la fastpath non funziona mai per quelle porte anche a filtri disattivati, chissa'

LATIITAY a ad esempio anche Vodafone fa la stessa assunzione: mette il proxy trasparente non solo sulla 80

Però qui stiamo parlando di un servizio consumer mobile - non di un router pro.

LATIITAY primo router sembra non faccia passare quel traffico per la fastpath hardware, mentre il secondo direi che lo fa.

Okkio che quelli delle immagino però sono Asus, non il Draytek. Quei dati dal DrayTek si potrebbe forse estrarli via SNMP, si vede probabilmente di più che da interfaccia utente. L'accelerazione hardware poi è diventa indispensabile passando a velocità superiori a quelle della VDSL2+, prima in qualche modo ci si stava dentro.

LATIITAY L'offloading probabilmente e' uno "shortcut" nel chip dello switch

C'è però il NAT di mezzo - tra l'altro quel DrayTek sembra avere una tabella di NAT in hardware abbastanza piccola che farà comunque sì che oltre un certo numero di connessioni non saranno tutte accelerate.

LATIITAY l'ipotesi che facevo io e' che eventuali filtri "parental control" o similari che potrebbero essere attivi

Mah, nel caso di un dispositivo di fascia professionale sarebbe veramente un cattivo design. Bisognerebbe provare a fare un test in routing puro senza NAT di mezzo, rendendo così meno rilevante l'accelerazione hardware. Se rimane un impatto molto significativo sulle prestazioni bisognerebbe indagare più a fondo, altrimenti il rallentamento è dovuto alla gestione del NAT. Comunque anche in puro forwarding la differenza fra un test iperf e un IMIX si vede ancora - alla fine la tabella di routing va consultata per ogni pacchetto....

[cancellato] Okkio che quelli delle immagino però sono Asus, non il Draytek.

In effetti ok, io mi riferivo agli Asus di MiloZ, ma mi ero confuso e pensavo fossero DrayTek pure quelli. Mea culpa

[cancellato] C'è però il NAT di mezzo - tra l'altro quel DrayTek sembra avere una tabella di NAT in hardware abbastanza piccola che farà comunque sì che oltre un certo numero di connessioni non saranno tutte accelerate.

Si', i chip dello switch che ho citato fanno proprio anche NAT, e con tabelle relativamente piccole, mi sembra fino a 128 connessioni per gli Atheros. Ha senso che il NAT sia implementato nel chip dello switch, visto che "vede" direttamente sia le porte LAN che la/le WAN, e infatti alcuni chip Wi-Fi implementano l'offloading collegandosi internamente proprio allo switch. (Ricordo infatti che in alcuni router di qualche anno fa di non ricordo quale marca veniva utilizzato 1.1.1.1 per la gestione del chip del Wi-Fi "autonomo" a 5 GHz... Non Cisco, li' il problema con 1.1.1.1 era un altro ancora )

[cancellato] routing puro senza NAT di mezzo, rendendo così meno rilevante l'accelerazione hardware

In realta', routing puro anche puo' essere accelerato con il flow offloading su questi switch, semplicemente lo switch viene programmato per cambiare solo i MAC address e non anche IP e porte...

[cancellato] Comunque anche in puro forwarding la differenza fra un test iperf e un IMIX si vede ancora - alla fine la tabella di routing va consultata per ogni pacchetto....

Se il flow offloading e' attivo per un dato flusso, lo switch per quel flusso riesce ad andare a line-rate come se stesse "soltanto switchando". La CPU non viene proprio toccata, per pacchetti TCP (solo data/ack) oppure UDP appartenenti ad un dato flusso presente nella tabella di offloading.

Ah ecco, la frammentazione dei pacchetti rompe parzialmente questo tipo di offloading, perche' i pacchetti IP vengono frammentati su base ID pacchetto + offset, e l'informazione delle porte e' contenuta solo nel primo fragmento... Questi switch operano in maniera completamente "stateless" in base a quanto viene dinamicamente programmato nella tabella di flow offloading dal software (spesso l'SDK proprietario, ma non sempre, da quando ad es OpenWrt sta pian piano implementando un po' di hardware flow offloading in maniera ehm "senza zappare" nel povero codice di Linux); insomma non viene tenuta traccia dallo switch dell'ID dei vari segmenti, per cui i segmenti diversi da offset 0 finiscono girati alla CPU, come se non facessero parte di alcun flusso.

siete meglio di una puntata di colpo grosso

LATIITAY

Ok ma senza aprire il router per vedere che chipset c'è dentro, o decompilando il firmware, puoi fare un po' di test in differenti configurazioni e confrontare i risultati. Che poi la discussione verteva su quale tipo di traffico - e a che livello - ha impatto sulle prestazioni, se c'è qualcosa a livello 7 o no, e quindi è tutto a L3 al massimo.