計算機網路之應用層

阿新 • • 發佈：2020-07-22

應用層

1、域名系統DNS

域名系統 DNS(Domain Name System) 是一個聯機分散式資料庫系統，採用C/S方式，提供了主機名和 IP 地址之間相互轉換的服務。這裡的分散式資料庫是指，每個站點只保留它自己的那部分資料。

1.1 主要任務

一個由分層的DNS伺服器實現的分散式資料庫；
一個是的主機能夠查詢分散式資料庫的應用層協議。

DNS協議執行在UDP之上，使用53埠。

DNS通常由其他的應用層協議HTTP、FTP、SMTP所使用，將使用者提供的主機名解析為IP地址。

1.2 應用場景

DNS協議是應用層協議。

使用客戶-伺服器模式執行在通訊的端系統之間；
在通訊的端系統之間通過下面的端到端運輸協議來傳送DNS報文。

1.3 DNS執行做法

執行在使用者主機上的一個瀏覽器請求URLhttps://www.cnblogs.com/njuptzheng/時會發生什麼？

同一臺使用者主機上執行著DNS應用的客戶端；
瀏覽器從上述URL中抽取主機名www.cnblogs.com ，並將這臺主機名傳送給DNS應用的客戶端；
DNS客戶向DNS伺服器傳送一個包含主機名的請求；
DNS客戶最終會收到一份回答報文，其中含有對應於該主機名的IP地址；
一旦瀏覽器接收到來自DNS的該IP地址，它能夠向位於該IP地址80埠的HTTP伺服器程序發起一個TCP連線。

1.4 域名

每個域名都由標號組成，每個標號之間用點隔開。域名具有層次結構，從上到下依次為：根域名、頂級域名、二級域名、三級域名。

1.5 DNS傳輸

DNS 可以使用 UDP 或者 TCP 進行傳輸，使用的埠號都為 53。大多數情況下 DNS 使用 UDP 進行傳輸，這就要求域名解析器和域名伺服器都必須自己處理超時和重傳從而保證可靠性。在兩種情況下會使用 TCP 進行傳輸：

如果返回的響應超過的 512 位元組（UDP 最大隻支援 512 位元組的資料）。
區域傳送（區域傳送是主域名伺服器向輔助域名伺服器傳送變化的那部分資料）。

主機解析域名的順序：瀏覽器快取、找本機的 hosts 檔案、路由快取、找 DNS 伺服器（本地DNS伺服器、權威DNS伺服器、頂級DNS伺服器、根DNS伺服器，通過迭代查詢、遞迴查詢）

任何DNS查詢既可以是迭代的也能是遞迴的。從請求主機到本地DNS伺服器的查詢是遞迴的，其他查詢是迭代的。

根DNS伺服器：根DNS伺服器提供TLD伺服器的IP地址。
頂級DNS伺服器(TLD：TLD伺服器提供權威DNS伺服器的IP地址。
權威DNS伺服器：在因特網上具有公共可訪問的機構必須提供公共可訪問的DNS記錄，這些記錄將這些主機的名字對映為IP地址。而權威DNS伺服器收藏這些DNS記錄。
本地DNS伺服器：每個ISP都有一臺本地DNS伺服器。

使用 nslookup 命令可以檢視域名解析的 IP 地址。

2、檔案傳送協議FTP

FTP 使用 TCP 進行連線，它需要兩個連線來傳送一個檔案：

控制連線：伺服器開啟埠號 21 等待客戶端的連線，客戶端主動建立連線後，使用這個連線將客戶端的命令傳送給伺服器，並傳回伺服器的應答。
資料連線：標準埠為 20，用來傳送一個檔案資料。

根據資料連線是否是伺服器端主動建立，FTP 有主動和被動兩種模式：

主動模式：伺服器端主動建立資料連線，其中伺服器端的埠號為 20，客戶端的埠號隨機，但是必須大於1024，因為 0~1023是熟知埠號。

被動模式：客戶端主動建立資料連線，其中客戶端的埠號由客戶端自己指定，伺服器端的埠號隨機。

主動模式要求客戶端開放埠號給伺服器端，需要去配置客戶端的防火牆，開放 20 和 21 埠。被動模式只需要伺服器端開放埠號即可，無需客戶端配置防火牆。但是被動模式會導致伺服器端的安全性減弱，因為開放了過多的埠號。

3、動態主機配置協議DHCP

DHCP (Dynamic Host Configuration Protocol) 提供了即插即用的連網方式，使用者不再需要手動配置 IP 地址等資訊。DHCP 配置的內容不僅是 IP 地址，還包括子網掩碼、閘道器 IP 地址。

DHCP 工作過程如下：

客戶端傳送 Discover 報文，該報文的目的地址為 255.255.255.255:67，源地址為 0.0.0.0:68，被放入 UDP 中，該報文被廣播到同一個子網的所有主機上。如果客戶端和 DHCP 伺服器不在同一個子網，就需要使用中繼代理。
DHCP 伺服器收到 Discover 報文之後，傳送 Offer 報文給客戶端，該報文包含了客戶端所需要的資訊。因為客戶端可能收到多個 DHCP 伺服器提供的資訊，因此客戶端需要進行選擇。
如果客戶端選擇了某個 DHCP 伺服器提供的資訊，那麼就傳送 Request 報文給該 DHCP 伺服器。
DHCP 伺服器傳送 Ack 報文，表示客戶端此時可以使用提供給它的資訊。

注意：DHCP 伺服器必須設定為靜態 IP 地址，如果為本網段分配 IP 地址，DHCP 伺服器的作用域範圍必須設定為本網段地址範圍。

4、超文字傳輸協議HTTP

4.1 統一資源定位符URL

統一資源定位符 URL 是用來表示網際網路上得到的資源位置和訪問這些資源的方法。一般形式由下面四個部分組成：<協議>://<埠>/<路徑>

4.2 HTTP中的非持續連線和持續連線

當客戶端-伺服器的互動是經過TCP進行的，應用程式就需要做一個決定，每一次的請求-響應是經一個單獨的TCP連線傳送，還是所有的請求-響應經相同的TCP連線傳送呢？

採用前一個方法，該應用程式就被稱為使用非持續連線；採用後一個方法，該程式就被稱為使用持續連線。

4.2.1 採用非持續連線的HTTP

我們模擬從伺服器向客戶傳送一個web頁面的步驟。
假設該web頁面含有一個HTML檔案和5個JPEG圖形，並且這6個物件位於同一臺伺服器上。假設該HTML檔案的URL為https://www.cnblogs.com/njuptzheng/ 。

HTTP客戶程序在埠號80發起一個到伺服器https://www.cnblogs.com的TCP連線。該埠號是HTTP的預設埠。在客戶和伺服器分別有一個套接字與該連線相關聯。
HTTP客戶經他的套接字向伺服器傳送一個HTTP請求報文。請求報文中包含路徑名 /njuptzheng/ 。
伺服器經他的套接字接受該請求報文，從其儲存器中找到https://www.cnblogs.com/njuptzheng/ ，在一個響應報文中封裝物件，並通過其套接字向客戶傳送響應報文。
HTTP伺服器通知TCP斷開該TCP連線。（TCP必須確定客戶收到響應報文後才會實際中斷連線）
客戶收到響應報文，TCP連線中斷。該報文指出封裝的物件是一個HTML檔案，客戶從響應報文中提取該檔案，檢查HTML檔案，得到5個JPEG圖形的引用。
對每個引用的圖形重複前四個步驟。

採用非持續連線的HTTP的響應時間為兩個RTT加上伺服器傳輸HTML檔案的時間。

RTT（往返時間）：一個短分組從客戶到伺服器再返回到客戶所花費的時間。

客戶和伺服器之間發起一個TCP連線：涉及到一次“三次握手”過程，客戶向伺服器傳送一個小TCP報文段，伺服器返回一個小TCP報文段做出確認和響應，最後客戶返回確認。三次握手的前兩個部分佔用一個RTT。客戶在返回確認報文時傳送一個HTTP請求報文。一旦該報文到達伺服器，伺服器就在該TCP連線上返回HTML檔案。該HTTP請求/響應用於了一個RTT。

4.2.2 採用持續連線的HTTP

非持續連線有一些缺點：

*必須為每一個請求的物件建立和維護一個全新的連線。這給web伺服器帶來了嚴重的負擔。
*每一個物件經受兩倍的RTT的交付時延。

4.3 HTTP操作過程

HTTP 使用面向連線的 TCP 作為運輸層協議，保證資料的可靠傳輸。但 HTTP 協議本身是無連線的，即通訊雙方在交換 HTTP 報文之前不需要建立 HTTP 連線。

4.4 HTTP的報文結構

HTTP 有兩類報文：請求報文（從客戶向伺服器傳送請求報文）和響應報文（從伺服器到客戶的回答）

HTTP 的請求報文和響應報文都是有三部分組成：

開始行：用於區分是請求報文還是響應報文。
首部行：用來說明瀏覽器、伺服器和報文主體的一些資訊。整個首部行結束後還有一空行將首部行和實體主體分開。
實體主體：請求報文中一般不使用這個欄位，而響應報文中也可能沒有這個欄位。

4.5 HTTP報文格式

4.5.1 HTTP請求報文

客戶端傳送的 請求報文 第一行為請求行，包含了方法欄位。

方法（操作）	意義
OPTION	請求一些選項的資訊
GET	請求讀取由 URL 標誌的資訊
HEAD	獲取 URL 標誌的報文首部
POST	主要用來傳輸資料，而 GET 主要用來獲取資源。
PUT	上傳檔案，不帶驗證機制，任何人都可以上傳檔案，因此存在安全性問題，一般不使用該方法。
PATCH	PUT 也可以用於修改資源，但是隻能完全替代原始資源，PATCH 允許部分修改
DELETE	刪除檔案，與 PUT 功能相反，並且同樣不帶驗證機制
OPTIONS	查詢指定的 URL 能夠支援的方法
CONNECT	要求在與代理伺服器通訊時建立隧道，使用 SSL 和 TLS 協議把傳輸內容加密後經網路隧道傳輸
TRACE	追蹤路徑，伺服器會將通訊路徑返回給客戶端

下面是一個完整的 HTTP 請求報文的例子：

 GET /dir/index.htm HTTP/1.1            {請求行使用了相對URL}
Host: www.xyz.edu.cn                    {首部行的開始，給出主機的域名}
Connection: close                       {告訴伺服器傳送完請求的文件就可以釋放連線}
User-Agent: Mozilla/5.0                 {表明使用者代理是使用火狐瀏覽器Firefox}
Accept-Language: cn                     {表示使用者希望優先得到中文版本的文件}
                                        {請求報文的最後還有一個空行}

4.5.2 HTTP響應報文

三個部分：一個初始狀態行、6個首部行、實體行

HTTP/1.1 200 OK						{初始狀態行：協議版本欄位、狀態碼和相應狀態資訊}
Connection: close					{首部行告訴伺服器傳送完請求的文件就可以釋放連線}
Date: Tue, 18 Aug 2015 15:44:04 GMT			{首部行指示伺服器產生併發送該響應報文的日期和時間}
Server: Apache/2.2.3 (CentOS)				{首部行指示該報文是由一臺Apache Web伺服器產生}
Last-Modified: Tue, 18 Aug 2015 15:11:03 GMT		{首部行指示物件建立或者最後修改的日期和時間}
Content-Length: 6821					{首部行指示被髮送物件中的位元組數}
Content-Type: text/html					{首部行指示實體體中的物件是HTML文字}

(data data data data data ...)

4.6 HTTP狀態碼

伺服器返回的 響應報文 中第一行為狀態行，包含了狀態碼以及原因短語，用來告知客戶端請求的結果。
狀態碼都是 3 位數，分為 5 個大類。

狀態碼	類別	含義
1XX	Informational（資訊性狀態碼）	接收的請求正在處理
2XX	Success（成功狀態碼）	請求正常處理完畢
3XX	Redirection（重定向狀態碼）	需要進行附加操作以完成請求
4XX	Client Error（客戶端錯誤狀態碼）	伺服器無法處理請求
5XX	Server Error（伺服器錯誤狀態碼）	伺服器處理請求出錯

1XX 資訊

100 Continue：表明到目前為止都很正常，客戶端可以繼續傳送請求或者忽略這個響應。

2XX 成功

200 OK
204 No Content：請求已經成功處理，但是返回的響應報文不包含實體的主體部分。一般在只需要從客戶端往伺服器傳送資訊，而不需要返回資料時使用。
206 Partial Content：表示客戶端進行了範圍請求，響應報文包含由 Content-Range 指定範圍的實體內容。

3XX 重定向

301 Moved Permanently：永久性重定向
302 Found：臨時性重定向
303 See Other：和 302 有著相同的功能，但是 303 明確要求客戶端應該採用 GET 方法獲取資源。
注：雖然 HTTP 協議規定 301、302 狀態下重定向時不允許把 POST 方法改成 GET 方法，但是大多數瀏覽器都會在 301、302 和 303 狀態下的重定向把 POST 方法改成 GET 方法。
304 Not Modified：如果請求報文首部包含一些條件，例如：If-Match，If-Modified-Since，If-NoneMatch，If-Range，If-Unmodified-Since，如果不滿足條件，則伺服器會返回 304 狀態碼。
307 Temporary Redirect：臨時重定向，與 302 的含義類似，但是 307 要求瀏覽器不會把重定向請求的POST 方法改成 GET 方法。

4XX 客戶端錯誤

400 Bad Request：請求報文中存在語法錯誤。
401 Unauthorized：該狀態碼錶示傳送的請求需要有認證資訊（BASIC 認證、DIGEST 認證）。如果之前已進行過一次請求，則表示使用者認證失敗。
403 Forbidden：請求被拒絕。
404 Not Found

5XX 伺服器錯誤

500 Internal Server Error：伺服器正在執行請求時發生錯誤。
503 Service Unavailable：伺服器暫時處於超負載或正在進行停機維護，現在無法處理請求。

常見的三種狀態行的響應報文：

HTTP/1.1 202 Accepted           {接收}
HTTP/1.1 400 Bad Request        {錯誤的請求}
HTTP/1.1 404 Not Found          {找不到}

5、HTTPS

HTTP 有以下安全性問題：

使用明文進行通訊，內容可能會被竊聽；
不驗證通訊方的身份，通訊方的身份有可能遭遇偽裝；
無法證明報文的完整性，報文有可能遭篡改。

HTTP 是一種 超文字傳輸協議(Hypertext Transfer Protocol) 協議，它是一個在計算機世界裡專門在兩點之間傳輸文字、圖片、音訊、視訊等超文字資料的約定和規範。

HTTPS 的全稱是 Hypertext Transfer Protocol Secure，它用來在計算機網路上的兩個端系統之間進行安全的交換資訊(secure communication)，它相當於在 HTTP 的基礎上加了一個 Secure 安全的詞眼，那麼我們可以給出一個 HTTPS 的定義：HTTPS 是一個在計算機世界裡專門在兩點之間安全的傳輸文字、圖片、音訊、視訊等超文字資料的約定和規範。HTTPS 是 HTTP 協議的一種擴充套件，它本身並不保傳輸的證安全性，那麼誰來保證安全性呢？在 HTTPS 中，使用傳輸層安全性(TLS)或安全套接字層(SSL)對通訊協議進行加密。也就是 HTTP + SSL(TLS) = HTTPS。

5.1 認識 SSL/TLS

TLS(Transport Layer Security) 是 SSL(Secure Socket Layer) 的後續版本，它們是用於在網際網路兩臺計算機之間用於身份驗證和加密的一種協議。

我們都知道一些線上業務（比如線上支付）最重要的一個步驟是建立一個值得信賴的交易環境，能夠讓客戶安心的進行交易，SSL/TLS 就保證了這一點，SSL/TLS 通過將稱為 X.509 證書的數字文件將網站和公司的實體資訊繫結到加密金鑰來進行工作。每一個金鑰對(key pairs) 都有一個 私有金鑰(private key) 和 公有金鑰(public key)，私有金鑰是獨有的，一般位於伺服器上，用於解密由公共金鑰加密過的資訊；公有金鑰是公有的，與伺服器進行互動的每個人都可以持有公有金鑰，用公鑰加密的資訊只能由私有金鑰來解密。

X.509 是公開金鑰證書的標準格式，這個文件將加密金鑰與（個人或組織）進行安全的關聯。
X.509 主要應用如下：

SSL/TLS 和 HTTPS 用於經過身份驗證和加密的 Web 瀏覽

通過 S/MIME 協議簽名和加密的電子郵件

程式碼簽名：它指的是使用數字證書對軟體應用程式進行簽名以安全分發和安裝的過程。通過使用由知名公共證書頒發機構（例如SSL.com）頒發的證書對軟體進行數字簽名，開發人員可以向終端使用者保證他們希望安裝的軟體是由已知且受信任的開發人員釋出；並且簽名後未被篡改或損害。

還可用於文件簽名

還可用於客戶端認證

政府簽發的電子身份證

5.2 加密

HTTPS 通過對資料加密來使其免受竊聽者對資料的監聽，這就意味著當用戶在瀏覽網站時，沒有人能夠監聽他和網站之間的資訊交換，或者跟蹤使用者的活動，訪問記錄等，從而竊取使用者資訊。

對稱金鑰加密

在瞭解對稱加密前，我們先來了解一下密碼學的東西，在密碼學中，有幾個概念：明文、密文、加密、解密

明文(Plaintext)，一般認為明文是有意義的字元或者位元集，或者是通過某種公開編碼就能獲得的訊息。明文通常用 m 或 p 表示
密文(Ciphertext)，對明文進行某種加密後就變成了密文
加密(Encrypt)，把原始的資訊（明文）轉換為密文的資訊變換過程
解密(Decrypt)，把已經加密的資訊恢復成明文的過程。

對稱加密(Symmetrical Encryption)顧名思義就是指加密和解密時使用的金鑰都是同樣的金鑰。只要保證了金鑰的安全性，那麼整個通訊過程也就是具有了機密性。

優點：運算速度快；
缺點：無法安全地將金鑰傳輸給通訊方。

非對稱金鑰加密

非對稱加密(Asymmetrical Encryption) 也被稱為公鑰加密，相對於對稱加密來說，非對稱加密是一種新的改良加密方式。金鑰通過網路傳輸交換，它能夠確保及時金鑰被攔截，也不會暴露資料資訊。非對稱加密中有兩個金鑰，一個是公鑰，一個是私鑰，公鑰進行加密，私鑰進行解密。公開金鑰可供任何人使用，私鑰只有你自己能夠知道。

非對稱金鑰除了用來加密，還可以用來進行簽名。因為私有金鑰無法被其他人獲取，因此通訊傳送方使用其私有金鑰進行簽名，通訊接收方使用傳送方的公開金鑰對簽名進行解密，就能判斷這個簽名是否正確。

優點：可以更安全地將公開金鑰傳輸給通訊傳送方；
缺點：運算速度慢。

HTTPS採用的混合加密方式

HTTPS 採用混合的加密機制，使用非對稱金鑰加密用於傳輸對稱金鑰來保證傳輸過程的安全性，之後使用對稱金鑰加密進行通訊來保證通訊過程的效率。

5.3 摘要演算法

SSL 提供報文摘要功能來進行完整性保護。

HTTP 也提供了 MD5 報文摘要功能，但不是安全的。例如報文內容被篡改之後，同時重新計算 MD5 的值，通訊接收方是無法意識到發生了篡改。
MD5 的全稱是 Message Digest Algorithm 5，它是屬於密碼雜湊演算法(cryptographic hash algorithm)的一種，MD5 可用於從任意長度的字串建立 128 位字串值。儘管 MD5 存在不安全因素，但是仍然沿用至今。MD5 最常用於驗證檔案的完整性。但是，它還用於其他安全協議和應用程式中，例如 SSH、SSL 和 IPSec。一些應用程式通過嚮明文加鹽值或多次應用雜湊函式來增強 MD5 演算法。

HTTPS 的報文摘要功能之所以安全，是因為它結合了加密和認證這兩個操作。試想一下，加密之後的報文，遭到篡改之後，也很難重新計算報文摘要，因為無法輕易獲取明文。

可以把摘要演算法理解成一種特殊的壓縮演算法，它能夠把任意長度的資料壓縮成一種固定長度的字串，這就好像是給資料加了一把鎖。

除了常用的 MD5 是加密演算法外，SHA-1(Secure Hash Algorithm 1) 也是一種常用的加密演算法，不過 SHA-1 也是不安全的加密演算法，在 TLS 裡面被禁止使用。目前 TLS 推薦使用的是 SHA-1 的後繼者：SHA-2。
SHA-2 的全稱是Secure Hash Algorithm 2 ，它在 2001 年被推出，它在 SHA-1 的基礎上做了重大的修改，SHA-2 系列包含六個雜湊函式，其摘要（雜湊值）分別為 224、256、384 或 512 位：SHA-224, SHA-256, SHA-384, SHA-512。分別能夠生成 28 位元組、32 位元組、48 位元組、64 位元組的摘要。
有了 SHA-2 的保護，就能夠實現資料的完整性，哪怕你在檔案中改變一個標點符號，增加一個空格，生成的檔案摘要也會完全不同，不過 SHA-2 是基於明文的加密方式，還是不夠安全，那應該用什麼呢？

安全性更高的加密方式是使用 HMAC，在理解什麼是 HMAC 前，你需要先知道一下什麼是 MAC。
MAC 的全稱是message authentication code，它通過 MAC 演算法從訊息和金鑰生成，MAC 值允許驗證者（也擁有祕密金鑰）檢測到訊息內容的任何更改，從而保護了訊息的資料完整性。
HMAC 是 MAC 更進一步的拓展，它是使用 MAC 值 + Hash 值的組合方式，HMAC 的計算中可以使用任何加密雜湊函式，例如 SHA-256 等。

5.4 認證

通過使用證書來對通訊方進行認證。我們在上面的敘述過程中出現過公鑰加密，私鑰解密的這個概念。提到的私鑰只有你一個人所有，能夠辨別唯一性，所以我們可以把順序調換一下，變成私鑰加密，公鑰解密。使用私鑰再加上摘要演算法，就能夠實現數字簽名，從而實現認證。
進行 HTTPS 通訊時，伺服器會把證書傳送給客戶端。客戶端取得其中的公開金鑰之後，先使用數字簽名進行驗證，如果驗證通過，就可以開始通訊了。

數字證書認證機構（CA，Certificate Authority）是客戶端與伺服器雙方都可信賴的第三方機構。伺服器的運營人員向 CA 提出公開金鑰的申請，CA 在判明提出申請者的身份之後，會對已申請的公開金鑰做數字簽名，然後分配這個已簽名的公開金鑰，並將該公開金鑰放入公開金鑰證書後繫結在一起。

通常情況下，數字證書的申請人將生成由私鑰和公鑰以及證書籤名請求（CSR）組成的金鑰對。CSR是一個編碼的文字檔案，其中包含公鑰和其他將包含在證書中的資訊（例如域名，組織，電子郵件地址等）。金鑰對和 CSR生成通常在將要安裝證書的伺服器上完成，並且 CSR 中包含的資訊型別取決於證書的驗證級別。與公鑰不同，申請人的私鑰是安全的，永遠不要向 CA（或其他任何人）展示。
生成 CSR 後，申請人將其傳送給 CA，CA 會驗證其包含的資訊是否正確，如果正確，則使用頒發的私鑰對證書進行數字簽名，然後將其傳送給申請人。