ここのところ、スマートフォンなどのモバイル端末を利用したインターネットアクセスが、PC利用を上回っています。ニールセンが2015年12月に公開した「Digital Trends 2015」によると、国内のPCからネットを利用した人が昨年9月時点で4753万人となり、2011年8月から少しずつ減少しています。一方のモバイル端末利用者数は同時点で5148万人へと増加しています。

こうした状況では、モバイルアプリケーションの利用がプライベート/ビジネスを問わずに増大するわけですが、アプリケーションのパフォーマンスを管理する立場からすれば、モバイル化は悩みの種でもあります。今回お話するポイントは、ネットワークの「RTT(Round Trip Time:往復の遅延時間)」です。実は、モバイル環境下でアプリケーションのパフォーマンスが悪化する大きな要因に、このRTTが挙げられるのです。

RTTが鍵となる理由は3つ存在します。

第1に、モバイル通信は固定通信と比較して、RTTが大きくなりがちです。2番目は、通信で頻繁に利用されるプロトコル「TCP」が、実際のデータ通信に先立って行われるコネクション確立においてRTTの影響を受けやすいためです。最後の要因は、小さいサイズのデータ送受信をモバイルアプリケーションが頻繁に行うという点です。

これらを総合すると、多くのモバイルアプリケーションは実際のデータ伝送と比較してコネクション確立に要する時間が増えやすく、パフォーマンスに影響しやすいのです。これは、発展が著しいIoT(Internet of Things)の分野でも、同じ問題が生じる可能性があります。センサーなどを搭載した各種デバイスとサーバーの間で、小さなデータが頻繁にやり取りされるからです。

TCPのコネクション確立がRTTに影響を受けるわけ

それではなぜ、TCPのコネクション確立は、RTTの影響を受けやすいのでしょうか。

TCPで通信を開始する際、クライアントから接続要求を意味する「SYN」パケットを送信し、それに対してサーバー側が接続許可を意味する「SYN ACK」パケットを返信します。ここからさらに、クライアントから接続開始を意味する「ACK」パケットを送信することで、ようやくコネクションが確立されます。

このやり取りは「3ウェイ ハンドシェイク(3WHS)」と呼ばれます。この一連の流れによってサーバーはクライアントのIPアドレスが正しいと確認でき、中間のルーターによる再送などで生じた「古くて重複したSYN」を受け取った場合でも、通信の混乱を防ぐことができます。

この3WHSの後、クライアントからサーバー上のアプリケーションに対して初めてリクエストが送られます。つまり、クライアントからアプリケーションにリクエストを送り出すまでに、最低でも1回のRTTが必要になるのです。RTTが大きいモバイル通信環境では、これが時間のロスを生み出してしまうのです。

では、どのように通信を最適化すれば良いのでしょうか?

一つのアイデアとしては、3WHSが終了する前に、クライアントからサーバー上のアプリケーションに対してデータを送付する考え方があります。TCPの仕様上、初めのSYNパケットに何らかのデータを加えることは可能となっています。ただ、ここにセキュリティ懸念が生じます。

というのも、悪意ある攻撃者がソースIPアドレスを偽装した上で、最初のSYNパケットにデータを加えて送付できるのです。そのデータは、3WHSが完了する前にサーバー上のアプリケーションに到達し、サーバー上のリソースを消費します。そのため、偽装されたIPアドレスへ返答してしまう問題が生じます。

その改善策の1つとして、2014年12月にRFC7413として仕様が公開された「TCP Fast Open(TFO)」です。

TCP Fast Openのメカニズム

TFOのメリットは、クライアントの正当性を、IPアドレスそのものではなく、IPアドレスをベースにしたクッキーで確認している点にあります。

TFOは、最初のコネクションでクライアントが「SYN」パケットの中に「TFO Cookie Request」を書き込んで送信します。続いて、サーバーが「SYN ACK」パケットの中に、クライアントのIPアドレスをベースに生成した「TFO Cookie」を書き込んで返信します。クライアントはこのクッキーを保存し、「CONTINUE」を送信します。これでコネクションが確立され、後は通常のTCPと同様にデータを送受信します。

2回目以降のコネクションでは、最初にやり取りした際のクッキーをクライアントの確認に利用します。クライアントは「SYN」パケットに「TFO Cookie」を書き込んで送信し、サーバーがその正当性を確認した上で「SYN ACK」を返すことで、コネクションが確立されます。

ここで重要なポイントは、TCPの仕様で「SYN」の中にユーザー データを入れられるということです。TFOでは実質的に、サーバーが「SYN+TFO Cookie」を受け取って「内容が正当である」と確認した時点で、コネクションを確立します。この時、「SYN+TFO Cookie」にアプリケーションへのリクエストが書き込まれていれば、「その内容をアプリケーションに渡しても構わない」という状態になります。アプリケーションはリクエストに応じた処理を実行して、レスポンスを生成できます。つまりTFOでは、コネクション確立に1回分のRTTを費やすことなく、アプリケーション処理を開始できるのです。

ただし、この効果を享受するには条件を満たす必要があります。それは、クライアントからのリクエストのデータ量がTCPのMSS(Maximum Segment Size:IPフラグメントを発生させずに送信可能なデータ量の最大サイズ)よりも小さいことです。

TCP Fast Openの制約事項と適したアプリケーション

MSSを超えるサイズのリクエストは、最初の「SYN+TFO Cookie」パケットにリクエスト全体が収まりきらず、クライアントはサーバーからの「SYN ACK」パケットを待ってから、続きのデータを送る必要があります。もちろん、サーバー側もリクエストデータがすべて到着するまで、アプリケーションにリクエストを渡すわけにはいきません。そのため、アプリケーションの処理を開始するまでの待ち時間は、通常のTCPとあまり変わらないことになります。

ほかにも、いくつかの制約があります。

まず、通信経路上にNATやファイアウォールが存在する場合は、TFOによる通信が失敗するケースがあります。この場合、通常のハンドシェイクへ自動的に切り替わる(フォールバックする)ため、通信障害の心配はありません。しかし、このフォールバック処理がオーバーヘッドとなり、コネクション確立に余計な時間がかかる恐れがあります。

また、古くて重複したSYNをサーバーが受け取った場合には、アプリケーション レベルで問題となる可能性があります。クライアントが「SYN ACK」を受け取って内容に問題がないと確認する前に、SYNに書き込まれたリクエストへのアプリケーション処理が始まってしまうからです。こうした状況が許されないケースではTFOを使用すべきではありません。例えば、十分に対策していないECサイトでは、受注処理が重複して行われる危険性もあるのです。

多くのモバイルアプリケーションやIoTにおいては、TFOは大きなパフォーマンス向上をもたらす可能性があります。一定の制約があるため、すべてのアプリケーションに適しているとは言えませんが、クライアントから送られるデータ量が小規模な場合、ぜひ検討してみてはいかがでしょうか。

著者プロフィール

伊藤 悠紀夫(いとう ゆきお)
F5ネットワークスジャパン
セールスエンジニアリング本部
プリセールスコンサルタント

UNIXサーバー、ストレージ、シン・クライアントといったインフラエンジニアを経て、F5ネットワークスジャパンへ2012年に入社。
現在はセキュリティ・クラウドをキーワードにイベント講演やハンズオンラボを行い、F5ソリューションの啓蒙活動に奮闘中。
最近はOpenStackやIoTといったキーワードを中心に連携ソリューションを模索している。