2022圖解網(wǎng)絡(luò)鏈接技術(shù)

第1 瀏覽器生成消息——探索瀏覽器內(nèi)HTTPHTTPHTTPDNSWebIPIPIPSocketIPDNSDNSDNSDNSIPDNS 第2 用電信號傳輸TCP/IP數(shù)據(jù)——探索協(xié)議棧和網(wǎng)socketHTTPACKACKACKACKHTTPIPIPIPMACARPMACIP3IPUDPUDP 第3 從網(wǎng)線到網(wǎng)絡(luò)設(shè)備——探索集線器、交換機(jī)和路由 MACIP 第4 通過接入網(wǎng)進(jìn)入互聯(lián)網(wǎng)內(nèi)部——探索接入網(wǎng)和網(wǎng)絡(luò)運(yùn)營ADSLADSLModemADSL將信元“調(diào)制”ADSLDSLAM光纖接入網(wǎng)PPPPPPIPPPPoEPOPIXIX 第5 服務(wù)器端的局域網(wǎng)中有什么玄WebWebWeb最原始的代理——正向代理的改良版—— 第6章 請求到達(dá)Web服務(wù)器，響應(yīng)返回瀏覽器——短短幾秒的“漫長旅程”迎來終IPTCPTCPTCPWebURICGIWeb 從在瀏覽器中輸入網(wǎng)址，到屏幕上顯示出網(wǎng)頁的內(nèi)容，在這個(gè)只有幾秒鐘的過程中，很多硬件和軟件都在各自的崗位上相互配合完成了一系列的工作。本書將以探索之旅的形式，帶領(lǐng)大家探索這一系列工作中的每一個(gè)環(huán)節(jié)。每個(gè)單獨(dú)的環(huán)節(jié)都并不復(fù)雜，只要仔細(xì)閱讀就一定能夠理解。不過，探索之旅中出現(xiàn)的硬件和軟件數(shù)量龐大，如果僅從微觀的視角關(guān)注每一個(gè)單獨(dú)的點(diǎn)，可能就會因?yàn)榭床坏秸w而迷失了方向。因此，在真正出發(fā)開始探索之前，我們先來對這次探索之旅作個(gè)簡單的介紹。下面的介紹中還包含一張?zhí)剿髦玫穆肪€圖，萬一在旅途中迷失了方向，請大家務(wù)必回來看一看這張地圖。WebWeb服務(wù)器并顯示W(wǎng)eb服務(wù)器之間的一系列交互，主要是下面這樣的交互。瀏覽器：“網(wǎng)頁的數(shù)據(jù)。Web服務(wù)器：“好的，這就是你要的數(shù)據(jù)。Web服務(wù)器接收到的數(shù)據(jù)顯示在屏幕上。Web服務(wù)器的操作其Web服務(wù)器：“好的，訂單數(shù)據(jù)已收到。Web服務(wù)器在收到訂單數(shù)據(jù)之后和銷售系統(tǒng)一起對訂單進(jìn)行實(shí)際處理的操作很Web服務(wù)器之間的交互卻很簡單，概括如下。WebWebWeb服務(wù)器等網(wǎng)絡(luò)應(yīng)用程序進(jìn)行交互的層面1。1盡管思路很簡單，但實(shí)際編寫這些應(yīng)用程序并不容易，需要事無巨細(xì)地設(shè)計(jì)好所有的功能，還要編寫大量的代Web服務(wù)器之間傳遞請201組成的數(shù)2為“包”（Packet）的容器中來運(yùn)送?！鞍?，3在日語中，Packet一詞在手機(jī)中指的是“移動數(shù)據(jù)流量”GPRS（GeneralPacketRadioService）P。——譯者注Web服務(wù)器這些網(wǎng)絡(luò)應(yīng)6章的內(nèi)容，帶領(lǐng)大家逐一探索其中的各個(gè)環(huán)節(jié)。1章Web\h在上面這個(gè)例子中，瀏覽器生成的請求消息表示“sample1.html這一文件中儲存的網(wǎng)頁數(shù)據(jù)”Web服務(wù)器。1章中，我們會探索到瀏覽器將數(shù)據(jù)委托出去為止。2章3ADSL和光纖到戶（FTTH）4線路稱為接入網(wǎng)。一般來說，我們可以用電話線、ISDNADSL、有線電視、光線、專運(yùn)營商，并接入被稱為接入點(diǎn)（PointofPresence，PoP）的設(shè)備。Web服務(wù)器5Web服務(wù)器所在的局域網(wǎng)中。接著，它會遇到Web服務(wù)器，直接從緩存服務(wù)器讀出數(shù)據(jù)。此外，在大型網(wǎng)站中，可能還會配備將Web服務(wù)器上的負(fù)載均衡器，還有可能會使用通過分布在整個(gè)互聯(lián)網(wǎng)中Web服務(wù)器。6章WebWeb服務(wù)器后，數(shù)據(jù)會被解包并還原為原始的請求消息，然后交給Web服務(wù)器程序。和客戶端一樣，這個(gè)操作也是由操作系統(tǒng)中的協(xié)議棧（網(wǎng)絡(luò)控制軟件）來完成的。接下來，Web服務(wù)器程序分析請求消息的含義，并按照其中的指示將數(shù)Web服務(wù)器的一系列操作就全部完成了，我們的探索之旅也到達(dá)了終點(diǎn)。專欄“網(wǎng)絡(luò)術(shù)語其實(shí)很簡單1章瀏覽器生成消息——探索瀏覽器內(nèi)\hhttp://www.nikkeibp.co.jp/wwwWorldWideWeb協(xié)議（對通信操作規(guī)則×。\hhttp://www.nikkeibp.co.jp/wwwWeb服務(wù)器上的一種命名。而且，WorldWideWebWebHTML√。如果是“.com”“.net”“.org”“.jp”（除“co.jp”“ne.jp”等“xx.jp”格式的域名外）1等沒1中國的情況類似，個(gè)人可以申請“.cn”域名，但“.”“.”等域名則是不開放給個(gè)人注冊的。此外，日本的HTTPWebHTTP協(xié)議的原理了。DNSWebIPDNSIPWeb服務(wù)器了，但HTTP://開頭，例如“ftp:”“file:”“mailto:”4等。2某些情況下，瀏覽器的工作是從點(diǎn)擊網(wǎng)頁中的一個(gè)鏈接開始，大家可以認(rèn)為這種情況與將鏈接中所包含的網(wǎng)址3URL：UniformResourceLocator4如果沒有正確配置電子郵件軟件，則即使在地址欄中輸入“mailto:”URLWeb服務(wù)器FTP5服務(wù)器上下載和上傳文URLWeb服務(wù)器時(shí)用“http:”FTP服5FTP：FileTransferProtocolFTP協(xié)議來傳送FTP。1.1URL，根據(jù)訪問目標(biāo)的不同，URL的寫法也WebFTP服務(wù)器時(shí)，URL6和要訪URL則包含收件人的郵件地址。此外，根據(jù)需要，URL7等信息。6\h這樣以句點(diǎn)（.）分隔的名稱。關(guān)于域名，.27端口號：1.4.366.1.3節(jié)有詳細(xì)說明，這里請大家理解為一個(gè)用來識別要連接的服務(wù)器程序的編號。Web8025等。圖 URL的各種格URLURL開頭的文字，WebHTTP8FTPFTP協(xié)議。因此，910。盡管后面部分的寫法各不相同，8HTTP：HypertextTransferProtocol9協(xié)議：通信操作的規(guī)則定義稱為協(xié)議（protocol）10像file:”URLURL的開頭部分表示的是協(xié)議類型并不完全準(zhǔn)確，也瀏覽器先要解析URLWeb服務(wù)器的請求消息。剛才我們已經(jīng)講過，URL的格式會隨著協(xié)議的不同而不同，因此下面我們以訪問Web服務(wù)器的情況為例來進(jìn)行講解。HTTP的規(guī)格，URL1.2（a）URL進(jìn)行解析時(shí)，1.2（a）1.2（b）URL1.2（c）URL代1.2（c），Web服務(wù)器名稱\hdir1file1.html，因此我們就能夠明白，圖1.2（b）URL\hWeb服務(wù)器上路徑名為dirfile1.htmldir11file1.html這個(gè)文件（1.3）。11目錄（directory）Windows中的文件夾（folder）圖 Web瀏覽器解析URL的過圖 路徑名為dirfile1.html的文URLURL是以“/”來結(jié)尾的。\h我們可以這樣理解，以“/”dirURLdirindex.htmldirdefault.htm。\hindex.htmldefault.htm這樣的文件了。12“”目錄表示目錄層級中最頂層的“根目錄”。也許單獨(dú)一個(gè)“”表示根目錄的寫法看上去很奇怪，其實(shí)只要明白目目錄本身沒有名字的話會怎么樣呢？在上面的例子中，就相當(dāng)于“dir”dir，這樣一來就只剩下一URL\h這次連結(jié)尾的都省略了。像這樣連目錄名都省略時(shí)，真不知道到底在請求哪個(gè)文13nd.hldu.hm這些文件，這樣就不會發(fā)生混亂了。13最早的時(shí)候這個(gè)文件被叫作“主頁”（homepage），意思就是當(dāng)省略文件名時(shí)訪問的那個(gè)默認(rèn)的頁面。隨著Web的普及，這個(gè)詞的意義似乎并沒有被正確理解，現(xiàn)在不光是默認(rèn)頁面，似乎隨便什么網(wǎng)頁都可以被叫作主頁了。\h前面這個(gè)例子中，由于末尾沒有“”whatisthis應(yīng)該理解為文件名才對。但實(shí)際whatisthis作為文件名來處理。一般來說，這種情況會按照下Webwhatisthiswhatisthis作為whatisthiswhatisthis14。14whatisthis的文件，同時(shí)又有一個(gè)名為whatisthiswhatisthis究竟是一個(gè)文件還是一個(gè)目錄了，并不URLHTTPURL之后，我們就知道應(yīng)該要訪問的目標(biāo)在哪里了。接下來，瀏覽器會使用HTTPWebHTTP協(xié)議圖 HTTP的基本思HTTP協(xié)議定義了客戶端和服務(wù)器之間交互的消息內(nèi)容和步驟，其基本思路非常簡單。首先，客戶端會向服務(wù)器發(fā)送請求消息（1.4）。請求消息中包含的內(nèi)容是“對什URICGI16的文件名，例如“dir1file1.html”“dir1program1.cgi”17。不過，URI用“http:”URL18URI。換句話說就是，這里可以寫各種訪問目標(biāo)，而這些訪URI。15URI：UniformResourceIdentifierCGI程序。185.4.3相當(dāng)于接下來“進(jìn)行怎樣的操作”19Web服務(wù)器完URI表示的數(shù)據(jù)、將客戶端輸入的數(shù)據(jù)發(fā)送給19HTTPHTTP動詞?！?HTTP的主要方URIURIURI指CGI程序，則返回該程序的輸出數(shù)據(jù)GETHTTP的消息頭（messageheader），而并不返回URIURIURI1.01.1RFC1945RFC2616。Web服務(wù)器發(fā)送數(shù)據(jù)時(shí)，會先發(fā)送頭字段，然后再發(fā)送數(shù)據(jù)。不過，頭字段屬于可收到請求消息之后，WebURI和方法來判Web404NotFound的錯(cuò)誤HTTP的整個(gè)工作就完成了。HTTPHTTP方法的知1.1GETWeb服務(wù)器GET方法。所謂一般的訪問過程大概就是這樣的：首先，GETURI中寫上存放網(wǎng)頁數(shù)據(jù)的文件名“dir1file1.html”dir1file1.htmlWeb服務(wù)器收dir1file1.html文件并讀取出里面的數(shù)據(jù)，然后將讀出的數(shù)據(jù)存放到響POST20WebPOST方法時(shí)，URIWeb21的文件名，典型的例子包括“index.cgi”“index.php”URI之外，還要加上傳遞消息后，WebURI指定的應(yīng)用程序。最后，Web服20211.1HTTP協(xié)議具GETPOSTWeb服務(wù)器中獲取網(wǎng)頁數(shù)WebPUTDELETE方法，就WebWebGETPOST之外22，但大家應(yīng)該能夠看出，HTTP協(xié)議其實(shí)蘊(yùn)藏著很多的可能性。22如果能夠規(guī)避安全問題，例如將訪問限制在公司內(nèi)部網(wǎng)絡(luò)，那么這種用法還是有效的。（實(shí)際上，PUTDELETERESTfulAPIApp和后端服務(wù)器交互時(shí)就會經(jīng)常用到?！g者注HTTPHTTPHTTP請求消息了。實(shí)際上，HTTP消息在格式上是有嚴(yán)格規(guī)定的，因此瀏覽器會按照規(guī)定的格式來生成請求消息（1.5）。圖 HTTP消息的格瀏覽器和Web23Content-Type字段來定義（MIME類型），MIME6.4節(jié)有詳細(xì)介紹?！g者注Web服務(wù)器它應(yīng)該進(jìn)行怎樣的操作。不過這里必須先解決一個(gè)問題，那就是方法有很多Web服務(wù)器發(fā)送請求消24，或者在表單中填寫信息后點(diǎn)擊“提交”按鈕，這些場24HTML<ahref="URLGET方法。點(diǎn)擊GETHTML源代碼中會在表單的屬性GETPOST（1.6）25。25GETPOST圖 表單中對方法的區(qū)URI。URI部分的格式如下，一般是文件和程序>HTTPHTTPHTTP1.2中列GET方法的情況下，僅憑方法URI，Web服務(wù)器就能夠判斷需要進(jìn)行怎樣的操作，因此消息體中不需要填寫任何數(shù)1.2HTTPTCP客戶端可支持的數(shù)據(jù)類型（Content-Type），MIMEIPURI當(dāng)請求的信息存在訪問控制時(shí)，返回身份認(rèn)證用的數(shù)據(jù)（Challenge26當(dāng)希望僅請求部分?jǐn)?shù)據(jù)（Range來指定范圍）時(shí)，服務(wù)器會告知客戶端是否實(shí)體頭：用于表示實(shí)體（消息體）URIMIME表示消息體在服務(wù)器上的位置Etag向客戶端發(fā)送一個(gè)唯一標(biāo)識，在下次請求中客戶端可以通If-Match、If-None-Match、If-Range字段將這個(gè)標(biāo)識告知服務(wù)器，這樣服務(wù)器就Cookie是相同的，但Cookie是網(wǎng)景（Netscape）Etag是將其進(jìn)行標(biāo)準(zhǔn)化后的26ChallengeChallenge-Response身份驗(yàn)證模型中的一環(huán)。簡單來說，Challenge相當(dāng)于“天王蓋地虎”，Response相當(dāng)于“寶塔鎮(zhèn)河妖”?！g者注POST方法時(shí)，需要將表單中填寫的信息寫在消息體中。到此為止，請求消息當(dāng)我們將上述請求消息發(fā)送出去之后，Web服務(wù)器會返回響應(yīng)消息。關(guān)于響應(yīng)消息6章詳細(xì)介紹，這里先粗略地了解一下。響應(yīng)消息的格式以及基本思路和請求表 HTTP狀態(tài)碼概27的控制信WebWeb服務(wù)URI部分寫上圖片的文件名并生成和發(fā)送請求消息就可以了。27HTML語言中規(guī)定的控制信息。例如，當(dāng)需要在網(wǎng)頁中插入圖片時(shí)，需要在相應(yīng)位置<imgsrc="image1.jpg">的標(biāo)簽。1URI1113張圖片，那么獲取網(wǎng)Web4條請求。Web服務(wù)器卻毫不知情。Web4條請求獲取11Web1.7Web服務(wù)器之間交互消息的一個(gè)實(shí)例。在這個(gè)例子中，我們需要獲取sample1.htmpicture.jpg的圖片，圖中展示了這個(gè)11URI1圖 HTTP消息示DNSWebIPIPHTTPWeb服務(wù)器。盡HTTP消息，但它本身并不具備將消息發(fā)送到網(wǎng)絡(luò)中的功28。在進(jìn)行這一操作時(shí)，我們還有一個(gè)工作IP地址。在委托操作系統(tǒng)發(fā)送消息時(shí)，IPHTTP消息之后，IP地址。在講解這一操作之前，讓我們先來簡單了解一下IP地址。28發(fā)送消息的功能對于所有的應(yīng)用程序來說都是通用的，因此讓操作系統(tǒng)來實(shí)現(xiàn)這一功能，其他應(yīng)用程序委托操TCP/IPTCP/IP的基本思路。TCP/IP1.830313229330331當(dāng)計(jì)算機(jī)數(shù)量較少時(shí)，可以用一臺集線器連接起來；當(dāng)計(jì)算機(jī)數(shù)量較多時(shí)，一臺集線器可能無法連接這么多計(jì)32一些家用路由器中已經(jīng)內(nèi)置了集線器功能，因此大家可以理解為這種路由器內(nèi)部同時(shí)包含路由器和集線器兩種的“××××室”。其中“號”對應(yīng)的號碼是分配給整個(gè)子網(wǎng)的，而“室”對應(yīng)的號碼是分配給IP33IP地址我們可以判斷出訪問對象服34，轉(zhuǎn)發(fā)到距離發(fā)送者最近的路由器上（1.8①）。接下來，路由器會根據(jù)消息的目的地判斷下一發(fā)到下一個(gè)路由器（1.8②）。前面的過程不斷重復(fù)，最終消息就被傳送到了目的地。33IP地址和現(xiàn)實(shí)中的地址含義是相同的，因此就像室”不能有兩戶人家的號碼相同一樣，也不能有兩臺IPIP地址的情況，但這種情況下網(wǎng)絡(luò)會發(fā)34圖 IP的基本思TCP/IPIP地址的基本思路。了解了這些知識之后，讓我們再來看一IP1.9IP328比特（1字節(jié)）4IP地址格式，但僅憑這一串?dāng)?shù)字我們無法區(qū)分哪部分是網(wǎng)絡(luò)號，哪部分是主機(jī)號。在IP32比特，但這兩部分的具體結(jié)構(gòu)是不固IP地址的內(nèi)部結(jié)構(gòu)。圖 IP地址的表示方1.10IP地址長32101的部分0IP地址一樣的方式以8IP1.9（b）的方法。這種寫法1IP地址的右側(cè)，如圖1.9（c）圖 IP地址的結(jié)1代表向子網(wǎng)上所有設(shè)備發(fā)送包，即廣播（1.9（e））。IP0全1：表示向子網(wǎng)上所有設(shè)備發(fā)送包，即“廣播IPTCP/IPIPIP地址就無法將消息發(fā)IP地址?？赡苣銜枴癐P地址不就好了嗎？”IP35。然而，就像你IPIP地36。35WebIP36TCP/IP架構(gòu)的當(dāng)時(shí)，在技術(shù)上還無法實(shí)現(xiàn)我們今天的搜索引擎，因此那么又有人問了：“IP地址，而是用名稱來確定通信對象不應(yīng)該還是做得到的吧？”3737實(shí)際上真的存在以名稱來確定通信對象的網(wǎng)絡(luò)，WindowsPC-NetworksIPIPIP324字節(jié)，相對地，域名255IP地址只需要處理4255個(gè)字節(jié)的字符，這增加了路由器的負(fù)擔(dān)，38?？赡苡腥藭f：“那使用高性能路由器不就能解決這個(gè)38域名并不僅是長，而且其長度是不固定的。處理長度不固定的數(shù)據(jù)比處理長度固定的數(shù)據(jù)要復(fù)雜，這也是造成IP地址。為了填補(bǔ)IPIP地址來查詢DNS39。39DNS：DomainNameSystemIPDNSSocketIPIPDNS服務(wù)器“\hIP地址是什么”就可以了，DNS服務(wù)器會回答說“IP地址為xxx.xxx.xxx.xxx”DNS服Web服務(wù)器發(fā)送請求消息的事情放一放，先來探索一下SSSSSSSP地址的操作稱為域名解析，因此負(fù)責(zé)執(zhí)行解析（ouon）這一操作的就叫解析器（ov）了。SocketSocket庫。首先，庫到底是什么東西呢？庫就是一堆通用程序組庫的種類和數(shù)量也非常之多。Socket庫也是一種庫，其中包含的程序組件可以讓其他的應(yīng)40，而解析器就是這個(gè)庫中的其中一種程序組件。庫開發(fā)了相應(yīng)的網(wǎng)絡(luò)庫。可以說，Socket庫是網(wǎng)絡(luò)開發(fā)中的一種標(biāo)準(zhǔn)庫。Socket庫中包含很多用于發(fā)送和接收數(shù)據(jù)的程序組件，這些功能我們暫且放一放，先Socket通過解析器向DNS解析器的用法非常簡單。Socket庫中的程序都是標(biāo)準(zhǔn)組件，只要從應(yīng)用程序中進(jìn)行調(diào)1.11這樣寫上解析器的程序名稱“gethostbyname”Web服務(wù)器的域名“\h”就可以了，41。41IP#include命令將圖 解析器的調(diào)用方DNSIPDNSDNS服務(wù)器會返回響應(yīng)IPIP地址，并將其寫入瀏覽器指定1.11中的這一行程序，就可以完成前面所有這些工作，我們IPWeb服務(wù)器發(fā)送消息時(shí)，只要從該內(nèi)存IPHTTP請求消息一起交給操作系統(tǒng)就可以了。IPSocket圖 調(diào)用解析器時(shí)計(jì)算機(jī)內(nèi)部的工作流器的部分時(shí)，對應(yīng)的那一行程序就會被執(zhí)行，應(yīng)用程序本身的工作就會暫停（行，這就是“控制流程轉(zhuǎn)移”42。gethostbyname程序中調(diào)用其他的程序。但如果繼續(xù)深挖下去的話會變得復(fù)雜難懂，因gethostbyname實(shí)現(xiàn)了解析器的全部功能。DNS服務(wù)器的查詢消息。這個(gè)WebHTTP請求消息的過程類似，解析器會根據(jù)DNS的規(guī)格，生成一條表示“\hIP地址”43的數(shù)據(jù)，并將DNS服務(wù)器（1.12③）。發(fā)送消息這個(gè)操作并不是由解析器自身來執(zhí)行，而44來執(zhí)行。這是因?yàn)楹蜑g覽器一樣，解析器本身也不DNS服務(wù)器（1.12④⑤）。43HTTPDNS44協(xié)議棧：操作系統(tǒng)內(nèi)部的網(wǎng)絡(luò)控制軟件，也叫“協(xié)議驅(qū)動”“TCP/IP驅(qū)動”DNS服務(wù)器收到查詢消息后，它會根據(jù)消息中的查詢內(nèi)容進(jìn)行查詢。這個(gè)查詢的WebDNS服務(wù)器上注冊，那么這條記錄就能夠被IP地址會被寫入響應(yīng)消息并返回給客戶端（1.12⑥）。接下來，消息經(jīng)過網(wǎng)絡(luò)到達(dá)客戶端，再經(jīng)過協(xié)議棧被傳遞給解析器（1.12⑦⑧），然后解析器讀取出IPIP地址傳遞給應(yīng)用程序（1.12⑨）。實(shí)際上，解析器會將取IP1.11用“<>”來表示，在實(shí)際IPIPDNSDNSIP地IPTCP/IP的一個(gè)設(shè)置項(xiàng)目事先設(shè)置好的，不需要再去查詢TCP/IP的設(shè)置方法也有差異，Windows1.13所示，DNSIP地址來發(fā)送消息。圖 DNS服務(wù)器地址的設(shè)DNSDNSDNSDNS服務(wù)器的工作。DNS服務(wù)器的基本工作就是接收來自客戶端的查詢消息，然后根據(jù)消息的內(nèi)容返回3服務(wù)器、郵件服務(wù)器（@后面的部分）DNS方案時(shí)，DNS在互聯(lián)網(wǎng)以外的其他網(wǎng)絡(luò)中的應(yīng)用也被考慮到Class就是用來識別網(wǎng)絡(luò)的信息。不過，如今除了互聯(lián)網(wǎng)并沒有其他的網(wǎng)絡(luò)了，因ClassINAIPDNS31.14所示。DNS服圖 DNS服務(wù)器的基本工\hIP（a）\h（b）Class=（c）然后，DNS服務(wù)器會從已有的記錄中查找域名、Class和記錄類型全部匹配的記錄。一致。于是，DNS26這個(gè)值返回給客戶端。然而，Web服\hWebWebwww這樣的命名，后來WebServer1也好，MySrvDNSWeb4645AAddress46WebA類型的記錄，都可以AIP地址所對應(yīng)的域名，因此與其說是某個(gè)服務(wù)器的域IP地址的某臺具體設(shè)備的域名。IPAMX47類DNS服務(wù)器上，IPA記錄中的，而郵件服務(wù)器則是保存在MX\htone@，當(dāng)需要知道這個(gè)地址對應(yīng)@后面的那一串名稱。查詢消息的內(nèi)容如下。47MX：MaileXchange（a）（b）Class=（c）DNS10MX時(shí)，DNS48。此外，MXIP地址。上表的第三行就是IP的域名就可以找到這條記IP27。48當(dāng)一個(gè)郵件地址對應(yīng)多個(gè)郵件服務(wù)器時(shí)，需要根據(jù)優(yōu)先級來判斷哪個(gè)郵件服務(wù)器是優(yōu)先的。優(yōu)先級數(shù)值較小的綜上所述，DNS服務(wù)器的基本工作就是根據(jù)需要查詢的域名和記錄類型查找相關(guān)的DNSIPIP地址。AMXPTRCNAMEDNSIP1.14展示的是表格形式，但實(shí)際上這些信息是保存在配置文件中的，Web和郵件服務(wù)器數(shù)量有限的環(huán)境中，所有的信息都可以DNS服務(wù)器是如何工作的。DNS服務(wù)器上注冊并保存的。首先，DNS服務(wù)器中的所有信息都是按照域名以分層次的結(jié)構(gòu)來保存的。層次結(jié)構(gòu)DNS\h，這里的句點(diǎn)代表49。在域名中，越靠右的位置表示其層級越高，比如\h這個(gè)域名如果按照公司里的組織結(jié)構(gòu)來說，大概就是“com事業(yè)集glasscomlabwww”這樣。其中，相當(dāng)于一個(gè)層級的部分稱為域。因此，com域glasscomlabwww這個(gè)名字。49公司里面的部、科之類的名稱會讓層次變得固化，缺乏靈活性，而用句點(diǎn)來分隔則可以很容易地增加新的層DNS服務(wù)器中，而每個(gè)域都是作為一個(gè)整體DNS服務(wù)器中的，不能DNS服務(wù)器中。不過，DNS服務(wù)器和域之間的關(guān)系也并不總DNS服務(wù)器中也可以存放多個(gè)域的信息。為了避免把事情搞得太復(fù)DNS服務(wù)器中只存放一個(gè)域的信息，后面的講解也是基于這個(gè)前提來進(jìn)行的。于是，DNS服務(wù)器也具有了像域名一樣的層次結(jié)構(gòu)，每個(gè)域的信息都存放在DNSDNS服務(wù)Web50。50DNSDNS服務(wù)DNS服務(wù)器中就存放了很多個(gè)域的信息。51，然后再將它們分別分配給各個(gè)example.co.jp，我們可以在這個(gè)域的下面創(chuàng)建兩個(gè)子sub1.example.co.jpsub2.example.co.jp，然后就可以將這兩個(gè)下級域分配給不同\hwww.nikkeibp.co.jp這jpco是日本國內(nèi)進(jìn)行分類的nikkeibpwww就是服務(wù)器51下級的域稱為“子域”DNSIPDNS服務(wù)器中存放的信息。這里的關(guān)鍵在于如何找到我們WebDNS服務(wù)器管。DNS服務(wù)器，肯定不能一臺一臺挨個(gè)去找。我們可以采用下面的DNSIPDNS服務(wù)器DNSIPDNS服務(wù)器中，以此類推。也DNSIP地址需要注冊到DNSDNSIP地址又需要注comDNSDNSDNSIPDNS服務(wù)器發(fā)送查詢請求了。com、jp這些域（稱為頂級域）就是最頂層了，它們各自負(fù)責(zé)DNS服務(wù)器的信息，但實(shí)際上并非如此。在互聯(lián)網(wǎng)中，comjp的上面還有一com、jp那樣有自己的名字，因此在一般書寫域名時(shí)經(jīng)常被省\h.這樣在域名的最后再加上一個(gè)DNScom、jpDNSDNSDNS服務(wù)器的信息，所以我們可以DNS服務(wù)器。DNS服務(wù)器信息保存在互聯(lián)網(wǎng)中DNSDNSDNS服務(wù)DNSDNS服DNS服務(wù)器（1.15）。分配給根DNSIP1352，而且這些地址幾乎不發(fā)生變化，因此將52DNSIPIP13個(gè)，但其實(shí)服務(wù)器的圖 找到目標(biāo)DNS服務(wù)DNS服務(wù)器時(shí)，必須要配置好DNSDNS服務(wù)器中找到目標(biāo)服務(wù)器。下面就1.16DNS服務(wù)器（DNS服務(wù)器地址），\hWeb服務(wù)器的相關(guān)信息（1.16①）DNS\hDNS服務(wù)器中保存了DNSDNS服務(wù)器（1.16②）\h這個(gè)域名，但根據(jù)域名結(jié)構(gòu)可以comDNScomDNS服IP地址，意思是“com域問問看”DNScomDNS服務(wù)器發(fā)送查詢消息（③）。com\h這個(gè)域名的信息，和剛才一樣，com域服DNSIP地址。以此類推，只要重復(fù)前\h圖 DNS服務(wù)器之間的查詢操收到客戶端的查詢消息之后，DNSIP地址，并返回給客戶端（1.16⑥）WebIP地址，也就能夠?qū)ζ溥M(jìn)行訪問了（1.16⑦）。DNS1.121.161.12中的⑤和⑥，將這部分重合起來，就可以將這兩張圖連起1.121.16DNS服務(wù)器的上下位置關(guān)系是顛倒著的，gethostbyname查WebDNSIP地址的實(shí)際過程。通過緩存加快DNS1.16展示的是基本原理，與真實(shí)互聯(lián)網(wǎng)中的工作方式還是有一些區(qū)別的。在真實(shí)DNS1.16這樣每個(gè)域DNSDNS服務(wù)器，但現(xiàn)實(shí)中上DNSDNS服務(wù)器時(shí)就DNSDNS服務(wù)器的相關(guān)信息。DNS53功53緩存：指的是將使用過的數(shù)據(jù)存放在離使用該數(shù)據(jù)的地方較近的高速存儲裝置中，以便提高后續(xù)訪問速度的技CPU和內(nèi)存之間的緩存、磁盤和內(nèi)存之間的緩存等，在網(wǎng)絡(luò)中緩存也是一種用來提高改變，這時(shí)緩存中的信息就有可能是不正確的。因此，DNS服務(wù)器中保存的信息都設(shè)置進(jìn)行響應(yīng)時(shí)，DNS服務(wù)器也會告知客戶端這一響應(yīng)的結(jié)果是來自緩存中還是來自負(fù)責(zé)管DNS服務(wù)器。IPIP地址，也就是WebWebHTTP消息是一種數(shù)字信息（digitaldata），因此也可以說是委托協(xié)議棧來發(fā)送數(shù)字信息。收發(fā)數(shù)字信息這一操作Web54。下面就來一起探索這一操作的過54DNSIPDNSIPSocket庫中的程序組IPSocket庫中Socket1.1755。簡單來說，收發(fā)數(shù)據(jù)的兩臺551.17TCPUDP（UserDatagramProtocol，用戶數(shù)圖 數(shù)據(jù)通過類似管道的結(jié)構(gòu)來流56。當(dāng)服務(wù)器進(jìn)入等待狀5657。其中一方斷開后，另一方也會隨之?dāng)嚅_，當(dāng)管道斷開后，套接字也會被刪457WebHTTP版本的不同而不HTTP1.0Web數(shù)據(jù)之后，服務(wù)器一方會斷開管道。1.4.5一節(jié)會有詳細(xì)介創(chuàng)建套接字（創(chuàng)建套接字階段將管道連接到服務(wù)器端的套接字上（連接階段收發(fā)數(shù)據(jù)（通信階段斷開管道并刪除套接字（斷開階段在每個(gè)階段，Socket庫中的程序組件都會被調(diào)用來執(zhí)行相關(guān)的數(shù)據(jù)收發(fā)操作。不過，4個(gè)操作都是由操作系統(tǒng)中的協(xié)議2章介紹。此外，這些委托的操作都是通過調(diào)用Socket庫中的程序組件來執(zhí)行的，但這些數(shù)據(jù)通信用的程序組件其實(shí)僅僅充當(dāng)了一個(gè)橋梁SocketSocket庫和協(xié)議?？闯梢粋€(gè)整體并講解它們的整體行為讓人Socket庫這一橋1.12中所示的一樣。DNSSocketDNS服務(wù)gethostbyname的程序組件（也就是解析器），而這一次則需1.18所示，請大家邊看圖邊繼續(xù)看Socket1.11旁邊關(guān)于調(diào)用解析器的圖 客戶端和服務(wù)器之間收發(fā)數(shù)據(jù)操作的情WebSocket庫中socket58就可以了（1.18①）socket之后，控socket內(nèi)部并執(zhí)行創(chuàng)建套接字的操作，完成之后控制流程又會被移交回應(yīng)用程序。只不過，socket2章為大59socket后套接字就創(chuàng)建好了就可以58Socket、socket、套接字（socket）socket表示Socket表示庫，而漢字的“套接字”則表示管道兩端的接口。59connect、write、read、close2Web服務(wù)器的過程，但實(shí)際上計(jì)算機(jī)中會同時(shí)進(jìn)行多個(gè)數(shù)據(jù)的通信操作，比如可Web服務(wù)器。這時(shí)，有兩個(gè)數(shù)據(jù)收發(fā)操作在同時(shí)應(yīng)用程序是通過“描述符”接下來，我們需要委托協(xié)議棧將客戶端創(chuàng)建的套接字與服務(wù)器那邊的套接字連接起oktonntonntP3個(gè)參數(shù)（1.18②）1個(gè)參數(shù)，即描述符，就是在創(chuàng)建套接字的時(shí)候由協(xié)議棧返回的那個(gè)描述符。connect會將應(yīng)用程序指定的描述符告知協(xié)議棧，然后協(xié)議棧根據(jù)這個(gè)描述符來判斷到底60。60SocketSocket庫的程序組件傳遞給協(xié)議棧，并由協(xié)IPIP地址了。3IP地址就像電IP地址到底能用來干什么。IP地址是為了區(qū)分網(wǎng)絡(luò)中的各個(gè)計(jì)算61IP地址，我們就可以識別出網(wǎng)絡(luò)上的某臺計(jì)算IP地址是無法做到這一點(diǎn)的。我們打電話的時(shí)候，也需要通過“請幫我找一下某某某”IP地61準(zhǔn)確地說，IP地址不是分配給每一臺設(shè)備的，而是分配給設(shè)備中安裝的網(wǎng)絡(luò)硬件的。因此，如果一臺設(shè)備中安IP地址。62。626.1.363IPDNS64。找了半天也沒有任Web8025號端口656章探索服務(wù)器內(nèi)部工作的時(shí)候進(jìn)行介紹，這里大家只要這Web80號端口，這是已經(jīng)規(guī)定好的。631.1的前兩張圖，實(shí)際上根據(jù)網(wǎng)址的規(guī)則，是有用來寫端口號的地方的，但實(shí)際的網(wǎng)址中很少出現(xiàn)端口64DNS65IPIANA（InternetAssignedNumberAuthority，互聯(lián)網(wǎng)編號管理局）這一組織來統(tǒng)一管理的。66。接下來，當(dāng)協(xié)議66IP地址和端口號等信息保存在套接字中，這樣我們就可以開IPSocketwrite這個(gè)程序組件，具體過程如下。HTTPwrite時(shí)，需要指定描述符和發(fā)送數(shù)據(jù)（1.18③），然后協(xié)議棧就會將數(shù)據(jù)發(fā)送到服務(wù)器。由于套接字中已經(jīng)保存了67。676Socket庫中read程序組件委托協(xié)議棧來完成的（1.18③’）read時(shí)需要指定用于存放接息時(shí)，read就會負(fù)責(zé)將接收到的響應(yīng)消息存放到接收緩沖區(qū)中。由于接收緩沖區(qū)是一塊位Socketclose程序組件進(jìn)入斷開階段（1.18④）。最終，連接在套接字之間的管道會被斷斷開的過程如下。WebHTTPWeb服務(wù)器發(fā)送完響應(yīng)消息之68Webclose來斷開連接。斷開操行接收數(shù)據(jù)操作時(shí)，read會告知瀏覽器收發(fā)數(shù)據(jù)操作已結(jié)束，連接已經(jīng)斷開。瀏覽器得知close進(jìn)入斷開階段。68closeclose，而另外close。HTTP的工作過程。HTTPHTML文檔和圖片都作為單獨(dú)的對象來處HTTP1.1中就可以使用這種Web服務(wù)器之間收發(fā)消息的過程，但實(shí)際負(fù)責(zé)收發(fā)消息的3者相互配合，數(shù)據(jù)才能夠在網(wǎng)絡(luò)中流動起來。下一\hhttp://www.nikkeibp.co.jp/http\h\hWebIPDNS Resolver69“怪杰”一詞出自“怪杰佐羅”，日語中“怪杰”與“解決”（resolve）的讀音相同，這里是一個(gè)諧音的梗。——詞匯是人類創(chuàng)造的，如果能理解詞匯創(chuàng)造者的思路，也就能理解這個(gè)詞的真正含義。而理解網(wǎng)絡(luò)中每個(gè)詞匯的真正含義之后，對網(wǎng)絡(luò)的理解也會更加深入，反過來也會更加理解設(shè)計(jì)和創(chuàng)造網(wǎng)絡(luò)的那些人。各位有不懂的詞嗎？問問我們的探索隊(duì)長吧！DNS客戶端的名字叫解析器，這個(gè)名字有點(diǎn)怪呢，為什么要叫解析器resolveresolver。……IPDNS服務(wù)器發(fā)送查詢消息之類的DNSIP地址，是不是？IP地址。resolver這個(gè)詞的意思呢。resolver嘛。（AddressResolutionProtocol，ARP）resolution也是一樣ARPIPMAC地址這個(gè)答案，從這個(gè)角度來看是ARPARP……ARP解析器也沒錯(cuò)，不過好像沒聽說過誰這么叫的?！璈TTP協(xié)議（參見【1.1.1】asample代表文件名，bsample代表目錄名（參見【1.1.3】IP地址（參見【1.2.1】DNS服務(wù)器（參見【1.2.31.3】解析器（參見【1.2.3】2章TCP/IP數(shù)據(jù)——探TCP/IPTCPIP兩個(gè)協(xié)議的名字組合而成的，最開始這兩個(gè)協(xié)議是合在一起2060（IEEE802.3/802.2），而是遵循一個(gè)更古老的規(guī)格（2DIX規(guī)格），√TCP/IPTCPIP合在一起的樣子，后來才TCPIP兩個(gè)協(xié)議。1HTTP1章介紹了發(fā)送消息的場景，接下來我們將視角切換到協(xié)議棧的內(nèi)部來繼續(xù)探索TCP4個(gè)階段。IPTCP協(xié)議收發(fā)消息的操作之后，我們再來看看實(shí)際的網(wǎng)絡(luò)包是如何進(jìn)行收發(fā)UDPTCP協(xié)議有很多方便的功能，比如網(wǎng)絡(luò)包出錯(cuò)丟失時(shí)可以重發(fā)，因此很多應(yīng)用程序TCP協(xié)議來收發(fā)數(shù)據(jù)的，但這些方便的功能也有幫倒忙的時(shí)候，在這種情況下UDPUDPTCP的差2.1所示，分為幾個(gè)部分，分別承擔(dān)不同的功能。這張圖中的上下圖 TCP/IP軟件采用分層結(jié)子郵件客戶端、Web服務(wù)器、電子郵件服務(wù)器等程序，它們會將收發(fā)數(shù)據(jù)等工作委派給SocketDNS服務(wù)器發(fā)出查1章已經(jīng)介紹過了。TCPUDPTCPUDP我們將在后面講解，現(xiàn)在大家只要先記住TCP收發(fā)數(shù)據(jù)的，而DNSUDP。TCP；DNS查詢等收發(fā)較短的控制數(shù)據(jù)時(shí)用UDP。1IP來負(fù)責(zé)的。此外，IPICMP2ARP3ICMP用于告知網(wǎng)絡(luò)包傳送過程中產(chǎn)生的錯(cuò)誤以及各種控制消息，ARPIPMAC4。12ICMP2.5.113ARP2.5.54MACIEEEMACIP下面的網(wǎng)卡驅(qū)動程序負(fù)責(zé)控制網(wǎng)卡硬件，而最下面的網(wǎng)卡則負(fù)責(zé)完成實(shí)際的收發(fā)IP地址、端口號、通信操作的進(jìn)行狀態(tài)等。本來套接字就只5。例如，在發(fā)送數(shù)據(jù)時(shí)，需要看一看套IPIP地址和端口發(fā)送數(shù)據(jù)。在發(fā)送數(shù)據(jù)5這里的控制信息類似于我們在筆記本上記錄的日程表和備忘錄。我們可以根據(jù)筆記本上的日程表和備忘錄來決Windowsnetstat命令顯示套接字內(nèi)容（2.2）6。圖中每一行相當(dāng)于一個(gè)套6圖 顯示套接字內(nèi)8PID7為4IP6IP8的對象進(jìn)行通信。1031139139Windows1PID984135端口等待另一方的連接，其中IPIP，這表示通信還沒開始，IP8。7PID：ProcessID（進(jìn)程標(biāo)識符）的縮寫，是操作系統(tǒng)為了標(biāo)識程序而分配的編號，使用任務(wù)管理器可以查詢所8IPIPIP地址之外，對其socketsocket9、connectSocket9socketSocketSocketsocketSocketsocket的程序組Socket庫向協(xié)議棧發(fā)出委托的一系列操作（圖TCP10，因此下面的講解都是TCP的。10TCPTCPUDP圖 消息收發(fā)操112.3socket申請創(chuàng)建套接112.3gethostbyname（解析器）DNS1DNS的內(nèi)容中12計(jì)算機(jī)內(nèi)部會同時(shí)運(yùn)行多個(gè)程序，如果每個(gè)程序都擅自使用內(nèi)存空間的話，就有可能發(fā)生多個(gè)程序重復(fù)使用同13。131.4.2創(chuàng)建套接字之后，應(yīng)用程序（瀏覽器）connect，隨后協(xié)議棧會將本地的套IP80號端口，但只有socket創(chuàng)建套接字時(shí)，這些信息并沒IP地址和端口號等信息告知協(xié)議棧，這是14，但服務(wù)器上的于是，我們需要讓客戶端向服務(wù)器告知必要的信息，比如“IP地xxx.xxx.xxx.xxxyyyy。”可見，客戶端向服務(wù)器傳達(dá)開始通信的請求，也146章進(jìn)行IP地址和端口號告知服務(wù)器這樣作所需的一些信息，IP地址和端口號就是典型的例子。除此之外還有其他一些控制信塊內(nèi)存空間稱為緩沖區(qū)，它也是在連接操作的過程中分配的。上面這些就是“連接”1515使用“連接”100多年，從通信技術(shù)誕生之初到幾年之前的很長一段TCP協(xié)議的規(guī)格2.1TCP16。這2.4（a）所示，這些信息會被添加在客戶IP協(xié)議也有自己的控制信息，這些信息也叫頭TCP17、IP16這張表中只列出了必需字段，TCP17以太網(wǎng)頭部又稱“MAC頭部”表 TCP頭部格特TCP頭部ACK號（接收數(shù)據(jù)節(jié)。其中，ACKacknowledge的縮寫PSHflush圖 客戶端與服務(wù)器之間交換的控制信發(fā)送方：“號數(shù)據(jù)?！苯邮辗剑骸啊痢撂枖?shù)據(jù)已收到。”……（以下省略18。些信息”19，但這并沒有什么問題。因?yàn)閰f(xié)議棧端和服務(wù)器之間的通信就能夠得以成立。例如，WindowsLinux操作系統(tǒng)的內(nèi)部結(jié)構(gòu)不一些重要的套接字控制信息（2.2），這些信息無論何種操作系統(tǒng)的協(xié)議棧都是共通1819無論協(xié)議棧的實(shí)現(xiàn)如何不同，IP套接字（協(xié)議棧中的內(nèi)存空間）Socketconnect開始的（2.3②）。connect（IPIPTCP模塊。然后，TCPIPTCP模塊交換控制信2.1所示，頭部包含很多字段，這里要關(guān)注的重點(diǎn)是發(fā)送方和SYN120。此外還需要設(shè)置適當(dāng)?shù)男蛱柡痛翱诖笮。@20SYNTCPTCPTCPTCPIP模塊并委托它進(jìn)行發(fā)21。IP模塊執(zhí)行網(wǎng)絡(luò)包發(fā)送操作后，網(wǎng)絡(luò)包就會通過網(wǎng)絡(luò)到達(dá)服務(wù)器，然后服務(wù)器上IPTCPTCPTCP頭部中的信TCP頭22TCP模塊會返回響TCPSYN比23ACK124，這表示已經(jīng)接收到相應(yīng)的網(wǎng)25ACKTCPTCPIPIP模塊向客戶端返回響應(yīng)。21IP22623SYNRST124ACK025IPTCPTCP頭部的SYN1則表示連接成功，這時(shí)會向套接字IP地址、端口號等信息，同時(shí)還會將狀態(tài)改為連接完畢。到這里，客戶ACK比特1ACK1并發(fā)回服務(wù)器，告訴服務(wù)器剛才26。只要數(shù)據(jù)傳輸過程在close斷開之前，連接是一直存在的。26這里的“連接”Connection。也有人把連接稱為“會話”（session），它們的意思大體上connect已經(jīng)執(zhí)行完畢，控制HTTPwrite將要發(fā)送的數(shù)據(jù)交給協(xié)議棧開始的（2.3③），協(xié)議棧收write時(shí)會MTU27的參數(shù)來進(jìn)行判斷。MTU1500字節(jié)（圖2.5）28。MTUMTU減去頭部的長度，然后得到的長MSS29。當(dāng)從應(yīng)用程序收MSS時(shí)再發(fā)送出去，就可以避免發(fā)送大量小包的問題了。27MTU：MaximumTransmissionUnit，最大傳輸單元?！?.3.2節(jié)進(jìn)行講解。option），MSS就會隨著頭部長度增加而相應(yīng)縮短。MTU1500MSSTCP30起始幀分界符：StartFrameDelimiter，SFD?！?1FCS：FrameCheckSequence，幀校驗(yàn)序列?！幷咦D2.5 MTU與MSSMSS時(shí)再發(fā)送，可能會因?yàn)榈却龝r(shí)間太長而造成發(fā)送延遲，這種情況下，即便緩MSS，也應(yīng)該果斷發(fā)送出去。為此，協(xié)議棧的內(nèi)部有一個(gè)計(jì)32。32到平衡。不過，TCP協(xié)議規(guī)格中并沒有告訴我們怎樣才能平衡，因此實(shí)際如何判斷是由HTTP請求消息一般不會很長，一個(gè)網(wǎng)絡(luò)包就能裝得下，但如果其中要提交表單數(shù)TCP頭部，并根據(jù)套接字中記錄的控制信息標(biāo)記發(fā)送方和接收方的端口號，然IP模塊來執(zhí)行發(fā)送數(shù)據(jù)的操作（2.6）33。33IPIPMAC圖 應(yīng)用程序數(shù)據(jù)的拆分發(fā)TCPACK我們先來看一下確認(rèn)的原理（2.7）。首先，TCPTCP頭部中，“序號”字段就是派在這個(gè)用場上的。然后，發(fā)送數(shù)據(jù)的長度也需要告知TCP頭部里面的，因?yàn)橛谜麄€(gè)網(wǎng)絡(luò)包的長度減去頭部的長圖 序號和ACK號的用14601461的包，說明中間沒有遺漏；但如果收到的2921，那就說明中間有包遺漏了。像這樣，如果確認(rèn)沒有遺漏，接收方會將到TCPACK34。簡單來說，發(fā)送方說的是“現(xiàn)在發(fā)送的是從××××字節(jié)哦！”而接收方則回復(fù)說，“××字節(jié)之前的數(shù)據(jù)我已經(jīng)都收到了哦！”ACK號的操作被稱為確認(rèn)響應(yīng)，通過這樣的方式，發(fā)34ACKACKACK1ACK號字段有ACK號的。2.71開始，通信過程SYN1并SYN設(shè)135。SYN原本的含ACK號來進(jìn)行數(shù)據(jù)確認(rèn)的思路，但僅憑這些還不夠，因?yàn)槲襎CP數(shù)據(jù)收發(fā)是雙向的，在客戶端向服務(wù)器發(fā)送數(shù)2.7中展示的客戶端向服務(wù)器發(fā)送數(shù)據(jù)的情形，我們只要增加一種左右相2.8所示。首先客戶端先計(jì)算出一個(gè)序號，然后將序號和數(shù)據(jù)一ACK號并返回給客戶端；相反地，服務(wù)器也需ACK號并返回給服務(wù)器。此外，如圖所示，客戶端和服務(wù)器雙方都需要各自計(jì)算序號，圖 數(shù)據(jù)雙向傳輸時(shí)的情2.9①）ACK號并返回給客戶端（②）ACK號作將這個(gè)值發(fā)送給客戶端（2.9②）。接下來像剛才一樣，客戶端也需要根據(jù)服務(wù)器發(fā)來ACK號并返回給服務(wù)器（2.9③）ACK號都已經(jīng)準(zhǔn)Web中是先由客戶端向服務(wù)器發(fā)送請求，序號也會跟隨數(shù)據(jù)一起發(fā)送（2.9④）ACK號（2.9⑤）。從服務(wù)器向客戶端發(fā)送數(shù)據(jù)的過程則正好相反（2.9⑥⑦）。圖 序號和ACK號的交TCP采用這樣的方式確認(rèn)對方是否收到了數(shù)據(jù)，在得到對方確認(rèn)之前，發(fā)送過的包ACK號，那么就重新發(fā)送這TCP傳輸，即便發(fā)生一些錯(cuò)誤對方最終也能夠收到TCP怎樣重傳都不管用。這種情況下，無論如何嘗試TCP會在嘗試幾次重傳無效之后強(qiáng)制結(jié)束通信，并向應(yīng)用程序報(bào)錯(cuò)。通過“序號”和“ACK號”根據(jù)網(wǎng)絡(luò)包平均往返時(shí)間調(diào)整ACKACK號的等待時(shí)間（這個(gè)等待時(shí)間叫超時(shí)時(shí)間）。當(dāng)網(wǎng)絡(luò)傳輸繁忙時(shí)就會發(fā)生擁塞，ACK號的返回會變慢，這時(shí)我們就必須將等待時(shí)ACK號才姍姍來遲的36ACK號的返回變慢大多是由于網(wǎng)絡(luò)擁塞引起的，因此如果此時(shí)再出現(xiàn)很多多余36務(wù)器物理距離的遠(yuǎn)近，ACK號的返回時(shí)間也會產(chǎn)生很大的波動，而且我們還必須考慮到ACK號，但在互ACK號也并不稀奇。TCPACK號返回所需的時(shí)間來判斷的。具體來說，TCPACKACKACK號馬上就能返回，則相應(yīng)縮短等37。37由于計(jì)算機(jī)的時(shí)間測量精度較低，ACK0.51ACK2.10（a）ACK號的方式是最簡單也最容易理ACK號的這段時(shí)間中，如果什么都不做那實(shí)在太浪費(fèi)了。為了減少這樣的浪費(fèi)，TCP2.10（b）ACK號的操作。ACK號返回，而是直接發(fā)送后續(xù)的一系A(chǔ)CK號的這段時(shí)間就被有效利用起來了。圖 一來一回方式和滑動窗口方ACK號時(shí)的時(shí)間浪費(fèi)，但有一些問題需要注意。在一來一ACKACK號之后才繼續(xù)發(fā)ACK號就連續(xù)發(fā)送包，就有可能會出現(xiàn)發(fā)送包的頻率超過接收方處理能力的情況。TCP收到包后，會先將數(shù)據(jù)存放到接收緩沖區(qū)ACK號，將數(shù)據(jù)塊組裝起來還原成原本的數(shù)據(jù)并傳遞給應(yīng)用TCP頭部中的窗口字段圖 滑動窗口與接收緩沖2.11中只顯示了從右往左發(fā)送數(shù)據(jù)的操作，實(shí)際上和序號、ACK號一樣，38TCP調(diào)優(yōu)參數(shù)中非常有名38ACKACK號和更新窗口的ACK號又是什么情況呢？當(dāng)接收方收到數(shù)據(jù)時(shí)，如果確認(rèn)內(nèi)容沒有問題，就應(yīng)ACK號，因此我們可以認(rèn)為收到數(shù)據(jù)之后馬上就應(yīng)該進(jìn)行這一操作。ACK39，當(dāng)數(shù)據(jù)傳遞給應(yīng)用程序之后才ACK40。這樣一來，接收方發(fā)給發(fā)送方的包就太多3940ACK號和窗口更新時(shí)，并不會馬上把包發(fā)送出去，而是會等待ACK號的時(shí)候正好需要更新窗口，這時(shí)就可ACK號和窗口更新放在一個(gè)包里發(fā)送，從而減少包的數(shù)量。當(dāng)需要連續(xù)發(fā)送多個(gè)ACKACK號表示的是已收到的數(shù)據(jù)量，也就是ACK號ACK號就可以了，中間的可以全部省略。當(dāng)需要連續(xù)發(fā)送多個(gè)窗ACK號一樣，可以省略中間過程，只要發(fā)送HTTPHTTP請求消息的一系列操HTTP請求消息后，接下來還需要等待Web服務(wù)器返回響應(yīng)消息。對于響應(yīng)消息，瀏覽器需要進(jìn)行接收操作，這一操作也需要Web服務(wù)器的順序逐一講解HTTP響應(yīng)消息應(yīng)該放在最后再講，但這樣一來大家可read程序（2.3④）read41，然后協(xié)議棧會執(zhí)行接下42，4142大家可以認(rèn)為這時(shí)協(xié)議棧會進(jìn)入暫停狀態(tài)，但實(shí)際上并非如此。協(xié)議棧會負(fù)責(zé)處理來自很多應(yīng)用程序的工作，43TCP頭部的內(nèi)容，判斷是否有數(shù)據(jù)ACK號。然后，協(xié)議棧將數(shù)據(jù)塊暫存到接收緩沖區(qū)中，并將44。43644ACKWebWeb服務(wù)器發(fā)送請求消息，Web服務(wù)器再返回響應(yīng)消息，這45。當(dāng)然，可能也有一些45HTTP1.0HTTP1.1中，服務(wù)器返回響應(yīng)消息之后，客戶端還可以繼續(xù)發(fā)起下一個(gè)請求Socketclose程序。然TCPFIN1IP模塊向客戶端發(fā)送數(shù)據(jù)（2.12①）。同時(shí)，服圖 斷開連接的交互過FIN1TCP頭部時(shí)，客戶端的協(xié)議FIN1ACK號（2.12②）。這些操作完成后，協(xié)議棧就可read46。這時(shí)，協(xié)議棧不會向應(yīng)用程序47，而是會告知應(yīng)用程序（瀏覽器）來自服務(wù)器的數(shù)據(jù)已經(jīng)全部收到了。根據(jù)規(guī)則，服務(wù)器返回請求之后，Web通信操作就全部結(jié)束了，因此只要收到服務(wù)器返回的close來結(jié)束數(shù)FIN1TCPIP模塊發(fā)送給服務(wù)器（2.12③）號（2.12④）46FIN1FIN包到達(dá)再繼472.12的過程相反，客戶端先發(fā)起斷開，則斷開ACKACKACKACKFIN48FINFIN是要發(fā)給剛剛FIN就會錯(cuò)誤地跑到新48TCP協(xié)議收發(fā)應(yīng)用程序數(shù)據(jù)的操作就全部結(jié)束了。這部分內(nèi)容的講解比1TCP包并發(fā)送給服務(wù)器（2.13①）TCP包的頭部還包含了客戶端向服務(wù)49SYN1TCP包（2.13②）。和2.13①一樣，這個(gè)包的頭部中也包含了序號和窗口大小，此外還包含表示確認(rèn)已收到ACK50。當(dāng)這個(gè)包到達(dá)客戶端時(shí)，客戶端會向服務(wù)器返回一個(gè)包含表示確認(rèn)的ACKTCP包（2.13③）492.11所示，窗口大小是由接收方告知發(fā)送方的，因此，在最初的這個(gè)包中，客戶端告訴服務(wù)器的窗口大小ACK2.13顯示了窗50ACKACK1圖 TCP的整體流Web為例，首先客戶端會向服務(wù)器發(fā)送請求消息。TCP會將請求消息切分成一定大小的塊，并在每一塊前面加TCP頭部，然后發(fā)送給服務(wù)器（2.13④）。TCP頭部中包含序號，它表示當(dāng)前發(fā)送（2.13⑥⑦）Web51FIN1TCP包（2.13⑧），ACK號（2.13⑨）FIN1TCP包（2.13⑩）ACKTCP包（2.13k）51HTTP1.1IPTCPIP模塊將數(shù)據(jù)封裝TCPIPIP模塊是由頭部和數(shù)據(jù)兩部分構(gòu)成的（2.14（a））。頭部包含目的地址等控制信息，大家可以2.15所示。圖 網(wǎng)絡(luò)包的結(jié)圖 發(fā)送方、接收方和轉(zhuǎn)發(fā)設(shè)查表的結(jié)果是“××××××××號線路”，那么轉(zhuǎn)發(fā)設(shè)備就會把這個(gè)××××號線路去。接下來，包在向目的地移動的過程中，又會到達(dá)下一個(gè)轉(zhuǎn)發(fā)設(shè)52。52絡(luò)。不過，TCP/IP包的結(jié)構(gòu)是在這個(gè)基本結(jié)構(gòu)的基礎(chǔ)上擴(kuò)展出來的，因此更加復(fù)雜。在IPIPIP2.14（b）所示，TCP/IPMAC頭部（用于以太網(wǎng)協(xié)議IP頭部（IP協(xié)議IPIP頭部中。這樣一來，我們就知道這個(gè)包應(yīng)該發(fā)往哪里，IP協(xié)議就可以2.16中的路R1。接下來，IP協(xié)議會委托以太網(wǎng)協(xié)議將包傳輸過去。這時(shí)，IP協(xié)議會查找下一個(gè)路由器的以太網(wǎng)地址（MAC地址），MAC頭部中。這樣一來，以太圖 IP網(wǎng)絡(luò)包的傳輸方網(wǎng)絡(luò)包在傳輸過程中（2.16①）會經(jīng)過集線器，集線器是根據(jù)以太網(wǎng)協(xié)議工作的IP頭部中記錄的目的地信息查出接下來應(yīng)該發(fā)往哪個(gè)路由器。為了將包發(fā)MAC53。這樣，網(wǎng)絡(luò)包就又被發(fā)往下一個(gè)節(jié)點(diǎn)了。53MACMACMAC頭R2。這IP和以太網(wǎng)的分工，其中以太網(wǎng)的部分也可以替換成其他的東西，例如無線局域網(wǎng)、ADSL、FTTH等，它們都可IP54IP和負(fù)責(zé)傳輸?shù)木W(wǎng)絡(luò)分54當(dāng)使用除以太網(wǎng)之外的其他網(wǎng)絡(luò)進(jìn)行傳輸時(shí)，MACIP模塊是如何完成包收發(fā)操作的。IP模塊負(fù)責(zé)將包發(fā)給對方，但實(shí)際上將包從發(fā)送方傳輸?shù)浇邮辗降墓ぷ魇怯?5IP模塊僅僅是整個(gè)包傳輸過程的入口而已。即便如此，IP模塊還是有很多工作需要完成，首先我們先粗略地整理一下。553TCPIP模塊發(fā)送包的操作（2.17中的“①發(fā)送”）。TCPTCPIP模TCPIP地址，也圖 包收發(fā)操作的整體過收到委托后，IP模塊會將包的內(nèi)容當(dāng)作一整塊數(shù)據(jù)，在前面加上包含控制信息的頭部。剛才我們講過，IPIPMAC頭部這兩種頭部。IPIP協(xié)IP地址將包發(fā)往目的地所需的控制信息；MAC頭部包含通過以太網(wǎng)的局56IPMAC頭部的區(qū)別以及IP模塊負(fù)責(zé)的工作。56MAC頭部，但其內(nèi)容根據(jù)局域網(wǎng)的類型有所不同。此外，對于除局域網(wǎng)之外的MACMAC頭部是相同IPMACMACIP頭部：IPIP接下來，封裝好的包會被交給網(wǎng)絡(luò)硬件（2.17中的“②發(fā)送”），例如以太網(wǎng)、無PCMCIA卡，或者是計(jì)算機(jī)主板上集成的芯片，不同形態(tài)的硬件名字也不一樣，本書將5701組成的數(shù)字信息，網(wǎng)卡會將57把集成在主板上的網(wǎng)絡(luò)硬件叫作“網(wǎng)卡”可能聽上去有些奇怪，從這個(gè)意義上來看應(yīng)該叫作“網(wǎng)絡(luò)接口”USB接口上的網(wǎng)卡，在計(jì)算機(jī)的領(lǐng)域中，“接口”這個(gè)詞有時(shí)候會帶來更多的歧義。在計(jì)算機(jī)和網(wǎng)IP模塊（2.17中的“③接收”）。接下來，IPMACIPTCP頭部加上數(shù)據(jù)塊，傳遞給TCPTCP模塊負(fù)責(zé)的部分了。在這個(gè)過程中，有幾個(gè)關(guān)鍵的點(diǎn)。TCP模塊在收發(fā)數(shù)據(jù)時(shí)會分為好幾個(gè)階段，并為IP的包收發(fā)操作都是相同的，并不會因包本IPTCP頭部和數(shù)據(jù)塊看作一整塊二進(jìn)制數(shù)據(jù)，在執(zhí)行收發(fā)TCP頭部和數(shù)據(jù)兩者都有呢，還是TCP頭部而沒有數(shù)據(jù)。當(dāng)然，IPTCP的操作階段，對于包的亂序和丟失也一概不知?？傊?，IP的職責(zé)就是將委托的東西打包送到對方手里，或者是將對方送IP的工作方式，可適用TCP委派的收發(fā)操作。無論要收發(fā)的包是控制包還是數(shù)據(jù)包，IP對各種類型的包的收發(fā)操作都是相同IPIPIP模塊的具體工作過程。IPTCP模塊的委托負(fù)責(zé)包的收發(fā)工IPTCP頭部前面。IP2.2所示，其中最I(lǐng)PTCP模塊告知TCP又是在執(zhí)行連接操作時(shí)從應(yīng)用程序那里獲得這個(gè)地址的，因此這個(gè)地址的最初來源就是應(yīng)用程序。IP不會自行判斷包的目的地，而是將包發(fā)往應(yīng)用程序指定的接收IP地址，IP模塊也只能照做。當(dāng)然，這樣做肯定會出錯(cuò)58。58SYNTCP連接完畢，就已經(jīng)確認(rèn)能夠正常和對方表 IP頭部格特（20IPIP頭部的長度?？蛇x字段可導(dǎo)致頭部長度變化，因此這里需要指定頭部的DiffServIPIDIP分片，則所有分ID32個(gè)比特有效，分別代表是否允許分片，以及當(dāng)IP10時(shí)這個(gè)包就會被丟棄協(xié)議號表示協(xié)議的類型（以下均為十六進(jìn)制）TCP:UDP:ICMP:IPIPIPIPIPIPIP，實(shí)際上“IP地址”這種說法并不準(zhǔn)確。一般的客戶端計(jì)算機(jī)上只有一塊網(wǎng)卡，IPIPIP地址，但如果計(jì)算機(jī)上有多個(gè)網(wǎng)卡，情況就沒那么簡單了。IP地址實(shí)際上并不是分配給計(jì)IPIP地址，在填寫發(fā)IP地址時(shí)就需要判斷到底應(yīng)該填寫哪個(gè)地址。這個(gè)判斷相當(dāng)于在多塊網(wǎng)卡中判斷應(yīng)IP地址。59IPDHCPIPIPIP頭部的“IP地址”IPIPIP這個(gè)“IP表”603章探索路由器時(shí)詳細(xì)介紹它的用法，這里2.18routeprint命令來顯示路由表，下面來邊IPNetworkDestination欄進(jìn)行比較，找到對應(yīng)的一行。例如，TCPIP1，那么2.186192.168.1IP地址為6610.10.13行。以此類推，我們需要找IP612列32Interface列，表示網(wǎng)卡等網(wǎng)絡(luò)接口，這些網(wǎng)絡(luò)接3GatewayIPIP6263。路由164，這表示默認(rèn)網(wǎng)關(guān)，如果其他所有條6560RoutingTable61362Gateway（網(wǎng)關(guān)）TCP/IP63GatewayInterfaceIPIP地3章詳細(xì)介紹。64IP1.2.1653圖 路由表示IP頭部IPIP地址。TCP06（十六進(jìn)制），UDP模塊委托的內(nèi)容，則設(shè)置為17（十六進(jìn)制），這些值都是按照規(guī)則來設(shè)置的。在現(xiàn)在我們使用的瀏覽器中，HTTP請TCPTCP06（十六進(jìn)制）。3章進(jìn)行介紹，MACIPIPIPMAC頭部（表2.3）。IPIP地址表示網(wǎng)絡(luò)包的目的地，通過這個(gè)地址我們就可以判斷要將包發(fā)到哪里，但在以太網(wǎng)的世界中，TCP/IP的這個(gè)思路是行不通的。以太網(wǎng)在判斷網(wǎng)TCP/IP的方式不同，因此必須采用相匹配的方式才能在以太網(wǎng)中將包發(fā)MAC頭部就是干這個(gè)用的。表 MAC頭部的字特MAC頭部（14MACMAC地址，在局域網(wǎng)中使用這一地址來傳輸網(wǎng)MACMAC地址，接收方通過它來判斷是誰發(fā)送了這TCP/IP通信08000806這兩種。0000-05DC：IEEE ：IP ：ARP IPIPMAC頭部。MAC頭部是以太網(wǎng)使用MAC地址等信息。MAC頭部的相關(guān)知識才能理解，因此先介紹一些最基礎(chǔ)的。MACMAC地IPIPIP32MAC48比特。此外，IP地址是類似多少弄多少號這種MAC48比特可以看作是一個(gè)整體。盡管有上述差異，但從表示接收方和發(fā)送方的意義上來說，MACIP地址是沒有區(qū)別的，因3IP頭部中的協(xié)議號類IPIP頭部后面的包內(nèi)容的類型；而在以太網(wǎng)中，我們可以認(rèn)為以IP、ARP66。662.3IPIPMAC2.33個(gè)字段就可以了。方便起見，我們按照從下往上的順序來對表進(jìn)行講解。首先是“以太類型”IP協(xié)議的值0800（十六進(jìn)制）MACMAC地址。MACROMMAC67IP68IPMAC地址填進(jìn)去就好了。67MAC地址，讀取出來之后會存放在內(nèi)ROMMAC地址拿出來放到內(nèi)存中并用于MACMAC地址。682.5.3MAC地址就有點(diǎn)復(fù)雜了。只要告訴以太網(wǎng)對方的MACMACGatewayIP地址就可以了。MACMAC地址IPMAC地址的操作。IPGatewayARPMACARP69，它其實(shí)非常簡單。在以太網(wǎng)中，有一種叫作廣播的方法，可以把包發(fā)給連接在同一以太網(wǎng)中的所有設(shè)備。ARP就是利用廣播對所有設(shè)備提問：IPMAC地址告訴我。”然后就會有人回答：“這個(gè)IPMAC××××?！?0（2.19）69ARP：AddressResolutionProtocol70IP圖 用ARP查詢MAC地MAC地71MACMAC頭部，MAC頭部就完成了。71ARP響應(yīng)，這時(shí)只能認(rèn)為對方不存ARP包，因此我們ARP緩存的內(nèi)存空間中留著以后用。也就是說，在發(fā)送包ARPMACARPARPARPMAC地址時(shí)，則發(fā)送ARPARPMAC2.202.21所示，供大家參圖 ARP緩存的內(nèi)圖 MAC地ARPARPARP緩存中保存的IP地址發(fā)生變化時(shí)，ARP緩存的內(nèi)容就會和現(xiàn)實(shí)發(fā)生差異。為了防止這種問題的發(fā)生，ARP緩存中的值在經(jīng)過一段時(shí)間后會被刪除，一般這個(gè)時(shí)間ARP緩存中的內(nèi)容是否有效，只要ARP緩存中刪除后，只要重新ARP查詢就可以再次獲得地址了。IP候，ARP7272ARPMACARPMACIP頭部的前面，整個(gè)包就完成了。到這里為止，整個(gè)打包的工作IP模塊負(fù)責(zé)的。有人認(rèn)為，MACIP的職責(zé)范IP負(fù)責(zé)整個(gè)打包工作是有利的。如果在交給網(wǎng)卡之前，IP模塊能IP以外的其IP包是完全相同的。這樣一來，同一塊網(wǎng)卡就可以支持各種類型的包。至于接收操IP模塊來處理，網(wǎng)卡就只IP包，不如將分工設(shè)計(jì)得現(xiàn)實(shí)一些，讓網(wǎng)卡IP模塊的工作之后，下面就該輪到網(wǎng)卡了，不過在此之前，我們先來了解一些2.22（a）所示。從圖上不難看出，這種網(wǎng)絡(luò)的本質(zhì)其實(shí)就是一根網(wǎng)線。圖上還2.3中列出的MACMACMAC地址，就能夠知道包是發(fā)給誰的；而通過MAC地址，就能夠知道包是誰發(fā)出的；此外，通過以太類型就可以判斷包里面裝73。73實(shí)際上，多臺設(shè)備同時(shí)發(fā)送信號會造成碰撞，當(dāng)然也有相應(yīng)的解決方案，不過這部分比較復(fù)雜。隨著交換式集圖 以太網(wǎng)的基本結(jié)7475。不過，雖然網(wǎng)絡(luò)的結(jié)構(gòu)有所變化，但74中繼式集線器：在以太網(wǎng)（10BASE-T/100BASE-TX）3.1.4一節(jié)進(jìn)行介紹。（以75（a）和（b）MACMAC頭76以下將“交換式集線器”簡稱為“交換機(jī)”?！?個(gè)性質(zhì)至今仍未改變，即將包發(fā)送到MACMACMAC地址識別發(fā)送方，用以太377。77MACMAC地址所代表的目的地，用發(fā)78。78路由器等網(wǎng)絡(luò)設(shè)備的網(wǎng)卡是集成在設(shè)備內(nèi)部的，其電路的設(shè)計(jì)也有所不同，盡管結(jié)構(gòu)有差異，但功能和行為是IPTCP7979將IP下面來看看以太網(wǎng)的包收發(fā)操作。IP生成的網(wǎng)絡(luò)包只是存放在內(nèi)存中的一串?dāng)?shù)字信80802.2381，但依然可以看清大體的思路。記住這一內(nèi)部結(jié)構(gòu)之后，我們再來介紹81圖 網(wǎng)MAC82MAC地址。82MAC：MediaAccessControl的縮寫。MAC頭部、MACMACMACMACROMMAC地址，這是在生產(chǎn)網(wǎng)卡時(shí)寫入的，將這個(gè)MAC模塊進(jìn)行設(shè)置，MACMAC地址了。MACMACROMMAC地址。有人認(rèn)為在網(wǎng)卡通電之后，ROM中MACMAC模MAC84。在操作系統(tǒng)啟動并完成這些初始化操作之后，網(wǎng)卡就可IP的委托了。83MAC84MACMAC地址重復(fù)，否則網(wǎng)絡(luò)將無法ROMMACMAC地址會由網(wǎng)卡驅(qū)動程序讀取并分配給MAC3IPMAC模塊發(fā)送發(fā)送包的命MAC模塊進(jìn)行工作了。首先，MAC模塊會將包從緩沖區(qū)中取出，并在開頭加上報(bào)頭和起始幀分界符，在末尾加上用于檢測錯(cuò)誤的幀校驗(yàn)序列（2.24）85。85IEEE出于歷史原因使用了“幀”而不是“包”，因此在以太網(wǎng)術(shù)語中都是說“幀”，其實(shí)我們2.24圖中顯示了協(xié)議棧和網(wǎng)卡對包的處理過程。MAC10101010…105610102.25這2.25每個(gè)包的前面都有報(bào)頭和起始幀分界符（SFD），報(bào)頭用來測定時(shí)機(jī)，SFD01兩種比特分別對應(yīng)特定的電壓和電2.26（a）這樣的電信號就可以表達(dá)數(shù)字信息。通過電信號來讀取數(shù)據(jù)的過程12.26所示的那樣有分隔每個(gè)比特的輔助2.26（a）10連續(xù)出現(xiàn)的信號，由于電壓和電流沒有變化，我們就沒辦法判圖 通過時(shí)鐘測量讀取信號的時(shí)2.26（b）86讀取電壓和電流的值，然862.26（c）2.26（b）這樣01的比特了。10Mbit/s100Mbit/s這種固定頻率進(jìn)行變化的，就像我們乘坐自動扶梯一樣，只要對信號進(jìn)行一段時(shí)間87。87如果在包信號結(jié)束之后，繼續(xù)傳輸時(shí)鐘信號，就可以保持時(shí)鐘同步的狀態(tài)，下一個(gè)包就無需重新進(jìn)行同步。有01的。因此，101010…2.25中的那個(gè)樣子，而2.25中也已經(jīng)畫出來了，它的末尾比特排列有少許變FCS（幀校驗(yàn)序列）用來檢查包傳輸過程中因噪聲導(dǎo)致的波形紊亂、數(shù)據(jù)錯(cuò)32比特的序列，是通過一個(gè)公式對包中從頭到尾的所有內(nèi)容進(jìn)行計(jì)算而得CRC88錯(cuò)誤校驗(yàn)碼是同一FCSFCS就會不同，這樣我們就可以判斷出數(shù)據(jù)有沒有錯(cuò)誤。88CRC：CyclicRedundancyCheckFCS之后，我們就可以將包通過網(wǎng)線發(fā)送出去了（圖89模式。89發(fā)送和接收同時(shí)并行的方式叫作“全雙工”，相對地，某一時(shí)刻只能進(jìn)行發(fā)送或接收其中一種操作的叫作“半雙MAC模塊從報(bào)頭開始將數(shù)字信息按每個(gè)比特轉(zhuǎn)換成電信PHYMAU90。在這里，將數(shù)字信息轉(zhuǎn)換10Mbit的數(shù)字信息轉(zhuǎn)換為電信號發(fā)送10Mbit/s90MAU（MediumAttachmentUnit，介質(zhì)連接單元），有些地方叫PHY（PhysicalLayerDevice，物理層裝置）100Mbit/sPHY。MAC模塊并不關(guān)心這些區(qū)別，而是將可轉(zhuǎn)換為任意格式的通用信號發(fā)送給PHY（MAU）PHY（MAU）模塊再將其轉(zhuǎn)換為可在網(wǎng)線上傳輸?shù)母袷?。大家PHY（MAU）MAC模塊產(chǎn)生的信號進(jìn)行格式轉(zhuǎn)換。當(dāng)然，912.27就是這樣一個(gè)例子，我們912.26（c）10BASE-T方式所使用的信號，這也是一個(gè)網(wǎng)線圖 100BASE-TX的信MAC模塊生成通用信號，然后由PHY（MAU）模塊轉(zhuǎn)換成可在網(wǎng)線中PHY（MAU）MAC10092，在這個(gè)距離內(nèi)極少會發(fā)生錯(cuò)93TCP也會負(fù)責(zé)搞定，因此在發(fā)送信號時(shí)沒有必要檢查錯(cuò)92這是雙絞線（twistedpaircable）93實(shí)際的錯(cuò)誤率低于萬分之一，所以比“萬一”94MAC地址生成一個(gè)隨機(jī)數(shù)計(jì)算出來的。10次，如果還是不行就報(bào)告通信錯(cuò)誤。95。95以太網(wǎng)的包接收操作和發(fā)送一樣，和設(shè)備類型、TCPPHY（MAU）模塊先開始工MAC模塊。首先，PHY（MAU）模塊會將信號轉(zhuǎn)換成通用格式并發(fā)送MAC模塊，MAC模塊再從頭開始將信號轉(zhuǎn)換為數(shù)字信息，并存放到緩沖區(qū)中。當(dāng)?shù)紽CS。具體來說，就是將從包開頭到結(jié)尾的所有比特套用FCSFCS進(jìn)行對比，正常情況下兩者應(yīng)該是一致的，MAC96。到這里，MAC模塊的工作就完成了，接下96有一個(gè)特殊的例子，其實(shí)我們也可以讓網(wǎng)卡不檢查包的接收方地址，不管是不是自己的包都統(tǒng)統(tǒng)接收下來，這種模式叫作“混雜模式”（PromiscuousMode）。CPU。當(dāng)產(chǎn)生中斷信號時(shí)，CPU會暫時(shí)97。然后，中斷處理程序會調(diào)97中斷處理程序執(zhí)行完畢之后，CPU11，則在中斷處理11和相應(yīng)的網(wǎng)卡驅(qū)動綁定起來，當(dāng)網(wǎng)卡發(fā)起中斷時(shí)，就會自動調(diào)用網(wǎng)卡98規(guī)范自動設(shè)置中斷號，我們沒必要去關(guān)心中98PnP（PlugandPlay），MACTCP/IP協(xié)TCP/IPNetWareIPX/SPX，以MacAppleTalk等協(xié)議。這些協(xié)議都被分配了不同的以太類型，如0080（十六進(jìn)制）IPTCP/IP協(xié)議棧；如果是809BAppleTalkAppleTalk99。99前提是操作系統(tǒng)內(nèi)部存在以太類型所對應(yīng)的協(xié)議棧。如果不存在相應(yīng)的協(xié)議棧，則會視作錯(cuò)誤，直接丟棄這個(gè)Web服務(wù)器發(fā)送包之后，后面收到的一定Web服務(wù)器返回的包，其實(shí)并非如此。計(jì)算機(jī)中同時(shí)運(yùn)行了很多程序，也會同時(shí)進(jìn)行IPWeb100？0800TCP/IP協(xié)議棧來進(jìn)行IPIP頭部，確認(rèn)格式是否正確。IP地址。如果接收網(wǎng)絡(luò)包的設(shè)備是一臺WindowsIP地址應(yīng)該與客戶端網(wǎng)卡的地址100正如介紹發(fā)送操作時(shí)提到過的一樣，IPTCPIP地址不是自己的地址，那一定是發(fā)生了什么錯(cuò)誤?？蛻舳擞?jì)算機(jī)不負(fù)101。當(dāng)發(fā)生這樣的錯(cuò)誤時(shí)，IP模塊ICMP消息將錯(cuò)誤告知發(fā)送方（2.1）ICMP2.4所示。當(dāng)我們遇到這個(gè)錯(cuò)誤時(shí)，IP2.4Destinationunreachable消息通101以像路由器一樣對包進(jìn)行轉(zhuǎn)發(fā)。在這種情況下，當(dāng)收到不是發(fā)給自己的包的時(shí)候，就會像路由器一樣執(zhí)行包轉(zhuǎn)發(fā)操3章探索路由器時(shí)進(jìn)行介紹。表 主要的ICMP消EchoEchoIP地址在路由表中不存在；目標(biāo)端口號不存在對應(yīng)的套接IP地址，指示發(fā)送方直接發(fā)pingEchoreply消息，以IPTTL字段表示的存活時(shí)間而被路由器丟棄，此時(shí)路IPIP地址正確，則這個(gè)包會被接收下來，這時(shí)還需要完成另一項(xiàng)工作。IP3章探索路由器時(shí)進(jìn)行介紹。簡單來IPIP頭部的標(biāo)志字段中進(jìn)行標(biāo)記，當(dāng)收到分片的包時(shí)，IPIPIDID。此外，IP頭部還有一個(gè)分片偏移量（fragmentoffset）字段，它表示當(dāng)前分片在整個(gè)包中所到這里，IPTCP模塊。TCPIPIPTCP頭部中的接收方和發(fā)送方端口號來查找對應(yīng)102。找到對應(yīng)的套接字之后，就可以根據(jù)套接字中記錄的通信狀態(tài)，執(zhí)行相應(yīng)102嚴(yán)格來說，TCPIP模塊有各自的責(zé)任范圍，TCPTCPIPIP模塊的TCP模塊之后，TCPIPIP地址來查找IPIP模塊負(fù)責(zé)的，TCP模塊去查詢它等于是越權(quán)了。如果要避免越權(quán)，應(yīng)該對兩者進(jìn)行明確的劃分，IPTCPTCPIP頭部中的IPIPTCP模塊。然而，如果根據(jù)這種嚴(yán)格的劃分來開發(fā)程序的話，IPTCPIPTCP模塊進(jìn)行類似交互的TCPIP作為一個(gè)整體來看待，這樣可以帶來更大的靈活性。IP6章介紹端口號機(jī)制時(shí)一起講UDP不需要重發(fā)的數(shù)據(jù)用UDPTCP協(xié)議來收發(fā)數(shù)據(jù)，但當(dāng)然也有例TCPUDPDNS服務(wù)器查IPUDPUDP協(xié)議。TCPUDP了。那么，為什么要設(shè)計(jì)得如此復(fù)TCP一樣要管理包。TCP之所以復(fù)雜，就是因?yàn)橐獙?shí)現(xiàn)這一點(diǎn)。TCPTCP這TCP，也不需要發(fā)送那些用來建立和斷開連接的控UDPDNS查詢等交換控制信息的操作基本上都可以在一個(gè)UDPT