▲

GN⁺: 리눅스용 Multipath TCP (2022년)

 (mptcp.dev)
1P by neo 3달전 | favorite | 댓글 1개

Multipath TCP 개요

  • Multipath TCP(MPTCP)는 표준 TCP의 확장판으로 RFC 8684에 기술되어 있음
  • 기기가 한번에 여러 인터페이스를 사용하여 단일 MPTCP 연결을 통해 TCP 패킷을 송수신할 수 있게 해줌
  • MPTCP는 여러 인터페이스의 대역폭을 집계하거나 지연시간이 가장 짧은 인터페이스를 선호할 수 있음
  • 또한 하나의 경로가 다운되더라도 페일오버가 가능하며, 트래픽이 다른 경로로 매끄럽게 재주입됨

MPTCP의 사용 사례

  • MPTCP를 사용하여 여러 경로를 병렬 또는 동시에 사용할 수 있게 되면서 TCP에 비해 새로운 사용 사례가 생김:
    • Seamless handovers: 연결을 유지하면서 한 경로에서 다른 경로로 전환. 애플은 2013년부터 이 이유로 스마트폰에서 주로 MPTCP 사용 중.
    • Best network selection: 지연, 손실, 비용, 대역폭 등 일부 조건에 따라 "최상의" 경로 사용.
    • Network aggregation: 더 높은 처리량을 위해 여러 경로를 동시에 사용. 예: 파일을 더 빨리 보내기 위해 고정 및 모바일 네트워크 결합.

MPTCP 개념

  • IPPROTO_MPTCP 프로토콜(리눅스 전용)로 새 소켓을 생성하면, 하나의 인터페이스를 통해 데이터를 전송하는 데 사용되는 일반 TCP 연결로 구성된 하위 흐름(또는 경로)이 생성됨
  • 추가 하위 흐름은 나중에 호스트 간에 협상될 수 있음
  • 원격 호스트가 MPTCP 사용을 감지할 수 있도록 기본 TCP 하위 흐름의 TCP 옵션 필드에 새 필드가 추가됨
  • 이 필드에는 다른 호스트에 MPTCP를 지원할 경우 사용하라고 알리는 MP_CAPABLE 옵션 등이 포함됨
  • 원격 호스트나 중간의 미들박스가 MPTCP를 지원하지 않으면 반환된 SYN+ACK 패킷의 TCP 옵션 필드에 MPTCP 옵션이 포함되지 않음
  • 이 경우 연결은 일반 TCP로 "다운그레이드"되고 단일 경로로 계속 진행됨

이러한 동작은 Path Manager와 Packet Scheduler라는 두 가지 내부 구성 요소로 인해 가능함.

Path Manager

  • Path Manager는 생성에서 삭제까지 하위 흐름을 담당하며 주소 알림도 담당함
  • 일반적으로 클라이언트 측에서 하위 흐름을 시작하고 서버 측에서 ADD_ADDR 및 REMOVE_ADDR 옵션을 통해 추가 주소를 알림
  • Linux v5.19 기준으로 net.mptcp.pm_type sysctl 노브로 제어되는 2개의 Path Manager가 있음:
    • in-kernel(유형 0): 모든 연결에 동일한 규칙 적용(ip mptcp 참조)
    • userspace(유형 1): 사용자 공간 데몬(예: mptcpd)에 의해 제어되며 각 연결에 대해 다른 규칙 적용 가능

Packet Scheduler

  • Packet Scheduler는 사용 가능한 하위 흐름 중 다음 데이터 패킷을 보내는 데 사용할 하위 흐름을 선택하는 역할을 함
  • 사용 가능한 대역폭 사용을 최대화하거나, 지연 시간이 가장 짧은 경로만 선택하거나, 구성에 따라 다른 정책을 결정할 수 있음
  • Linux v6.8 기준으로 net.mptcp의 sysctl 노브로 제어되는 단일 Packet Scheduler만 있음

MPTCP의 주요 특징 (Linux v6.10 기준)

  • socket() 시스템 호출에서 IPPROTO_MPTCP 프로토콜 지원
  • 피어 또는 미들박스가 MPTCP를 지원하지 않는 경우 MPTCP에서 TCP로 대체
  • 커널 내부 또는 사용자 공간 경로 관리자를 사용하는 경로 관리
  • TCP 소켓에서 일반적으로 사용되는 소켓 옵션
  • MIB 카운터, diag 지원(ss 명령에서 사용), 추적 포인트를 포함한 디버그 기능

GN⁺의 의견

  • MPTCP는 단말이 여러 네트워크에 연결된 경우 매우 유용한 기술임. 5G-Wi-Fi 핸드오버나 이종망 집성 등에 효과적으로 활용 가능함.
  • 하지만 MPTCP를 지원하는 서버와 클라이언트 양쪽에 구현이 되어야 하고, 중간 네트워크에서 MPTCP를 지원해야 한다는 제약이 있음. 보편화되기까지 시간이 걸릴 것으로 보임.
  • 구글의 QUIC 프로토콜도 유사한 멀티패스 기능을 제공하는데, QUIC이 더 간단하고 UDP 기반이라 더 빠르게 확산될 것으로 전망됨. MPTCP와 QUIC의 경쟁이 예상됨.
  • 커널에 종속적인 리눅스용 MPTCP 구현과 달리, 애플은 자체적으로 사용자영역에서 MPTCP를 구현하여 iOS와 맥OS에 탑재하고 있음. 구글도 비슷한 접근을 할 가능성이 있어 보임.
  • MPTCP의 경로제어나 스케줄링 정책이 애플리케이션 요구사항에 최적화되려면, 애플리케이션과 MPTCP간 API를 통한 정보 교환이 필요해 보임. 이에 대한 표준화된 방안은 아직 없는 것으로 파악됨.
▲
neo 3달전  [-]
Hacker News 의견
  • MPTCP에 대해 2013년에 처음 들었을 때 모바일 앱의 네트워크 변경에 대한 대응력이 약했기 때문에 사용자 경험 개선에 큰 도움이 될 것이라 생각했으나, 10년이 지나도록 거의 주목받지 못한 것이 매우 실망스러움
  • IPv4의 32비트 주소 공간과 TCP가 연결 튜플에 출발지/목적지 IP 주소를 사용하는 것 중 어느 것이 더 슬픈지 모르겠음. 타임머신이 있다면 과거로 돌아가 이 두 가지를 바꾸고 싶음
  • MPTCP의 실용적 사용은 모바일과 Wi-Fi 네트워크를 함께 사용해 속도를 높이는 것이나, 모바일 데이터 요금제 때문에 개인적으로는 항상 끄고 있어 쓸모없음
  • OpenWrt 파생 프로젝트 등 MPTCP를 사용하는 프로젝트 링크가 없는 것이 아쉬움. 2년간 GSOC에서 OpenWrt에 MPTCP 지원을 패치하는 학생을 멘토링함
  • 투명한 폴백이 있다면 애플리케이션의 명시적 옵트인이 왜 필요한지 의문. 커널이 모든 TCP 연결에 대해 투명하게 처리하여 경로 집계/링크 선호도에 대한 전역적 결정을 내리는 것이 가장 합리적일 것 같음
  • 리눅스 네트워크 스택과 드라이버를 지원/디버깅/수정하는 일을 하면서 MPTCP의 낮은 채택률에 놀라움. SCTP처럼 기존 TCP를 대체하려 했던 모든 것들이 소수의 개발자들에게만 사용되고 나머지 세계는 잊혀지는 운명인 듯함
  • MPTCP와 QUIC의 아키텍처 차이, 그리고 저자들이 제안한 MPQUIC 프로토콜을 설명하는 논문을 찾음. QUIC은 단일 UDP 흐름에 애플리케이션 스트림을 다중화하고, MPTCP는 단일 스트림을 여러 TCP 하위 흐름으로 분할함. MPQUIC은 여러 UDP 하위 흐름에 애플리케이션 스트림을 다중화하여 두 기능을 결합함
  • Apple도 MPTCP를 지원하며 Siri에 사용 중
  • 중간의 미들박스가 MPTCP 옵션을 지원하지 않으면 SYN+ACK 패킷에 MPTCP 옵션이 포함되지 않는다는 점이 꽤 제한적으로 보임. 미들박스의 유일한 요구사항은 MPTCP 옵션을 그대로 전달하는 것인가?
  • MPTCP는 보안/프라이버시 설정에 도움이 될 수 있음. 예를 들어 여러 업링크 채널에 트래픽을 분할하면 중국 정부 방화벽이 차단을 위해 트래픽을 결합하기 어려워짐
답변달기