网络协议知识总结
網(wǎng)絡(luò)協(xié)議知識(shí)總結(jié)
協(xié)議
協(xié)議就是計(jì)算機(jī)之間通過(guò)網(wǎng)絡(luò)實(shí)現(xiàn)通信時(shí)事先達(dá)成的一種“約定”；這種“約定”使那些由不同廠商的設(shè)備，不同 CPU 及不同操作系統(tǒng)組成的計(jì)算機(jī)之間，只要遵循相同的協(xié)議就可以實(shí)現(xiàn)通信。
OSI/RM 模型
TCP/IP
除了標(biāo)準(zhǔn)的 OSI 七層模型以外，常見(jiàn)的網(wǎng)絡(luò)層次劃分還有 TCP/IP 四層協(xié)議以及 TCP/IP
五層協(xié)議；它們之間的對(duì)應(yīng)關(guān)系如下圖所示：
有人可能會(huì)認(rèn)為 TCP/IP 是指 TCP 和 IP 兩種協(xié)議。實(shí)際生活當(dāng)中有時(shí)也確實(shí)就是指這兩種協(xié)議。然而在很多情況下，它只是利用 IP 進(jìn)行通信時(shí)所必須用到的協(xié)議群的統(tǒng)稱(chēng)。具體來(lái)說(shuō)，IP 或 ICMP、TCP 或 UDP、TELNET 或 FTP、以及 HTTP等都屬于 TCP/IP 協(xié)議。他們與 TCP 或 IP 的關(guān)系緊密，是互聯(lián)網(wǎng)必不可少的組成部分。TCP/IP 一詞泛指這些協(xié)議，因此，有時(shí)也稱(chēng) TCP/IP 為網(wǎng)絡(luò)協(xié)議群。
應(yīng)用協(xié)議
應(yīng)用協(xié)議是定義了運(yùn)行在不同系統(tǒng)上的應(yīng)用程序進(jìn)程如何相互傳遞報(bào)文的協(xié)議。
傳輸協(xié)議
傳輸層提供了進(jìn)程間的邏輯通信，傳輸層向高層用戶屏蔽了下面網(wǎng)絡(luò)層的核心細(xì)節(jié)，使
應(yīng)用程序看起來(lái)像是在兩個(gè)傳輸層實(shí)體之間有一條端到端的邏輯通信通道。
網(wǎng)際協(xié)議
網(wǎng)際協(xié)議是一個(gè)網(wǎng)絡(luò)層協(xié)議，它包含尋址信息和控制信息 ，可使數(shù)據(jù)包在網(wǎng)絡(luò)中路由。
路由控制協(xié)議
路由控制協(xié)議是一種網(wǎng)絡(luò)層協(xié)議，它通過(guò)提供一種共享路由選擇信息的機(jī)制，允許路由
器與其他路由器通信以更新和維護(hù)自己的路由表，并確定最佳的路由選擇路徑。通過(guò)路由選
擇協(xié)議，路由器可以了解未直接連接的網(wǎng)絡(luò)的狀態(tài)，當(dāng)網(wǎng)絡(luò)發(fā)生變化時(shí)，路由表中的信息可
以隨時(shí)更新，以保證網(wǎng)絡(luò)上的路由選擇路徑處于可用狀態(tài)。
TCP 協(xié)議傳輸特點(diǎn)
TCP 是一個(gè)可靠的傳輸協(xié)議，在創(chuàng)建連接時(shí)會(huì)經(jīng)歷三次握手，在斷開(kāi)連接時(shí)會(huì)經(jīng)歷四次
揮手。
建立連接的三次握手
所謂三次握手是指建立一個(gè) TCP 連接時(shí)需要客戶端和服務(wù)器端總共發(fā)送三個(gè)包以確認(rèn)連接的建立。
斷開(kāi)連接的四次揮手
四次揮手即終止 TCP 連接，就是指斷開(kāi)一個(gè) TCP 連接時(shí)，需要客戶端和服務(wù)端總共發(fā)送4 個(gè)包以確認(rèn)連接的斷開(kāi)。
HTTP 協(xié)議
?HTTP 協(xié)議是 Hyper Text Transfer Protocol（超文本傳輸協(xié)議）的縮寫(xiě), HTTP 是萬(wàn)維網(wǎng)
（WWW:World Wide Web）的數(shù)據(jù)通信的基礎(chǔ)。
?HTTP 是一個(gè)簡(jiǎn)單的請(qǐng)求-響應(yīng)協(xié)議，它通常運(yùn)行在 TCP 之上。它指定了客戶端可能發(fā)送給服務(wù)器什么樣的消息以及得到什么樣的響應(yīng)。
HTTP是一個(gè)基于TCP/IP通信協(xié)議來(lái)傳遞數(shù)據(jù)（HTML 文件, 圖片文件, 查詢結(jié)果等）。
超文本
超文本是用超鏈接的方法，將各種不同空間的文字信息組織在一起的網(wǎng)狀文本。超文本
更是一種用戶界面范式，用以顯示文本及與文本之間相關(guān)的內(nèi)容。
HTTP 協(xié)議特點(diǎn)
支持客戶/服務(wù)器模式
HTTP 協(xié)議支持客戶端服務(wù)端模式，需要使用瀏覽器作為客戶端來(lái)訪問(wèn)服務(wù)端。
簡(jiǎn)單快速
客戶向服務(wù)器請(qǐng)求服務(wù)時(shí)，只需傳送請(qǐng)求方法和路徑。請(qǐng)求方法常用的有 GET、POST等。每種方法規(guī)定了客戶與服務(wù)器聯(lián)系的類(lèi)型不同。由于 HTTP 協(xié)議簡(jiǎn)單，使得 HTTP 服務(wù)器的程序規(guī)模小，因而通信速度很快。
靈活
HTTP 允許傳輸任意類(lèi)型的數(shù)據(jù)對(duì)象。正在傳輸?shù)念?lèi)型由 Content-Type（Content-Type 是HTTP 包中用來(lái)表示內(nèi)容類(lèi)型的標(biāo)識(shí)）加以標(biāo)記。
無(wú)連接
每次請(qǐng)求一次，釋放一次連接。所以無(wú)連接表示每次連接只能處理一個(gè)請(qǐng)求。優(yōu)點(diǎn)就是節(jié)省傳輸時(shí)間，實(shí)現(xiàn)簡(jiǎn)單。我們有時(shí)稱(chēng)這種無(wú)連接為短連接。對(duì)應(yīng)的就有了長(zhǎng)鏈接，長(zhǎng)連接專(zhuān)門(mén)解決效率問(wèn)題。當(dāng)建立好了一個(gè)連接之后，可以多次請(qǐng)求。但是缺點(diǎn)就是容易造成占用資源不釋放的問(wèn)題。當(dāng) HTTP 協(xié)議頭部中字段 Connection：keep-alive 表示支持長(zhǎng)鏈接。
單向性
服務(wù)端永遠(yuǎn)是被動(dòng)的等待客戶端的請(qǐng)求。
無(wú)狀態(tài)
HTTP 協(xié)議是無(wú)狀態(tài)協(xié)議。無(wú)狀態(tài)是指協(xié)議對(duì)于事務(wù)處理沒(méi)有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務(wù)器不需要先前信息時(shí)它的應(yīng)答就較快。為了解決 HTTP 協(xié)議無(wú)狀態(tài)，于是，
兩種用于保持 HTTP 連接狀態(tài)的技術(shù)就應(yīng)運(yùn)而生了，一個(gè)是 Cookie，而另一個(gè)則是 Session。
HTTP 協(xié)議中 URI、URL、URN
URI
URI：（Uniform Resource Identifier），統(tǒng)一資源標(biāo)識(shí)符，是一個(gè)用于標(biāo)識(shí)某一互聯(lián)網(wǎng)資
源名稱(chēng)的字符串。URL 和 URN 都是 URI 的子集。
例
發(fā)送郵件
URI 是個(gè)純粹的句法結(jié)構(gòu)，用于指定標(biāo)識(shí) Web 資源的字符串的各個(gè)不同部分。他不屬
于定位符，因?yàn)楦鶕?jù)該標(biāo)識(shí)符無(wú)法定位任何資源。
URL
URL(Uniform Resource Location 統(tǒng)一資源定位符)，可以幫助我們唯一定位互聯(lián)網(wǎng)上的某一個(gè)資源，相當(dāng)于是互聯(lián)網(wǎng)資源的身份證號(hào)。URL 的五個(gè)元素包括在一個(gè)簡(jiǎn)單的地址中：
1.傳送協(xié)議。
2.服務(wù)器。（通常為域名或者 IP 地址）
3.端口號(hào)。（以數(shù)字方式表示，若為 HTTP 的默認(rèn)值“:80”可省略）
4.請(qǐng)求資源路徑。
5.傳遞數(shù)據(jù)。（在 URL 中傳遞數(shù)據(jù)是以 key=value 的結(jié)構(gòu)進(jìn)行數(shù)據(jù)綁定，以“?”字符為起點(diǎn)，每個(gè)參數(shù)以“&”隔開(kāi)，再以“=”分開(kāi)參數(shù)名稱(chēng)與數(shù)據(jù)，通常以 UTF8 的 URL 編碼，避開(kāi)字符沖突的問(wèn)題）
例
http://www.itbaizhan.cn:80/course/id/18.html?a=3&b=4
?http, 是協(xié)議；
?www.itbaizhan.cn，是服務(wù)器域名；
?80，是服務(wù)器上的默認(rèn)網(wǎng)絡(luò)端口號(hào)，默認(rèn)不顯示；
?/course/id/18.html，是路徑（URI：直接定位到對(duì)應(yīng)的資源）；
??a=3&b=4，請(qǐng)求時(shí)傳遞的數(shù)據(jù)；
URN
URN（Uniform Resource Name，統(tǒng)一資源名稱(chēng)），其目的是通過(guò)提供一種途徑，用于在
特定的命名空間資源的標(biāo)識(shí)，以補(bǔ)充網(wǎng)址。
例
www.itbaizhan.cn:80/course/id/18.html?a=3&b=4
URN 是 URI 的子集，包括名字(給定的命名空間內(nèi))，相當(dāng)于URL去掉協(xié)議后的部分就是URN;
HTTP 協(xié)議中的請(qǐng)求信息
打開(kāi)一個(gè)網(wǎng)頁(yè)需要瀏覽器發(fā)送很多次 Request（請(qǐng)求）
1.在瀏覽器輸入 URL http://www.itbaizhan.cn 的時(shí)候，瀏覽器發(fā)送一個(gè) Request 去獲取 http://www.itbaizhan.cn 的 html. 服務(wù)器把 Response 發(fā)送回給瀏覽器。
（如果沒(méi)有給定請(qǐng)求資源的路徑以及名稱(chēng)，默認(rèn)的是請(qǐng)求站點(diǎn)首頁(yè)的資源；）
2.瀏覽器分析 Response 中的 HTML，發(fā)現(xiàn)其中引用了很多其他文件，比如圖片，CSS 文件，JS 文件。
3.瀏覽器會(huì)自動(dòng)再次發(fā)送 Request 去獲取圖片，CSS 文件，或者 JS 文件。
4.等所有的文件都下載成功后。 網(wǎng)頁(yè)就被顯示出來(lái)了。
請(qǐng)求狀態(tài)分析(request)
Request 消息分為 3 部分，第一部分叫 Request line（請(qǐng)求行）, 第二部分叫 Request header（請(qǐng)求頭）, 第三部分是 Request body（請(qǐng)求體）。Request header 和 Request body 之間有個(gè)空行。
客戶端發(fā)送一個(gè) HTTP 請(qǐng)求到服務(wù)器的請(qǐng)求消息包括以下格式：
?請(qǐng)求行
?請(qǐng)求頭
請(qǐng)求頭用于說(shuō)明是誰(shuí)或什么在發(fā)送請(qǐng)求、請(qǐng)求源于何處，或者客戶端的喜好及能力。服
務(wù)器可以根據(jù)請(qǐng)求頭部給出的客戶端信息，試著為客戶端提供更好的響應(yīng)。請(qǐng)求頭中信 息的格式為 key：value。
?請(qǐng)求體
客戶端傳遞給服務(wù)器的數(shù)據(jù)。比如：表單使用 post 方式提交的數(shù)據(jù)、上傳的文件數(shù)據(jù)等。
請(qǐng)求方式
? GET
向指定的資源發(fā)出“顯示”請(qǐng)求。GET 請(qǐng)求中會(huì)將請(qǐng)求中傳遞的數(shù)據(jù)包含在 URL 中并在
瀏覽器的地址欄中顯示。GET 請(qǐng)求傳遞數(shù)據(jù)時(shí)要求數(shù)據(jù)必須是 ASCII 字符。GET 請(qǐng)求 可以被瀏覽器緩存。
? POST
向指定資源提交數(shù)據(jù)，請(qǐng)求服務(wù)器進(jìn)行處理（例如提交表單或者上傳文件）。數(shù)據(jù)被包
含在請(qǐng)求體中。POST 請(qǐng)求傳遞數(shù)據(jù)時(shí)，數(shù)據(jù)可以是ASCII 字符也可以是字節(jié)型數(shù)據(jù)， 默認(rèn)為字符型。POST 請(qǐng)求默認(rèn)情況下不會(huì)被瀏覽器所緩存。
?GET 和 POST 的區(qū)別(重要,面試常問(wèn))
1.GET 在瀏覽器回退時(shí)是無(wú)害的，而 POST 會(huì)再次提交請(qǐng)求。
2.GET 產(chǎn)生的 URL 地址可以被 Bookmark（添加到書(shū)簽），而 POST 不可以。
3.GET 請(qǐng)求會(huì)被瀏覽器主動(dòng) cache（緩存），而 POST 不會(huì)，除非手動(dòng)設(shè)置。
4.GET 請(qǐng)求只能進(jìn)行 url 編碼，而 POST 支持多種編碼方式。
5.GET 請(qǐng)求參數(shù)會(huì)被完整保留在瀏覽器歷史記錄里，而 POST 中的參數(shù)不會(huì)被保留。
6.GET 請(qǐng)求在 URL 中傳送的參數(shù)是有長(zhǎng)度限制的，而 POST 則沒(méi)有。對(duì)參數(shù)的數(shù)據(jù)類(lèi)型 GET只接受字符類(lèi)型，而 POST 即可是字符也可是字節(jié)。
7.GET 比 POST 更不安全，因?yàn)閰?shù)直接暴露在 URL 上，所以不能用來(lái)傳遞敏感信息。
8.GET 參數(shù)通過(guò) URL 傳遞，POST 放在 Request body （請(qǐng)求體）中。
HTTP 協(xié)議中的響應(yīng)信息
響應(yīng)狀態(tài)分析（response）
Response 消息也由三部分組成：第一部分叫 Response line（響應(yīng)行）、第二部分叫 Response header（響應(yīng)頭）、第三部分叫 Response body（響應(yīng)體）。
服務(wù)端為瀏覽器返回消息格式如下：
?響應(yīng)行
1.響應(yīng)行中的狀態(tài)碼
和請(qǐng)求消息相比，響應(yīng)消息多了一個(gè)“響應(yīng)狀態(tài)碼”，它以“清晰明確”的語(yǔ)言告訴客 戶端本次請(qǐng)求的處理結(jié)果。
2.http 狀態(tài)碼分類(lèi)
3.常見(jiàn)狀態(tài)碼及含義
200 - 請(qǐng)求成功，已經(jīng)正常處理完畢
301 - 請(qǐng)求永久重定向，轉(zhuǎn)移到其它 URL
302 - 請(qǐng)求臨時(shí)重定向
304 - 請(qǐng)求被重定向到客戶端本地緩存
400 - 客戶端請(qǐng)求存在語(yǔ)法錯(cuò)誤
401 - 客戶端請(qǐng)求沒(méi)有經(jīng)過(guò)授權(quán)
403 - 客戶端的請(qǐng)求被服務(wù)器拒絕，一般為客戶端沒(méi)有訪問(wèn)權(quán)限
404 - 資源未找到，客戶端請(qǐng)求的 URL 在服務(wù)端不存在
500 - 服務(wù)端出現(xiàn)異常
?響應(yīng)頭
響應(yīng)頭用于告知瀏覽器當(dāng)前響應(yīng)中的詳細(xì)信息，瀏覽器通過(guò)獲取響應(yīng)頭中的信息可以知
道應(yīng)該如何處理響應(yīng)結(jié)果。響應(yīng)頭中信息的格式為 key：value。
（請(qǐng)求頭是為了瀏覽器在請(qǐng)求服務(wù)端時(shí)能夠傳遞更多的請(qǐng)求信息，響應(yīng)頭在服務(wù)端給客 戶端瀏覽器產(chǎn)生響應(yīng)時(shí)能夠傳遞更多的響應(yīng)信息！）
Content-Type
表示響應(yīng)的文檔屬于什么 MIME 類(lèi)型。
?MIME 類(lèi)型
MIME(Multipurpose Internet Mail Extensions)多用途互聯(lián)網(wǎng)郵件擴(kuò)展類(lèi)型。是設(shè)定某種擴(kuò)
展名的文件用一種應(yīng)用程序來(lái)打開(kāi)的方式類(lèi)型，當(dāng)該擴(kuò)展名文件被訪問(wèn)的時(shí)候，瀏覽器 會(huì)自動(dòng)使用指定應(yīng)用程序來(lái)打開(kāi)。多用于指定一些客戶端自定義的文件名，以及一些媒 體文件打開(kāi)方式。
?MIME 類(lèi)型的作用
HTTP 協(xié)議所產(chǎn)生的響應(yīng)中正文部分可以是任意格式的數(shù)據(jù)，那么如何保證接收方能看
得懂發(fā)送方發(fā)送的正文數(shù)據(jù)呢？HTTP 協(xié)議采用 MIME 協(xié)議來(lái)規(guī)范正文的數(shù)據(jù)格式。
?MIME 類(lèi)型的使用
在服務(wù)端我們可以設(shè)置響應(yīng)頭中 Content-Type 的值來(lái)指定響應(yīng)類(lèi)型。
?響應(yīng)體
就是響應(yīng)的消息體，如果是純數(shù)據(jù)就是返回純數(shù)據(jù)，如果請(qǐng)求的是 HTML 頁(yè)面，那么 返回的就是 HTML 代碼，如果是 JS 就是 JS 代碼，如此之類(lèi)。
總結(jié)
- 上一篇： 两周的时间教会我，要低头做人（jQuer
- 下一篇： GET 和 POST 的区别(重要,面试