1. 模型結(jié)構(gòu)

五層模型：

應(yīng)用層、傳輸層、網(wǎng)絡(luò)層、數(shù)據(jù)鏈路層、物理層。

• 應(yīng)用層：為應(yīng)用程序提供交互服務(wù)。在互聯(lián)網(wǎng)中的應(yīng)用層協(xié)議很多，如域名系統(tǒng)DNS、HTTP協(xié)議、SMTP協(xié)議等。
• 傳輸層：負責向兩臺主機進程之間的通信提供數(shù)據(jù)傳輸服務(wù)。傳輸層的協(xié)議主要有傳輸控制協(xié)議TCP和用戶數(shù)據(jù)協(xié)議UDP。
• 網(wǎng)絡(luò)層：選擇合適的路由和交換結(jié)點，確保數(shù)據(jù)及時傳送。主要包括IP協(xié)議。
• 數(shù)據(jù)鏈路層：在兩個相鄰節(jié)點之間傳送數(shù)據(jù)時，數(shù)據(jù)鏈路層將網(wǎng)絡(luò)層交下來的 IP 數(shù)據(jù)報組裝成幀，在兩個相鄰節(jié)點間的鏈路上傳送幀。
• 物理層：實現(xiàn)相鄰節(jié)點間比特流的透明傳輸，盡可能屏蔽傳輸介質(zhì)和物理設(shè)備的差異。

ISO七層模型

是國際標準化組織（International Organization for Standardization）制定的一個用于計算機或通信系統(tǒng)間互聯(lián)的標準體系。

• 應(yīng)用層：網(wǎng)絡(luò)服務(wù)與最終用戶的一個接口，常見的協(xié)議有：HTTP FTP SMTP SNMP DNS.
• 表示層：數(shù)據(jù)的表示、安全、壓縮。，確保一個系統(tǒng)的應(yīng)用層所發(fā)送的信息可以被另一個系統(tǒng)的應(yīng)用層讀取。
• 會話層：建立、管理、終止會話,對應(yīng)主機進程，指本地主機與遠程主機正在進行的會話.
• 傳輸層：定義傳輸數(shù)據(jù)的協(xié)議端口號，以及流控和差錯校驗,協(xié)議有TCP UDP.
• 網(wǎng)絡(luò)層：進行邏輯地址尋址，實現(xiàn)不同網(wǎng)絡(luò)之間的路徑選擇,協(xié)議有ICMP IGMP IP等.
• 數(shù)據(jù)鏈路層：在物理層提供比特流服務(wù)的基礎(chǔ)上，建立相鄰結(jié)點之間的數(shù)據(jù)鏈路。
• 物理層：建立、維護、斷開物理連接。

TCP/IP 四層模型

• 應(yīng)用層：對應(yīng)于OSI參考模型的（應(yīng)用層、表示層、會話層）。
• 傳輸層: 對應(yīng)OSI的傳輸層，為應(yīng)用層實體提供端到端的通信功能，保證了數(shù)據(jù)包的順序傳送及數(shù)據(jù)的完整性。
• 網(wǎng)際層：對應(yīng)于OSI參考模型的網(wǎng)絡(luò)層，主要解決主機到主機的通信問題。
• 網(wǎng)絡(luò)接口層：與OSI參考模型的數(shù)據(jù)鏈路層、物理層對應(yīng)。

2. 三次握手

假設(shè)發(fā)送端為客戶端，接收端為服務(wù)端。開始時客戶端和服務(wù)端的狀態(tài)都是CLOSED。

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

之所以需要第三次握手，主要為了防止已失效的連接請求報文段突然又傳輸?shù)搅朔?wù)端，導(dǎo)致產(chǎn)生問題。

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

3. 四次握手

1. A的應(yīng)用進程先向其TCP發(fā)出連接釋放報文段（FIN=1，seq=u），并停止再發(fā)送數(shù)據(jù)，主動關(guān)閉TCP連接，進入FIN-WAIT-1（終止等待1）狀態(tài)，等待B的確認。
2. B收到連接釋放報文段后即發(fā)出確認報文段（ACK=1，ack=u+1，seq=v），B進入CLOSE-WAIT（關(guān)閉等待）狀態(tài)，此時的TCP處于半關(guān)閉狀態(tài)，A到B的連接釋放。
3. A收到B的確認后，進入FIN-WAIT-2（終止等待2）狀態(tài)，等待B發(fā)出的連接釋放報文段。
4. B發(fā)送完數(shù)據(jù)，就會發(fā)出連接釋放報文段（FIN=1，ACK=1，seq=w，ack=u+1），B進入LAST-ACK（最后確認）狀態(tài)，等待A的確認。
5. A收到B的連接釋放報文段后，對此發(fā)出確認報文段（ACK=1，seq=u+1，ack=w+1），A進入TIME-WAIT（時間等待）狀態(tài)。此時TCP未釋放掉，需要經(jīng)過時間等待計時器設(shè)置的時間2MSL（最大報文段生存時間）后，A才進入CLOSED狀態(tài)。B收到A發(fā)出的確認報文段后關(guān)閉連接，若沒收到A發(fā)出的確認報文段，B就會重傳連接釋放報文段。

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

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

為什么是四次揮手？

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

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

• 16位端口號：源端口號，主機該報文段是來自哪里；目標端口號，要傳給哪個上層協(xié)議或應(yīng)用程序
• 32位序號：一次TCP通信（從TCP連接建立到斷開）過程中某一個傳輸方向上的字節(jié)流的每個字節(jié)的編號。
• 32位確認號：用作對另一方發(fā)送的tcp報文段的響應(yīng)。其值是收到的TCP報文段的序號值加1。
• 4位頭部長度：表示tcp頭部有多少個32bit字（4字節(jié)）。因為4位最大能標識15，所以TCP頭部最長是60字節(jié)。
• 6位標志位：URG(緊急指針是否有效)，ACk（表示確認號是否有效），PSH（緩沖區(qū)尚未填滿），RST（表示要求對方重新建立連接），SYN（建立連接消息標志接），F(xiàn)IN（表示告知對方本端要關(guān)閉連接了）
• 16位窗口大小：是TCP流量控制的一個手段。這里說的窗口，指的是接收通告窗口。它告訴對方本端的TCP接收緩沖區(qū)還能容納多少字節(jié)的數(shù)據(jù)，這樣對方就可以控制發(fā)送數(shù)據(jù)的速度。
• 16位校驗和：由發(fā)送端填充，接收端對TCP報文段執(zhí)行CRC算法以檢驗TCP報文段在傳輸過程中是否損壞。注意，這個校驗不僅包括TCP頭部，也包括數(shù)據(jù)部分。這也是TCP可靠傳輸?shù)囊粋€重要保障。
• 16位緊急指針：一個正的偏移量。它和序號字段的值相加表示最后一個緊急數(shù)據(jù)的下一字節(jié)的序號。因此，確切地說，這個字段是緊急指針相對當前序號的偏移，不妨稱之為緊急偏移。TCP的緊急指針是發(fā)送端向接收端發(fā)送緊急數(shù)據(jù)的方法。

5. TCP的粘包和拆包

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

為什么會產(chǎn)生粘包和拆包呢?

• 要發(fā)送的數(shù)據(jù)小于TCP發(fā)送緩沖區(qū)的大小，TCP將多次寫入緩沖區(qū)的數(shù)據(jù)一次發(fā)送出去，將會發(fā)生粘包；
• 接收數(shù)據(jù)端的應(yīng)用層沒有及時讀取接收緩沖區(qū)中的數(shù)據(jù)，將發(fā)生粘包；
• 要發(fā)送的數(shù)據(jù)大于TCP發(fā)送緩沖區(qū)剩余空間大小，將會發(fā)生拆包；
• 待發(fā)送數(shù)據(jù)大于MSS（最大報文長度），TCP在傳輸前將進行拆包。即TCP報文長度-TCP頭部長度>MSS。

解決方案：

• 發(fā)送端將每個數(shù)據(jù)包封裝為固定長度
• 在數(shù)據(jù)尾部增加特殊字符進行分割
• 將數(shù)據(jù)分為兩部分，一部分是頭部，一部分是內(nèi)容體；其中頭部結(jié)構(gòu)大小固定，且有一個字段聲明內(nèi)容體的大小。

6. TCP的滑動窗口機制

TCP 利用滑動窗口實現(xiàn)流量控制。流量控制是為了控制發(fā)送方發(fā)送速率，保證接收方來得及接收。 TCP會話的雙方都各自維護一個發(fā)送窗口和一個接收窗口。接收窗口大小取決于應(yīng)用、系統(tǒng)、硬件的限制。發(fā)送窗口則取決于對端通告的接收窗口。接收方發(fā)送的確認報文中的window字段可以用來控制發(fā)送方窗口大小，從而影響發(fā)送方的發(fā)送速率。將接收方的確認報文window字段設(shè)置為 0，則發(fā)送方不能發(fā)送數(shù)據(jù)。

7. 擁塞控制

慢開始

把擁塞窗口 cwnd 設(shè)置為一個最大報文段MSS的數(shù)值。而在每收到一個對新的報文段的確認后，把擁塞窗口增加至多一個MSS的數(shù)值。每經(jīng)過一個傳輸輪次，擁塞窗口 cwnd 就加倍。 為了防止擁塞窗口cwnd增長過大引起網(wǎng)絡(luò)擁塞，還需要設(shè)置一個慢開始門限ssthresh狀態(tài)變量。

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

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

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

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

1. TCP 連接進行初始化時，把擁塞窗口 cwnd 置為 1。
2. 當執(zhí)行慢開始算法時，擁塞窗口 cwnd 的初始值為 1。以后發(fā)送方每收到一個對新報文段的確認 ACK，就把擁塞窗口值加 1，然后開始下一輪的傳輸（請注意，圖示的橫坐標是傳輸輪次）。因此擁塞窗口 cwnd 隨著傳輸輪次按指數(shù)規(guī)律增長。當擁塞窗口 cwnd 增長到慢開始門限值 ssthresh 時（即當 cwnd = 16時），就改為執(zhí)行擁塞避免算法，擁塞窗口按線性規(guī)律增長。
3. 假定擁塞窗口的數(shù)值增長到 24 時，網(wǎng)絡(luò)出現(xiàn)超時（這很可能就是網(wǎng)絡(luò)發(fā)生擁塞了）。更新后的 ssthresh 值變?yōu)?12（即變?yōu)槌霈F(xiàn)超時時的擁塞窗口數(shù)值 24的一半），擁塞窗口再重新設(shè)置為 1，并執(zhí)行慢開始算法。當 cwnd = ssthresh = 12 時改為執(zhí)行擁塞避免算法，擁塞窗口按線性規(guī)律增長，每經(jīng)過一個往返時間增加一個 MSS 的大小。

擁塞避免

讓擁塞窗口cwnd緩慢地增大，每經(jīng)過一個往返時間RTT就把發(fā)送方的擁塞窗口cwnd加1，而不是加倍。這樣擁塞窗口cwnd按線性規(guī)律緩慢增長。

無論在慢開始階段還是在擁塞避免階段，只要發(fā)送方判斷網(wǎng)絡(luò)出現(xiàn)擁塞（其根據(jù)就是沒有收到確認），就要把慢開始門限ssthresh設(shè)置為出現(xiàn)擁塞時的發(fā)送 方窗口值的一半（但不能小于2）。然后把擁塞窗口cwnd重新設(shè)置為1，執(zhí)行慢開始算法。這樣做的目的就是要迅速減少主機發(fā)送到網(wǎng)絡(luò)中的分組數(shù)，使得發(fā)生 擁塞的路由器有足夠時間把隊列中積壓的分組處理完畢。

快重傳

有時個別報文段會在網(wǎng)絡(luò)中丟失，但實際上網(wǎng)絡(luò)并未發(fā)生擁塞。如果發(fā)送方遲遲收不到確認，就會產(chǎn)生超時，就會誤認為網(wǎng)絡(luò)發(fā)生了擁塞。這就導(dǎo)致發(fā)送方錯誤地啟動慢開始，把擁塞窗口cwnd又設(shè)置為1，因而降低了傳輸效率。

快重傳算法可以避免這個問題?？熘貍魉惴ㄊ紫纫蠼邮辗矫渴盏揭粋€失序的報文段后就立即發(fā)出重復(fù)確認，使發(fā)送方及早知道有報文段沒有到達對方。

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

快恢復(fù)

當發(fā)送方連續(xù)收到三個重復(fù)確認，就會把慢開始門限ssthresh減半，接著把cwnd值設(shè)置為慢開始門限ssthresh減半后的數(shù)值，然后開始執(zhí)行擁塞避免算法，使擁塞窗口緩慢地線性增大。

在采用快恢復(fù)算法時，慢開始算法只是在TCP連接建立時和網(wǎng)絡(luò)出現(xiàn)超時時才使用。 采用這樣的擁塞控制方法使得TCP的性能有明顯的改進。

8. POST和GET的區(qū)別？

• GET 和 POST 最本質(zhì)的區(qū)別是規(guī)范上的區(qū)別，在規(guī)范中，定義 GET 請求是用來獲取資源的，也就是進行查詢操作的，而 POST 請求是用來傳輸實體對象的，因此會使用 POST 來進行添加、修改和刪除等操作。
• GET請求參數(shù)通過URL傳遞，POST的參數(shù)放在請求體中。
• GET 請求可以直接進行回退和刷新，不會對用戶和程序產(chǎn)生任何影響；而 POST 請求如果直接回滾和刷新將會把數(shù)據(jù)再次提交。
• GET產(chǎn)生一個TCP數(shù)據(jù)包；POST產(chǎn)生兩個TCP數(shù)據(jù)包。對于GET方式的請求，瀏覽器會把請求頭和請求體一并發(fā)送出去；而對于POST，瀏覽器先發(fā)送請求頭，服務(wù)器響應(yīng)100 continue，瀏覽器再發(fā)送請求體。
• GET 請求一般會被緩存，比如常見的 CSS、JS、HTML 請求等都會被緩存；而 POST 請求默認是不進行緩存的。
• GET請求參數(shù)會被完整保留在瀏覽器歷史記錄里，而POST中的參數(shù)不會被保留。

9. 什么是cookie和session？

由于HTTP協(xié)議是無狀態(tài)的協(xié)議，需要用某種機制來識具體的用戶身份，用來跟蹤用戶的整個會話。常用的會話跟蹤技術(shù)是cookie與session。

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

cookie工作流程：

1. servlet創(chuàng)建cookie，保存少量數(shù)據(jù)，發(fā)送給瀏覽器。
2. 瀏覽器獲得服務(wù)器發(fā)送的cookie數(shù)據(jù)，將自動的保存到瀏覽器端。
3. 下次訪問時，瀏覽器將自動攜帶cookie數(shù)據(jù)發(fā)送給服務(wù)器。

session原理：首先瀏覽器請求服務(wù)器訪問web站點時，服務(wù)器首先會檢查這個客戶端請求是否已經(jīng)包含了一個session標識、稱為SESSIONID，如果已經(jīng)包含了一個sessionid則說明以前已經(jīng)為此客戶端創(chuàng)建過session，服務(wù)器就按照sessionid把這個session檢索出來使用，如果客戶端請求不包含session id，則服務(wù)器為此客戶端創(chuàng)建一個session，并且生成一個與此session相關(guān)聯(lián)的獨一無二的sessionid存放到cookie中，這個sessionid將在本次響應(yīng)中返回到客戶端保存，這樣在交互的過程中，瀏覽器端每次請求時，都會帶著這個sessionid，服務(wù)器根據(jù)這個sessionid就可以找得到對應(yīng)的session。以此來達到共享數(shù)據(jù)的目的。 這里需要注意的是，session不會隨著瀏覽器的關(guān)閉而死亡，而是等待超時時間。文章來源地址http://www.zghlxwxcb.cn/news/detail-609237.html

cookie和session的區(qū)別？

• 作用范圍不同，Cookie 保存在客戶端，Session 保存在服務(wù)器端。
• 有效期不同，Cookie 可設(shè)置為長時間保持，比如我們經(jīng)常使用的默認登錄功能，Session 一般失效時間較短，客戶端關(guān)閉或者 Session 超時都會失效。
• 隱私策略不同，Cookie 存儲在客戶端，容易被竊取；Session 存儲在服務(wù)端，安全性相對 Cookie 要好一些。
• 存儲大小不同， 單個 Cookie 保存的數(shù)據(jù)不能超過 4K；對于 Session 來說存儲沒有上限，但出于對服務(wù)器的性能考慮，Session 內(nèi)不要存放過多的數(shù)據(jù)，并且需要設(shè)置 Session 刪除機制。

到了這里，關(guān)于計算機網(wǎng)絡(luò)概念匯總的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！