요약

  • 멀티패스 TCP(Multipath TCP)는 애플리케이션에 하나의 신뢰성 있고 순서화된 바이트 스트림을 제공하면서, 엔드포인트는 이를 하나 이상의 일반 TCP 서브플로로 운반할 수 있습니다.
  • MP_CAPABLE이 연결을 협상하고,MP_JOIN이 추가 서브플로를 인증하며, 연결 수준 시퀀스 번호 덕분에 장애 발생 후 데이터를 다른 경로로 재전송할 수 있습니다.
  • 인터페이스가 둘이라는 것만으로 복원력의 증거가 되지는 않습니다. 경로가 병목을 공유할 수 있고, 중간 장비가 필요한 옵션을 제거할 수 있으며, 엔드포인트 정책이 두 번째 서브플로를 활성·백업·부재 중 어느 상태로 둘지를 결정합니다.

정문 앞의 하나의 소켓

겉으로 드러나는 사건은 평범합니다. 업로드, 호출 제어 교환 또는 긴 응답이 진행 중인 상태에서 기기가 Wi-Fi 커버리지 밖으로 나갑니다. IP 계층에서는 한 주소가 사라지고 다른 주소가 사용 가능해질 수 있습니다. 그러나 애플리케이션 계층에서 유용한 대상은 주소가 아니라 이미 상대와 교환된 순서화된 바이트 스트림입니다.

RFC 8684는 이 둘을 분리합니다. MPTCP 연결은 애플리케이션 소켓과 일대일로 대응하지만 여러 서브플로를 포함할 수 있습니다. 각 서브플로는 한 경로에서 일반 TCP 흐름처럼 보이고, 일반 TCP와 거의 같은 방식으로 시작·종료될 수 있습니다. 연결은 이들 위에 놓여 애플리케이션이 기대하는 서비스를 유지합니다. 따라서 어떤 경로가 더 이상 유용하지 않게 되더라도 그것이 곧 연결의 끝을 정의하지는 않습니다.

이 자격 조건이 중요합니다. MPTCP는 선언만으로 연결을 살아 있게 유지하지 않습니다. 양쪽 엔드포인트가 이를 협상해야 하고, 사용 가능한 서브플로가 최소 하나 남아 있거나 새로 수립되어야 하며, 연결 상태도 그대로 유지되어야 합니다. 프로토콜은 연속성을 위한 기제를 만들 뿐, 그 기제가 작동할 네트워크 조건을 보증하지는 않습니다.

허용 여부는 엔드포인트에 있다

첫 서브플로는MP_CAPABLE교환을 운반합니다. 이는 각 측에 상대가 MPTCP를 지원한다는 사실을 알리고, 연결에 사용될 키 재료를 교환합니다. 어느 한 호스트가 지원하지 않거나 중간 장비가 옵션의 생존을 막으면, 설계상 일반 TCP로 폴백할 수 있습니다.

추가 경로는 다른 주소가 존재한다는 이유만으로 단순히 붙는 것이 아닙니다. 새 TCP 핸드셰이크는MP_JOIN을 실어 나릅니다. 연결 토큰이 가입 대상 연결을 식별하고, 논스와 원래 키에서 파생된 HMAC이 각 엔드포인트가 가입하는 서브플로가 동일한 피어에 속함을 검증하게 합니다. 그럼에도 로컬 정책이 이를 금지할 수 있습니다. 이는 자동 경로 탐색이 아니라 허용 결정입니다.

주소는 연결 수명 중에도 바뀔 수 있습니다.ADD_ADDR은 한 엔드포인트가 다른 주소를 광고하게 하고,REMOVE_ADDR은 이를 철회합니다. 주소 식별자는 NAT가 주소를 재기록하더라도 시그널링이 살아남도록 돕습니다. 그러나 광고된 주소는 엔드포인트가 후보를 제안했다는 사실만을 말합니다. 그 결과 만들어지는 경로가 도달 가능하고, 독립적이며, 저렴하고, 더 나은지를 증명하지는 않습니다.

이것이 첫 번째 운영 경계입니다. 네트워크 운영자는 도달 가능성을 제공하고 물리적 경로에 영향을 줄 수 있습니다. 엔드포인트는 MPTCP가 협상되었는지, 어떤 후보가 서브플로가 되는지, 서브플로가 허용되는지를 결정합니다. MPTCP를 모르는 애플리케이션은 평범한 소켓만 볼 수 있으므로, 가장 중요한 경로 선택이 자신의 인터페이스 아래에서 일어날 수 있습니다.

여러 TCP 흐름 위의 하나의 장부

각 서브플로는 일반 TCP 시퀀스 번호를 유지합니다. 그래야 서브플로가 자기 경로에서 TCP처럼 동작할 수 있습니다. MPTCP는 여기에 두 번째 장부를 더합니다: 연결 전체를 위한 64비트 데이터 시퀀스 번호(Data Sequence Number)입니다. 데이터 시퀀스 신호는 서브플로의 시퀀스 공간에 있는 바이트를 그 연결 수준 공간으로 사상하고, 연결 수준에서 진행 상황을 확인(ACK)할 수 있습니다.

이 추가 장부가 복원력의 뒤에 있는 기제입니다. 한 서브플로에서 보낸 데이터가 전달되지 않으면, 같은 연결 수준 바이트를 새 사상과 함께 다른 서브플로로 재전송할 수 있습니다. 수신 애플리케이션은 여전히 하나의 신뢰성 있고 순서화된 스트림을 받습니다. 두 개의 독립적인 TCP 연결을 조정하거나 어느 사본이 다음 차례인지 판단할 필요가 없습니다.

동시에 이것이 덧씌우기 어려운 진실의 근원이기도 합니다. 애플리케이션은 여전히 순서화된 바이트를 기다리므로, 빠른 경로가 정상 작동 중이어도 느린 경로가 유용한 전달을 지연시킬 수 있습니다. 패킷 스케줄링, 재주입, 혼잡 제어가 여러 경로가 경험을 개선하는지 아니면 지연과 상태만 추가하는지를 결정합니다. RFC 8041은 이것이 인터페이스 수 세기로 풀리는 세부 사항이 아니라 운영 문제임을 기록하고 있습니다.

두 번째 링크는 활성일 수도, 백업일 수도, 무용지물일 수도 있다

RFC 8684는 호스트가 서브플로를 일반(regular) 또는 백업(backup)으로 표시하게 하며,MP_PRIO로 연결 중 우선순위 변경을 요청할 수 있습니다. 작아 보이는 이 플래그는 멀티패스 전송 안의 상업적 결정을 드러냅니다. 셀룰러 경로는 복원력이 있지만 종량제일 수 있고, 위성 경로는 도달 가능하지만 느릴 수 있으며, 두 번째 고정 접속은 같은 통관이나 상류 병목을 공유하면서도 이질적으로 보일 수 있습니다.

RFC 6182는 주소 조합이 반드시 분리된 경로를 만들지는 않는다고 명시합니다. 그 아키텍처의 목표는 최고 구성 경로보다 못한 처리량, 일반 TCP보다 못한 복원력을 피하면서, 공유 병목에서 다른 사용자에게 불공정한 압박을 주지 않는 것입니다. 이는 설계 목표이며, 특정 배포에 대한 측정 보고서가 아닙니다.

따라서 올바른 증거 단위는 “사용 가능한 인터페이스”가 아니라, 협상된 연결과 그 관찰된 서브플로입니다. 어느 것이 수립되었는지, 어느 것이 백업으로 지정되었는지, 서로 다른 장애 도메인을 통과했는지, 연결 수준 전달이 어떻게 동작했는지, 데이터를 다른 곳에서 다시 보내야 했는지입니다. 그 증거 없이는 멀티패스 배지가 잠재력을 서비스처럼 묘사할 수 있습니다.

폴백도 결과의 일부다

중간 장비는 MPTCP 설계를 형성했습니다. 경로상의 장비는 TCP 옵션을 제거하거나, 주소·포트를 재기록하거나, 페이로드를 멀티패스 시그널링을 무효화하는 방식으로 변경할 수 있습니다. RFC 8684는 안전한 반응을 정의합니다. 초기 연결은 일반 TCP로 폴백할 수 있고, 결함 있는 추가 서브플로는 리셋·제거될 수 있으며, 운영 중 유효한 사상을 잃은 서브플로는 손상된 것으로 다루어야 합니다.

따라서 폴백은 단순히 설치 실패가 아닙니다. 협상 가능한 결과 중 하나입니다. 일반 TCP가 여전히 작동하므로 서비스가 건강해 보일 수 있지만, 설계를 정당화했던 이중화는 사라져 있는 것입니다. 애플리케이션 성공만 기록하는 모니터링은 “연결이 다른 서브플로로 살아남았다”와 “MPTCP가 여기서 한 번도 작동하지 않았다”의 차이를 놓칩니다.

멀티패스 TCP는 연결의 경계를 하나의 경로 위로 옮기지만, 경로를 폐지하지는 않습니다. 엔드포인트에 경로를 모으고, 추가를 인증하고, 하나의 바이트 스트림을 장애를 넘어 보존하는 방법을 줍니다. 지속되는 질문은 누가 엔드포인트 정책을 통제하며 그 아래 경로가 진정으로 다른지입니다. 연속성은 화면의 무선 아이콘 수가 아니라 그 결정들에서 얻어집니다.

출처