Netgate SG-1000 microFirewall

Author Topic: Google QUIC protocol issues  (Read 195 times)

0 Members and 1 Guest are viewing this topic.

Offline atxcoder

  • Newbie
  • *
  • Posts: 5
  • Karma: +0/-0
    • View Profile
Google QUIC protocol issues
« on: February 18, 2018, 09:42:37 pm »
So I have seen here and there mentions of the QUIC protocol and people trying to block it. Since everyone in my family is on Google and uses a Android phone and Chrome Browser on their laptops, I was getting complaints about slow Youtube, quic error message in Google Chrome, etc. I saw where QUIC uses port 80 and 443 both over UDP and even though I had a rule allowing it from any LAN source, it still had issues. The only workaround I have found so far is to block traffic over 80/443 UDP plus disable QUIC protocol in Chrome via the chrome flags.

The above Chrome flag fix worked on the laptops, but the issue still remain for things like the YouTube app on Android Phones. Anyone had similar issues? Solutions? I would love to fix this at the firewall level and not have to fix a bunch of client devices.

Offline Gertjan

  • Hero Member
  • *****
  • Posts: 2522
  • Karma: +201/-9
    • View Profile
Re: Google QUIC protocol issues
« Reply #1 on: February 19, 2018, 01:06:15 am »

I had to look up what that actually is, QUIC..
Is is comparable to SPDY, and if so, then
http/2 is the future for every browser.

pfSense handles TCP and UDP just fine, on every port. If something is blocking it for you, then it must be something upstream. Tread the mentioned Wiki page - and point number : it appears "some users" have UDP connectivity problems.
Possible, but be assured that doesn't come from pfSense.

Offline Harvy66

  • Hero Member
  • *****
  • Posts: 2341
  • Karma: +216/-12
    • View Profile
Re: Google QUIC protocol issues
« Reply #2 on: February 19, 2018, 12:12:46 pm »
QUIC is a layer 4/5 protocol that works around poor TCP implementations by streaming over UDP and handling congestion control itself. I assume BBR or something similar will replace this once TCP congestion control algorithms stabilize. A few main goals. Reduce buffer bloat, don't be so sensitive to loss because wifi is lossy, be sensitive to congestion based loss, quickly maximize bandwidth, packet pacing.

HTTP2/SPDY are layer 7 protocols. One of the main benefits is asynchronous multiplexing over a single stream, which allows browsers to stop creating tons of connections due to head-of-queue blocking in HTTP1.1. Lots of TCP connections are bad. Not only eat up more resources, but the have a "thundering herd" problem due to natural synchronization that occurs, and effectively a scaling factor on top of "slow start", making slow start less slow resulting in larger bursts that over congest links.
« Last Edit: February 19, 2018, 04:51:10 pm by Harvy66 »