計算機網路之應用層
阿新 • • 發佈：2020-06-21
### 應用層協議
應用層協議 (application-layer protocol) 定義了執行在不同端系統上的應用程式程序如何相互傳遞報文，特別是應用層協議定義了:
* 交換的報文型別，例如請求報文和響應報文
* 各種報文型別的語法，如報文中的各個欄位及這些欄位是如何描述的
* 欄位的語義，即這些欄位中包含的資訊的含義
* 一個程序何時以及如何傳送報文，對報文進行響應的規則。
在本文中主要是講5種重要的應用: Web 、檔案傳輸、電子郵件、目錄服務和P2P，我們首先討論 Web應用，不僅因為它是極為流行的應用，而且因為它的應用層協議 HTTP 相對比較簡單並且易於理解。討論完 Web ，我們簡要地討論FTP，因為它與 HTTP 形成了很好的對照 我們接下來討論電子郵件應用，這是因特網上最早的招人喜愛的應用程式。說電子郵件比 Web更復雜，是因為它使用了多個而不是一個應用層協議。在電子郵件之後，我們討論DNS它為因特網提供目錄服務，大多數使用者不直接與 DNS 打交道，而是通過其他的應用(包括Web 、檔案傳輸和電子郵件)間接使用它，DNS 很好地說明了一種核心的網路功能(網路名字到網路地址的轉換)是怎樣在因特網的應用層實現的。
### HTTP概況
Web 的應用層協議是超文字傳輸協議 (HyperText Transfer Protocol , HTTP) ，它是Web的核心，HTTP 由兩個程式實現:一個客戶程式和一個伺服器程式。客戶程式和伺服器程式執行在不同的端系統中，通過交換HTTP報文進行會話。 HTTP 定義了這些報文的結構以及客戶和伺服器進行報文交換的方式。HTTP使用TCP作為它的支撐運輸協議(而不是在 UDP 上執行)。HTTP 客戶首先發起一個與伺服器的TCP連線，一旦連線建立，該瀏覽器和伺服器程序就可以通過套接字介面訪問TCP。
**注意：**伺服器向客戶傳送被請求的檔案，而不儲存任何關於該客戶的狀態資訊，假如某個特定的客戶在短短的幾秒鐘內兩次請求同一個物件，伺服器並不會因為剛剛為該客戶提供了該物件就不再做出反應，而是重新發送該物件，就像伺服器已經完全忘記不久之前所做過的事一樣，因為 HTTP 伺服器並不儲存關於客戶的任何資訊，所以我們說HTTP是一個無狀態協議 (stateless protocol) #### 非持續連線和持續連線 在許多因特網應用程式中，客戶和伺服器在一個相當長的時間範圍內通訊，其中客戶發出一系列請求並且伺服器對每個請求進行響應 依據應用程式以及該應用程式的使用方式，這一系列請求可以以規則的間隔週期性地或者間斷性地一個接一個發出。當這種客戶-伺服器的互動是經TCP進行的，應用程式的研製者就需要做一個重要決定，即每個請求/響應對是經一個單獨的 TCP 連線傳送，還是所有的請求及其響應經相同的TCP連線傳送呢?採用前一種方法，該應用程式被稱為使用非持續連線( non- persistent connection) ;採用後一種方法，該應用程式被稱為使用持續連線( persistent connection)。儘管 HTTP在其預設方式下使用持續連線， HTTP 客戶和伺服器也能配置成使用非持續連線。
非持續連線有一些缺點：首先，必須為每一個請求的物件建立和維護一個全新的連線。對於每個這樣的連線，在客戶和伺服器巾都要分配 TCP 的緩衝區和保持 TCP 變數。這給 Web 伺服器帶來了嚴重的負擔，因為一臺 Web 伺服器可能同時服務於數以百計不同的客戶的請求。第二，每一個物件經受兩倍 RTT 的交付時延，即一個RTT 用於建立 TCP ，另一個 RTT 用於請求和接收一個物件。在採用持續連線的情況下，伺服器在傳送響應後保持該 TCP 連線開啟。在相同的客戶與伺服器之間的後續請求和響應報文能夠通過相同的連線進行傳送 #### HTTP報文格式 1. **請求報文** ``` GET /somedir/page.html HTTP/l.l Host: www.someschool.edu Connection: close User-agent: Mozilla/5.0 Accept-language: fr ``` 我們看到該報文由5行組成，每行由一個回車和換行符結束。最後一行後再附加一個回車換行。雖然這個特定的報文僅有5行，但一個請求報文能夠具有更多的行或者至少為一行。HTTP 請求報文的第一行叫做請求行 (request line) ，其後繼的行叫做首部行( headerline)。請求行有3個欄位:方法欄位、URL欄位和HTTP版本欄位。方法宇段可以取幾種不同的值，包括 GET、POST、HEAD、PUT和DELETE。絕大部分的 HTTP 請求報文使用GET方法，當瀏覽器請求一個物件時，使用 GET 方法，在 URL 欄位帶有請求物件的標識。在本例中，該瀏覽器正在請求物件/somedirl page. html 其版本欄位是自解釋的;在本例中，瀏覽器實現的是 HTTP/ l. 版本。
現在我們看看本例的首部行：首部行 Host: www. someschool. edu 指明瞭物件所在的主機。你也許認為該首部行是不必要的，因為在該主機中已經有一條 TCP 連線存在了，但是，該首部行提供的資訊是 Web 代理快取記憶體所要求的，通過包含 Connection: close 首部行，該瀏覽器告訴伺服器不希望麻煩地使用持續連線，它要求伺服器在傳送完被請求的物件後就關閉這條連線。User- agent: 首部行用來指明使用者代理，即向伺服器傳送請求的瀏覽器的型別。這裡瀏覽器型別是 Mozilla/5. 0，即Firefox 瀏覽器，這個首部行是有用的，因為伺服器可以有效地為不同型別的使用者代理，實際傳送相同物件的不同版本 (每個版本都由相同的URL定址)。最後Accept-language：首部行表示使用者想得到該物件的法語版本(如果伺服器中有這樣的物件的話)；否則，伺服器應當傳送它的預設版本 Accept -language：首部行僅是 HTTP 中可用的眾多內容協商首部之一。  HEAD方法類似於GET方法，當伺服器收到使用HEAD方法的請求時，將會用一個HTTP報文進行響應，但是並不返回請求物件，應用程式開發者常用HEAD方法進行除錯，跟蹤PUT方法常與Web發行工具聯合使用，它允許使用者上傳物件到指定的 Web 伺服器上指定的路徑(目錄)。PUT方法也被那些需要向 Web 伺服器上傳物件的應用程式使用。DELETE 方法允許使用者或者應用程式刪除 Web 伺服器上的物件 2. **HTTP響應報文** 下面我們提供了一條典型的HTTP響應報文 該響應報文可以是對剛剛討論的例子中請求報文的響應： ``` HTTP/ 1. 1 200 OK Connection: close Date: Tue , 09 Aug 2011 15:44:04 GMT Server: Apache/2.2.3 (CentOS) Last-Modified: Tue , 09 Aug 2011 15:11:03 GMT Content-Length: 6821 Content-Type: text/html (data data data data data ...) ``` 我們仔細看一下這個響應報文 它有三個部分：一個初始狀態行 (sLatus line) ，6個首部行 (header 1ine) ，然後是實體體 (enLity body) 實體體部分是報文的主要部分，即它包含了所請求的物件本身(表示為 dala dala data data ...）。 狀態行有3個欄位:協議版本欄位、狀態碼和相應狀態資訊。在這個例子中，狀態行指示伺服器正在使用 HTTP/l.1，並且一切正常(即伺服器已經找到並正在傳送所請求的物件)。
我們現在來看看首部行。伺服器用 Connection: close 首部行告訴客戶，傳送完報文後將關閉該 TCP 連線。Date: 首部行指示伺服器產生併發送該響應報文的日期和時間。值得一提的是，這個時間不是指物件建立或者最後修改的時間；而是伺服器從它的檔案系統中檢索到該物件，插入到響應報文，併發送該響應報文的時間。Server: 首部行指示該報文是由一臺 Apache Web 伺服器產生的，它類似於 HTTP 請求報文中的 User- agent 首部行。Last- Modified: 首部行指示了物件建立或者最後修改的日期和時間。Lasl-Modified: 首部行對既可能在本地客戶也可能在網路快取伺服器上的物件快取來說非常重要。下面將會介紹快取伺服器(也叫代理伺服器)。Content- Length: 首部行指示了被髮送物件中的位元組數；Conlent- Type: 首部行指示了實體體中的物件是 HTML 文字 (該物件型別應該正式地由 Conlent- Type: 首部行而不是用副檔名來指示。  #### Web 快取 Web快取器 (Web cache)也叫代理伺服器 (proxy server)，它是能夠代表初始 Web 伺服器來滿足 HTTP 請求的網路實體。Web 快取器有自己的磁碟儲存空間，並在儲存空間中儲存最近請求過的物件的副本 如圖 2-11 所示，可以配置使用者的瀏覽器，使得使用者的所有 HTTP請求首先指向 Web 快取器。一旦某瀏覽器被配置，每個對某物件的瀏覽器請求首先被定向到該 Web 快取器。舉例來說，假設瀏覽器正在請求物件 http://www.someschool. edu/ campus.giI.將會發生如下情況:  * 瀏覽器建立一個到Web快取器的TCP連線，並向 Web 快取器中的物件傳送一個HTTP請求 * Web 快取器進行檢查，看看本地是否儲存了該物件副本 如果有， Web 快取器就向客戶瀏覽器用 HTTP 響應報文返回該物件 * 如果 Web 快取器中沒有該物件，它就開啟一個與該物件的初始伺服器(如www. someschool. edu)，TCP 連線 Web 快取器則在這個快取器到伺服器的TCP連線上傳送一個對該物件的 HTTP 請求，在收到該請求後，初始伺服器向該 Web快取器傳送具有該物件的 HTTP響應 * 當 Web 快取器接收到該物件時，它在本地儲存空間儲存一份副本，並向客戶的瀏覽器用盯TP 響應報文傳送該副本(通過現有的客戶瀏覽器和 Web 快取器之間的TCP連線) #### DHCP協議 DHCP(Dynamic Host Configuration Protocol: 動態主機設定協議，DHCP是一個區域網協議，DHCP是應用UDP協議的應用層協議。使用UDP協議工作，主要有兩個用途：給內部網路或網路服務供應商自動分配IP地址，給使用者或者內部網路管理員作為對所有計算機作中央管理的手段。 對於一個 臨時裝置，是如何知道自己的IP地址的？ DHCP伺服器監聽預設埠：67，主機使用UDP協議廣播DHCP發現報文，DHCP伺服器發出DHCP提供報文，主機向DHCP伺服器發出DHCP請求報文，DHCP伺服器迴應並提供IP地址。 #### HTTPS 由於HTTP是明文傳輸的，則HTTPS(Secure)是安全的HTTP協議，預設埠為443，http(s): //<主機>:<埠>/<路徑>   * A、B是擁有一定數學關係的一組祕鑰 + 私鑰：私鑰自己使用，不對外公開 + 公鑰：公鑰給大家使用，對外公開  使用公鑰加密，使用私鑰解密。 * 數字證書是可信任組織頒發給特定物件的認證
* SSL(Secure Sockets Layer: 安全套接層)
+ 資料安全和資料完整
+ 對傳輸層資料進行加密後傳輸
HTTPS 原理
1. 客戶端將它所支援的演算法列表和一個用作產生金鑰的隨機數傳送給伺服器 ；
2. 伺服器從演算法列表中選擇一種加密演算法，並將它和一份包含伺服器公用金鑰的證書傳送給客戶端；該證書還包含了用於認證目的的伺服器標識，伺服器同時還提供了一個用作產生金鑰的隨機數；
3. 客戶端對伺服器的證書進行驗證（有關驗證證書，可以參考數字簽名），並抽取伺服器的公用金鑰；然後，再產生一個稱作 pre_master_secret 的隨機密碼串，並使用伺服器的公用金鑰對其進行加密（參考非對稱加 / 解密），並將加密後的資訊傳送給伺服器 ；
4. 客戶端與伺服器端根據 pre_master_secret 以及客戶端與伺服器的隨機數值獨立計算出加密和 MAC金鑰（參考 DH金鑰交換演算法）；
5. 客戶端將所有握手訊息的 MAC 值傳送給伺服器；
6. 伺服器將所有握手訊息的 MAC 值傳送給客戶端
### 檔案傳輸協議：FTP
在一個典型的FTP會話中，使用者坐在一臺主機(本地主機)前面，向一臺遠端主機傳輸(或接收來自遠端主機的)檔案 為使使用者能訪問它的遠端賬戶，使用者必須提供一個使用者標識和口令 在提供了這種授權資訊後，使用者就能從本地檔案系統向遠端主機檔案系統傳送檔案，反之亦然 如圖 2-14 所示，使用者通過一個FTP使用者代理與FTP互動。該使用者首先提供遠端主機的主機名，使本地主機的FTP客戶程序建立一個到遠端主機FTP伺服器程序的 TCP 連線。該使用者接著提供使用者標識和口令，作為 FTP 命令的一部分在該 TCP連線上傳送。一旦該伺服器向該使用者授權，使用者可以將存放在本地檔案系統中的一個或者多個檔案複製到遠端檔案系統(反之亦然)。
HTTP和FTP 都是檔案傳輸協議，並且有很多共同的特點，例如，它們都執行在 TCP上，然而，這兩個應用層協議也有一些重要的區別 其中最顯著的就是FTP 使用了兩個並行的 TCP 連線來傳輸檔案，一個是控制連線 (control connection) ，一個是資料連線( data connection) 。控制連線用於在兩主機之間傳輸控制資訊，如使用者標識、口令、改變遠端目錄的命令以及"存放 (put) "和"獲取 (get)"檔案的命令。資料連線用於實際傳送一個檔案，因為FTP協議使用一個獨立的控制連線，所以我們也稱FTP的控制資訊是帶外(out-of-band)傳送的。如你所知，HTTP協議是在傳輸檔案的同一個 TCP 連線中傳送請求和響應首部行的 因此，HTTP也可以說是帶內 (in-band) 傳送控制資訊的。FTP協議的控制連線和資料連線如圖二 15 所示：
當用戶主機與遠端主機開始一個FTP會話時，FTP的客戶(使用者)端首先在伺服器21號埠與伺服器(遠端主機)端發起一個用於控制的 TCP 連線。FTP的客戶端也通過該控制連線傳送使用者的標識和口令，傳送改變遠端目錄的命令，當FTP的伺服器端從該連線上收到一個檔案傳輸的命令後(無論是向還是來自遠端主機) ，就發起一個到客戶端的 TCP 資料連線 FTP 在該資料連線上準確地傳送一個檔案，然後關閉該連線。在同一個會話期間，如果使用者還需要傳輸另一個檔案，FTP則開啟另一個數據連線，因而對FTP傳輸而言，控制連線貫穿了整個使用者會話期間，但是對會話中的每一次檔案傳輸都需要建立一個新的資料連線(即資料連線是非持續的)。
FTP伺服器必須在整個會話期間保留使用者的狀態(state) 特別是，伺服器必須把特定的使用者賬戶與控制連線聯絡起來，隨著使用者在遠端目錄樹上徘徊，伺服器必須追蹤使用者在遠端目錄樹上的當前位置，對每個進行中的使用者會話的狀態資訊進行追蹤，大大限制了FTP同時維持的會話總數。而另一方面，前面講過 HTTP 是無狀態的，即它不必對任何使用者狀態進行追蹤。 ### 因特網中的電子郵件 圖2-16 給出了因特網電子郵件系統的總體情況，從該圖中我們可以看到它有3個主要組成部分: 使用者代理( user agenl) 、郵件伺服器 (mail server) 簡單郵件傳輸協議(Simple Mai] Transfer Prolocol , SMTP) 。  SMTP 是因特網電子郵件中主要的應用層協議，它使用 TCP 可靠資料傳輸服務，從傳送方的郵件伺服器向接收方的郵件伺服器傳送郵件，像大多數應用層協議一樣， SMTP有兩個部分:執行在傳送方郵件伺服器的客戶端和執行在接收方郵件伺服器的伺服器端，每臺郵件伺服器上既執行 SMTP 的客戶端也執行 SMTP 的伺服器端 。當一個郵件伺服器向其他郵件伺服器傳送郵件時，它就表現為 SMTP 的客戶;當郵件伺服器從其他郵件伺服器上接收郵件時，它就表現為SMTP的伺服器。目前有一些流行的郵件訪問協議，包括第三版的郵局協議 (POSl OfficeProtocol-Version 3 , POP3)、因特網郵件訪問協議 (Intemet Mail Access Protocol , IMAP)以及 HTTP。
總結：應用層為作業系統或網路應用程式提供訪問網路服務的介面。資料傳輸基本單位為報文；包含的主要協議：FTP（檔案傳送協議）、Telnet（遠端登入協議）、DNS（域名解析協議）、SMTP（郵件傳送協議），POP3協議（郵局協議），HTTP協議（Hyper Text Transfer Protoc
**注意：**伺服器向客戶傳送被請求的檔案，而不儲存任何關於該客戶的狀態資訊，假如某個特定的客戶在短短的幾秒鐘內兩次請求同一個物件，伺服器並不會因為剛剛為該客戶提供了該物件就不再做出反應，而是重新發送該物件，就像伺服器已經完全忘記不久之前所做過的事一樣，因為 HTTP 伺服器並不儲存關於客戶的任何資訊，所以我們說HTTP是一個無狀態協議 (stateless protocol) #### 非持續連線和持續連線 在許多因特網應用程式中，客戶和伺服器在一個相當長的時間範圍內通訊，其中客戶發出一系列請求並且伺服器對每個請求進行響應 依據應用程式以及該應用程式的使用方式，這一系列請求可以以規則的間隔週期性地或者間斷性地一個接一個發出。當這種客戶-伺服器的互動是經TCP進行的，應用程式的研製者就需要做一個重要決定，即每個請求/響應對是經一個單獨的 TCP 連線傳送，還是所有的請求及其響應經相同的TCP連線傳送呢?採用前一種方法，該應用程式被稱為使用非持續連線( non- persistent connection) ;採用後一種方法，該應用程式被稱為使用持續連線( persistent connection)。儘管 HTTP在其預設方式下使用持續連線， HTTP 客戶和伺服器也能配置成使用非持續連線。
非持續連線有一些缺點：首先，必須為每一個請求的物件建立和維護一個全新的連線。對於每個這樣的連線，在客戶和伺服器巾都要分配 TCP 的緩衝區和保持 TCP 變數。這給 Web 伺服器帶來了嚴重的負擔，因為一臺 Web 伺服器可能同時服務於數以百計不同的客戶的請求。第二，每一個物件經受兩倍 RTT 的交付時延，即一個RTT 用於建立 TCP ，另一個 RTT 用於請求和接收一個物件。在採用持續連線的情況下，伺服器在傳送響應後保持該 TCP 連線開啟。在相同的客戶與伺服器之間的後續請求和響應報文能夠通過相同的連線進行傳送 #### HTTP報文格式 1. **請求報文** ``` GET /somedir/page.html HTTP/l.l Host: www.someschool.edu Connection: close User-agent: Mozilla/5.0 Accept-language: fr ``` 我們看到該報文由5行組成，每行由一個回車和換行符結束。最後一行後再附加一個回車換行。雖然這個特定的報文僅有5行，但一個請求報文能夠具有更多的行或者至少為一行。HTTP 請求報文的第一行叫做請求行 (request line) ，其後繼的行叫做首部行( headerline)。請求行有3個欄位:方法欄位、URL欄位和HTTP版本欄位。方法宇段可以取幾種不同的值，包括 GET、POST、HEAD、PUT和DELETE。絕大部分的 HTTP 請求報文使用GET方法，當瀏覽器請求一個物件時，使用 GET 方法，在 URL 欄位帶有請求物件的標識。在本例中，該瀏覽器正在請求物件/somedirl page. html 其版本欄位是自解釋的;在本例中，瀏覽器實現的是 HTTP/ l. 版本。
現在我們看看本例的首部行：首部行 Host: www. someschool. edu 指明瞭物件所在的主機。你也許認為該首部行是不必要的，因為在該主機中已經有一條 TCP 連線存在了，但是，該首部行提供的資訊是 Web 代理快取記憶體所要求的，通過包含 Connection: close 首部行，該瀏覽器告訴伺服器不希望麻煩地使用持續連線，它要求伺服器在傳送完被請求的物件後就關閉這條連線。User- agent: 首部行用來指明使用者代理，即向伺服器傳送請求的瀏覽器的型別。這裡瀏覽器型別是 Mozilla/5. 0，即Firefox 瀏覽器，這個首部行是有用的，因為伺服器可以有效地為不同型別的使用者代理，實際傳送相同物件的不同版本 (每個版本都由相同的URL定址)。最後Accept-language：首部行表示使用者想得到該物件的法語版本(如果伺服器中有這樣的物件的話)；否則，伺服器應當傳送它的預設版本 Accept -language：首部行僅是 HTTP 中可用的眾多內容協商首部之一。  HEAD方法類似於GET方法，當伺服器收到使用HEAD方法的請求時，將會用一個HTTP報文進行響應，但是並不返回請求物件，應用程式開發者常用HEAD方法進行除錯，跟蹤PUT方法常與Web發行工具聯合使用，它允許使用者上傳物件到指定的 Web 伺服器上指定的路徑(目錄)。PUT方法也被那些需要向 Web 伺服器上傳物件的應用程式使用。DELETE 方法允許使用者或者應用程式刪除 Web 伺服器上的物件 2. **HTTP響應報文** 下面我們提供了一條典型的HTTP響應報文 該響應報文可以是對剛剛討論的例子中請求報文的響應： ``` HTTP/ 1. 1 200 OK Connection: close Date: Tue , 09 Aug 2011 15:44:04 GMT Server: Apache/2.2.3 (CentOS) Last-Modified: Tue , 09 Aug 2011 15:11:03 GMT Content-Length: 6821 Content-Type: text/html (data data data data data ...) ``` 我們仔細看一下這個響應報文 它有三個部分：一個初始狀態行 (sLatus line) ，6個首部行 (header 1ine) ，然後是實體體 (enLity body) 實體體部分是報文的主要部分，即它包含了所請求的物件本身(表示為 dala dala data data ...）。 狀態行有3個欄位:協議版本欄位、狀態碼和相應狀態資訊。在這個例子中，狀態行指示伺服器正在使用 HTTP/l.1，並且一切正常(即伺服器已經找到並正在傳送所請求的物件)。
我們現在來看看首部行。伺服器用 Connection: close 首部行告訴客戶，傳送完報文後將關閉該 TCP 連線。Date: 首部行指示伺服器產生併發送該響應報文的日期和時間。值得一提的是，這個時間不是指物件建立或者最後修改的時間；而是伺服器從它的檔案系統中檢索到該物件，插入到響應報文，併發送該響應報文的時間。Server: 首部行指示該報文是由一臺 Apache Web 伺服器產生的，它類似於 HTTP 請求報文中的 User- agent 首部行。Last- Modified: 首部行指示了物件建立或者最後修改的日期和時間。Lasl-Modified: 首部行對既可能在本地客戶也可能在網路快取伺服器上的物件快取來說非常重要。下面將會介紹快取伺服器(也叫代理伺服器)。Content- Length: 首部行指示了被髮送物件中的位元組數；Conlent- Type: 首部行指示了實體體中的物件是 HTML 文字 (該物件型別應該正式地由 Conlent- Type: 首部行而不是用副檔名來指示。  #### Web 快取 Web快取器 (Web cache)也叫代理伺服器 (proxy server)，它是能夠代表初始 Web 伺服器來滿足 HTTP 請求的網路實體。Web 快取器有自己的磁碟儲存空間，並在儲存空間中儲存最近請求過的物件的副本 如圖 2-11 所示，可以配置使用者的瀏覽器，使得使用者的所有 HTTP請求首先指向 Web 快取器。一旦某瀏覽器被配置，每個對某物件的瀏覽器請求首先被定向到該 Web 快取器。舉例來說，假設瀏覽器正在請求物件 http://www.someschool. edu/ campus.giI.將會發生如下情況:  * 瀏覽器建立一個到Web快取器的TCP連線，並向 Web 快取器中的物件傳送一個HTTP請求 * Web 快取器進行檢查，看看本地是否儲存了該物件副本 如果有， Web 快取器就向客戶瀏覽器用 HTTP 響應報文返回該物件 * 如果 Web 快取器中沒有該物件，它就開啟一個與該物件的初始伺服器(如www. someschool. edu)，TCP 連線 Web 快取器則在這個快取器到伺服器的TCP連線上傳送一個對該物件的 HTTP 請求，在收到該請求後，初始伺服器向該 Web快取器傳送具有該物件的 HTTP響應 * 當 Web 快取器接收到該物件時，它在本地儲存空間儲存一份副本，並向客戶的瀏覽器用盯TP 響應報文傳送該副本(通過現有的客戶瀏覽器和 Web 快取器之間的TCP連線) #### DHCP協議 DHCP(Dynamic Host Configuration Protocol: 動態主機設定協議，DHCP是一個區域網協議，DHCP是應用UDP協議的應用層協議。使用UDP協議工作，主要有兩個用途：給內部網路或網路服務供應商自動分配IP地址，給使用者或者內部網路管理員作為對所有計算機作中央管理的手段。 對於一個 臨時裝置，是如何知道自己的IP地址的？ DHCP伺服器監聽預設埠：67，主機使用UDP協議廣播DHCP發現報文，DHCP伺服器發出DHCP提供報文，主機向DHCP伺服器發出DHCP請求報文，DHCP伺服器迴應並提供IP地址。 #### HTTPS 由於HTTP是明文傳輸的，則HTTPS(Secure)是安全的HTTP協議，預設埠為443，http(s): //<主機>:<埠>/<路徑>   * A、B是擁有一定數學關係的一組祕鑰 + 私鑰：私鑰自己使用，不對外公開 + 公鑰：公鑰給大家使用，對外公開  使用公鑰加密，使用私鑰解密。 * 數字證書是可信任組織頒發給特定物件的認證
| 證書格式、版本號 |
| 證書序列號 |
| 簽名演算法 |
| 有效期 |
| 物件名稱 |
| 物件公開祕鑰 |
| ... |
FTP伺服器必須在整個會話期間保留使用者的狀態(state) 特別是，伺服器必須把特定的使用者賬戶與控制連線聯絡起來，隨著使用者在遠端目錄樹上徘徊，伺服器必須追蹤使用者在遠端目錄樹上的當前位置，對每個進行中的使用者會話的狀態資訊進行追蹤，大大限制了FTP同時維持的會話總數。而另一方面，前面講過 HTTP 是無狀態的，即它不必對任何使用者狀態進行追蹤。 ### 因特網中的電子郵件 圖2-16 給出了因特網電子郵件系統的總體情況，從該圖中我們可以看到它有3個主要組成部分: 使用者代理( user agenl) 、郵件伺服器 (mail server) 簡單郵件傳輸協議(Simple Mai] Transfer Prolocol , SMTP) 。  SMTP 是因特網電子郵件中主要的應用層協議，它使用 TCP 可靠資料傳輸服務，從傳送方的郵件伺服器向接收方的郵件伺服器傳送郵件，像大多數應用層協議一樣， SMTP有兩個部分:執行在傳送方郵件伺服器的客戶端和執行在接收方郵件伺服器的伺服器端，每臺郵件伺服器上既執行 SMTP 的客戶端也執行 SMTP 的伺服器端 。當一個郵件伺服器向其他郵件伺服器傳送郵件時，它就表現為 SMTP 的客戶;當郵件伺服器從其他郵件伺服器上接收郵件時，它就表現為SMTP的伺服器。目前有一些流行的郵件訪問協議，包括第三版的郵局協議 (POSl OfficeProtocol-Version 3 , POP3)、因特網郵件訪問協議 (Intemet Mail Access Protocol , IMAP)以及 HTTP。
總結：應用層為作業系統或網路應用程式提供訪問網路服務的介面。資料傳輸基本單位為報文；包含的主要協議：FTP（檔案傳送協議）、Telnet（遠端登入協議）、DNS（域名解析協議）、SMTP（郵件傳送協議），POP3協議（郵局協議），HTTP協議（Hyper Text Transfer Protoc