[コンピュータ ネットワーク ノート 10] コンピュータ ネットワークの面接の質問のまとめ

1. コンピュータネットワークの各層のプロトコルと機能は何ですか?

コンピュータネットワークシステムは、OSI 7 層モデル、TCP/IP 4 層モデル、5 層モデルの 3 種類に大別されます。

• OSI 7 層モデル: 大規模で包括的ですが、比較的複雑であり、最初は理論的なモデルであり、実際的な応用はありません。
• TCP/IP 4 層モデル: 実用的なアプリケーションの開発から要約されたものです. 本質的に、TCP/IP には上位 3 層のみがあり、下位層には特定の内容はありません. TCP/IP 参照モデルは実際には記述されていませんこの層の実現。
• TCP/IP 5 層モデル: 5 層モデルは、コンピュータ ネットワークの教育プロセスでのみ使用されます。これは、7 層モデルと 4 層モデルの間の妥協点であり、簡潔であり、概念を明確に説明できます。

7 層のネットワーク アーキテクチャの各層の主な機能は次のとおりです。

• アプリケーション層:アプリケーションに対話型サービスを提供します。インターネットには、ドメイン ネーム システムDNS 、 World Wide Web アプリケーションをサポートするHTTPプロトコル、電子メールをサポートするSMTPプロトコルなど、多くのアプリケーション層プロトコルがあります。

• プレゼンテーション層:暗号化と復号化、変換と翻訳、圧縮と解凍などのデータ形式の変換を主に担当します。

• セッション層:ネットワーク内の 2 つのノード間の通信の確立、維持、終了を担当します。たとえば、ユーザーのログインを認証するサーバーはセッション層によって完了します。

• トランスポート層:トランスポート層と訳されることもあり、ホスト プロセスに一般的なデータ送信サービスを提供します。この層には主に次の 2 つのプロトコルがあります。

  • TCP :コネクション型で信頼性の高いデータ送信サービスを提供します。
  • UDP :コネクションレス型のベストエフォート型のデータ送信サービスを提供しますが、データ送信の信頼性を保証するものではありません。

• ネットワーク層:適切なルーティング ノードとスイッチング ノードを選択して、データをタイムリーに送信できるようにします。主にIPプロトコルが含まれます。

• データ リンク層: データ リンク層は、単にリンク層と呼ばれることがよくあります。ネットワーク層から渡されたIPデータパケットをフレームに組み立て、隣接するノードのリンク上でフレームを送信します。

• 物理層：隣接するノード間でのビットストリームの透過的な伝送を実現し、伝送媒体や通信手段の違いを可能な限り遮蔽します。

2. TCP と UDP の違いは何ですか?

比較は次のとおりです。

	UDP	TCP
接続するかどうか	接続がありません	接続指向
信頼できるものですか?	信頼性の低い送信、フロー制御と輻輳制御の使用なし	フロー制御と輻輳制御を使用した信頼性の高い転送
順調ですか？	障害	メッセージは送信中に順序が崩れる可能性があり、TCP によってメッセージの順序が変更されます。
転送速度	素早い	遅い
接続オブジェクトの数	1対1、1対多、多対1、多対多のインタラクティブな通信をサポート	1対1のポイントツーポイント通信のみ可能
転送方法	メッセージ指向	バイトストリーム指向
初期オーバーヘッド	ヘッダーのオーバーヘッドは小さく、わずか 8 バイトです	ヘッダーの最小長は 20 バイト、最大長は 60 バイトです。
該当シーン	リアルタイムアプリケーション（IP電話、ビデオ会議、ライブブロードキャストなど）に適しています。	ファイル転送など、確実な伝送が求められる用途に最適

要約:

• TCPはトランスポート層で確実な伝送が必要な場合に使用され、UDPは高速伝送やリアルタイム性の要求が高い通信に使用されます。TCPとUDPは用途に応じて使い分けてください。

3. UDP と TCP に対応するアプリケーション シナリオは何ですか?

TCPは接続指向であり、信頼性の高いデータ配信を保証できるため、次の用途によく使用されます。

• FTPファイル転送
• HTTP / HTTPS

UDP はコネクションレスであり、いつでも、UDP 自体の処理がシンプルで効率的であるため、次の用途によく使用されます。

• DNS、SNMPなど総パケット数が少ない通信。
• 映像や音声などのマルチメディアリアルタイム通信
• ブロードキャスト通信

4. TCP の 3 ウェイ ハンドシェイク メカニズムについて詳しく説明してください。

• 最初のハンドシェイク: クライアントはSYN = 1 seq = x をサーバーに送信して、接続の確立を要求します。SYN = 1 は、これが TCP 接続要求メッセージであることを示し、seq = xは、クライアント プロセスがシーケンス番号xを初期シーケンス番号として使用することを示します。クライアントはSYN_SENT状態に入り、サーバーからの確認を待ちます。
• 2 回目のハンドシェイク: サーバーはSYN = 1 ACK = 1 ack = x + 1 seq = y をクライアントに送信します。SYN = 1 ACK = 1 は、現在のメッセージがクライアント要求に対する確認メッセージであることを示します。確認番号はack = x + 1です。同時に、初期シーケンス番号としてseq = yが選択されます。このとき、サーバーはSYN_RECV状態になります。
• 3 回目のハンドシェイク: クライアントはACK = 1 ack = y + 1 seq = x + 1 をサーバーに送信します。ACK = 1 は、現在のメッセージがサーバー要求の確認メッセージであることを示します。確認番号はack = y + 1で、シーケンス番号はseq = x + 1です。クライアントとサーバーはESTABLISHED状態に入り、3 つの手順を完了します。ウェイ握手。

理想的には、TCP 接続が確立されると、どちらかが積極的に接続を閉じるまで TCP 接続が維持されます。

5. 2 ウェイ ハンドシェイクではなく 3 ウェイ ハンドシェイクが必要なのはなぜですか?

TCP は信頼性の高い伝送制御プロトコルであり、スリーウェイ ハンドシェイクは信頼性の高いデータ伝送を保証し、伝送効率を向上させるための最小限の回数です。

主な理由は次の 3 つです。

1. 3 ウェイ ハンドシェイクにより、双方が自分と相手の送受信機能が正常であることを確認できます。

   最初のハンドシェイク: クライアントはリクエストセグメントを送信するだけで何も確認できませんが、サーバーは自身の受信能力と相手の送信能力が正常であることを確認できます。

   2 回目のハンドシェイク: クライアントは、自身の送受信能力が正常であることと、相手の送受信能力が正常であることを確認できます。

   3 回目のハンドシェイク: サーバーは、自身の送受信能力が正常であることと、相手の送受信能力が正常であることを確認できます。

   3ウェイハンドシェイクにより、双方が自分と相手の送受信能力が正常であることを確認でき、快適に通信できることがわかります。

2. 相手方にシリアル番号の初期値を通知し、シリアル番号の初期値を受信したことを確認します。

   信頼性の高いデータ送信を実現するには、TCP プロトコルで通信する双方の当事者がシーケンス番号と確認番号フィールドを維持して、送信されたデータ パケットのどれが相手方に受信されたかを識別する必要があります。これら 2 つのフィールドの値は、最初のシーケンス番号の値に基づいて増加します。

   3 ウェイ ハンドシェイク プロセスは、通信する双方の当事者がシーケンス番号の開始値を互いに通知し、相手がシーケンス番号の開始値を受信したことを確認するために必要なステップです。ハンドシェイクが２回しかない場合、せいぜい接続開始者の開始シーケンス番号しか確認できず、相手が選択したシーケンス番号は確認できない。

3. これにより、期限切れ (タイムアウト再送信など) の接続要求メッセージが突然サーバーに送信され、エラーやリソースの浪費が発生することが防止されます。

   双方向ハンドシェイクが使用されている場合、サーバーは最初のリクエストの後に接続が確立されたことを確認します。このとき、クライアントが接続を閉じ、サーバーがクライアントの以前に期限切れになった TCP 接続リクエストを受信すると、リクエストを送信します。確認要求メッセージをクライアントに送信します。現時点では、クライアントはサーバーが閉じているため応答できません。サーバーは、クライアントが閉じていることを認識していないため、クライアントに確認要求メッセージを送信し続けます。無駄な資源です。

6. なぜ 4 回ではなく 3 回握手をするのですか?

スリーウェイ ハンドシェイクでは、双方の送受信能力が正常であることをすでに確認できるため、双方がお互いの準備が整っていることを認識し、双方の初期シーケンス番号の確認も完了できるため、必要はありません。 4回目の握手へ。

• 最初のハンドシェイク: サーバーは、「自己受信、クライアント送信」メッセージ機能が正常であることを確認します。
• 2 回目のハンドシェイク: クライアントは、「自己送信、自己受信、サーバー受信、サーバー送信」メッセージが正常に機能することを確認し、接続が確立されたと判断します。
• 3回目のハンドシェイク：サーバーは「自分送信、クライアント受信」メッセージ機能が正常であることを確認し、この時点で双方がコネクションを確立し、正常に通信できています。

7. SYN フラッド攻撃とは何ですか? それを防ぐにはどうすればよいでしょうか？

SYN フラッド攻撃は DOS 攻撃の一種で、TCP プロトコルの欠陥を悪用し、大量の半接続リクエストを送信することで CPU とメモリのリソースを消費します。

原理：

• 3 ウェイ ハンドシェイク中、サーバーが [SYN/ACK] パケット (2 番目のパケット) を送信した後、クライアントの [ACK] パケット (3 番目のパケット) を受信するまでの TCP 接続は、ハーフオープン接続と呼ばれます。今回、サーバーは SYN_RECV (クライアントの応答を待っている) 状態にあります。クライアントからの[ACK]を受信できればTCP接続成功、そうでなければ成功するまでリクエストを再送信します。
• SYN 攻撃の攻撃者は、短期間に大量の存在しない IP アドレスを偽造し、サーバーに [SYN] パケットを送信し続けます。サーバーは [SYN/ACK] パケットで応答し、クライアントの確認を待ちます。 。送信元アドレスが存在しないため、サーバーはタイムアウトになるまで再送信を続ける必要があります。
• これらの偽造された [SYN] パケットは、未接続のキューを長時間占有して、通常の SYN に影響を与え、ターゲット システムの動作速度の低下、ネットワークの輻輳、さらにはシステムの麻痺を引き起こします。

検出: サーバー上で多数の半接続状態が確認された場合、特に送信元 IP アドレスがランダムである場合、基本的にこれは SYN 攻撃であると結論付けることができます。

予防：

• ファイアウォール、ルーターなどを介してゲートウェイを保護します。
• ハーフコネクションの最大数の増加やタイムアウトの短縮など、TCP/IP プロトコルスタックを強化することで防止します。
• SYN クッキー技術。SYN Cookie は、特に SYN フラッディング攻撃を防ぐために、TCP サーバー側の 3 ウェイ ハンドシェイクに何らかの変更を加える手段です。

8. 3 ウェイ ハンドシェイク接続フェーズ中に、最後の ACK パケットが失われた場合はどうなりますか?

サーバ：

• 3 番目の ACK がネットワークで失われ、サーバー側の TCP 接続のステータスはSYN_RECVになり、TCP タイムアウト再送信メカニズムに従って、SYN + を再送信する前に 3 秒、6 秒、および 12 秒待機します。 ACK パケット。クライアントは ACK パケットを再送信します。

• 指定された回数再送信してもクライアントから ACK 応答が受信されない場合、サーバーは一定の時間が経過した後に接続を自動的に閉じます。

クライアント：

• クライアントは接続が確立されたと認識し、サーバーにデータを送信すると、サーバーはRSTパケット (リセットを示す Reset、接続を異常終了するために使用) で応答します。この時点で、クライアントは 3 回目のハンドシェイクが失敗したことを認識します。

9. TCP の 4 つのウェーブ プロセスを詳しく紹介してください。

• 初回: クライアントはFIN = 1 ACK = 1 seq = u ack = v をサーバーに送信します。FIN=1 は、これが接続を解放するためのTCP要求メッセージであることを示します。

• 2 回目: サーバーはACK = 1 seq = v ack = u + 1 をクライアントに送信します。クライアントの最初のリリース接続要求メッセージの確認を示します。

  このとき、 A→B方向のコネクションは解放され、TCP はセミクローズ状態となり、BはAがデータを送信しなくなることを確認しますが、 B は引き続きAにデータを送信する可能性があります。

• 3 回目: サーバーはFIN = 1 ACK = 1 seq = w ack = u + 1 をクライアントに送信し、サーバーが接続要求メッセージを解放することを示します。

  • シーケンス番号 seq = w。これは、サーバーによって送信された最後のメッセージの最後のバイトのシーケンス番号+ 1です。
  • この間にクライアントがデータを送信しなかったため、確認番号 ack = u + 1 は第 2 波と同じです。

• 4 回目: クライアントはACK = 1 seq = u + 1 ack = w + 1 をサーバーに送信します。サーバーのシャットダウン要求が確認されたことを示します。

  このとき、サーバーは直接クローズ状態に入り、クライアントはTIME_WAIT待機状態になります。待機時間は2MSLで、これは最長メッセージ ライフ サイクルの2 倍です。この期間中に相手からのメッセージを受信しなかった場合、クライアントは待機状態になります。クライアントは最終的にクローズ状態に入ります。

サーバーがクライアントよりも早く TCP 接続を終了することがわかります。

10. 接続するときは 3 ウェイ ハンドシェイクが行われるのに、閉じるときは 4 ウェイ ハンドシェイクが行われるのはなぜですか?

1. クライアントの FIN セグメントを受信した後、サーバーにはまだ送信するデータがある可能性があるため、接続をすぐに閉じることはできませんが、応答して ACK セグメントを返します。

   次に、データの送信が継続される可能性があり、データの送信後、サーバーはデータが送信されたことを示し、接続を閉じるように要求する FIN メッセージをクライアントに送信します。サーバーの ACK と FIN は通常、別々に送信されるため、さらに 1 つのウェーブが発生し、合計 4 つのウェーブが必要になります。

2. TCP は全二重接続であり、接続を真に閉じるには、両端が同時に接続を閉じる必要があります。

   A が書き込みを閉じる準備ができている場合でも、B によって送信されたデータを読み取ることができます。このとき、A は B に FIN メッセージを送信します。それを受信した B は、A に ACK メッセージを返信します。

   B も書き込みを終了する準備ができたら、FIN メッセージを A に送信し、A は B に ACK を返します。このとき、両端はクローズされ、TCP コネクションは正常にクローズされます。

   したがって、全二重モードの場合、完全にシャットダウンするには、通信の両端間で 4 回の対話が行われ、互いのシャットダウン ステータスを確認する必要があります。

11. クライアントの TIME-WAIT 状態が 2MSL 待機する必要があるのはなぜですか?

1. TCP 接続の信頼性の高い終了を保証します。サーバーが接続を正常に閉じることができるように、ACK メッセージがサーバーに到達できることを確認してください。

   クライアントからサーバーに 4 回目に送信された確認メッセージが失われた場合、サーバーは確認メッセージを受信して​​いないため、タイムアウトになり、FIN/ACK メッセージをクライアントに再送信します。

   ただし、この時点でクライアントが閉じていると、サーバーに応答できなくなり、サーバーは FIN/ACK メッセージを再送信し続けることになります。つまり、サーバーは確認を取得できず、最終的にはサーバーに入ることができなくなります。 CLOSED状態です。

   MSL は、セグメントがネットワーク上で存続できる最大時間です。クライアントは 2MSL 時間待機します。つまり、「クライアント ACK メッセージ 1MSL タイムアウト + サーバー FIN メッセージ 1MSL 送信」後、サーバーによって再送信された FIN/ACK メッセージを受信でき、クライアントは ACK メッセージを再送信します。 2MSLタイマー。これにより、サーバーを正常にシャットダウンできるようになります。

   サーバーによって再送信された FIN が 2MSL 時間以内にクライアントに正常に送信されなかった場合、サーバーは接続が切断されるまでタイムアウトを繰り返し、再試行します。

2. 期限切れの接続要求セグメントが後続の接続に表示されないようにします。

   TCP では、2MSL 内で同じシーケンス番号を使用しないことが要求されます。クライアントが最後の ACK セグメントを送信し、2MSL が経過すると、この接続中に生成されたすべてのセグメントがネットワークから確実に消えるようになります。これにより、そのような古い接続要求セグメントが次の接続に表示されなくなります。あるいは、これらの古いメッセージを受信した場合でも、処理されない可能性があります。

12. 接続は確立されているが、クライアントが失敗した場合はどうなりますか?

タイマー+タイムアウトリトライ機構により、最後に接続が自動的に切断されるまで確認を試みます。

具体的には、TCP にはキープアライブ タイマーがあります。サーバーがクライアントからデータを受信するたびに、このタイマーはリセットされます。時間は通常2 時間に設定されます。2 時間クライアントからデータを受信しなかった場合、サーバーは再試行を開始します: 75 秒ごとに検出メッセージ セグメントを送信します。検出メッセージを 10 回連続して送信してもクライアントがまだ応答しない場合、サーバーは接続を検討します。すでに切断されています。

13. TIME-WAIT 状態が多すぎるとどのような影響がありますか? どうやって対処すればいいのでしょうか？

サーバーの観点から見ると、短期間に多数のクライアント接続を閉じると、サーバー上に多数の TIME_WAIT 接続が表示され、サーバーのリソースが大幅に消費されます。このとき、一部のクライアントは、接続できません。

クライアントの観点から見ると、クライアントの TIME_WAIT が多すぎるとポート リソースが占有されてしまいます。これは、ポートが65536 個しかなく、ポートがいっぱいの場合は新しい接続を作成できないためです。

解決：

• サーバーは SO_REUSEADDR ソケット オプションを設定することで TIME_WAIT 状態を回避できます。このソケット オプションは、たとえビジー状態 (TIME_WAIT 状態) であっても、このポートを続行して再利用するようにカーネルに指示します。
• システム カーネル パラメータを調整し、/etc/sysctl.confファイルを変更します。つまり、modifynet.ipv4.tcp_tw_reuseと tcp_timestamps

net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；
net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。

• 強制的にクローズされ、RST パケットを送信して TIME_WAIT 状態をバイパスし、直接 CLOSED 状態に入ります。

14. TIME_WAIT はサーバー側の状態ですか? それともクライアント側の状態ですか?

TIME_WAIT は、アクティブに切断する側が入る状態です。通常の状況では、クライアントがこの状態にあります。サーバーは通常、接続をアクティブに閉じないように設定されています。

TIME_WAIT は 2MSL 待機する必要があります。短い接続が多数ある場合、TIME_WAIT は長すぎるため、システム リソースも大量に消費されます。サーバーの場合、HTTP プロトコルで KeepAlive を指定し (ブラウザーは TCP 接続を再利用して複数の HTTP リクエストを処理します)、ブラウザーが積極的に切断することで、サーバーのこの問題をある程度軽減できます。

15. TCP プロトコルはどのように信頼性を確保しますか?

TCPは主に、チェックサム、シーケンス番号/確認応答、タイムアウト再送、スライディングウィンドウ、輻輳制御、フロー制御など、確実な伝送を実現するための手法を提供しています。

• チェックサム: 受信側はチェックサム方式により、データにエラーや例外があるかどうかを検出でき、エラーがある場合は TCP セグメントが破棄されて再送信されます。

• シリアルナンバー/確認応答：

  シーケンス番号の役割は応答だけではなく、受信したデータをシーケンス番号に従って並べ替えたり、シーケンス番号が重複するデータを削除したりすることができます。

  TCP 送信プロセス中、受信側はデータを受信するたびに、送信側を確認して応答します。つまり、ACK メッセージが送信され、この ACK メッセージには、送信者にどのようなデータが受信されたか、次のデータがどこから送信されるかを伝える、対応する確認シーケンス番号が含まれています。

• スライディング ウィンドウ: スライディング ウィンドウは、メッセージ送信の効率を向上させるだけでなく、送信者が送信するデータが多すぎて受信者がそれを正常に処理できないという例外を回避します。

• タイムアウト再送信: タイムアウト再送信とは、データ パケットを送信してから確認パケットを受信するまでの時間を指します。この時間を超えると、パケットは失われたとみなされ、再送信が必要になります。最大タイムアウトは動的に計算されます。

• 輻輳制御: データ送信プロセス中に、ネットワーク状態の問題によりネットワーク輻輳が発生する場合がありますが、このとき、TCP の信頼性を確保しながらパフォーマンスを向上させるために、輻輳制御メカニズムが導入されています。

• フロー制御: ホスト A がホスト B にデータを送信し続けると、ホスト B の受信能力に関係なく、ホスト B の受信バッファーがいっぱいになり、データを受け入れることができなくなり、その結果、大量のデータ パケット損失が発生し、再送信がトリガーされる可能性があります。再送処理中にホスト B の受信バッファの状態が改善されていない場合、データの再送に多くの時間が無駄になり、データ送信の効率が低下します。したがって、フロー制御メカニズムが導入され、ホスト B は、ホスト A に受信バッファのサイズを通知することで、送信されるデータの量を制御できるようになります。フロー制御は、TCP プロトコル ヘッダーのウィンドウ サイズに関連します。

16. TCP のスライディング ウィンドウについて詳しく教えてください。

データを送信する場合、送信するデータが比較的大きい場合は、複数のデータ パケットに分割して送信する必要があります。TCP プロトコルでは、次のデータ パケットを送信する前にデータの確認が必要です。このようにして、確認応答パケットを待つ時間が無駄になります。
この状況を回避するために、TCP はウィンドウの概念を導入しました。ウィンドウ サイズとは、確認応答パケットを待たずにデータ パケットを送信し続けることができる最大値を指します。

上の図から、スライディング ウィンドウの左側は送信されて確認されたパケット、スライディング ウィンドウの右側はまだ順番が来ていないパケットであることがわかります。

スライディング ウィンドウも 2 つの部分に分割されます。1 つは送信済みだが確認されていないパケット、もう 1 つはウィンドウ内で送信を待機しているパケットです。送信されたパケットの確認応答が続くと、ウィンドウ内で送信を待っているパケットも送信され続けます。ウィンドウ全体が右に移動し、まだ順番が来ていないグループがウィンドウに入ることができるようになります。

スライディング ウィンドウが電流制限の役割を果たしていることがわかります。つまり、現在のスライディング ウィンドウのサイズによって TCP がパケットを送信する現在のレートが決まり、スライディング ウィンドウのサイズは輻輳間の最小値に依存します。制御ウィンドウとフロー制御ウィンドウ。

17. 輻輳制御について詳しく教えてください。

TCP は、合計 4 つのアルゴリズムを使用して輻輳制御を実装します。

• スロースタート。
• 渋滞の回避。
• 高速再送信 (高速再送信)。
• 早い回復

送信側は、輻輳ウィンドウcwnd (輻輳ウィンドウ) と呼ばれる状態変数を維持します。

• cwnd<ssthresh の場合、スロースタート アルゴリズムが使用されます。
• cwnd>ssthresh の場合、代わりに輻輳回避アルゴリズムが使用されます。
• cwnd=ssthresh の場合、スロー スタートおよび輻輳回避アルゴリズムは任意です。

スロー スタート: 最初は大量のデータを送信せず、輻輳ウィンドウのサイズを小さいものから大きいものまで徐々に大きくします。

輻輳回避: 輻輳回避アルゴリズムにより、輻輳ウィンドウがゆっくりと拡大します。つまり、往復時間RTT が経過するたびに、送信側の輻輳ウィンドウ cwnd が 2 倍ではなく 1 ずつ増加します。このようにして、輻輳ウィンドウはゆっくりと直線的に増加します。

高速再送信:一部の不要な輻輳メッセージを排除し、ネットワーク スループットを向上させることができます。たとえば、受信側は、順序が正しくないメッセージ セグメントを受信した後、データの送信時に確認を待つのではなく、ただちに重複した確認を送信します。高速再送信ルール: 送信者は、繰り返し確認応答を 3 回続けて受信する限り、設定された再送信タイマーが期限切れになるのを待つことなく、相手が受信していないメッセージ セグメントを直ちに再送信する必要があります。

高速リカバリ:主に高速再送信と連携します。送信側が 3 回連続して繰り返される確認応答を受信すると、「乗算リダクション」アルゴリズムを実行し、ssthresh しきい値を半分にします (ネットワークの輻輳を防ぐため)。ただし、ネットワークが輻輳している場合は、スロー スタート アルゴリズムは実行されません。複数の重複した確認を受信しない 3 つの重複した確認を受信した場合は、ネットワークの状態が正常であることを示します。

18. 一般的な HTTP ステータス コードは何ですか?

一般的なステータス コード:

• 200: リクエストはサーバーによって正常に処理されました
• 204: リクエストは受け入れられましたが、リソースを返すことができません。
• 206: クライアントはリソースの一部のみを要求し、サーバーは要求されたリソースの一部に対して GET メソッドのみを実行します。対応するメッセージには、Content-Range で指定された範囲内のリソースが含まれます。
• 301: 永続的なリダイレクト
• 302: 一時的なリダイレクト
• 400: クライアント要求メッセージに構文エラーがあるため、サーバーが認識できません。
• 401: リクエストには認証が必要です
• 403: 要求されたリソースへのアクセスは禁止されています。サーバーは要求を受信しましたが、サービスの提供を拒否しました。
• 404: サーバーは対応するリソースを見つけることができません。
• 500: 内部サーバー エラー。サーバーでエラーが発生したため、リクエストを完了できませんでした。
• 503: サーバーがビジー状態です

ステータス コードの先頭はタイプを表します。

19. ステータス コード 301 と 302 の違いは何ですか?

共通点: 301 と 302 の両方のステータス コードはリダイレクトを示します。これは、サーバーから返されたステータス コードを取得した後、ブラウザが自動的に新しい URL アドレスにジャンプすることを意味します。このアドレスは、応答のLocationヘッダーから取得できます。(ユーザーが見た効果は、入力したアドレス A が即座に別のアドレス B に変わることです)。

違い:

• 301 は、古いアドレス A のリソースが完全に削除されたことを示します (このリソースはアクセスできなくなりました)。また、検索エンジンは、新しいコンテンツをクロールするときに、古い URL をリダイレクトされた URL と交換します。

• 302 は、古いアドレス A のリソースがまだそこにある (まだアクセスできる) ことを意味します。このリダイレクトは、古いアドレス A からアドレス B に一時的にジャンプするだけです。検索エンジンは新しいコンテンツをクロールし、古い URL を保存します。SEO では 301 より 302 の方が優れています。

リダイレクトの理由:

1. Web サイトの調整 (Web ディレクトリ構造の変更など)。
2. Web ページは新しいアドレスに移動されました。
3. Web ページの拡張子が変更されました (たとえば、アプリケーションは .php を .Html または .shtml に変更する必要があります)。

20. 一般的に使用される HTTP リクエストメソッドは何ですか?

記憶を容易にするために、PUT、DELETE、POST、および GET は、サーバーに対するクライアントの追加、削除、変更、およびクエリとして理解できます。

• PUT: ファイルをアップロードし、サーバーにデータを追加します。これは追加とみなすことができます。
• 削除: ファイルを削除します
• POST: データを送信し、サーバーにデータを送信し、サーバー データを更新します。
• GET: リソースを取得し、サーバー リソースをクエリします。

21. GET リクエストと POST リクエストの違いは何ですか?

使用上の違い:

• GET は URL または Cookie を使用してパラメータを渡しますが、POST はデータを BODY に置きます。これは、HTTP プロトコルの使用規則によるものです。
• GET によって送信されるデータには長さの制限がありますが、POST によって送信されるデータは非常に大きくなる可能性があります。これは、使用するオペレーティング システムとブラウザの設定の違いによるものです。
• データがアドレス バーに表示されないため、POST は GET より安全です。このステートメントには何も問題はありませんが、それでも GET と POST 自体の違いはありません。

本質的な違い

• GET と POST の最大の違いは、GET リクエストは冪等であるのに対し、POST リクエストは冪等ではないことです。これが彼らの本質的な違いです。

• 冪等性とは、リソースを 1 回要求しても複数回要求しても同じ副作用が生じることを意味します。簡単に言えば、同じ URL に対する複数のリクエストは同じ結果を返す必要があることを意味します。

22. HTTP の長い接続と短い接続について説明しますか?

HTTP/1.0 では、デフォルトで短い接続が使用されます。つまり、ブラウザとサーバーが HTTP 操作を実行するたびに TCP 接続が確立されますが、タスクが完了すると接続は中断されます。クライアント ブラウザによってアクセスされる HTML またはその他の種類の Web ページに、JavaScript ファイル、画像ファイル、CSS ファイルなどの他の Web リソースが含まれている場合、ブラウザはそのような Web リソースに遭遇するたびに、HTTP セッションを作成します。

ただし、HTTP/1.1 以降では、接続特性を維持するためにデフォルトで長い接続が使用されます。長い接続で HTTP プロトコルを使用する場合、次のコード行が応答ヘッダーに追加されます: Connection: keep-alive

長い接続が使用される場合、Web ページが開かれるとき、クライアントとサーバー間の HTTP データの送信に使用される TCP 接続は閉じられません。クライアントがサーバー上の Web ページに再度アクセスすると、引き続き使用されます。このリンクの接続が確立されました。Keep-Alive は接続を永続的に維持するものではなく、さまざまなサーバー ソフトウェア (Apache など) で設定できる保持時間を設定します。長い接続を実装するには、クライアントとサーバーの両方が長い接続をサポートする必要があります。

HTTP プロトコルの長い接続と短い接続は、本質的には TCP プロトコルの長い接続と短い接続です。

23. HTTP リクエスト メッセージとレスポンス メッセージの形式は何ですか?

リクエストメッセージの形式:

1. リクエスト行（リクエストメソッド+URI+プロトコルバージョン）
2. リクエストヘッダー
3. 空行 + CRLF 復帰および改行
4. リクエストボディ

GET /sample.jsp HTTP/1.1 请求行
Accept:image/gif.image/jpeg, 请求头部
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflate

username=jinqiao&password=1234 请求主体

応答メッセージ:

1. ステータス行 (プロトコル バージョン + ステータス コード + 理由フレーズ)
2. 応答ヘッダー
3. 空白行+CRLF
4. レスポンスボディ

HTTP/1.1 200 OK
Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:23:42 GMT
Content-Length:112

<html>
<head>
<title>HTTP响应示例<title>
</head>
<body>
Hello HTTP!
</body>
</html>

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

HTTP1.0 は 1996 年に初めて Web ページで使用されました。当時、HTTP1.0 は一部の単純な
Web ページとネットワーク リクエストにのみ使用されていましたが、HTTP1.1 が主要なブラウザのネットワーク リクエストで広く使用され始めたのは 1999 年になってからです。 HTTP1.1 は現在最も広く使用されている HTTP プロトコルです。

主な違いは主に次の点に反映されます。

• 長時間接続: HTTP 1.1 は、長時間接続とリクエスト パイプライン処理をサポートしています。複数の HTTP リクエストと応答を TCP 接続で送信できるため、接続の確立と終了の消費と遅延が削減されます。接続: キープアライブはHTTP 1.1 ではデフォルトで有効になっています。これにより、リクエストごとに接続を作成する必要があるという HTTP1.0 の欠点がある程度補われます。
• キャッシュ処理: HTTP 1.0では主にヘッダー内のIf-Modified-SinceとExpiresがキャッシュ判定の基準として使用されていましたが、HTTP 1.1ではEntityタグ、If-Unmodified-Since、If -Match、Ifなどのキャッシュ制御戦略がさらに導入されています。 -None-Matchおよびその他のオプションのキャッシュ ヘッダーにより、キャッシュ
  戦略を制御します。
• 帯域幅の最適化とネットワーク接続の使用: HTTP 1.0 では、クライアントはオブジェクトの一部のみを必要としますが、サーバーはオブジェクト全体を送信し、再開機能をサポートしていないなど、帯域幅を浪費する現象がいくつかあります。.1 では、リクエスト ヘッダーに範囲ヘッダー フィールドが導入されています。これにより、リソースの特定の部分のみをリクエストできます。つまり、リターン コードは206 (部分コンテンツ) となり、開発者が帯域幅を最大限に活用することを自由に選択できるようになります。そしてつながり。
• エラー通知管理:要求されたリソースがリソースの現在のステータスと競合していることを示す409 (Conflict) 、サーバー上のリソースが既に削除されていることを示す410 (Gone)など、24 の新しいエラー ステータス応答コードが HTTP 1.1 に追加されました。完全に削除された性的削除。
• ホストヘッダ処理: HTTP 1.0では、各サーバーは固有のIPアドレスにバインドされているとみなされるため、リクエストメッセージ内のURLにはホスト名(ホスト名)が渡されません。しかし、仮想ホスト技術の発展により、物理サーバー上に複数の仮想ホスト (マルチホーム Web サーバー) が存在し、IP アドレスを共有できるようになりました。HTTP 1.1 リクエスト メッセージとレスポンス メッセージは Host ヘッダー フィールドをサポートする必要があり、リクエスト メッセージに Host ヘッダー フィールドがない場合、エラー (400 Bad Request) が報告されます。

25. HTTP 1.1 と HTTP 2.0 の違いは何ですか?

HTTP1.1 と比較した HTTP2.0 でサポートされる機能:

• 新しいバイナリ形式: HTTP 1.1 の解析はテキストベースです。テキスト プロトコルに基づく形式解析には当然の欠陥があります。テキストの表現は多様であり、堅牢性を考慮するために多くのシナリオを考慮する必要があります。バイナリは異なり、0 と 1 の組み合わせのみが認識されます。この考慮に基づいて、HTTP2.0 のプロトコル解析には、実装に便利で堅牢なバイナリ形式を使用することが決定されました。
• 多重化、つまり接続共有、つまり各リクエストは接続共有メカニズムとして使用されます。リクエストは ID に対応するため、1 つの接続上に複数のリクエストが存在する可能性があり、各接続のリクエストはランダムに混在することができ、受信側はリクエスト ID に基づいてリクエストを異なるサーバー リクエストに帰属させることができます。
• ヘッダー圧縮、HTTP1.1のヘッダーには大量の情報が含まれているため、毎回繰り返し送信する必要がありますが、HTTP2.0ではエンコーダーを使用して送信する必要のあるヘッダーのサイズを削減し、各通信当事者がテーブルをキャッシュしますこれにより、ヘッダー フィールドの繰り返しが回避され、送信する必要があるサイズが削減されます。
• サーバー プッシュ: 最初のリクエストに対するサーバーの応答に加えて、サーバーは、クライアントからの明示的なリクエストなしで追加のリソースをクライアントにプッシュすることもできます。

HTTP2.0の多重化とHTTP1.Xの長時間接続の多重化の違いは何ですか?

• HTTP/1.0 はリクエストとレスポンスであり、接続を確立し、完了したら接続を閉じます。接続はリクエストごとに確立する必要があります。
• HTTP/1.1 パイプリング ソリューションでは、シリアル シングル スレッド処理のために複数のリクエストをキューに入れ、後続のリクエストは実行の機会を得る前に前のリクエストが返されるのを待ちます。リクエストがタイムアウトすると、後続のリクエストはブロックされるだけです。これは、行頭ブロックと呼ばれることがよくあります。
• HTTP/2 複数のリクエストを 1 つの接続上で同時に並行して実行できます。特定のリクエスト タスクは非常に時間がかかり、他の接続の通常の実行には影響しません。

26. HTTP と HTTPS の違いは何ですか?

HTTPSプロトコル (HyperText Transfer Protocol over Secure Socket Layer): 一般的にHTTP + SSL/TLSとして理解され、サーバーの ID はSSL証明書によって検証され、ブラウザとサーバー間の通信は暗号化されます。

• HTTP URL はhttp://で始まり、HTTPS URL はhttps://で始まります
• HTTP は安全ではありませんが、HTTPS は安全です
• HTTP の標準ポートは 80 ですが、HTTPS の標準ポートは 443 です。
• OSI ネットワーク モデルでは、HTTP はアプリケーション層で機能し、HTTPS の安全な送信メカニズムはトランスポート層で機能します。
• HTTP は暗号化できませんが、HTTPS は送信データを暗号化します。
• HTTP には証明書は必要ありませんが、HTTPS には CA 機関によって発行された SSL 証明書が必要です。

27. HTTPS の長所と短所は何ですか?

利点:

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

• SEO: Google は 2014 年 8 月に検索エンジンのアルゴリズムを調整し、「同等の HTTP Web サイトと比較して、HTTPS 暗号化を使用している Web サイトは検索結果で上位にランクされる」と述べました。

欠点:

• 同じネットワーク環境において、HTTPS は HTTP に比べて応答時間と消費電力が大幅に増加します。
• HTTPS のセキュリティには限界があり、ハッカー攻撃やサーバーハイジャックなどの場合にはほとんど役に立ちません。
• 既存の証明書メカニズムでは、依然として中間者攻撃の可能性があります。
• HTTPS はより多くのサーバー リソースを必要とし、コストも高くなります。

28. HTTPS の原理について教えてください。

暗号化プロセスは、図のシリアル番号に従って次のように分かれています。

• ① クライアントは HTTPS URL を要求し、サーバーのポート443 (HTTP のポート80に似た HTTPS のデフォルト ポート) に接続します。

• ② HTTPS プロトコルを使用するサーバーには、一連のデジタルCA (認証局) 証明書が必要です。証明書が発行されると、秘密鍵と公開鍵が生成されます。秘密キーはサーバー自体によって保持され、漏洩することはありません。公開鍵は証明書情報に含まれており、公開することが可能です。証明書自体にも証明書の電子署名が付いており、この署名は証明書の完全性と信頼性を検証し、証明書の改ざんを防止するために使用されます。

• ③ サーバーはクライアントの要求に応じて、公開鍵のほか、認証局情報、企業情報、証明書の有効期間などの多くの情報が含まれた証明書をクライアントに渡します。

• ④ クライアントは証明書を解析して検証します。証明書が信頼できる機関によって発行されていない場合、証明書内のドメイン名が実際のドメイン名と一致しない場合、または証明書の有効期限が切れている場合は、訪問者に警告が表示され、訪問者は通信を継続するかどうかを選択できます。

  証明書に問題がない場合、クライアントはサーバー証明書からサーバーの公開鍵 Aを取得します。次に、クライアントもランダム コード KEY を生成し、公開キー A を使用して暗号化します。

• ⑤ クライアントは暗号化されたランダムコード KEY を以降の対称暗号化の鍵としてサーバーに送信します。

• ⑥ ランダムコードKEY を受信した後、サーバーは秘密鍵 B を使用してそれを復号化します。

  上記の手順の後、クライアントとサーバーは最終的に安全な接続を確立し、対称暗号化のキー漏洩の問題を完全に解決し、対称暗号化を使用して快適に通信できるようになります。

• ⑦ サーバーは対称鍵（ランダムコード KEY）を使用してデータを対称暗号化してクライアントに送信し、クライアントは同じ鍵（ランダムコード KEY）を使用してデータを復号します。

• ⑧ 双方は対称暗号化を使用して、すべてのデータを問題なく送信します。

29. ブラウザに www.baidu.com を入力した後に実行されるプロセス全体は何ですか?

1. ドメイン名解決(ドメイン名 www.baidu.com が IP アドレスになります)。

   ブラウザは独自のDNS キャッシュを検索し(ドメイン名と IP の対応テーブルを維持)、
   そうでない場合はオペレーティング システムの DNS キャッシュを検索し(ドメイン名と IP の対応テーブルを維持)、
   そうでない場合はオペレーティング システムのホストを検索します。ファイル (ドメイン名と IP の間の対応表を維持します)。

   存在しない場合は、 tcp/ip パラメータに設定されている優先DNS サーバー、つまりローカル DNS サーバー(再帰クエリ) を探します。ローカル ドメイン ネーム サーバーは、独自のDNS キャッシュをクエリします。存在しない場合は、反復クエリを実行します。ローカル DNS サーバーは IP をオペレーティング システムに返し、同時に IP をキャッシュします。

2. TCP 3 ウェイ ハンドシェイクを開始し、TCP 接続を確立します。ブラウザは、ランダムなポート (1024 ～ 65535) を使用して、サーバーの Web プログラム ポート 80 への TCP 接続を開始します。

3. TCP 接続を確立した後、http リクエストを開始します。

4. サーバーは http リクエストに応答し、クライアントは HTML コードを取得します。サーバー Web アプリケーションは http リクエストを受信すると、リクエストの処理を開始し、処理後に HTML ファイルをブラウザに返します。

5. ブラウザは HTML コードを解析し、HTML 内のリソースを要求します。

6. ブラウザはページをレンダリングしてユーザーに表示します。

通常、サーバーはリクエスト データをクライアントに返すと TCP 接続を閉じますが、クライアントまたはサーバーがヘッダー情報に Connection: keep-alive というコード行を追加すると、送信後も TCP 接続は維持されます。オープン状態なので、クライアントは同じ接続を通じてリクエストを送信し続けることができます。つまり、前の 3 から 6 を繰り返すことができます。接続を維持すると、リクエストごとに新しい接続を確立するのに必要な時間が節約され、ネットワーク帯域幅も節約されます。

30. Cookie とセッションとは何ですか?

クッキーとは何ですか

HTTP Cookie (Web Cookie またはブラウザ Cookie とも呼ばれます) は、サーバーによってユーザーのブラウザに送信され、ローカルに保存される小さなデータです。次回ブラウザが同じサーバーにリクエストを行うときに転送され、サーバーに送信されます。 . . 通常、これは、ユーザーのログイン状態を維持するなど、2 つのリクエストが同じブラウザーからのものであるかどうかをサーバーに伝えるために使用されます。Cookie を使用すると、ステートレス HTTP プロトコルに基づいて安定した状態情報を記録できます。

Cookie は主に次の 3 つの側面で使用されます。

• セッション状態管理（ユーザーのログインステータス、ショッピングカート、ゲームスコア、その他記録が必要な情報など）
• パーソナライズされた設定 (ユーザー定義の設定、テーマなど)
• ブラウザの行動追跡（ユーザー行動の追跡と分析など）

セッションとは

セッションは、サーバーとクライアント間のセッションのプロセスを表します。Session オブジェクトには、特定のユーザー セッションに必要なプロパティと構成情報が格納されます。このようにして、ユーザーがアプリケーションの Web ページ間を移動しても、Session オブジェクトに格納されている変数は失われることなく、ユーザー セッション全体にわたって保持されます。クライアントがセッションを閉じるか、セッション タイムアウトが経過すると、セッションは終了します。

31. Cookie とセッションはどのように連携しますか?

ユーザーが初めてサーバーをリクエストすると、サーバーはユーザーが送信した関連情報に基づいて対応するセッションを作成し、リクエストが返されると、このセッションの一意の識別情報である SessionID がブラウザに返されます。ブラウザはサーバーから返された SessionID 情報を受け取り、この情報はCookieに保存され、Cookie はこの SessionID がどのドメイン名に属しているかを記録します。

ユーザーが 2 回目にサーバーにアクセスすると、このドメイン名に Cookie 情報があるかどうかがリクエストによって自動的に判断されます。存在する場合は、Cookie 情報が自動的にサーバーに送信されます。サーバーは Cookie からセッション ID を取得します。 , そして、 SessionID に基づいて対応するセッションを見つけます。情報が見つからない場合は、ユーザーがログインしていないか、ログインが無効であることを意味します。セッションが見つかった場合は、ユーザーがログインしていることが証明され、実行できることになります。以下の操作。

上記のプロセスによれば、SessionID は Cookie と Session を接続するブリッジであり、ほとんどのシステムもこの原則に基づいてユーザーのログイン状態を検証します。

32. Cookie とセッションの違いは何ですか?

• 動作範囲が異なり、Cookieはクライアント(ブラウザ)側に保存され、Sessionはサーバー側に保存されます。
• アクセス方法が異なります。Cookie は ASCII のみを保存できますが、Session は任意のデータ型を保存できます。一般的に、UserId などのいくつかの共通の変数情報を Session に保持できます。
• Cookieの有効期限は異なりますが、例えばよく使うデフォルトのログイン機能では、セッションの有効期限は一般に短く、クライアントを閉じたり、終了したりすると有効期限が切れてしまいます。セッションがタイムアウトになります。
• プライバシー ポリシーが異なります。Cookie はクライアント側に保存されるため、不正取得されやすいです。初期の頃は、ユーザーのログイン名とパスワードを Cookie に保存する人がいて、結果として情報が盗まれました。セッションはサーバー側に保存されます。 、セキュリティは Cookie よりも優れています。
• ストレージ サイズが異なり、1 つの Cookie には 4K を超えるデータを保存できませんが、セッションには Cookie よりもはるかに多くのデータを保存できます。

33. HTTP プロトコルのステートレスプロトコルとは何ですか? 解決方法は何ですか?

ステートレス プロトコルにはトランザクション処理用のメモリがありません。ステータスがないということは、後の処理に前の情報が必要な場合、つまりクライアントが HTTP リクエストを完了した後、クライアントが別の HTTP リクエストを送信することを意味します。HTTP は現在のクライアントが「古いユーザー」であることを認識しません。

ステートレスな問題を解決するためにCookie を使用できます。Cookie はパスに相当します。クライアントが初めて訪問したとき、Cookie がクライアントに送信されます。クライアントが再び訪問したとき、クライアントは Cookie (パスポート) を保持し、次にサーバーが保持します。これは「古いユーザー」です。

34. URIとURLの違い

URI は、リソースを一意に識別するために使用される統一リソース識別子です。HTML ドキュメント、画像、ビデオ クリップ、プログラムなど、Web 上で利用可能なすべてのリソースは、URIによって検索されます。

URI は通常、次の 3 つの部分で構成されます。

• ① リソースにアクセスするための命名機構
• ② リソースが格納されているホスト名
• ③ リソース自体の名前。リソースを強調したパスで表されます。

URLは、ユニフォーム リソース ロケーターです。これは特定の URI です。つまり、URL はリソースを識別するために使用でき、リソースを見つける方法も示します。URL はインターネット上の情報リソースを記述するために使用される文字列で、主にさまざまな WWW クライアント プログラムやサーバー プログラム、特に有名な Mosaic で使用されます。

URL を使用すると、ファイル、サーバー アドレス、ディレクトリなどのさまざまな情報リソースを統一された形式で記述することができます。URL は通常、次の 3 つの部分で構成されます。

• ① 規約（またはサービス方法）
• ②リソースが格納されているホストのIPアドレス（ポート番号を含む場合もあります）
• ③ ホストリソースの特定のアドレス。ディレクトリ名やファイル名など。

URN、統一リソース名、統一リソース命名は、リソースを名前で識別します。たとえば、 ですmailto:[email protected]。

URI が抽象インターフェイス定義とみなされる場合、URL と URN は両方とも URI の具象実装です。大まかに言えば、すべての URL は URI ですが、すべての URI が URL であるわけではありません。これは、URI にはサブクラス、Uniform Resource Name (URN) も含まれており、これはリソースに名前を付けますが、リソースの検索方法は指定しないためです。上記の mailto、news、isbn URI はすべて URN の例です。

Java の URI では、URI の構文規則に準拠している限り、URI インスタンスは絶対または相対を表すことができます。URL クラスはセマンティクスに準拠するだけでなく、リソースを見つけるための情報も含まれるため、相対的なものにすることはできません。Java クラス ライブラリでは、URI クラスにはリソースにアクセスするメソッドが含まれておらず、その唯一の機能は解析です。対照的に、URL クラスはリソースへのストリームを開きます。

35. TCP パケットのスタック/アンパッキングの原因と解決策は何ですか?

TCP はデータをストリーム方式で処理し、完全なパケットを複数のパケットに分割して TCP で送信したり、小さなパケットを大きなデータ パケットにカプセル化して送信したりできます。

TCP パケットのスティッキング/サブパッケージ化の理由:

• アプリケーションによって書き込まれたバイトのサイズがソケット送信バッファのサイズより大きい場合、アンパックが発生します。

• アプリケーションによって書き込まれたデータがソケット バッファ サイズより小さい場合、ネットワーク カードはアプリケーションによって複数回書き込まれたデータをネットワークに送信するため、パケット スタックが発生します。

• MSS サイズの TCP セグメンテーションを実行します。TCP メッセージ長 - TCP ヘッダー長 > MSS の場合にアンパックが行われます。

• イーサネット フレームのペイロードは、IP フラグメンテーションの MTU (1500 バイト) より大きくなります。

解決：

• ① メッセージは固定長です。つまり、毎回固定長のバイトが送信されます。この解決策は簡単ですが、スペースを無駄に消費するという欠点があります。たとえば、10 バイトごとにメッセージを表すと規定されていますが、クライアントが送信するメッセージには 1 バイトしか含まれていないため、残りの 9 バイトは空白または 0 で埋める必要があり、無駄です。FixedLengthFrameDecoderクラスをご利用いただけます。
• ② パケットの最後に改行文字（\n）を区切り文字として使用するなど、HTTP プロトコルの境界として HTTP ヘッダーに改行文字と改行文字を使用するなど、特殊な区切り文字を使用します。行区切り文字クラスLineBasedFrameDecoderまたはカスタム区切り文字クラスを使用できますDelimiterBasedFrameDecoder。
• ③ 固定長フィールドにはコンテンツの長さ情報が格納されます。つまり、メッセージはメッセージヘッダーとメッセージボディに分かれており、メッセージヘッダーに固定長フィールドが追加されてメッセージコンテンツの長さを格納します。たとえば、各メッセージのヘッダーには固定長 4 が使用されます。バイトのサイズはメッセージのコンテンツの長さを表します。受信側が解析するとき、最初に固定長フィールドを読み取って長さを取得し、次に読み取ります。エスケープすることなくデータ コンテンツを正確に特定するために、長さに応じてデータ コンテンツを抽出します。短所:データコンテンツの長さは制限されており、最長メッセージのバイト数を事前に知っておく必要があります。LengthFieldBasedFrameDecoderクラスをご利用いただけます。

36. 連載の概要を教えてください

シリアル化 (エンコード) はオブジェクトをバイナリ形式 (バイト配列) にシリアル化し、主にネットワーク送信、データの永続化などに使用されます。一方、逆シリアル化 (デコード) はネットワーク、ディスクなどからバイトを読み取ります。配列は次のように復元されます。元のオブジェクト。主にネットワーク送信オブジェクトをデコードしてリモート呼び出しを完了するために使用されます。

シリアル化のパフォーマンスに影響を与える主な要素: シリアル化されたコード ストリームのサイズ (ネットワーク帯域幅の使用量)、シリアル化のパフォーマンス (CPU リソースの使用量)、言語間 (異種システムのドッキングと開発言語の切り替え) をサポートするかどうか。

• Java によってデフォルトで提供されるシリアル化:言語をまたぐことはできず、シリアル化後のコード ストリームが大きすぎ、シリアル化のパフォーマンスが低下します。

• XML、利点:人間と機械の可読性が高く、要素または属性の名前を指定できます。

  欠点: シリアル化されたデータには、型の識別とアセンブリ情報を除いて、データ自体とクラスの構造のみが含まれます。シリアル化できるのはパブリック プロパティとフィールドのみです。メソッドはシリアル化できません。ファイルは巨大で、ファイル形式は複雑です。送信は帯域幅を消費します。

  適用可能なシナリオ:データを保存し、リアルタイムのデータ変換を実行するための構成ファイルとして使用します。

• JSON は軽量のデータ交換形式であり、

  利点:高い互換性、比較的単純なデータ形式、読み書きが簡単、シリアル化後のデータが小さい、拡張性が良い、互換性が良い XML と比較して、そのプロトコルは比較的単純で、解析速度は比較的速い。

  欠点:データは XML よりも説明的ではなく、パフォーマンス要件がミリ秒レベルであり、余分なスペースのオーバーヘッドが比較的大きい状況には適していません。

  適用可能なシナリオ (XML を置き換えることができる): クロスファイアウォール アクセス、高度な調整要件、Web ブラウザー ベースの Ajax リクエスト、送信される比較的少量のデータ、およびリアルタイム要件が比較的低いサービス (第 2 レベルなど)。

• Fastjson は、「仮定された順序付き高速マッチング」アルゴリズムを使用します。

  利点:インターフェイスはシンプルで使いやすく、現在 Java 言語で最も高速な JSON ライブラリです。

  短所: スピードと「標準」および機能からの逸脱、低いコード品質、不完全なドキュメント、および多数のセキュリティ ホールが重視されすぎています。

  適用可能なシナリオ: プロトコル対話、Web 出力、Android クライアント

• Thriftはシリアル化プロトコルであるだけでなく、RPC フレームワークでもあります。

  利点: シリアル化後のサイズが小さく、速度が速く、複数の言語と豊富なデータ型をサポートし、データ フィールドの追加と削除に対する強い互換性があり、バイナリ圧縮エンコーディングをサポートします。

  短所: ユーザーが少ない、ファイアウォールを越えてアクセスすると安全でなく読み取り不能、コードのデバッグが比較的難しい、他のトランスポート層プロトコル (HTTP など) では使用できない、永続層へのデータの直接読み取りおよび書き込みをサポートできない。データ永続化シリアル化プロトコルには適していません。

  適用可能なシナリオ: 分散システム用の RPC ソリューション

• Protobuf はデータ構造を.protoファイルとして記述し、コード生成ツールはデータ構造に対応するPOJOオブジェクトと Protobuf 関連のメソッドおよびプロパティを生成できます。

  利点:シリアル化後のコード ストリームが小さく、パフォーマンスが高く、構造化データ ストレージ形式(XML JSON など)、
  フィールドの順序を識別することでプロトコルの上位互換性を実現でき、構造化ドキュメントの管理と保守が容易です。

  欠点:コードを生成するにはツールに依存する必要があり、サポートされる言語は比較的少なく、公式には Java、C++、Python のみをサポートしています。

  適用可能なシナリオ: 高いパフォーマンス要件を伴う RPC 呼び出し、優れたファイアウォール間アクセス プロパティ、アプリケーション層オブジェクトの永続化に適した

37. select、pol、epoll の違いは何ですか?

選択、ポーリング、およびエポーリングはすべて、オペレーティング システムがIO 多重化を実装するメカニズムです。I/O 多重化では複数の記述子を監視するメカニズムが使用されることが知られており、記述子の準備が完了すると (通常は読み取り準備完了または書き込み準備完了)、対応する読み取りおよび書き込み操作を実行するようにプログラムに通知できます。では、これら 3 つのメカニズムの違いは何でしょうか?

1. プロセスによってオープンできる接続の最大数をサポートします。

IO多重化名	開くことができる接続の最大数
選択する	1 つのプロセスで開くことができる接続の最大数はFD_SETSIZEマクロによって定義されており、そのサイズは です1024。 もちろん、これを変更してカーネルを再コンパイルすることもできますが、パフォーマンスが影響を受ける可能性があります。
世論調査	ポーリングは基本的に選択と同じですが、リンクされたリストに基づいて保存されるため、最大接続数に制限がありません。
エポール	接続数は基本的にマシンのメモリ サイズによってのみ制限されます。

2. FDの急増によるIO効率の問題

IO多重化名	IO効率
選択する	接続は呼び出されるたびに線形に通過するため、FD が増加すると、通過速度が遅くなる「線形パフォーマンス低下の問題」が発生します。
世論調査	同上
エポール	カーネルでの epoll の実装は各 fd のコールバック関数に基づいているため、アクティブなソケットのみがアクティブにコールバックを呼び出します。したがって、アクティブなソケットが少ない場合でも、epoll を使用すると、前の 2 つのパフォーマンスの線形低下の問題は発生しません 。ただし、 すべてのソケットがアクティブな場合、パフォーマンスの問題が発生する可能性があります。

3. メッセージ配信方法

IO多重化名	メッセージング
選択する	カーネルはメッセージをユーザー空間に渡す必要があり、これにはカーネル コピー アクションが必要です。
世論調査	同上
エポール	epoll は、カーネルとユーザー空間の間でメモリを共有することによって実装されます。

要約:

要約すると、select、poll、または epoll を選択するときは、特定の使用機会とこれら 3 つのメソッドの特性を考慮する必要があります。

1. 表面的には、 epoll のパフォーマンスが最も優れていますが、接続数が少なく、接続が非常にアクティブである場合、selectとPaulのパフォーマンスはepollよりも優れている可能性があります。結局のところ、epollの通知メカニズムには多くの関数コールバックが必要です。
2. select は毎回 ポーリングが必要なため非効率的です。しかし、非効率は相対的なものであり、状況によっては、適切な設計によって改善することもできます。

38. レベルトリガー(LT)、エッジトリガー(ET)とは何ですか?

条件付きトリガー (Level_triggered): レベル トリガーとも呼ばれ、監視対象のファイル記述子で読み取り可能または書き込み可能なイベントが発生すると、ハンドラーにepoll_wait()読み取りと書き込みが通知されます。今回、すべてのデータの読み取りと書き込みが一度に行われない場合 (たとえば、読み取りおよび書き込みバッファーが小さすぎる場合)、次回呼び出したときに、ファイル記述子の読み取りと書き込みを続行するように通知されますepoll_wait()。もちろん、読み書きがされていない場合は、通知が継続されます。！！読み書きする必要のない準備完了ファイル記述子がシステム内に多数存在し、それらが毎回返される場合、ハンドラーが対象とする準備完了ファイル記述子を取得する際の効率が大幅に低下します。！！

エッジ トリガー (Edge_triggered) : 監視対象のファイル記述子で読み取りおよび書き込み可能なイベントが発生すると、ハンドラーにepoll_wait()読み取りと書き込みが通知されます。今回すべてのデータの読み取りおよび書き込みが行われていない場合 (たとえば、読み取りおよび書き込みバッファーが小さすぎる場合)、epoll_wait()次回呼び出されるときに通知されません。つまり、2 回目までは 1 回だけ通知されます。ファイル記述子に表示されます。読み取りおよび書き込みイベントが発生した後にのみ通知されます。！！このモードは水平トリガよりも効率的であり、システムは、必要のない大量の既製ファイル記述子で溢れかえることはありません。！

簡単に理解すると、1 つはユーザーに継続的に通知し、もう 1 つはユーザーに 1 回だけ通知するということです。

要約:

• 条件付きトリガー: 読み取る必要のあるデータなど、イベントの条件が満たされている限り、イベントは継続的にユーザーに配信されます。
• エッジ トリガー: 初めて条件が満たされた場合にのみトリガーされ、同じイベントは再度配信されません。
• エッジ トリガーの効率は条件付きトリガーよりも高くなります。epoll はエッジ トリガーと条件付きトリガーをサポートしています。デフォルトは条件付きトリガーです。選択とポーリングは両方とも条件付きトリガーです。

39. 直接記憶とは何ですか

すべてのネットワーク通信とアプリケーションでは、各 TCP ソケットのコアに送信バッファ (SO_SNDBUF) と受信バッファ (SO_RECVBUF) があり、バッファ サイズは関連するソケット オプションを使用して変更できます。

アプリケーション プロセスがwriteを呼び出すと、カーネルはアプリケーション プロセスのバッファから書き込み中のソケットの送信バッファにすべてのデータをコピーします。ソケットの送信バッファーがアプリケーション プロセスのすべてのデータを収容できない場合 (アプリケーション プロセスのバッファーがソケットの送信バッファーより大きいか、ソケットの送信バッファーに他のデータがあるかのいずれか)、ソケットがブロックされていると仮定すると、アプリケーション プロセスは眠らされてしまいます。

カーネルは、アプリケーションプロセスバッファ内のすべてのデータがソケット送信バッファにコピーされるまで、書き込みシステムコールから戻りません。したがって、TCP ソケットへの書き込み呼び出しからの正常な復帰は、元のアプリケーション プロセス バッファを再利用できることを意味するだけであり、相手の TCP またはアプリケーション プロセスがデータを受信したことを示すものではありません。

Java プログラムは当然ながら上記の規則に従う必要があります。ただし、Javaにはヒープやガベージコレクションなどの機能があるため、実際のIOではJVM内に次のような仕組みがあります。

• IO の読み取りと書き込みに関して、ヒープ メモリが使用されている場合、JDK は最初にDirectBufferを作成し、次に実際の書き込み操作を実行します。
• これは、JNI を介して基礎となる C ライブラリにアドレスを渡すときに、このアドレスのコンテンツを無効化できないという基本要件があるためです。
• ただし、GC 管理下のオブジェクトは Java ヒープ内に移動されます。つまり、基になるwriteにアドレスを渡しても、GC によるメモリのソートによりこのメモリが無効になる可能性があります。
• したがって、送信するデータは GC の制御が及ばない場所に配置する必要があります。このため、ネイティブ メソッドを呼び出す前にデータをオフヒープ メモリに置く必要があります。

HeapBuffer がもう 1 つのコピーを作成する必要があるため、DirectBuffer はメモリ コピーを保存しないことがわかります。DirectBuffer を使用すると、メモリ コピーが 1 つ保存されます。ヒープ メモリを使用しない Java プログラムと比較すると、ダイレクト メモリを使用する Java プログラムは確かに高速です。

ガベージコレクションの観点から見ると、ダイレクトメモリは GC (新世代のマイナー GC) の影響を受けません。ダイレクトメモリは旧世代のフル GC が実行された場合にのみリサイクルされます。また、メモリのソートのプレッシャーも軽減されます。データを HeapBuffer に配置します。

オフヒープメモリの長所と短所

オフヒープ メモリには、オンヒープ メモリに比べていくつかの利点があります。

1. ガベージ コレクションによって他の作業が中断されるため、ガベージ コレクション作業が軽減されます(マルチスレッドまたはタイム スライス メソッドが使用される可能性がありますが、まったく感じられません)。
2. コピーを高速化します。ヒープがリモートにフラッシュされると、まずダイレクト メモリ (非ヒープ メモリ) にコピーされてから送信されますが、オフヒープ メモリはこの作業を省略することに相当するためです。

祝福と呪いには当然悪い面もあります:
3.オフヒープ メモリは制御が難しく、メモリ リークが発生した場合のトラブルシューティングが困難です
4.オフヒープ メモリは非常に複雑なオブジェクトの保存には比較的適していません。一般に、単純なオブジェクトまたは平らなオブジェクトの方が適しています。

40. ゼロコピーとは何ですか?

ゼロコピーテクノロジとは、コンピュータが操作を実行するときに、CPU が最初に 1 つのメモリから別の特定の領域にデータをコピーする必要がないことを意味します。この手法は、ネットワーク上でファイルを転送するときに CPU サイクルとメモリ帯域幅を節約するために一般的に使用されます。

• ゼロコピーテクノロジは、データコピーと共有バス操作の数を削減し、メモリ間の不要なデータの中間コピーを排除することで、データ転送効率を効果的に向上させることができます。
• ゼロコピー テクノロジは、ユーザー プロセス アドレス空間とカーネル アドレス空間の間の CPU コンテキストの切り替えによって生じるオーバーヘッドを削減します。

ゼロコピーはコピーが必要ないことを意味するのではなく、冗長な（不要な）コピーが削減されることを意味することがわかります。

Linux I/O メカニズムと DMA

初期のコンピューターでは、ユーザー プロセスはディスク データを読み取る必要があり、それには CPU 割り込みと CPU の参加が必要であったため、効率は比較的低く、IO リクエストが開始され、各 IO 割り込みによって CPU コンテキスト スイッチが発生しました。そこで登場したのが - DMA です。

DMA (ダイレクト メモリ アクセス) は、最新のすべてのコンピュータの重要な機能であり、CPU への大きな割り込み負荷に依存せずに、異なる速度のハードウェア デバイスが通信できるようにします。

DMA コントローラーがデータの読み取りおよび書き込み要求を引き継ぎ、CPU の負担を軽減します。このようにして、CPU は効率的に動作できます。最近のハードドライブは基本的に DMA をサポートしています。

したがって、実際の IO 読み取りには次の 2 つのプロセスが含まれます。

1. DMA はデータの準備ができるのを待ち、ディスク データをオペレーティング システムのカーネル バッファに読み取ります。
2. ユーザー プロセスは、カーネル バッファー内のデータをユーザー空間にコピーします。

両方のプロセスがブロックされます。

従来のデータ転送メカニズム

たとえば、ファイルを読み取り、ソケットを使用して送信するには、実際には 4 つのコピーが必要です。疑似コードの実装は次のとおりです。

buffer = File.read()
Socket.send(buffer)

1. 初回: ディスク ファイルをオペレーティング システムのカーネル バッファに読み取ります。
2. 2 回目: カーネル バッファー内のデータをアプリケーション バッファーにコピーします。
3. ステップ 3: アプリケーション バッファ内のデータをソケット ネットワーク送信バッファ (オペレーティング システム カーネルに属するバッファ) にコピーします。
4. 4回目：ソケットバッファのデータをネットワークカードにコピーし、ネットワークカードがネットワーク送信を行います。

上記のプロセスを分析すると、CPU の割り込み要求を引き継ぐために DMA が導入されていますが、 4 つのコピーの中に「不要なコピー」が存在します。データの 2 番目と 3 番目のコピーは実際には必要ありません。アプリケーションはデータをキャッシュし、それをソケット バッファに転送するだけです。代わりに、データを読み取りバッファからソケット バッファに直接転送できます。

明らかに、このシナリオでは 2 番目と 3 番目のデータ コピーは役に立ちませんが、オーバーヘッドが生じます。これがゼロ コピーの背景と重要性です。

同時に、読み取りと送信は両方ともシステム コールであり、各呼び出しには 2 つのコンテキスト スイッチが含まれます。

要約すると、従来のデータ転送のコストは、コピー 4 回、コンテキスト スイッチ 4 回です。4 つのコピーのうち、2 つはDMA コピー、2 つはCPU コピーです。

Linux でサポートされる (共通の) ゼロコピー

目的: IO プロセスでの不必要なコピーを削減します もちろん、ゼロコピーには OS のサポートが必要です。つまり、カーネルが API を公開する必要があります。

• mmap メモリ マッピング:ハードディスク上のファイルの場所はアプリケーション バッファにマッピングされます (1
  対 1 の対応を確立します) 。mmap() はファイルをユーザー空間に直接マッピングするため、実際のファイルはこれに従って読み取られます。マッピング関係により、ファイルはハードディスクからユーザー空間に直接コピーされます。データ コピーは 1 回だけ実行され、ファイルの内容はハードディスクからカーネル空間のバッファにコピーされません。

  mmap メモリ マッピングは次の 3 つのコピーを実行します: 1 つの CPU コピー、2 つの DMA コピー、および 4 つのコンテキスト スイッチ
  

• sendfile: Linux 2.1 でサポートされる sendfile sendfile() が呼び出されると、DMA はディスク データをカーネル バッファにコピーし、カーネル内のカーネル バッファをソケット バッファに直接コピーします。ハードウェアがサポートしている場合は、データであってもソケットに関連付けられたバッファに実際にコピーする必要はありません。代わりに、データの場所と長さを記録する記述子のみがソケット バッファーに追加され、DMA モジュールはデータをカーネル バッファーからプロトコル エンジンに直接渡し、従来の直前のコピーを排除します。

  データがすべてソケット バッファにコピーされると、sendfile() システム コールが返され、データ変換の完了が示されます。ソケット バッファ内のデータはネットワーク経由で送信できます。

  sendfile は、コピー 3 つ、CPU コピー 1 つ、DMA コピー 2 つを実行します。ハードウェアがサポートしている場合は、コピー 2 つ、CPU コピー 0 つ、DMA コピー 2 つになります。および 2 つのコンテキスト スイッチ
  

• splice: Linux は 2.6.17 からスプライスをサポートします。データがディスクから OS カーネル バッファに読み取られた後、カーネル バッファはユーザー空間にコピーせずに、それをカーネル空間内の他のデータ バッファに直接変換できます。

  次の図に示すように、ディスクからカーネル バッファを読み取った後、カーネル空間内のソケット バッファとのパイプが直接確立されます。

  sendfile() とは異なり、splice() はハードウェアのサポートを必要としません。

  splice と sendfile の違いに注意してください。sendfile では、ディスク データをカーネル バッファにロードした後、ソケット バッファにコピーするために CPU コピーが必要です。Splice はさらに一歩進んでおり、CPU コピーさえ必要とせず、2 つのカーネル空間内のバッファを直接パイプします。

  スプライスは 2 つのコピーを経由します: 0 CPU コピー、2 DMA コピー、および 2 コンテキスト スイッチ
  

Linux におけるゼロコピーの概要

ゼロコピーの最も初期の定義は次のとおりです。

Linux 2.4 カーネルは新しい sendfile システム コールを追加し、ゼロ コピーを提供します。ディスク データは、DMA を通じてカーネル ステート バッファにコピーされた後、CPU のコピーを行わずに、DMA を通じて NIO バッファ (ソケット バッファ) に直接コピーされます。

これがゼロコピーという用語の由来です。これは、オペレーティング システムの本当の意味でのゼロ コピー (つまり、狭義のゼロ コピー) です。

しかし、OS カーネルによって提供されるオペレーティング システムの意味でのゼロ コピーの種類はそれほど多くないことがわかっています。これまでのところ、そのようなゼロ コピーはそれほど多くはありません。開発に伴い、ゼロ コピーの概念は拡張され、現在はゼロ コピーの概念が拡張されています。不要なデータコピーの削減もコピーゼロの範疇に含まれます。

41. Linux の IO モデルとは何ですか?

Linux における 5 つのネットワーク IO モデル:

• ①ブロッキングIO（ブロッキングIO）
• ②ノンブロッキングIO（ノーブロッキングIO）
• ③ IO多重化（select、poll、epoll）（IO多重化）
• ④シグナルドリブンIO（シグナルドリブンIO）
• ⑤ 非同期IO（非同期IO）

タイプ⑤を除く他の 4 タイプはすべて同期 IO です。

5 つの I/O モデルの比較:

さまざまな I/O モデルの違いは、実際には主に、データの待機時間とデータのコピーの 2 つの時間にあります。

42. epoll効率の原則

• プロセスがepoll_create()メソッドを呼び出すと、Linux カーネルは構造を作成しeventpoll、受信ソケットを格納するためにカーネル内に赤黒ツリーcacheが構築されます。また、準備完了イベントを格納する二重リンク リストも作成されます。呼び出されると、この二重リンクリストにデータがあるかどうかを観察します。データがあればリターン、データがなければスリープ、タイムアウト時間が経過するとリンクリストにデータがなくてもリターンします。epoll_ctl()rdllist epoll_wait()rdllist

• 同時に、epollに追加されたすべてのイベントは、デバイス (ネットワーク カードなど) ドライバーとのコールバック関係を確立します。つまり、対応するイベントが発生すると、ここでのコールバック メソッドが呼び出されます。このコールバック メソッドは kernel で呼び出されep_poll_callback、そのようなイベントをrdllist上記の二重リンク リストに追加します。

• epoll_wait()イベントが発生する接続があるかどうかを確認するために呼び出すと、eventpollオブジェクト内のrdllist二重リンク リストにepitem要素があるかどうかだけがチェックされ、rdllistリンク リストが空でない場合、ここでのイベントはユーザー モード メモリ (共有メモリを使用) にコピーされます。効率を向上させるため)、イベントは次のとおりです。数量がユーザーに返されます。したがって、epoll_wait()非常に効率的であり、数百万の同時接続を簡単に処理できます。

43. QQ の設計を依頼された場合、ネットワーク プロトコルの設計をどのように検討しますか?

TCP プロトコルと HTTP プロトコルはログインに使用され、UDP プロトコルは主に友人との間のメッセージの送信に使用され、P2P テクノロジはイントラネット上のファイルの転送に使用されます。

一般的に言えば:

1. ログイン プロセス中、クライアントは TCP プロトコルを使用してサーバーに情報を送信し、HTTP プロトコルを使用して情報をダウンロードします。ログイン後は、オンラインを維持するために TCP 接続が行われます。
2. 友人にメッセージを送信するには、クライアントは UDP プロトコルを使用しますが、サーバー経由で転送する必要があります。メッセージ送信の信頼性を確保するために、Tencent は上位層プロトコルを使用して信頼性の高い送信を保証します。メッセージの送信に失敗した場合、クライアントはメッセージの送信に失敗したことを示すプロンプトを表示し、メッセージを再送信できます。
3. イントラネット上の 2 つのクライアント間でファイルが転送される場合、QQ は P2P テクノロジを使用するため、サーバー転送は必要ありません。