應用層 HTTP DNS協議

假如我們要實現乙個網路版的計算器，客戶端把1+1這個字串傳送給伺服器，那麼伺服器經過解析，將1 ，+ ，1 分別提取出來，至於伺服器是如何提取的，我們先不管，這個提取規則可以理解為協議，當然協議有很多種類，也可以定義結構體，將結構體按照規則轉換成字串傳送給伺服器，伺服器接收到後解析為字串返回給客戶端正確的答案，總之一端傳送時構造的資料, 在另一端能夠正確的進行解析，這中約定就是應用層協議.

協議可以自定義，但是這篇主要總結的是一些大佬們定義的協議，所以像我這種小菜雞，只能望塵莫及

負責解析網域名稱到 ip 位址之間的服務，因為我們在位址列輸入的是url，也就是網域名稱，比如 ,當按下回車時候，dns 協議會解析出對應的 ip 位址，這個ip位址在網路層和鏈路層就可以大顯身手了.

當然 dns 也可以通過 ip 位址查詢到網域名稱，是乙個雙向的服務

這裡有個常考的面試題：當輸入 url 的按下回車的時候，發生了什麼？

其實可以分為兩個部分：通過 dns 查詢 ip，通過 socket 傳送資料

通過 dns 查詢 ip

如果瀏覽器之前有訪問記錄，則首先通過瀏覽器 dns 快取或者系統快取 hosts 檔案中查詢，找不到的話會去路由器快取或者本地伺服器 dns 快取中查詢，找到了則將解析結果返回客戶端進行網域名稱解析

如果還沒有找到，那麼網域名稱對應的 ip 位址就必須去 dns 伺服器查詢，基於 udp 實現，比如要訪問 www.abc.com 首先由本機所設定的 dns 伺服器向 dns 根節點查詢負責 .com 區域的域務器，然後通過其中乙個負責 .com 的伺服器查詢負責 abc.com 的伺服器，最後由其中乙個 abc.com 的網域名稱伺服器查詢 www.abc.com 網域名稱的ip位址返回給客戶端,所以這是乙個遞迴方式的查詢

通過 socket 傳送資料http 是超文字傳輸協議

http 分為兩個時代

http 協議的職責就是生成針對目標伺服器的請求報文，也可以理解為資料單元，在請求報文中包含很多內容，當請求報文傳送到web伺服器時，會返回乙個響應報文，裡面也有很多內容

下面詳細總結裡面有啥內容

請求報文分為兩個部分，報文首部和報文主體，報文首部又可以分為請求行和首部字段

請求行由方法,url,協議版本組成，至於方法和協議版本有哪些，後面詳細總結

請求首部字段(header)由多組屬性組成，每一組屬性的格式是乙個鍵值對，一組屬性佔一行，比如：

host:job.xjtu.edu.cn

connection:keep-alive

content-length:36

cache-control:max-age=0

…

報文主體也可以叫內容的主體(body)，body裡面可以有東西，主要是像伺服器提供資源請求被處理，當然也可以為空字串

響應報文也分為兩個部分，分別是響應報文首部和響應報文主體,首部又可以分為狀態行和首部字段

狀態行由版本號,狀態碼，狀態碼解釋組成,狀態碼和狀態碼解釋後面也會詳細總結.

響應首部字段也是由鍵值對組成的屬性

accept: 告訴瀏覽器，它所支援的資料型別

accept-encoding: 支援哪種編碼格式 gbk, uft-8,gb2312,…

accept-language: 告訴瀏覽器，它的語言環境

cache-control: 快取控制

connection:告訴瀏覽器，請求完成是保持連線還是斷開連線

refresh: 告訴客戶端，多久重新整理一次

referer: 當前頁面是從哪個頁面跳轉過來的;

content-type : 資料型別(text/html 等)

content-length: body的長度，如果實體主體經過編碼後，將不會有這個字段

host: 客戶端告知伺服器, 所請求的資源是在哪個主機的哪個埠上;

location: 搭配3xx狀態碼使用, 告訴客戶端接下來要去指定的 url 訪問;

主體 body裡面存放著資訊，如果伺服器返回乙個頁面，那麼這個頁面資源就在body中，例如：

< html >

…< /html>

下面是請求報文中的方法，以及相應報文中的狀態碼

在請求報文的第一行，由方法和 url,協議版本組成

url 是什麼？url 編碼

url 可以理解為網頁位址，主要包含協議名、伺服器位址、埠號、帶層次的檔案路徑、查詢字串、片段識別符號

url 編碼是對部分字元進行轉義，比如 c++ 被轉義為 c%2b%2b，因為 + 符號對於 url 有特定的含義，轉義是為了避免產出歧義.

那麼請求方法有多種，主要是 get 和 post

get：一般是去伺服器請求獲取資源或者指定的頁面資訊，請求的引數可以附在 url 的後面，所以它的安全性比較低，另外對應的伺服器對 url 長度會有限制

post：一般是更新伺服器資源或者提交資源，比如我們註冊頁面的時候，post 請求會把資料放在 http 請求報文體中去請求伺服器，所以比起 get 更加安全，另外 post 也沒有長度限制

其它請求方法

head 獲取報文首部，返回的響應中沒有具體內容

put 傳輸檔案，比如從客戶端向伺服器傳輸的資料取代指定的內容

delete 請求伺服器刪除指定的頁面

以上三種有印象即可，在學習微服務的時候會詳細總結

響應狀態碼

當伺服器返回給客戶端的響應報文中，包含的狀態碼主要有 2 開頭， 3 開頭 4 開頭以及 5 開頭

2xx：請求被成功處理了，例如

3xx: 重定向，表明瀏覽器需要執行特殊的處理，伺服器才可以正確的處理

4xx:客戶端錯誤

5xx: 伺服器錯誤啦

網頁 web 通訊，當我們開啟瀏覽器，在位址列輸入 url ，按下回車的時候，就會訪問對應的 web 伺服器，而他們之間的通訊就建立在 http 協議的基礎上.

當然資料報也不會一下子就傳送過去，依然是從應用層到傳輸層選擇傳輸的方式以及建立連線，傳輸層(tcp協議)完成的工作還是比較複雜的，將資料進行分割，並在各個報文打上標記序號，及埠號，然後才**給網路層，這個時候根本沒有連線，只是在傳輸層約定連線的方式和規則，當資料段傳送到 web 伺服器的傳輸層，經過解析之後才會建立連線(如何建立連線)，接著資料會來到網路層選擇通過什麼樣的路徑到達 web 伺服器，並且會將 mac 位址一併發給下一層…資料鏈路層處理連線網路的硬體部分

接收端的伺服器在鏈路層收到資料，按序往上層傳送，一直到應用層才算真正接收到了客戶端發來的請求

傳送端在層與層之間會附加乙個該層的首部資訊，反之在接收端每經過一層，就會去掉對應的首部，從傳輸層開始，附加乙個 tcp 首部或者 udp 首部到網路層，網路層會附加乙個ip首部傳送到鏈路層，鏈路層會附加乙個乙太網的首部，這個首部裡面包含的資訊是非常重要的，比如在tcp首部中，含有目標埠號，可以保障資料被傳送到正確的應用程式.

http 協議雖然執行在 tcp 協議之上，保證可靠傳輸，但是屬於明文傳輸，在傳輸的過程中可能會被篡改，而且客戶端和伺服器無法驗證對方身份，所以在 htpp 基礎上加了 ssl 套接層，ssl 又是執行在 tcp 的基礎上

所以通俗理解 https 就是在 http 的基礎上進行加密和認證

對稱金鑰加密是指加密和解密使用同乙個金鑰的方式，這種方式存在的最大問題就是如何安全地將金鑰發給對方；

而非對稱加密是指使用一對非對稱金鑰，即公鑰和私鑰，公鑰可以隨意發布，但私鑰只有自己知道。傳送密文的一方使用對方的公鑰進行加密處理，對方接收到加密資訊後，使用自己的私鑰進行解密

由於非對稱加密的方式不需要傳送解密的私鑰，所以可以保證安全性；但是和對稱加密比起來，處理速度要慢，所以 https 採用混合機制，用對稱加密來傳送訊息，但對稱加密所使用的金鑰我們可以通過非對稱加密的方式傳送出去

這裡面還有乙個問題，就是如何保證公開金鑰沒有被攻擊者篡改替換？

可以使用數字證書認證機構頒發的公開金鑰證書，就比如說，我是名校本科畢業生，在面試的時候，證明我身份的是該學校的畢業證和學位證.而面試官通過檢視畢業證，認為我值得信賴

… 待補充

應用層 HTTP DNS協議

應用層協議

應用層協議

應用層協議 HTTP協議

相關推薦