“網(wǎng)絡(luò)協(xié)議”是指為完成特定的任務(wù)而制定的一套規(guī)則。網(wǎng)絡(luò)協(xié)議通常用來(lái)表示數(shù)據(jù)傳輸中一組用于實(shí)現(xiàn)一個(gè)或多個(gè)OT模型級(jí)別的規(guī)則或規(guī)范。在通信時(shí)，網(wǎng)絡(luò)協(xié)議定義了在通信時(shí)如何進(jìn)行通信。今天海翎光電的小編就匯總了常見(jiàn)的網(wǎng)絡(luò)協(xié)議，來(lái)一起看看。我們先回顧一下計(jì)算機(jī)網(wǎng)絡(luò)五層模型，如下圖。
- 應(yīng)用層：為用戶為用戶的應(yīng)用進(jìn)程提供網(wǎng)絡(luò)通信服務(wù)
協(xié)議——DNS協(xié)議、HTTP協(xié)議、HTTPS協(xié)議
- 傳輸層：負(fù)責(zé)兩臺(tái)主機(jī)之間的數(shù)據(jù)傳輸，將數(shù)據(jù)從發(fā)送端傳輸?shù)浇邮斩?/section>
協(xié)議——TCP協(xié)議、UDP協(xié)議
- 網(wǎng)絡(luò)層：負(fù)責(zé)傳輸?shù)牡刂饭芾砗吐酚蛇x擇，在眾多復(fù)雜的網(wǎng)絡(luò)環(huán)境中確定一條合適的路徑
- 數(shù)據(jù)鏈路層：負(fù)責(zé)設(shè)備之間數(shù)據(jù)幀的傳送和識(shí)別，將網(wǎng)絡(luò)層傳遞的數(shù)據(jù)報(bào)封裝成幀，在處于同一個(gè)數(shù)據(jù)數(shù)據(jù)鏈路節(jié)點(diǎn)的兩個(gè)設(shè)備之間傳輸
協(xié)議——ARP協(xié)議、MTU協(xié)議
- 物理層：負(fù)責(zé)光電信號(hào)的傳遞方式，實(shí)現(xiàn)相鄰計(jì)算機(jī)節(jié)點(diǎn)之間比特流的透明傳輸
對(duì)于五層網(wǎng)絡(luò)模型基本都是耳熟能詳，但是有沒(méi)有思考過(guò)，網(wǎng)絡(luò)為什么要這樣分層呢？海翎光電的小編接著分享。 最直接的回答就是為了簡(jiǎn)化網(wǎng)絡(luò)設(shè)計(jì)的復(fù)雜性，通信協(xié)議采用分層結(jié)構(gòu)，各層之間既相互獨(dú)立又相互協(xié)調(diào)工作，如此以來(lái)便達(dá)到的高效的目的。如同設(shè)計(jì)模式中對(duì)于設(shè)計(jì)一個(gè)復(fù)雜的程序時(shí)，盡量使程序各功能之間是解耦合的一樣，對(duì)于復(fù)雜的網(wǎng)絡(luò)設(shè)計(jì)，分層設(shè)計(jì)也是很明智的一種做法。 網(wǎng)絡(luò)分層的最本質(zhì)就是每一層獨(dú)立的完成一個(gè)任務(wù)而不必考慮自己任務(wù)之外的實(shí)現(xiàn)，而因?yàn)椴煌娜蝿?wù)因此就有了每一層所對(duì)應(yīng)的不同設(shè)備。(實(shí)例到應(yīng)用就是，物理層只需要關(guān)系0和1的光電信號(hào)如何傳輸，而對(duì)它所表達(dá)的內(nèi)容毫不關(guān)心；再往上數(shù)據(jù)鏈路層只需要關(guān)心封裝好的數(shù)據(jù)幀如何準(zhǔn)確的送到對(duì)應(yīng)的MAC地址的目的主機(jī)中，而不必關(guān)心數(shù)據(jù)報(bào)的具體內(nèi)容和具體會(huì)通過(guò)何種方式光纖還是局域網(wǎng)…同理往上對(duì)于所有層) 應(yīng)用層協(xié)議主要負(fù)責(zé)各個(gè)程序間的通信，發(fā)生網(wǎng)絡(luò)傳輸一個(gè)數(shù)據(jù)時(shí)，先由應(yīng)用層對(duì)數(shù)據(jù)按照對(duì)應(yīng)的協(xié)議封裝，然后交給下一層傳輸層，當(dāng)經(jīng)過(guò)一系列網(wǎng)絡(luò)傳輸，數(shù)據(jù)達(dá)到接收端時(shí)，一層層的分用，最后一層再由應(yīng)用層分用，最終得到數(shù)據(jù)。 DNS協(xié)議是一個(gè)應(yīng)用層協(xié)議，建立在TCP和UDP的基礎(chǔ)之上，使用默認(rèn)端口為53，其默認(rèn)通過(guò)UDP協(xié)議通信，但如果報(bào)文過(guò)大是則會(huì)切換成TCP協(xié)議。 域名系統(tǒng) (DNS) 的作用是將人類(lèi)可讀的域名轉(zhuǎn)換為機(jī)器可讀的 IP 地址 (如，192.0.2.44)，本質(zhì)是通過(guò)DNS域名和IP地址的對(duì)應(yīng)關(guān)系轉(zhuǎn)換，而這種對(duì)應(yīng)關(guān)系則保存在DNS服務(wù)器中
域名的解析工作大體上可以分為兩個(gè)步驟：第一步客戶端向本地DNS服務(wù)器發(fā)起一個(gè)DNS請(qǐng)求報(bào)文，報(bào)文里攜帶需要查詢(xún)的域名，第二步本地DNS服務(wù)器向本機(jī)回應(yīng)一個(gè)DNS響應(yīng)報(bào)文，報(bào)文里攜帶查詢(xún)域名所對(duì)應(yīng)的IP地址
|
1.在本地緩存中查詢(xún)，如果有則返回對(duì)應(yīng)IP，如果沒(méi)有將請(qǐng)求發(fā)給DNS服務(wù)器
2.當(dāng)本地DNS服務(wù)器接收到查詢(xún)后，先在服務(wù)器管理區(qū)域記錄中查詢(xún)，若沒(méi)有再在服務(wù)器本地緩存中查詢(xún)，如果沒(méi)有將請(qǐng)求發(fā)送到根域名服務(wù)器
3.根域名服務(wù)器負(fù)責(zé)解析請(qǐng)求的根域部分，然后將包含下一級(jí)域名信息的DNS服務(wù)地址返回給本地DNS服務(wù)器
4.本地DNS服務(wù)器利用根域名服務(wù)器解析的地址訪問(wèn)下一級(jí)DNS服務(wù)器，得到再下一級(jí)域的DNS服務(wù)器地址
5.按照上述遞歸方法逐級(jí)接近查詢(xún)目標(biāo)，最后在有目標(biāo)域名的DNS服務(wù)器上找到相應(yīng)的IP地址信息
6.本地DNS服務(wù)器將最終查詢(xún)到的IP返回給客戶端，讓客戶端訪問(wèn)對(duì)應(yīng)主機(jī)
|
HTTP協(xié)議是一個(gè)簡(jiǎn)單的請(qǐng)求——響應(yīng)協(xié)議，它通常運(yùn)行在TCP之上。它指定了客戶端可能發(fā)送給服務(wù)器什么樣的消息以及得到什么樣的響應(yīng)。 同其他應(yīng)用層協(xié)議一樣，是為了實(shí)現(xiàn)某一類(lèi)具體應(yīng)用的協(xié)議，并由某一運(yùn)行在用戶空間的應(yīng)用程序來(lái)實(shí)現(xiàn)其功能。HTTP是一種協(xié)議規(guī)范，這種規(guī)范記錄在文檔上，為真正通過(guò)HTTP進(jìn)行通信的HTTP的實(shí)現(xiàn)程序。HTTP是基于TCP協(xié)議，且面向連接的。典型的HTTP事務(wù)處理有如下的過(guò)程：3.服務(wù)器接受請(qǐng)求，并根據(jù)請(qǐng)求返回相應(yīng)的數(shù)據(jù)作為應(yīng)答響應(yīng)； HTTP報(bào)文由從客戶機(jī)到服務(wù)器的請(qǐng)求(Request)和從服務(wù)器到客戶機(jī)的響應(yīng)(Respone)構(gòu)成
-
請(qǐng)求由請(qǐng)求行，請(qǐng)求頭，請(qǐng)求體組成
-
請(qǐng)求行中包含請(qǐng)求方法、路徑、版本號(hào)，請(qǐng)求頭為多個(gè)key-value數(shù)據(jù)，請(qǐng)求正文包含一些請(qǐng)求的數(shù)據(jù)
-
響應(yīng)由響應(yīng)行，響應(yīng)頭，響應(yīng)體組成
-
響應(yīng)行中包含狀態(tài)碼，狀態(tài)碼描述，版本號(hào)，響應(yīng)頭為多個(gè)key-value數(shù)據(jù)，響應(yīng)正文包含一些響應(yīng)的數(shù)據(jù)
常見(jiàn)HTTP響應(yīng)狀態(tài)碼匯總
3XX系列
| 301 Moved Permanently ：請(qǐng)求的資源以被永久的移動(dòng)到新URL中，返回的Response中包含一個(gè)Location，瀏覽器會(huì)自動(dòng)重定向到新URL，以后請(qǐng)求都會(huì)被新的URL替代302 Found ：與301類(lèi)似，但請(qǐng)求的資源只是臨時(shí)的被移動(dòng)到新的URL中，下次請(qǐng)求客戶端繼續(xù)使用原URL307 Temporary Redirect ： 臨時(shí)重定向，類(lèi)似于302，使用GET請(qǐng)求重定向 |
4XX系列
| 400 Bad Request ：客戶端請(qǐng)求語(yǔ)法錯(cuò)誤，服務(wù)器無(wú)法理解（在 ajax 請(qǐng)求后臺(tái)數(shù)據(jù)時(shí)比較常見(jiàn)）401 Unauthorized ：請(qǐng)求要求用戶的身份認(rèn)證403 Forbidden ：服務(wù)器理解客戶端請(qǐng)求，但是拒絕執(zhí)行（一般用于用戶級(jí)別為達(dá)到要求等等不支持訪問(wèn)）404 Not Found ： 服務(wù)器無(wú)法根據(jù)客戶端請(qǐng)求找到對(duì)應(yīng)資源405 Method Not Allowed ： 服務(wù)器不支持該方法 |
5XX系列
| 500 Internal Server Error ：服務(wù)器內(nèi)部錯(cuò)誤，無(wú)法完成請(qǐng)求503 Service Unavailable ：由于超載或系統(tǒng)維護(hù)，服務(wù)器暫時(shí)的無(wú)法處理客戶端的請(qǐng)求。延時(shí)的長(zhǎng)度可包含在服務(wù)器的Retry-After頭信息中 |
HTTP協(xié)議的特點(diǎn)
-
支持服務(wù)器/客戶端模式
-
傳輸較快速，客戶端向服務(wù)器發(fā)送請(qǐng)求，只需要傳輸請(qǐng)求方法和路徑
-
靈活，HTTP允許傳輸任意類(lèi)型的數(shù)據(jù)對(duì)象
-
無(wú)連接，每次連接只能處理一個(gè)請(qǐng)求，服務(wù)器處理完客戶端請(qǐng)求，客戶端收到響應(yīng)后就斷開(kāi)連接
-
無(wú)狀態(tài)，協(xié)議本身對(duì)事務(wù)處理沒(méi)有記憶能力，如果后序連接需要之前發(fā)送的信息時(shí)就需要重傳
HTTP1.0和HTTP1.1和HTTP2.0的區(qū)別：
-
長(zhǎng)連接：HTTP1.0只支持瀏覽器與服務(wù)器的短連接，即每次請(qǐng)求都要重新建立連接，服務(wù)器無(wú)法記錄每個(gè)歷史請(qǐng)求，HTTP1.1支持長(zhǎng)連接即在一次連接下，瀏覽器可以向服務(wù)器發(fā)送多次請(qǐng)求
-
增加Host字段：HTTP1.0中認(rèn)為每個(gè)服務(wù)器都綁定這唯一一個(gè)IP，所有發(fā)送的請(qǐng)求頭URL中沒(méi)有host信息，而HTTP1.1在請(qǐng)求和響應(yīng)中都支持了host頭域，且請(qǐng)求消息中如果沒(méi)有Host頭域會(huì)報(bào)告一個(gè)錯(cuò)誤(400 Bad Request)
-
緩存：HTTP1.1在1.0的基礎(chǔ)上加入了一些cache的新特性，當(dāng)緩存對(duì)象的Age超過(guò)Expire時(shí)變?yōu)閟tale對(duì)象，cache不需要直接拋棄stale對(duì)象，而是與源服務(wù)器進(jìn)行重新激活（revalidation）。
-
錯(cuò)誤提示：HTTP1.0中定義了16個(gè)狀態(tài)碼，對(duì)錯(cuò)誤或警告的提示不夠具體。HTTP1.1引入了一個(gè)Warning頭域，增加對(duì)錯(cuò)誤或警告信息的描述，并且還新增了24個(gè)狀態(tài)響應(yīng)碼，如409(Conflict)表示請(qǐng)求的資源與資源的當(dāng)前狀態(tài)發(fā)生沖突；410(Gone)表示服務(wù)器上的某個(gè)資源被永久性的刪除
|
HTTP1.X和HTTP2.0的區(qū)別
-
增加二進(jìn)制格式解析：HTTP1.X解析基于文本，而文本格式本身就具有多樣性，很多場(chǎng)景下不方便，而引入二進(jìn)制后，只有0和1組合，使解析更加方便也增強(qiáng)了健壯性
-
多路復(fù)用：即每個(gè)request都是是用作連接共享機(jī)制的，每個(gè)request都對(duì)應(yīng)一個(gè)id，使一個(gè)連接可以有多個(gè)請(qǐng)求，再根據(jù)id將request歸屬到不同的服務(wù)端請(qǐng)求里
-
header壓縮：HTTP1.X中，每次傳輸都要寫(xiě)點(diǎn)header頭，占用了大量數(shù)據(jù)，因此HTTP2.0在客戶端和服務(wù)端各保存了一份header fields表，每次傳輸時(shí)只需傳輸header的更新信息，將header fields表更新即可實(shí)現(xiàn)header傳輸
-
服務(wù)端推送：HTTP2.0也添加了server push功能
|
HTTPS協(xié)議
HTTPS同樣作為應(yīng)用層協(xié)議，可以說(shuō)它是HTTP的升級(jí)版，增加了傳輸數(shù)據(jù)的安全性，HTTPS協(xié)議是在HTTP的基礎(chǔ)上增加了一個(gè)SSL外殼，HTTPS運(yùn)行在SSL上，SSL運(yùn)行在TCP上，對(duì)數(shù)據(jù)的加密工作就是在SSL上完成的
其保證安全性的做法是通過(guò)證書(shū)驗(yàn)證和對(duì)信息混合加密的方式
混合加密技術(shù)：
| 混合加密技術(shù)：結(jié)合對(duì)稱(chēng)加密與非對(duì)稱(chēng)加密服務(wù)端生成私鑰，再通過(guò)私鑰生成公鑰，然后將公鑰放在證書(shū)中頒發(fā)給客戶端使用公鑰和私鑰以非對(duì)稱(chēng)方式加密生成密鑰客戶端接下來(lái)的傳輸數(shù)據(jù)中，都會(huì)用密鑰以對(duì)稱(chēng)方式對(duì)信息加密，再傳輸給服務(wù)端 |
對(duì)于，上述提到的公鑰和私鑰，我們規(guī)定用公鑰加密的內(nèi)容必須用私鑰才能解開(kāi)，同樣，私鑰加密的內(nèi)容只有公鑰能解開(kāi) 所以HTTPS傳輸數(shù)據(jù)是用被密鑰加密的密文和用公鑰加密的私鑰來(lái)保證數(shù)據(jù)安全的
| HTTPS加密，只用對(duì)稱(chēng)加密可以嗎？ 不行！無(wú)法保證安全性，因?yàn)橹挥脤?duì)稱(chēng)加密即只用密鑰對(duì)數(shù)據(jù)加密傳輸?shù)脑挘绻麄鬏斖局校畔⒈坏谌浇俪郑@取到密鑰，那接下來(lái)的傳輸，第三方都可以通過(guò)密鑰對(duì)數(shù)據(jù)解密從而得到原始數(shù)據(jù)。 |
| HTTPS加密，只用非對(duì)稱(chēng)加密可以嗎？?jī)纱文兀?/strong> 同樣不行，如果只用非對(duì)稱(chēng)加密。客戶端每次傳輸數(shù)據(jù)用公鑰加密，服務(wù)端再用私鑰解密這一方向看似安全，但當(dāng)服務(wù)端發(fā)送數(shù)據(jù)用私鑰加密，客戶端收到用公鑰解密時(shí)，第三方劫持到信息，但可能在此之前就獲得公鑰，因?yàn)槭状畏?wù)端向客戶端發(fā)送公鑰是明文傳輸?shù)摹?/section> 而換個(gè)角度如果使用兩次非對(duì)稱(chēng)加密，即兩組公鑰，兩組私鑰，客戶端服務(wù)端各持一組，理論上可以達(dá)到安全，但實(shí)際HTTPS并未采用，因?yàn)榉菍?duì)稱(chēng)加密耗時(shí)十分大 |
單有混合加密技術(shù)，看似已經(jīng)保證了傳輸?shù)陌踩裕瑢?shí)則還是有漏洞，問(wèn)題就在于服務(wù)器根本無(wú)法識(shí)別發(fā)送過(guò)來(lái)的公鑰是否是自己的，如此以來(lái)在第三方劫持到數(shù)據(jù)后，自行再定義一個(gè)公鑰B，并將公鑰B傳回給客服端，此時(shí)客戶端就會(huì)利用該公鑰B重新加密數(shù)據(jù)然后發(fā)送，此時(shí)第三方就可以通過(guò)自己的公鑰B解密得到原始數(shù)據(jù)了。 證書(shū)就解決了這一問(wèn)題，指定頒發(fā)的為CA機(jī)構(gòu)，當(dāng)網(wǎng)站使用HTTPS時(shí)，會(huì)向CA機(jī)構(gòu)申請(qǐng)一個(gè)數(shù)字證書(shū)，證書(shū)中可以存放公鑰、數(shù)據(jù)等信息，由此以來(lái)，服務(wù)端就可以通過(guò)證書(shū)來(lái)向客戶端證明正確的公鑰是哪一個(gè)，以此保證安全。 而對(duì)于證書(shū)，還有一些自己的放篡改機(jī)制，防止第三方獲取到使用
