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)

Yoko

I don't have any experience with the HFT field, but I suspect that TCP is used because it guarantees that the packet gets to it's destination, whereas UDP does not. – Helvetia

A UDP connection would be faster but not as reliable. It would be bad if you tried to sell your plummeting stock but your UDP packet didn't get through. That's probably why most people use TCP rather than UDP for HFT. – Dovev

Here's a post that talks to exactly this. – Dineric

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.

Tokoloshe

There are some funds which had their own optimised version of the kernel to reduce latency from network card to algo. – Marvismarwin

Not sure I agree. When a packet is lost, TCP will block the data flow to the application until successful retransmission. HFT data is like video - if you don't have a frame in time, forget it - it's too late - just get the next one. – Leonelleonelle

@BlankXavier: You have to weigh that against all the other things that TCP does that you do need, such as transmit pacing, duplicate packet detection, connection setup and tear down, and so on. You also have to consider the relative maturity and reliability of something you cook up yourself versus TCP. And from a performance standpoint, every modern platform has a heavily-optimized TCP stack including things like hardware offload. It's hard to match that yourself. – Tokoloshe

Those same platforms have heavily optimized UDP stacks, too and in these platforms there's a big return for the effort to write this code. Hell, these companies are implementing softwarei n FPGAs to get performance improvements. Implementing their own UDP transport wrapper is the right thing to do. – Leonelleonelle

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.

Beirut

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.

Diptych

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.

Gwynethgwynne

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.

Alice

With UDP, you can send batches of messages in one datagram, the newest one + some number of previous ones, so you can actually handle the packets in real-time; if one datagram gets lost, you receive its "newest" message in the next datagram. In TCP, you don't receive the next segment (and the newest message) until the lost one is retransmitted, period. – Lions

@Lions Would you care to explain how, within the context of OP's question which is HFT, that losing messages is a viable strategy rather than doing UDP based retransmission similar to SIP over UDP? Period? – Alice