1、Application
（1）網絡應用的常見架構
網絡應用一般採用兩種架構模式，一種是 CS (Client/Server) 架構，一種是 P2P (Peer-To-Peer) 架構
對於 CS 架構 而言，網絡中的每個節點是不對稱的，具體而言可以分爲服務端和客戶端兩類
簡單來說，服務端擁有資源，可以爲客戶端提供服務，而客戶端需要資源，需要向服務端申請服務
對於 P2P 架構 而言，網絡中的每個節點都是對稱的，也可以說每個節點都是服務端和客戶端
因爲每個節點都擁有資源，每個節點都可以提供服務，同時每個節點也都需要資源，每個節點也都需要申請服務
（2）網絡應用的通信方式
不同應用之間的通信，其實就是不同進程之間的通信，如果兩個進程在同一主機上，那麼通信過程由操作系統定義
假如兩個進程不在同一主機上，那麼它們之間的通信需要通過網絡，這時通信過程由一系列層次化的網絡協議定義
而站在 應用層 這一層次上，我們只需要定義好消息的內容，以及指定好把消息發給誰（目標進程）即可
一個進程可以通過套接字將消息交給底層，然後通過底層提供的服務，另一個進程可以通過套接字從底層得到消息
至於底層是如何把消息 (message) 從一個套接字傳到另一個套接字，不是應用層需要關心的內容
（3）如何定位進程
一個運行在網絡上的進程怎麼定位呢？我們可以通過 IP 地址定位網絡中的主機，然後通過端口定位主機上的進程
一些常見的應用層協議會帶有 默認的 端口號：
| 協議 | 端口 | 用途 |
|---|---|---|
| HTTP | 80 | 網頁傳輸 |
| FTP | 21 | 文件傳輸 |
| SMTP | 25 | 郵件發送 |
| POP3 | 110 | 郵件接收 |
| IMAP | 143 | 郵件接收 |
| Telnet | 23 | 遠程登陸 |
2、Web and HTTP
（1）通信過程
對於網頁 (Web) 應用，通常使用 HTTP (Hypertext Transfer Protocol) 控制通信規則，其依賴於 TCP 提供的服務
根據標準的不同，HTTP 協議可以分爲 HTTP/1.0 和 HTTP/1.1，其中 HTTP/1.1 由 HTTP/1.0 改進而來
在 HTTP/1.0 中，使用的是 非持續性連接 (Non-persistent Connection)，對於 CS 架構通信過程如下：
- 客戶端請求與服務端建立 TCP 連接
- 服務端同意後，正式建立 TCP 連接
- 客戶端發送請求，在請求信息中指定需要獲取的資源
- 服務端返回響應，在響應信息中包含資源實體，之後關閉 TCP 連接
- 客戶端收到響應，解析拿到資源實體
- 如果發現資源實體還要引用其它資源，那麼重複以上步驟
而在 HTTP/1.1 中，使用的是 持續性連接 (Persistent Connection)，對於 CS 架構通信過程如下：
- 客戶端請求與服務端建立 TCP 連接
- 服務端同意後，正式建立 TCP 連接
- 客戶端發送請求，在請求信息中指定需要獲取的資源
- 服務端返回響應，在響應信息中包含資源實體，但是不會關閉 TCP 連接
- 客戶端收到響應，解析拿到資源實體
- 如果發現資源實體還要引用其它資源，那麼重複步驟 3~ 5
假設我們需要傳輸一個 HTML 文件，在文件中引用十個 JEPG 圖片，計算傳輸時間？
- 若使用非持續性連接：T = (2RTT + Ttransfer) + (2RTT + Ttransfer) * 10
- 如果使用持續性連接：T = (2RTT + Ttransfer) + (RTT + Ttransfer) * 10
（2）消息格式
HTTP 採用 請求/響應 格式，客戶端提交請求 (Request)，服務端返回響應 (Response)
請求消息的格式請看下面的圖片，其中常見的 請求方法 如下：
- GET：請求指定資源，返回資源實體
- POST：向指定資源提交數據，可能導致新資源的建立或舊資源的修改
- HEAD：類似 GET 請求，只是返回的響應沒有具體的內容，常常用於獲取報頭
- DELETE：刪除指定的資源
- PUT：使用提交的數據取代指定的資源
- TRACE：返回服務端收到的請求，常常用於測試
- OPTIONS：返回服務端針對特定資源所支持的請求方法，也能用於查看服務端的性能
響應消息的格式請看下面的圖片，其中常見的 狀態代碼和狀態信息 如下：
- 1**：信息，服務端收到請求，要求客戶端繼續執行操作
- 2**：成功
- 200：OK，服務器已成功處理請求，並返回請求的資源
- 3**：重定向
- 301：Moved Permanently，永久重定向，請求的資源永久移動到新位置
- 302： Found，臨時重定向，請求的資源暫時移動到新位置
- 4**：客戶端錯誤
- 400：Bad Request，請求報文存在語法錯誤
- 403：Forbidden，對請求資源的訪問被服務器拒絕
- 404：Not Found，在服務器上沒有找到請求的資源
- 5**：服務端錯誤
- 500：Internal Server Error，服務器在執行請求時發生錯誤
- 502：Bad Gateway，作爲網關的服務器在執行請求時，從遠程服務器收到一個無效的響應
- 503：Service Unavailable，由於服務端超載或停機維護，服務器暫時無法處理客戶端的請求
（3）Cookies
由於 HTTP 協議是 無狀態的，因此服務器想要跟蹤用戶狀態，可以使用 Cookies 技術
Cookie 其實就是一個特殊的值，它由服務端創建和維護，併發送給客戶端
之後，客戶端在每次請求時帶上 Cookie，服務端通過 Cookie 就能判斷用戶狀態
（4）Caches
Caches 技術可以降低客戶端獲取響應的時間，也能減少服務端處理請求的壓力，可以說是一舉兩得
使用 Caches 其實就是建立一個或多個 代理服務器 (proxy server)，由代理服務器幫助響應客戶端的請求
客戶端直接發送請求到代理服務器，如果請求的資源在代理服務器上，那麼直接返回給客戶端
如果不在，那麼代理服務器先向服務器請求資源，得到資源後保存在本地，之後再返回給客戶端
簡單描述一下 HTTP 協議的發展過程？
HTTP/0.9【1991 年】
- 最簡單的版本，只能訪問 HTML 格式資源，沒有頭部，請求方法只有 GET
HTTP/1.0【1996 年】
- 增加 HTTP 版本號
- 增加狀態代碼和狀態信息
- 增加請求方法，包括 POST 和 HEAD
- 增加頭部，無論是請求或者是響應都要有頭部
- 在頭部中通過設置 Content-Type 支持傳輸其它類型的文件
HTTP/1.1【1997 年】
- 增加持久性連接，能讓 HTTP 請求複用 TCP 連接
- 支持流水線傳輸，允許在一個 TCP 連接中同時發送多個請求
- 增加請求方式，包括 DELETE、PUT、OPTIONS 等等
HTTP/2.0【2015 年】
- 二進制分幀：將傳輸的數據劃分爲更小的幀，並對它們採用二進制編碼
- 服務端推送：允許在客戶端沒有請求的情況下，主動給客戶端發送資源
- 壓縮頭部：多次請求的很多頭部其實是重複的，有必要對頭部進行處理
一是使用壓縮工具對頭部進行壓縮後再發送，二是對於重複的字段可以使用索引號來代替
3、File and FTP
（1）通信過程
對於文件 (File) 傳輸，通常使用 FTP (File Transfer Protocol) 控制通信規則，其依賴於 TCP 提供的服務
FTP 協議在通信時會建立兩個連接，分別爲 控制連接 (Control Connection) 和 數據連接 (Data Connection)
- 控制連接：用於傳輸命令，進行授權認證
- 數據連接：用於傳輸文件
對於 CS 架構通信過程如下：
- 客戶端與服務端建立控制連接
- 客戶端通過控制連接進行授權，發送命令
- 服務端收到文件傳輸命令之後，建立數據連接
- 服務端通過數據連接傳輸文件，當一個文件傳輸完成後，服務端關閉數據連接
- 如果還有其它文件傳輸，需要重新建立數據連接
（2）消息格式
FTP 採用 命令/響應 格式，客戶端發送的命令以及服務端返回的響應通過控制連接傳輸，它們都是 7 比特的 ASCII
客戶端發送 命令 (Command) 進行授權和請求資源，常用的命令如下：
USER username：向服務端發送賬號PASS password：向服務端發送密碼LIST：返回當前目錄的文件列表RETR filename：從服務端下載文件STOR filename：將文件上傳到服務端
服務端接收到命令後，發送 響應 (Response) 返回結果，一個響應包括狀態代碼和狀態信息，常見的響應如下：
311：賬號正確，要求輸入密碼125：已經建立數據連接，開始傳輸文件425：不能建立數據連接
4、Email and SMTP
（1）通信過程
對於郵件 (Mail) 傳輸，通常使用 SMTP (Simple Mail Transfer Protocol) 控制通信規則，其依賴於 TCP 提供的服務
郵件傳輸有兩個重要的組件，分別是 用戶代理 (User Agent) 和 郵件服務器 (Mail Server)
- 用戶代理：用於編輯、閱讀郵件
- 郵件服務器：用於發送、接收郵件
對於 CS 架構通信過程如下：
- 發送方通過自己的用戶代理編輯郵件
- 發送方的用戶代理髮送郵件到自己的郵件服務器
- 發送方的郵件服務器接收郵件，將郵件放在消息隊列 (Message Queue)，等待發送
- 發送方的郵件服務器發送郵件到接收方的郵件服務器
- 接收方的郵件服務器接收郵件，將郵件放在郵件箱子 (Mail Box)，等待閱讀
- 接收方通過自己的用戶代理閱讀郵件
（2）消息格式
最開始的時候，郵件只能傳輸文本，因此只用簡單的 ASCII 定義郵件格式
普通郵件格式 包括兩個部分，分爲頭部 (Header) 和主體 (Body)
後來，郵件還能傳輸多媒體資源，又定義了新的格式 MIME (Multiperpose Internet Mail Extension)
只需要在頭部添加新行，指定使用 MIME 郵件格式 即可
SMTP 同樣採用 命令/響應格式，對於客戶端發送的命令以及服務端返回的響應，它們都是 7 比特的 ASCII
客戶端發送 命令 (Command) 進行授權和請求資源，常用的命令如下：
HELO：建立連接AUTH LOGIN：身份認證MAIL FROM address：指定發送郵件的郵箱RCPT TO address：指定接收郵件的郵箱DATA：指定郵件正文QUIT：關閉連接
服務端接受到命令後，發送 響應 (Response) 返回結果，一個響應包括狀態代碼和狀態信息，常見的響應如下：
220：服務就緒250：要求的操作已完成354：開始輸入郵件正文，以.結束221： 服務關閉
（3）其它郵件協議
上面介紹過的 SMTP 是 郵件發送協議，下面要介紹的 POP3 和 IMAP 是 郵件接收協議
- POP3 (Post Office Protocol 3)：允許用戶從郵件服務器下載郵件
- IMAP (Internet Mail Access Protocol)：允許用戶直接在郵件服務器上管理郵件，包括移動、分類等等
5、DNS
DNS (Domain Name System) 的作用是 將域名解析爲 IP 地址
DNS 是一個 分佈式、層次化的數據庫，裏面儲存着域名與 IP 地址的映射關係，稱爲 資源記錄 (Resource Record)
資源記錄的格式如下：(name, value, type, ttl)，常見的資源記錄如下：
- A 記錄：type 爲 A，此時 name 表示域名，value 表示 IP 地址
- NS 記錄：type 爲 NS，此時 name 表示域名，value 表示負責解析 name 的域名服務器的域名
- SOA 記錄：type 爲 SOA，此時 name 表示域名，value 表示負責解析 name 的主域名服務器的域名
- CNAME 記錄：type 爲 CNAME，此時 name 表示別名，value 表示標準名稱
數據庫按照層級的不同可分爲四層：
- 根域名服務器 (Root DNS Server)：目前全球一共有 13 臺根域名服務器
- 頂級域名服務器 (Top-Level Domain DNS Server)：提供 com、org、net、edu 等頂級域名的解析服務
- 權威域名服務器 (Authoritative DNS Server)：爲特定的組織提供解析服務
- 本地域名服務器 (Local DNS Server)：嚴格來說不屬於其中一層，每個 ISP 都有一個本地域名服務器
DNS 也是一種 應用層協議，當請求域名解析服務時，通常使用 DNS 控制通信規則，其依賴於 UDP 提供的服務
（1）通信過程
當客戶端向域名服務器請求域名解析服務時，有兩種查詢方式，分別是迭代查詢和遞歸查詢
如果使用 迭代查詢 (Iterated Query)，那麼通信過程如下：
如果使用 遞歸查詢 (Recursive Query)，那麼通信過程如下：
（2）消息格式
DNS 使用 請求/回覆格式，它們使用相同的報文
【 閱讀更多計算機網絡系列文章，請看 計算機網絡複習 】