VPSにTCP BBRなhttp/2 Proxyを構築してMVNOなiPhoneから使う

はじめに

 自宅のインターネット環境として、レオネットからOCNへ抜ける環境を使っています。
 しかし、IPv6とのデュアルスタックがないこと、AbemaTVなど動画を見ているとしばしばバッファが発生することがありました。
 これらをVPS上のProxyで改善できないか、あわよくばMVNOの通信環境も改善できないかと思いました。

対象読者

  • MVNOを混雑する時間帯も快適に使いたい人
  • pingでロスがある、rttが2桁ms以上ある環境からもっとスループットが欲しい人

前提条件

  • VPSにはChonoha VPSの1GBプラン、Ubuntu 16.04 (64bit)を使っています。
  • 固定回線は20時台にPingが1%ほど落ち、rttが50msあるアクセス環境です。
  • MVNOは4G、iPhone 7 plusを使っています。

1. Proxyの構築

 Proxyサーバには、Squidを利用します。

1-1. Squidのインストール

Squidをインストールするには、次のコマンドを入力します。

apt-get install squid

 インストールができたら、設定ファイルを編集し、次の内容を先頭に挿入します。

vi /etc/squid/squid.conf
acl localnet src 127.0.0.1/32 ::1
acl localdomain srcdomain .hiroshima.ocn.ne.jp
acl localdomain srcdomain .mineo.jp
http_access allow localnet
http_access allow localdomain

visible_hostname unknown
#forwarded_for off
#request_header_access X-FORWARDED-FOR deny all
#request_header_access Via deny all
#request_header_access Cache-Control deny all
#reply_header_access X-Forwarded-For deny all
#reply_header_access Via deny all
#reply_header_access Cache-Control deny all

client_persistent_connections off
server_persistent_connections off

negative_ttl 0 minutes
shutdown_lifetime 0 seconds

acl NOCACHE src all
cache deny NOCACHE

 aclの節では、許容する接続元に自分の利用するプロバイダのドメインを指定しています。これは、IPアドレスが変わるためです。利用する環境と許容するセキュリティレベルに合わせて設定してください。「#」でコメントアウトしているのは、プロキシ特有の情報を隠す設定ですが、隠す必要がない場合は無効にしたほうがキャッシュコントロールが効いて早いです。また、squidのキャッシュは無効にしています。

 設定を反映させるために、サービスを再起動します。

service squid restart
lsof -i | grep squid
squid    2939    proxy    6u  IPv6  26526      0t0  UDP *:40851 
squid    2939    proxy    8u  IPv4  26527      0t0  UDP *:57064 
squid    2939    proxy   11u  IPv6  26530      0t0  TCP *:3128 (LISTEN)
squid    2939    proxy   14u  IPv6  26533      0t0  UDP localhost:33861->localhost:59409 

1-2. Chromeからの動作確認

 では、ChromeからProxyを利用してアクセスできるか確認してみましょう。
 Chromeは、利用するProxyサーバを設定するにはWindowsの設定画面を利用するのが一般的ですが、それではシステムの設定も変わってしまいます。しかし、Chromeの起動スクリプトを利用すれば、Chromeのみ指定したProxyサーバを利用することができます。

以下は、起動ショートカットの設定例です。--proxy-server= の次にsquidを起動しているサーバのIPアドレスを、--proxy-bypass-list=の次に、Proxyを介さずにアクセスしたいIPアドレスを入力します。

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --proxy-server=111.111.111.111:3128 --proxy-bypass-list=localhost;127.0.0.1;192.168.*

 これでProxyを介したインターネットアクセスになっているはずです。デュアルスタックになっていることを確認するために、IPv6テストサイトへアクセスしてみましょう。

https://test-ipv6.jp/

一般のインターネット上で見えるあなたの IPv4 アドレスは 111.111.111.111

    一般のインターネット上で見えるあなたの IPv6 アドレスは 2400:8500:1302:847:111:111:111:111

    ご利用のインターネットサービスプロバイダ (ISP): INTERQ GMO Internet,Inc

    あなたはIPv6接続に対応しているため、他のIPv6サイトへの到達性の状況を示すタブを表示します。

    このWebサイトではベータ版のHTTPSをサポートしています。

    あなたの DNS サーバ (おそらくお使いのプロバイダが運用) は、IPv6 インターネットアクセスがあるように思われます。
あなたの事前対応点
10/10   コンテンツ側が IPv6 のみになった際の、あなたの IPv6 の安定性と準備状況

 これで、デュアルスタックのインターネットアクセス環境が整いました。

1-3. iPhoneからのProxy利用

 せっかくProxyを構築したので、スマホからも利用したいと思いませんか?
 Wifiからのproxy設定は簡単にできるのでいいとして、モバイル回線からProxyを利用する場合は、プロファイルに手を入れる必要があります。

 ご自身の利用するMVNOからプロファイルを入手して、以下の内容を追記します。

<key>APNs</key>
<array>
  <dict>
    ~~~ ここから ~~~
    <key>ProxyServer</key>
    <string>111.111.111.111</string>
    <key>ProxyPort</key>
    <integer>3128</integer>
    ~~~ ここまで ~~~
  </dict>
</array>

 編集したプロファイルを利用するには、iPhoneに読み込ませる必要があります。編集前のオリジナルのプロファイルと編集後のプロファイルをまとめてiCloud等のメールに送信しておけば、もしVPSの障害などで接続できない場合も切り戻しが容易になります。

 プロファイルを切り替え後は、iPhoneから先ほどのIPv6テストサイトへアクセスして、VPSのプロバイダが表示されるか確認してみましょう。

squidのログをみて確認するのも良いでしょう。less /var/log/squid/access.logで開いたあと、Gで最下段、shift+fで順次表示に設定したあと、safariでgoogleを開いてみましょう。googleを開いたログが見えましたか?

2. Secure Proxyの構築

 ここまでで、Squid経由でインターネット接続できるようになりました。しかし、ブラウザからSquidまではhttp 1.1で接続されているため、通信内容は暗号化されません。どうせSSL化するなら、http/2に対応したSecure Proxyを構築してみましょう。

 nghttpxを、Squidと連携して動作させます。
 ここまでは、次のような接続構成でした。

 PC ---(IPv4 Internet, http 1.1)--- Squid ---(IPv4/IPv6 Internet)

 nghttpx を利用すると、ProxyまでのアクセスをSSLで暗号化できます。

  PC ---(IPv4 Internet, http/2 SSL)--- nghttpx - Squid ---(IPv4/IPv6 Internet)

2-1. ドメイン取得、SSL証明書の入手

 ドメインを取得してDNSにIPアドレスを設定し、Let's Encryptで証明書を取得します。ここでは、説明を省略します。

2-2. nghttpxのインストール

 nghttpxをパッケージからインストールします。

apt-get install nghttp2

 インストールが終わったら、設定ファイルを開き、既存の設定をコメントアウトして、http/2プロキシとして動作させるためのの設定を入力します。
 private-key-file、certificate-fileには、取得した証明書のフルパスを入力します。

vi /etc/nghttpx/nghttpx.conf
frontend=0.0.0.0,3127
backend=127.0.0.1,3128
private-key-file=/etc/letsencrypt/live/example.net/privkey.pem
certificate-file=/etc/letsencrypt/live/example.net/fullchain.pem
http2-proxy=yes
workers=1

#accesslog-file=/var/log/nghttpx/access.log
#errorlog-file=/var/log/nghttpx/error.log

verify-client=no
add-x-forwarded-for=yes
no-via=yes
no-ocsp=yes
no-host-rewrite=yes
tls-proto-list=TLSv1.2
ciphers=ECDHE+AES128

 ログを出力する場合は、保存先ディレクトリを作成後、コメントを外しましょう。
 設定が終わったら、nghttpxを再起動します。

service nghttpx restart

 では、Chromeからnginxにアクセスしてみましょう。
 起動オプションは、--proxy-server=https://に変更します。

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --proxy-server=https://example.net:3127 --proxy-bypass-list=localhost;127.0.0.1;192.168.1.*

 Firefoxからnghttpxを利用する場合は、proxy.pacファイルを用意します。
 以下の内容で作成し、適当なサーバに配置後、ブラウザに設定します。

    function FindProxyForURL(url, host) {
        return "HTTPS example.net:3127";
    }

 うまくいったでしょうか。

 なお、Chromeがhttp/2通信しているか確認するには、拡張機能を利用するか、デバッグ用の画面を利用します。
 httpのサイトでも、ブラウザからProxyまではhttp/2で通信していることが確認できます。

 - HTTP/2 and SPDY Indicator
 - chrome://net-internals/#http2

Host    Proxy   ID  Negotiated Protocol Active streams  Unclaimed pushed    Max Initiated   Pushed  Pushed and claimed  Abandoned   Received frames Secure  Sent settings   Received settings   Send window Receive window  Unacked received data   Error
example.net:3127    direct://   37  h2  4   0   100 27574   0   0   0   913769  null    null    null    36702   15728640    6739510 0

 ちなみに、iPhoneからssl proxyに接続できるか手動と自動の設定を試してみましたが、いまのところ未対応のようです。

3. TCP BBRをインストール

 TCP BBRはkernel 4.9以上でサポートされています。CUBICはloss-basedでパケットロスがあると帯域を半分に抑えるのに対し、BBRは速度と遅延をベースにしているため、パケットロスがある環境でもスループットの向上とレイテンシの低減が期待できるようです。
 - 輻輳制御の新アルゴリズム TCP BBR を GCP に導入

 では、まずは現状の状態を確認します。

root@:~# uname -r
4.4.0-57-generic
root@:~# sysctl net.ipv4.tcp_available_congestion_control
net.ipv4.tcp_available_congestion_control = cubic reno
root@:~# sysctl net.ipv4.tcp_congestion_control
net.ipv4.tcp_congestion_control = cubic
root@:~# sysctl net.core.default_qdisc
net.core.default_qdisc = pfifo_fast
root@:~# lsmod | grep bbr

 bbrはkernel 4.9からサポートされるのに対し、現在使っているバージョンはkernel 4.4のため、まずはカーネルをアップデートする必要があります。最新カーネルとTCP BBRを簡単に導入するには、2つの方法があります。

  1. シェルスクリプトを使う
  2. HWE (Hardware Enablement) カーネルを使う(Ubuntu 16.04以上限定)

 1番のシェルスクリプトは、最新のカーネルをインストールして、TCP BBRを設定するところまで自動で実施してくれます。CentOS 6+、Debian 7+ 、Ubuntu 12+をサポートしています。
 2番の方法は、Ubuntu公式の最新カーネルを導入後、手動でsysctl.confを編集してtcp bbrを有効化する必要があります。
 ここでは、1番のシェルスクリプトを使います。

wget https://github.com/teddysun/across/raw/master/bbr.sh && chmod +x bbr.sh && ./bbr.sh

 シェルスクリプトを実行してエンターを押すと、カーネルのダウンロードとインストールが実行されます。最後に [y] でリブートします。

root@:~# wget https://github.com/teddysun/across/raw/master/bbr.sh && chmod +x bbr.sh && ./bbr.sh

---------- System Information ----------
 OS      : Ubuntu 16.04.4 LTS
 Arch    : x86_64 (64 Bit)
 Kernel  : 4.4.0-57-generic
----------------------------------------
 Auto install latest kernel for TCP BBR

 URL: https://teddysun.com/489.html
----------------------------------------

Press any key to start...or Press Ctrl+C to cancel
--2018-04-08 00:30:26--  http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.16/linux-image-4.16.0-041600-generic_4.16.0-041600.201804012230_amd64.deb
Resolving kernel.ubuntu.com (kernel.ubuntu.com)... 91.189.94.216
Connecting to kernel.ubuntu.com (kernel.ubuntu.com)|91.189.94.216|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 53088470 (51M) [application/x-debian-package]
Saving to: ‘linux-image-4.16-amd64.deb’

     0K .......... .......... .......... .......... ..........  0%  108K 8m0s
    50K .......... .......... .......... .......... ..........  0%  216K 6m0s
()
 51750K .......... .......... .......... .......... .......... 99% 35.6M 0s
 51800K .......... .......... .......... .......... ....      100% 38.6M=6.1s

2018-04-08 00:30:33 (8.34 MB/s) - ‘linux-image-4.16-amd64.deb’ saved [53088470/53088470]

Selecting previously unselected package linux-image-4.16.0-041600-generic.
(Reading database ... 126851 files and directories currently installed.)
Preparing to unpack linux-image-4.16-amd64.deb ...
Done.
Unpacking linux-image-4.16.0-041600-generic (4.16.0-041600.201804012230) ...
Setting up linux-image-4.16.0-041600-generic (4.16.0-041600.201804012230) ...
Running depmod.
update-initramfs: deferring update (hook will be called later)
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.16.0-041600-generic /boot/vmlinuz-4.16.0-041600-generic
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 4.16.0-041600-generic /boot/vmlinuz-4.16.0-041600-generic
update-initramfs: Generating /boot/initrd.img-4.16.0-041600-generic
W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.
run-parts: executing /etc/kernel/postinst.d/unattended-upgrades 4.16.0-041600-generic /boot/vmlinuz-4.16.0-041600-generic
run-parts: executing /etc/kernel/postinst.d/update-notifier 4.16.0-041600-generic /boot/vmlinuz-4.16.0-041600-generic
run-parts: executing /etc/kernel/postinst.d/x-grub-legacy-ec2 4.16.0-041600-generic /boot/vmlinuz-4.16.0-041600-generic
Searching for GRUB installation directory ... found: /boot/grub
Searching for default file ... found: /boot/grub/default
Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
Searching for splash image ... none found, skipping ...
Found kernel: /boot/vmlinuz-4.4.0-119-generic
Found kernel: /boot/vmlinuz-4.4.0-57-generic
Found kernel: /boot/vmlinuz-4.4.0-31-generic
Found kernel: /boot/vmlinuz-4.16.0-041600-generic
Found kernel: /boot/vmlinuz-4.4.0-119-generic
Found kernel: /boot/vmlinuz-4.4.0-57-generic
Found kernel: /boot/vmlinuz-4.4.0-31-generic
Replacing config file /run/grub/menu.lst with new version
Updating /boot/grub/menu.lst ... done

run-parts: executing /etc/kernel/postinst.d/zz-update-grub 4.16.0-041600-generic /boot/vmlinuz-4.16.0-041600-generic
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.16.0-041600-generic
Found initrd image: /boot/initrd.img-4.16.0-041600-generic
Found linux image: /boot/vmlinuz-4.4.0-119-generic
Found initrd image: /boot/initrd.img-4.4.0-119-generic
Found linux image: /boot/vmlinuz-4.4.0-57-generic
Found initrd image: /boot/initrd.img-4.4.0-57-generic
Found linux image: /boot/vmlinuz-4.4.0-31-generic
Found initrd image: /boot/initrd.img-4.4.0-31-generic
done
removed 'linux-image-4.16-amd64.deb'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.16.0-041600-generic
Found initrd image: /boot/initrd.img-4.16.0-041600-generic
Found linux image: /boot/vmlinuz-4.4.0-119-generic
Found initrd image: /boot/initrd.img-4.4.0-119-generic
Found linux image: /boot/vmlinuz-4.4.0-57-generic
Found initrd image: /boot/initrd.img-4.4.0-57-generic
Found linux image: /boot/vmlinuz-4.4.0-31-generic
Found initrd image: /boot/initrd.img-4.4.0-31-generic
done

Info: The system needs to reboot.
Do you want to restart system? [y/n]
y

 再起動後、カーネルのバージョン、輻輳制御方式を確認します。

root@:~# uname -a
Linux 4.16.0-041600-generic #201804012230 SMP Sun Apr 1 22:31:39 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
root@:~# sysctl net.ipv4.tcp_available_congestion_control
net.ipv4.tcp_available_congestion_control = reno cubic bbr
root@:~# sysctl net.ipv4.tcp_congestion_control
net.ipv4.tcp_congestion_control = bbr
root@:~# sysctl net.core.default_qdisc
net.core.default_qdisc = fq
root@:~# lsmod | grep bbr
tcp_bbr                20480  4

 比較のために、bbrカーネル使用前後のspeedtestをしてみます。

  • 使用前
root@:~# wget -O speedtest-cli https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest.py && chmod +x speedtest-cli && ./speedtest-cli 
--2018-04-08 00:52:53--  https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest.py
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.72.133
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.72.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 59555 (58K) [text/plain]
Saving to: ‘speedtest-cli’

speedtest-cli                                  100%[====================================================================================================>]  58.16K  --.-KB/s    in 0.002s  

2018-04-08 00:52:53 (30.7 MB/s) - ‘speedtest-cli’ saved [59555/59555]

Retrieving speedtest.net configuration...
Testing from GMO Internet (163.44.169.216)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by IPA CyberLab (Bunkyo) [2.57 km]: 1.86 ms
Testing download speed................................................................................
Download: 125.73 Mbit/s
Testing upload speed................................................................................................
Upload: 135.56 Mbit/s
  • 使用後
root@:~# ./speedtest-cli 
Retrieving speedtest.net configuration...
Testing from GMO Internet,Inc (150.95.146.127)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by IPA CyberLab (Bunkyo) [5.97 km]: 1.88 ms
Testing download speed................................................................................
Download: 125.40 Mbit/s
Testing upload speed................................................................................................
Upload: 101.06 Mbit/s

 使用後のほうが、VPSからスピードテストサーバまでのスループットは少し落ちてしまいました。これは、cubicがベルトコンベアにじゃんじゃんパケットを積み込むのに対して、bbrはrttが悪化しないよう様子を見ながら積み込むという特性があります。そのため、低遅延かつパケットロスのないネットワークでは、cubicよりも少し遅くなります。
パケットロス環境下におけるcubicとbbrのスループットを比較したよい資料があります。下のスライドの13ページ目のグラフを参照してください。

https://www.janog.gr.jp/meeting/janog41/application/files/4615/1727/7615/janog41-sp09tcp-ishizaki-02.pdf

4. その他

 ここまでで、Secure Proxyを利用する準備ができました。ここからは、利用中に起こった問題と解決策を紹介します。

4-1. ChromeでWebSocketが利用できない

 ChromeでSecure Proxyを利用していると、WebSocketがうまく動きません。具体例としては、ニコニコ生放送のhtml 5対応ページで動画とコメントが再生されないません。ちなみにFirefoxではこの問題は起こりません。
 WebSocketの接続テストをできるページによると、SSL以外が失敗します。

Aggregated Test Results
WebSockets supported    Yes ✔
WebSocket protocol version  rfc-6455
HTTP Proxy  No
Browser chrome 66.0.3359.81
Antivirus   No Data
WebSockets (Port 80)    No ✘
WebSockets (Port 443)   No ✘
WebSockets (Port 8080)  No ✘
WebSockets (Port 443, SSL)  Yes ✔

 この問題を回避するには、WebSocketとの通信のみProxyを経由せず直接接続すればよいです。Chromeの起動オプションのバイパスリストにWebSocketを加えましょう。

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --proxy-server=https://example.net:3127 --proxy-bypass-list=localhost;127.0.0.1;192.168.1.*;ws://*

 これで、先ほどのテストを実施すると、全て成功します。

Aggregated Test Results
WebSockets supported    Yes ✔
WebSocket protocol version  rfc-6455
HTTP Proxy  No
Browser chrome 66.0.3359.81
Antivirus   No Data
WebSockets (Port 80)    Yes ✔
WebSockets (Port 443)   Yes ✔
WebSockets (Port 8080)  Yes ✔
WebSockets (Port 443, SSL)  Yes ✔

 その他、VPSからのアクセスを許容しないサイトに遭遇したら、バイパスリストに加えればよいでしょう。

4-2. 輻輳時に通信が停止する問題

 自分の環境からAbemaTVなどを閲覧していると、しばしば止まることがあります。タスクマネージャのイーサネットのスループットグラフや連続Pingから想定すると、ネットワークが輻輳すると、途中のNWで一時的に転送を抑止しているように見えていました。
 このことから、自分のインターネットアクセス環境の最大ネットワーク速度で通信速度を抑えればいいと仮定しました。レオネットのカタログスペックは100Mbps、Chonoha VPSも100Mbpsですが、正確なところはどうでしょうか。
 まずは、レオネットのMTUを測定してみました。結果は、1426でした。

PS > ping 1.1.1.1 -f -l 1426

1.1.1.1 に ping を送信しています 1426 バイトのデータ:
1.1.1.1 からの応答: バイト数 =1426 時間 =16ms TTL=52
1.1.1.1 からの応答: バイト数 =1426 時間 =18ms TTL=52

1.1.1.1 の ping 統計:
    パケット数: 送信 = 2、受信 = 2、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 16ms、最大 = 18ms、平均 = 17ms

PS > ping 1.1.1.1 -f -l 1428

1.1.1.1 に ping を送信しています 1428 バイトのデータ:
10.55.215.1 からの応答: パケットの断片化が必要ですが、DF が設定されています。
パケットの断片化が必要ですが、DF が設定されています。

1.1.1.1 の ping 統計:
    パケット数: 送信 = 2、受信 = 1、損失 = 1 (50% の損失)、

 MTUは、自宅環境のほうがEthernet標準の1500より小さいことがわかりました。このことから、VPSから自宅のPCにデータを送信するとき、VPSから送信する速度が早すぎて、途中のNWでキューが一杯になって輻輳していると想定しました。
 適切な通信帯域は、以下のように計算しました。

 100Mbps / 8bit / 1500byte * 1426byte * 8bit = 95.06Mbps

 これを、VPSに設定します。

tc qdisc add dev ens3 root handle 1: htb default 0
tc class add dev ens3 parent 1:0 classid 1:0 htb rate 95Mbit

 なお、削除するには、以下のコマンドを実行します。

tc qdisc del dev ens3 root

 起動時に実行するには、rc.localに設定します。

vi /etc/rc.local 
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

tc qdisc add dev ens3 root handle 1: htb default 0
tc class add dev ens3 parent 1:0 classid 1:0 htb rate 95Mbit

exit 0

 うまく帯域制御できているか確認します。

 tc実行前と実行後をスピードテストスクリプトで比較します。

  • tc実行前
root@:~# ./speedtest-cli 
--2018-04-08 03:38:35--  https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest.py
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.72.133
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.72.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 59555 (58K) [text/plain]
Saving to: ‘speedtest-cli’

speedtest-cli                                  100%[====================================================================================================>]  58.16K  --.-KB/s    in 0.002s  

2018-04-08 03:38:36 (25.4 MB/s) - ‘speedtest-cli’ saved [59555/59555]

Retrieving speedtest.net configuration...
Testing from GMO Internet,Inc (150.95.191.105)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by OPEN Project (via 20G SINET) (Tokyo) [0.16 km]: 1.725 ms
Testing download speed................................................................................
Download: 126.08 Mbit/s
Testing upload speed................................................................................................
Upload: 135.56 Mbit/s
  • tc実行後
root@:~# ./speedtest-cli 
Retrieving speedtest.net configuration...
Testing from GMO Internet,Inc (150.95.191.105)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by OPEN Project (via 20G SINET) (Tokyo) [0.16 km]: 1.624 ms
Testing download speed................................................................................
Download: 117.34 Mbit/s
Testing upload speed................................................................................................
Upload: 91.64 Mbit/s

 帯域制御がUpload側、Proxyから自宅への送信方向にうまく効いていることが確認できました。

しかし、この計算と対処が適切かどうかは、全く自信がありません...

帯域テスト

 fast.comでPCから帯域テストしました。

  • 設定なし

 38Mbps

  • Squid

 80Mbps

  • TCP BBR + Squid

 86Mbps

  • TCP BBR + Squid + nghttpx

 83Mbps

  • tc + TCP BBR + Squid + nghttpx

 81Mbps

 平日12時台にMVNOの4G回線からiPhoneのSpeedtestアプリでテストしました。

  • 設定なし

 1Mbps

  • TCP BBR + Squid

 2Mbps

同じく平日12時台に、MVNOの4G回線から、fast.comで測定しました。

  • 設定なし

250kbps

  • TCP BBR + Squid

6.9Mbps

30倍近く速くなりました。

まとめ

パケットロスや遅延があるアクセス回線、混雑時の4G回線に対して、TCP BBRを有効にしたProxyサーバを利用すると、3倍から30倍もスループットが改善されました。

特に、平日昼間のスマホが劇的に快適になり、夜に動画を見てもバッファがなくなりストレスがなくなりました。

bbrの効果を肌で感じるには、カナダの某買い切りVPSをお持ちの方は、そこでbbrを試すとよいです。コンソールがぬるりと動きますよ。

Sign up for free and join this conversation.
Sign Up
If you already have a Qiita account log in.