記事のディレクトリ
HTTPプロトコル
1. HTTPプロトコルは、要求の送信と応答の返送の形式を指定します
2.リクエストメッセージ
要求メッセージは、要求メソッド、要求URL、プロトコルバージョン、オプションの要求ヘッダーフィールド、およびコンテンツエンティティで構成されます。注：リクエストヘッダーフィールドの下に空白行があります。
3.応答メッセージ
リクエストメッセージはプロトコルバージョンに基づいており、HTTP / 1.1はサーバーに対応するHTTPバージョンを示し、次の200OKはリクエスト処理結果のステータスコードと理由フレーズを示します。次の行は、応答が作成された日時を表します。これは、ヘッダーフィールドの属性です。次に、空白行があります。次は、応答の主な内容です。
4.HTTPプロトコルの機能
HTTPプロトコルはステートレスプロトコルです。つまり、HTTPプロトコル自体には、以前に送信された要求または応答を保存する機能はありません。新しいリクエストが送信されるたびに、対応する新しいレスポンスが生成されます。このプロトコルは、多数のトランザクションをより高速に処理するように設計されているため、セットアップが非常に簡単です。
5.HTTPメソッド
| 方法 | 効果 |
|---|---|
| 取得する | リソースへのアクセス |
| 役職 | 送信エンティティの件名 |
| プット | ファイルを転送する |
| 頭 | メッセージヘッダーを取得する |
| 削除 | ファイルを削除する |
| オプション | サポートを依頼する方法 |
| 痕跡 | トレースパス |
| 接続する | エージェントに接続するにはトンネリングプロトコルが必要です |
6.持続的接続は通信量を節約します
たとえば、ブラウザを使用して複数の画像を含むHTMLページを参照する場合、HTMLページのリソースにアクセスする要求を送信すると、HTMLページに含まれる他のリソースも要求されます。そのため、不要なTCP接続の切断が多く発生し、リソースを大幅に浪費します。
したがって、持続的接続が非常に必要です。
方法1：持続的接続は、パイプライン方式でHTTP要求を送信することであり、応答を1つずつ待たずに、複数の要求を同時に送信できます。
方法2： Cookieの状態管理を使用します。
Cookieは、サーバーから送信された応答メッセージのSet-Cookieと呼ばれるヘッダーフィールド情報に基づいてCookieを保存するようにクライアントに通知します。クライアントが次回サーバーにリクエストを送信するとき、クライアントは送信する前にリクエストメッセージにCookie値を自動的に追加します。サーバーは、クライアントから送信されたCookieを検出すると、接続要求の送信元のクライアントを確認し、サーバー上のレコードを比較して、最後に以前のステータス情報を取得します。
7.HTTP応答ステータスコード
| カテゴリー | 理由フレーズ | |
|---|---|---|
| 1XX | 情報ステータスコード | 受信したリクエストは処理中です |
| 2XX | 成功ステータスコード | リクエストは正常に処理されます |
| 3XX | リダイレクトステータスコード | リクエストを完了するには、追加のアクションが必要です |
| 4XX | 情報ステータスコード | 受信したリクエストは処理中です |
| 5XX | サーバーエラーステータスコード | サーバー処理要求エラー |
HTTPSが必要なのはなぜですか？
1.HTTPのデメリット
HTTPには良い面があります。いくつかの欠点があるはずです。その主な欠点は次のとおりです。
- 通信はプレーンテキスト（暗号化されていない）を使用し、コンテンツは盗聴される可能性があります。
- 通信相手の身元は確認されていないため、マスカレードに遭遇する可能性があります。
- メッセージの整合性を証明できないため、改ざんされている可能性があります。
- 応答が返されるクライアントが、実際に意図したとおりに応答を受信したクライアントであるかどうかを判別することはできません。偽装したクライアントである可能性があります。
- リクエストがどこから来たのか、誰がリクエストから来たのかを知る方法はありません。
これらの欠点を効果的に防ぐために、HTTPSプロトコルの出現が非常に必要です。
2. HTTP +暗号化+認証+整合性保護= HTTPS
HTTPS通信は、Webログインページとショッピングカートのチェックアウトインターフェイスでよく使用されます。HTTPS通信を使用する場合、http：//は使用されなくなりますが、https：//が使用されます。また、ブラウザを使用してWebサーバーにアクセスすると、ロックマークが表示されます。
（1）HTTPSは、SSLシェルを使用したHTTPです。
HTTPSはアプリケーション層の新しいプロトコルではありませんが、HTTP通信インターフェイス部分はSSL（Secure Socket Layer）およびTLS（Transport Layer Security）プロトコルに置き換えられています。
以前は、HTTPはTCPと直接通信していました。SSLを使用すると、HTTPが最初にSSLと通信し、次にSSLとTCPと通信するようになります。SSLはHTTPに依存しないプロトコルであるため、HTTPプロトコルだけでなく、アプリケーション層で実行されているSMTPやTelnetなどの他のプロトコルをSSLプロトコルと組み合わせて使用できます。
（2）ブラウザのインストール後、ブラウザは認証局が発行した証明書を初期化しますが、証明書の用途は何ですか？
まず、データ送信の過程で解決する必要のある問題は次のとおりです。
（1）サーバーがフィッシングWebサイトではなく、本物であることを確認するにはどうすればよいですか。
（2）ネットワーク伝送を解決するには、平文伝送を使用します。道路上のすべての機器が取得されると、情報漏えいが発生します。フィッシング詐欺師は、アカウント番号とパスワードを取得して、違法な収入を取得します（実際のWebサイトにアクセスします）。
それを解決する方法は？これは私たちの証明書を使用します。
（1）権限のある認証局によって発行された証明書は、フィッシングWebサイトではないことが保証されています。
（2）httpsサーバーの証明書は、クリアテキスト送信の問題を解決するためのものです。
証明書の原則と機能：
非対称暗号化：暗号化に
秘密鍵/公開鍵を使用し、復号化に公開鍵/秘密鍵を使用
できます。鍵：
暗号化と復号化にクライアント/サーバー。対称暗号化：暗号化と復号化に同じ鍵を使用します（共有鍵）。 ）
httpsに関連する詳細：
1。キーを生成するプロセス-キー（実際のデータの暗号化と復号化）キーが本当に信頼でき、フィッシングWebサイトによって送信されないようにする方法-対称暗号化
2.公開およびキー非対称暗号化を生成するための秘密キー
共有キーで暗号化する場合、キーは相手にも送信する必要があります。インターネット上で鍵を転送する際に通信を監視していると、攻撃者の手に渡ると同時に暗号化の意味が失われる可能性があります。また、受け取った鍵を安全に保管するよう努める必要があります。
したがって、2つの鍵の公開鍵暗号化を使用します。
公開鍵暗号化は、非対称鍵のペアを使用します。1つは秘密鍵と呼ばれ、もう1つは公開鍵と呼ばれます。秘密鍵は誰にも知られることはなく、公開鍵は任意に解放して誰でも取得できます。
公開鍵暗号化を使用して、暗号文を送信する当事者は、暗号化に相手方の公開鍵を使用し、相手方が暗号化された情報を受信した後、復号化に独自の秘密鍵を使用します。このように、あなたはあなた自身の秘密鍵を送る必要はありません、そしてあなたは他人によって盗聴される鍵を心配する必要はありません。
HTTPSはハイブリッド暗号化方式を使用します。
公開鍵暗号化は共有鍵暗号化よりも複雑であるため、通信時に公開暗号化を使用する効率は比較的低くなります。したがって、2つを組み合わせる必要があります。鍵交換リンクでは、公開鍵暗号化方式が使用され、その後の通信確立では共有鍵暗号化方式が使用されます。
しかし、公開鍵自体が本物であることを証明するにはどうすればよいでしょうか。
したがって、デジタル認証局およびその関連機関によって発行された公開鍵証明書が提供されます。
デジタル証明書認証局は、クライアントとサーバーの両方から信頼できるサードパーティ組織の立場にあります。まず、サーバーのオペレーターは、デジタル証明書認証局に公開鍵申請書を提出し、デジタル証明書認証局が申請者の身元を判断した後、申請された公開鍵にデジタル署名し、公開鍵を配布します。デジタル署名（シールに相当）、公開鍵を公開鍵証明書に入れてバインドします。次に、サーバーは、デジタル証明書認証局によって発行された公開鍵証明書をクライアントに送信して、公開鍵暗号化通信を行います。
公開鍵証明書は、デジタル証明書または直接証明書と呼ばれることもあります。
上記のブラウザをインストールした後、ブラウザは認証局が発行した証明書を初期化します。これは、ブラウザ開発者がバージョンをリリースするときに、一般的に使用される認証局の公開鍵が事前に埋め込まれます。
