后端学习 - 计算机网络
文章目錄
- 一 基本概念
- 1 計算機網絡體系結構
- 2 時延
- 二 應用層:HTTP
- 1 請求和響應報文
- 2 URL
- 3 HTTP 協議通信過程
- 4 HTTP 方法
- 5 HTTP 狀態碼
- 6 短連接、長連接與流水線
- 7 Cookie
- 8 Session
- 9 緩存
- 三 應用層:HTTPS
- 1 加密方式
- 2 證書認證
- 四 應用層:其它協議
- 1 DNS
- 2 FTP
- 3 SMTP、POP3、IMAP
- 4 DHCP
- 五 傳輸層:TCP & UDP
- 1 TCP vs UDP
- 2 三次握手
- 3 四次揮手
- 4 TCP 如何實現可靠傳輸
- 5 滑動窗口協議
- 6 TCP 流量控制
- 7 TCP 擁塞控制
- 六 常見問題
- 1 從輸入 URL 地址到顯示主頁的過程
一 基本概念
1 計算機網絡體系結構
數據在各層之間的傳遞過程:在向下的過程中,需要添加下層協議所需要的首部或者尾部,而在向上的過程中不斷拆開首部和尾部
| 應用層 | 為特定應用程序提供數據傳輸服務,例如 HTTP、DNS 等協議,數據單位為報文 |
| 傳輸層 | 為進程提供通用數據傳輸服務,包括兩種協議:傳輸控制協議 TCP,提供面向連接、可靠的數據傳輸服務,數據單位為 報文段 (主要提供完整性服務);用戶數據報協議 UDP,提供無連接、盡最大努力的數據傳輸服務,數據單位為 用戶數據報(主要提供及時性服務 ) |
| 網絡層 | 為主機提供數據傳輸服務,把傳輸層傳遞下來的報文段或者用戶數據報封裝成分組 |
| 數據鏈路層 | 為同一鏈路的主機提供數據傳輸服務,把網絡層傳下來的分組封裝成幀 |
| 物理層 | 在傳輸媒體上傳輸數據比特流 |
2.OSI七層協議
- 應用層、表示層、會話層、傳輸層、網絡層、數據鏈路層、物理層
- 表示層 :數據壓縮、加密以及數據描述,這使得應用程序不必關心在各臺主機中數據內部格式不同的問題
- 會話層 :建立及管理會話
- 五層協議沒有表示層和會話層,而是將這些功能留給應用程序開發者處理
3.TCP/IP 協議
- 應用層、傳輸層、網際層、網絡接口層
- 相當于五層協議中數據鏈路層和物理層合并為網絡接口層
- 不嚴格遵循 OSI 分層概念,應用層可能會直接使用 IP 層或者網絡接口層
2 時延
總時延 = 排隊時延 + 處理時延 + 傳輸時延 + 傳播時延
- 排隊時延:分組在路由器的輸入隊列和輸出隊列中排隊等待的時間,取決于網絡當前的通信量
- 處理時延:主機或路由器收到分組時進行處理所需要的時間,例如分析首部、從分組中提取數據、進行差錯檢驗或查找適當的路由等
- 傳輸時延:主機或路由器傳輸數據幀所需要的時間
- 傳播時延:電磁波在信道中傳播所需要花費的時間,電磁波傳播的速度接近光速
二 應用層:HTTP
1 請求和響應報文
- 客戶端發送一個請求報文給服務器,服務器根據請求報文中的信息進行處理,并將處理結果放入響應報文中返回給客戶端
- 請求報文
第一行是包含了請求方法、URL、協議版本;
接下來的多行都是請求首部 Header,每個首部都有一個首部名稱,以及對應的值;
一個空行用來分隔首部和內容主體 Body
最后是請求的內容主體
- 響應報文
第一行包含協議版本、狀態碼以及描述
接下來多行也是首部內容
一個空行分隔首部和內容主體
最后是響應的內容主體
2 URL
- URI(Uniform Resource Identifier,統一資源標識符)是抽象的標識資源的方式,它的具體實現包括 URL( Uniform Resource Locator,統一資源定位符) 和 URN (Uniform Resource Name,統一資源名稱)
- 以上并不代表 URI = URL + URN,而是代表 URL 是 URI,URN 也是 URI
- HTTP 使用 URL 來定位資源
3 HTTP 協議通信過程
HTTP 是應用層協議,它以 TCP(傳輸層)作為底層協議,默認端口為 80
4 HTTP 方法
- 安全的 HTTP 方法不會改變服務器的狀態。從這個角度出發,GET、HEAD、OPTIONS 是安全的,而 POST、DELETE‘PUT 是不安全的
- 冪等的 HTTP 方法,同樣的請求被執行一次與連續執行多次的效果是一樣的(冪等方法不應該具有副作用)。從這個角度出發,GET,HEAD,PUT 和 DELETE 等方法都是冪等的,而 POST 方法不是
獲取資源
獲取報文首部,和 GET 方法類似,但是不返回報文實體主體部分
主要用于確認 URL 的有效性以及資源更新的日期時間等
傳輸實體主體
上傳文件
沒有驗證機制,存在安全性問題,一般不使用
對資源進行部分修改
PUT 也可以用于修改資源,但是只能完全替代原始資源,PATCH 允許部分修改
與 PUT 功能相反,并且同樣不帶驗證機制
查詢指定的 URL 能夠支持的 HTTP 方法
要求在與代理服務器通信時建立隧道
使用 SSL(Secure Sockets Layer,安全套接層)和 TLS(Transport Layer Security,傳輸層安全)協議把通信內容加密后經網絡隧道傳輸
追蹤路徑,服務器會將通信路徑返回給客戶端
發送請求時,在 Max-Forwards 首部字段中填入數值,每經過一個服務器就會減 1,當數值為 0 時就停止傳輸
5 HTTP 狀態碼
- 服務器返回的 響應報文 中第一行為狀態行,包含了狀態碼以及原因短語,用來告知客戶端請求的結果
6 短連接、長連接與流水線
- 短連接每進行一次 HTTP 通信就要新建一個 TCP 連接,長連接只需要建立一次 TCP 連接就能進行多次 HTTP 通信
- 在 HTTP/1.1 之前默認短連接,HTTP/1.1 及之后開始默認長連接
- 默認情況下,HTTP 請求是按順序發出的,下一個請求只有在當前請求收到響應之后才會被發出。流水線是在 同一條長連接上連續發出請求,而不用等待響應返回,這樣可以減少延遲
7 Cookie
- HTTP 是無狀態的協議,HTTP/1.1 引入 Cookie 來保存狀態信息
- Cookie 由服務器發送到用戶瀏覽器,并存放在客戶端,在瀏覽器之后向同一服務器再次發起請求時被攜帶上,用于告知服務端兩個請求是否來自同一瀏覽器
- 創建過程:
8 Session
除了可以將用戶信息通過 Cookie 存儲在用戶瀏覽器中,也可以利用 Session 存儲在服務器端,存儲在服務器端的信息更加安全
Cookie 被禁用怎么辦?
最常用的就是利用 URL 重寫把 Session ID 直接附加在 URL 路徑的后面
9 緩存
- 使用緩存可以緩解服務器壓力,并能降低客戶端獲取資源的延遲
- 可以利用 代理服務器,或客戶端瀏覽器 進行緩存
三 應用層:HTTPS
- 默認端口號是 443
- 讓 HTTP 先和 SSL(Secure Sockets Layer)通信,再由 SSL 和 TCP 通信,也就是說 HTTPS 使用了隧道進行通信
- 通過使用 SSL,HTTPS 具有了加密(防竊聽)、認證(防偽裝)和完整性保護(防篡改)
1 加密方式
-
對稱密鑰:加密和解密使用同一密鑰
-
非對稱密鑰:公開密鑰所有人都可以獲得,通信發送方獲得 接收方的公開密鑰 之后,就可以使用公開密鑰進行加密,接收方收到通信內容后使用私有密鑰解密
-
HTTPS 采用混合加密機制:
使用 非對稱密鑰 加密方式,傳輸 對稱密鑰 加密方式所需要的 Secret Key,從而保證安全性;
獲取到 Secret Key 后,再使用 對稱密鑰加密方式進行通信 ,從而保證效率
2 證書認證
根本目的是傳遞服務器的公鑰
四 應用層:其它協議
1 DNS
- DNS 是一個分布式數據庫,提供了主機名和 IP 地址之間 相互轉換 的服務
- 域名具有層次結構,從上到下依次為:根域名、頂級域名、二級(權威)域名
- DNS 可以使用 UDP 或者 TCP 進行傳輸,使用的端口號都為 53
- 一般使用 UDP 進行傳輸,除非返回的響應超過的 512 字節(UDP 最大只支持 512 字節的數據)
- 查詢可以通過兩種方式:遞歸查詢和迭代查詢
2 FTP
- 使用兩個 TCP 連接進行文件傳輸,分別是數據連接和控制連接
- 數據連接:用來傳送文件數據
- 控制連接:服務器打開端口號 21 等待客戶端的連接,客戶端主動建立連接后,使用這個連接將客戶端的命令傳送給服務器,并傳回服務器的應答
- 根據 數據連接 (而非控制連接,因為控制連接一定是客戶端主動建立的)是否是服務器端主動建立,FTP 有主動和被動兩種模式
- 主動連接:服務器端主動建立數據連接,服務器端口號為20,客戶端端口號隨機
- 被動模式:客戶端主動建立數據連接,客戶端端口號由客戶端自己指定,服務器端口號隨機
3 SMTP、POP3、IMAP
- SMTP 是發送協議,POP3 和 IMAP 是讀取協議
- 因為需要保證郵件傳遞可靠,所以都基于 TCP 連接
如何判斷郵箱是否存在?利用 SMTP 協議
4 DHCP
- 動態主機配置協議提供了即插即用的連網方式,用戶不再需要手動配置 IP 地址等信息
五 傳輸層:TCP & UDP
1 TCP vs UDP
- UDP(User Datagram Protocol)是無連接的,盡最大可能交付,沒有擁塞控制,面向報文(對于應用程序傳下來的報文不合并也不拆分,只是添加 UDP 首部),支持一對一、一對多、多對一和多對多的交互通信
- TCP(Transmission Control Protocol)是面向連接的,提供可靠交付,有流量控制,擁塞控制,提供全雙工通信,面向字節流(把應用層傳下來的報文看成字節流,把字節流組織成大小不等的數據塊),每一條 TCP 連接只能是點對點的(一對一)
2 三次握手
三次握手的目的是建立可靠的通信信道,讓雙方確認自己與對方的發送與接收是正常的
- 第一次握手(SYN):Client 什么都不能確認;Server 確認了對方發送正常,自己接收正常
- 第二次握手(SYN/ACK):Client 確認自己發送、接收正常,對方發送、接收正常;Server 確認對方發送正常,自己接收正常
- 第三次握手(ACK):Client 確認自己發送、接收正常,對方發送、接收正常;Server 確認自己發送、接收正常,對方發送、接收正常
3 四次揮手
- 第一次揮手(FIN):客戶端-發送一個 FIN,用來關閉客戶端到服務器的數據傳送
- 第二次揮手(ACK):服務器-收到這個 FIN,它發回一 個 ACK,確認序號為收到的序號加 1 。和 SYN 一樣,一個 FIN 將占用一個序號
- 第三次揮手(FIN):服務器-關閉與客戶端的連接,發送一個 FIN 給客戶端
- 第四次揮手(ACK):客戶端-發回 ACK 報文確認,并將確認序號設置為收到序號加 1
- 為什么客戶端接收到服務器端的 FIN 報文后,進入 TIME_WAIT 狀態而不是 CLOSED 狀態?
是為了確保最后一個確認報文能夠到達。如果 B 沒收到 A 發送來的確認報文,那么就會重新發送連接釋放請求報文,A等待一段時間就是為了處理這種情況的發生
4 TCP 如何實現可靠傳輸
5 滑動窗口協議
- 限制發送方 已發送但未確認的分組數 最大為N
- 采用 累計確認 的機制
- 優點是接收方不需要緩存亂序分組,只需關注下一個分組的序號
- 缺點是丟棄亂序到達的分組,發生重傳的分組數增加
- 發送方只重傳真正丟失的分組
- 發送方只確認已經到達的分組的序號,而不采用累計確認
- 接收方緩存失序到達的分組,同時接收方永遠不會把分組失序地交給應用層,而是先要等待那些更早發送的分組到達
6 TCP 流量控制
- 流量控制是速度匹配服務,即發送方的發送速率和接收方的接收速率相匹配
- 接收窗口(接收方緩沖區空閑塊大小)的計算方法
rwnd = RcvBuffer - [LastByteRcvd - LastByteRead]
RcvBuffer:接收方的緩沖區大小
LastByteRcvd:緩沖區接收到的從網絡層到達的數據流的最后一個字節的編號
LastByteRead:接收方應用進程從緩存中讀出的數據流的最后一個字節的編號
- 當接收方的接收窗口為0,即緩存滿的時候,發送方繼續發送只有一個字節數據的報文段,保證了后續的傳輸能正常進行
7 TCP 擁塞控制
- TCP 采用的是端到端的擁塞控制,而非網絡輔助的擁塞控制,因為網絡層不向端系統提供顯式的網絡擁塞反饋
- 對于不同原因引起的 Loss,處理策略不同:
如果收到3個重復 ACK(網絡還能夠傳輸一些報文段),設置 cwnd 為原來的一半,然后進入擁塞避免
如果發生超時(更嚴重的擁塞),設置 cwnd = 1,然后進入慢啟動
慢啟動
慢啟動指,TCP 發送速率起始慢,但以指數增長
初始發送時,cwnd 通常設置為一個較小值 MSS,發送報文段后等待確認,如果收到確認則 cwnd 翻倍
到達慢啟動閾值(如果丟包,設置慢啟動閾值 ssthresh = cwnd / 2)時,停止慢啟動,進入擁塞避免
擁塞避免
當 cwnd 到達慢啟動閾值時,接近擁塞狀態,此時 cwnd 線性增長
如果遇到 Loss,更新慢啟動閾值為 cwnd / 2 ,根據產生 Loss 的原因采取不同的策略
(圖中并不包含快速恢復,僅包含慢啟動和擁塞避免)
- 當收到3個重復ACK時,ssthresh = cwnd / 2,cwnd = ssthresh + 3,然后重傳丟失的報文段,加3是因為收到3個重復的ACK,表明有3個“老”的數據包離開了網絡
- 再收到重復的ACK時,cwnd++
- 收到新的數據包的ACK時,cwnd = ssthresh。原因是確認了新的數據,說明重復ACK的數據都已收到,可以回到恢復之前的狀態(擁塞避免狀態)
六 常見問題
1 從輸入 URL 地址到顯示主頁的過程
總結
以上是生活随笔為你收集整理的后端学习 - 计算机网络的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 算法 - 排序算法
- 下一篇: 我选了一款带鱼屏游戏显示器我选了一款带鱼