Web ページを開くと何が起こりますか?

ブラウザに URL を入力するか、リンクをクリックすると、Web ページが開きます...これは、インターネットを閲覧するときによく見られる光景ですが、このような単純な外見の背後には、極めて複雑な技術的プロセスが存在します。知識を増やしたいですか?続きをお読みください。

HTTPリクエストのプロセス

簡単にするために、HTTP リクエストから始めて、HTTP リクエストのネットワーク転送プロセス、つまり「URL を入力してからページのダウンロードが完了するまでに何が起こるか」を簡単に紹介しましょう。

● DNSルックアップはまずURLに対応するIPアドレスを取得します

● ソケット接続 ブラウザとサーバーはTCP接続を確立する

● リクエストの送信 HTTPリクエストの送信

● コンテンツダウンロードサーバーが応答を送信

物理層でそれについて話すと、それは少し不正になります。これらの手順にまだ同意する場合は、関連するパフォーマンスの問題について話し合いましょう。

● DNS クエリをまだ覚えている場合は、今考えてみてください。 DNS ルックアップは、IP アドレスの文字列を取得するために無数の DNS サーバーと通信することです。これにはどれくらい時間がかかりますか?クエリを終了しても、まだ向こうのサーバーと通信していないことに注意してください。

● TCP 接続には 3 回のハンドシェイクが必要です。サーバーが遠い場合、この 3 ウェイ ハンドシェイクにはどのくらいの時間がかかりますか?接続を確立した後、まだリクエストを送信していないことに注意してください。 （通常は0.5秒で出ます）

● HTTP リクエストを送信する場合、ネットワーク帯域幅は通常、アップストリームとダウンストリームで異なることを知っておく必要があります。通常、アップストリーム帯域幅は小さくなります。 1 つだけであれば問題ありませんが、最近の Web ページでは、多くのリソースに対して後続のリクエストを行うのが一般的です。帯域幅が小さいときにアップストリームが混雑している場合はどうすればよいでしょうか?ステップ 3 に到達したことを忘れないでください。サーバーはまだ応答を送信しておらず、ブラウザーはまだ何も描画できません。

● 最後にサーバーが応答を送信しますが、残念ながらアクセス先のサーバーは非常にビジー状態であり、数万人がこのリソースを必要としており、サーバーのアップストリーム帯域幅も制限されています。何をすべきでしょうか?

かなり良い面接の質問を思いついたと思います。ちなみに、最初の 2 つのステップの遅延とネットワーク帯域幅はほとんど影響を与えません。最後の 2 つのステップに帯域幅を追加すると、ある程度は問題を軽減できますが、お金が必要であり、非常に高価です。

ブロガーは WebKit のローカル レンダリングを最適化しましたが、Web ページの読み込みにかかる時間のほとんどがネットワーク通信に費やされていることがわかっているため、これらの手順を最適化すると、ブラウザー カーネルを最適化するよりも労力がかからず、より効果的になります。

まとめると、ネットワークにおける主な最適化方法は、キャッシュ、プリフェッチ、圧縮、並列処理だけです。今後、パフォーマンスの最適化に関する面接の質問があった場合、誰もがこのように検討することができます。

以下、既存の最適化手法を段階的に紹介します。

DNS最適化

DNS の最適化に関して言えば、キャッシュは間違いなく最も単純で、最も強力かつ最も効果的な方法です。キャッシュについて話すときは、キャッシュ階層について言及する必要があります。

● ブラウザDNSキャッシュ

● システムDNSキャッシュ

● ホストファイル

● 各DNSサーバーにキャッシュ

もちろん、DNS キャッシュの有効期限は通常は比較的短いため、再度検索する必要がある場合が多くあります。ユーザーが経験する遅延（ネットワーク遅延ではないことに注意してください）を減らすには、プリフェッチが適切な方法です。

たとえば、URL を入力するとき、まだ入力は終わっていませんが、ブラウザは履歴に基づいて、特定の Web サイトにアクセスする可能性が高いことを検出し、事前に DNS をプリフェッチします。たとえば、「w」と入力すると、Chrome はすでに weibo.com の IP アドレスを見つけるのを手伝ってくれます。 Chrome ユーザーは chrome://predictors をチェックすればわかります。

さらに、ブラウザは過去の履歴を記録し、各ドメイン名の下に通常どのようなリンクがあるかを把握して、Web サイトのトポロジを確立します。このドメイン名のウェブサイトにアクセスすると、事前にリンクされている他のドメイン名の DNS 解決が実行されます。

TCP 最適化

DNS の最適化がいかに複雑であるかを見ると、この単純なステップがそれほど単純ではないことがわかります。

その結果、DNS はすでに IP を事前に取得しているため、TCP の最適化は実際には簡単で、接続を確立するには前の手順に従うだけで済みます。

そのため、最初の文字を入力すると DNS 解決が完了して接続が確立されますが、この時点では URL の入力が終了していない可能性があります。初めて Web サイトにアクセスすると、ブラウザは他のサーバーへの TCP 接続をすぐに確立するのに役立ちます。

HTTP トランスポートの最適化

この時点で、TCP 接続が確立されているので、さらに一歩進んでリンク コンテンツをすべて直接プリフェッチし、URL の入力が完了する前に Web ページが読み込まれるようにしたらどうかと考える人もいるかもしれません。

このアイデアは良いのですが、現実は残酷です。帯域幅が限られていることを忘れてはならないからです。 DNS および TCP 接続は比較的軽量で、ネットワーク帯域幅をあまり消費しませんが、HTTP 転送は異なります。すべてのリンクをプリフェッチすると、帯域幅がすぐにいっぱいになり、通常の要求を満たすことができず、パフォーマンスが大幅に低下します。

キャッシュが再び登場しますが、キャッシュについて言及するときは、階層について言及する必要があります。

● PageCache が最も高速です。既存の Web ページの DOM 構造とレンダリング結果をメモリに直接キャッシュします。そのため、進む、戻るをクリックするときに非常に高速になります。

● HTTP キャッシュ ファイルレベルのキャッシュはローカル ファイル システムに保存され、RFC2616 に従って実装されます。

● プロキシキャッシュインターネットにアクセスするためにプロキシサーバーを使用する場合、プロキシサーバーは通常、キャッシュ標準に従います。

● CDN は地理的に近い場所にあるコンテンツ サーバーです。たとえば、北京で杭州の Taobao から画像をリクエストし、その画像が北京の CDN で入手できる場合、杭州に行く必要はありません。

● DMOC（分散メモリオブジェクトキャッシュシステム）CDN は主に静的データを保存しますが、Web ページにはデータベースで確認する必要がある動的データが多く含まれることがよくあります。交通量が増えると圧力が非常に高くなります。通常、サーバーの外部には、これらのデータベース内のオブジェクトをキャッシュするための専用のメモリ キャッシュ サーバーのレイヤーがあります。 「Taobao 過去 10 年間の技術」によると、データベース アクセスを 99.5% 削減できます。

● サーバー 実際にはサーバーに届くリクエストはそれほど多くありません。

これを見た後、どこに別のキャッシュ層を追加するか考えましたか?実際には、2 と 3 の間に追加、つまりルーターにキャッシュを追加できます。

Xiaomi Router と Sogou が開発したプリフェッチ エンジンは、実際にはルーターにキャッシュ レイヤーを追加し、インテリジェントなプリフェッチを実行することと同等です。 Xiaomi について話すために、なぜここで別の段落を始めなければならないのでしょうか?それはXiaomiの海軍でしょうか？いいえ、ブロガーはこのニュースを見て悲しんだのです。これはブロガーの卒業プロジェクトと重なるからです。

ブロガーがこのアイデアを思いついたのは、360 がポータブル Wi-Fi を発売した昨年のことで、この製品を開発した後、これを利用してビジネスを立ち上げ、360 との協力について話し合うことを考えていた。その結果、彼はつい最近それを終えて論文を提出した。彼は人生の絶頂期を迎え、業界を転覆させることを夢見ていたが、XiaomiとSogouが同じ製品を発売し、商品化していたことを知った。私の人生のピークは過ぎ去りました。これを知っていたら、去年特許を申請していただろう。

よく使用されるもう 1 つの HTTP 最適化は圧縮です。ネットワーク転送時間 = メッセージ サイズ / ネットワーク速度。ネットワーク速度は比較的高価なので、圧縮します。ほとんどのサーバーは HTTP メッセージを gzip で圧縮します。 HTTP ヘッダーで確認できます。詳細については説明しません。

将来のプロトコル: SPDY

上記はすべて伝統的な慣習です。以下は将来の技術についての議論です。 HTTP プロトコルは前世紀に開発されたもので、現在の Web の開発にうまく適応できないため、Google は SPDY プロトコルを提案しました。これは現在、HTTP2.0 標準の基本バージョンとして規定されています。

SPDY の主な機能は次のとおりです。

● 1 つの TCP 接続で複数の HTTP 接続を並行して接続できるため、接続の確立にかかる時間が短縮されます。

● リクエストの優先順位（具体的な実装はまだ確認されていません）。

● HTTP ヘッダー圧縮: 上記の HTTP 圧縮は、ヘッダーではなく HTTP 本体の圧縮です。小さな HTTP メッセージの場合、ヘッダーが依然として大きな割合を占めており、現在の Web には小さなメッセージが多数存在します。

● サーバー プッシュ/ヒント サーバーはオブジェクトを積極的にプッシュします (サーバーがクライアントのプリフェッチを支援するものと考えることができます)。

現在、業界では SPDY に対して賞賛と批判の両方の意見があり、ブロガーも主に 1 と 4 について慎重な姿勢を示しています。4 は、実は先ほど述べた HTTP ダイレクト プリフェッチの矛盾と同じです。プッシュされたデータが不要で、帯域幅を占有する場合はどうなりますか?ヒントを実装するのは難しいです。

最初の潜在的なリスクは、TCP 接続が途中で切断され、すべての接続が停止してしまうことです。この状況は PC インターネットではあまり一般的ではないかもしれませんが、モバイル インターネットでは TCP 接続の切断は依然として比較的よく見られます。

しかし、今後の技術として、まだまだ注目していく必要がある。

今日頭条の青雲計画と百家曼の百+計画の受賞者、2019年百度デジタル著者オブザイヤー、百家曼テクノロジー分野最人気著者、2019年捜狗テクノロジー文化著者、2021年百家曼季刊影響力のあるクリエイターとして、2013年捜狐最優秀業界メディア人、2015年中国ニューメディア起業家コンテスト北京3位、2015年光芒体験賞、2015年中国ニューメディア起業家コンテスト決勝3位、2018年百度ダイナミック年間有力セレブなど、多数の賞を受賞しています。