tcp是乙個端到端（peer-to-peer）的傳輸層協議，處於應用層和網路層之間。在資料傳輸之前，由tcp模組在執行於不同主機上的兩個應用程式之間建立直接連線，通常稱為虛擬連線，其後的tcp報文在此連線的基礎上進行傳輸。tcp協議在ip協議提供的服務基礎上，提供面向連線的、可靠的、全雙工的資料流傳輸服務。
tcp協議通過動態的調整傳送視窗的大小，來達到流量控制以及擁塞控制的目的。傳送視窗的大小等於min(接收視窗的大小,擁塞視窗的大小）。若服務端需要傳輸給客戶端的資料較大，則需要多次分塊傳輸。即需要多個rtt時間才能完成資料的傳輸。顯示接收視窗的大小和擁塞視窗的大小直接影響了完成所有資料傳輸的時間。理想情況下，如果接收端的處理能力足夠強即接收視窗足夠大，同時網路狀況足夠好即擁塞視窗足夠大的話，可以一次性把所需傳送的資料全部分片發給接收方。這樣可以極大的減少網路傳輸耗時。
linux 3.0以前，核心預設的initcwnd比較小，mss為1460時，初始的擁塞控制視窗為3。linux3.0以後，採取了google的建議，把初始擁塞控制視窗調到了10。具體的文章《 an argument for increasing tcp's initial congestion window》。
由於公司內部伺服器之間的通訊都是走專線的。網路狀況足夠好，根據業務需求，可以進一步調大擁塞視窗的初始值嗎？
對於公司內部的伺服器一般情況下ｔｃｐ連線的接收視窗的預設值為87380位元組，最大值為 4194304。ｌｉｎｕｘ核心本身有乙個緩衝大小自動調優的機制，接收視窗的實際大小會自動在最小值和最大值之間浮動，以期找到效能和資源的平衡點。具體引數的設定可以檢視/proc/sys/net/ipv4/下的配置引數。但是傳送方的擁塞視窗的初始值較小，一般是３。由於乙太網的ｍｓｓ為１４６０位元組，那麼就使得第乙個包的大小最大只能為１４６０＊３位元組。
以瀏覽器後台的抓取服務為例。抓取服務是瀏覽器後台實時抓取頁面主資源及子資源的服務。抓取服務採用http協議與部署在全國各地甚至是世界各地的webserver進行資料傳輸，一旦抓取完成需要立即返回給前端呼叫者。實時抓取資源耗時越少，手機瀏覽器使用者的體驗也就越好。
為了縮短抓取服務與**的通訊耗時，通過自實現的智慧型路由服務，抓取服務的主調方會根據情況走專線呼叫其他區域的抓取服務從而使得抓取服務能夠與**就近通訊。公司的跨區域專線的延遲時間大約是30ms左右。即當抓取服務的主調方走跨區域專線呼叫抓取服務時，走專線的耗時是不能忽略的。
經統計，目前網際網路上網頁的內容９９％在１００ｋ以內。所以瀏覽器這邊的所有抓取服務所在機器的擁塞視窗的初始值都修改為了８０。即盡量保證抓取服務一次就能把請求的ｕｒｌ的所有資料都傳送給抓取的主調服務。這樣修改的好處是，對於跨區域呼叫抓取服務時，由於同乙個請求不需要多次通訊，盡量一次網路傳輸就完成了響應，從而降低了抓取服務的響應資料的傳送耗時。
下圖展示了普通情況下一次http請求的耗時：
由圖中可知，一次請求總的耗時=連線建立時間+請求傳送時間+等待響應時間+接收響應時間。連線時間等於1個rtt,因為發出了第三次握手的ack後，馬上就能觸發傳送真正的資料請求，並不用等待**收到這個ack。客戶端傳送請求的時間認為等於0。等待響應的時間，由於需要計算請求到達伺服器的時間以及第乙個響應包到達客戶端的時間，所以等於1個rtt+服務端處理請求耗時。接收響應時間等於n個rtt,n大於等於0，若響應資料一次就傳送完畢了，則按照我們的計算方式，n此時等於零。所以一次請求總的耗時=（n+2)rtt+服務端處理請求耗時。
通過調整擁塞視窗的初始值，可以使得n的取值盡量為0。
通常內部伺服器間通訊是基於長連線的通訊。當連線超過一定時間沒有資料傳輸時，才斷開連線。對於長連線，調整擁塞視窗的初始值有意義嗎？
檢視伺服器的/proc/sys/net/ipv4/目錄下的tcp_max_ssthresh的值，發現tcp_max_ssthresh=0。這個值表示慢啟動閾值。如果擁塞視窗的值cwnd小於閾值ssthresh，那麼表示在慢啟動階段；如果擁塞視窗的值cwnd大於閾值ssthresh，那麼表示在擁塞避免階段，此時擁塞視窗cwnd不再像慢啟動階段那樣呈指數級整整，而是趨向於線性增長，以期避免網路擁塞。
所以對於我們的伺服器，預設情況下，擁塞視窗會一直處於線性增長階段，即增長非常慢。一旦出現丟包，擁塞視窗的值會減半。即在連線建立初期以及出現丟包後，擁塞視窗的值都會較小。從而使得傳送的資料可能需要多次分塊傳輸。
綜上所述，調整伺服器的擁塞視窗的初始值是有意義的。不過，對於短連線的場景，擁塞視窗初始值的調整意義更大。但是注意，擁塞視窗的初始值值並不是越大越好。如果網路狀態不太好的情況下，擁塞視窗的初始值設定的過大，可能會導致網路一直處於擁塞狀態，適得其反。另一方面，網路中實際傳輸的未經確認的資料大小等於min(接收視窗的大小,擁塞視窗的大小），所以一旦接收方的接收視窗比較小的話，調整擁塞視窗的值也沒什麼作用。
通過tcpdump抓取通訊資料報。首先通過連線建立階段的耗時確認rtt的值，然後計算第乙個資料到達的時間加上乙個rtt時間後，在這個時間段內收到的資料報的個數即為擁塞視窗的初始值。
tcp網路引數調優思路
1.設定向外連線可用埠範圍 2.設定time wait連線重用 3.設定快速 time wait連線 4.設定time wait的最大連線長度 5.啟用以一種比超時重發更精確的方法來啟用rtt的計算 rtt round trip time 乙個連線的往返時間，即資料傳送時刻到接收到確認的時刻的差值 ...
linux之核心引數調優
調優1 調優2調優3 調優4net.ipv4.tcp syncookies 1 net.ipv4.tcp tw reuse 1 net.ipv4.tcp tw recycle 1 net.ipv4.tcp fin timeout 30 net.ipv4.tcp keepalive time 1200...
TCP連線狀態以及核心調優
狀態 描述closed 無連線是活動的或正在進行 listen 伺服器在等待進入呼叫 syn recv 乙個連線請求已經到達，等待確認 syn sent 應用已經開始，開啟乙個連線 established 正常資料傳輸狀態 fin wait1 應用說它已經完成 fin wait2 另一邊已同意釋放 ...