TCP、UDP協議

1.TCP和UDP

爲什麼TCP連接的時候是3次？2次不可以嗎？
- 因爲需要考慮連接時丟包的問題，如果只握手2次，第二次握手時如果服務端發給客戶端的確認報文段丟失，此時服務端已經準備好了收發數(可以理解服務端已經連接成功)據，而客戶端一直沒收到服務端的確認報文，所以客戶端就不知道服務端是否已經準備好了(可以理解爲客戶端未連接成功)，這種情況下客戶端不會給服務端發數據，也會忽略服務端發過來的數據。
如果已經建立了連接，但是客戶端突然出現故障了怎麼辦？
- TCP設有一個保活計時器，客戶端如果出現故障，服務器不能一直等下去，白白浪費資源。服務器每收到一次客戶端的請求後都會重新復位這個計時器，時間通常是設置爲2小時，若兩小時還沒有收到客戶端的任何數據，服務器就會發送一個探測報文段，以後每隔75秒鐘發送一次。若一連發送10個探測報文仍然沒反應，服務器就認爲客戶端出了故障，接着就關閉連接。

爲什麼TCP連接的時候是3次，關閉的時候卻是4次？
- 因爲只有在客戶端和服務端都沒有數據要發送的時候才能斷開TCP。而客戶端發出FIN報文時只能保證客戶端沒有數據發了，服務端還有沒有數據發客戶端是不知道的。而服務端收到客戶端的FIN報文後只能先回復客戶端一個確認報文來告訴客戶端我服務端已經收到你的FIN報文了，但我服務端還有一些數據沒發完，等這些數據發完了服務端才能給客戶端發FIN報文(所以不能一次性將確認報文和FIN報文發給客戶端，就是這裏多出來了一次)。
爲什麼客戶端發出第四次揮手的確認報文後要等2MSL的時間才能釋放TCP連接？
- 這裏同樣是要考慮丟包的問題，如果第四次揮手的報文丟失，服務端沒收到確認ack報文就會重發第三次揮手的報文，這樣報文一去一回最長時間就是2MSL，所以需要等這麼長時間來確認服務端確實已經收到了。

發送方維持一個擁塞窗口cwnd的狀態變量。擁塞窗口的大小取決於網絡的擁塞程度，並且動態地在變化。
發送方控制擁塞窗口的原則是：只要網絡沒有出現擁塞，擁塞窗口就再增大一些，以便把更多的分組發送出去。但只要網絡出現擁塞，擁塞窗口就減少一些，以減少注入到網絡中的分組數。
當連接開始，以指數增加速率，直到第一個丟失事件發生，cwnd=1。
慢啓動門限ssthresh。
當cwnd < ssthresh時，使用慢啓動算法；
當cwnd > ssthresh時，停止使用慢啓動算法而改用擁塞避免算法；
當cwnd = ssthresh時，即可使用慢啓動算法，也可以使用擁塞避免算法；
發生丟失事件時，ssthresh設置爲發生丟失以前的cwnd的一半，並且cwnd設爲1。
快重傳算法規定，發送方只要一連收到**三個重複確認（即四個確認）**就應當立即重傳對方尚未收到的報文段，而不必繼續等待設置的重傳計時器時間到期。
快恢復：考慮到如果網絡出現擁塞的話就不會收到好幾個重複的確認，所以發送方現在認爲網絡可能沒有出現擁塞。所以此時不執行慢開始算法，而是將cwnd設置爲ssthresh減半後的值，然後執行擁塞避免算法，使cwnd緩慢增大。

考慮一種特殊的情況，就是接收方若沒有緩存足夠使用，就會發送零窗口大小的報文，此時發送放將發送窗口設置爲0，停止發送數據。之後接收方有足夠的緩存，發送了非零窗口大小的報文，但是這個報文在中途丟失的話，那麼發送方的發送窗口就一直爲零導致死鎖。
解決這個問題，TCP爲每一個連接設置一個持續計時器（persistence timer）。只要TCP的一方收到對方的零窗口通知，就啓動該計時器，週期性的發送一個零窗口探測報文段。對方就在確認這個報文的時候給出現在的窗口大小（注意：TCP規定，即使設置爲零窗口，也必須接收以下幾種報文段：零窗口探測報文段、確認報文段和攜帶緊急數據的報文段）。

法（反碼和，求和時溢出都被回捲）。接收方覈對全部字段之和是否爲全1。

------本篇完------