(Data)使用TCP/IP Protocol通过网络和Internet传输(Internet)数据。TCP/IP并不完美，但与其他理论上的数据通信协议相比更容易实现……例如ISO OSI模型。与任何技术事物一样，TCP/IP也有一些缺陷，而傻窗综合症(Silly Window Syndrome)就是这些缺陷之一的产物。要了解什么是Silly Window Syndrome或SWS，您首先需要了解TCP/IP中数据通信的底层机制。
傻窗综合症
了解窗口及其大小
当两点在TCP/IP下通信时，它涉及到一个确认机制。这种确认机制是导致傻窗综合症(Silly Window Syndrome)的原因，正如进一步解释的那样。点可能是指两台计算机，客户端和服务器等。
SWS is caused by the receiver advancing the right window edge whenever it has any new buffer space available to receive data and by the sender using any incremental window, no matter how small, to send more data. The result can be a stable pattern of sending tiny data segments, even though both sender and receiver have a large total buffer space for the connection, says MSDN.
当一台计算机（比如 A）向另一台计算机 B 发送数据包时，后者必须确认并回复它收到了数据包。除了确认之外，它还必须发送为该通信线程设置的缓冲区大小。这通常是为通信设置的可用字节数。
因此，当 B 说 100B 可用于下一条消息时， 100B 就是Silly Window Syndrome中的窗口。也就是说，它是缓冲区大小。由于其自身的缺陷，TCP/IP机制可能会减少来自 A 的每个通信/数据的缓冲区大小。也就是说，每当 A 发送消息时，B 假设缓冲区大小减小并发送更小的数字。因此，窗口大小不断减小，并且在某一点上，当 B 发送 0B 作为窗口大小时，通信就停止了。
傻窗综合症是如何工作的
根据上面A和B的例子，如果B发送1000B作为窗口大小，A会将其拆分为两个500B，发送两个500B的包。收到第一个数据包后，B 将发送一个确认消息说 500B 可用于窗口，因为尚未收到第二个数据包。A 假设 500B 是窗口大小，因此发送两个 250B 的数据包。在 B 处，使用 500B 并且刚刚收到 500，它将发送 0B 作为可用。此时，A 将假定没有可用的窗口，尽管由于处理器用完那里的数据，缓冲区可能会是空的。A 仍将发送一个较小的数据包以查看是否有可用的窗口。如果 B 处缓冲区的内容尚未删除，它仍将收到 0 作为响应/确认。
因此，窗口大小不断减小，因为 B 每次从 A 接收到数据包时都会发送确认。此大小通常小于先前的确认，因为 B 正在接收部分数据包。如果 A 可以一次发送一个足够大的数据包来覆盖 B 上的缓冲区大小，那将没有问题。但它需要额外的机制，因此需要傻窗综合症(Silly Window Syndrome)。A 收到 0 两三次后通讯停止。
如何预防傻窗综合症(Silly Window Syndrome)（SWS）
有一个简单的算法可以实现摆脱SWS。收到初始数据包后，B 将实际可用空间的一半作为窗口发送。这将使 A 发送更小的数据包。因此，当数据包变得太小时，B 会发送总缓冲区大小，以便 A 可以再次开始发送更大的数据字节。
换句话说，如果 1000B 可用，B 发送 500B 作为确认。因此，A 发送 250B x 2 个数据包。为此，A 收到 100B 作为确认。当它收到 50B 数据包时，B 将 1000B – 50B 发送给 A。这使得整个对话再次运行。这可能会在处理过程中引起一点延迟，但会阻止傻窗综合症(Silly Window Syndrome)的发生并停止整个对话。
总而言之，SWS是基于接收方可用的缓冲区大小和发送方计算的假定大小。为了防止SWS，引入了延迟，并且故意减小了窗口大小，直到数据包大小变得太小。然后接收者披露实际可用的窗口大小。整个过程不断重复，直到通信完成。
尽管我可能交替使用了窗口和缓冲区这两个词。我并不是说它们之间有任何区别。在SWS研究中，缓冲区是窗口。
What is Silly Window Syndrome - Explanation and Prevention
Data is tranѕferred оver the network and Internet using the TCP/IP Protocol. The TCP/IP is not perfect but is easier to implement compared to other protocols theorized for data communication… such as the ISO OSI model. As with any technical thing, TCP/IP has some flaws too and Silly Window Syndrome is a creation of one of those flaws. To understand what is Silly Window Syndrome or SWS, you will first need to understand the underlying mechanism of data communication in TCP/IP.
Silly Window Syndrome
Understanding the window and its size
When two points are communicating under TCP/IP, it involves an acknowledging mechanism. This acknowledging mechanism is what causes Silly Window Syndrome as explained further. Points may refer to two computers, client and server, etc.
SWS is caused by the receiver advancing the right window edge whenever it has any new buffer space available to receive data and by the sender using any incremental window, no matter how small, to send more data. The result can be a stable pattern of sending tiny data segments, even though both sender and receiver have a large total buffer space for the connection, says MSDN.
When a computer, say A, sends a data packet to another computer B, the latter has to acknowledge and reply that it received the data packet. Along with the acknowledgment, it also has to send the size of buffer set apart for that communication thread. This is generally the number of bytes set free for communication.
So when B says 100B is available for the next message, the 100B is the window in Silly Window Syndrome. That is, it is the buffer size. With its own flaw, the TCP/IP mechanism may reduce the buffer size for each communication/data coming from A. That is, whenever A sends a message, B assumes the buffer size is reduced and sends a smaller number. Thus the window size keeps on reduced and at a point, the communication just stops as B sends 0B as the window size.
How Does Silly Window Syndrome Work
According to the above example of A and B, if B sends 1000B as window size, A will split it into two 500B and send two packets of 500B. Upon receipt of the first packet, B will send an acknowledgment saying 500B is available for the window as the second packet is yet to be received. A assumes 500B is the window size and sends two packets of 250B consequently. While at B, 500B is used and 500 is just received, it will send 0B as available. At this point, A will assume no window is available though it might happen that buffer is empty as the processor used up the data there. A will still send a smaller packet to see if any window is available. If the contents of the buffer at B are not yet removed, it will still receive 0 as response/acknowledgment.
Thus, the window size keeps on reducing as B sends acknowledgment every time it receives a packet from A. This size is usually smaller than the previous acknowledgment as B is receiving data packets in parts. There would be no problem if A could send a packet big enough to cover the buffer size on B at a time. But that it would require additional mechanisms and hence Silly Window Syndrome. The communication stops after A receives 0 two or three times.
How to prevent Silly Window Syndrome (SWS)
There is a simple algorithm to be implemented to get rid of SWS. Upon receiving the initial packet, B sends half the really available space as the window. That will make A send smaller packets. Consequently, when the packets become too smaller, then B sends the total buffer size so that A can start sending bigger data bytes again.
In other words, if 1000B is available, B sends 500B as acknowledgment. Accordingly, A sends 250B x 2 packets. For this, A receives 100B as acknowledgment. When it receives 50B packet, B sends 1000B – 50B to A. That makes the entire conversation operational again. This might induce a little delay in processing but will prevent Silly Window Syndrome from occurring and stopping the entire conversation.
To sum up, SWS is based on the buffer size available to the recipient and the assumed size calculated by the sender. To prevent SWS, a delay is introduced and a deliberate smaller window size is reciprocated until packet size becomes too small. Then the recipient discloses actually available window size. The entire process keeps on repeating until the communication is complete.
Although I may have used the words window and buffer interchangeably. I do not mean any difference between them. In SWS studies, the buffer is the window.
