本節書摘來華章計算機《計算機網絡：自頂向下方法（原書第6版）》一書中的第2章 ，第2.5節，（美）james f.kurose keith w.ross 著 陳 鳴 譯 更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。
人類能以很多方式來辨別。例如，我們能夠通過出生證書上的名字來辨別；能夠通過社會保險号碼來辨別；也能夠通過駕駛執照上的号碼來辨別。盡管這些辨別辦法都可以用來識别一個人，但是在特定環境下，某種識别方法可能比另一種方法更為适合。例如，irs（美國的一個聲名狼藉的稅務征收機構）的計算機更喜歡使用定長的社會保險号碼而不是出生證書上的姓名。另一方面，普通人樂于使用更好記的出生證書上的姓名而不是社會保險号碼。（毫無疑問，你能想象人們之間以這種方式說話嗎？如“你好，我叫132-67-9875。請找一下我的丈夫178-87-1146”。）
網際網路上的主機和人類一樣，可以使用多種方式進行辨別。主機的一種辨別方法是用它的主機名（hostname），如cnn.com、www.yahoo.com、gaia.cs.umass.edu以及cis.poly.edu等，這些名字便于記憶也樂于被人們接受。然而，主機名幾乎沒有提供（即使有也很少）關于主機在網際網路中位置的資訊。（一個名為www.eurecom.fr的主機以國家碼.fr結束，告訴我們該主機很可能在法國，僅此而已。）況且，因為主機名可能由不定長的字母數字組成，路由器難以處理。由于這些原因，主機也可以使用所謂ip位址（ip address）進行辨別。
我們将在第4章更為詳細地讨論ip位址，但現在簡略地介紹一下還是有必要的。一個ip位址由4個位元組組成，并有着嚴格的層次結構。例如121.7.106.83這樣一個ip位址，其中的每個位元組都被句點分隔開來，表示了0～255的十進制數字。我們說ip位址具有層次結構，是因為當我們從左至右掃描它時，我們會得到越來越具體的關于主機位于網際網路何處的資訊（即在衆多網絡的哪個網絡裡）。類似地，當我們從下向上檢視郵政位址時，我們能夠獲得該位址位于何處的越來越具體的資訊。
我們剛剛看到了識别主機有兩種方式，通過主機名或者ip位址。人們喜歡便于記憶的主機名辨別方式，而路由器則喜歡定長的、有着層次結構的ip位址。為了折衷這些不同的偏好，我們需要一種能進行主機名到ip位址轉換的目錄服務。這就是域名系統（domain name system，dns）的主要任務。dns是：①一個由分層的dns伺服器（dns server）實作的分布式資料庫；②一個使得主機能夠查詢分布式資料庫的應用層協定。dns伺服器通常是運作bind（berkeley internet name domain）軟體［bind 2012］的unix機器。dns協定運作在udp之上，使用53号端口。
dns通常是由其他應用層協定所使用的，包括http、smtp和ftp，将使用者提供的主機名解析為ip位址。舉一個例子，考慮當某個使用者主機上的一個浏覽器（即一個http客戶）請求url www.someschool.edu/index.html頁面時會發生什麼現象。為了使使用者的主機能夠将一個http請求封包發送到web伺服器www.someschool.edu，該使用者主機必須獲得www.someschool.edu的ip位址。其做法如下。
同一台使用者主機上運作着dns應用的用戶端。
浏覽器從上述url中抽取出主機名www.someschool.edu，并将這台主機名傳給dns應用的用戶端。
dns客戶向dns伺服器發送一個包含主機名的請求。
dns客戶最終會收到一份回答封包，其中含有對應于該主機名的ip位址。
一旦浏覽器接收到來自dns的該ip位址，它能夠向位于該ip位址80端口的http伺服器程序發起一個tcp連接配接。
從這個例子中，我們可以看到dns給使用它的網際網路應用帶來了額外的時延，有時還相當可觀。幸運的是，如我們下面讨論的那樣，想獲得的ip位址通常就緩存在一個“附近的”dns伺服器中，這有助于減少dns的網絡流量和dns的平均時延。
除了進行主機名到ip位址的轉換外，dns還提供了一些重要的服務：
主機名稱（host aliasing）。有着複雜主機名的主機能擁有一個或者多個别名。例如，一台名為relay1.west-coast.enterprise.com的主機，可能還有兩個别名為enterprise.com和www.enterprise.com。在這種情況下，relay1.west-coast.enterprise.com也稱為規範主機名（canonical hostname）。主機名稱（當存在時）比主機規範名更加容易記憶。應用程式可以調用dns來獲得主機名稱對應的規範主機名以及主機的ip位址。
郵件伺服器别名（mail server aliasing）。顯而易見，人們也非常希望電子郵件位址好記憶。例如，如果bob在hotmail上有一個賬戶，bob的郵件位址就像[email protected]這樣簡單。然而，hotmail郵件伺服器的主機名可能更為複雜，不像hotmail.com那樣簡單好記（例如，規範主機名可能像relay1.west-coast.hotmail.com那樣）。電子郵件應用程式可以調用dns，對提供的郵件伺服器别名進行解析，以獲得該主機的規範主機名及其ip位址。事實上，mx記錄（參見後面）允許一個公司的郵件伺服器和web伺服器使用相同（别名化的）的主機名；例如，一個公司的web伺服器和郵件伺服器都能叫做enterprise.com。
負載配置設定（load distribution）。dns也用于在備援的伺服器（如備援的web伺服器等）之間進行負載配置設定。繁忙的站點（如cnn.com）被備援分布在多台伺服器上，每台伺服器均運作在不同的端系統上，每個都有着不同的ip位址。由于這些備援的web伺服器，一個ip位址集合是以與同一個規範主機名相聯系。dns資料庫中存儲着這些ip位址集合。當客戶對映射到某位址集合的名字發出一個dns請求時，該伺服器用ip位址的整個集合進行響應，但在每個回答中循環這些位址次序。因為客戶通常總是向ip位址排在最前面的伺服器發送http請求封包，是以dns就在所有這些備援的web伺服器之間循環配置設定了負載。dns的循環同樣可以用于郵件伺服器，是以，多個郵件伺服器可以具有相同的别名。一些内容分發公司如akamai也以更加複雜的方式使用dns［dilley 2002］，以提供web内容分發（參見第7章）。
dns由rfc 1034和rfc 1035定義，并且在幾個附加的rfc中進行了更新。dns是一個複雜的系統，我們在這裡隻是就其運作的主要方面進行學習。感興趣的讀者可以參考這些rfc文檔和albitz和liu寫的書［albitz 1993］；亦可參閱文章［mockapetris 1998］和［mockapetris 2005］，其中［mockapetris 1998］是回顧性的文章，它提供了dns組成和工作原理的精細的描述。
下面給出一個dns工作過程的總體概括，我們的讨論将集中在主機名到ip位址轉換服務方面。
假設運作在使用者主機上的某些應用程式（如web浏覽器或郵件閱讀器）需要将主機名轉換為ip位址。這些應用程式将調用dns的用戶端，并指明需要被轉換的主機名（在很多基于unix的機器上，應用程式為了執行這種轉換需要調用函數gethostbyname()）。使用者主機上的dns接收到後，向網絡中發送一個dns查詢封包。所有的dns請求和回答封包使用udp資料報經端口53發送。經過若幹毫秒到若幹秒的時延後，使用者主機上的dns接收到一個提供所希望映射的dns回答封包。這個映射結果則被傳遞到調用dns的應用程式。是以，從使用者主機上調用應用程式的角度看，dns是一個提供簡單、直接的轉換服務的黑盒子。但事實上，實作這個服務的黑盒子非常複雜，它由分布于全球的大量dns伺服器以及定義了dns伺服器與查詢主機通信方式的應用層協定組成。
dns的一種簡單設計是在網際網路上隻使用一個dns伺服器，該伺服器包含所有的映射。在這種集中式設計中，客戶直接将所有查詢直接發往單一的dns伺服器，同時該dns伺服器直接對所有的查詢客戶做出響應。盡管這種設計的簡單性非常具有吸引力，但它不适用于當今的網際網路，因為網際網路有着數量巨大（并持續增長）的主機。這種集中式設計的問題包括：
單點故障（a single point of failure）。如果該dns伺服器崩潰，整個網際網路随之癱瘓！
通信容量（traffic volume）。單個dns伺服器不得不處理所有的dns查詢（用于為上億台主機産生的所有http請求封包和電子郵件封包服務）。
遠距離的集中式資料庫（distant centralized database）。單個dns伺服器不可能“鄰近”所有查詢客戶。如果我們将單台dns伺服器放在紐約市，那麼所有來自澳洲的查詢必須傳播到地球的另一邊，中間也許還要經過低速和擁塞的鍊路。這将導緻嚴重的時延。
維護（maintenance）。單個dns伺服器将不得不為所有的網際網路主機保留記錄。這不僅将使這個中央資料庫非常龐大，而且它還不得不為解決每個新添加的主機而頻繁更新。
總的來說，在單一dns伺服器上運作集中式資料庫完全沒有可擴充能力。是以，dns采用了分布式的設計方案。事實上，dns是一個在網際網路上實作分布式資料庫的精彩範例。
1.分布式、層次資料庫
為了處理擴充性問題，dns使用了大量的dns伺服器，它們以層次方式組織，并且分布在全世界範圍内。沒有一台dns伺服器擁有網際網路上所有主機的映射。相反，該映射分布在所有的dns伺服器上。大緻說來，有3種類型的dns伺服器：根dns伺服器、頂級域（top-level domain，tld）dns伺服器和權威dns伺服器。這些伺服器以圖2-19中所示的層次結構組織起來。為了了解這3種類型的dns伺服器互動的方式，假定一個dns客戶要決定主機名www.amazon.com的ip位址。粗略說來，将發生下列事件。客戶首先與根伺服器之一聯系，它将傳回頂級域名com的tld伺服器的ip位址。該客戶則與這些tld伺服器之一聯系，它将為amazon.com傳回權威伺服器的ip位址。最後，該客戶與amazon.com權威伺服器之一聯系，它為主機名www.amazon.com傳回其ip位址。我們将很快更為詳細地考察dns查找過程。不過我們先仔細看一下這3種類型的dns伺服器。
根dns伺服器。在網際網路上有13個根dns伺服器（标号為a到m），它們中的大部分位于北美洲。圖2-20中顯示的是一張2012年的根dns伺服器分布圖；通過［root-servers 2012］可檢視目前可用的根dns伺服器清單。盡管我們将這13個根dns伺服器中的每個都視為單個的伺服器，但每台“伺服器”實際上是一個備援伺服器的網絡，以提供安全性和可靠性。到了2011年秋季，共有247個根伺服器。
頂級域（dns）伺服器。這些伺服器負責頂級域名如com、org、net、edu和gov，以及所有國家的頂級域名如uk、fr、ca和jp。verisign global registry services公司維護com頂級域的tld伺服器；educause公司維護edu頂級域的tld伺服器。所有頂級域的清單參見［iana tld 2012］。
權威dns伺服器。在網際網路上具有公共可通路主機（如web伺服器和郵件伺服器）的每個組織機構必須提供公共可通路的dns記錄，這些記錄将這些主機的名字映射為ip位址。一個組織機構的權威dns伺服器收藏了這些dns記錄。一個組織機構能夠選擇實作它自己的權威dns伺服器以儲存這些記錄；另一種方法是，該組織能夠支付費用，讓這些記錄存儲在某個服務提供商的一個權威dns伺服器中。多數大學和大公司實作和維護它們自己基本和輔助（備份）的權威dns伺服器。
根、tld和權威dns伺服器都處在該dns伺服器的層次結構中，如圖2-19中所示。還有另一類重要的dns，稱為本地dns伺服器（local dns server）。一個本地dns伺服器嚴格說來并不屬于該伺服器的層次結構，但它對dns層次結構是重要的。每個isp（如一個大學、一個系、一個公司或一個居民區的isp）都有一台本地dns伺服器（也叫預設名字伺服器）。當主機與某個isp連接配接時，該isp提供一台主機的ip位址，該主機具有一台或多台其本地dns伺服器的ip位址（通常通過dhcp，将在第4章中讨論）。通過通路windows或unix的網絡狀态視窗，能夠容易地确定你本地dns伺服器的ip位址。主機的本地dns伺服器通常“鄰近”本主機。對某機構isp而言，本地dns伺服器可能就與主機在同一個區域網路中；對于某居民區isp來說，本地dns伺服器通常與主機相隔不超過幾台路由器。當主機發出dns請求時，該請求被發往本地dns伺服器，它起着代理的作用，并将該請求轉發到dns伺服器層次結構中，我們下面将更為詳細地讨論。
我們來看一個簡單的例子，假設主機cis.poly.edu想知道主機gaia.cs.umass.edu的ip位址。同時假設理工大學（polytechnic）的本地dns伺服器為dns.poly.edu，并且gaia.cs.umass.edu的權威dns伺服器為dns.umass.edu。
如圖2-21所示， 圖2-21 各種dns伺服器的互動主機cis.poly.edu首先向它的本地dns伺服器dns.poly.edu發送一個dns查詢封包。該查詢封包含有被轉換的主機名gaia.cs.umass.edu。本地dns伺服器将該封包轉發到根dns伺服器。該根dns伺服器注意到其edu字首并向本地dns伺服器傳回負責edu的tld的ip位址清單。該本地dns伺服器則再次向這些tld伺服器之一發送查詢封包。該tld伺服器注意到umass.edu字首，并用權威dns伺服器的ip位址進行響應，該權威dns伺服器是負責馬薩諸塞大學的dns.umass.edu。最後，本地dns伺服器直接向dns.umass.edu重發查詢封包，dns.umass.edu用gaia.cs.umass.edu的ip位址進行響應。注意到在本例中，為了獲得一台主機名的映射，共發送了8份dns封包：4份查詢封包和4份回答封包!我們将很快看到利用dns緩存減少這種查詢流量的方法。
我們前面的例子假設了tld伺服器知道用于主機的權威dns伺服器的ip位址。一般而言，這種假設并不總是正确的。相反，tld伺服器隻是知道中間的某個dns伺服器，該中間dns伺服器依次才能知道用于該主機的權威dns伺服器。例如，再次假設馬薩諸塞大學有一台用于本大學的dns伺服器，它稱為dns.umass.edu。同時假設該大學的每個系都有自己的dns伺服器，每個系的dns伺服器是本系所有主機的權威伺服器。在這種情況下，當中間dns伺服器dns.umass.edu收到了對某主機的請求時，該主機名是以cs.umass.edu結尾，它向dns.poly.edu傳回dns.cs.umass.edu的ip位址，後者是所有以cs.umass.edu結尾的主機的權威伺服器。本地dns伺服器dns.poly.edu則向權威dns伺服器發送查詢，該權威dns伺服器将請求的映射發送給本地dns伺服器，該本地伺服器依次向請求主機傳回該映射。在這個例子中，共發送了10份dns封包！
圖2-21所示的例子利用了遞歸查詢（recursive query）和疊代查詢（iterative query）。從cis.poly.edu到dns.poly.edu發出的查詢是遞歸查詢，因為該查詢請求dns.poly.edu以自己的名義獲得該映射。而後繼的3個查詢是疊代查詢，因為所有的回答都是直接傳回給dns.poly.edu。從理論上講，任何dns查詢既可以是疊代的也能是遞歸的。 圖2-22 dns中的遞歸查詢例如，圖2-22顯示了一條dns查詢鍊，其中的所有查詢都是遞歸的。實踐中，查詢通常遵循圖2-21中的模式。從請求主機到本地dns伺服器的查詢是遞歸的，其餘的查詢是疊代的。
2.dns緩存
至此我們的讨論還沒有涉及dns系統的一個非常重要特色：dns緩存（dns caching）。實際上，為了改善時延性能并減少在網際網路上到處傳輸的dns封包數量，dns廣泛使用了緩存技術。dns緩存的原理非常簡單。在一個請求鍊中，當某dns伺服器接收一個dns回答（例如，包含主機名到ip位址的映射）時，它能将該回答中的資訊緩存在本地存儲器中。例如，在圖2-21中，每當本地dns伺服器dns.poly.edu從某個dns伺服器接收到一個回答，它能夠緩存包含在該回答中的任何資訊。如果在dns伺服器中緩存了一台主機名/ip位址對，另一個對相同主機名的查詢到達該dns伺服器時，該dns伺服器就能夠提供所要求的ip位址，即使它不是該主機名的權威伺服器。由于主機和主機名與ip位址間的映射并不是永久的，dns伺服器在一段時間後（通常設定為兩天）将丢棄緩存的資訊。
舉一個例子，假定主機apricot.poly.edu向dns.poly.edu查詢主機名cnn.com的ip位址。此後，假定過了幾個小時，polytechnic理工大學的另外一台主機如kiwi.poly.edu也向dns.poly.edu查詢相同的主機名。因為有了緩存，該本地dns伺服器可以立即傳回cnn.com的ip位址，而不必查詢任何其他dns伺服器。本地dns伺服器也能夠緩存tld伺服器的ip位址，因而允許本地dns繞過查詢鍊中的根dns伺服器（這經常發生）。
共同實作dns分布式資料庫的所有dns伺服器存儲了資源記錄（resource record，rr），rr提供了主機名到ip位址的映射。每個dns回答封包包含了一條或多條資源記錄。在本小節以及後續小節中，我們概要地介紹dns資源記錄和封包；更詳細的資訊可以在［albitz 1993］或有關dns的rfc文檔［rfc 1034；rfc 1035］中找到。
資源記錄是一個包含了下列字段的4元組：
（name，value，type，ttl）
ttl是該記錄的生存時間，它決定了資源記錄應當從緩存中删除的時間。在下面給出的記錄例子中，我們忽略掉ttl字段。name和value的值取決于type：
如果type=a，則name是主機名，value是該主機名對應的ip位址。是以，一條類型為a的資源記錄提供了标準的主機名到ip位址的映射。例如（relay1.bar.foo.com，145.37.93.126，a）就是一條類型a記錄。
如果type=ns，則name是個域（如foo.com），而value是個知道如何獲得該域中主機ip位址的權威dns伺服器的主機名。這個記錄用于沿着查詢鍊來路由dns查詢。例如（foo.com，dns.foo.com，ns）就是一條類型為ns的記錄。
如果type=cname，則value是别名為name的主機對應的規範主機名。該記錄能夠向查詢的主機提供一個主機名對應的規範主機名，例如（foo.com，relay1.bar.foo.com，cname）就是一條cname類型的記錄。
如果type=mx，則value是個别名為name的郵件伺服器的規範主機名。舉例來說，（foo.com，mail.bar.foo.com，mx）就是一條mx記錄。mx記錄允許郵件伺服器主機名具有簡單的别名。值得注意的是，通過使用mx記錄，一個公司的郵件伺服器和其他伺服器（如它的web伺服器）可以使用相同的别名。為了獲得郵件伺服器的規範主機名，dns客戶應當請求一條mx記錄；而為了獲得其他伺服器的規範主機名，dns客戶應當請求cname記錄。
如果一台dns伺服器是用于某特定主機名的權威dns伺服器，那麼該dns伺服器會有一條包含該主機名的類型a記錄（即使該dns伺服器不是其權威dns伺服器，它也可能在緩存中包含有一條類型a記錄）。如果伺服器不是用于某主機名的權威伺服器，那麼該伺服器将包含一條類型ns記錄，該記錄對應于包含主機名的域；它還将包括一條類型a記錄，該記錄提供了在ns記錄的value字段中的dns伺服器的ip位址。舉例來說，假設一台edu tld伺服器不是主機gaia.cs.umass.edu的權威dns伺服器，則該伺服器将包含一條包括主機cs.umass.edu的域記錄，如（umass.edu，dns.umass.edu，ns）；該edu tld伺服器還将包含一條類型a記錄，如（dns.umass.edu，128.119.40.111，a），該記錄将名字dns.umass.edu映射為一個ip位址。
1.dns封包
在本節前面，我們提到了dns查詢和回答封包。dns隻有這兩種封包，并且，查詢和回答封包有着相同的格式，如圖2-23所示。dns封包中各字段的語義如下：
圖2-23 dns封包格式前12個位元組是首部區域，其中有幾個字段。第一個字段(辨別符)是一個16比特的數，用于辨別該查詢。這個辨別符會被複制到對查詢的回答封包中，以便讓客戶用它來比對發送的請求和接收到的回答。标志字段中含有若幹标志。1比特的“查詢/回答”标志位指出封包是查詢封包（0）還是回答封包（1）。當某dns伺服器是所請求名字的權威dns伺服器時，1比特的“權威的”标志位被置在回答封包中。如果客戶（主機或者dns伺服器）在該dns伺服器沒有某記錄時希望它執行遞歸查詢，将設定1比特的“希望遞歸”标志位。如果該dns伺服器支援遞歸查詢，在它的回答封包中會對1比特的“遞歸可用”标志位置位。在該首部中，還有4個有關數量的字段，這些字段指出了在首部後的4類資料區域出現的數量。
問題區域包含着正在進行的查詢資訊。該區域包括：①名字字段，指出正在被查詢的主機名字；②類型字段，它指出有關該名字的正被詢問的問題類型，例如主機位址是與一個名字相關聯（類型a）還是與某個名字的郵件伺服器相關聯（類型mx）。
在來自dns伺服器的回答中，回答區域包含了對最初請求的名字的資源記錄。前面講過每個資源記錄中有type（如a、ns、cname和mx）字段、value字段和ttl字段。在回答封包的回答區域中可以包含多條rr，是以一個主機名能夠有多個ip位址（例如，就像本節前面讨論的備援web伺服器）。
權威區域包含了其他權威伺服器的記錄。
附加區域包含了其他有幫助的記錄。例如，對于一個mx請求的回答封包的回答區域包含了一條資源記錄，該記錄提供了郵件伺服器的規範主機名。該附加區域包含一個類型a記錄，該記錄提供了用于該郵件伺服器的規範主機名的ip位址。
你願意從正在工作的主機直接向某些dns伺服器發送一個dns查詢封包嗎？使用nslookup程式（nslookup program）能夠容易地做到這一點，對于多數windows和unix平台，nslookup程式是可用的。例如，從一台windows主機打開指令提示符界面，直接鍵入“nslookup”即可調用該nslookup程式。在調用nslookup後，你能夠向任何dns伺服器（根、tld或權威）發送dns查詢。在接收到來自dns伺服器的回答後，nslookup将顯示包括在該回答中的記錄（以人可讀的格式）。從你自己的主機運作nslookup還有一種方法，即通路允許你遠端應用nslookup的許多web站點之一（在一個搜尋引擎中鍵入“nslookup”就能夠得到這些站點中的一個）。本章最後的dns wireshark實驗将使你更為詳細地研究dns。
2.在dns資料庫中插入記錄
當你向某些注冊登記機構注冊域名networkutopia.com時，需要向該機構提供你的基本和輔助權威dns伺服器的名字和ip位址。假定該名字和ip位址是dns1.networkutopia.com和dns2.networkutopia.com及212.212.212.1和212.212.212.2。對這兩個權威dns伺服器的每一個，該注冊登記機構確定将一個類型ns和一個類型a的記錄輸入tld com伺服器。特别是對于用于networkutopia.com的基本權威伺服器，該注冊登記機構将下列兩條資源記錄插入該dns系統中：
你還必須確定用于web伺服器www.networkutopia.com的類型a資源記錄和用于郵件伺服器mail.networkutopia.com的類型mx資源記錄被輸入你的權威dns伺服器中。（直到最近，每個dns伺服器中的内容都是靜态配置的，例如來自系統管理者建立的配置檔案。最近，在dns協定中添加了一個更新（update）選項，允許通過dns封包對資料庫中的内容進行動态添加或者删除。［rfc 2136］和［rfc 3007］定義了dns動态更新。）
一旦完成所有這些步驟，人們将能夠通路你的web站點，并向你公司的雇員發送電子郵件。我們通過驗證該說法的正确性來總結dns的讨論。這種驗證也有助于充實我們已經學到的dns知識。假定在澳洲的alice要觀看www.networkutopia.com的web頁面。如前面所讨論，她的主機将首先向其本地dns伺服器發送請求。該本地伺服器接着則聯系一個tld com伺服器。（如果tld com伺服器的位址沒有被緩存，該本地dns伺服器也将必須與根dns伺服器相聯系。）該tld伺服器包含前面列出的類型ns和類型a資源記錄，因為注冊登記機構将這些資源記錄插入所有的tld com伺服器。該tld com伺服器向alice的本地dns伺服器發送一個回答，該回答包含了這兩條資源記錄。該本地dns伺服器則向212.212.212.1發送一個dns查詢，請求對應于www.networkutopia.com的類型a記錄。該記錄提供了所希望的web伺服器的ip位址，如212.212.71.4，本地dns伺服器将該位址回傳給alice的主機。alice的浏覽器此時能夠向主機212.212.71.4發起一個tcp連接配接，并在該連接配接上發送一個http請求。當一個人在網上沖浪時，有比滿足眼球更多的事情在進行！