Linux için Multipath TCP (2022)

 (mptcp.dev)
1 puan yazan GN⁺ 2024-04-21 | 1 yorum | WhatsApp'ta paylaş
  • MPTCP, RFC 8684 tabanlı bir TCP uzantısıdır; tek bir bağlantının aynı anda birden fazla ağ arayüzü kullanarak bant genişliği, gecikme ve arıza dayanıklılığını iyileştirmesini sağlar
  • Birden fazla yolu paralel kullanan bir yapı olduğu için bant genişliği birleştirme, düşük gecikmeli yolu tercih etme ve yol arızasında başka bir yola yeniden enjeksiyon mümkündür
  • Linux'ta IPPROTO_MPTCP ile soket oluşturulur ve normal TCP bağlantısı olan subflow'lar yapılandırılır; karşı uç veya ara cihazlar desteklemiyorsa otomatik olarak tek yollu TCP'ye geri düşer
  • Yol yönetimi için Linux v5.19 itibarıyla çekirdek içi yöntem ve mptcpd gibi kullanıcı alanı daemon yöntemi vardır; Linux v6.8 itibarıyla paket zamanlayıcısı ise net.mptcp sysctl ile kontrol edilen tek bir yapıdadır
  • Linux v6.10 itibarıyla özellikler arasında socket() desteği, TCP'ye geri düşme, çekirdek/kullanıcı alanı yol yönetimi, TCP soket seçenekleri, MIB, ss tanılama ve tracepoint hata ayıklama özellikleri bulunur

MPTCP'nin TCP bağlantı modelini nasıl değiştirdiği

  • Multipath TCP (MPTCP), standart TCP'nin bir uzantısıdır ve RFC 8684 içinde tanımlanmıştır
  • Tek bir MPTCP bağlantısı, TCP paketlerini göndermek ve almak için aynı anda birden fazla arayüz kullanabilir
  • Birden fazla arayüzün bant genişliğini birleştirebilir veya gecikmesi en düşük arayüze öncelik verebilir
  • Bir yol kesildiğinde trafiği başka bir yola sorunsuz şekilde yeniden enjekte ederek failover gerçekleştirir
  • Normal TCP'nin aynı anda yalnızca tek bir yol kullanmasının aksine, MPTCP 5G ve Wi‑Fi gibi birden fazla yolu subflow olarak birlikte kullanabilir

Başlıca kullanım senaryoları

  • Kesintisiz handover

    • Mevcut bağlantıyı koruyarak bir yoldan diğerine geçiş yapılabilir
    • Apple, 2013'ten beri akıllı telefonlarda ağırlıklı olarak bu nedenle Multipath TCP kullanıyor

  • En iyi ağın seçimi

    • Gecikme, kayıp, maliyet ve bant genişliği gibi koşullara göre kullanılabilir yollar arasından “en iyi” olanı seçer

  • Ağ birleştirme

    • Birden fazla yol aynı anda kullanılarak aktarım hızı artırılabilir
    • Sabit hat ile mobil ağı birleştirip dosyaları daha hızlı aktarmak buna örnektir

Linux'ta bağlantının kurulma biçimi

  • Linux'a özel IPPROTO_MPTCP protokolüyle yeni bir soket oluşturulduğunda subflow veya path oluşturulur
  • Subflow, tek bir arayüz üzerinden veri taşıyan normal bir TCP bağlantısıdır
  • Ardından ana makineler arasındaki müzakereyle ek subflow'lar oluşturulabilir
  • Altta yatan TCP subflow'un TCP option alanına, karşı ana makinenin MPTCP kullanımını algılayabilmesi için yeni alanlar eklenir
    • Bu alanlar arasında karşı tarafa MPTCP kullanımını bildiren MP_CAPABLE seçeneği de bulunur
  • Karşı ana makine veya aradaki middlebox MPTCP'yi desteklemiyorsa, dönen SYN+ACK paketinin TCP option alanında MPTCP seçeneği yer almaz
    • Bu durumda bağlantı normal TCP'ye geri düşer ve tek yol üzerinden devam eder

Path manager ve packet scheduler

  • MPTCP içinde Path Manager ve Packet Scheduler, subflow oluşturma, adres duyurusu ve aktarım yolu seçimini ayrı ayrı yönetir

  • Path Manager

    • Path Manager, subflow'ların oluşturulmasından silinmesine kadar olan süreci yönetir ve adres duyurusunu da üstlenir
    • Genelde istemci tarafı subflow başlatır, sunucu tarafı ise ADD_ADDR ve REMOVE_ADDR seçenekleriyle ek adresleri duyurur
    • Linux v5.19 itibarıyla iki path manager, net.mptcp.pm_type sysctl knob ile kontrol edilir
      • type 0: Çekirdek içi yöntemdir ve tüm bağlantılara aynı kuralları uygular. ip mptcp ile ilişkilidir
      • type 1: Kullanıcı alanı yöntemidir; mptcpd gibi daemon'lar tarafından kontrol edilir ve bağlantı bazında farklı kurallar uygulanabilir

  • Packet Scheduler

    • Packet Scheduler, bir sonraki veri paketinin hangi subflow üzerinden gönderileceğini seçer
    • Kullanılabilir bant genişliğini en üst düzeye çıkarabilir, yalnızca daha düşük gecikmeli yolları seçebilir veya yapılandırmaya göre başka politikalar uygulayabilir
    • Linux v6.8 itibarıyla yalnızca bir paket zamanlayıcısı vardır ve net.mptcp altındaki sysctl knob ile kontrol edilir

Linux v6.10 itibarıyla özellikler

  • Linux v6.10 itibarıyla MPTCP şu özellikleri sunar
    • socket() sistem çağrısında IPPROTO_MPTCP protokol desteği
    • Karşı uç veya middlebox MPTCP'yi desteklemediğinde MPTCP'den TCP'ye geri düşme
    • Çekirdek içi veya kullanıcı alanı path manager kullanan yol yönetimi
    • TCP soketlerinde yaygın olarak kullanılan soket seçenekleri
    • MIB sayaçları, ss komutunun kullandığı diag desteği ve tracepoint içeren hata ayıklama özellikleri
  • Ayrıntılı değişiklikler ChangeLog üzerinden görülebilir

İletişim ve ilgili projeler

Çekirdek geliştirme kaynakları

İlgili okumalar

1 yorum

 
GN⁺ 2024-04-21
Hacker News yorumları

  • MPTCP’yi 2013’te zaten duymuştum
    O dönemde mobil uygulamaların ağ değişikliklerine pek dayanıklı olmadığını düşününce, UX’te büyük bir iyileşme sağlayıp hızla benimseneceğini sanmıştım
    Ama son 10 yılda neredeyse hiç traction kazanamadı; kernel seçeneğinin ancak şimdi ortaya çıkması epey moral bozucu. Bu arada herkes HTTP çağrılarını birden fazla yeniden deneme işleyicisiyle sardı, mobil işletim sistemleri de ağ bağlantısını o kadar soyutladı ki TCP’den çok zeromq kullanıyormuş hissine yaklaştı

    • Yenilik enerjisinin büyük kısmı QUIC’e kaymış gibi görünüyor. Çünkü TCP’de yeni bir varyantı iyi yapsanız bile ara cihazlar onu keyfi biçimde bozabiliyor
      Örnek için bkz. https://blog.apnic.net/2021/12/08/efficient-multipath-transp...
    • Sevmek istemiştim, Apple da iOS’a koydu, ama gerçek sunucularda desteklemek çok zordu
      FreeBSD’ye yük dengeleyici olmadan dağıttığımda güncel yamalar yoktu; olsa bile özel ağ IP’sinin alternatif rota olarak duyurulmasını engellemek ciddi iş gerektirirdi
      Linux’ta yük dengeleyici arkasındayken stream’i doğru yere göndermek çok karmaşıktı, yük dengeleyici de bunu yapmaya çalışmıyordu
      İki stream’i birlikte işlemek yüksek işlem hacimli yola büyük karmaşıklık eklemek demek, bu yüzden riski yüksek; değiştirmek için yeniden başlatma da gerekiyor
      Tüm bunları yapsanız bile fayda çoğunlukla yalnızca iOS kullanıcılarına gidiyor; onlar da zaten daha iyi ağlar kullanma eğiliminde
    • 2000’de çıkan SCTP de ilgilenmeye değer. O da bugüne kadar neredeyse hiç benimsenemedi
      https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...
    • Teslimat robotu yaparken 2 hücresel modem ile anında failover yapmak istediğim için MPTCP’den umutluydum
      Sonunda geliştirme zamanından tasarruf etmek için PepLink’in SpeedFusion’ını kullandık, ama lisans maliyeti pahalıydı. Gelecekte 2 hücresel ağ ve 50 ms altı failover için ücretsiz bir çözüm çıkmasını umuyorum
      Çok yollu UDP + OpenVPN de muhtemelen pratik bir çözüm olabilir
    • Asıl bunun hak etmediği ilgiyi görmesi moral bozucu. TCP’ye modern ortamda kullanım senaryolarının ancak yarısına kabaca uyan hack’leri tek tek ekleyip kombinasyon seçtirmek yerine, TCP’nin SCTP ile değiştirilmesi gerekiyor

  • IPv4 adres alanının yalnızca 32 bit olması mı, yoksa TCP’nin bağlantı tuple’ında kaynak/hedef IP adreslerini kullanması mı daha üzücü, bilmiyorum
    Zaman makinem olsa Cerf ve Kahn’a geri dönüp ikisini de değiştirtmek isterdim

    • TCP’yi nasıl değiştirmek istediğini merak ediyorum
      İki tarafın IP adresleri ve portları, yani 4 alanla bağlantı izlemek zorunda olan yapıyı mı kastediyorsun?
    • Muhtemelen zaten source routing verdiklerini, bunun istediğinin yarısı olduğunu ve seçenek olarak doğru biçimde belirtildiğini söylerlerdi

  • MPTCP kullanan projelere, örneğin OpenWrt türevi bir projeye link olmaması üzücü
    GSOC’ta 2 yıl boyunca öğrencilere mentorluk edip OpenWrt’ye MPTCP yaması eklemiştim
    https://blog.freifunk.net/2017/05/29/gsoc-2017-add-mptcp-sup...

  • Şeffaf bir alternatif rota varsa uygulamanın açıkça seçmesi neden gerekli, anlamıyorum
    Kernel’in tüm TCP bağlantıları için bunu şeffaf biçimde işlemesi, rota birleştirme veya link tercihi gibi küresel kararları daha iyi vermesini sağlamaz mı?

    • Bunu Linux TCP/ağ alt sistemi bakımcılarının fiilen dayattığı bir koşul olarak anlıyorum. İlk upstream tartışmasına[1] bakınca bunun temel kural olarak belirlendiği görülüyor
      Upstream öncesindeki eski multipath TCP uygulaması, uygulama için tamamen şeffaf olacak şekilde tasarlanmıştı; protokolün amacına da bunun daha uygun olduğunu düşünüyorum
      Elbette birçok durumda MPTCP uygulama yönergeleri alırsa daha iyi olabilir, ama örneğin LTE bağlantısında bir alt akış oluşturup otomatik failover’a hazır tutan, ancak o alt akıştan veri göndermeyen standart bir sistem yaklaşımı bile vakaların %95’i için yeterli olurdu
      [1] https://lore.kernel.org/all/alpine.OSX.2.21.1707181728570.11...
    • Bunu kullanmak, tek bir TCP bağlantısı için her iki uç noktada da birden fazla IP ilişkilendirilebileceği anlamına gelir. Birçok durumda uygulamanın açık desteği veya farkındalığı gerekir
    • Birden fazla IP’nin aynı TCP bağlantısı üzerinden iletişim kurmasına izin vermek yeni güvenlik açıkları yaratabilir
      Örneğin bağlantı anında istemci IP’sini whitelist ile karşılaştıran ve sonrasında değişmeyeceğini varsayan bir uygulamayı düşünebilirsiniz

  • Benim için MPTCP'nin tek pratik kullanım alanı mobil ağ ile Wi‑Fi'yi birlikte kullanarak hızı artırmak. iOS ve WeChat ikisi de bunu destekliyor
    Ancak mobil ağ kota bazlı olduğu için hep kapalı tutuyorum. Bu yüzden kişisel olarak MPTCP benim için işe yaramaz

    • Bu sorunla uğraşmıştım. İçeride buna otopark hatası diyorduk
      Wi‑Fi sinyalinin hâlâ göründüğü ama düzgün bağlanılamadığı durum. MPTCP varsa hücresel bağlantıya failover yapılıyor

  • Linux ağ yığını ve sürücülerini destekleme, hata ayıklama ve düzeltme işi yapıyorum; bunun bu kadar az benimsenmiş olması şaşırtıcı
    SCTP gibi düz TCP'nin yerini almaya çalışan şeylerde olduğu gibi, MPTCP de bazı uygulama geliştiricilerinin kullanmaya devam ettiği bir niş teknoloji olarak kalıyor, dünyanın geri kalanı ise unutuyor gibi görünüyor

    • Apple Siri MPTCP kullandığı için cihaz sayısını düşününce buna sadece niş demek pek doğru değil

  • MPTCP ile QUIC arasındaki yapısal farkları açıklayan ve yazarların önerdiği MPQUIC protokolünü de tanıtan bir kaynak buldum
    QUIC, uygulama akışlarını tek bir UDP akışı üzerinde çoklar; MPTCP ise tek bir akışı birden fazla TCP alt akışına böler. MPQUIC bu iki özelliği birleştirerek uygulama akışlarını birden fazla UDP alt akışı üzerinde çoklar
    [1]: "Multipath QUIC: A Deployable Multipath Transport Protocol" https://www.researchgate.net/publication/327122884_Multipath...
    Şimdi bu protokollerin üretim ortamında nasıl karşılaştırıldığını merak ediyorum. İkisini de kullanmış olan var mı?

    • MPQUIC hâlâ IETF'te tartışılıyor. Son IETF toplantısında da daha fazla değişiklik konuşuldu ve ne yazık ki bu yüzden benimsenmesi yavaşlıyor
      https://lwn.net/Articles/964377/
      İkisi de aynı hedefe ulaşmaya çalışıyor. Teknik olarak çok benzer davranışlar üretilebilir. MPTCP Linux çekirdeğinde uygulanmış durumda, QUIC ise kullanıcı alanı tarafında

  • Apple da destekliyor ve Siri'de kullanıyor
    https://developer.apple.com/documentation/foundation/urlsess...

    • Diğer uygulamalarda da oldukça kolay kullanılabiliyor. Temel işlevlerin içinde yer alıyor
      2011'de VoIP uygulamamızın oldukça sağlam çalıştığını görünce şaşırmıştım :D

  • Aradaki cihazlardan biri bile desteklemiyorsa dönen SYN+ACK paketinin TCP seçenekleri alanında MPTCP seçeneğinin bulunmaması kulağa epey sınırlayıcı geliyor
    Aradaki cihazlar için tek gereksinim MPTCP seçeneğini olduğu gibi iletmek mi?

  • Güvenlik ve gizlilik ayarlarında işe yarayabilir
    Örneğin Çin'in Great Firewall'unu düşünürsek, trafik birden fazla uplink kanalına bölünebildiğinde güvenlik duvarının bunu yeniden birleştirip kural uygulaması zorlaşmaz mı?

    • Bilinmeyen trafikse basitçe engeller ya da ciddi hız sınırlaması uygular