NACK vs.ACK？いつ他の1つを使用するのですか？

個人的には、ACKの必要性は感じていません。受信したパケットごとにACKを送信する代わりに、失われたパケットに対してNACK（n）を送信する方が高速です。それでは、いつ/どの状況でACKをNACK経由で使用しますか？

ACKの理由は、NACKだけでは不十分だからです。X個のセグメントのデータストリームを送信するとします（簡単にするために10個としましょう）。

接続が不良で、セグメント1、2、4、5のみを受信します。コンピュータはセグメント3のNACKを送信しますが、セグメント6〜10があるはずであり、それらをNACKしません。

そのため、セグメント3を再送信しましたが、コンピューターはデータが正常に送信されたと誤って信じています。

ACKは、セグメントが宛先に到着したことをある程度保証します。

アプリケーションでデータの順序と再送信を処理する場合は、UDPなどのプロトコルを使用することを選択できます（たとえば、TFTPのように）。

損失確率の分布とトラフィックパターンに要約されます。

たとえば、10〜30％の安定した損失率を持つ典型的なワイヤレスリンクを考えてみましょう。受信した各フレーム（802.11abgなど）を確認すると、フレームが失われたことをすぐに検出できるため、タイムアウトを待つ時間を失うことはありません。

代わりにNAKを使用した場合は、トラフィックパターンに依存するようになります。回答。-パケットのストリームをほとんどミュート受信者に送信している場合、受信者が次のパケットを受信したときなどにNAKを受信するだけでかまいません。しかし、これは、受信者がパケットを並べ替える必要があり、送信者が送信したメッセージの大きなバックログを追跡する必要があることを意味します。

（802.11nが選択するソリューションは？両方。レシーバーは、受信したフレームの可変長ビットマップを送信します）

さて、典型的なインターネットネットワークを考えてみましょう：何か悪いことが起きるまで、パケット損失は0％近くあります。そして、200msの中断から1分、ハーフ。

リンクが切断された場合を考慮するまで、各パケットを取得することは、損失のないネットワークでは無意味に見えます。ACKまたはNACKを長時間にわたって受信することはなく、受信者は通常、リンクが送信されるまで何も送信しません復元されます。

ACKを使用すると、送信者は送信を停止し、リンクが復元されるまでバックログを保持します。代わりにNACKを使用すると、受信者は、長い間送信者のバックログから落ちたパケットを受信して​​おらず、接続が本質的に回復不能であると最終的に通知する場合があります。

ACKはスライディングウィンドウプロトコルで役立ち、送信者Aは、送信されたデータがリモートBによって受信されたことを認識できます。送信者Aは、送信ウィンドウがいっぱいになるまで（リモートに送信されたがまだ送信されていないデータの）確認済み）。

ACKはNAKよりも重要であると見なされる場合があります。Aによって送信されたパケット/ブロックがBによって受信されず、Bが何らかの方法でパケット/ブロックが欠落していることを検出する場合、NAKは単に高速な回復を可能にします。

NAKを使用せず、ACKのみで信頼性の高い転送とフロー制御をサポートするプロトコルを設計することは完全に実行可能です（送信機がACKを受信しない場合の送信機による再送信、いずれの場合でも必要な再送信メカニズムを使用）。

ここで追加したい最も重要なことの1つは、TCPで、すべての受信パケットに対してACKを送信しないことです。

ただし、ACKは最後に受信したパケットに対してのみ送信されます。

私が間違っている場合は修正してください。