Multipath TCP

Your phone often has two ways to reach the Internet at the same time — Wi-Fi and the cellular network. Ordinary TCP can only use one of them per connection: it picks a path and is stuck with it, so if you walk out of Wi-Fi range mid-download the connection breaks and has to start over. Multipath TCP asks a simple question: why not use both roads at once, and switch smoothly between them, while the app upstairs never even notices? It is like having two delivery trucks taking two roads to the same address, so if one road jams you still get your goods.

Multipath TCP is an extension to ordinary TCP that lets a single logical connection spread its data across several network paths, called subflows, at the same time. To the application it looks and behaves exactly like one normal TCP socket — same reliable, ordered byte stream — but underneath, the operating system opens one TCP subflow per available path (for example one over Wi-Fi and one over cellular), labels the bytes so they can be reassembled in order at the far end, and balances the load between them. If one subflow slows down or dies, the others carry the data; if a new path appears, a new subflow can join. The congestion control is coupled across subflows so that the combined connection plays fair with ordinary single-path TCP connections sharing the same links.

Why it matters: Multipath TCP makes connections more robust (survive a Wi-Fi-to-cellular handoff without dropping) and potentially faster (aggregate the bandwidth of two links). Apple uses it for services like Siri so a request is not lost when your phone changes networks. The honest caveats: it only helps when genuinely separate paths exist, the two paths may have very different delays which complicates reassembly, and old middleboxes that mangle unfamiliar TCP options can break it — which is part of why deployment has been gradual rather than universal.