計算機網路經典30問
大家好，我是大彬~
最近在準備面試，看了大量的面經，將常見的計算機網路面試題總結如下，如果對你有幫助，可以收藏點贊支援哦～
首先給大家分享一個github倉庫，上面放了
200多本經典的計算機書籍
，包括C語言、C++、Java、Python、前端、資料庫、作業系統、計算機網路、資料結構和演算法、機器學習、程式設計人生等，可以star一下，下次找書直接在上面搜尋，倉庫持續更新中~
github地址：
https：//
github。com/Tyson0314/ja
va-books
如果github訪問不了，可以訪問gitee倉庫。
gitee地址：
https：//
gitee。com/tysondai/java
-books
網路分層結構
計算機網路體系大致分為三種，OSI七層模型、TCP/IP四層模型和五層模型。一般面試會考察五層模型，要能流暢回答。
計算機網路七層模型：應用層、表示層、會話層、傳輸層、網路層、資料鏈路層、物理層。
應用層：為應用程式提供互動服務。在網際網路中的應用層協議很多，如域名系統DNS、HTTP協議、SMTP協議等。
表示層：負責資料格式的轉換，如加密解密、壓縮解壓縮等。
會話層：負責在網路中的兩節點之間建立、維持和終止通訊，如伺服器驗證使用者登入便是由會話層完成的。
運輸層：負責向兩臺主機程序之間的通訊提供資料傳輸服務。傳輸層的協議主要有傳輸控制協議TCP和使用者資料協議UDP。
網路層：選擇合適的路由和交換結點，確保資料及時傳送。主要包括IP協議。
資料鏈路層：將網路層傳下來的IP資料包組裝成幀，並再相鄰節點的鏈路上傳送幀。
物理層：實現相鄰節點間位元流的透明傳輸，儘可能遮蔽傳輸介質和通訊手段的差異。
三次握手
假設傳送端為客戶端，接收端為服務端。開始時客戶端和服務端的狀態都是CLOSE。
第一次握手：客戶端向服務端發起建立連線請求，客戶端會隨機生成一個起始序列號x，客戶端向服務端傳送的欄位中包含標誌位SYN=1，序列號seq=x。第一次握手前客戶端的狀態為CLOSE，第一次握手後客戶端的狀態為SYN-SENT。此時服務端的狀態為LISTEN
第二次握手：服務端在收到客戶端發來的報文後，會隨機生成一個服務端的起始序列號y，然後給客戶端回覆一段報文，其中包括標誌位SYN=1，ACK=1，序列號seq=y，確認號ack=x+1。第二次握手前服務端的狀態為LISTEN，第二次握手後服務端的狀態為SYN-RCVD，此時客戶端的狀態為SYN-SENT。（其中SYN=1表示要和客戶端建立一個連線，ACK=1表示確認序號有效）
第三次握手：客戶端收到服務端發來的報文後，會再向服務端傳送報文，其中包含標誌位ACK=1，序列號seq=x+1，確認號ack=y+1。第三次握手前客戶端的狀態為SYN-SENT，第三次握手後客戶端和服務端的狀態都為ESTABLISHED。
兩次握手可以嗎？
主要為了防止已失效的連線請求報文段突然又傳送到了B，因而產生錯誤。如A發出連線請求，可能因為網路阻塞原因，A沒有收到確認報文，於是A再重傳一次連線請求。連線成功，等待資料傳輸完畢後，就釋放了連線。而A發出的第一個連線請求等到連線釋放以後的某個時間才到達B，此時B誤認為A又發出一次新的連線請求，於是就向A發出確認報文段，同意建立連線，不採用三次握手，只要B發出確認，就建立新的連線了，此時A不理睬B的確認且不傳送資料，則B一直等待A傳送資料，浪費資源。
四次揮手
A的應用程序先向其TCP發出連線釋放報文段（FIN=1，序號seq=u），並停止再發送資料，主動關閉TCP連線，進入FIN-WAIT-1（終止等待1）狀態，等待B的確認。
B收到連線釋放報文段後即發出確認報文段（ACK=1，確認號ack=u+1，序號seq=v），B進入CLOSE-WAIT（關閉等待）狀態，此時的TCP處於半關閉狀態，A到B的連線釋放。
A收到B的確認後，進入FIN-WAIT-2（終止等待2）狀態，等待B發出的連線釋放報文段。
B傳送完資料，就會發出連線釋放報文段（FIN=1，ACK=1，序號seq=w，確認號ack=u+1），B進入LAST-ACK（最後確認）狀態，等待A的確認。
A收到B的連線釋放報文段後，對此發出確認報文段（ACK=1，seq=u+1，ack=w+1），A進入TIME-WAIT（時間等待）狀態。此時TCP未釋放掉，需要經過時間等待計時器設定的時間2MSL（最大報文段生存時間）後，A才進入CLOSED狀態。B收到A發出的確認報文段後關閉連線，若沒收到A發出的確認報文段，B就會重傳連線釋放報文段。
為什麼客戶端在TIME-WAIT狀態必須等待2MSL的時間才能釋放TCP連線？
保證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報文。其中ACK報文是用來應答的，SYN報文是用來同步的。但是關閉連線時，當Server端收到連線釋放報文時，很可能並不會立即關閉SOCKET，所以只能先回復一個ACK報文，告訴Client端：“你發的連線釋放報文我收到了”。只有等到Server端所有的報文都發送完了，才能傳送連線釋放報文，因此不能一起傳送。故需要四步握手。
TCP有哪些特點？
TCP是面向連線的運輸層協議
點對點，每一條TCP連線只能有兩個端點
TCP提供可靠交付的服務
TCP提供全雙工通訊
面向位元組流
TCP和UDP的區別？
TCP面向連線；UDP是無連線的，即傳送資料之前不需要建立連線
TCP提供可靠的服務；UDP不保證可靠交付
TCP面向位元組流，把資料看成一連串無結構的位元組流；UDP是面向報文的
TCP有擁塞控制；UDP沒有擁塞控制，因此網路出現擁塞不會使源主機的傳送速率降低（對實時應用很有用，如IP電話，實時影片會議等）
每一條TCP連線只能是點到點的；UDP支援一對一，一對多，多對一和多對多的互動通訊
TCP首部開銷20位元組；UDP的首部開銷小，只有8個位元組
TCP 和 UDP 對應的應用場景是什麼？
TCP 是面向連線，能保證資料的可靠性交付，因此經常用於：
FTP檔案傳輸
HTTP / HTTPS
UDP 面向無連線，它可以隨時傳送資料，再加上UDP本身的處理既簡單又高效，因此經常用於：
包總量較少的通訊，如 DNS 、SNMP等
影片、音訊等多媒體通訊
廣播通訊
HTTP的特點
靈活：HTTP允許傳輸任意型別的資料。傳輸的型別由Content-Type加以標記。
無狀態：是指服務端對於客戶端每次傳送的請求都認為它是一個新的請求，上一次會話和下一次會話沒有聯絡；HTTP 協議這種特性有優點也有缺點，優點在於解放了伺服器，不會造成不必要連線佔用，缺點在於如果後續處理需要前面的資訊，則它必須重傳，這樣可能導致每次連線傳送的資料量增大。
支援客戶端/伺服器模式。
簡單快速：客戶向伺服器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與伺服器聯絡的型別不同。由於HTTP協議簡單，使得HTTP伺服器的程式規模小，因而通訊速度很快。
HTTP請求報文和響應報文的格式？
HTTP請求由請求行、請求頭部、空行和請求體四個部分組成。
請求行：請求方法，訪問的資源URL，使用的HTTP版本；GET和POST是最常見的HTTP方法，除此以外還包括DELETE、HEAD、OPTIONS、PUT、TRACE。
請求頭包含一些屬性，格式為“屬性名：屬性值”，服務端據此獲取客戶端的資訊，主要有cookie、host、connection、accept-language、accept-encoding、user-agent。
請求體：使用者的請求資料如使用者名稱，密碼等。
POST
/
xxx
HTTP
/
1
。
1
請求行
Accept：
image
/
gif
。
image
/
jpeg
，
請求頭部
Accept
-
Language
：
zh
-
cn
Connection：
Keep
-
Alive
Host：
localhost
User
-
Agent
：
Mozila
/
4
。
0
（
compatible
；
MSIE5
。
01
；
Window
NT5
。
0
）
Accept
-
Encoding
：
gzip
，
deflate
username
=
dabin
請求體
HTTP響應也由四個部分組成，分別是：狀態行、響應頭、空行和響應體。
狀態行：協議版本，狀態碼及狀態描述。
響應頭：connection、content-type、content-encoding、content-length、set-cookie、Last-Modified，、Cache-Control、Expires。
響應體：伺服器返回給客戶端的內容。
HTTP/1。1 200 OK
Server：Apache Tomcat/5。0。12
Date：Mon，6Oct2003 13：23：42 GMT
Content-Length：112
<
html
>
<
body
>
響應體
body
>
html
>
HTTP狀態碼有哪些？
POST和GET的區別？
GET請求引數透過URL傳遞，POST的引數放在請求體中。
GET產生一個TCP資料包；POST產生兩個TCP資料包。對於GET方式的請求，瀏覽器會把請求頭和請求體一併傳送出去；而對於POST，瀏覽器先發送請求頭，伺服器響應100 continue，瀏覽器再發送請求體。
GET請求會被瀏覽器主動快取，而POST不會，除非手動設定。
GET請求只能進行url編碼，而POST支援多種編碼方式。
GET請求引數會被完整保留在瀏覽器歷史記錄裡，而POST中的引數不會被保留。
HTTP長連線和短連線？
HTTP1.0預設使用的是短連線
。瀏覽器和伺服器每進行一次HTTP操作，就建立一次連線，任務結束就中斷連線。
HTTP/1.1起，預設使用長連線
。要使用長連線，客戶端和伺服器的HTTP首部的Connection都要設定為keep-alive，才能支援長連線。
HTTP長連線，指的是
複用TCP連線
。多個HTTP請求可以複用同一個TCP連線，這就節省了TCP連線建立和斷開的消耗。
HTTP1。0和HTTP1。1的區別？
長連線
：HTTP1。0預設使用短連線，每次請求都需要建立新的TCP連線，連線不能複用。HTTP1。1支援長連線，複用TCP連線。
快取處理
：在HTTP1。0中主要使用header裡的
If-Modified-Since，Expires
來做為快取判斷的標準，HTTP1。1則引入了更多的快取控制策略，可供選擇的快取頭來控制快取策略。
頻寬最佳化及網路連線的使用
：HTTP1。0中，存在一些浪費頻寬的現象，例如客戶端只是需要某個物件的一部分，而伺服器卻將整個物件送過來了，並且不支援斷點續傳功能，HTTP1。1則在請求頭引入了range頭域，它允許只請求資源的某個部分，即返回碼是206（Partial Content），這樣就方便了開發者自由的選擇以便於充分利用頻寬和連線。
錯誤通知的管理
：在HTTP1。1中新增了24個錯誤狀態響應碼，如409（Conflict）表示請求的資源與資源的當前狀態發生衝突；410（Gone）表示伺服器上的某個資源被永久性的刪除。
Host頭處理
：在HTTP1。0中認為每臺伺服器都繫結一個唯一的IP地址，因此，請求訊息中的URL並沒有傳遞主機名。但隨著虛擬主機技術的發展，在一臺物理伺服器上可以存在多個虛擬主機，並且它們共享一個IP地址。HTTP1。1的請求訊息和響應訊息都應支援Host頭域，且請求訊息中如果沒有Host頭域會報告一個錯誤（400 Bad Request）。
HTTP1。1和 HTTP2。0的區別？
HTTP2。0相比HTTP1。1支援的特性：
新的二進位制格式
：HTTP1。1的解析是基於文字。HTTP2。0的協議解析採用二進位制格式，實現方便且健壯。
多路複用
：一個request對應一個id，這樣一個連線上可以有多個request，接收方可以根據request的 id將request再歸屬到各自不同的服務端請求裡面。
頭部壓縮
，HTTP1。1的header帶有大量資訊，而且每次都要重複傳送；HTTP2。0使用encoder來減少需要傳輸的header大小。
服務端推送
：伺服器除了對最初請求的響應外，伺服器還可以額外的向客戶端推送資源，無需客戶端請求。
HTTPS與HTTP的區別？
HTTP是超文字傳輸協議，資訊是明文傳輸，HTTPS則是具有安全性的ssl加密傳輸協議。
HTTP和HTTPS用的埠不一樣，前者是80，後者是443。
HTTPS協議需要到CA機構申請證書，一般免費證書較少，因而需要一定費用。
HTTP執行在TCP協議之上；HTTPS執行在SSL協議之上，SSL執行在TCP協議之上。
HTTP協議以明文方式傳送內容，不提供任何方式的資料加密，因此，HTTP協議不適合傳輸一些敏感資訊，比如：信用卡號、密碼等支付資訊。而HTTPS協議是由SSL+HTTP協議構建的可進行身份認證（非對稱加密）、加密傳輸（對稱加密）的網路協議。SSL作用在應用層和運輸層之間，在TCP之上建立起一個安全通道，確保資料傳輸安全。
什麼是數字證書？
服務端可以向證書頒發機構CA申請證書，以避免中間人攻擊（防止證書被篡改）。證書包含三部分內容：tbsCertificate（to be signed certificate）待簽名證書內容、證書籤名演算法和CA給的簽名（使用證書籤名演算法對tbsCertificate進行雜湊運算得到雜湊值，CA會用它的私鑰對此雜湊值進行簽名，並放在簽名部分）。簽名是為了驗證身份。
服務端把證書傳輸給瀏覽器，瀏覽器從證書裡取公鑰。證書可以證明該公鑰對應該網站。
數字簽名的製作過程：
CA使用證書籤名演算法對證書內容（待簽名證書內容）進行hash。
對hash後的值用CA自己的私鑰加密，得到數字簽名。
瀏覽器驗證過程：
拿到證書，得到證書內容、證書籤名演算法和數字簽名。
用CA機構的公鑰對數字簽名解密（由於是瀏覽器信任的機構，所以瀏覽器會儲存它的公鑰）。
用證書裡的簽名演算法對證書內容進行hash。
比較解密後的數字簽名和對證書內容hash後的雜湊值，相等則表明證書可信。
HTTPS原理
首先是TCP三次握手，然後客戶端（瀏覽器）發起一個HTTPS連線建立請求，客戶端先發一個Client Hello的包，然後服務端響應一個Server Hello，接著再給客戶端傳送它的證書，然後雙方經過金鑰交換，最後使用交換的金鑰加解密資料。
協商加密演算法 。在Client Hello裡面客戶端會告知服務端自己當前的一些資訊，包括客戶端要使用的TLS版本，支援的加密演算法，要訪問的域名，給服務端生成的一個隨機數（Nonce）等。需要提前告知伺服器想要訪問的域名以便伺服器傳送相應的域名的證書過來。
服務端在Server Hello裡面會做一些響應，告訴客戶端服務端選中的加密演算法。
接著服務端給客戶端發來了2個證書。第二個證書是第一個證書的簽發機構（CA）的證書。
客戶端使用證書的認證機構CA公開發布的RSA公鑰對該證書進行驗證，下圖表明證書認證成功。
驗證透過之後，瀏覽器和伺服器透過金鑰交換演算法產生共享的對稱金鑰。
開始傳輸資料，使用同一個對稱金鑰來加解密。
DNS 解析過程？
瀏覽器搜尋自己的DNS快取
若沒有，則搜尋作業系統中的DNS快取和hosts檔案
若沒有，則作業系統將域名傳送至本地域名伺服器，本地域名伺服器查詢自己的DNS快取，查詢成功則返回結果，否則依次向根域名伺服器、頂級域名伺服器、許可權域名伺服器發起查詢請求，最終返回IP地址給本地域名伺服器
本地域名伺服器將得到的IP地址返回給作業系統，同時自己也將IP地址快取起來
作業系統將 IP 地址返回給瀏覽器，同時自己也將IP地址快取起來
瀏覽器得到域名對應的IP地址
瀏覽器中輸入URL返回頁面過程？
解析域名，找到主機IP。
瀏覽器利用IP直接與網站主機通訊，三次握手，建立 TCP 連線。瀏覽器會以一個隨機埠向服務端的 web 程式 80 埠發起 tcp 的連線。
建立TCP連線後，瀏覽器向主機發起一個HTTP請求。
伺服器響應請求，發回網頁內容。
瀏覽器解析網頁內容，進行渲染，呈現給使用者。
什麼是cookie和session？
由於HTTP協議是無狀態的協議，需要用某種機制來識具體的使用者身份，用來跟蹤使用者的整個會話。常用的會話跟蹤技術是cookie與session。
cookie
就是由伺服器發給客戶端的特殊資訊，而這些資訊以文字檔案的方式存放在客戶端，然後客戶端每次向伺服器傳送請求的時候都會帶上這些特殊的資訊。說得更具體一些：當用戶使用瀏覽器訪問一個支援cookie的網站的時候，使用者會提供包括使用者名稱在內的個人資訊並且提交至伺服器；接著，伺服器在向客戶端回傳相應的超文字的同時也會發回這些個人資訊，當然這些資訊並不是存放在HTTP響應體中的，而是存放於HTTP響應頭；當客戶端瀏覽器接收到來自伺服器的響應之後，瀏覽器會將這些資訊存放在一個統一的位置。 自此，客戶端再向伺服器傳送請求的時候，都會把相應的cookie存放在HTTP請求頭再次發回至伺服器。伺服器在接收到來自客戶端瀏覽器的請求之後，就能夠透過分析存放於請求頭的cookie得到客戶端特有的資訊，從而動態生成與該客戶端相對應的內容。網站的登入介面中“請記住我”這樣的選項，就是透過cookie實現的。
cookie工作流程
：
servlet建立cookie，儲存少量資料，傳送給瀏覽器。
瀏覽器獲得伺服器傳送的cookie資料，將自動的儲存到瀏覽器端。
下次訪問時，瀏覽器將自動攜帶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 儲存在客戶端，比較容易遭到不法獲取，早期有人將使用者的登入名和密碼儲存在 Cookie 中導致資訊被竊取；Session 儲存在服務端，安全性相對 Cookie 要好一些。
儲存大小不同， 單個 Cookie 儲存的資料不能超過 4K，Session 可儲存資料遠高於 Cookie。
什麼是對稱加密和非對稱加密？
對稱加密：通訊雙方使用相同的金鑰進行加密。特點是加密速度快，但是缺點是需要保護好金鑰，如果金鑰洩露的話，那麼加密就會被別人破解。常見的對稱加密有AES，DES演算法。
非對稱加密：它需要生成兩個金鑰：公鑰和私鑰。公鑰是公開的，任何人都可以獲得，而私鑰是私人保管的。我們提交程式碼到github的時候，就可以使用SSH key：在本地生成私鑰和公鑰，私鑰放在本地
。ssh
目錄中，公鑰放在github網站上，這樣每次提交程式碼，就不用輸入使用者名稱和密碼了，github會根據網站上儲存的公鑰來識別我們的身份。公鑰負責加密，私鑰負責解密；或者私鑰負責加密，公鑰負責解密。這種加密演算法安全性更高，但是計算量相比對稱加密大很多，加密和解密都很慢。常見的非對稱演算法有RSA。
滑動視窗機制
TCP 利用滑動視窗實現流量控制。流量控制是為了控制傳送方傳送速率，保證接收方來得及接收。 TCP會話的雙方都各自維護一個傳送視窗和一個接收視窗。接收視窗大小取決於應用、系統、硬體的限制。傳送視窗則取決於對端通告的接收視窗。接收方傳送的確認報文中的window欄位可以用來控制傳送方視窗大小，從而影響傳送方的傳送速率。將接收方的確認報文window欄位設定為 0，則傳送方不能傳送資料。
TCP頭包含window欄位，16bit位，它代表的是視窗的位元組容量，最大為65535。這個欄位是接收端告訴傳送端自己還有多少緩衝區可以接收資料。於是傳送端就可以根據這個接收端的處理能力來發送資料，而不會導致接收端處理不過來。接收視窗的大小是約等於傳送視窗的大小。
詳細講一下擁塞控制？
防止過多的資料注入到網路中。 幾種擁塞控制方法：慢開始（ slow-start ）、擁塞避免（ congestion avoidance ）、快重傳（ fast retransmit ）和快恢復（ fast recovery ）。
慢開始
把擁塞視窗 cwnd 設定為一個最大報文段MSS的數值。而在每收到一個對新的報文段的確認後，把擁塞視窗增加至多一個MSS的數值。每經過一個傳輸輪次，擁塞視窗 cwnd 就加倍。 為了防止擁塞視窗cwnd增長過大引起網路擁塞，還需要設定一個慢開始門限ssthresh狀態變數。
當 cwnd < ssthresh 時，使用慢開始演算法。
當 cwnd > ssthresh 時，停止使用慢開始演算法而改用擁塞避免演算法。
當 cwnd = ssthresh 時，既可使用慢開始演算法，也可使用擁塞控制避免演算法。
擁塞避免
讓擁塞視窗cwnd緩慢地增大，每經過一個往返時間RTT就把傳送方的擁塞視窗cwnd加1，而不是加倍。這樣擁塞視窗cwnd按線性規律緩慢增長。
無論在慢開始階段還是在擁塞避免階段，只要傳送方判斷網路出現擁塞（其根據就是沒有收到確認），就要把慢開始門限ssthresh設定為出現擁塞時的傳送 方視窗值的一半（但不能小於2）。然後把擁塞視窗cwnd重新設定為1，執行慢開始演算法。這樣做的目的就是要迅速減少主機發送到網路中的分組數，使得發生 擁塞的路由器有足夠時間把佇列中積壓的分組處理完畢。
快重傳
有時個別報文段會在網路中丟失，但實際上網路並未發生擁塞。如果傳送方遲遲收不到確認，就會產生超時，就會誤認為網路發生了擁塞。這就導致傳送方錯誤地啟動慢開始，把擁塞視窗cwnd又設定為1，因而降低了傳輸效率。
快重傳演算法可以避免這個問題。快重傳演算法首先要求接收方每收到一個失序的報文段後就立即發出重複確認，使傳送方及早知道有報文段沒有到達對方。
傳送方只要一連收到三個重複確認就應當立即重傳對方尚未收到的報文段，而不必繼續等待重傳計時器到期。由於傳送方儘早重傳未被確認的報文段，因此採用快重傳後可以使整個網路吞吐量提高約20%。
快恢復
當傳送方連續收到三個重複確認，就會把慢開始門限ssthresh減半，接著把cwnd值設定為慢開始門限ssthresh減半後的數值，然後開始執行擁塞避免演算法，使擁塞視窗緩慢地線性增大。
在採用快恢復演算法時，慢開始演算法只是在TCP連線建立時和網路出現超時時才使用。 採用這樣的擁塞控制方法使得TCP的效能有明顯的改進。
ARP協議
ARP解決了同一個區域網上的主機和路由器IP和MAC地址的解析。
每臺主機都會在自己的ARP緩衝區中建立一個ARP列表，以表示IP地址和MAC地址的對應關係。
當源主機需要將一個數據包要傳送到目的主機時，會首先檢查自己 ARP列表中是否存在該 IP地址對應的MAC地址，如果有，就直接將資料包傳送到這個MAC地址；如果沒有，就向本地網段發起一個ARP請求的廣播包，查詢此目的主機對應的MAC地址。此ARP請求資料包裡包括源主機的IP地址、硬體地址、以及目的主機的IP地址。
網路中所有的主機收到這個ARP請求後，會檢查資料包中的目的IP是否和自己的IP地址一致。如果不相同就忽略此資料包；如果相同，該主機首先將傳送端的MAC地址和IP地址新增到自己的ARP列表中，如果ARP表中已經存在該IP的資訊，則將其覆蓋，然後給源主機發送一個 ARP響應資料包，告訴對方自己是它需要查詢的MAC地址。
源主機收到這個ARP響應資料包後，將得到的目的主機的IP地址和MAC地址新增到自己的ARP列表中，並利用此資訊開始資料的傳輸。
如果源主機一直沒有收到ARP響應資料包，表示ARP查詢失敗。
