Multipath TCP (MPTCP) Explained: How It Works

Updated on Nov 5, 2026

9 min read

Multipath TCP (MPTCP) is a transport protocol extension for devices that can reach the same service through more than one network path. It can keep one application connection alive while a phone changes between Wi-Fi and cellular, or use multiple links at once when policy and path conditions allow. This guide explains how MPTCP differs from ordinary TCP, what its components do, and how to inspect a small Linux test setup.

What Is Multipath TCP?

Ordinary TCP connection traffic follows one network path at a time. MPTCP extends TCP so the two endpoints can use multiple TCP flows, called subflows, as parts of one logical connection. To the application, the connection still presents a reliable, ordered byte stream. The endpoints coordinate which subflows carry data and reconstruct the original stream if packets arrive at different times.

MPTCP is specified in RFC 8684, an Internet Standards Track document. The Linux kernel MPTCP documentation describes its implementation, including path managers, schedulers, and application socket support. The community-maintained MPTCP project site provides implementation and development resources.

MPTCP is not simply two independent TCP connections bonded together by an application. It has connection-level sequence and acknowledgment mechanisms that coordinate data across its subflows, while each subflow retains TCP’s delivery mechanisms on its own path.

Why Does MPTCP Exist?

An application connection can be interrupted when a device changes networks or loses the interface carrying its TCP traffic. A phone might move out of Wi-Fi coverage while cellular service remains available. With ordinary TCP, the connection is tied to its active network addresses and path; changing that path often means creating a new transport connection and asking the application to recover.

Multiple interfaces can also be available at once, but ordinary TCP generally does not combine them for a single connection. An application could open parallel connections, yet it would then need to divide data, handle out-of-order results, coordinate failures, and preserve application semantics itself.

MPTCP moves that coordination into the transport layer. It can add a subflow over another address, keep a backup path available, or schedule traffic across usable subflows. This can improve continuity or use otherwise idle capacity, but only when both endpoints, the network, and their configuration support the necessary behavior.

How MPTCP Works

An MPTCP connection is a logical byte stream carried by one or more regular TCP subflows:

Application byte stream
          |
  MPTCP connection
     /          \
TCP subflow 1   TCP subflow 2
 Wi-Fi path      cellular path
     \          /
     IP networks

The connection begins with a TCP handshake that includes the MPTCP MP_CAPABLE option. If both endpoints accept MPTCP, they establish the connection’s MPTCP state and can exchange data using it. If the peer does not support MPTCP, or an in-path device prevents the required options from working, implementations can fall back to regular TCP. The connection then has one path rather than silently pretending to be multipath.

After setup, a peer can announce another address with an ADD_ADDR signal. The other endpoint may attempt an additional TCP handshake using the MP_JOIN option to create a subflow associated with the existing MPTCP connection. MPTCP authenticates this join with connection-related keys so that an unrelated connection cannot simply attach itself to the data stream. A peer can also remove an address, mark a subflow as a backup, or close a failed subflow.

Each subflow has its own TCP sequence space, which supports retransmission and delivery on that path. MPTCP adds a data sequence space for the combined connection. Mapping information associates subflow bytes with positions in the logical stream, allowing the receiver to reorder data from paths with different latency and deliver a single ordered stream to the application. This separation is what lets one path fail without necessarily losing the whole connection.

Path quality can change while data is in flight. If a link becomes unavailable, data may be retransmitted or reinjected over a usable subflow, subject to the implementation’s state and policy. MPTCP therefore helps with continuity, but it does not make every handover instantaneous: detection, address reachability, retransmission, and application timeouts still affect the interruption.

Key Components and TCP Comparison

Feature	Regular TCP	MPTCP
Application interface	Reliable, ordered byte stream	Reliable, ordered byte stream
Paths in one connection	One active path	One or more TCP subflows
Path changes	May require a new connection	Can add or switch subflows when configured and reachable
Data ordering	TCP orders bytes on its connection	MPTCP reassembles bytes across subflows
Bandwidth use	Uses the selected path	May schedule traffic over multiple paths
Endpoint support	Widely supported	Both peers need MPTCP support to use multiple paths
Compatibility	Standard TCP behavior	Can fall back to TCP when MPTCP negotiation is unavailable
Operational tuning	TCP and route configuration	Also needs path discovery, subflow policy, and scheduling decisions

Two implementation components shape how paths are used:

Path manager: Tracks local and peer addresses and manages subflow creation and removal. Linux has an in-kernel path manager and supports userspace management. Administrators can configure eligible local addresses with the ip mptcp commands.
Packet scheduler: Chooses which usable subflow sends the next data. A policy may favor one path, keep another as backup, or distribute data according to implementation-specific criteria. A scheduler cannot use a path that routing, address advertisement, or network policy has not made reachable.
Congestion control: Each subflow must respond to congestion on its own path, while multipath behavior must also avoid taking an unfair share when subflows cross a shared bottleneck. RFC 6356 describes an experimental coupled congestion-control design; actual algorithms and defaults depend on the implementation.

MPTCP does not guarantee that the paths are physically independent. Wi-Fi and cellular routes may converge on the same upstream network, so a shared outage or bottleneck can affect both. Nor does adding subflows guarantee a throughput increase: a slow interface, remote-server limits, reordering, or policy may make a single preferred path better.

Real-World Use Cases

Mobile connection continuity is a prominent use case. A device can maintain an application session while it moves between interfaces, provided the remote service supports MPTCP and the device can create a reachable subflow. This is a transport-level mechanism; it does not perform the cellular network’s radio handover itself.

Multi-WAN systems can use a fixed broadband connection and a mobile uplink together. Depending on the path policy, the system may keep the mobile link as backup, move traffic away from congestion, or use both paths for a transfer. Operators should account for metered data, differing latency, and whether both providers actually use separate failure domains.

Edge, data-transfer, and server workloads may benefit when endpoints have multiple usable network interfaces and the workload can tolerate the scheduling behavior. These are engineering choices, not automatic wins: the service’s socket API, kernel, firewall, NAT, routing, and monitoring all need to be compatible.

MPTCP is distinct from link aggregation configured only between adjacent switches. Link aggregation works at the link layer across a local segment, while MPTCP coordinates end-to-end TCP subflows between transport endpoints. A deployment might use either approach, both, or neither depending on its topology.

Test MPTCP on Linux

MPTCP support depends on the Linux kernel configuration and user-space tools. On Debian or Ubuntu, install the networking utilities and a test tool from the distribution repositories:

sudo apt install iproute2 iperf3 mptcpd

Check whether the running kernel allows MPTCP sockets and inspect the configured endpoints:

sysctl net.mptcp.enabled
ip mptcp endpoint show
ip mptcp limits show

The kernel setting is enabled by default on many supported Linux systems. If it is disabled and you control the host, enable it for a temporary lab test:

sudo sysctl -w net.mptcp.enabled=1

For a two-host test, configure a second reachable interface on both hosts and use addresses actually assigned to those interfaces. On the server, announce its secondary address; on the client, allow that local address to start an additional subflow. Replace the example interface names and addresses with values from your lab:

# On the server: announce its additional address to the peer.
sudo ip mptcp endpoint add 10.10.2.20 dev eth1 signal

# On the client: use its additional address for an extra subflow.
sudo ip mptcp endpoint add 10.10.2.10 dev eth1 subflow

Make sure the routes and firewalls allow the test traffic between both address pairs. Start an MPTCP-enabled iperf3 listener on the server and run a test from the client:

# Server
mptcpize run iperf3 -s

# Client
mptcpize run iperf3 -c SERVER_PRIMARY_IP -t 30

mptcpize is provided by mptcpd and runs a compatible TCP application using MPTCP sockets. A standard iperf3 run without MPTCP socket support would test ordinary TCP instead. Observe path-manager events while the test runs and review the configured endpoints:

ip mptcp monitor
ip mptcp endpoint show

Compare repeated tests with and without MPTCP under the same conditions. Record throughput, latency, retransmissions, and whether both subflows were established; a throughput result alone does not prove that the second path was used. Run load tests only between systems and networks you administer, because they consume bandwidth. Remove only the endpoint IDs you added for the test with ip mptcp endpoint delete id ID; avoid flushing shared host configuration.

Common Misconceptions

“MPTCP always doubles throughput”

No. The scheduler may not use both paths, the paths may share a bottleneck, and the receiving application or server can be the limiting factor. MPTCP provides a mechanism for multipath transport, not a bandwidth guarantee.

“MPTCP works with any TCP server without changes”

Both ends need MPTCP-capable transport support to establish multiple subflows. Some Linux applications can be wrapped with mptcpize, while other applications must request an MPTCP socket directly. If negotiation fails, fallback may preserve a TCP connection but does not create multiple paths.

“MPTCP encrypts or replaces TCP”

MPTCP is a transport extension, not encryption. It does not replace TLS or an application’s authentication. It extends TCP with signaling and data mapping so one logical stream can use multiple TCP subflows.

TCP, UDP, and HTTP explained distinguishes transport protocols from application protocols.
Cellular network architecture explained shows where radio mobility and transport paths fit in a mobile network.
TCP congestion control: CUBIC vs BBR explains how TCP senders adapt to network capacity.
Linux network troubleshooting covers tools for diagnosing routes, interfaces, and connectivity.
Wi-Fi 7 Multi-Link Operation explained describes a different, link-layer approach to using multiple wireless links.

Changelog

Initial publication.

Last updated: 5 November.