Quant developer HFT course · Module 7: The network
TCP versus UDP for trading
The question
Why do exchanges publish market data over UDP but take orders over TCP? Would you ever want it the other way round?
What TCP gives you, and what it costs
TCP provides an ordered, reliable byte stream between two endpoints:
- Reliability: lost segments are retransmitted until acknowledged.
- Ordering: data is delivered in the order it was sent; a segment that arrives early waits for the missing one.
- Flow control: the receiver advertises how much buffer it has, and the sender never sends more.
- Congestion control: the sender slows down when the network seems congested.
Each guarantee has a latency cost. The big one is head-of-line blocking: if one segment is lost, everything sent after it waits in the receiver's buffer until the retransmission arrives, which takes at least a round trip and, after a timeout, can be milliseconds. Every message behind the lost one is late, even though it arrived.
What UDP gives you
UDP sends independent datagrams with no connection, no retransmission, no ordering and no flow control. A datagram arrives promptly or not at all. Multicast, one packet delivered to every subscriber by the network itself, only exists for UDP.
Why market data is UDP multicast
- One to many. Thousands of participants need the same data at the same moment. With TCP, the exchange would need a connection to each and would send each packet thousands of times, in some order, making the first and last recipients wildly unequal. Multicast replicates packets in the switches.
- Fairness and timeliness. A slow subscriber cannot slow the feed for others, which TCP flow control would allow.
- Old data is worthless. A quote that arrives after a 200 ms retransmission is history. It is better to deliver the next packet on time and let the subscriber detect the loss.
Loss is handled at the application level instead: every packet carries a sequence number; subscribers detect gaps; redundant A and B feeds cover most single losses; and the exchange offers a recovery service, either a retransmission request over TCP or a separate snapshot feed from which the subscriber rebuilds its book (lesson 3).
Why orders are TCP
- One to one. Each participant's orders go to one gateway.
- Every message matters. A lost new order, cancel or fill must never be silently dropped, and order matters: a cancel must not overtake the order it cancels.
- Sessions. Exchange protocols layer logins, sequence numbers and resend logic on top, and TCP gives them a reliable stream to build on.
The latency costs of TCP matter less here because the order path is designed to never lose packets in the first place: short, dedicated, well-provisioned links with no congestion. In the normal case, a TCP send on such a link is as fast as UDP.
Would you ever invert it?
Some venues do use UDP for order entry, with their own sequence numbers and acknowledgements on top, to avoid TCP's retransmission timing and kernel processing. And some market data is delivered over TCP, usually for slower consumers, retransmission and snapshot services, or venues whose volumes do not justify multicast infrastructure. The general rule holds: broadcast data where freshness beats completeness goes over UDP with sequence numbers; point-to-point instructions where completeness and order are essential go over TCP or a reliable protocol built on UDP.
Reliable UDP in general
When teams build reliability on UDP themselves, they choose what to keep: sequence numbers for gap detection, negative acknowledgements (the receiver asks for what it missed) rather than positive ones, and no head-of-line blocking: later messages are processed immediately and the missing one is handled when it arrives, or skipped if it is no longer useful. That selective choice is the reason to do it.
Check yourself
Question 1 of 3
What is head-of-line blocking in TCP?
In-order delivery means data after a gap waits. On a lossy path, that turns one lost packet into delay for many messages.
Question 2 of 3
Why is multicast used for market data rather than one TCP connection per subscriber?
Multicast is efficient and fair for one-to-many data. It provides no reliability, which the application adds with sequence numbers and recovery services.
Question 3 of 3
Why can order entry use TCP without paying much latency in normal operation?
TCP's costs appear on loss and congestion. Infrastructure built to avoid both leaves TCP's per-message cost close to UDP's.
In the interview
Say your own answer out loud first, then open the one we would give.
Why is market data distributed over UDP multicast?
It is one-to-many: the network replicates each packet to every subscriber simultaneously, so the exchange sends once and nobody is systematically behind. UDP never delays later data waiting for retransmission of lost data, which suits information that loses value in milliseconds. Loss is detected with sequence numbers and covered by redundant feeds and recovery services.
Why are orders sent over TCP?
Each message must arrive, exactly once and in order, and the relationship is one client to one gateway. TCP provides that, and on dedicated low-loss links its extra latency in normal operation is small. Exchange session protocols add their own sequence numbers and resend logic on top.
What does TCP's reliability cost?
Head-of-line blocking after a loss, retransmission delays of at least a round trip and possibly a timeout, flow control that lets a slow receiver slow the sender, and congestion control that reduces the rate after loss. It also means more kernel processing per segment.