計算機網路概念匯總

1. 模型結構

五層模型：

應用層、傳輸層、網路層、資料鏈路層、物理層，

• 應用層：為應用程式提供互動服務，在互聯網中的應用層協議很多，如域名系統DNS、HTTP協議、SMTP協議等，
• 傳輸層：負責向兩臺主機行程之間的通信提供資料傳輸服務，傳輸層的協議主要有傳輸控制協議TCP和用戶資料協議UDP，
• 網路層：選擇合適的路由和交換結點，確保資料及時傳送，主要包括IP協議，
• 資料鏈路層：在兩個相鄰節點之間傳送資料時，資料鏈路層將網路層交下來的 IP 資料報組裝成幀，在兩個相鄰節點間的鏈路上傳送幀，
• 物理層：實作相鄰節點間位元流的透明傳輸，盡可能屏蔽傳輸介質和物理設備的差異，

ISO七層模型

是國際標準化組織（International Organization for Standardization）制定的一個用于計算機或通信系統間互聯的標準體系，

• 應用層：網路服務與最終用戶的一個介面，常見的協議有：HTTP FTP SMTP SNMP DNS.
• 表示層：資料的表示、安全、壓縮，，確保一個系統的應用層所發送的資訊可以被另一個系統的應用層讀取，
• 會話層：建立、管理、終止會話,對應主機行程，指本地主機與遠程主機正在進行的會話.
• 傳輸層：定義傳輸資料的協議埠號，以及流控和差錯校驗,協議有TCP UDP.
• 網路層：進行邏輯地址尋址，實作不同網路之間的路徑選擇,協議有ICMP IGMP IP等.
• 資料鏈路層：在物理層提供位元流服務的基礎上，建立相鄰結點之間的資料鏈路，
• 物理層：建立、維護、斷開物理連接，

TCP/IP 四層模型

• 應用層：對應于OSI參考模型的（應用層、表示層、會話層），
• 傳輸層: 對應OSI的傳輸層，為應用層物體提供端到端的通信功能，保證了資料包的順序傳送及資料的完整性，
• 網際層：對應于OSI參考模型的網路層，主要解決主機到主機的通信問題，
• 網路介面層：與OSI參考模型的資料鏈路層、物理層對應，

2. 三次握手

假設發送端為客戶端，接收端為服務端，開始時客戶端和服務端的狀態都是CLOSED，

1. 第一次握手：客戶端向服務端發起建立連接請求，客戶端會隨機生成一個起始序列號x，客戶端向服務端發送的欄位中包含標志位SYN=1，序列號seq=x，第一次握手前客戶端的狀態為CLOSE，第一次握手后客戶端的狀態為SYN-SENT，此時服務端的狀態為LISTEN，
2. 第二次握手：服務端在收到客戶端發來的報文后，會隨機生成一個服務端的起始序列號y，然后給客戶端回復一段報文，其中包括標志位SYN=1，ACK=1，序列號seq=y，確認號ack=x+1，第二次握手前服務端的狀態為LISTEN，第二次握手后服務端的狀態為SYN-RCVD，此時客戶端的狀態為SYN-SENT，（其中SYN=1表示要和客戶端建立一個連接，ACK=1表示確認序號有效）
3. 第三次握手：客戶端收到服務端發來的報文后，會再向服務端發送報文，其中包含標志位ACK=1，序列號seq=x+1，確認號ack=y+1，第三次握手前客戶端的狀態為SYN-SENT，第三次握手后客戶端和服務端的狀態都為ESTABLISHED，此時連接建立完成，

之所以需要第三次握手，主要為了防止已失效的連接請求報文段突然又傳輸到了服務端，導致產生問題，

• 比如客戶端A發出連接請求，可能因為網路阻塞原因，A沒有收到確認報文，于是A再重傳一次連接請求，
• 然后連接成功，等待資料傳輸完畢后，就釋放了連接，
• 然后A發出的第一個連接請求等到連接釋放以后的某個時間才到達服務端B，此時B誤認為A又發出一次新的連接請求，于是就向A發出確認報文段，
• 如果不采用三次握手，只要B發出確認，就建立新的連接了，此時A不會回應B的確認且不發送資料，則B一直等待A發送資料，浪費資源，

3. 四次握手

1. A的應用行程先向其TCP發出連接釋放報文段（FIN=1，seq=u），并停止再發送資料，主動關閉TCP連接，進入FIN-WAIT-1（終止等待1）狀態，等待B的確認，
2. B收到連接釋放報文段后即發出確認報文段（ACK=1，ack=u+1，seq=v），B進入CLOSE-WAIT（關閉等待）狀態，此時的TCP處于半關閉狀態，A到B的連接釋放，
3. A收到B的確認后，進入FIN-WAIT-2（終止等待2）狀態，等待B發出的連接釋放報文段，
4. B發送完資料，就會發出連接釋放報文段（FIN=1，ACK=1，seq=w，ack=u+1），B進入LAST-ACK（最后確認）狀態，等待A的確認，
5. A收到B的連接釋放報文段后，對此發出確認報文段（ACK=1，seq=u+1，ack=w+1），A進入TIME-WAIT（時間等待）狀態，此時TCP未釋放掉，需要經過時間等待計時器設定的時間2MSL（最大報文段生存時間）后，A才進入CLOSED狀態，B收到A發出的確認報文段后關閉連接，若沒收到A發出的確認報文段，B就會重傳連接釋放報文段，

第四次揮手為什么要等待2MSL？

• 保證A發送的最后一個ACK報文段能夠到達B，這個ACK報文段有可能丟失，B收不到這個確認報文，就會超時重傳連接釋放報文段，然后A可以在2MSL時間內收到這個重傳的連接釋放報文段，接著A重傳一次確認，重新啟動2MSL計時器，最后A和B都進入到CLOSED狀態，若A在TIME-WAIT狀態不等待一段時間，而是發送完ACK報文段后立即釋放連接，則無法收到B重傳的連接釋放報文段，所以不會再發送一次確認報文段，B就無法正常進入到CLOSED狀態，
• 防止已失效的連接請求報文段出現在本連接中，A在發送完最后一個ACK報文段后，再經過2MSL，就可以使這個連接所產生的所有報文段都從網路中消失，使下一個新的連接中不會出現舊的連接請求報文段，

為什么是四次揮手？

因為當Server端收到Client端的SYN連接請求報文后，可以直接發送SYN+ACK報文，但是在關閉連接時，當Server端收到Client端發出的連接釋放報文時，很可能并不會立即關閉SOCKET，所以Server端先回復一個ACK報文，告訴Client端我收到你的連接釋放報文了，只有等到Server端所有的報文都發送完了，這時Server端才能發送連接釋放報文，之后兩邊才會真正的斷開連接，故需要四次揮手，

4. 說說TCP報文首部有哪些欄位，其作用又分別是什么？

• 16位埠號：源埠號，主機該報文段是來自哪里；目標埠號，要傳給哪個上層協議或應用程式
• 32位序號：一次TCP通信（從TCP連接建立到斷開）程序中某一個傳輸方向上的位元組流的每個位元組的編號，
• 32位確認號：用作對另一方發送的tcp報文段的回應，其值是收到的TCP報文段的序號值加1，
• 4位頭部長度：表示tcp頭部有多少個32bit字（4位元組），因為4位最大能標識15，所以TCP頭部最長是60位元組，
• 6位標志位：URG(緊急指標是否有效)，ACk（表示確認號是否有效），PSH（緩沖區尚未填滿），RST（表示要求對方重新建立連接），SYN（建立連接訊息標志接），FIN（表示告知對方本端要關閉連接了）
• 16位視窗大小：是TCP流量控制的一個手段，這里說的視窗，指的是接收通告視窗，它告訴對方本端的TCP接識訓沖區還能容納多少位元組的資料，這樣對方就可以控制發送資料的速度，
• 16位校驗和：由發送端填充，接收端對TCP報文段執行CRC演算法以檢驗TCP報文段在傳輸程序中是否損壞，注意，這個校驗不僅包括TCP頭部，也包括資料部分，這也是TCP可靠傳輸的一個重要保障，
• 16位緊急指標：一個正的偏移量，它和序號欄位的值相加表示最后一個緊急資料的下一位元組的序號，因此，確切地說，這個欄位是緊急指標相對當前序號的偏移，不妨稱之為緊急偏移，TCP的緊急指標是發送端向接收端發送緊急資料的方法，

5. TCP的粘包和拆包

TCP是面向流，沒有界限的一串資料，TCP底層并不了解上層業務資料的具體含義，它會根據TCP緩沖區的實際情況進行包的劃分，所以在業務上認為，一個完整的包可能會被TCP拆分成多個包進行發送，也有可能把多個小的包封裝成一個大的資料包發送，這就是所謂的TCP粘包和拆包問題，

為什么會產生粘包和拆包呢?

• 要發送的資料小于TCP發送緩沖區的大小，TCP將多次寫入緩沖區的資料一次發送出去，將會發生粘包；
• 接收資料端的應用層沒有及時讀取接識訓沖區中的資料，將發生粘包；
• 要發送的資料大于TCP發送緩沖區剩余空間大小，將會發生拆包；
• 待發送資料大于MSS（最大報文長度），TCP在傳輸前將進行拆包，即TCP報文長度-TCP頭部長度>MSS，

解決方案：

• 發送端將每個資料包封裝為固定長度
• 在資料尾部增加特殊字符進行分割
• 將資料分為兩部分，一部分是頭部，一部分是內容體；其中頭部結構大小固定，且有一個欄位宣告內容體的大小，

6. TCP的滑動視窗機制

TCP 利用滑動視窗實作流量控制，流量控制是為了控制發送方發送速率，保證接收方來得及接收， TCP會話的雙方都各自維護一個發送視窗和一個接收視窗，接收視窗大小取決于應用、系統、硬體的限制，發送視窗則取決于對端通告的接收視窗，接收方發送的確認報文中的window欄位可以用來控制發送方視窗大小，從而影響發送方的發送速率，將接收方的確認報文window欄位設定為 0，則發送方不能發送資料，

7. 擁塞控制

慢開始

把擁塞視窗 cwnd 設定為一個最大報文段MSS的數值，而在每收到一個對新的報文段的確認后，把擁塞視窗增加至多一個MSS的數值，每經過一個傳輸輪次，擁塞視窗 cwnd 就加倍， 為了防止擁塞視窗cwnd增長過大引起網路擁塞，還需要設定一個慢開始門限ssthresh狀態變數，

當 cwnd < ssthresh 時，使用慢開始演算法，

當 cwnd > ssthresh 時，停止使用慢開始演算法而改用擁塞避免演算法，

當 cwnd = ssthresh 時，既可使用慢開始演算法，也可使用擁塞控制避免演算法，

根據上面的解釋，分析一下圖示曲線的走勢情況：

1. TCP 連接進行初始化時，把擁塞視窗 cwnd 置為 1，
2. 當執行慢開始演算法時，擁塞視窗 cwnd 的初始值為 1，以后發送方每收到一個對新報文段的確認 ACK，就把擁塞視窗值加 1，然后開始下一輪的傳輸（請注意，圖示的橫坐標是傳輸輪次），因此擁塞視窗 cwnd 隨著傳輸輪次按指數規律增長，當擁塞視窗 cwnd 增長到慢開始門限值 ssthresh 時（即當 cwnd = 16時），就改為執行擁塞避免演算法，擁塞視窗按線性規律增長，
3. 假定擁塞視窗的數值增長到 24 時，網路出現超時（這很可能就是網路發生擁塞了），更新后的 ssthresh 值變為 12（即變為出現超時時的擁塞視窗數值 24的一半），擁塞視窗再重新設定為 1，并執行慢開始演算法，當 cwnd = ssthresh = 12 時改為執行擁塞避免演算法，擁塞視窗按線性規律增長，每經過一個往返時間增加一個 MSS 的大小，

擁塞避免

讓擁塞視窗cwnd緩慢地增大，每經過一個往返時間RTT就把發送方的擁塞視窗cwnd加1，而不是加倍，這樣擁塞視窗cwnd按線性規律緩慢增長，

無論在慢開始階段還是在擁塞避免階段，只要發送方判斷網路出現擁塞（其根據就是沒有收到確認），就要把慢開始門限ssthresh設定為出現擁塞時的發送 方視窗值的一半（但不能小于2），然后把擁塞視窗cwnd重新設定為1，執行慢開始演算法，這樣做的目的就是要迅速減少主機發送到網路中的分組數，使得發生 擁塞的路由器有足夠時間把佇列中積壓的分組處理完畢，

快重傳

有時個別報文段會在網路中丟失，但實際上網路并未發生擁塞，如果發送方遲遲收不到確認，就會產生超時，就會誤認為網路發生了擁塞，這就導致發送方錯誤地啟動慢開始，把擁塞視窗cwnd又設定為1，因而降低了傳輸效率，

快重傳演算法可以避免這個問題，快重傳演算法首先要求接收方每收到一個失序的報文段后就立即發出重復確認，使發送方及早知道有報文段沒有到達對方，

發送方只要一連收到三個重復確認就應當立即重傳對方尚未收到的報文段，而不必繼續等待重傳計時器到期，由于發送方盡早重傳未被確認的報文段，因此采用快重傳后可以使整個網路吞吐量提高約20%，

快恢復

當發送方連續收到三個重復確認，就會把慢開始門限ssthresh減半，接著把cwnd值設定為慢開始門限ssthresh減半后的數值，然后開始執行擁塞避免演算法，使擁塞視窗緩慢地線性增大，

在采用快恢復演算法時，慢開始演算法只是在TCP連接建立時和網路出現超時時才使用， 采用這樣的擁塞控制方法使得TCP的性能有明顯的改進，

8. POST和GET的區別？

• GET 和 POST 最本質的區別是規范上的區別，在規范中，定義 GET 請求是用來獲取資源的，也就是進行查詢操作的，而 POST 請求是用來傳輸物體物件的，因此會使用 POST 來進行添加、修改和洗掉等操作，
• GET請求引數通過URL傳遞，POST的引數放在請求體中，
• GET 請求可以直接進行回退和重繪，不會對用戶和程式產生任何影響；而 POST 請求如果直接回滾和重繪將會把資料再次提交，
• GET產生一個TCP資料包；POST產生兩個TCP資料包，對于GET方式的請求，瀏覽器會把請求頭和請求體一并發送出去；而對于POST，瀏覽器先發送請求頭，服務器回應100 continue，瀏覽器再發送請求體，
• GET 請求一般會被快取，比如常見的 CSS、JS、HTML 請求等都會被快取；而 POST 請求默認是不進行快取的，
• GET請求引數會被完整保留在瀏覽器歷史記錄里，而POST中的引數不會被保留，

9. 什么是cookie和session？

由于HTTP協議是無狀態的協議，需要用某種機制來識具體的用戶身份，用來跟蹤用戶的整個會話，常用的會話跟蹤技術是cookie與session，

cookie就是由服務器發給客戶端的特殊資訊，而這些資訊以文本檔案的方式存放在客戶端，然后客戶端每次向服務器發送請求的時候都會帶上這些特殊的資訊，說得更具體一些：當用戶使用瀏覽器訪問一個支持cookie的網站的時候，用戶會提供包括用戶名在內的個人資訊并且提交至服務器；接著，服務器在向客戶端回傳相應的超文本的同時也會發回這些個人資訊，當然這些資訊并不是存放在HTTP回應體中的，而是存放于HTTP回應頭；當客戶端瀏覽器接收到來自服務器的回應之后，瀏覽器會將這些資訊存放在一個統一的位置， 自此，客戶端再向服務器發送請求的時候，都會把相應的cookie存放在HTTP請求頭再次發回至服務器，服務器在接收到來自客戶端瀏覽器的請求之后，就能夠通過分析存放于請求頭的cookie得到客戶端特有的資訊，從而動態生成與該客戶端相對應的內容，網站的登錄界面中“請記住我”這樣的選項，就是通過cookie實作的，

cookie作業流程：

1. servlet創建cookie，保存少量資料，發送給瀏覽器，
2. 瀏覽器獲得服務器發送的cookie資料，將自動的保存到瀏覽器端，
3. 下次訪問時，瀏覽器將自動攜帶cookie資料發送給服務器，

session原理：首先瀏覽器請求服務器訪問web站點時，服務器首先會檢查這個客戶端請求是否已經包含了一個session標識、稱為SESSIONID，如果已經包含了一個sessionid則說明以前已經為此客戶端創建過session，服務器就按照sessionid把這個session檢索出來使用，如果客戶端請求不包含session id，則服務器為此客戶端創建一個session，并且生成一個與此session相關聯的獨一無二的sessionid存放到cookie中，這個sessionid將在本次回應中回傳到客戶端保存，這樣在互動的程序中，瀏覽器端每次請求時，都會帶著這個sessionid，服務器根據這個sessionid就可以找得到對應的session，以此來達到共享資料的目的， 這里需要注意的是，session不會隨著瀏覽器的關閉而死亡，而是等待超時時間，

cookie和session的區別？

• 作用范圍不同，Cookie 保存在客戶端，Session 保存在服務器端，
• 有效期不同，Cookie 可設定為長時間保持，比如我們經常使用的默認登錄功能，Session 一般失效時間較短，客戶端關倍訓者 Session 超時都會失效，
• 隱私策略不同，Cookie 存盤在客戶端，容易被竊取；Session 存盤在服務端，安全性相對 Cookie 要好一些，
• 存盤大小不同， 單個 Cookie 保存的資料不能超過 4K；對于 Session 來說存盤沒有上限，但出于對服務器的性能考慮，Session 內不要存放過多的資料，并且需要設定 Session 洗掉機制，

本文來自博客園，作者：ivanlee717，轉載請注明原文鏈接：https://www.cnblogs.com/ivanlee717/p/17262162.html

標籤：其他

上一篇：大廠光環下的功能測驗，出去面試自動化一問三不知

下一篇：【原型設計工具】??上海道寧為您提供Justinmind，助力您在幾分鐘內形成原型，并現場測驗，無需撰寫任何代碼