리눅스용 Multipath TCP (2022년)

 (mptcp.dev)
1P by GN⁺ | ★ favorite | 댓글 1개
  • MPTCP는 RFC 8684 기반의 TCP 확장으로, 하나의 연결이 여러 네트워크 인터페이스를 동시에 써서 대역폭·지연·장애 대응을 개선함
  • 여러 경로를 병렬로 쓰는 구조라 대역폭 집계, 낮은 지연 경로 선호, 경로 장애 시 다른 경로로의 재주입이 가능함
  • Linux에서는 IPPROTO_MPTCP로 소켓을 만들고 일반 TCP 연결인 subflow를 구성하며, 상대나 중간 장비가 지원하지 않으면 단일 경로 TCP로 자동 하향 전환됨
  • 경로 관리는 Linux v5.19 기준 커널 내장 방식과 mptcpd 같은 사용자 공간 데몬 방식이 있고, Linux v6.8 기준 패킷 스케줄러는 net.mptcp sysctl로 제어되는 하나만 있음
  • Linux v6.10 기준 기능은 socket() 지원, TCP 하향 전환, 커널/사용자 공간 경로 관리, TCP 소켓 옵션, MIB·ss 진단·tracepoint 디버그 기능까지 포함함

MPTCP가 바꾸는 TCP 연결 방식

  • Multipath TCP(MPTCP) 는 표준 TCP의 확장으로, RFC 8684에 정의됨
  • 하나의 MPTCP 연결은 여러 인터페이스를 동시에 사용해 TCP 패킷을 보내고 받을 수 있음
  • 여러 인터페이스의 대역폭을 집계하거나 지연 시간이 가장 낮은 인터페이스를 우선할 수 있음
  • 한 경로가 끊기면 트래픽을 다른 경로로 매끄럽게 재주입해 장애 전환을 수행함
  • 일반 TCP가 한 번에 하나의 경로를 쓰는 것과 달리, MPTCP는 5G와 Wi‑Fi 같은 여러 경로를 subflow로 함께 사용할 수 있음

대표 사용 사례

  • 끊김 없는 핸드오버

    • 기존 연결을 유지한 채 한 경로에서 다른 경로로 전환할 수 있음
    • Apple은 2013년부터 스마트폰에서 주로 이 이유로 Multipath TCP를 사용함

  • 최적 네트워크 선택

    • 지연 시간, 손실, 비용, 대역폭 같은 조건에 따라 사용 가능한 경로 중 “가장 좋은” 경로를 고름

  • 네트워크 집계

    • 여러 경로를 동시에 사용해 처리량을 높일 수 있음
    • 고정망과 모바일 네트워크를 결합해 파일을 더 빠르게 전송하는 방식이 예시임

Linux에서 연결이 성립되는 방식

  • Linux 전용 IPPROTO_MPTCP 프로토콜로 새 소켓을 만들면 subflow 또는 path가 생성됨
  • subflow는 하나의 인터페이스를 통해 데이터를 전송하는 일반 TCP 연결임
  • 이후 호스트 간 협상을 거쳐 추가 subflow를 만들 수 있음
  • 기반 TCP subflow의 TCP option 필드에는 상대 호스트가 MPTCP 사용을 감지할 수 있도록 새 필드가 추가됨
    • 이 필드에는 상대에게 MPTCP 사용을 알리는 MP_CAPABLE 옵션 등이 들어감
  • 상대 호스트나 중간의 middlebox가 MPTCP를 지원하지 않으면 반환되는 SYN+ACK 패킷의 TCP option 필드에 MPTCP 옵션이 없음
    • 이 경우 연결은 일반 TCP로 하향 전환되어 단일 경로로 계속됨

경로 관리자와 패킷 스케줄러

  • MPTCP는 내부적으로 Path Manager와 Packet Scheduler가 subflow 생성, 주소 공지, 전송 경로 선택을 나눠 처리함

  • Path Manager

    • Path Manager는 subflow의 생성부터 삭제까지 관리하고 주소 공지도 담당함
    • 일반적으로 클라이언트 측이 subflow를 시작하고, 서버 측은 ADD_ADDR와 REMOVE_ADDR 옵션으로 추가 주소를 공지함
    • Linux v5.19 기준 net.mptcp.pm_type sysctl knob으로 두 가지 path manager를 제어함
      • type 0: 커널 내장 방식이며 모든 연결에 같은 규칙을 적용함. ip mptcp와 관련됨
      • type 1: 사용자 공간 방식이며 mptcpd 같은 데몬이 제어하고 연결별로 다른 규칙을 적용할 수 있음

  • Packet Scheduler

    • Packet Scheduler는 다음 데이터 패킷을 보낼 때 사용할 subflow를 선택함
    • 사용 가능한 대역폭을 최대화하거나, 지연 시간이 더 낮은 경로만 고르거나, 설정에 따른 다른 정책을 적용할 수 있음
    • Linux v6.8 기준 패킷 스케줄러는 하나만 있으며, net.mptcp의 sysctl knob으로 제어됨

Linux v6.10 기준 기능

  • Linux v6.10 기준 MPTCP는 다음 기능을 제공함
    • socket() 시스템 호출에서 IPPROTO_MPTCP 프로토콜 지원
    • 상대나 middlebox가 MPTCP를 지원하지 않을 때 MPTCP에서 TCP로 하향 전환
    • 커널 내장 또는 사용자 공간 path manager를 사용하는 경로 관리
    • TCP 소켓에서 일반적으로 쓰이는 소켓 옵션
    • MIB 카운터, ss 명령이 사용하는 diag 지원, tracepoint를 포함한 디버그 기능
  • 자세한 변경 사항은 ChangeLog에서 확인할 수 있음

커뮤니케이션과 관련 프로젝트

커널 개발 리소스

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • MPTCP는 2013년에 이미 들어봤음
    당시 모바일 앱이 네트워크 변경에 그다지 강하지 않았던 걸 생각하면 UX 개선 폭이 커서 금방 채택될 줄 알았음
    그런데 지난 10년 동안 거의 traction을 못 얻었고, 이제야 커널 옵션이 나타나는 게 꽤 우울함. 그사이 다들 HTTP 호출을 여러 재시도 처리기로 감쌌고, 모바일 운영체제는 네트워크 연결성을 너무 추상화해서 TCP라기보다 zeromq를 쓰는 느낌에 가까워짐

    • 많은 혁신 에너지가 QUIC으로 옮겨간 듯함. TCP에서는 새 변형을 잘 만들어도 중간 장비가 임의로 망가뜨릴 수 있기 때문임
      예시는 https://blog.apnic.net/2021/12/08/efficient-multipath-transp... 참고
    • 좋아하고 싶었고 Apple도 iOS에 넣었지만, 실제 서버에서 지원하기가 너무 어려웠음
      FreeBSD에 로드 밸런서 없이 배포했을 때는 최신 패치가 없었고, 설령 있었더라도 사설망 IP를 대체 경로로 광고하지 않게 하려면 상당한 작업이 필요했음
      Linux에서 로드 밸런서 뒤에 있을 때는 스트림을 올바른 곳으로 보내는 게 너무 복잡했고, 로드 밸런서도 그걸 하려고 하지 않았음
      두 스트림을 함께 처리하는 건 고처리량 경로에 큰 복잡도를 넣는 일이라 위험이 크고, 변경하려면 재부팅도 필요함
      그렇게 다 해도 이득은 주로 iOS 사용자에게만 가는데, 그 사용자들은 애초에 더 나은 네트워크를 쓰는 편임
    • 2000년에 나온 SCTP도 관심 가질 만함. 이것도 아직까지 거의 채택되지 못했음
      https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...
    • 배송 로봇을 만들 때 셀룰러 모뎀 2개로 즉시 장애 전환을 하고 싶어서 MPTCP에 기대했음
      결국 개발 시간을 아끼려고 PepLink의 SpeedFusion을 썼지만 라이선스 비용이 비쌌음. 앞으로 2개의 셀룰러 네트워크와 50ms 미만 장애 전환을 위한 무료 해법이 나오길 바람
      다중 경로 UDP + OpenVPN도 아마 실용적인 해법이 될 수 있음
    • 오히려 이게 받을 만하지 않은 관심을 얻는 게 우울함. TCP는 현대 환경에서 절반 정도의 사용 사례에만 대충 맞는 해킹을 하나씩 더하고 조합을 고르게 할 게 아니라, SCTP로 대체되어야 함

  • IPv4 주소 공간이 32비트뿐인 것과 TCP가 연결 튜플에 출발지/목적지 IP 주소를 쓰는 것 중 뭐가 더 슬픈지 모르겠음
    타임머신이 있다면 Cerf와 Kahn에게 돌아가서 둘 다 바꾸게 하고 싶음

    • TCP를 어떻게 바꾸겠다는 뜻인지 궁금함
      양쪽의 IP 주소와 포트, 즉 4개 필드로 연결을 추적해야 하는 구조를 말하는 건가?
    • 그들은 이미 소스 라우팅을 줬고, 그게 원하는 것의 절반이며 옵션으로 올바르게 명세되어 있다고 말할 것 같음

  • MPTCP를 쓰는 프로젝트, 예를 들면 OpenWrt 파생 프로젝트 링크가 없는 게 아쉬움
    GSOC에서 2년 동안 학생을 멘토링하며 OpenWrt에 MPTCP를 패치한 적이 있음
    https://blog.freifunk.net/2017/05/29/gsoc-2017-add-mptcp-sup...

  • 투명한 대체 경로가 있다면 왜 애플리케이션의 명시적 선택이 필요한지 모르겠음
    커널이 모든 TCP 연결에 대해 투명하게 처리해야 경로 집계나 링크 선호도 같은 전역 판단을 더 잘할 수 있지 않나 싶음

    • Linux TCP/네트워킹 하위 시스템 유지관리자들이 사실상 강제한 조건으로 이해하고 있음. 초기 업스트림 논의[1]를 보면 이게 기본 규칙으로 잡혀 있었음
      업스트림 전의 오래된 다중 경로 TCP 구현은 애플리케이션에 완전히 투명하도록 의도됐고, 프로토콜의 목적에는 그쪽이 더 맞다고 봄
      물론 많은 경우 MPTCP가 애플리케이션 지침을 받으면 더 나을 수 있지만, 예를 들어 LTE 연결에 하위 흐름을 만들어 자동 장애 전환은 준비하되 그 하위 흐름으로 데이터는 보내지 않는 표준 시스템 접근만 있어도 95%의 경우에는 충분했을 것임
      [1] https://lore.kernel.org/all/alpine.OSX.2.21.1707181728570.11...
    • 이걸 쓴다는 건 하나의 TCP 연결에 대해 양 끝점마다 여러 IP가 연결될 수 있다는 뜻임. 많은 경우 애플리케이션의 명시적 지원이나 인지가 필요해짐
    • 여러 IP가 같은 TCP 연결 위에서 통신하도록 허용하면 새로운 보안 구멍이 생길 수 있음
      예를 들어 연결 시점에 클라이언트 IP를 화이트리스트와 대조하고 이후에는 바뀌지 않는다고 가정하는 애플리케이션을 생각해볼 수 있음

  • 내게 MPTCP의 유일한 실용적 용도는 모바일 네트워크와 Wi-Fi를 함께 써서 속도를 올리는 것임. iOS와 WeChat 모두 이를 지원함
    하지만 모바일 네트워크는 종량제라 항상 꺼둠. 그래서 개인적으로는 MPTCP가 쓸모없음

    • 이 문제를 다뤄봤음. 내부적으로 주차장 버그라고 불렀음
      Wi-Fi 신호는 여전히 보이지만 제대로 연결은 안 되는 상황임. MPTCP가 있으면 셀룰러로 장애 전환됨

  • Linux 네트워크 스택과 드라이버를 지원·디버깅·수정하는 일을 하는데, 이게 이렇게 적게 채택된 게 놀라움
    SCTP처럼 일반 TCP를 대체하려 했던 것들과 마찬가지로, MPTCP도 일부 애플리케이션 개발자들이 계속 쓰는 틈새 기술에 머물고 나머지 세상은 잊어버리는 듯함

    • Apple Siri가 MPTCP를 쓰므로 기기 수를 생각하면 딱히 틈새라고만 보긴 어려움

  • MPTCP와 QUIC의 구조적 차이를 설명하고 저자들이 제안한 MPQUIC 프로토콜도 소개하는 자료를 찾았음
    QUIC은 하나의 UDP 흐름 위에 애플리케이션 스트림을 다중화하고, MPTCP는 하나의 스트림을 여러 TCP 하위 흐름으로 나눔. MPQUIC은 두 특징을 결합해 여러 UDP 하위 흐름 위에 애플리케이션 스트림을 다중화함
    [1]: "Multipath QUIC: A Deployable Multipath Transport Protocol" https://www.researchgate.net/publication/327122884_Multipath...
    이제 운영 환경에서 이 프로토콜들이 어떻게 비교되는지 궁금함. 둘 다 써본 사람이 있나?

    • MPQUIC은 아직 IETF에서 논의 중임. 지난 IETF 회의에서도 더 많은 변경이 논의됐고, 안타깝게도 그래서 채택이 느려지고 있음
      https://lwn.net/Articles/964377/
      둘 다 같은 목표를 달성하려고 함. 기술적으로는 매우 비슷한 동작을 만들 수 있음. MPTCP는 Linux 커널에 구현되어 있고, QUIC은 사용자 공간 쪽에 있음

  • Apple도 지원하고 Siri에 사용함
    https://developer.apple.com/documentation/foundation/urlsess...

    • 다른 앱에서도 꽤 쉽게 쓸 수 있음. 기본 기능에 들어 있음
      2011년에 우리 VoIP 앱이 꽤 튼튼하게 동작하는 걸 보고 놀랐음 :D

  • 중간 장비 중 하나라도 지원하지 않으면 반환되는 SYN+ACK 패킷의 TCP 옵션 필드에 MPTCP 옵션이 없다는 건 꽤 제한적으로 들림
    중간 장비의 유일한 요구사항은 MPTCP 옵션을 그대로 전달하는 것뿐인가?

  • 보안·프라이버시 설정에서 도움이 될 수 있음
    예를 들어 중국의 Great Firewall을 생각하면, 트래픽을 여러 업링크 채널로 나눌 수 있을 때 방화벽이 이를 다시 조립해 집행하기 어려워지지 않을까?

    • 모르는 트래픽이면 그냥 차단하거나 심하게 속도 제한을 걸면 됨
답변달기