この記事では、ネットワークプロトコルの使い方を説明します。

ご存知のとおり、ネットワークは複数のコンピュータで構成され、相互に通信し、データを交換する「大きなネットワーク」です。また、さまざまなコンピューターメーカーが製造したコンピューターには違いがあるはずであることは誰もが知っていますが、これらの違いをどのように克服して通信するのでしょうか?

1. ディレクトリ

ネットワークプロトコル
HTTP
HTTPS

この記事が、読者がネットワークプロトコルとは何か、そして私たちが最もよく目にする http と https について理解するのに役立つことを願っています。

2. ネットワークプロトコル

ネットワークプロトコルは、コンピュータネットワークでのデータ交換のために確立された規則、標準、または規約です。

ご存知のとおり、ネットワークは複数のコンピュータで構成され、相互に通信し、データを交換する「大きなネットワーク」です。さまざまなコンピューターメーカーが製造したコンピューターには違いがあるはずであることは誰もが知っていますが、どのようにしてこれらの違いを克服してコミュニケーションをとっているのでしょうか? 明らかに、それは「言語」です。たとえば、リンゴは特定の果物を指します。コンピュータもこの合意を確立することで通信を完了します。ただし注意してください! このネットワークプロトコルは、コンピュータが相互に使用するためだけではなく、ネットワーク上のすべてのデバイス (サーバー、個人用 PC、スイッチ、ルーター、ファイアウォールなど) にも適用されます。ほとんどのネットワークは階層化されたアーキテクチャを採用しており、各層は下位層に構築され、特定のサービスを上位層に提供し、このサービスを実現する方法の詳細を上位層から保護します (これはコードのインターフェイスに似ています)。あるデバイスのレイヤー n が別のデバイスのレイヤー n と通信するためのルールは、レイヤー n プロトコルです。ネットワークの各層には多くのプロトコルがあり、受信側と送信側の同じ層のプロトコルが一致していないと、一方が他方から送信された情報を認識できなくなります。ネットワークプロトコルにより、ネットワーク上のさまざまなデバイスが相互に情報を交換できるようになります。上で述べたように、ほとんどのネットワークは階層化を使用します。階層化モデルは次のとおりです。

OSI モデル (Open System Interconnection Reference Model) は、国際標準化機構によって提案された概念モデルであり、さまざまなコンピュータを世界中のネットワークに相互接続することを試みる標準フレームワークです。具体的には次の 7 つの層に分かれています。
アプリケーション層（第7層）
アプリケーション間通信用のアプリケーションソフトウェア用インターフェース
プレゼンテーション層（第6層）
データを受信側システムが使用できる形式に変換する
セッション層（第5層）
セッション層はトランスポート層の上に構築され、トランスポート層が提供するインターフェースを使用して、アプリケーションはセッションを確立および維持し、セッションを同期することができます（単純にデータ送信のチャネルとして理解されます）。
トランスポート層（レイヤー4）
データ（送信したいデータ）に送信ヘッダ（TH、送信ヘッダには使用するプロトコルなどの情報が含まれます）を付加してデータパケットを形成します
ネットワーク層（レイヤー3）
ネットワーク層はデータの伝送経路と転送を決定し、データパケットにネットワークヘッダー（NH、ネットワークデータを含む：IPなど）を追加します。
データリンク層(レイヤー2)
データリンク層 (データリンク層) は、ネットワークアドレス指定、エラー検出、およびエラー修正を担当します。物理層 (レイヤー 1)
物理層は、生データをさまざまな物理メディア上で確実に送信できるようにします。

次の図に示すように、TCP/IP プロトコルファミリの階層化方式と OSI 階層化の類似点と相違点は次のとおりです。

以下では、単純なシーンのネットワークリクエストを描画します。

シナリオ: 会社用に hello world の単純な静的ページを作成し、会社のサーバーに展開しました。自分のコンピュータを使用して、自宅のパブリックネットワーク経由でこの静的ページにアクセスします。たとえば、URL は「http://www」です。 .xxx.com」。

この URL にアクセスすると、ブラウザは何をしますか? 下の図を見てみましょう。

TCP

TCP (Transmission Control Protocol、伝送制御プロトコル) は、コネクション指向で信頼性の高い、バイトストリームベースの双方向伝送トランスポート層通信プロトコルです。接続を確立するときに 3 ウェイハンドシェイクが実行され、3 ウェイハンドシェイクが完了するまでデータの送信は開始されません。接続を終了する場合は 4 回のハンドシェイクが必要です。詳細は次のとおりです。

(1) 接続を確立する

出典: 百度百科事典

スリーウェイハンドシェイク:

クライアントはサーバーに SYN メッセージを送信し、SYN_SEND 状態に入ります。
サーバーは SYN で応答し、SYN_RECV 状態に入ります。
クライアントはサーバーから SYN メッセージを受信すると、ACK で応答します。

クライアントとサーバーは確立状態になり、データの送受信を開始できるようになります。

(2) 接続を終了する

出典: 百度百科事典

4 回ウェーブします (注: 閉じるアクションはどちらの側でも最初に開始できます。ここではクライアントによって開始される例を示します)。
クライアントは最初に close を呼び出し、active close を実行し、データが送信されたことを示す FIN を送信して、FIN_WAIT_1 状態に入ります。
サーバーは FIN を受信すると、パッシブクローズを実行し、クライアントに ACK を送信し、CLOSE_WAIT 状態に入ります。
サーバーはクライアントに FIN を送信し、LAST_ACK 状態に入ります。

クローズを開始する当事者は、FIN の最終確認を担当します。この例では、クライアントは FIN を受信してサーバーに ACK を返信し、TIME_WAIT 状態に入り、サーバーは ACK を受信した後に CLOSED 状態に入る必要があります。

なぜ終了時に4回手を振るのですか？

一方のパーティが積極的にクローズを開始して FIN を送信するということは、データの送信は行われなくなりますが、引き続きデータを受信できることを意味するだけであるため、もう一方のパーティはクローズして FIN を送信して相手に通知する必要があります。なぜACKとFINを分けるのかというと、ACKは相手に「知っています」と伝えるもの、FINは「データがありません」と相手に伝えるものだからです。ただ、実態としては、FINを受け取ったらそのまま相手にすべてのデータを渡しているわけではないので、分離する必要がある。

HTTP

HTTP (HyperText Transfer Protocol)、ハイパーテキスト転送プロトコル、TCP プロトコルに基づいています。

HTTP はステートレスプロトコルであり、訪問者としてページにアクセスする場合、ステートレスプロトコルはシンプルで効率的です。ただし、電子商取引シナリオでは、ユーザーのログインステータスを記録するか、ショッピングカートの製品情報を記録する必要があります (ユーザーステータスも記録する必要がある電子商取引および一部のミドルエンドシステムを除き、ここでは一例にすぎません)。その後、追加の技術サポートが必要になります。 Cookie などのものが必要です。

HTTPメッセージフォーマット

HTTPプロトコルのリクエストメッセージとレスポンスメッセージの構造は基本的に同じです。

メッセージは 3 つの部分で構成されます。

スタートライン
GET /** HTTP/1.1、HTTP/1.1 200 OK などのリクエストまたはレスポンスの基本情報を記述します。
ヘッダーフィールドのコレクション
Key-Value を使用してメッセージを説明します (リクエストヘッダーとレスポンスヘッダーを考えてください)。
メッセージ本文

HTTPS

HTTP は TCP に基づいて実装されています。そのメッセージはプレーンテキストであり、送信プロセス全体が完全に透過的です。どのリンクも簡単に傍受および変更される可能性があり、非常に安全ではありません。したがって、安全な HTTP プロトコルである HTTPS が登場しました。HTTPS は実際には HTTP の上に SSL を追加します。

(1) SSL/TLS

SSL は Secure Sockets Layer (Secure Sockets Layer) の略で、1999 年に TLS (Transport Layer Security、トランスポート層セキュリティ) に名前変更されました。

最初に明確にする必要がある概念がいくつかあります。

対称暗号化
同じ「鍵」による暗号化と復号化
非対称暗号化
「鍵」には公開鍵と秘密鍵の2つがあり、公開鍵で暗号化されたものは秘密鍵で復号化する必要があり、秘密鍵で暗号化されたものは公開鍵で復号化する必要があります。
ダイジェストアルゴリズム
ランダム長のコンテンツから固定長のコンテンツを生成します。一般的なアルゴリズムには、MD5、sha1、sha2 などがあります。
安全性
絶対的なセキュリティはありません。私たちが話しているデータセキュリティはトラストポイントに基づいています。私たちはそれが安全であると考えており、私たちが話しているセキュリティは確立できると考えています。そうでなければ、セキュリティなどというものは存在しません。非対称暗号化や対称暗号化など、当社はこれらのアルゴリズムの安全性を信じているため、キーが漏洩しない限り安全であると考えています。

(2) HTTPS のワークフローは大まかに次のとおりです。

まず、HTTP と一致する 3 ウェイハンドシェイクを完了します。

ブラウザは暗号スイートのリストをサーバーに送信します (つまり、サーバーがサポートする暗号化アルゴリズムをサーバーに伝えます)。
サーバーは暗号化スイートのリストに従って暗号化アルゴリズムを選択し、公開キーをブラウザに送信します。
ブラウザは公開キーを取得すると、対称暗号化アルゴリズムで使用されるキーをランダムに生成し、そのキーを公開キーで暗号化し、暗号文をサーバーに送信します。
サーバーは秘密キーを使用して復号化し、このキーを使用してセッションのコンテンツ情報を暗号化してブラウザに送信します。

(3) メリット

非対称暗号化により、ブラウザーによって送信されるキーが解読されないことが保証されます (秘密キーはユーザー自身の手にあり、ネットワーク送信を経験していないため)。
対称暗号化アルゴリズムを使用して、コンテンツを高効率で暗号化および復号化します。

(4) デメリット

サーバーが公開鍵をブラウザに送信するとき、ブラウザが公開鍵を公開しないという保証はありません。

この欠点に基づいて、HTTPS の安全性と信頼性を高めるには、サードパーティ組織の支援に依存する必要があります。

詳細は次のとおりです。

3段階目では、送信用公開鍵を送信用公開鍵電子証明書に変更します。
デジタル証明書の構成: 公開鍵ユーザー情報、公開鍵、署名、ハッシュで取得したデータ概要 (公開鍵、企業情報、ドメイン名、その他のアプリケーション情報)、CA が概要情報を暗号化し、暗号文が署名、CA 情報、有効期間、証明書のシリアル番号、電子証明書は第三者機関（CA機関）により発行されます。
システムの企業情報、ドメイン名、公開鍵は認証局機関による認証が必要であり、認証に合格した後、認証局より証明書が発行されますが、証明書の内容は上記には記載しておりません。証明書には署名が付いているため、証明書の内容を改ざんすることができず、公開鍵利用者情報や証明書内の公開鍵の安全性が保証されます。
CA 機関が発行する証明書の信頼性はルート証明書に依存し、ルート証明書はオペレーティングシステムまたはブラウザに組み込まれています (つまり、オペレーティングシステムまたはブラウザのセキュリティを信頼する必要があります)。

要約すると、HTTPS のセキュリティはルート証明書と暗号化アルゴリズムへの信頼に基づいているため、私たちは安全であると考えています。

上で述べたように、ある信頼点に基づいてセキュリティについて話すことができるため、絶対的なセキュリティは存在しません。ハッカーがブラウザをハイジャックし、すべてのリクエストが最初にハッカーに送信され、次にサーバーに送信されると、リクエストしたすべてのデータが最初にハッカーに送信されるため、安全ではありません。例: 私たちのラダーの多くはプロキシです。ブラウザによって送信されたリクエストはブラウザによってプロキシされ、壁をバイパスできるサーバーに移動してリソースをリクエストします。取得されたデータは当然同じルートで返されるため、このトランジットサーバーは多くの操作を行うことができます。

私たちがよく言っているネットワークの階層構造というのは、一般的には5層とか7層というふうに定義されていて、ここで言うネットワークプロトコルというのは、その中のある層の通信プロトコルのことであるということは、この時点ではもう皆さんもご存じだと思います。ここでは、私たちがよく接する http と https を例に挙げて、その違いについて説明し、ネットワークセキュリティの内容を拡張します。