Spoiler alert: BBRv2 is slower than BBRv1 but that’s a good thing. Three years have passed since “ Bottleneck Bandwidth and Round-trip” (BBR) congestion control was released. Nowadays, it is considered production-ready and added to Linux, FreeBSD, and Chrome (as part of QUIC.) In our blogpost from 2017, “ Optimizing web servers for high throughput and low latency,” we evaluated BBRv1 congestion co

TCPの重要な要素として、輻輳制御アルゴリズムがある。TCPはシーケンス番号を使った応答確認によってデータの確実な到達を担保している。応答確認が行われないパケットについては、再度同じデータを送信するように、受信側から送信側へ再送要求が行われる。 ところが、ネットワークが輻輳して遅延が大きくなると、同じデータを何度も再送してしまい、無駄なトラフィックが発生して輻輳がさらに悪化する。そこで転送量を制御して輻輳状態を抑える「輻輳制御」が重要となる。 輻輳制御を行うアルゴリズムの歴史は、TCPの歴史と言っても過言ではない。ここで簡単に発展経緯をひもといてみよう。 1988年に初登場した輻輳制御アルゴリズム「Tahoe」は、後に登場するアルゴリズムに多くの影響を与えた。段階的にウインドウサイズ▼を増加させて帯域流量を増加させる「スロースタート」、再送タイムアウトを待たずにパケットを送信する「高速再送

検証結果の理由TCP はデータ欠損が発生しない。これを実現するための仕組みに再送処理があるが、そもそも再送がなるべく発生しないように、受信側が処理可能なデータ量だけを送信するように流量制御を行っている。流量制御の仕組みは、 受信側はバッファを用意する。受信側は送信側にウィンドウサイズ(rwnd)を通知する。(バイト数単位で指定する)送信側は輻輳制御アルゴリズムに基づいてウィンドウサイズ(cwnd)を決定し、ウィンドウサイズ( min(cwnd, rwnd) )分のデータを送信する。受信側はデータを受け取ったら ACK を返す。送信側は ACK を受け取ると、次のデータを送信する(ウィンドウがスライドする=スライディングウィンドウ)。このとき輻輳制御アルゴリズムがウィンドウサイズを再調整する。 ただ複数セグメントをまとめて送信できるとはいえ、送信側がパケットを送るためには、 受信側からの A

tl;dr トラフィックが多いL4ロードバランサーなどのサーバーでは、BBRを有効にし、キューイングアルゴリズムをfqにするとソケットバッファ(以下バッファと呼ぶ)が枯渇するので、fqにするのはお勧めしないというお話です。 前提 この記事ではBBRとはなんぞや、keepalivedはなんぞやということは説明しておりません。 前提として、BBRの概要、keepalivedの概要がわかっていることで話をします。 以下が今回検証した環境です。 OS: Ubuntu20.04 keepalived: 2.0.19 はじめに TCPの輻輳制御のアルゴリズムであるBBRを有効にしたら、TCPの速度がはやくなるのではないかという話になり、BBRを有効にしてkeepalivedを動かしたら以下のエラーが出力されてサーバとの通信ができなくなりました。 Keepalived_vrrp[6098]: Error

私たちはこのほど、インターネット トラフィックの帯域幅を広げ、レイテンシを低減する最先端の輻輳制御アルゴリズム、TCP BBR を Google Cloud Platform（GCP）に導入しました。TCP BBR は、google.com からの TCP トラフィックで使われ、YouTube ネットワークのスループットを全世界平均で 4 %、一部の国では 14 % 以上引き上げたのと同じ BBR です。 私たち WP Engine のデジタル エクスペリエンス プラットフォーム上で稼働する 50 万の WordPress サイトは、BBR のおかげで驚異的な速さでロードできるようになりました。Google のテストによれば、BBR のスループットはこれまでベストだった loss-based 輻輳制御の 2,700 倍に達し、キューイング遅延は 25 倍も下がっています。私たちが GCP

様々な輻輳制御アルゴリズム 輻輳制御アルゴリズムとは、輻輳ウインドウサイズ（cwndと表されます）をいかに上手にコントロールするか、の方法です。より効率の良いデータ転送を実現するために、これまで非常に多くの輻輳制御アルゴリズムが研究されてきました。 これまでに開発された代表的な輻輳制御アルゴリズムとその関係性を、図1を用いて紹介します。 図1　様々な輻輳制御アルゴリズム 図中では、四角い囲みが各輻輳制御アルゴリズムの名称と提案年を表します。横軸は時間軸で、右に位置するものほど新しい輻輳制御アルゴリズムであることを表します。塗りつぶしの色はフィードバック形式の違いを表し、黄色がLoss-based、濃緑がDelay-based、そして水色がHybridを表します。Loss-basedはパケットロスを、Delay-basedは遅延を、Hybridはその両方を基準に、cwndを更新する輻輳制御ア

本連載の背景と目的 近年、LTEなどの高速なネットワークの展開とスマートフォンや様々なクラウドサービスの普及により、インターネットを流れるデータ量は急激に増大しています。今後も、新たなスマートデバイスやIoTサービスの普及、5Gサービスの商用展開などに従い、私たちの生活においてインターネットへの接続は不可欠なものとなっていくと考えられます。そのインターネットにおいて広く利用されているプロトコルがTCP/IPです。TCP/IPは1980年頃にその基本形が完成して以来、インターネットの普及とともに広まり、発展を続けてきました。 本連載では、TCP/IPの中でも初学者にとって難しいプロトコルであるTCPに着目します。TCPは通信の信頼性を担保するための様々な機能を備えています。特に、ネットワークの状況に応じて効率的にデータを転送するための輻輳制御アルゴリズムは、今日にいたるまで様々な手法が提案、

Raspberry Pi2とUSB Wifiドングルで無線アクセスポイント(ルーター)化をした時のメモ 利用したWifiドングルは BUFFALO の WLI-UC-GNM2。 BUFFALO 11n対応 11g/b 無線LAN子機 親機-子機デュアルモード対応モデル WLI-UC-GNM2 出版社/メーカー: バッファロー発売日: 2011/07/30メディア: Personal Computers購入: 198人 クリック: 5,602回この商品を含むブログを見る 無線LAN子機 親機-子機デュアルモード対応で、普通にWifiアクセスポイントに接続したり、親機にしたりどちらにも使えます。 手順はここに載っている通りなんですが、 www.maketecheasier.com コマンドで以下のように手動実行しようとすると $ sudo hostapd /etc/hostapd/hostap