MsQuic – QUIC Implementation from Microsoft(github.com) |
MsQuic – QUIC Implementation from Microsoft(github.com) |
This blog has details on current development status and adoption within Microsoft: https://techcommunity.microsoft.com/t5/networking-blog/msqui...
Maybe I skimmed too quickly but I didn't see this mentioned in that blog post.
Was there a requirement from other teams?
QUIC has the potential to be helpful in game development but suffers from an overly specialized approach.
edit: the spec (https://tools.ietf.org/html/draft-ietf-quic-tls-27) seems agnostic on this. Also simple APIs especially in security are important, so supporting certs only is no flaw in my book, just curious about the edges of how the OS QUIC could be used in the future.
I really like this version of Microsoft.
I hope they start giving more control to us, though, because I'm tired of having to firewall block telemetry and forced to have Cortana installed or whatever other garbage. If Microsoft allowed me to install Windows like I do Debian, where I can pick my packages and leave out what I don't want, and they also allowed for replacement APIs, so I could swap explorer.exe for my own version for example, I'd never use Linux again. But that'll never happen, so I'll just use tools to block that stuff for now and hope the Linux experience catches up.
Like any large corporation, MS is not a single cohesive entity and I suspect the Win10 group pushing metrics and Cortana is not the same folks writing nifty quic implementations.
Weird, I must have some different edition of Windows. Totally inconsistent settings/control panel interfaces, updates taking ages, updates failing when you look at it wrong (and then stuck in update-revert loop every boot), driver setup taking minutes, and I constantly discover some new disk-hogging background process.
But C? come on Microsoft.
Google and Apple have seen what happens to Microsoft's tenants, so they decided to be landlords. Microsoft knows how awful a landlord it had been (and after decades of landlord-only status, suffered abuse as a tenant at Google's gmail and youtube platforms), so it also tries to be a landlord in every way it can; It couldn't attract it's own tenants to Windows Phone, IE11 and its own Edge, so it has to offer subleases on Android, iOS and Blink(=Edgium) these days.
QUIC looks more "behind the scenes" as a platform right now, but building your own is a very cheap hedge against ceding complete control of what could become a potentially fundamental platform to your competitors. So everyone does that.
I'm no fan of Microsoft, and I believe that Microsoft has been "beaten to submission" rather than "left the dark side", so to speak. But regardless of the overall technical quality or moral/values one assigns to Microsoft - they are a smart, politically and business oriented and savvy corporation. This is a "staying relevant and in control" move.
Multiple implementations of a protocol are by no means a bad thing. The opposite is a problem - too few implementations means that the implementations dictate the spec and creating something compatible requires implementing bugs of those implementations too.
That said, I’d be surprised if we still had this many implementations 5 years from now. I think at least some of those will become unmaintained and instead use what Google/Microsoft/Mozilla/Cloudflare have developed.
Maybe this one can be added to the list.
Does that mean that a HTTP.SYS Webserver will also Support QUIC?
What use is to have Fort Knox security level if the foundations are built on top of quick sand.
https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-s...
As far as what we do to keep quality high, we have a large number of automated test (> 4000 cases per CI run) automated on Azure Pipelines. Our code is deployed on several interop servers used to test with all the other QUIC implementations out there, and we do additional testing and fuzzing internally at Microsoft.
Love the username, by the way :)
There'll also be static analysis being thrown at it
--
[1] https://www.reddit.com/r/cpp/comments/4oruo1/windows_10_code...
Microsoft C/C++ 7.0 was released in 1992 alongside MFC 1.0, which was a bit late to the race.
Microsoft was the latest C compiler vendor on the MS-DOS space to integrate a C++ compiler into their tooling.
Pre-shared keys are a thing in TLS 1.3 though there are subtle differences you ought to be aware of before implementing, but as I understand it SRP is not (at time of writing) and neither is anonymity.
It isn't possible to "just" take an extension to TLS 1.2 that altered the handshake mechanism and have it work in TLS 1.3 because the handshake is very different even though it was camouflaged so that rusted-in-place TLS 1.2 middleboxes think it's just TLS 1.2 and don't freak out.
API for the curious: https://docs.microsoft.com/en-us/windows/win32/http/http-api...
I personally would really love to switch to Ubuntu full time, but I'm not going to forgive it soon for bricking my machine after a software update.
Unfortunately for Linux, the automated recovery tools just aren't there like on Windows - if a Windows update breaks the system, it will be able to recover itself 90% of the time.
Yeah, the UI is shitty and inconsistent and there's lots of nonsense in the background, but ultimately those don't matter as much as baseline reliability. No one hunts for WiFi drivers on Windows, at least not since Vista.
This is not yet a full QUIC implementation, but we have plans for extending this codebase to cover more of the QUIC protocol.
• QUIC’s original implementation bound the transport protocol & app protocol to HTTP/2 - this was led by Google and is commonly referred to as “gQUIC”. This is what Chromium implemented and could be used via the Cronet library in other contexts. • A desire to use QUIC as a stand-alone transport layer (above UDP) grew, and is now standards-tracked as “IETF QUIC”. • HTTP/3 is a evolution (rather than a revolution) of HTTP/2 that requires IETF QUIC as a transport.
[1] https://support.office.com/en-us/article/what-is-money-in-ex...
See https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2....
The specification makes gRPC sound rather tightly bound to HTTP/2 level details, but I don't think it really is. You should be able to speak gRPC just fine over any kind of HTTP. One main pain point for browser support however had been APIs to exchange trailers, which are necessary for gRPC.
The headers frame, and the capability to have headers before AND after content is a requirement. gRPC requires trailing headers for the status code of the call. Trailing headers frame is a new concept in HTTP/2.
gRPC-Web supports HTTP/1.1 and browsers. It is able to do that by encoding the status into the end of the response body. However gRPC-Web is a different spec.
If HTTP/3+QUIC supports the same features of HTTP/2 then gRPC should work on it. There might be a HTTP/3 specific spec for details around the management of a HTTP/3 connection, but gRPC headers, message content, and proto contracts shouldn't need to change. Take what I say with a grain of salt because I haven't looked closely at HTTP/3+QUIC yet.
Therefore the fact that there is a frame involved doesn’t really matter.
HTTP/3 doesn’t change the HTTP semantics: Peers are sending 0-N informational headers, 1 set of request headers, a stream of body data, and 0-1 set of trailing headers. Therefore gRPC should run fine over it at long as the underlying HTTP library exposes all those necessary features.