現代のインターネットに合わせてAppを最適化する

(音楽)

(拍手) おはようございます 今回 初めてWWDCに 参加される方は？

毎年 新たな参加者が増えて うれしいです 私 スチュアートが ネットワークの話をします まずはアプリケーションの 動作に関わるトピックです ネットワークを使わないAppは ほぼ存在しないので 最高のパフォーマンスを 引き出すことが重要です そのための技術を いくつかご紹介します AppleのAPIを 有効活用するための― 秘訣についても 皆さんにお教えします そして後半は 私の同僚のジテンが― URLSessionの詳細について ご紹介します

まずは最新の ネットワークについてです インターネット利用者数は いまや40億人まで増えました これは世界人口の半数以上で― ネットの使用量も 増え続けています ネット利用者数の増加率は 緩やかになりましたが インターネットの成長率は 降下してはいません M2MやIoT スマートホームなどで 進化を続けています インドや 中国の人々の間では― デスクトップ型パソコンが あまり普及していません 彼らはスマートフォンを メインで使用しており― その通信規格は 2Gのままなのです この会場の皆さんが生み出す アプリケーションは― ほとんどがLTEを想定した 仕様のはずです これは私たちにとって 不利な事実です LTE向けの アプリケーションは― 2Gでの操作性が 非常に悪いからです 2Gでのパフォーマンスが 良いアプリケーションは― LTEだと最高の操作性です そこで速度の遅い環境の プロパティを再現する― Network Link Conditionerを ご紹介いたします このNLCを 必ず実行しながら― アプリケーションの 開発を進めてください アプリケーションが 完成した後では手遅れです プログラミングに ミスがあっても― 開発途中なら すぐに修正ができるからです Wiresharkやtcptraceを 使うことで操作性や― メモリとCPUの使用量を 確認できます tcptraceは このようなグラフで― ネットワークの状況を ひと目で確認できます 詳しくは３年前の セッションをご覧ください

IPv6の使用量が 増え続けている理由は― IPv4より良い 性能を発揮するからです アプリケーションの 操作性には― ネイティブ方式のIPv6に 対応しているかも重要です IPv6が推奨されている 地域は多く― アメリカでも87％の携帯が IPv6向けです ほぼ同じ状況である インドに焦点を当ててみます これは今年の初めに調査した ネットワークのデータです インドの 携帯ネットワークで― TCP接続にかかる時間と その往復遅延時間を表しています 青い線がIPv6です 例として75％の部分を 見てみましょう IPv6によるTCP接続の 75％が― 0.15秒以下であることを 意味します 一方 IPv4での接続時間は 0.325秒以上で― ２倍以上の遅さです もしアプリケーションの 操作性を高めるなら― IPv6に対応してください

他にもExplicit Congestion Notificationで パケットロスや再送信を減らし 操作性を高められます macOSやiOSには― 数年前から実装されています 特別な作業は不要ですが― ネットワークは ECN対応にしてください Alexaで上位100万件の Webサイトを調べると― そのうち77％が ECN対応のサイトでした 数年前より激増しています

その他 操作性と レジリエンス向上に有効なのが Multipath TCPです オフィスでWi-Fiが つながっていても― 屋外では 途切れることがあります その場合 従来のTCPは 再接続が必要でした Multipath TCPは経路を パケットごとに決めるため― 異なるインターフェイスへ 接続できるのです

詳しくは昨年のセッションを ご覧ください そして お使いのサーバが マルチパス対応かもご確認を 世界中の携帯キャリアを 調査した結果― 78％がMultipath TCPを 利用したネットワークでした 未対応のままなのは たった22％です

TCP Fast Openは― TCPの往復遅延を 改善してくれる技術です TCP接続確立パケットに― 初回のデータを含めることが 可能になります

詳細は３年前の セッションをご覧ください そして お使いのサーバが― TCP Fast Open対応か ご確認ください 次は新しい情報です QUICという技術を ご存知の方もいるでしょう ここ30年来で 初めて開発された― TCPに代わる 新しいプロトコルです Googleの エンジニアが開発し― その成果も検証済みです 現在はIETFによって― QUICの標準化が 検討されています Appleのエンジニアも― スウェーデンで開催中の 会議に参加しています

標準化はまだ先の話ですが 我々は準備を進めています 準備が整い次第 我々のAPIも対応します

他にも操作性の観点から― よくある事象に気づきました ウェブサイトで使われる DNSレコードは― 持続時間が短いものばかりです それは データセンターが ダウンした際に― DNSを更新し 別のセンターに 迅速にアクセスするためです しかし コストをかけて この対策を行っても― センターは めったにダウンしません そのためDNSレコードが 期限切れになるたびに サーバからの応答を 待たねばならず 余分な往復遅延時間が かかることになります では 私たちにできる 最適な方法は何なのか？ それをご説明しましょう 例えばキャッシュに 古い情報があった場合― すぐさま同時進行で DNSクエリを実行します DNSの情報を照会するのです 予想どおりの 応答が得られれば― そのまま接続ができ データ往復の時間が省けます 違うアドレスで応答があると 非同期通知が送られ― 新たなアドレスで 再接続を行います Happy Eyeballsと 連動させることで― 並列的な接続が可能です IPv6 IPv4 複数のアドレスや インターフェイスを試します 皆さんがお考えのとおり これは大変な作業です この作業を簡単に行える 新たなAPIについて― 後ほどご紹介いたします

次はガイダンスです SCNetwork Reachabilityで― 事前チェックを行う デベロッパも多いでしょう ネットワークの運用が― うまくいくかどうかを 確認するためです しかし先のことを 予見するのは大変です 今はうまく接続しても― ２秒後にはWi-Fiの電波が 途切れるかもしれません 運用が成功する保証は どこにもないのです 運用がうまくいくまで 失敗を繰り返すのも― 日常茶飯事です ネットワークプロキシの 設定も― とても複雑で 負担の大きい作業です その悩みを解決しましょう

waitsForConnectivityで 作業負荷を減らせます 詳細は昨年のセッションを ご覧ください このシステムに 接続を要請するだけです タイミングは問いません デバイスが機内モードの場合 設定を解除すれば接続されます リトライ処理を行うより はるかに簡単です ユーザに多数の質問に 回答してもらう際― 有効であるという 開発時のケースがあります 処理が失敗しても ユーザの 時間を無駄にしたくないですね 休憩後のセッションで 詳細をお伝えします 改善策をお知らせします

セキュリティ面も重要です

TLS1.2が普及して 10年が経ちました より安全性の高い TLS 1.3への移行準備が― すでに始まっています TLS 1.3は 接続時間も短く済みます 標準規格化に向けて 最終調整をしており― 公表文書の最終稿も IESGに認証されました RFCエディタより 正式文書が刊行されたら― 初期設定をTLS 1.3に 切り替える予定です 今すぐにTLS 1.3を 試したい方は― iOSやmacOSの説明書を ご参照ください アプリケーションを TLS 1.3規格に更新できます 規格がデフォルトになった時点で 互換性の問題が発覚しないよう なるべく早めにお試しください 切り替え時期が来る前に 動作確認を終えてください

Certificate Transparencyも セキュリティ対策の１つです 悪意からか無能ゆえか 認証局が不正な証明書を 適切でない相手に 発行する場合があります この解決策が “証明書の透明性ログ”です 認証局が発行した すべての証明書に― 証跡が残るのです その証跡は第三者の 監査ログに記載されます ポリシー外の認証局から 不正に発行された証明書は すぐに検知されます

証明書が未発行の場合も 同様です なじみのある セットアップですね 新しいのはログです 認証局が 証明書を発行すると― 監査ログに その証跡が記録されます サーバは接続時に ログから取得した証跡を― クライアントに提示します クライアントは その証明書が― 公的に記録され 署名されたと確認できます このポリシー外の認証局が― 不正な証明書を 発行したと想定します クライアントは ログを確認することで― この証明書が不正だと 検知できます

私たちは今年の終わりに―

新たなTLS証明書を 発行します ログの検証による― 不正な証明書の検知も 可能です アプリケーションの改訂は 要りません 独自のサーバ証明書を お持ちの場合は― 適切にログが記載されるか ご確認ください

ハードウェアについても お知らせがあります Bonjour Conformance Testで― Bonjourが適切に 実装されているかが分ります Bonjourの商標を使う際は ぜひ試してください Windowsのアプリケーションに Bonjourを実装する際も同様です AirPrintやAirPlayなどの商標を 商品に使用する際も このテストが必須です Bonjourの信頼性の高さが― その商品の根幹になるからです そしてテストで さらに重要なのは― 皆さんの商品の質を 高めるということです それが顧客の満足に つながり― 皆さんの幸せにつながります 顧客が信頼できる商品と 快適に暮らせることが 私たちの望みです

次はAPIの話です 30年前はBSDソケットが 一般的でした 当時にしては優れものです しかし30年前には 携帯端末はもちろん― ワイヤレス接続や IPv6もありませんでした

PCの複数台接続や― イーサネットのポートがある PCも珍しかったのです いまや40億人もの人々が 電源管理を行いつつ IPv6対応のモバイル端末を 持ち歩く時代です 世界は複雑化しています

ソケット通信のサービスを お使いの方もいれば― URLSessionを お使いの方もいるでしょう URLSessionはソケット通信と 大差ないと思いますか？ それは間違いです URLSessionはAppleの ユーザ空間を使って― 設計されています iOS 12からは― URLSessionと同じ APIが使用されます お持ちの アプリケーションから― TCP接続などのため 直接使用可能です URLやGETメソッドを使ってる方は ご検討ください URLSession非対応の アプリケーション用に― フレームワークも 公開しています BSDソケットで設計された ライブラリを― 開発されている方も いるでしょう その場合はNetwork.framework APIを使ってください ライブラリを高性能な APIに移行いただき― ぜひフィードバックを お寄せください 2018年は BSDソケットの利用を― やめることを 強くおすすめします BSDソケット系統の ライブラリも同様です そして古いAPIをお使いの方も 切り替えをご検討ください 今日の午後もしくは明日 我々のラボで― 移行に関するフィードバックを お待ちしています 次は同僚のジテンが― URLSessionの詳細を ご説明します (拍手) ありがとう おはようございます CFNetworkのエンジニア ジテンです 今日は皆さんに最適な ネットワークをご紹介します アプリケーションに ネットワークは不可欠です 新たな開発に 尽力されている皆さんに― ネットワークの詳細を 簡単にお話しします きっと役立つはずです

これから 待機時間の削減 処理量や反応性の向上 システムリソースの 有効活用といった― ４つの項目について話します

その前に簡単に URLSessionのおさらいです

URLSessionはApple推奨の 高性能APIで― Appleのプラットフォームで 利用可能です 第一推奨の利用環境は HTTP/2と― HTTP/1.1です

アプリケーションが HTTP非対応の場合は― URLSessionStreamTaskをどうぞ そうすれば 任意のプロトコルで― サーバへの TCP接続が可能になります

おさらいは以上です では 待機時間の削減の トピックに移りましょう あなたは友人と レストランを訪れ― 店員に水を頼んだとします 店員があなたに 水を持ってきたところで― 友人も水を頼みました 店員は再び歩きさり 友人に水を持ってきました 店員が水を一度に 持ってくれば― 往復時間が省けるはずです リソース取得までの― 往復時間を減らす場合も 考え方は同様です アプリケーションの動きは？

このプロトコルは HTTP/1.1です リソースを取得するため― URLSessionで タスクを開始します するとDNSやTCP TLSを含んだ― 新たな接続が作成されます

サーバに接続したら リクエストを送り―

サーバからの応答を待ちます この間 アプリケーションに 待機時間が発生するのです

応答が得られたら 終了ブロックか― デリゲートで ロードを終了させます

ロード中に別のリソースを 取得することも可能です

その場合はURLSessionで 別のタスクを作成し― 接続プールに ムダな接続がない状態で リソース取得のために 新たに接続します

さらに他のリソースを 取得したい場合も同様に― URLSessionで 別のタスクを作成します

ここでは同じサーバから ３つの接続で 異なるリソースを取得しています

初回の接続には 時間を要しましたが― これが単一接続だったら どうでしょう

単一接続の場合です 初回の接続時間は短いですが 別の問題があります ２つ目の緑色のタスクは― 最初のタスクの完了まで 待機が必要です ３つ目の オレンジ色のタスクも― ２つ目のタスクが終わるまで 待機が必要です

これがヘッドオブ ラインブロッキングです

実は新規格のHTTP/2も 単一接続を行いますが― この問題への 回避策が備わっています

HTTP/2は１つの接続上で ストリームを多重化し― 複数の送受信を 並列的に行えるのです

HTTP/2がHTTP/1.1より 優れていることを― 例を見て分析しましょう

複数のリソースを 取得するまでの― 所要時間に注目してください HTTP/1.1では 明らかな遅延が リソース取得のリクエストが 送られるまでに発生しています

一方のHTTP/2は― 遅れが少なく 迅速に― リクエストが送られています

グレーの部分にも 注目してください 先ほどお話ししたとおり― サーバからの応答を待つ 待機時間が生じてしまいます

HTTP/2では この待機時間が削減され― バンド幅を有効に使い 迅速なロードが可能になるのです

HTTP/2がHTTP/1.1より 優れている点を― 簡単におさらいします HTTP/2はヘッドオブライン ブロッキングを解消し― バンド幅を有効利用できます すでにURLSessionを お使いの方は― そのままの状態で HTTP/2の恩恵を受けられます

HTTP/2はサーバへの 接続回数も少ないので― サーバ側の負担が軽く済む メリットもあります

今年からURLSessionに― HTTP/2の強みを生かす 技術が加わります

HTTP/2 Connection Coalescingについて― ご紹介します

この技術のおかげで― より強力な接続が 可能になります

毎回 接続をオープンにする やり取りが不要なため― さらに反応が速くなるのです

HTTP/2 Connection Coalescingは

URLSessionに対応した アプリケーションでは 自動適用されます

接続の再利用方法を 見てみましょう

アプリケーションが― リソースの取得を 要求したとします サーバへ接続をすると 証明書が発行されました さらに他のリソースを 取得する場合は― 別の接続をオープンにし 新たな証明書が発行されます これは従来の URLSessionで― 複数のリソースを取得する 手順と同じです

しかし よく見ると 最初の証明書によって― すべてのサブドメインが 網羅されています delivery.example.comに 最初の証明書が 適用されているのです さらに最初の接続と同じ IPアドレスで― 処理されていることも 分かります

同一のエンドポイントが 接続を再利用しているので 安全です 新たな接続のオープンが 不要なため― 待機時間が 大幅に短縮されるのです

HTTP/2 Connection Coalescingは― iOS 12とmacOS Mojaveに 搭載されています

URLSessionの オブジェクトによる― 処理速度を見てみます

先ほどご紹介した 接続の恩恵を受けるには― 同じURLSessionを 利用する必要があります

URLSessionは 接続プールが可能なので オブジェクトを複数作成すると メリットは感じられません また自明でない メモリフットプリントを― URLSessionで作成すると コストがかかります そのためURLSessionの オブジェクトは― 少ないほうが良いのです

次は処理量の向上について お話しします

レストランで― こう注文したとします “グリルチキンと トマトとタマネギに―” “バターたっぷりの ソースを添えて” 言いにくいですね “バターチキン”と 注文すれば十分です

リソース取得時の 送信バイトを減らし― 処理量を 向上させるのも同様です 実際にお見せします

リクエストのサイズを 減らす方法です

HTTP cookieに 注目してください cookieは すべての リクエストにおいて― ドメインとパス属性で ひも付けられています サイズが膨大になる原因です ドメインとパス属性を 効果的に使えば― cookieとリクエストが 適切に照合されます 小さいcookieを使い 適宜 削除すれば―

クライアント側のcookieの数を 減らすことができます

HTTP/2に移行すれば ヘッダ圧縮も可能です

圧縮について 詳しく説明します

HTTP圧縮はサーバと クライアント間で― 行き交うデータを 圧縮する手法です これにより 情報量が増加します URLSessionでは― GzipとBrotliを 推奨しています Gzipは汎用性が高く 処理速度も速いです Brotliは昨年 iOS 11と― macOS High Sierraで 導入されました 構造化テキストや HTMLなどの― 小さなデータの圧縮に Brotliは最適です

ぜひ この圧縮方法を サーバに適用ください

次にご紹介する項目は― 反応性の向上についてです 再びレストランに戻ります あなたはWWDCで 旧友と再会する予定です ２人はテーブルに 座っていて― ドリンクは すでに手元にあります 食事前に旧友と 近況報告をするため― あなたは店員に言います “食事はゆっくり 出してもらえますか？” 別タスクの実行中に― 特定のタスクを 優先させる場合も同様です 実際に見てみましょう

５つのQoSと NSOperationが― 関連しているのは ご存じだと思います スケジューリングポリシーに 沿っています

URLSessionは “QoS-aware”で task.resumeを呼ぶキューで QoSをキャプチャします 送られるメッセージは QoSを優先します

例を見ましょう 緊急でないデータを 取得する場合― バックグラウンドの QoSが働きます 優先度の高いタスクを 妨げないように― 処理してくれるのです

URLSessionの オブジェクトによって― ネットワークトラフィックが 分類され タスクに優先順位が つけられるのです

“responsiveData”を 今年から導入します defaultTypeより高度なので 上手に活用しましょう responsiveDataは 通販サイトで清算する時にも 便利です 支払い請求書の情報を― すぐにサーバから 呼び出す時などに便利です

Ciscoのファストレーンを 使うことで― 記録されたタグを いつでも呼び出せます このAPIの詳細は― 2016年のWWDCのセッションで ご確認ください

昨年 URLSessionのAPIで 導入したのが― waitsForConnectivityです タスクの実行中に 接続が切れても― タスクを待機させてくれます 従来 リクエストの 事前チェックには― STNetworkReachabilityが 主流でした しかしスチュアートが 指摘したとおり サーバの接続中に タスクが競合しがちです いざリクエストを 実行すると― 接続が切れてることも あります

waitsFor Connectivityを使えば― 有効なサーバに すぐリクエストを送れます また taskIsWaitingFor Connectivityのメソッドを 接続がない状態で 呼び出せます このためユーザは 違う操作をしたり― UIをオフラインに することができます

このAPIの詳細は― 昨年のWWDCの内容を ご参照ください

最後の項目は― システムリソースの 有効活用です 再びレストランの例です

あなたは料理が気に入り 明日も来たくなりました しかし このレストランは 宅配も行っており― 注文した翌日に 料理を届けてくれます 顧客の時間と労力が 宅配によって節約され― 店側も仕事の優先順位が つけられます システムリソースの 有効活用も同じ考えです

バックグラウンドで― アップロードと ダウンロードをします システムが状況に応じて― ロードの中断や 再開をしてくれます バッテリーやCPU Wi-Fi環境で判断するのです

バックグラウンド セッションは― 大容量データに有効です これらのタスクは プロセス外で実行され アプリケーションが停止中も ダウンロードが続きます

本件に関する詳細は― 2014年のセッションを ご参照ください

キャッシュで待機時間は 削減されます しかしディスクI/Oでしか 効果を発揮できません 現実世界のアプリケーションは 日々 大容量のデータを扱い フラッシュストレージが 劣化します

固有のコンテンツに キャッシュは不向きなのです あなたが マッチングアプリの― ネットワークコードの 責任者だとします ユーザのプロフィールを 高画質でロードします この高画質な画像の 読み込みに― キャッシュを用いるのは ムダです ユーザは いろんな人の画像を― 次々と閲覧していくからです

willCacheResponseを 実装すれば― キャッシュするリソースを 判断してくれます

自身のサーバをお持ちなら Cache-Controlヘッダを ぜひ お試しください

今日のポイントを おさらいします レストランでは 一度に全部の注文をする 今のは冗談です HTTP/2は ヘッダを圧縮したり― ヘッドオブライン ブロッキングを解消できます

URLSessionの オブジェクトを減らせば― 待機時間を減らせます メモリフットプリントも削減し リソースの活用がより効率的に

リクエストのサイズ削減で 処理速度を最大にします

QoSでアプリケーションの 反応性も向上します システムリソースの 有効活用の鍵は― バックグラウンドセッションです

詳しい情報は ウェブサイトをご覧ください 少し休憩をはさんだ後に― ソケットの代わりとなる 新たなフレームワークを紹介します 我々のラボにも ぜひお立ち寄りください

皆さんの ご参加に感謝します (拍手)