第5世代移動通信システムとHTTP通信

## はじめに

第5世代移動通信システム、通称「5G」について面白いスライドが出てたので殴り書き。

5Gは今スマホ等で使われている4G(3.9G)通信の次の世代の通信の話。IEEE802.11aの周波数帯域の話ではないです。
([次世代移動通信「5G」って何？ 2020年の暮らしはどう変わる？](https://kakakumag.com/pc-smartphone/?id=10188)より図を参照)
![5G](https://img1-kakaku.ssl.k-img.com/images/maga/10188/history2.jpg)

5Gでの大容量・高速データ通信が可能な時代になるため、様々なリアルタイムWebサービスが無線通信(スマートフォン)でも展開されていくことが期待されます。

そんな5G通信について、HTTP/2サーバー「H2O」の開発者である奥一穂さんがツイートし、そのリプライで5Gでのネットワーク測定を実施された浅井 智也さんがスライドを共有。

<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">こちらご査収ください。<a href="https://t.co/bq2Bhhp0ZG">https://t.co/bq2Bhhp0ZG</a><br>私なんかより余程詳しい皆さんでこれからどんどんサービスインまでに5Gとうまく付き合っていけるように議論と調査を深めて行っていただきたいです。</p>&mdash; dynamis (でゅなみす) (@dynamitter) <a href="https://twitter.com/dynamitter/status/1066680935263875073?ref_src=twsrc%5Etfw">2018年11月25日</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

こちらのスライドが面白かったので記事にしてみました。元のスライドは[こちら](https://www.slideshare.net/dynamis/httpp-and-5g-fixed1)です。

## ただHTTP/1.1, HTTP/2を使うだけでは、5Gの性能がフル活用できない。

HTTP/2はHTTP1.1の高速化・高品質・高セキュリティ版として登場したHTTP規格です。当然5GでもHTTP/2を使えばHTTP通信が速くなるはず！
しかし実際に5Gでの性能測定を実施した結果、以下のような結果が出たようです。

- HTTP/1.1もHTTP/2も5Gでは期待した性能が出ない。
    - 特にHTTP/2の1 TCPセッションだとHTTP/1.1よりも遅い。
- HTTP/2 over QUIC(HTTP/3)が一番高速

**単純に5Gの帯域を使ったからといって、その性能をフル活用はできない！**
それどころかHTTP/2の方がHTTP1/1よりも遅いケースまであるのが驚き。

### 5Gを活かすには、輻輳対策とHOLブロッキング対策が必要

上記の原因として挙げられているのは以下でした。

- 5Gの帯域をフルに使う前に輻輳扱いされる
- HOL(Head of line) blockingによる影響

#### 輻輳の原因

輻輳とはをざっくり

- 輻輳
    - 通信帯域がいっぱいになっている状態。無線通信では利用しようとしている帯域が目いっぱい利用されていると、データ送信が出来ない。
- 輻輳制御
    - 輻輳が発生した際に**送信速度を落としてデータ送信を行う制御**

というわけで、輻輳が検知されると輻輳制御が発生し速度が落ちます。([簡単な輻輳の説明はこちら](https://wa3.i-3-i.info/word12911.html))

実験の結果では、5GではRTT(ラウンドトリップタイム)が安定しない現象やパケットロスが発生してしており、これらが輻輳と誤検知され速度が遅くなってしまうそうです。

#### 輻輳対策

以下が提示されていました。

- サーバーの輻輳制御を変更する
- RTTが安定するよう無線機側の実装を改良する
    - RTT発生原因はこの調査(2018/11/25)時点では不明。課題

輻輳の検知アルゴリズムについては、スライドではCUBICとBBRという2種類のアルゴリズムが採用されていました。
最大速度はCUBIC > BBR, ばらつきはCUBIC < BBRとのことなので、TCPを使うならどちらを使うのかを用途に合わせて選択する必要があります。
["CUBIC: A new TCP-friendly high-speed TCP variant"を読んだ](https://blog.yuuk.io/entry/cubictcp)
[TCPを高速化する新アルゴリズム「BBR」、Googleが開発](https://tech.nikkeibp.co.jp/it/atcl/idg/14/481542/082500407/?ST=cm-network&P=3)

後者は通信規格や通信事業者レベルの話だと思うので、今後の研究結果に期待！って感じですかね。

後はまとめを見てもHTTP/2 over QUICの利用も有効？QUICも輻輳制御を行っているのでここは関係ない？

#### Head of line blockingの原因

簡単に言うと、「送信データの順番を保証して送信するために送信待ちが発生すること」ってところですかね。
HOL blockingについて
[Head-Of-line blocking(en)](https://en.wikipedia.org/wiki/Head-of-line_blocking)
[Head of Line Blocking - High Performance Web 2015](https://qiita.com/Jxck_/items/0dbdee585db3e21639a8)

以下2つはともに順序が大事となります。HTTP/2はHTTPリクエストをまとめて送信できますが、1セッションの場合はTCPレイヤーでのHOL blockingが発生します。

1. HTTP/1.1でのサーバーへのHTTPリクエスト
2. TCPの送信パケット

結局根っこであるTCPで詰まってしまうから遅延の原因になるという結果ですね。
補足情報: [TCPとUDPの違いを10個挙げてみる](http://d.hatena.ne.jp/ikeas/20100415/1271338590)

#### Head of line blocking対策

- HTTP/2 over QUICを利用する。

※ただし、通信を安定させるための対策は必要

その他、複数TCPセッションを使用して利用帯域を増やすことも有効とのことです。
いずれにせよ5Gを活かすためには何かしらの対策を講じないといけないみたい。

## 5G通信での課題必要な意識・課題

### この検証実験(2018/11/25時点)での未解決問題

- なんでRTTが安定しないの？
- パケットロス問題

### サービス提供者が考慮すること

- サービスに合わせたプロトコル、輻輳制御のサーバーを利用する必要がある
    - 通信速度の最大を取るか、平均を取るか、極端な遅延の無い環境を取るか
        - CUBIC? BBR? UDPのQUIC?
    - HTTP/1.1を取るかHTTP/2を取るかQUICを取るか
        - HTTP/2の場合、速度を重視した複数セッションにするかどうか
            - etc
- パケットロスをケアした設計が必要

## 最後に

**今まで⇒「サーバー側やブラウザが良しなにやってくれていた」**
**これから⇒「特性のある複数のプロトコルから、提供者がサービスに適したものを選択、メンテナンスする」**
という時代に変わっていくのかなという印象でした。

どこまでが本当に自社サービス内で意識することになるのかは、今後の世の中の動向次第だと思います。
ただ2020年以降の5G時代は、自分たちのサービスに合ったHTTP通信を選択する必要がありそうです。

## 参考元

[HTTP and 5G (fixed1)：(記事の元にしたスライド)](https://www.slideshare.net/dynamis/httpp-and-5g-fixed1)