다중경로 TCP(MPTCP, Multipath TCP)
1. 개요
가. 정의
MPTCP(Multipath TCP)는 하나의 TCP 연결을 여러 네트워크 경로(서브플로우)에 걸쳐 동시에 전송하면서도, 애플리케이션에는 단 하나의 표준 TCP 소켓처럼 보이게 하는 전송계층 확장 프로토콜이다. IETF가 RFC 6824(v0, 2013)로 표준화하고 RFC 8684(v1, 2020)로 개정했으며, TCP 옵션 필드를 이용해 여러 인터페이스(LTE·Wi-Fi 등)를 하나의 논리적 연결로 묶는다.
나. 등장 배경 및 필요성
오늘날 단말은 둘 이상의 네트워크 인터페이스를 동시에 보유하는 것이 일반적이다. 스마트폰은 셀룰러(LTE·5G)와 Wi-Fi를, 데이터센터 서버는 다중 NIC를, 노트북은 유선과 무선을 함께 갖는다. 그러나 전통적 TCP는 연결을 수립할 때 선택한 출발지/목적지 IP와 포트의 4-튜플에 고정되어, 그중 한 경로가 끊기거나 혼잡해져도 다른 인터페이스로 옮겨 타지 못한다. Wi-Fi 신호가 약해지면 셀룰러가 멀쩡히 살아 있어도 다운로드가 멈추는 경험이 그 전형적 사례다. 즉 단말에는 여유 자원이 있는데 TCP의 경직된 연결 모델이 그 자원을 활용하지 못하는 구조적 비효율이 존재한다.
이 문제를 해결하려는 직관적 발상은 "여러 경로를 동시에 쓰자"는 것이지만, 실현은 간단하지 않다. 인터넷에는 NAT·방화벽·프록시 같은 미들박스(middlebox)가 TCP 헤더를 검사·변형하기 때문에, 완전히 새로운 전송 프로토콜은 중간에서 차단되기 쉽다. MPTCP는 이 현실을 수용해 기존 TCP와 선로(wire) 호환성을 유지하는 설계를 택했다. 새 프로토콜 번호를 쓰지 않고 기존 TCP 세그먼트의 옵션 필드에 제어 정보를 실어, 미들박스에는 평범한 TCP처럼 보이되 양 끝단(end host)만이 다중경로로 이해하도록 한 것이다. 이 "점진적 배치 가능성(incremental deployability)"이야말로 수많은 멀티패스 전송 제안 중 MPTCP가 실제 상용화에 이른 핵심 이유다.
필요성은 세 가지 가치로 집약된다. 첫째는 처리량 증대(bandwidth aggregation)로, 여러 경로의 대역폭을 합쳐 더 빠른 전송을 얻는다. 둘째는 복원력(resilience)으로, 한 경로가 끊겨도 나머지 경로로 연결을 유지해 끊김 없는 핸드오버를 제공한다. 셋째는 혼잡 분산(load balancing)으로, 혼잡한 경로의 트래픽을 여유 있는 경로로 옮겨 네트워크 전체의 효율을 높인다. 이 세 가치는 모바일·데이터센터·IoT 등 다중 연결 환경이 보편화될수록 중요도가 커지고 있다.
다. 설계 목표와 특징
MPTCP의 설계는 RFC 6356이 명시한 세 가지 목표로 요약된다. (1) 처리량 개선: 여러 경로를 함께 쓰는 MPTCP 연결은 가장 좋은 단일 경로 하나를 쓰는 것보다 성능이 나빠서는 안 된다. (2) 무해성(do no harm): MPTCP의 모든 서브플로우가 공유 병목에서 차지하는 총량은, 같은 병목에서 단일 경로 TCP 하나가 차지하는 양을 넘지 않아야 한다. (3) 혼잡 균형(balance congestion): 가능한 한 혼잡이 덜한 경로로 트래픽을 몰아 전체 네트워크의 혼잡을 낮춘다.
이 목표들은 서로 긴장 관계에 있다. 처리량만 좇으면 공정성을 해치고, 공정성만 지키면 멀티패스의 이점이 사라진다. MPTCP가 결합 혼잡제어(coupled congestion control)라는 독특한 메커니즘을 도입한 이유가 바로 이 균형을 맞추기 위함이다. 즉 MPTCP의 기술적 핵심은 단순히 "경로를 여러 개 쓴다"가 아니라, 여러 경로를 쓰되 기존 인터넷 생태계에 공정하고 무해하도록 제어한다는 데 있다.
2. MPTCP 전체 구조와 프로토콜 스택
MPTCP는 애플리케이션과 개별 TCP 서브플로우 사이에 MPTCP 계층을 삽입하는 구조다. 애플리케이션은 평소처럼 하나의 소켓에 대고 send()/recv()를 호출하지만, 그 아래에서 MPTCP 계층이 데이터를 여러 서브플로우로 쪼개 보내고 수신 측에서 다시 순서대로 재조립한다. 각 서브플로우는 그 자체로 완결된 정규 TCP 연결이어서 자신만의 시퀀스 번호·혼잡 윈도우·재전송을 독립적으로 관리한다. 아래 구조도는 이 계층 관계와 두 서브플로우의 구성을 보여준다.
flowchart TB
APP["애플리케이션 (단일 소켓 API)"]
subgraph MP["MPTCP 계층"]
SCH["스케줄러 (어느 경로로 보낼지)"]
DSS["데이터 시퀀스 매핑 (DSS)"]
PM["경로 관리자 (서브플로우 생성/제거)"]
end
subgraph SF["서브플로우 (각각 정규 TCP)"]
SF1["서브플로우 1 : Wi-Fi 경로"]
SF2["서브플로우 2 : LTE 경로"]
end
APP --> MP
SCH --> SF1
SCH --> SF2
DSS -. "연결 레벨 순서 보장" .-> SF1
DSS -. "연결 레벨 순서 보장" .-> SF2
SF1 --> NET["IP 네트워크 (미들박스 통과)"]
SF2 --> NET
구조의 중심에는 두 개의 시퀀스 공간이 있다. 각 서브플로우는 미들박스를 속이기 위해 자신만의 TCP 시퀀스 번호를 그대로 유지한다. 동시에 MPTCP는 연결 레벨의 64비트 데이터 시퀀스 번호(DSN)를 별도로 두고, 어떤 바이트가 전체 데이터 스트림의 어디에 해당하는지를 추적한다. 이 둘을 연결해 주는 것이 DSS(Data Sequence Signal) 옵션으로, "이 서브플로우의 시퀀스 X부터 Y바이트는 연결 레벨의 DSN Z에 매핑된다"는 사상(mapping) 정보를 실어 나른다. 수신 측은 여러 서브플로우로 뒤섞여 도착한 조각들을 DSS 매핑에 따라 올바른 순서로 재조립(reassembly)한 뒤 애플리케이션에 넘긴다.
이 이중 시퀀스 설계가 MPTCP의 정수다. 만약 연결 레벨 시퀀스가 없다면 수신 측은 서로 다른 경로로 온 데이터의 전역 순서를 알 수 없고, 반대로 서브플로우 레벨 시퀀스가 없다면 미들박스가 "시퀀스에 구멍이 났다"고 오판해 연결을 끊거나 변조할 수 있다. 두 공간을 분리함으로써 MPTCP는 미들박스 호환성과 경로 독립성을 동시에 달성한다. 주요 구성요소를 정리하면 다음과 같다.
| 구성요소 | 역할 | 비고 |
|---|---|---|
| 서브플로우(Subflow) | 하나의 경로를 담당하는 정규 TCP 연결 | 독립 혼잡윈도우·재전송 |
| DSS 매핑 | 서브플로우 ↔ 연결 레벨 시퀀스 사상 | 64비트 DSN, 재조립 기준 |
| 토큰/키 | 연결 식별·서브플로우 인증 | HMAC 기반 MP_JOIN 검증 |
| 경로 관리자 | 서브플로우 추가/삭제 결정 | full-mesh, ndiffports 등 |
| 스케줄러 | 패킷을 어느 경로로 보낼지 결정 | minRTT(기본), BLEST, RR 등 |
3. 연결 수립과 서브플로우 관리 절차
MPTCP 연결은 평범한 TCP 핸드셰이크에 MP_CAPABLE 옵션을 얹는 것으로 시작한다. SYN·SYN/ACK·ACK 3-way 과정에서 양측이 MP_CAPABLE을 교환하면 서로가 MPTCP를 지원함을 확인하고, 이때 교환한 키로 연결 고유의 토큰과 서브플로우 인증용 비밀을 생성한다. 만약 상대가 MP_CAPABLE을 이해하지 못하거나 중간 미들박스가 옵션을 제거하면, 연결은 조용히 일반 TCP로 폴백(fallback)한다. 이 "실패해도 보통 TCP로 동작"하는 성질이 MPTCP를 안전하게 배치할 수 있게 하는 토대다.
첫 서브플로우가 서면 이후 추가 경로는 MP_JOIN 옵션으로 결합한다. 단말이 두 번째 인터페이스(예: LTE)로 새 TCP 핸드셰이크를 열면서 MP_JOIN에 기존 연결의 토큰과 HMAC 인증값을 실으면, 상대는 그것이 같은 논리적 연결에 속하는 새 경로임을 인증·확인하고 받아들인다. 이 인증 절차는 제3자가 임의로 남의 연결에 서브플로우를 끼워 넣는 공격을 막는 역할을 한다. 아래 시퀀스도는 초기 수립부터 두 번째 서브플로우 결합, 데이터 전송, 연결 종료까지의 흐름을 보여준다.
sequenceDiagram
participant C as 클라이언트
participant S as 서버
Note over C,S: 1단계 - 첫 서브플로우 수립 (Wi-Fi)
C->>S: SYN + MP_CAPABLE (키 교환)
S->>C: SYN/ACK + MP_CAPABLE
C->>S: ACK + MP_CAPABLE
Note over C,S: 2단계 - 두 번째 서브플로우 결합 (LTE)
C->>S: SYN + MP_JOIN (토큰 + HMAC)
S->>C: SYN/ACK + MP_JOIN (HMAC 검증)
C->>S: ACK
Note over C,S: 3단계 - 데이터 전송 (DSS 매핑으로 분산/재조립)
C->>S: 데이터 조각 A (Wi-Fi, DSS)
C->>S: 데이터 조각 B (LTE, DSS)
S->>C: 연결 레벨 ACK (DATA_ACK)
Note over C,S: 4단계 - 종료 (DATA_FIN)
C->>S: DATA_FIN
S->>C: DATA_ACK
연결 수립 이후에도 MPTCP는 경로 상태를 동적으로 관리한다. 특정 서브플로우를 평시에는 쓰지 않고 백업으로만 두도록 표시하는 MP_PRIO 신호, 사라진 주소를 상대에게 알려 해당 서브플로우를 정리하게 하는 REMOVE_ADDR 신호가 대표적이다. 또한 종료는 두 수준으로 나뉘는데, 개별 서브플로우는 평범한 TCP FIN으로 닫히지만 연결 전체는 연결 레벨의 DATA_FIN으로 끝나므로, 일부 경로가 먼저 닫혀도 데이터 스트림 전체의 정합성은 유지된다. 이처럼 제어 신호가 서브플로우 레벨과 연결 레벨로 이원화되어 있다는 점이 MPTCP 상태 관리의 특징이다.
경로의 생성과 소멸을 결정하는 주체가 경로 관리자(Path Manager)다. 어떤 인터페이스가 새로 활성화됐을 때 즉시 서브플로우를 추가할지, 몇 개까지 둘지, 끊긴 경로를 언제 정리할지를 정책으로 관리한다. 리눅스 구현은 모듈형 경로 관리자를 제공하는데, 가능한 모든 주소 쌍으로 서브플로우를 만드는 full-mesh, 같은 주소 쌍에 포트만 달리해 여러 흐름을 만드는 ndiffports 등이 대표적이다. 또한 한쪽이 자신이 가진 추가 주소를 상대에게 알리는 ADD_ADDR 신호를 통해, 서버 뒤의 NAT 환경에서도 상대가 어떤 주소로 서브플로우를 열 수 있는지 광고한다. 경로 관리자의 정책은 처리량·배터리·비용(셀룰러 과금) 사이의 트레이드오프를 직접 좌우하므로, 모바일 환경에서는 "기본은 Wi-Fi, 끊기면 LTE" 같은 핸드오버 지향 정책이, 데이터센터에서는 "가용 경로 전부 묶기" 같은 집약 지향 정책이 쓰인다.
4. 핵심 메커니즘: 스케줄러·혼잡제어
가. 패킷 스케줄러
스케줄러는 매 전송 시점에 "이 데이터 조각을 어느 서브플로우로 내보낼 것인가"를 결정하는 두뇌다. 리눅스 기본 스케줄러는 최소 RTT(minRTT) 방식으로, 혼잡 윈도우에 여유가 있는 서브플로우 중 왕복지연이 가장 짧은 경로를 우선 사용한다. 지연이 짧은 경로를 먼저 채우고 넘칠 때 다음 경로를 쓰는 전략이어서, 단일 빠른 경로 상황에서 불필요한 느린 경로 사용을 억제한다.
문제는 경로들의 성능이 서로 크게 다를 때(heterogeneous) 발생한다. 빠른 Wi-Fi와 느린 LTE를 함께 쓰면, 느린 경로로 보낸 조각이 늦게 도착해 수신 버퍼에서 머리 막힘(Head-of-Line Blocking)을 일으킨다. 이미 도착한 빠른 경로의 뒷부분 데이터가, 느린 경로의 앞부분이 올 때까지 애플리케이션에 전달되지 못하고 대기하는 것이다. 이를 완화하려고 BLEST(버퍼 점유 예측), ECF(Earliest Completion First, 완료시각 예측), RR(라운드로빈), redundant(동일 데이터를 여러 경로로 중복 전송해 지연 최소화) 등 다양한 스케줄러가 제안됐다. 예컨대 지연에 극도로 민감한 원격제어·음성 트래픽에는 대역폭을 희생하더라도 중복 스케줄러로 최단 도착 시간을 보장하는 식의 선택이 이뤄진다.
스케줄러 선택은 곧 응용 특성에 대한 최적화다. 대용량 파일 다운로드는 총 처리량이 중요하므로 모든 경로를 꽉 채우는 편이 좋고, 화상회의는 지연·지터가 중요하므로 안정적인 단일 경로 위주에 보조 경로를 백업으로 두는 편이 낫다. 하나의 스케줄러가 모든 상황에 최적일 수 없다는 점이 MPTCP 운영의 핵심 난제이며, 최근에는 강화학습 기반 적응형 스케줄러 연구도 활발하다.
이기종 네트워크를 다룬 최근 실험 연구들은 스케줄러와 혼잡제어의 조합이 성능을 좌우함을 보여 준다. 예를 들어 minRTT·ECF·RR 계열 스케줄러는 결합형 손실 기반 혼잡제어와 맞물릴 때 BLEST·LLHD 계열보다 나은 처리량을 내는 반면, 지연 편차가 극심한 구간에서는 완료시각을 예측하는 ECF가 머리 막힘을 더 잘 억제하는 식이다. 결국 "어떤 스케줄러가 절대적으로 우수한가"가 아니라 "주어진 경로 조합과 응용 요구에 어떤 스케줄러·혼잡제어 쌍이 맞는가"라는 설정 문제로 귀결되며, 이 점이 MPTCP를 단순 기능이 아닌 운영 역량의 영역으로 만든다.
나. 결합 혼잡제어(Coupled Congestion Control)
각 서브플로우가 단순히 독립적인 TCP 혼잡제어를 돌리면, MPTCP 연결은 공유 병목에서 n개의 일반 TCP 연결처럼 행동해 다른 사용자보다 n배의 대역을 가로채는 불공정을 저지른다. 이를 막기 위해 MPTCP는 여러 서브플로우의 혼잡 윈도우 증가를 서로 연동(coupling)해, 전체 연결이 공유 병목에서 대략 일반 TCP 하나만큼만 공격성을 갖도록 억제한다. 동시에 혼잡이 덜한 경로의 윈도우를 더 키워 트래픽을 그쪽으로 자연스럽게 이동시킨다.
구체적 알고리즘으로는 원조 격인 LIA(Linked Increases Algorithm, RFC 6356), 그 공정성 결함을 개선한 OLIA(Opportunistic LIA), 응답성과 안정성의 균형을 노린 BALIA(Balanced Linked Adaptation), 지연 기반의 wVegas 등이 리눅스 커널에 구현되어 sysctl로 선택할 수 있다. LIA는 단순하지만 때때로 단일 경로 TCP에 과도하게 공격적이라는 지적이 있어, OLIA·BALIA가 이를 보정한다. 이처럼 "경로는 여럿이되 네트워크에는 하나처럼 행동하게" 만드는 것이 결합 혼잡제어의 본질이며, 이는 MPTCP가 QUIC 멀티패스 등 후속 프로토콜 설계에도 넘겨준 중요한 유산이다.
다. 수신 버퍼와 재조립
MPTCP의 체감 성능은 수신 버퍼 크기에 크게 좌우된다. 경로 간 지연 차가 클수록 느린 경로를 기다리는 동안 빠른 경로 데이터를 담아 둘 버퍼가 커야 하기 때문이다. 버퍼가 부족하면 머리 막힘이 심해져 멀티패스가 오히려 단일 경로보다 느려지는 역효과가 난다. 따라서 실무에서는 경로 특성(대역폭·지연)을 고려해 수신 버퍼를 넉넉히 잡고, 스케줄러가 느린 경로로 보내는 양을 제한하도록 튜닝한다. 이 상호작용 때문에 MPTCP의 성능은 "경로 수를 늘리면 선형으로 좋아진다"가 아니라, 스케줄러·혼잡제어·버퍼가 함께 맞물린 시스템 최적화 문제로 다뤄야 한다.
직관적 수치로 보면 이해가 쉽다. 대략적인 산정식으로 필요한 수신 버퍼는 총 대역폭 × 최대 경로 RTT 수준이 되어야 한다. 예를 들어 100Mbps Wi-Fi(RTT 20ms)와 50Mbps LTE(RTT 80ms)를 함께 쓴다면, 합산 150Mbps를 가장 느린 80ms 동안 수용하려면 약 150Mbps × 80ms ≈ 1.5MB 내외의 버퍼가 필요하다. 커널 기본값(수백 KB)으로는 부족해 느린 경로가 도착할 때마다 전송이 멈추는 현상이 나타나며, 이것이 "LTE를 더했더니 오히려 느려졌다"는 흔한 오해의 실제 원인이다. 따라서 이기종 경로를 묶을 때는 버퍼 상향과 더불어, 이득이 없는 느린 경로는 스케줄러가 백업으로만 쓰도록 억제하는 설정이 함께 필요하다.
5. 단일경로 TCP·QUIC 멀티패스와의 비교
MPTCP를 일반 TCP와 가르는 결정적 차이는 경로 이동성이다. 일반 TCP는 연결이 4-튜플에 묶여 인터페이스가 바뀌면 연결이 끊기지만, MPTCP는 서브플로우를 더하고 빼며 연결을 유지한다. 그 결과 Wi-Fi 음영지역을 지나며 LTE로 전환돼도 영상 스트림이 끊기지 않는다. 다만 MPTCP는 이 이점을 공짜로 얻지 못한다. 미들박스가 옵션을 제거하면 폴백해야 하고, 두 시퀀스 공간과 재조립 로직으로 구현 복잡도와 버퍼 비용이 커진다.
QUIC의 멀티패스 확장과의 비교는 최근 중요한 출제·실무 논점이다. QUIC은 UDP 위에서 동작하며 연결 식별자(Connection ID)로 경로를 식별하므로, IP가 바뀌어도 핸드셰이크 없이 연결을 이어가는 커넥션 마이그레이션이 프로토콜에 내장돼 있다. 반면 MPTCP는 TCP 생태계와의 호환성이 강점이지만 미들박스 간섭에 취약하다. 즉 "기존 인프라와의 호환(MPTCP)"과 "암호화된 UDP 기반의 유연성(QUIC)"이라는 서로 다른 설계 철학의 산물로 이해해야 하며, 둘은 경쟁이자 상호 보완 관계에 있다. 아래 표는 핵심 차이를 비교한 것이다.
| 구분 | 단일경로 TCP | MPTCP | QUIC 멀티패스 |
|---|---|---|---|
| 경로 수 | 1개 고정 | 다중 서브플로우 | 다중 경로 |
| 인터페이스 전환 | 연결 끊김 | 서브플로우로 유지 | 커넥션 마이그레이션 |
| 미들박스 호환 | 높음 | 옵션 제거 시 폴백 | UDP 차단 시 취약 |
| 암호화 | 선택(TLS) | 선택(TLS) | 기본 내장 |
| 재조립 비용 | 낮음 | 높음(이중 시퀀스) | 중간 |
6. 심화: 표준·구현 동향과 실무 적용 사례
표준 측면에서 MPTCP는 RFC 6824(v0)에서 RFC 8684(v1, 2020)로 개정되며 옵션 형식과 폴백 처리가 정비됐고, 서버 측 배치를 돕는 0-RTT TCP Converter(RFC 8803) 같은 프록시 표준도 나왔다. 리눅스는 오랫동안 외부 패치(multipath-tcp.org)로만 제공되다가, 커널 5.6(2020년 3월)부터 업스트림에 정식 통합되어 모듈형 경로 관리자·스케줄러·혼잡제어를 기본 제공하게 됐다. 이는 MPTCP가 연구 단계를 넘어 범용 운영체제의 표준 기능으로 자리 잡았음을 보여주는 이정표다.
가장 널리 알려진 상용 사례는 애플의 Siri다. 애플은 2013년 iOS 7부터 Siri 트래픽에 MPTCP를 적용해, Wi-Fi와 셀룰러를 오가며(switching) 응답 지연과 네트워크 실패를 줄였다. 주목할 점은 애플의 초기 적용이 대역폭을 합치는 '본딩'이 아니라, 끊김 없이 경로를 전환하는 복원력 중심이었다는 것이다. 이후 애플은 iOS 11에서 개발자 API를 열고 Maps·Music·Apple Pay 등으로 MPTCP 사용을 확대했다.
국내의 대표 사례는 KT의 GiGA LTE다. KT는 삼성전자와 공동 개발해 2015년 6월, 3밴드 CA LTE와 GiGA Wi-Fi를 MPTCP로 묶어 이론상 최대 1.17Gbps를 제공하는 세계 최초의 상용 서비스를 선보였다(시연에서는 최대 약 835Mbps, 평균 600~700Mbps 수준). KT의 IETF 발표 자료에 따르면 LTE를 주 서브플로우(MP_CAPABLE), Wi-Fi를 보조 서브플로우(MP_JOIN)로 두고, 단말과 통신사 망 사이에 MPTCP 프록시 게이트웨이를 배치해 서버가 MPTCP를 몰라도 본딩 효과를 내도록 했다. 이는 애플의 '전환' 사례와 달리 대역폭 집약(bonding)에 초점을 둔 것으로, 같은 MPTCP라도 적용 목적에 따라 설계가 어떻게 달라지는지 보여주는 좋은 대비다(다만 일부 2차 자료는 SOCKS 프록시 기반 설명을 하여, 세부 아키텍처는 자료별로 차이가 있다).
예상 출제 방향으로는 "MPTCP의 세 가지 설계 목표와 결합 혼잡제어의 필요성을 논하라", "MPTCP와 QUIC 멀티패스를 미들박스 호환성·마이그레이션 관점에서 비교하라", "모바일 핸드오버와 데이터센터 본딩 각각에 적합한 MPTCP 경로 관리자·스케줄러 정책을 제시하라" 등이 유력하다.
7. 고려사항 및 시사점
- 적용 전략(목적별 정책 분리): MPTCP는 "모든 경로를 항상 묶는" 획일적 적용보다, 모바일은 복원력(핸드오버) 중심·데이터센터는 처리량(본딩) 중심으로 경로 관리자와 스케줄러를 분리 설계해야 효과가 크다. 셀룰러 과금·배터리를 고려해 평시 Wi-Fi, 유사시 LTE로 전환하는 정책이 모바일에서 현실적이다.
- 트레이드오프(성능 ↔ 복잡도·버퍼): 경로를 늘린다고 선형으로 빨라지지 않는다. 경로 간 지연 편차가 크면 머리 막힘과 재조립 비용이 이득을 상쇄하므로, 수신 버퍼 사이징과 느린 경로 억제 튜닝이 선행돼야 한다. 이기종 경로에서는 오히려 서브플로우 수를 줄이는 편이 나을 수 있다.
- 미들박스·배치 가능성: 옵션을 제거·변형하는 방화벽·NAT 환경에서는 MPTCP가 일반 TCP로 폴백한다. 종단 서버가 MPTCP를 지원하지 않는 현실을 감안해, 통신사 망 내 MPTCP 프록시/컨버터를 두는 아키텍처가 상용 배치의 핵심 패턴이다.
- 보안 관점: MP_JOIN의 HMAC 인증으로 서브플로우 하이재킹을 막지만, ADD_ADDR 스푸핑·크로스패스 공격 등 다중경로 특유의 위협이 존재한다. 경로별 TLS 종단 암호화와 결합해 연결 레벨 무결성을 함께 확보해야 한다.
- 전망·연계 기술: 멀티패스의 설계 사상은 QUIC 멀티패스(Multipath QUIC)로 계승·확장되고 있으며, 5G·Wi-Fi 7 다중 연결, ATSSS(5G의 다중 접속 트래픽 조종), SD-WAN의 경로 본딩과도 긴밀히 연계된다. 암호화 전송이 표준이 되는 흐름 속에서 MPTCP와 QUIC 멀티패스의 역할 분담이 향후 핵심 쟁점이다.
참고자료
- IETF, "TCP Extensions for Multipath Operation with Multiple Addresses (RFC 8684)", https://datatracker.ietf.org/doc/html/rfc8684
- IETF, "Coupled Congestion Control for Multipath Transport Protocols (RFC 6356)", https://datatracker.ietf.org/doc/html/rfc6356
- Wikipedia, "Multipath TCP", https://en.wikipedia.org/wiki/Multipath_TCP
- multipath-tcp.org, "Configure MPTCP (Linux >= v5.6)", https://multipath-tcp.org/pmwiki.php/Users/ConfigureMPTCP
- KT/IETF, "GiGA LTE Mobile MPTCP Proxy Development (IETF 97 slides)", https://www.ietf.org/proceedings/97/slides/slides-97-banana-kt-giga-lte-mobile-mptcp-proxy-development-00.pdf
- Netmanias, "KT's GiGA LTE: World's First Commercial Wireless 1Gbps", https://netmanias.com/en/post/korea_ict_news/7591/kt-korea-lte-mptcp-wi-fi/kt-s-giga-lte-world-s-first-commercial-wireless-1-giga-3-band-ca-giga-wifi
한 줄 요약: MPTCP는 기존 TCP 옵션에 DSS 매핑·MP_CAPABLE/MP_JOIN을 얹어 여러 경로를 하나의 논리적 연결로 묶는 전송계층 확장으로, 처리량·복원력·혼잡분산을 결합 혼잡제어로 공정하게 달성하되 미들박스 폴백·머리 막힘·버퍼 비용의 한계를 프록시·스케줄러·버퍼 튜닝으로 보완하며, Siri(전환)·KT GiGA LTE(본딩) 사례와 QUIC 멀티패스로 이어진다.