ブラウザにURLを入力すると何が起こるか [closed] 質問する

注意: これは非常に大まかで単純化されたスケッチであり、可能な限り単純な HTTP リクエスト (HTTPS なし、HTTP2 なし、追加なし)、可能な限り単純な DNS、プロキシなし、シングルスタック IPv4、1 つの HTTP リクエストのみ、もう一方の端にある単純な HTTP サーバー、およびどのステップでも問題がないことを前提としています。これは、現代のほとんどの意図と目的からすると非現実的なシナリオです。これらはすべて、実際の使用でははるかに複雑であり、この記事が書かれたときから技術スタックは桁違いに複雑になっています。これを念頭に置くと、次のタイムラインはまだある程度有効です。

1. ブラウザはキャッシュをチェックします。要求されたオブジェクトがキャッシュ内にあり、新しい場合は、#9 に進みます。
2. ブラウザはOSにサーバーのIPアドレスを問い合わせる
3. OSはDNSルックアップを行い、IPアドレスをブラウザに返信します。
4. ブラウザはサーバーへのTCP接続を開きます（この手順はHTTPSでははるかに複雑です）
5. ブラウザはTCP接続を介してHTTPリクエストを送信します
6. ブラウザはHTTPレスポンスを受信し、TCP接続を閉じるか、別のリクエストに再利用する可能性がある。
7. ブラウザは、応答がリダイレクトまたは条件付き応答（3xx 結果ステータス コード）、認証要求（401）、エラー（4xx および 5xx）などであるかどうかを確認します。これらは、通常の応答（2xx）とは異なる方法で処理されます。
8. キャッシュ可能な場合、応答はキャッシュに保存されます
9. ブラウザはレスポンスをデコードします（例：gzip圧縮されている場合）
10. ブラウザは応答をどのように処理するかを決定します (例: HTML ページか、画像か、サウンド クリップか)
11. ブラウザは応答をレンダリングするか、認識できないタイプのダウンロードダイアログを表示します

繰り返しになりますが、これらの各ポイントに関する議論は数え切れないほどのページ数に及んでいます。これは、わかりやすくするために要約しただけのものです。また、これと並行して、他にも多くの処理が行われています (入力されたアドレスの処理、投機的なプリフェッチ、ブラウザー履歴へのページの追加、ユーザーへの進行状況の表示、プラグインと拡張機能への通知、ダウンロード中のページのレンダリング、パイプライン処理、キープアライブのための接続追跡、Cookie 管理、悪意のあるコンテンツのチェックなど)。さらに、HTTPS を使用すると、操作全体が桁違いに複雑になります (証明書、暗号、ピン留めなど)。