TCP vs UDP

Due to Coronavirus (COVID19) all TCP applications are being converted to UDP to avoid handshake.

--- HTTP/3 is coming! And it won't use TCP! ---

A recent announcement reveals that HTTP - the protocol used by browsers to communicate with web servers - will get a major change in version 3!

Before, the HTTP protocols (version 1.0, 1.1 and 2.2) were all layered on top of TCP (Transmission Control Protocol).
TCP provides reliable, ordered, and error-checked delivery of data over an IP network.
It can handle hardware failures, timeouts, etc. and makes sure the data is received in the order it was transmitted in.
Also you can easily detect if any corruption during transmission has occurred.
All these features are necessary for a protocol such as HTTP, but TCP wasn't originally designed for HTTP!
It's a "one-size-fits-all" solution, suitable for *any* application that needs this kind of reliability.
TCP does a lot of round trips between the client and the server to make sure everybody receives their data. Especially if you're using SSL. This results in a high network latency.
So if we had a protocol which is basically designed for HTTP, it could help a lot at fixing all these problems.
This is the idea behind "QUIC", an experimental network protocol, originally created by Google, using UDP.

Now we all know how unreliable UDP is: You don't know if the data you sent was received nor does the receiver know if there is anything missing. Also, data is unordered, so if anything takes longer to send, it will most likely mix up with the other pieces of data. The only good part of UDP is its simplicity.
So why use this crappy thing for such an important protocol as HTTP?
Well, QUIC fixes all these problems UDP has, and provides the reliability of TCP but without introducing lots of round trips and a high latency! (How cool is that?)

The Internet Engineering Task Force (IETF) has been working (or is still working) on a standardized version of QUIC, although it's very different from Google's original proposal.
The IETF also wants to create a version of HTTP that uses QUIC, previously referred to as HTTP-over-QUIC. HTTP-over-QUIC isn't, however, HTTP/2 over QUIC.
It's a new, updated version of HTTP built for QUIC.

Now, the chairman of both the HTTP working group and the QUIC working group for IETF, Mark Nottingham, wanted to rename HTTP-over-QUIC to HTTP/3, and it seems like his proposal got accepted!
So version 3 of HTTP will have QUIC as an essential, integral feature, and we can expect that it no longer uses TCP as its network protocol.

We will see how it turns out in the end, but I'm sure we will have to wait a couple more years for HTTP/3, when it has been thoroughly tested and integrated.

Thank you for reading!

I'm pretty sure it was already posted in here, but I found it today

Did you get it?

A tcp packet walks in to a bar and says “I want a beer”, barman says “you want a beer?” and tcp packet says “yes, a beer” .

In high society, TCP is more welcome than UDP. At least it knows a proper handshake.

A bunch of TCP packets go into a bar, until it’s overcrowded. The next day, half as many go in.

A bunch of TCP packets walk into a bar. The bartender says, “Hang on just a second, I need to close the window.”

When I try to send SYNs to chicks, I don’t get any ACKs. Just FINs and RSTs.

IP packet with TTL=1 arrives at bar. Bartender: “Sorry, can’t let you leave…and you don’t get any beer either…” 

The worst part about token ring jokes is that if someone starts telling one while you are telling yours, all joking stops.

The great thing about TCP jokes is that you always get them.

The problem with TCP jokes is that people keep retelling them slower until you get them.

I would tell some UDP jokes too but I never know if anyone gets them

The best thing about UDP jokes is that I don’t care if you get them or not.

I had a funny UDP joke to tell, but I lost it somewhere...

The sad thing about IPv6 jokes is that almost no one understands them and no one is using them yet.

I tried to come up with an IPv4 joke, but the good ones were all already exhausted.

A DHCP packet walks into a bar and asks for a beer. Bartender says: “here, but I’ll need that back in an hour!

DHCP jokes only work when there is only one person telling them

The worst part of SSH jokes is that, even when they're not funny, you suck it up and just pretend they were anyway.

The problem with token ring jokes is you need to wait your turn to laugh

I’d make a joke about UDP, but I don’t know if anyone’s actually listening…

You won’t get it. But I don't care.... :)

Mother of god.

I spent hours and hours last week to try and get OpenVPN working. I mean, OpenVPN is working perfectly fine (on a VirtualBox (nope no vmware for me on servers) machine on a friends' dedicated server) but it wouldn't get through! As in, every forwarding/firewall rule just didn't work.

Was seriously about to lose my shit just now when I suddenly noticed the term 'TCP' in a forwarding rule.

Looked at the .ovpn file: proto udp

I added the exact same rule for UDP as a forward within VirtualBox.

It worked.

Well, there goes quite some hours 😐

And solely because I didn't realise that I setup a forwarding thingy for the wrong protocol.

I feel very stupid now :(

TCP Jedi: Master, how are you?
UDP Jedi: Good i am.

credit:@AlgoRythm

Due to COVID-19 all TCP applications are being converted to UDP to avoid handshakes!

UDP vs TCP

You know what, I'm out of devRant until Coronavirus is over. I can't take one more repost of the TCP UDP handshake shit.

TCP vs UDP...

First lecture of computer networks. Let's shove all of these abbreviations with their meaning, and possibly a associated port number in one 1.5 hour lecture:

HTTP, HTTPS, FTP, FTPS, SFTP, TCP, IP, UDP, ISP, DSL, DNS, LAN, WLAN, WDM, P2P, TELNET, PGP, TLS, SSL, SSH, MIME, SMTP, POP3, IMAP, IANA, DHT, RTT, DHCP

I really feel sorry for students who didn't have previous knowledge about this stuff..

Perfectly explained

Protocol!

So here I am reinventing the wheel making an HTTP server in C.
Finished implementing HTTP/1.1 and WebSockets support and now I find out the current thingy is HTTP/2.
Well that's fine, I'll add support for that later. In fact I kinda dig it since it uses binary conventions instead of plain text ones.
I dig a little bit and find out there already is an HTTP/3 going around which uses UDP.
Why me.

My school blocks all UDP traffic going outside their network. 1 - 65535. Which in turn means that I had to switch to TCP for my VPN to connect. Now my VPN is slow as shit. -.-

We converted all TCP APIs to UDP to ensure there are no handshakes...

Bash

Has pretty much everything you may need, except for a TCP/UDP server functionality.

I mean, if it has a built-in TCP client -- why not create simplistic TCP server?
WHY???

UDP joke, I don't care if you get it.

Here's something I'm sick of seeing: server software documentation that doesn't fully list what ports they are using. Too often I've read things like this: "AcmeServe uses ports 400, 8001, and 8002". Great, but why are you making me guess if those are TCP or UDP?

And sometimes it's: "AcmeServe uses ports 400 (UDP), 8001 (TCP), and 8002 (TCP)". Soooo, which ones do I port forward? Are you really going to make me have to use netstat -a to find out?

I can't understand the mentality behind that. They obviously realise you need to setup firewalls, but they half-arse it by only telling you the port numbers but not the protocol and/or if they're inbound/outbound.

Please, list what protocol the port is and if it's listening or outbound. Oh, and consider also mentioning where the port numbers come from in your config files, so I don't have to go playing a guessing game with a bunch of XML files should someone have overridden the default port numbers.

Tcp vs Udp

It must be good to at least know computer networking?! I remember nothing about these TCP, UDP, whatever the fudge protocol shite. I don't remember these megabit and megabyte things. All I do is code from one end to another. Anyone else watched Eli The Computer Guy's series?

So I was talking microservices architecture with some lead techs.
And I started asking how did they combine/connect their microservices.

And despite having a lot, they use HTTP as the main transporter.
So the put some API-Gateway, all inside traffic has to go through it, to connect to the final client.

And I said that I do meshing microservices, and we use Nats as man transporter, so our messages go through UDP and not TCP.

And they freaked out. Saying UDP is too low level and not useful...

My question: if you do microservices oriented architecture, and not SOA, do you use HTTP? Did you use it simply because "it works"?

Perfect! (Copyright : some Facebook page)

That moment when full-stack web development suddenly includes troubleshooting the TCP connections on your new listener.

#rememberthatoneclassinundergrad

so remember how I said I was sending TCP packets? screw that

UDP is life

I don't know if many rememeber me but at one point this year I had to turn UDP basically into tcp, handshake, packet ordering, resend on failed, ACK response, and 4k bit aes encryption. Fucking done, it works, signed the last version and pushed to client, client loved it, just what he wanted, paid out contract then turned around and asked me to setup his server for one day with no further expectations and an extra 250, said sure don't mind, as I am setting shit up I decided to test if his business isp really blocks tcp, guess what? NOPE IT WORKS JUSY FUXKIJG FINE AND I COILD HAVE KUST RIPPED A PREMADE CORE AND GOT PAID AND SET IT UP AND HE WOULD NEVER know, but maybe theirs some weird circumstances that require the core to be made only with udp, so after I was done I asked why only udp if his line allowed tcp? Requirements maybe? NOPE HE JUST DOSENT UNDERSTAND TCP FUUUUUUUQQQQHDJDIOAJEJDICJDNXIKZMZJDJCU

I have to take UDP and add packet ordering, filter in, and resend and some form of handshake, because client couldn't figure out how to change the port from UDP to TCP and refused any help

I’ve got a really good TCP/UDP joke to tell you, but I don’t know if you’ll get it

Ugh... I don't like how TCP is a stream protocol and how UDP is unreliable and unordered.

I want a semi-reliable, ordered, message protocol dang it!

I am working on an embedded system, a microcontroller-based design. The system has an Ethernet port. I am using NetX framework in the microcontroller firmware.
The DHCP Client is executed properly, an IP address is assigned correctly when connected to a router. I connect a laptop to the router using a LAN cable. Then TCP sockets behave the way they should, UDP broadcast behave the way they should. The only issue is, when I connect a Laptop over wireless to the same router UDP broadcast are received on application on Laptop, but data sent is not received on the embedded device.
Any idea why?

Platform:
Laptop is Windows
Embedded Device: Renesas S7G2, NetX framework.

A: Do you want to hear a joke about TCP/IP?

B: Yes, I would like to hear a joke about TCP/IP.

A: Are you ready to hear the joke about TCP/IP?

B: I am ready to head the joke about TCP/IP.

A: Here is a joke about TCP/IP.

A: Did you receive the joke about TCP/IP?

B: I have received the joke about TCP/IP.

Fuck you sophos. Fuck you hard. I moved a server to a new datacenter and it worked like a charm. Thank you windows and hyper-v. BUT! BUUUUUUT my fucking sophos worked like shit. Blocking everything by default? Yeah fuck you. Reconfigured everything. Still blocked and why? Forward “all“ doesnt mean forward all. Had to apply rules from port tcp 1 - 65335 and udp 1-65335. Nice you piece of fuck.