HTTP は 1990 年に登場しました。当時、HTTP は正式な標準として確立されていませんでした
HTTP と呼ばれていました。この標準は 1996 年 5 月に正式に発表され、そのバージョンは HTTP/1.0 と名付けられ、現在でもサーバー側で広く使用されています。
HTTP/1.1 は 1997 年 1 月に発表され、現在の主流の HTTP プロトコルのバージョンです。
HTTP/2.0 は開発中です。
TCP/IP は特定のプロトコルではなく、インターネットに関連するさまざまなプロトコル ファミリの総称です。詳細については、TCP/IP 詳細学習ノートを参照してください
TCP/IP プロトコル ファミリは、レベルに応じて次の 4 つの層に分かれています:
アプリケーション層: アプリケーション サービスをユーザーに提供する際の通信アクティビティを決定します。この層には、FTP DNS HTTP が含まれます
送信層: 上位のアプリケーション層は、ネットワーク接続内の 2 台のコンピューター間のデータ送信を提供します。 この層には TCP UDP が含まれます
ネットワーク層: ネットワーク上を流れるデータ パケットの処理方法を指定します。パスが相手のコンピューターに到達し、データパケットを相手に送信しますリンク層: ネットワーク接続のハードウェア部分を処理するために使用され、ネットワークカード光ファイバー
TCP/IP 通信送信プロセス (http の例)
まず、アプリケーションでは送信側となるクライアントが使用されます。その層（httpプロトコル）は、あるWebページを閲覧するためにhttpリクエストを発行します。そして、送信の便宜上、アプリケーション層から受信したデータ（httpリクエストメッセージ）をトランスポート層（tcpプロトコル）で分割し、各メッセージにタグシーケンス番号とポート番号を付けてネットワーク層に転送します。 。通信先のMACアドレスはネットワーク層(IPプロトコル)に付加され、リンク層に転送されます。このようにして、ネットワークへの通信要求が完了する。
1.4.1 送信を担うIPプロトコル
IPアドレスはノードに割り当てられたアドレスを指定し、MACアドレスはネットワークカードが属する固定アドレス
1.4.2 信頼性を確保するための TCP プロトコル
スリーウェイハンドシェイク戦略:
送信側はまずSYN(同期)フラグ付きのデータパケットを相手に送信し、それを受信した後、受信側はSYN(同期)フラグ付きのデータパケットを送り返す。確認情報を伝えるための SYN/ACK フラグ。最後に、送信側はハンドシェイクの終了を表す ACK (確認応答) フラグを付けたデータ パケットを送り返します。
1.5 ドメイン名解決を担当する DNS (Domain Name System) サービス
1.6 http プロトコル通信プロセスにおけるさまざまなプロトコルの役割
DNS サービス: ユーザーが入力したドメイン名を IP アドレスに解決します
HTTP プロトコル: ターゲット Web サーバーへの HTTP リクエスト メッセージを生成します
TCP プロトコル: 通信を容易にするために、HTTP リクエスト メッセージはメッセージ セグメントに分割されます、それぞれのメッセージセグメントを確実に相手に送信します
IPプロトコル：相手のアドレスを検索し、転送しながら送信します
TCPプロトコル：相手からメッセージセグメントを受信し、それに応じたグループにメッセージを要求しますシーケンス番号へ
HTTPプロトコル: Webサーバーへ リクエストされたコンテンツの処理
1.7 URI/URL
URL (Uniform Resource Locator) は、インターネット リソースの特定の場所を表します
第 2 章、簡単な http プロトコル
応答メッセージは基本的に、プロトコル バージョン、ステータス コード、ステータス コードを説明する理由フレーズ、オプションの応答ヘッダー フィールド、およびエンティティ本文で構成されます。
2.3 HTTPは状態を保存しないプロトコルです
2.5 サーバーに意図を通知するhttpメソッド
POST: エンティティの本体を送信するために使用されます
GET メソッドと POST メソッドの違い:
Get はサーバーからデータを取得するために使用され、Post はサーバーにデータを転送するために使用されます。
以下の他のメソッドは一般的に使用されません
PUT: ファイルを転送 HEAD: メッセージ ヘッダーを取得 DELETE: ファイルを削除 OPTUIONS: サポートされているメソッドを尋ねます TRACK: トレース パス CONNECT: プロキシに接続するにはトンネル プロトコルが必要です
永続的な接続の利点は、TCP 接続の確立と切断の繰り返しによって生じる追加のオーバーヘッドが軽減され、サーバー側の負荷が軽減されることです。 HTTP/1.1 では、デフォルトですべての接続が永続接続になります
永続接続では、ほとんどのリクエストをパイプライン方式で送信できます。つまり、複数のリクエストを同時に並行して送信できます。
Cookie技術は、リクエストメッセージとレスポンスメッセージにCookie情報を書き込むことでクライアントの状態を制御します
Cookieは、サーバーから送信される応答メッセージ内のSet-Cookieと呼ばれる値に基づきますフィールド情報は、クライアントに Cookie を保存するように通知します。次回クライアントがサーバーにリクエストを送信するとき、クライアントはリクエスト メッセージに Cookie 値を自動的に追加して送信します。クライアントから送信された Cookie を受信したサーバーは、どのクライアントが接続リクエストを送信したかを確認し、サーバー上のレコードと比較して、最終的に以前のステータス情報を取得します。
HTTP メッセージは、メッセージヘッダーとメッセージボディの 2 つの部分に分けることができます。通常、この 2 つは最初の空白行によって区切られます。メッセージ本文
リクエストライン: リクエストに使用されたメソッド、リクエストURI、HTTPバージョンが含まれます
ステータスライン: レスポンス結果のステータスコード、理由フレーズ、HTTPが含まれますversion
Header フィールド: リクエストと応答のさまざまな条件と属性を表すさまざまなタイプのヘッダーが含まれます。通常、一般ヘッダー、リクエスト ヘッダー、応答ヘッダー、エンティティ ヘッダーが含まれます。 + 標準圧縮)
deflate(zlib)
3.5 コンテンツの一部を取得するための Range リクエスト (Range Request)
4.1 ステータスコードは、サーバーから返されたリクエスト結果を通知します
カテゴリクール
1XX
| Success(成功ステータスコード) | リクエストは正常に処理されました | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| リダイレクト(重いダイレクトステータスコード) | 追加のアクションが必要です リクエストが完了しました | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| クライアントエラー(クライアントエラーステータスコード) | サーバーはリクエストを処理できません | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| サーバーエラー(サーバー側)エラーステータスコード) ) | リクエスト処理中のサーバーエラー |
| キャッシュ動作の制御 | |
| ホップバイホップの最初の部分、接続の管理 | |
| メッセージ作成日時 | |
| メッセージコマンド | |
| 最後にヘッダーの概要メッセージの転送エンコーディング | |
| 指定レポート 本文の転送エンコード方式 | |
| 他プロトコルへのアップグレード | |
| プロキシサーバー関連情報 | |
| エラー通知 |
ヘッダーフィールド 名前の説明
| ユーザーエージェントが処理できるメディアタイプ | |||||||||||||||||||
| 優先キャラクターセット | |||||||||||||||||||
| 優先コンテンツエンコーディング | |||||||||||||||||||
| 優先言語 | |||||||||||||||||||
| Web認証情報 | |||||||||||||||||||
| Expectサーバーからの動作 | |||||||||||||||||||
| ユーザーのメールアドレス | |||||||||||||||||||
| リクエストされたリソースが存在するサーバー | |||||||||||||||||||
| エンティティタグETagの比較 | |||||||||||||||||||
| エンティティタグの比較 | |||||||||||||||||||
| リソースの更新時間を比較 | |||||||||||||||||||
| リソースの更新時間を比較 | |||||||||||||||||||
| リソースが更新されていない場合にエンティティのバイト範囲リクエストを送信 | |||||||||||||||||||
| 最大送信ホップバイホップ数 | |||||||||||||||||||
| サーバーが必要とするエージェントクライアント認証情報 | |||||||||||||||||||
| リクエスト内のURIの元のゲッター | |||||||||||||||||||
| エンティティのバイト範囲リクエスト | |||||||||||||||||||
| 転送エンコードの優先度 | |||||||||||||||||||
| httpクライアントプログラム情報 |
| Accept-Range | バイト範囲リクエストを受け入れるかどうか |
| Age | リソース作成経過時間 |
| ETag | リソースのマッチング情報 |
| Location | 指定されたURIにクライアントをリダイレクト |
| クライアントのプロキシサーバーの認証情報 | |
| リクエストを再開始するタイミングの要件 | |
| HTTPサーバーのインストール情報 | |
| プロキシサーバーのキャッシュ管理情報 | |
| クライアントのサーバー認証情報 |
第 7 章、Web の確保安全なhttps
SSL は公開鍵暗号と呼ばれる暗号化処理方式を使用します
公開鍵暗号では、秘密鍵と公開鍵のペアを使用します 暗号文を送信する側は、相手の公開鍵を使用します。暗号化された情報を受け取った後、相手は自分の秘密鍵を使用して復号化します公開鍵暗号化は共有鍵暗号化よりも複雑であるため、通信中に公開鍵暗号化を使用すると、効率は非常に低くなります。したがって、HTTPS は共有キー暗号化と公開キー暗号化の両方を使用するハイブリッド暗号化メカニズムを採用しています。
ハイブリッド暗号化メカニズムの原理:
公開キー暗号化を使用して共有キーを安全に交換します (共有キーについては後で説明します)。
共有鍵暗号を利用して、交換した秘密鍵の安全性を確保しながら通信を行います。
リクエストはクライアントからのみ開始でき、クライアントはレスポンス以外の指示を受け取ることができません
Comet コンテンツはリアルタイムで更新できますが、応答を保持するために接続時間が長くなり、より多くのリソースを消費します
通信量を削減するだけでなく、各接続の総コストは削減されますが、ヘッダー情報も非常に小さくなります
JavaScript は、「WebSocket API」で提供される WebSocket プログラム インターフェイスを呼び出すことができます。 " WebSocket プロトコルで全二重通信を実現します
第 10 章、Web コンテンツ構築技術
第 11 章、Web 攻撃技術
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
