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

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

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

2022/11/211.1TCP/IP簡介

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

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

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

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

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

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

2022/11/21每一層負責的功能如下：

·

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

·

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

2022/11/21

·

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

·

應用層：該層負責處理實際的應用程序細節(jié)，包括Telnet、HTTP、SMTP、FTP、DNS和SNMP等協(xié)議和應用。

2022/11/21圖1.3通過TCP/IP和路由器連接的兩臺主機

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

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

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

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

·

每臺計算機分配一個唯一的地址。

·

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

2022/11/21

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

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

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

·

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

·

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

·回送地址：用于測試。

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

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

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

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

2022/11/21

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

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

2022/11/21

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

→ XXXl

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

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

2022/11/21

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

2022/11/21

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

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

2022/11/21由于IP數(shù)據(jù)報通常是分組傳輸?shù)模虼烁鼫蚀_地說，圖1.5中IP和網(wǎng)絡接口層之間傳送的數(shù)據(jù)單元應該是分組(Packet)。分組既可以是一個完整的IP數(shù)據(jù)報，也可以是IP數(shù)據(jù)報的一個片(Fragment)。關于分組的細節(jié)算法不在本書的討論范圍之內(nèi)。

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

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

2022/11/21當目的主機收到一個以太網(wǎng)數(shù)據(jù)幀時，數(shù)據(jù)就開始從協(xié)議棧中由底向上升，同時去掉各層協(xié)議加上的報文首部。每層協(xié)議盒都要去檢查報文首部中的協(xié)議標識，以確定接收數(shù)據(jù)的上層協(xié)議。這個過程稱作分用(Demultiplexing)，圖1.6顯示了該過程。圖1.6中把ARP和RARP放在IP層是因為它們都有以太網(wǎng)頭部和尾部，而在前面的論述中把它們作為鏈路層的協(xié)議，這并不矛盾，因為TCP/IP棧的層次劃分本來就不是非常清晰。

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

2022/11/21

5.端口號

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

2022/11/21客戶端通常對它所使用的端口號并不關心，只需保證該端口號在本機上是唯一的就可以了?？蛻舳丝谔栍址Q作臨時端口號(即存在時間很短暫)，這是因為它通常只是在用戶運行該客戶程序時才存在，而服務器則只要主機是開著的，其服務就運行。大多數(shù)TCP/IP實現(xiàn)給臨時端口分配1024～5000之間的端口號。大于5000的端口號是為其他服務(Internet上并不常用的服務)預留的。

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

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

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

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

2022/11/21

·

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

·

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

·

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

·

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

·

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

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

2022/11/21

·

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

·

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

2022/11/21

2.IP

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

2022/11/21

IP協(xié)議還要負責尋找路由，因此它還需要配套一個確定的IP地址。在IP報文的包頭中包含了源與目的IP地址。一般來說不會有應用程序直接訪問IP協(xié)議。

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

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

2022/11/21

·

IP數(shù)據(jù)報頭的最小長度是5個字(word，1字＝4字節(jié))，如果有其他選項，報頭可能會更長。IPv4數(shù)據(jù)報中的數(shù)據(jù)(包括報頭中的數(shù)據(jù))以32位(4字節(jié))的方式來組織。IPv4中包含至少12個不同字段，且在沒有選項時長度為20個字節(jié)，但在包含選項時可達60個字節(jié)。

·

版本(VERS)：指定IP協(xié)議的版本號，對于IPv4來說，版本為4。

·

報頭長度(HLENS)：指定IP報頭的長度，以字為單位，范圍為5～15個字。

·

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

2022/11/21

·

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

·

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

2022/11/21

·

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

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

2022/11/21

·

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

·

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

·頭校驗和(HeaderChecksum)：目的是保證報頭的正確性，目的機、網(wǎng)絡中的每個網(wǎng)關都要重新計算報頭的校驗和，如果計算出的校驗和與報文所含的校驗和不同，則丟棄該報文。

2022/11/21

·

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

·

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

·

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

·

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

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

2022/11/21

3.TCP

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

2022/11/21圖1.10TCP段格式

2022/11/21

·

源端口(SourcePort)：16位的源端口字段指發(fā)起通信的端口號，它和IP首部中的源IP地址的作用是標識發(fā)送報文的計算機及應用程序。

·

目的端口(DestinationPort)：16位的目的端口字段定義了傳輸?shù)哪康牡囟丝谔?，它和IP首部中的目的IP地址的作用是標識接收報文的計算機及應用程序。

2022/11/21

·

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

·

當建立一個新的連接時，SYN標志(下文介紹)置1。序號字段包含由這個主機選擇的該連接的ISN。該主機要發(fā)送數(shù)據(jù)的第一個字節(jié)序號為該ISN加1，因為SYN標志消耗了一個序號。

2022/11/21

·

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

·

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

·

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

2022/11/21·

URG：緊急指針有效。·

ACK：確認序號有效。·

PSH：接收方應該盡快將這個報文段交給應用層?！?/p>

RST：重置連接。·

SYN：同步序號，用來發(fā)起一個連接?！?/p>

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

2022/11/21

·

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

·

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

2022/11/21

·

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

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

2022/11/21

·

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

TCP提供了一個完全可靠的、面向連接的、全雙工的流傳輸服務。允許兩個應用程序建立一個連接，并在每一個方向上發(fā)送數(shù)據(jù)，然后終止連接，每一個TCP連接可靠地建立完善的終止，在終止發(fā)生前，所有數(shù)據(jù)都會被可靠地傳送?？煽總鬏敺哲浖鶓哂械奶卣魅缦拢?/p>

2022/11/21

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

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

(3)帶緩沖的傳送。

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

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

2022/11/21

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

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

2022/11/21

(1)請求端(通常稱為客戶)發(fā)送一個SYN段，指明客戶打算連接的服務器的端口以及初始序號(SEQ)。這個SYN段為報文段1。

(2)服務器發(fā)回包含服務器的初始序號的SYN報文段(報文段2)作為應答。同時，將確認序號設置為客戶的ISN加1，用以對客戶的SYN報文段進行確認。一個SYN占用一個序號。

(3)客戶必須將確認序號設置為服務器的ISN加1，用以對服務器的SYN報文段進行確認(報文段3)。

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

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

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

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

2022/11/21

4.UDP

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

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

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

2022/11/21

·

源端口(SourcePort)：16位的源端口是發(fā)送端上的連接端口，它和IP首部中的源IP地址的作用是標識發(fā)送UDP報文的計算機及應用程序。

·

目的端口(DestinationPort)：16位的目的端口是接收端上的連接端口，它和IP首部中的目的IP地址的作用是標識接收報文的計算機及應用程序。

·

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

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

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

2022/11/21

5.ARP/RARP

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

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

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

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

(2)目的主機的ARP層收到這份廣播報文后，識別出這是發(fā)送端在詢問它的IP地址，于是發(fā)送一個ARP應答。這個ARP應答包含IP地址及對應的硬件地址。

2022/11/21

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

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

2022/11/21

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

·

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

·

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

·

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

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

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

表1.3硬件接口類型一覽表

2022/11/21

·

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

·

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

·

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

2022/11/21

·

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

·

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

·

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

·

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

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

2022/11/21

6.ICMP

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

2022/11/21

·

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

·

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

·應答請求與回復：用Ping來檢測目標主機是否可以到達。Ping指令調(diào)用ICMP消息的應答請求功能發(fā)送數(shù)據(jù)報，如果遠程主機是可以到達的，則該系統(tǒng)會用應答回復功能來響應。

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

2022/11/21類型字段可以有15個不同的值，以描述特定類型的ICMP報文。某些ICMP報文還使用代碼字段的值來進一步描述不同的條件。檢驗和字段覆蓋整個ICMP報文。對于ICMP報文來說，檢驗和是必需的。

ICMP的報文類型由報文中的類型字段和代碼字段來共同決定，如表1.4所示。

2022/11/21表1.4ICMP報文類型

2022/11/21表1.4ICMP報文類型

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

(1)?ICMP差錯報文(但ICMP查詢報文可能會產(chǎn)生ICMP差錯報文)。

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

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

(4)不是IP數(shù)據(jù)報第一個分片的數(shù)據(jù)報。

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

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

·

回應請求和回應應答報文?；貞埱蠛突貞獞饒笪慕?jīng)常用來判斷一個特定的主機是否處于活動狀態(tài)，并且是否可以通過網(wǎng)絡訪問到。回應請求和回應應答報文的格式如圖1.16所示。

2022/11/21圖1.16回應請求和回應應答報文

2022/11/21

·

ICMP地址掩碼請求和應答報文。

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

圖1.17ICMP地址掩碼請求和應答報文

2022/11/21

·

ICMP時間戳請求和應答報文。

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

2022/11/21圖1.18ICMP時間戳請求和應答報文

2022/11/211.1.4進程/應用層協(xié)議

1.Telnet協(xié)議

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

2022/11/21

2.FTP協(xié)議

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

2022/11/21

3.HTTP協(xié)議

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

2022/11/21

4.SMTP與POP3協(xié)議

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

5.DNS

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

2022/11/211.2網(wǎng)絡編程應考慮的問題

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

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

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

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

2022/11/21

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

2022/11/21

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

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

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

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

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

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

2022/11/211.2.4服務類型的選擇

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

2022/11/21

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

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

·

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

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

2022/11/21

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

2022/11/21

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

2022/11/21表1.5面向連接服務與無連接服務的比較

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

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

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

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

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

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

3.簡述IP數(shù)據(jù)報中各字段的含義。

4.簡述并比較MAC地址、IP地址和端口的作用。

5.試舉例說明網(wǎng)絡編程時可能遇到的問題，并提出相應的比較合理的解決方案。

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

2.2WinSock編程原理

2.3WinSockI/O模型

2.4WinSock2的擴展特性

2.5套接字選項和I/O控制命令

習題與思考題

2022/11/212.1基

本

概

念

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

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

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

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

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

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

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

2022/11/21

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

2022/11/21

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

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

2022/11/21

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

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

2022/11/212.1.3服務方式

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

2022/11/21

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

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

2022/11/21

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

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

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

2022/11/21

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

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

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

2022/11/21客戶機/服務器模式在操作過程中采取主動請求方式：

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

2022/11/21

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

2022/11/212.1.5WinSock對Socket的擴充

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

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