Tailscaleは、デバイスを「tailnets」と呼ばれるプライベートネットワークに接続するコネクティビティプラットフォームであり、現在、トラフィックの移動や準備を担当するシステム部分の変更に取り組んでいます。9月22日の投稿において、同社はこれらの作業がLinuxおよびAndroidのパケット処理、サブネットルーター、appコネクター、およびエグジットノード向けのマルチキュー処理、さらにnetmapキャッシュを通じた広範な起動の改善をカバーしていると述べています。
最初の変更は小さなパケットを対象としています。Tailscaleによると、ほとんどのネットワークパケットは約1 KiBですが、LinuxのGeneric Receive Offload（GRO）というスループット向上機能は、より大きなバッチのトラフィックを処理するために64 KiBを保持できるバッファを想定しています。従来のパスでは、各小さなパケットを独自の大きなバッファにコピーしていました。LinuxおよびAndroidにおいて、Tailscaleは現在、パケットを大きな読み取りバッファ内に残し、各パケットの開始位置と終了位置を追跡することで、多くの小さなパケットが1つの割り当てを共有できるようにします。同社は、この変更だけで多くのネットワーク構成において約5%の速度向上が見られたと報告しています。
パケットが個別の64 KiBバッファにコピーされる代わりに、より大きな読み取りバッファ内に残るLinuxおよびAndroidのパケット処理の説明の後に配置。
マルチキューの作業は、多くの接続のためにトラフィックを転送するノードを対象としています。サブネットルーターはtailnetと物理的なサブネットの間のゲートウェイであり、Tailscaleを実行できないデバイスをネットワークに参加させます。エグジットノードは、別のデバイスを通じて外部インターネットトラフィックをルーティングします。Tailscaleは、これらの役割が以前は、受信アプリケーションが自身のパケットを順序通りに受信する必要があるため、一部の理由から、独立したストリームを1つの順序付けられたシングルスレッドパイプラインで処理していたと述べています。新しい設計では、各ストリームを「レーン」に割り当て、CPUコア全体でレーンを並列に実行し、レーンの数をピアの数ではなくマシンの性能に合わせてスケールさせます。この投稿では、appコネクターも恩恵を受けると述べられていますが、これらは短期間の接続で多くのユーザーにサービスを提供するTailscaleノードとして定義されています。
サブネットルーター、エグジットノード、およびappコネクターが1つの順序付けられたパイプラインからCPUコア全体にわたる並列レーンに移行する議論の後に配置。
起動ももう一つの主要なターゲットです。通常、デバイスはTailscaleのコントロールプレーンに連絡し、認証を行い、到達可能なデバイスと接続方法を記述したネットワークマップ（netmap）を受け取ります。これは典型的なネットワークでは約100ミリ秒かかりますが、質の低い機内Wi-Fi、フィルタリングされたホテルのネットワーク、またはその他の不安定な接続では、遅延やブロックが発生することがあります。netmapキャッシュを使用すると、以前に接続したことのあるデバイスは永続ディスクにコピーを保存し、コントロールプレーンに到達する前に直接のデバイス間接続の確立を開始できます。Tailscaleは、コントロールプレーンへの到達性が低いtailnetにおいて、ウォームキャッシュでの起動はコールドスタートよりも1〜2桁速かったと述べています。
トレードオフは特定のものがあります。キャッシュには事前の接続成功とディスクスペースが必要であり、非常に大きなtailnetでは大幅なキャッシュ更新トラフィックが発生する可能性があり、SDカードのような低速または摩耗に敏感なストレージは適さない可能性があります。可用性も段階的に導入されます。バッファの変更はLinuxおよびAndroidのv1.104で予定されており、マルチキューのサポートはv1.104以降に計画され、netmapキャッシュはテスト済みのデフォルト展開の前に現在機能フラグの背後にあります。したがって、Linux/Androidへの焦点は、明示された展開の境界であり、他の場所で同じ技術が不可能であることを証明するものではありません。