【計算機網路學習筆記】一
第二章 應用層
目錄
2.1應用層協議原理
2.1.1 網路應用程式體系結構
- 客戶-伺服器體系結構（client-server architecture）
客戶相互之間不直接通訊；
伺服器具有固定的、周知的地址（IP地址），因而伺服器總是開啟的；
配備大量主機的資料中心常被用於建立強大的虛擬伺服器；
- P2P體系結構（P2P architecture）
應用程式在間斷連線的主機對之間使用直接通訊；
某些應用具有混合的體系結構，結合了客戶-伺服器和P2P的元素；
自拓展性（self-scalability）
2.1.2 程序通訊
在兩個不同端系統上的程序，通過跨越計算機網路交換報文
（message）而相互通訊。
1）客戶和伺服器程序
在給定的一對程序之間的通訊會話場景中，發起通訊（即在該會話開始時發起與其他程序的聯絡）的程序被標識為客戶（client），在會話開始時等待聯絡的程序標識為伺服器（server）。
對Web而言，瀏覽器→客戶程序，Web伺服器→伺服器程序；
對P2P檔案共享，下載檔案的對等方→客戶，上載檔案的對等方→伺服器。
2）程序與計算機網路之間的介面
程序通過一個成為套接字（socket）的軟體介面向網路傳送報文和接收報文。套接字是同一臺主機內應用層與運輸層之間的介面，亦稱應用程式和網路之間的應用程式程式設計介面（Application Programming Interface，API）。
3）程序定址
為了標識接收程序，需要定義兩種資訊：
-
主機的地址（IP地址 IP adress）；
-
定義在目的主機中的接收程序的識別符號（埠號 port number）。
2.1.3 可供應用程式使用的運輸服務
- 可靠資料傳輸
如果一個協議提供了確保資料交付支付服務，就認為提供了可靠資料傳輸（reliable data transfer）；
當一個運輸層協議不提供可靠資料傳輸時，由傳送程序傳送的某些資料可能不能夠到達接收程序，這可能能被容忍丟失的應用（loss-tolerant application）所接收。
- 吞吐量
具有吞吐量要求的應用程式被稱為寬頻敏感的應用（bandwidth-sensitive application）；
彈性應用（elastic application）能夠根據情況或多或少的地利用可供使用的吞吐量。
- 定時
這種服務對互動式實時應用程式由吸引力（電話、網路遊戲）。
- 安全性
2.1.4 因特網體提供的運輸服務
1）TCP服務
-
面向連線的服務
-
可靠的資料傳送服務
【TCP安全-SSL】
無論TCP還是UDP都沒有提供任何加密機制；
TCP的加強版：安全套接字層（Secure Socket Layer，SSL）。
2）UDP服務
-
無連線
-
不可靠的資料傳送服務
3）因特網運輸協議所不提供的服務
今天的因特網通常能夠為時間敏感應用提供滿意的服務，但它不能提供任何定時或寬頻保證。
2.1.5 應用層協議
應用層協議（application-layer protocol）定義了執行在不同端系統上的應用程式程序如何相互傳遞報文。
特別定義了：
-
交換的報文型別，例如請求報文和響應報文；
-
各種報文型別的語法；
-
欄位的語義；
-
一個程序何時以及如何傳送報文，對報文進行響應的規則。
2.1.6 本書涉及的網路應用
Web、檔案傳輸、電子郵件、目錄服務和P2P。
2.2 Web和HTTP
2.2.1 HTTP概況
Web的應用層協議是超文字傳輸協議（HyperText Transfer Protocol，HTTP），它是Web的核心，在【RFC 1945】和【RFC 2616】中進行了定義。
某些Web術語：
Web頁面（Web page）（也叫文件，由物件組成）；
物件（object）只是一個檔案，諸如HTML檔案、JPEG圖形、Java小程式等等；
HTML 基本檔案（base HTML file）：通過物件的URL地址引用頁面中的其他物件；
Web瀏覽器（Web browser）實現了HTTP的客戶端；
Web伺服器（Web server）實現了HTTP的服務端，用於儲存Web物件，每個物件由URL定址。
HTTP伺服器並不儲存關於客戶的任何資訊，所以我們說HTTP是一個無狀態協議（statusless protocol）。
2.2.2 非持續連線和持續連線
每個請求/響應對是經一個單獨的TCP連線傳送，還是所有的請求及其響應經相同的TCP連線傳送呢？採用前者的應用程式被稱為使用非連續連線（non-persistent connection）；採用後者則被稱為使用持續連線（persistent connection）。
1）採用非持續連線的HTTP
往返時間（Round-Trip Time，RTT）：一個短分組從客戶到伺服器然後再返回客戶所花費的時間。
“三次握手”：客戶向伺服器傳送一個小TCP報文段，伺服器用一個小TCP報告文段做出確認和響應，最後，客戶向伺服器返回確認。
總的響應時間：兩個RRT加上伺服器傳輸HTML檔案的時間。
2）採用持續連線的HTTP
在採用持續連線的情況下，伺服器在傳送響應後保持該TCP連線開啟，在相同的客戶與伺服器之間的後續請求和響應報文能夠通過相同的連線進行傳送。特別是，一個完整的Web頁面（上例中的HTML基本檔案加上10個圖形）可以用單個持續TCP連線進行傳送。
HTTP的預設模式是使用帶流水線的持續連線。
2.2.3 HTTP 報文格式
1.HTTP 請求報文
一個請求報文至少為一行，第一行為請求行（request line）其後繼的行叫做首部行（header line）；
請求行有三個欄位：方法欄位、URL欄位和HTTP版本欄位。
方法欄位：GET、POST、HEAD、PUT、DELETE。（絕大部分HTTP請求使用GET方法）
2.HTTP響應報文
三個部分：狀態行（status line）、首部行（header line）、實體體（entity body）【包含了所請求的物件本身】
狀態行有三個欄位：協議版本欄位、狀態碼和相應狀態資訊。
（Date：首部行指示伺服器產生併發送該相應報文的日期和時間。注意，這個時間不是指物件建立或者最後修改的時間，而是伺服器從它的檔案系統中檢索到該物件，插入到響應報文，併發送該響應報文的時間。）
常見的狀態碼和相關的短語：
- 200 OK：請求成功，資訊在返回的響應報文中；
- 301 Moved Permanently：請求的物件已經被永久轉移了，客戶軟體將自動獲取新的URL；
- 400 Bad Request：一個通用差錯程式碼，指示該請求不能被伺服器理解；
- 404 Not Found：被請求的文件不在伺服器上；
- 505 HTTP Version Not Supported：伺服器不支援請求報文使用的HTTP協議版本。
2.2.4 使用者和伺服器的互動：cookie
cookie技術的四個元件：
- 在HTTP響應報文中的一個cookie首部行；
- 在HTTP請求報文中的一個cookie首部行；
- 在使用者端系統中保留有一個cookie檔案，並由使用者的瀏覽器進行管理；
- 位於Web站點的一個後端資料庫。
2.2.5 Web快取
Web快取器（Web cache）也叫代理伺服器（proxy server），它是能夠代表初始Web伺服器來滿足HTTP請求的網路實體。
內容分發網路（Content Distribution Network，CDN）。
2.2.6 條件 GET 方法
條件 GET 方法（conditional GET），如果：
- 請求報文使用 GET 方法；
- 請求報文中包含一個 “If-Modified-Since:” 首部行。
則該 HTTP 請求報文就是一個條件 GET 請求報文。
2.3 檔案傳輸協議：FTP
HTTP 和 FTP 都是檔案傳輸協議，並且有很多共同的特點，例如，它們都執行在 TCP 上。區別：FTP 使用了兩個並行的 TCP 連線來傳輸檔案，一個是控制連線（control connection），一個是資料連線（data connection）。
FTP 命令（4個大寫字母 ASCII 字元）：
- USER username：用於向伺服器傳送使用者標識；
- PASS password：用於向伺服器傳送使用者口令；
- LIST：用於請求伺服器回送當前遠端目錄中的所有檔案列表；
- RETR filename：用於從遠端主機當前目錄檢索（即 get）檔案；
- STOR filename：用於在遠端主機的當前目錄上存放（即 put）檔案。
典型的回答：
- 331 Username OK，Password required（使用者名稱 OK，需要口令）；
- 125 Data connection already open；transfer starting（資料連線已開啟，開始傳送）；
- 425 Can't open data connection（無法開啟資料連線）；
- 452 Error writing file（寫檔案差錯）。
2.4 因特網中的電子郵件
2.7 TCP套接字程式設計
2.7.1 UDP 套接字程式設計
應用程式演示：
1）客戶從其鍵盤讀取一行字元並將資料向伺服器傳送；
2）伺服器接收該資料並將這些字元轉換成大寫；
3）伺服器將修改的資料傳送給客戶；
4）客戶接收修改的資料並在其監視器上將該行顯示出來。
2.7.2 TCP 套接字程式設計