2 つの隣接するノード間のリンク上のトラフィックを制御する作業はどこで行われますか?

隣接する 2 つのノード間のリンク上のトラフィックを制御する作業は、「リンク層」で完了します。データリンク層の最も基本的な機能は、この層のユーザーに透過的で信頼性の高いデータ送信を提供することです。サービス、データリンク層は、元のビットストリームを送信するために物理層の機能を強化し、物理層によって提供されるエラーが発生しやすい物理接続を論理エラーのないデータリンクに変換します。ネットワーク層をエラーのない回線として扱います。

#このチュートリアルの動作環境: Windows 10 システム、DELL G3 コンピューター。

隣接する 2 つのノード間のリンク上のトラフィックを制御するために行われること

リンク層で行われる

データ リンク層基本的な機能は、この層でユーザーに透過的で信頼性の高い基本的なデータ送信サービスを提供することです。透明性とは、この層で送信されるデータの内容、形式、符号化に制限がなく、情報構造の意味を説明する必要がないことを意味し、確実に送信できるため、情報の損失や情報の干渉、情報の混信などの心配がなくなります。間違った順序。このような状況は物理層で発生する可能性があり、エラーを検出して訂正するにはデータリンク層でエラー訂正コードを使用する必要があります。データリンク層は、元のビットストリームを送信する物理層の機能を強化し、物理層によって提供されるエラーが発生しやすい物理接続を論理的にエラーのないデータリンクに変換し、エラーのない回線のように見えます。ネットワーク層へ。

#拡張知識: フロー制御エラー制御はデータ リンク層機能の一部です。もう 1 つの重要な部分はフロー制御です。フロー制御には、受信機が受信前に各文字またはフレームを受け入れるのに十分なバッファ ストレージ スペースを確保できるように、リンク上の文字またはフレームの送信速度を制御することが含まれます。たとえば、文字指向の端末とコンピュータのリンクでは、リモート コンピュータが多数の端末にサービスを提供する場合、ピーク時にすべての文字を所定の速度で送信できないため、一時的に過負荷になる可能性があります。同様に、フレーム指向の自動再送要求システムでは、応答するフレームの数が増加すると、バッファの記憶容量を超えて過負荷が発生する可能性があります。

XON/XOFF方式

バッファの保存容量を増やすことで受信側と送信側の伝送速度の差をある程度緩和できますが、これは受動的なものです。ネガティブおよびパッシブな方法には、実装において多くの不便さと制限があります。システムは過度に大きなバッファ スペースの確立を許可しない一方で、速度が著しく不一致で大きなファイルが送信される場合には、依然としてバッファ スペースが不足します。 XON/XOFF スキームは、よりアクティブでアクティブなフロー制御方法です。 XON/XOFF スキームでは、フロー制御を実装するために 1 対の制御文字が使用されます。XON は ASCII 文字セットの制御文字 DC1 を使用し、XOFF は ASCII 文字セットの制御文字 DC3 を使用します。通信チェーン上の受信側が過負荷になると、送信側に XOFF キャラクタを送信し、データの送信を一時的に停止します。受信側がバッファ メモリ内のデータを処理し、過負荷が回復した後、送信側に XON キャラクタを送信します。 . 、送信者にデータ送信を再開するように通知します。データ送信プロセス中に、XOFF サイクルと XON サイクルが複数回繰り返される可能性がありますが、ユーザーには意識されません。多くの非同期データ通信ソフトウェア パッケージは XON/XOFF プロトコルをサポートしています。このスキームは、コンピュータがプリンタまたは他の端末装置に文字を送信するために使用することもできます。この場合、プリンタまたは端末装置の制御コンポーネントが文字の流れを制御するために使用されます。

ウィンドウの仕組み

チャネルの有効利用を向上させるため。前項で述べたように、送信側は確認フレームの返信を待たずに複数のフレームを連続して送信する、この送信処理が連続したパイプラインに似ているため、パイプライン技術とも呼ばれます。複数の未承認のフォールドフレームを連続して送信することが許可されているため、フレーム番号は複数ビットの 2 進数を使用して区別できます。送信されても​​確認されていないフレームはエラーまたは損失する可能性があり、再送信が必要になるため、これらのフレームは保持する必要があります。これには、再送信が必要になる可能性がある未確認のフレームを保持するために、送信側に大きな送信バッファが必要です。ただし、バッファ容量には常に限界があるため、受信側が送信側の送信速度で受信フレームを処理できない場合でも、バッファ容量が不足し、一時的に過負荷になる可能性があります。この目的のために、アイドル RQ スキームと同様の調整手段を導入することができます。その本質は、送信者が特定のフレームを受信する前に送信できるフレーム数を制限することです。これは、送信者が予約されたフレーム数を調整した結果です。再発行はフレーム数を確認することで実現します。受信者に受信フレームを処理する時間がない場合、受信者は確認応答情報の送信を停止します。この時点で、送信者の再公開制限に達します。再公開制限に達すると、確認応答が送信されるまで新しいフレームは送信されません。再度情報を頂きました。この解決策を実現するには、未確認フレームの再送信時に未確認フレームの最大数を設定する必要があり、この制限はリンクの送信ウィンドウと呼ばれます。明らかに、ウィンドウが 1 に設定されている場合、つまり送信側のバッファリング容量が 1 フレームに等しい場合、送信制御方式はアイドル RQ 方式に戻りますが、このとき、送信効率は非常に低いため、ウィンドウ制限は、受信側が可能な限り処理または受け入れできるように選択する必要があります。もちろん、選択する際には、最大フレーム長、利用可能なバッファ容量、送信ビット レートなどの要素も考慮する必要があります。再発行は、送信者が送信したがまだ確認応答していないフレームに対応する連続したシーケンス番号のリストです。これらのフレームのシーケンス番号には最大値があり、これが送信ウィンドウの制限になります。いわゆる送信ウィンドウは、送信されたが送信者によってまだ確認されていないフレーム番号のキューの境界を指します。上限と下限は、それぞれ送信ウィンドウの上端と下端、および送信ウィンドウ間の距離と呼ばれます。上端と下端はウィンドウ サイズと呼ばれます。受信機にも同様に、受信が許可されるフレームのシーケンス番号を示す受信ウィンドウがあります。受信ウィンドウの上限と下限も時間とともにスライドします。

送信者がフレームを送信するたびに、確認応答されるフレームの数は 1 ずつ増加します。同様に、送信者が確認メッセージを受信するたびに、確認応答されるフレームの数は 1 ずつ減少します。再送カウント値、つまり確認応答するフレームの数が送信ウィンドウと等しくなると、新しいフレームの送信が停止されます。一般にフレーム番号は限られた2進数で一定時間ごとに循環しますが、フレーム番号に3桁の2進数が付加されている場合、フレーム番号は0から7の間を循環します。送信処理中はウィンドウの位置がスライドし続けるため、スライディングウィンドウ（Slidding Window）、または単にスライディングウィンドウとも呼ばれます。

スライディング ウィンドウの状態変更プロセスは次のように記述できます (送信ウィンドウを 2、受信ウィンドウを 1 と仮定します)。

初期状態では、送信側はフレームを送信せず、送信ウィンドウの前端と後端は等しいです。受信ウィンドウの制限は 1 で、フレーム 0 の受信が許可されます。

送信者はフレーム番号 0 を送信しました。このとき、送信ポートは開いており (つまり、先頭が 1 増加します)、ウィンドウは番号 0 に揃っています。フレームは送信されましたが、確認応答メッセージがまだ受信されていません。受信ウィンドウのステータスは以前と同じで、0 フレームの受信が許可されていることを示します。

送信側はフレーム0の確認返信情報を受信する前にフレームNo.1の送信を続けます。送信ウィンドウのステータスは変わりません。

送信者はフレーム 0 を受信し、ウィンドウが 1 スペース分スライドして、フレーム No. 1 を受信する準備ができていることを示します。送信ウィンドウのステータスは変わりません。

送信者はフレーム番号 0 の確認返信情報を受信し、送信ウィンドウの後端が 1 増加します。これは、フレーム番号 0 が再公開から削除されたことを示し、ステータスはフレーム番号 0 です。受信ウィンドウは変更されません。

送信者は 2 つのフレームを送信し続け、送信ウィンドウの先頭が 1 つ増加します。これは、フレーム 2 も保留中の確認のリストに含まれていることを示します。受信

ウィンドウのステータスは変わりません。

受信機はフレーム No. 1 を受信し、受信ウィンドウが 1 スペーススライドして、フレーム No. 2 を受信する準備ができていることを示します。送信ウィンドウのステータスは変わりません。

送信側は受信側からフレーム No. 1 を受信したという確認メッセージを受信し、送信ウィンドウの後端が 1 ずつ増加します。これは、最初に受信したフレーム No. 1 がフレームから削除されることを示します。再出版。受信ウィンドウのステータスは変わりません。一般に、特定の範囲内に到着するフレームは、順序が異なっていても受信する必要があります。この範囲を受信ウィンドウと見なす場合、受信ウィンドウのサイズは 1 より大きい必要があり、Go-back-N は受信ウィンドウが 1 に等しい特殊なケースです。選択的再送信は、送信ウィンドウと受信ウィンドウの両方が 1 より大きいことを除いて、スライディング ウィンドウ プロトコルとみなすこともできます。アイドル RQ、ゴーバック N、選択的再送信の 3 つのプロトコルをスライディング ウィンドウの観点から見ると、それらの違いはそれぞれのウィンドウのサイズにあります。

アイドル RQ: 送信window = 1 、受信 window=1

Go-back-N: 送信ウィンドウ>1、受信ウィンドウ=1

再送信の選択: 送信ウィンドウ>1、受信ウィンドウ>1

フレームシーケンス番号が 3 桁のバイナリエンコーディングを採用している場合、最大シーケンス番号は SMAX=2^3-1=7 です。順序付け受信モードの場合、送信ウィンドウの最大サイズは SMAX として選択されますが、非フェンス受信モードの場合、送信ウィンドウの最大サイズはシーケンス番号範囲の最大でも半分です。タイムアウト制御を管理するタイマーは、シーケンス番号スペースのサイズではなく、送信バッファーの数に等しい必要があります。実際には、各バッファはタイマーに対応する必要があり、タイマーがタイムアウトすると、対応するバッファの内容が再送信されます。受信側が設定する必要があるバッファの数は、シーケンス番号スペースのサイズではなく、受信ウィンドウのサイズと同じである必要があります。

関連知識の詳細については、FAQ 列をご覧ください。

以上が2 つの隣接するノード間のリンク上のトラフィックを制御する作業はどこで行われますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。