High Frequency Trading - TCP > UDP?

Question

I was told that for a High Frequency Trading (HFT) system that requires low-latency, TCP is used over UDP. I was told that with TCP you can make point to point connections, whereas you cannot with UDP, however from my understanding you can send UDP packets to specific IP/port.

There are several arguments used in this article as to why UDP > TCP for gaming but I can see relevance for HFT.

Why would TCP be a better protocol to use for HFT?

(Admins: My previous post of this question was silently removed with no explanation. If I am violating terms of use please alert me of this instead of silently removing the question)

Answer 1

UDP is superior to TCP if you don't need some of the features TCP provides. Every feature has a cost, and so if you don't need features, you are paying that cost for no reason.

In an HFT application, you need pretty much every feature TCP requires. So if you picked UDP, you'd have to implement those features yourself. That means you'd have to implement connection establishment, connection teardown, retransmissions, transmit pacing, windows, and so on.

If there was a way to do all those things that was better than the way TCP was doing it, TCP would be doing it that way. You'd have one hand tied behind your back because TCP is heavily optimized by some of the best minds on the planet and implemented in/with the kernel.

Answer 2

There's no reasons to expect a stream of data over an already-established TCP connection would be slower than the same data over UDP, plus you get checksumming, retries, and all the other TCP goodness. UDP mainly wins in cases where you can afford to discard the reliability or where the overhead of many TCP handshakes would be too expensive, such as with common DNS queries.

Answer 3

TCP is faster for when using a few connections, the important difference is that modern NICs perform significant amounts of acceleration on TCP and not really that much for UDP. This means there is more overhead to process each UDP packet and as such they cannot compete unless you need to send to multiple recipients simultaneously.

However the UDP multicast route still suffers the same problems as unicast UDP per datagram overheads. Therefore many HFT systems use hardware accelerated systems that can multiplex the streams across many NICs via TCP, example Solace.

These days though you want to completely bypass the kernel with say a userspace IP stack such as by Solarflare or Mellanox, or even skip both the kernel and IP stack with RDMA.

Answer 4

Quite simply, if you need connection reliability (ensuring that every byte of data transmitted is received), you should be using TCP regardless.

As you mentioned, UDP is more suitable for games, where 100% accurate real-time tracking of every object would use quite a large amount of bandwidth and is unnecessary (this is where slow connections encounter lag).

There is no special difference between a TCP port and a UDP port, beyond the type of connection being used (send the packet and forget it, UDP style, or negotiate a connection and sustain it, TCP style) and the service listening on the server side. e.g. TCP/25 would usually reveal a SMTP server, whereas UDP/25 would not.

Answer 5

Basically, modern TCP implementations are going to be just as fast as UDP, if you're keeping the connection alive. If TCP is having to resend a packet, you'd need to resend it in UDP too. Plus for UDP you're going to end up implementing the same reliability code (retransmission of dropped packets) that TCP has already implemented.