報(bào)文段

報(bào)文段是指TCP/IP協(xié)議網(wǎng)絡(luò)傳輸過(guò)程中，起著路由導(dǎo)航作用

用以查詢各個(gè)網(wǎng)絡(luò)路由網(wǎng)段潜索，ip地址，交換協(xié)議等ip數(shù)據(jù)包

報(bào)文段充當(dāng)整個(gè)tcp/ip協(xié)議數(shù)據(jù)包的導(dǎo)航路由功能

報(bào)文在傳輸過(guò)程中會(huì)不斷的封裝成組聊记、包先改、幀來(lái)傳輸?shù)?/p>

傳輸協(xié)議

協(xié)議顧名思義，一種規(guī)定，約束

約定大于配置宾袜，在網(wǎng)絡(luò)傳輸中依然適用捻艳；網(wǎng)絡(luò)的傳輸流程是健壯的穩(wěn)定的，得益于基礎(chǔ)的協(xié)議構(gòu)成

簡(jiǎn)單來(lái)說(shuō)：A->B的傳輸數(shù)據(jù)庆猫，B能識(shí)別认轨，繁殖B->A的傳輸數(shù)據(jù)A也能識(shí)別，這就是協(xié)議

IP地址

"1.1.1.1": 為直接廣播地址月培，會(huì)向全網(wǎng)廣播UDP消息嘁字，但是一般會(huì)被路由器防火墻攔截

"255.255.255.255": 為受限廣播地址，會(huì)在局域網(wǎng)絡(luò)內(nèi)發(fā)送UDP消息

UDP

用戶數(shù)據(jù)報(bào)協(xié)議节视，基于報(bào)文的協(xié)議拳锚，而不是基于連接的協(xié)議

應(yīng)用場(chǎng)景：DNS TFTP SNMP

UDP包的最大長(zhǎng)度

1.png

16位-> 2字節(jié) 存儲(chǔ)長(zhǎng)度信息；2^16-1=65535寻行；自身協(xié)議占用：32+32位=64位=8字節(jié)

所以最大數(shù)據(jù)長(zhǎng)度：65535-8=65507 byte字節(jié)

UDP單播霍掺，廣播，多播

單播：點(diǎn)對(duì)點(diǎn)

廣播：給所有設(shè)備發(fā)送數(shù)據(jù)(例如：受限廣播地址拌蜘，255.255.255.255)

• C網(wǎng)廣播地址一般為：xxx.xxx.xxx.255（192.168.1.255）

多播(組播)：給一組發(fā)送數(shù)據(jù)

• D類(lèi)IP地址為多播預(yù)留

2.png

廣播地址運(yùn)算

IP杆烁；192.168.124.7

子網(wǎng)掩碼: 255.255.255.0

網(wǎng)絡(luò)地址: 192.168.124.0

廣播地址: 192.168.124.255

但是運(yùn)算結(jié)果不是絕對(duì)的，如下：

如果子網(wǎng)掩碼是:255.255.255.192-> 11111111.11111111.11111111.11000000

則可劃分網(wǎng)段就是最后的一個(gè)字節(jié)的1數(shù)據(jù)简卧，即2*2=4個(gè)

四個(gè)網(wǎng)段為:0-63 64-127 128-191 n 192-255

IP：192.168.124.7歸屬于第一個(gè)網(wǎng)段兔魂，所以廣播地址就是該網(wǎng)段的
最后一個(gè)即192.168.124.63 ,網(wǎng)絡(luò)地址(是該網(wǎng)段第一個(gè)地址)
仍是192.168.124.0

廣播通信問(wèn)題

3.png

如上圖，主機(jī)一位于第一個(gè)網(wǎng)段举娩，主機(jī)二位于第二個(gè)網(wǎng)段析校，所以二者無(wú)法通信

協(xié)議

什么是協(xié)議

從應(yīng)?的?度出發(fā)，協(xié)議可理解為“規(guī)則”铜涉，是數(shù)據(jù)傳輸和數(shù)據(jù)的解釋的規(guī)則智玻。

假設(shè)，A芙代、B雙?欲傳輸?件吊奢。規(guī)定：

• 第?次，傳輸?件名纹烹，接收?接收到?件名页滚，應(yīng)答OK給傳輸?；
• 第?次铺呵，發(fā)送?件的尺?裹驰，接收?接收到該數(shù)據(jù)再次應(yīng)答?個(gè)OK；
• 第三次陪蜻，傳輸?件內(nèi)容邦马。同樣，接收?接收數(shù)據(jù)完成后應(yīng)答OK表示?件內(nèi)容接收成功

由此，?論A滋将、B之間傳遞何種?件邻悬，都是通過(guò)三次數(shù)據(jù)傳輸來(lái)完成。A随闽、B之間形成了?個(gè)最簡(jiǎn)單的數(shù)據(jù)傳輸規(guī)則父丰。雙?都按此規(guī)則發(fā)送、接收數(shù)據(jù)掘宪。A蛾扇、B之間達(dá)成的這個(gè)相互遵守的規(guī)則即為協(xié)議。

這種僅在A魏滚、B之間被遵守的協(xié)議稱之為原始協(xié)議镀首。當(dāng)此協(xié)議被更多的?采?，不斷的增加鼠次、改進(jìn)更哄、維護(hù)、完善腥寇。最終形成?個(gè)穩(wěn)定的成翩、完整的?件傳輸協(xié)議，被?泛應(yīng)?于各種?件傳輸過(guò)程中赦役。該協(xié)議就成為?個(gè)標(biāo)準(zhǔn)協(xié)議麻敌。最早的ftp協(xié)議就是由此衍??來(lái)。

TCP協(xié)議注重?cái)?shù)據(jù)的傳輸掂摔。http協(xié)議著重于數(shù)據(jù)的解釋术羔。

典型協(xié)議

傳輸層 常?協(xié)議有TCP/UDP協(xié)議。
應(yīng)?層 常?的協(xié)議有HTTP協(xié)議乙漓，F(xiàn)TP協(xié)議聂示。
?絡(luò)層 常?協(xié)議有IP協(xié)議、ICMP協(xié)議簇秒、IGMP協(xié)議。
?絡(luò)接?層 常?協(xié)議有ARP協(xié)議秀鞭、RARP協(xié)議趋观。
TCP傳輸控制協(xié)議（Transmission Control Protocol）是?種?向連接的、可靠的锋边、基于字節(jié)流的
傳輸層通信協(xié)議皱坛。
UDP?戶數(shù)據(jù)報(bào)協(xié)議（User Datagram Protocol）是OSI參考模型中?種?連接的傳輸層協(xié)議，
提供?向事務(wù)的簡(jiǎn)單不可靠信息傳送服務(wù)豆巨。
HTTP超?本傳輸協(xié)議（Hyper Text Transfer Protocol）是互聯(lián)?上應(yīng)?最為?泛的?種?絡(luò)協(xié)
議剩辟。
FTP?件傳輸協(xié)議（File Transfer Protocol）
IP協(xié)議是因特?互聯(lián)協(xié)議（Internet Protocol）
ICMP協(xié)議是Internet控制報(bào)?協(xié)議（Internet Control Message Protocol）它是TCP/IP協(xié)議族的?個(gè)?協(xié)議，?于在IP主機(jī)、路由器之間傳遞控制消息贩猎。
IGMP協(xié)議是 Internet 組管理協(xié)議（Internet Group Management Protocol）熊户，是因特?協(xié)議家
族中的?個(gè)組播協(xié)議。該協(xié)議運(yùn)?在主機(jī)和組播路由器之間吭服。
ARP協(xié)議是正向地址解析協(xié)議（Address Resolution Protocol）嚷堡，通過(guò)已知的IP，尋找對(duì)應(yīng)主機(jī)
的MAC地址艇棕。
RARP是反向地址轉(zhuǎn)換協(xié)議蝌戒，通過(guò)MAC地址確定IP地址。

分層模型

• 物理層：

主要定義物理設(shè)備標(biāo)準(zhǔn)沼琉，如?線的接?類(lèi)型北苟、光纖的接?類(lèi)型、各種傳輸介質(zhì)的傳輸速率等打瘪。它的主要作?是傳輸?特流（就是由1友鼻、0轉(zhuǎn)化為電流強(qiáng)弱來(lái)進(jìn)?傳輸，到達(dá)?的地后再轉(zhuǎn)化為1瑟慈、0桃移，也就是我們常說(shuō)的數(shù)模轉(zhuǎn)換與模數(shù)轉(zhuǎn)換）。這?層的數(shù)據(jù)叫做?特葛碧。

• 數(shù)據(jù)鏈路層：

定義了如何讓格式化數(shù)據(jù)以幀為單位進(jìn)?傳輸借杰，以及如何讓控制對(duì)物理介質(zhì)的訪問(wèn)。這?層通常還提供錯(cuò)誤檢測(cè)和糾正进泼，以確保數(shù)據(jù)的可靠傳輸蔗衡。如：串?通信中使?到的115200、 8乳绕、N绞惦、1

• ?絡(luò)層：

在位于不同地理位置的?絡(luò)中的兩個(gè)主機(jī)系統(tǒng)之間提供連接和路徑選擇。Internet的發(fā)展使得從世界各站點(diǎn)訪問(wèn)信息的?戶數(shù)??增加洋措，??絡(luò)層正是管理這種連接的層济蝉。

• 傳輸層：

定義了?些傳輸數(shù)據(jù)的協(xié)議和端?號(hào)（WWW端?80等），如：TCP（傳輸控制協(xié)議菠发，傳輸效率低王滤，可靠性強(qiáng)，?于傳輸可靠性要求?滓鸠，數(shù)據(jù)量?的數(shù)據(jù)）雁乡，UDP（?戶數(shù)據(jù)報(bào)協(xié)議，與TCP特性恰恰相反糜俗，?于傳輸可靠性要求不?踱稍，數(shù)據(jù)量?的數(shù)據(jù)曲饱，如QQ聊天數(shù)據(jù)就是通過(guò)這種?式傳輸?shù)模Ｖ饕菍南聦咏邮盏臄?shù)據(jù)進(jìn)?分段和傳輸珠月，到達(dá)?的地址后再進(jìn)?重組扩淀。常常把這?層數(shù)據(jù)叫做段。

• 會(huì)話層：

通過(guò)傳輸層(端?號(hào)：傳輸端?與接收端?)建?數(shù)據(jù)傳輸?shù)耐非盼隆Ｖ饕谀愕南到y(tǒng)之間發(fā)起會(huì)話或者接受會(huì)話請(qǐng)求（設(shè)備之間需要互相認(rèn)識(shí)可以是IP也可以是MAC或者是主機(jī)名）引矩。

• 表示層：

可確保?個(gè)系統(tǒng)的應(yīng)?層所發(fā)送的信息可以被另?個(gè)系統(tǒng)的應(yīng)?層讀取。例如侵浸，PC程序與另?臺(tái)計(jì)算機(jī)進(jìn)?通信旺韭，其中?臺(tái)計(jì)算機(jī)使?擴(kuò)展???進(jìn)制交換碼(EBCDIC)，?另?臺(tái)則使?美國(guó)信息交換標(biāo)準(zhǔn)碼（ASCII）來(lái)表示相同的字符掏觉。如有必要区端，表示層會(huì)通過(guò)使??種通格式來(lái)實(shí)現(xiàn)多種數(shù)據(jù)格式之間的轉(zhuǎn)換。

• 應(yīng)?層

是最靠近?戶的OSI層澳腹。這?層為?戶的應(yīng)?程序（例如電?郵件织盼、?件傳輸和終端仿真）提供?絡(luò)服務(wù)。

1.png

下圖模擬一個(gè)數(shù)據(jù)發(fā)送到接收一層層封包和解包的過(guò)程

01網(wǎng)絡(luò)數(shù)據(jù)傳輸.png

通信過(guò)程

2.jpg

TCP/IP通信過(guò)程

上圖對(duì)應(yīng)兩臺(tái)計(jì)算機(jī)在同??段中的情況酱塔，如果兩臺(tái)計(jì)算機(jī)在不同的?段中沥邻，那么數(shù)據(jù)從?臺(tái)計(jì)算機(jī)到另?臺(tái)計(jì)算機(jī)傳輸過(guò)程中要經(jīng)過(guò)?個(gè)或多個(gè)路由器，如下圖所示：

3.jpg

跨路由通信

鏈路層有以太?羊娃、令牌環(huán)?等標(biāo)準(zhǔn)唐全，鏈路層負(fù)責(zé)?卡設(shè)備的驅(qū)動(dòng)、幀同步（即從?線上檢測(cè)到什么信號(hào)算作新幀的開(kāi)始）蕊玷、沖突檢測(cè)（如果檢測(cè)到?jīng)_突就?動(dòng)重發(fā)）邮利、數(shù)據(jù)差錯(cuò)校驗(yàn)等?作。交換機(jī)是?作在鏈路層的?絡(luò)設(shè)備垃帅，可以在不同的鏈路層?絡(luò)之間轉(zhuǎn)發(fā)數(shù)據(jù)幀（?如?兆以太?和百兆以太?之間延届、以太?和令牌環(huán)?之間），由于不同鏈路層的幀格式不同贸诚，交換機(jī)要將進(jìn)來(lái)的數(shù)據(jù)包拆掉鏈路層?部重新封裝之后再轉(zhuǎn)發(fā)方庭。

?絡(luò)層的IP協(xié)議是構(gòu)成Internet的基礎(chǔ)。Internet上的主機(jī)通過(guò)IP地址來(lái)標(biāo)識(shí)酱固，Inter-net上有?量路由器負(fù)責(zé)根據(jù)IP地址選擇合適的路徑轉(zhuǎn)發(fā)數(shù)據(jù)包二鳄，數(shù)據(jù)包從Internet上的源主機(jī)到?的主機(jī)往往要經(jīng)過(guò)?多個(gè)路由器。路由器是?作在第三層的?絡(luò)設(shè)備媒怯，同時(shí)兼有交換機(jī)的功能，可以在不同的鏈路層接?之間轉(zhuǎn)發(fā)數(shù)據(jù)包髓窜，因此路由器需要將進(jìn)來(lái)的數(shù)據(jù)包拆掉?絡(luò)層和鏈路層兩層?部并重新封裝扇苞。IP協(xié)議不保證傳輸?shù)目煽啃云鄣睿瑪?shù)據(jù)包在傳輸過(guò)程中可能丟失，可靠性可以在上層協(xié)議或應(yīng)?程序中提供?持鳖敷。

?絡(luò)層負(fù)責(zé)點(diǎn)到點(diǎn)（ptop脖苏，point-to-point）的傳輸（這?的“點(diǎn)”指主機(jī)或路由器），?傳輸層負(fù)責(zé)端到端（etoe定踱，end-to-end）的傳輸（這?的“端”指源主機(jī)和?的主機(jī)）棍潘。傳輸層可選擇TCP或UDP協(xié)議。

TCP是?種?向連接的崖媚、可靠的協(xié)議亦歉，有點(diǎn)像打電話，雙?拿起電話互通身份之后就建?了連接畅哑，然后說(shuō)話就?了肴楷，這邊說(shuō)的話那邊保證聽(tīng)得到，并且是按說(shuō)話的順序聽(tīng)到的荠呐，說(shuō)完話掛機(jī)斷開(kāi)連接赛蔫。也就是說(shuō)TCP傳輸?shù)碾p?需要?先建?連接，之后由TCP協(xié)議保證數(shù)據(jù)收發(fā)的可靠性泥张，丟失的數(shù)據(jù)包?動(dòng)重發(fā)呵恢，上層應(yīng)?程序收到的總是可靠的數(shù)據(jù)流，通訊之后關(guān)閉連接媚创。UDP是?連接的傳輸協(xié)議渗钉，不保證可靠性，有點(diǎn)像寄信筝野，信寫(xiě)好放到郵筒?晌姚，既不能保證信件在郵遞過(guò)程中不會(huì)丟失，也不能保證信件寄送順序歇竟。使?UDP協(xié)議的應(yīng)?程序需要??完成丟包重發(fā)挥唠、消息排序等?作。

?的主機(jī)收到數(shù)據(jù)包后焕议，如何經(jīng)過(guò)各層協(xié)議棧最后到達(dá)應(yīng)?程序呢戚绕？其過(guò)程如下圖所示：

4.jpg

以太?驅(qū)動(dòng)程序?先根據(jù)以太??部中的“上層協(xié)議”字段確定該數(shù)據(jù)幀的有效載荷（payload婿屹，指除去協(xié)議?部之外實(shí)際傳輸?shù)臄?shù)據(jù)）是IP、ARP還是RARP協(xié)議的數(shù)據(jù)報(bào)，然后交給相應(yīng)的協(xié)議處理劈猿。假如是IP數(shù)據(jù)報(bào)，IP協(xié)議再根據(jù)IP?部中的“上層協(xié)議”字段確定該數(shù)據(jù)報(bào)的有效載荷是TCP慌洪、
UDP只冻、ICMP還是IGMP，然后交給相應(yīng)的協(xié)議處理蝙寨。假如是TCP段或UDP段晒衩，TCP或UDP協(xié)議再根據(jù)TCP?部或UDP?部的“端?號(hào)”字段確定應(yīng)該將應(yīng)?層數(shù)據(jù)交給哪個(gè)?戶進(jìn)程嗤瞎。IP地址是標(biāo)識(shí)?絡(luò)中不同主機(jī)的地址，?端?號(hào)就是同?臺(tái)主機(jī)上標(biāo)識(shí)不同進(jìn)程的地址听系，IP地址和端?號(hào)合起來(lái)標(biāo)識(shí)?絡(luò)中唯?的進(jìn)程贝奇。

雖然IP、ARP和RARP數(shù)據(jù)報(bào)都需要以太?驅(qū)動(dòng)程序來(lái)封裝成幀靠胜，但是從功能上劃分掉瞳，ARP和RARP屬于鏈路層，IP屬于?絡(luò)層浪漠。雖然ICMP陕习、IGMP、TCP郑藏、UDP的數(shù)據(jù)都需要IP協(xié)議來(lái)封裝成數(shù)據(jù)報(bào)衡查，但是從功能上劃分，ICMP必盖、IGMP與IP同屬于?絡(luò)層拌牲，TCP和UDP屬于傳輸層。

02以太網(wǎng)幀格式.png

協(xié)議格式

數(shù)據(jù)包封裝

傳輸層及其以下的機(jī)制由內(nèi)核提供歌粥，應(yīng)?層由?戶進(jìn)程提供（后?將介紹如何使?socket API編寫(xiě)應(yīng)?程序）塌忽，應(yīng)?程序?qū)νㄓ崝?shù)據(jù)的含義進(jìn)?解釋?zhuān)?傳輸層及其以下處理通訊的細(xì)節(jié)，將數(shù)據(jù)從?臺(tái)計(jì)算機(jī)通過(guò)?定的路徑發(fā)送到另?臺(tái)計(jì)算機(jī)失驶。應(yīng)?層數(shù)據(jù)通過(guò)協(xié)議棧發(fā)到?絡(luò)上時(shí)土居，每層協(xié)議都要加上?個(gè)數(shù)據(jù)?部（header），稱為封裝（Encapsulation）嬉探，如下圖所示：

5.jpg

TCP/IP數(shù)據(jù)包封裝

不同的協(xié)議層對(duì)數(shù)據(jù)包有不同的稱謂擦耀，在傳輸層叫做段（segment），在?絡(luò)層叫做數(shù)據(jù)報(bào)（datagram）涩堤，在鏈路層叫做幀（frame）眷蜓。數(shù)據(jù)封裝成幀后發(fā)到傳輸介質(zhì)上，到達(dá)?的主機(jī)后每層協(xié)議再剝掉相應(yīng)的?部胎围，最后將應(yīng)?層數(shù)據(jù)交給應(yīng)?程序處理吁系。

以太網(wǎng)幀格式

6.jpg

以太?幀格式

其中的源地址和?的地址是指?卡的硬件地址（也叫MAC地址），?度是48位白魂，是在?卡出?時(shí)固化的汽纤。可在shell中使?ifconfig命令查看福荸，“HWaddr 00:15:F2:14:9E:3F”部分就是硬件地址蕴坪。協(xié)議字段有三種值，分別對(duì)應(yīng)IP敬锐、ARP辞嗡、RARP捆等。幀尾是CRC校驗(yàn)碼。以太?幀中的數(shù)據(jù)?度規(guī)定最?46字節(jié)续室，最?1500字節(jié)，ARP和RARP數(shù)據(jù)包的?度不夠46字節(jié)谒养，要在后?補(bǔ)填充位挺狰。最?值1500稱為以太?的最?傳輸單元（MTU），不同的?絡(luò)類(lèi)型有不同的MTU买窟，如果?個(gè)數(shù)據(jù)包從以太?路由到撥號(hào)鏈路上丰泊，數(shù)據(jù)包?度?于撥號(hào)鏈路的MTU，則需要對(duì)數(shù)據(jù)包進(jìn)?分?（fragmentation）始绍。ifconfig命令輸出中也有“MTU:1500”瞳购。注意，MTU這個(gè)概念指數(shù)據(jù)幀中有效載荷的最??度亏推，不包括幀頭長(zhǎng)度学赛。

ARP數(shù)據(jù)報(bào)格式

在?絡(luò)通訊時(shí)，源主機(jī)的應(yīng)?程序知道?的主機(jī)的IP地址和端?號(hào)吞杭，卻不知道?的主機(jī)的硬件地址盏浇，?數(shù)據(jù)包?先是被?卡接收到再去處理上層協(xié)議的，如果接收到的數(shù)據(jù)包的硬件地址與本機(jī)不符芽狗，則直接丟棄绢掰。因此在通訊前必須獲得?的主機(jī)的硬件地址。ARP協(xié)議就起到這個(gè)作?童擎。源主機(jī)發(fā)出ARP請(qǐng)求滴劲，詢問(wèn)“IP地址是192.168.0.1的主機(jī)的硬件地址是多少”，并將這個(gè)請(qǐng)求?播到本地?段（以太?幀?部的硬件地址填FF:FF:FF:FF:FF:FF表示?播）顾复，?的主機(jī)接收到?播的ARP請(qǐng)求班挖，發(fā)現(xiàn)其中的IP地址與本機(jī)相符，則發(fā)送?個(gè)ARP應(yīng)答數(shù)據(jù)包給源主機(jī)捕透，將??的硬件地址填寫(xiě)在應(yīng)答包中聪姿。

每臺(tái)主機(jī)都維護(hù)?個(gè)ARP緩存表，可以?arp-a命令查看乙嘀。緩存表中的表項(xiàng)有過(guò)期時(shí)間（?般為20分鐘）末购，如果20分鐘內(nèi)沒(méi)有再次使?某個(gè)表項(xiàng)，則該表項(xiàng)失效虎谢，下次還要發(fā)ARP請(qǐng)求來(lái)獲得?的主機(jī)的硬件地址盟榴。想?想，為什么表項(xiàng)要有過(guò)期時(shí)間?不是?直有效婴噩？

7.jpg

ARP數(shù)據(jù)報(bào)格式

源MAC地址擎场、?的MAC地址在以太??部和ARP請(qǐng)求中各出現(xiàn)?次羽德，對(duì)于鏈路層為以太?的情況是多余的，但如果鏈路層是其它類(lèi)型的?絡(luò)則有可能是必要的迅办。硬件類(lèi)型指鏈路層?絡(luò)類(lèi)型宅静，1為以太?，協(xié)議類(lèi)型指要轉(zhuǎn)換的地址類(lèi)型站欺，0x0800為IP地址姨夹，后?兩個(gè)地址?度對(duì)于以太?地址和IP地址分別為6和4（字節(jié)），op字段為1表示ARP請(qǐng)求矾策，op字段為2表示ARP應(yīng)答磷账。

看?個(gè)具體的例?。

請(qǐng)求幀如下（為了清晰在每?的前?加了字節(jié)計(jì)數(shù)贾虽，每?16個(gè)字節(jié)）：以太??部（14字節(jié)）

0000: ff ff ff ff ff ff 00 05 5d 61 58 a8 08 06

ARP幀（28字節(jié)）

0000: 00 01
0010: 08 00 06 04 00 01 00 05 5d 61 58 a8 c0 a8 00 37
0020: 00 00 00 00 00 00 c0 a8 00 02

填充位（18字節(jié)）

0020: 00 77 31 d2 50 10
0030: fd 78 41 d3 00 00 00 00 00 00 00 00

以太??部：?的主機(jī)采??播地址逃糟，源主機(jī)的MAC地址是00:05:5d:61:58:a8，上層協(xié)議類(lèi)型0x0806表示ARP蓬豁。

ARP幀：硬件類(lèi)型0x0001表示以太?绰咽，協(xié)議類(lèi)型0x0800表示IP協(xié)議，硬件地址（MAC地址）?度為6庆尘，協(xié)議地址（IP地址）?度為4剃诅，op為0x0001表示請(qǐng)求?的主機(jī)的MAC地址，源主機(jī)MAC地址為00:05:5d:61:58:a8驶忌，源主機(jī)IP地址為c0 a8 00 37（192.168.0.55）矛辕，?的主機(jī)MAC地址全0待填寫(xiě)，?的主機(jī)IP地址為c0 a8 00 02（192.168.0.2）付魔。

由于以太?規(guī)定最?數(shù)據(jù)?度為46字節(jié)聊品，ARP幀?度只有28字節(jié)，因此有18字節(jié)填充位几苍，填充位的內(nèi)容沒(méi)有定義翻屈，與具體實(shí)現(xiàn)相關(guān)。

應(yīng)答幀如下：

以太??部

0000: 00 05 5d 61 58 a8 00 05 5d a1 b8 40 08 06

ARP幀

0000: 00 01
0010: 08 00 06 04 00 02 00 05 5d a1 b8 40 c0 a8 00 02
0020: 00 05 5d 61 58 a8 c0 a8 00 37

填充位

0020: 00 77 31 d2 50 10
0030: fd 78 41 d3 00 00 00 00 00 00 00 00

以太??部：?的主機(jī)的MAC地址是00:05:5d:61:58:a8妻坝，源主機(jī)的MAC地址是
00:05:5d:a1:b8:40伸眶，上層協(xié)議類(lèi)型0x0806表示ARP。

ARP幀：硬件類(lèi)型0x0001表示以太?刽宪，協(xié)議類(lèi)型0x0800表示IP協(xié)議厘贼，硬件地址（MAC地址）?度為6，協(xié)議地址（IP地址）?度為4圣拄，op為0x0002表示應(yīng)答嘴秸，源主機(jī)MAC地址為00:05:5d:a1:b8:40，源主機(jī)IP地址為c0 a8 00 02（192.168.0.2），?的主機(jī)MAC地址為00:05:5d:61:58:a8凭疮，?的主機(jī)IP地址為c0 a8 00 37（192.168.0.55)

IP段格式

8.jpg

IP數(shù)據(jù)報(bào)格式

IP數(shù)據(jù)報(bào)的?部?度和數(shù)據(jù)?度都是可變?的，但總是4字節(jié)的整數(shù)倍串述。

對(duì)于IPv4执解，4位版本字段是4。4位?部?度的數(shù)值是以4字節(jié)為單位的纲酗，最?值為5材鹦，也就是說(shuō)?部?度最?是4x5=20字節(jié)，也就是不帶任何選項(xiàng)的IP?部耕姊，4位能表示的最?值是15，也就是說(shuō)?部?度最?是60字節(jié)栅葡。

8位TOS字段有3個(gè)位?來(lái)指定IP數(shù)據(jù)報(bào)的優(yōu)先級(jí)（?前已經(jīng)廢棄不?）茉兰，還有4個(gè)位表示可選的服務(wù)類(lèi)型（最?延遲、最?吐量欣簇、最?可靠性规脸、最?成本），還有?個(gè)位總是0熊咽∧迹總?度是整個(gè)數(shù)據(jù)報(bào)（包括IP?部和IP層payload）的字節(jié)數(shù)。每傳?個(gè)IP數(shù)據(jù)報(bào)横殴，16位的標(biāo)識(shí)加1被因，可?于分?和重新組裝數(shù)據(jù)報(bào)。3位標(biāo)志和13位?偏移?于分?衫仑。

TTL（Time to live)是這樣?的：源主機(jī)為數(shù)據(jù)包設(shè)定?個(gè)?存時(shí)間梨与，?如64，每過(guò)?個(gè)路由器就把該值減1文狱，如果減到0就表示路由已經(jīng)太?了仍然找不到?的主機(jī)的?絡(luò)粥鞋，就丟棄該包，因此這個(gè)?存時(shí)間的單位不是秒瞄崇，?是跳（hop）呻粹。

協(xié)議字段指示上層協(xié)議是TCP、UDP苏研、ICMP還是IGMP等浊。然后是校驗(yàn)和，只校驗(yàn)IP?部楣富，數(shù)據(jù)的校驗(yàn)由更?層協(xié)議負(fù)責(zé)凿掂。IPv4的IP地址?度為32位。

03TCP.IP協(xié)議.png

UDP數(shù)據(jù)報(bào)格式

9.jpg

UDP數(shù)據(jù)段

下?分析?幀基于UDP的TFTP協(xié)議幀庄萎。

以太??部

0000: 00 05 5d 67 d0 b1 00 05 5d 61 58 a8 08 00

IP?部

0000: 45 00
0010: 00 53 93 25 00 00 80 11 25 ec c0 a8 00 37 c0 a8
0020: 00 01

UDP?部

0020： 05 d4 00 45 00 3f ac 40

TFTP協(xié)議

0020: 00 01 'c'':''\''q'
0030: 'w''e''r''q''.''q''w''e'00 'n''e''t''a''s''c''i'
0040: 'i'00 'b''l''k''s''i''z''e'00 '5''1''2'00 't''i'
0050: 'm''e''o''u''t'00 '1''0'00 't''s''i''z''e'00 '0'

以太??部：源MAC地址是00:05:5d:61:58:a8踪少，?的MAC地址是00:05:5d:67:d0:b1，上層協(xié)議類(lèi)型0x0800表示IP糠涛。

IP?部：每?個(gè)字節(jié)0x45包含4位版本號(hào)和4位?部?度援奢，版本號(hào)為4，即IPv4忍捡，?部?度為5集漾，說(shuō)明IP?部不帶有選項(xiàng)字段。服務(wù)類(lèi)型為0砸脊，沒(méi)有使?服務(wù)具篇。16位總?度字段（包括IP?部和IP層payload的?度）為0x0053，即83字節(jié)凌埂，加上以太??部14字節(jié)可知整個(gè)幀?度是97字節(jié)驱显。IP報(bào)標(biāo)識(shí)是0x9325，標(biāo)志字段和?偏移字段設(shè)置為0x0000瞳抓，就是DF=0允許分?埃疫，MF=0此數(shù)據(jù)報(bào)沒(méi)有更多分?，沒(méi)有分?偏移孩哑。TTL是0x80栓霜，也就是128。上層協(xié)議0x11表示UDP協(xié)議横蜒。IP?部校驗(yàn)和為0x25ec胳蛮，源主機(jī)IP是c0 a8 00 37（192.168.0.55），?的主機(jī)IP是c0 a8 00
01（192.168.0.1）愁铺。

UDP?部：源端?號(hào)0x05d4（1492）是客戶端的端?號(hào)鹰霍，?的端?號(hào)0x0045（69）是TFTP服務(wù)的well-known端?號(hào)。UDP報(bào)?度為0x003f茵乱，即63字節(jié)茂洒，包括UDP?部和UDP層pay-load的?度。UDP?部和UDP層payload的校驗(yàn)和為0xac40瓶竭。

TFTP是基于?本的協(xié)議督勺，各字段之間?字節(jié)0分隔，開(kāi)頭的00 01表示請(qǐng)求讀取?個(gè)?件斤贰，接下來(lái)的各字段是：

c:\qwerq.qwe
netascii
blksize 512
timeout 10
tsize 0

?般的?絡(luò)通信都是像TFTP協(xié)議這樣智哀，通信的雙?分別是客戶端和服務(wù)器，客戶端主動(dòng)發(fā)起請(qǐng)求（上?的例?就是客戶端發(fā)起的請(qǐng)求幀）荧恍，?服務(wù)器被動(dòng)地等待瓷叫、接收和應(yīng)答請(qǐng)求屯吊。客戶端的IP地址和端?號(hào)唯?標(biāo)識(shí)了該主機(jī)上的TFTP客戶端進(jìn)程摹菠，服務(wù)器的IP地址和端?號(hào)唯?標(biāo)識(shí)了該主機(jī)上的TFTP服務(wù)進(jìn)程盒卸，由于客戶端是主動(dòng)發(fā)起請(qǐng)求的??，它必須知道服務(wù)器的IP地址和TFTP服務(wù)進(jìn)程的端?號(hào)次氨，所以蔽介，?些常?的?絡(luò)協(xié)議有默認(rèn)的服務(wù)器端?，例如HTTP服務(wù)默認(rèn)TCP協(xié)議的80端?煮寡，F(xiàn)TP服務(wù)默認(rèn)TCP協(xié)議的21端?虹蓄，TFTP服務(wù)默認(rèn)UDP協(xié)議的69端?（如上例所示）。
在使?客戶端程序時(shí)幸撕，必須指定服務(wù)器的主機(jī)名或IP地址薇组，如果不明確指定端?號(hào)則采?默認(rèn)端?萎津，請(qǐng)讀者查閱ftp坑律、tftp等程序的manpage了解如何指定端?號(hào)。/etc/services中列出了所有well-known的服務(wù)端?和對(duì)應(yīng)的傳輸層協(xié)議杈笔，這是由IANA（Internet Assigned NumbersAuthority）規(guī)定的挑童，其中有些服務(wù)既可以?TCP也可以?UDP，為了清晰跃须，IANA規(guī)定這樣的服務(wù)采?相同的TCP或UDP默認(rèn)端?號(hào)站叼，?另外?些TCP和UDP的相同端?號(hào)卻對(duì)應(yīng)不同的服務(wù)。很多服務(wù)有well-known的端?號(hào)菇民，然?客戶端程序的端?號(hào)卻不必是well-known的尽楔，往往是每次運(yùn)?客戶端程序時(shí)由系統(tǒng)?動(dòng)分配?個(gè)空閑的端?號(hào)，?完就釋放掉第练，稱為ephemeral的端?號(hào)阔馋，想想這是為什么？

前?提過(guò)娇掏，UDP協(xié)議不?向連接呕寝，也不保證傳輸?shù)目煽啃裕纾?/p>

發(fā)送端的UDP協(xié)議層只管把應(yīng)?層傳來(lái)的數(shù)據(jù)封裝成段交給IP協(xié)議層就算完成任務(wù)了婴梧，如果因?yàn)?絡(luò)故障該段?法發(fā)到對(duì)?下梢，UDP協(xié)議層也不會(huì)給應(yīng)?層返回任何錯(cuò)誤信息。

接收端的UDP協(xié)議層只管把收到的數(shù)據(jù)根據(jù)端?號(hào)交給相應(yīng)的應(yīng)?程序就算完成任務(wù)了塞蹭，如果發(fā)送端發(fā)來(lái)多個(gè)數(shù)據(jù)包并且在?絡(luò)上經(jīng)過(guò)不同的路由孽江，到達(dá)接收端時(shí)順序已經(jīng)錯(cuò)亂了，UDP協(xié)議層也不保證按發(fā)送時(shí)的順序交給應(yīng)?層番电。

通常接收端的UDP協(xié)議層將收到的數(shù)據(jù)放在?個(gè)固定??的緩沖區(qū)中等待應(yīng)?程序來(lái)提取和處理岗屏，如果應(yīng)?程序提取和處理的速度很慢，?發(fā)送端發(fā)送的速度很快，就會(huì)丟失數(shù)據(jù)包这刷，UDP協(xié)議層并不報(bào)告這種錯(cuò)誤婉烟。

因此，使?UDP協(xié)議的應(yīng)?程序必須考慮到這些可能的問(wèn)題并實(shí)現(xiàn)適當(dāng)?shù)慕鉀Q?案崭歧，例如等待應(yīng)答隅很、超時(shí)重發(fā)、為數(shù)據(jù)包編號(hào)率碾、流量控制等叔营。?般使?UDP協(xié)議的應(yīng)?程序?qū)崿F(xiàn)都?較簡(jiǎn)單，只是發(fā)送?些對(duì)可靠性要求不?的消息所宰，?不發(fā)送?量的數(shù)據(jù)绒尊。例如，基于UDP的TFTP協(xié)議?般只?于傳送??件（所以才叫trivial的ftp）仔粥，?基于TCP的FTP協(xié)議適?于 各種?件的傳輸婴谱。TCP協(xié)議?是如何??向連接的服務(wù)來(lái)代替應(yīng)?程序解決傳輸?shù)目煽啃詥?wèn)題呢。

TCP數(shù)據(jù)報(bào)格式

10.jpg

TCP數(shù)據(jù)段

與UDP協(xié)議?樣也有源端?號(hào)和?的端?號(hào)躯泰，通訊的雙?由IP地址和端?號(hào)標(biāo)識(shí)谭羔。32位序號(hào)、32位確認(rèn)序號(hào)麦向、窗???稍后詳細(xì)解釋瘟裸。4位?部?度和IP協(xié)議頭類(lèi)似，表示TCP協(xié)議頭的?度诵竭，以4字節(jié)為單位话告，因此TCP協(xié)議頭最?可以是4x15=60字節(jié)，如果沒(méi)有選項(xiàng)字段卵慰，TCP協(xié)議頭最短20字節(jié)沙郭。URG、ACK裳朋、PSH病线、RST、SYN鲤嫡、FIN是六個(gè)控制位氧苍，本節(jié)稍后將解釋SYN、ACK泛范、FIN让虐、RST四個(gè)位，其它位的解釋從略罢荡。16位檢驗(yàn)和將TCP協(xié)議頭和數(shù)據(jù)都計(jì)算在內(nèi)赡突。緊急指針和各種選項(xiàng)的解釋從略对扶。

TCP協(xié)議

TCP通信時(shí)序

下圖是?次TCP通訊的時(shí)序圖。TCP連接建?斷開(kāi)惭缰。包含三次握?和四次握?浪南。

11.jpg

TCP通訊時(shí)序

在這個(gè)例?中，?先客戶端主動(dòng)發(fā)起連接漱受、發(fā)送請(qǐng)求络凿，然后服務(wù)器端響應(yīng)請(qǐng)求，然后客戶端主動(dòng)關(guān)閉連接昂羡。兩條豎線表示通訊的兩端絮记，從上到下表示時(shí)間的先后順序，注意虐先，數(shù)據(jù)從?端傳到?絡(luò)的另?端也需要時(shí)間怨愤，所以圖中的箭頭都是斜的。雙?發(fā)送的段按時(shí)間順序編號(hào)為1-10蛹批，各段中的主要信息在箭頭上標(biāo)出撰洗，例如段2的箭頭上標(biāo)著SYN, 8000(0), ACK1001, ，表示該段中的SYN位置1腐芍，32位序號(hào)是8000差导，該段不攜帶有效載荷（數(shù)據(jù)字節(jié)數(shù)為0），ACK位置1猪勇，32位確認(rèn)序號(hào)是1001柿汛，帶有?個(gè)mss（Maximum Segment Size，最?報(bào)??度）選項(xiàng)值為1024埠对。

建?連接（三次握?）的過(guò)程：

• 客戶端發(fā)送?個(gè)帶SYN標(biāo)志的TCP報(bào)?到服務(wù)器。這是三次握?過(guò)程中的段1

客戶端發(fā)出段1裁替，SYN位表示連接請(qǐng)求项玛。序號(hào)是1000，這個(gè)序號(hào)在?絡(luò)通訊中?作臨時(shí)的地址弱判，每發(fā)?個(gè)數(shù)據(jù)字節(jié)襟沮，這個(gè)序號(hào)要加1，這樣在接收端可以根據(jù)序號(hào)排出數(shù)據(jù)包的正確順序昌腰，也可以發(fā)現(xiàn)丟包的情況开伏，另外，規(guī)定SYN位和FIN位也要占?個(gè)序號(hào)遭商，這次雖然沒(méi)發(fā)數(shù)據(jù)固灵，但是由于發(fā)了SYN位，因此下次再發(fā)送應(yīng)該?序號(hào)1001劫流。mss表示最?段尺?巫玻，如果?個(gè)段太?丛忆，封裝成幀后超過(guò)了鏈路層的最?幀?度，就必須在IP層分?仍秤，為了避免這種情況熄诡，客戶端聲明??的最?段尺?，建議服務(wù)器端發(fā)來(lái)的段不要超過(guò)這個(gè)?度诗力。

• 服務(wù)器端回應(yīng)客戶端凰浮，是三次握?中的第2個(gè)報(bào)?段，同時(shí)帶ACK標(biāo)志和SYN標(biāo)志苇本。它表示對(duì)剛才客戶端SYN的回應(yīng)袜茧；同時(shí)?發(fā)送SYN給客戶端，詢問(wèn)客戶端是否準(zhǔn)備好進(jìn)?數(shù)據(jù)通訊圈澈。

服務(wù)器發(fā)出段2惫周，也帶有SYN位，同時(shí)置ACK位表示確認(rèn)康栈，確認(rèn)序號(hào)是1001递递，表示“我接收到序號(hào)1000及其以前所有的段，請(qǐng)你下次發(fā)送序號(hào)為1001的段”啥么，也就是應(yīng)答了客戶端的連接請(qǐng)求登舞，同時(shí)也給客戶端發(fā)出?個(gè)連接請(qǐng)求，同時(shí)聲明最?尺?為1024悬荣。

• 客戶必須再次回應(yīng)服務(wù)器端?個(gè)ACK報(bào)?菠秒，這是報(bào)?段3。

客戶端發(fā)出段3氯迂，對(duì)服務(wù)器的連接請(qǐng)求進(jìn)?應(yīng)答践叠，確認(rèn)序號(hào)是8001。在這個(gè)過(guò)程中嚼蚀，客戶端和服務(wù)器分別給對(duì)?發(fā)了連接請(qǐng)求禁灼，也應(yīng)答了對(duì)?的連接請(qǐng)求，其中服務(wù)器的請(qǐng)求和應(yīng)答在?個(gè)段中
發(fā)出轿曙，因此?共有三個(gè)段?于建?連接弄捕，稱為“三?握?（three-way-handshake）”。在建?連接的同時(shí)导帝，雙?協(xié)商了?些信息守谓，例如雙?發(fā)送序號(hào)的初始值、最?段尺?等您单。

在TCP通訊中斋荞，如果??收到另??發(fā)來(lái)的段，讀出其中的?的端?號(hào)虐秦，發(fā)現(xiàn)本機(jī)并沒(méi)有任何進(jìn)程使?這個(gè)端?譬猫，就會(huì)應(yīng)答?個(gè)包含RST位的段給另??讯檐。例如，服務(wù)器并沒(méi)有任何進(jìn)程使?8080端?染服，我們卻?telnet客戶端去連接它别洪，服務(wù)器收到客戶端發(fā)來(lái)的SYN段就會(huì)應(yīng)答?個(gè)RST段，客戶端的telnet程序收到RST段后報(bào)告錯(cuò)誤Connection refused：

$ telnet 192.168.0.200 8080
Trying 192.168.0.200...
telnet: Unable to connect to remote host: Connection refused

數(shù)據(jù)傳輸?shù)倪^(guò)程：

• 客戶端發(fā)出段4柳刮，包含從序號(hào)1001開(kāi)始的20個(gè)字節(jié)數(shù)據(jù)挖垛。
• 服務(wù)器發(fā)出段5，確認(rèn)序號(hào)為1021秉颗，對(duì)序號(hào)為1001-1020的數(shù)據(jù)表示確認(rèn)收到痢毒，同時(shí)請(qǐng)求發(fā)送序號(hào)1021開(kāi)始的數(shù)據(jù)，服務(wù)器在應(yīng)答的同時(shí)也向客戶端發(fā)送從序號(hào)8001開(kāi)始的10個(gè)字節(jié)數(shù)據(jù)蚕甥，這稱為piggyback哪替。
• 客戶端發(fā)出段6，對(duì)服務(wù)器發(fā)來(lái)的序號(hào)為8001-8010的數(shù)據(jù)表示確認(rèn)收到菇怀，請(qǐng)求發(fā)送序號(hào)8011開(kāi)始的數(shù)據(jù)凭舶。

在數(shù)據(jù)傳輸過(guò)程中，ACK和確認(rèn)序號(hào)是?常重要的爱沟，應(yīng)?程序交給TCP協(xié)議發(fā)送的數(shù)據(jù)會(huì)暫存在TCP層的發(fā)送緩沖區(qū)中帅霜，發(fā)出數(shù)據(jù)包給對(duì)?之后，只有收到對(duì)?應(yīng)答的ACK段才知道該數(shù)據(jù)包確實(shí)發(fā)到了對(duì)?呼伸，可以從發(fā)送緩沖區(qū)中釋放掉了身冀，如果因?yàn)?絡(luò)故障丟失了數(shù)據(jù)包或者丟失了對(duì)?發(fā)回的ACK段，經(jīng)過(guò)等待超時(shí)后TCP協(xié)議?動(dòng)將發(fā)送緩沖區(qū)中的數(shù)據(jù)包重發(fā)括享。

關(guān)閉連接（四次握?）的過(guò)程：

由于TCP連接是全雙?的搂根，因此每個(gè)?向都必須單獨(dú)進(jìn)?關(guān)閉。這原則是當(dāng)??完成它的數(shù)據(jù)發(fā)送任務(wù)后就能發(fā)送?個(gè)FIN來(lái)終?這個(gè)?向的連接铃辖。收到?個(gè)FIN只意味著這??向上沒(méi)有數(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)閉。

• 客戶端發(fā)出段7沐悦，F(xiàn)IN位表示關(guān)閉連接的請(qǐng)求成洗。
• 服務(wù)器發(fā)出段8，應(yīng)答客戶端的關(guān)閉連接請(qǐng)求藏否。
• 服務(wù)器發(fā)出段9瓶殃，其中也包含F(xiàn)IN位，向客戶端發(fā)送關(guān)閉連接請(qǐng)求副签。
• 客戶端發(fā)出段10遥椿，應(yīng)答服務(wù)器的關(guān)閉連接請(qǐng)求.

建?連接的過(guò)程是三?握?基矮，?關(guān)閉連接通常需要4個(gè)段，服務(wù)器的應(yīng)答和關(guān)閉連接請(qǐng)求通常不合并在?個(gè)段中冠场，因?yàn)橛羞B接半關(guān)閉的情況家浇，這種情況下客戶端關(guān)閉連接之后就不能再發(fā)送數(shù)據(jù)給服務(wù)器了，但是服務(wù)器還可以發(fā)送數(shù)據(jù)給客戶端碴裙，直到服務(wù)器也關(guān)閉連接為?钢悲。

滑動(dòng)窗? (TCP流量控制)

介紹UDP時(shí)描述了這樣的問(wèn)題：如果發(fā)送端發(fā)送的速度較快，接收端接收到數(shù)據(jù)后處理的速度較慢舔株，?接收緩沖區(qū)的??是固定的莺琳，就會(huì)丟失數(shù)據(jù)。TCP協(xié)議通過(guò)“滑動(dòng)窗?（SlidingWindow）”機(jī)制解決這?問(wèn)題载慈〔训龋看下圖的通訊過(guò)程

12.jpg

滑動(dòng)窗?

• 發(fā)送端發(fā)起連接，聲明最?段尺?是1460办铡，初始序號(hào)是0辞做，窗???是4K，表示“我的接收緩沖區(qū)還有4K字節(jié)空閑料扰，你發(fā)的數(shù)據(jù)不要超過(guò)4K”凭豪。接收端應(yīng)答連接請(qǐng)求，聲明最?段尺?是1024晒杈，初始序號(hào)是8000嫂伞，窗???是6K。發(fā)送端應(yīng)答拯钻，三?握?結(jié)束帖努。
• 發(fā)送端發(fā)出段4-9，每個(gè)段帶1K的數(shù)據(jù)粪般，發(fā)送端根據(jù)窗???知道接收端的緩沖區(qū)滿了拼余，因此停?發(fā)送數(shù)據(jù)。
• 接收端的應(yīng)?程序提?2K數(shù)據(jù)亩歹，接收緩沖區(qū)?有了2K空閑匙监，接收端發(fā)出段10，在應(yīng)答已收到6K數(shù)據(jù)的同時(shí)聲明窗???為2K小作。
• 接收端的應(yīng)?程序?提?2K數(shù)據(jù)亭姥，接收緩沖區(qū)有4K空閑，接收端發(fā)出段11顾稀，重新聲明窗???為4K达罗。
• 發(fā)送端發(fā)出段12-13，每個(gè)段帶2K數(shù)據(jù)静秆，段13同時(shí)還包含F(xiàn)IN位粮揉。
• 接收端應(yīng)答接收到的2K數(shù)據(jù)（6145-8192）巡李，再加上FIN位占?個(gè)序號(hào)8193，因此應(yīng)答序號(hào)是8194扶认，連接處于半關(guān)閉狀態(tài)侨拦，接收端同時(shí)聲明窗???為2K。
• 接收端的應(yīng)?程序提?2K數(shù)據(jù)蝠引，接收端重新聲明窗???為4K阳谍。
• 接收端的應(yīng)?程序提?剩下的2K數(shù)據(jù)，接收緩沖區(qū)全空螃概，接收端重新聲明窗???為6K矫夯。
• 接收端的應(yīng)?程序在提?全部數(shù)據(jù)后，決定關(guān)閉連接吊洼，發(fā)出段17包含F(xiàn)IN位训貌，發(fā)送端應(yīng)答，連接完全關(guān)閉冒窍。

上圖在接收端???塊表示1K數(shù)據(jù)佑菩，實(shí)?的??塊表示已接收到的數(shù)據(jù)渠概，虛線框表示接收緩沖區(qū)，因此套在虛線框中的空???塊表示窗???，從圖中可以看出溯香，隨著應(yīng)?程序提?數(shù)據(jù)舵盈，虛線框是向右滑動(dòng)的诅迷，因此稱為滑動(dòng)窗?翁锡。

從這個(gè)例?還可以看出，發(fā)送端是?K?K地發(fā)送數(shù)據(jù)附帽，?接收端的應(yīng)?程序可以兩K兩K地提?數(shù)據(jù)埠戳，當(dāng)然也有可能?次提?3K或6K數(shù)據(jù)，或者?次只提??個(gè)字節(jié)的數(shù)據(jù)蕉扮。也就是說(shuō)整胃，應(yīng)?程序所看到的數(shù)據(jù)是?個(gè)整體，或說(shuō)是?個(gè)流（stream）喳钟，在底層通訊中這些數(shù)據(jù)可能被拆成很多數(shù)據(jù)包來(lái)發(fā)送屁使，但是?個(gè)數(shù)據(jù)包有多少字節(jié)對(duì)應(yīng)?程序是不可?的，因此TCP協(xié)議是?向流的協(xié)議奔则。?UDP是?向消息的協(xié)議蛮寂，每個(gè)UDP段都是?條消息，應(yīng)?程序必須以消息為單位提取數(shù)據(jù)应狱，不能?次提取任意字節(jié)的數(shù)據(jù)共郭，這?點(diǎn)和TCP是很不同的祠丝。

TCP狀態(tài)轉(zhuǎn)換

這個(gè)圖N多?都知道疾呻，它排除和定位?絡(luò)或系統(tǒng)故障時(shí)?有幫助除嘹，但是怎樣牢牢地將這張圖刻在腦中呢？那么你就?定要對(duì)這張圖的每?個(gè)狀態(tài)岸蜗，及轉(zhuǎn)換的過(guò)程有深刻的認(rèn)識(shí)尉咕，不能只停留在?知半解之中。下?對(duì)這張圖的11種狀態(tài)詳細(xì)解析?下璃岳，以便加強(qiáng)記憶年缎！不過(guò)在這之前，先回顧?下TCP建?連接的三次握?過(guò)程铃慷，以及 關(guān)閉連接的四次握?過(guò)程单芜。

13.jpg

CLOSED：表示初始狀態(tài)。

LISTEN：該狀態(tài)表示服務(wù)器端的某個(gè)SOCKET處于監(jiān)聽(tīng)狀態(tài)犁柜，可以接受連接洲鸠。

SYN_SENT：這個(gè)狀態(tài)與SYN_RCVD遙相呼應(yīng)，當(dāng)客戶端SOCKET執(zhí)?CONNECT連接時(shí)馋缅，它?先發(fā)送SYN報(bào)?扒腕，隨即進(jìn)?到了SYN_SENT狀態(tài)，并等待服務(wù)端的發(fā)送三次握?中的第2個(gè)報(bào)?萤悴。SYN_SENT狀態(tài)表示客戶端已發(fā)送SYN報(bào)?瘾腰。

SYN_RCVD: 該狀態(tài)表示接收到SYN報(bào)?，在正常情況下覆履，這個(gè)狀態(tài)是服務(wù)器端的SOCKET在建?TCP連接時(shí)的三次握?會(huì)話過(guò)程中的?個(gè)中間狀態(tài)蹋盆，很短暫。此種狀態(tài)時(shí)内狗，當(dāng)收到客戶端的ACK報(bào)?后怪嫌，會(huì)進(jìn)?到ESTABLISHED狀態(tài)。

ESTABLISHED：表示連接已經(jīng)建?柳沙。

FIN_WAIT_1: FIN_WAIT_1和FIN_WAIT_2狀態(tài)的真正含義都是表示等待對(duì)?的FIN報(bào)?岩灭。區(qū)別是：FIN_WAIT_1狀態(tài)是當(dāng)socket在ESTABLISHED狀態(tài)時(shí)，想主動(dòng)關(guān)閉連接赂鲤，向?qū)?發(fā)送了FIN報(bào)?噪径，此時(shí)該socket進(jìn)?到FIN_WAIT_1狀態(tài)。

FIN_WAIT_2狀態(tài)是當(dāng)對(duì)?回應(yīng)ACK后数初，該socket進(jìn)?到FIN_WAIT_2狀態(tài)找爱，正常情況下，對(duì)?應(yīng)?上回應(yīng)ACK報(bào)?泡孩，所以FIN_WAIT_1狀態(tài)?般較難?到车摄，?FIN_WAIT_2狀態(tài)可?netstat看到。

FIN_WAIT_2：主動(dòng)關(guān)閉鏈接的??，發(fā)出FIN收到ACK以后進(jìn)?該狀態(tài)吮播。稱之為半連接或半關(guān)閉狀態(tài)变屁。該狀態(tài)下的socket只能接收數(shù)據(jù)，不能發(fā)意狠。

TIME_WAIT: 表示收到了對(duì)?的FIN報(bào)?粟关，并發(fā)送出了ACK報(bào)?，等2MSL后即可回到CLOSED可?狀態(tài)环戈。如果FIN_WAIT_1狀態(tài)下闷板，收到對(duì)?同時(shí)帶FIN標(biāo)志和ACK標(biāo)志的報(bào)?時(shí)，可以直接進(jìn)?到TIME_WAIT狀態(tài)院塞，??須經(jīng)過(guò)FIN_WAIT_2狀態(tài)遮晚。

CLOSING: 這種狀態(tài)較特殊，屬于?種較罕?的狀態(tài)拦止。正常情況下鹏漆，當(dāng)你發(fā)送FIN報(bào)?后，按理來(lái)說(shuō)是應(yīng)該先收到（或同時(shí)收到）對(duì)?的ACK報(bào)?创泄，再收到對(duì)?的FIN報(bào)?艺玲。但是CLOSING狀態(tài)表示你發(fā)送FIN報(bào)?后，并沒(méi)有收到對(duì)?的ACK報(bào)?鞠抑，反?卻也收到了對(duì)?的FIN報(bào)?饭聚。什么情況下會(huì)出現(xiàn)此種情況呢？如果雙??乎在同時(shí)close?個(gè)SOCKET的話搁拙，那么就出現(xiàn)了雙?同時(shí)發(fā)送FIN報(bào)?的情況秒梳，也即會(huì)出現(xiàn)CLOSING狀態(tài)，表示雙?都正在關(guān)閉SOCKET連接箕速。

CLOSE_WAIT: 此種狀態(tài)表示在等待關(guān)閉酪碘。當(dāng)對(duì)?關(guān)閉?個(gè)SOCKET后發(fā)送FIN報(bào)?給??，系統(tǒng)會(huì)回應(yīng)?個(gè)ACK報(bào)?給對(duì)?盐茎，此時(shí)則進(jìn)?到CLOSE_WAIT狀態(tài)兴垦。接下來(lái)呢，察看是否還有數(shù)據(jù)發(fā)送給對(duì)?字柠，如果沒(méi)有可以close這個(gè)SOCKET探越，發(fā)送FIN報(bào)?給對(duì)?，即關(guān)閉連接窑业。所以在CLOSE_WAIT狀態(tài)下钦幔，需要關(guān)閉連接。

LAST_ACK: 該狀態(tài)是被動(dòng)關(guān)閉??在發(fā)送FIN報(bào)?后常柄，最后等待對(duì)?的ACK報(bào)?鲤氢。當(dāng)收到ACK報(bào)?后搀擂，即可以進(jìn)?到CLOSED可?狀態(tài)。

半關(guān)閉

當(dāng)TCP鏈接中A發(fā)送FIN請(qǐng)求關(guān)閉卷玉，B端回應(yīng)ACK后（A端進(jìn)?FIN_WAIT_2狀態(tài)）哥倔，B沒(méi)有?即發(fā)送FIN給A時(shí)，A?處在半鏈接狀態(tài)揍庄，此時(shí)A可以接收B發(fā)送的數(shù)據(jù)，但是A已不能再向B發(fā)送數(shù)據(jù)东抹。

2MSL

2MSL (Maximum Segment Lifetime) TIME_WAIT狀態(tài)的存在有兩個(gè)理由：

1. 讓4次握?關(guān)閉流程更加可靠蚂子；4次握?的最后?個(gè)ACK是是由主動(dòng)關(guān)閉?發(fā)送出去的，若這個(gè)ACK丟失缭黔，被動(dòng)關(guān)閉?會(huì)再次發(fā)?個(gè)FIN過(guò)來(lái)食茎。若主動(dòng)關(guān)閉?能夠保持?個(gè)2MSL的TIME_WAIT狀態(tài)，則有更?的機(jī)會(huì)讓丟失的ACK被再次發(fā)送出去馏谨。
2. 防?lost duplicate對(duì)后續(xù)新建正常鏈接的傳輸造成破壞别渔。lost uplicate在實(shí)際的?絡(luò)中?常常?，經(jīng)常是由于路由器產(chǎn)?故障惧互，路徑?法收斂哎媚，導(dǎo)致?個(gè)packet在路由器A，B喊儡，C之間做類(lèi)似死循環(huán)的跳轉(zhuǎn)拨与。IP頭部有個(gè)TTL，限制了?個(gè)包在?絡(luò)中的最?跳數(shù)艾猜，因此這個(gè)包有兩種命運(yùn)买喧，要么最后TTL變?yōu)?，在?絡(luò)中消失匆赃；要么TTL在變?yōu)?之前路由器路徑收斂淤毛，它憑借剩余的TTL跳數(shù)終于到達(dá)?的地。但?乘懔可惜的是TCP通過(guò)超時(shí)重傳機(jī)制在早些時(shí)候發(fā)送了?個(gè)跟它?模?樣的
   包低淡，并先于它達(dá)到了?的地，因此它的命運(yùn)也就注定被TCP協(xié)議棧拋棄瞬项。

另外?個(gè)概念叫做incarnation connection查牌，指跟上次的socket pair?摸?樣的新連接，叫做incarnation of previous connection滥壕。lost uplicate加上incarnation connection纸颜，則會(huì)對(duì)我們的
傳輸造成致命的錯(cuò)誤。

TCP是流式的绎橘，所有包到達(dá)的順序是不?致的胁孙，依靠序列號(hào)由TCP協(xié)議棧做順序的拼接唠倦；假設(shè)?個(gè)incarnation connection這時(shí)收到的seq=1000, 來(lái)了?個(gè)lost duplicate為seq=1000，len=1000,則TCP認(rèn)為這個(gè)lost duplicate合法涮较，并存放?了receive buffer稠鼻，導(dǎo)致傳輸出現(xiàn)錯(cuò)誤。通過(guò)?個(gè)
2MSL TIME_WAIT狀態(tài)狂票，確保所有的lost duplicate都會(huì)消失掉候齿，避免對(duì)新連接造成錯(cuò)誤。

該狀態(tài)為什么設(shè)計(jì)在主動(dòng)關(guān)閉這??：

（1）發(fā)最后ACK的是主動(dòng)關(guān)閉??闺属。

（2）只要有??保持TIME_WAIT狀態(tài)慌盯，就能起到避免incarnation connection在2MSL內(nèi)的重新建?，不需要兩?都有掂器。
如何正確對(duì)待2MSL TIME_WAIT?RFC要求socket pair在處于TIME_WAIT時(shí)亚皂，不能再起?個(gè)incarnation connection。但絕?部分
TCP實(shí)現(xiàn)国瓮，強(qiáng)加了更為嚴(yán)格的限制灭必。在2MSL等待期間，socket中使?的本地端?在默認(rèn)情況下不能再被使?乃摹。

若A 10.234.5.5 : 1234和B 10.55.55.60 : 6666建?了連接禁漓，A主動(dòng)關(guān)閉，那么在A端只要port為
1234孵睬，?論對(duì)?的port和ip是什么璃饱，都不允許再起服務(wù)。這甚??RFC限制更為嚴(yán)格肪康，RFC僅僅是要求socket pair不?致荚恶，?實(shí)現(xiàn)當(dāng)中只要這個(gè)port處于TIME_WAIT，就不允許起連接磷支。這個(gè)限制
對(duì)主動(dòng)打開(kāi)?來(lái)說(shuō)是?所謂的谒撼，因?yàn)?般?的是臨時(shí)端?；但對(duì)于被動(dòng)打開(kāi)?雾狈，?般是server廓潜，就悲劇了，因?yàn)閟erver?般是熟知端?善榛。?如http辩蛋，?般端?是80，不可能允許這個(gè)服務(wù)在2MSL內(nèi)不能起來(lái)移盆。
解決?案是給服務(wù)器的socket設(shè)置SO_REUSEADDR選項(xiàng)悼院，這樣的話就算熟知端?處于TIME_WAIT狀態(tài)，在這個(gè)端?上依舊可以將服務(wù)啟動(dòng)咒循。當(dāng)然据途，雖然有了SO_REUSEADDR選項(xiàng)绞愚，但sockt pair這個(gè)限制依舊存在。?如上?的例?颖医，A通過(guò)SO_REUSEADDR選項(xiàng)依舊在1234端?上起了監(jiān)聽(tīng)位衩，但這時(shí)我們?nèi)羰菑腂通過(guò)6666端?去連它，TCP協(xié)議會(huì)告訴我們連接失敗熔萧，原因?yàn)锳ddress already in use.
RFC 793中規(guī)定MSL為2分鐘糖驴，實(shí)際應(yīng)?中常?的是30秒，1分鐘和2分鐘等佛致。
RFC (Request For Comments)贮缕，是?系列以編號(hào)排定的?件。收集了有關(guān)因特?相關(guān)資訊晌杰，以及UNIX和因特?社群的軟件?件。

粘包拆包發(fā)生的原因

產(chǎn)生原因主要有這3種：滑動(dòng)窗口筷弦、MSS/MTU限制肋演、Nagle算法

1. 滑動(dòng)窗口
   TCP流量控制主要使用滑動(dòng)窗口協(xié)議，滑動(dòng)窗口是接受數(shù)據(jù)端使用的窗口大小烂琴，用來(lái)告訴發(fā)送端接收端的緩存大小爹殊，以此可以控制發(fā)送端發(fā)送數(shù)據(jù)的大小，從而達(dá)到流量

控制的目的奸绷。這個(gè)窗口大小就是我們一次傳輸幾個(gè)數(shù)據(jù)梗夸。對(duì)所有數(shù)據(jù)幀按順序賦予編號(hào)，發(fā)送方在發(fā)送過(guò)程中始終保持著一個(gè)發(fā)送窗口号醉，只有落在發(fā)送窗口內(nèi)的幀才允許被發(fā)送反症；

同時(shí)接收方也維持著一個(gè)接收窗口，只有落在接收窗口內(nèi)的幀才允許接收畔派。這樣通過(guò)調(diào)整發(fā)送方窗口和接收方窗口的大小可以實(shí)現(xiàn)流量控制铅碍。

現(xiàn)在來(lái)看一下滑動(dòng)窗口是如何造成粘包、拆包的线椰？

粘包：假設(shè)發(fā)送方的每256 bytes表示一個(gè)完整的報(bào)文胞谈，接收方由于數(shù)據(jù)處理不及時(shí)，這256個(gè)字節(jié)的數(shù)據(jù)都會(huì)被緩存到SO_RCVBUF(接收緩存區(qū)）中憨愉。如果接收方的SO_RCVBUF中緩存了多個(gè)報(bào)文烦绳，那么對(duì)于接收方而言，這就是粘包配紫。

拆包：考慮另外一種情況径密，假設(shè)接收方的窗口只剩了128，意味著發(fā)送方最多還可以發(fā)送128字節(jié)躺孝，而由于發(fā)送方的數(shù)據(jù)大小是256字節(jié)睹晒，因此只能發(fā)送前128字節(jié)趟庄，等到接收方ack后，才能發(fā)送剩余字節(jié)伪很。這就造成了拆包戚啥。

2. MSS和MTU分片
   MSS: 是Maximum Segement Size縮寫(xiě)，表示TCP報(bào)文中data部分的最大長(zhǎng)度锉试，是TCP協(xié)議在OSI五層網(wǎng)絡(luò)模型中傳輸層對(duì)一次可以發(fā)送的最大數(shù)據(jù)的限制猫十。
   MTU: 最大傳輸單元是Maxitum Transmission Unit的簡(jiǎn)寫(xiě)，是OSI五層網(wǎng)絡(luò)模型中鏈路層(datalink layer)對(duì)一次可以發(fā)送的最大數(shù)據(jù)的限制呆盖。
   當(dāng)需要傳輸?shù)臄?shù)據(jù)大于MSS或者M(jìn)TU時(shí)拖云，數(shù)據(jù)會(huì)被拆分成多個(gè)包進(jìn)行傳輸。由于MSS是根據(jù)MTU計(jì)算出來(lái)的应又，因此當(dāng)發(fā)送的數(shù)據(jù)滿足MSS時(shí)宙项，必然滿足MTU。

MTU是以太網(wǎng)傳輸數(shù)據(jù)方面的限制株扛，每個(gè)以太網(wǎng)幀都有最小的大小64bytes最大不能超過(guò)1518bytes尤筐。刨去以太網(wǎng)幀的幀頭 （DMAC目的MAC地址48bit=6Bytes+SMAC源MAC地址48bit=6Bytes+Type域2bytes）14Bytes和幀尾 CRC校驗(yàn)部分4Bytes（這個(gè)部分有時(shí)候大家也把它叫做FCS），那么剩下承載上層協(xié)議的地方也就是Data域最大就只能有1500Bytes這個(gè)值 我們就把它稱之為MTU洞就。
由于MTU限制了一次最多可以發(fā)送1500個(gè)字節(jié)盆繁，而TCP協(xié)議在發(fā)送DATA時(shí)，還會(huì)加上額外的TCP Header和Ip Header旬蟋，因此刨去這兩個(gè)部分油昂，就是TCP協(xié)議一次可以發(fā)送的實(shí)際應(yīng)用數(shù)據(jù)的最大大小，也就是MSS倾贰。

  MSS長(zhǎng)度=MTU長(zhǎng)度-IP Header-TCP Header

TCP Header的長(zhǎng)度是20字節(jié)冕碟，IPv4中IP Header長(zhǎng)度是20字節(jié)，IPV6中IP Header長(zhǎng)度是40字節(jié)匆浙，因此：在IPV4中鸣哀，以太網(wǎng)MSS可以達(dá)到1460byte；在IPV6中吞彤，以太網(wǎng)MSS可以達(dá)到1440byte我衬。
需要注意的是MSS表示的一次可以發(fā)送的DATA的最大長(zhǎng)度，而不是DATA的真實(shí)長(zhǎng)度饰恕。發(fā)送方發(fā)送數(shù)據(jù)時(shí)挠羔，當(dāng)SO_SNDBUF中的數(shù)據(jù)量大于MSS時(shí)，操作系統(tǒng)會(huì)將數(shù)據(jù)進(jìn)行拆分埋嵌，使得每一部分都小于MSS城榛，這就是拆包秸滴，然后每一部分都加上TCP Header比搭，構(gòu)成多個(gè)完整的TCP報(bào)文進(jìn)行發(fā)送，當(dāng)然經(jīng)過(guò)網(wǎng)絡(luò)層和數(shù)據(jù)鏈路層的時(shí)候合是，還會(huì)分別加上相應(yīng)的內(nèi)容。

需要注意: 默認(rèn)情況下锭环，與外部通信的網(wǎng)卡的MTU大小是1500個(gè)字節(jié)聪全。而本地回環(huán)地址的MTU大小為65535，這是因?yàn)楸镜販y(cè)試時(shí)數(shù)據(jù)不需要走網(wǎng)卡辅辩，所以不受到1500的限制难礼。

3、 Nagle算法
TCP/IP協(xié)議中玫锋，無(wú)論發(fā)送多少數(shù)據(jù)蛾茉，總是要在數(shù)據(jù)(DATA)前面加上協(xié)議頭(TCP Header+IP Header)，同時(shí)撩鹿，對(duì)方接收到數(shù)據(jù)谦炬，也需要發(fā)送ACK表示確認(rèn)。

即使從鍵盤(pán)輸入的一個(gè)字符节沦，占用一個(gè)字節(jié)键思，可能在傳輸上造成41字節(jié)的包，其中包括1字節(jié)的有用信息和40字節(jié)的首部數(shù)據(jù)散劫。這種情況轉(zhuǎn)變成了4000%的消耗稚机，這樣的情況對(duì)于重負(fù)載的網(wǎng)絡(luò)來(lái)是無(wú)法接受的幕帆。

為了盡可能的利用網(wǎng)絡(luò)帶寬获搏，TCP總是希望盡可能的發(fā)送足夠大的數(shù)據(jù)。（一個(gè)連接會(huì)設(shè)置MSS參數(shù)失乾，因此常熙，TCP/IP希望每次都能夠以MSS尺寸的數(shù)據(jù)塊來(lái)發(fā)送數(shù)據(jù)）。

Nagle算法就是為了盡可能發(fā)送大塊數(shù)據(jù)碱茁，避免網(wǎng)絡(luò)中充斥著許多小數(shù)據(jù)塊裸卫。

Nagle算法的基本定義是任意時(shí)刻，最多只能有一個(gè)未被確認(rèn)的小段纽竣。 所謂“小段”墓贿，指的是小于MSS尺寸的數(shù)據(jù)塊，所謂“未被確認(rèn)”蜓氨，是指一個(gè)數(shù)據(jù)塊發(fā)送出去后聋袋，沒(méi)有收到對(duì)方發(fā)送的ACK確認(rèn)該數(shù)據(jù)已收到。
Nagle算法的規(guī)則：

  1）如果SO_SNDBUF(發(fā)送緩沖區(qū)）中的數(shù)據(jù)長(zhǎng)度達(dá)到MSS穴吹，則允許發(fā)送幽勒；

  2）如果該SO_SNDBUF中含有FIN，表示請(qǐng)求關(guān)閉連接港令，則先將SO_SNDBUF中的剩余數(shù)據(jù)發(fā)送啥容，再關(guān)閉锈颗；
  3）設(shè)置了TCP_NODELAY=true選項(xiàng)，則允許發(fā)送咪惠。TCP_NODELAY是取消TCP的確認(rèn)延遲機(jī)制击吱，相當(dāng)于禁用了Nagle 算法。

  4）未設(shè)置TCP_CORK選項(xiàng)時(shí)硝逢，若所有發(fā)出去的小數(shù)據(jù)包（包長(zhǎng)度小于MSS）均被確認(rèn)姨拥，則允許發(fā)送;

  5）上述條件都未滿足，但發(fā)生了超時(shí)（一般為200ms）渠鸽，則立即發(fā)送叫乌。

總結(jié)：UDP無(wú)粘包拆遷現(xiàn)象，最多會(huì)出現(xiàn)丟包問(wèn)題徽缚，因?yàn)槭遣豢煽客ㄐ欧绞剑?Nagle的算法通常會(huì)在TCP程序里添加兩行代碼憨奸，在未確認(rèn)數(shù)據(jù)發(fā)送的時(shí)候讓發(fā)送器把數(shù)據(jù)送到緩存里。任何數(shù)據(jù)隨后繼續(xù)直到得到明顯的數(shù)據(jù)確認(rèn)或者直到攢到了一定數(shù)量的數(shù)據(jù)了再發(fā)包凿试。降低網(wǎng)絡(luò)負(fù)載