Slashdot Mirror

← Back to Stories (view on slashdot.org)

QUIC: Google's New Secure UDP-Based Protocol

Posted by Soulskill on from the set-for-a-twelve-year-beta-test dept.

New submitter jshurst1 writes "Google has announced QUIC, a stream multiplexing protocol running over a new variation of TLS, as well as UDP. The new protocol offers connectivity with a reduced number of round trips, strong security, and pluggable congestion control. QUIC is in experiment now for Chrome dev and canary users connecting to Google websites."

2 of 97 comments (clear)

  1. Re:Don't trust 'em by SolarCanine · · Score: 4, Insightful

    What exactly can be hidden in an open protocol specification that will compromise your personally sensitive data? By design, a protocol has to be something that people can actually implement to be useful - the payloads you send via that protocol are up to you (based on your choices of which pieces of software to use, etc.)

  2. QUIC is more like TCP in these ways, exception to by raymorris · · Score: 4, Insightful

    > Please, if you can't use SSL+TCP for text chat and keep it real time

    They could have, but QUIC is "better" for their use cases. In many ways, it's like an improved version of TCP. It runs on top of UDP simply
    because routers, firewalls, etc. often only speak TCP and UDP. From the FAQ:

    > it is unlikely to see significant adoption of client-side TCP changes in less than 5-15 years. QUIC allows us to test and experiment with new ideas,
    > and to get results sooner. We are hopeful that QUIC features will migrate into TCP and TLS if they prove effective.

    > You can outright lose data. Your packets can arrive out of order. It's okay with video data where a hiccup only makes a few missing pixels,
    > but with text, that's a terrible idea.

    Unless of course the protocol you're running over UDP handles that stuff, just like TCP handles that stuff.
    Normally, it's a bad idea to use UDP to run a protocol that has in-order packets, guaranteed delivery, etc. because TCP already gives you that.
    Why re-invent TCP? Unless you're going to spend a few million dollars on R&D to make your UDP-based protocol actually be better than TCP,
    you should just use TCP.

    That "unless you're going to spend a few million dollars on R&D" is the key here. Google DID make the investment, so the protocol actually does
    work better for the particular use than TCP does.