TCP BBRのテスト - Slow-fire hacking next

以前から気になっていたTCP BBR。Youtubeではかなりのパフォーマンスが向上したらしい。
しかし、テストをしていたが全然効果がない。全く。どうやらホームラボで確認する限りは効果がない。
効果がわかる検証ができたのでご紹介。

まず、BBRって何？ネットワークの輻輳制御アルゴリズムである。これを制御することでネットワーク通信が効率よくできる。
何も設定をしない場合は、CUBICというモードになる。

CUBICは，パケット廃棄数をネットワークの輻輳状態の指標とする
以下のように表示されていればCUBIC

# cat /proc/sys/net/ipv4/tcp_congestion_control
cubic

BBRは，RTTをネットワークの輻輳状態の指標とする
以下のように表示されていればBBR

# cat /proc/sys/net/ipv4/tcp_congestion_control
bbr

まとめると、このBBRは、そこそこ遠いサイトへの通信で効果がでてくるのではと。。。
というわけでオブジェクトストレージで確認をしてみる。それも遠目のもの。今回はbackblaze B2を利用することに
オブジェクトストレージにいきなりベンチマークをとっても、「試してガッテン」になるのである程度、予備試験をする。

環境は、NURO光でUbuntu Server 20.04のvSphere 7.0U2のVM (2vcpu 4GB RAM)

まずは　経路の確認。16ホップで到達する様子

# traceroute -I s3.us-west-002.backblazeb2.com
traceroute to s3.us-west-002.backblazeb2.com (206.190.215.254), 30 hops max, 60 byte packets
1 <ホームラボのルータ> (192.168.X.1) 0.184 ms 0.255 ms 0.252 ms
2 <家のONUルータ> (192.168.Y.1) 0.616 ms 0.667 ms 0.725 ms
3 <プロバイダーのルータ> (PPP.QQQ.RRR.SSS) 6.685 ms 6.692 ms 6.692 ms
〜略〜
16 s3.us-west-002.backblazeb2.com (206.190.215.254) 115.159 ms 115.142 ms 115.180 ms

次にPingでの確認。別に疎通確認をしているのではなく、ざっくりの帯域確認をするため。

# ping -s 1426 s3.us-west-002.backblazeb2.com -c 10
PING s3.us-west-002.backblazeb2.com (206.190.215.254) 1426(1454) bytes of data.
1434 bytes from s3.us-west-002.backblazeb2.com (206.190.215.254): icmp_seq=1 ttl=49 time=115 ms
〜略〜
1434 bytes from s3.us-west-002.backblazeb2.com (206.190.215.254): icmp_seq=10 ttl=49 time=115 ms

--- s3.us-west-002.backblazeb2.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9013ms
rtt min/avg/max/mdev = 114.255/115.531/118.309/0.999 ms

もっと大きいパケットでテストしたかったのだが、先方のセキュリティの制限でこれが限界だった。なので、帯域はあくまでも目安
たまに大きいパケットを送信できるのだが、それによると4Mbpsしか取れない。

BBRの設定は以下のsysctlのパラメータを設定して、再起動をする。再起動をしないとBBRが有効にならない。

net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr

再起動後、以下を確認する

# cat /proc/sys/net/ipv4/tcp_congestion_control
bbr

systctlの設定を外すとCUBICに戻る。

テスト方法

s3testerを利用。Goが必要だが、Linux x86_64の単体バイナリも置いてあるのでそれを利用。
https://github.com/s3tester/s3tester

クレデンシャルが出ちゃうのであくまでもサンプル。事前にAWSコマンドにプロファイルを設定しておくこと。

# s3tester -bucket=＜バケット名＞ -concurrency=16 -size=16777216 -operation=put -requests=200 -prefix=testdata1 --profile=＜awsコマンドのプロファイル＞ --endpoint=＜エンドポイントURL＞ -region=＜リージョン＞

まずはCUBICでの確認

Size=1M 同時16接続で200リクエスト (PUT)
Content throughput: 7.738037 MB/s
Size=16M 同時16接続で200リクエスト (PUT)
Content throughput: 35.019121 MB/s
Size=16M 同時32接続で200リクエスト (PUT)
Content throughput: 38.083356 MB/s

次にBBRでの確認

Size=1M 同時16接続で200リクエスト (PUT)
Content throughput: 10.320328 MB/s
Size=16M 同時16接続で200リクエスト (PUT)
Content throughput: 63.878509 MB/s
Size=16M 同時32接続で200リクエスト (PUT)
Content throughput: 85.140798 MB/s

BBRの効果が結構でている。

注意点としては

全てのLinuxディストリビューションやカーネルバージョンでサポートされているわけではない。(Linux Kernel 4.9以降。Ubuntu 20.04やRHEL8/CentOS8では使えると思われる。CentOS7だとepelカーネルが必要）
言うまでもないが、ネットワーク的に近い環境の場合は、効果はほぼない。効果が出るか出ないかは、実測したほうがいい。効果が出ても薄い場合がある。なので、いきなりベンチマークを取るのではなく、Linuxのtracerouteとpingでも確認。
これって、大丈夫なの？何か言われて説明に困るのであれば、使わない方が身のためかもしれない。これって使えますか？どこに書いてありましたと言われても。。。。

コメントを残す コメントをキャンセル

コメントを残すコメントをキャンセル