當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

后端学习 - 计算机网络

發布時間：2023/12/4 编程问答 38 豆豆

生活随笔收集整理的這篇文章主要介紹了后端学习 - 计算机网络小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

文章目錄

一基本概念
- 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
最后是請求的內容主體

GET http://www.example.com/ HTTP/1.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 Accept-Encoding: gzip, deflate Accept-Language: zh-CN,zh;q=0.9,en;q=0.8 Cache-Control: max-age=0 Host: www.example.com If-Modified-Since: Thu, 17 Oct 2019 07:18:26 GMT If-None-Match: "3147526947+gzip" Proxy-Connection: keep-alive Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 xxxparam1=1&param2=2

響應報文
第一行包含協議版本、狀態碼以及描述
接下來多行也是首部內容
一個空行分隔首部和內容主體
最后是響應的內容主體

HTTP/1.1 200 OK Age: 529651 Cache-Control: max-age=604800 Connection: keep-alive Content-Encoding: gzip Content-Length: 648 Content-Type: text/html; charset=UTF-8 Date: Mon, 02 Nov 2020 17:53:39 GMT Etag: "3147526947+ident+gzip" Expires: Mon, 09 Nov 2020 17:53:39 GMT Keep-Alive: timeout=4 Last-Modified: Thu, 17 Oct 2019 07:18:26 GMT Proxy-Connection: keep-alive Server: ECS (sjc/16DF) Vary: Accept-Encoding X-Cache: HIT<!doctype html> <html> <head><title>Example Domain</title>// 省略... </body> </html>

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

服務器在 80 端口等待客戶的請求

瀏覽器發起到服務器的 TCP 連接（創建套接字 Socket）

服務器接收來自瀏覽器的 TCP 連接

瀏覽器（HTTP 客戶端）與 Web 服務器（HTTP 服務器）交換 HTTP 消息

關閉 TCP 連接

4 HTTP 方法

安全的 HTTP 方法不會改變服務器的狀態。從這個角度出發，GET、HEAD、OPTIONS 是安全的，而 POST、DELETE‘PUT 是不安全的
冪等的 HTTP 方法，同樣的請求被執行一次與連續執行多次的效果是一樣的（冪等方法不應該具有副作用）。從這個角度出發，GET，HEAD，PUT 和 DELETE 等方法都是冪等的，而 POST 方法不是

GET
獲取資源

HEAD
獲取報文首部，和 GET 方法類似，但是不返回報文實體主體部分
主要用于確認 URL 的有效性以及資源更新的日期時間等

POST
傳輸實體主體

PUT
上傳文件
沒有驗證機制，存在安全性問題，一般不使用

PATCH
對資源進行部分修改
PUT 也可以用于修改資源，但是只能完全替代原始資源，PATCH 允許部分修改

DELETE
與 PUT 功能相反，并且同樣不帶驗證機制

OPTIONS
查詢指定的 URL 能夠支持的 HTTP 方法

CONNECT
要求在與代理服務器通信時建立隧道
使用 SSL（Secure Sockets Layer，安全套接層）和 TLS（Transport Layer Security，傳輸層安全）協議把通信內容加密后經網絡隧道傳輸

TRACE
追蹤路徑，服務器會將通信路徑返回給客戶端
發送請求時，在 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 由服務器發送到用戶瀏覽器，并存放在客戶端，在瀏覽器之后向同一服務器再次發起請求時被攜帶上，用于告知服務端兩個請求是否來自同一瀏覽器
創建過程：

# 服務器發送的響應報文包含 Set-Cookie 首部字段 # 客戶端得到響應報文后把 Cookie 內容保存到瀏覽器中 HTTP/1.0 200 OK Content-type: text/html Set-Cookie: yummy_cookie=choco Set-Cookie: tasty_cookie=strawberry[page content] # 客戶端之后對同一個服務器發送請求時會從瀏覽器中取出 Cookie 信息 # 通過 Cookie 請求首部字段發送給服務器 GET /sample_page.html HTTP/1.1 Host: www.example.org Cookie: yummy_cookie=choco; tasty_cookie=strawberry

8 Session

除了可以將用戶信息通過 Cookie 存儲在用戶瀏覽器中，也可以利用 Session 存儲在服務器端，存儲在服務器端的信息更加安全

用戶進行登錄時，用戶提交包含用戶名和密碼的表單，放入 HTTP 請求報文中；

服務器驗證該用戶名和密碼，如果正確則把用戶信息存儲到 Redis 中，它在 Redis 中的 Key 稱為 Session ID；

服務器返回的響應報文的 Set-Cookie 首部字段包含了這個 Session ID，客戶端收到響應報文之后將該 Cookie 值存入瀏覽器中；

客戶端之后對同一個服務器進行請求時會包含該 Cookie 值，服務器收到之后提取出 Session ID，從 Redis 中取出用戶信息，繼續之前的業務操作

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 證書認證

根本目的是傳遞服務器的公鑰

數字證書認證機構（CA，Certificate Authority）是客戶端與服務器雙方都可信賴的第三方機構

CA 知道服務器的公鑰，向服務器頒發證書，并附上 CA 私鑰對消息摘要的加密簽名

服務器獲得 CA 辦法的證書，并將證書傳遞給客戶端

客戶端獲得證書，并且客戶端知道 CA 公鑰，使用 CA 公鑰對證書上的簽名解密，同時對消息進行散列處理得到摘要

比較摘要，驗證證書的真實性。如果客戶端驗證服務器的證書是真實的，則信任服務器的公鑰

四應用層：其它協議

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 協議

查找郵箱域名對應的 SMTP 服務器地址

嘗試與服務器建立連接

連接成功后嘗試向需要驗證的郵箱發送郵件

根據返回結果判定郵箱地址的真實性

4 DHCP

動態主機配置協議提供了即插即用的連網方式，用戶不再需要手動配置 IP 地址等信息

客戶端發送 Discover 報文，該報文的目的地址為 255.255.255.255:67，源地址為 0.0.0.0:68，被放入 UDP 中，該報文被廣播到同一個子網的所有主機上。如果客戶端和 DHCP 服務器不在同一個子網，就需要使用中繼代理

DHCP 服務器收到 Discover 報文之后，發送 Offer 報文給客戶端，該報文包含了客戶端所需要的信息。因為客戶端可能收到多個 DHCP 服務器提供的信息，因此客戶端需要進行選擇

如果客戶端選擇了某個 DHCP 服務器提供的信息，那么就發送 Request 報文給該 DHCP 服務器

DHCP 服務器發送 Ack 報文，表示客戶端此時可以使用提供給它的信息

五傳輸層：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 如何實現可靠傳輸

TCP 給發送的每一個包進行編號，接收方對數據包進行排序，把有序數據傳送給應用層

TCP 報文段校驗和。端到端的檢驗和，如果收到段的校驗和有差錯，TCP 將丟棄這個報文段

TCP 的接收端會丟棄重復的數據

流量控制：當接收方來不及處理發送方的數據，能提示發送方降低發送的速率，防止包丟失（接收方發送的確認報文中的窗口字段可以用來控制發送方窗口大小，從而影響發送方的發送速率）

擁塞控制：當網絡擁塞時，減少數據的發送（發送方的 發送窗口大小，即已發送未確認的大小 為 擁塞窗口 和接收方的 接收窗口 中較小的一個：LastByteSent - LastByteAcked = min{receive_window, crowd_window}）

超時重傳：當 TCP 發出一個段后，啟動一個定時器，等待目的端確認收到這個報文段。如果不能及時收到確認，將重發報文段

5 滑動窗口協議

GBN 回退N步協議

限制發送方 已發送但未確認的分組數 最大為N
采用 累計確認 的機制
優點是接收方不需要緩存亂序分組，只需關注下一個分組的序號
缺點是丟棄亂序到達的分組，發生重傳的分組數增加

SR 選擇重傳協議

發送方只重傳真正丟失的分組
發送方只確認已經到達的分組的序號，而不采用累計確認
接收方緩存失序到達的分組，同時接收方永遠不會把分組失序地交給應用層，而是先要等待那些更早發送的分組到達

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 地址到顯示主頁的過程

用戶輸入 URL，通過 UDP 連接向 DNS 服務器請求獲取域名對應的 IP 地址

用戶獲得 IP 地址，與服務器建立 HTTP 連接（HTTP 基于 TCP 連接，三次握手）

用戶向服務器發送 HTTP Request

服務器處理請求（這里又可以展開到 Spring MVC 的執行流程），返回 HTTP Response

瀏覽器渲染頁面

總結

以上是生活随笔為你收集整理的后端学习 - 计算机网络的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇：算法 - 排序算法
下一篇： cheatengine找不到数值_彩票中