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

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