題目一：
來源2015年408計算機綜合
試題鏈接：https://www.nowcoder.com/questionTerminal/3241441c88f04ab58585a187716055d3
主機甲和主機乙新建一個TCP 連接，甲的擁塞控制初始閾值為 32KB，甲向乙始終以 MSS=1KB 大小的段發送數據，並一直有數據發送；乙為該連接分配 16KB 接收緩存，並對每個數據段進行確認， 忽略段傳輸延遲。若乙收到的數據全部存入緩存，不被取走，則甲從連接建立成功時刻起，未發送超時 的情況下，經過 4 個 RTT 后，甲的發送窗口是（A）。
A.1KB
B.8KB
C.16KB
D.32KB
發送窗口大小取決於min(rwnd,cwnd).
其中rwnd是接收緩存的空余大小，表示接收方還能接收多少。
cwnd就是我們常常畫慢增長曲線，擁塞避免曲線等等分析的縱軸數值。
這里，其實很明確的告訴我們接收緩存只進不出，因此在不斷減小。可是我們有一個思維慣性是喜歡思考有趣的部分，畫cwnd的變化，自以為這個分析好了問題就手到擒來了，切不可忽視rwnd。這里就是個例子。
cwnd從1MSS = 1KB開始，一個RTT后變為2KB，兩個RTT后變為4KB,3RTT后變為8KB，4個RTT后變為16KB
同時呢，接收緩由16KB→15KB→13KB→9KB→1KB16KB→15KB→13KB→9KB→1KB
| 通知窗口值，代表接收緩存剩余值(KB) | 擁塞窗口大小(KB) | 發送窗口大小(KB) | |
| 初始 | 16 | 1 | 1 |
| 經過第一個RTT | 16-1=15 | 2 | min(15, 2)=2 |
| 經過第二個RTT | 15-2=13 | 4 | min(13,4)=4 |
| 經過第三個RTT | 13-4=9 | 8 | min(9,8)=8 |
| 經過第四個RTT | 9-8=1 | 16 | 通知接收緩存只有1KB了，發送窗口取min(1, 16)=1KB |
經過一個RTT，第二次發送時，rwnd = 15KB,cwnd = 2KB，發送窗口取較小值：2KB
經過兩個RTT，第三次發送時，rwnd = 13KB,cwnd = 4KB，發送窗口取較小值：4KB
經過三個RTT，第四次發送時，rwnd = 9KB,cwnd = 8KB，發送窗口取較小值：8KB
經過四個RTT，第五次發送時，rwnd = 1KB,cwnd = 16KB，發送窗口取較小值：1KB
當然第五次發送之后接受窗口就滿了，主機甲就會周期性的只發送一個字節數據的報文段，一旦主機乙的緩存有空，確認報文段就會出現非0的通知窗口值，當然這里是題目要求，主機乙的數據不被取走，僅僅為了計算，並非實際情況。
再來看一題：
題目二：
來源為2014年408計算機綜合
鏈接：https://www.nowcoder.com/questionTerminal/cee6014573f841e2b1b19fbd89ab5d32
主機甲和乙已建立了TCP連接，甲始終以MSS=1KB大小的段發送數據，並一直有數據發送；乙每收到一個數據段都會發出一個接收窗口為10KB的確認段。若甲在t時刻發生超時時擁塞窗口為8KB，則從t時刻起，不再發生超時的情況下，經過10個RTT后，甲的發送窗口是 （A）
A.10KB
B.12KB
C.14KB
D.15KB
分析：
當t時刻發生超時，TCP擁塞控制，擁塞窗口發生乘性減，把ssthresh設為8的一半，即為4，且擁塞窗口設為1KB。然后經歷10個RTT后，擁塞窗口的大小依次為1(t時刻初始)、2(第一個RTT后)、4(第二個RTT后)、5、6、7、8、9、10、11、12(第10個RTT后)，而發送窗口取當時的擁塞窗口和接收窗口的最小值，而接收窗口始終為10KB，所以選A。其中，1、2、4為慢啟動，到達了閾值后開始加性增->5，6，7，8，9，10，11，12.
試題三：
題目來源：北京航空航天大學-2015-961_計算機學科專業基礎綜合
鏈接：https://www.nowcoder.com/questionTerminal/c5bf448282b745a3b97b52d33fac28d6
主機甲中的應用程序使用TCP協議向主機乙發送20KB的數據。在建立TCP連接后，主機甲按照慢啟動（慢開始）和擁塞避免機制發送數據，其擁塞窗口初始值為1，慢啟動門限值ssthresh為8，且每次發送TCP報文段均搭載1KB的用戶數據。
1. 如傳輸過程中未發生確認超時，且不考慮流量控制，則主機甲到第幾輪次時能夠完成題中所述20KB數據的發送？各輪次的擁塞窗口寬度是多少？
2. 如傳輸過程中未發生確認超時，主機乙返回的確認報文段中“窗口（Window size）”字段值始終為6KB，則主機甲到第幾輪次時能夠完成題中所述20KB數據的發送？
分析
1.題目說了不考慮流量控制，而流量控制是TCP接收方針對TCP發送方采取的措施，能夠消除發送方使接收方緩存溢出的可能性。
也就是說，這里接收方接收緩存無限大。而發送窗口=min(接收緩存的通知值，擁塞窗口大小)。所以這里發送窗口=擁塞窗口。
並且收到的確認不超時，不考慮超時重傳。
第一次：發送了1KB，收到確認之后擁塞窗口變為2KB，發送窗口也變為了2KB，此時共發送1KB
第二次：發送了2KB，收到確認之后擁塞窗口變為4KB，發送窗口變為了4KB，此時共發送3KB
第三次：發送了4KB，收到確認之后擁塞窗口變為8KB(准備開始加性增)，發送窗口變為了8KB，此時共發送7KB
第四次：發送了8KB，收到確認之后擁塞窗口變為9KB，發送窗口變為9KB，此時共發送15KB
第五次：發送了9KB，收到確認之后擁塞窗口變為10KB，發送窗口變為10KB，此時共發送24KB
滿足要求！到達第5次時，能夠完成題中所述20KB數據的發送。
2.在TCP報文段結構中有一個接收窗口值，這里題目說明每次返回的報文中，接收窗口的值均為6KB，意味着接收窗口的通知值每次都是6KB，發送窗口值=min(6KB，擁塞窗口值)
第一次：發送了1KB，收到確認之后擁塞窗口變為2KB，發送窗口也變為了min(6KB, 2KB)=2KB，此時共發送1KB
第二次：發送了2KB，收到確認之后擁塞窗口變為4KB，發送窗口變為了min=(6KB, 4KB)=4KB，此時共發送3KB
第三次：發送了4KB，收到確認之后擁塞窗口變為8KB(准備開始加性增)，發送窗口變為了min=(6KB, 8KB)=6KB，此時共發送7KB
第四次：收到確認發送了6KB，之后擁塞窗口變為9KB，發送窗口變為min=(6KB, 9KB)=6KB，此時共發送13KB
第五次：收到確認發送了6KB，之后擁塞窗口變為10KB，發送窗口變為min=(6KB, 10KB)=6KB，此時共發送19KB
第六次：收到確認發送了6KB，之后擁塞窗口變為11KB，發送窗口變為min=(6KB, 11KB)=6KB，此時共發送25KB
綜上分析：主機甲到第6次時能夠完成題中所述20KB數據的發送。
===========================Talk is cheap, show me the code=======================