作者：林沛滿
出處：Wireshark網絡分析就是這么簡單
1.每個TCP的包都含有“window size” (也就是win=)的信息。這個值表示發送窗口的大小嗎？
這個不是發送窗口，
而是在向對方表明自己的接收窗口。
另，加入接收方處理數據的速度跟不上接收數據的速度，緩存就會被占滿，從而導致接收窗口為0。
2.我如何在包里看出發送窗口的大小呢？
很遺憾，沒有簡單的辦法。因為，當發送窗口是由接收窗口決定的時候，我們還可以通過“window size:”的值來判斷。而當它由網絡因素決定的時候，事情就會變得非常復雜。
3.發送窗口和MSS有什么關系？
發送窗口決定了一口氣能發多少字節，而MSS決定了這些字節要分多少個包發完。舉個例子，在發送窗口為16000字節的情況下，如果MSS為1000字節，那就需要發送16000/1000=16個包；
4.發送方在一個窗口里發出n個包，是不是就能收到n個確認包？
不一定，確認包一般會少一些。由于TCP可以累積起來確認，所以當收到多個包的時候，只需要確認最后一個就可以了。
5.經常聽人說“TCP Window Scale”這個概念，他究竟和接收窗口有什么關系呢？
在TCP剛被發明的時候，全世界的網絡貸款都很小，所以最大接收窗口被定義為65535字節。隨著硬件的革命性進步，65535字節已經成為性能瓶頸了。怎么樣才能擴展呢？TCP頭中只給接受窗口溜了16bit，肯定無法突破65535字節的。
1992年的RFC1323中提出一個解決方案，就是在三次我我握手中，增加Window Scale信息放到TCP頭之外的Options中（也就不需要修改TCP頭的設計）。Window Scale的作用是向對方聲明一個Shift count ，我們把它作為2的指數，再乘以TCP頭中定義的接收窗口，就得到真正的TCP接收窗口了。如果IP A告訴IP B說它的Shift count是5。2^5等于32，這就意味著以后的（此次三次握手之后）IP A聲明的接收窗口要乘以32才是真正的接收窗口值。
要注意Wireshark是根據Shift count計算出這個Win的數值，如果Wireshark抓包是沒有抓到三次握手，Wireshark就不知道怎么計算了，所以有時候我們會看到莫名的一些很小的接收窗口值。還有些時候是防火墻識別不了Window Scale，因此對方無法獲得Shift count，最終導致嚴重的性能問題。
