最新のネットワーキングによるパフォーマンスとセキュリティの向上

こんにちは　ようこそWWDCへ “最新のネットワーキングによる パフォーマンスとセキュリティの向上” 私はジテン・メータです 最高のユーザーエクスペリエンスのため― Appとサーバーにしておくべき重要なことを お話します ネットワーク運用で パフォーマンスを最大化する方法に触れます Appleプラットフォームに搭載された 強固なセキュリティ機能を活用します デバイスがネットワークをまたいで移動する際の 本格的なモビリティ体験の提供と ユーザープライバシーの保護です ご注意いただきたいのは これからお話する内容はテクノロジーが絡むため クライアント端末とサーバーの両方が 対応していなければなりません クライアント側は 既にAppleプラットフォームで 最新のネットワーキングAPIを使っていれば 設定は完了です URL Sessionと Network Frameworkを使っていれば これらのテクノロジーに自動で対応します 早速パフォーマンスから見ていきましょう まず インターネットの最新プロトコルである IPv6は インターネットを支える基本的なプロトコルです Appleのプラットフォームは何年も ネイティブでIPv6対応をしてきました これにはIPv6のみのネットワーク対応も含みます

ネットワーク接続にIPv6を使うと 低遅延であり 一般的に IPv4よりも高パフォーマンスです これは NATが減り 最新のネットワーク機器が多くなるからです

Macのインターネット共有をNAT64対応にし IPv6のみのネットワークで Appの動作確認をすることは App Storeに提出するための要件です 幸い 最新のネットワーキングAPIを使うだけで 動作します インターネット上でのIPv6の利用は 増加傾向にあります 世界中のApple端末による 先月分の接続を見ると IPv6が全体の26%を占めています IPv6で接続できても サーバーが未対応だったケースが20%です IPv6を使用する時の接続確立は中央値で IPv4より1.4倍速いです これはNATが減るのと ルーティングが改善するからです IPv6で改善された点は 皆さんのAppで必ず活用して下さい URL SessionとNetwork Frameworkを使えば すぐに対応できます

私たちの対応は以上です あとは皆さんが サーバーにチェックを入れて下さい 最高のユーザー体験を提供するためにも IPv6の有効化は必ずして下さい 次はURL Sessionです ロードを高速化する HTTP/2対応が実装されています 同一サーバーへの 複数のリクエストを １つのコネクション上で多重化するのです 次のリクエストを送信する際に レスポンスを待つ必要がなく時間が節約できます HTTP/2はConnection Coalescingで パフォーマンスの改善もします システムは同じサーバーで対応できる リクエストを検出し 既存のコネクションを再利用することで コネクション確立の負荷を軽減します ヘッダー圧縮対応で 帯域幅をより活用できます リクエストとレスポンス 両方のヘッダーの 余分なバイトが減るからです HTTP/2が 皆さんのAppにとって どんなメリットがあるかについては WWDC18の“Optimizing Your App for Todays Internet”をご覧下さい SafariでのHTTP利用状況を見ると 先月のリクエストの79%が HTTP/2を使っていました また HTTP/2を使うリクエストが URL Sessionタスクを実行する時間は HTTP/1.1を使うリクエストに比べ 速度が中央値で1.8倍でした クライアント側でURL Sessionを使うと デフォルトでHTTP/2と通信します ただし サーバーで 有効化していなければなりません そのため サーバー設定を確認し 必ずHTTP/2を有効化して下さい

次に ネットワークトランザクションの セキュリティの進化についてです TLS 1.3はTLSの最新かつ最高のバージョンで ハンドシェイク時のパケット往復回数を １回減らすことで接続の確立を速くします 形式検証を行い 構成ミスの可能性を減らすことで セキュリティを向上させます iOS 12とmacOS Mojaveでは TLS 1.3規格の暫定版を有効化し 皆さんのサーバーでテストが可能な プレビュー版を提供しました

現在 この規格は確立されて TLS 1.3は iOS13.4以降 URL SessionとNetwork frameworkに デフォルトで有効化されています 先月は最新のiOSを搭載するデバイスで 全体の接続の約49%が TLS 1.3を使っていました また TLS 1.3を使った接続確立の方が TLS1.2に比べ 速度が1.3倍でした 最新のネットワーキングAPIは サーバーが 有効であればデフォルトでTLS1.3を選びます ですから サーバー側でTLS1.3を有効化して より速くセキュアな体験をして下さい デバイスのネットワーク横断を スムーズにする方法を見てみましょう Multipath TCPは デバイスのネットワークが変わっても Appからの単一のTCP接続を 継続できます これで Appの接続が不安定な時や ユーザーがネットワークに出入りした時でも 接続を最初からやり直す必要はありません

クライアント側でMuiltipath対応に オプトインするには URL Session Configurationで multipathServiceTypeプロパティを設定する またはNetwork frameworkを使用する場合は NWParametersオブジェクトで設定します 弊社のサービスもMultipath TCPで 大成功しています 昨年 私たちはSiriに加えて Apple MusicでもMultipath TCPを 有効化したことを発表しました それ以降 曲が途中で停止する現象は13%減り 停止した場合でも 停止中の時間が 22%短縮されました Appleプラットフォームで簡単に マルチパスプロトコルにオプトインするには 構成またはパラメータ上で multipathServiceTypeプロパティを設定します サーバー側で有効化するには もう少し作業が必要です multipath-tcp.orgにある説明書に従い サーバー上でMultipath TCPを有効化します 次は 同僚のエリックが iOS 14の新たなプライバシー機能を紹介します では また ありがとう iOS 14のユーザープライバシーは ローカルネットワークの 新たな プライバシー保護を入れることで向上します これはAppやサードパーティのライブラリ あるいはSDKが ネットワーク上の他のデバイスの存在を使って ユーザーの位置や身元を特定するのを防止します ローカルネットワークとやりとりをする 内蔵システムサービス 例えば AirPrintやAirPlay HomeKitなどは ネットワークに関する情報は Appに一切渡しません しかし マルチキャストや ブロードキャストの使用など ローカルネットワークのリソースへ 直接アクセスするには ユーザーの明白な許可が必要となりました Appがローカルネットワークを使う理由を ユーザーが理解できるように 目的を示す文字列をAppのInfo.plistの中に 含める必要があります

Appを検証する際の心構えや 強固なプライバシー保護の環境を提供する準備が 整っているか確認する方法については “Support Local Network Privacy in Your App”をご覧下さい また iOS 14とmacOS Big Surの新たな機能は セキュアなドメインの名前解決に対応しています これにはDNS-over-TLSとDNS-over-HTTPSの 両方が含まれます 各Appやブラウザごとに解決サービスを 提供するのではなく システムリゾルバが対応するので 一度セキュアなDNSを設定すれば デバイス上のすべてのAppで使えます NetworkExtentionを使ってAppを書くと DNS通信の暗号化をシステム全体で設定でき 暗号化解決をAppの要件にすることもできます これらのAPIの活用方法の詳細については “Enable Encrypted DNS”をご覧下さい クライアント側でNetworkExtensionを使いAppを 書くと システム全体の暗号化解決の設定ができ DNS-over-HTTPSオプションを提供するよう DNSプロバイダに要請できます 近く登場するテクノロジーに備えられるよう プレビューをお見せします もし DNSの暗号化を有効にし 名前解決を よりプライベートにしても サーバーと行うTLSハンドシェイクのパケットは サーバー名を示す平文またはSNIを含んでいます これはネットワーク上の第三者に 傍受される可能性があります 現在 私たちは第三者がトラフィックを のぞき見できないようIETFと共に TLSハンドシェイクをさらに暗号化する方法の 標準化に取り組んでいます これをDNS暗号化と組み合わせると デバイスとサーバー間のネットワーク通信を プライベートにする大きな１歩になります もう１つは次世代のHTTPである HTTP/3のプレビューです これは トランスポートプロトコルに 新しいQUICを使っています

このトランスポートプロトコルには TLS 1.3のセキュリティ機能が搭載されています HTTP/2と同じく ストリームの多重化に対応しますが Head of Lineブロッキングをさらに減らし 個別のリクエストやレスポンスの損失が 無関係なメッセージを停滞させないようにします

QUICを使用するHTTP/3は 忠実度の高い情報を持ち 改善されたcongestion controlと パケットロスの回復を提供します モビリティにも対応しており ネットワーク間を 移動しても実行中のセッションは途切れず 次のネットワークに スムーズに受け継がれます

IETFによるHTTP/3の仕様策定は まだ完了していません HTTP/3を世界中に展開できるよう 積極的な協力を続けていきます その第一歩として iOS14とmacOS Big Surには 試験的にHTTP/3対応のプレビューが含まれ URL Sessionを使うAppであれば デベロッパ設定で有効化できます

Safariの試験運用の設定でも 同じHTTP/3対応をお試しいただけます 同様にmacOS Big SurでもURL Sessionを使う Appで試験的にHTTP/3対応を有効化できます 方法は CFNetworkHTTP3Overrideを ユーザーデフォルトに設定し デベロップメニューを使って Safariの試験的機能のところで有効化します HTTP/3を試し 見つけたバグを報告して下さい 皆さまのフィードバックをお待ちしています 本日 お話したのはIPv6やHTTP/2 TLS 1.3やMultipath TCP encrypted DNSを活用する方法です この活用で誰もがパフォーマンス　セキュリティ モビリティ　プライバシーの恩恵を享受できます このテクノロジーはAppleプラットフォーム上の 最新のネットワーキングAPIが対応しています 皆さんのAppには URL Sessionや Network frameworkを使うようにして下さい 次に サーバー側がすべて最新状態であることを 確認して下さい これらの機能はリストの右側を埋めることで 有効化できます 最後に 試験的HTTP/3サポートを有効化し 次世代ネットワーキングプロトコルを サーバーで試し フィードバックをお願いします ご清聴ありがとうございました