TCP-IP協(xié)議與UDP-IP協(xié)議的區(qū)別參考

1、TCP-IP協(xié)議與UDP-IP協(xié)議的區(qū)別TCP-IP協(xié)議與UDP-IP協(xié)議的區(qū)別29/29TCP-IP協(xié)議與UDP-IP協(xié)議的區(qū)別 HYPERLINK /a199228/article/details/7020884 TCP/IP協(xié)議與UDP/IP協(xié)議的區(qū)別 TCP（Transmission Control Protocol，傳輸控制協(xié)議）是面向連接的協(xié)議， 也就是說，在收發(fā)數(shù)據(jù)前，必須和對(duì)方建立可靠的連接。一個(gè)TCP連接必須要經(jīng)過三次“對(duì)話”才能建立起來，其中的過程非常復(fù)雜，只簡單的描述下這三次對(duì)話的簡單過程：A B/主機(jī)A向主機(jī)B發(fā)出連接請(qǐng)求數(shù)據(jù)包：“我想給你發(fā)數(shù)據(jù)，可以嗎？”，這是第一次

2、對(duì)話；A B/主機(jī)A再發(fā)出一個(gè)數(shù)據(jù)包確認(rèn)主機(jī)B的要求同步：“我現(xiàn)在就發(fā)，你接著吧！”，這是第三次對(duì)話。三次“對(duì)話”的目的是使數(shù)據(jù)包的發(fā)送和接收同步，經(jīng)過三次“對(duì)話”之后，主機(jī)A才向主機(jī)B正式發(fā)送數(shù)據(jù)。詳細(xì)點(diǎn)說就是：TCP接通連接要進(jìn)行3次握手過程1 主機(jī)A通過向主機(jī)B 發(fā)送一個(gè)含有同步序列號(hào)的標(biāo)志位的數(shù)據(jù)段給主機(jī)B ,向主機(jī)B 請(qǐng)求建立連接,通過這個(gè)數(shù)據(jù)段,主機(jī)A告訴主機(jī)B 兩件事:我想要和你通信;你可以用哪個(gè)序列號(hào)作為起始數(shù)據(jù)段來回應(yīng)我.2 主機(jī)B 收到主機(jī)A的請(qǐng)求后,用一個(gè)帶有確認(rèn)應(yīng)答(ACK)和同步序列號(hào)(SYN)標(biāo)志位的數(shù)據(jù)段響應(yīng)主機(jī)A,也告訴主機(jī)A兩件事:我已經(jīng)收到你的請(qǐng)求了,你可以

3、傳輸數(shù)據(jù)了;你要用哪佧序列號(hào)作為起始數(shù)據(jù)段來回應(yīng)我3 主機(jī)A收到這個(gè)數(shù)據(jù)段后,再發(fā)送一個(gè)確認(rèn)應(yīng)答,確認(rèn)已收到主機(jī)B 的數(shù)據(jù)段:我已收到回復(fù),我現(xiàn)在要開始傳輸實(shí)際數(shù)據(jù)了這樣3次握手就完成了,主機(jī)A和主機(jī)B 就可以傳輸數(shù)據(jù)了.3次握手的特點(diǎn)沒有應(yīng)用層的數(shù)據(jù)SYN這個(gè)標(biāo)志位只有在TCP建產(chǎn)連接時(shí)才會(huì)被置1握手完成后SYN標(biāo)志位被置0TCP斷開連接要進(jìn)行4次1 當(dāng)主機(jī)A完成數(shù)據(jù)傳輸后,將控制位FIN置1,提出停止TCP連接的請(qǐng)求2 主機(jī)B收到FIN后對(duì)其作出響應(yīng),確認(rèn)這一方向上的TCP連接將關(guān)閉,將ACK置13 由B 端再提出反方向的關(guān)閉請(qǐng)求,將FIN置14 主機(jī)A對(duì)主機(jī)B的請(qǐng)求進(jìn)行確認(rèn),將ACK置1

4、,雙方向的關(guān)閉結(jié)束.由TCP的三次握手和四次斷開可以看出,TCP使用面向連接的通信方式,大大提高了數(shù)據(jù)通信的可靠性,使發(fā)送數(shù)據(jù)端和接收端在數(shù)據(jù)正式傳輸前就有了交互,為數(shù)據(jù)正式傳輸打下了可靠的基礎(chǔ)名詞解釋ACK TCP報(bào)頭的控制位之一,對(duì)數(shù)據(jù)進(jìn)行確認(rèn).確認(rèn)由目的端發(fā)出,用它來告訴發(fā)送端這個(gè)序列號(hào)之前的數(shù)據(jù)段都收到了.比如,確認(rèn)號(hào)為X,則表示前X-1個(gè)數(shù)據(jù)段都收到了,只有當(dāng)ACK=1時(shí),確認(rèn)號(hào)才有效,當(dāng)ACK=0時(shí),確認(rèn)號(hào)無效,這時(shí)會(huì)要求重傳數(shù)據(jù),保證數(shù)據(jù)的完整性.SYN 同步序列號(hào),TCP建立連接時(shí)將這個(gè)位置1FIN 發(fā)送端完成發(fā)送任務(wù)位,當(dāng)TCP完成數(shù)據(jù)傳輸需要斷開時(shí),提出斷開連接的一方將這位

5、置1UDP（User Data Protocol，用戶數(shù)據(jù)報(bào)協(xié)議）（1） UDP是一個(gè)非連接的協(xié)議，傳輸數(shù)據(jù)之前源端和終端不建立連接，當(dāng)它想傳送時(shí)就簡單地去抓取來自應(yīng)用程序的數(shù)據(jù)，并盡可能快地把它扔到網(wǎng)絡(luò)上。在發(fā)送端，UDP傳送數(shù)據(jù)的速度僅僅是受應(yīng)用程序生成數(shù)據(jù)的速度、計(jì)算機(jī)的能力和傳輸帶寬的限制；在接收端，UDP把每個(gè)消息段放在隊(duì)列中，應(yīng)用程序每次從隊(duì)列中讀一個(gè)消息段。（2）由于傳輸數(shù)據(jù)不建立連接，因此也就不需要維護(hù)連接狀態(tài)，包括收發(fā)狀態(tài)等，因此一臺(tái)服務(wù)機(jī)可同時(shí)向多個(gè)客戶機(jī)傳輸相同的消息。（3） UDP信息包的標(biāo)題很短，只有8個(gè)字節(jié)，相對(duì)于TCP的20個(gè)字節(jié)信息包的額外開銷很小。（4）吞吐量

6、不受擁擠控制算法的調(diào)節(jié)，只受應(yīng)用軟件生成數(shù)據(jù)的速率、傳輸帶寬、源端和終端主機(jī)性能的限制。（5）UDP使用盡最大努力交付，即不保證可靠交付，因此主機(jī)不需要維持復(fù)雜的鏈接狀態(tài)表（這里面有許多參數(shù)）。（6）UDP是面向報(bào)文的。發(fā)送方的UDP對(duì)應(yīng)用程序交下來的報(bào)文，在添加首部后就向下交付給IP層。既不拆分，也不合并，而是保留這些報(bào)文的邊界，因此，應(yīng)用程序需要選擇合適的報(bào)文大小。我們經(jīng)常使用“ping”命令來測試兩臺(tái)主機(jī)之間TCP/IP通信是否正常，其實(shí)“ping”命令的原理就是向?qū)Ψ街鳈C(jī)發(fā)送UDP數(shù)據(jù)包，然后對(duì)方主機(jī)確認(rèn)收到數(shù)據(jù)包，如果數(shù)據(jù)包是否到達(dá)的消息及時(shí)反饋回來，那么網(wǎng)絡(luò)就是通的。小結(jié)TCP與U

7、DP的區(qū)別：1.基于連接與無連接；2.對(duì)系統(tǒng)資源的要求（TCP較多，UDP少）；3.UDP程序結(jié)構(gòu)較簡單；4.流模式與數(shù)據(jù)報(bào)模式 ；5.TCP保證數(shù)據(jù)正確性，UDP可能丟包，TCP保證數(shù)據(jù)順序，UDP不保證。更多TCP和UPD的資料：TCP傳輸控制協(xié)議,提供的是面向連接、可靠的字節(jié)流服務(wù)。當(dāng)客戶和服務(wù)器彼此交換數(shù)據(jù)前，必須先在雙方之間建立一個(gè)TCP連接，之后才能傳輸數(shù)據(jù)。TCP提供超時(shí)重發(fā)，丟棄重復(fù)數(shù)據(jù)，檢驗(yàn)數(shù)據(jù)，流量控制等功能，保證數(shù)據(jù)能從一端傳到另一端。UDP用戶數(shù)據(jù)報(bào)協(xié)議，是一個(gè)簡單的面向數(shù)據(jù)報(bào)的運(yùn)輸層協(xié)議。UDP不提供可靠性，它只是把應(yīng)用程序傳給IP層的數(shù)據(jù)報(bào)發(fā)送出去，但是并不能保證它

8、們能到達(dá)目的地。由于UDP在傳輸數(shù)據(jù)報(bào)前不用在客戶和服務(wù)器之間建立一個(gè)連接，且沒有超時(shí)重發(fā)等機(jī)制，故而傳輸速度很快。UDP 與 TCP 的主要區(qū)別在于 UDP 不一定提供可靠的數(shù)據(jù)傳輸。事實(shí)上，該協(xié)議不能保證數(shù)據(jù)準(zhǔn)確無誤地到達(dá)目的地。UDP 在許多方面非常有效。當(dāng)某個(gè)程序的目標(biāo)是盡快地傳輸盡可能多的信息時(shí)（其中任意給定數(shù)據(jù)的重要性相對(duì)較低），可使用 UDP。ICQ 短消息使用 UDP 協(xié)議發(fā)送消息。許多程序?qū)⑹褂脝为?dú)的TCP連接和單獨(dú)的UDP連接。重要的狀態(tài)信息隨可靠的TCP連接發(fā)送，而主數(shù)據(jù)流通過UDP發(fā)送。TCP的目的是提供可靠的數(shù)據(jù)傳輸，并在相互進(jìn)行通信的設(shè)備或服務(wù)之間保持一個(gè)虛擬連接。

9、TCP在數(shù)據(jù)包接收無序、丟失或在交付期間被破壞時(shí)，負(fù)責(zé)數(shù)據(jù)恢復(fù)。它通過為其發(fā)送的每個(gè)數(shù)據(jù)包提供一個(gè)序號(hào)來完成此恢復(fù)。記住，較低的網(wǎng)絡(luò)層會(huì)將每個(gè)數(shù)據(jù)包視為一個(gè)獨(dú)立的單元，因此，數(shù)據(jù)包可以沿完全不同的路徑發(fā)送，即使它們都是同一消息的組成部分。這種路由與網(wǎng)絡(luò)層處理分段和重新組裝數(shù)據(jù)包的方式非常相似，只是級(jí)別更高而已。為確保正確地接收數(shù)據(jù)，TCP要求在目標(biāo)計(jì)算機(jī)成功收到數(shù)據(jù)時(shí)發(fā)回一個(gè)確認(rèn)（即 ACK）。如果在某個(gè)時(shí)限內(nèi)未收到相應(yīng)的 ACK，將重新傳送數(shù)據(jù)包。如果網(wǎng)絡(luò)擁塞，這種重新傳送將導(dǎo)致發(fā)送的數(shù)據(jù)包重復(fù)。但是，接收計(jì)算機(jī)可使用數(shù)據(jù)包的序號(hào)來確定它是否為重復(fù)數(shù)據(jù)包，并在必要時(shí)丟棄它。TCP與UDP的選

10、擇如果比較UDP包和TCP包的結(jié)構(gòu)，很明顯UDP包不具備TCP包復(fù)雜的可靠性與控制機(jī)制。與TCP協(xié)議相同，UDP的源端口數(shù)和目的端口數(shù)也都支持一臺(tái)主機(jī)上的多個(gè)應(yīng)用。一個(gè)16位的UDP包包含了一個(gè)字節(jié)長的頭部和數(shù)據(jù)的長度，校驗(yàn)碼域使其可以進(jìn)行整體校驗(yàn)。（許多應(yīng)用只支持UDP，如：多媒體數(shù)據(jù)流，不產(chǎn)生任何額外的數(shù)據(jù)，即使知道有破壞的包也不進(jìn)行重發(fā)。）很明顯，當(dāng)數(shù)據(jù)傳輸?shù)男阅鼙仨氉屛挥跀?shù)據(jù)傳輸?shù)耐暾?、可控制性和可靠性時(shí)，TCP協(xié)議是當(dāng)然的選擇。當(dāng)強(qiáng)調(diào)傳輸性能而不是傳輸?shù)耐暾詴r(shí)，如：音頻和多媒體應(yīng)用，UDP是最好的選擇。在數(shù)據(jù)傳輸時(shí)間很短，以至于此前的連接過程成為整個(gè)流量主體的情況下，UDP也是一

11、個(gè)好的選擇，如：DNS交換。把 SNMP建立在UDP上的部分原因是設(shè)計(jì)者認(rèn)為當(dāng)發(fā)生網(wǎng)絡(luò)阻塞時(shí)，UDP較低的開銷使其有更好的機(jī)會(huì)去傳送管理數(shù)據(jù)。TCP豐富的功能有時(shí)會(huì)導(dǎo)致不可預(yù)料的性能低下，但是我們相信在不遠(yuǎn)的將來，TCP可靠的點(diǎn)對(duì)點(diǎn)連接將會(huì)用于絕大多數(shù)的網(wǎng)絡(luò)應(yīng)用。FTP協(xié)議即文件傳輸協(xié)議,它是一個(gè)標(biāo)準(zhǔn)協(xié)議,FTP協(xié)議也是應(yīng)用TCP/IP協(xié)議的應(yīng)用協(xié)議標(biāo)準(zhǔn),它是在計(jì)算機(jī)和網(wǎng)絡(luò)之間交換文件的最簡單的方法。 TCP與UDP區(qū)別TCP傳輸控制協(xié)議,提供的是面向連接、可靠的字節(jié)流服務(wù)。當(dāng)客戶和服務(wù)器彼此交換數(shù)據(jù)前，必須先在雙方之間建立一個(gè)TCP連接，之后才能傳輸數(shù)據(jù)。TCP提供超時(shí)重發(fā)，丟棄重復(fù)數(shù)據(jù)，檢

12、驗(yàn)數(shù)據(jù)，流量控制等功能，保證數(shù)據(jù)能從一端傳到另一端。UDP用戶數(shù)據(jù)報(bào)協(xié)議，是一個(gè)簡單的面向數(shù)據(jù)報(bào)的運(yùn)輸層協(xié)議。UDP不提供可靠性，它只是把應(yīng)用程序傳給IP層的數(shù)據(jù)報(bào)發(fā)送出去，但是并不能保證它們能到達(dá)目的地。由于UDP在傳輸數(shù)據(jù)報(bào)前不用在客戶和服務(wù)器之間建立一個(gè)連接，且沒有超時(shí)重發(fā)等機(jī)制，故而傳輸速度很快OverviewTCP (Transmission Control Protocol) is the most commonly used protocol on the Internet. The reason for this is because TCP offers error corr

13、ection. When the TCP protocol is used there is a guaranteed delivery. This is due largely in part to a method called flow control. Flow control determines when data needs to be re-sent, and stops the flow of data until previous packets are successfully transferred. This works because if a packet of

14、data is sent, a collision may occur. When this happens, the client re-requests the packet from the server until the whole packet is complete and is identical to its original.UDP (User Datagram Protocol) is anther commonly used protocol on the Internet. However, UDP is never used to send important da

15、ta such as webpages, database information, etc; UDP is commonly used for streaming audio and video. Streaming media such as Windows Media audio files (.WMA) , Real Player (.RM), and others use UDP because it offers speed! The reason UDP is faster than TCP is because there is no form of flow control

16、or error correction. The data sent over the Internet is affected by collisions, and errors will be present. Remember that UDP is only concerned with speed. This is the main reason why streaming media is not high quality.On the contrary, UDP has been implemented among some trojan horse viruses. Hacke

17、rs develop scripts and trojans to run over UDP in order to mask their activities. UDP packets are also used in DoS (Denial of Service) attacks. It is important to know the difference between TCP port 80 and UDP port 80. If you dont know what ports are go HYPERLINK /ports.php here.Frame StructureAs d

18、ata moves along a network, various attributes are added to the file to create a frame. This process is called encapsulation. There are different methods of encapsulation depending on which protocol and HYPERLINK /ntoplogy.php topology are being used. As a result, the frame structure of these packets

19、 differ as well. The images below show both the TCP and UDP frame structures.TCP FRAME STRUCTUREUDP FRAME STRUCTUREThe payload field contains the actually data. Notice that TCP has a more complex frame structure. This is largely due to the fact the TCP is a connection-oriented protocol. The extra fi

20、elds are need to ensure the guaranteed delivery offered by TCP.UDPUDP 與 TCP 的主要區(qū)別在于 UDP 不一定提供可靠的數(shù)據(jù)傳輸。事實(shí)上，該協(xié)議不能保證數(shù)據(jù)準(zhǔn)確無誤地到達(dá)目的地。UDP 在許多方面非常有效。當(dāng)某個(gè)程序的目標(biāo)是盡快地傳輸盡可能多的信息時(shí)（其中任意給定數(shù)據(jù)的重要性相對(duì)較低），可使用 UDP。ICQ 短消息使用 UDP 協(xié)議發(fā)送消息。許多程序?qū)⑹褂脝为?dú)的TCP連接和單獨(dú)的UDP連接。重要的狀態(tài)信息隨可靠的TCP連接發(fā)送，而主數(shù)據(jù)流通過UDP發(fā)送。TCPTCP的目的是提供可靠的數(shù)據(jù)傳輸，并在相互進(jìn)行通信的設(shè)備或服務(wù)

21、之間保持一個(gè)虛擬連接。TCP在數(shù)據(jù)包接收無序、丟失或在交付期間被破壞時(shí)，負(fù)責(zé)數(shù)據(jù)恢復(fù)。它通過為其發(fā)送的每個(gè)數(shù)據(jù)包提供一個(gè)序號(hào)來完成此恢復(fù)。記住，較低的網(wǎng)絡(luò)層會(huì)將每個(gè)數(shù)據(jù)包視為一個(gè)獨(dú)立的單元，因此，數(shù)據(jù)包可以沿完全不同的路徑發(fā)送，即使它們都是同一消息的組成部分。這種路由與網(wǎng)絡(luò)層處理分段和重新組裝數(shù)據(jù)包的方式非常相似，只是級(jí)別更高而已。為確保正確地接收數(shù)據(jù)，TCP要求在目標(biāo)計(jì)算機(jī)成功收到數(shù)據(jù)時(shí)發(fā)回一個(gè)確認(rèn)（即 ACK）。如果在某個(gè)時(shí)限內(nèi)未收到相應(yīng)的 ACK，將重新傳送數(shù)據(jù)包。如果網(wǎng)絡(luò)擁塞，這種重新傳送將導(dǎo)致發(fā)送的數(shù)據(jù)包重復(fù)。但是，接收計(jì)算機(jī)可使用數(shù)據(jù)包的序號(hào)來確定它是否為重復(fù)數(shù)據(jù)包，并在必要時(shí)丟棄

22、它。TCP與UDP的選擇如果比較UDP包和TCP包的結(jié)構(gòu)，很明顯UDP包不具備TCP包復(fù)雜的可靠性與控制機(jī)制。與TCP協(xié)議相同，UDP的源端口數(shù)和目的端口數(shù)也都支持一臺(tái)主機(jī)上的多個(gè)應(yīng)用。一個(gè)16位的UDP包包含了一個(gè)字節(jié)長的頭部和數(shù)據(jù)的長度，校驗(yàn)碼域使其可以進(jìn)行整體校驗(yàn)。（許多應(yīng)用只支持UDP，如：多媒體數(shù)據(jù)流，不產(chǎn)生任何額外的數(shù)據(jù)，即使知道有破壞的包也不進(jìn)行重發(fā)。）很明顯，當(dāng)數(shù)據(jù)傳輸?shù)男阅鼙仨氉屛挥跀?shù)據(jù)傳輸?shù)耐暾?、可控制性和可靠性時(shí)，TCP協(xié)議是當(dāng)然的選擇。當(dāng)強(qiáng)調(diào)傳輸性能而不是傳輸?shù)耐暾詴r(shí)，如：音頻和多媒體應(yīng)用，UDP是最好的選擇。在數(shù)據(jù)傳輸時(shí)間很短，以至于此前的連接過程成為整個(gè)流量主體

23、的情況下，UDP也是一個(gè)好的選擇，如：DNS交換。把SNMP建立在UDP上的部分原因是設(shè)計(jì)者認(rèn)為當(dāng)發(fā)生網(wǎng)絡(luò)阻塞時(shí)，UDP較低的開銷使其有更好的機(jī)會(huì)去傳送管理數(shù)據(jù)。TCP豐富的功能有時(shí)會(huì)導(dǎo)致不可預(yù)料的性能低下，但是我們相信在不遠(yuǎn)的將來，TCP可靠的點(diǎn)對(duì)點(diǎn)連接將會(huì)用于絕大多數(shù)的網(wǎng)絡(luò)應(yīng)用。 HYPERLINK /Jessy/p/3536163.html TCP與UDP的區(qū)別 1. 理解：窗口和滑動(dòng)窗口TCP的流量控制TCP使用窗口機(jī)制進(jìn)行流量控制什么是窗口？連接建立時(shí)，各端分配一塊緩沖區(qū)用來存儲(chǔ)接收的數(shù)據(jù)，并將緩沖區(qū)的尺寸發(fā)送給另一端接收方發(fā)送的確認(rèn)信息中包含了自己剩余的緩沖區(qū)尺寸剩余緩沖區(qū)空間的數(shù)

24、量叫做窗口2. TCP的流控過程（滑動(dòng)窗口）2.TCP與UDP的區(qū)別很多文章都說TCP協(xié)議可靠，UDP協(xié)議不可靠！為什么前者可靠，后者不可靠呢？既然UDP協(xié)議不可靠，為什么還要使用它呢？所謂的TCP協(xié)議是面向連接的協(xié)議，面向連接是什么呢？TCP和UDP都是傳輸層的協(xié)議！從編程的角度看，就是兩個(gè)模塊（模塊就是代碼的集合，一系列代碼的組合提供相應(yīng)的功能！模塊化最終目的就是：分工協(xié)作！模塊化好處：便于擴(kuò)展開發(fā)以及維護(hù)?。Ｏ日fTCP協(xié)議：這個(gè)協(xié)議，是面向的連接！面向連接這個(gè)概念，我們要從物理層看起。大家都知道，因?yàn)椤靶诺缽?fù)用技術(shù)”的迅猛發(fā)展，才促使了計(jì)算機(jī)網(wǎng)絡(luò)的發(fā)展！如果沒有“信道復(fù)用技術(shù)”，那么單

25、條線路上（這里的線路指物理傳輸介質(zhì)，例如：雙絞線、光纖、電話線）單位時(shí)間內(nèi)只能供一臺(tái)計(jì)算機(jī)使用！還是舉例說明：就拿你自己的計(jì)算機(jī)來說，你跟同學(xué)“小明”聊天的時(shí)候，就不能跟另外一位同學(xué)“小強(qiáng)”聊天，如果你想同時(shí)跟兩位同學(xué)聊天，那么你就得裝兩條線路！那么同時(shí)與第三位、第四位同學(xué)。第N位同學(xué)聊天的時(shí)候，你需要裝幾根線路？全世界人民聊天的時(shí)候，又需要裝幾根線路？“信道復(fù)用技術(shù)”實(shí)現(xiàn)了，在同一條線路上，單位時(shí)間內(nèi)可供X臺(tái)計(jì)算機(jī)同時(shí)通信！Toad知道以下幾種復(fù)用技術(shù)：1、頻分復(fù)用2、時(shí)分復(fù)用3、波分復(fù)用4、碼分復(fù)用5、空分復(fù)用6、統(tǒng)計(jì)復(fù)用7、極化波復(fù)用關(guān)于“信道復(fù)用技術(shù)”更深層次的問題，需要你自己去研究！

26、上面我們提到了“信道復(fù)用技術(shù)”！知道了這一點(diǎn)，我們就很容易明白“物理信道”上的“虛擬信道”概念了！不同的信道復(fù)用技術(shù)，使用不同的復(fù)用技術(shù)，目的就是創(chuàng)建“虛擬信道”。一個(gè)TCP協(xié)議連接其實(shí)就是在物理線路上創(chuàng)建的一條“虛擬信道”。這條“虛擬信道”建立后，在TCP協(xié)議發(fā)出FIN包之前（兩個(gè)終端都會(huì)向?qū)Ψ桨l(fā)送一個(gè)FIN包），是不會(huì)釋放的。正因?yàn)檫@一點(diǎn)，TCP協(xié)議被稱為面向連接的協(xié)議！UDP協(xié)議，一樣會(huì)在物理線路上創(chuàng)建一條“虛擬信道”，否則UDP協(xié)議無法傳輸數(shù)據(jù)！但是，當(dāng)UDP協(xié)議傳完數(shù)據(jù)后，這條“虛擬信道”就被立即注銷了！因此，稱UDP是不面向連接的協(xié)議！TCP協(xié)議和UDP協(xié)議為什么會(huì)共存?1. 大家

27、要知道，一種物理線路，單位時(shí)間內(nèi)，能夠創(chuàng)建的“虛擬信道”是有限的！2. 使用TCP協(xié)議傳輸數(shù)據(jù)，當(dāng)數(shù)據(jù)從A端傳到B端后，B端會(huì)發(fā)送一個(gè)確認(rèn)包（ACK包）給A端，告知A端數(shù)據(jù)我已收到！UDP協(xié)議就沒有這種確認(rèn)機(jī)制！這就是為什么說TCP協(xié)議可靠，UDP協(xié)議不可靠.QQ普通會(huì)員就是使用的UDP協(xié)議進(jìn)行傳輸數(shù)據(jù)！既然UDP協(xié)議自身沒有確認(rèn)機(jī)制，這個(gè)工作可以交給應(yīng)用層的進(jìn)程來完成（QQ）！大家使用QQ的時(shí)候，感覺出錯(cuò)的幾率還是非常小吧！當(dāng)然，把這個(gè)確認(rèn)工作完全交給QQ自身來做，就直接導(dǎo)致了，QQ軟件體積增大！ 有些應(yīng)用，對(duì)數(shù)據(jù)傳輸可靠性要求非常高，例如大家瀏覽網(wǎng)頁，通過網(wǎng)頁注冊帳號(hào)、轉(zhuǎn)帳等服務(wù)，這是不容

28、許出錯(cuò)的，使用TCP協(xié)議能把出錯(cuò)的可能性降到最低（當(dāng)然，網(wǎng)絡(luò)自身很糟糕，TCP協(xié)議也沒辦法）。但是，提供這種可靠服務(wù)，會(huì)加大網(wǎng)絡(luò)帶寬的開銷，因?yàn)椤疤摂M信道”是持續(xù)存在的，同時(shí)網(wǎng)絡(luò)中還會(huì)出現(xiàn)大量的ACK和FIN包！ 因此，魚和熊掌不可兼得，需根據(jù)實(shí)際情況選擇傳輸協(xié)議.TCP協(xié)議提供了可靠的數(shù)據(jù)傳輸,但是其擁塞控制、數(shù)據(jù)校驗(yàn)、重傳機(jī)制的網(wǎng)絡(luò)開銷很大,不適合實(shí)時(shí)通信,所以選擇開銷很小的UDP協(xié)議來傳輸數(shù)據(jù)。 UDP 協(xié)議是無連接的數(shù)據(jù)傳輸協(xié)議并且無重傳機(jī)制,會(huì)發(fā)生丟包、收到重復(fù)包、亂序等情況。而對(duì)于數(shù)據(jù)精確性要求不高的狀態(tài)數(shù)據(jù)以及視頻數(shù)據(jù),丟包的影響不大。因?yàn)闀?huì)不斷收到新的包,丟失的個(gè)別包會(huì)有新的包

29、來覆蓋,所以只需在遠(yuǎn)程控制系統(tǒng)的通信部分自行處理亂序及重復(fù)包的問題,而對(duì)于丟包的問題一般不作處理。 但對(duì)于命令包這種需要精確收發(fā)的數(shù)據(jù), 可在程序的開發(fā)中加入丟包重發(fā)和超時(shí)丟棄的處理。 當(dāng)然,如果開發(fā)的是對(duì)于實(shí)時(shí)性要求不高的事件型控制命令的傳輸,不希望發(fā)生指令的丟失也可以直接采用TCP協(xié)議。TCP的重傳機(jī)制正好適合這種情況。 非面向連接的傳輸協(xié)議在數(shù)據(jù)傳輸之前不建立連接，而是在每個(gè)中間節(jié)點(diǎn)對(duì)非面向連接的包和數(shù)據(jù)包進(jìn)行路由。沒有點(diǎn)到點(diǎn)的連接，非面向連接的協(xié)議，如UDP，是不可靠的連接。當(dāng)一個(gè)UDP數(shù)據(jù)包在網(wǎng)絡(luò)中移動(dòng)時(shí)，發(fā)送過程并不知道它是否到達(dá)了目的地，除非應(yīng)用層已經(jīng)確認(rèn)了它已到達(dá)的事實(shí)。非面向

30、連接的協(xié)議也不能探測重復(fù)的和亂序的包。標(biāo)準(zhǔn)的專業(yè)術(shù)語用“不可靠”來描述UDP。在現(xiàn)代網(wǎng)絡(luò)中，UDP并不易于導(dǎo)致傳輸失敗，但是你也不能肯定地說它是可靠的 HYPERLINK /Jessy/p/3535612.html TCP的三次握手(建立連接）和四次揮手(關(guān)閉連接） 參照：/CSTD/Linux/reference/files/018.PDF/raycomer/item/944d23d9b502d13be3108f61建立連接：理解：窗口和滑動(dòng)窗口TCP的流量控制TCP使用窗口機(jī)制進(jìn)行流量控制什么是窗口？連接建立時(shí)，各端分配一塊緩沖區(qū)用來存儲(chǔ)接收的數(shù)據(jù)，并將緩沖區(qū)的尺寸發(fā)送給另一端接收方發(fā)送的

31、確認(rèn)信息中包含了自己剩余的緩沖區(qū)尺寸剩余緩沖區(qū)空間的數(shù)量叫做窗口2. TCP的流控過程（滑動(dòng)窗口）TCP(Transmission Control Protocol)傳輸控制協(xié)議三次握手TCP是主機(jī)對(duì)主機(jī)層的傳輸控制協(xié)議，提供可靠的連接服務(wù)，采用三次握手確認(rèn)建立一個(gè)連接:位碼即tcp標(biāo)志位,有6種標(biāo)示:SYN(synchronous建立聯(lián)機(jī))ACK(acknowledgement 確認(rèn))PSH(push傳送)FIN(finish結(jié)束)RST(reset重置)URG(urgent緊急)Sequence number(順序號(hào)碼)Acknowledge number(確認(rèn)號(hào)碼)客戶端TCP狀態(tài)遷移：

32、CLOSED-SYN_SENT-ESTABLISHED-FIN_WAIT_1-FIN_WAIT_2-TIME_WAIT-CLOSED服務(wù)器TCP狀態(tài)遷移：CLOSED-LISTEN-SYN收到-ESTABLISHED-CLOSE_WAIT-LAST_ACK-CLOSED各個(gè)狀態(tài)的意義如下：LISTEN - 偵聽來自遠(yuǎn)方TCP端口的連接請(qǐng)求；SYN-SENT -在發(fā)送連接請(qǐng)求后等待匹配的連接請(qǐng)求；SYN-RECEIVED - 在收到和發(fā)送一個(gè)連接請(qǐng)求后等待對(duì)連接請(qǐng)求的確認(rèn)；ESTABLISHED- 代表一個(gè)打開的連接，數(shù)據(jù)可以傳送給用戶；FIN-WAIT-1 - 等待遠(yuǎn)程TCP的連接中斷請(qǐng)求，或

33、先前的連接中斷請(qǐng)求的確認(rèn)；FIN-WAIT-2 - 從遠(yuǎn)程TCP等待連接中斷請(qǐng)求；CLOSE-WAIT - 等待從本地用戶發(fā)來的連接中斷請(qǐng)求；CLOSING -等待遠(yuǎn)程TCP對(duì)連接中斷的確認(rèn)；LAST-ACK - 等待原來發(fā)向遠(yuǎn)程TCP的連接中斷請(qǐng)求的確認(rèn)；TIME-WAIT -等待足夠的時(shí)間以確保遠(yuǎn)程TCP接收到連接中斷請(qǐng)求的確認(rèn)；CLOSED - 沒有任何連接狀態(tài)；TCP/IP協(xié)議中，TCP協(xié)議提供可靠的連接服務(wù)，采用三次握手建立一個(gè)連接，如圖1所示。（1）第一次握手：建立連接時(shí)，客戶端A發(fā)送SYN包（SYN=j）到服務(wù)器B，并進(jìn)入SYN_SEND狀態(tài)，等待服務(wù)器B確認(rèn)。（2）第二次握手：

34、服務(wù)器B收到SYN包，必須確認(rèn)客戶A的SYN（ACK=j+1），同時(shí)自己也發(fā)送一個(gè)SYN包（SYN=k），即SYN+ACK包，此時(shí)服務(wù)器B進(jìn)入SYN_RECV狀態(tài)。（3）第三次握手：客戶端A收到服務(wù)器B的SYNACK包，向服務(wù)器B發(fā)送確認(rèn)包ACK（ACK=k+1），此包發(fā)送完畢，客戶端A和服務(wù)器B進(jìn)入ESTABLISHED狀態(tài)，完成三次握手。完成三次握手，客戶端與服務(wù)器開始傳送數(shù)據(jù)。確認(rèn)號(hào)：其數(shù)值等于發(fā)送方的發(fā)送序號(hào) +1(即接收方期望接收的下一個(gè)序列號(hào))。圖1TCP三次握手建立連接TCP的包頭結(jié)構(gòu)：源端口 16位目標(biāo)端口 16位序列號(hào) 32位回應(yīng)序號(hào) 32位TCP頭長度 4位reserved

35、 6位控制代碼 6位窗口大小 16位偏移量 16位校驗(yàn)和 16位選項(xiàng)32位(可選)這樣我們得出了TCP包頭的最小長度，為20字節(jié)第一次握手:客戶端發(fā)送一個(gè)TCP的SYN標(biāo)志位置1的包指明客戶打算連接的服務(wù)器的端口，以及初始序號(hào)X,保存在包頭的序列號(hào)(Sequence Number)字段里。第二次握手:服務(wù)器發(fā)回確認(rèn)包(ACK)應(yīng)答。即SYN標(biāo)志位和ACK標(biāo)志位均為1同時(shí)，將確認(rèn)序號(hào)(Acknowledgement Number)設(shè)置為客戶的I S N加1以.即X+1。第三次握手.客戶端再次發(fā)送確認(rèn)包(ACK) SYN標(biāo)志位為0,ACK標(biāo)志位為1.并且把服務(wù)器發(fā)來ACK的序號(hào)字段+1,放在確定字

36、段中發(fā)送給對(duì)方.并且在數(shù)據(jù)段放寫ISN的+1下面是具體的例子截圖：1.此圖包含兩部分信息：TCP的三次握手(方框中的內(nèi)容） （SYN, (SYN+ACK), ACK)2. TCP的數(shù)據(jù)傳輸 （TCP segment of a reassembled PUD)可以看出，server是將數(shù)據(jù)TCP層對(duì)消息包進(jìn)行分片傳輸(1)Server端收到HTTP請(qǐng)求如GET之后，構(gòu)造響應(yīng)消息，其中攜帶網(wǎng)頁內(nèi)容，在server端的HTTP層發(fā)送消息200 OK-server端的TCP層；(2)server端的TCP層對(duì)消息包進(jìn)行分片傳輸；(3)client端的TCP層對(duì)接收到的各個(gè)消息包分片回送響應(yīng)；(4)cl

37、ient端的TCP層每次收到一部分都會(huì)用ACK確認(rèn)，之后server繼續(xù)傳輸，client繼續(xù)確認(rèn)，直到完成響應(yīng)消息的所有分片之后，Server發(fā)送組合HTTP響應(yīng)包 200 OK，此時(shí)在client端的消息跟蹤中才可以顯示HTTP 200 OK的消息包關(guān)閉連接：由于TCP連接是全雙工的，因此每個(gè)方向都必須單獨(dú)進(jìn)行關(guān)閉。這個(gè)原則是當(dāng)一方完成它的數(shù)據(jù)發(fā)送任務(wù)后就能發(fā)送一個(gè)FIN來終止這個(gè)方向的連接。收到一個(gè)FIN只意味著這一方向上沒有數(shù)據(jù)流動(dòng)，一個(gè)TCP連接在收到一個(gè)FIN后仍能發(fā)送數(shù)據(jù)。首先進(jìn)行關(guān)閉的一方將執(zhí)行主動(dòng)關(guān)閉，而另一方執(zhí)行被動(dòng)關(guān)閉。CP的連接的拆除需要發(fā)送四個(gè)包，因此稱為四次揮手(f

38、our-way handshake)?？蛻舳嘶蚍?wù)器均可主動(dòng)發(fā)起揮手動(dòng)作，在socket編程中，任何一方執(zhí)行close()操作即可產(chǎn)生揮手操作。（1）客戶端A發(fā)送一個(gè)FIN，用來關(guān)閉客戶A到服務(wù)器B的數(shù)據(jù)傳送。（2）服務(wù)器B收到這個(gè)FIN，它發(fā)回一個(gè)ACK，確認(rèn)序號(hào)為收到的序號(hào)加1。和SYN一樣，一個(gè)FIN將占用一個(gè)序號(hào)。（3）服務(wù)器B關(guān)閉與客戶端A的連接，發(fā)送一個(gè)FIN給客戶端A。（4）客戶端A發(fā)回ACK報(bào)文確認(rèn)，并將確認(rèn)序號(hào)設(shè)置為收到序號(hào)加1。TCP采用四次揮手關(guān)閉連接如圖2所示。圖2TCP四次揮手關(guān)閉連接參見wireshark抓包，實(shí)測的抓包結(jié)果并沒有嚴(yán)格按揮手時(shí)序。我估計(jì)是時(shí)間間隔太短

39、造成。深入理解TCP連接的釋放：由于TCP連接是全雙工的，因此每個(gè)方向都必須單獨(dú)進(jìn)行關(guān)閉。這原則是當(dāng)一方完成它的數(shù)據(jù)發(fā)送任務(wù)后就能發(fā)送一個(gè)FIN來終止這個(gè)方向的連接。收到一個(gè) FIN只意味著這一方向上沒有數(shù)據(jù)流動(dòng)，一個(gè)TCP連接在收到一個(gè)FIN后仍能發(fā)送數(shù)據(jù)。首先進(jìn)行關(guān)閉的一方將執(zhí)行主動(dòng)關(guān)閉，而另一方執(zhí)行被動(dòng)關(guān)閉。TCP協(xié)議的連接是全雙工連接，一個(gè)TCP連接存在雙向的讀寫通道。簡單說來是 “先關(guān)讀，后關(guān)寫”，一共需要四個(gè)階段。以客戶機(jī)發(fā)起關(guān)閉連接為例：1.服務(wù)器讀通道關(guān)閉2.客戶機(jī)寫通道關(guān)閉3.客戶機(jī)讀通道關(guān)閉4.服務(wù)器寫通道關(guān)閉關(guān)閉行為是在發(fā)起方數(shù)據(jù)發(fā)送完畢之后，給對(duì)方發(fā)出一個(gè)FIN（fin

40、ish）數(shù)據(jù)段。直到接收到對(duì)方發(fā)送的FIN，且對(duì)方收到了接收確認(rèn)ACK之后，雙方的數(shù)據(jù)通信完全結(jié)束，過程中每次接收都需要返回確認(rèn)數(shù)據(jù)段ACK。詳細(xì)過程：第一階段 客戶機(jī)發(fā)送完數(shù)據(jù)之后，向服務(wù)器發(fā)送一個(gè)FIN數(shù)據(jù)段，序列號(hào)為i； 1.服務(wù)器收到FIN(i)后，返回確認(rèn)段ACK，序列號(hào)為i+1，關(guān)閉服務(wù)器讀通道； 2.客戶機(jī)收到ACK(i+1)后，關(guān)閉客戶機(jī)寫通道；（此時(shí)，客戶機(jī)仍能通過讀通道讀取服務(wù)器的數(shù)據(jù)，服務(wù)器仍能通過寫通道寫數(shù)據(jù)）第二階段服務(wù)器發(fā)送完數(shù)據(jù)之后，向客戶機(jī)發(fā)送一個(gè)FIN數(shù)據(jù)段，序列號(hào)為j； 3.客戶機(jī)收到FIN(j)后，返回確認(rèn)段ACK，序列號(hào)為j+1，關(guān)閉客戶機(jī)讀通道； 4.

41、服務(wù)器收到ACK(j+1)后，關(guān)閉服務(wù)器寫通道。這是標(biāo)準(zhǔn)的TCP關(guān)閉兩個(gè)階段，服務(wù)器和客戶機(jī)都可以發(fā)起關(guān)閉，完全對(duì)稱。FIN標(biāo)識(shí)是通過發(fā)送最后一塊數(shù)據(jù)時(shí)設(shè)置的，標(biāo)準(zhǔn)的例子中，服務(wù)器還在發(fā)送數(shù)據(jù)，所以要等到發(fā)送完的時(shí)候，設(shè)置FIN（此時(shí)可稱為TCP連接處于半關(guān)閉狀態(tài)，因?yàn)閿?shù)據(jù)仍可從被動(dòng)關(guān)閉一方向主動(dòng)關(guān)閉方傳送）。如果在服務(wù)器收到FIN(i)時(shí)，已經(jīng)沒有數(shù)據(jù)需要發(fā)送，可以在返回ACK(i+1)的時(shí)候就設(shè)置FIN(j)標(biāo)識(shí)，這樣就相當(dāng)于可以合并第二步和第三步。讀Linux網(wǎng)絡(luò)編程關(guān)閉TCP連接章節(jié)，作以下筆記：“先關(guān)讀，后關(guān)寫”這句話大神是有別的理解嗎？按道理來說，發(fā)送方不寫，接受方收到發(fā)送方不寫后

42、不讀。這樣才更好保證，已發(fā)的都能收到，不發(fā)的之后不再發(fā)。我理解來應(yīng)該是先關(guān)寫后關(guān)讀才對(duì)。而且對(duì)于樓主的那個(gè)http請(qǐng)求的抓包實(shí)驗(yàn)，我想到的一點(diǎn)拙見:對(duì)于tcp的兩端而言，我關(guān)我的寫端，你關(guān)你的寫端。http協(xié)議的一般特殊性，一請(qǐng)求一應(yīng)答。所以服務(wù)端收到客戶端請(qǐng)求之后，已經(jīng)決定不再有后續(xù)通信，所以寫完的回復(fù)之后立即關(guān)閉。客戶端收到服務(wù)器回復(fù)后也幾乎同時(shí)收到了服務(wù)端作為發(fā)送方時(shí)的關(guān)閉寫端。這才表現(xiàn)出了這個(gè)tcp的關(guān)閉時(shí)序跟你解釋的有出入。關(guān)閉寫端也是需要發(fā)送的tcp數(shù)據(jù)。感覺有幾個(gè)地方說的太誤導(dǎo)人。其一：客戶機(jī)發(fā)起關(guān)閉連接為例，為什么不是客戶端先關(guān)閉寫通道，服務(wù)器后關(guān)閉讀通道？其二：對(duì)于CLOSE

43、_WAIT狀態(tài)的描述是錯(cuò)的。原文說“被動(dòng)關(guān)閉的server收到FIN后，但未發(fā)出ACK的TCP狀態(tài)是CLOSE_WAIT”。應(yīng)該是被動(dòng)關(guān)閉端未發(fā)出FIN的TCP狀態(tài)是CLOASE_WAIT。通常服務(wù)器收到FIN消息，不管什么情況都會(huì)立馬發(fā)送ACK確認(rèn)的。如果按原文說的未發(fā)出ACK是CLOSE_WAIT狀態(tài)。那么相信CLOSE_WAIT狀態(tài)將很少看到TCP的TIME_WAIT和Close_Wait狀態(tài)面試時(shí)看到應(yīng)聘者簡歷中寫精通網(wǎng)絡(luò)，TCP編程，我常問一個(gè)問題，TCP建立連接需要幾次握手？95%以上的應(yīng)聘者都能答對(duì)是3次。問TCP斷開連接需要幾次握手，70%的應(yīng)聘者能答對(duì)是4次通訊。再問CLOS

44、E_WAIT，TIME_WAIT是什么狀態(tài)，怎么產(chǎn)生的，對(duì)服務(wù)有什么影響，如何消除？有一部分同學(xué)就回答不上來。不是我扣細(xì)節(jié)，而是在通訊為主的前端服務(wù)器上，必須有能力處理各種TCP狀態(tài)。比如統(tǒng)計(jì)在本廠的一臺(tái)前端機(jī)上高峰時(shí)間TCP連接的情況，統(tǒng)計(jì)命令：Linux shell代碼netstat-n|awk/tcp/+S$NFENDfor(ainS)printa,Sa結(jié)果：除了ESTABLISHED，可以看到連接數(shù)比較多的幾個(gè)狀態(tài)是：FIN_WAIT1, TIME_WAIT, CLOSE_WAIT, SYN_RECV和LAST_ACK；下面的文章就這幾個(gè)狀態(tài)的產(chǎn)生條件、對(duì)系統(tǒng)的影響以及處理方式進(jìn)行簡單

45、描述。TCP狀態(tài)TCP狀態(tài)如下圖所示：可能有點(diǎn)眼花繚亂？再看看這個(gè)時(shí)序圖下面看下大家一般比較關(guān)心的三種TCP狀態(tài)SYN_RECV服務(wù)端收到建立連接的SYN沒有收到ACK包的時(shí)候處在SYN_RECV狀態(tài)。有兩個(gè)相關(guān)系統(tǒng)配置：1，net.ipv4.tcp_synack_retries ：INTEGER默認(rèn)值是5對(duì)于遠(yuǎn)端的連接請(qǐng)求SYN，內(nèi)核會(huì)發(fā)送SYN ACK數(shù)據(jù)報(bào)，以確認(rèn)收到上一個(gè) SYN連接請(qǐng)求包。這是所謂的三次握手( threeway handshake)機(jī)制的第二個(gè)步驟。這里決定內(nèi)核在放棄連接之前所送出的 SYN+ACK 數(shù)目。不應(yīng)該大于255，默認(rèn)值是5，對(duì)應(yīng)于180秒左右時(shí)間。通常我們

46、不對(duì)這個(gè)值進(jìn)行修改，因?yàn)槲覀兿Ｍ鸗CP連接不要因?yàn)榕紶柕膩G包而無法建立。2，net.ipv4.tcp_syncookies一般服務(wù)器都會(huì)設(shè)置net.ipv4.tcp_syncookies=1來防止SYN Flood攻擊。假設(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分鐘）。這些處在SYNC_RECV的T

47、CP連接稱為半連接，并存儲(chǔ)在內(nèi)核的半連接隊(duì)列中，在內(nèi)核收到對(duì)端發(fā)送的ack包時(shí)會(huì)查找半連接隊(duì)列，并將符合的requst_sock信息存儲(chǔ)到完成三次握手的連接的隊(duì)列中，然后刪除此半連接。大量SYNC_RECV的TCP連接會(huì)導(dǎo)致半連接隊(duì)列溢出，這樣后續(xù)的連接建立請(qǐng)求會(huì)被內(nèi)核直接丟棄，這就是SYN Flood攻擊。能夠有效防范SYN Flood攻擊的手段之一，就是SYN Cookie。SYN Cookie原理由D. J. Bernstain和 Eric Schenk發(fā)明。SYN Cookie是對(duì)TCP服務(wù)器端的三次握手協(xié)議作一些修改，專門用來防范SYN Flood攻擊的一種手段。它的原理是，在TCP

48、服務(wù)器收到TCP SYN包并返回TCP SYN+ACK包時(shí)，不分配一個(gè)專門的數(shù)據(jù)區(qū)，而是根據(jù)這個(gè)SYN包計(jì)算出一個(gè)cookie值。在收到TCP ACK包時(shí)，TCP服務(wù)器在根據(jù)那個(gè)cookie值檢查這個(gè)TCP ACK包的合法性。如果合法，再分配專門的數(shù)據(jù)區(qū)進(jìn)行處理未來的TCP連接。觀測服務(wù)上SYN_RECV連接個(gè)數(shù)為：7314，對(duì)于一個(gè)高并發(fā)連接的通訊服務(wù)器，這個(gè)數(shù)字比較正常。CLOSE_WAIT發(fā)起TCP連接關(guān)閉的一方稱為client，被動(dòng)關(guān)閉的一方稱為server。被動(dòng)關(guān)閉的server收到FIN后，但未發(fā)出ACK的TCP狀態(tài)是CLOSE_WAIT。出現(xiàn)這種狀況一般都是由于server端代碼

49、的問題，如果你的服務(wù)器上出現(xiàn)大量CLOSE_WAIT，應(yīng)該要考慮檢查代碼。TIME_WAIT根據(jù)TCP協(xié)議定義的3次握手?jǐn)嚅_連接規(guī)定,發(fā)起socket主動(dòng)關(guān)閉的一方 socket將進(jìn)入TIME_WAIT狀態(tài)。TIME_WAIT狀態(tài)將持續(xù)2個(gè)MSL(Max Segment Lifetime),在Windows下默認(rèn)為4分鐘，即240秒。TIME_WAIT狀態(tài)下的socket不能被回收使用. 具體現(xiàn)象是對(duì)于一個(gè)處理大量短連接的服務(wù)器,如果是由服務(wù)器主動(dòng)關(guān)閉客戶端的連接，將導(dǎo)致服務(wù)器端存在大量的處于TIME_WAIT狀態(tài)的socket， 甚至比處于Established狀態(tài)下的socket多的多,嚴(yán)

50、重影響服務(wù)器的處理能力，甚至耗盡可用的socket，停止服務(wù)。為什么需要TIME_WAIT？TIME_WAIT是TCP協(xié)議用以保證被重新分配的socket不會(huì)受到之前殘留的延遲重發(fā)報(bào)文影響的機(jī)制,是必要的邏輯保證。和TIME_WAIT狀態(tài)有關(guān)的系統(tǒng)參數(shù)有一般由3個(gè)，本廠設(shè)置如下：net.ipv4.tcp_tw_recycle = 1net.ipv4.tcp_tw_reuse = 1net.ipv4.tcp_fin_timeout = 30net.ipv4.tcp_fin_timeout，默認(rèn)60s，減小fin_timeout，減少TIME_WAIT連接數(shù)量。net.ipv4.tcp_tw_re

51、use = 1表示開啟重用。允許將TIME-WAIT sockets重新用于新的TCP連接，默認(rèn)為0，表示關(guān)閉；net.ipv4.tcp_tw_recycle = 1表示開啟TCP連接中TIME-WAIT sockets的快速回收，默認(rèn)為0，表示關(guān)閉。為了方便描述，我給這個(gè)TCP連接的一端起名為Client，給另外一端起名為Server。上圖描述的是Client主動(dòng)關(guān)閉的過程，F(xiàn)TP協(xié)議中就這樣的。如果要描述Server主動(dòng)關(guān)閉的過程，只要交換描述過程中的Server和Client就可以了，HTTP協(xié)議就是這樣的。描述過程：Client調(diào)用close()函數(shù)，給Server發(fā)送FIN，請(qǐng)求關(guān)閉連接；Server收到FIN之后給Client返回確認(rèn)