[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' 🙈
