[toc]

# 2.1 Principles of Network Applications

## 2.1.1 Network Application Architectures

要寫出一個網(wǎng)絡(luò)應(yīng)用怠李，首先要選擇一種架構(gòu)，是**CS**（client-to-server）架構(gòu)捂襟，還是**P2P**（peer-to-peer）架構(gòu)缩挑。

所謂CS架構(gòu)星持，就是整個網(wǎng)絡(luò)應(yīng)用生態(tài)是由server和client這種不對等關(guān)系組成（比如web應(yīng)用）狰晚，server必須長時間不關(guān)機來達到持續(xù)為client提供資源的效果枚冗，client專門訪問資源座泳。一般來說服務(wù)提供方都是服務(wù)器的集群呀邢，也稱為**data center**洒沦，一個data center中包含了成千上萬臺服務(wù)器。因為就如今的網(wǎng)絡(luò)吞吐量來看价淌，一臺server是遠遠無法為一個成熟的網(wǎng)絡(luò)應(yīng)用提供所需的服務(wù)的申眼。甚至一個data center也不夠，要多個data center才能滿足需求（google有將近50data centers遍布全球）蝉衣。


P2P架構(gòu)中括尸，兩兩相連的hosts彼此對等，它們自己都既可以提供資源病毡，也可以訪問資源濒翻。這種架構(gòu)方式在數(shù)據(jù)傳輸量較大的網(wǎng)絡(luò)應(yīng)用中經(jīng)常被使用（比如點對點文件傳輸BitTorrent，網(wǎng)絡(luò)電話啦膜，視頻會議）有送。

P2P最大的好處就是**self-scalability**，因為一臺host給它的所有peers發(fā)送文件A后僧家，它的所有peers又能給它們各自的peers發(fā)送文件A雀摘，文件A在整個網(wǎng)絡(luò)中被越來越多hosts所擁有，到了后期如果網(wǎng)絡(luò)中某臺新host要請求文件A八拱，就可能會有N個已持有文件A的hosts一起傳輸給它阵赠，速度非乘嘎洌快。

另外P2P也不需要類似server等的一些基礎(chǔ)架構(gòu)豌注，比較經(jīng)濟，方便灯萍。

不過P2P也存在一些問題：安全轧铁，peers較少時性能很差，去中心化網(wǎng)絡(luò)的可靠性較低旦棉。


>如今很多軟件都同時采用了P2P和CS架構(gòu)

## 2.1.2 Processes Communicating

一臺機器上processes之間相互通信的內(nèi)容是操作系統(tǒng)中需要探究的內(nèi)容齿风，在網(wǎng)絡(luò)中，我們主要研究**不同hosts上**的process之間通信的過程：它們通過互相發(fā)送**message**來通信绑洛。

### 2.1.2.1 Client and Server Processes

無論是CS架構(gòu)還是P2P架構(gòu)救斑，不同**hosts**之間的processes都存在**server/client pair**的關(guān)系（注意CS架構(gòu)中的server和client指的是host，而不是此處的process）真屯。

比如web應(yīng)用中脸候，客戶端的瀏覽器就是一個client process，服務(wù)端為client提供內(nèi)容的進程就是server process绑蔫；P2P的文件傳輸服務(wù)中运沦，請求文件內(nèi)容的進程為client process，提供內(nèi)容的進程為server process（所以P2P中的一個host可以同時充當(dāng)client和server的角色）配深。

更精確的定義：

In the context of a communication session between a pair of processes, the process that initiates the communication (that is, initially contacts the other process at the beginning of the session) is labeled as the client. The process that waits to be contacted to begin the session is the server.

在web應(yīng)用中携添，瀏覽器（client process）向服務(wù)端發(fā)起連接請求，一直在等待請求的服務(wù)端接收服務(wù)的進程（server process）接受（或拒絕）連接請求篓叶；P2P中請求文件的host向另一個host發(fā)起連接請求（client process）烈掠，另一個host被動等待并接受（或拒絕）連接請求（server process）。

### 2.1.2.2 The Interface Between the Process and the Computer Network

process通過【軟件實現(xiàn)的接口——**socket** 】來接收或發(fā)送message缸托。

如果把process比作房子左敌，那么socket就是這個房子的門，process接收信息發(fā)送信息都要通過它的socket嗦董。


（上圖假定運輸層協(xié)議為TCP）母谎，可以看出，socket其實就是一個host上**應(yīng)用層和傳輸層之間的接口**京革，因此它也被稱為【應(yīng)用和網(wǎng)絡(luò)】之間的**Application Programming Interface (API)** 奇唤。

應(yīng)用程序的開發(fā)者對應(yīng)用層這邊的socket擁有**完全控制權(quán)**，而對傳輸層那邊的socket的操作空間卻非常少匹摇，只有如下兩個方面：

1. 選擇使用哪一個傳輸層協(xié)議

2. 填寫一些傳輸層的參數(shù)（比如最大的segment size）

### 2.1.2.3 Addressing Processes

兩個hosts之間互相通信需要知道彼此的IP地址咬扇，而一臺host上會運行多個processes，兩個processes之間通信的話廊勃，就需要知道對方是host上具體的哪一個進程懈贺。用**port number**來標(biāo)識每一個進程经窖，這樣就可以通過【IP+port number】來精確的定位一個host上的某一個process了。

一些著名的應(yīng)用程序擁有固定的port number：HTTP（80）梭灿，SMTP（25）等画侣，

## 2.1.3 Transport Services Available to Applications

編寫網(wǎng)絡(luò)應(yīng)用程序之前首先要選擇一種傳輸層協(xié)議，傳輸層的協(xié)議有兩個：TCP和UDP堡妒，它們提供了不同的服務(wù)類型配乱。

**Reliable Data Transfer**，選擇可靠傳輸可以保證數(shù)據(jù)完好無損的到達接收端皮迟，但是速度較慢搬泥。相對的，選擇不可靠傳輸速度較快伏尼。

**throughput**忿檩，很多媒體應(yīng)用（比如視頻網(wǎng)站）要保證穩(wěn)定的網(wǎng)絡(luò)帶寬，這時就要選擇throughput guaranteed服務(wù)爆阶，而一些比如郵件服務(wù)燥透，就不需要穩(wěn)定的帶寬，只要傳輸可靠就行扰她。

**timing**兽掰，一些應(yīng)用要求數(shù)據(jù)必須要給定的時間內(nèi)傳遞到（比如網(wǎng)絡(luò)會議，網(wǎng)絡(luò)游戲）徒役，就要選擇timing的協(xié)議孽尽。

**Security**，傳輸層協(xié)議還會提供一些數(shù)據(jù)加密忧勿，數(shù)據(jù)完整性校驗等安全服務(wù)杉女。

## 2.1.4 Transport Services Provided by the Internet

**TCP**

提供面向連接的可靠數(shù)據(jù)傳輸服務(wù)，具體來看：

1. connection-oriented service

在傳輸數(shù)據(jù)之前鸳吸，使用TCP連接的兩個進程會先交換一些控制信息熏挎，這個過程就是著名的**三次握手**，三次握手完成后晌砾，兩個進程的sockets之間就建立起了**TCP connection**坎拐，這種連接允許它們進行**全雙工**通信。

通信結(jié)束后养匈，兩進程也會通過類似三次握手的方式揮手告別來中止TCP連接哼勇。

2. reliable data transfer service

通過TCP connection傳輸?shù)臄?shù)據(jù)不會產(chǎn)生丟包或者數(shù)據(jù)重復(fù)、數(shù)據(jù)缺失等問題呕乎。

3. congestion control

如果當(dāng)前網(wǎng)絡(luò)整體比較擁塞积担，TCP可以限制進程的數(shù)據(jù)發(fā)送速率

**UDP**

UDP只提供最基本的數(shù)據(jù)傳輸服務(wù)，因為簡單猬仁，所以它的特點是高效帝璧，但是不夠可靠先誉。

UDP是無連接的服務(wù)，通信之前不需要交換控制信息的烁；UDP不可靠褐耳，這意味著數(shù)據(jù)傳輸過程中可能發(fā)生丟包、數(shù)據(jù)缺失渴庆、數(shù)據(jù)到達順序錯亂等問題漱病。不僅如此，UDP也沒有任何擁塞控制策略把曼，這意味著它可能一次發(fā)送一大批數(shù)據(jù)到鏈路上，引發(fā)鏈路擁塞漓穿。

>視頻通話這類一般都使用UDP實現(xiàn)嗤军，因為這類應(yīng)用對數(shù)據(jù)完整性有一定容忍度，使用UDP能夠避免TCP帶來的額外開銷晃危。不過如今多數(shù)防火墻都會阻塞UDP數(shù)據(jù)叙赚，因此通常這類應(yīng)用會將TCP作為第二選擇以備不時之需。

## 2.1.5 Application-Layer Protocols

使用相同兩個應(yīng)用層協(xié)議的終端可以互相發(fā)送message來實現(xiàn)對應(yīng)的功能僚饭。

應(yīng)用層協(xié)議通常定義了：

1. message類型（是請求還是回應(yīng)）

2. message的語法（里面有多少個字段）

3. message中每個字段的語義

4. 一個進程【何時】震叮、【如何】發(fā)送和接收message

注意區(qū)分【應(yīng)用層協(xié)議application-layer protocols】和【網(wǎng)絡(luò)應(yīng)用network applications】，前者是后者的子集（十分重要的子集）鳍鸵。比如web應(yīng)用包含了HTML苇瓣、web browser、web servers以及應(yīng)用層協(xié)議HTTP偿乖。

# 2.2 The Web and HTTP

## 2.2.1 Overview of HTTP

web的核心是它的應(yīng)用層協(xié)議：HTTP（TyperText Transfer Protocol）击罪。HTTP包含兩個程序：client program和server program，分別運行在客戶端和服務(wù)端贪薪，通過交換HTTP messages來互相通信媳禁。HTTP定義了這些messages的結(jié)構(gòu)以及client和server交換messages的方式。

>因為browser實現(xiàn)了客戶端的HTTP画切，所以web應(yīng)用中client可等同于browser

**web page**由base HTML file和多個objects（圖片竣稽、視頻等）組成，這些objects都被URL唯一標(biāo)識霍弹。

**URL（Uniform Resource Locator）**包含兩部分內(nèi)容：

1. 提供網(wǎng)頁內(nèi)容（object）的服務(wù)器的域名

2. object所在的路徑名稱

例如：http://www.someSchool.edu/someDepartment/picture.gif

www.someSchool.edu就是提供objects訪問的服務(wù)器域名

/someDepartment/picture.gif就是當(dāng)前訪問的object的路徑

HTTP定義了client向server請求網(wǎng)頁的方式毫别，以及server向client傳輸網(wǎng)頁的方式。web應(yīng)用整體采用了CS架構(gòu)庞萍，即一個server長期開機固定ip運行服務(wù)等待client請求拧烦，多個client可以在任意時間訪問server提供的web資源。


HTTP歸根到底是一個應(yīng)用钝计，之前學(xué)過恋博，網(wǎng)絡(luò)應(yīng)用都要選擇一個傳輸層協(xié)議齐佳，**HTTP選擇的傳輸層協(xié)議是TCP**，因此web應(yīng)用是無損傳輸數(shù)據(jù)的债沮。

HTTP還是一個**stateless protocol**炼吴，即它不會記錄client的狀態(tài)信息。這一點體現(xiàn)在疫衩，即使一個client在極短的間隔內(nèi)多次請求同一個object硅蹦，每當(dāng)server響應(yīng)完一次請求，就會把它完全忘記闷煤，下一次請求對它來說就像以前從來沒有發(fā)生過一樣童芹。

## 2.2.2 Non-Persistent and Persistent Connections

運行在TCP之上的應(yīng)用程序，server和client之間會建立持久的連接來通信鲤拿，這種情況下需要做一個重要的決定：只建立一條TCP連接假褪，讓request/response同時在這個連接上傳輸；還是為request和response各自單獨建立一條TCP連接近顷？

只建立一條TCP連接生音，讓request/response同時在這個連接上傳輸稱為**Non-persistent connection**，

為request和response各自單獨建立一條TCP連接稱為**Persistent connection**窒升。

HTTP可以在這兩種方式中任選其一缀遍。

### 2.2.2.1 HTTP with Non-Persistent Connections

為了解釋non-persistent connection，先來看看一個網(wǎng)頁從server發(fā)送到client的過程是怎樣的饱须。

假定網(wǎng)頁的URL是: http://www.someSchool.edu/someDepartment/home.index

1. HTTP client process首先向服務(wù)器www.someSchool.edu的80端口（HTTP的默認端口）發(fā)起TCP連接請求域醇，連接建立起來后，client和server兩邊各有一個socket口蓉媳。

2. HTTP client process通過socket向HTTP server process發(fā)送請求報文歹苦，該請求報文中包含請求的資源在server上的具體路徑（如：/someDepartment/home.index）。

3. HTTP server process通過自己這邊的socket接收client發(fā)來的請求報文督怜，然后根據(jù)報文的請求殴瘦，到自己的硬盤上尋找相應(yīng)的資源/someDepartment/home.index，然后將該資源打包成HTTP response報文的格式号杠，從socket向client發(fā)出蚪腋。

4. 資源傳輸完畢后，HTTP server process發(fā)出關(guān)閉TCP connection的請求（不過這時TCP連接不會真的被關(guān)閉姨蟋，它會等到HTTP client process確認【完整的】收到資源報文后屉凯，才會關(guān)閉）

5. HTTP client process（browser）接收到回復(fù)報文后，TCP連接斷開眼溶，接著client將報文拆開悠砚，取出其中的資源顯示在瀏覽器界面上

使用不同的瀏覽器可能會看到并不完全相同的網(wǎng)頁，因為HTTP只管發(fā)送和接收HTTP報文堂飞，至于報文中的信息是如何被解釋然后呈現(xiàn)給用戶則完全是由browser來控制的灌旧。

以上整個過程就是典型的non-persistent connection绑咱，每傳輸一個資源就需要創(chuàng)建一次TCP連接（第1步），每一次傳輸完畢后都要斷開連接（第4步）枢泰，所以下一次傳輸網(wǎng)頁又要重新建立TCP連接描融，注意【一次HTTP傳輸只能傳輸一個資源(object)，而非整個網(wǎng)頁】衡蚂，所以假如一個網(wǎng)頁上有11張圖片窿克，那么這張網(wǎng)頁就需要11次TCP傳輸。這就是所謂的面向無連接毛甲，無記憶年叮，不會因為一個client要請求多個資源而為它保持TCP連接。

不過現(xiàn)代的browser一般可以同時并行的維護多個TCP連接玻募，所以網(wǎng)頁連接的速度不至于很慢谋右。

現(xiàn)在來算算從client發(fā)起網(wǎng)頁請求到它接收到完整的網(wǎng)頁總共需要的時間。我們稱一個簡短的小報文從client發(fā)到server补箍，然后從server發(fā)回到client總共花費的時間為 **round-trip time（RTT）** ，RTT包括了之前我們介紹過的packet-propagation delays啸蜜、packet-queuing delays以及packet-processing delays坑雅。一個網(wǎng)頁從請求到完整接收這整個過程其實遠不止一個RTT的時間，一個重要的原因就是兩個終端之間建立TCP連接必須要經(jīng)過 **三次握手（three-way handshaking）** 衬横。

<img src="C:\Users\65403\Desktop\typora圖片\image-20200924190555437.png" alt="image-20200924190555437" style="zoom:50%;" />

三次握手的前兩次就用掉了一個RTT的時間裹粤，最后一次握手則將第三次握手的報文和HTTP request報文一起發(fā)出。

### 2.2.2.2 HTTP with Persistent Connections

Non-persistent connection讓server的負擔(dān)過重蜂林。其實請求一次網(wǎng)頁建立一次TCP連接還稍微可以接受遥诉，如果請求一個object就得新建一個TCP連接的話，一個現(xiàn)代網(wǎng)頁至少也要創(chuàng)建十幾個TCP連接噪叙，一個server可是要同時對成百上千個clients提供服務(wù)的矮锈。不僅如此，TCP連接創(chuàng)建還特別慢睁蕾，要好幾個RTT苞笨。

為了解決這個問題，HTTP 1.1提供了persistent connection子眶，它使得連接得以維持瀑凝，可以對同一目標(biāo)進行連續(xù)的objects傳輸（如果server收到【連續(xù)的】請求，它就會將這些請求的結(jié)果【連續(xù)地】發(fā)回給目標(biāo)client）臭杰，這下終于可以用一個TCP連接一次性傳輸整個網(wǎng)頁而不需要為網(wǎng)頁上的每一個object都創(chuàng)建一個全新的TCP鏈接了粤咪。當(dāng)一條TCP鏈接在一定時間內(nèi)（用戶可定義）沒有被使用后，該鏈接才會被關(guān)閉渴杆。

HTTP 1.1的模式默認為persistent connection寥枝，之后在HTTP 1.1基礎(chǔ)之上新做出來的HTTP/2甚至允許多個不同的請求和應(yīng)答報文同時在一條TCP鏈路上傳輸宪塔。

## 2.2.3 HTTP Message Format

### 2.2.3.1 HTTP Request Message

一個典型的HTTP請求報文示例如下：

【GET /somedir/page.html HTTP/1.1】? ? //第一行叫做 **request line** ，包含三個字段：方法（有GET脉顿、POST等）蝌麸、URL、以及HTTP version艾疟。

余下幾行統(tǒng)稱為 **header lines**

【Host: www.someschool.edu】? //指明了請求的資源在哪臺host上来吩。既然已經(jīng)建立了TCP鏈接，那么對方主機的IP已經(jīng)是知道的蔽莱，然而這條信息是否是多余的呢弟疆？其實到后面我們就會學(xué)到Web proxy caches會用到它。

【Connection: close 】? ? ? //這代表browser并不希望建立persistent connection盗冷，這樣在server發(fā)出response message后就會請求關(guān)閉TCP

【User-agent: Mozilla/5.0】? ? ? //說明了發(fā)出 resquest的browser類型怠苔，本例為火狐。這條信息其實很重要仪糖，因為server可以根據(jù)不同的browser類型發(fā)送不同版本的response message

【Accept-language: fr】? //說明了client想接收法文版本的網(wǎng)頁

現(xiàn)在來學(xué)習(xí)HTTP resquest message的一般格式：

<img src="C:\Users\65403\Desktop\typora圖片\image-20200924200842021.png" alt="image-20200924200842021" style="zoom:50%;" />

可以看到其中有一個特殊的字段叫做 Entity body柑司，如果method字段使用GET，該字段就為空锅劝。只有當(dāng)使用POST方法時攒驰，該字段可以被用戶填寫。要注意的是故爵，不光是POST方法可以讓用戶寫入數(shù)據(jù)玻粪，GET也可以，它們之間的區(qū)別在于诬垂，GET會把用戶輸入的數(shù)據(jù)展示在url上劲室，而POST不會。

也可以使用head方法结窘，當(dāng)server收到一個head方法的request message時很洋，它會無視掉請求報文，直接返回一個response message隧枫，因此該方法通常用來debug蹲缠；put方法使得用戶可以上傳object到web server；delete方法使得用戶可以刪除web server上的文件悠垛。

### 2.2.3.1 HTTP Response Message

下面的示例就是上一小節(jié)示例的回復(fù)：

HTTP/1.1 200 OK? ? // **status line** 线定，有三個字段：協(xié)議版本、status code确买、狀態(tài)信息斤讥。本例server使用HTTP 1.1版本，一切正常。

//中間六行統(tǒng)稱 **header lines**

Connection: close? ? ? ///告訴client這條消息發(fā)完我就要關(guān)TCP鏈接了

Date: Tue, 18 Aug 2015 15:44:04 GMT? //server發(fā)送response message的時間

Server: Apache/2.2.3 (CentOS)? ? //指明了server的軟件類型

Last-Modified: Tue, 18 Aug 2015 15:11:03 GMT? //之后還會詳細介紹芭商，指明本object內(nèi)容的最后修改時間

Content-Length: 6821? //entity body的長度

Content-Type: text/html? //entity body中的數(shù)據(jù)類型

//最后是entity body

(data data data data data ...)

具體看看status code

| status code? ? ? ? ? ? ? ? ? ? | 含義? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |? ? ? |

| ------------------------------ | ------------------------------------------------------------ | ---- |

| 200 OK? ? ? ? ? ? ? ? ? ? ? ? | 請求成功派草，response message也已經(jīng)成功發(fā)送? ? ? ? ? ? ? ? ? ? |? ? ? |

| 301 Moved Permanently? ? ? ? ? | 請求的object已經(jīng)被永久移走了，新的網(wǎng)址在Location字段中給出铛楣，一般這時browser會自動重定位到新的網(wǎng)址 |? ? ? |

| 400 Bad Request? ? ? ? ? ? ? ? | 400是一個通用的錯誤碼近迁，代表server無法理解本次request? ? ? ? |? ? ? |

| 404 Not Found? ? ? ? ? ? ? ? ? | 請求的文件不在該server上? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |? ? ? |

| 505 HTTP Version Not Supported | 本server不支持請求的HTTP協(xié)議版本? ? ? ? ? ? ? ? ? ? ? ? ? ? |? ? ? |

|? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |? ? ? |

## 2.2.4 User-Server Interaction: Cookies

雖然HTTP server是無狀態(tài)協(xié)議（不會對用戶有記憶），但大多數(shù)情況下web server需要去記住用戶來實現(xiàn)某些功能（比如對會員用戶提供特定的內(nèi)容）簸州，基于這種需求鉴竭，cookies技術(shù)出現(xiàn)了，使用cookie可以讓網(wǎng)站持續(xù)的追蹤用戶岸浑，現(xiàn)在大多數(shù)網(wǎng)頁都使用了cookie技術(shù)搏存。

cookie技術(shù)分為四個部分：

1. 在HTTP response message和request message中各有一行cookie header line

2. browser會在客戶端維護一個cookie file

3. 一個網(wǎng)站后端的數(shù)據(jù)庫

現(xiàn)在來根據(jù)案例學(xué)習(xí)下cookie的具體運作流程：

假定Susan第一次訪問亞馬遜的網(wǎng)站，當(dāng)它發(fā)送的HTTP resquest到達亞馬遜的web服務(wù)器后矢洲，服務(wù)器會為它創(chuàng)建一個獨一無二的身份驗證碼璧眠，并且在后端數(shù)據(jù)庫中以該驗證碼為索引創(chuàng)建一個數(shù)據(jù)條目，接著亞馬遜的web服務(wù)器會回應(yīng)Susan的browser一個HTTP response? message读虏，其中就包含了一個cookie的條目：【Set-cookie：1678】责静。當(dāng)Susan的browser接收到亞馬遜的response message后，發(fā)現(xiàn)其中有一個set-cookie字段盖桥，就會在自己維護的cookie文件中增添一行數(shù)據(jù)灾螃，這一行數(shù)據(jù)包括亞馬遜服務(wù)器的主機名以及set-cookie字段中的身份驗證碼。隨后Susan不斷的訪問亞馬遜網(wǎng)站葱轩，他每一次訪問的resquest message都會被browser加上cookie的身份驗證碼字段（即：Cookie：1678），這樣一來亞馬遜的web server就可以追蹤Susan在網(wǎng)站上的行為藐握，用戶1678瀏覽了哪些網(wǎng)頁靴拱，瀏覽的順序，甚至打開網(wǎng)頁的時間猾普，收集這些數(shù)據(jù)并分析就可以做出一個推薦系統(tǒng)袜炕。如果Susan在亞馬遜上注冊了自己賬號，那么亞馬遜的web server就會將用戶1678和Susan填寫的個人信息（姓名初家、性別偎窘、銀行卡號和密碼）關(guān)聯(lián)起來，綜合分析1678的訪問偏好以及Susan的個人信息溜在，精準(zhǔn)的推薦首頁商品或者投放廣告陌知，并且Susan每次購買商品無需重復(fù)輸入自己的卡號密碼。

用戶第一次訪問某網(wǎng)站后掖肋，網(wǎng)站服務(wù)器會用一個獨一無二的身份碼標(biāo)識他仆葡，并將其寫入數(shù)據(jù)庫，該身份碼同時會保存在用戶本地端志笼，之后如果再次訪問該網(wǎng)站沿盅，用戶的browser每次發(fā)出的HTTP resquest message中就會在cookie字段包含自己的身份碼把篓，server根據(jù)身份碼來記住用戶。

雖然cookie方便了用戶腰涧，但是由于它能夠獲取用戶大量的敏感信息韧掩，因此不太安全。

## 2.2.5 Web Caching

**web cache** 也稱為 **proxy server** 窖铡，可以【代替原web server滿足一些HTTP resquests】疗锐。web cache擁有自己的存儲系統(tǒng)，里面保存了原web server中最近被訪問過的一些數(shù)據(jù)万伤，用戶可以在browser中進行設(shè)置所有請求都優(yōu)先發(fā)送到web cache≈匣冢現(xiàn)假定browser請求http://www.someschool.edu/campus.gif：

1. browser先與web cache建立TCP鏈接，并向其發(fā)送HTTP request

2. web cache接收到resquest后敌买，檢查自己是否緩存了resquest要求的目標(biāo)資源简珠，如果有，就將目標(biāo)資源打包到HTTP response message中發(fā)送給client browser

3. 如果web cache沒有緩存目標(biāo)資源虹钮，就會轉(zhuǎn)而與原web server建立TCP鏈接聋庵，然后向其發(fā)送請求目標(biāo)資源的HTTP resquest，等收到原web server的response后芙粱，就會將其中的目標(biāo)資源存儲到自己的硬盤中祭玉，并將一份該資源的復(fù)制打包成HTTP response message發(fā)送給client browser

<img src="C:\Users\65403\Desktop\typora圖片\image-20200925093557033.png" alt="image-20200925093557033" style="zoom:50%;" />

從上述過程可以看出【web cache既是client也是server】。

一般web cache是由ISP購買并安裝的春畔，比如大學(xué)就可能購買一個web cache脱货，然后配置讓校園中所有的browser都優(yōu)先訪問web cahce。

使用web cache的理由有二：

1. 極大的降低客戶端請求網(wǎng)頁的時延律姨，尤其是當(dāng)client和原服務(wù)器之間的帶寬遠小于client和web cache之間的的帶寬時（通常情況下client和web cache之間都會建立高速連接）

2. web cache可以極大的減輕接入層的擁塞狀況振峻，使得接入層的機構(gòu)不需要很頻繁的升級帶寬，節(jié)省了很多費用择份。不僅如此扣孟，從整體上看web cache減輕了整個互聯(lián)網(wǎng)的擁塞狀況，提升了整個互聯(lián)網(wǎng)的性能荣赶。

### 2.2.5.1 The Conditional GET

web cache可能會帶來一個問題：一個資源剛剛被緩存后凤价，原服務(wù)器上該資源的內(nèi)容被更新了。幸好HTTP提供了驗證一個object是否是最新的機制 **conditional GET** 拔创，當(dāng)一個HTTP request message【使用GET方法】并且【存在If-Modified-Since字段】它就叫conditional GET利诺。

依然通過第一個例子來看看conditional GET的工作方式：

1. client browser向web cache發(fā)出請求，web cache本地沒有緩存目標(biāo)資源剩燥，轉(zhuǎn)而向原web server發(fā)出請求立轧。

2. 原web server將目標(biāo)資源發(fā)回給web cached

? HTTP/1.1 200 OK

? Date: Sat, 3 Oct 2015 15:39:29

? Server: Apache/1.3.0 (Unix)

? Last-Modified: Wed, 9 Sep 2015 09:23:24

? Content-Type: image/gif

? (data data data data data ...)

3. web cache將目標(biāo)資源【以及Last-Modified字段】存儲在本地硬盤，并將一份復(fù)制發(fā)給client browser

4. 一周后，一個browser向該web cache請求同一份資源氛改，雖然這份資源被緩存在了web cache中帐萎，但是可能已經(jīng)過期了，因此它要發(fā)出conditional GET來確認該資源是否是最新的胜卤，即向原web server發(fā)送：

? GET /fruit/kiwi.gif HTTP/1.1

? Host: www.exotiquecuisine.com

? If-modified-since: Wed, 9 Sep 2015 09:23:24

5. conditional GET的作用是讓原server對比目標(biāo)資源的modified字段疆导，如果不同就傳一份最新的灼伤，如果相同就按兵不動谆级。本例中兩modified字段值相同，表明該資源沒有被修改過橄登。

6. 原web server將response message傳輸給cache：

? HTTP/1.1 304 Not Modified

? Date: Sat, 10 Oct 2015 15:39:29

? Server: Apache/1.3.0 (Unix)

? (empty entity body)

7. web cache知道了該資源是最新的舰攒，就直接將其發(fā)送給client browser

# 2.3 Electronic Mail in the Internet

電子郵件在互聯(lián)網(wǎng)誕生之初就已經(jīng)存在了败富，直到現(xiàn)在它仍然是互聯(lián)網(wǎng)中不可缺少的一環(huán)

電子郵件的三個主要組成部分：

1. **user agent** (如Outlook、sina mail等)

2. **mail servers**

3. **Simple Mail Transfer Protocol (SMTP)**

<img src="C:\Users\65403\Desktop\typora圖片\image-20200925105557333.png" alt="image-20200925105557333" style="zoom:50%;" />

電郵寫好后摩窃，發(fā)送端通過user agent將其發(fā)送到mail server上兽叮，接收端通過user agent獲取mail server上的郵件。每一個用戶都在某一個mail server上擁有自己的 **mailbox** 猾愿，里面裝著待收取的郵件鹦聪。如果接收端的mail server出現(xiàn)問題，發(fā)送端的mail server可以察覺到并且將發(fā)送失敗的郵件保存到自己的 **message queue** 中蒂秘，過一段時間后再次嘗試發(fā)送泽本，如果失敗次數(shù)過多，發(fā)送端mail server就會通知用戶是否要將郵件刪除姻僧。

SMTP是電郵使用的標(biāo)準(zhǔn)應(yīng)用層協(xié)議规丽，它下層使用TCP可靠傳輸，提供將郵件從發(fā)送端mail server傳輸?shù)浇邮斩薽ail server的服務(wù)撇贺。SMTP有兩個端赌莺，一個運行在發(fā)送端mail server上的客戶端，一個運行在接收端mail server上的服務(wù)端显熏，不過每一個mail server都會同時運行SMTP的兩種端雄嚣，因為它要同時扮演發(fā)送端和接收端兩種角色晒屎。

## 2.3.1 SMTP

假設(shè)Alice想要給Bob發(fā)送一個純ASCII字符文件：

1. Alice打開她的user agent喘蟆，輸入Bob的電郵地址，然后將已經(jīng)寫好的郵件發(fā)送

2. Alice的user agent將郵件發(fā)送到她的mail server處鼓鲁，mail server接收到后將該郵件存儲在待發(fā)送隊列中

3. Alice這邊的mail server上運行的SMTP發(fā)現(xiàn)待發(fā)送隊列中有新郵件蕴轨，就會開始申請與Bob的mail server上的SMTP（port 25）進行TCP連接

4. 待雙方的SMTP連接成功后，Alice端（即SMTP客戶端）就會將Alice的郵件放到TCP信道上發(fā)送

5. 郵件傳輸?shù)紹ob端的mail server后骇吭，其上運行的SMTP會接收該郵件橙弱，然后買了server將該郵件放到Bob的mailbox中

6. Bob的user agent會給他發(fā)出一個新郵件提示，Bob有空時即可閱讀


值得注意的一點是，SMTP傳輸不使用中繼服務(wù)器棘脐，也就是說斜筐，【即使郵件通信雙方處在地球的南北極，郵件也會直接在雙方的mail server之間通過SMTP傳輸蛀缝，不會因為距離太遠而在中途被中繼發(fā)送】顷链。不僅如此，電子郵件要么發(fā)送成功——在接收端手中屈梁，要么發(fā)送失敗——在發(fā)送端手中等待重新發(fā)送嗤练，絕不可能因為傳輸中途失敗而留存在某一個發(fā)送端和接收端之外的服務(wù)器中。

## 2.3.2 Comparison with HTTP

HTTP和SMTP有相同之處在讶，他們都用于在服務(wù)器和客戶端之間傳送數(shù)據(jù)煞抬，都使用persistent connection。它們的不同之處在于：

1. HTTP是一種 **pull protocol** 构哺，比如用戶通過HTTP去web server上主動pull下來自己想要的信息革答。【在HTTP建立的TCP連接中遮婶，通常是想要主動獲取數(shù)據(jù)的一方先發(fā)起TCP請求】

? SMTP是一種 **push protocol** 蝗碎，比如電郵發(fā)送端的mail server將郵件主動push到接收端mail server∑炱耍【在SMTP建立的TCP連接中蹦骑，通常是想要主動發(fā)送數(shù)據(jù)的一方先發(fā)起TCP請求】

2. SMTP要求郵件內(nèi)容全是ASCII格式的，如果有非ASCII格式的內(nèi)容臀防，要先將這部分內(nèi)容轉(zhuǎn)成ASCII格式才能發(fā)送眠菇，而HTTP沒有這個要求

3. HTTP會將每一個object封裝到HTTP response message中逐個發(fā)送，而SMTP會將所有的objects封裝到一個message中一次全部發(fā)送

## 2.3.3 Mail Access Protocols

我們之前討論的內(nèi)容中袱衷，只說了mail server之間消息的傳輸需要SMTP捎废，但其實從發(fā)送端user agent將消息發(fā)送到他的mail server這一步也是需要SMTP來push的，那么接收端該如何從他的mail server中獲取郵件數(shù)據(jù)呢致燥？SMTP只能push不能用登疗，因此必須要想其他方法。

事實上可以完成把郵件從接收端mail server給pull到user agent這一任務(wù)協(xié)議有很多：**Post Office Protocol——Version 3（POP3）嫌蚤，Internet Mail Access Protocol（IMAP）辐益，以及HTTP**?

<img src="C:\Users\65403\Desktop\typora圖片\image-20200928100545154.png" alt="image-20200928100545154" style="zoom:50%;" />

### 2.3.3.1 POP3

POP3是一個極其簡單的協(xié)議，因為它太簡單了以至于它的許多功能都受限了脱吱。

接收端的user agent對它的mail server的110端口（POP3端口）發(fā)起TCP連接智政，POP3的運行有三個階段：authorization、transaction以及update箱蝠。

1. authorization续捂。這一階段user agent會發(fā)送用戶名和密碼來驗證用戶身份

2. transaction垦垂。這一階段user agent將消息內(nèi)容pull到本地，并標(biāo)記郵件狀態(tài)（是否要刪除牙瓢，標(biāo)為已讀等）

3. update劫拗。用戶在user agent發(fā)出 quit指令后，本次POP3對話結(jié)束矾克，與此同時mail server將標(biāo)記為刪除的郵件刪除杨幼。

### 2.3.3.2 IMAP

POP3只能把郵件取回到用戶本地，而IMAP可以將郵件取到用戶指定的云存儲器中聂渊，它比POP3要復(fù)雜的多差购。IMAP server可以通過IMAP session持續(xù)維護用戶的狀態(tài)信息，IMAP還允許用戶一次獲取部分郵件信息汉嗽，比如只獲取郵件頭部信息欲逃，或者部分郵件內(nèi)容，當(dāng)用戶網(wǎng)絡(luò)狀況不好時饼暑，用戶可以通過該方法僅僅獲取郵件中的文字內(nèi)容稳析，等到網(wǎng)絡(luò)狀況較好時再收取其中的媒體內(nèi)容。

### 2.3.3.3 Web-Based E-Mail

如今越來越多用戶通過web browser來獲取電郵弓叛，使用Web-Based Email時彰居，user agent就是一個web browser，用戶通過HTTP來與遠程的mail box通信撰筷。發(fā)送端將郵件發(fā)送到mail server使用HTTP協(xié)議陈惰，當(dāng)接收端想要從mail server中獲取郵件時，郵件內(nèi)容也會通過HTTP協(xié)議pull到接收端主機上毕籽，不過兩個mail servers之間的數(shù)據(jù)傳輸依然使用SMTP抬闯。

# 2.4 DNS—The Internet’s Directory Service

雖然人類可以同時被身份證號、姓名关筒、學(xué)生證號所標(biāo)識溶握，但通常情況下我們更愿意用好記的方式——姓名，去記住一個人蒸播。計算機網(wǎng)絡(luò)中的主機也一樣睡榆，用ip地址去標(biāo)識一個主機對機器來說輕而易舉，但對人類來說卻十分痛苦袍榆，DNS的出現(xiàn)就是為了解決人類記憶up地址難的問題胀屿。

## 2.4.1 Services Provided by DNS

利用字符串來標(biāo)識網(wǎng)絡(luò)實體方便了人類，但卻幾乎不可能為機器（如路由器）所用蜡塌，因為字符串長短不一碉纳，如果統(tǒng)一字符串格式又會造成限制過多勿负，在加上字符串相關(guān)算法一般復(fù)雜度較高馏艾，所以路由器等設(shè)備在工作時仍然以IP地址來標(biāo)識網(wǎng)絡(luò)實體劳曹。

所以每一個網(wǎng)絡(luò)實體都同時被IP地址和字符串hostname所標(biāo)識，為了同時滿足機器處理方便和人類記憶方便琅摩，就得提供一種機制快速對IP地址和hostname進行轉(zhuǎn)換铁孵，**domain name system（DNS）** 提供了這個轉(zhuǎn)換的服務(wù)。

DNS的定義：首先它是【由一組劃分等級的DNS servers組成的分布式數(shù)據(jù)庫】房资，也是【一個應(yīng)用層協(xié)議蜕劝，使得主機可以向DNS數(shù)據(jù)庫發(fā)起域名轉(zhuǎn)換請求】。

大多數(shù)應(yīng)用層協(xié)議都離不開DNS轰异，假設(shè)某一個browser想要請求baidu的主頁岖沛， 它能夠把HTTP request正確發(fā)送到百度web服務(wù)器的前提就是拿到www.baidu.com的IP地址：

1. browser所在的主機上同時運行著DNS client進程

2. browser將用戶在URL中輸入的www.baidu/com提取出來并發(fā)送給DNS client進程

3. DNS client向DNS server發(fā)起對www.baidu.com的域名轉(zhuǎn)換請求（請求報文基于UDP傳輸）

4. 正常情況下，一段時間后DNS client會收到DNS server的回復(fù)搭独，其中包含了www.baidu.com的IP地址

5. browser拿到了目標(biāo)IP地址后婴削，就開始向該IP主機發(fā)起TCP請求

除了能夠進行域名轉(zhuǎn)換，DNS還提供了其他的重要功能：

1. Host aliasing牙肝。一個IP地址可以申請多個域名唉俗，DNS能夠?qū)⑷魏斡蛎加成涞秸_的IP

2. Mail server aliasing。 DNS還可以為電子郵箱地址提供別名轉(zhuǎn)換服務(wù)

3. Load distribution配椭。為了降低服務(wù)器的壓力虫溜，很多機構(gòu)會將服務(wù)器分布在各個地方，但這些服務(wù)器都提供相同的服務(wù)（如web）股缸，DNS可以將這樣一組功能相同但IP不同的服務(wù)器映射到同一個域名上

## 2.4.2 Overview of How DNS Works

### 2.4.2.1 A Distributed, Hierarchical Database

互聯(lián)網(wǎng)中衡楞，沒有任何一個DNS server是全能的——能夠提供所有的地址轉(zhuǎn)換，整個DNS生態(tài)其實是遍布世界各地的分布式服務(wù)器集群敦姻，它們之間有嚴(yán)格的等級劃分寺酪。一般情況下DNS server可以被劃分為四種：

1. root DNS servers

? 總共有400多臺遍布世界各地，提供TLD的IP地址

2. top-level domain（TLD）DNS servers

? 每一個頂級域名（com替劈、org寄雀、edu等）都對應(yīng)了一個TLD，Verisign Global Registry Services公司維護com陨献，Educause公司維護edu盒犹。TLD提供authoritative servers的IP地址

3. authoritative DNS servers

? 想在互聯(lián)網(wǎng)上讓別人使用自己的服務(wù)器，就必須要將服務(wù)器的【域名--IP 】記錄到authoritative DNS server中眨业〖卑颍可以選擇實現(xiàn)自己的authoritative DNS server，把服務(wù)器的【域名--IP】記錄上去龄捡，也可以選擇付錢把自己的【域名--IP】記錄到別人authoritative DNS server上卓嫂，一般大學(xué)和大公司都擁有自己的authoritative DNS server。

4. local DNS server

? 嚴(yán)格來說它不屬于DNS hierarchy中的一種聘殖。一般每一個ISP都有一個local DNS server晨雳，client連接上ISP后行瑞，所有DNS請求會先發(fā)到local DNS server，它作為代理將client的DNS請求發(fā)送給root DNS server餐禁，一般local DNS server距離client只有幾個路由器的距離血久。

<img src="C:\Users\65403\Desktop\typora圖片\image-20201007153611383.png" alt="image-20201007153611383" style="zoom:50%;" />

假如某個client想要請求www.baidu.com的IP地址：

1. client將DNS請求發(fā)送給local DNS server，由它將請求代理轉(zhuǎn)發(fā)給root server

2. 一段時間后帮非，root server將對應(yīng)TLD的IP地址回復(fù)給local DNS server

3. local DNS server與TLD聯(lián)絡(luò)氧吐，TLD返回對應(yīng)authoritative server的IP地址

4. 接著local DNS server與authoritative server聯(lián)絡(luò)，authoritative server返回www.baidu.com的IP地址

5. 最后local DNS server把百度的ip地址發(fā)送給client

這就是典型的DNS lookup過程末盔。

<img src="C:\Users\65403\Desktop\typora圖片\image-20201007161910182.png" alt="image-20201007161910182" style="zoom:50%;" />

以上這種DNS請求過程中筑舅，從requesting host到local DNS server是 **recursive query** （請求是以遞歸的方式進行的），而接下來local DNS sersver的三個請求都是 **iterative query** （請求的結(jié)果直接返回請求方）

### 2.4.2.2 DNS Caching

DNS轉(zhuǎn)換的過程太耗時間了陨舱，需要與好幾個server通信才能進行一次轉(zhuǎn)換豁翎。因此為了減少轉(zhuǎn)換過程中時間的消耗，現(xiàn)在普遍采用DNS Caching機制隅忿，它的原理如下：

在DNS請求鏈中所有涉及到的DNS servers心剥，它們只要收到一個DNS reply（已經(jīng)轉(zhuǎn)換好的結(jié)果），就會把這個reply結(jié)果緩存在本地背桐，這樣之后如果收到一個對相同域名的請求就可以立即將結(jié)果返回优烧，DNS server大概每兩天會對本地的DNS reply條目進行更新。

在DNS caching機制的作用下链峭，大多數(shù)DNS請求根本無法到達root DNS server畦娄，因此節(jié)省了巨量的DNS轉(zhuǎn)換時間，也節(jié)省了巨量的網(wǎng)絡(luò)資源弊仪。

## 2.4.3 DNS Records and Messages

DNS中存儲的條目叫做 **resource records（RRs）** 熙卡，它給出了域名到IP地址的映射關(guān)系。每一個DNS reply message可以攜帶多個RRs励饵。

RRs是一個四元組（Name驳癌，Value，Type役听，TTL）颓鲜，其中TTL規(guī)定了本條RRs應(yīng)該多久時候被更新，Name和Value字段的意義取決于Type：

1. 當(dāng)【Type=A】時典予，Name字段代表hostname甜滨，Value字段代表Name對應(yīng)的IP address，所以Type A的RRs提供了標(biāo)準(zhǔn)的hostname-to-IP映射瘤袖。比如RRs（www.funwithcode.com, 145.37.93.126, A, 30）

2. 當(dāng)【Type=NS】時衣摩，Name字段代表domain name（如baidu.com），Value字段代表一個authoritative DNS server的hostname捂敌，它知道如何獲取domain name中任意hosts的IP地址艾扮。Type=NS的RRs用來把當(dāng)前的DNS query送到DNS query chain中的下一個server處既琴。比如RRs（funwithcode.com, dns.funwithcode.com. NS, 30）

3. 當(dāng)【Type=CNAME】時，Name字段是alias hostname栏渺，Value字段是alias hostname的本名，這種類型的RRs是用來將別名轉(zhuǎn)換為原名的锐涯。比如RRs（funwithcode.com, relay1.bar.funwithcode.com, CNAME）

4. 當(dāng)【Type=MX】時磕诊，Name字段是mail server的alias hostname，Value字段是本名纹腌。比如（funwithcode.com, mail.bar.funwithcode.com, MX, 30）霎终。MX RRs使得人們可以給mail servers的hostname起更好記的別名。要注意的是一個機構(gòu)可以給mail server和其他server（如web server）起一樣的別名升薯，這時只能靠DNS message中的Type來區(qū)別client請求的是哪個server的域名

某一個hostname（比如A）的authoritative DNS server中存儲了A對應(yīng)的type A RRs莱褒，利用它可以直接對A進行域名轉(zhuǎn)換；然而這個DNS server可能對其他的hostname（比如B）來說可能不是authoritative DNS server涎劈，此時這個server中存儲了hostname B對應(yīng)的type NS RRs广凸，該條目提供了hostname B所處的域名，以及一個type A條目——提供能對NS RRs域名中所有host進行域名轉(zhuǎn)換的authoritative DNS server的IP地址（包含在value字段中）蛛枚。

比如某DNS server 不是www.baidu.com的authoritative DNS server谅海，則它會包含一個type NS的條目（baidu.com, dns.baidu.com, NS, 30）提供了知道如何域名轉(zhuǎn)換www.baidu.com的authoritative DNS server的hostname，以及一個type A條目（dns.baidu.com, 123.123.123.123, A, 20）對NS RRs中hostname進行域名轉(zhuǎn)換蹦浦。

### 2.4.3.1 DNS Message

DNS reply和DNS request報文【格式相同】扭吁。

<img src="C:\Users\65403\Desktop\typora圖片\image-20201024163602442.png" alt="image-20201024163602442" style="zoom:70%;" />

【header section】

最上方的12 bytes是 **header section** 。

Identification：在DNS處理的過程中client可能還會不斷的發(fā)送DNS請求盲镶，該字段幫助client弄清楚哪個請求對應(yīng)哪個回應(yīng)

Flags：其中包含了幾個標(biāo)志位侥袜。

| flag name? ? ? ? ? ? ? ? | flag meaning? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |

| :----------------------- | ------------------------------------------------------------ |

| query/reply flag? ? ? ? | 標(biāo)識DNS報文類型，1為回復(fù)溉贿，0為請求? ? ? ? ? ? ? ? ? ? ? ? ? ? |

| authoritative flag? ? ? | 當(dāng)請求轉(zhuǎn)換的hostname到達authoritative DNS server時枫吧，其回復(fù)報文中該字段為1 |

| recursion-desired flag? | client想要遞歸式的DNS解析時，該字段為1? ? ? ? ? ? ? ? ? ? ? |

| recursion-available flag | 當(dāng)DNSserver支持遞歸式解析時宇色，該字段為1? ? ? ? ? ? ? ? ? ? ? |

|? ? ? ? ? ? ? ? ? ? ? ? ? |? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |

四個number-of：不同RRs的數(shù)量

【question section】

在client發(fā)送給DNS server的詢問報文中由蘑，包含了client的DNS請求信息。

【answer section】

在DNS server發(fā)回給client的回復(fù)報文中代兵，其中包含了DNS server對query的回復(fù)信息尼酿。

【authority section】

包含其他authoritative server的記錄

【additional section】

其他的補充信息

可以直接通過nslookup程序向附近的DNS server發(fā)送DNS請求，比如在命令行中輸入nslookup后植影，當(dāng)接收到DNS server的回復(fù)后裳擎，nslookup就會將回復(fù)的信息（answer section中的數(shù)據(jù)）轉(zhuǎn)譯成人話并打印在屏幕上

### 2.4.3.2 Inserting Records into the DNS Database

假設(shè)我們剛剛成立了一家互聯(lián)網(wǎng)業(yè)務(wù)公司（假設(shè)叫networkutopia），則我們要做的第一件事就是去 **registrar** 注冊networkutopia.com這個域名思币，registrar是一類商業(yè)公司鹿响，它們的主營業(yè)務(wù)就是讓客戶注冊【獨一無二】的域名羡微，并把這個域名寫入到 **DNS database** 中。1999年Network Solutions壟斷了com, net, org這些頂級域名惶我，之后涌現(xiàn)了很多registrars與其競爭妈倔，所有的accredits都可在ICANN中查到。

當(dāng)我們在某個registrar注冊networkutopia.com域名時绸贡，還需要提供【主/次authoritative DNS servers】的域名和IP地址盯蝴，registrar會將這兩個DNS server對應(yīng)的Type NS和Type A條目存入頂級DNS servers（TLD server），即下列兩個條目：

(networkutopia.com, dns1.networkutopia,com, NS)

(dns1.networkutopia.com, 212,212,212,1, A)

與此同時听怕，還得確保我們公司web server（www.networkutopia.com）的Type A和mail server（mail.networkutopia.com）的Type MX記錄存入了我們的主/次authoritative DNS server中（現(xiàn)在這一過程通常動態(tài)的完成）

## 2.4.4 Conclude

最后通過一個例子來把DNS這節(jié)的知識總結(jié)一下捧挺。

假如A想要訪問www.networkutopia.com網(wǎng)站。

1. 首先她的主機會發(fā)送DNS query給local DNS server尿瞭，

2. 接著local DNS server將請求轉(zhuǎn)發(fā)到TLD com server（如果TLD server中沒有緩存networkutopia的條目闽烙，則TLD server會把root server的信息發(fā)給local DNS server，然后local DNS server再將DNS請求發(fā)送給root DNS server）声搁，不過由于我們已經(jīng)成功在TLD server中注冊了我們的域名黑竞，所以query走到TLD com server時命中了

3. 然后TLD將authoritative DNS server信息（一條Type A，一條Type NS）回復(fù)給local DNS server

4. local DNS server提取Type A中提供的authoritatvie DNS server的IP地址212.212.212.1疏旨，并將DNS請求發(fā)給它

5. authoritative DNS server將www.networkutopia.com對應(yīng)的IP地址212.212.212.4發(fā)給local DNS server摊溶，然后local DNS server將其發(fā)送給client

6. 至此A的DNS請求完成，現(xiàn)在A可以與212.212.212.4建立TCP連接并發(fā)送HTTP request來獲取網(wǎng)頁內(nèi)容了

# 2.5 Peer-to-Peer File Distribution

之前我們討論的所有協(xié)議都是基于C/S架構(gòu)的充石，需要一臺不停工作的S來為C提供服務(wù)莫换，而在P2P架構(gòu)中，任意兩臺主機可以直接配對并互相通信骤铃，任意兩臺終端都互為彼此的 **peer** 拉岁，所有在P2P中的實體都即可作為server也可作為client，因此P2P架構(gòu)中所有的實體都可以稱為peer惰爬。

本章我們將討論P2P的一個最基本的應(yīng)用：某一個節(jié)點將一個大文件發(fā)送給其他多個節(jié)點喊暖。試想如果用C/S架構(gòu)來完成這件事，server的負擔(dān)將會非常重——它必須把這一個巨大的文件逐個傳輸給所有其他的client撕瞧，但如果使用P2P架構(gòu)陵叽，網(wǎng)絡(luò)中每一個peer都可以把自己當(dāng)前已經(jīng)接收到的文件的任意部分發(fā)給其他peers，其他peers又把自己已接收文件的任意部分發(fā)送給它們的peers丛版，這樣就將文件分發(fā)的任務(wù)均攤給了每一個網(wǎng)絡(luò)中的節(jié)點巩掺，提高傳輸效率同時，避免了單點網(wǎng)絡(luò)負擔(dān)過重页畦。

<img src="C:\Users\65403\Desktop\typora圖片\image-20201029152135474.png" alt="image-20201029152135474" style="zoom:50%;" />

截止2016年胖替，最流行的P2P文件分發(fā)協(xié)議是BitTorrent。在BitTorrent協(xié)議中，對某一個文件独令，所有參與該文件傳輸?shù)墓?jié)點（peer）組成一個 **torrent** 端朵，該文件被劃分為一個個的chunks（固定大小，一般為256Kb）燃箭，每一對peers互相下載對方的chunks冲呢。

一個剛參與進來的peer沒有chunk，不過隨著它不斷的與其他peer結(jié)對招狸，其他peer會給它傳輸（它缺失的）chunks敬拓，同時它也會不斷給其他節(jié)點傳輸（對方缺失的）chunks。當(dāng)一個節(jié)點獲取到了完整文件后瓢颅，它可以選擇直接離開恩尾，也可以選擇繼續(xù)留下作為server給別人傳輸文件挽懦。

每一個torrent中都包含一個 **tracker**，每當(dāng)一個peer加入torrent時木人，它會在tracker上注冊并周期性的告知tracker自己仍然在當(dāng)前torrent中信柿，這就相當(dāng)于tracker可以一直監(jiān)視本torrent內(nèi)的情況。

當(dāng)一個peer A加入torrent時醒第，tracker會在本torrent中隨機選擇一些peers并將它們的IP地址發(fā)送給A渔嚷，拿到這個peers列表后，A就會并行的與該列表上所有的peers建立TCP連接〕砺現(xiàn)在假定所有與A建立了連接的peers叫做neighboring peers形病，隨著時間的推移，A的neighboring peers中有一些會退出霞幅，也會有一些新加入peers與A建立連接漠吻，因此A的neighboring peers list是 **動態(tài)變化的** 。

與所有neighboring peers建立連接后司恳，A就會周期性的詢問它所有的鄰居：你們手上都有哪些trunk途乃？列好清單發(fā)給我看看。A收到清單后扔傅，就會根據(jù)清單上的內(nèi)容耍共，向所有鄰居請求它缺少的trunks（優(yōu)先請求最稀缺的trunk，以此來盡力保持每個trunk數(shù)量的平衡）猎塞。

# 2.6 Video Streaming and Content Distribution Networks

## 2.6.1 Internet Video

首先我們來了解一下什么是video试读。

video本質(zhì)上是一系列圖片，這些圖片以每秒24~30張的速度顯示在屏幕上荠耽。一張數(shù)碼圖片由一組pixels組成鹏往，每一個pixel以比特的形式編碼，這個編碼的值就代表了亮度和顏色。

video的一個重要特性就是其比特率可以被壓縮伊履，比特率越低韩容，畫質(zhì)越差，所占硬盤空間越小√破伲現(xiàn)在一般視頻網(wǎng)站都會為一個視頻提供不同清晰度的版本群凶，方便用戶根據(jù)自己的網(wǎng)絡(luò)狀況進行選擇。

## 2.6.2 HTTP Streaming and DASH

使用HTTP Streaming的話哄辣，視頻就存儲在HTTP server上请梢。當(dāng)client想要觀看視頻時，只需要與HTTP server建立TCP連接力穗，并發(fā)送HTTP GET請求指定視頻（用URL標(biāo)識）毅弧，之后server就會把視頻打包在HTTP回復(fù)中發(fā)送給client。client這邊視頻播放器會有一個buffer当窗，當(dāng)接收數(shù)據(jù)達到一定閾值時就會開始播放視頻够坐。

一開始很多視頻公司（比如YouTube）都是采用HTTP Streaming方式提供服務(wù)，但它的缺點在于所有的用戶只能觀看同一種清晰度的視頻崖面，為了提高靈活性元咙，現(xiàn)在一般一種新的基于HTTP的streaming方式：**Dynamic Adaptive Streaming over HTTP（DASH）** ，它為每一個視頻提供了多個不同清晰度的版本巫员。

## 2.6.3 Content Distribution Networks

試想像Youtube這樣的公司庶香，每秒鐘都要為全世界的網(wǎng)友傳輸巨量的視頻數(shù)據(jù)，這個任務(wù)該如何完成呢简识？

利用**Content Distribution Networks(CDNs)** 技術(shù)赶掖，它可以管理多個分布在不同地理位置的服務(wù)器集群（cluster），在這些服務(wù)器中存儲視頻（可能還有音頻和文件）七扰，并指引用戶去距離最近的cluster請求視頻數(shù)據(jù)奢赂。如果請求的視頻并未存儲在當(dāng)前cluster中，則當(dāng)前cluster會去其他cluster請求該視頻戳寸，并在將該視頻存儲在本地的同時發(fā)送給用戶呈驶。

#