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