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ù)前，必須和對方建立可靠的連接。一個TCP連接必須要經(jīng)過三次“對話”才能建立起來，其中的過程非常復(fù)雜，只簡單的描述下這三次對話的簡單過程：A B/主機A向主機B發(fā)出連接請求數(shù)據(jù)包：“我想給你發(fā)數(shù)據(jù)，可以嗎？”，這是第一次

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

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

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

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

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

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

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

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

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

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

12、驗數(shù)據(jù)，流量控制等功能，保證數(shù)據(jù)能從一端傳到另一端。UDP用戶數(shù)據(jù)報協(xié)議，是一個簡單的面向數(shù)據(jù)報的運輸層協(xié)議。UDP不提供可靠性，它只是把應(yīng)用程序傳給IP層的數(shù)據(jù)報發(fā)送出去，但是并不能保證它們能到達目的地。由于UDP在傳輸數(shù)據(jù)報前不用在客戶和服務(wù)器之間建立一個連接，且沒有超時重發(fā)等機制，故而傳輸速度很快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ù)傳輸。事實上，該協(xié)議不能保證數(shù)據(jù)準(zhǔn)確無誤地到達目的地。UDP 在許多方面非常有效。當(dāng)某個程序的目標(biāo)是盡快地傳輸盡可能多的信息時（其中任意給定數(shù)據(jù)的重要性相對較低），可使用 UDP。ICQ 短消息使用 UDP 協(xié)議發(fā)送消息。許多程序?qū)⑹褂脝为毜腡CP連接和單獨的UDP連接。重要的狀態(tài)信息隨可靠的TCP連接發(fā)送，而主數(shù)據(jù)流通過UDP發(fā)送。TCPTCP的目的是提供可靠的數(shù)據(jù)傳輸，并在相互進行通信的設(shè)備或服務(wù)

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

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

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

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

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

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

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

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

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

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建立連接：理解：窗口和滑動窗口TCP的流量控制TCP使用窗口機制進行流量控制什么是窗口？連接建立時，各端分配一塊緩沖區(qū)用來存儲接收的數(shù)據(jù)，并將緩沖區(qū)的尺寸發(fā)送給另一端接收方發(fā)送的

31、確認信息中包含了自己剩余的緩沖區(qū)尺寸剩余緩沖區(qū)空間的數(shù)量叫做窗口2. TCP的流控過程（滑動窗口）TCP(Transmission Control Protocol)傳輸控制協(xié)議三次握手TCP是主機對主機層的傳輸控制協(xié)議，提供可靠的連接服務(wù)，采用三次握手確認建立一個連接:位碼即tcp標(biāo)志位,有6種標(biāo)示:SYN(synchronous建立聯(lián)機)ACK(acknowledgement 確認)PSH(push傳送)FIN(finish結(jié)束)RST(reset重置)URG(urgent緊急)Sequence number(順序號碼)Acknowledge number(確認號碼)客戶端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各個狀態(tài)的意義如下：LISTEN - 偵聽來自遠方TCP端口的連接請求；SYN-SENT -在發(fā)送連接請求后等待匹配的連接請求；SYN-RECEIVED - 在收到和發(fā)送一個連接請求后等待對連接請求的確認；ESTABLISHED- 代表一個打開的連接，數(shù)據(jù)可以傳送給用戶；FIN-WAIT-1 - 等待遠程TCP的連接中斷請求，或

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

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

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

36、段中發(fā)送給對方.并且在數(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層對消息包進行分片傳輸(1)Server端收到HTTP請求如GET之后，構(gòu)造響應(yīng)消息，其中攜帶網(wǎng)頁內(nèi)容，在server端的HTTP層發(fā)送消息200 OK-server端的TCP層；(2)server端的TCP層對消息包進行分片傳輸；(3)client端的TCP層對接收到的各個消息包分片回送響應(yīng)；(4)cl

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

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

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

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

41、服務(wù)器收到ACK(j+1)后，關(guān)閉服務(wù)器寫通道。這是標(biāo)準(zhǔn)的TCP關(guān)閉兩個階段，服務(wù)器和客戶機都可以發(fā)起關(guān)閉，完全對稱。FIN標(biāo)識是通過發(fā)送最后一塊數(shù)據(jù)時設(shè)置的，標(biāo)準(zhǔn)的例子中，服務(wù)器還在發(fā)送數(shù)據(jù)，所以要等到發(fā)送完的時候，設(shè)置FIN（此時可稱為TCP連接處于半關(guān)閉狀態(tài)，因為數(shù)據(jù)仍可從被動關(guān)閉一方向主動關(guān)閉方傳送）。如果在服務(wù)器收到FIN(i)時，已經(jīng)沒有數(shù)據(jù)需要發(fā)送，可以在返回ACK(i+1)的時候就設(shè)置FIN(j)標(biāo)識，這樣就相當(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)讀才對。而且對于樓主的那個http請求的抓包實驗，我想到的一點拙見:對于tcp的兩端而言，我關(guān)我的寫端，你關(guān)你的寫端。http協(xié)議的一般特殊性，一請求一應(yīng)答。所以服務(wù)端收到客戶端請求之后，已經(jīng)決定不再有后續(xù)通信，所以寫完的回復(fù)之后立即關(guān)閉?？蛻舳耸盏椒?wù)器回復(fù)后也幾乎同時收到了服務(wù)端作為發(fā)送方時的關(guān)閉寫端。這才表現(xiàn)出了這個tcp的關(guān)閉時序跟你解釋的有出入。關(guān)閉寫端也是需要發(fā)送的tcp數(shù)據(jù)。感覺有幾個地方說的太誤導(dǎo)人。其一：客戶機發(fā)起關(guān)閉連接為例，為什么不是客戶端先關(guān)閉寫通道，服務(wù)器后關(guān)閉讀通道？其二：對于CLOSE

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

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

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

46、不對這個值進行修改，因為我們希望TCP連接不要因為偶爾的丟包而無法建立。2，net.ipv4.tcp_syncookies一般服務(wù)器都會設(shè)置net.ipv4.tcp_syncookies=1來防止SYN Flood攻擊。假設(shè)一個用戶向服務(wù)器發(fā)送了SYN報文后突然死機或掉線，那么服務(wù)器在發(fā)出SYN+ACK應(yīng)答報文后是無法收到客戶端的ACK報文的（第三次握手無法完成），這種情況下服務(wù)器端一般會重試（再次發(fā)送SYN+ACK給客戶端）并等待一段時間后丟棄這個未完成的連接，這段時間的長度我們稱為SYN Timeout，一般來說這個時間是分鐘的數(shù)量級（大約為30秒-2分鐘）。這些處在SYNC_RECV的T

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

48、服務(wù)器收到TCP SYN包并返回TCP SYN+ACK包時，不分配一個專門的數(shù)據(jù)區(qū)，而是根據(jù)這個SYN包計算出一個cookie值。在收到TCP ACK包時，TCP服務(wù)器在根據(jù)那個cookie值檢查這個TCP ACK包的合法性。如果合法，再分配專門的數(shù)據(jù)區(qū)進行處理未來的TCP連接。觀測服務(wù)上SYN_RECV連接個數(shù)為：7314，對于一個高并發(fā)連接的通訊服務(wù)器，這個數(shù)字比較正常。CLOSE_WAIT發(fā)起TCP連接關(guān)閉的一方稱為client，被動關(guān)閉的一方稱為server。被動關(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次握手斷開連接規(guī)定,發(fā)起socket主動關(guān)閉的一方 socket將進入TIME_WAIT狀態(tài)。TIME_WAIT狀態(tài)將持續(xù)2個MSL(Max Segment Lifetime),在Windows下默認為4分鐘，即240秒。TIME_WAIT狀態(tài)下的socket不能被回收使用. 具體現(xiàn)象是對于一個處理大量短連接的服務(wù)器,如果是由服務(wù)器主動關(guān)閉客戶端的連接，將導(dǎo)致服務(wù)器端存在大量的處于TIME_WAIT狀態(tài)的socket， 甚至比處于Established狀態(tài)下的socket多的多,嚴

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

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