計算機網路面經之TCP協議(一)

1、為什么要三次握手

【 一句話，主要防止已經失效的連接請求報文突然又傳送到了服務器，從而產生錯誤， 】

不能是兩次：客戶端發送了第一個請求連接并且沒有丟失，只是因為在網路結點中滯留的時間太長了，由于TCP的客戶端遲遲沒有收到確認報文，以為服務器沒有收到（滯留），此時重新向服務器發送這條報文，此后客戶端和服務器經過兩次握手完成連接，傳輸資料，然后關閉連接（正常傳輸），此時此前滯留的那一次請求連接，網路通暢了到達了服務器，服務器接著回傳第一次請求的回應，這個報文本該是失效的，但是，兩次握手的機制將會讓客戶端和服務器再次建立連接，這將導致不必要的錯誤和資源的浪費，

如果采用的是三次握手，就算是那一次失效的報文傳送過來了，服務端接受到了那條失效報文并且回復了確認報文，但是客戶端不會再次發出確認，由于服務器收不到確認，就知道客戶端并沒有請求連接，

不能是四次： 如果是四次握手，即第三次只是傳輸的回應報文段，第四次才傳輸資料，本來第三次握手就能傳輸資料了，這屬于畫蛇添足，也浪費了資源， （可以但沒必要）

2、為什么要四次揮手

【斷開連接時，服務器端可能還在發資料，因此不能將回應的ACK和斷開連接的請求一起發送】

? 因為當Server端收到Client端的SYN連接請求報文后，可以直接發送SYN+ACK報文，其中ACK報文是用來應答的，SYN報文是用來同步的，但是關閉連接時，當Server端收到FIN報文時，很可能并不會立即關閉SOCKET，所以只能先回復一個ACK報文，告訴Client端，“你發的FIN報文我收到了”，只有等到我Server端所有的報文都發送完了，我才能發送FIN報文，因此不能一起發送，故需要四步揮手，

? 服務端收到客戶端的 FIN 標志，知道客戶端想要斷開這次連接了，但是，我服務端，我還想發資料呢？我等到發送完了所有的資料后，會發送一個 FIN 段來關閉此方向上的連接，接收方發送 ACK確認關閉連接，

3、為什么揮手要等待2MSL

【為了保證客戶端發送的最后一個報文能成功到達服務器，客戶端能夠在2MSL中接收到這個服務端重傳的報文（最后一次握手，客戶端發送完最后一個報文后，如果2MSL內沒有服務端沒有收到，就會觸發超時重傳，在2MSL內就一定能收到這個重傳請求）】

? 為了保證客戶端發送的最后一個ACK報文段能夠到達服務器，這個ACK報文段可能丟失（客戶端發的，第四次握手），因而使在Last-ACK狀態的服務器收不到客戶端已發送的FIN+ACK報文段的確認，服務器就會超時重傳這個報文段，而客戶端就能在2MSL時間內收到這個重傳的FIN-ACK報文段，接著客戶端重傳一個確認，重新啟動2MSL計時器，最后客戶端和服務器端都能正常進入到CLOSED狀態，

? 如果服務器端在TIME-WAIT狀態下不等待一段時間，而是在發送完ACK報文段就立即釋放連接，那么客戶端就無法收到服務器重傳的FIN_ACK報文段，因而也就不會再發送一個報文段，這樣服務器就無法進入CLOSED狀態，

4、大量TIME_WAIT產生的原因和解決辦法

產生原因：對于一些Web服務器，斷開連接的是Server端，這樣Server端就會進入TIME_WAIT狀態，當在高并發的Web服務器中存在大量的連接，當斷開時會產生大量的TIME_WAIT，

危害：在socket的TIME_WAIT結束之前，該socket會一直占用本地埠，在高并發和短連接的互動系統中，大量的TIME_WAIT會把可用的埠都占用且系統未能及時回收，就會 出現無法向服務端創建新的socket連接的情況 ，

解決方法：將socket進行復用，允許TIME_WAIT的socket重新用于TCP的連接，將短鏈接設定為長鏈接

【一句話：高并發的服務器中有大量連接，而且主動斷開連接的一方是服務器，因此在斷開時會出現大量TIME_WAIT】

5、TCP怎么保證可靠傳輸

可靠是指：不重復、不丟失、不失序

• 確認和重傳：接收方收到報文就會確認，發送方發送一段時間后沒有收到確認就會重傳，

• 資料校驗：TCP報文頭有校驗和，用于校驗報文是否損壞，

• 資料合理分片和排序：tcp會按最大傳輸單元(MTU)合理分片，接收方會快取未按序到達的資料，重新排序后交給應用層，而UDP：IP資料報大于1500位元組，大于MTU，這個時候發送方的IP層就需要分片，把資料報分成若干片，是的每一片都小于MTU，而接收方IP層則需要進行資料報的重組，由于UDP的特性，某一片資料丟失時，接收方便無法重組資料報，導致丟棄整個UDP資料報，

• 流量控制：當接收方來不及處理發送方的資料，能通過滑動視窗，提示發送方降低發送的速率，防止包丟失，

• 擁塞控制：當網路擁塞時，通過擁塞視窗，減少資料的發送，防止包丟失，

  【一句話：確認重傳、合理分片、資料校驗、流量控制、擁塞控制】

6、TCP流量控制

流量控制是為了控制發送方發送速率，保證接收方來得及接收，TCP 中采用滑動視窗來進行傳輸控制，滑動視窗的大小意味著接收方還有多大的緩沖區可以用于接收資料，發送方可以通過滑動視窗的大小來確定應該發送多少位元組的資料，當滑動視窗為 0 時，發送方一般不能再發送資料報，

【一句話：控制發送方發送速率，保證接收方能接受】

7、TCP滑動視窗

視窗是快取的一部分，用來暫時存放位元組流，發送方和接收方各有一個視窗，接收方通過 TCP 報文段中的視窗欄位告訴發送方自己的視窗大小，發送方根據這個值和其它資訊設定自己的視窗大小， （接收方控制發送方視窗）

發送視窗內的位元組都允許被發送，接收視窗內的位元組都允許被接收， 接收視窗只會對視窗內最后一個按序到達的位元組進行確認，例如接收視窗已經收到的位元組為{31, 34, 35}，其中{31}按序到達，而 {34, 35} 就不是，因此只對位元組 31 進行確認，發送方得到一個位元組的確認之后，就知道這個位元組之前的所有位元組都已經被接收，

8、TCP擁塞控制

如果網路出現擁塞，分組將會丟失，此時發送方會繼續重傳，從而導致網路擁塞程度更高，因此當出現擁塞時，應當控制發送方的速率，這一點和流量控制很像，但是出發點不同，流量控制是為了讓接收方能來得及接收，而擁塞控制是為了降低整個網路的擁塞程度， TCP 主要通過四個演算法來進行擁塞控制：慢開始、擁塞避免、快重傳、快恢復，

發送方需要維護一個叫做擁塞視窗（cwnd）的狀態變數，注意擁塞視窗與發送方視窗的區別：擁塞視窗只是一個狀態變數，實際決定發送方能發送多少資料的是發送方視窗，

【流量控制：控制接收方；擁塞控制：控制整個網路】

(1)慢開始與擁塞避免

慢開始：發送的最初執行慢開始，令 cwnd = 1，發送方只能發送 1 個報文段；當收到確認后，將 cwnd 加倍，因此之后發送方能夠發送的報文段數量為：2、4、8 …（擁塞視窗每次都2倍增長）注意到慢開始每個輪次都將 cwnd 加倍，這樣會讓 cwnd 增長速度非常快，從而使得發送方發送的速度增長速度過快，網路擁塞的可能性也就更高，

擁塞避免：設定一個慢開始門限 ssthresh，當 cwnd >= ssthresh 時，進入擁塞避免，每個輪次只將 cwnd 加 1，如果出現了超時，則令 ssthresh = cwnd / 2，然后重新執行慢開始，

(2)快重傳與快恢復

快重傳： 就是使發送方盡快進行重傳,而不是等超時重傳計時器超時再重傳，在發送方，如果收到三個重復確認，那么可以知道下一個報文段丟失，此時執行快重傳，立即重傳下一個報文段，例如收到三個 M2，則 M3 丟失，立即重傳 M3，

快恢復： 在這種情況下，只是丟失個別報文段，而不是網路擁塞，因此執行快恢復，令 ssthresh = cwnd / 2 ，cwnd = ssthresh，注意到此時直接進入擁塞避免，

注意：（1）慢開始和快恢復的快慢指的是 cwnd 的設定值，而不是 cwnd 的增長速率，慢開始 cwnd 設定為 1，而快恢復 cwnd 設定為 ssthresh， (2)快重傳指的是發送方的動作（重傳報文），而不是對擁塞視窗的改變；而快恢復指的是對擁塞視窗的變化，