連接斷開(kāi)階段

• 四次揮手機(jī)制：TCP連接的斷開(kāi)需要四次揮手，這是因?yàn)殡p方都需要獨(dú)立地關(guān)閉數(shù)據(jù)傳輸。第二次和第三次揮手不能合并，因?yàn)樵诨貜?fù)第二次揮手的時(shí)候，可能還有數(shù)據(jù)沒(méi)有接收完成，所以需要先回復(fù)ACK報(bào)文，等待所有的數(shù)據(jù)接收完成之后再發(fā)送FIN報(bào)文。這樣可以確保數(shù)據(jù)的完整性。

• 延遲應(yīng)答：TCP為了提高傳輸效率，采用了延遲應(yīng)答的策略。如果沒(méi)有響應(yīng)數(shù)據(jù)要發(fā)送，TCP會(huì)延遲一段時(shí)間，等待是否有響應(yīng)數(shù)據(jù)可以一起發(fā)送。這樣可以減少網(wǎng)絡(luò)的負(fù)載。如果在等待發(fā)送ACK期間，對(duì)方的第二個(gè)數(shù)據(jù)報(bào)文又到達(dá)了，這時(shí)就會(huì)立刻發(fā)送ACK。這樣可以確保數(shù)據(jù)的及時(shí)性。如果開(kāi)啟了延遲應(yīng)答的TCP，并且沒(méi)有響應(yīng)數(shù)據(jù)要發(fā)送，那么就可能看到ACK和FIN報(bào)文合并的情況。這是因?yàn)門CP為了提高效率，盡可能地將多個(gè)報(bào)文合并發(fā)送。

• 報(bào)文丟失：如果某次揮手的報(bào)文丟失了，TCP會(huì)進(jìn)行超時(shí)重傳，達(dá)到最大次數(shù)之后就強(qiáng)制斷開(kāi)連接。這是因?yàn)門CP為了確保數(shù)據(jù)的可靠性，采用了超時(shí)重傳的策略。如果超過(guò)一定的時(shí)間還沒(méi)有收到對(duì)方的應(yīng)答，就會(huì)認(rèn)為報(bào)文丟失，然后進(jìn)行重傳。

• 主機(jī)宕機(jī)：如果客戶端/服務(wù)端建立連接后宕機(jī)/斷網(wǎng)，會(huì)有以下幾種情況：

  • 未宕機(jī)方傳輸數(shù)據(jù)：如果服務(wù)端向客戶端傳輸數(shù)據(jù)的過(guò)程中發(fā)現(xiàn)客戶端宕機(jī)并重啟，客戶端的TCP連接的數(shù)據(jù)結(jié)構(gòu)已經(jīng)丟失，那么會(huì)發(fā)送RST報(bào)文；如果客戶端仍在宕機(jī)，服務(wù)端會(huì)觸發(fā)超時(shí)重傳，次數(shù)達(dá)上限后斷開(kāi)。這是因?yàn)門CP為了確保數(shù)據(jù)的可靠性，采用了超時(shí)重傳的策略。
  • 宕機(jī)方傳輸數(shù)據(jù)：如果客戶端宕機(jī)之后重啟，希望與同一服務(wù)端連接，會(huì)發(fā)送SYN報(bào)文。如果客戶端SYN報(bào)文中端口號(hào)與歷史連接相同，服務(wù)端會(huì)認(rèn)為這個(gè)SYN是亂序的，所以回復(fù)歷史連接中的正確ACK（Challenge ACK），但是客戶端發(fā)現(xiàn)這個(gè)ACK不是自己希望收到的，就會(huì)發(fā)送RST，雙方斷開(kāi)連接。這是因?yàn)門CP為了防止亂序的報(bào)文影響到正常的連接，采用了Challenge ACK的策略。
  • 長(zhǎng)時(shí)間無(wú)數(shù)據(jù)傳輸：為了防止客戶端長(zhǎng)時(shí)間不發(fā)送報(bào)文占用服務(wù)端資源，服務(wù)端可以開(kāi)啟TCP保活機(jī)制，發(fā)送探測(cè)報(bào)文來(lái)探測(cè)客戶端還是否處于正常狀態(tài)，否則只有服務(wù)端重啟才能斷開(kāi)。這是因?yàn)門CP為了防止無(wú)效的連接占用資源，采用了?；顧C(jī)制。

• 進(jìn)程崩潰：如果進(jìn)程崩潰，操作系統(tǒng)會(huì)在回收資源的時(shí)候代為進(jìn)行揮手過(guò)程，這與主機(jī)宕機(jī)是不同的，因?yàn)門CP的連接信息是由內(nèi)核維護(hù)的。這是因?yàn)門CP為了防止進(jìn)程崩潰導(dǎo)致的資源泄露，采用了進(jìn)程崩潰后自動(dòng)斷開(kāi)連接的策略。

• TIME_WAIT狀態(tài)：

  TIME_WAIT狀態(tài)是TCP連接斷開(kāi)后的一個(gè)必要狀態(tài)。這個(gè)狀態(tài)的存在有兩個(gè)主要原因：
  • 防止舊報(bào)文干擾新連接：TIME_WAIT狀態(tài)可以防止“舊的重復(fù)報(bào)文”在新的連接中被錯(cuò)誤地接收。這是通過(guò)讓TCP連接在TIME_WAIT狀態(tài)持續(xù)2MSL的時(shí)間，使得網(wǎng)絡(luò)中可能存在的屬于“舊連接”的報(bào)文都消失，這樣新的連接就不會(huì)收到舊的報(bào)文了。
  • 保證正常關(guān)閉：TIME_WAIT狀態(tài)可以確保TCP連接可靠地關(guān)閉。這是通過(guò)在TIME_WAIT狀態(tài)期間等待2MSL（報(bào)文最大生存時(shí)間）來(lái)實(shí)現(xiàn)的，這樣可以保證對(duì)方收到了我們的FIN報(bào)文，如果對(duì)方?jīng)]有收到，我們可以在這個(gè)時(shí)間內(nèi)重發(fā)。

• 主動(dòng)斷開(kāi)連接：

  主動(dòng)斷開(kāi)連接會(huì)導(dǎo)致有很多處于TIME_WAIT狀態(tài)的TCP連接，這會(huì)占用系統(tǒng)資源，因此，應(yīng)該盡量讓客戶端承受TIME_WAIT。
  
  TCP連接可以在以下幾種情況下被主動(dòng)斷開(kāi)：
  • 長(zhǎng)連接數(shù)量達(dá)上限：如果長(zhǎng)連接的數(shù)量達(dá)到了系統(tǒng)的上限，系統(tǒng)可能會(huì)主動(dòng)斷開(kāi)一些連接以釋放資源。
  • 長(zhǎng)連接超時(shí)：如果客戶端長(zhǎng)時(shí)間無(wú)請(qǐng)求，長(zhǎng)連接可能會(huì)超時(shí)，此時(shí)服務(wù)端可能會(huì)主動(dòng)斷開(kāi)連接。
  • 沒(méi)有使用長(zhǎng)連接：如果沒(méi)有使用長(zhǎng)連接（Keep-Alive），短鏈接一般由服務(wù)端主動(dòng)關(guān)閉

• 快速?gòu)?fù)用：文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-849428.html

  當(dāng)TIME_WAIT狀態(tài)過(guò)長(zhǎng)會(huì)導(dǎo)致占用系統(tǒng)資源過(guò)多時(shí)，可以選擇快速?gòu)?fù)用，但這相當(dāng)于放棄了TIME_WAIT的作用，所以最好在保證安全的情況下復(fù)用。
  • tcp_tw_reuse選項(xiàng)：tcp_tw_reuse選項(xiàng)可以快速?gòu)?fù)用處于TIME_WAIT的連接，但需要配合時(shí)間戳一同開(kāi)啟。雖然有了時(shí)間戳控制可以避免歷史報(bào)文，但是歷史RST報(bào)文只要在接收窗口內(nèi)就不會(huì)丟棄，而且也無(wú)法保證被動(dòng)關(guān)閉方正常關(guān)閉。
  • tcp_tw_recycle選項(xiàng)：tcp_tw_recycle選項(xiàng)也可以快速?gòu)?fù)用，但是在使用了NAT網(wǎng)絡(luò)的情況下是不安全的，因?yàn)閠cp_tw_recycle和時(shí)間戳是針對(duì)IP地址做PAWS檢查的，使用NAT會(huì)導(dǎo)致內(nèi)網(wǎng)下的兩個(gè)主機(jī)會(huì)映射到同一個(gè)IP，此時(shí)兩端傳輸數(shù)據(jù)包，一端的時(shí)間戳?xí)攘硪欢诵?，在服?wù)器看來(lái)，會(huì)認(rèn)為小的那一端是非法報(bào)文，從而丟棄。
  • tcp_max_tw_buckets選項(xiàng)：tcp_max_tw_buckets選項(xiàng)可以設(shè)定當(dāng)前主機(jī)最多存在的TIME_WAIT狀態(tài)的TCP連接的數(shù)量，當(dāng)超過(guò)這個(gè)上限就可以直接關(guān)閉。

到了這里，關(guān)于計(jì)算機(jī)網(wǎng)絡(luò)-TCP斷開(kāi)連接階段錯(cuò)誤應(yīng)對(duì)機(jī)制的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！