そのため、現代のネットワークの実際の大部分は、パケット伝送とIPを基盤として使用しています。 情報はネットワークを通じて情報の断片として送信され、通常、これらの断片のサイズは1バイトから1,500バイトまで変化します（ペイロードを意味します）。 WANネットワークを通過する途中で、そのようなパケットは非常に多くのルーターとゲートウェイを通過できます。 Tracerouteユーティリティを使用して、これらの積み替えポイントの一部を確認できます。 しかし、これらはすべての実際の中継ノードからはほど遠いです。たとえば、ここではトラフィックがトンネル化されたノード（MPLS VPN、GREなど）は表示されません。 同時に、ゼロ以外の確率で、トランジットノードの1つは現時点で負荷が高くなり、ネットワークの輻輳を防ぐためにパケットを破壊します。 そして、そのような中継ノードが多いほど、ネットワークでのパケット損失の可能性が高くなります。
例として、同じ通信チャネルで時間の経過とともに失われたパケットの割合がどのように変化するかを示す写真を示します。
理論的には、このようなパケットのドロップは完全に安全で正常なものです。特殊なTCPプロトコルがデータ転送の整合性を監視します。 しかし、いつものように、微妙な違いがあります。 微妙な点は、パケット損失が発生した場合、TCPプロトコルがネットワーク上で再度送信する必要があることです。 ただし、再出荷を決定するには、次のパケットが受信されていないという受信側からの通知を待つ必要があります。 ここで、信号遅延などのネットワークパラメータが重要になります。 それが長いほど、送信側が暗闇に長くなり、情報の送信が遅くなります。
以下は、通信チャネルの遅延とパケット損失の割合に対するトラフィック速度の依存性のグラフです。 実際、一般的なWANの遅延が50〜100ミリ秒のチャネルでの伝送速度の主な損失は、損失の割合が1〜2％であるように見えます。
電話やビデオ会議など、UDPを介して動作し、リアルタイムで動作することに焦点を当てているアプリケーションについて話す場合、再送信メカニズムは提供されず、正当化されません。 そして、損失がある場合は、何と言っても、アーティファクトは「きしみ」、「utter音」、および周期的に崩れる画像の形で出てきます。
Silver Peakのエンジニアが行ったように、パケット損失はわずかに異なる角度から見ることができ、かなりエレガントな方法で解決できることがわかりました。 間違いなく、多くの人がエラーを特定できる特別なコーディング方法について耳にしたことがあり、その中には情報のエラーを修正するものもあります。 たとえば、ECCコードとリードソロモンコードは、CDが登場した70年代に最初に工業的に使用されました。 このようなコードの一般的な意味は、ある程度の冗長性を導入することであり、この冗長性は現在のチャネル特性に適応的に適応できます。 別のより具体的な例は、3、4、5、またはそれ以上のデータディスクごとに1つの冗長ディスクドライブを提供するRAID5ディスクアレイ上の情報を保護する技術です。 パケット伝送の場合、ディスクの類似物はパケット自体です。N個のパケットごとに、1つの冗長パケットが作成されます。
問題は、一般的な英語名の前方誤り訂正（FEC）を持つこのような技術は、通常、データ伝送チャネルの物理レベルでのみ使用されることです。 また、ネットワークの輻輳、動的なトポロジの再配置などに関連する情報の損失を排除することはできません。 Silver Peakのエンジニアは、FECテクノロジーをリンクレベルで実装したため、任意の2つのSilver Peakデバイス間で、多数の冗長パケットがサポートされ、適応的に調整される独自の「トンネル」を作成します。 このソリューションとFECテクノロジーを使用した一般的な通信チャネルトポロジを次の図に示します。
非送信側のデバイスが過剰なパケットを生成する方法と、受信側のデバイスがそれに基づいて別の失われたパケットを再作成する方法を示しています。
パケット損失を排除するためにFECを使用する有効性を評価するために、特定の割合のトラフィック損失で、ファイルがネットワークを介して送信された時間を調べることができます。 次の図は、冗長性のわずかな割合でさえ、ファイル転送速度を数倍向上させ、ビデオ会議中のduring音やキュービズム風の写真は簡単に忘れられることを示しています。
