Live data from Hacker News

QUIC and the end of TCP sockets

codemia.io

81–83 of 83 posts

Re: QUIC and the end of TCP sockets

#81

One thing to note is that using HTTP2.0 for anything other than "this is not how to design high throughput protocols" is unfair. At the time HTTP2.0's multiplexing was known to be bad for anything other than perfect, low latency networks. I hope this was because people had faith in better connectivity, rather than ignorance of how mobile and non-lan traffic worked. You should probably at least try QUIC now, but you c…

Even on perfect networks HoL blocking is an issue. If the receiving end of a set of stream blocks on one stream, it ends up blocking the whole connection. One stream stops due to backpressure, all streams stop.

Oh yeah, but thats why HTTP2.0 was flawed from the start.

Re: QUIC and the end of TCP sockets

#82
post #35

The obnoxious thing is that overly aggressive firewalls have killed any IP protocols that are not TCP or UDP. Even ICMP is often blocked or partially blocked. In the mean time we could have had nice things: https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr... SCTP would be a fantastic protocol for HTTP/HTTPS. Pipelining, multi homing, multi streaming, oh my.

^^^^ this. I work for a big company (15k engineers). Trying to use anything that is not TCP or UDP simply doesnt work here. For years, even UDP was blocked and the answer we got was always "why are you using UDP, use TCP instead". Yep you read that right. Most of these folks are very short sighted or narrow minded. We tried to use SCTP for one project, major blunder. Zero support from network teams. Sctp is blocked e…

I'm one of a few people who can say they used SCTP for its original purpose, SIGTRAN transmission of Signaling System 7 call setup data over IPSec tunnels. It was really cool seeing SS7 packets in the wireshark dumps.
Post reply on HN