TCP協議當中最重要的部分就是流量控制（flow control）和擁塞控制（congestion control）了。
TCP協議的流量控制是通過窗口機制實現的，:-)。只聽這些概念很抽象，扭頭就忘了，我們用個實例來看看。
使用的工具是 tcpdump。使用這個工具獲取一下訪問本機的web服務器所產生的數據如下：
22:14:27.757059 IP ubuntu-xingwang.39585 > ubuntu-xingwang.http: Flags [S], seq 779326623, win 43690, options [mss 65495,sackOK,TS val 1423721 ecr 0,nop,wscale 7], length 0
22:14:27.757093 IP ubuntu-xingwang.http > ubuntu-xingwang.39585: Flags [S.], seq 283855395, ack 779326624, win 43690, options [mss 65495,sackOK,TS val 1423721 ecr 1423721,nop,wscale 7], length 0
22:14:27.757121 IP ubuntu-xingwang.39585 > ubuntu-xingwang.http: Flags [.], ack 1, win342, options [nop,nop,TS val 1423721 ecr 1423721], length 0
22:14:27.757375 IP ubuntu-xingwang.39585 > ubuntu-xingwang.http: Flags [P.], seq 1:372, ack 1, win 342, options [nop,nop,TS val 1423721 ecr 1423721], length371
22:14:27.757421 IP ubuntu-xingwang.http > ubuntu-xingwang.39585: Flags [.], ack 372, win 350, options [nop,nop,TS val 1423721 ecr 1423721], length 0
22:14:27.759204 IP ubuntu-xingwang.http > ubuntu-xingwang.39585: Flags [P.], seq 1:380, ack 372, win 350, options [nop,nop,TS val 1423722 ecr 1423721], length 379
22:14:27.759236 IP ubuntu-xingwang.39585 > ubuntu-xingwang.http: Flags [.], ack 380, win 350, options [nop,nop,TS val 1423722 ecr 1423722], length 0
22:14:32.667501 IP ubuntu-xingwang.http > ubuntu-xingwang.39585: Flags [F.], seq 380, ack 372, win 350, options [nop,nop,TS val 1424949 ecr 1423722], length 0
22:14:32.667748 IP ubuntu-xingwang.39585 > ubuntu-xingwang.http: Flags [F.], seq 372, ack 381, win 350, options [nop,nop,TS val 1424949 ecr 1424949], length 0
22:14:32.667801 IP ubuntu-xingwang.http > ubuntu-xingwang.39585: Flags [.], ack 373, win 350, options [nop,nop,TS val 1424949 ecr 1424949], length 0
可以說是教科書般的流量啊，三次握手建立鏈接（藍色流量）和四次握手斷開鏈接（紅色流量）一清二楚。
我們要注意的就是每條數據中的 win 字段數據，這就是傳說中的窗口（window）了。這個值就是告訴鏈接中的另一方，我端的緩存空間現在是這麼大，下次發送數據的時候別發太多，要不就會有數據無法保存下來，發生丟失。這就是TCP的流量控制方法。
我們來看具體的數據，第三條數據中，本地端口告知服務器，本地的緩存空間暫時只有 342 字節了。按說服務器再次發送數據的時候不會超過這個數的。可是實際上，第四條服務器發送了長度爲372字節的數據。這是爲什麼呢？
原來TCP協議剛制定的時候，只給win字段分配了兩個字節的空間，那麼他的最大數就是65536字節，64K。但是爲了更高效地使用帶寬很高的網絡，科學家們就增加了一個 窗口擴大因子（window scale factor）選項來增加窗口的值。在第一次syn發出的時候，客戶端的選項數據裏的wscale字段值設置爲了7。就是說今後這個端所有的窗口數據都要左移7位，也就是342乘以128，那就是43776字節了。所以服務器發送了372個字節，太小意思了，遠遠沒有超過本地緩存能力呢，呵呵
窗口擴大因子可以是0-14中間的任意一個值。