后端学习 - 计算机网络
生活随笔
收集整理的這篇文章主要介紹了
后端学习 - 计算机网络
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
文章目錄
- 一 基本概念
- 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 地址到顯示主頁的過程
總結
以上是生活随笔為你收集整理的后端学习 - 计算机网络的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 算法 - 排序算法
- 下一篇： 我选了一款带鱼屏游戏显示器我选了一款带鱼