[Wien] Beschleunigtes Websurfen; 100 Mbit LTE feeling in 3 MBit Funkfeuer bringen, Googles´s Data Compression Technology am Desktop (Win/Mac) nutzen, in Chrome,

[Martin Shivraj Saini]

Hallo!

Danke für die Antwort, gibts da noch paar details dazu? Peering, 
Upstream Provider, etc?

MfG
Martin


Am 26.09.2014 18:17, schrieb gerhard poller:
> anbindung ist eigenes glas peak 100 mbit ihmo
> *Gesendet:* Freitag, 26. September 2014 um 14:53 Uhr
> *Von:* "Martin Shivraj Saini" <(spam-protected)>
> *An:* (spam-protected)
> *Betreff:* Re: [Wien] Beschleunigtes Websurfen; 100 Mbit LTE feeling 
> in 3 MBit Funkfeuer bringen, Googles´s Data Compression Technology am 
> Desktop (Win/Mac) nutzen, in Chrome,
> Hallo!
>
> Wie sieht die Anbindung von Funkfeuer ansich aus - hab das auf die
> schnelle jetzt nicht gefunden (möglicherweise unfähigkeit meinerseits :)
>
> mfg
> martin
>
>
> Am 25.09.2014 13:04, schrieb Erich N. Pekarek:
> > Hallo!
> >
> > Am 2014-09-25 um 11:07 schrieb Matthias S(ubik:
> >> On 25.09.2014, at 07:06, Alexander Meinhart wrote:
> >> ...
> >>> Ihr braucht im Chrome Browser (Win/Mac) nur diese Erweiterung (s.
> >>> unten)
> >>> instalieren, und ich muss sagen, es zahlt sich voll aus, alles geht
> >>> flotter, auch videos werden m.E. nach rascher vorgeladen, fühlt sich
> >>> nun
> >>> alles wie bei LTE an (was ich auch bei A1 nutze...), und das bei 
> max. 3
> >>> Mbit bei meinem Funkfeuer Zugang / Knoten!!
> >>>
> >> Also das mit SPDY bei HTTP plus Kompression bei Webservern die das
> >> nicht können ist mir klar,
> > Wenn ich es richtig verstanden habe, dann aktivert das Plugin einen
> > Proxy im Netz von Google, der wiederum SPDY kann und auch Inhalte in
> > einem für Chrome passenden Format komprimiert.
> >
> > https://developer.chrome.com/multidevice/data-compression
> >
> > Nicht klar ist mir, ob das teils lokal (Proxy-Chain) oder zentral
> > (Google-Proxy) abläuft.
> >> aber wie youtube schneller gehen soll, ist mir nicht klar. Bei
> >> A1/TMA/3/UPC ist klar, die können (und tun es) youtube ausbremsen,
> >> aber bei 0xFF würde das ja nur heissen, dass 64.15.113.0/24 langsamer
> >> daher kommt, wenn es direkt angesprochen wird, ODER der SPDY Proxy
> >> hat einen Zugang zu Youtube den Du sonst nicht hast.
> > Durch den komprimierten Datenstrom wird wohl eine DPI verhindert, die
> > das Ausbremsen sonst ermöglicht. Den Providern ist ja selbst an einer
> > Reduktion der Auslastung der Netz gelegen, weshalb sie das vermutlich
> > schlicht dulden.
> > Man umgeht damit wohl auch die Mechanismen, die dies bereits beim
> > Provider tun - wie zB. die alles andere als netzneutrale "UMTS image
> > compression", bei der Proxyserver des Providers Bilder
> > bandbreitenschonend modifizieren. Siehe u.a.
> > http://forums.linuxmint.com/viewtopic.php?f=90&t=22249.
> >
> >>
> >> Meine erste Vermutung würde sein, dass der Proxy via 2a00:1450::/32
> >> an Youtube kommt, weil seit ich nativ IPv6 bei UPC nutze, ist mein
> >> Netz schneller ;) in IPv6 ist einfach weniger los.
> > Das kommt sowieso dazu.
> >>
> >> Also die zusätzliche Dienstleistung in allen Ehren, aber ich vermute
> >> hier treffen verschiedene Effekte zusammen, nicht nur ein "simpler"
> >> Proxy.
> > Proxy, spdy, dns late-binding, image transcoding (wie bei den APNs der
> > Provider), content-aware compression, malware-blocker, etc.
> > Diese Annahme scheint also korrekt zu sein. Dieser Proxy modifiziert
> > also definitiv auch Inhalte.
> >>
> >> bG
> >> Matthias
> >>
> > LG
> > Erich
> >
> > --
> > Wien mailing list
> > (spam-protected)
> > https://lists.funkfeuer.at/mailman/listinfo/wien
>
>
> --
> Wien mailing list
> (spam-protected)
> https://lists.funkfeuer.at/mailman/listinfo/wien
>
>
> --
> Wien mailing list
> (spam-protected)
> https://lists.funkfeuer.at/mailman/listinfo/wien

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/wien/attachments/20140929/e6e28fa9/attachment.htm>