cidermitainaスマートフォン用の表示で見るcidermitainaフロントエンドエンジニアをやっています。頑張るから読んでほしい。2019-04-20ハイパフォーマンスブラウザネットワーキングを読みました(HTTP)プログラミング最近ハイパフォーマンスブラウザネットワーキングの10章~12章を読んだのでまとめました。どんな本?ブラウザに関連する、インターネットで使用される様々なネットワーク技術をまとめたものハイパフォーマンスを誇るアプリケーションを構築するためには、なぜネットワークがそのような挙動を見せるのか理解する必要がある「良い開発者はどのように動作するか知っている。素晴らしい開発者はなぜ動作するかを知っている」Webアプリケーションを提供するには、ブラウザとネットワークの動作の関連性について、硬い基盤となる知識が必要とされるゴールはネットワークについてすべての開発者が知っておくべきすべてを説明することどのようなプロトコルが用いられてる?どのような制限を持つ?アプリケーションをその基盤ネットワークに対して最適化する方法はどのようなもの?ブラウザにが提供するネットワーク機能とその使いどころは?目的ハイパフォーマンスを誇るアプリケーションを構築するために、なぜネットワークがこのような挙動なのかを理解し、理由が述べられるようになる。(なりたい...)とりあえず10章~12章に絞って読みました。パフォーマンス入門パフォーマンス最適化のプロセスの大部分は、システム内で明確に分離している。制限と制約を持った各レイヤーの間に存在する相互作用を理解し紐解くこと。すべての異なるレイヤーの相互作用を最適化すること?相互依存しているいくつかの方程式を説いて回答を導き出すことではなく、場合によって多数の解が存在する。それぞれのパフォーマンスのベストプラクティスを数値化・分析する前に一歩下がって、問題そのものを定義しておくことが重要。モダンWebアプリケーションとは?どのようなツールが利用可能なのか?Webアプリケーションをどのように計測するのか?などモダンWebアプリケーションの解剖学モダンWebアプリケーションとは?以下のサイトが参考になる。主要Webサイトのコンテンツを自動分析してレポートしている。https://httparchive.org/reports/state-of-the-webwebアプリケーションにはインストールプロセスがない。URLを入力し、enterキーを押すだけで使える状態になる最高のweb体験提供するには、数百のリソース、数MBのデータ、いくつもの異なるホスト。これらすべてを数百ミリ秒以内に。生活のペースが歴史上一番早くなっている。かかわらず、反応時間は常に一定。アプリケーションが瞬時に反応したと感じさせられるためには、ユーザの入力に対して知覚できるレスポンスを数百ミリ秒のうちに提供しなければならない。一般的なWebページのリクエストにかかるDNSルックアップ、TCPハンドシェイク、Webページリクエストに通常かかるいくつかのパケット往復時間を合計してみる100-1000ミリ秒というレイテンシの予算はネットワークオーバーヘッドだけで、すべてではないにせよ、その大半が簡単に消化せれてしまう。リソースのウォーターフォールチャートを分析するWebパフォーマンスの議論はリソースのウォーターフォールチャートに言及するまで完結しない。増減を表すのに便利なグラフWebPageTestを使って診断する。データ転送における指標のひとつで、転送要求を出してから実際にデータが送られてくるまでに生じる、通信の遅延時間のことをいいます。この遅延時間が短いことをレイテンシが小さい(低い)、遅延時間が長いことをレイテンシが大きい(高い)と表現しています。通信相手に信号やデータを発信してから、応答が帰ってくるまでにかかる時間。ブラウザ最適化パフォーマンスはブラウザベンダにおける最も重要な競争力の要素であり、ネットワークパフォーマンスがその重要な基準であれば、ブラウザが日々進化していることに驚くべきことではない。外部URLからリソースを取得する要素がある場合、ブラウザはdocumentの上部から解釈し、外部URLを見つけた時点で外部URLへリクエストを送ります。href="/css/style.css">重要度は高いがページの後ろで読み込まれるリソースの優先プリフェッチsubresourceは同一ページ内で使用する任意のリソースを裏で読み込んでおくことができる。href="//example.com/future-image.jpg">リソースのプリフェッチユーザーが次に訪問する可能性が高いページを開発者がわかっている場合、リソースを前もって取得しておくことができる。JSやCSSなどキャッシュ可能なリソースに限られる。href="//example.com/future-page.html">指定ページのプリレンダリング指定したページのCSSを読み込み、JSを実行、ページ全体の不可視バージョンを作成する。10章まとめDNS、TCP、SSLの遅延はほとんどのユーザと、Web開発者にはまったく透過的で、ネットワーク層で処理される。本来はこのような最適化を気にすべきではないキープアライブ接続の利点HTTP1.1の主要なパフォーマンス向上の一つが持続的接続な接続、または、キープアライブ接続の採用なぜこの機能がパフォーマンス戦略における重要な要素なのか?キープアライブ一つのTCP接続を一回のHTTP通信で切断せず、複数のHTTPリクエスト/レスポンスを送受信するよう維持する機能。キープアライブなしでは、それぞれのリクエストが2往復分のレイテンシを発生させるキープアライブを有効にすると、最初のリクエストは2往復分、そしてそれ以降のリクエストは一往復分のレイテンシを発生させる言うまでもなく、すべてのアプリケーションにとって持続的なHTTP接続は重要な最適化HTTPパイプラインHTTPパイプライン一つのTCPコネクション上で、複数のHTTPリクエストを応答を待つことなく送信する技術である。リクエストをパイプライン化することにより、ウェブページの読み込みが大幅に高速化される。リクエストを早いうちに送信しておくことによって、それぞれのレスポンスをブロックすることなくもう一往復分のネットワークレイテンシを削減できるしかし、HTTP1.1では多重化送信がサポートされていいないため、パイプラインはHTTPサーバや中間装置、そしてクライアントに様々な微妙かつドキュメント化されていない影響を及ぼす参考しかし、パイプラインはサーバー側できちんとした対応がされていないと、ブラウザ側のリクエストを正しく処理できないということになり実装にも課題がありました。HTTPパイプラインには「サーバーはリクエストの順番通りにレスポンスを返さなければならない」という制限があります。5個あるリクエストのうち1番目のリクエスト処理が遅い場合、2個目以降のレスポンスは待ち状態(ヘッドオブラインブロッキング)になり結果全体の速度が遅くなるといった課題がある。このような状況から、パイプラインはOPERAブラウザを除きほとんどのモダンブラウザはデフォルトでOFFになっており、残念ながらほとんど利用されていないのが現状。遅いレスポンスが一つ存在すると、その後のすべてのリクエストがブロックされる並列処理を行う際、サーバはパイプライン化されたレスポンスをバッファリングする必要があり、サーバのリソースを圧縮する可能性がある。レスポンスに失敗するとTCP接続が終了する場合があり、クライアントは未処理リクエストを再送して重複処理になる可能性がある中間装置が存在する可能性がある場合、パイプラインの互換性を信頼できる形で検出することは難しい。↑のような複雑さと、発生する問題に対する指針がHTTP1.1標準で示されてないために、ある程度の改善効果が見込めるにも関わらずHTTPパイプラインはほとんど採用されていない複数のTCP接続を使用するモダンブラウザでは、デスクトップでもモバイルでも、ホストあたり6接続まで並列使用できる。?接続数が多いほどクライアントとサーバのオーバヘッドは増大するが、リクエストの並列性による利点は増す。ホストあたりの6接続はバランスをとった。オーバーヘッド付加的に発生した処理(負荷)のことドメインシャーディングシャーディング(分割)HTTP1.xプロトコルが持つ欠如のために、ブラウザベンダは1ホストあたり6つまでのTCPストリームを管理する接続プールの採用と維持を強いられてきた。HTTPArchiveによると、平均的なWebページは90以上のリソースで構成されている。これらのリソースがすべて同じホストから配信されている場合は相当なキューイング遅延が発生。shardN}.example.comといった複数のサブドメインにシャーディング(分割)できる。接続先のホスト名が異なるのでブラウザの接続制限を増加させてより高いレベルの並列性を手に入れることができる。多くのドメインに分割することで、より並列性が高まる。デメリットそれぞれのホストについてDNSルックアップが必要になるサイト管理者がリソースをどのように分割配置するかを管理しなければならない実際にはドメインシャーディングは過度に利用される傾向があり、数十の利用されていないTCP接続を低下させてしまう。HTTPSを使用しなければならない場合はTLSハンドシェイクのために追加のパケット往復が発生し、更にコストが高くなるまとめドメインシャーディングの実施に際して以下を考慮する必要があるまずTCPの最適化ブラウザは6つまでの接続を自動的に開始それぞれのリソースの数、サイズ、そしてレスポンス時間がシャードの最適数を左右するクライアントレイテンシと帯域幅がシャードの最適数を左右するドメインシャーディングはDNSのルックアップとTCPスロースタートによってパフォーマンスを低下させる可能性があるドメインシャーディングは合理的ですが、不完全な最適化。リソースの数を減らしてリクエスト数を削減することで大きな利益を得ることができる。プロトコルオーバーヘッドの計測と制御HTTP1.0はリクエストとレスポンスのヘッダに書式を追加しメタデータの交換ができるようにプロトコルを拡張したブラウザが開始するHTTPリクエストじゃ500-800バイトのHTTPのメタデータを運んでいるい。すべてのHTTPヘッダは無圧縮のプレーンテキストで送信されるため、すべてのリクエストで高いオーバーヘッドにつながる可能性がある。無圧縮で繰り返し送信されるヘッダの転送量を減らすことで、パケット往復によるネットワークレイテンシを削減でき、パフォーマンス向上に繋がる。ファイル結合とスプライトより早いリクエストは、そもそもリクエストが行われないこと。リクエスト数を減らすことは、使用プロトコルやアプリケーションに関係なく最高の最適化。複数の画像を統合した画像デメリット複数の独立したリソースのバンドルはキャッシュのパフォーマンスやページの実行速度を低下させる。統合されたファイルは、現在のページには必要ないリソースを含んでいる可能性があるどれか一つのファイルをアップデートするとキャッシュは無効化され、リソースのバンドルを再度ダウンロードする必要があり、オーバーヘッドが追加発生するJavaScriptとCSSはどちらも、転送が終了してから構文解析を開始し、実行する。したがってアプリケーションの実行を遅くする可能性がある。まとめ結合とスプライトはHTTP1.xプロトコル向けのアプリケーション層における最適化。使用された場合はかなりのパフォーマンス向上をもたらすが、アプリケーションの複雑さやキャッシュ時の注意、アップデート時のコスト、スクリプト、レンダリングの実行時間に悪い影響を与える可能性がある。アプリケーションは多くの小さなリソースのダウンロードによってブロックされているか?アプリケーションは特定のリクエストを結合することで利益を得ることができるか?キャッシュの粒度が落ちるとアプリケーションに悪い影響があるか?結合された画像は高いメモリオーバヘッドに繋がるか?実行が遅くなることで最初のレンダリングまでの時間に影響を与えるか?リソースインライン化ドキュメントに直接リソースを埋め込むことにより、リクエストの数を減らすdata:image/gif;base64,R0lGODlhAQABAAAAACw=dataURIスキームを利用すれば、画像や音声、PDFファイルを埋め込めるdataURIは小さくて、汎用的ではないリソースに向いている。インライン化されるとブラウザやCDNにキャッシュされないリソースをインライン化する大まかな指針としては、リソースの大きさが2KB未満程度であること。HTTP2.0HTTP2.0はアプリケーションをより速く、よりシンプルに、そして堅牢にするHTTP2.0の目標は、リクエストとレスポンスの多重化によるレイテンシの削減、HTTPヘッダフィールドの効率的な圧縮によるプロトコルオーバーヘッドの最小化、リクエスト優先度設定とサーバプッシュの実現HTTP2.0はHTTPメソッド、ステータスコード、URI、などすべてのコアコンセプトを全く変更しない。目的は最高のパフォーマンスHTTP2.0の歴史、そしてSPDYとの関係。SPDYはHTTP2.0ではない。HTTP-WG内の様々な議論を経てSPDYがHTTP2.0の出発点に採用される設計と技術的目標HTTP1.xは実装のシンプルさを意識して設計される。残念ながら、実装のシンプルさによってアプリケーションのパフォーマンスが犠牲になる。HTTP2.0はこの犠牲を取り戻すよう設計されている。バイナリフレーミングレイヤーHTTP2.0のすべてのパフォーマンス強化の中心となる存在は、バイナリフレーミングレイヤー。ストリーム、メッセージ、フレーム参考ストリーム確立した接続内の双方向のフレームの流れメッセージフレームの完全なシーケンス。論理的なメッセージを構成する。フレームHTTP2.0における通信の最小単位。それぞれのフレームはヘッダを持ち、ヘッダは最低でもそのフレームが所属するストリームを識別する参考リクエストとレスポンスの多重化HTTPメッセージをフレームに分割し、インターリーブし、相手側で再構成を行う一連の機能は、HTTP2.0において最も重要な強化ポイント参考HTTP/2では1つの接続上にストリームと呼ばれる仮想的な双方向シーケンスを作ること(ストリームの多重化)で問題を克服している。リクエスト優先度付けHTTP2.0は優先度の扱いについてのアルゴリズムを指定していない。優先度付けが行われたデータをクライアントとサーバ間でやり取りできるメカニズムを提供しているだけ。クライアントは適切な優先度データを送信すべきで、サーバはその優先度に従って処理と配信を行うべき。フロー制御ひとつのストリームがリソースを占有してしまうことで、他のストリームがブロックしてしまうことを防ぐことサーバプッシュクライアントのリクエスト一つに対してサーバが複数のレスポンスを返すことができるリソースはドキュメントの構文解析を行うことによって発見されるが、あらかじめサーバからプッシュしてもらうヘッダ圧縮ヘッダのメタデータを圧縮。効率的なHTTP2.0アップグレードと発見HTTP2.0のサーバサポートについて情報が存在しない場合、クライアントはHTTPアップグレードを使用して適切なプロトコルのネゴシエートを行う。このアップグレードを利用して、サーバがHTTP2.0に対応していない場合はHTTP1.1のレスポンスを返します。1つの接続上にストリームと呼ばれる仮想的な双方向シーケンスを作ること(ストリームの多重化)でパフォーマンス(レイテンシの改善がされた)が向上。Archiveを眺めてると、モダンなwebアプリケーションを見てみるとリクエスト数やファイルサイズの年々増加していることが分かりました。現在の平均的なWebアプリケーションは約1.8MBのサイズ、約70以上の従属リソースで構成されています。サイトパフォーマンス向上のため多くのWeb開発者が数々の最適化(ファイル結合、スプライト、インライン化)を行っていますが、一時しのぎのためのものであって、本質的な解決策ではないです。QUICやHTTP/3の話にも興味を持ちました。SSLの設定をしてみる。サーバーにSSLの設定をしたのでメモです。(1)はてなブログをはじめよう!cidermitainaさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。