計網學習彙總
文章目錄
計網分層模型
OSI分層 （7層）： 物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層、應用層。
TCP/IP分層（4層）： 網絡接口層、 網際層、運輸層、 應用層。
五層協議 （5層）： 物理層、數據鏈路層、網絡層、運輸層、 應用層。
運輸層的兩種協議
TCP
傳輸控制協議 TCP（Transmisson Control Protocol）–提供面向連接的，可靠的數據傳輸服務。
- TCP 是面向連接的。（就好像打電話一樣，通話前需要先撥號建立連接，通話結束後要掛機釋放連接）；
- 每一條 TCP 連接只能有兩個端點，每一條TCP連接只能是點對點的（一對一）；
- TCP 提供可靠交付的服務。通過TCP連接傳送的數據，無差錯、不丟失、不重複、並且按序到達；
- TCP 提供全雙工通信。TCP 允許通信雙方的應用進程在任何時候都能發送數據。TCP 連接的兩端都設有發送緩存和接收緩存，用來臨時存放雙方通信的數據；
- 面向字節流。TCP 中的“流”（Stream）指的是流入進程或從進程流出的字節序列。“面向字節流”的含義是：雖然應用程序和 TCP 的交互是一次一個數據塊（大小不等），但 TCP 把應用程序交下來的數據僅僅看成是一連串的無結構的字節流。
UDP
用戶數據協議 UDP（User Datagram Protocol）–提供無連接的，盡最大努力的數據傳輸服務（不保證數據傳輸的可靠性）
- UDP 是無連接的；
- UDP 使用盡最大努力交付，即不保證可靠交付，因此主機不需要維持複雜的鏈接狀態（這裏面有許多參數）；
- UDP 是面向報文的；
- UDP 沒有擁塞控制，因此網絡出現擁塞不會使源主機的發送速率降低（對實時應用很有用，如 直播，實時視頻會議等）；
- UDP 支持一對一、一對多、多對一和多對多的交互通信；
- UDP 的首部開銷小，只有8個字節，比TCP的20個字節的首部要短。
TCP面向字節流和UDP面向報文的區別
打個比方比喻TCP，你家裏有個蓄水池，你可以裏面倒水，蓄水池上有個龍頭，你可以通過龍頭將水池裏的水放出來，然後用各種各樣的容器裝(杯子、礦泉水瓶、鍋碗瓢盆)接水。
上面的例子中，往水池裏倒幾次水和接幾次水是沒有必然聯繫的，也就是說你可以只倒一次水，然後分10次接完。另外，水池裏的水接多少就會少多少;往裏面倒多少水，就會增加多少水，但是不能超過水池的容量，多出的水會溢出。
結合TCP的概念，水池就好比接收緩存，倒水就相當於發送數據，接水就相當於讀取數據。好比你通過TCP連接給另一端發送數據，你只調用了一次 write，發送了100個字節，但是對方可以分10次收完，每次10個字節;你也可以調用10次write，每次10個字節，但是對方可以一次就收完。 (假設數據都能到達)但是，你發送的數據量不能大於對方的接收緩存(流量控制)，如果你硬是要發送過量數據，則對方的緩存滿了就會把多出的數據丟棄。
UDP和TCP不同，發送端調用了幾次write，接收端必須用相同次數的read讀完。UPD是基於報文的，在接收的時候，每次最多隻能讀取一個 報文，報文和報文是不會合並的，如果緩衝區小於報文長度，則多出的部分會被丟棄。也就說，如果不指定MSG_PEEK標誌，每次讀取操作將消耗一個報文。
原因:
TCP是面向連接的，也就是說，在連接持續的過程中，socket中收到的數據都是由同一臺主機發出的(劫持什麼的不考慮)，因此，知道保證數據是有序的到達就行了，至於每次讀取多少數據自己看着辦。
而UDP是無連接的協議，也就是說，只要知道接收端的IP和端口，且網絡是可達的，任何主機都可以向接收端發送數據。這時候，如果一次能讀取超過一 個報文的數據，則會亂套。比如，主機A向發送了報文P1，主機B發送了報文P2，如果能夠讀取超過一個報文的數據，那麼就會將P1和P2的數據合併在了一 起，這樣的數據是沒有意義的。
udp如何實現可靠性傳輸
爲什麼要隨機選擇初始序號
主要是爲了安全，不讓第三方破壞。
如果不是隨機產生初始序列號，黑客將會以很容易的方式獲取到你與其他主機之間通信的初始化序列號，並且僞造序列號進行攻擊，這已經成爲一種很常見的網絡攻擊手段。
ACK和ack以及seq的區別
ack是確認號，ACK是6個控制位之一，僅當 ACK=1 時ack字段纔有效。建立 TCP 連接後，所有報文段都必須把 ACK 字段置爲 1。
seq是數據包本身的序列號，ack是期望對方繼續發送的那個數據包的序列號。
半連接狀態
在service端收到client的SYN報文後，會送一個ACK-SYN報文，然後sevice就會進入半連接狀態，等待最後一次握手。每一個半連接狀態都會存儲在一個隊列裏面，這時候如果僞造大量IP發送請求，就會導致service癱瘓。
爲什麼需要3次握手
一句話概括，TCP連接握手，握的是啥？
通信雙方數據原點的序列號！
A 代表發送方，B代表了接受方
這也就是說，如果只有2次握手，A和B只有對A的seq達成了共識，但是沒有對B的seq達成共識，必須增加第三次握手，才能達到對通信雙方各自的seq都有認知的事實。
爲什麼握手只要三次，而揮手要四次
因爲在握手的時候ACK和SYN在第二次握手的時候是一起傳的。但是由於TCP是全雙工的，斷開連接也是雙向的，也就是需要A申請斷開連接，B申請斷開連接，這樣子的兩次行爲。那麼在A發出FIN請求後，B指揮返回ACK，確認收到了A的請求，這個時候A已經不會再發送數據，但是B並沒有斷開連接，所以B可能還會發送一些數據給A，B發送完之後，B會發送FIN請求，最後需要A會送一個ACK，也就是需要四次揮手。
爲什麼揮手最後客戶端需要等待2*MSL
因爲A最後發送出去的ACK，可能會因爲網絡延遲等問題造成丟失。那麼如果B沒收收到ACK，就會觸發超時重傳機制，再次給A發送FIN消息。那麼A收到後，會重啓計時器，然後再次發送ACK報文以確保連接正常斷開。
換個方向來說，如果不等，釋放的端口可能會重連剛斷開的服務器端口，這樣依然存活在網絡裏的老的TCP報文可能與新TCP連接報文衝突，造成數據衝突，爲避免此種情況，需要耐心等待網絡老的TCP連接的活躍報文全部死翹翹，2MSL時間可以滿足這個需求。
總的的來說，就兩點
- 可靠地實現TCP全雙工連接的終止
- 允許老的重複分節在網絡中消逝，防止舊信息出現在新的連接中
四次揮手
- 主動關閉連接的一方，調用close()；協議層發送FIN包
- 被動關閉的一方收到FIN包後，協議層回覆ACK；然後**被動關閉的一方，進入CLOSE_WAIT狀態，**主動關閉的一方等待對方關閉，則進入FIN_WAIT_2狀態；此時，主動關閉的一方 等待 被動關閉一方的應用程序，調用close操作
- 被動關閉的一方在完成所有數據發送後，調用close()操作；此時，協議層發送FIN包給主動關閉的一方，等待對方的ACK，被動關閉的一方進入LAST_ACK狀態；
- 主動關閉的一方收到FIN包，協議層回覆ACK；此時，主動關閉連接的一方，進入TIME_WAIT狀態；而被動關閉的一方，進入CLOSED狀態
- 等待2MSL時間，主動關閉的一方，結束TIME_WAIT，進入CLOSED狀態
出現大量TIME-WAIT的原因
首先TIME-WAIT的出現在TCP四次揮手過程中主動斷開連接一方的一個狀態。當客戶端創建了許多短連接的時候，那麼就會出現很多TIME-WAIT狀態。
多個進程能否監聽同一個端口號？
可以
具體參考博客https://blog.csdn.net/jiyiqinlovexx/article/details/50959351
RST
RST：TCP首部中的6個標誌比特之一,表示重置連接、復位連接。
在TCP協議中RST表示復位，用來異常的關閉連接，在TCP的設計中它是不可或缺的。發送RST包關閉連接時，不必等緩衝區的包都發出去，直接就丟棄緩存區的包發送RST包。而接收端收到RST包後，也不必發送ACK包來確認。
出現RST包的原因：
- 服務器端口未打開而客戶端來連接時
- 在一個已關閉的SOCKET上收到數據
- 請求超時
- 提前關閉
服務端解決TIME_WAIT
服務端爲了解決這個TIME_WAIT問題，可選擇的方式有三種：
保證由客戶端主動發起關閉（即做爲B端）
關閉的時候使用RST的方式
-
發送RST包關閉連接時，不必等緩衝區的包都發出去，直接就丟棄緩衝區中的包，發送RST。
-
而接收端收到RST包後，也不必發送ACK包來確認。
對處於TIME_WAIT狀態的TCP允許重用
-
還可以通過調整內核參數來解決這個問題，我覺得開啓重用和快速回收比較重要。
net.ipv4.tcp_syncookies = 1 表示開啓SYN Cookies。當出現SYN等待隊列溢出時，啓用cookies來處理，可防範少量SYN攻擊，默認爲0，表示關閉；
net.ipv4.tcp_tw_reuse = 1 表示開啓重用。允許將TIME-WAIT sockets重新用於新的TCP連接，默認爲0，表示關閉；
net.ipv4.tcp_tw_recycle = 1 表示開啓TCP連接中TIME-WAIT sockets的快速回收，默認爲0，表示關閉。
net.ipv4.tcp_fin_timeout 修改系默認的 TIMEOUT 時間
TCP 協議如何保證可靠傳輸
校驗和： TCP 將保持它首部和數據的檢驗和。
流量控制： TCP 連接的每一方都有固定大小的緩衝空間，TCP的接收端只允許發送端發送接收端緩衝區能接納的據。當接收方來不及處理髮送方的數據，能提示發送方降低發送的速率，防止包丟失。TCP 使用的流量控制協議是可變大小的滑動窗口協議。 （TCP 利用滑動窗口實現流量控制）
擁塞控制： 當網絡擁塞時，減少數據的發送。
停止等待協議 也是爲了實現可靠傳輸的，它的基本原理就是每發完一個分組就停止發送，等待對方確認。在收到確認後再發下一個分組。
超時重傳： 當 TCP 發出一個段後，它啓動一個定時器，等待目的端確認收到這個報文段。如果不能及時收到一個確認，將重發這個報文段
使用擁塞窗口
TCP的擁塞控制採用了四種算法，即 慢開始 、 擁塞避免 、快重傳 和 快恢復。
慢開始： 慢開始算法的思路是當主機開始發送數據時，如果立即把大量數據字節注入到網絡，那麼可能會引起網絡阻塞，因爲現在還不知道網絡的符合情況。經驗表明，較好的方法是先探測一下，即由小到大逐漸增大發送窗口，也就是由小到大逐漸增大擁塞窗口數值。cwnd初始值爲1，每經過一個傳播輪次，cwnd加倍。、
擁塞避免： 擁塞避免算法的思路是讓擁塞窗口cwnd緩慢增大，即每經過一個往返時間RTT就把發送放的cwnd加1.
快重傳要求接收方在收到一個失序的報文段後就立即發出重複確認（爲的是使發送方及早知道有報文段沒有到達對方），而不要等到自己發送數據時捎帶確認。
快重傳算法規定，發送方只要一連收到3個重複確認就應當立即重傳對方尚未收到的報文段，而不必繼續等待設置的重傳計數器時間到期。
快恢復
（1）當發送方連續收到三個重複確認，就執行“乘法減小”算法，把慢開始門限ssthresh減半。這是爲了預防網絡發生擁塞。請注意：接下去不執行慢開始算法。
（2）由於發送方現在認爲網絡很可能沒有發生擁塞，因此與慢開始不同之處是現在不執行慢開始算法（即擁塞窗口cwnd現在不設置爲1），而是把cwnd值設置爲慢開始門限ssthresh減半後的數值，然後開始執行擁塞避免算法（“加法增大”），使擁塞窗口緩慢地線性增大。
在瀏覽器中輸入url地址 ->> 顯示主頁的過程
- 瀏覽器查找輸入域名對應的IP地址
- 現在本地host查找
- 本地DNS解析器緩存中查找
- 查詢首選DNS服務器（本地DNS服務器）
- 如果沒有轉發模式,就直接請求根域名服務器,沒有的話,返回一個對應的頂級域名服務器,繼續查詢,直到找到IP地址
- 如果用的是轉發模式，此DNS服務器就會把請求轉發至上一級DNS服務器，由上一級服務器進行解析，上一級服務器如果不能解析，或找根DNS或把轉請求轉至上上級，以此循環。
- 根據IP地址，請求建立連接（對於TCP而言）
- 瀏覽器發送HTTP請求
- 服務器相應請求，發送HTML請求
- 瀏覽器渲染相應的內容
關於HTTP的長短連接
在HTTP/1.0中默認使用短連接。也就是說，客戶端和服務器每進行一次HTTP操作，就建立一次連接，任務結束就中斷連接。當客戶端瀏覽器訪問的某個HTML或其他類型的Web頁中包含有其他的Web資源（如JavaScript文件、圖像文件、CSS文件等），每遇到這樣一個Web資源，瀏覽器就會重新建立一個HTTP會話。
而從HTTP/1.1起，默認使用長連接，用以保持連接特性。使用長連接的HTTP協議，會在響應頭加入這行代碼：
Connection:keep-alive
而且是需要客戶端和服務器端都設置纔有效。
在使用長連接的情況下，當一個網頁打開完成後，客戶端和服務器之間用於傳輸HTTP數據的TCP連接不會關閉，客戶端再次訪問這個服務器時，會繼續 用這一條已經建立的連接。Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務器軟件（如Apache）中設定這個時間。實現長連接需要客戶端和服務端都支持長連接。
HTTP的長短連接本質上是TCP的長短連接。
在建立客戶端和服務端的連接之後，完成了一次請求，這時候就會有兩種選擇，要麼是斷開連接，要麼是保持連接。那麼這就對應了TCP的兩種連接。
長連接可以省去較多的TCP建立和關閉的操作，減少浪費，節約時間。
短連接對於服務器來說管理較爲簡單，存在的連接都是有用的連接，不需要額外的控制手段
關於長短輪詢
1、短輪詢：
客戶端向服務器端發起請求，服務器端立即返回相關信息並且關閉鏈接。同時客戶端再次發起請求，與服務器端建立鏈接。
優點：後端程序的編寫簡單
缺點：大部分請求是無用的
2、長輪詢
與輪詢不同的是服務器端會hold住鏈接，等待有數據的情況下返回並且關閉連接。
區別：服務器端hold住請求，客戶端不會再請求數據。
優點：無消息的情況下不會再次發起請求
缺點： 會耗費服務端的性能
3、總結：
短輪詢和長輪詢主要是服務器端的實現方式，如果服務器端掛起請求等待消息則實現長輪詢，如果服務器端不管任何條件下都返回數據則爲短輪詢。這種方式可以稱之爲編程方式實現短輪詢和長輪詢。
常見的狀態碼
1xx(臨時響應)表示臨時響應並需要請求者繼續執行操作的狀態代碼
2xx (成功)表示成功處理了請求的狀態代碼
3xx (重定向) 表示要完成請求，需要進一步操作。 通常，這些狀態代碼用來重定向
4xx(請求錯誤) 這些狀態代碼表示請求可能出錯，妨礙了服務器的處理
5xx(服務器錯誤)這些狀態代碼表示服務器在嘗試處理請求時發生內部錯誤。 這些錯誤可能是服務器本身的錯誤，而不是請求出錯
常見的
200 (成功) 服務器已成功處理了請求。 通常，這表示服務器提供了請求的網頁。
201 (已創建) 請求成功並且服務器創建了新的資源。
202 (已接受) 服務器已接受請求，但尚未處理。
300 (多種選擇) 針對請求，服務器可執行多種操作。 服務器可根據請求者 (user agent) 選擇一項操作，或提供操作列表供請求者選擇。
301 (永久移動) 請求的網頁已永久移動到新位置。 服務器返回此響應(對 GET 或 HEAD 請求的響應)時，會自動將請求者轉到新位置。
400 (錯誤請求) 服務器不理解請求的語法。
401 (未授權) 請求要求身份驗證。 對於需要登錄的網頁，服務器可能返回此響應。
403 (禁止) 服務器拒絕請求。
404 (未找到) 服務器找不到請求的網頁。
500 (服務器內部錯誤) 服務器遇到錯誤，無法完成請求。
502 (錯誤網關) 服務器作爲網關或代理，從上游服務器收到無效響應。
504 (網關超時) 服務器作爲網關或代理，但是沒有及時從上游服務器收到請求。
HTTP和HTTPS的區別與聯繫
HTTP：是互聯網上應用最爲廣泛的一種網絡協議，是一個客戶端和服務器端請求和應答的標準（TCP），用於從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議，它可以使瀏覽器更加高效，使網絡傳輸減少。
HTTPS：是以安全爲目標的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL。
HTTPS和HTTP的區別主要如下：
1、https協議需要到ca申請證書，一般免費證書較少，因而需要一定費用。
2、http是超文本傳輸協議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協議。
3、http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，後者是443。
4、http的連接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。
Http的請求報文和響應報文
一個HTTP請求報文由請求行（request line)，消息頭部（header)，空行，請求正文4個部分組成。
- 請求行由請求方法，URL，HTTP協議版本3個字段組成，它們用空格分隔。
- 一些請求方法：GET、HEAD、PUT、POST、TRACE、OPTIONS、DELETE
- 消息頭部就是一些鍵值對，用於通知服務器有關於客戶端請求的信息。
- 空行用來通知以下是請求的正文
- 請求正文比如post方法就會包含數據
一個HTTP響應報文主要由狀態行、響應頭部、響應正文3部分組成。
- 狀態行由3部分組成，分別爲：協議版本，狀態碼，狀態碼描述，之間由空格分隔
- 響應頭部和請求頭類似
- 響應正文就是服務器響應的數據
HTTPS協議解析
HTTPS協議爲了保傳輸的安全，採用的是對稱加密算法（AES）+非對稱加密算法（RSA）+散列算法（MD5）的方式加密整個流程。
同時使用CA證書保證了證書的可靠性。證書=服務器公鑰+申請者與頒發者信息+簽名
下面是一個大概的基本流程。
- 客戶端請求建立https連接。
- 服務端會發送自己的CA證書給客戶端，這裏麪包含了服務端的公鑰，後於後續對對稱加密算法的傳遞。
- 客戶端會驗證這個證書
- 首先會驗證證書的頒發機構是不是可信任，如果不可信任，就會提示證書的不可信
- 如果可信，就會驗證數字簽名是否一致。首先對傳輸過來的數字簽名使用CA的公鑰解密，生成一份消息摘要。
- 然後對證書的信息使用哈希算法加密，也生成一份消息摘要，客戶端對兩份摘要進行對比，如果相同，則認爲證書正確。
- 客戶端隨機一個數字，作爲之後通信的對稱算法的密鑰，使用服務端的公鑰加密密鑰，保證這個數字不會被中間截取
- 服務端收到客戶端的信息，使用自己的私鑰解密，獲得對稱算法的密鑰。
- 之後通信雙方就會使用對稱算法的密鑰進行通信，保證了數據的安全性。
下圖是數字簽名的生成。
爲什麼使用對稱算法加密通信數據而不是非對稱算法？
原因是非對稱算法性能太低，影響速度。
CDN介紹
CDN即內容分發網絡，是基於用戶的地理位置、網頁的源地址還有就是一個內容分發服務器。距離CDN服務器越近的用戶，就能越快地獲取到靜態內容。
CDN緩存後的網站的訪問過程
(1) 用戶向瀏覽器提供要訪問的域名；
(2) 瀏覽器調用域名解析庫對域名進行解析得到CNAME，再解析CNAME域名獲取IP地址，在此過程中，使用的全局負載均衡DNS解析，如根據地理位置信息解析對應的IP地址，使得用戶能就近訪問;
(3) 這次解析到只是CDN服務器的IP地址，瀏覽器獲取這個IP地址就向CDN緩存發送請求;
(4) CDN緩存服務器根據瀏覽器提供的要訪問的域名，通過Cache內部專用DNS解析得到此域名的實際IP地址，再由緩存服務器向此實際IP地址提交訪問請求,緩存服務器就好像是中間人那樣子;
(5) CDN緩存服務器獲取內容後，一方面在本地存儲，以便客戶端下次訪問；另外一方面就發送給客戶端;
(6) 客戶端就把從CDN緩存服務器返回的內容顯示，下次訪問就直接訪問CDN緩存服務器。
使用CDN的好處
- 本地Cache加速，加快訪問速度
- 鏡像服務，消除運營商之間互聯的瓶頸影響，保證不同網絡的用戶都能得到良好的訪問質量
- 遠程加速，自動選擇cache服務器
- 帶寬優化，分擔網絡流量，減輕壓力，
- 集羣抗攻擊
- 節約成本
UDP如何實現可靠性傳輸
由於UDP在設計的時候是不可靠的，所以想要實現可靠的傳輸只能通過上層的應用層來控制。
應用層需要模仿TCP連接時候的可靠方法，比如實現確認機制、重傳機制、窗口確認機制。
目前有如下開源程序利用udp實現了可靠的數據傳輸。分別爲RUDP、RTP、UDT。