Saw this update in my Windows Update list recently:
As it stands right now, this is what it says (in part):
OK, so I started off feeling good about this â€“ whatâ€™s not to like about the idea that DTLS, a security layer for UDP that works roughly akin to TLS / SSL for TCP, now can be made a part of Windows?
Sure, you could say â€śwhat about downstream versionsâ€ť, but then again, thereâ€™s a point where a developer should say â€śupgrading has its privilegesâ€ť. I donâ€™t support Windows 3.1 any more, and I donâ€™t feel bad about that.
No, the part I dislike is this one:
Note DTLS provides TLS functionalities that are based on the User Datagram Protocol (UDP) protocol. Because TLS is based on the Transmission Control Protocol (TCP) protocol, DTLS performs better than TLS.
Thatâ€™s just plain wrong. Actually, Iâ€™m not even sure it qualifies as wrong, and itâ€™s quite frankly the sort of mis-statement and outright guff that made me start responding to networking posts in the first place, and which propelled me in the direction of eventually becoming an MVP.
Yes, I was the nerdy guy complaining that there were already too many awful networking applications, and that promulgating stupid myths like â€śUDP performs better than TCPâ€ť or â€śthe Nagle algorithm is slowing your app down, just disable itâ€ť causes there to be more of the same.
But I think thatâ€™s really the point â€“ you actually do want nerds of that calibre writing your network applications, because network programming is not easy â€“ itâ€™s actually hard. As I have put it on a number of occasions, when youâ€™re writing a program that works over a network, youâ€™re only writing one half of the application (if that). The other half is written by someone else â€“ and that person may have read a different RFC (or a different version of the protocol design), may have had a different interpretation of ambiguous (or even completely clear) sections, or could even be out to destroy your program, your data, your company, and anyone who ever trusted your application.
Surviving in those circumstances requires an understanding of the purity of good network code.
Bicycle messengers are faster than the postal service, too. Fast isnâ€™t always what youâ€™re looking for. In the case comparing UDP and TCP, if it was just a matter of â€śUDP is faster than TCPâ€ť, all the worldâ€™s web sites would be running on some protocol other than HTTP, because HTTP is rooted in TCP. Why donâ€™t they?
Because UDP repeats packets, loses packets, repeats packets, and first of all, re-orders packets. And when your web delivery over UDP protocol retransmits those lost packets, correctly orders packets, drops repeated packets, and thereby gives you the full web experience without glitches, itâ€™s re-written large chunks of the TCP stack over UDP â€“ and done so with worse performance.
Donâ€™t get me wrong â€“ UDP is useful in and of itself, just not for the same tasks TCP is useful for. UDP is great for streaming audio and video, because youâ€™d rather drop frames or snippets of sound than wait for them to arrive later (as they would do with TCP requesting retransmission, say). If you can afford to lose a few packets here and there in the interest of timely delivery of those packets that do get through, your application protocol is ideally suited to UDP. If itâ€™s more important to occasionally wait a little in order to get the whole stream, TCP will outperform UDP every time.
Never choose UDP over TCP because you heard it goes faster.
Choose UDP over TCP because youâ€™d rather have packets dropped at random by the network layer than have them arrive any later than the absolute fastest they can get there.
Choose TCP over UDP because youâ€™d rather have all the packets that were sent, in the order that they were sent, than get most / many / some of them earlier.
And whether you use TCP or UDP, you can now add TLS-style security protection.
I await the arrival of encrypted UDP traffic with some interest.