第二章：應用層 |《計算機網路：自頂向下方法》

一、應用層協議原理

1、網路應用程序體系結構

客戶-伺服器體系結構（C-S）：Web

點對點結構（P2P）：迅雷

混合結構：Napster

2、進程通信

客戶和伺服器進程

進程與計算機網路之間的介面：進程通過套接字（socket）軟體介面向網路發送報文和從網路接收報文。

進程定址：主機的地址由IP地址標識，進程的位置由埠號標識。

3、可供應用使用的運輸服務

運輸服務的衡量標準：可靠數據傳輸、吞吐量、定時、安全性

4、網際網路提供的運輸服務

TCP服務：特點是面向連接和可靠的數據傳送

UDP服務：特點是無連接的最小服務（非可靠）

5、應用層協議

應用層協議(application layer protocol)定義了運行在不同端系統上的應用程序進程如何相互傳遞報文。

(1)交換的報文類型，如請求報文和響應報文；

(2)各種報文類型的語法，如報文中的各個欄位公共詳細描述;

(3)欄位的語義，即包含在欄位中信息的含義；

(4)進程何時、如何發送報文及對報文進行響應。

二、Web和HTTP

1、HTTP

HTTP即超文本傳輸協議，是Web的應用層協議。

Web是由對象組成的，比如一個Web頁面包含一個HTML文本和5個JPRG圖形，那麼這個Web就包含了6個對象。

HTTP使用TCP作為它的支撐運輸協議。

HTTP不保存關於客戶的任何信息，所以我們說HTTP是一個無狀態協議。

2、非持續連接和持續連接

參考鏈接：面試時如何優雅的談論HTTP／1.0／1.1／2.0

HTTP 1.0

HTTP 1.0規定瀏覽器與伺服器只保持短暫的連接，瀏覽器的每次請求都需要與伺服器建立一個TCP連接，伺服器完成請求處理後立即斷開TCP連接，伺服器不跟蹤每個客戶也不記錄過去的請求。但是，這也造成了一些性能上的缺陷，例如，一個包含有許多圖像的網頁文件中並沒有包含真正的圖像數據內容，而只是指明了這些圖像的URL地址，當WEB瀏覽器訪問這個網頁文件時，瀏覽器首先要發出針對該網頁文件的請求，當瀏覽器解析WEB伺服器返回的該網頁文檔中的HTML內容時，發現其中的圖像標籤後，瀏覽器將根據標籤中的src屬性所指定的URL地址再次向伺服器發出下載圖像數據的請求。顯 然，訪問一個包含有許多圖像的網頁文件的整個過程包含了多次請求和響應，每次請求和響應都需要建立一個單獨的連接，每次連接只是傳輸一個文檔和圖像，上一次和下一次請求完全分離。即使圖像文件都很小，但是客戶端和伺服器端每次建立和關閉連接卻是一個相對比較費時的過程，並且會嚴重影響客戶機和伺服器的性能。當一個網頁文件中包含JavaScript文件，CSS文件等內容時，也會出現類似上述的情況。

HTTP1.1

為了克服HTTP 1.0的這個缺陷，HTTP 1.1支持持久連接（HTTP/1.1的默認模式使用帶流水線的持久連接），在一個TCP連接上可以傳送多個HTTP請求和響應，減少了建立和關閉連接的消耗和延遲。一個包含有許多圖像的網頁文件的多個請求和應答可以在一個連接中傳輸，但每個單獨的網頁文件的請求和應答仍然需要使用各自的連接。HTTP 1.1還允許客戶端不用等待上一次請求結果返回，就可以發出下一次請求，但伺服器端必須按照接收到客戶端請求的先後順序依次回送響應結果，以保證客戶端能夠區分出每次請求的響應內容，這樣也顯著地減少了整個下載過程所需要的時間。

HTTP2.0

HTTP/2.0 時代擁有了「多路復用」功能，意思是: 在一條連接上，我可以同時發起無數個請求，並且響應可以同時返回。

3、HTTP報文格式

參考鏈接：HTTP請求、響應報文格式 - CSDN博客

請求報文：HTTP請求報文主要由請求行、請求頭部、請求正文3部分組成。

響應報文：HTTP響應報文主要由狀態行、響應頭部、響應正文3部分組成。

4、用戶和伺服器的交互：cookie

參考鏈接：計算機網路應用層之cookie - CSDN博客

1）cookie技術的組成

在了解cookie的工作原理之前，我們先來了解一下cookie技術的組成，它由4部分組成，如下：

1. 在HTTP響應報文中有一個cookie首部行；
2. 在HTTP請求報文中有一個cookie首部行；
3. 在用戶端系統中保留有一個cookie文件，由用戶瀏覽器管理；
4. 在Web站點有一個後端資料庫；

2）cookie的工作原理

在了解了cookie技術的組成之後，我們來看看cookie是怎麼工作的。下面就以主機A中的瀏覽器訪問網站xxx作為例子來分析cookie的工作原理吧。

首先主機A使用瀏覽器上網，當主機A第一次訪問xxx網站時，當請求報文到達xxx的Web伺服器時，該Web伺服器將產生一個唯一識別碼（例如：12345），並以此作為索引在它的後端資料庫中產生一個表項，並用Set-cookie：首部行和剛才產生的值為設置HTTP響應報文的首部。這樣在HTTP響應報文的首部，我們就可以看到這樣的一個首部行——Set-cookie: 12345.

當主機A的瀏覽器收到該HTTP響應報文時，它會看到Set-cookie：首部，然後瀏覽器在它的本地cookie文件上加入一行，其中包括Set-cookie：首部行中的識別碼。

由於主機A的cookie文件已經有了用於xxx網站的表項，因此當主機A的瀏覽器繼續瀏覽xxx網站時，每請求一個Web頁面，其瀏覽器就會從它的cookie文件中獲取到xxx網站的識別碼，並放入HTTP請求報文中cookie首部行中，即加入了首部行Cookie: 12345。

當xxx網站的伺服器收到該包含Cookie首部行的HTTP請求報文後，伺服器通過查詢後端伺服器，確定cookie標識碼對應的用戶，從而可以直接知道用戶的信息（即知道確實有一個這樣的用戶，不久前登陸過該網站）。

注意，在cookie的方式下，xxx網站的伺服器可以跟蹤主機A在該站點的活動，xxx Web站點並不需要知道主機A的用戶是誰，但是，它確切地知道用戶12345訪問了哪些頁面，按照什麼順序，在什麼時間。

簡單點來說，cookie用於標識用戶，用戶首次訪問站點時，可能需要提供一個用戶標識，但在後繼的訪問中，瀏覽器向伺服器傳遞一個cookie首部，供伺服器識別該用戶。因此cookie可以在無狀態的HTTP上建立一個用戶會話層，允許伺服器通過用戶與應用程序之間的會話對用戶進行驗證。

5、Web緩存器（代理伺服器）

1）使用Web緩存器的2個主要原因：

• 降低延遲：緩存離客戶端更近，因此，從緩存請求內容比從源伺服器所用時間更少，呈現速度更快，網站就顯得更靈敏。
• 降低網路傳輸：副本被重複使用，大大降低了用戶的帶寬使用，其實也是一種變相的省錢（如果流量要付費的話），同時保證了帶寬請求在一個低水平上，更容易維護了。

2）工作過程

6、條件get方法

參考鏈接：應用層-3、web緩存和代理伺服器技術 - CSDN博客

上述實現方式還有一個問題就是無法保證本地存儲器內的內容是最新的，所以需要採用一種方式——（條件性GET方法）來保證數據是最新版本。這個方法的基本思想就是本地代理伺服器向URL目標伺服器發送一個GET請求消息，這個消息裡面包括了本地存儲資源的更新時間，在URL目標伺服器中，會用這個時間與最新版本的時間進行比對，如果時間一致就返回 304 Not Modified , 否則就返回 200 OK 和最新版本的資源。代理伺服器接收到返回信息後會判斷這個返回碼，如果是304，就直接返回給客戶給本地代理伺服器存儲的資源；如果是200就把新接收到的資源返回給用戶，同時更新代理伺服器存儲的內容。

三、文件傳輸協議FTP

FTP的特點：同HTTP一樣，也是運行在TCP上的協議，但它採用了兩個並行的TCP連接來傳輸文件，一個用於控制連接，一個用於數據連接，所以我們稱其為帶外（out-of-band）傳輸。另外，控制鏈接和持續整個過程，而每傳輸一個新文件，都需要新開一條數據連接。

四、網際網路中的電子郵件

參考鏈接：[計算機網路-應用層] 網際網路中的電子郵件

電子郵件的組成部分：

用戶代理、郵件伺服器和簡單郵件傳輸協議。

用戶代理允許用戶閱讀、回復、轉發、保存和撰寫報文。

郵件伺服器組成了電子郵件體系結構的核心。每個接收方在其中的某個伺服器上有一個郵箱。郵箱包含用戶的到達報文、離開(將發送)郵件報文的報文隊列；在發送電子郵件報文的郵件伺服器之間採用SMTP協議。

SMTP是網際網路電子郵件中主要的應用層協議。它使用TCP可靠數據傳輸服務，從發送方的郵件伺服器向接收方的郵件伺服器發送郵件。

1、SMTP

使用TCP從客戶機到伺服器可靠地傳輸電子郵件報文，用埠25。

直接傳輸：發送伺服器到接收伺服器。

傳輸的三個階段：握手 (歡迎)、報文的傳輸、關閉。

命令/響應交互

命令: ASCII文本

響應: 狀態碼和短語

報文必須以7比特ASCII格式。

為了描述SMTP的基本操作，下面來模擬一下Alice給Bob發送一封簡單的ASCII報文的過程：

1) Alice使用UA寫作報文並向 bob@someschool.edu 發送

2) Alice的UA向其郵件伺服器發送報文；報文放置在報文隊列中

3) SMTP的客戶機側打開與Bob的郵件伺服器的TCP連接

4) SMTP通過TCP連接發送Alice的報文

5) Bob的郵件伺服器將該報文放入Bob的郵箱

6) Bob調用其用戶代理來讀報文

2、SMTP與HTTP的對比

HTTP: 拉協議 SMTP: 推協議

SMTP要求全部7位ASCII碼格式傳輸，HTTP無此要求

HTTP: 每個對象封裝在其自己的響應報文中 SMTP: 所有報文對象放在一個報文中

兩者都有ASCII 命令/響應交互，狀態碼

3、郵件報文格式

一個典型的報文首部如下：

From: alice@crepes.frTo: bob@hamburger.eduSubject: Searching for the meaning of life.

在報文首部之後，緊接著是一個空白行，然後是以ASCII格式表示的報文主體。

MIME：

由於在RFC 822中描述的報文首部只適合於發送普通ASCII文本，不能充分滿足多媒體報文（如帶有圖片、音頻和視頻的報文）或攜帶有非ASCII文本格式（例如，非英語語言所使用的字元）的報文的需求。為發送非ASCII文本的內容，發送方的用戶代理必須在報文使用附加的首部行。這些額外的首部行定義在RFC 2045和RFC 2046中，多用途網際網路郵件擴展（MIME）是對RFC 822的擴展。

支持多媒體的兩個關鍵MIME首部是Content-Type：和Content-Transfer-Encoding：。

Content-Type：首部行允許接收用戶代理對報文採取適當的動作。

Content-Transfer-Encoding：首部行提示接收用戶代理該報文主體已經使用了ASCII編碼，並指出了所用的編碼類型。

接收伺服器一旦接收到具有RFC 822和MIME首部行的報文，就在該報文的頂部添加一個Received：首部行；該首部行定義了發送該報文的SMTP伺服器的名稱（from），接收該報文的SMTP伺服器的名稱（by），以及接收伺服器接收到的時間。

有時一個郵件有多個Receive：行，這是因為有的郵件在發送方和接收方之間的路徑要經過不止一個SMTP伺服器轉發。

4、郵件訪問協議

在上述分析中，有一個疏漏的環節，那就是在Alice向Bob發送郵件的過程中，Bob是如何通過運行在他本地PC上的用戶代理，獲得位於某ISP的郵件伺服器上的他的郵件呢？注意到Bob的用戶代理不能使用SMTP來取回郵件，因為取郵件時一個拉操作，而SMTP是一個推協議。因此我們要引入郵件訪問協議。

POP

POP協議支持「離線」郵件存儲轉發處理：客戶端程序連接伺服器，下載所有未閱讀的電子郵件；一旦將郵件從郵件伺服器端送到客戶端上，郵件伺服器上的郵件將會被刪除。

POP3

POP3協議允許電子郵件客戶端下載伺服器上的郵件，但是在客戶端的操作（如移動郵件、標記已讀等），不會反饋到伺服器上，比如通過客戶端收取了郵箱中的3封郵件並移動到其他文件夾，郵箱伺服器上的這些郵件是沒有同時被移動的 。

IMAP，以及和POP3的區別

IMAP像POP3那樣提供了方便的郵件下載服務，讓用戶能進行離線閱讀。IMAP和POP3是郵件訪問最為普遍的Internet標準協議。不同的是：

• IMAP提供Webmail與電子郵件客戶端之間的雙向通信，客戶端收取的郵件仍然保留在伺服器上，同時在客戶端上的操作都會反饋到伺服器上（如：刪除郵件，標記已讀等，伺服器上的郵件也會做相應的動作。所以無論從瀏覽器登錄郵箱或者客戶端軟體登錄郵箱，看到的郵件以及狀態都是一致的）。而POP3在客戶端的操作不會反饋到伺服器上。
• IMAP更好地支持了從多個不同設備中隨時訪問新郵件。
• IMAP提供的摘要瀏覽功能可以讓你在閱讀完所有的郵件到達時間、主題、發件人、大小等信息後才作出是否下載的決定。
• POP3需要下載未閱讀的郵件，IMAP可以不用把所有的郵件全部下載，而是通過客戶端直接對伺服器上的郵件進行操作。所有通過IMAP傳輸的數據都會被加密，從而保證通信的安全性。
• IMAP 整體上為用戶帶來更為便捷和可靠的體驗。POP3 更易丟失郵件或多次下載相同的郵件。

五、DNS：網際網路的目錄服務

參考鏈接：[計算機網路-應用層] DNS：網際網路的目錄服務

DNS提供的服務主要為主機名到IP地址。

1、DNS提供的其他服務：

• 主機別名。有著複雜主機名的主機可以擁有一個或多個別名。原複雜主機名也叫規範主機名。主機別名（如果有的話）比主機規範名更容易記憶。應用程序可以調用DNS來獲得主機別名對應的規範主機名以及主機的IP地址。
• 郵件伺服器別名。同主機別名類似，電子郵件應用程序調用DNS，對提供的郵件伺服器別名進行解析，以獲得該主機的規範主機名以及其IP地址。MX（Mail Exchanger，郵件交換）記錄允許一個公司的郵件伺服器和Web伺服器用相同的（別名化的）主機名。
• 負載分配。DNS也用於在冗餘的伺服器（如冗餘的Web伺服器等）之間進行負載分配。對於這些冗餘的Web伺服器，一個IP地址集合對應於同一個規範主機名。DNS資料庫中存儲著這些IP地址集合。當客戶機為映射到這個IP地址集合的名字發出一個DNS請求時，該伺服器用包含全部這些地址的報文回答，但在每個回答中旋轉這些地址排放順序。因為客戶機通常總是向IP地址排在最前面的伺服器發送HTTP請求報文，所以DNS就在所有這些冗餘的Web伺服器之間旋轉分配負載。DNS旋轉同樣適用於郵件伺服器，因此，多個郵件伺服器可以具有相同的別名。

2、DNS的工作原理

DNS採用分散式的設計方案。

下面是DNS伺服器的部分層次結構（由上到下，每層分別是根伺服器、TLD伺服器、權威伺服器）：

1）分散式、層次資料庫

大致來說，有3種類型的DNS伺服器：根DNS伺服器、頂級域（Top Level Domain，TLD）DNS伺服器和權威DNS伺服器。

假設一個DNS客戶機要確定主機名http://www.amazon.com的IP地址。粗略來講，將發生下列事件：

·客戶機請求根伺服器以發現com TLD伺服器 ·客戶機請求com TLD伺服器以得到 http://amazon.com 權威伺服器 ·客戶機請求http://amazon.com 權威伺服器以得到對 http://www.amazon.com的IP地址

下面來詳細介紹一下這三種類型的DNS伺服器：

·根DNS伺服器

在網際網路上有13個根DNS伺服器（標號為a到m），儘管我們將這13個根DNS伺服器中的每個都視為單個的伺服器，但每台「伺服器」實際上是冗餘伺服器的群集，以提供安全性和可靠性。

·頂級域（TLD）伺服器

負責com, org, net, edu等，以及所有頂級國家域 uk, fr, ca, jp.

·權威DNS伺服器

組織的DNS伺服器為組織的伺服器(如Web和電子郵件)提供對IP映射的權威主機名。 能夠由組織或服務提供商維護。

·本地DNS伺服器

本地DNS伺服器嚴格來說並不屬於DNS伺服器的層次結構，但它對DNS層次結構是很重要的。

在圖1的例子中用到了遞歸查詢和迭代查詢。從http://cis.poly.edu到http://dns.poly.edu發出的查詢是遞歸查詢，因為該查詢請求http://dns.poly.edu以自己的名義獲得該映射。而後繼的三個是迭代查詢，因為所有的回答都是直接返回給http://dns.poly.edu。

從理論上，所有的DNS查詢既可以是迭代的也可以是遞歸的。例如，圖2顯示了一條DNS查詢鏈，其中所有查詢都是遞歸的。

實際中，查詢通常遵循圖1中的模式：從請求主機到本地DNS伺服器的查詢是遞歸的，其餘查詢是迭代的。

2）DNS緩存

為了改善時延性能並減少在網際網路上到處傳輸的DNS報文數量，DNS廣泛使用緩存技術。

原理：當一個DNS伺服器接收一個DNS回答（例如，包含主機名到IP地址的映射）時，DNS伺服器能將回答中的信息緩存在本地存儲器。由於主機與主機名的IP地址映射決不是永久的，所以DNS伺服器在一段時間後（通常設置為兩天）將丟棄緩存的信息。

3）域名解析過程

3、DNS記錄和報文

1）DNS記錄：

實現DNS分散式資料庫的所有DNS伺服器共同存儲著資源記錄（Resource Record，RR），RR提供了主機名到IP地址的映射。下面是RR的基本格式：

Type=A name 是主機名，Value是IP地址

Type=NS name 是域 (如 http://foo.com)， Value是該域的權威名字伺服器的IP地址

Type=MX Value是與name相聯繫的郵件伺服器

Type=CNAME Value是別名為name的主機對應的規範主機名

註：通過使用MX記錄，一個公司的郵件伺服器和其他伺服器（如它的Web伺服器）可以使用相同的別名

2）DNS報文：

DNS只有兩種報文，即查詢和回答報文，並且這兩種報文有著相同的格式。

下圖是DNS報文格式：

6、P2P應用

問題 : 從一個伺服器向N個節點分發一個文件需要多長時間?

客戶機/伺服器：伺服器串列地發送N個副本

• 時間： NF/us
• 客戶機i需要F/di時間下載

P2P：伺服器必須發送一個副本

• 時間： F/us
• 客戶機i需要F/di時間下載
• 總共需要下載NF比特
• 最快的可能上傳速率： us + ∑ui

PS：

廣告時間啦~

理工狗不想被人文素養拖後腿？不妨關注微信公眾號：