CEDEC 2021 の講演資料です。 ノートに講演で話した内容をそのまま記載ありますので、 講演内容を完全に把握したい方はダウンロードしての閲覧をお勧めします。
株式会社セガ 開発技術部 山田英伸/竹原涼
ダウンロード時間を⼤幅減︕〜⼤量のアセットをさばく⾼速な実装と運⽤事例の共有〜
View Slide
© SEGAゲームコンテンツ＆サービス事業本部 技術本部 開発技術部⽵原 涼⾃⼰紹介【登壇歴】CEDEC 2020 「技術同⼈作家になろう 〜働き⽅改⾰時代におけるエンジニアのレベルアップの⼀例〜」Unite Tokyo 2019 「⼤量のアセットも怖くない︕〜HTTP/2による⾼速な通信の実装例〜」CEDEC 2018、CEDEC 2016、CEDEC 2015 プロダクション関連のラウンドテーブルGDC2016 報告会 「GDC16にみる⾃動化技術とテストのトレンド」祝・HTTP/3 RFC発⾏(間近)︕
© SEGAゲームコンテンツ＆サービス事業本部 技術本部 開発技術部⼭⽥ 英伸⾃⼰紹介【登壇歴】CEDEC 2020「技術同⼈作家になろう〜働き⽅改⾰時代におけるエンジニアのレベルアップの⼀例〜」Unite Tokyo 2019「⼤量のアセットも怖くない〜HTTP/2による⾼速な通信の実装例〜」
© SEGA• 本講演内容の撮影、SNS投稿は OK• 後⽇、CEDIL で資料を公開• 講演中の質疑が可能です。コメントに書き込んでください• 資料に記載されている会社名、システム名、製品名、サービス名は各社の登録商標または商標です• Android ロボットは、Google が作成および提供している作品から複製または変更したものであり、クリエイティブ・コモンズ表⽰ 3.0 ライセンスに記載された条件に従って使⽤しています
© SEGA• CDN に配置したアセットを端末にダウンロード• HTTP/1.1 と HTTP/2 の差に注⽬効果を先にお⾒せします
© SEGA• HTTP/2 なら接続数が少なくても、HTTP/1.1 より圧倒的に早い (待ち時間短縮)HTTP/2による効果プロトコル 速度 完了までの時間 備考HTTP/2 約 280 Mbps 約 3.6 s 1 ConnectionHTTP/1.1 約 110 Mbps 約 9.2 s 6 ConnectionHTTP/1.1 約 59 Mbps 約 17.2 s 3 Connection諸条件Pixel3 (Android10) 使用AWS CloudFront 使用(国内リージョン)総数 2000 ファイル / 1ファイル64KB※ 300-340Mbps が出る回線にて Wi-Fi 接続状態
© SEGA• ゲーム開発者向け HTTP/2 仕様の説明• HTTP/2 を使うための実装について• HTTP/2 導⼊時の勘所• HTTP/2 トラブル集• HTTP/2 の採⽤によるインターネット全体への波及効果• まとめ本講演の流れ
© SEGAゲーム開発者のための HTTP/2
© SEGA• HTTP/2 2015年 標準化完了＆公開– HTTP/1.1 を基本的に継承• 現在の普及率 約45.6% (w3techs.com 2021/06時点)ゲーム開発者のための HTTP/2
© SEGA• 多重化• HPACK• バイナリフレーム(ゲームと関連性の深いものに限定)HTTP/2 の仕様
© SEGAHTTP/2 多重化
© SEGA• 1つのコネクションに複数の HTTP リクエスト多重化 – HTTP/2 の仕様GETGETGETAPP SRVConnectionストリーム
© SEGA• HTTP の Head of Line Blocking:HoLB (HTTP/1.1)– 何らかの要因で先⾏リクエスト処理に時間が掛かると後続のリクエスト処理が遅れてしまうHTTP/1.1の課題 - 多重化 – HTTP/2 の仕様1.png2.png3.pngこの分の遅れが後続に響く1.png
© SEGA• HTTP/2 は HTTP の HoLB を回避– 複数ストリームの多重化により後続のリクエストを並⾏に処理可能多重化でHoLB回避 - 多重化 – HTTP/2 の仕様1.png この分の遅れは他のリクエストに影響しない1.png2.png3.png
© SEGA• HTTP/1.1 と HTTP/2 通信状態の⽐較帯域の利⽤ - 多重化 – HTTP/2 の仕様HTTP/1.1 HTTP/2時間使⽤可能な回線帯域時間HTTP/1.1 は Keep Alive 有効を想定.但しファイルサイズが⼩さいと広帯域を活⽤できない.
© SEGA• HTTP/2 は使える帯域を有効活⽤帯域の利⽤ - 多重化 – HTTP/2 の仕様HTTP/1.1 HTTP/2時間使⽤可能な回線帯域時間帯域を活⽤できていない 多重化で帯域をしっかり活⽤
© SEGAl 細かいアセットダウンロードに有効ü 効率的に回線帯域を使⽤l クライアント・サーバ間通信ü RTT による待ち時間削減(モバイル回線 など)ゲームとの関連 – 多重化 – HTTP/2の仕様RTTRTTAPP SRVSRVAPP1RTT 分で複数リクエストRTTHTTP/1.1HTTP/2
© SEGAHTTP/2 HPACK
© SEGA• HTTP ヘッダを圧縮する仕組み (RFC 7541)• 技術要素ü Huffman codingü Indexing TableuStatic TableuDynamic TableHPACK – HTTP/2 の仕様
© SEGA• 出現頻度の⾼い⽂字に短いビット列を割当てて圧縮Huffman coding - HPACK – HTTP/2 の仕様HTTP/1.1 HTTP/210 BYTESから8 BYTES へ
© SEGA• 出現頻度の⾼い⽂字に短いビット列を割当てて圧縮Huffman coding - HPACK – HTTP/2 の仕様※ < > 内はパディング. オクテット境界に揃える
© SEGA• 出現頻度の⾼い⽂字に短いビット列を割当てて圧縮Huffman coding - HPACK – HTTP/2 の仕様HTTP/1.1 HTTP/259 BYTES 48 BYTES※ 参考値です。実際に送信されるバイト数とは異なります約 81.4% に削減HTTP/263 BYTES
© SEGA• インデックス値を⽤いた圧縮機構– Static Table– Dynamic TableIndexing Table - HPACK – HTTP/2 の仕様
© SEGA• 事前定義されているテーブルのインデックス値を使うStatic Table - Indexing Table - HPACK – HTTP/2 の仕様HTTP/2※ 参考値です。実際に送信されるバイト数とは異なります31 BYTES63 BYTES約 49.2% に削減
© SEGA• 通信に使⽤したデータをテーブルに登録し、テーブルのインデックス値を使うDynamic Table - Indexing Table - HPACK – HTTP/2 の仕様※ 参考値です。実際に送信されるバイト数とは異なります5 BYTES約 8.4% に削減テーブルに登録同内容でリクエスト時
© SEGA• フレーム: ストリーム上を流れる最⼩単位• バイナリデータ送受でテキストより効率が良いバイナリフレーム – HTTP/2の仕様フレームヘッダは 9Bytesフレームの構造
© SEGA• HTTP/1.1 の場合• テキストベースのプロトコル• 解釈の処理で負荷が⾼めゲームとの関連 – HPACK/バイナリフレームHTTP/1.1 200 OKDate: Wed, 30 Jun 2021 02:19:48 GMTContent-Type:image/jpegTransfer-Encoding: chunkedKeep-Alive: timeout=15, max=100Connection: Keep-Alive456Chunk1のデータ ....0: の後に空⽩を許可ヘッダ領域との区切りヘッダ名は⼤⽂字⼩⽂字区別なしChunk終了の CRLFデータサイズはまだ不明
© SEGA• HPACK, バイナリフレームü API 通信のデータ削減・処理負荷軽減ゲームとの関連 – HPACK/バイナリフレームHTTP/1.1 200 OKDate: Wed, 30 Jun 2021 02:19:48 GMTContent-Type:image/jpegTransfer-Encoding: chunkedTrailer: ExpiresKeep-Alive: timeout=15, max=100Connection: Keep-Alive456Chunk1のデータ ....0データサイズは先頭HPACKで圧縮データサイズは先頭
© SEGA• TCP, RUDP を使えば︖– HTTP/2をトランスポートレイヤーに持つgRPC や WebSocket– サーバ設定や導⼊コストの圧縮が⾒込める– 対応したサーバレスコンテナの登場• Cloud Run (Google)閑話 : API 通信に HTTP を⽤いるメリット
© SEGAHTTP/2 を使う実装ClientServerクライアントサーバ
© SEGA• ⾃⼒で全て実装は現実的ではない• ゲームエンジンが内蔵しているもの＆オープンソースの利⽤HTTP/2 を使う実装 Client
© SEGA• C/C++による⾃社製ゲームエンジンやミドルウェアを利⽤ü C/C++製の OSS は選択肢が豊富ü 中でも libcurl, nghttp2 がお勧めケース１ - HTTP/2 を使う実装 Client
© SEGA• Unity を使⽤している場合ü Unityが採⽤している C#ランタイム/クラスライブラリでは HTTP/2 が利⽤できないü 前述のC/C++製OSSを⽤いたネイティブプラグインを実装ケース２ - HTTP/2 を使う実装 Client
© SEGA• Unreal Engine4 を使⽤している場合ü Windows で WinHttp 使⽤時のみ HTTP/2 対応ü C/C++製OSSを⽤いて対処を考えるケース３ - HTTP/2 を使う実装 Client
© SEGA• C#による⾃社ゲームエンジンやミドルウェアを利⽤ü C# 標準 API (HttpClient) が HTTP/2 対応• .NET Framework 4.6• .NET Core は注意. .NET Core 3.0 で対応(*1)ü 但し、パフォーマンスに懸念ケース４ - HTTP/2 を使う実装 Client*1 : https://docs.microsoft.com/ja-jp/dotnet/core/whats-new/dotnet-core-3-0#http2-support
© SEGA• CDN の選定• サーバソフトウェアの選定HTTP/2 を使う実装 Server
© SEGA• 主要なCDNは全て HTTP/2 対応済み︕ü CloudFront (Amazon)ü Cloud CDN (Google)ü Azure CDN (Microsoft Azure)ü Fastly (Fastly)ü Akamai CDN (Akamai)ü CloudFlare (CloudFlare)CDNの選定 - HTTP/2 を使う実装 Server
© SEGA• サーバソフトウェアの選定– 主要なサーバプログラムは全て HTTP/2 対応済み︕• IIS, nginx, apache など– 前段にあるロードバランサに注意 (ADC含む)• HTTP/2を終端する可能性ソフトウェア選定 - HTTP/2 を使う実装 Server
© SEGAHTTP/2 導⼊時の勘所
© SEGA• ダウンロードするデータサイズや順序によっては期待した結果が出ないü ファイルサイズが⼤きいものが⽀配的な場合ü ファイルサイズでソートされている場合パフォーマンスが出ない① Problem!
© SEGA• プロジェクトに有効かをまず判断︕ü ファイルサイズのヒストグラム• ダウンロードリストの作り⽅に⼯夫が必要パフォーマンスが出ない① Solution!私たちが遭遇したので、後で詳しく説明します
© SEGA• コネクション数に応じて、逐次的にリクエスト発⾏をしている場合– HTTP/1.1 を意識した実装の場合、3〜6程度でリクエストを送信となることが多いパフォーマンスが出ない② Problem!
© SEGA• リクエストを束で受け取る設計– 多くのリクエストを同時に発⾏する– ライブラリを作るときに意識するパフォーマンスが出ない② Solution!
© SEGA• リクエスト数が数万になることも︕– ファイル保存時、ファイル I/O のコスト– メモリに展開時、メモリ使⽤量が爆発⼤量リクエストを捌くために Problem!
© SEGAü ファイル保存時、分散書込みなど、負荷軽減策が必要ü メモリに展開時、⼀旦ファイルに保存ü 実装によっては、思わぬボトルネックを⽣むので注意⼤量リクエストを捌くために Solution!私たちが遭遇したので、後で詳しく説明します
© SEGA• HTTP/1.1 時「コネクションエラー=通信エラー」だったが、考え⽅を改める必要ありエラーへの考え⽅ Problem!
© SEGA• HTTP/2 ストリーム単位でのエラーは復帰できる可能性があるü 即、通信エラーにしてはいけないエラーへの考え⽅をアップデート Solution!APP SRVConnection正常なストリームは通信中
© SEGA• 1 Connection内に複数ストリームで通信– ⾼パケロス環境では複数Connection HTTP/1.1 より速度が劣ることもパケットロス率に注意 Problem!APP SRV他のストリームも再送の影響を受けるパケットロスで通信エラーが発⽣
© SEGA• HTTP/2 を悪環境で利⽤時ü ⼀定のパケットロス環境ではHTTP/1.1 にフォールバックする対策ü フォールバックする場合の割合は、各プロジェクトで計測して判断が必要パケットロス率に注意 Solution!
© SEGA• 本番・テストのサーバは対応しているか︖• サーバ側の HTTP/2 機能を有効にし忘れていないか︖• このような事態が発⽣すると、HTTP/2 使っても速くない、と誤解される恐れがあるサーバの対応を確認 Problem!
© SEGA• HTTP/2 の誤った認識をさせないためü HTTP/2 通信できているかのチェックツールを⽤意しておくのも良いサーバの対応を確認 Solution!
© SEGA• 優先度(プライオリティ)の仕様がある• 各ストリームに重みづけや依存関係を設定し、先に欲しいリソースをサーバに通知する仕組みHTTP/2 の優先度設定
© SEGA• ダウンロードの順序制御にHTTP/2 の優先度制御を使うことはできない– CDN 実装の問題で事実上使えない– HTTP として優先度オプションの協議– 現状 RFC 策定されていない優先度制御の課題 Problem!
© SEGA• リクエスト順を制御したい場合には、⾃前で実装するのが無難優先度制御 Solution!
© SEGA• TLS 1.2 以上が必要 (サーバ)– 仕様上 HTTP/2では TLS1.2• AWS ロードバランサ– ALB の https 通信で HTTP/2 が使⽤可能その他
© SEGAHTTP/2 トラブル集CSクライアント事例サーバ事例
© SEGAダウンロード速度が出ない①CSクライアント事例サーバ事例
© SEGA• 通信速度が⼀定を超えるとそれ以上のダウンロード速度にならない問題が発⽣ダウンロード速度が出ない① Problem!C
© SEGA• 受信バッファが満タンになった際に待ちが発⽣ü 送受信処理をメインループに同期させていた為ダウンロード速度が出ない① CauseCHTTP/2ライブラリ受信処理ゲームメインループ同期 同期受信バッファ満タンパケット受け取れないので待つ
© SEGA• 受信を別スレッドに分離し、取りこぼしを抑制ダウンロード速度が出ない① Solution!CHTTP/2ライブラリ受信処理ゲームメインループ取得パケット受信バッファ保存
© SEGAダウンロード速度が出ない②CSクライアント事例サーバ事例
© SEGA• 前項の「通信速度が⼀定を超えるとそれ以上のダウンロード以上にならない問題」が特定の端末でのみ再発ダウンロード速度が出ない② Problem!C
© SEGA• 下位グレードの端末で以下の逆転現象が発⽣ü 通信速度 > ファイルI/O速度• 特にファイル I/O の回数がボトルネックにダウンロード速度が出ない② C Cause
© SEGA• メモリマネージャの実装により解消ü ⼀定のサイズまではメモリに書き溜めておくü 上記サイズを上回った段階でファイルに書き込む• ⼀定のサイズの設定値には注意が必要ü ⼤き過ぎるとこれまたボトルネックにダウンロード速度が出ない② Solution!C
© SEGAダウンロード速度が出ない③CSクライアント事例サーバ事例
© SEGA• 特定のタイトルでダウンロード速度が安定しない問題が発⽣ダウンロード速度が出ない③ Problem!C S
© SEGA• 帯域を使い切ることができないケースがあるü リスト上に⼩さいファイルが固まっている時ダウンロード速度が出ない③ C Cause使⽤可能な回線帯域ここが使えていない︕
© SEGA• ダウンロードリストの作り⽅を⼯夫するü ランダムに⼊れ替えるだけでも効果ありダウンロード速度が出ない③ここの部分を使えるようになったSolution!C
© SEGA• ソートしてもダメなケースダウンロード速度が出ない③ C Cause使⽤可能な回線帯域(⾼速)帯域次第で使い切れないケースが発⽣
© SEGA• ファイルの同時ダウンロード数はサーバ固有ü HTTP/2的にはストリーム最⼤数と表現ü RFC的にはMAX_CONCURRENT_STREAMS• クライアントとサーバで別ü お互い⾃分の受付可能なストリーム最⼤数を送り合うダウンロード速度が出ない③ C S Cause
© SEGA• コネクション数を増やすことにより解決ü 使⽤していたCDNのストリーム最⼤数が変更不可• 最⼤3コネクションまで張る仕様としたü 300〜400ストリームで安定感のある速度になったü 例 : 200Mbps ÷ 384 (stream) → 65kb (1filesize)ダウンロード速度が出ない③ Solution!C
© SEGA主要なCDNのストリーム最⼤数ダウンロード速度が出ない③ AppendixSAmazon CloudFront 128Azure CDN 100Google Cloud CDN 100akamai 128Fastly 100Cloudflare 256実測値 + 一部 https://netsec.ccert.edu.cn/files/papers/ndss-2020-cdn-judo.pdf を参考
© SEGA• .Net 6のHTTP/2の機能でも同様の議論有りü ストリームが上限に達したらコネクションを追加するü https://github.com/dotnet/runtime/issues/35088.Netダウンロード速度が出ない③ AppendixC
© SEGAダウンロード速度が出ない④CSクライアント事例サーバ事例
© SEGA• 特定のタイトルでのみダウンロード速度が極端に低下する問題が発⽣ダウンロード速度が出ない④ Problem!C
© SEGA• ファイル処理負荷が⾼い構成だったü 1ディレクトリ下に⼤量のファイルを保存ü ハッシュ化した⻑めのファイル名を使⽤ダウンロード速度が出ない④ C Cause
© SEGA• ⼀時ファイルの処理を変更して回避ü 専⽤のディレクトリを⽤意ü 短いファイル名(内部的なリクエスト番号)ダウンロード速度が出ない④ Solution!C
© SEGA速度出ない問題との闘いに終⽌符
© SEGAダウンロード速度が出すぎたCSクライアント事例サーバ事例
© SEGA• とあるタイトルの⼤型アップデート時に、CDNのデータ転送レート設定上限値を超える通信量が発⽣することが判明したダウンロード速度が出すぎた Problem!C S
© SEGA• CDNによってはデータ転送レートに制限が掛かっていることがある• Amazon CloudFrontの旧制限は40Gbps (※)ü 200Mbps出る端末の同時ダウンロード可能数Ø 40Gbps ÷ 200Mbps = 200 (端末)ダウンロード速度が出すぎた S Cause※2020/5/20に150Gbpsに更新された
© SEGA• 混雑時間帯のみHTTP/1.1へダウングレード• お⾦で解決するのも⼿ü 制限があるCDNも転送レート上限の引き上げが可能な所がほとんど• CDN選定条件にデータ転送レートも考慮しようダウンロード速度が出すぎた Solution!C
© SEGAファイルオープンエラー発⽣CSクライアント事例サーバ事例
© SEGA• タイトル側でファイル上限エラーが発⽣• HTTP/2ライブラリは以下の80%を上限に使⽤ü Windows (VCRUNTIME) : _getmaxstdioü Android/iOS : /proc/self/limitsファイルオープンエラー発⽣ Problem!C
© SEGA• iOS11でファイルオープン上限数が256に• 結果、タイトル側でファイルリソースが枯渇ü 256 * 0.2 = 51 ファイルファイルオープンエラー発⽣ C Cause
© SEGA• 上限数の変更を⾏う実装に修正ü setrlimit/getrlimitを使⽤• タイトルのファイル使⽤上限を受け取るようにü setrlimit/getrlimitが効かない端末対策• ファイルオープン数の削減ü オープンタイミングの⾒直しファイルオープンエラー発⽣ Solution!C
© SEGAファイルのrenameに失敗CSクライアント事例サーバ事例
© SEGA• 特定の端末でのみダウンロード完了後のファイルのrenameに失敗する問題が発⽣ファイルのrenameに失敗 Problem!C
© SEGA• Android11からExternalStorage境界をまたぐrename(POSIX)呼び出しが禁⽌ü Javaはコピー&削除にフォールバックされる• 以下の境界をまたぐとNGü PublicDirectory(Download), Cache, Files,Files(Download), Mediaファイルのrenameに失敗 C Cause
© SEGA• Android11でも必ず再現する訳ではない• sdcardfs採⽤のカーネルでは発⽣しないü cat /proc/filesystems の結果にsdcardfsがあれば発⽣しないファイルのrenameに失敗 C Cause
© SEGA• ファイルのrenameが失敗する端末ではコピー&削除にフォールバック• renameに⽐べパフォーマンスペナルティありü ExternalStorageの境界を跨がない設計をお勧めファイルのrenameに失敗 Solution!C S
© SEGAタイムアウトしないCSクライアント事例サーバ事例
© SEGA• データを全くダウンロードできないにも関わらず、タイムアウトが発⽣しない問題が発⽣タイムアウトしない Problem!C S
© SEGA• HTTP/2特有のコネクションクローズ問題ü コネクション切断時に送信されるGOAWAYフレームがロストしたことが原因と推測• 複数のストリームが⾮同期に絡むのでHTTP/2のコネクションクローズの実装は複雑となりがちタイムアウトしない C S Cause
© SEGA• 独⾃のタイムアウト処理を追加したü タイムアウト判定時にはハンドシェイクからやり直し• graceful shutdownに対応したサーバやライブラリを使っていれば不要ü サーバ側が担保できなかったので独⾃に実装タイムアウトしない Solution!C S
© SEGAiPhoneで通信中に不正終了CSクライアント事例サーバ事例
© SEGA• ダウンロード中に極稀に不正終了が発⽣ü 検証環境では7万回に⼀回程度発⽣iPhoneで通信中に不正終了 Problem!C
© SEGA• 利⽤しているOSSの不具合だったü HTTP/2のconnection reuse発⽣時に加えていくつかの条件を満たした時のみ発⽣ü 数千〜数万ファイルを⼀気にダウンロードするのはゲームくらいなのでレアなものを踏むiPhoneで通信中に不正終了 C Cause
© SEGA• その後OSSの更新で無事に修正された• HTTP/2のゲーム活⽤も枯れてきているü 他社の⼤型タイトルでも採⽤が増えてきたiPhoneで通信中に不正終了 Solution!C
© SEGAHTTP/2独⾃の設定をしたいCSクライアント事例サーバ事例
© SEGA• 5G時代に備え、もっと速度を……︕ü HTTP/2独⾃の設定をカスタマイズすればいけそう︖• 設定例ü HPACK Dynamic Table設定ü ストリームの初期ウィンドウサイズHTTP/2独⾃の設定をしたい Problem!C S
© SEGA• 諦めたü 利⽤しているOSSは設定を内部パラメータとして隠蔽ü CDNも設定できない場合が多い• OSS選定のタイミングで考慮しておこうHTTP/2独⾃の設定をしたい Solution!C S
© SEGAインターネット全体への波及効果
© SEGAインターネット全体への波及効果コネクション数削減による効果
© SEGAゲームはコネクションを多数⽤いるアセットダウンロードランキングゲーム通信チャット
© SEGA• コネクション数の増加はそのままインターネット上に存在する中継器の負荷増⼤に繋がるコネクション数による負荷増⼤
© SEGA• ⽇本をはじめ全世界に余裕がない状態インターネットは社会全体の資源総務省 :我が国のインターネットにおけるトラヒックの集計・試算 2020年11⽉分の集計結果 より
© SEGA• HTTP/2であれば従来に⽐べてコネクション数を⼤幅に削減可能ü 多重化ü コネクションの再利⽤HTTP/2によるコネクション数削減
© SEGA• Webブラウザや動画ストリーミングサービス等の⾮ゲーム分野ではコネクション数は減少傾向⾮ゲーム分野では既に導⼊が進んでいるWeb Almanac 2020 HTTP/2 - HTTP/2のインパクト より
© SEGAHTTP/2のゲームへの導⼊のメリット開発者 ユーザ体験の向上(離脱率低下)ユーザ ダウンロード待ち短縮インターネット 負荷軽減
© SEGAコネクション数削減による効果HTTP/2を使って開発者、ユーザ、インターネットに優しいゲーム作りを⽬指そう︕︕
© SEGAインターネット全体への波及効果ゲームのデータ配信とトラフィック
© SEGA• AAAタイトルの発売⽇や⼤型アップデートの⽇にインターネットトラフィックが⾮常に混雑するというのが最近問題になっているü CEDEC 2020 [JANOG×CEDECコラボセッション]インターネットとゲームトラフィック でも話題にゲームのデータ配信の影響
© SEGA• ゲーム業界はインターネットを使わせてもらっている⽴場ü 少しでもインフラへの負荷を減らすべき• 必要になったタイミングで都度ダウンロードü モバイルゲームでは採⽤しているタイトルも多いü ⾮モバイルゲームは⼤型パッチが主流データ配信⽅式の転換の提案
© SEGA• ゲームの適正とよく相談する必要はあるü ジャンルü プラットフォーム• 採⽤メリットもü 従来に⽐べ管理や差し替えが容易になるパッチ配信とトラフィック
© SEGAまとめ
© SEGA• HTTP/2はアセットダウンロードに効果⼤• HTTP/2はクライアントサーバ間の通信の効率化にも効果⼤• HTTP/2はインターネットにも優しいHTTP/2を使おう︕︕
© SEGAご清聴ありがとうございました
segadevtech
ojun9
assu_ming
ryounasso
kinocoboy2
antyadev
qnighy
twada
parttimenerd
codehex
hiroyaonoe
zakky21
ivargrimstad
holman
davidbonilla
palkan
danielanewman
jennybc
destraynor
matthewcrist
bcantrill
lauravandoore
lemiorhan
addyosmani
ammeep