[コンピュータネットワークのステレオタイプ] コンピュータネットワーク (1)

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

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

• OSI 7 層モデル: 大規模で包括的ですが、より複雑で、最初に理論モデルがあり、実際の応用はありません。
• TCP/IP 4 層モデル: 実用的なアプリケーションの開発によって要約されています. 本質的に、TCP/IP には上位 3 層のみがあり、最下位層には特定の内容はありません. TCP/IP 参照モデルは実際には記述されていませんこの層の実現。
• 5 層モデル: 5 層モデルは、コンピュータ ネットワークの教育プロセスにのみ表示されます。これは、7 層モデルと 4 層モデルの折衷案であり、簡潔で、概念を明確に説明できます。
  
  7 層のネットワーク アーキテクチャの各層の主な機能は次のとおりです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• DNS、SNMPなどの少量のパケットによる通信。
• ビデオ、オーディオ、その他のマルチメディア通信
• 同報通信

アプリケーション層プロトコル	応用	トランスポート層プロトコル
SMTP	Eメール	TCP
Telnet	リモート端末アクセス	TCP
HTTP	ワールドワイドウェブ	TCP
FTP	ファイル転送	TCP

アプリケーション層プロトコル	応用	トランスポート層プロトコル
DNS	ドメイン変換	UDP
TFTP	ファイル転送	UDP
SNMP	ネットワーク管理	UDP
NFS	リモートファイルサーバー	UDP

TCPの3ウェイハンドシェイクの仕組みを詳しく説明してください。

• 最初のハンドシェイク:クライアントは接続の確立を要求し、同期メッセージ(SYN=1)をサーバーに送信し、乱数 seq = xを初期シーケンス番号として選択し、SYN_SENT状態に入り、サーバーが接続を確立するのを待ちます。確認する。

• 2 番目のハンドシェイク:接続要求メッセージを受信した後、サーバーが接続の確立に同意すると、同期確認メッセージ(SYN=1、ACK=1) をクライアントに送信します。確認番号は ack = x + 1、 [乱数 seq = y を初期シーケンス番号として使用する] を選択し、この時点でサーバーはSYN_RECV状態に入ります。

• 3 回目のハンドシェイク:サーバーから確認を受信した後、クライアントは確認メッセージ(ACK=1)をサーバーに送信します。確認番号は ack = y + 1、シーケンス番号は seq = x + 1、クライアントとサーバーはESTABLISHED状態に入り、3 ウェイ ハンドシェイクを完了します。

なぜ 2 ウェイ ハンドシェイクではなく 3 ウェイ ハンドシェイクがあるのでしょうか?

• 1.期限切れの接続要求メッセージが突然サーバーに送信され、エラーやリソースの無駄が発生することを防ぎます。
  両者間で 2 回のハンドシェイク後に接続を確立できる場合、クライアントが接続の確立を要求するセグメント A を送信すると仮定すると、A はネットワーク上の理由により一時的にサーバーに到達できず、サーバーは確認を返しません。リクエストセグメント部分を受信できない場合はメッセージを返します。クライアントは、長期間応答を受信しない場合、リクエスト メッセージ セグメント B を再送信します。今度は、B がサーバーに正常に到着し、サーバーはすぐに確認メッセージを返し、ESTABLISHED 状態に入ります。確認メッセージを受信した後、クライアントも ESTABLISHED 状態になり、両者は接続を確立してデータを送信し、その後通常どおり切断されます。
  このとき、遅れて到着した A メッセージセグメントがサーバーに到着し、サーバーはすぐに確認メッセージを返して ESTABLISHED 状態になりますが、CLOSED 状態になったクライアントは確認メッセージセグメントを受け入れることができず、ましてや、 ESTABLISHED 状態。これにより、サーバーが一方的に長時間待機することになり、リソースが浪費されます。

• 2 回または 3 回のハンドシェイクにより、双方は自分自身と相手の送受信機能が正常であることを確認できます。
  1回目のハンドシェイク：クライアントはリクエストセグメントを送信するだけで何も確認できないが、サーバーは自身の受信能力と相手の送信能力が正常であることを確認できる 2回目のハンドシェイク：クライアントは自身の送信を確認できる能力
  ・受信能力正常、相手の送信能力・受信能力が正常、
  3回目のハンドシェイク：サーバー側の送信能力・受信能力が正常であることが確認でき、相手の送信能力・受信能力も正常である;
  3 ウェイ ハンドシェイクにより、双方が自分と相手の送受信能力を確認できることがわかります。すべて正常なので、快適に通信できます。

• 3. 相手方に自身のシリアル番号の初期値を通知し、相手方のシリアル番号の初期値の受信を確認します。
  TCP が信頼性の高いデータ伝送を実現できる理由の 1 つは、 TCP メッセージ セグメントにシーケンス番号フィールドと確認シーケンス番号フィールドが保持されていることです。これら 2 つのフィールドを通じて、双方が送信したデータのうちどのデータが確認済みであるかを知ることができます。相手です。これら 2 つのフィールドの値は、初期シーケンス番号の値に基づいてインクリメントされます。双方向ハンドシェイクの場合、イニシエーターの初期シーケンス番号のみが確認でき、もう一方の初期シーケンス番号は確認できません。パーティーは確認できません。

なぜ 4 ウェイ ハンドシェイクではなく 3 ウェイ ハンドシェイクなのでしょうか?

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

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

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

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

原理：

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

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

防止：

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

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

サーバ：

• 3 番目の ACK がネットワークで失われ、サーバー上の TCP 接続のステータスは SYN_RECV (同期が受信されました) になり、TCP タイムアウト再送信メカニズムに従って、3 秒、6 秒、および 12 秒待機します。 SYN+ACK パケットを再送信する前に、クライアントが ACK パケットを再送信するようにします。
• 指定された回数再送信してもクライアントからの ACK 応答が受信されない場合、サーバーは一定の時間が経過した後に接続を自動的に閉じます。

クライアント：

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

TCP の 4 つのウェーブ プロセスを詳しく説明してください。

• 最初のウェーブ:クライアントは接続解放メッセージ (FIN=1、ACK=1) をサーバーに送信し、積極的に接続を閉じ、サーバーからの確認を待ちます。

  • シーケンス番号 seq = m、つまり、クライアントが最後に送信したメッセージの最後のバイトのシーケンス番号+ 1
  • 確認番号 ack = n、つまり、サーバーが最後に送信したメッセージの最後のバイトのシーケンス番号+ 1

• 2 番目の波:接続解放メッセージを受信した後、サーバーは直ちに確認メッセージ(ACK=1)、シーケンス番号 seq = n、および確認番号 ack = m + 1 を送信します。

  • このとき、TCPコネクションはハーフクローズ状態、つまりクライアントからサーバへのコネクションは解放されているが、サーバからクライアントへのコネクションはまだ解放されていない。これは、クライアントには送信するデータがないにもかかわらず、サーバーがクライアントにデータを送信する可能性があることを意味します。

• 3 番目の波:サーバーは接続解放メッセージ (FIN=1、ACK=1) をクライアントに送信し、接続を積極的に閉じて、A の確認を待ちます。

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

• 4 番目の波: サーバーから接続解放メッセージを受信した後、クライアントは直ちに確認メッセージ(ACK=1) を送信します。シーケンス番号 seq = m + 1、確認番号は ack = p + 1 です。

  • この時点で、クライアントはTIME-WAITこの状態に入ります。クライアントから TCP への接続はまだ解放されておらず、2*MSL(最長のメッセージ セグメントの有効期間) 時間が経過した後にのみこの状態に入ることに注意してくださいCLOSED。サーバーがクライアントから確認を受信すると、すぐにCLOSEDこの状態になります。サーバーが TCP 接続を終了する時間がクライアントよりも早いことがわかります。

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

サーバーがクライアントの FIN セグメントを受信した後 (最初の波)、送信するデータがまだある可能性があるため、接続をすぐに閉じることはできませんが、サーバーは応答して ACK セグメントを返します (2 番目の波)。データの送信後、サーバーはクライアントに FIN メッセージを送信し (第 3 波)、データが送信されたことを示し、接続を閉じるように要求します。サーバーのACK と FIN は通常、別々に送信されるため、さらに 1 つのウェーブが発生し、合計 4 つのウェーブが必要になります。

クライアントの TIME-WAIT 状態が 2MSL (最大セグメント存続期間) 待機する必要があるのはなぜですか?

1. サーバーが接続を正常に閉じることができるように、ACK メッセージがサーバーに到達できることを確認してください。
   4回目に振る場合、クライアントからの4回目のACKパケットが必ずしもサーバーに届くとは限りません。サーバーは時間の経過とともに FIN/ACK メッセージを再送信します。この時点でクライアントが切断されている場合、サーバーからの 2 番目の要求に応答することはできません。このようにして、サーバーは FIN の確認を受信できません。 /ACK メッセージが長時間表示されます。正常に切断できません。

   MSL は、セグメントがネットワーク上で存続できる最長時間です。クライアントは 2MSL 時間待機します。つまり【客户端 ACK 报文 1MSL 超时 + 服务端 FIN 报文 1MSL 传输】、サーバーによって再送信された FIN/ACK メッセージを受信できます。その後、クライアントは ACK メッセージを 1 回再送信し、2MSL タイマーを再起動します。これにより、サーバーを正常にシャットダウンできるようになります。

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

2. 無効な接続要求セグメントが後続の接続に表示されるのを防ぎます。

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

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

タイマー + タイムアウト再試行メカニズムにより、最後まで自動的に切断されるまで確認を試みます。具体的には、TCP にはキープアライブ タイマーがあります。サーバーがクライアントからデータを受信するたびにタイマーがリセットされ、通常は2 時間に設定されます。
2 時間以内にクライアントからデータを受信しない場合、サーバーは再試行を開始します。プローブ セグメントを 75 分ごとに送信します。10 回連続してプローブを送信してもクライアントがまだ応答しない場合、サーバーは接続を次のようにみなします。切断されて閉じられます。

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

サーバーの観点から見ると、短期間に多数のクライアント接続を閉じると、サーバー上で大量の TIME_WAIT 接続が発生し、サーバーのリソースが大幅に消費されます。このとき、一部のクライアントは接続できないことを示します。 。
クライアント側から見ると、クライアント側で TIME_WAIT が多すぎるとポート リソースが占有されてしまいます。これは、ポートが 65536 個しかなく、ポートがいっぱいになると新しい接続を作成できないためです。
解決：

• サーバーはソケット オプションを設定することで TIME_WAIT 状態を回避できます。このソケット オプションは、このポートがビジー状態 ( TIME_WAIT 状態) であっても、続行して再利用してくださいとSO_REUSEADDRカーネルに指示します。
  

• システムのカーネルパラメータを調整し、/etc/sysctl.confファイルを変更します。つまり、変更net.ipv4.tcp_tw_reuseおよびtcp_timestamps

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

• 強制的にクローズし、RST パケットを送信して TIME_WAIT 状態をスキップし、直接 CLOSED 状態に入ります。RST パケットは TCP 接続を強制的に閉じるために使用され、ホストができるだけ早く接続を閉じる必要がある場合 (または接続がタイムアウトした場合、ポートまたはホストに到達できない場合)、RST パケットが送信されます。

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

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

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

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

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

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

• シリアル番号/確認応答:

  シリアル番号の役割はレスポンスの役割だけではなく、シリアル番号を使用することで受信データをシリアル番号でソートしたり、シリアル番号が重複するデータを削除したりすることができます。
  TCP伝送の過程では、受信側はデータを受信するたびに、送信側への応答を確認します。つまり、対応する確認シーケンス番号を含む ACK メッセージを送信し、受信したデータと次のデータの送信先を送信者に伝えます。

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

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

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

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

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

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

スライディング ウィンドウの左側は送信されて確認されたパケット、スライディング ウィンドウの右側はまだ到着していないパケットです。

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

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

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

TCP は、輻輳制御を実現するために合計 4 つのアルゴリズムを使用します。

• スロースタート(スロースタート);

• 輻輳回避（輻輳回避）;

• 高速再送信。

• 素早い回復。

送信側は、cwnd輻輳ウィンドウと呼ばれる状態変数を維持します。cwnd の値が輻輳ウィンドウ削減の初期しきい値まで減少するとcwndssthresh、代わりに輻輳回避アルゴリズムが使用されます。

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

輻輳回避: 輻輳回避アルゴリズムは、輻輳ウィンドウをゆっくりと拡大させます。つまり、送信者の輻輳ウィンドウは、cwnd+1 往復時間 RTT が経過するたびに 2 倍になるわけではありません。このようにして、輻輳ウィンドウは線形法則に従ってゆっくりと増加します。

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

高速リカバリ: 主に高速再送信と組み合わせて使用​​します。送信者が 3 回連続して繰り返し確認を受信すると、(ネットワークの輻輳を防ぐために) 「乗算削減」アルゴリズムを実行しssthreshてしきい値を半分にしますが、ネットワークが輻輳している場合はスロー スタート アルゴリズムは実行しません。確認が何度も繰り返されることはありません。確認が 3 回繰り返されると、ネットワークの状態が正常であることを示します。