《網(wǎng)絡(luò)編程WinSock》配套教學(xué)課件

《網(wǎng)絡(luò)編程（WinSock）》TCP/IP協(xié)議介紹2022/11/21第1章TCP/IP協(xié)議介紹1.1TCP/IP簡(jiǎn)介1.2網(wǎng)絡(luò)編程應(yīng)考慮的問(wèn)題

習(xí)題與思考題（作業(yè)）

2022/11/211.1TCP/IP簡(jiǎn)介

1.1.1OSI模型與TCP/IP結(jié)構(gòu)

OSI/RM(OpenSystemInterconnection/ReferenceModel，開放系統(tǒng)互連參考模型)將計(jì)算機(jī)網(wǎng)絡(luò)通信定義為一個(gè)七層框架模型，如圖1.1所示。

2022/11/21圖1.1OSI模型與通信流程

2022/11/21表1.1OSI模型中各個(gè)層的功能

2022/11/21當(dāng)然，OSI模型只是一個(gè)框架，它的每一層并不執(zhí)行某種功能，功能的具體實(shí)現(xiàn)還需通信協(xié)議，主要通過(guò)軟件來(lái)進(jìn)行。當(dāng)數(shù)據(jù)在層間向下傳播時(shí)(源主機(jī)部分)，每一層都會(huì)為傳輸中的數(shù)據(jù)增加一個(gè)包頭(header)，用于標(biāo)識(shí)包的來(lái)源與目的。到了目標(biāo)主機(jī)時(shí)，每一層都從數(shù)據(jù)中讀取相應(yīng)包頭，執(zhí)行請(qǐng)求的任務(wù)，并負(fù)責(zé)向上傳輸數(shù)據(jù)包。每一種具體的協(xié)議一般都定義了OSI模型中的各個(gè)層次具體實(shí)現(xiàn)的技術(shù)要求。

2022/11/21圖1.2TCP/IP族的體系結(jié)構(gòu)

2022/11/21每一層負(fù)責(zé)的功能如下：

·

鏈路層：有時(shí)被稱作數(shù)據(jù)鏈路層或網(wǎng)絡(luò)接口層，通常包括操作系統(tǒng)中的設(shè)備驅(qū)動(dòng)程序和計(jì)算機(jī)中對(duì)應(yīng)的網(wǎng)絡(luò)接口卡，它們一起處理與電纜(或其他任何傳輸媒介)的物理接口細(xì)節(jié)。

·

網(wǎng)絡(luò)層：有時(shí)也被稱為互聯(lián)網(wǎng)層，負(fù)責(zé)分組在網(wǎng)絡(luò)中的活動(dòng)，包括IP(網(wǎng)際協(xié)議)、ICMP(Internet控制報(bào)文協(xié)議)以及IGMP(Internet組管理協(xié)議)。

2022/11/21

·

傳輸層：該層主要為兩臺(tái)主機(jī)上的應(yīng)用程序提供端到端的數(shù)據(jù)通信，它分為兩個(gè)不同的協(xié)議——TCP(傳輸控制協(xié)議)和UDP(用戶數(shù)據(jù)報(bào)協(xié)議)。TCP提供端到端的質(zhì)量保證的數(shù)據(jù)傳輸，該層負(fù)責(zé)數(shù)據(jù)的分組、質(zhì)量控制和超時(shí)重發(fā)等，對(duì)于應(yīng)用層來(lái)說(shuō)，就可以忽略這些工作。UDP則只負(fù)責(zé)簡(jiǎn)單地把數(shù)據(jù)報(bào)從一端發(fā)送到另一端，至于數(shù)據(jù)是否到達(dá)或按時(shí)到達(dá)、數(shù)據(jù)是否損壞都必須由應(yīng)用層來(lái)做。這兩種協(xié)議各有用途，前者可用于面向連接的應(yīng)用，而后者則在及時(shí)性服務(wù)中有著重要的用途，如網(wǎng)絡(luò)多媒體通信等。

·

應(yīng)用層：該層負(fù)責(zé)處理實(shí)際的應(yīng)用程序細(xì)節(jié)，包括Telnet、HTTP、SMTP、FTP、DNS和SNMP等協(xié)議和應(yīng)用。

2022/11/21圖1.3通過(guò)TCP/IP和路由器連接的兩臺(tái)主機(jī)

2022/11/21在圖1.3所示的系統(tǒng)中，兩臺(tái)主機(jī)通過(guò)路由器互相連接。路由器可以把以太網(wǎng)、令牌點(diǎn)對(duì)點(diǎn)鏈接和FDDI(光纖分布式數(shù)據(jù)接口)等不同的網(wǎng)絡(luò)連接在一起。協(xié)議中的各層對(duì)上一層是透明的，也就是說(shuō)，應(yīng)用層只負(fù)責(zé)應(yīng)用程序之間的通信規(guī)則，不必了解數(shù)據(jù)如何在網(wǎng)絡(luò)中傳輸，也不必了解怎樣接入網(wǎng)絡(luò)。而鏈路層只需要負(fù)責(zé)傳輸，而不需要知道正在傳送的是什么數(shù)據(jù)。

2022/11/211.1.2TCP/IP基本概念作為一個(gè)整體的結(jié)構(gòu)體系，TCP/IP必然要涉及到一系列基本但非常重要的概念，本節(jié)主要簡(jiǎn)要介紹IP地址、地址解析及端口號(hào)等基本概念。

1.IP地址與子網(wǎng)掩碼網(wǎng)絡(luò)互聯(lián)的目的是提供一個(gè)無(wú)縫的通信系統(tǒng)。為此，必須用互聯(lián)網(wǎng)協(xié)議屏蔽物理網(wǎng)絡(luò)的具體細(xì)節(jié)，并提供一個(gè)虛擬網(wǎng)絡(luò)的功能。在TCP/IP棧中，編址由IP協(xié)議規(guī)定，IP標(biāo)準(zhǔn)分配給每臺(tái)主機(jī)一個(gè)32位的二進(jìn)制數(shù)作為該主機(jī)的IP地址。在最新出臺(tái)的IPv6中IP地址升至128位，這樣IP資源就變得更加豐富了。

2022/11/21每個(gè)IP地址被分割成前綴和后綴兩部分。前綴用于確定計(jì)算機(jī)從屬的物理網(wǎng)絡(luò)，后綴則用于確定網(wǎng)絡(luò)上一臺(tái)單獨(dú)的計(jì)算機(jī)。互聯(lián)網(wǎng)中每一個(gè)物理網(wǎng)絡(luò)都有一個(gè)唯一的值作為網(wǎng)絡(luò)號(hào)(NetworkNumber)。IP地址的層次性保證了以下兩個(gè)重要性質(zhì)：

·

每臺(tái)計(jì)算機(jī)分配一個(gè)唯一的地址。

·

網(wǎng)絡(luò)號(hào)的分配全球統(tǒng)一，但后綴可本地分配，無(wú)須全球統(tǒng)一。

2022/11/21

IP地址共分五類：A類、B類、C類、D類和E類。其中A類、B類和C類為基本類；D類用于多播傳送；E類屬于保留類，現(xiàn)在不用。它們的格式如下(其中*代表網(wǎng)絡(luò)號(hào)位數(shù))：IP地址一般采用點(diǎn)分十進(jìn)制的表示方法，例如：

10000001001101000000011000000000→2022/11/21表1.2各類IP地址的范圍

2022/11/21此外，需要特別注意以下幾個(gè)特殊的IP地址：

·

網(wǎng)絡(luò)地址：IP中主機(jī)地址為0的地址表示網(wǎng)絡(luò)地址，如。

·

廣播地址：網(wǎng)絡(luò)號(hào)后跟一個(gè)所有位全是1的后綴，就是直接廣播地址。

·回送地址：用于測(cè)試。

2022/11/21除了給每臺(tái)主機(jī)分配一個(gè)IP地址外，IP協(xié)議規(guī)定也應(yīng)給路由器分配一個(gè)IP地址。事實(shí)上，每個(gè)路由器被分配了兩個(gè)或更多的IP地址。一個(gè)路由器連接到多個(gè)物理網(wǎng)絡(luò)，每一個(gè)IP地址包含一個(gè)特定物理網(wǎng)絡(luò)的網(wǎng)絡(luò)號(hào)。一個(gè)IP地址并不標(biāo)識(shí)一臺(tái)特定的計(jì)算機(jī)，而是標(biāo)識(shí)一臺(tái)計(jì)算機(jī)和一個(gè)網(wǎng)絡(luò)間的連接。

2022/11/21現(xiàn)在所有的主機(jī)都要求支持子網(wǎng)編址(RFC950，J.MogulandJ.Postel，1985)，該功能要求不僅把IP地址看成由單純的一個(gè)網(wǎng)絡(luò)號(hào)和一個(gè)主機(jī)號(hào)組成，而且要把主機(jī)號(hào)再分成一個(gè)子網(wǎng)號(hào)和一個(gè)主機(jī)號(hào)。這樣做的原因是因?yàn)锳類和B類地址為主機(jī)號(hào)分配了太多的空間，可分別容納的主機(jī)數(shù)為224－2和216－2。但是，事實(shí)上在一個(gè)網(wǎng)絡(luò)中并不會(huì)有這么多的主機(jī)，因此在InterNIC獲得某個(gè)IP網(wǎng)絡(luò)號(hào)后，就由系統(tǒng)管理員來(lái)進(jìn)行分配，由他來(lái)決定是否建立子網(wǎng)，以及分配多少位給子網(wǎng)號(hào)和主機(jī)號(hào)。例如，這里有一個(gè)B類網(wǎng)絡(luò)地址()，在剩下的16位中，8位用于子網(wǎng)號(hào)，8位用于主機(jī)號(hào)，其格式如圖1.4所示。這樣就允許有254個(gè)子網(wǎng)，每個(gè)子網(wǎng)可以有254臺(tái)主機(jī)。

2022/11/21圖1.4B類地址的子網(wǎng)編址舉例

除了地址以外，主機(jī)還需要知道有多少位用于子網(wǎng)號(hào)及多少位用于主機(jī)號(hào)。這是在引導(dǎo)過(guò)程中通過(guò)子網(wǎng)掩碼來(lái)確定的。這個(gè)掩碼是一個(gè)32位的值，其中值為1的位留給網(wǎng)絡(luò)號(hào)和子網(wǎng)號(hào)，為0的位留給主機(jī)號(hào)。在上面的例子中，子網(wǎng)掩碼就是。

2022/11/21

2.地址解析地址解析(AddressResolution)就是將計(jì)算機(jī)中的協(xié)議地址翻譯成物理地址(或稱MAC地址，即媒體映射地址)。地址解析只能在本地網(wǎng)內(nèi)進(jìn)行。地址解析技術(shù)可分為如下三種：

(1)表查詢(Table-Lookup)。該方法適用于廣域網(wǎng)(WAN)，通過(guò)建立映射數(shù)組(協(xié)議地址?物理地址)的方法解決。用戶可通過(guò)查詢找到物理地址。

2022/11/21

(2)相近形式計(jì)算(CloseForm-Computation)。該方法適用于可以自行配置的網(wǎng)絡(luò)，IP地址和物理地址相互對(duì)應(yīng)，例如：

→ XXXl

→ XXX2可通過(guò)這種算法得到物理地址：物理地址＝協(xié)議地址&0xFF。

(3)信息交換(Message-Exchange)。該方式適用于LAN，是基于分布式的處理方式，即主機(jī)發(fā)送一個(gè)解析請(qǐng)求，以廣播的形式發(fā)出，并等待網(wǎng)絡(luò)內(nèi)各個(gè)主機(jī)的響應(yīng)。

2022/11/21

3.域名系統(tǒng)一個(gè)系統(tǒng)的全域名由主機(jī)名、域名和擴(kuò)展名三部分組成，各部分間使用“．”分隔，例如。在TCP/IP應(yīng)用中，域名系統(tǒng)(DNS)是一個(gè)分布的數(shù)據(jù)庫(kù)，由它來(lái)提供IP地址和主機(jī)名之間的映射信息，可以通過(guò)在程序中調(diào)用標(biāo)準(zhǔn)庫(kù)函數(shù)來(lái)編程實(shí)現(xiàn)域名與IP地址之間的相互轉(zhuǎn)換。通過(guò)從域名地址到IP地址的映射，使得在日常的網(wǎng)絡(luò)應(yīng)用中可以使用域名這種便于記憶的網(wǎng)絡(luò)地址表示形式。所有的網(wǎng)絡(luò)應(yīng)用程序理論上都應(yīng)該具有內(nèi)嵌的域名解析機(jī)制。

2022/11/21

4.數(shù)據(jù)包的封裝和分用當(dāng)應(yīng)用程序用TCP傳送數(shù)據(jù)時(shí)，數(shù)據(jù)被送入?yún)f(xié)議棧中，然后逐個(gè)通過(guò)每一層，直到被當(dāng)作一串比特流送入網(wǎng)絡(luò)。其中每一層對(duì)收到的數(shù)據(jù)都要增加一些首部信息(有時(shí)還要增加尾部信息)，該過(guò)程如圖1.5所示。TCP傳給IP的數(shù)據(jù)單元稱作TCP報(bào)文段或簡(jiǎn)稱TCP段。IP傳給網(wǎng)絡(luò)接口層的數(shù)據(jù)單元稱作IP數(shù)據(jù)報(bào)(IPDatagram)。通過(guò)以太網(wǎng)傳輸?shù)谋忍亓鞣Q作幀(Frame)。圖1.5中幀頭和幀尾下面所標(biāo)注的數(shù)字是典型以太網(wǎng)幀首部的字節(jié)長(zhǎng)度。以太網(wǎng)數(shù)據(jù)幀的長(zhǎng)度必須在46～1518字節(jié)之間。

2022/11/21圖1.5數(shù)據(jù)包的封裝過(guò)程示意圖

2022/11/21由于IP數(shù)據(jù)報(bào)通常是分組傳輸?shù)?，因此更?zhǔn)確地說(shuō)，圖1.5中IP和網(wǎng)絡(luò)接口層之間傳送的數(shù)據(jù)單元應(yīng)該是分組(Packet)。分組既可以是一個(gè)完整的IP數(shù)據(jù)報(bào)，也可以是IP數(shù)據(jù)報(bào)的一個(gè)片(Fragment)。關(guān)于分組的細(xì)節(jié)算法不在本書的討論范圍之內(nèi)。

UDP數(shù)據(jù)與TCP數(shù)據(jù)基本一致。唯一不同的是，UDP傳給IP的信息單元稱作UDP數(shù)據(jù)報(bào)(UDPDatagram)，而且UDP的首部長(zhǎng)為8字節(jié)。由于TCP、UDP、ICMP和IGMP都要向IP傳送數(shù)據(jù)，因此IP必須在生成的IP首部中加入某種標(biāo)識(shí)，以表明數(shù)據(jù)屬于哪一層。為此，IP在首部中存入一個(gè)長(zhǎng)度為8bit的數(shù)據(jù)，稱作協(xié)議域。1表示ICMP，2表示IGMP，6表示TCP，17表示UDP。

2022/11/21同樣，許多應(yīng)用程序都可以使用TCP或UDP來(lái)傳送數(shù)據(jù)。傳輸層協(xié)議在生成報(bào)文首部時(shí)要存入一個(gè)應(yīng)用程序的標(biāo)識(shí)符。TCP和UDP都用一個(gè)16位的端口號(hào)來(lái)表示不同的應(yīng)用程序。TCP和UDP把源端口號(hào)和目的端口號(hào)分別存入報(bào)文首部中。網(wǎng)絡(luò)接口分別要發(fā)送和接收IP、ARP和RARP數(shù)據(jù)，因此也必須在以太網(wǎng)的幀首部中加入某種形式的標(biāo)識(shí)，以指明生成數(shù)據(jù)的網(wǎng)絡(luò)層協(xié)議。為此，以太網(wǎng)的幀首部也有一個(gè)16bit的幀類型域。

2022/11/21當(dāng)目的主機(jī)收到一個(gè)以太網(wǎng)數(shù)據(jù)幀時(shí)，數(shù)據(jù)就開始從協(xié)議棧中由底向上升，同時(shí)去掉各層協(xié)議加上的報(bào)文首部。每層協(xié)議盒都要去檢查報(bào)文首部中的協(xié)議標(biāo)識(shí)，以確定接收數(shù)據(jù)的上層協(xié)議。這個(gè)過(guò)程稱作分用(Demultiplexing)，圖1.6顯示了該過(guò)程。圖1.6中把ARP和RARP放在IP層是因?yàn)樗鼈兌加幸蕴W(wǎng)頭部和尾部，而在前面的論述中把它們作為鏈路層的協(xié)議，這并不矛盾，因?yàn)門CP/IP棧的層次劃分本來(lái)就不是非常清晰。

2022/11/21圖1.6數(shù)據(jù)分用過(guò)程

2022/11/21

5.端口號(hào)

TCP和UDP采用端口號(hào)來(lái)識(shí)別應(yīng)用程序。例如，服務(wù)器提供的服務(wù)一般都是通過(guò)通用端口號(hào)來(lái)識(shí)別的，對(duì)于TCP/IP實(shí)現(xiàn)來(lái)說(shuō)，F(xiàn)TP服務(wù)器的TCP端口號(hào)都是21，Telnet服務(wù)器的TCP端口號(hào)都是23，TFTP(簡(jiǎn)單文件傳送協(xié)議)服務(wù)器的UDP端口號(hào)都是69。任何TCP/IP實(shí)現(xiàn)所提供的服務(wù)都使用通用端口號(hào)1～1023。這些通用端口號(hào)由Internet號(hào)分配機(jī)構(gòu)(InternetAssignedNumbersAuthority,IANA)來(lái)管理。

2022/11/21客戶端通常對(duì)它所使用的端口號(hào)并不關(guān)心，只需保證該端口號(hào)在本機(jī)上是唯一的就可以了?？蛻舳丝谔?hào)又稱作臨時(shí)端口號(hào)(即存在時(shí)間很短暫)，這是因?yàn)樗ǔＶ皇窃谟脩暨\(yùn)行該客戶程序時(shí)才存在，而服務(wù)器則只要主機(jī)是開著的，其服務(wù)就運(yùn)行。大多數(shù)TCP/IP實(shí)現(xiàn)給臨時(shí)端口分配1024～5000之間的端口號(hào)。大于5000的端口號(hào)是為其他服務(wù)(Internet上并不常用的服務(wù))預(yù)留的。

2022/11/211.1.3常用協(xié)議下面對(duì)一些常用協(xié)議進(jìn)行簡(jiǎn)要的介紹。

1.以太網(wǎng)數(shù)據(jù)鏈路層幀結(jié)構(gòu)

IEEE802.3定義了一種具有七個(gè)字段的幀(MAC)：前導(dǎo)符、起始幀分界符、目標(biāo)地址、源地址、PDU的長(zhǎng)度/類型、數(shù)據(jù)以及CRC。以太網(wǎng)不提供任何對(duì)收到的幀進(jìn)行確認(rèn)的機(jī)制，確認(rèn)在高層完成，這表明它是一種不可靠的介質(zhì)。CSMA/CD中MAC幀的格式如圖1.7所示。

2022/11/21圖1.7IEEE802.3MAC幀結(jié)構(gòu)

2022/11/21

·

前導(dǎo)符(Preamble)：該字段長(zhǎng)7個(gè)字節(jié)(56位)，其中1和0交替出現(xiàn)，警告接收系統(tǒng)即將有數(shù)據(jù)幀到來(lái)，同時(shí)同步系統(tǒng)時(shí)序。

·

起始幀分界符(SFD)：該字段長(zhǎng)1字節(jié)，為10101011，標(biāo)志幀的開始。SFD通知接收方后面所有的內(nèi)容都是數(shù)據(jù)。

·

目標(biāo)地址(DestinationAddress)：該字段長(zhǎng)6個(gè)字節(jié)，包含了數(shù)據(jù)幀的目的物理地址。一個(gè)系統(tǒng)的物理地址是一個(gè)在它的網(wǎng)絡(luò)接口卡(NIC)上編碼的比特模式。每一個(gè)NIC由一個(gè)獨(dú)一無(wú)二的地址將它和其他所有的NIC區(qū)別開來(lái)。2022/11/21

·

源地址(SourceAddress)：該字段同樣長(zhǎng)6個(gè)字節(jié)，包含轉(zhuǎn)發(fā)數(shù)據(jù)幀的最后一個(gè)設(shè)備的物理地址。該設(shè)備可以是發(fā)送站點(diǎn)，也可以是接收和轉(zhuǎn)發(fā)數(shù)據(jù)包的最近路由器。

·

PDU的長(zhǎng)度/類型(Length/Type)：該字段的兩個(gè)字節(jié)指出PDU的長(zhǎng)度或封裝的數(shù)據(jù)類型。當(dāng)PDU的長(zhǎng)度固定時(shí)，這個(gè)字段可以用來(lái)表示數(shù)據(jù)類型，如IP(0x0800)、ARP(0x0806)、RARP(0x8035)等。在以太網(wǎng)中，如果高層協(xié)議采用TCP/IP協(xié)議族，則MAC幀的結(jié)構(gòu)如圖1.8所示(沒(méi)有標(biāo)出前導(dǎo)符和起始幀分界符)。

2022/11/21圖1.8采用TCP/IP協(xié)議族的MAC幀結(jié)構(gòu)示意

2022/11/21

·

數(shù)據(jù)：保存高層協(xié)議的數(shù)據(jù)(PDU)。

·

CRC：IEEE802.3MAC幀的最后一個(gè)字段是檢錯(cuò)信息，通常為CRC-32。

2022/11/21

2.IP

IP負(fù)責(zé)在TCP/IP主機(jī)之間提供數(shù)據(jù)報(bào)服務(wù)，進(jìn)行數(shù)據(jù)封裝及產(chǎn)生協(xié)議頭。由于在以太網(wǎng)中幀的大小要受到限制，并且不同的幀可能由不同的網(wǎng)絡(luò)路徑傳送，因此IP協(xié)議需要將較大的數(shù)據(jù)報(bào)文分割開來(lái)，并在目的主機(jī)處按正確順序組合。另外，IP協(xié)議不負(fù)責(zé)包的校驗(yàn)，它是一種無(wú)連接、不可靠的傳輸。不可靠(unreliable)的意思是它不能保證IP數(shù)據(jù)報(bào)能成功地到達(dá)目的地。如果發(fā)生任何錯(cuò)誤，IP協(xié)議則丟棄該數(shù)據(jù)報(bào)，然后發(fā)送ICMP消息報(bào)給信源端。數(shù)據(jù)包的檢測(cè)校驗(yàn)是由上層協(xié)議如TCP等提供的。無(wú)連接(connectionless)的意思是IP并不維護(hù)任何關(guān)于后續(xù)數(shù)據(jù)報(bào)的狀態(tài)，每個(gè)數(shù)據(jù)報(bào)的處理是相互獨(dú)立的，即IP數(shù)據(jù)報(bào)可以不按發(fā)送順序接收。

2022/11/21

IP協(xié)議還要負(fù)責(zé)尋找路由，因此它還需要配套一個(gè)確定的IP地址。在IP報(bào)文的包頭中包含了源與目的IP地址。一般來(lái)說(shuō)不會(huì)有應(yīng)用程序直接訪問(wèn)IP協(xié)議。

IP數(shù)據(jù)報(bào)是Internet上數(shù)據(jù)通信的基本單元，這些數(shù)據(jù)報(bào)不超過(guò)1000字節(jié)長(zhǎng)，當(dāng)人們打開Web頁(yè)、下載文件或者發(fā)送E-mail時(shí)，這些數(shù)據(jù)報(bào)就在世界各地來(lái)回傳輸。IP數(shù)據(jù)報(bào)的報(bào)文格式如圖1.9所示。

2022/11/21圖1.9IP數(shù)據(jù)報(bào)格式

2022/11/21

·

IP數(shù)據(jù)報(bào)頭的最小長(zhǎng)度是5個(gè)字(word，1字＝4字節(jié))，如果有其他選項(xiàng)，報(bào)頭可能會(huì)更長(zhǎng)。IPv4數(shù)據(jù)報(bào)中的數(shù)據(jù)(包括報(bào)頭中的數(shù)據(jù))以32位(4字節(jié))的方式來(lái)組織。IPv4中包含至少12個(gè)不同字段，且在沒(méi)有選項(xiàng)時(shí)長(zhǎng)度為20個(gè)字節(jié)，但在包含選項(xiàng)時(shí)可達(dá)60個(gè)字節(jié)。

·

版本(VERS)：指定IP協(xié)議的版本號(hào)，對(duì)于IPv4來(lái)說(shuō)，版本為4。

·

報(bào)頭長(zhǎng)度(HLENS)：指定IP報(bào)頭的長(zhǎng)度，以字為單位，范圍為5～15個(gè)字。

·

服務(wù)類型(ToS，TypeofService)：表示數(shù)據(jù)報(bào)的服務(wù)類型，即處理的優(yōu)先級(jí)，包括延時(shí)、吞吐量、可靠性或代價(jià)，它在IPv4中的應(yīng)用并不廣泛。

2022/11/21

·

報(bào)文總長(zhǎng)度(TotalLength)：以字節(jié)為單位指定數(shù)據(jù)報(bào)的總長(zhǎng)度，IP數(shù)據(jù)報(bào)的長(zhǎng)度最大為65535字節(jié)，網(wǎng)絡(luò)主機(jī)可以使用數(shù)據(jù)報(bào)長(zhǎng)度來(lái)確定一個(gè)數(shù)據(jù)報(bào)的結(jié)束和下一個(gè)數(shù)據(jù)報(bào)的開始；當(dāng)傳送長(zhǎng)度超過(guò)65535字節(jié)的IP數(shù)據(jù)報(bào)時(shí)，大多數(shù)的鏈路層都會(huì)分片。主機(jī)一般要求接收的數(shù)據(jù)報(bào)不超過(guò)576字節(jié)。由于TCP把用戶數(shù)據(jù)分成若干片，因此，一般來(lái)說(shuō)這個(gè)限制不會(huì)影響TCP。

·

標(biāo)識(shí)符(ID)：該16位標(biāo)識(shí)符由產(chǎn)生它的主機(jī)唯一指定給數(shù)據(jù)報(bào)，分段后的數(shù)據(jù)報(bào)共享同一個(gè)數(shù)據(jù)報(bào)ID，有助于接收主機(jī)對(duì)分段的數(shù)據(jù)報(bào)重裝。

2022/11/21

·

標(biāo)志(FLG)：包括3個(gè)1位標(biāo)志，標(biāo)識(shí)報(bào)文是否允許被分段和是否使用了這些域。第一位保留并設(shè)為0；第二位標(biāo)識(shí)報(bào)文能否被分段，其中0表示報(bào)文可以被分段，1表示報(bào)文不能被分段；第三位只有在第二位為0時(shí)才有意義，這一位標(biāo)識(shí)此報(bào)文是否是這一系列分段的最后一個(gè)，或者接收應(yīng)用程序是否還希望有更多的段，0指示報(bào)文是最后一個(gè)。

·分段偏移量(FragmentOffset)：指定分段在整個(gè)數(shù)據(jù)報(bào)中的位置。接收主機(jī)同時(shí)使用標(biāo)志位和分段偏移，以重組被分段的數(shù)據(jù)報(bào)。這個(gè)值以64位為單位遞增。

2022/11/21

·

生命周期(TTL，TimeToLive)：代表數(shù)據(jù)報(bào)在被丟棄前能夠穿越的最大主機(jī)跳數(shù)。TTL的初始值由源主機(jī)設(shè)置，其理論最大值為255，每經(jīng)過(guò)一個(gè)處理節(jié)點(diǎn)減1。當(dāng)該字段的值為0時(shí)，報(bào)文就被認(rèn)為是不可轉(zhuǎn)發(fā)的，之后產(chǎn)生一個(gè)ICMP報(bào)文發(fā)回源主機(jī)，并丟棄該不可轉(zhuǎn)發(fā)的報(bào)文。

·

協(xié)議(Protocol)：指明數(shù)據(jù)報(bào)中攜帶的載荷類型，主要標(biāo)識(shí)所使用的協(xié)議，一般是指TCP協(xié)議、UDP協(xié)議、ICMP報(bào)文和IGMP報(bào)文。

·頭校驗(yàn)和(HeaderChecksum)：目的是保證報(bào)頭的正確性，目的機(jī)、網(wǎng)絡(luò)中的每個(gè)網(wǎng)關(guān)都要重新計(jì)算報(bào)頭的校驗(yàn)和，如果計(jì)算出的校驗(yàn)和與報(bào)文所含的校驗(yàn)和不同，則丟棄該報(bào)文。

2022/11/21

·

源IP地址(SourceIPAddress)：指明數(shù)據(jù)報(bào)的發(fā)送方地址。

·

目的IP地址(DestinationIPAddress)：指明數(shù)據(jù)報(bào)的接收方地址。

·

選項(xiàng)(Options)：在IPv4中，主要用于網(wǎng)絡(luò)測(cè)試和調(diào)試。

·

填充區(qū)(Padding)：為了保證IP頭長(zhǎng)度是32位的整數(shù)倍，要填充額外的0。2022/11/21

IP協(xié)議是TCP與UDP的基礎(chǔ)。TCP和UDP的每組數(shù)據(jù)都通過(guò)端系統(tǒng)和每個(gè)中間路由器中的IP層在互聯(lián)網(wǎng)中進(jìn)行傳輸。ICMP作為IP協(xié)議的附屬協(xié)議，用來(lái)與其他主機(jī)或路由器交換錯(cuò)誤報(bào)文和其他重要信息。IP層協(xié)議的另一個(gè)附屬協(xié)議是IGMP(Internet組管理協(xié)議)，它用來(lái)把一個(gè)UDP數(shù)據(jù)報(bào)多播或組播到多個(gè)主機(jī)。

2022/11/21

3.TCP

TCP使用IP作為網(wǎng)絡(luò)層協(xié)議。TCP的全稱是TransmissionControlProtocol，即傳輸控制協(xié)議。在網(wǎng)絡(luò)通信傳輸機(jī)制中，它屬于面向連接、可靠傳輸?shù)念愋?。面向連接的傳輸意味著在進(jìn)行通信以前，需要在兩個(gè)系統(tǒng)之間建立邏輯連接，在每個(gè)數(shù)據(jù)傳輸?shù)倪^(guò)程中都需要進(jìn)行應(yīng)答以保證數(shù)據(jù)包的完整。這種方法需要的網(wǎng)絡(luò)開銷較大，但數(shù)據(jù)傳輸?shù)目煽啃钥梢员ＷC。雖然TCP使用不可靠的IP服務(wù)，但它卻提供了一種可靠的傳輸層服務(wù)。

2022/11/21圖1.10TCP段格式

2022/11/21

·

源端口(SourcePort)：16位的源端口字段指發(fā)起通信的端口號(hào)，它和IP首部中的源IP地址的作用是標(biāo)識(shí)發(fā)送報(bào)文的計(jì)算機(jī)及應(yīng)用程序。

·

目的端口(DestinationPort)：16位的目的端口字段定義了傳輸?shù)哪康牡囟丝谔?hào)，它和IP首部中的目的IP地址的作用是標(biāo)識(shí)接收?qǐng)?bào)文的計(jì)算機(jī)及應(yīng)用程序。

2022/11/21

·

序號(hào)(InitialSequenceNumber，ISN)：該序號(hào)是32bit的無(wú)符號(hào)數(shù)，到達(dá)232－1后又從0開始，表示在這個(gè)報(bào)文段中的第一個(gè)數(shù)據(jù)字節(jié)的編號(hào)。如果將字節(jié)流看作在兩個(gè)應(yīng)用程序間的單向流動(dòng)，則TCP用序號(hào)字段對(duì)每個(gè)字節(jié)進(jìn)行計(jì)數(shù)。在動(dòng)態(tài)路由網(wǎng)絡(luò)中，報(bào)文很可能使用不同的路由，因此，報(bào)文可能亂序。利用序號(hào)字段可以糾正傳輸導(dǎo)致的亂序，從而重組分段的報(bào)文。

·

當(dāng)建立一個(gè)新的連接時(shí)，SYN標(biāo)志(下文介紹)置1。序號(hào)字段包含由這個(gè)主機(jī)選擇的該連接的ISN。該主機(jī)要發(fā)送數(shù)據(jù)的第一個(gè)字節(jié)序號(hào)為該ISN加1，因?yàn)镾YN標(biāo)志消耗了一個(gè)序號(hào)。

2022/11/21

·

確認(rèn)序號(hào)(AcknowledgmentNumber)：TCP使用32位的確認(rèn)序號(hào)標(biāo)識(shí)下一個(gè)希望收到的報(bào)文的第一個(gè)字節(jié)的編號(hào)。因此，確認(rèn)序號(hào)應(yīng)當(dāng)是上次已成功收到的數(shù)據(jù)字節(jié)序號(hào)加1。只有ACK標(biāo)志(下文介紹)置1時(shí)確認(rèn)序號(hào)字段才有效。發(fā)送ACK無(wú)需任何代價(jià)，因此，一旦連接建立，該字段總是被設(shè)置，ACK標(biāo)志也總是置1。

·

首部長(zhǎng)度(DataOffset)：長(zhǎng)為4位，該字段以字為單位計(jì)量TCP頭長(zhǎng)度。

·

保留(ReservedBits)：該字段是6位恒為0的域，為將來(lái)定義新的用途保留。

2022/11/21·

URG：緊急指針有效?！?/p>

ACK：確認(rèn)序號(hào)有效?！?/p>

PSH：接收方應(yīng)該盡快將這個(gè)報(bào)文段交給應(yīng)用層?！?/p>

RST：重置連接?！?/p>

SYN：同步序號(hào)，用來(lái)發(fā)起一個(gè)連接?！?/p>

FIN：發(fā)送端完成發(fā)送任務(wù)。

2022/11/21

·

窗口(Window)：該16位字段表明接收端聲明可以接收的TCP數(shù)據(jù)段的大小，最大為65535字節(jié)。窗口大小為字節(jié)數(shù)，起始于確認(rèn)序號(hào)字段指明的值，這個(gè)值是接收端期望接收的字節(jié)數(shù)。

·

校驗(yàn)和(Checksum)：該16位字段是一個(gè)強(qiáng)制性的字段，由發(fā)送端計(jì)算存儲(chǔ)，由接收端進(jìn)行驗(yàn)證。校驗(yàn)和對(duì)整個(gè)TCP報(bào)文段進(jìn)行，包括TCP首部和TCP數(shù)據(jù)。如果收到的內(nèi)容沒(méi)有被改變過(guò)，雙方的計(jì)算結(jié)果應(yīng)完全一樣，保證了數(shù)據(jù)的有效性。

2022/11/21

·

緊急指針(UrgentPoint)：只有當(dāng)URG標(biāo)志置1時(shí)16位的緊急指針字段才有效。緊急指針是一個(gè)正的偏移量，和序號(hào)字段中的值相加表示緊急數(shù)據(jù)最后一個(gè)字節(jié)的序號(hào)。TCP的緊急方式是發(fā)送端向另一端發(fā)送緊急數(shù)據(jù)的一種方式。

·選項(xiàng)(Option)：常見的可選字段是最長(zhǎng)報(bào)文大小(MSS，MaximumSegmentSize)。每個(gè)連接方通常都在通信的第一個(gè)報(bào)文段(為建立連接而設(shè)置SYN標(biāo)志的那個(gè)段)中指明這個(gè)選項(xiàng)，指明本端所能接收的最大長(zhǎng)度的報(bào)文段。

2022/11/21

·

數(shù)據(jù)(Data)：TCP段的數(shù)據(jù)部分是可選的。在連接建立和連接終止時(shí)，雙方交換的TCP段僅有首部。如果一方?jīng)]有數(shù)據(jù)要發(fā)送，仍然發(fā)送一個(gè)沒(méi)有任何數(shù)據(jù)的首部來(lái)確認(rèn)收到的數(shù)據(jù)。在處理超時(shí)的許多情況中，也會(huì)發(fā)送不帶任何數(shù)據(jù)的報(bào)文段。

TCP提供了一個(gè)完全可靠的、面向連接的、全雙工的流傳輸服務(wù)。允許兩個(gè)應(yīng)用程序建立一個(gè)連接，并在每一個(gè)方向上發(fā)送數(shù)據(jù)，然后終止連接，每一個(gè)TCP連接可靠地建立完善的終止，在終止發(fā)生前，所有數(shù)據(jù)都會(huì)被可靠地傳送。可靠傳輸服務(wù)軟件所應(yīng)具有的特征如下：

2022/11/21

(1)面向數(shù)據(jù)流：數(shù)據(jù)流(stream)就是兩個(gè)應(yīng)用程序間傳輸?shù)臄?shù)據(jù)。

(2)電路連接：包括連接的建立、通信的開始及連接的結(jié)束都要求所建立的連接是可靠的，連接的結(jié)束要完美(在連接終止前傳送的所有數(shù)據(jù)均為可靠的)。

(3)帶緩沖的傳送。

(4)無(wú)結(jié)構(gòu)的數(shù)據(jù)流，即不考慮數(shù)據(jù)內(nèi)容。

(5)全雙工連接：包含兩個(gè)獨(dú)立且方向相反的連接。

2022/11/21

TCP提供一個(gè)可靠連接的方式是通過(guò)三次握手(Three-wayHandshake)來(lái)完成的。三次握手是指通信雙方彼此交換三次信息。三次握手是在存在包丟失、重復(fù)和延遲的情況下，確保通信雙方信息交換確定性的充分必要條件。三次握手的操作過(guò)程如圖1.11所示。

2022/11/21圖1.11建立連接的三次握手機(jī)制

2022/11/21

(1)請(qǐng)求端(通常稱為客戶)發(fā)送一個(gè)SYN段，指明客戶打算連接的服務(wù)器的端口以及初始序號(hào)(SEQ)。這個(gè)SYN段為報(bào)文段1。

(2)服務(wù)器發(fā)回包含服務(wù)器的初始序號(hào)的SYN報(bào)文段(報(bào)文段2)作為應(yīng)答。同時(shí)，將確認(rèn)序號(hào)設(shè)置為客戶的ISN加1，用以對(duì)客戶的SYN報(bào)文段進(jìn)行確認(rèn)。一個(gè)SYN占用一個(gè)序號(hào)。

(3)客戶必須將確認(rèn)序號(hào)設(shè)置為服務(wù)器的ISN加1，用以對(duì)服務(wù)器的SYN報(bào)文段進(jìn)行確認(rèn)(報(bào)文段3)。

2022/11/21上述三個(gè)過(guò)程依次完成，即表明建立了TCP連接。建立一個(gè)TCP連接需要三次握手，而正常終止一個(gè)連接要經(jīng)過(guò)四次握手，這是由TCP的半關(guān)閉(half-close)特性造成的。由于TCP是全雙工連接，每個(gè)方向的連接必須單獨(dú)關(guān)閉，因此當(dāng)一方完成數(shù)據(jù)發(fā)送任務(wù)后必須發(fā)送一個(gè)FIN標(biāo)志來(lái)終止這個(gè)方向的連接。當(dāng)一端收到一個(gè)FIN后，必須通知應(yīng)用層另一端已經(jīng)終止了該方向的數(shù)據(jù)傳送。發(fā)送FIN通常是應(yīng)用層關(guān)閉連接的結(jié)果。

TCP連接收到一個(gè)FIN標(biāo)志只意味著對(duì)方已不再發(fā)送數(shù)據(jù)，但己方仍能發(fā)送數(shù)據(jù)，這是半關(guān)閉型應(yīng)用。正常關(guān)閉過(guò)程如圖1.12所示。

2022/11/21圖1.12中的報(bào)文段1發(fā)起終止連接，TCP客戶端發(fā)送一個(gè)FIN，用來(lái)關(guān)閉從客戶機(jī)到服務(wù)器的數(shù)據(jù)傳送。當(dāng)服務(wù)器收到這個(gè)FIN時(shí)，它發(fā)回一個(gè)ACK，確認(rèn)序號(hào)為收到的序號(hào)加1(報(bào)文段2)。和SYN一樣，一個(gè)FIN占用一個(gè)序號(hào)，同時(shí)TCP服務(wù)器還向應(yīng)用程序傳送一個(gè)文件結(jié)束符。接著這個(gè)服務(wù)器程序就關(guān)閉它的連接，TCP端發(fā)送一個(gè)FIN(報(bào)文段3)，客戶必須發(fā)回一個(gè)確認(rèn)，并將確認(rèn)序號(hào)設(shè)置為收到的序號(hào)加1(報(bào)文段4)。

2022/11/21圖1.12終止連接的四次握手機(jī)制

2022/11/21

4.UDP

UDP(UserDatagramProtocol)即用戶數(shù)據(jù)報(bào)協(xié)議，它屬于面向無(wú)連接、不可靠傳輸?shù)念愋?。該協(xié)議只負(fù)責(zé)接收和傳送由上層協(xié)議傳遞的消息，它本身不做任何檢測(cè)、修改與應(yīng)答，上層協(xié)議需要自己處理這些事務(wù)。

UDP的報(bào)頭格式較簡(jiǎn)單，主要是地址信息、包的長(zhǎng)度和校驗(yàn)信息。與此對(duì)應(yīng)，TCP包的頭信息有10多個(gè)域。因此，UDP的網(wǎng)絡(luò)開銷一般要小于TCP。由于UDP在傳送數(shù)據(jù)過(guò)程中沒(méi)有建立連接，亦不進(jìn)行檢查，因此在良好的網(wǎng)絡(luò)環(huán)境中，其工作效率較TCP要高。由于UDP的這種特點(diǎn)，因此它也是進(jìn)行網(wǎng)絡(luò)廣播的首選協(xié)議。UDP的報(bào)頭格式如圖1.13所示。

2022/11/21圖1.13UDP數(shù)據(jù)報(bào)首部

2022/11/21

·

源端口(SourcePort)：16位的源端口是發(fā)送端上的連接端口，它和IP首部中的源IP地址的作用是標(biāo)識(shí)發(fā)送UDP報(bào)文的計(jì)算機(jī)及應(yīng)用程序。

·

目的端口(DestinationPort)：16位的目的端口是接收端上的連接端口，它和IP首部中的目的IP地址的作用是標(biāo)識(shí)接收?qǐng)?bào)文的計(jì)算機(jī)及應(yīng)用程序。

·

報(bào)文長(zhǎng)度(TotalLength)：報(bào)文長(zhǎng)度字段為16位，存儲(chǔ)UDP首部和UDP數(shù)據(jù)的字節(jié)長(zhǎng)度，最小值為8字節(jié)。

·校驗(yàn)和(Checksum)：16位的校驗(yàn)和字段存儲(chǔ)基于報(bào)文的內(nèi)容計(jì)算得到的錯(cuò)誤檢查信息。接收端執(zhí)行和發(fā)送端相同的數(shù)學(xué)計(jì)算，若兩個(gè)計(jì)算值不同則表明報(bào)文在傳輸過(guò)程中出現(xiàn)了錯(cuò)誤。

2022/11/21理論上，IP數(shù)據(jù)報(bào)的最大長(zhǎng)度為65535字節(jié)，這是由IP首部16位字段所限制的。去除20字節(jié)的IP首部和8個(gè)字節(jié)的UDP首部，UDP數(shù)據(jù)報(bào)中用戶數(shù)據(jù)的最大長(zhǎng)度為65507字節(jié)。但大多數(shù)實(shí)現(xiàn)所提供的長(zhǎng)度比這個(gè)最大值小，這主要是因?yàn)榇嬖趦蓚€(gè)限制因素：一個(gè)是因?yàn)閼?yīng)用程序可能會(huì)受到其程序接口的限制，SocketAPI提供了一個(gè)可供應(yīng)用程序調(diào)用的函數(shù)，以設(shè)置接收和發(fā)送緩存的長(zhǎng)度。現(xiàn)在的大部分系統(tǒng)都默認(rèn)提供了可讀/寫大于8192字節(jié)的UDP數(shù)據(jù)報(bào)。另一個(gè)限制來(lái)自于TCP/IP的內(nèi)核，不同的系統(tǒng)可能存在一些實(shí)現(xiàn)特性的差異，使IP數(shù)據(jù)報(bào)長(zhǎng)度小于65535字節(jié)。

2022/11/21

5.ARP/RARP

ARP(AddressResolutionProtocol，地址解析協(xié)議)和RARP(ReverseAddressResolutionProtocol，逆向地址解析協(xié)議)是某些網(wǎng)絡(luò)接口(如以太網(wǎng)和令牌環(huán)網(wǎng))使用的特殊協(xié)議，用來(lái)轉(zhuǎn)換IP層和網(wǎng)絡(luò)接口層使用的地址。

2022/11/21每一塊網(wǎng)卡(NIC，NetworkInterfaceCard)都有一個(gè)唯一的硬件地址(是由網(wǎng)卡的生產(chǎn)廠商設(shè)置的，需要使用特殊的方式才可以修改)。這個(gè)硬件地址稱為MAC(MediumAccessControl，媒體訪問(wèn)控制)。一塊網(wǎng)卡依據(jù)數(shù)據(jù)幀的包頭信息中是否寫有它的MAC地址來(lái)決定是否接受并上傳該幀。分配給主機(jī)使用的IP地址和它固有的MAC地址是互不相干的。IP地址只對(duì)TCP/IP有效，MAC地址只對(duì)網(wǎng)絡(luò)訪問(wèn)層有意義。在物理網(wǎng)絡(luò)上的數(shù)據(jù)幀交換依賴于MAC地址，ARP實(shí)現(xiàn)了從IP地址到MAC地址的映射，而RARP負(fù)責(zé)根據(jù)NIC硬件地址去查詢對(duì)應(yīng)的IP地址。

2022/11/21假設(shè)在一個(gè)以太網(wǎng)中，客戶端要將一個(gè)IP報(bào)文發(fā)送到服務(wù)器端，那么客戶端必須把32位的IP地址轉(zhuǎn)換成48位的以太網(wǎng)地址。

(1)?ARP以廣播的方式發(fā)送ARPRequest數(shù)據(jù)幀給以太網(wǎng)上的每個(gè)主機(jī)，ARP請(qǐng)求數(shù)據(jù)幀中包含目的主機(jī)的IP地址，意思是“如果你是這個(gè)IP地址的擁有者，請(qǐng)回答你的硬件地址”。

(2)目的主機(jī)的ARP層收到這份廣播報(bào)文后，識(shí)別出這是發(fā)送端在詢問(wèn)它的IP地址，于是發(fā)送一個(gè)ARP應(yīng)答。這個(gè)ARP應(yīng)答包含IP地址及對(duì)應(yīng)的硬件地址。

2022/11/21

(3)收到ARP應(yīng)答后，主機(jī)間通過(guò)使用ARP協(xié)議獲得的硬件地址進(jìn)行通信。

ARP要求網(wǎng)絡(luò)接口有一個(gè)硬件地址。在硬件上進(jìn)行的數(shù)據(jù)幀交換必須有正確的接口地址。TCP/IP的地址是32位的IP地址。僅知道主機(jī)的IP地址并不能讓內(nèi)核(如以太網(wǎng)驅(qū)動(dòng)程序)發(fā)送數(shù)據(jù)幀給主機(jī)，內(nèi)核必須知道目的端的硬件地址才能發(fā)送數(shù)據(jù)。ARP的功能是指在32位的IP地址和采用不同網(wǎng)絡(luò)技術(shù)的硬件地址之間提供動(dòng)態(tài)映射。

2022/11/21

ARP中規(guī)定了兩種信息的基本類型：請(qǐng)求(Request)和應(yīng)答(Response)。在以太網(wǎng)上解析IP地址時(shí)，ARP請(qǐng)求和應(yīng)答分組的格式如圖1.14所示(ARP亦可用于解析其他類型網(wǎng)絡(luò)的IP地址以外的地址，緊跟著幀類型字段的前四個(gè)字段決定了最后四個(gè)字段的類型和長(zhǎng)度)。

·

源地址(DestinationAddress)：該48位字段存儲(chǔ)以太網(wǎng)的源地址。

·

目的地址(SourceAddress)：該48位字段存儲(chǔ)以太網(wǎng)的目的地址。

·

幀類型(FrameType)：該16位字段存儲(chǔ)以太網(wǎng)數(shù)據(jù)幀類型，表示后面數(shù)據(jù)的類型。對(duì)于ARP協(xié)議，該字段的值為0x0806。

2022/11/21圖1.14以太網(wǎng)傳輸?shù)腁RP請(qǐng)求和應(yīng)答分組格式

2022/11/21硬件類型(HardwareType)：該16位字段識(shí)別硬件接口類型，0x0001表示以太網(wǎng)接口，其他接口對(duì)應(yīng)的值如表1.3所示。

表1.3硬件接口類型一覽表

2022/11/21

·

協(xié)議類型(ProtocolType)：該16位字段標(biāo)識(shí)發(fā)送設(shè)備所使用的協(xié)議類型。通常它的值為0x0800，即表示使用IP，它的值與包含IP數(shù)據(jù)報(bào)的以太網(wǎng)數(shù)據(jù)幀中的幀類型字段的值相同，這在協(xié)議設(shè)計(jì)時(shí)是有意為之的。

·

硬件地址長(zhǎng)度(LengthofHardwareAddress)：該8位字段表示硬件地址長(zhǎng)度。

·

協(xié)議地址長(zhǎng)度(LengthofProtocolAddress)：該8位字段表示協(xié)議地址長(zhǎng)度。上述兩個(gè)字段以字節(jié)為單位，對(duì)于以太網(wǎng)上IP地址的ARP請(qǐng)求或應(yīng)答來(lái)說(shuō)，它們的值分別為6和4，表明硬件地址即MAC地址為6字節(jié)，協(xié)議地址即IP地址為4字節(jié)。

2022/11/21

·

操作類型(Opcode)：該16位字段用以區(qū)分協(xié)議的四種操作類型，即ARP請(qǐng)求(值為1)、ARP應(yīng)答(值為2)、RARP請(qǐng)求(值為3)和RARP應(yīng)答(值為4)。ARP請(qǐng)求和ARP應(yīng)答的幀類型字段值是相同的，因此必須用操作類型字段將其區(qū)分。

·

發(fā)送端硬件地址(Sender’sHardwareAddress)：該48位字段存儲(chǔ)發(fā)送端的硬件地址。

·

發(fā)送端協(xié)議地址(Sender’sProtocolAddress)：該32位字段存儲(chǔ)發(fā)送端的協(xié)議地址。

·

目的端硬件地址(TargetHardwareAddress)：該48位字段存儲(chǔ)目的端的硬件地址。目的端協(xié)議地址(TargetProtocolAddress)：該32位字段存儲(chǔ)目的端的協(xié)議地址。

2022/11/21對(duì)于一個(gè)ARP請(qǐng)求來(lái)說(shuō)，除目的端的硬件地址外的所有其他字段都有填充值。當(dāng)系統(tǒng)收到一份目的端為本機(jī)的ARP請(qǐng)求報(bào)文后，首先把硬件地址填進(jìn)去，然后用兩個(gè)目的端地址分別替換兩個(gè)發(fā)送端地址，并把Opcode置為2，最后把它發(fā)送回去。

2022/11/21

6.ICMP

ICMP全稱為InternetControlMessageProtocol，即Internet控制報(bào)文協(xié)議。ICMP是IP的附屬協(xié)議，IP用它來(lái)與其他主機(jī)或路由器交換錯(cuò)誤報(bào)文和其他一些網(wǎng)絡(luò)情況。在ICMP包中攜帶了控制信息和故障恢復(fù)信息，這些信息可以用于以下幾方面：源抑制：這是一個(gè)流控制信息，由接收方向源主機(jī)發(fā)送該信息來(lái)請(qǐng)求源主機(jī)停止發(fā)送數(shù)據(jù)。當(dāng)接收主機(jī)在其緩沖區(qū)快滿時(shí)發(fā)送該信息。

2022/11/21

·

路徑重定向：由網(wǎng)關(guān)向請(qǐng)求其提供服務(wù)的主機(jī)發(fā)送，用于通知該主機(jī)在網(wǎng)絡(luò)中還有其他距離目的主機(jī)更近的網(wǎng)關(guān)。

·

主機(jī)不可到達(dá)：在網(wǎng)絡(luò)狀況不佳的網(wǎng)絡(luò)中傳送數(shù)據(jù)報(bào)時(shí)，發(fā)生故障(如鏈路失效、鏈路堵塞、主機(jī)失效等)的網(wǎng)關(guān)或者系統(tǒng)會(huì)發(fā)出此消息。在ICMP報(bào)文中通常包括失效的原因。

·應(yīng)答請(qǐng)求與回復(fù)：用Ping來(lái)檢測(cè)目標(biāo)主機(jī)是否可以到達(dá)。Ping指令調(diào)用ICMP消息的應(yīng)答請(qǐng)求功能發(fā)送數(shù)據(jù)報(bào)，如果遠(yuǎn)程主機(jī)是可以到達(dá)的，則該系統(tǒng)會(huì)用應(yīng)答回復(fù)功能來(lái)響應(yīng)。

2022/11/21圖1.15ICMP數(shù)據(jù)在IP數(shù)據(jù)報(bào)中的封裝

2022/11/21類型字段可以有15個(gè)不同的值，以描述特定類型的ICMP報(bào)文。某些ICMP報(bào)文還使用代碼字段的值來(lái)進(jìn)一步描述不同的條件。檢驗(yàn)和字段覆蓋整個(gè)ICMP報(bào)文。對(duì)于ICMP報(bào)文來(lái)說(shuō)，檢驗(yàn)和是必需的。

ICMP的報(bào)文類型由報(bào)文中的類型字段和代碼字段來(lái)共同決定，如表1.4所示。

2022/11/21表1.4ICMP報(bào)文類型

2022/11/21表1.4ICMP報(bào)文類型

2022/11/21為了防止由于ICMP差錯(cuò)報(bào)文響應(yīng)所引發(fā)的廣播風(fēng)暴，協(xié)議規(guī)定當(dāng)接收端收到下列報(bào)文時(shí)不會(huì)產(chǎn)生ICMP差錯(cuò)報(bào)文：

(1)?ICMP差錯(cuò)報(bào)文(但I(xiàn)CMP查詢報(bào)文可能會(huì)產(chǎn)生ICMP差錯(cuò)報(bào)文)。

(2)目的地址是廣播地址或多播地址的IP數(shù)據(jù)報(bào)。

(3)作為鏈路層廣播的數(shù)據(jù)報(bào)。

(4)不是IP數(shù)據(jù)報(bào)第一個(gè)分片的數(shù)據(jù)報(bào)。

(5)源地址不是單個(gè)主機(jī)的數(shù)據(jù)報(bào)。這就是說(shuō)，源地址不能為零地址、環(huán)回地址、廣播地址或多播地址。

2022/11/21下面介紹原始套接字編程中常用的三類ICMP報(bào)文。

·

回應(yīng)請(qǐng)求和回應(yīng)應(yīng)答報(bào)文?；貞?yīng)請(qǐng)求和回應(yīng)應(yīng)答報(bào)文經(jīng)常用來(lái)判斷一個(gè)特定的主機(jī)是否處于活動(dòng)狀態(tài)，并且是否可以通過(guò)網(wǎng)絡(luò)訪問(wèn)到。回應(yīng)請(qǐng)求和回應(yīng)應(yīng)答報(bào)文的格式如圖1.16所示。

2022/11/21圖1.16回應(yīng)請(qǐng)求和回應(yīng)應(yīng)答報(bào)文

2022/11/21

·

ICMP地址掩碼請(qǐng)求和應(yīng)答報(bào)文。

ICMP地址掩碼請(qǐng)求用于無(wú)盤系統(tǒng)在引導(dǎo)過(guò)程中獲取自己的子網(wǎng)掩碼并系統(tǒng)廣播它的ICMP請(qǐng)求報(bào)文。ICMP地址掩碼請(qǐng)求和應(yīng)答報(bào)文的格式如圖1.17所示。

圖1.17ICMP地址掩碼請(qǐng)求和應(yīng)答報(bào)文

2022/11/21

·

ICMP時(shí)間戳請(qǐng)求和應(yīng)答報(bào)文。

ICMP時(shí)間戳請(qǐng)求允許系統(tǒng)向另一個(gè)系統(tǒng)查詢當(dāng)前的時(shí)間。返回的建議值是自午夜開始計(jì)算的毫秒數(shù)。這種ICMP報(bào)文的好處是它提供了毫秒級(jí)的分辨率，而利用其他方法從別的主機(jī)獲取的時(shí)間只能提供秒級(jí)的分辨率。由于返回的時(shí)間是從午夜開始計(jì)算的，因此調(diào)用者必須通過(guò)其他方法獲知當(dāng)時(shí)的日期。ICMP時(shí)間戳請(qǐng)求和應(yīng)答報(bào)文的格式如圖1.18所示。

2022/11/21圖1.18ICMP時(shí)間戳請(qǐng)求和應(yīng)答報(bào)文

2022/11/211.1.4進(jìn)程/應(yīng)用層協(xié)議

1.Telnet協(xié)議

Telnet是網(wǎng)絡(luò)虛擬終端協(xié)議的一個(gè)典型例子，該協(xié)議允許用戶通過(guò)Internet登錄到遠(yuǎn)程計(jì)算機(jī)中?？蛻舫绦蛐枰约簩?shí)現(xiàn)Telnet協(xié)議，同時(shí)在某些鍵以及顯示的特性上，不同的終端類型定義是不一樣的，目前的大多數(shù)終端支持DEC的VT100終端類型。在進(jìn)行Telnet協(xié)議的實(shí)現(xiàn)時(shí)，工作量最大的還在于使自己的客戶程序適應(yīng)不同的終端類型上。

2022/11/21

2.FTP協(xié)議

FTP(FileTransferProtocol)即文件傳輸協(xié)議。在該協(xié)議中，要求使用者是經(jīng)過(guò)授權(quán)的用戶，從而使文件的訪問(wèn)具有一定的安全限制。由于FTP口令在網(wǎng)絡(luò)上是以明文傳輸?shù)模虼艘坏┍槐O(jiān)聽泄密就會(huì)威脅到系統(tǒng)安全。許多站點(diǎn)也提供匿名FTP服務(wù)(AnonymousFTP)，在這類站點(diǎn)上，通常的登錄用戶名為Anonymous，口令按照慣例是Guest，也可以是用戶的E-mail地址。

2022/11/21

3.HTTP協(xié)議

HTTP(HyperTextTransferProtocol，超文本傳輸協(xié)議)是WWW服務(wù)程序所用的協(xié)議，也是目前在Internet中使用最廣泛的協(xié)議。HTTP客戶端包括InternetExplorer、NetscapeNavigator、Opera、Mozilla等。通過(guò)WWW方式，可以進(jìn)行信息查詢、文件下載、訪問(wèn)WWW方式的E-mail、在線聊天等，功能非常強(qiáng)大。

2022/11/21

4.SMTP與POP3協(xié)議

SMTP是SimpleMailTransferProtocol的縮寫，即簡(jiǎn)單郵件傳輸協(xié)議。POP3是PostOfficeProtocol3的縮寫，即郵局協(xié)議。通過(guò)這兩個(gè)協(xié)議就可以實(shí)現(xiàn)E-mail的收發(fā)功能。

5.DNS

DNS(DomainNameService，域名服務(wù))實(shí)現(xiàn)了由主機(jī)名到IP地址的映射功能。

2022/11/211.2網(wǎng)絡(luò)編程應(yīng)考慮的問(wèn)題

1.2.1并發(fā)環(huán)境下的網(wǎng)絡(luò)編程單進(jìn)程應(yīng)用與多進(jìn)程或多線程應(yīng)用程序的編程有著很大的區(qū)別。在多進(jìn)程或多線程應(yīng)用程序中，涉及到資源共享、進(jìn)程或線程間的同步，因而要復(fù)雜得多。在多進(jìn)程或多線程應(yīng)用中，使用的系統(tǒng)調(diào)用或函數(shù)必須是可重入的。不同系統(tǒng)中可重入的系統(tǒng)調(diào)用或系統(tǒng)函數(shù)是不同的，一般都會(huì)有詳細(xì)的說(shuō)明。對(duì)于那些不可重入的調(diào)用或函數(shù)，系統(tǒng)如果不提供多線程安全的版本，則應(yīng)用編程人員需要避免使用或自己編寫相應(yīng)的函數(shù)。

2022/11/21在多線程應(yīng)用中，對(duì)調(diào)用或函數(shù)的使用有很多限制。例如在Solaris2.5中，在Solaris線程中訪問(wèn)定界數(shù)據(jù)會(huì)導(dǎo)致總線錯(cuò)誤。在Solaris操作系統(tǒng)中，在一個(gè)線程中關(guān)閉另一個(gè)線程正在使用的網(wǎng)絡(luò)端口會(huì)導(dǎo)致應(yīng)用程序“死掉”，而這種情況在DigitalUNIX(后稱為Tru64UNIX)中則不會(huì)出現(xiàn)。因此，在多進(jìn)程或多線程應(yīng)用中，需要仔細(xì)考慮這些限制。

2022/11/211.2.2異構(gòu)環(huán)境下的網(wǎng)絡(luò)編程

1.字節(jié)順序不同的平臺(tái)以不同的方式存放一個(gè)二進(jìn)制數(shù)。最常見的有兩種格式：大數(shù)在前(big-endian)的字節(jié)順序和小數(shù)在前(little-endian)的字節(jié)順序。大數(shù)在前的字節(jié)順序是指將一個(gè)多字節(jié)數(shù)的高序字節(jié)存儲(chǔ)在內(nèi)存的起始地址；而小數(shù)在前的字節(jié)順序則相反，將低序字節(jié)存儲(chǔ)在內(nèi)存的起始地址。在操作系統(tǒng)中，IBMAIX、SunOS、HPUNIX、Solaris采用大數(shù)在前的字節(jié)順序；而DigitalUNIX、Linux、BSDi、SystemⅤ4、DOS、Windows9x/2000/NT則采用的是小數(shù)在前的字節(jié)順序。同一數(shù)值在具有不同字節(jié)順序的平臺(tái)上的表示剛好相反。因此，作為網(wǎng)絡(luò)編程人員，必須清楚各種字節(jié)順序間的區(qū)別，并采用相應(yīng)的措施來(lái)解決因這種差別所帶來(lái)的問(wèn)題。

2022/11/21

2.字的長(zhǎng)度不同的實(shí)現(xiàn)對(duì)于相同的數(shù)據(jù)類型可能有不同的表示長(zhǎng)度。例如32位和64位操作系統(tǒng)中，類型longint的長(zhǎng)度是不一樣的。在DigitalUNIX中的longint的長(zhǎng)度為8字節(jié)，而在Solaris中則為4字節(jié)。對(duì)shortint或int等數(shù)據(jù)類型的大小也沒(méi)有確定的規(guī)定。

2022/11/21

3.字節(jié)定界問(wèn)題不同的平臺(tái)上為結(jié)構(gòu)體(struct)或共同體(union)打包的方式也是不同的，這取決于所有數(shù)據(jù)類型的位數(shù)及機(jī)器的定界限制。一般情況下，操作系統(tǒng)在分配內(nèi)存時(shí)，數(shù)據(jù)結(jié)構(gòu)以4字節(jié)定界。例如，在很多系統(tǒng)中，默認(rèn)情況下結(jié)構(gòu)體struct{chara;intb}的長(zhǎng)度為8而不是5，只有在1字節(jié)定界的情況下其長(zhǎng)度才為5。為解決該問(wèn)題，對(duì)于具有相同字節(jié)順序的平臺(tái)，可以令通信雙方均以單字節(jié)定界。

2022/11/21另一種解決該問(wèn)題的方法是將需要發(fā)送的信息的結(jié)構(gòu)在發(fā)送前變換成一種統(tǒng)一的格式(轉(zhuǎn)換成一個(gè)字符數(shù)組)，到達(dá)接收方后再執(zhí)行相反的過(guò)程。對(duì)于數(shù)據(jù)結(jié)構(gòu)中有比特變量的情況，處理起來(lái)更加復(fù)雜，因此，在實(shí)際網(wǎng)絡(luò)編程中盡量不要使用比特變量。在很多網(wǎng)絡(luò)協(xié)議的設(shè)計(jì)中，常常需要填充一些無(wú)用的字節(jié)以滿足四字節(jié)定界，從而簡(jiǎn)化協(xié)議的實(shí)現(xiàn)。

2022/11/211.2.3阻塞與非阻塞通信通信包括阻塞和非阻塞兩種模式。在網(wǎng)絡(luò)編程時(shí)，選擇通信模式是一件很重要的事情。對(duì)于不同的協(xié)議，阻塞通信和非阻塞通信有不同的表現(xiàn)。以插口為例，在阻塞模式下，利用TCP協(xié)議發(fā)送一個(gè)報(bào)文時(shí)，如果低層協(xié)議沒(méi)有可用空間來(lái)存放用戶數(shù)據(jù)，則應(yīng)用進(jìn)程將阻塞等待直到協(xié)議有可用的空間。而在非阻塞模式下，調(diào)用將直接返回而不需等待。在應(yīng)用進(jìn)程調(diào)用接收函數(shù)接收?qǐng)?bào)文時(shí)，如果是在阻塞模式下，若沒(méi)有到達(dá)的數(shù)據(jù)，則調(diào)用將一直阻塞直到有數(shù)據(jù)到達(dá)或出錯(cuò)；而在非阻塞模式下，將直接返回而不需等待。

2022/11/21對(duì)于UDP協(xié)議而言，由于UDP沒(méi)有發(fā)送緩存，因此所有UDP協(xié)議即使在阻塞模式下也不會(huì)發(fā)生阻塞。對(duì)于面向連接的協(xié)議，在連接建立階段，阻塞與非阻塞也表現(xiàn)不一。在阻塞模式下，如果沒(méi)有連接請(qǐng)求到達(dá)，則等待連接調(diào)用將阻塞直到有連接請(qǐng)求到達(dá)；但在非阻塞模式下，如果沒(méi)有連接請(qǐng)求到達(dá)，等待連接調(diào)用將直接返回。

2022/11/21在連接建立階段，不管是阻塞模式還是非阻塞模式，發(fā)起連接請(qǐng)求的一方總是會(huì)使調(diào)用它的進(jìn)程阻塞，阻塞間隔最少等于到達(dá)服務(wù)器的一次往返時(shí)間。不同操作系統(tǒng)下，在非阻塞模式下，不能完成的I/O操作返回的錯(cuò)誤代碼也是不一樣的。例如，SystemⅤ返回EAGAIN錯(cuò)誤，而源自Berkeley的實(shí)現(xiàn)返回EWOULDBLOCK錯(cuò)誤。更混亂的是，Posix.1指定使用EAGAIN，而Posix.1g指定使用EWOULDBLOCK。大多數(shù)系統(tǒng)(包括SVR4和4.3BSD)將這兩個(gè)錯(cuò)誤代碼定義為相同的值。

2022/11/21通信模式對(duì)應(yīng)用程序的設(shè)計(jì)方法也有直接的影響。在非阻塞模式下，應(yīng)用程序必須不斷地輪詢是否有數(shù)據(jù)到達(dá)或有連接請(qǐng)求到達(dá)。這種輪詢的方式耗費(fèi)的CPU資源較大，要盡可能避免使用，或采用多路復(fù)用技術(shù)(調(diào)用select或poll函數(shù))來(lái)解決這一問(wèn)題。而在阻塞模式下則不存在這一問(wèn)題，但其缺點(diǎn)是進(jìn)程或線程在執(zhí)行I/O操作時(shí)將被阻塞而不能執(zhí)行其他的工作，因此在單進(jìn)程或單線程應(yīng)用中不能使用這種模式。在多線程應(yīng)用中比較適合采用阻塞模式，一個(gè)線程被阻塞不影響其他線程的工作。

2022/11/211.2.4服務(wù)類型的選擇

1.面向連接服務(wù)所謂連接，是指兩個(gè)對(duì)等實(shí)體為進(jìn)行數(shù)據(jù)通信而進(jìn)行的一種結(jié)合。面向連接服務(wù)要求在數(shù)據(jù)交換之前先建立連接；當(dāng)數(shù)據(jù)交換結(jié)束后終止該連接。一般來(lái)說(shuō)，面向連接服務(wù)過(guò)程分為三個(gè)階段：連接建立、數(shù)據(jù)傳輸和連接釋放。在傳送數(shù)據(jù)時(shí)是按序傳送的。這點(diǎn)和電路交換的許多特性很相似，因此面向連接服務(wù)又稱為“虛電路服務(wù)”。面向連接服務(wù)比較適合于在一段時(shí)間間隔內(nèi)要向同一目的地發(fā)送許多報(bào)文的情況。對(duì)于發(fā)送很短的零星報(bào)文，則連接建立和釋放的開銷過(guò)大。

2022/11/21

2.無(wú)連接服務(wù)無(wú)連接服務(wù)指兩個(gè)實(shí)體之間的通信不需要先建立好一條連接，其所需的下層資源在數(shù)據(jù)傳輸時(shí)動(dòng)態(tài)地進(jìn)行分配。無(wú)連接服務(wù)的另一個(gè)特征是它不需要通信的兩個(gè)實(shí)體同時(shí)是活躍的。只有發(fā)送端的實(shí)體正在進(jìn)行發(fā)送時(shí)，它才必須是活躍的。而接收端的實(shí)體只有在進(jìn)行接收操作時(shí)才必須是活躍的。無(wú)連接服務(wù)的優(yōu)點(diǎn)是靈活方便和效率高；但它不能防止報(bào)文的丟失、重復(fù)或失序，該問(wèn)題必須由應(yīng)用程序根據(jù)需要自行解決。無(wú)連接服務(wù)特別適合于傳送少量零星的報(bào)文。

2022/11/21無(wú)連接服務(wù)又可分為以下三種類型：

·

數(shù)據(jù)報(bào)(datagram)：它的特點(diǎn)是不需要接收端做任何響應(yīng)，因而是一種不可靠的服務(wù)。數(shù)據(jù)報(bào)常被描述為“盡最大努力交付”(besteffortdelivery)。在TCP/IP協(xié)議棧中，由UDP協(xié)議提供數(shù)據(jù)報(bào)服務(wù)。

·證實(shí)交付(confirmeddelivery)：又被稱為可靠的數(shù)據(jù)報(bào)。這種服務(wù)對(duì)每一個(gè)報(bào)文由提供服務(wù)的協(xié)議層產(chǎn)生一個(gè)證實(shí)給發(fā)方，這種證實(shí)只能保證報(bào)文已經(jīng)發(fā)送給遠(yuǎn)端目的站了，但并不能保證目的站用戶已收到這個(gè)報(bào)文。

2022/11/21

·請(qǐng)求應(yīng)答(request-reply)：這種類型的數(shù)據(jù)報(bào)是接收端的用戶每收到一個(gè)報(bào)文，就向發(fā)送端的用戶發(fā)送一個(gè)應(yīng)答報(bào)文。與“證實(shí)交付”的主要區(qū)別在于應(yīng)答是由接收端的用戶而不是提供服務(wù)的協(xié)議層發(fā)出的。事務(wù)處理(transaction)中的“一問(wèn)一答”方式的短報(bào)文以及數(shù)據(jù)庫(kù)中的查詢，都很適合使用這種類型的服務(wù)。

2022/11/21

3.兩種服務(wù)的比較表1.5列出了面向連接服務(wù)與無(wú)連接服務(wù)的主要區(qū)別。這些區(qū)別為網(wǎng)絡(luò)應(yīng)用編程選擇何種類型的服務(wù)提供了依據(jù)。

2022/11/21表1.5面向連接服務(wù)與無(wú)連接服務(wù)的比較

2022/11/211.2.5差錯(cuò)處理任何應(yīng)用程序均需進(jìn)行差錯(cuò)處理，即檢查函數(shù)返回的調(diào)用結(jié)果的正確性并做出相應(yīng)的處理。網(wǎng)絡(luò)應(yīng)用編程接口提供差錯(cuò)處理的基本設(shè)施，更高一級(jí)的差錯(cuò)處理需要應(yīng)用程序來(lái)實(shí)現(xiàn)。在UNIX系統(tǒng)中，有一個(gè)全局變量errno，每當(dāng)一個(gè)Unix函數(shù)(不僅僅是網(wǎng)絡(luò)應(yīng)用編程接口中的函數(shù))中出現(xiàn)差錯(cuò)時(shí)，errno將被置成一個(gè)指示錯(cuò)誤類型的正數(shù)，而函數(shù)本身則通常返回－1。

errno的值在函數(shù)發(fā)生錯(cuò)誤時(shí)設(shè)置。如果函數(shù)正確返回，則errno的值就無(wú)定義。在UNIX系統(tǒng)中，所有的錯(cuò)誤代碼都是常數(shù)值，在頭文件sys/errno.h中定義。

2022/11/21在一個(gè)進(jìn)程中共享所有全局變量的多線程編程不適宜采用把錯(cuò)誤代碼保存在全局變量errno中的方法。因此，在多線程環(huán)境中，每個(gè)線程必須有自己的errno變量。通常情況下，當(dāng)編譯時(shí)的程序指定為可重入時(shí)，即有編譯選項(xiàng)為-D_REENTRANT，編譯器缺省將errno.h頭文件中的errno宏擴(kuò)展為一個(gè)函數(shù)，由該函數(shù)訪問(wèn)errno變量局限于某個(gè)線程的副本，提供一個(gè)局限于線程的errno變量的隱式請(qǐng)求。在有些UNIX系統(tǒng)中，如DigitalUNIX，還有一個(gè)與錯(cuò)誤處理有關(guān)的全局變量sys_errlist[]，它是一個(gè)二維字符串?dāng)?shù)組，用錯(cuò)誤代碼作為數(shù)組的下標(biāo)即可得到該錯(cuò)誤代碼對(duì)應(yīng)的錯(cuò)誤報(bào)文。

2022/11/21習(xí)題與思考題（作業(yè)）

1.描述IEEE802.3MAC幀的結(jié)構(gòu)。不同的高層協(xié)議在幀的類型字段中的代碼是什么？

2.簡(jiǎn)述TCP/IP協(xié)議族的不同層中的各種協(xié)議及其作用。

3.簡(jiǎn)述IP數(shù)據(jù)報(bào)中各字段的含義。

4.簡(jiǎn)述并比較MAC地址、IP地址和端口的作用。

5.試舉例說(shuō)明網(wǎng)絡(luò)編程時(shí)可能遇到的問(wèn)題，并提出相應(yīng)的比較合理的解決方案。

2022/11/21《網(wǎng)絡(luò)編程（WinSock）》WinSock基礎(chǔ)2022/11/21第2章WinSock基礎(chǔ)2.1基本概念

2.2WinSock編程原理

2.3WinSockI/O模型

2.4WinSock2的擴(kuò)展特性

2.5套接字選項(xiàng)和I/O控制命令

習(xí)題與思考題

2022/11/212.1基

本

概

念

2.1.1套接字及類型套接字(socket)是網(wǎng)絡(luò)通信的基本構(gòu)件，是可以被命名和尋址的通信端點(diǎn)，使用中的每一個(gè)套接字都有其類型和與之相連的進(jìn)程。套接字存在于通信區(qū)域中，通信區(qū)域也稱地址族，是個(gè)抽象概念，主要用于將通過(guò)套接字通信的進(jìn)程的共有特性綜合在一起。套接字通常只與同一區(qū)域中的套接字交換數(shù)據(jù)(也可跨區(qū)域通信，但要執(zhí)行某種轉(zhuǎn)換進(jìn)程之后才能實(shí)現(xiàn))。WindowsSockets只支持一個(gè)通信區(qū)域：網(wǎng)際域(AF-INET)，這個(gè)域被使用網(wǎng)際協(xié)議族通信的進(jìn)程所使用。

2022/11/21套接字都具有不同類型，是根據(jù)用戶可見的通信特征進(jìn)行分類的。應(yīng)用程序被假定為只在同一類型的套接字間通信，不過(guò)只要通信協(xié)議支持，也可在不同類型的套接字間通信。

TCP/IP的socket提供三種類型的套接字：*流式套接字(SOCK_STREAM)：提供一個(gè)面向連接的、可靠的數(shù)據(jù)傳輸服務(wù)，數(shù)據(jù)無(wú)差錯(cuò)、無(wú)重復(fù)地發(fā)送，且按發(fā)送順序接收。內(nèi)設(shè)流量控制，避免數(shù)據(jù)流超限；數(shù)據(jù)被看作是字節(jié)流，無(wú)長(zhǎng)度限制。文件傳輸協(xié)議(FTP)即使用流式套接字。2022/11/21*數(shù)據(jù)報(bào)式套接字(SOCK_DGRAM)：提供一個(gè)無(wú)連接服務(wù)。數(shù)據(jù)報(bào)以獨(dú)立包形式被發(fā)送，不提供無(wú)錯(cuò)保證，數(shù)據(jù)可能丟失或重復(fù)，且接收順序混亂。網(wǎng)絡(luò)文件系統(tǒng)(NFS)使用數(shù)據(jù)報(bào)式套接字。*原始式套接字(SOCK_RAW)：該接口允許對(duì)較低層協(xié)議，如IP、ICMP直接訪問(wèn)。常用于檢驗(yàn)新的協(xié)議實(shí)現(xiàn)或訪問(wèn)現(xiàn)有服務(wù)中配置的新設(shè)備。

2022/11/212.1.2網(wǎng)間進(jìn)程通信

1.端口網(wǎng)絡(luò)中可以被命名和尋址的通信端口是操作系統(tǒng)可分配的一種資源。按照OSI協(xié)議的描述，傳輸層與網(wǎng)絡(luò)層在功能上的最大區(qū)別是傳輸層提供進(jìn)程通信，從這個(gè)意義上講，網(wǎng)絡(luò)通信的最終地址不僅僅是主機(jī)地址，還包括可以描述進(jìn)程的某種標(biāo)識(shí)符。為此，TCP/IP協(xié)議提出可協(xié)議端口(protocolport，簡(jiǎn)稱端口)的概念，用于標(biāo)識(shí)通信的進(jìn)程。

2022/11/21端口是一種抽象的軟件結(jié)構(gòu)(包括一些數(shù)據(jù)結(jié)構(gòu)和I/O緩沖區(qū))。應(yīng)用程序(進(jìn)程)通過(guò)系統(tǒng)調(diào)用與某端口建立連接(binding)后，傳輸層傳給該端口的數(shù)據(jù)都被相應(yīng)進(jìn)程所接收，相應(yīng)進(jìn)程發(fā)給傳輸層的數(shù)據(jù)都通過(guò)該端口輸出。在TCP/IP協(xié)議的實(shí)現(xiàn)中，端口操作類似一般的I/O操作，進(jìn)程獲取一個(gè)端口，相當(dāng)于獲取本地唯一的I/O文件。類似于文件描述符，每個(gè)端口都擁有一個(gè)叫端口號(hào)(portnumber)的整數(shù)型標(biāo)識(shí)符，用于區(qū)別不同的端口。由于TCP/IP傳輸層的兩個(gè)協(xié)議TCP和UDP是完全獨(dú)立的兩個(gè)軟件模塊，因此各自的端口號(hào)也相互獨(dú)立。

2022/11/21端口號(hào)的分配是個(gè)重要問(wèn)題，有兩種基本分配方式：全局分配和本地分配。全局分配是一種集中控制方式，由一個(gè)公認(rèn)的中央機(jī)構(gòu)根據(jù)用戶需要進(jìn)行統(tǒng)一分配，并將結(jié)果公布于眾。本地分配又稱動(dòng)態(tài)連接，即進(jìn)程需要訪問(wèn)傳輸層服務(wù)時(shí)，向本地操作系統(tǒng)提出申請(qǐng)，操作系統(tǒng)返回一個(gè)本地唯一的端口號(hào)，進(jìn)程再通過(guò)合適的系統(tǒng)調(diào)用，將自己與該端口號(hào)聯(lián)系起來(lái)。TCP/IP中端口號(hào)的分配綜合了上述兩種方式，TCP/IP將端口號(hào)分為兩部分，少量的作為保留端口，以全局方式分配給服務(wù)進(jìn)程，因此每個(gè)標(biāo)準(zhǔn)服務(wù)器都擁有一個(gè)全局公認(rèn)的端口即周知口(well-knownport)，即使在不同機(jī)器上，其端口號(hào)也相同。剩余的為自由端口，以本地方式進(jìn)行分配。TCP和UDP均規(guī)定，小于256的端口號(hào)才能作保留端口。

2022/11/21

2.地址網(wǎng)絡(luò)通信中通信的兩個(gè)進(jìn)程在不同的機(jī)器上。這兩個(gè)機(jī)器可能位于不同的網(wǎng)絡(luò)，這些網(wǎng)絡(luò)通過(guò)網(wǎng)絡(luò)互聯(lián)設(shè)備(網(wǎng)關(guān)、網(wǎng)橋、路由器等)連接。因此需要如下三級(jí)尋址：*某一主機(jī)與多個(gè)網(wǎng)絡(luò)相連，必須指定一特定網(wǎng)絡(luò)地址；*網(wǎng)絡(luò)上每一主機(jī)應(yīng)有唯一的地址；*每一主機(jī)上的每一進(jìn)程應(yīng)有在該主機(jī)上的唯一標(biāo)識(shí)符。通常主機(jī)地址由網(wǎng)絡(luò)ID和主機(jī)ID組成，在TCP/IP協(xié)議中用32位整數(shù)值表示；TCP和UDP均使用16位端口號(hào)標(biāo)識(shí)用戶進(jìn)程。

2022/11/21

3.網(wǎng)絡(luò)字節(jié)順序不同計(jì)算機(jī)存放多字節(jié)值的順序不同，為保證數(shù)據(jù)的正確性，在網(wǎng)絡(luò)協(xié)議中需要指定網(wǎng)絡(luò)字節(jié)順序。TCP/IP協(xié)議使用16位整數(shù)和32位整數(shù)的高位先存格式，它們均含在協(xié)議頭文件中。

4.連接兩個(gè)進(jìn)程間的通信鏈路稱為連接。連接在內(nèi)部表現(xiàn)為一些緩沖區(qū)和一組協(xié)議機(jī)制，在外部表現(xiàn)出比無(wú)連接高的可靠性。

2022/11/21

5.半相關(guān)綜上所述，網(wǎng)絡(luò)中用一個(gè)三元組(協(xié)議，本地地址，本地端口號(hào))可以在全局唯一標(biāo)志一個(gè)進(jìn)程，這個(gè)三元組叫半相關(guān)(half-association)，它指定連接的每半部分。

6.全相關(guān)一個(gè)完整的網(wǎng)間進(jìn)程通信需要由兩個(gè)進(jìn)程組成，且只能使用同一種高層協(xié)議。即不可能通信的一端用TCP協(xié)議，另一端用UDP協(xié)議。因此一個(gè)完整的網(wǎng)間通信需要用一個(gè)五元組(協(xié)議，本地地址，本地端口號(hào)，遠(yuǎn)地地址，遠(yuǎn)地端口號(hào))來(lái)標(biāo)識(shí)，這個(gè)五元組叫全相關(guān)(association)，即兩個(gè)協(xié)議相同的半相關(guān)才能組成一個(gè)合適的相關(guān)，或完全指定組成一連接。

2022/11/212.1.3服務(wù)方式

1.面向連接(虛電路)或無(wú)連接面向連接服務(wù)是電話系統(tǒng)服務(wù)模式的抽象，每一次完整的數(shù)據(jù)傳輸都要經(jīng)過(guò)建立連接、使用連接、終止連接的過(guò)程。在數(shù)據(jù)傳輸過(guò)程中，各數(shù)據(jù)分組但不攜帶目的地址，而使用連接號(hào)(connectID)。本質(zhì)上，連接是一個(gè)管道，收發(fā)數(shù)據(jù)不但順序一致，而且內(nèi)容相同。TCP協(xié)議提供面向連接的虛電路。無(wú)連接服務(wù)是郵政系統(tǒng)服務(wù)的抽象，每個(gè)分組都攜帶完整的目的地址，各分組在系統(tǒng)中獨(dú)立傳送。無(wú)連接服務(wù)不能保證分組的先后順序，不進(jìn)行分組出錯(cuò)的恢復(fù)和重傳，不保證傳輸?shù)目煽啃?。UDP協(xié)議提供無(wú)連接的數(shù)據(jù)報(bào)服務(wù)。

2022/11/21

2.順序在網(wǎng)絡(luò)傳輸中，兩個(gè)連續(xù)報(bào)文在端到端通信中可能經(jīng)過(guò)不同的路徑，這樣到達(dá)目的地址時(shí)的順序可能與發(fā)送時(shí)不同?！绊樞颉笔侵附邮諗?shù)據(jù)順序與發(fā)送數(shù)據(jù)順序相同。TCP協(xié)議提供這項(xiàng)服務(wù)。

3.差錯(cuò)控制差錯(cuò)控制是保證應(yīng)用程序接收的數(shù)據(jù)無(wú)差錯(cuò)的一種機(jī)制。檢查差錯(cuò)的方法一般是采用檢驗(yàn)“校驗(yàn)和”(Checksum)的方法，而保證傳輸無(wú)差錯(cuò)的方法是雙方采用確認(rèn)應(yīng)答技術(shù)。TCP協(xié)議提供這項(xiàng)服務(wù)。

2022/11/21

4.流控制流控制是在數(shù)據(jù)傳輸過(guò)程中控制數(shù)據(jù)傳輸速率的一種機(jī)制，以保證數(shù)據(jù)不丟失。TCP協(xié)議提供這項(xiàng)服務(wù)。

5.字節(jié)流字節(jié)流方式是指僅把傳輸中的報(bào)文看作是一個(gè)字節(jié)序列，不提供數(shù)據(jù)流的任何邊界。TCP協(xié)議提供這項(xiàng)服務(wù)。

6.報(bào)文接收方要保存發(fā)送方的報(bào)文邊界。UDP協(xié)議提供這項(xiàng)服務(wù)。

2022/11/21

7.全雙工/半雙工全雙工/半雙工是指端與端之間的數(shù)據(jù)同時(shí)向兩個(gè)方向或一個(gè)方向傳送。

8.緩存/帶外數(shù)據(jù)在字節(jié)流服務(wù)中，由于沒(méi)有報(bào)文邊界，用戶進(jìn)程在某一時(shí)刻可以讀/寫任意數(shù)量的字節(jié)。為保證傳輸正確或采用有流控制的協(xié)議，都要進(jìn)行緩存。但對(duì)某些特殊的需求，如交互式應(yīng)用程序，又會(huì)要求取消這種緩存。

2022/11/212.1.4客戶機(jī)/服務(wù)器模式在TCP/IP網(wǎng)絡(luò)應(yīng)用中，通信的兩個(gè)進(jìn)程間相互作用的主要模式是客戶機(jī)/服務(wù)器模式(Client/ServerModel)，即客戶機(jī)向服務(wù)器發(fā)出服務(wù)請(qǐng)求，服務(wù)器接收到請(qǐng)求后，提供相應(yīng)的服務(wù)。客戶機(jī)/服務(wù)器模式的建立基于以下兩點(diǎn)：首先，建立網(wǎng)絡(luò)的起因是網(wǎng)絡(luò)中軟/硬件資源、運(yùn)算能力和信息不均等，需要共享，從而形成擁有眾多資源的主機(jī)提供服務(wù)，資源較少的客戶請(qǐng)求服務(wù)這一非對(duì)稱的情況。其次，網(wǎng)間進(jìn)程通信完全是異步的，相互通信的進(jìn)程間既不存在父子關(guān)系，又不共享內(nèi)存緩沖區(qū)，因此需要一種機(jī)制為希望通信的進(jìn)程間建立聯(lián)系，為二者的數(shù)據(jù)交換提供同步，這就是基于客戶機(jī)/服務(wù)器模式的TCP/IP。

2022/11/21客戶機(jī)/服務(wù)器模式在操作過(guò)程中采取主動(dòng)請(qǐng)求方式：

(1)服務(wù)器方啟動(dòng)，并根據(jù)請(qǐng)求提供相應(yīng)的服務(wù)：*打開一通信通道并告知本地主機(jī)，它愿意在某公認(rèn)地址(如FTP:21)上接收客戶請(qǐng)求。*等待客戶請(qǐng)求到達(dá)該端口。*接收到重復(fù)服務(wù)請(qǐng)求，處理該請(qǐng)求并發(fā)送應(yīng)答信號(hào)。接收到并發(fā)服務(wù)請(qǐng)求，要激活一新進(jìn)程來(lái)處理這個(gè)客戶請(qǐng)求(如UNIX系統(tǒng)中用fork、exec)。新進(jìn)程處理此客戶請(qǐng)求，并不需要對(duì)其他請(qǐng)求作出應(yīng)答。*返回第二步，等待另一客戶請(qǐng)求。*關(guān)閉服務(wù)器。

2022/11/21

(2)客戶機(jī)方：*打開一通信通道，并連接到服務(wù)器所在地的主機(jī)特定端口。*向服務(wù)器發(fā)送服務(wù)請(qǐng)求報(bào)文，等待并接收應(yīng)答，繼續(xù)提出請(qǐng)求。*請(qǐng)求結(jié)束后關(guān)閉通信通道并終止。從上面描述的過(guò)程可知：*客戶機(jī)與服務(wù)器進(jìn)程的作用是非對(duì)稱的，因此編碼不同。*服務(wù)進(jìn)程一般是先于客戶機(jī)請(qǐng)求而啟動(dòng)的，只要系統(tǒng)運(yùn)行，該服務(wù)進(jìn)程一直存在，直到正常終止或強(qiáng)迫終止。

2022/11/212.1.5WinSock對(duì)Socket的擴(kuò)充

WindowsSockets是從BerkeleySockets擴(kuò)展而來(lái)的，并在繼承BerkeleySockets的基礎(chǔ)上進(jìn)行了新的擴(kuò)充。這些擴(kuò)充主要是提供了一些異步函數(shù)，并增加了符合Windows消息驅(qū)動(dòng)特性的網(wǎng)絡(luò)事件異步選擇機(jī)制。

WindowsSockets由兩部分組成：開發(fā)組件和運(yùn)行組件。開發(fā)組件：WindowsSockets實(shí)現(xiàn)文檔、應(yīng)用程序接口(API)引入庫(kù)和一些頭文件。運(yùn)行組件：WindowsSockets應(yīng)用程序接口的動(dòng)