TCP和UDP講解分析

1、TCP UDP數(shù)據(jù)包發(fā)送程序Windows下winpcap實(shí)現(xiàn)講解流程 (目錄)lTCPlUDPlTCP/UDP校驗(yàn)以及計(jì)算方法TCP (協(xié)議簡介)維基百科給出的定義:是一種 面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議，由IETF（互聯(lián)網(wǎng)工程任務(wù)小組）的RFC 793定義。在簡化的計(jì)算機(jī)網(wǎng)絡(luò)OSI模型中，它完成第四層傳輸層所指定的功能，用戶數(shù)據(jù)報(bào)協(xié)議（UDP）是同一層內(nèi)另一個(gè)重要的傳輸協(xié)議。TCP (數(shù)據(jù)包結(jié)構(gòu))URG：緊急指針有效標(biāo)志位，當(dāng)它被置為1時(shí)，緊急指針才有效。ACK：確認(rèn)序號有效，當(dāng)它被置為1時(shí)，確認(rèn)序號才有效。PSH：接受方應(yīng)該盡快將這個(gè)報(bào)文交給應(yīng)用層。RST：重建連接。SY

2、N：同步序號用來發(fā)起一個(gè)新連接。FIN：發(fā)端完成發(fā)送任務(wù)。seqack=seq+1TCP (三次握手)1.建立連接時(shí)，客戶端發(fā)送SYN包以及seq到服務(wù)器，并進(jìn)入到SYN-SEND狀態(tài)，等待服務(wù)器確認(rèn)2.服務(wù)器收到SYN包，必須確認(rèn)客戶的SYN（ack=seq+1）,同時(shí)自己也發(fā)送一個(gè)SYN包,即SYN+ACK包，此時(shí)服務(wù)器進(jìn)入SYN-RECV狀態(tài)3.客戶端收到服務(wù)器的SYN+ACK包，向服務(wù)器發(fā)送確認(rèn)報(bào)ACK（ack=k+1）,此包發(fā)送完畢，客戶端和服務(wù)器進(jìn)入ESTABLISHED狀態(tài)，完成三次握手TCP (四次揮手)1.如圖所示，發(fā)送端先發(fā)送帶有FIN標(biāo)志的報(bào)文給服務(wù)端，表面自己這端已經(jīng)無

3、數(shù)據(jù)可以發(fā)送了，希望關(guān)閉TCP連接。報(bào)文的seq為x2.服務(wù)端接受到這個(gè)報(bào)文之后發(fā)送帶有ACK標(biāo)志的報(bào)文，其ack為x+13.服務(wù)端無數(shù)據(jù)發(fā)送之后，也向客戶端發(fā)送帶有FIN標(biāo)志的報(bào)文，seq為z4.客戶端接受到該報(bào)文之后，發(fā)送一個(gè)帶有ACK標(biāo)志的報(bào)文，其ack為z+1UDP(協(xié)議簡介)UDP ，是OSI參考模型中一種無連接的傳輸層協(xié)議，提供面向事務(wù)的簡單不可靠信息傳送服務(wù)，IETF RFC 768是UDP的正式規(guī)范。UDP在IP報(bào)文的協(xié)議號是17。UDP協(xié)議全稱是用戶數(shù)據(jù)報(bào)協(xié)議1 ，在網(wǎng)絡(luò)中它與TCP協(xié)議一樣用于處理數(shù)據(jù)包，是一種無連接的協(xié)議。在OSI模型中，在第四層傳輸層，處于IP協(xié)議的上一

4、層。UDP有不提供數(shù)據(jù)包分組、組裝和不能對數(shù)據(jù)包進(jìn)行排序的缺點(diǎn)，也就是說，當(dāng)報(bào)文發(fā)送之后，是無法得知其是否安全完整到達(dá)的。UDP用來支持那些需要在計(jì)算機(jī)之間傳輸數(shù)據(jù)的網(wǎng)絡(luò)應(yīng)用。包括網(wǎng)絡(luò)視頻會議系統(tǒng)在內(nèi)的眾多的客戶/服務(wù)器模式的網(wǎng)絡(luò)應(yīng)用都需要使用UDP協(xié)議。UDP協(xié)議從問世至今已經(jīng)被使用了很多年，雖然其最初的光彩已經(jīng)被一些類似協(xié)議所掩蓋，但是即使是在今天UDP仍然不失為一項(xiàng)非常實(shí)用和可行的網(wǎng)絡(luò)傳輸層協(xié)議。與所熟知的TCP（傳輸控制協(xié)議）協(xié)議一樣，UDP協(xié)議直接位于IP（網(wǎng)際協(xié)議）協(xié)議的頂層。根據(jù)OSI（開放系統(tǒng)互連）參考模型，UDP和TCP都屬于傳輸層協(xié)議。UDP協(xié)議的主要作用是將網(wǎng)絡(luò)數(shù)據(jù)流量壓

5、縮成數(shù)據(jù)包的形式。一個(gè)典型的數(shù)據(jù)包就是一個(gè)二進(jìn)制數(shù)據(jù)的傳輸單位。每一個(gè)數(shù)據(jù)包的前8個(gè)字節(jié)用來包含報(bào)頭信息，剩余字節(jié)則用來包含具體的傳輸數(shù)據(jù)UDP(特點(diǎn))l 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è)消息段。l 由于傳輸數(shù)據(jù)不建立連接，因此也就不需要維護(hù)連接狀態(tài)，包括收發(fā)狀態(tài)等，因此一臺服務(wù)機(jī)可同時(shí)向多個(gè)客戶機(jī)傳輸相同的消息。l UDP信息包的標(biāo)題很短

6、，只有8個(gè)字節(jié)，相對于TCP的20個(gè)字節(jié)信息包的額外開銷很小。吞吐量不受擁擠控制算法的調(diào)節(jié)，只受應(yīng)用軟件生成數(shù)據(jù)的速率、傳輸帶寬、源端和終端主機(jī)性能的限制。l UDP使用盡最大努力交付，即不保證可靠交付，因此主機(jī)不需要維持復(fù)雜的鏈接狀態(tài)表（這里面有許多參數(shù)）。l UDP是面向報(bào)文的。發(fā)送方的UDP對應(yīng)用程序交下來的報(bào)文，在添加首部后就向下交付給IP層。既不拆分，也不合并，而是保留這些報(bào)文的邊界，因此，應(yīng)用程序需要選擇合適的報(bào)文大小。UDP(使用條件)l 在選擇使用協(xié)議的時(shí)候，選擇UDP必須要謹(jǐn)慎。在網(wǎng)絡(luò)質(zhì)量令人不十分滿意的環(huán)境下，UDP協(xié)議數(shù)據(jù)包丟失會比較嚴(yán)重。但是由于UDP的特性：它不屬于連

7、接型協(xié)議，因而具有資源消耗小，處理速度快的優(yōu)點(diǎn)，所以通常音頻、視頻和普通數(shù)據(jù)在傳送時(shí)使用UDP較多，因?yàn)樗鼈兗词古紶杹G失一兩個(gè)數(shù)據(jù)包，也不會對接收結(jié)果產(chǎn)生太大影響。比如我們聊天用的ICQ和QQ就是使用的UDP協(xié)議。l 舉個(gè)例子校驗(yàn)l TCP校驗(yàn)和是一個(gè)端到端的校驗(yàn)和，由發(fā)送端計(jì)算，然后由接收端驗(yàn)證。其目的是為了發(fā)現(xiàn)TCP首部和數(shù)據(jù)在發(fā)送端到l 接收端之間發(fā)生的任何改動(dòng)。如果接收方檢測到校驗(yàn)和有差錯(cuò)，則TCP段會被直接丟棄。l TCP校驗(yàn)和覆蓋TCP首部和TCP數(shù)據(jù)，而IP首部中的校驗(yàn)和只覆蓋IP的首部，不覆蓋IP數(shù)據(jù)報(bào)中的任何數(shù)據(jù)。l TCP的校驗(yàn)和是必需的，而UDP的校驗(yàn)和是可選的。l TCP和UDP計(jì)算校驗(yàn)和時(shí)，都要加上一個(gè)12字節(jié)的偽首部校驗(yàn)UDP的檢驗(yàn)和所需要用到的所有信息，包括三個(gè)部分：1.UDP偽首部2.UDP首部3.UDP的數(shù)據(jù)部分校驗(yàn)l 首先解釋下偽首部的概念，偽首部包含IP首部一些字段。其目的是讓UDP兩次檢查數(shù)據(jù)是否已經(jīng)正確到達(dá)目的地，只是單純?yōu)榱俗鲂ｒ?yàn)用的。l 還有一個(gè)概念十分重要，那就是16位UDP總長度，請注意該長度不是報(bào)文的總長度，而只是UDP（包括UDP頭和數(shù)據(jù)部分）的總長度計(jì)算校驗(yàn)和checksum1. 把偽首部添加到UDP上；2. 計(jì)算初始時(shí)是需要將檢