https://ma.ttias.be/googles-quic-protocol-moving-web-tcp-udp/ (https://ma.ttias.be/googles-quic-protocol-moving-web-tcp-udp/)
Fascinating, basically rolling in WANop functionality lower down the stack. Its interesting how its really focused on mobile/wireless, e.g. how it assumes lossiness and sacrifices straight up throughput in favour of error recovery/hash recomputation of missing fragments.
Not sure if baking SSL at that level is a good idea long term wise (harder to patch/update?) but I guess as long as its not part of the OS stack you can just update the browser on top?
Fascinating news in the comments:
As for webservers:[/size]– Nginx will be the first major webserver/proxy to implement QUIC in their mainline repository (= beta channel)– Apache will follow shortly after with a mod_quic module, similar to their mod_h2 module– This may be, just like in the case of HTTP/2, the perfect time for "smaller" webservers to gain market share by beating the big players to the implementation.
It sounds quite fascinating. Don't know if it'll catch on, though.
When I was capturing SSL VPN traffic, wireshark identified it as QUIC -> not sure why though.
Sending duplicate data every Tx is not new either. I learnt about that when studying for the VOIP certs although it's not really used. I *think* you just select the codec which has this incorporated and then each voip packet is duplicated to allow for some loss.
I'm glad to see that protocols are still being worked on. The current set of protocols are really designed for the networks at the time they were designed. We didn't have multi-spacial stream wifi and mobile devices achieving 50mbs with stupidly high jitter.
That is pretty interesting especially from a dropping packet or latency perspective.
Quote from: burnyd on August 07, 2016, 07:34:39 AM
That is pretty interesting especially from a dropping packet or latency perspective.
Exactly. I saw an O'Reilly book on HTTP/2, http://www.oreilly.com/webops-perf/free/HTTP2-high-perf-browser-networking.csp
I think I'll read it this afternoon. Yay free pdf books!
edit: attaching to thread
Also this: https://docs.google.com/document/d/1lmL9EF6qKrk7gbazY8bIdvq3Pno2Xj_l_YShP40GLQE/edit
QUIC FAQ for Geeks
EDIT: OK, so it seems that the SSL encryption needs to be on the entire stream first and foremost to keep routers along the path from trying to optimize the packets... which would ruin them, since the routers along the path don't know about QUIC just yet.
OK, so I was playing with trying to capture side-channel info from my wireless and fired up Wireshark and whaddya know... I see QUIC on my local wireless network! This is fun stuff.
Is wireshark just encompassing any UDP/443 packets as QUIC?
Nope, it's reading QUIC as QUIC. It's encrypted and everything. Really cool. Until you want to do layer 7 inspection, then it sucks if you can't get a wildcard Google cert installed on the ol' Next-Gen firewall/proxy.
So if wireshark is correct has Cisco implemented QUIC in their AnyConnect client?
Mad props to Wintermute, who is well on his way to clinching "Most Helpful Forum Member of 2016" title. I have incremented his total by the amount of one (1) Internet.
We have a system that uses HTTP/HTTPS interception to redirect that traffic to a guest login portal. Works just fine, prior to QUIC.
With QUIC, if a user has Google as a home page, that HTTP hijack does not work. Instead, if the device does not have connectivity, the browser displays an error message saying QUIC could not connect. I observed this on my Android doing some testing, and was thrilled to get the error message. The service manager, being less technical, did not share my enthusiasm for error messages. The vendor is looking at it in the lab. Fun times.
Hi Dean, have you had any more progress or interaction with this? Did you need to do anything on the back of those labs?
I noticed of late that when in places like the airport with *FREE WIFI*, that a lot of the time my devices are not redirected to the captive portal. I've never been interested to try and find out why, I think I've just assumed the people who've set it up havent done something correctly. The usual fix for me is to keep refreshing the page or trying to reach google.com and eventually you're taken to the portal where you can log in and achieve full internet access.
Reading your post Dean I'm wondering if QUIC is breaking this? Because if HTTP to Google.com is going via / attempting to go via UDP/443 and the portal is not set up to capture / forward udp/443 then could this be it? My home pages are default google, so this would make sense if this is true.
I also run a captive portal in our office for the guest wifi on a WLC. Pondering if I need to do anything to it :)
The free wifi without captive portal can be fixed in one of a few ways:
1. Use a different browser. IE typically has the best results for me. I log on with that, and then hit Chrome for to do my actual browsing.
2. Keep refreshing, always a good move.
3. Go to espn.go.com. It's in HTTP (as of this writing) and for some reason, HTTP redirects with more fidelity than HTTPS.
4. Decide not to use "free wifi" because it's probably a criminal hoping to harvest your financial data.
I just opened wireshark, turned on capturing and set a filter of: udp.port==443
I then opened google chrome which has the default homepage and wireshark lit up with protocol: QUIC and a ton of traffic.
Quote from: Dieselboy on September 14, 2016, 08:57:49 PM
I just opened wireshark, turned on capturing and set a filter of: udp.port==443
I then opened google chrome which has the default homepage and wireshark lit up with protocol: QUIC and a ton of traffic.
Yep. It's all about the QUIC with Google stuff.