本文主要探究
tcp連接建立和釋放過(guò)程中的狀態(tài)演變
TCP連接的建立
其實(shí)這張圖已經(jīng)說(shuō)得很清楚了，客戶(hù)端應(yīng)用程序調(diào)用connect導(dǎo)致TCP發(fā)送一個(gè)SYN報(bào)文段，服務(wù)器端有一個(gè)監(jiān)聽(tīng)套接字，該監(jiān)聽(tīng)套接字收到SYN后，在待連接套接字隊(duì)列中插入一項(xiàng)，然后發(fā)送SYN和對(duì)客戶(hù)端確認(rèn)的ACK(注意到ACK序列號(hào)總是和目前等待接收的序列號(hào)相同，此圖中客戶(hù)端發(fā)送的數(shù)據(jù)僅僅只有SYN 1個(gè)字節(jié)，所以在SYN的序列號(hào)J的基礎(chǔ)上加1得到ACK的序列號(hào)，如果是其他數(shù)據(jù)報(bào)文段，那么報(bào)文段實(shí)際長(zhǎng)度為多少，確認(rèn)序列號(hào)就在該報(bào)文段的序列號(hào)基礎(chǔ)上加多少)?？蛻?hù)端接收到該SYN和ACK以后,connect調(diào)用就成功返回，同時(shí)向服務(wù)端發(fā)送ACK。服務(wù)端接收到客戶(hù)端發(fā)送的ACK之后，就將該連接從待連接套接字隊(duì)列移到已連接套接字隊(duì)列，等待accept調(diào)用從已連接套接字隊(duì)列中取出。注意到accept總是對(duì)已連接套接字隊(duì)列執(zhí)行pop操作，因此accept得到的總是三路握手已完成，連接已建立的套接字，可以說(shuō)即使不調(diào)用accept，這個(gè)已連接的套接字也已經(jīng)存在于系統(tǒng)中。那么如果客戶(hù)端在三路握手完成之后，accept調(diào)用之前crash掉怎么辦，有些系統(tǒng)對(duì)accept之前crash掉的連接在內(nèi)核層面已經(jīng)解決，所以accept不會(huì)看到這種狀態(tài)的出現(xiàn)，另一些對(duì)已經(jīng)crash掉的連接調(diào)用accept則返回ECONNABORT錯(cuò)誤，因此，最保險(xiǎn)的做法是檢查ECONNABORT錯(cuò)誤，如果檢查到該錯(cuò)誤，直接進(jìn)行下一次accept就行。
TCP連接的釋放
從這個(gè)圖可以看到客戶(hù)端調(diào)用close，導(dǎo)致內(nèi)核發(fā)送FIN主動(dòng)發(fā)起結(jié)束連接的第一次揮手，同時(shí)進(jìn)入FIN_WAIT1狀態(tài)，服務(wù)器端接收到這個(gè)FIN之后發(fā)送ACK同時(shí)進(jìn)入到CLOSE_WAIT狀態(tài)，客戶(hù)端接收到服務(wù)器對(duì)自己發(fā)送的FIN確認(rèn)之后進(jìn)入FIN_WAIT2狀態(tài)，直到服務(wù)器程序也調(diào)用close導(dǎo)致TCP發(fā)送FIN，服務(wù)器進(jìn)入LAST_ACK狀態(tài)，客戶(hù)端接收到這個(gè)FIN之后，發(fā)送對(duì)服務(wù)器端ACK的確認(rèn)，同時(shí)進(jìn)入TIME_WAIT狀態(tài)。注意到由于TCP的延遲確認(rèn)機(jī)制，如果服務(wù)器接收到客戶(hù)端的FIN后，及時(shí)調(diào)用close，會(huì)使得對(duì)客戶(hù)端的確認(rèn)ACK和服務(wù)器自己的FIN同時(shí)發(fā)送，四次揮手變?yōu)槿巍?/p>
首先看這個(gè)TIME_WAIT狀態(tài)的必要性，第一，假定客戶(hù)端發(fā)送給服務(wù)器的最后一個(gè)ACK丟包（這是完全有可能的），此時(shí)服務(wù)器會(huì)不斷重傳最后一個(gè)FIN，而客戶(hù)端已經(jīng)沒(méi)有關(guān)于這個(gè)連接的任何信息，因此
會(huì)導(dǎo)致服務(wù)器處于錯(cuò)誤狀態(tài)。第二，如果客戶(hù)端另一個(gè)進(jìn)程馬上占用掉剛剛關(guān)閉的套接字端口號(hào)，此時(shí)服務(wù)器在上一個(gè)連接中發(fā)送的數(shù)據(jù)由于網(wǎng)絡(luò)擁塞發(fā)生延時(shí)，剛好到達(dá)該端口，被新的連接讀取，就會(huì)出現(xiàn)串話(huà)現(xiàn)象。因此，這個(gè)TIME_WAIT狀態(tài)一般持續(xù)2MSL時(shí)長(zhǎng)，以保證上一個(gè)連接的所有報(bào)文都已發(fā)送完畢。和連接
操作永遠(yuǎn)是由客戶(hù)端來(lái)主動(dòng)發(fā)起的不同，主動(dòng)關(guān)閉操作也可以由服務(wù)器來(lái)進(jìn)行(例如WEB服務(wù)器)，因此當(dāng)服務(wù)器應(yīng)當(dāng)避免TIME_WAIT的出現(xiàn)，或者縮短TIME_WAIT的時(shí)延，因?yàn)槊恳粋€(gè)TIME_WAIT都是沒(méi)有釋放資源的連接，此狀態(tài)過(guò)多會(huì)導(dǎo)致服務(wù)器資源消耗嚴(yán)重，而且由于服務(wù)器必要時(shí)需要極短時(shí)間內(nèi)重啟，TIME_WAIT也會(huì)使得服務(wù)器由于端口仍被占用導(dǎo)致短時(shí)間內(nèi)重啟失敗。
TCP連接中的一些臨界情況
(1) A,B兩個(gè)主機(jī)上的進(jìn)程a,b已經(jīng)通過(guò)TCP建立連接c，然后主機(jī)A,B之間的網(wǎng)絡(luò)硬件連接出現(xiàn)故障，此時(shí)a進(jìn)程會(huì)處于何種狀態(tài)？
如果網(wǎng)絡(luò)發(fā)生故障期間a進(jìn)程永遠(yuǎn)不通過(guò)c連接對(duì)b進(jìn)程發(fā)送數(shù)據(jù)，那么a進(jìn)程就永遠(yuǎn)不會(huì)知道這件事的發(fā)生，A主機(jī)上為a,b兩個(gè)進(jìn)程建立的連接將會(huì)永遠(yuǎn)存在，這就好像a,b兩個(gè)人只能通過(guò)有線(xiàn)電話(huà)聯(lián)系，突然有一天連接到b的電話(huà)線(xiàn)斷了，那么只要a不給b打電話(huà)，他就永遠(yuǎn)不知道b的電話(huà)線(xiàn)斷了。這里有一個(gè)服務(wù)器編程中需要注意的問(wèn)題是，如果服務(wù)器程序一直只是監(jiān)聽(tīng)客戶(hù)端的請(qǐng)求并作出回復(fù)，那么如果客戶(hù)端在連接建立之后出現(xiàn)這種網(wǎng)絡(luò)硬件故障導(dǎo)致連接實(shí)際不可用的情況，服務(wù)器將永遠(yuǎn)不會(huì)覺(jué)察到這種狀態(tài)，實(shí)際不可用的連接c將會(huì)永遠(yuǎn)存在，其所占有的資源也就永遠(yuǎn)不會(huì)釋放。那么如果故障期間a進(jìn)程通過(guò)c給b進(jìn)程發(fā)送數(shù)據(jù)呢？這時(shí)候TCP發(fā)送該數(shù)據(jù)，由于收不到b的確認(rèn)，因此不斷重傳直到超時(shí)，(或者收到某個(gè)中間路由器回復(fù)的目的不可達(dá)），此時(shí)TCP就知道b已經(jīng)掛了或者到b之間的網(wǎng)絡(luò)硬件出現(xiàn)故障了，就可以通知應(yīng)用程序處理這個(gè)事件。這也是TCP中KEEPALIVE存在的意義（如果一個(gè)連接上較長(zhǎng)時(shí)間沒(méi)有接受和發(fā)送數(shù)據(jù)，設(shè)置了KEEPALIVE選項(xiàng)的TCP會(huì)發(fā)送?；顖?bào)文段，收到確認(rèn)就當(dāng)什么事兒也沒(méi)有，如果超時(shí)或者收到destination unreachable，就通知應(yīng)用程序處理該事件。那么如果拔掉網(wǎng)線(xiàn)后馬上連接，而且保證此時(shí)a，b兩個(gè)進(jìn)程沒(méi)有互相發(fā)送數(shù)據(jù)，會(huì)發(fā)生什么？答案是一切正常，就好像a,b兩個(gè)人在電話(huà)線(xiàn)路斷掉的時(shí)候互相之間沒(méi)有打過(guò)電話(huà)，等到他們打電話(huà)時(shí)，電話(huà)線(xiàn)路已經(jīng)被電信部門(mén)修好了，那么a，b就永遠(yuǎn)不知道電話(huà)線(xiàn)斷掉的這個(gè)事情。
(2) A,B兩個(gè)主機(jī)上的進(jìn)程a,b已經(jīng)通過(guò)TCP建立連接c，b進(jìn)程一直在忙別的事情（比如阻塞在別的IO上面)，在此期間a進(jìn)程調(diào)用了close，會(huì)發(fā)生什么？
如果b進(jìn)程在忙完別的事情后馬上讀取c連接上的數(shù)據(jù)，那么讀到FIN并調(diào)用close正常關(guān)閉連接。如果b進(jìn)程還要往c連接上寫(xiě)數(shù)據(jù)會(huì)發(fā)送什么？第一次寫(xiě)數(shù)據(jù)是可以正常進(jìn)行的，因?yàn)?code>TCP是雙向連接，因此b接收到a的FIN會(huì)認(rèn)為a不會(huì)再發(fā)送數(shù)據(jù)，但并不以為著不能向a寫(xiě)數(shù)據(jù)，a進(jìn)程接收到b發(fā)送來(lái)的（非期望的）數(shù)據(jù)后，會(huì)給b進(jìn)程發(fā)送一個(gè)RST，只要b進(jìn)程的下一次寫(xiě)操作發(fā)生在接收到a的RST之前，寫(xiě)操作一直會(huì)正常進(jìn)行。直到接收到a的RST之后，在對(duì)a進(jìn)行寫(xiě)操作，會(huì)返回返回EPIPE錯(cuò)誤，同時(shí)出發(fā)SIG_PIPE信號(hào)（默認(rèn)終止進(jìn)程），因此服務(wù)器程序一般要忽略SIG_PIPE信號(hào)，并對(duì)EPIPE錯(cuò)誤進(jìn)行處理。
(3) A,B兩個(gè)主機(jī)上的進(jìn)程a,b已經(jīng)通過(guò)TCP建立連接c,此時(shí)B主機(jī)突然斷電宕機(jī)，然后馬上重啟（假定b程序是開(kāi)機(jī)自動(dòng)啟動(dòng)的服務(wù)器程序），此時(shí)a進(jìn)程往b進(jìn)程寫(xiě)數(shù)據(jù)會(huì)發(fā)生什么？
由于B的宕機(jī)，b進(jìn)程不會(huì)再crash時(shí)給a發(fā)送FIN，所以a進(jìn)程在給b進(jìn)程寫(xiě)數(shù)據(jù)之前是不會(huì)感知到這一現(xiàn)象，等到B主機(jī)接收到a進(jìn)程發(fā)來(lái)的數(shù)據(jù)時(shí)（這是可以的，因?yàn)锽主機(jī)已經(jīng)重啟），b進(jìn)程由于crash導(dǎo)致關(guān)于a，b之間的連接c的任何信息都已不存在，所以B主機(jī)找不到這樣一個(gè)連接，因此會(huì)讓a進(jìn)程重新連接，a進(jìn)程返回ECONNREST錯(cuò)誤。
