當傳送端應用程序產生資料很慢、或接收端應用程序處理接收緩衝區資料很慢，或二者兼而有之；就會使應用程序間傳送的報文段很小，特別是有效載荷很小。 極端情況下，有效載荷可能只有1個位元組；而傳輸開銷有40位元組(20位元組的ip頭+20位元組的tcp頭) 這種現象就叫糊塗視窗綜合症
如果傳送端為產生資料很慢的應用程式服務(典型的有telnet應用)，例如，一次產生乙個位元組。這個應用程式一次將乙個位元組的資料寫入傳送端的tcp的快取。如果傳送端的tcp沒有特定的指令，它就產生只包括乙個位元組資料的報文段。結果有很多41位元組的ip資料報就在互連網中傳來傳去。
解決的方法是防止傳送端的tcp逐個位元組地傳送資料。必須強迫傳送端的tcp收集資料，然後用乙個更大的資料塊來傳送。傳送端的tcp要等待多長時間呢？如果它等待過長，它就會使整個的過程產生較長的時延。如果它的等待時間不夠長，它就可能傳送較小的報文段。nagle找到了乙個很好的解決方法，發明了nagle演算法。
接收端的tcp可能產生糊塗視窗綜合症，如果它為消耗資料很慢的應用程式服務，例如，一次消耗乙個位元組。假定傳送應用程式產生了1000位元組的資料塊，但接收應用程式每次只吸收1位元組的資料。再假定接收端的tcp的輸入快取為4000位元組。傳送端先傳送第乙個4000位元組的資料。接收端將它儲存在其快取中。現在快取滿了。它通知視窗大小為零，這表示傳送端必須停止傳送資料。接收應用程式從接收端的tcp的輸入快取中讀取第乙個位元組的資料。在入快取中現在有了1位元組的空間。接收端的tcp宣布其視窗大小為1位元組，這表示正渴望等待傳送資料的傳送端的tcp會把這個宣布當作乙個好訊息，並傳送只包括乙個位元組資料的報文段。這樣的過程一直繼續下去。乙個位元組的資料被消耗掉，然後傳送只包含乙個位元組資料的報文段。
對於這種糊塗視窗綜合症，即應用程式消耗資料比到達的慢，有兩種建議的解決方法。
1.clark解決方法
clark解決方法是只要有資料到達就傳送確認，但宣布的視窗大小為零，直到或者快取空間已能放入具有最大長度的報文段，或者快取空間的一半已經空了。
2.延遲確認
這表示當乙個報文段到達時並不立即傳送確認。接收端在確認收到的報文段之前一直等待，直到入快取有足夠的空間為止。延遲的確認防止了傳送端的tcp滑動其視窗。當傳送端的tcp傳送完其資料後，它就停下來了。這樣就防止了這種症狀。遲延的確認還有另乙個優點：它減少了通訊量。接收端不需要確認每乙個報文段。但它也有乙個缺點，就是遲延的確認有可能迫使傳送端重傳其未被確認的報文段。可以用協議來平衡這個優點和缺點，例如現在定義了確認的延遲不能超過500毫秒。
[1]
37 tcp協議 糊塗視窗症候群和nagle演算法
假設一種這麼情況，當傳送方的應用程序傳送資料的速度比較慢，或者接收方的應用程序讀取資料速度比較慢，又或者雙方都有。但無論是對哪一種情況，都會讓傳送資料很小，這將會降低tcp的效能。比如，接收方的快取空間已經滿了，接收方程序每次從快取中唯讀1位元組資料，而快取每次也只騰出1位元組的空間，然後向傳送方傳...
在別處症候群
我思我悟。任何時刻都不要忘記思考，思維永遠是行動的先驅，遙遙領先。第一篇 姑娘，你不是一朵花 第二篇 在別處症候群 第三篇 我們當下的孤獨 第二篇 在別處症候群 身邊不乏這樣的朋友，在乙個地方呆久了，受挫了，或者某個地方留下了傷心的回憶，就會想著換乙個環境，所有的動機和期望都是押注在乙個沒有把握不知...
症候群 本當 怠 病 ？！
筋 有名 病院 受診 分厚 問診票 血液 尿検查。脳 診斷 検查 暗暗 瞳孔 光 當 収縮 見 検查 縞模様 眼球運動 平衡感覚 検查 行 半日 及 検查 結果 症候群 疑 濃厚 診斷 迴圈器系 異常 無 神経系 異常 出 特有 症狀 決 感 怠 病 気 過敏 理解 大変 分 救 感 引越 先生 言...