1ネットワーク要求のプロセス
通常、ブラウザーにURLを入力してEnterキーを押した後、1秒未満のWeb要求の後に対応するページを表示します。実際、このような完全なWeb要求プロセスは、いくつかの手順を実行する必要があります。
最初のステップ：DNSはIPアドレスを解決します。
2番目のステップ：接続を確立するためのTCP 3ウェイハンドシェイク。
ステップ3：HTTPSの場合、TLSハンドシェイク検証署名証明書も必要です。
ステップ4：クライアントがHTTPリクエストを開始する
ステップ5：サーバーがHTTPリクエストに応答する
ステップ6：クライアントブラウザーはコンテンツを受信し、html、css、jsを解析します
ステップ7：ブラウザーがページをレンダリングする
2 DNS解決IPプロセス
DNS（ドメインネームシステム）は「ドメインネームシステム」と呼ばれます。これは、ドメイン階層に編成されたコンピュータとネットワークサービスのネーミングシステムです。TCP/ IPネットワークで使用されます。提供するサービスは、ホスト名とドメイン名の変換に使用されます。 IPアドレスのために働く。プロセスはおそらく次のようになります。
最初のステップ：AndroidシステムにはDNSの2次レベルのキャッシュ処理があるため、java.net.InetAddressクラスを通じて対応するメソッドを呼び出して、独自のキャッシュが存在するかどうかを確認します。
手順2：java.net.InetAddressがキャッシュされていない場合は、仮想マシンのDNSキャッシュをチェックして、それが存在するかどうかを判断します。これは2次キャッシュです。
ステップ3：キャッシング後にIPアドレスを解決できない場合は、ローカルのHostsファイルから解決策を読み取ります。
ステップ4：上記の方法でローカルマシンでドメイン名解決を完了できない場合、システムはキャンパスネットワークなどの分析のためにローカルエリアのドメイン名解決サービスシステムのみを要求できます。オペレーターネットワークが接続されている場合、ローカルドメイン名解決サーバーはローカルです。サービスを提供する地域の事業者。
手順5：ローカルドメイン名解決サーバーが解決を完了していない場合、ローカルドメイン名解決サーバーはルートドメインネームサーバーへの解決要求を開始します。ルートドメインネームサーバーは、.com、.cn、.org、.eduなど、検索されたドメインの汎用トップレベルドメイン（gTLD）アドレスを返します。
ステップ6：ローカルドメイン名解決サーバーがgTLDサーバーへのリクエストを開始します。
ステップ7：gTLDサーバーは、ローカルドメインネームサーバーによって開始されたリクエストを受信し、解決する必要があるドメイン名に従って、ドメイン名に対応するネームサーバーネームサーバーを見つけます。通常、このネームサーバーサーバーは、登録したネームサーバーであり、次に登録します。ドメインネームサービスプロバイダーのサーバーは、ドメイン名解決のタスクを引き受けます。
ステップ8：ネームサーバーは、ドメイン名に対応するIPアドレスを検索し、IPアドレスを存続時間（Time To Live、TTL）とともにローカルドメインネームサーバーに返します。
ステップ9：ローカルドメインネームサーバーは解決された結果をキャッシュし、キャッシュ時間はTTL時間によって制御されます。
ステップ10：解決結果をユーザーに返すユーザーシステムはIPアドレスをキャッシュし、キャッシュ時間はTTLによって制御されます。この時点で、解析プロセスは終了します。
3 TCP 3ウェイハンドシェイク
いわゆるスリーウェイハンドシェイク（Three-Way Handshake）は、データセグメントの送受信を同期するために毎回送信されるデータの量を追跡する方法、データ受信の数に応じて決定されるデータ確認とデータ送受信の数を指します。いつ連絡がキャンセルされ、完了後に仮想接続が確立されますか。
最初のハンドシェイク：クライアントは接続要求セグメントを送信し、SYN（同期シーケンス番号、同期シーケンス番号）を1に設定し、seq = x（シーケンス番号、シーケンス番号）を設定します（xはオペレーティングシステムによって決定されます）このメッセージ（SYN = 1 seq = x）をサーバーに送信することは、特定のルールによって生成され、乱数と見なすことができます）。この時点で、クライアントは同期送信状態SYN_SENDに入り、サーバーの確認を待ちます。
2番目のハンドシェイク：サーバーがクライアントのリクエストセグメントSYNを受信した後、接続を確立することに同意した場合、このSYNセグメントの確認（確認番号、確認文字）を確認し、同時にack = x + 1を設定します。また、SYNリクエスト情報を送信し、SYNを1に設定します。seq= y。サーバーは、上記のすべての情報をメッセージセグメントに入れ（ACK = 1 ack = x + 1、SYN = 1 seq = y）、同時にクライアントに送信します。このとき、サーバーは同期受信状態SYN_RECVに入ります。
3番目のハンドシェイク：クライアントはサーバーのSYN + ACKセグメントを受信し、サーバーに確認応答、つまりACK確認を送信し、ackをy + 1に設定し、サーバーにACKセグメントを送信します（ACK = 1 ack = y + 1）、クライアントとサーバーの両方が接続状態ESTABLISHEDに入り、3つのハンドシェイクを完了します。
キビの例：
最初の握手：クライアントは言った：こんにちは、こんにちは、あなたは私を聞くことができますか？
2番目のハンドシェイク：サーバーは言った：こんにちは、聞こえます、聞こえますか？
3番目の握手：クライアントは言った：私もあなたが話しているのを聞くことができます
対話を通じてお互いに聞いたことを確認したら、お互いに話し始めることができます...
なぜ2つではなく3つのハンドシェイクを使用するのですか？
ここで、接続の確立中に異常な状況が発生したとします。クライアントが送信した最初の接続要求セグメントは失われませんが、一部のネットワークノードに長時間留まるため、遅延が発生します。サーバーに到達するのに時間がかかりませんでした。これは本来無効化されるべきセグメントでしたが、サーバーはこの無効な接続要求を受信しました。これが無効な要求であることを認識していなかったため、クライアントが新しい接続要求を発行したと誤って判断したため、確認セグメントがクライアントに送信され、それらの間で接続が確立されます。3ウェイハンドシェイクは使用されないと想定しているため、この時点で接続関係が確立されます。
クライアントは接続を確立する要求を送信していないため、サーバーの確認を無視せず、サーバーにデータを送信しませんが、サーバーは接続が確立され、クライアントがデータを送信するのを待っていると見なします。サーバーはリソースを浪費します。
したがって、3ウェイハンドシェイクは上記の現象を効果的に防止できます。3番目のハンドシェイク時に、クライアントはサーバーに確認を送信しません。サーバーは確認を受信しないため、クライアントが実際に接続の確立を要求しなかったことがわかります。
4四波
3ウェイハンドシェイクの反対は4ウェイウェーブ（Four-Way Wavehand）です。つまり、TCP接続が切断された場合、ウェイバーはクライアントまたはサーバーのいずれかになります。接続が切断されたことを確認するために、それらの間で合計4パケットが送信されます。開くと、プロセスは次のようになります。
最初の波：ホストAは切断されたメッセージセグメントを送信し、FIN（終了番号）を1に設定し、seq = u（uは最後に送信された最後のバイト番号+1）をこのメッセージに設定します（FIN = 1 seq = u）送信後、ホストA は終了待ち1 状態FIN_WAIT_1に入ります。
2番目の波：ホストBはホストAからFINセグメントを受信し、このセグメントにACKを送信し、ack = u + 1を設定し、シーケンス番号seq = vをもたらす必要があります。ホストBは上記を送信しますすべての情報がメッセージセグメントでホストA に返送されます（ACK = 1 ack = u + 1 seq = v）この時点で、ホストBはシャットダウン待機状態CLOSE_WAITに入ります。ホストA がホストB から確認要求を受信すると、ホストA は終了待機2 状態FIN_WAIT_2に入り、ホストBが接続解放メッセージを送信するのを待ちます。このとき、ホストB は通常のデータをホストAに送信することもできます。
3番目の波：ホストBが最後のデータをすべて送信し、送信するデータがなくなった場合、ホストAに接続解放メッセージを送信し、FINを1に設定して、seq = wおよびACKを選択して確認します。 ack = u + 1を設定して解放メッセージを送信します（FIN = 1 seq = w、ACK = 1 ack = u + 1）この時点で、ホストBは最終確認状態LAST_ACKに入ります。
4番目の波：リリースメッセージを受信した後、ホストAは最終確認を送信し、ackをw + 1に設定し、シーケンス番号seq = u + 1をもたらし、メッセージセグメントをホストBに送信する必要があります（ACK = 1 ack = w + 1 seq = u + 1）、この時点で、ホストAは時間待機状態TIME_WAITに入ります。このとき、TCP 接続はすぐには切断されませんが、2 * MSL （最も長いセグメントライフタイム、通常2 同じ期間に同じアドレスとポートを持つ新しい接続が再作成されないようにするための分数）伝送制御ブロックが取り消され、CLOSED状態になります。この間、ホストB はホストA から最終確認を受信すると、すぐにクローズ状態CLOSEDに入り、伝送制御ブロックを取り消します。この時点で、TCP の4つの手を振ったものが完成しました。
キビの例：
最初の波：Aが言った：私は終わりました。私は黙って、何も言いたくないのです。
第二波：Bは言った：私はそれを受け取り、あなたが終わったことを知っていたが、私はまだ言いたいことがある。
Bが言葉を口にした後...
3回目を振った：Bは言った：私は話し終えた、そして私は黙る必要があります。
第4の波：Aが言った：受け取った、そしてあなたがそれを終えたとわかっていたが、Aは落ち着かなかった。しばらく待った後（2つの最大メッセージライフサイクル）、本当に何も聞こえなかった。 BはAを受け取り、話し終えたことを知ってすぐに立ち去りました。
接続時に3ウェイハンドシェイクがあるのに、クローズすると4ウェイブになるのはなぜですか？
TCP は全二重モードです。つまり、ホストA がFIN セグメントを送信すると、ホストB にデータが送信され、それ以上データが送信されないことが通知されます。この場合、ホストBのリターンはACK パケットの時間を、彼はすでにホストを知っていると述べたA データが送信されていないのが、コードは主にされていないBがああ送信するデータがないため、ホストのときB またはホストがにデータを送信することができるA 、いつホストB がFIN メッセージセグメントも送信した場合、これはホストB に送信するデータがないことを意味し、ホストA に送信するデータがないことを通知します。次に、お互い がこのTCP 接続を中断します。
5 TLSハンドシェイク
SSL / TLS プロトコルの基本的な考え方
最初のステップ：クライアントはサーバーに公開鍵を要求します。
ステップ2：サーバーは、公開鍵を含む信頼できる証明書を返します。
3番目のステップ：クライアントは証明書を検証して公開鍵を決定し、公開鍵を使用して非対称暗号化を使用して非公開でネゴシエーションします。会話鍵を生成する方法（非対称暗号化は効率は低くてもセキュリティが高いため、サーバーの公開鍵は暗号化にのみ使用されます「ダイアログキー」自体）。
4番目のステップ：サーバーはネゴシエーション後に復号結果を受信し、2者間の通信は対称暗号化方式を使用して会話キーを生成します（対称暗号化は効率が高く、通信時間を短縮します）。
4 方向ハンドシェイクの詳細なプロセス
最初のハンドシェイク：クライアントは暗号化された通信（ClientHello）のリクエストをサーバーに送信し、次の情報を提供します。
次のような最高のプロトコルバージョンバージョンをサポートします。
サポートされる暗号スイートのリスト：ID認証アルゴリズム、鍵交換アルゴリズム、対称暗号化アルゴリズム、メッセージダイジェスト
後続の情報圧縮送信のためにサポートされている圧縮アルゴリズムの圧縮方法のリスト
乱数random_C、後で会話キーを生成するために使用
拡張フィールド拡張、サポートプロトコルおよびアルゴリズム関連のパラメータ、その他の補助情報など
2番目のハンドシェイク：サーバーは、クライアントリクエスト（server_hello + server_certificate + sever_hello_done）を受信した後、リクエストに応答します（オンラインバンキングのUシールドのように、サーバーがクライアントに証明書の提供も要求している場合、ここにもう1つ含まれますアイテム）：
server_hello：サーバーは、次の情報を含む交渉された情報の結果を返します。
プロトコルバージョン
暗号スイートの使用を確認
選択した圧縮方法
乱数random_S、後で会話キーを生成するために使用
拡張フィールド拡張、サポートプロトコルおよびアルゴリズム関連のパラメータ、その他の補助情報など
server_certificates：公開鍵を使用してサーバー側で構成された証明書
server_hello_done：情報が送信されたことをクライアントに通知します
3番目のハンドシェイク：サーバーから応答を受信した後、クライアントは返された証明書を検証します。証明書が信頼できる機関によって発行されていない場合、または証明書のドメイン名が実際のドメイン名と一致していない場合、または証明書が失効している場合、または証明書の有効期限が切れている場合は、訪問者に警告を表示して通信を続行するかどうかを選択します。証明書に問題がない場合、クライアントは引き続きサーバーに情報を送信します（client_key_exchange + change_cipher_spec + encrypted_handshake_message（Finished））（サーバーがクライアントにインターネットバンキングのUシールドなどの証明書の撤回も要求する場合は、証明書とその証明書を送信します関連情報）：
client_key_exchange：乱数pre_masterを計算し、証明書から抽出した公開鍵を使用して、非対称暗号化を使用して送信を暗号化します
（クライアントは、この時点で会話キーを計算する方法をマスターしました：enc_key = Fuc（random_C、random_S、pre_master））
change_cipher_spec：後続の通信で、暗号化された通信のために双方がネゴシエートした鍵と暗号化アルゴリズムを使用することを示します
encrypted_handshake_message：ハンドシェイクの終了を通知し、以前の通信のすべてのコンテンツのハッシュ値およびその他の関連情報と組み合わせて、サーバーが確認するデータの一部を生成します
4番目のハンドシェイク：サーバーは、クライアントから渡された暗号化されたpre_masterを受信し、それを秘密鍵で復号化し、さらにenc_key = Fuc（random_C、random_S、pre_master）によって会話キーを計算し、メッセージをクライアントに返します（change_cipher_spec + encrypted_handshake_message（終了））：
change_cipher_spec：後続の通信で、暗号化された通信のために双方がネゴシエートした鍵と暗号化アルゴリズムを使用することを示します
encrypted_handshake_message：ハンドシェイクの終了を通知し、以前の通信のすべてのコンテンツのハッシュ値およびその他の関連情報と組み合わせて、クライアントが検証に使用するデータを生成します
この時点で、TLSハンドシェイクフェーズ全体が終了しました。次に、クライアントとサーバー間の通信は通常のHTTPプロトコルですが、コンテンツはセッションキーを使用して暗号化されます。
