第一章概述

1.互聯(lián)網(wǎng)交換中心

互聯(lián)網(wǎng)交換中心(IntemetExchangePoint,IX)是為促迸互聯(lián)網(wǎng)骨干網(wǎng)的網(wǎng)間互聯(lián)和公平競爭而設(shè)置的運營商間進行數(shù)據(jù)網(wǎng)

際交換的機構(gòu)是為互聯(lián)網(wǎng)業(yè)者提供空間進行網(wǎng)絡(luò)互連、交換流量和資源的服務(wù)場所，互聯(lián)網(wǎng)業(yè)者可以在這里利用機架或場地、放

置管理自己的網(wǎng)絡(luò)設(shè)笛.方便地進行彼此間網(wǎng)絡(luò)互聯(lián),經(jīng)營業(yè)者也可以選擇史經(jīng)濟、高效的接入方式。

2.互聯(lián)網(wǎng)結(jié)構(gòu)網(wǎng)絡(luò)核心：互聯(lián)大量的異構(gòu)網(wǎng)絡(luò)

互聯(lián)網(wǎng)結(jié)構(gòu)核心設(shè)備：路由器

■網(wǎng)絡(luò)邊緣■由相互連接的路由器構(gòu)成的網(wǎng)狀

■運行TCP/IP協(xié)議和應(yīng)用的端系

網(wǎng)(Mesh)

統(tǒng)，如手機、云服務(wù)器等，統(tǒng)

稱為主機■路由器之間通過物理網(wǎng)絡(luò)相互連

■網(wǎng)絡(luò)核心接，如以太網(wǎng)、光纖主干網(wǎng)等

■由大量互聯(lián)的路由器構(gòu)成(可

以暫且忽略連接的具體形式)路由器的主要功能

■路由器運行1P協(xié)議和路由協(xié)議■執(zhí)行路由協(xié)議和算法，尋找到目

■接入網(wǎng)絡(luò)

的地的最佳路徑

■端系統(tǒng)通過有線網(wǎng)絡(luò)或無線網(wǎng)

絡(luò)連接到邊緣路由器■根據(jù)目的地址進行報文分組轉(zhuǎn)發(fā)

報文分組轉(zhuǎn)發(fā)：將來自一個物理網(wǎng)絡(luò)的報文分組轉(zhuǎn)發(fā)到下一個物理網(wǎng)絡(luò)(或來自于一個路由

器分組轉(zhuǎn)發(fā)到下一個路由器)

存儲-轉(zhuǎn)發(fā)式交換：路由器對到達的報文分組進行緩存，只有整個報文分組完全到達且一個

物理網(wǎng)絡(luò)鏈路空閑，才能被轉(zhuǎn)發(fā)出去

3.

網(wǎng)絡(luò)核心：報文分組交換網(wǎng)絡(luò)核心：報文分組交換

B

網(wǎng)絡(luò)核心：傳輸時延

■報文長度外單位?位(M)-

■負路長度人冷位“米”

?W輸遑率R：牛歸F"秒”

■也播時空所。巴電電波在介質(zhì)上伐播的時間，朝位一杪”

我中C為電磁波W播速懂**???

■傳輸時間“MNSPi發(fā)送K度為啪報文所用的時何

IKANiP-P/K,大中R為傳輸遑率

■逑魏時Utotmcy,發(fā)送端開始傳送第一付到接收瑞接收到最H一仲所

用的時間,在單基踏上計算方法為：

統(tǒng)計多路復(fù)用增益=

2C/RLatency=PKOP?TRANSP

4.統(tǒng)計多路復(fù)用：網(wǎng)絡(luò)流量具有很強的突發(fā)性，即不平穩(wěn)每個獨立的流的峰值可能出現(xiàn)在

不同時間；結(jié)論：流越多，網(wǎng)絡(luò)平均流量越平滑

5.為什么不直接發(fā)送報文(message),而使用報文分組(packet)：將報文分成報文段傳輸可以

降低端端時延；可以避免某條鏈路或路由器緩存被一個農(nóng)文長時間占用

問題：當(dāng)報文分組到達時，如果出口鏈路忙，報文分組需要在路由器緩存中排隊等待，會引

入排隊時延。在給定鏈路長度和傳輸速率的情況下，只有排隊時延是變化量排隊時延對網(wǎng)絡(luò)

性能會產(chǎn)生較大的影響(擁塞控制)

實際的端端時延：Latency='(TRANS?+PROP,+QD

6.

應(yīng)用層

主機A主機B

表示層應(yīng)用層

庾用房應(yīng)用展

會話又IETF定義Z

時等層通信,執(zhí)行相關(guān)訕議

傳輸層傳輸層溫y

路由器路由器傳■層

網(wǎng)絡(luò)層網(wǎng)絡(luò)層網(wǎng)絡(luò)層巴網(wǎng)絡(luò)層網(wǎng)絡(luò)層網(wǎng)絡(luò)層

數(shù)據(jù)選路層各種組織定義

接口層接口層接口層接口層接口層接n層接口層

如、

物理層IEEE3GPP

t____T1IL[

OSI參考模型TCP/IP體系結(jié)構(gòu)接口層地常包拈8(京11路層和物理層

7.

8.FTP服務(wù)器訪問實例：應(yīng)用編程接U(API”傳輸層(TCP”網(wǎng)絡(luò)層(IP)?>接口層(Ethernet)->

網(wǎng)絡(luò)層(IP)

9.分組交換:大家一起發(fā)，有時需要排隊，電路交換：頻分時分復(fù)用，提前給各個用戶分配

好資源

10.平均吞吐量：收F比特用T秒，平均吞吐量F/Tbps

服務(wù)器到主機之間有n條鏈路,傳輸速率分別是Rl-Rn,吞吐量min{Rl,…}

第二章應(yīng)用層協(xié)議及網(wǎng)絡(luò)編程

1.進程標(biāo)識符：包括IP地址和端口號

為了向www.的Web服務(wù)器發(fā)送消息,

Web瀏覽器需要使用的進程標(biāo)識符

?IP地址：3

?端口號：80

2.應(yīng)用對傳輸層要求(TCP/UDP)

常用應(yīng)用對傳輸層的要求互聯(lián)網(wǎng)傳輸層提供的服務(wù)

rrOiA

ICFMJtiUDP服齊?

應(yīng)用致?lián)r庭客戶與服務(wù)器'不可蠢,拗贏贏收建

文件傳蛤否并性否?面向連接：

電r郵件否彈性否建立連接.—?不能提供：連接建,X、可靠

Web文科可容忍彈性否?可■傳9：可保證傳遞數(shù)據(jù)無期錨性,流嘛控制、抑里控制、

實時在視頻可容忍ft5jj:5kbps-1Mbps是時延和帶寬保證

?流■控制：發(fā)送故據(jù)不全如過接收

視蝴10kbpa5Mbps端的容納容量h:子寫Ey口

可艘存在視頻可容忍同上是

?M富控制：提供擁息解決方案?一產(chǎn)］

交互游戲可容忍高于幾kbps是

即時消?&否彈性是或可.?不能提供：時延和帶寬保證

互聯(lián)網(wǎng)應(yīng)用：常用應(yīng)用使用的傳輸層服務(wù)

應(yīng)用應(yīng)用層的議借榆反砂議

電廣郵件SMTP[RFC2821]TCP

Web限務(wù)HTTP[RFC2616]TCP

文件傳輸FTP(RFC9591TCP

流媒體HTTPTCPorUDP

網(wǎng)絡(luò)電話RTP[RFC1889]典型為UDP

SIP、專有協(xié)議

3.網(wǎng)絡(luò)編程

計算機中整數(shù)如何存儲：小端：低位放內(nèi)存低端，高位放內(nèi)存高端；大端：與小端相反；不

同的CPU使用的種類不同，x86用小端，網(wǎng)絡(luò)傳輸用大端，此時如果傳來的數(shù)據(jù)按照字節(jié)序

存儲但想使用網(wǎng)絡(luò)序(按數(shù)字使用)，需要進行處理

4.域名系統(tǒng)：DNS協(xié)議運行在UDP之上

（1）域名到葉節(jié)點才能分配給機器

DNS域名解析

優(yōu)點，nf以支N大螳蝴.快速曠M?小JS要中CW

DNS域名體系點支Ei均11但分名字交向的授權(quán)實現(xiàn)0集中式管

，字找地始的我附可以通過分布射式哄現(xiàn)■域名解析：名字到地址映射（通過名字查地址）

?分布式，層級的服務(wù)涔出雙.辦網(wǎng)或現(xiàn)制析

>有效性?大多數(shù)解析可以在本地完成.一部分會產(chǎn)生互聯(lián)同流量

?可喜代，通過冗余診置,遵免航點失效

■客戶-服務(wù);8模式

?域名展務(wù)笈：

-保杼名字到地址映射美篌（數(shù)據(jù)咻）

-接收客廣解請求.并給出響應(yīng)

?域名單析器（客戶蛾）.

-請友域名皖析的N戶進程

■層級命名、逐級授權(quán)、多級管理

一名L1成為互負網(wǎng)的?復(fù)葦電迎殖

Mtascc.fuinkAi.cdu.cii-向域名服務(wù)器發(fā)起X析請求.并等待堀務(wù)81的哨戰(zhàn)

D、S服務(wù)器組織

*<n<f

(tunUictftA.cn)

■附臺域名服務(wù)用包含一個或多個區(qū)域的信息

?父,就已知千％點的地址

DNS域名解析：分為反復(fù)解析和遞歸解析?，服務(wù)器兩種都支持，反復(fù)解析使用較多，遞歸解

析對上行服務(wù)器壓力較大（2遞歸，1遞歸加反復(fù)/迭代〕

（2）DNS域名服務(wù)器緩存：服務(wù)器學(xué)習(xí)到某個名字和地址的映射關(guān)系時，便進行緩存；基

于授權(quán)服務(wù)器中的TTL值設(shè)置超時時間，緩存的映射關(guān)系經(jīng)過一定時間會超時；TLD服務(wù)器

（頂級域名服務(wù)器）通常會被本地域名服務(wù)器緩存，可以有效減少根域名服務(wù)器的訪問頻度

DNS域名服務(wù)器緩存（續(xù)）

■服務(wù)器使用緩存的映射關(guān)系響應(yīng)客戶端的請求

?標(biāo)記為業(yè)授權(quán)1nonauthoritative1映射

?給出茯取映射的服務(wù)器的域名和1P地址

■客戶機接收服務(wù)器響應(yīng)

?映時有可能過時

?如果注重效率，客戶端接受傳授權(quán)響應(yīng)

?如果注水座確性,客戶機可以再聯(lián)系授權(quán)服務(wù)器,驗證映射是否

仍有效14.

（3）主機緩存：在啟動時從本地域名服務(wù)器下載名字-地址映射數(shù)據(jù)庫；定期獲取新的映射;

緩存最近用過的名字和地址映射

（4）DNS資源記錄？？？

資源記錄結(jié)構(gòu)

A名字（name）

?TTL（TimeToLive）：有效時間，通常為86400杪（24小時）

?類型（Type）：SOA、NS、A,AAAA、PTR、CNAME、MX

?類（Class）s例如，IN類

?值（Sduc）

DNS資源記錄：示例

csAii.nl.86400INSOAMarbo?(serial,refresh,retry.cKpig

csA-u.nl.、§6400INTXT“AUfiwcrsW

cs.vu.nl..笆*,6400INMXizqAycr.cs.vu.nl.

cx.vu.nl.W?400INMX2yvu.nl.

11F

flMcs.vunQ86400INHINFOSunUnix

flits.es.vu.nl.86400INA12

niu.oA-u.nl.86400INMX1nits.cAii.nl.

nite.cxAii.nl.*64(10INMX2zcphycr.cs.vu.nl.

flits.gvu.nl.86400INMX3top.cs.%ii.nl.

wuv.cs.vu.nl.86400INCNAMEtop.cs.vu.nl.

ftp.cs.vv.nl.86400INCNAMEzcphycr.cs.vu.nl.

/1T^hyrrINA

INHINFOSunUnix

TTL是該記錄的生存時間，它決定了資源記錄應(yīng)當(dāng)從緩存中刪除的時間。在下面給出

的記錄例子中，我們忽略掉TTL字段。Name和Value的值取決于Type：

?如果Type二A,則Name是主機名，Value是該主機名對應(yīng)的IP地址。因此，一條

類型為A的資源記錄提供了標(biāo)準(zhǔn)的主機名到IP地址的映射。例如(idayl.

bar.foo.com,145.37.93.126,A)就是一條類型A記錄。

?如果Type=NS,則Name是個域(如foo.com),而Value是個知道如何獲得該域

中主機IP地址的權(quán)威DNS服務(wù)器的主機名。這個記錄用于沿著查詢鏈來路由DNS

查詢。例如(,,NS)就是一條類型為NS的記錄。

?如果Typc=CNAME,則Value是別名為Name的主機對應(yīng)的規(guī)范主機名。該記錄

能夠向查詢的主機提供一個主機名對應(yīng)的規(guī)范主機名，例如(,relay1.

bar.foo.com,CNAME)就是一條CNAME類型的記錄。

?如果Type=MX,則Value是個別名為Name的郵件服務(wù)器的規(guī)范主機名。舉例來

說，(*com,mail.bar.foo.com,MX)就是一條MX記錄。MX記錄允許郵件服

務(wù)器主機名具有簡單的別名。值得注意的是，通過使用MX記錄，一個公司的郵

件服務(wù)器和其他服務(wù)器(如它的Web服務(wù)器)可以使用相同的別名。為了獲得郵

件服務(wù)器的規(guī)范主機名，DNS客戶應(yīng)當(dāng)請求一條MX記錄；而為了獲得其他服務(wù)

器的規(guī)范主機名，DNS客戶應(yīng)當(dāng)請求CNAME記錄。

(5)DNS報文格式：包括query和reply兩種報文，ID將請求應(yīng)答對應(yīng)起來，報文足可變長

度，在number開頭的四個部分指明長度

參數(shù)域中的位1含義

0報文類型:O-queryi-reply

查詢類型：

1-4

0?標(biāo)準(zhǔn)查制1?反向查詢

5授權(quán)響應(yīng)，則更1

6報文被截斷，則置1

7期望遞歸，則置1

8支持遞歸，則置1

9-11保留

應(yīng)答類型：

0-無錯誤

12-161?查詢中格式錯

2-服務(wù)器失效

3-名字不存在

(6)主機別名

(7)域名格式壓縮https:〃blo@/muvanHzhel2Tartide/details/41622461

報文中域名格式

?每個段第一個字節(jié)指定長度(00xxxxxx=n),后跟n個字節(jié)

?長度為0的段，表明域名結(jié)束

壓縮格式

?域名的后綴部分經(jīng)常重復(fù)，可以進行適當(dāng)壓縮

?指針：如果前兩位為11,則段前兩個字節(jié)的后14為指針

(1Ixxxxxxxxxxxxxx)

■例如：需要查詢名字F.ISI.ARPA,FOO.F.ISLARPA.ARPA,

和根，忽略其他域，這些名字可以表示為：

2.川卷的小例

DNSjfiM的報Z可健色結(jié)彩個?亞的域名.因此使附壓帽方式.

限播方法很M件.4一個域名中的b漢符是屈耐的它的rter字節(jié)中的0島何位將裱我翼為〃.

達表示它是?個J6從母針a不用足SM的計軟字節(jié),指計中的弱卜〃弧表示該標(biāo)識符CDNS報

文中所在的仇置偏移（和文頭）.注量?個推竹可能指之?個完整的緘名.也叫德只指臼

的姑兄陸分.并H一個域名也可以解￥覦分不王縮,僅時后早*分才應(yīng)用指計伍縮.此外H偈任娟

也41存在的.即用"指向的域Z也可版知壓縮的（包含?個狗葉）.

分外“兩點需■建總，

/〃一個域名（X俺包含一個指計?要么只外四十字節(jié)it“包含一個箱汁?要么只在姑兄齪分猴的一個指鼾.

/:/包含指針的線g無策以字符小偌甩.

5.web服務(wù)與http連接

HTTP請求響應(yīng)報文P69

持久連接

非持久連接

■HTTP/1.0磁奢壽IF.持久連接■HTTP/L1缺省為持久連接

a在相同的連接匕服務(wù)器接

A服務(wù)器接收請求.給出響應(yīng).關(guān)TCP

收請求、給出響應(yīng)：再接收請求.

閉TCP連接

給出響應(yīng)：響應(yīng)后保持連接

■獲取每個對象需要兩階段

■HTTP/L1支持流水線機制

?建立TCP連接黑-M；多個..都|

?需要按序響卜

?對象請求和傳輸

■經(jīng)歷較少的慢啟動過程，減

■每次連接需要經(jīng)歷TCP慢啟

少往返時間

動階段

?降低響應(yīng)時間

用會被關(guān)閉

Web緩存機制：代理服務(wù)器緩存

Web緩存機制：客戶端緩存

■目標(biāo)：由代理服務(wù)器進行援

■目標(biāo)?如果被講求的對象在客

存,盡量誠少原始服務(wù)塞參與

戶次畿存仃最近版本，則不需

要發(fā)送該對象■用戶設(shè)覆瀏覽器：通過代理股

務(wù)器進行Web訪問

■客戶端：在發(fā)送的HTTP請求中

指定線存的時間，請求頭包含■瀏域器將折的的HTTP詁求發(fā)

送到代理股務(wù)嘉

ir>nx?dificd*MiK￥：<d?lc>

>服務(wù)m：如果援存的對皇是最?如皋m"中”被請求的時象.M

新的,在響應(yīng)時無需些返亞直接運HW象

象，響應(yīng)頭包球：送汴/]?否M.代用服務(wù)dlMIl始H務(wù)JS

請求“象.啊珞對象返回給*戶

IITTP/I.IJ04、otModified

用戶-服務(wù)器交互：認(rèn)證用戶■服務(wù)器狀態(tài)：Cookies

■服務(wù)器使用cookies保持狀態(tài)

■認(rèn)證：控制對服務(wù)器內(nèi)容的訪問?HTTP響應(yīng)頭中使用

-選界的cookie號具有唯一性

?認(rèn)證方法：通常使用“名字?口令”

?后繼的HTTPi青求中使用,@?檢：

?無狀態(tài)：客戶端需要在每個請求中攜?Cookie文件保存在用戶的主機中,

長連接可以發(fā)鄉(xiāng)次請求做股務(wù)器不公記由用戶主機中的瀏覽器管理

帶認(rèn)證信息余，M次啟乘.故他夫都離或掖需認(rèn)證

信息_______________________________

AWeb服務(wù)器建立后端數(shù)據(jù)庫，記

?每個請求頭中包含〃"加錄用戶信息

例如：

?如果請求頭中無〃〃的o/7z〃，o〃：，則?

Set-Cookie:SlD=31d4d96e407aad42;

服務(wù)器拒絕訪問，并在響應(yīng)頭中包含

Path=/;Domain=

WWWauthenticate：Cw）kie:SID=3ld4d96c407aad4

6.HTTP1.1的問題：隊頭阻塞問題-基于文本協(xié)議的問答有序模式，先請求的必須先響應(yīng)；

傳輸效率問題-文本格式、冗長重復(fù)的頭部等

解決策略：瀏覽器建立多個TCP連接-一般最多可以建立6個TCP連接-通過不同TCP連

接傳送的請求沒有響應(yīng)順序的要求-耗費較多的計算和存儲資源

7.HTTP2.0

HTTP2.0協(xié)議基本原理（續(xù)）HTTP2.0協(xié)議基本原理（續(xù)）

,TCP連接乂用?提高連接利用率.M決HTTP的隊頭阻塞何題?TCP連接!X用（示例》

?消息（Maage）：HTTP?次請求或響應(yīng)，包含?個或多個幀

a流（Stream）：筒中心成?次訪求和應(yīng)答，包含暮個M

?漳個TCP連接中可以承領(lǐng)U個油.不問流的幀可以交件號插儀修

?流的創(chuàng)建9標(biāo)識

-SuurnlD.標(biāo)idt*.ID為QCI,?1%》創(chuàng)建的海.10為（（

tt：（MKMMMH用定場景，如果箏在ItlJD分配

%.會新*一條旌核.接收感逋過52）111遇〃澗電的殂口.

-發(fā)i8租崔RXHEADEM（包含*StreamID，財創(chuàng)建

-瀛優(yōu)先flh町11依愛外為不K的（I先媛（卜2%，.以DFJisN中

承K

服務(wù)器推送：提高響應(yīng)速度,-q

A服務(wù)器在請求之前先推送請牌店出底戶端,推

送的響應(yīng)信息可以在客戶端枝獴存

HTTP頭壓縮（HPACK）

?請求頭由大心的健值組成，多個請求的健值重第

程度很高

?靜態(tài)表：定義通用HTTP頭域，常用健值無需重復(fù)

傳送，汽接引用內(nèi)部字典的整數(shù)索引

?動態(tài)表：兩邊交互發(fā)現(xiàn)新的關(guān)域.添加到動態(tài)喪

?自定義鍵值：采用Huffman編碼

■HTTP頭次縮示例

■5我

HTTP2.0協(xié)議解決的問題：通過引入流機制，解決了HTTP隊頭阻塞問題，提高了傳輸效率;

通過二進制編碼、頭壓縮機制提高了網(wǎng)絡(luò)帶寬利用率；通過服務(wù)器推送，加快了負面響應(yīng)速

度

HTTP2.0協(xié)議沒有解決的問題：TCP+TLS的多次交互，造成啟動延遲問題；對移動主機和多

宿主機的連接遷移問題；TCP隊頭阻塞問題

8.內(nèi)部分發(fā)網(wǎng)絡(luò)CDN

CDN基本原理HTTP重定向

,股務(wù)器決31CDN服務(wù)器

■CDN的實現(xiàn)機制（1）/HTTP響出狀態(tài)出H0X.淅明新的位置

CDN基本原理DNS輔助

，負翼均蜀D、S貨妻決策CDN服務(wù);8逍界

?CDN的實現(xiàn)機制（2），負我均衡D、SS；俁收集CDN服務(wù)JB的位置和負我情況

/如果找不到被請求的時象.衢要從Ki始”務(wù)JS狹取

內(nèi)容復(fù)制屐#

Ki始版務(wù)騫

URL：,儕服務(wù)器

獷展：CDN服務(wù)器的房次化組期一移動邊爆發(fā)存一移動邊埠計算

9.動態(tài)自適應(yīng)流媒體協(xié)議DASH

(1)基本思想：完整視頻被拆分為固定時長(2s-10s)、不同碼率的視頻片段(segment)；視

頻片段與媒體內(nèi)容描述(MediaPresentationDescription,MPD)一同存放于DASH服務(wù)器；

客戶端根據(jù)自身設(shè)備性能、當(dāng)前網(wǎng)絡(luò)條件、客戶端緩沖大小等自適應(yīng)選擇一種視頻碼率進

行下載

(2)例如：HTTP服務(wù)器中保存有高中低三種質(zhì)量的視頻片段，DASH客戶端評估網(wǎng)絡(luò)狀況,

通常在保證視頻流暢的前提下，獲取最高質(zhì)量的視頻片段

(3)MPD(MediaPresentationDescription)文件：一種XML文件，描述了DASH流媒體中

視頻/音頻文件信息

DASH基本原理典型的DASH開源播放器dashjs

■自適應(yīng)碼率(Adaptivebitrate,ABR)規(guī)則

例使用漕動修口f均估計A*亦吐

M.逡打不高J伍計值的&大碼率稷粒

基于吞吐盤的算法

r2個主要眄率切換規(guī)則

基『?緩沖的算法

ABR規(guī)則例如，便加4沖M.涓的奴利來決定F-

個“net的請求碼率

-放并清求規(guī)則(AbandonRcqucstsRulc)

在卜歿祝共跳的過伴中,如果算法檢酬利卜故議決*塊的過用過火

Ml.剜缶止'Iti*求，轉(zhuǎn)而?新下?相應(yīng)第低瑪學(xué)跖塊?

第三覃傳輸層協(xié)議

1.傳輸層解決的問題：可靠性，向應(yīng)用層提供可靠服務(wù)；復(fù)用(Multiplexing)和分用

(Demultiplexing)；

2.UDP數(shù)據(jù)報的差錯檢測:可選項，利用數(shù)據(jù)報中攜帶冗余位(校驗和域段)來檢測數(shù)據(jù)

報傳輸過程中出現(xiàn)的差錯；發(fā)送端：利用自己產(chǎn)生的偽首部和發(fā)送的UDP數(shù)據(jù)報計算校驗

和；接收端：利用自己產(chǎn)生的偽首部和接收的UDP數(shù)據(jù)報計算校驗和；偽首部：包含源IP

地址、目的IP地址、協(xié)議類型等域段

■UDP校驗和的計算方法

發(fā)送端：接收端：

?產(chǎn)生偽首部，校驗和域段清0,將數(shù)?產(chǎn)生偽首部,將數(shù)據(jù)報用0補齊為16

據(jù)報用0補齊為16位整數(shù)倍為整數(shù)倍

?將偽首部和數(shù)據(jù)報一起看成16位整?按16位整數(shù)序列，采用16位二進制

數(shù)序列反碼求和運算

?進行16位二進制反碼求和運算，計?如果計算結(jié)果位全1,沒有檢測到錯

算結(jié)果取反寫入校驗和域段誤：否則，說明數(shù)據(jù)報存在差錯

龍送時只發(fā)讖熠”號H

的端口號長度檢驗和數(shù)

。142|3|43|6口|0|42|3|4|5|6|7回||2|3卜|5|6|7|0|1|2|3|4|5|6,

據(jù)5個部分,偽濘部、填

充都被丟棄,偽首部只

0為了計算檢驗和,開源IPW(Source!Paddfe?)

盛計算前校驗和要設(shè)0

目的IP地址(DcstionationIPaddress)

協(xié)議(Protocol)長度(Length)

源端口號(SourcePon)目的端口號(DcYinationf\xt)

長度(Length)校騏和(Chcckwim)

(Data)

。填充

校驗和計算方法示例

TCP/IP進位加法，加到頭如果有?進位加到

尾部，最后按位取反

1110011001100110

1101010101010101

11011101110111011

1011101110111100

0100010001000011

■計算UDP校驗和示例

1001100100010011T153.19

040000100001101000->8.104

偽首部11010101100000011T171.3

017150000111000001011T14.11

000000000001000110和17

UDP108713

0000000000001111-15

首部150

0000010000111111—1087

01010100010001010I0ID0II01010100

數(shù)據(jù)0000000000001101-13

0100100101001110010(X)1110填充0000000000001111-15

0000000000000000-0(校驗和)

0101010001000101T數(shù)據(jù)

0101001101010100T數(shù)據(jù)

01001001010011101數(shù)據(jù)

^^0100011100000000一數(shù)據(jù)和0（填充）

網(wǎng)貝：jn果it事出姐圖財n為金。用全1代替（不會由盟i__________________________

|1的站架）.兇IPWH1個。代々上依依|一

按二進制反碼運算求和1001011011101101—求和得出的結(jié)果

將得出的結(jié)果求反碼0110100100010010-*校驗和

u_shortcksum(u_shortwbut,intcount)

(

registeru_longsum=0;

while(count-)

(

sum+=*buf++;

if(sum&0XFFFF0000)

(

sum&=OXFFFF;

sum++;

)

Return~(sum&OXFFFF);

UDP校驗和計算幾點說明

?IPv4中UDP校驗和是可選項，IPv6中變成強制項

■0無，非0有（如果計尊結(jié)果為0,則以全1代替）

?UDP校驗和覆蓋的范圍超出了UDP數(shù)據(jù)報本身，使用偽首部的目的是

檢驗UDP數(shù)據(jù)報是否到達真正的目的地

-正確的目的地包括了特定的主機和該主機上特定的端口

?偽首部不隨用戶數(shù)據(jù)報一起傳輸，接收方需自己形成偽首部進行校驗

?偽首部的使用破壞了層次劃分的基本前提，即每一層的功能獨立

-目的主機的IP地址UDP通常知道，源IP的使用需要通過路由選擇決定

IP首部、ICMPLUDPLTCP都需要計算校驗和，方法類似|

UDP校驗和計算幾點說明

?IPv4中UDP校瞼和是可選項，IPv6中變成強制項

-0無，非。有（如果計算結(jié)果為0,則以全1代怦）

?UDP校驗和覆蓋的范圍超出了UDP數(shù)據(jù)報本身，使用偽首部的目的是

檢驗UDP數(shù)據(jù)報是否到達真正的目的地

-正確的目的地包括了特定的主機和該主機上特定的端口

?偽首部不隨用戶數(shù)據(jù)報一起傳輸，接收方需自己形成偽首部進行校驗

?偽首部的使用破壞了層次劃分的基本前提，即每一層的功能獨立

-目的主機的IP地址UDP通常知道，源IP的使用需要通過路由選擇決定仁

3可靠數(shù)據(jù)傳輸

⑴停等機制

具有位錯誤通道上的可靠數(shù)據(jù)傳輸：rdt2.0

＞卜層通道可能造成某些位出現(xiàn)錯誤（如：1變0,。變1）

＞需要解決的問題：如何恢發(fā)差錯（自動重伐請求ARQL

?ACK：接收病通知發(fā)送病分處正病接收

?NAK：接收端通如發(fā)送端接收的分機存在錯誤

?發(fā)送端收到NAK,則重傳分級

處理重復(fù)接受問題：增加序列號

rdt2.0：存在的問題

＞如果ACKNAK受損會產(chǎn)生什么狀況？

在rdt2.0基礎(chǔ)上需要增加哪些功能？

?發(fā)送端無法確認(rèn)接收端的狀況ACK或NAKi

?發(fā)送端在每個分組中增加序列號使用幾個序列號夠用？

?不能簡單進行傳：可能會造成值復(fù)接收

?發(fā)送端通過校驗字段驗證ACK/NAK分組是否損壞

＞處理重復(fù)接收問題

?如果ACK/NAK分組損壞，發(fā)送端用傳當(dāng)前的分組

?發(fā)送端在年個分tn中增加序列號

?如果無法判斷是ACISIAK,則就傳當(dāng)Q的分綱,接收端根據(jù)序列號判斷是否是重發(fā)的分組

?眩收端左ACKNAK分批中增加校對項

?接收端丟棄重復(fù)的分組

停等機制接收端要在ACK/NAK報文中添加校驗字段

NAK：接收端通知發(fā)送端接收的分組存在錯誤

停等：發(fā)送端收到錯誤ACK不重傳，超時才重傳，接收端每收到一個包都要回復(fù)對應(yīng)ACK

不論包是否是正確的

性能問題

“例如：RFGbpsUOVbps)的蹺路.往返延時R7T=30?柒杪.分紈長

PM000字W(8000(4),發(fā)送一個分川所用的時間77?4\50為，

……P8000bit門

77M

＞發(fā)送培的埴路利用率(忽畸發(fā)送ACKM時間)

P/R0.008

RTT+P/R=30+0.008*0.00027

即伍麗

＞大約毋30堪秒發(fā)送一個分縱IGbps鏈路上的吞吐率約為芬煙圻

如何提廟鏈路利用率？Rdt&O如何改進？

(2)流水線協(xié)議

■I可退N：Go-Back-N(GBN)■選擇承傳：SelectiveRepeat(SR)

A接收運獨立確認(rèn)得個正確接收的分ifl.必要時饋存分ifl.財高層按字交付

＞允許發(fā)送端發(fā)出N個未得到確認(rèn)的分組

＞短個分狼立定時,發(fā)15端“映傳未收到ACK的分ill.

＞需要增和序列號

*是“，T-1＞??＞4'II

?分扭首部中增加k位的序列號.序列號空間為［0.2'-1］XIMIitAXig

,采用JK枳胸認(rèn)，只確認(rèn)it續(xù)接收夕注11的啦大序列號

?可能接收到小發(fā)的ACKOOOOOLIIIlilllllODMO…

A發(fā)送端設(shè)置定時器,定時器超時時，用傳所有未礴認(rèn)的分批—■口大小.一?

再卜，】訐r［鞏廠和丁hI

移我.舊“米石I大.再...0.AII可.....

&KCnettWQnum1

I巳經(jīng)|可用.任未發(fā)送ODOMOOIIIIIIIIIIIIM--r

I—■口大收—

IIIIIIOIIIIIIIIIIIIMDID|一內(nèi)

t-—?muiJM

■SR交互示例SR問題討論

?n(N-4?發(fā)送靖播收端＞例如：序弓為0、k2、3.

發(fā)送力機0

窗口大小為3

DEB'678發(fā)送分假I

發(fā)送分m