バッファに空きがあると送信できる

TCPのウインドウ管理は直接、確認通知に束縛されるものではない。例えば、受信者が4096バイトのバッファを持っていると仮定しよう。送信者が2048バイトのセグメントを送り、それが、正常に受信されると受信者はそのセグメントの確認通知をする。受信者にはこのとき2048バイトのバッファ・スペースが存在するので（アプリケーションがバッファからデータを取り込んでくれないと空きが増えない)、次の受信することを期待するバイトの順序番号2048とウインドウ幅として2048バイトを通知するだろう。

ウインドウ通知が０になると送信できない

送信者がさらに2048バイトを送り、それが、確認通知され、ウインドウ通知が０になったとしよう。送信者は受信ホスト上のアプリケーション・プロセスがバッファからデータを取り込むまで停止していなければならない。空きがでると、TCPは０でないウインドウを通知できる。

遠隔マシン上のプロセスの削除、受信者に順序番号とウインドウ幅を聞く場合のみ０でも送信できる

ウインドウが0の時送信者はセグメントを送っていけない。しかし、二つの例外がある。一つは緊急データで、ユーザーが遠隔マシン上のプロセスを消すなどの目的に使われる。もう一つは、受信者に順序番号とウインドウ幅をもう一度通知させるための1バイトのセグメントである。このパケットをウインドウ・プローブ(window probe)と呼ぶ。TCP標準はこのオプションを明示的に提供している。ウインドウ通知が毎回ロスしてしまうようなデッドロックを回避するためである。

応答を遅らせてまとめてまとめて確認通知する

1文字が送信TCPエンティティに到着し、TCPが21バイトのTCPセグメントを生成し、IPがそれを41バイトのIPデータグラムとして送ってしまう。

確認通知とウインドウ更新を５００ミリ秒遅らせて、なるべく複数のデータを一つのパケットで送ろうとしている。これを遅延ACK(delayed acknowledgement:遅延確認応答)と呼ぶ。

Nagleのアルゴリズムでバッファする

送信者がたった1バイトのデータを41バイトのパケットで送ってしまうという非効率さに変わりはない。

送信者に１バイトずつデータがやって来る時、とにかく最初のバイトを送信し、それが、確認通知されるまで、やってくるデータ全てをバッファするというものである。確認通知されタラ、それまでバッファされたそれまでバッファされた文字を一つのTCPセグメントで送信し、再び送信したデータ全てが確認通知されるまで、バッファリングを開始する。