簡易版：
1、ブラウザのアドレスバーにURLを入力し、エンターキーを押します。
2、ブラウザは、現在のURLのDNSキャッシュレコードを見つけるために
3, DNSはURLに対応するIPを解決します。
4、TCP接続を確立するためにIPによると
5、HTTPリクエスト
6、サーバーはリクエストを処理し、ブラウザはHTTPレスポンスを受信します。
7、ページのレンダリング、DOMツリーの構築
8、TCPコネクションを閉じる
3つの握手：
最初のハンドシェイク：接続を確立するために、クライアントはサーバにSYNパケットを送信し、SYN_SENT状態になり、サーバが確認するのを待ちます；
2回目のハンドシェイク：サーバーはSYNパケットを受信し、クライアントのSYNを確認する必要があります（ack=k+1）。
3回目のハンドシェーク：クライアントがサーバーのSYN+ACKパケットを受信し、確認パケットACK（ack=k+1）をサーバーに送信、パケットが送信され、クライアントとサーバーはESTABLISHED状態になり、3回のハンドシェークが完了します。
4つの波：
最初の波は、ブラウザがデータを送信した後、切断するためにFINを送信するときです。2番目の波は、サーバは、この時点で切断するFIN要求を送信することもできますが、考慮サーバはまだ送信するデータを持っている可能性がありますので、FINを送信すると、ブラウザが同意を示すためにACKに返す必要があるように、3番目の波に配置する必要があります同意することを示すためにACKを送信することです、つまり、4番目の波。
詳細版：
I. HTTPリクエストとレスポンスの手順
以上がHTTPリクエストとレスポンスの7つのステップの完全な表現です。 以下は、TCP/IPプロトコルモデルの観点から、HTTPリクエストとレスポンスがどのように配信されるかを理解するためのものです。
第二に、TCP/IP
インターネットの基礎となる一連のネットワークプロトコルを含むTCP/IPプロトコルモデルは、インターネットの中核プロトコルであり、20年以上の開発期間を経て成熟し、ローカルエリアネットワーク（LAN）やワイドエリアネットワーク（WAN）で広く使用され、現在では事実上の国際標準となっています。TCP/IPプロトコル群は、異なるレベルの複数のプロトコルの組み合わせの集合であり、通常、4層のプロトコルシステムとみなされます。OSIの7層モデルに相当します。
HTTPプロトコルは、情報を転送するためのTCP/IPプロトコルモデルに基づいています。
. リンク層
ARPとRARPは、IP層とネットワークインターフェイス層で使用されるアドレスを変換するために、いくつかのネットワークインターフェイスで使用される特別なプロトコルです。ARPとRARPは、IP層とネットワークインターフェイス層で使用されるアドレスを変換するために、いくつかのネットワークインターフェイスで使用される特別なプロトコルです。
. ネットワーク層
インターネット層とも呼ばれ、パケットルーティングなど、ネットワーク内のパケットアクティビティを処理します。TCP/IPプロトコルファミリーのネットワーク層プロトコルには、IPプロトコル、ICMPプロトコル、IGMPプロトコルなどがあります。
IPはネットワーク層のプロトコルで、送信元ノードから宛先ノードへパケットを可能な限り高速に転送するだけの、信頼性の保証されないサービスを提供します。TCPとUDPの両方で使用されます。TCPとUDPの両方の各データグループは、エンドシステムと各中間ルータのIP層を介してインターネットを横断して転送されます。
ICMPはIPプロトコルの補助的なもので、IPレイヤーが他のホストやルーターとエラーメッセージやその他の重要な情報を交換するのに使われます。
IGMPとは、インターネットグループ管理プロトコルのことです。UDPデータグラムを複数のホストにマルチキャストするために使用されます。
. トランスポート層
主に2つのホスト上のアプリケーションにエンドツーエンドの通信を提供します。TCP/IPプロトコルファミリーの中には、TCPとUDPという、互いに同一ではない2つのトランスポートプロトコルがあります。
TCPは、2つのホスト間で信頼性の高いデータ通信を提供します。TCPは、アプリケーションから渡されたデータを適切なチャンクに分割して下のネットワーク層に渡すことから、受信したパケットの確認、確認済みの最終パケットを送信するためのタイムアウトクロックの設定など、あらゆることを行います。トランスポート層は信頼性の高いエンドツーエンド通信を提供するので、アプリケーション層はこれらの詳細をすべて無視することができます。信頼性の高いサービスを提供するために、TCPはタイムアウト再送、エンドツーエンドの確認応答パケットの送受信などのメカニズムを採用しています。
一方、UDPはアプリケーション層に非常にシンプルなサービスを提供します。UDPは単にデータグラムと呼ばれるパケットをあるホストから別のホストに送信するだけです。データグラムは送信者から受信者に送信される情報の単位です。UDPプロトコルに必要な信頼性はアプリケーション層が提供しなければなりません。
. アプリケーション層。
アプリケーション・レイヤは、アプリケーション・サービスがユーザーに提供されるときに行われる通信アクティビティを決定します。HTTP、FTP、DNSサービスなどです。
アプリケーションがTCPを使ってデータを転送するとき、データはプロトコル・スタックに供給され、ビットのストリームとしてネットワークに供給されるまで、各レイヤーを1つずつ通過します。これらの各レイヤは、受信したデータにいくつかの初期情報を追加します。
宛先ホストがイーサネットデータフレームを受信すると、プロトコルの各層によって追加されたメッセージヘッダを強調しないようにしながら、データはプロトコルスタックの下から上へ上昇し始めます。各レイヤーのプロトコルボックスは、データを受信した上位レイヤーのプロトコルを決定するために、メッセージヘッダ内のプロトコル識別をチェックします。このプロセスをサブサンプションと呼びます。プロトコルは、宛先ポート番号、送信元 I P アドレス、送信元ポート番号によって解凍されます。
上記の手順は、TCP/IPモデルの観点からHTTPリクエストとレスポンスのプロセスを理解するためのものです。
下のグラフの方がわかりやすいですね：
ここでは、その方法をステップ・バイ・ステップでご紹介します。
つのTCPハンドシェイク
TCPはコネクション指向であり、どちらか一方が他方にデータを送信する場合、まず両者間にコネクションを確立する必要があります。TCP/IPでは、TCPプロトコルは信頼性の高い接続サービスを提供し、接続は3つのハンドシェイクによって初期化されます。3つのハンドシェイクの目的は、2つの接続パーティのシーケンス番号と確認番号を同期させ、TCPウィンドウ・サイズ情報を交換することです。
最初のハンドシェイク：接続の確立。クライアントは、SYNポジションを1、シーケンス番号をxとして、接続要求メッセージセグメントを送信します；
2回目のハンドシェーク：サーバーはSYNメッセージセグメントを受信します。サーバはクライアントのSYNメッセージセグメントを受信すると、このSYNメッセージセグメントを確認し、Acknowledgment Numberをx+1（Sequence Number+1）に設定する必要があります。同時に、サーバ自身もSYNリクエスト情報を送信する必要があり、SYNの位置を1、Sequence Numberをyに設定します。サーバは上記の情報を1つのメッセージセグメントにまとめてクライアントに送信します。このときサーバはSYN_RECV状態になります；
3回目のハンドシェイク: クライアントはサーバからSYN+ACKメッセージセグメントを受信します。このセグメントが送信されると、クライアントとサーバはともにESTABLISHED状態になり、TCPハンドシェイクが3回完了します。
なぜ3回も握手するのですか？
有効期限が切れた接続要求メッセージセグメントが突然サーバーに再送信され、エラーが発生するのを防ぐため。
lapsed connection request segment "は、クライアントから送られた最初のコネクションリクエストセグメントが失われたのではなく、ネットワークノードで長い間保留され、コネクションが解放されるまでサーバーへの到着が遅れた場合に発生します。サーバーはこの無効なメッセージ・セグメントを受信します。しかし、サーバーはこの無効な接続要求メッセージセグメントを受け取ると、クライアントからの新しい接続要求と勘違いします。その後、サーバはクライアントに確認メッセージを送信し、接続の確立に同意します。3つのハンドシェイク」が使用されないと仮定すると、サーバーが確認応答を送信する限り、新しい接続は確立されます。クライアントはコネクション確立のリクエストを送信していないので、サーバからの確認応答を無視し、サーバにデータを送信しません。しかし、サーバは新しいトランスポート接続が確立されたとみなし、クライアントがデータを送信するのを待ち続けます。その結果、サーバーのリソースの多くが無駄になります。スリーハンドシェイク "アプローチでは、このようなことが起こりません。例えば、先ほど説明したケースでは、クライアントはサーバからの確認応答に対して確認応答を送信しません。サーバは確認応答を受信しないので、クライアントが接続を要求していないことがわかります。"
HTTP プロトコール
Httpとは何ですか？
平たく言えば、彼はネットワークを介してコンピュータ通信のルールであり、要求と応答に基づいて、ステートレス、アプリケーション層のプロトコルは、多くの場合、データを送信するTCP/IPプロトコルに基づいています。現時点では、任意の端末間の通信の任意の種類のHttpプロトコルに従って実施する必要があります、それ以外の場合は接続することはできません。
クライアント側はリクエストを送信し、サーバー側はデータで応答します。
トランザクション処理のためのプロトコルは、クライアントがサーバー側への要求を送信するためにサーバーとの接続を確立するためのセキュリティ認証の一連の要求を一致させる必要があるので、ページの待ち時間を増加させるので、覚えておく能力を持っていない、クライアントがサーバー側に要求を送信すると、サーバー側の応答が完了すると、2つの切断、および接続状態を保存しない、クリーンブレーク！エン切断！この時点から、道！次にクライアントが同じサーバーにリクエストを送信するとき、彼らはお互いを忘れてしまったので、接続を再確立する必要があります。
Httpはアプリケーション層に属するプロトコルで、TCP/IPと組み合わせて使用されます。
HTTPクライアントはサーバーとのTCP接続を開始します。接続が確立されると、ブラウザとサーバープロセスはソケットインターフェースを通じてTCPにアクセスできます。
時には、ユーザーのHTTP通信の状態を保存する必要があります、例えば、ログイン操作を実行するために、30分ですべての要求が再びログインする必要はありません。そこでクッキー技術が導入されました。
HTTP/1.1 では持続的接続方式が登場しました。これは、どちらか一方が明示的に切断しない限り、TCP 接続が維持されるという特徴があり、リクエストヘッダーフィールドの Connection: keep-alive は、持続的接続が使用されていることを示すものです。
などなど。
HTTPリクエスト・メッセージ、レスポンス・メッセージ、上記のステップ2、3、4、5、6に対応します。
HTTPメッセージはテキスト指向で、メッセージの各フィールドはASCII文字列で、各フィールドの長さは不確定です。HTTPにはリクエストメッセージとレスポンスメッセージの2種類のメッセージがあります。
V. HTTPリクエストメッセージ
HTTPリクエストメッセージは、リクエスト行、リクエストヘッダ、空行、リクエストデータの4つの部分から構成されます。
1.リクエストライン
リクエスト行は、リクエストメソッド、リクエストアドレス、プロトコルバージョンの3つのセクションに分かれています。
最も一般的なGETとPOSTの2つは、それがRESTfulインターフェイスであれば、一般的にGET、POST、DELETE、PUTを使用します。
URL:Uniform Resource Locator（ユニフォーム・リソース・ロケーター）。
構成:<协议>//<主机>:<主机><端口>/<路径>
以下の例：
時にはパラメータ付きで、GETリクエスト
プロトコルバージョンの形式は、HTTP/プライマリバージョン番号。HTTP/1.0 と HTTP/1.1 でよく使われる二次バージョン番号。
2.リクエストヘッダ
リクエストヘッダはリクエストメッセージにいくつかの付加的な情報を加えます。 それは「名前/値」のペアで構成され、1行に1つずつ、コロンで区切られます。
一般的なリクエストヘッダを以下に示します：
リクエストヘッダの最後には、リクエストヘッダの終わりを示す空行があり、その後にリクエストデータが続きます。
3.データのリクエスト
GETリクエストのようなオプション部分はデータを要求しません。
以下は POST メソッドのリクエスト・メッセージです：
第六に、HTTPレスポンスメッセージ
HTTPレスポンスメッセージは、主にステータス行、レスポンスヘッダ、空行、レスポンスデータから構成されます。
1.ステータスライン
プロトコルのバージョン、ステータスコード、ステータスコードの説明です。
ここで、プロトコルのバージョンはリクエストメッセージと一致しており、 ステータスコードの記述はステータスコードの単純な記述なので、 ここではステータスコードのみを示します。
ステータスコードは3桁の数字です。
1xx: 表示メッセージ - リクエストを受信したことを示します。
2xx: 成功 - リクエストが正常に受信され、理解され、受け入れられたことを示します。
3xx: リダイレクト(Redirection) - リクエストを完了するために、さらなる 操作が必要であることを示します。
4xx: クライアント側のエラー - リクエストに構文エラーがあるか、 リクエストを実行できませんでした。
5xx: サーバー側のエラー - サーバーが正当なリクエストを実行できませんでした。
以下に一般的なものをいくつか挙げます：
2.レスポンスヘッダ
リクエストヘッダと同様に、いくつかの追加情報がレスポンスメッセージに追加されます。
一般的なレスポンス・ヘッダを以下に示します：
3.レスポンスデータ
クライアントに返す必要のあるデータ情報を格納するために使用します。
以下は応答メッセージの例です：
リクエストヘッダとレスポンスヘッダについて知っておくべきことはたくさんあります。
上記の手順を介して、データが渡されている、HTTP / 1.1は、永続的な接続を維持しますが、時間の期間は、常に接続を閉じる必要があります続けて、この時間は、TCP接続を切断する必要があります。
TCP4つの波
クライアントとサーバーが3回のハンドシェイクを経てTCPコネクションを確立し、データ転送が完了したら、TCPコネクションを切断しなければなりません。そのTCP切断のために、ここでは謎の "4つのブレークアップ "です。
最初のブレークアップ：ホスト1、シーケンス番号を設定し、ホスト2にFINメッセージセグメントを送信。この時、ホスト1はFIN_WAIT_1状態になります；
第二のブレークアップ：ホスト2はホスト1からFINメッセージセグメントを受信し、ACKメッセー ジセグメントをシーケンス番号に1を加えた応答番号でホスト1に送り返します。「に同意します；
3番目の切断：ホスト2がLAST_ACK状態に入る間、ホスト2は接続の切断を要求するFINメッセージセグメントをホスト1に送信；
ホスト2がホスト1からACKメッセージセグメントを受信した後、ホスト1はTIME_WAIT状態に入ります。この時、ホスト1は2MSL待っても応答を受信しないので、サーバー側が正常に閉じたことを証明し、ホスト1も接続を閉じることができます。接続を閉じることができます。
なぜ4回も別れたのですか？
TCPは全二重モードであり、ホスト1がFINメッセージセグメントを送出するとき、それは単にホスト1が送信するデータがもうないことを意味し、ホスト1はホスト2に送信するデータがすべてあることを伝えます。ホスト2がACKメッセージセグメントを返したとき、それはホスト1に送信するデータがないことをすでに知っていることを意味しますが、ホスト2はまだホスト1にデータを送信できます。ホスト2もFINメッセージセグメントを送信したとき、今度はホスト2に送信するデータがないことを意味し、ホスト1に「私には送信するデータがありません」と伝えます。
上記の手順を通じて、HTTPリクエストとレスポンスが完了し、知識の必要性を伴うデータ転送は、理解するために一つずつ実施されています。
