国产成人精品无码青草_亚洲国产美女精品久久久久∴_欧美人与鲁交大毛片免费_国产果冻豆传媒麻婆精东

18143453325 或 在線咨詢 在線咨詢
18143453325 或 在線咨詢
所在位置： 首頁 > 營銷資訊 > 建站知識 > 常見網(wǎng)絡協(xié)議匯總（一）

常見網(wǎng)絡協(xié)議匯總（一）

時間：2023-02-02 13:48:01 | 來源：建站知識

時間：2023-02-02 13:48:01 來源：建站知識

“網(wǎng)絡協(xié)議”是指為完成特定的任務而制定的一套規(guī)則。網(wǎng)絡協(xié)議通常用來表示數(shù)據(jù)傳輸中一組用于實現(xiàn)一個或多個OT模型級別的規(guī)則或規(guī)范。在通信時，網(wǎng)絡協(xié)議定義了在通信時如何進行通信。今天海翎光電的小編就匯總了常見的網(wǎng)絡協(xié)議，來一起看看。我們先回顧一下計算機網(wǎng)絡五層模型，如下圖。




協(xié)議——DNS協(xié)議、HTTP協(xié)議、HTTPS協(xié)議

協(xié)議——TCP協(xié)議、UDP協(xié)議

協(xié)議——IP協(xié)議

協(xié)議——ARP協(xié)議、MTU協(xié)議

對于五層網(wǎng)絡模型基本都是耳熟能詳，但是有沒有思考過，網(wǎng)絡為什么要這樣分層呢？海翎光電的小編接著分享。 最直接的回答就是為了簡化網(wǎng)絡設計的復雜性，通信協(xié)議采用分層結(jié)構(gòu)，各層之間既相互獨立又相互協(xié)調(diào)工作，如此以來便達到的高效的目的。如同設計模式中對于設計一個復雜的程序時，盡量使程序各功能之間是解耦合的一樣，對于復雜的網(wǎng)絡設計，分層設計也是很明智的一種做法。 網(wǎng)絡分層的最本質(zhì)就是每一層獨立的完成一個任務而不必考慮自己任務之外的實現(xiàn)，而因為不同的任務因此就有了每一層所對應的不同設備。(實例到應用就是，物理層只需要關系0和1的光電信號如何傳輸，而對它所表達的內(nèi)容毫不關心；再往上數(shù)據(jù)鏈路層只需要關心封裝好的數(shù)據(jù)幀如何準確的送到對應的MAC地址的目的主機中，而不必關心數(shù)據(jù)報的具體內(nèi)容和具體會通過何種方式光纖還是局域網(wǎng)…同理往上對于所有層) 應用層協(xié)議 應用層協(xié)議主要負責各個程序間的通信，發(fā)生網(wǎng)絡傳輸一個數(shù)據(jù)時，先由應用層對數(shù)據(jù)按照對應的協(xié)議封裝，然后交給下一層傳輸層，當經(jīng)過一系列網(wǎng)絡傳輸，數(shù)據(jù)達到接收端時，一層層的分用，最后一層再由應用層分用，最終得到數(shù)據(jù)。 DNS協(xié)議： DNS協(xié)議是一個應用層協(xié)議，建立在TCP和UDP的基礎之上，使用默認端口為53，其默認通過UDP協(xié)議通信，但如果報文過大是則會切換成TCP協(xié)議。 域名系統(tǒng) (DNS) 的作用是將人類可讀的域名轉(zhuǎn)換為機器可讀的 IP 地址 (如，192.0.2.44)，本質(zhì)是通過DNS域名和IP地址的對應關系轉(zhuǎn)換，而這種對應關系則保存在DNS服務器中

域名的解析過程：

域名的解析工作大體上可以分為兩個步驟：第一步客戶端向本地DNS服務器發(fā)起一個DNS請求報文，報文里攜帶需要查詢的域名，第二步本地DNS服務器向本機回應一個DNS響應報文，報文里攜帶查詢域名所對應的IP地址具體流程如下：

1.在本地緩存中查詢，如果有則返回對應IP，如果沒有將請求發(fā)給DNS服務器2.當本地DNS服務器接收到查詢后，先在服務器管理區(qū)域記錄中查詢，若沒有再在服務器本地緩存中查詢，如果沒有將請求發(fā)送到根域名服務器3.根域名服務器負責解析請求的根域部分，然后將包含下一級域名信息的DNS服務地址返回給本地DNS服務器4.本地DNS服務器利用根域名服務器解析的地址訪問下一級DNS服務器，得到再下一級域的DNS服務器地址5.按照上述遞歸方法逐級接近查詢目標，最后在有目標域名的DNS服務器上找到相應的IP地址信息6.本地DNS服務器將最終查詢到的IP返回給客戶端，讓客戶端訪問對應主機
HTTP協(xié)議

HTTP協(xié)議是一個簡單的請求——響應協(xié)議，它通常運行在TCP之上。它指定了客戶端可能發(fā)送給服務器什么樣的消息以及得到什么樣的響應。 同其他應用層協(xié)議一樣，是為了實現(xiàn)某一類具體應用的協(xié)議，并由某一運行在用戶空間的應用程序來實現(xiàn)其功能。HTTP是一種協(xié)議規(guī)范，這種規(guī)范記錄在文檔上，為真正通過HTTP進行通信的HTTP的實現(xiàn)程序。HTTP是基于TCP協(xié)議，且面向連接的。典型的HTTP事務處理有如下的過程：1.客戶端與服務器建立連接；2.客戶端向服務器提出請求；3.服務器接受請求，并根據(jù)請求返回相應的數(shù)據(jù)作為應答響應；4.客戶端與服務器關閉連接。

HTTP協(xié)議報文格式 HTTP報文由從客戶機到服務器的請求(Request)和從服務器到客戶機的響應(Respone)構(gòu)成

常見HTTP響應狀態(tài)碼匯總200 OK ：客戶端請求成功

3XX系列

301 Moved Permanently ：請求的資源以被永久的移動到新URL中，返回的Response中包含一個Location，瀏覽器會自動重定向到新URL，以后請求都會被新的URL替代302 Found ：與301類似，但請求的資源只是臨時的被移動到新的URL中，下次請求客戶端繼續(xù)使用原URL307 Temporary Redirect ： 臨時重定向，類似于302，使用GET請求重定向
4XX系列

400 Bad Request ：客戶端請求語法錯誤，服務器無法理解（在 ajax 請求后臺數(shù)據(jù)時比較常見）401 Unauthorized ：請求要求用戶的身份認證403 Forbidden ：服務器理解客戶端請求，但是拒絕執(zhí)行（一般用于用戶級別為達到要求等等不支持訪問）404 Not Found ： 服務器無法根據(jù)客戶端請求找到對應資源405 Method Not Allowed ： 服務器不支持該方法
5XX系列

500 Internal Server Error ：服務器內(nèi)部錯誤，無法完成請求503 Service Unavailable ：由于超載或系統(tǒng)維護，服務器暫時的無法處理客戶端的請求。延時的長度可包含在服務器的Retry-After頭信息中
HTTP協(xié)議的特點

  1. 支持服務器/客戶端模式
  2. 傳輸較快速，客戶端向服務器發(fā)送請求，只需要傳輸請求方法和路徑
  3. 靈活，HTTP允許傳輸任意類型的數(shù)據(jù)對象
  4. 無連接，每次連接只能處理一個請求，服務器處理完客戶端請求，客戶端收到響應后就斷開連接
  5. 無狀態(tài)，協(xié)議本身對事務處理沒有記憶能力，如果后序連接需要之前發(fā)送的信息時就需要重傳

    HTTP1.0和HTTP1.1和HTTP2.0的區(qū)別：
HTTP1.0和HTTP1.1的區(qū)別：

  1. 長連接：HTTP1.0只支持瀏覽器與服務器的短連接，即每次請求都要重新建立連接，服務器無法記錄每個歷史請求，HTTP1.1支持長連接即在一次連接下，瀏覽器可以向服務器發(fā)送多次請求增加Host字段：HTTP1.0中認為每個服務器都綁定這唯一一個IP，所有發(fā)送的請求頭URL中沒有host信息，而HTTP1.1在請求和響應中都支持了host頭域，且請求消息中如果沒有Host頭域會報告一個錯誤(400 Bad Request)緩存：HTTP1.1在1.0的基礎上加入了一些cache的新特性，當緩存對象的Age超過Expire時變?yōu)閟tale對象，cache不需要直接拋棄stale對象，而是與源服務器進行重新激活（revalidation）。錯誤提示：HTTP1.0中定義了16個狀態(tài)碼，對錯誤或警告的提示不夠具體。HTTP1.1引入了一個Warning頭域，增加對錯誤或警告信息的描述，并且還新增了24個狀態(tài)響應碼，如409(Conflict)表示請求的資源與資源的當前狀態(tài)發(fā)生沖突；410(Gone)表示服務器上的某個資源被永久性的刪除
  2. 長連接：HTTP1.0只支持瀏覽器與服務器的短連接，即每次請求都要重新建立連接，服務器無法記錄每個歷史請求，HTTP1.1支持長連接即在一次連接下，瀏覽器可以向服務器發(fā)送多次請求增加Host字段：HTTP1.0中認為每個服務器都綁定這唯一一個IP，所有發(fā)送的請求頭URL中沒有host信息，而HTTP1.1在請求和響應中都支持了host頭域，且請求消息中如果沒有Host頭域會報告一個錯誤(400 Bad Request)緩存：HTTP1.1在1.0的基礎上加入了一些cache的新特性，當緩存對象的Age超過Expire時變?yōu)閟tale對象，cache不需要直接拋棄stale對象，而是與源服務器進行重新激活（revalidation）。錯誤提示：HTTP1.0中定義了16個狀態(tài)碼，對錯誤或警告的提示不夠具體。HTTP1.1引入了一個Warning頭域，增加對錯誤或警告信息的描述，并且還新增了24個狀態(tài)響應碼，如409(Conflict)表示請求的資源與資源的當前狀態(tài)發(fā)生沖突；410(Gone)表示服務器上的某個資源被永久性的刪除
  3. 長連接：HTTP1.0只支持瀏覽器與服務器的短連接，即每次請求都要重新建立連接，服務器無法記錄每個歷史請求，HTTP1.1支持長連接即在一次連接下，瀏覽器可以向服務器發(fā)送多次請求增加Host字段：HTTP1.0中認為每個服務器都綁定這唯一一個IP，所有發(fā)送的請求頭URL中沒有host信息，而HTTP1.1在請求和響應中都支持了host頭域，且請求消息中如果沒有Host頭域會報告一個錯誤(400 Bad Request)緩存：HTTP1.1在1.0的基礎上加入了一些cache的新特性，當緩存對象的Age超過Expire時變?yōu)閟tale對象，cache不需要直接拋棄stale對象，而是與源服務器進行重新激活（revalidation）。錯誤提示：HTTP1.0中定義了16個狀態(tài)碼，對錯誤或警告的提示不夠具體。HTTP1.1引入了一個Warning頭域，增加對錯誤或警告信息的描述，并且還新增了24個狀態(tài)響應碼，如409(Conflict)表示請求的資源與資源的當前狀態(tài)發(fā)生沖突；410(Gone)表示服務器上的某個資源被永久性的刪除
  4. 長連接：HTTP1.0只支持瀏覽器與服務器的短連接，即每次請求都要重新建立連接，服務器無法記錄每個歷史請求，HTTP1.1支持長連接即在一次連接下，瀏覽器可以向服務器發(fā)送多次請求增加Host字段：HTTP1.0中認為每個服務器都綁定這唯一一個IP，所有發(fā)送的請求頭URL中沒有host信息，而HTTP1.1在請求和響應中都支持了host頭域，且請求消息中如果沒有Host頭域會報告一個錯誤(400 Bad Request)緩存：HTTP1.1在1.0的基礎上加入了一些cache的新特性，當緩存對象的Age超過Expire時變?yōu)閟tale對象，cache不需要直接拋棄stale對象，而是與源服務器進行重新激活（revalidation）。錯誤提示：HTTP1.0中定義了16個狀態(tài)碼，對錯誤或警告的提示不夠具體。HTTP1.1引入了一個Warning頭域，增加對錯誤或警告信息的描述，并且還新增了24個狀態(tài)響應碼，如409(Conflict)表示請求的資源與資源的當前狀態(tài)發(fā)生沖突；410(Gone)表示服務器上的某個資源被永久性的刪除
HTTP1.X和HTTP2.0的區(qū)別

  1. 增加二進制格式解析：HTTP1.X解析基于文本，而文本格式本身就具有多樣性，很多場景下不方便，而引入二進制后，只有0和1組合，使解析更加方便也增強了健壯性多路復用：即每個request都是是用作連接共享機制的，每個request都對應一個id，使一個連接可以有多個請求，再根據(jù)id將request歸屬到不同的服務端請求里header壓縮：HTTP1.X中，每次傳輸都要寫點header頭，占用了大量數(shù)據(jù)，因此HTTP2.0在客戶端和服務端各保存了一份header fields表，每次傳輸時只需傳輸header的更新信息，將header fields表更新即可實現(xiàn)header傳輸服務端推送：HTTP2.0也添加了server push功能
  2. 增加二進制格式解析：HTTP1.X解析基于文本，而文本格式本身就具有多樣性，很多場景下不方便，而引入二進制后，只有0和1組合，使解析更加方便也增強了健壯性多路復用：即每個request都是是用作連接共享機制的，每個request都對應一個id，使一個連接可以有多個請求，再根據(jù)id將request歸屬到不同的服務端請求里header壓縮：HTTP1.X中，每次傳輸都要寫點header頭，占用了大量數(shù)據(jù)，因此HTTP2.0在客戶端和服務端各保存了一份header fields表，每次傳輸時只需傳輸header的更新信息，將header fields表更新即可實現(xiàn)header傳輸服務端推送：HTTP2.0也添加了server push功能
  3. 增加二進制格式解析：HTTP1.X解析基于文本，而文本格式本身就具有多樣性，很多場景下不方便，而引入二進制后，只有0和1組合，使解析更加方便也增強了健壯性多路復用：即每個request都是是用作連接共享機制的，每個request都對應一個id，使一個連接可以有多個請求，再根據(jù)id將request歸屬到不同的服務端請求里header壓縮：HTTP1.X中，每次傳輸都要寫點header頭，占用了大量數(shù)據(jù)，因此HTTP2.0在客戶端和服務端各保存了一份header fields表，每次傳輸時只需傳輸header的更新信息，將header fields表更新即可實現(xiàn)header傳輸服務端推送：HTTP2.0也添加了server push功能
  4. 增加二進制格式解析：HTTP1.X解析基于文本，而文本格式本身就具有多樣性，很多場景下不方便，而引入二進制后，只有0和1組合，使解析更加方便也增強了健壯性多路復用：即每個request都是是用作連接共享機制的，每個request都對應一個id，使一個連接可以有多個請求，再根據(jù)id將request歸屬到不同的服務端請求里header壓縮：HTTP1.X中，每次傳輸都要寫點header頭，占用了大量數(shù)據(jù)，因此HTTP2.0在客戶端和服務端各保存了一份header fields表，每次傳輸時只需傳輸header的更新信息，將header fields表更新即可實現(xiàn)header傳輸服務端推送：HTTP2.0也添加了server push功能
HTTPS協(xié)議

HTTPS同樣作為應用層協(xié)議，可以說它是HTTP的升級版，增加了傳輸數(shù)據(jù)的安全性，HTTPS協(xié)議是在HTTP的基礎上增加了一個SSL外殼，HTTPS運行在SSL上，SSL運行在TCP上，對數(shù)據(jù)的加密工作就是在SSL上完成的

其保證安全性的做法是通過證書驗證和對信息混合加密的方式

混合加密技術：

混合加密技術：結(jié)合對稱加密與非對稱加密服務端生成私鑰，再通過私鑰生成公鑰，然后將公鑰放在證書中頒發(fā)給客戶端使用公鑰和私鑰以非對稱方式加密生成密鑰客戶端接下來的傳輸數(shù)據(jù)中，都會用密鑰以對稱方式對信息加密，再傳輸給服務端
對于，上述提到的公鑰和私鑰，我們規(guī)定用公鑰加密的內(nèi)容必須用私鑰才能解開，同樣，私鑰加密的內(nèi)容只有公鑰能解開 所以HTTPS傳輸數(shù)據(jù)是用被密鑰加密的密文和用公鑰加密的私鑰來保證數(shù)據(jù)安全的

HTTPS加密，只用對稱加密可以嗎？ 不行！無法保證安全性，因為只用對稱加密即只用密鑰對數(shù)據(jù)加密傳輸?shù)脑?，如果傳輸途中，信息被第三方劫持，獲取到密鑰，那接下來的傳輸，第三方都可以通過密鑰對數(shù)據(jù)解密從而得到原始數(shù)據(jù)。



HTTPS加密，只用非對稱加密可以嗎？兩次呢？ 同樣不行，如果只用非對稱加密?？蛻舳嗣看蝹鬏敂?shù)據(jù)用公鑰加密，服務端再用私鑰解密這一方向看似安全，但當服務端發(fā)送數(shù)據(jù)用私鑰加密，客戶端收到用公鑰解密時，第三方劫持到信息，但可能在此之前就獲得公鑰，因為首次服務端向客戶端發(fā)送公鑰是明文傳輸?shù)摹? 而換個角度如果使用兩次非對稱加密，即兩組公鑰，兩組私鑰，客戶端服務端各持一組，理論上可以達到安全，但實際HTTPS并未采用，因為非對稱加密耗時十分大
證書：

單有混合加密技術，看似已經(jīng)保證了傳輸?shù)陌踩?，實則還是有漏洞，問題就在于服務器根本無法識別發(fā)送過來的公鑰是否是自己的，如此以來在第三方劫持到數(shù)據(jù)后，自行再定義一個公鑰B，并將公鑰B傳回給客服端，此時客戶端就會利用該公鑰B重新加密數(shù)據(jù)然后發(fā)送，此時第三方就可以通過自己的公鑰B解密得到原始數(shù)據(jù)了。 證書就解決了這一問題，指定頒發(fā)的為CA機構(gòu)，當網(wǎng)站使用HTTPS時，會向CA機構(gòu)申請一個數(shù)字證書，證書中可以存放公鑰、數(shù)據(jù)等信息，由此以來，服務端就可以通過證書來向客戶端證明正確的公鑰是哪一個，以此保證安全。 而對于證書，還有一些自己的放篡改機制，防止第三方獲取到使用



關鍵詞：匯總,協(xié)議,網(wǎng)絡

74
73
25
news

版權(quán)所有? 億企邦 1997-2025 保留一切法律許可權(quán)利。

為了最佳展示效果，本站不支持IE9及以下版本的瀏覽器，建議您使用谷歌Chrome瀏覽器。 點擊下載Chrome瀏覽器
關閉