コンピュータネットワークに関する記事で頻繁に聞かれるフロントエンドインタビューの質問の概要

コンピューターネットワークの面接の質問.png

1.HTTPプロトコル

1. GET リクエストと POST リクエストの違い

Post と Get は HTTP リクエストの 2 つのメソッドであり、違いは次のとおりです。

アプリケーションシナリオ: GET リクエストは冪等リクエストです。一般に、Get リクエストは、Web ページリソースのリクエストなど、サーバーリソースに影響を与えないシナリオで使用されます。Post は冪等リクエストではなく、通常、ユーザーの登録などの操作など、サーバーリソースに影響を与えるシナリオで使用されます。
キャッシュするかどうか: 2 つのアプリケーションシナリオは異なるため、ブラウザーは通常 Get リクエストをキャッシュしますが、Post リクエストをキャッシュすることはほとんどありません。
送信されるメッセージの形式: Get リクエストのメッセージの実体部分は空であり、Post リクエストのメッセージの実体部分は通常、サーバーに送信されるデータです。
セキュリティ: Get リクエストでは、リクエストされたパラメータを URL に入れてサーバーに送信できます。リクエストされた URL は履歴に残るため、Post リクエストと比較すると、このメソッドの安全性は低くなります。
リクエストの長さ: URL の長さに関するブラウザーの制限により、get リクエストによって送信されるデータの長さに影響します。この制限は、RFC ではなくブラウザによって指定されます。
パラメーターの種類: post のパラメーター受け渡しでは、より多くのデータ型がサポートされています。

2. POST リクエストと PUT リクエストの違い

PUTリクエストはサーバーにデータを送信してデータの内容を変更するものですが、データの種類などは増加しません。つまり、何度PUT操作を実行しても結果は次のとおりです。違わない。(時間内にデータが更新されていることがわかります)
POST リクエストはサーバーにデータを送信することであり、このリクエストによりデータの種類やその他のリソースが変更され、新しいコンテンツが作成されます。(データを作成すると理解できます)

3. 共通の HTTP リクエストヘッダーとレスポンスヘッダー

HTTP リクエストヘッダー一般的なリクエストヘッダー:

Accept: ブラウザが処理できるコンテンツのタイプ
Accept-Charset: ブラウザが表示できる文字セット
Accept-Encoding: ブラウザが処理できる圧縮エンコーディング
Accept-Language: ブラウザによって現在設定されている言語
接続: ブラウザとサーバー間の接続のタイプ
Cookie: 現在のページによって設定されているすべての Cookie
ホスト: リクエストを行っているページのドメイン
リファラー: リクエストを行ったページの URL
User-Agent: ブラウザのユーザーエージェント文字列

HTTP 応答ヘッダー一般的な応答ヘッダー:

Date: メッセージが送信された時刻を示し、時刻の記述形式はrfc822で定義されています。
サーバー: サーバー名
接続: ブラウザとサーバー間の接続のタイプ
Cache-Control: HTTP キャッシュを制御します。
content-type: 次のドキュメントがどの MIME タイプに属しているかを示します

一般的な Content-Type 属性値は次のとおりです。

(1) application/x-www-form-urlencoded: ブラウザのネイティブフォーム形式。enctype 属性が設定されていない場合、データは最終的に application/x-www-form-urlencoded の形式で送信されます。このようにして送信されたデータはボディに配置され、key1=val1&key2=val2 メソッドに従ってデータがエンコードされ、key と val の両方が URL トランスコードされます。

(2) multipart/form-data: このメソッドは一般的な POST 送信メソッドでもあり、通常はフォームにファイルをアップロードするときに使用されます。

(3) application/json: サーバーメッセージ本文はシリアル化された JSON 文字列です。

(4) text/xml: このメソッドは主に XML 形式でデータを送信する場合に使用されます。

4. HTTP ステータスコード 304 はどの程度優れていますか?

ウェブサイトのアクセス速度を向上させるために、サーバーは以前にアクセスしたページの一部をキャッシュする仕組みを指定しており、クライアントがここでこれらのページをリクエストすると、サーバーはキャッシュされた内容に基づいてそのページが以前と同じページであるかどうかを判断します。それは同じであり、直接 304 を返します。このとき、クライアントは、二次ダウンロードを必要とせずに、キャッシュされたコンテンツを呼び出します。

ステータスコード 304 はエラーとはみなされませんが、クライアントにキャッシュがある場合のサーバーへの応答と見なされます。

検索エンジンスパイダーは、コンテンツソースが頻繁に更新される Web サイトを好みます。Web サイトをクロールする頻度は、一定期間内に Web サイトをクロールすることによって返されるステータスコードによって調整されます。Web サイトが一定期間 304 状態にある場合、スパイダーは Web サイトをクロールする回数を減らす可能性があります。逆に、Web サイトの変更頻度が非常に速く、クロールされるたびに新しいコンテンツを取得できる場合、再訪問率は時間の経過とともに増加します。

より多くの 304 ステータスコードが生成される理由:

ページの更新周期が長い、または更新されない
純粋に静的なページ、または静的な HTML を強制的に生成する

304 ステータスコードが多すぎると、次の問題が発生します。

サイトのスナップショットが停止しました。
収集の削減。
体重が減る。

5. 一般的なHTTPリクエストメソッド

GET: サーバーからデータを取得します。
POST: エンティティを指定されたリソースに送信します。通常はサーバーリソースが変更されます。
PUT: ファイルをアップロードし、データを更新します。
DELETE: サーバー上のオブジェクトを削除します。
HEAD: メッセージのヘッダーを取得します。GET と比較して、メッセージの本文は返されません。
オプション: クロスドメインリクエストに使用される、サポートされているリクエストメソッドについて質問します。
CONNECT: プロキシサーバーと通信するときにトンネルを確立し、TCP 通信にトンネルを使用する必要があります。
TRACE: 主にテストまたは診断のために、サーバーが受信したリクエストをエコーします。

6. OPTIONSのリクエスト方法と利用シーン

OPTIONS は、GET と POST 以外の HTTP リクエストメソッドの 1 つです。

OPTIONS メソッドは、Request-URI要求/応答通信中に、識別されたリソースで利用可能な機能オプションを要求するために使用されます。この方法により、クライアントは、特定のリソース要求を行う前に、リソースに対して実行する必要なアクションを決定したり、サーバーのパフォーマンスを理解したりすることができます。このリクエストメソッドの応答はキャッシュできません。

OPTIONS リクエストメソッドには主に 2 つの用途があります。

サーバーでサポートされているすべての HTTP リクエストメソッドを取得します。
アクセス権を確認するために使用されます。たとえば、CORS クロスドメインリソース共有を実行する場合、複雑なリクエストの場合は、OPTIONS メソッドを使用してスニッフィングリクエストを送信し、指定されたリソースへのアクセスがあるかどうかを判断します。

7. HTTP 1.0 と HTTP 1.1 の違いは何ですか?

HTTP 1.0 と HTTP 1.1 には次の違いがあります。

接続に関しては、http1.0 はデフォルトで非永続接続を使用しますが、http1.1 はデフォルトで永続接続を使用します。http1.1 では、複数の http リクエストで永続接続を使用して同じ TCP 接続を再利用できるため、非永続接続を使用する場合に毎回接続を確立する遅延を回避できます。
http1.0ではリソースリクエストに関して、クライアントはオブジェクトの一部だけを必要とするが、サーバーはオブジェクト全体を送信し、アップロードを再開する機能をサポートしていないなど、帯域幅を無駄に消費する現象がいくつかあります。 http1.1 リクエストヘッダーに範囲ヘッダーフィールドが導入され、リソースの特定の部分のみをリクエストできるようになります。つまり、リターンコードは 206 (部分コンテンツ) であり、開発者が自由に選択できるようにするのに便利です。帯域幅と接続を最大限に活用します。
キャッシュに関しては、http1.0 ではキャッシュの判断基準としてヘッダー内の If-Modified-Since と Expires が主に使用されていますが、http1.1 では Etag、If-Unmodified-Since、If-Match などのより多くのキャッシュ制御戦略が導入されています。、If-None-Match およびその他のオプションのキャッシュヘッダーを使用して、キャッシュ戦略を制御します。
新しいホストフィールドがhttp1.1 に追加され、サーバーのドメイン名を指定するために使用されます。http1.0 では、各サーバーは固有の IP アドレスにバインドされているため、リクエストメッセージ内の URL にはホスト名 (ホスト名) が渡されません。しかし、仮想ホスト技術の発展により、物理サーバー上に複数の仮想ホストが存在し、IP アドレスを共有できるようになりました。そのため、host フィールドを使用すると、同じサーバー上の異なる Web サイトにリクエストを送信できます。
http1.0 と比較して、http1.1には PUT、HEAD、OPTIONS などの新しいリクエストメソッドが多数追加されています。

8. HTTP 1.1とHTTP 2.0の違い

バイナリプロトコル: HTTP/2 はバイナリプロトコルです。HTTP/1.1 バージョンでは、メッセージのヘッダー情報はテキスト (ASCII エンコード) である必要があり、データ本体はテキストまたはバイナリにすることができます。HTTP/2は完全なバイナリプロトコルであり、ヘッダ情報もデータ本体もバイナリであり、これらを総称して「フレーム」と呼び、ヘッダ情報フレームとデータフレームに分けることができます。フレームの概念は、多重化の基礎です。
多重化: HTTP/2 は多重化を実装しており、HTTP/2 は引き続き TCP 接続を多重化しますが、接続では、クライアントとサーバーの両方が複数のリクエストまたは応答を同時に送信でき、順番に従う必要はありません。 1 回の送信で済むため、「行頭ブロック」[1] の問題が回避されます。
データフロー: HTTP/2 では、データフローの概念が使用されています。これは、HTTP/2 データパケットが順不同で送信され、同じ接続内の連続したデータパケットが異なるリクエストに属する可能性があるためです。したがって、パケットがどのリクエストに属しているかを示すためにパケットにマークを付ける必要があります。HTTP/2 では、各要求または応答のすべてのデータパケットをデータストリームと呼びます。各データストリームには一意の番号があります。データパケットが送信されるときは、どのデータフローに属しているかを区別するためにデータフロー ID をマークする必要があります。
ヘッダー情報の圧縮: HTTP/2 はヘッダー情報の圧縮を実装しています。HTTP 1.1 プロトコルには状態がないため、すべての情報を各リクエストに添付する必要があります。したがって、Cookie やユーザーエージェントなど、リクエストの多くのフィールドが繰り返され、まったく同じコンテンツを各リクエストに添付する必要があり、大量の帯域幅が無駄になり、速度に影響します。HTTP/2 は、ヘッダー圧縮メカニズムを導入することでこれを最適化します。一方では、ヘッダー情報は送信前に gzip または compress で圧縮されますが、他方では、クライアントとサーバーは同時にヘッダー情報テーブルを維持し、すべてのフィールドがこのテーブルに格納されてインデックス番号が生成されます。、今後同じフィールドは送信されなくなり、インデックス番号のみが送信されるため、速度が向上します。
サーバープッシュ: HTTP/2 を使用すると、サーバーはリクエストなしでリソースをクライアントにアクティブに送信できます。これはサーバープッシュと呼ばれます。サーバープッシュを使用して、必要なリソースを事前にクライアントにプッシュすることで、遅延時間をある程度短縮できます。ここで、サーバーは http2 で静的リソースをアクティブにプッシュすることに注意してください。これは、WebSocket や SSE によってクライアントに送信されるリアルタイムデータのプッシュとは異なります。

[1] ラインの先頭でのブロック：

行頭ブロックは、HTTP の基本的な「要求と応答」モデルによって発生します。HTTP では、メッセージを「送受信」する必要があると規定しており、これにより先入れ先出しの「シリアル」キューが形成されます。キュー内のリクエストには優先度はなく、キューに入った順序だけがあり、先頭にあるリクエストが最も高い優先度で処理されます。キューの先頭にあるリクエストの処理が遅すぎるために時間が遅れた場合、キュー内の後続のリクエストはすべて一緒に待機する必要があり、その結果、他のリクエストに過度の時間コストがかかり、キューの先頭がブロックされてしまいます。。

9. HTTP プロトコルと HTTPS プロトコルの違い

HTTP プロトコルと HTTPS プロトコルの主な違いは次のとおりです。

HTTPS プロトコルには高価な CA 証明書が必要ですが、HTTP プロトコルには必要ありません。
HTTP プロトコルはハイパーテキスト転送プロトコルであり、情報はプレーンテキストで送信されますが、HTTPS は安全な SSL 暗号化転送プロトコルです。
接続方法が異なればポートも異なります。HTTP プロトコルのポートは 80、HTTPS プロトコルのポートは 443 です。
HTTP プロトコルの接続は非常にシンプルでステートレスです。HTTPS プロトコルは、SSL と HTTP プロトコルで構築されたネットワークプロトコルで、暗号化された送信と ID 認証を実行でき、HTTP よりも安全です。

10. GETメソッドのURL長制限の理由

実際、HTTP プロトコルの仕様では、get メソッドによって要求される URL の長さに制限はなく、この制限は特定のブラウザーとサーバーによって課される制限です。
IE では、URL の長さが 2083 バイト (2K+35) に制限されています。IE ブラウザでは、開発プロセス中に URL の最小長が許可されているため、URL が 2083 バイトを超えない限り、すべてのブラウザで問題なく動作します。

GET的长度值 = URL（2083）- （你的Domain+Path）-2（2是get请求中?=两个字符的长度）

主流ブラウザの get メソッドにおける URL の長さ制限の範囲を見てみましょう。

Microsoft Internet Explorer (ブラウザ): IE ブラウザでは URL の最大文字数が 2083 文字に制限されており、この文字数を超えると送信ボタンが応答しなくなります。
Firefox (ブラウザ): Firefox ブラウザの URL の長さ制限は 65,536 文字です。
Safari (ブラウザ): URL の最大長は 80,000 文字に制限されています。
Opera (ブラウザ): URL の最大長は 190,000 文字に制限されています。
Google (Chrome): URL の最大長は 8182 文字に制限されています。

メインストリームサーバーでは、get メソッドの URL の長さが制限されています。

Apache (サーバー): 受け入れられる最大 URL 長は 8192 文字です。
Microsoft Internet Information Server (IIS): 受け入れられる URL の最大長は 16384 文字です。

上記のデータによると、get メソッドの URL の長さは 2083 文字を超えないため、すべてのブラウザとサーバーが正常に動作することがわかります。

11. ブラウザに「Google.com」と入力して Enter キーを押すとどうなりますか?

(1) URL 解析:まず、URL が解析され、使用される送信プロトコルと要求されたリソースのパスが分析されます。入力された URL のプロトコルまたはホスト名が無効な場合、アドレスバーに入力された内容が検索エンジンに渡されます。問題がなければ、ブラウザは URL 内に不正な文字がないかチェックし、不正な文字がある場合は不正な文字をエスケープしてから次の処理に進みます。

(2)キャッシュ判定:ブラウザは要求されたリソースがキャッシュにあるかどうかを判定し、要求されたリソースがキャッシュにあり有効期限が切れていない場合はそのまま使用し、そうでない場合は新たなリクエストをサーバーに送信します。

(3) DNS 解決:次のステップでは、まず入力 URL 内のドメイン名の IP アドレスを取得し、ローカルにドメイン名の IP アドレスのキャッシュがあるかどうかを確認します。ローカル DNS サーバーも最初にキャッシュがあるかどうかを確認し、キャッシュがない場合は、まずルートドメインネームサーバーへのリクエストを開始し、責任のあるトップレベルドメインネームサーバーのアドレスを取得してから、トップレベルドメインをリクエストします。次に、責任のある権威ドメインネームサーバーのアドレスを取得し、次に権威ドメインネームサーバーへの要求を開始し、最後にドメイン名の IP アドレスを取得します。その後、ローカル DNS サーバーはその IP アドレスを要求元のユーザー。ユーザーはローカル DNS サーバーへのリクエストを再帰的リクエストとして開始し、ローカル DNS サーバーはすべてのレベルのドメインネームサーバーへのリクエストを反復リクエストとして開始します。

(4) MAC アドレスの取得:ブラウザが IP アドレスを取得した後、アプリケーション層がデータをトランスポート層に送信し、TCP プロトコルが送信元ポートを指定するため、データ送信では宛先ホストの MAC アドレスも知る必要があります。番号と宛先ポート番号を指定してネットワーク層に配信します。ネットワーク層はローカルアドレスを送信元アドレス、取得したIPアドレスを宛先アドレスとして使用します。その後、データリンク層に送信されます。データリンク層の送信では、通信する双方の MAC アドレスを追加する必要があります。ローカルマシンの MAC アドレスが送信元 MAC アドレスとして使用され、宛先 MAC アドレスが使用されます。状況に応じてアドレスを処理する必要があります。IPアドレスと本機のサブネットマスクを比較することで、要求元のホストと同じサブネット内にあるかどうかを判断でき、同じサブネット内であればAPRプロトコルを使用して宛先のMACアドレスを取得できます。ホストが同じサブネット内にない場合ネットワーク内では、リクエストはゲートウェイに転送される必要があり、ゲートウェイが代わりに転送しますこのとき、ゲートウェイの MAC アドレスは ARP プロトコルを通じて取得することもできますこのとき、宛先ホストのMACアドレスはゲートウェイのアドレスである必要があります。

(5) TCP スリーウェイハンドシェイク: TCP 接続確立の 3 ウェイハンドシェイクプロセスは次のとおりです. まず、クライアントは SYN 接続要求セグメントとランダムなシーケンス番号をサーバーに送信し、サーバーは要求を受信した後、サーバーへの SYN ACK メッセージセクションでは、接続要求を確認し、ランダムなシーケンス番号もクライアントに送信します。クライアントは、サーバからの確認応答を受信後、コネクション確立状態となり、同時にACK確認セグメントをサーバに送信し、サーバも確認受信後、コネクション確立状態となり、クライアント間の接続が完了します。二大政党が成立する。

(6) HTTPS ハンドシェイク: HTTPS プロトコルを使用する場合、通信前に TLS の 4 ウェイハンドシェイク処理が行われます。まず、クライアントは使用するプロトコルのバージョン番号、乱数、使用可能な暗号化方式をサーバーに送信します。サーバーはそれを受信すると、暗号化方式を確認し、乱数と独自のデジタル証明書をクライアントに送信します。クライアントはデジタル証明書を受信すると、まずそのデジタル証明書が有効かどうかを確認し、有効であれば乱数を生成し、その乱数を証明書内の公開鍵で暗号化してサーバーに送信し、以前のすべてのコンテンツのコピー。ハッシュ値はサーバー側の検証用です。受信後、サーバーは独自の秘密キーでデータを復号化し、同時に検証のために以前のすべてのコンテンツのハッシュ値をクライアントに送信します。このとき、双方は 3 つの乱数を持っており、事前に合意した暗号化方式に従って、これら 3 つの乱数を使用して秘密鍵を生成し、双方が通信する前に、この秘密鍵を使用してデータを暗号化して送信します。

(7)戻りデータ:ページ要求がサーバーに送信されると、サーバーは応答として html ファイルを返し、応答を受信した後、ブラウザーは html ファイルの解析を開始し、ページのレンダリングプロセスを開始します。

(8)ページのレンダリング:ブラウザは、まず html ファイルに基づいて DOM ツリーを構築し、解析された CSS ファイルに基づいて CSSOM ツリーを構築し、script タグを見つけた場合、そのタグに defer 属性が含まれているか、async 属性が含まれているかを判断します。、そうでない場合、スクリプトの読み込みと実行がページのレンダリングをブロックします。DOM ツリーと CSSOM ツリーが確立されると、それらに従ってレンダリングツリーが構築されます。レンダリングツリーが構築されると、レンダリングツリーに従ってレイアウトされます。レイアウトが完了したら、最後にブラウザの UI インターフェイスを使用してページを描画します。この時点で、ページ全体が表示されます。

(9) TCP 4 方向ウェーブ:最後のステップは、TCP 切断の 4 方向ウェーブプロセスです。クライアントは、データ送信が完了したと判断した場合、サーバーに接続解放要求を送信する必要があります。接続解放要求を受信した後、サーバーはアプリケーション層に TCP 接続を解放するように指示します。その後、ACK パケットを送信し、CLOSE_WAIT 状態に入ります。これは、クライアントからサーバーへの接続が解放され、クライアントによって送信されたデータが受信されなくなることを示します。ただし、TCP 接続は双方向であるため、サーバーは引き続きクライアントにデータを送信できます。この時点でサーバーに未完了のデータがある場合は送信を続け、完了後、クライアントに接続解放要求を送信し、サーバーは LAST-ACK 状態になります。クライアントは解放要求を受信した後、サーバーに確認応答を送信し、TIME-WAIT 状態に移行します。この状態は 2MSL (最大セグメント存続期間。メッセージセグメントがネットワーク内で存続し、タイムアウト後に破棄される時間を指します) の間続きます。この期間内にサーバーからの再送信要求がない場合、メッセージセグメントは次の状態になります。 CLOSED状態。サーバーは確認応答を受信すると、CLOSED 状態になります。

12. キープアライブの理解

HTTP1.0 のデフォルトでは、各要求/応答、クライアントとサーバーは新しい接続を作成し、完了後にすぐに切断する必要があります。これは短い接続です。Keep-Alive モードを使用すると、Keep-Alive 機能によりクライアントからサーバーへの接続が継続的に有効に保たれ、後続のサーバーへのリクエストがあった場合でも、Keep-Alive 機能により接続の確立または再確立が回避されます。長い接続です。その使用法は次のとおりです。

HTTP バージョン 1.0 にはデフォルトでキープアライブがない (つまり、デフォルトでキープアライブを送信する) ため、接続を維持したい場合は送信フィールドを手動で設定する必要がありますConnection: keep-alive。キープアライブ接続を切断したい場合は、Connection:closeフィールドを送信する必要があります。
HTTP1.1 では、デフォルトで永続的な接続が維持され、データ送信完了後も TCP 接続が切断されずに、このチャネルを使用して同じドメイン名でデータが送信され続けるのを待つことが規定されています。閉じる必要がある場合、クライアントはConnection：closeヘッダーフィールドを送信する必要があります。

Keep-Alive の確立プロセス:

クライアントがリクエストメッセージをサーバーに送信すると、ヘッダーに Connection フィールドが追加されます。
サーバーはリクエストを受信し、接続フィールドを処理します。
サーバーは、Connection: Keep-Alive フィールドをクライアントに送り返します。
クライアントは Connection フィールドを受け取ります
キープアライブ接続が正常に確立されました

サーバーはプロセスを自動的に切断します (つまり、キープアライブはありません)。

クライアントはコンテンツメッセージをサーバーに送信するだけです (Connection フィールドは含まれません)。
サーバーはリクエストを受信して処理します
サーバーはクライアントが要求したリソースを返し、接続を閉じます。
クライアントはリソースを受信し、Connection フィールドがないことを確認して切断します。

クライアント要求の切断処理:

クライアントは Connection:close フィールドをサーバーに送信します
サーバーはリクエストを受信し、接続フィールドを処理します。
サーバーは応答リソースを送り返し、接続を切断します。
クライアントがリソースを受け取り、切断する

Keep-Alive をオンにする利点:

CPU とメモリの使用量が少なくなります (同時に開かれる接続が少ないため)。
リクエストとレスポンスの HTTP パイプライン処理を許可します。
輻輳制御の削減 (TCP 接続の削減)。
後続のリクエストの待ち時間が短縮されました (ハンドシェイクがなくなりました)。
TCP 接続を閉じずにエラーを報告します。

キープアライブをオンにするデメリット:

Tcp 接続が長期間続くと、システムリソースが非効率的に占有され、システムリソースが浪費される可能性があります。

13. ページ上に複数の画像がありますが、HTTP 読み込みパフォーマンスはどのくらいですか?

以下ではHTTP 1、ドメイン名の TCP 接続の最大数は 6 であるため、ブラウザは複数回リクエストします。これは、複数のドメイン名を展開することで解決できます。これにより、同時リクエストの数が増加し、ページ画像の取得が高速化される可能性があります。
この状況下ではHTTP 2、HTTP2 は多重化をサポートしており、複数の HTTP リクエストを 1 つの TCP 接続で送信できるため、多くのリソースを瞬時にロードできます。

14. HTTP2のヘッダ圧縮アルゴリズムは何ですか?

HTTP2 のヘッダ圧縮は HPACK アルゴリズムです。クライアントとサーバーの両端に「辞書」を確立し、インデックス番号を使用して繰り返し文字列を表現し、ハフマン符号化を使用して整数と文字列を圧縮します。これにより、50% ～ 90% の高い圧縮率を達成できます。

具体的には：

クライアントとサーバーの「ヘッダーテーブル」を使用して、以前に送信されたキーと値のペアを追跡および保存します。同じデータについては、各リクエストと応答を通じて送信されなくなりました。
ヘッダーテーブルは HTTP/2 の接続中に常に存在し、クライアントとサーバーの両方によって徐々に更新されます。
新しいヘッダーのキーと値のペアはそれぞれ、現在のテーブルの末尾に追加されるか、テーブル内の以前の値を置き換えます。

たとえば、次の図の 2 つのリクエストでは、最初のリクエストはすべてのヘッダーフィールドを送信し、2 番目のリクエストは差分データのみを送信する必要があるため、冗長なデータが削減され、オーバーヘッドが削減されます。

15. HTTP リクエストメッセージはどのようなものですか?

リクエストメッセージは 4 つの部分で構成されます。

リクエストライン
リクエストヘッダー
空行
リクエストボディ

画像.png

(1) リクエスト行には、リクエストメソッドフィールド、URL フィールド、HTTP プロトコルバージョンフィールドが含まれます。それらはスペースで区切られます。たとえば、GET /index.html HTTP/1.1。
(2) リクエストヘッダー: リクエストヘッダーは、1 行に 1 つのキーワードと値のペアで構成され、キーワードと値はコロン「:」で区切られます。

ユーザーエージェント: リクエストを行ったブラウザのタイプ。
Accept: クライアントによって認識されるコンテンツタイプのリスト。
ホスト: 要求されたホスト名。これにより、複数のドメイン名を同じ IP アドレスに含めることができます (つまり、仮想ホスト)。

(3) リクエストボディ: post put などのリクエストで運ばれるデータ
画像.png

16. HTTP 応答メッセージはどのようなものですか?

リクエストメッセージは 4 つの部分で構成されます。

応答ライン
応答ヘッダー
空行
レスポンスボディ

画像.png

応答行: ネットワークプロトコルのバージョン、ステータスコード、およびステータスコードの理由フレーズ ( HTTP/1.1 200 OK など) で構成されます。
応答ヘッダー: 応答ラジカルの構成
応答本文: サーバーが応答するデータ

17. HTTPプロトコルの長所と短所

HTTP はハイパーテキスト転送プロトコルであり、クライアントとサーバー間でメッセージを交換する形式と方法を定義し、デフォルトでポート 80 を使用します。データ伝送の信頼性を確保するために、トランスポート層プロトコルとして TCP を使用します。

HTTP プロトコルには次の利点があります。

クライアント/サーバーモードをサポート
シンプルかつ高速: クライアントがサーバーにサービスを要求する場合、要求メソッドとパスを送信するだけで済みます。HTTPプロトコルがシンプルなため、HTTPサーバーのプログラムサイズが小さく、通信速度が非常に速いです。
接続なし: 接続なしは、各接続が 1 つのリクエストのみを処理するように制限します。サーバーがクライアントのリクエストの処理を完了し、クライアントのレスポンスを受信すると切断するため、送信時間を節約できます。
ステートレス: HTTP プロトコルはステートレスプロトコルであり、状態とは通信プロセスのコンテキスト情報を指します。状態がないということは、後続の処理で以前の情報が必要な場合にその情報を再送信する必要があり、接続ごとに転送されるデータ量が増加する可能性があることを意味します。一方、サーバーが以前の情報を必要としない場合、サーバーの応答は速くなります。
柔軟性: HTTP では、任意のタイプのデータオブジェクトの送信が可能です。転送されるタイプは Content-Type によってマークされます。

HTTP プロトコルには次のような欠点があります。

ステートレス: HTTP はステートレスプロトコルであり、HTTP サーバーはクライアントに関する情報を保存しません。
クリアテキスト送信:プロトコル内のメッセージはテキスト形式を使用しますが、これは外部の世界に直接公開され、安全ではありません。
危険な

(1) 通信は平文（暗号化されていない）で行われるため、内容が盗聴される可能性がある、
(2) 通信相手の本人確認ができないため、偽装される可能性がある、
(3) メッセージの完全性が証明できないため、改ざんされている可能性があります。

18. HTTP 3.0について話す

HTTP/3は、UDPプロトコルをベースに、TCPと同様にデータストリームの多重化や伝送の信頼性などの機能を実装しており、この機能群をQUICプロトコルと呼びます。

フロー制御、伝送信頼性機能：QUICは、データ伝送の信頼性を確保するためのUDPベースの層を追加し、TCPにおけるデータパケットの再送、輻輳制御などの機能を提供します。
統合された TLS 暗号化機能: 現在、QUIC は TLS1.3 を使用しており、これによりハンドシェイクに費やされる RTT の数が削減されます。
多重化: 同じ物理接続上に複数の独立した論理データストリームを存在させることができ、これによりデータストリームの個別の送信が実現され、TCP の行頭ブロック問題が解決されます。

高速ハンドシェイク: UDP に基づいているため、0 ～ 1 RTT を使用して接続を確立できます。

19. HTTP プロトコルのパフォーマンスはどのようなものですか?

HTTP プロトコルは TCP/IP をベースにしており、リクエストとレスポンスの通信方式を採用しているため、パフォーマンスの鍵はこの 2 点にあります。

長い接続

HTTP プロトコルには 2 つの接続モードがあり、1 つは永続的な接続で、もう 1 つは非永続的な接続です。
(1) 非永続接続とは、サーバーが要求されたオブジェクトごとに新しい接続を確立して維持する必要があることを意味します。
(2) 永続的な接続では、TCP 接続はデフォルトでは閉じられず、複数のリクエストで多重化できます。永続的接続を使用する利点は、TCP 接続が確立されるたびにスリーウェイハンドシェイクに費やす時間を回避できることです。

バージョンごとに異なる接続方法が使用されます。

HTTP/1.0ではリクエストが発生するたびに新たなTCPコネクション（スリーウェイハンドシェイク）を作成する必要があり、シリアルリクエストであるためTCPコネクションの確立と切断を恐れることなく通信のオーバーヘッドが増加します。このバージョンでは非永続接続が使用されますが、Connection: keep-a live を追加して、要求時に TCP 接続を閉じないようサーバーに要求できます。
HTTP/1.1では、永続接続とも呼ばれる長時間接続の通信方式が提案されています。この方法の利点は、TCP 接続の確立と切断の繰り返しによって生じる追加のオーバーヘッドが軽減され、サーバー側の負荷が軽減されることです。このバージョン以降のバージョンでは、デフォルトで永続接続が使用されます。現在、同じドメインに対して、ほとんどのブラウザは同時に 6 つの永続接続の確立をサポートしています。

パイプラインネットワーク伝送

HTTP/1.1ではロングコネクション方式を採用しており、パイプラインネットワーク伝送が可能です。

パイプライン (パイプライン) ネットワーク送信の意味: 同じ TCP 接続で、クライアントは複数のリクエストを開始できます。最初のリクエストが送信される限り、2 番目のリクエストは戻ってくるのを待たずに送信できるため、全体的なコストを削減できます。反応時間。ただし、サーバーは引き続きリクエストに順番に応答します。前の応答が特に遅い場合、後から多くのリクエストが並んで待機することになります。これは行頭ブロッキングと呼ばれます。

行頭詰まり

HTTPで送信されるメッセージは一度送受信する必要がありますが、中のタスクはタスクキューに入れられて逐次実行されるため、キュー先頭のリクエスト処理が遅すぎると後続のリクエストの処理がブロックされてしまいます。これは、HTTP 行頭ブロックの問題です。

キューの先頭ブロックの解決策:
(1) 同時接続: 1 つのドメイン名に対して複数の長期接続が許可されます。これはタスクキューを増やすことと同じなので、あるチームのタスクが他のすべてのタスクをブロックすることはありません。
(2) ドメイン名の断片化: ドメイン名が多数の第 2 レベルのドメイン名に分割され、そのすべてが同じサーバーを指すため、同時長時間接続の数が増加し、行頭ブロックの問題が解決されます。

20. URL のコンポーネントは何ですか?

次の URL を例に挙げます: http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name

上記の URL からわかるように、完全な URL には次の部分が含まれています。

プロトコル部分: URL のプロトコル部分は「http:」です。これは、Web ページが HTTP プロトコルを使用することを意味します。インターネットでは、HTTP、FTP などのさまざまなプロトコルが使用されます。この例では、HTTP プロトコルが使用されます。「HTTP」の後の「//」は区切り文字です。
ドメイン名部分: URL のドメイン名部分は「www.aspxfans.com」です。URL では、IP アドレスをドメイン名として使用することもできます
ポート部分: ドメイン名の後にポートが続きます。ドメイン名とポートの間の区切り文字として「:」を使用します。ポートは URL の必須部分ではありません。ポート部分を省略すると、デフォルトのポートが使用されます (HTTP プロトコルのデフォルトポートは 80、HTTPS プロトコルのデフォルトポートは 443)。
仮想ディレクトリ部：ドメイン名の後の最初の「/」から最後の「/」までが仮想ディレクトリ部です。仮想ディレクトリも URL の必須部分ではありません。この例の仮想ディレクトリは「/news/」です。
ファイル名部分：ドメイン名の最後の「/」から「?」までがファイル名部分、「?」がない場合はドメイン名の最後の「/」から「#」まで, はいファイル部分は、「?」と「#」がなければ、ドメイン名の後の最後の「/」から最後までがファイル名部分です。この例のファイル名は「index.asp」です。ファイル名部分は URL の必須部分ではありません。この部分が省略された場合は、デフォルトのファイル名が使用されます。
アンカー部：「#」から最後までがアンカー部です。この例のアンカー部分は「名前」です。アンカー部分は URL の必須部分ではありません。
パラメータ部: 「?」から「#」までの部分はパラメータ部であり、検索部、クエリ部とも呼ばれます。この例のパラメータ部分は「boardID=5&ID=24618&page=1」です。パラメータには複数のパラメータを使用でき、パラメータ間の区切り文字として「&」が使用されます。

21. キャッシュに関連する HTTP リクエストヘッダーは何ですか?

強力なキャッシュ:

有効期限が切れます
キャッシュ制御

ネゴシエーションキャッシュ:

Etag、If-None-Match
最終更新日、更新日以降

2.HTTPSプロトコル

1. HTTPS プロトコルとは何ですか?

Hypertext Transfer Protocol Secure (略して HTTPS) は、コンピュータネットワーク上で安全な通信を行うための伝送プロトコルです。HTTPS は、SSL/TLS を使用してパケットを暗号化し、HTTP 経由で通信します。HTTPS の主な目的は、Web サイトサーバーに ID 認証を提供し、交換されるデータのプライバシーと完全性を保護することです。

HTTPプロトコルは平文で情報を送信するため、情報の盗聴、情報の改ざん、情報乗っ取りの危険性がありますが、TLS/SSLプロトコルは本人確認、情報の暗号化、完全性検証の機能を備えており、これらの問題を回避できます。。

セキュリティ層の主な役割は、開始された HTTP リクエストのデータを暗号化し、受信した HTTP コンテンツを復号化することです。

2. TLS/SSL の仕組み

TLS/SSLの正式名称はTransport Layer Security (トランスポート・レイヤー・セキュリティ)で、TCPとHTTPの間のセキュリティプロトコルの層であり、本来のTCPプロトコルやHTTPプロトコルには影響を与えません。

TLS/SSL の機能実現は、主にハッシュ関数 hash、対称暗号化、非対称暗号化の 3 種類の基本アルゴリズムに依存します。これら 3 種類のアルゴリズムの機能は次のとおりです。

ハッシュ関数に基づいて情報の整合性を検証します
対称暗号化アルゴリズムは、ネゴシエートされた秘密キーを使用してデータを暗号化します
非対称暗号化により本人認証と秘密鍵ネゴシエーションを実現

(1) ハッシュ関数ハッシュ

一般的なハッシュ関数には、MD5、SHA1、SHA256 などがあります。この関数は一方向の不可逆性を特徴としており、入力データの影響を非常に受けやすく、出力の長さは固定されています。データを変更するとハッシュ関数の結果が変更され、情報の改ざんを防止し、データの検証に使用できます。データの整合性。

特徴：情報伝送の過程において、ハッシュ関数では情報の改ざん防止ができないが、平文伝送であるため、仲介者による情報の改ざんや情報の概要の再計算が可能であるため、伝送される情報や情報の概要は改ざんする必要がある。暗号化されています。

(2) 対称暗号化

対称暗号化の方法は、双方が同じ秘密キーを使用してデータを暗号化および復号化することです。しかし、対称暗号化では、鍵がネットワークを介して送信されるため、鍵が他人に取得されると暗号化プロセス全体が無駄になってしまい、鍵送信の安全性を確保するという問題があります。これには、非対称暗号化の使用が必要です。

一般的な対称暗号化アルゴリズムには、AES-CBC、DES、3DES、AES-GCM などが含まれます。同じキーを使用してメッセージの暗号化と復号化を行うことができます。秘密鍵を使いこなすだけで情報を入手でき、情報の盗聴を防ぐことができ、通信方式は1対1です。

特徴:対称暗号化の利点は、情報伝送が 1 対 1 で行われ、同じパスワードを共有する必要があることです。パスワードセキュリティは、情報セキュリティを確保するための基礎です。サーバーは N 個のクライアントと通信し、N 個のパスワードレコードを維持する必要があり、パスワードレコードを維持する必要があります。パスワードを変更します。

(3) 非対称暗号化

非対称暗号化の方法では、2 つの秘密鍵 (1 つは公開鍵、もう 1 つは秘密鍵) を使用します。公開キーは公開され、秘密キーは秘密に保たれます。秘密キーで暗号化されたデータは、対応する公開キーでのみ復号化でき、公開キーで暗号化されたデータは、対応する秘密キーでのみ復号化できます。当社は公開キーを公開することができ、当社との通信を希望する顧客は、当社が提供する公開キーを使用してデータを暗号化し、当社は秘密キーを使用して復号化し、データのセキュリティを確保できます。しかし、非対称暗号化は暗号化処理が非常に遅いというデメリットがあり、通信ごとに非対称暗号化を行うと待ち時間が長くなるという問題が発生します。

一般的な非対称暗号化アルゴリズムには、RSA、ECC、DH などが含まれます。秘密キーはペアで提供され、一般に公開 (公開) キーと秘密 (秘密) キーと呼ばれます。公開キーで暗号化された情報は秘密キーでのみロックを解除でき、秘密キーで暗号化された情報は公開キーでのみロックを解除できるため、公開キーを持っている異なるクライアントは互いの情報を復号化することができず、サーバーとの通信は暗号化された形式でのみ可能であり、サーバーは 1 対多の通信で、秘密キーを保持するサーバーの ID を検証するためにクライアントを使用することもできます。

特徴:非対称暗号化は 1 対多の情報を特徴とし、サーバーは複数のクライアントと通信するために秘密鍵を保持するだけで済みますが、サーバーから送信された情報はすべてのクライアントで復号化でき、アルゴリズムの計算は複雑で、暗号化が遅い。

上記のアルゴリズムの特性に基づいて、TLS/SSL の動作方法は、クライアントが非対称暗号化を使用してサーバーと通信し、本人確認を実現し、対称暗号化に使用される秘密鍵をネゴシエートすることです。対称暗号化アルゴリズムは、ネゴシエートされた秘密鍵を使用して情報および情報要約の通信を暗号化し、異なるノードで使用される対称秘密鍵は異なり、通信中の 2 つの当事者のみが情報を取得できるようにします。これにより、2 つの方法のそれぞれの問題が解決されます。

3. デジタル証明書とは何ですか?

取得した公開鍵が安全な公開鍵であるかどうかを判断する方法がないため、現在の方法は必ずしも安全であるとは限りません。相手から送られてきた公開鍵を傍受し、自分の公開鍵を送ってくる仲介者がいる可能性があり、送信された情報を公開鍵で暗号化すると、相手は自分の秘密鍵で復号化することができます。そして、私たちになりすまして、同じように相手に情報を送り、私たちの情報を盗まれましたが、彼はまだ気づいていませんでした。このような問題を解決するには、デジタル証明書を使用できます。

まず、ハッシュアルゴリズムを使用して公開キーとその他の情報を暗号化し、メッセージダイジェストを生成します。次に、信頼できる証明機関 (CA) が秘密キーを使用してメッセージダイジェストを暗号化し、署名を形成します。最後に、元の情報と署名が結合されてデジタル証明書が作成されます。受信者がデジタル証明書を受け取ると、最初に同じハッシュアルゴリズムを使用して元の情報に基づいてダイジェストを生成し、次に公証役場の公開キーを使用してデジタル証明書内のダイジェストを復号化し、最後に復号化されたダイジェストと証明書のダイジェストを比較します。生成されたダイジェストと比較することで、取得した情報が変更されているかどうかを知ることができます。

この方法で最も重要なことは、認証センターの信頼性です。通常、一部のトップレベルの認証センター証明書はブラウザーに組み込まれており、自動的に信頼されることになります。この方法でのみデータのセキュリティが保証されます。

4. HTTPS通信（ハンドシェイク）処理

HTTPSの通信プロセスは次のようになります。

クライアントはサーバーへのリクエストを開始します。リクエストには、使用されるプロトコルのバージョン番号、生成された乱数、およびクライアントがサポートする暗号化方式が含まれます。
リクエストを受信したサーバーは、双方が使用した暗号化方式を確認し、サーバーの証明書とサーバーが生成した乱数を渡します。
クライアントは、サーバー証明書が有効であることを確認した後、新しい乱数を生成し、その乱数をデジタル証明書内の公開キーで暗号化し、サーバーに送信します。また、サーバーによる検証のために、以前のすべてのコンテンツのハッシュ値も提供されます。
サーバーは独自の秘密キーを使用して、クライアントから送信された乱数を復号化します。そして、クライアントが確認できるように、以前のすべてのコンテンツのハッシュ値を提供します。
クライアントとサーバーは、合意された暗号化方式に従って前の 3 つの乱数を使用して対話キーを生成します。このキーは、後続の対話プロセスで情報を暗号化するために使用されます。

5. HTTPSの特徴

HTTPS の利点は次のとおりです。

HTTPS プロトコルを使用してユーザーとサーバーを認証し、データが正しいクライアントとサーバーに送信されるようにします。
HTTPS プロトコルを使用すると、暗号化された送信と ID 認証を実行できるため、通信の安全性が高まり、送信中のデータの盗難や改ざんを防ぎ、データのセキュリティを確保できます。
HTTPS は現在のアーキテクチャでは最も安全なソリューションですが、完全に安全というわけではありませんが、中間者攻撃のコストが大幅に増加します。

HTTPS の欠点は次のとおりです。

HTTPS ではサーバー側とクライアント側の両方で暗号化と復号化の処理が必要となるため、より多くのサーバーリソースが消費され、プロセスが複雑になります。
HTTPS プロトコルのハンドシェイクフェーズには時間がかかるため、ページの読み込み時間が長くなります。
SSL 証明書は有料であり、証明書が強力であればあるほど、料金も高くなります。
HTTPS 接続はサーバー側のリソースを大量に消費するため、訪問者数がわずかに多い Web サイトをサポートするには、より大きなコストが必要になります。
SSL 証明書は IP にバインドする必要があり、複数のドメイン名を同じ IP にバインドすることはできません。

6. HTTPS はどのようにセキュリティを確保しますか?

まず、次の 2 つの概念を理解します。

対称暗号化: つまり、通信の双方が同じ秘密鍵を使用して暗号化と復号化を行います。対称暗号化は単純でパフォーマンスも優れていますが、秘密鍵を初めて相手に送信するという問題を解決できません。ゲストは秘密鍵を傍受します。
非対称暗号化:

秘密鍵 + 公開鍵 = 鍵ペア
つまり、秘密キーで暗号化されたデータは、対応する公開キーでのみ復号化でき、公開キーで暗号化されたデータは、対応する秘密キーでのみ復号化できます。
通信の両当事者が独自の鍵ペアのセットを持っているため、通信の前に、まず両当事者がお互いに公開鍵を送信します。
次に、相手はこの公開鍵を取得してデータを暗号化し、相手に応答します。それが相手に到達すると、相手は自分の秘密鍵で復号します。

非対称暗号化はより安全ですが、非常に遅く、パフォーマンスに影響を与えるという問題があります。

解決：

2 つの暗号化方式を組み合わせると、対称暗号化キーが非対称暗号化公開キーで暗号化されて送信され、受信者は秘密キーを使用して復号化して対称暗号化キーを取得し、その後、双方が対称暗号化を使用して次のことを行うことができます。伝える。

このとき、仲介者の問題という別の問題があります。
この時点でクライアントとサーバーの間に仲介者がいる場合、仲介者は最初に両者から送信された公開鍵を自分の公開鍵に置き換えるだけで済みます。仲介者は、通信の 2 つの当事者によって送信されたすべてのデータを簡単に復号化できます。

したがって、現時点では、ID の身元を証明し、仲介者による攻撃を防ぐために、安全なサードパーティ証明書 (CA) が必要です。証明書には、発行者、証明書の目的、ユーザー公開鍵、ユーザー秘密鍵、ユーザーの HASH アルゴリズム、証明書の有効期限などが含まれます。

しかし、ここで疑問が生じます。仲介者が証明書を改ざんした場合、身分証明書は無効になるのでしょうか? この証明書は無料で購入できるため、現時点では新しいテクノロジーであるデジタル署名が必要です。

デジタル署名は、CA に付属の HASH アルゴリズムを使用して証明書の内容をハッシュして概要を取得し、それを CA の秘密キーで暗号化して最終的にデジタル署名を形成します。誰かが証明書を送信すると、同じハッシュアルゴリズムを使用してメッセージダイジェストを再度生成し、次に CA の公開キーを使用してデジタル署名を復号化し、CA によって作成されたメッセージダイジェストを取得します。真ん中。現時点では、通信のセキュリティは最大限に保証されます。

3. HTTPステータスコード

ステータスコードのカテゴリ:

カテゴリー	理由	説明
1xx	情報 (情報ステータスコード)	受け入れられたリクエストは処理中です
2xx	成功 (成功ステータスコード)	リクエストは正常に処理されます
3xx	リダイレクト (リダイレクトステータスコード)	追加のアクションが必要です - リクエストを完了してください
4xx	クライアントエラー (クライアントエラーステータスコード)	サーバーはリクエストを処理できませんでした
5xx	サーバーエラー (サーバーエラーステータスコード)	サーバーがリクエストを処理中にエラーが発生しました

1. 2XX (成功ステータスコード)

ステータスコード 2XX は、リクエストが正常に処理されたことを示します。

（1）200OK

200 OK は、クライアントによって送信されたリクエストがサーバーによって正常に処理されたことを意味します。

（2）204 コンテンツなし

このステータスコードは、クライアントから送信されたリクエストがサーバー側で正常に処理されたものの、コンテンツが返されず、応答メッセージにエンティティの主要部分が含まれていないことを示します。一般に、これは、クライアントからサーバーに情報のみを送信する必要があり、サーバーがクライアントにコンテンツを送信する必要がない場合に使用されます。

（3）206 内容の一部

このステータスコードは、クライアントが範囲リクエストを作成し、サーバーが GET リクエストのこの部分を実行したことを示します。応答メッセージには、Content-Range で指定された範囲内のエンティティのコンテンツが含まれます。

2. 3XX (リダイレクトリダイレクトステータスコード)

3XX 応答は、リクエストを適切に処理するためにブラウザが何らかの特別な処理を実行する必要があることを示します。

（1）301 が永久に移動されました

永続的なリダイレクト。
このステータスコードは、要求されたリソースに新しい URI が割り当てられ、リソースによって指定された URI が今後使用される必要があることを示します。新しい URI は、HTTP 応答ヘッダーの Location ヘッダーフィールドで指定されます。ユーザーが元の URI をブックマークとして保存している場合、ブックマークは Location の新しい URI に従って再度保存されます。同時に、検索エンジンは新しいコンテンツをクロールするときに、古い URL をリダイレクトされた URL に置き換えます。

使用するシーン:

ドメイン名を変更する必要があり、古いドメイン名が使用されなくなった場合、ユーザーは古いドメイン名にアクセスすると 301 で新しいドメイン名にリダイレクトされます。実際、これは、含まれるドメイン名に新しいドメイン名を含める必要があることも検索エンジンに伝えます。
検索エンジンの検索結果には、wwwが含まれないドメイン名は表示されますが、wwwが含まれるドメイン名は含まれませんが、このとき、301リダイレクトを使用して、どのドメイン名がターゲットであるかを検索エンジンに伝えることができます。

（2）302件見つかりました

一時的なリダイレクト。
このステータスコードは、要求されたリソースが新しい URI に割り当てられていることを示し、ユーザーが (今回は) 新しい URI を使用してリソースにアクセスできることが期待されます。301 Moved Permanently ステータスコードと似ていますが、302 で表されるリソースは永続的にリダイレクトされるのではなく、一時的にのみリダイレクトされます。つまり、移動されたリソースに対応する URI は将来変更される可能性があります。ユーザーが URI をブックマークとして保存すると、301 ステータスコードが表示されたときのようにブックマークは更新されませんが、302 ステータスコードを返したページに対応する URI は保持されます。同時に、検索エンジンは新しいコンテンツをクロールし、古い URL を保持します。サーバーは 302 コードを返すため、検索エンジンは新しい URL が一時的なものであると判断します。

使用するシーン:

イベント開催中はホームページにログインすると、自動的にイベントページにリダイレクトされます。
ログインしていないユーザーがユーザーセンターにアクセスすると、ログインページにリダイレクトされます。
404 ページにアクセスすると、ホームページにリダイレクトされます。

（3）303 その他を見る

このステータスコードは、リクエストに対応するリソースに別の URI が存在するため、リクエストされたリソースを取得するには GET メソッドを使用する必要があることを示します。
303 ステータスコードと 302 Found ステータスコードには同様の機能がありますが、303 ステータスコードは、クライアントが GET メソッドを使用してリソースを取得する必要があることを明確に示しています。

303 ステータスコードは通常、PUT または POST 操作の戻り結果として使用されます。これは、リダイレクトリンクが新しくアップロードされたリソースではなく、メッセージ確認ページやアップロード進行状況ページなどの別のページを指していることを意味します。リダイレクトされたページをリクエストするメソッドは常に GET を使用する必要があります。

知らせ：

ステータスコード 301、302、および 303 が返された場合、ほとんどのブラウザは POST を GET に変更し、リクエストメッセージの本文を削除して、リクエストを自動的に再送信します。
301 および 302 標準では、POST メソッドを GET メソッドに変更することを禁止していますが、実際には誰もがこれを行うでしょう。

（4）304 未修正

ブラウザキャッシュ関連。
このステータスコードは、クライアントが条件付きリクエストを送信すると、サーバーはリクエストによるリソースへのアクセスを許可したが、条件は満たされなかったことを示します。304 ステータスコードが返される場合、応答本文は含まれません。304 は 3XX カテゴリに分類されますが、リダイレクトとは関係ありません。

条件付きリクエスト (Http 条件付きリクエスト): Get メソッドを使用してリクエストします。リクエストメッセージには ( if-match、if-none-match、if-modified-since、if-unmodified-since、 )if-range内のヘッダーが含まれます。

ステータスコード 304 はエラーではありませんが、キャッシュが存在し、キャッシュ内のデータを直接使用することをクライアントに伝えます。ヘッダー情報のみがページに返され、コンテンツ部分は返されないため、Web ページのパフォーマンスがある程度向上します。

（5）307一時リダイレクト

307 は一時的なリダイレクトを意味します。このステータスコードは 302 Found と同じ意味を持ち、302 規格では POST から GET への変更を禁止していますが、実際の使用では依然として変更されています。

307 はブラウザ標準に準拠し、POST から GET に変更されません。ただし、リクエストの処理動作に関しては、ブラウザーごとに状況が異なります。この仕様では、ブラウザがロケーションのアドレスにコンテンツを POST し続ける必要があります。この仕様では、ブラウザがロケーションのアドレスにコンテンツを POST し続ける必要があります。

3. 4XX (Client Error クライアントエラーステータスコード)

4XX 応答は、クライアントがエラーの原因であることを示します。

（1）400 不正なリクエスト

このステータスコードは、リクエストメッセージに構文エラーがあることを示します。エラーが発生した場合は、リクエストの内容を修正して再度リクエストを送信する必要があります。また、ブラウザはこのステータスコードを 200 OK のように扱います。

（2）401 不正

このステータスコードは、送信するリクエストにHTTP認証（BASIC認証、DIGEST認証）を通過する認証情報が必要であることを示します。以前にリクエストが行われたことがある場合は、ユーザー認証に失敗したことを意味します

401 で返される応答には、ユーザー情報にチャレンジするために、要求されたリソースに適用される WWW-Authenticate ヘッダーが含まれなければなりません (MUST)。ブラウザが初めて 401 応答を受信すると、認証用のダイアログウィンドウがポップアップ表示されます。

401 は次の状況で表示されます。

401.1 - ログインに失敗しました。
401.2 - サーバー構成が原因でログインに失敗しました。
401.3 - リソースに対する ACL 制限により許可されません。
401.4 - フィルターの承認に失敗しました。
401.5 - ISAPI/CGI アプリケーションの認証に失敗しました。
401.7 - Web サーバー上の URL 承認ポリシーによってアクセスが拒否されます。このエラーコードは IIS 6.0 に固有です。

（3）403 禁止

このステータスコードは、要求されたリソースへのアクセスがサーバーによって拒否されたことを示します。サーバーは詳細な理由を示す必要はありませんが、応答メッセージエンティティの本文で説明できます。この状態になると、検証を続行できなくなります。このアクセスは永久に禁止されており、アプリケーションロジックと密接に関係しています。

IIS では、より具体的なエラー原因を示すさまざまな 403 エラーが定義されています。

403.1 - アクセス禁止の実行。
403.2 - 読み取りアクセスは禁止されています。
403.3 - 書き込みアクセスは禁止されています。
403.4 - SSL が必要です。
403.5 - SSL 128 が必要です。
403.6 - IP アドレスが拒否されました。
403.7 - クライアント証明書が必要です。
403.8 - サイトへのアクセスが拒否されました。
403.9 - ユーザーが多すぎます。
403.10 - 無効な構成。
403.11 - パスワードが変更されました。
403.12 - マッピングテーブルへのアクセスが拒否されました。
403.13 - クライアント証明書が取り消されます。
403.14 - ディレクトリのリストが拒否されました。
403.15 - クライアントのアクセス許可を超えました。
403.16 - クライアント証明書が信頼されていないか、無効です。
403.17 - クライアント証明書の有効期限が切れているか、まだ有効ではありません
403.18 - 要求された URL は現在のアプリケーションプールでは実行できません。このエラーコードは IIS 6.0 に固有です。
403.19 - このアプリケーションプール内のクライアントに対して CGI を実行できません。このエラーコードは IIS 6.0 に固有です。
403.20 - パスポートのログインに失敗しました。このエラーコードは IIS 6.0 に固有です。

（4）404が見つかりません

このステータスコードは、要求されたリソースがサーバー上に見つからないことを示します。さらに、サーバーがリクエストを拒否し、その理由を説明したくない場合にも使用できます。
404 は次の場合に発生します。

404.0 - (なし) - ファイルまたはディレクトリが見つかりません。
404.1 - 要求されたポートでは Web サイトにアクセスできません。
404.2 - Web サービス拡張機能のロックアウトポリシーにより、このリクエストは阻止されます。
404.3 - MIME マッピングポリシーにより、このリクエストは阻止されます。

（5）405メソッドは使用できません

このステータスコードは、クライアントが要求したメソッドはサーバーでは認識できるが、サーバーがそのメソッドの使用を禁止していることを示します。GET メソッドと HEAD メソッドでは、サーバーは常にクライアントにアクセスを許可する必要があります。クライアントは、次のように OPTIONS メソッド (事前チェック) を通じてサーバーによって許可されたアクセスメソッドを表示できます。

Access-Control-Allow-Methods: GET,HEAD,PUT,PATCH,POST,DELETE

4. 5XX (Server Error サーバーエラーステータスコード)

5XX 応答により、サーバー自体でエラーが発生します。

（1）500内部サーバーエラー

このステータスコードは、リクエストの実行中にサーバー側でエラーが発生したことを示します。Web アプリケーションのバグまたは一時的な不具合である可能性もあります。

（2）502 不正なゲートウェイ

このステータスコードは、ゲートウェイまたはプロキシとして機能するサーバーが上流サーバーから無効な応答を受信したことを示します。502 エラーは通常、クライアントでは修正できませんが、通過する Web サーバーまたはプロキシサーバーによって修正する必要があることに注意してください。502 は次の状況で表示されます。

502.1 - CGI (Common Gateway Interface) アプリケーションがタイムアウトしました。
502.2 - CGI (共通ゲートウェイインターフェイス) アプリケーションエラー。

（3）503サービス利用不可

このステータスコードは、サーバーが一時的に過負荷になっているか、メンテナンスのために停止しているため、現在リクエストを処理できないことを示します。上記の状況を解決するのに必要な時間が事前にわかっている場合は、RetryAfter ヘッダーフィールドを書き込んでクライアントに返すことが最善です。

使用するシーン:

サーバーがメンテナンスのためにダウンしている場合は、503 でリクエストに積極的に応答します。
nginxには速度制限が設定されており、速度制限を超えると503が返されます。

（4）504ゲートウェイタイムアウト

このステータスコードは、ゲートウェイまたはプロキシサーバーが指定された時間内に必要な応答を取得できないことを示します。これは HTTP 1.1 の新機能です。

使用シナリオ: コードの実行タイムアウト、または無限ループが発生します。

5. まとめ

(1) 2XX 成功

200 OK、クライアントから送信されたリクエストがサーバー側で正しく処理されたことを示します
204 コンテンツなし。リクエストは成功したが、応答メッセージにエンティティの本文が含まれていないことを示します。
205 コンテンツのリセット。リクエストが成功したことを示しますが、応答メッセージにはエンティティの本文が含まれていません。ただし、リクエスト側がコンテンツをリセットする必要があるという点で 204 応答とは異なります。
206 部分コンテンツ、範囲リクエストの作成

(2) 3XX リダイレクト

301 永久に移動されました。永久にリダイレクトされ、リソースに新しい URL が割り当てられたことを示します。
302 が見つかりました。一時的なリダイレクト。リソースに一時的に新しい URL が割り当てられていることを示します。
303 see other、リソースには別の URL があり、リソースを取得するには GET メソッドを使用する必要があることを示します。
304 は変更されていません。サーバーはリソースへのアクセスを許可していますが、リクエストが条件を満たしていないことを示します。
307 一時リダイレクト、一時リダイレクトは 302 と同様の意味を持ちますが、クライアントがリクエストメソッドを変更せずに新しいアドレスにリクエストを送信することを期待します。

(3) 4XXクライアントエラー

400 不正なリクエストです。リクエストメッセージに構文エラーがあります。
401 無許可。送信されるリクエストには HTTP 認証による認証情報が必要であることを示します。
403 禁止、要求されたリソースへのアクセスがサーバーによって拒否されていることを示します
404 not found、要求されたリソースがサーバー上に見つからなかったことを示します

(4) 5XXサーバーエラー

500 内部サーバーエラー。リクエストの実行時にサーバー側でエラーが発生したことを示します。
501 Not Implemented、サーバーが現在のリクエストで必要な機能をサポートしていないことを示します
503 サービスを利用できません。サーバーが一時的に過負荷になっているか、メンテナンスのためにシャットダウン中で、リクエストを処理できないことを示します。

6. リダイレクト、 307、303 、および302の違いも同様です。

302 は http1.0 のプロトコルステータスコードですが、http1.1 バージョンでは、302 ステータスコードを改良するために、さらに 2 つの 303 と 307 が追加されました。303 は、クライアントがリソースを取得するために get メソッドを使用する必要があることを明確に示しており、リダイレクトのために POST リクエストを GET リクエストに変更します。307 はブラウザ標準に従い、post から get まで変わりません。

4. DNSプロトコルの概要

1.DNSプロトコルとは何ですか

概念: DNS は、Domain Name System (ドメインネームシステム) の略で、ホスト名から IP アドレスへの変換サービスを提供します。これは、私たちがよくドメインネームシステムと呼んでいるものです。これは、階層型 DNS サーバーで構成される分散データベースであり、ホストがこの分散データベースにクエリを実行する方法を定義するアプリケーション層プロトコルです。これにより、マシンが直接読み取ることができる IP 番号文字列を覚えていなくても、インターネットに簡単にアクセスできるようになります。

機能: ドメイン名が IP アドレスに解決され、クライアントは DNS サーバーにドメイン名クエリ要求を送信し (DNS サーバーは独自の IP アドレスを持っています)、DNS サーバーはクライアントに Web サーバーの IP アドレスを通知します。。

2. DNS は TCP プロトコルと UDP プロトコルの両方を使用しますか?

DNS はポート 53 を占有し、TCP プロトコルと UDP プロトコルの両方を使用します。
(1) ゾーン転送時に TCP プロトコルを使用する

セカンダリドメインネームサーバーは、データが変更されたかどうかを確認するために、定期的に (通常は 3 時間) プライマリドメインネームサーバーにクエリを実行します。変更があった場合は、データを同期するためにゾーン転送が実行されます。ゾーン転送では、同期的に転送されるデータ量がリクエストで応答できるデータ量よりはるかに大きいため、UDP ではなく TCP が使用されます。
TCP は、データの正確性を保証する信頼性の高い接続です。

(2) ドメイン名解決にはUDPプロトコルを使用

クライアントは DNS サーバーにドメイン名を問い合わせます。返されるコンテンツは通常 512 バイトを超えず、UDP で送信できます。3 ウェイハンドシェイクを行う必要がないため、DNS サーバーの負荷が低くなり、応答が速くなります。理論的には、クライアントは DNS サーバーにクエリを実行するときに TCP を使用するように指定することもできますが、実際には、多数の DNS サーバーが構成されている場合、それらは UDP クエリパケットのみをサポートします。

3. DNS クエリプロセスを完了する

DNS サーバーがドメイン名を解決するプロセス:

まず、ブラウザのキャッシュから対応する IP アドレスを検索します。見つかった場合は直接戻ります。見つからない場合は、次のステップに進みます。
ローカル DNS サーバーにリクエストを送信し、ローカルドメインネームサーバーのキャッシュ内でクエリを実行します。見つかった場合は、検索結果を直接返します。見つからない場合は、次の手順に進みます。
ローカル DNS サーバーはルートドメインネームサーバーにリクエストを送信し、ルートドメインネームサーバーはクエリされたドメインのトップレベルドメインネームサーバーアドレスを返します。
ローカル DNS サーバーはトップレベルドメインネームサーバーにリクエストを送信し、リクエストを受け取ったサーバーは自身のキャッシュを照会し、レコードがあればその結果を返し、レコードがなければ該当するアドレスを返します。次のレベルの権限のあるドメインネームサーバー。
ローカル DNS サーバーは権限のあるドメインネームサーバーにリクエストを送信し、ドメインネームサーバーは対応する結果を返します。
ローカル DNS サーバーは、返された結果を次回使用するためにキャッシュに保存します。
ローカル DNS サーバーは結果をブラウザに返します。

たとえば、www.baidu.comの IPアドレスをクエリしたい場合、まずブラウザのキャッシュにドメイン名のキャッシュがあるかどうかを確認し、存在しない場合はリクエストが送信されます。ローカル DNS サーバーは、ドメイン名が存在するかどうかを判断します。ドメイン名のキャッシュが存在しない場合は、ルートネームサーバーにリクエストが送信され、ルートネームサーバーはトップレベルの名前の IP アドレスのリストを返します。 .com を担当するサーバー。次に、ローカル DNS サーバーは、.com を担当するトップレベルドメインネームサーバーの 1 つにリクエストを送信し、.com を担当するトップレベルドメインネームサーバーは、担当する権威ドメインネームサーバーの IP アドレスリストを返します。 .baiduの。次に、ローカル DNS サーバーが権威ドメインネームサーバーの 1 つにリクエストを送信し、最後に権威ドメインネームサーバーがホスト名に対応する IP アドレスのリストを返します。

4. 反復クエリと再帰クエリ

実際、DNS 解決は、反復クエリと再帰クエリを含むプロセスです。

再帰的クエリとは、クエリ要求が送信された後、ドメインネームサーバーがその代わりに次のレベルのドメインネームサーバーに要求を送信し、最後にクエリの最終結果をユーザーに返すことを意味します。再帰クエリを使用すると、ユーザーはクエリリクエストを 1 回発行するだけで済みます。
反復クエリとは、クエリ要求の後、ドメインネームサーバーが単一のクエリの結果を返すことを意味します。次のレベルのクエリは、ユーザー自身によって要求されます。反復クエリを使用する場合、ユーザーは複数のクエリ要求を発行する必要があります。

一般に、ローカル DNS サーバーにリクエストを送信する方法は再帰的クエリです。これは、リクエストを 1 回送信するだけで済み、その後、ローカル DNS サーバーが最終的なリクエスト結果を返すためです。ローカル DNS サーバーが他のドメインネームサーバーを要求するプロセスは、反復的なクエリプロセスです。ドメインネームサーバーは毎回 1 つのクエリの結果のみを返し、次のレベルのクエリはローカル DNS サーバー自体によって実行されるためです。

5. DNS レコードとメッセージ

DNS サーバーはリソースレコードの形式で情報を保存し、通常、各 DNS 応答メッセージには複数のリソースレコードが含まれます。リソースレコードの具体的な形式は次のとおりです。

（Name，Value，Type，TTL）

このうち、TTL はリソースレコードの有効期間であり、他の DNS サーバーがリソースレコードをキャッシュできる期間を定義します。

一般的に使用される Type 値は、A、NS、CNAME、MX の 4 つです。Type 値が異なれば、対応するリソースレコードの意味も異なります。

Type = A の場合、Name はホスト名、Value はホスト名に対応する IP アドレスです。したがって、A という名前のリソースレコードは、標準のホスト名から IP アドレスへのマッピングを提供します。
Type = NS の場合、Name はドメイン名、Value はドメイン名を担当する DNS サーバーのホスト名です。このレコードは主に、次のレベルでクエリされる DNS サーバーの情報を返す DNS チェーンクエリに使用されます。
Type = CNAME の場合、Name はエイリアス、Value はホストの正規のホスト名です。このレコードは、ホスト名に対応する正規のホスト名をクエリ元のホストに返し、クエリ元のホストにホスト名の IP アドレスをクエリするように指示するために使用されます。ホストエイリアスの主な目的は、複雑なホスト名をいくつか指定することで、覚えやすい単純なエイリアスを提供することです。
Type = MX の場合、Name はメールサーバーのエイリアス、Value はメールサーバーの正規のホスト名です。その機能は CNAME の機能と同じであり、どちらも正規のホスト名がメモリに貢献しないという欠点を解決するものです。

5. ネットワークモデル

1. OSI 7 層モデル

ISOネットワークアプリケーションをより普及させるために、OSIリファレンスモデルが導入されています。

(1) アプリケーション層

OSI参照モデルの中でユーザーに最も近い層は、コンピュータユーザーにアプリケーションインターフェイスを提供し、ユーザーにさまざまなネットワークサービスを直接提供します。一般的なアプリケーション層ネットワークサービスプロトコルはHTTP、、、、、などです。HTTPSFTPPOP3SMTP

多くの場合、クライアントとサーバーでデータ要求が発生し、この時点で使用されたり、http(hyper text transfer protocol)(超文本传输协议)バックhttpsエンドでデータインターフェイスを設計するときにこのプロトコルがよく使用されます。
FTPこれはファイル転送プロトコルであり、私は開発プロセスに個人的には関与していませんが、たとえば一部のリソース Web サイトは百度网盘``迅雷このプロトコルに基づいているべきだと思います。
SMTPはいsimple mail transfer protocol（简单邮件传输协议）。プロジェクトでは、このプロトコルはユーザーのメールボックス検証コードログインの機能で使用されます。

(2) プレゼンテーション層

プレゼンテーション層は、アプリケーション層データのさまざまなエンコードおよび変換機能を提供し、あるシステムのアプリケーション層によって送信されたデータが別のシステムのアプリケーション層によって確実に認識されるようにします。この層は、必要に応じて、コンピュータ内のさまざまなデータ形式を通信で使用される標準表現に変換するための標準表現を提供します。データ圧縮と暗号化も、プレゼンテーション層が提供できる変換機能の 1 つです。

プロジェクト開発では、データ送信を容易にするために、base64データをエンコードおよびデコードするために使用できます。機能ごとに分けるとbase64プレゼンテーション層で動作するはずです。

(3) セッション層

セッション層は、プレゼンテーション層エンティティ間の通信セッションの確立、管理、終了を担当します。この層での通信は、異なるデバイスのアプリケーション間のサービス要求と応答で構成されます。

(4) トランスポート層

トランスポート層は、ホストのエンドツーエンドのリンクを確立します。トランスポート層の役割は、エラー制御などの問題の処理を含め、上位層プロトコルにエンドツーエンドの信頼性が高く透過的なデータ送信サービスを提供することです。そしてフロー制御。この層は、下位層のデータ通信の詳細を上位層から保護するため、上位層のユーザーには、ユーザーが制御および設定できる 2 つの送信エンティティ間のホストからホストへの信頼できるデータパスのみが表示されます。私たちが普段言っていることはTCP UDPこのレベルです。ここではポート番号が両方とも「終わり」です。

(5) ネットワーク層

この層は、IPアドレス指定を通じて 2 つのノード間の接続を確立し、送信元のトランスポート層によって送信されたパケットに対して適切なルーティングノードとスイッチングノードを選択し、それらのパケットを宛先のトランスポート層にエラーなく送信します。通常レイヤーと言われますIP。この層は、私たちがよくIPプロトコル層と呼ぶものです。IP合意がInternet基礎です。ネットワーク層はデータパケットの伝送経路を指定し、トランスポート層はデータパケットの伝送方法を指定することがわかります。

(6) データリンク層

ビットをバイトに結合し、バイトをフレームに組み立て、リンク層アドレス (イーサネットは MAC アドレスを使用) を使用してメディアにアクセスし、エラー検出を実行します。
ネットワーク層とデータリンク層を比較すると、上記の説明から、ネットワーク層がデータパケットの伝送経路を計画し、データリンク層が伝送経路であることが理解できよう。ただし、データリンク層にもエラー制御の機能が追加されます。

(7) 物理層

実際の最終信号の伝送は物理層を通じて実現されます。物理メディアを介したビットストリームの送信。レベル、速度、ケーブルのピン配置を指定します。一般的に使用されるデバイスには、(さまざまな物理デバイス) ハブ、リピータ、モデム、ネットワークケーブル、ツイストペアケーブル、および同軸ケーブルがあります。これらは物理層の伝送媒体です。

OSI 7 層モデルの通信特性: ピアツーピア
通信ピアツーピア通信では、送信元から宛先にデータパケットを送信するには、送信元の OSI モデルの各層がピアと通信する必要があります。この通信方式をピアツーピア通信といいます。各層の通信プロセスでは、独自のプロトコルを使用して通信します。

2. TCP/IP 5層プロトコル

TCP/IP5 層プロトコルとOSI7 層プロトコルの対応関係は次のとおりです。

アプリケーション層 (アプリケーション層) : アプリケーションプロセスにサービスを直接提供します。アプリケーション層プロトコルは、アプリケーションプロセス間の通信と対話のルールを定義します。HTTP プロトコル (World Wide Web サービス)、FTP プロトコル (ファイル転送)、SMTP プロトコル (電子メール)、DNS (ドメイン) など、アプリケーションごとに異なるアプリケーション層プロトコルがあります。名前クエリ）など
トランスポート層 (トランスポート層) : トランスポート層と訳されることもあり、2 つのホスト内のプロセスに通信サービスを提供する役割を果たします。この層には主に次の 2 つのプロトコルがあります。
- 伝送制御プロトコル (TCP): コネクション型で信頼性の高いデータ伝送サービスを提供します。データ伝送の基本単位はセグメントです。
- ユーザーデータグラムプロトコル (UDP): コネクションレス型のベストエフォート型のデータ送信サービスを提供しますが、データ送信の信頼性は保証されません。データ送信の基本単位はユーザーデータグラムです。
インターネット層: インターネット層と訳されることもあり、2 つのホストに通信サービスを提供し、適切なルートを選択してターゲットホストにデータを転送する役割を果たします。
データリンク層 (データリンク層) : ネットワーク層から渡された IP データグラムをフレームにカプセル化して、リンクの隣接する 2 つのノード間でフレームを送信する役割を果たします。各フレームにはデータと必要な制御情報 (同期情報、アドレス情報など) が含まれます。、エラー制御など）。
物理層: さまざまな物理メディア上でデータを送信できることを保証し、データ送信のための信頼できる環境を提供します。

上の図からわかるように、モデルはモデルTCP/IPよりもOSI簡潔であり、应用层/表示层/会话层すべてが統合されています应用层。

各層ではさまざまなデバイスが動作し、たとえば、一般的に使用されるスイッチはデータリンク層で動作し、一般的なルーターはネットワーク層で動作します。

各層で実装されるプロトコルも異なります。つまり、各層のサービスも異なります。次の図は、各層の主な伝送プロトコルを示しています。

同様に、TCP/IP5 層プロトコルの通信モードはピアツーピア通信です。
画像.png

6. TCPとUDP

1. TCPとUDPの概念と特徴

TCP と UDP はどちらもトランスポート層プロトコルであり、どちらも TCP/IP プロトコルファミリに属します。

（1）UDP

UDP の正式名はUser Datagram Protocolで、ネットワーク内の TCP プロトコルと同じ方法でデータパケットを処理するために使用され、コネクションレス型プロトコルです。OSI モデルでは、トランスポート層は IP プロトコルの上位層にあります。UDP には、データパケットのグループ化、組み立て、並べ替えができないという欠点があります。つまり、メッセージが送信された後、メッセージが安全かつ完全に到着したかどうかを知ることが不可能です。

その特徴は次のとおりです。

1) コネクションレス指向

まず、UDP は TCP のようにデータを送信する前に 3 ウェイハンドシェイクを実行して接続を確立する必要がなく、データを送信したい場合に送信を開始できます。また、これはデータメッセージのポーターにすぎず、データメッセージの分割や結合操作は実行しません。

具体的には：

送信側では、アプリケーション層からトランスポート層の UDP プロトコルにデータが渡され、UDP はデータに UDP プロトコルを識別するための UDP ヘッダーを付加するだけでネットワーク層に渡します。
受信側では、ネットワーク層がデータをトランスポート層に渡し、UDP は IP ヘッダーのみを削除して、スプライシング操作を行わずにアプリケーション層に渡します。

2) ユニキャスト、マルチキャスト、ブロードキャスト機能があります

UDP は 1 対 1 の送信モードをサポートするだけでなく、1 対多、多対多、および多対 1 モードもサポートします。つまり、UDP はユニキャスト、マルチキャスト、およびブロードキャスト機能を提供します。

3) メッセージ指向

送信者の UDP はメッセージをアプリケーションプログラムに送信し、ヘッダーを追加した後、IP 層に配信します。UDP は、アプリケーション層によって配信されたパケットをマージも分割もせず、これらのパケットの境界を保持します。したがって、アプリケーションはメッセージの適切なサイズを選択する必要があります。

4) 信頼性の低さ

まず、信頼性の低さは、接続がないという事実に表れますが、通信は接続を確立する必要がなく、必要なときにすぐに送信できるため、このような状況は間違いなく信頼性が低くなります。

そして、受信したデータは何でも送信し、データをバックアップすることはなく、データを送信するときに相手がデータを正しく受信したかどうかは気にしません。

また、ネットワーク環境の良し悪しはありますが、UDPには輻輳制御がないため、常に一定の速度でデータが送信されます。ネットワーク状態が悪い場合でも送信レートは調整されません。この実装の欠点は、ネットワーク状態が良くない場合にパケット損失が発生する可能性があることですが、利点も明らかです。リアルタイム要件が高い一部のシナリオ (電話会議など) では、代わりに UDP を使用する必要があります。 TCP。

5) ヘッドのオーバーヘッドが小さく、データパケットの送信時に非常に効率的です。

UDP ヘッダーには次のデータが含まれます。

2 つの 16 ビットポート番号。送信元ポート (オプションフィールド) と宛先ポートです。
データグラム全体の長さ
データグラム全体のチェックサム (IPv4 のオプションフィールド)。ヘッダー情報とデータのエラーを検出するために使用されます。

したがって、UDP のヘッダーオーバーヘッドは小さく、わずか 8 バイトであり、TCP の少なくとも 20 バイトよりもはるかに少なく、データパケットの送信時に非常に効率的です。

(2) TCP TCP
の正式名称は Transmission Control Protocol であり、コネクション指向で信頼性の高いバイトストリームベースのトランスポート層通信プロトコルです。TCP は、接続指向で信頼性の高いストリームプロトコルです (ストリームは中断のないデータ構造です)。

次のような特徴があります。

1) コネクション指向

接続指向とは、データを送信する前に両端で接続を確立する必要があることを意味します。接続の確立方法は、確実な接続が可能な「3ウェイハンドシェイク」を採用しています。接続を確立すると、信頼性の高いデータ送信の基礎が築かれます。

2) ユニキャスト送信のみをサポートします

各 TCP 送信接続はエンドポイントを 2 つだけ持つことができ、ポイントツーポイントデータ送信のみを実行でき、マルチキャストおよびブロードキャスト送信方法はサポートしません。

3) バイトストリーム指向

UDP とは異なり、TCP は個々のパケットを独立して送信せず、パケット境界を保持せずにバイトストリームで送信します。

4) 確実な伝送

確実な伝送のため、パケットロスやビットエラーの判定はTCPのセグメント番号と確認番号に依存します。メッセージ送信の信頼性を確保するために、TCP は各パケットにシーケンス番号を与えます。また、このシーケンス番号により、受信側エンティティに送信されたパケットの連続受信も保証されます。次に、受信側エンティティは、正常に受信したバイトに対して対応する確認応答 (ACK) を送り返します。送信側エンティティが適切な往復遅延 (RTT) 以内に確認応答を受信しない場合、対応するデータ (失われたとみなされる) は失われます。再送信されました。

5) 輻輳制御の提供

ネットワークが輻輳している場合、TCP はネットワークに注入されるデータの速度と量を減らして輻輳を緩和します。

6) 全二重通信の提供

TCP 接続の両端には双方向通信用のデータを一時的に保存するバッファがあるため、TCP を使用すると、通信の両側のアプリケーションがいつでもデータを送信できます。もちろん、TCP はデータセグメントをすぐに送信することも、一定期間バッファしてより多くのデータセグメントを一度に送信することもできます (最大データセグメントサイズは MSS によって異なります)。

2. TCPとUDPの違い

	UDP	TCP
繋がってるのかな	接続がありません	接続指向
信頼できますか	信頼性の低い送信、フロー制御と輻輳制御の使用なし	フロー制御と輻輳制御を使用した、信頼性の高い配信 (データの順序と正確さ)
接続オブジェクトの数	1対1、1対多、多対1、多対多のインタラクティブな通信をサポート	1対1のコミュニケーションのみ
転送方法	メッセージ指向	ストリーム指向
頭のオーバーヘッド	ヘッダーのオーバーヘッドは小さく、わずか 8 バイトです	ヘッダーの最小値は 20 バイト、最大値は 60 バイトです
該当シーン	ビデオ会議、ライブブロードキャストなどのリアルタイムアプリケーションに最適	ファイル転送など、信頼性の高い転送が必要なアプリケーションに適しています。

3. TCPとUDPの利用シナリオ

TCP アプリケーションシナリオ:効率要件は比較的低いが、精度要件は比較的高いシナリオ。送信時にはデータの確認や再送、並び替えなどの操作が必要となるため、UDPほど効率は高くありません。例: ファイル転送 (高精度で要件は高いですが、速度が比較的遅い場合があります)、メールの受信、リモートログイン。
UDP アプリケーションシナリオ:比較的高い効率要件と比較的低い精度要件を持つシナリオ。例: QQ チャット、オンラインビデオ、VoIP (インスタントメッセージング、高速要件。ただし、時折の中断は大きな問題ではなく、ここでは再送信メカニズムは使用できません)、ブロードキャスト通信 (ブロードキャスト、マルチキャスト)。

4. UDP プロトコルはなぜ信頼できないのですか?

UDP はデータを送信する前に接続を確立する必要がなく、リモートホストのトランスポート層は UDP メッセージの受信後に確認する必要がないため、配信の信頼性が低くなります。要点をまとめると以下の4点になります。

メッセージ配信の保証なし: 確認応答なし、再送信なし、タイムアウトなし
配信順序は保証されません。パケットシーケンス番号は設定されず、並べ替えも行われず、フロントオブラインブロッキングも発生しません。
接続状態を追跡しません。接続を確立したり、ステートマシンを再起動したりする必要はありません。
輻輳制御なし: 組み込みのクライアントまたはネットワークフィードバックメカニズムなし

5. TCP 再送信メカニズム

TCP の基礎となるネットワーク (ネットワーク層) は紛失、重複、または故障する可能性があるため、TCP プロトコルは信頼性の高いデータ送信サービスを提供します。データ送信の正確性を保証するために、TCP は失われたと思われるパケット (メッセージ内のビットエラーを含む) を再送信します。TCP は 2 つの独立したメカニズムを使用して再送信を完了します。1 つは時間に基づき、もう 1 つは確認情報に基づきます。

TCPはデータ送信後タイマーを起動し、時間内にデータ送信に対するACK確認メッセージを受信できない場合はメッセージを再送し、一定回数に達すると諦めてメッセージを送信します。成功しないとリセット信号が発生します。

6. TCP輻輳制御メカニズム

TCP の輻輳制御メカニズムには主に次の 4 つのメカニズムがあります。

スロースタート (スロースタート)
渋滞回避
高速再送信
迅速な回復

(1) スロースタート(スロースタート)

送信開始時に cwnd = 1 を設定します (cwnd は輻輳ウィンドウを指します)
アイデア: 最初から大量のデータを送信せず、最初にネットワークの輻輳レベルをテストし、輻輳ウィンドウのサイズを小さいものから大きいものに増やします。
cwndの過剰な増大によるネットワークの輻輳を防ぐため、スロースタート閾値(ssthresh状態変数)を設定します。
- cnwd < ssthresh の場合、スロースタートアルゴリズムを使用します。
- cnwd = ssthresh の場合、スロースタートアルゴリズムまたは輻輳回避アルゴリズムのいずれかを使用できます。
- cnwd > ssthresh の場合、輻輳回避アルゴリズムを使用する

(2) 渋滞の回避

輻輳回避では輻輳を完全に回避できない場合がありますが、これは、輻輳回避フェーズ中に輻輳ウィンドウが直線的に増加するように制御され、ネットワークが輻輳しにくくなるということを意味します。
アイデア: 輻輳ウィンドウ cwnd をゆっくりと増加させます。つまり、戻り時間 RTT が経過するたびに送信側の輻輳制御ウィンドウを増加させます。
スロースタートフェーズでも輻輳回避フェーズでも、送信側がネットワークが輻輳していると判断する限り、スロースタート閾値は輻輳発生時の送信ウィンドウサイズの半分に設定されます。次に、輻輳ウィンドウを 1 に設定し、スロースタートアルゴリズムを実行します。図に示すように

、ネットワークが混雑していると判断する根拠は、アクノリッジメントが受信されないことであるが、アクノレッジメントが受信できないのは他の理由によるパケットロスである可能性もあるが、判断できないため、すべて輻輳として扱われます。

(3) 高速再送信

高速再送信では、受信者は、順序がずれたセグメントを受信した直後に確認応答を繰り返し送信する必要があります (セグメントが相手に届いていないことを送信者に早く知らせるため)。送信者は、3 回連続して繰り返される確認応答を受信する限り、設定された再送信タイマーが期限切れになるのを待ち続けることなく、相手方がまだ受信していないメッセージセグメントを直ちに再送信します。
設定された再送信タイマーが期限切れになるのを待つ必要がないため、未確認のメッセージセグメントをできるだけ早く再送信でき、ネットワーク全体のスループットが向上します。

(4) 素早い回復

送信者が 3 回連続して繰り返される確認を受信すると、「乗算削減」アルゴリズムを実行して ssthresh しきい値を半分にします。ただし、スロースタートアルゴリズムは実行されません。
ネットワークが輻輳している場合、複数の重複した確認応答を受信しないことを考慮すると、送信者はネットワークが輻輳していないと考えるようになります。したがって、この時点ではスロースタートアルゴリズムは実行されませんが、cwnd が ssthresh のサイズに設定されてから、輻輳回避アルゴリズムが実行されます。

7. TCPフロー制御メカニズム

一般に、フロー制御は、受信者が時間内にデータを受信できるように、送信者がデータをあまりにも速く送信するのを防ぐことです。TCP はフロー制御に可変サイズのスライディングウィンドウを使用し、ウィンドウサイズの単位はバイトです。ここで言うウィンドウサイズとは、実際には毎回送信されるデータのサイズです。

接続が確立されると、接続の各端は受信データを保持するためのバッファを割り当て、バッファのサイズをもう一方の端に送信します。
データが到着すると、受信側は残りのバッファサイズを含む確認応答を送信します。(残りのバッファスペースのサイズはウィンドウと呼ばれ、ウィンドウのサイズを示す通知はウィンドウアドバタイズメントと呼ばれます。受信者は送信するすべての確認応答にウィンドウアドバタイズメントを含めます。)
受信側アプリケーションがデータが到着するのと同じ速さでデータを読み取ることができる場合、受信側は確認応答ごとにポジティブウィンドウ通知を送信します。
送信側が受信側よりも高速に動作する場合、受信データは最終的に受信側のバッファを満たし、受信側がゼロウィンドウをアドバタイズすることになります。送信者がゼロウィンドウアドバタイズメントを受信した場合、受信者がポジティブウィンドウを再度アドバタイズするまで送信を停止する必要があります。

8. TCPの信頼できる送信メカニズム

TCP の信頼性の高い送信メカニズムは、連続 ARQ プロトコルとスライディングウィンドウプロトコルに基づいています。

TCP プロトコルは、送信側で送信ウィンドウを維持します。送信ウィンドウの前のメッセージセグメントは、送信され確認されたメッセージセグメントです。送信ウィンドウの後のメッセージセグメントは、キャッシュ内で送信が許可されていないメッセージセグメントです。。送信者が受信者にメッセージを送信すると、ウィンドウ内のすべてのメッセージセグメントが順番に送信され、タイマーが設定されます。これは、送信されたものの確認が受信されなかった最も早いメッセージセグメントとして理解できます。タイマー時間内に特定のメッセージセグメントの確認応答を受信した場合、ウィンドウをスライドさせ、確認メッセージセグメントの最後の位置までウィンドウの先頭を後方にスライドさせ、メッセージセグメントが存在しない場合は、ウィンドウの先頭をリセットします。タイマーをオンにし、それ以上ない場合はタイマーをオフにします。タイマーが期限切れになった場合は、送信したが確認を受信していないすべてのメッセージセグメントを再送信し、タイムアウト間隔を前回の 2 倍に設定します。送信者が受信者から 3 つの冗長な確認応答を受信した場合、これはこのメッセージセグメントの後のメッセージセグメントが失われる可能性があることを示します。その場合、送信者は高速再送信メカニズムを有効にします。つまり、送信済みで確認済みのセグメントをすべて送信します。現在のタイマーが期限切れになります。

受信者は累積確認応答メカニズムを使用し、順番に到着するすべてのメッセージセグメントに対して、メッセージセグメントの肯定応答を返します。順序が乱れたセグメントを受信した場合、受信側はそれを破棄し、順序通りに到着した最新のセグメントに肯定応答を返します。累積確認を使用すると、返された確認番号よりも前のメッセージセグメントが順番に到着していることが保証されるため、送信ウィンドウを確認済みメッセージセグメントの後ろに移動できます。

送信ウィンドウのサイズは可変で、受信ウィンドウの残りのサイズとネットワークの混雑度によって決定され、TCP は送信ウィンドウの長さを制御することでメッセージセグメントの送信速度を制御します。

しかし、TCP プロトコルはスライディングウィンドウプロトコルとまったく同じではありません。多くの TCP 実装は順序が乱れたセグメントをキャッシュし、再送信が発生した場合には 1 つのセグメントのみが再送信されるため、TCP プロトコルの信頼できる送信メカニズムは機能しません。これは、ウィンドウスライディングプロトコルと選択的再送信プロトコルのハイブリッドに似ています。

9. TCP の 3 ウェイハンドシェイクと 4 ウェイウェーブ

(1) スリーウェイハンドシェイク

スリーウェイハンドシェイク (スリーウェイハンドシェイク) とは、実際には、TCP 接続を確立するときに、クライアントとサーバーが合計 3 つのパケットを送信する必要があることを意味します。3 ウェイハンドシェイクの主な機能は、双方の送受信能力が正常であるかどうかを確認し、その後の信頼性の高い送信に備えて独自の初期化シーケンス番号を指定することです。要は、サーバーの指定ポートに接続してTCP接続を確立し、双方のシリアル番号や確認番号を同期し、TCPウィンドウサイズ情報を交換するというものです。

最初は、クライアントはクローズ状態にあり、サーバーはリッスン状態にあります。

最初のハンドシェイク: クライアントはサーバーに SYN メッセージを送信し、クライアントの初期化シリアル番号 ISN を示します。この時点でクライアントは SYN_SEND 状態にあります。

ヘッダーの同期ビットは SYN=1、初期シーケンス番号は seq=x、SYN=1 のメッセージセグメントはデータを運ぶことができませんが、シーケンス番号が消費されます。

2 番目のハンドシェイク: クライアントから SYN メッセージを受信した後、サーバーは独自の SYN メッセージで応答し、独自の初期化シーケンス番号 ISN も指定します。同時に、クライアントの ISN + 1 が ACK 値として使用され、クライアントの SYN を受信し、サーバーが SYN_REVD 状態にあることを示します。

確認セグメントでは、SYN=1、ACK=1、確認番号ack=x+1、初期シーケンス番号seq=y

3 番目のハンドシェイク: クライアントは SYN メッセージを受信した後、ACK メッセージを送信します。もちろん、サーバーの ISN + 1 を ACK の値として使用し、サーバーから SYN メッセージを受信したことを示します。今回、クライアントは ESTABLISHED 状態にあります。サーバーが ACK メッセージを受信した後も ESTABLISHED 状態になり、この時点で両者は接続を確立します。

確認メッセージセグメント ACK=1、確認番号 ack=y+1、シーケンス番号 seq=x+1 (初期値は seq=x であるため、2 番目のメッセージセグメントは +1 である必要があります)、ACK メッセージセグメントはデータの搬送、なしデータの搬送はシリアル番号を消費しません。

では、なぜスリーウェイハンドシェイクなのでしょうか？2回はできないの？

双方の送受信能力が正常であることを確認するため
2 つのハンドシェイクが使用される場合、次の状況が発生します。

クライアントが接続要求を送信したが、接続要求メッセージの損失により確認応答を受信しなかった場合、クライアントは接続要求を再度再送信します。その後確認が受信され、接続が確立されました。データ送信が完了すると、接続が解放され、クライアントは 2 つの接続要求セグメントを送信します。最初のセグメントは失われ、2 番目のセグメントはサーバーに到達します。ただし、最初の失われたセグメントは一部のセグメントにのみ存在します。ネットワークノードは一定期間留まります。長い時間がかかり、接続が解放されてからサーバーに到達するまでに一定の時間がかかりますが、このときサーバーはクライアントが新しい接続要求を送信したと誤って認識するため、クライアントに確認メッセージセグメントを送信して同意します。接続の確立には 3 ウェイハンドシェイクは使用されません。サーバーが確認を送信する限り、新しい接続が確立されます。このとき、クライアントはサーバーから送信される確認を無視し、データを送信しません。サーバーはクライアントがデータを送信するのを待ち、リソースを無駄にします。

簡単に言うと以下の3ステップです。

最初のハンドシェイク:クライアントは接続要求セグメントをサーバーに送信します。このメッセージセグメントには、独自のデータ通信の初期シーケンス番号が含まれます。リクエストが送信されると、クライアントは SYN-SENT 状態に入ります。
2 回目のハンドシェイク:接続要求セグメントを受信した後、サーバーが接続に同意すると、サーバーは独自のデータ通信の初期シーケンス番号も含む応答を送信し、送信後に SYN-RECEIVED 状態に入ります。
3 回目のハンドシェイク:クライアントは接続許可書の応答を受信すると、確認メッセージもサーバーに送信します。クライアントはこのメッセージセグメントの送信後に ESTABLISHED 状態になり、サーバーも応答の受信後に ESTABLISHED 状態になり、この時点で接続が正常に確立されます。

TCP スリーウェイハンドシェイクにおけるコネクション確立のプロセスは、初期シーケンス番号を相互に確認し、どのシーケンス番号のセグメントが正しく受信できるかを相手に伝えるプロセスです。3 回目のハンドシェイクの機能は、クライアントがサーバーの最初のシーケンス番号を確認することです。ハンドシェイクが 2 回だけ使用される場合、サーバーはシーケンス番号が確認されたかどうかを知る方法がありません。同時に、これは無効なリクエストセグメントがサーバーによって受信されてエラーが発生するのを防ぐためでもあります。

(2) 4回振る

クライアントが最初にシャットダウン要求を開始した場合、最初は両方の当事者が ESTABLISHED 状態にあります。4 波のプロセスは次のとおりです。

最初のウェーブ: クライアントは FIN メッセージを送信し、メッセージ内にシーケンス番号が指定されます。この時点で、クライアントは FIN_WAIT1 状態になります。

つまり、接続解放セグメント (FIN=1、シーケンス番号 seq=u) を送信し、データの送信を停止し、TCP 接続を積極的に閉じ、FIN_WAIT1 (終了待ち 1) 状態に入り、サーバーの確認を待ちます。

第 2 の波: FIN を受信した後、サーバーは ACK メッセージを送信し、クライアントのシリアル番号の値 + 1 を ACK メッセージのシリアル番号の値として使用し、クライアントからのメッセージが受信されたことを示します。今度は、サーバーは CLOSE_WAIT 状態になります。

つまり、サーバーは接続解放メッセージセグメントを受信した後、確認メッセージセグメント (ACK=1、確認番号 ack=u+1、シーケンス番号 seq=v) を送信し、サーバーは CLOSE_WAIT (クローズ待機) 状態に入ります。このとき、TCPはハーフクローズ状態となり、クライアントからサーバーへのコネクションが解放されます。サーバーからの確認を受信した後、クライアントは FIN_WAIT2 (終了待機 2) 状態に入り、サーバーから送信される接続解放セグメントを待ちます。

3 番目の波: サーバーも切断したい場合は、クライアントの最初の波と同様に、FIN メッセージを送信し、シリアル番号を指定します。このとき、サーバーは LAST_ACK の状態になります。

つまり、サーバーにはクライアントに送信するデータがなく、サーバーは接続解放セグメント (FIN=1、ACK=1、シリアル番号 seq=w、確認番号 ack=u+1) を送信し、サーバーは LAST_ACK に入ります。 (最終確認) クライアントからの確認を待っている状態。

第 4 の波: FIN を受信したクライアントは、応答として ACK メッセージも送信し、サーバーのシリアル番号の値 + 1 を自身の ACK メッセージのシリアル番号の値として使用します。 TIME_WAIT 状態。サーバーが自身の ACK メッセージを受信した後、確実に CLOSED 状態になるまでには時間がかかります。サーバーは ACK メッセージを受信した後、接続を閉じて CLOSED 状態になります。

つまり、クライアントはサーバーから接続解放メッセージセグメントを受信した後、確認応答メッセージセグメント (ACK=1、seq=u+1、ack=w+1) を送信し、クライアントは TIME_WAIT (待機時間) に入ります。州。このとき、TCPは解放されておらず、クライアントは時間待ちタイマで設定された時間2MSL経過後にCLOSED状態となる。

では、なぜ4回手を振る必要があるのでしょうか？

これは、サーバーがクライアントから SYN 接続要求メッセージを受信したときに、SYN+ACK メッセージを直接送信できるためです。このうち、ACKメッセージは応答に使用され、SYNメッセージは同期に使用されます。ただし、接続が閉じられているとき、サーバーが FIN メッセージを受信したときに、SOCKET がすぐに閉じられない可能性があるため、最初に ACK メッセージを返信して、クライアントに「送信された FIN メッセージを受信しました」と伝えることしかできません。サーバー上のすべてのメッセージが送信された後にのみ FIN メッセージを送信できるため、一緒に送信することはできず、手を 4 回振る必要があります。

簡単に言うと以下の4ステップです。

最初の波:クライアントがデータが送信されたと考えた場合、サーバーに接続解放リクエストを送信する必要があります。
第 2 波: 接続解放要求を受信した後、サーバーはアプリケーション層に TCP 接続を解放するように指示します。その後、ACK パケットを送信し、CLOSE_WAIT 状態に入ります。これは、クライアントからサーバーへの接続が解放され、クライアントによって送信されたデータが受信されなくなることを示します。ただし、TCP 接続は双方向であるため、サーバーは引き続きクライアントにデータを送信できます。
第 3 の波: この時点でサーバーに未完了のデータがある場合は送信を続け、完了後、クライアントに接続解放要求を送信し、サーバーは LAST-ACK 状態になります。
第 4 の波:解放要求を受信した後、クライアントはサーバーに確認応答を送信し、クライアントは TIME-WAIT 状態に入ります。この状態は 2MSL (最大セグメント存続期間。メッセージセグメントがネットワーク内で存続し、タイムアウト後に破棄される時間を指します) の間続きます。この期間内にサーバーからの再送信要求がない場合、メッセージセグメントは次の状態になります。 CLOSED状態。サーバーは確認応答を受信すると、CLOSED 状態になります。

TCP が 4 つの波を使用する理由は、TCP 接続が全二重であるため、双方が相手側への接続を個別に解放する必要があるためです。一方の接続だけが解放されると、データを送信できなくなります。相手に接続され、接続が半解放された状態になります。

クライアントが最後のウェーブの後に閉じるまで一定期間待機する理由は、サーバーに送信された確認セグメントが失われたり間違っていたりして、サーバーが正常に閉じられなくなることを防ぐためです。

10. TCP スティッキーパケットとは何ですか?またその対処方法は何ですか?

デフォルトでは、TCP 接続は遅延配信アルゴリズム (Nagle アルゴリズム) を有効にし、データを送信する前にキャッシュします。短期間に複数のデータを送信する場合、それらは 1 回の送信用にまとめてバッファリングされます (バッファサイズ)。これにより、IO 消費量が削減され、パフォーマンスが向上します。

ファイルを転送するのであれば、粘着パッケージの問題に対処する必要はまったくなく、1 つのパッケージと 1 つのパッケージを結合するだけで十分です。ただし、複数のメッセージや他の目的のデータの場合は、スティッキーパケットを処理する必要があります。

例を見てみましょう. send を 2 回続けて呼び出して、2 つのデータ data1 と data2 をそれぞれ送信します. 受信側では次のような一般的な状況があります: A. 最初に data1 を受信し、次に data2 を受信します。 B. 最初に受信します
受信
部分data1 のデータを一度に受信し、次に data1 の残りと data2 のすべてを受信
C. まず data1 のデータをすべて受信し、data2 の一部を受信し、次に data2 の残りを受信 D.
data1 と data2 の全データを一度に受信データ２．

その中でも、BCD は粘着性パッケージの一般的な状況であり、粘着性パッケージの問題に対処するための一般的な解決策は次のとおりです。

複数回送信するまでに待ち時間があり、一定時間待ってから次回送信するため、特にやり取り頻度が低いシナリオに適していますが、頻度が高いシナリオではデメリットも明らかです送信効率が低すぎる, ただし加工はほとんど必要ありません。
Nagle アルゴリズムをオフにする: Nagle アルゴリズムをオフにします。Node.js では、socket.setNoDelay() メソッドを通じて Nagle アルゴリズムをオフにできるため、各送信はバッファリングせずに直接送信されます。この方法は、毎回送信されるデータが比較的大きく (ただし、ファイルほど大きくない)、頻度がそれほど高くないシナリオに適しています。毎回送信されるデータの量が比較的少なく、頻度が特に高い場合、Nagle をオフにすることは完全に自滅的です。また、Nagle アルゴリズムはサーバー側で実行されるパッケージの組み合わせであるため、この方法はネットワーク状態が悪い場合には適していませんが、クライアントのネットワーク状態が短期間に良くない場合や、アプリケーション層の影響により、何らかの理由で、TCP データを時間内に受信できないと、複数のパケットがクライアント側でバッファリングされ、スティッキーパケットが発生します。(通信が安定したコンピュータ室であれば、この可能性は比較的小さいため無視できます)
梱包/開梱:梱包/開梱は業界では一般的なソリューションです。つまり、各データパケットを送信する前に、その前後に何らかの特徴的なデータを配置し、データを受信するときにその特徴的なデータに従って各データパケットを分割します。

11. udp がパケットを固定しないのはなぜですか?

TCP プロトコルはストリーム指向のプロトコルであり、UDP はメッセージ指向のプロトコルです。UDP セグメントはメッセージであり、アプリケーションはメッセージ単位でデータを抽出する必要があり、一度にデータバイトを抽出することはできません。
UDP には保護メッセージ境界があり、各 UDP パケットにはメッセージヘッダー (情報ソースアドレス、ポートなど) があり、受信側での区別と処理が容易になります。伝送プロトコルはインターネット上でデータを独立したメッセージとして送信し、受信側は独立したメッセージのみを受信できます。受信側は、送信側が送信するデータパケットを一度に1パケットしか受信できません、受信したデータのサイズが送信側が一度に送信するデータのサイズより小さい場合、データの一部が失われます紛失しても受け取り側では問題ありません 2回に分けて受け取ります。

7. ウェブソケット

1. WebSocketの理解

WebSocket は、ブラウザとサーバー間の全二重通信のために HTML5 によって提供されるネットワークテクノロジであり、アプリケーション層プロトコルに属します。これは TCP トランスポートプロトコルに基づいており、HTTP ハンドシェイクチャネルを再利用します。ブラウザとサーバーはハンドシェイクを完了するだけで、両者の間に永続的な接続を直接作成でき、双方向のデータ送信を実行できます。

WebSocket の登場により、半二重通信の欠点が解決されました。最大の特徴は、サーバーがクライアントにメッセージをアクティブにプッシュでき、クライアントもサーバーにメッセージをアクティブにプッシュできることです。

WebSocket の原則: クライアントはすべての受信者 ID (受信者 ID) を持つイベント (イベント) を WebSocket サーバーに通知 (通知) し、サーバーは受信後すぐにすべてのアクティブ (アクティブ) クライアントに通知します。受信者 ID には ID のみが含まれます。シーケンスのクライアントがこのイベントを処理します。

WebSocketの特徴は以下の通りです。

双方向通信をサポートし、よりリアルタイムなパフォーマンスを実現
テキストまたはバイナリデータを送信できます。」
TCP プロトコルに基づいているため、サーバーの実装は比較的簡単です
データ形式が比較的軽く、パフォーマンスのオーバーヘッドが小さく、通信が効率的です。
同一オリジンの制限はなく、クライアントは任意のサーバーと通信できます。
プロトコル識別子は ws (暗号化されている場合は wss) で、サーバー URL は URL です。
HTTPプロトコルとの互換性が良好です。デフォルトのポートも 80 と 443 で、ハンドシェイクフェーズでは HTTP プロトコルが使用されるため、ハンドシェイク中にシールドするのは容易ではなく、さまざまな HTTP プロキシサーバーを通過できます。

Websocketの使い方は以下の通りです
。

クライアントでは:

// 在index.html中直接写WebSocket，设置服务端的端口号为 9999
let ws = new WebSocket('ws://localhost:9999');
// 在客户端与服务端建立连接后触发
ws.onopen = function() {
    
    
    console.log("Connection open."); 
    ws.send('hello');
};
// 在服务端给客户端发来消息的时候触发
ws.onmessage = function(res) {
    
    
    console.log(res);       // 打印的是MessageEvent对象
    console.log(res.data);  // 打印的是收到的消息
};
// 在客户端与服务端建立关闭后触发
ws.onclose = function(evt) {
    
    
  console.log("Connection closed.");
};

2. インスタントメッセージングの実現: ショートポーリング、ロングポーリング、SSE、WebSocket の違いは?

ショートポーリングとロングポーリングの目的は、クライアントとサーバー間の即時通信を実現することです。

ショートポーリングの基本的な考え方:ブラウザーは時々 http リクエストをブラウザーに送信し、サーバーはデータの更新があるかどうかに関係なく、リクエストを受信した後に直接応答します。このように実装されたインスタントメッセージングは、基本的にブラウザがリクエストを送信し、サーバーがリクエストを受け取るというプロセスであり、クライアントが継続的にリクエストを行うことで、クライアントはサーバーから受信したデータの変更をリアルタイムでシミュレートできます。この方法の利点は、比較的シンプルで理解しやすいことです。欠点は、この方法では http 接続を継続的に確立する必要があるため、サーバーとクライアントのリソースが大幅に浪費されることです。ユーザー数が増えるとサーバー側の負担も大きくなり、非常に無理があります。

ロングポーリングの基本的な考え方:まず、クライアントがサーバーに対してリクエストを開始し、サーバーがクライアントからリクエストを受信すると、サーバーは直接応答せず、まずリクエストを一時停止し、その後サーバーデータを判断します。アップデートはありますか。更新があれば応答しますが、データがない場合は一定時間経過後に復帰します。サーバーから返された情報を処理した後、クライアント側の JavaScript 応答処理関数は、接続を再確立するためにリクエストを再度送信します。ショートポーリングと比較して、ロングポーリングには、不要な http リクエストの数が大幅に削減され、リソースが節約されるという利点があります。長いポーリングの欠点は、接続のハングによってリソースの浪費が発生することです。

SSE の基本的な考え方:サーバーはストリーム情報を使用して情報をサーバーにプッシュします。厳密に言えば、http プロトコルではサーバーが情報をアクティブにプッシュできるようにすることはできません。ただし、サーバーが次に送信するのはストリーム情報であることをクライアントに宣言するという回避策があります。つまり、送信されるのは 1 回限りのデータパケットではなく、継続的に送信されるデータストリームです。このとき、クライアントは接続を閉じず、常にサーバーから送信される新しいデータストリームを待ちます (ビデオ再生などはこの例です)。SSE はこのメカニズムを使用して、ストリーミング情報を使用して情報をブラウザーにプッシュします。これは http プロトコルに基づいており、現在 IE/Edge を除く他のブラウザでサポートされています。前の 2 つの方法と比較して、大量の http リクエストを作成する必要がなく、リソースを節約できます。

WebSocketは HTML5 で定義された新しいプロトコルで、従来の http プロトコルとは異なり、このプロトコルを使用すると、サーバーがクライアントに情報をアクティブにプッシュできます。WebSocket プロトコルを使用する場合の欠点は、サーバー側の構成がより複雑になることです。WebSocket は全二重プロトコルであり、通信の双方が同等であり、相互にメッセージを送信できますが、SSE 方式は一方向通信であり、サーバーはクライアントに情報をプッシュすることしかできません。情報を送信する必要がある場合、それは次の http リクエストに属します。

上記の 4 つの通信プロトコルのうち、最初の 3 つは HTTP プロトコルに基づいています。

これら 4 つのインスタント通信プロトコルについて、パフォーマンスの観点から見ると:
WebSocket > ロング接続 (SEE) > ロングポーリング > ショートポーリング
ただし、ブラウザの互換性の問題を考慮すると、順序はまったく逆になります:
ショートポーリング問い合わせ > ロングポーリング >長時間接続(SEE) > WebSocket
したがって、具体的な利用シーンに応じてどの方式を使用するかを判断する必要があります。