【正文】 關(guān)閉連接：當(dāng)應(yīng)答結(jié)束后，web瀏覽器與web服務(wù)器必須斷開，以保證其它web瀏覽器能夠與web服務(wù)器建立連接。應(yīng)答：web服務(wù)器收到這個(gè)請求，進(jìn)行處理。如果url不包含端口號(hào)，則會(huì)使用該協(xié)議的默認(rèn)端口號(hào)，HTTP協(xié)議的默認(rèn)端口號(hào)為80。TCP和UDP都是傳輸層的協(xié)議！應(yīng)用層 （）物理連接層各自協(xié)議使用的常用端口：如, , tcp, udp, ftp等等TCP:FTP:21, Telnet:23, SMTP:25UDP:DNS:53, TFTP:69, SNMP:161, RIP:520::80請求的詳細(xì)過程HTTP是一個(gè)應(yīng)用層的協(xié)議，在這個(gè)層的協(xié)議，是一種網(wǎng)絡(luò)交互需要遵守的一種協(xié)議規(guī)范。一般來說不會(huì)發(fā)生什么問題，但是還是有特殊情況出現(xiàn)：假設(shè)新連接和已經(jīng)關(guān)閉的老連接端口號(hào)是一樣的，如果前一次連接的某些數(shù)據(jù)仍然滯留在網(wǎng)絡(luò)中，這些延遲數(shù)據(jù)在建立新連接之后才到達(dá)Server，由于新連接和老連接的端口號(hào)是一樣的，又因?yàn)門CP協(xié)議判斷不同連接的依據(jù)是socket pair，于是，TCP協(xié)議就認(rèn)為那個(gè)延遲的數(shù)據(jù)是屬于新連接的，這樣就和真正的新連接的數(shù)據(jù)包發(fā)生混淆了。再說第二點(diǎn)，如果Client直接CLOSED，然后又再向Server發(fā)起一個(gè)新連接，我們不能保證這個(gè)新連接與剛關(guān)閉的連接的端口號(hào)是不同的。這樣的情況雖然不會(huì)造成數(shù)據(jù)丟失，但是卻導(dǎo)致TCP協(xié)議不符合可靠連接的要求。為什么要這樣做而不是直接進(jìn)入CLOSED狀態(tài)？原因有二：一、保證TCP協(xié)議的全雙工連接能夠可靠關(guān)閉二、保證這次連接的重復(fù)數(shù)據(jù)段從網(wǎng)絡(luò)中消失先說第一點(diǎn)，如果Client直接CLOSED了，那么由于IP協(xié)議的不可靠性或者是其它網(wǎng)絡(luò)原因，導(dǎo)致Server沒有收到Client最后回復(fù)的ACK。以上就是TCP協(xié)議關(guān)閉連接的過程，現(xiàn)在說一下TIME_WAIT狀態(tài)。Server接收到Client對自己的FIN的確認(rèn)ACK，關(guān)閉寫通道，TCP連接轉(zhuǎn)化為CLOSED，也就是關(guān)閉連接。Client收到對自己的FIN確認(rèn)后，關(guān)閉 寫通道，不再向連接中寫入任何數(shù)據(jù)。描述過程：Client調(diào)用close()函數(shù)，給Server發(fā)送FIN，請求關(guān)閉連接；Server收到FIN之后給Client返回確認(rèn)ACK，同時(shí)關(guān)閉讀通道（不清楚就去看一下shutdown和close的差別），也就是說現(xiàn)在不能再從這個(gè)連接上讀取東西，現(xiàn)在read返回0。上圖描述的是Client主動(dòng)關(guān)閉的過程，F(xiàn)TP協(xié)議中就這樣的。允許將TIMEWAIT sockets重新用于新的TCP連接，默認(rèn)為0，表示關(guān)閉； = 1表示開啟TCP連接中TIMEWAIT sockets的快速回收，默認(rèn)為0，表示關(guān)閉。和TIME_WAIT狀態(tài)有關(guān)的系統(tǒng)參數(shù)有一般由3個(gè)，本廠設(shè)置如下： = 1 = 1 = 30為什么需要TIME_WAIT？TIME_WAIT是TCP協(xié)議用以保證被重新分配的socket不會(huì)受到之前殘留的延遲重發(fā)報(bào)文影響的機(jī)制,是必要的邏輯保證。TIME_WAIT狀態(tài)下的socket不能被回收使用. 具體現(xiàn)象是對于一個(gè)處理大量短連接的服務(wù)器,如果是由服務(wù)器主動(dòng)關(guān)閉客戶端的連接，將導(dǎo)致服務(wù)器端存在大量的處于TIME_WAIT狀態(tài)的socket， 甚至比處于Established狀態(tài)下的socket多的多,嚴(yán)重影響服務(wù)器的處理能力，甚至耗盡可用的socket，停止服務(wù)。TIME_WAIT根據(jù)TCP協(xié)議定義的3次握手?jǐn)嚅_連接規(guī)定,發(fā)起socket主動(dòng)關(guān)閉的一方 socket將進(jìn)入TIME_WAIT狀態(tài)。被動(dòng)關(guān)閉的server收到FIN后，但未發(fā)出ACK的TCP狀態(tài)是CLOSE_WAIT。觀測服務(wù)上SYN_RECV連接個(gè)數(shù)為：7314，對于一個(gè)高并發(fā)連接的通訊服務(wù)器，這個(gè)數(shù)字比較正常。如果合法，再分配專門的數(shù)據(jù)區(qū)進(jìn)行處理未來的TCP連接。它的原理是，在TCP服務(wù)器收到TCP SYN包并返回TCP SYN+ACK包時(shí)，不分配一個(gè)專門的數(shù)據(jù)區(qū)，而是根據(jù)這個(gè)SYN包計(jì)算出一個(gè)cookie值。SYN Cookie原理由D. J. Bernstain和 Eric Schenk發(fā)明。這些處在SYNC_RECV的TCP連接稱為半連接，并存儲(chǔ)在內(nèi)核的半連接隊(duì)列中，在內(nèi)核收到對端發(fā)送的ack包時(shí)會(huì)查找半連接隊(duì)列，并將符合的requst_sock信息存儲(chǔ)到完成三次握手的連接的隊(duì)列中，然后刪除此半連接。假設(shè)一個(gè)用戶向服務(wù)器發(fā)送了SYN報(bào)文后突然死機(jī)或掉線，那么服務(wù)器在發(fā)出SYN+ACK應(yīng)答報(bào)文后是無法收到客戶端的ACK報(bào)文的（第三次握手無法完成），這種情況下服務(wù)器端一般會(huì)重試（再次發(fā)送SYN+ACK給客戶端）并等待一段時(shí)間后丟棄這個(gè)未完成的連接，這段時(shí)間的長度我們稱為SYN Timeout，一般來說這個(gè)時(shí)間是分鐘的數(shù)量級(jí)（大約為30秒2分鐘）。通常我們不對這個(gè)值進(jìn)行修改，因?yàn)槲覀兿Ｍ鸗CP連接不要因?yàn)榕紶柕膩G包而無法建立。這里決定內(nèi)核在放棄連接之前所送出的 SYN+ACK 數(shù)目。1， ：INTEGER默認(rèn)值是5對于遠(yuǎn)端的連接請求SYN，內(nèi)核會(huì)發(fā)送SYN ＋ ACK數(shù)據(jù)報(bào)，以確認(rèn)收到上一個(gè) SYN連接請求包。服務(wù)端收到建立連接的SYN沒有收到ACK包的時(shí)候處在SYN_RECV狀態(tài)。TCP狀態(tài)TCP狀態(tài)如下圖所示：可能有點(diǎn)眼花繚亂？再看看這個(gè)時(shí)序圖除了ESTABLISHED，可以看到連接數(shù)比較多的幾個(gè)狀態(tài)是：FIN_WAIT1, TIME_WAIT, CLOSE_WAIT, SYN_RECV和LAST_ACK；下面的文章就這幾個(gè)狀態(tài)的產(chǎn)生條件、對系統(tǒng)的影響以及處理方式進(jìn)行簡單描述。S[a]}39。printinEND/^tcp/awkn不是我扣細(xì)節(jié)，而是在通訊為主的前端服務(wù)器上，必須有能力處理各種TCP狀態(tài)。問TCP斷開連接需要幾次握手，70%的應(yīng)聘者能答對是4次通訊。那么相信CLOSE_WAIT狀態(tài)將很少看到TCP的TIME_WAIT和Close_Wait狀態(tài)通常服務(wù)器收到FIN消息，不管什么情況都會(huì)立馬發(fā)送ACK確認(rèn)的。原文說“被動(dòng)關(guān)閉的server收到FIN后，但未發(fā)出ACK的TCP狀態(tài)是CLOSE_WAIT”。感覺有幾個(gè)地方說的太誤導(dǎo)人。這才表現(xiàn)出了這個(gè)tcp的關(guān)閉時(shí)序跟你解釋的有出入。所以服務(wù)端收到客戶端請求之后，[已經(jīng)決定不再有后續(xù)通信]，所以寫完的回復(fù)之后立即關(guān)閉。而且對于樓主的那個(gè)請求的抓包實(shí)驗(yàn)，我想到的一點(diǎn)拙見:對于tcp的兩端而言，我關(guān)我的寫端，你關(guān)你的寫端。這樣才更好保證，已發(fā)的都能收到，不發(fā)的之后不再發(fā)。如果在服務(wù)器收到FIN(i)時(shí)，已經(jīng)沒有數(shù)據(jù)需要發(fā)送，可以在返回ACK(i+1)的時(shí)候就設(shè)置FIN(j)標(biāo)識(shí)，這樣就相當(dāng)于可以合并第二步和第三步。這是標(biāo)準(zhǔn)的TCP關(guān)閉兩個(gè)階段，服務(wù)器和客戶機(jī)都可以發(fā)起關(guān)閉，完全對稱。 (j)后，返回確認(rèn)段ACK，序列號(hào)為j+1，關(guān)閉客戶機(jī)讀通道；第二階段（此時(shí)，客戶機(jī)仍能通過讀通道讀取服務(wù)器的數(shù)據(jù)，服務(wù)器仍能通過寫通道寫數(shù)據(jù)） (i)后，返回確認(rèn)段ACK，序列號(hào)為i+1，關(guān)閉服務(wù)器讀通道；直到接收到對方發(fā)送的FIN，且對方收到了接收確認(rèn)ACK之后，雙方的數(shù)據(jù)通信完全結(jié)束，過程中每次接收都需要返回確認(rèn)數(shù)據(jù)段ACK。簡單說來是 “先關(guān)讀，后關(guān)寫”，一共需要四個(gè)階段。TCP協(xié)議的連接是全雙工連接，一個(gè)TCP連接存在雙向的讀寫通道。收到一個(gè) FIN只意味著這一方向上沒有數(shù)據(jù)流動(dòng)，一個(gè)TCP連接在收到一個(gè)FIN后仍能發(fā)送數(shù)據(jù)。由于TCP連接是全雙工的，因此每個(gè)方向都必須單獨(dú)進(jìn)行關(guān)閉。深入理解TCP連接的釋放：我估計(jì)是時(shí)間間隔太短造成。TCP四次揮手關(guān)閉連接圖2TCP采用四次揮手關(guān)閉連接如圖2所示。（4）客戶端A發(fā)回ACK報(bào)文確認(rèn)，并將確認(rèn)序號(hào)設(shè)置為收到序號(hào)加1。（3）服務(wù)器B關(guān)閉與客戶端A的連接，發(fā)送一個(gè)FIN給客戶端A。和SYN一樣，