計算機網路複習筆記

AlexEz發表於2021-03-02

Author：AlexEz Mail：mao.looper@gmail.com
若發現錯誤和遺漏請指正
原創，禁止轉載

1 計算機網路概述

介面與協議的區別

介面規定了執行在一個端系統上的程式請求因特網基礎設施向執行在另一個端系統上的特定目的地程式交付資料的方式

協議定義了在兩個或多個通訊實體之間交換的報文的格式和順序，以及報文傳送/或接收一條報文或其他事件所採取的動作。

TCP/IP只是一個協議棧，就像作業系統的執行機制一樣，必須要具體實現，同時還要提供對外的操作介面。這個就像作業系統會提供標準的程式設計介面，比如win32程式設計介面一樣，TCP/IP也要提供可供程式設計師做網路開發所用的介面，這就是Socket程式設計介面。

1.1 網路概念

網路：許多計算機連在一起
網際網路： internet 許多網路連在一起
因特網： Internet 全求最大的網際網路

1.2 資料交換方式

電路交換（Circuit Switching）實時性、建立專用路線
報文交換（Message Switching）報文一般比分組長、報文交換的時延較長
分組交換（Packet Switching）高效、迅速時延高
- 路由器儲存轉發功能

1.3 網路分類

按作用範圍分：

新的理解，不單單從網路覆蓋的範圍來區分廣域網、區域網

使用了廣域網技術即廣域網

使用了區域網技術即區域網

區域網：自己花錢購買裝置、自己維護、頻寬固定（100M，1000M），距離一般在100m以內
廣域網：花錢買服務、花錢買頻寬

1.4 網路的效能指標

速率：數字通道上傳送資料位數的速率
頻寬：數字通道能傳送的最高速率 (b/s)
吞吐量(Throughput)：傳送端與接收端之間傳送資料速率（b/s）瓶頸鍊路
時延：
- 傳送(傳輸)時延(transmission delay)=$分組長度(bit)/鏈路頻寬(bit/s)$
- 傳播時延(propagation delay)=$物理鏈路長度(m)/訊號在通道上的傳播速率(m/s)$
- 處理時延：差錯檢測、確定輸出鏈路，一般<msec
- 排隊時延：分組在路由器快取中排隊產生，等待輸出鏈路可用
  - 丟包：分組到達速率超出輸出鏈路容量時，超出部分丟棄
時延頻寬積=$傳播時延\times頻寬$ ;又稱以位元為單位的鏈路長度
RTT（Round-Trip Time）往返時間
利用率：
- 通道利用率
- 網路利用率：通道利用率加權平均值

1.5 網路體系結構

優點：模組化的分層易於系統的更新、維護，任何一層服務的改變對於系統其他層都是透明的

1. 概念

實體（Entity）：交換資訊的硬體或軟體程式
協議（Protocol）：控制兩個對等通訊的規則
服務（Service）：下層向上層提供服務，上層需要下層提供的服務來實現本層的功能
服務訪問點（SAP）：相鄰兩層實體間交換資訊的地方

2. OSI參考模型

（Reference Model）

1 物理層

編碼方式
- 單/雙極性不歸零碼
- 單/雙極性歸零碼 (缺點：無法判斷結束訊號)
- 曼切斯特編碼
- 差分曼切斯特編碼（抗干擾更強）
傳輸模式
- 單工（Simplex）
- 半雙工（half-duplex）
- 全雙工（full-duplex）
介面特性
- 機械、電氣、功能、規程特性
位元同步
- 時鐘同步

2 資料鏈路層

負責結點-結點（node-to-node）資料傳輸
組幀（Framing）
物理定址（Physical addressing）
流量控制（Flow control）
- 避免淹沒接收端
差錯控制（Error control）
- 檢測並重傳損壞或丟失幀，並避免重複幀
訪問(接入)控制（Access control）
- 在任一給定時刻決定哪個裝置擁有鏈路（物理介質控制使用權）

3 網路層

負責源主機到目的主機資料分組（packet）交付：跨越多個網路
邏輯定址（Logical addressing）：全域性唯一，IP地址
路由（Routing）：路徑選擇
分組轉發

4 傳輸層

負責源-目的（端-端）（程式間）完整報文傳輸
報文分段與重組
SAP定址
- 確保將完整報文提交給正確程式，如埠號
連線控制
流量控制
差錯控制

5 會話層

對話控制（dialog controlling）
- 建立、維護
同步（synchronization）
- 在資料流中插入“同步點”
最“薄”的一層

6 表示層

處理兩個系統間交換資訊的語法與語義（syntax and semantics）問題
資料表示轉化
- 轉換為主機獨立的編碼
加密/解密
壓縮/解壓縮

7 應用層

支援使用者通過使用者代理（如瀏覽器）或網路介面使用網路(服務)
典型應用層服務
- 檔案傳輸（FTP）
- 電子郵件（SMTP）
- Web（HTTP）
- ......

通訊過程

資料封裝

增加控制資訊：構造協議資料單元（PDU）
- 地址（Address）：標識傳送端/接收端
- 差錯檢測碼（Error-detecting code）
- 協議控制（Protocol control）：實現協議功能的附加資訊

網路排錯

從底層到高層

物理層安全

資料鏈路層安全：ADSL、無線AP

網路層安全

應用層安全：SQL隱碼攻擊漏洞、上傳漏洞

3. TCP/IP參考模型

實際網路的執行方式

IP over Everything

4. 5層參考模型

綜合OSI和TCP/IP的優點

5層結構

應用層: 通過應用程式間的互動來完成特定網路應用。應用層協議定義的是應用程式間通訊和互動的規則。

FTP, SMTP, HTTP
傳輸層: 運輸層的任務是負責為兩個主機中程式之間的通訊提供通用的資料傳輸服務。應用程式利用該服務傳送應用層報文：

TCP, UDP
網路層: 網路層為分組交換網上不同主機提供通訊服務。網路層將運輸層產生的報文段或使用者資料包封裝成分組和包進行傳送

IP協議、路由協議等
鏈路層: 兩臺主機間的資料傳輸，總是一段一段在資料鏈路上傳送的，這就需要使用專門的鏈路層協議。在兩個相鄰節點間的鏈路上傳送幀，每一幀包括資料和必要的控制資訊（如同步資訊，地址資訊，差錯控制等）。相鄰網路元素（主機、交換機、路由器等）的資料傳輸

乙太網（Ethernet）、802.11 (WiFi)、 PPP
物理層:位元傳輸

資料封裝

2. 應用層

2.1 體系結構

1. 客戶機/伺服器結構（Client/Server）

伺服器

24小時不間斷提供服務

永久性訪問地址/域名

利用大量伺服器實現可擴充套件性
客戶機

使用伺服器提供的服務

間歇性接入網路

可能使用動態IP地址

不會與其他客戶機直接通訊

2. P2P結構（peer-to-peer）

沒有永遠線上的伺服器
任意端系統/節點之間可以直接通訊
節點間歇性接入網路
節點可能改變IP地址

高度可伸縮，難以管理

3. 混合結構

綜合以上兩者的優點，規避缺點。如Napster

2.2 程式間通訊

1. Socket

客戶機程式：發起通訊的程式

伺服器程式：等待通訊請求的程式

同一主機上的程式通訊有程式間通訊機制，由作業系統提供：管道、訊息佇列、共享記憶體、訊號量

不同主機間的程式通訊：使用套接字（Socket）,也稱為網路程式設計的API

2. 定址

IP地址
埠號/Port number
- 為主機上每個需要通訊的程式分配一個埠號

3. 應用層協議

網路應用需遵循應用層協議
公開協議：由RFC（Request For Comments）定義
私有協議 : 多數P2P共享檔案應用
訊息型別（type）
訊息語法（syntax）
欄位語義（semantics）
規則（rules）

2.3 Web應用

1. HTTP協議

C/S結構
請求(命令)/響應互動模式
使用TCP傳輸服務
- 伺服器在80埠等待客戶請求
- 瀏覽器發起TCP連線請求
- 伺服器接受TCP連線
- 交換HTTP訊息
- 關閉TCP連線
無狀態（stateless）
- 伺服器不維護任何有關客戶端過去所發請求的資訊
1.0version 非永續性連線
- 每次傳輸一個物件
- 任何格式的內容都可以傳送，這使得網際網路不僅可以傳輸文字，還能傳輸影像、視訊、二進位制等檔案
- 有GET、POST、HEAD請求命令
- 響應時間：2RTT+檔案傳送時間
1.1version 永續性連線
- 每次可傳輸多個物件
- 支援長連線（persistent connection）和請求的流水線（pipelining），connection欄位預設keep-alive
- 錯誤通知的管理：新增了24個錯誤狀態碼
- 頻寬優化及網路連線的使用：增加range頭域，允許只請求資源的某個部分
- 新增方法：PUT、 PATCH、 OPTIONS、 DELETE
請求訊息
響應訊息
2.0 version 提升效能
- 多路複用，允許同時通過單一的HTTP/2連線發起多重的請求-響應訊息
- 二進位制分幀，文字表示形式多樣，需要考慮較多場景，二進位制比文字更方便健壯
- header壓縮，通訊雙方各自cache一份header fields表避免重複header傳輸
- 服務端推送
3.0 version QUIC實現機制
- 基於UDP協議
- 快速重啟會話（支援手機網路切換），使用uuid來標識每一次連線，網路環境變化但uuid不變就不需要握手
與HTTPS的區別
- https需要到CA申請證照
- http執行在tcp上，所有傳輸的資料都是明文的，https執行在SSL/TLS之上，所有傳輸的內容都經過加密
- http預設埠為80，後者是443
HTTPS工作流程

第一步：客戶使用https的URL訪問Web伺服器，要求與Web伺服器建立SSL連線。

第二步：Web伺服器收到客戶端請求後，會將網站的證照資訊（證照中包含公鑰）傳送一份給客戶端。

第三步：客戶端的瀏覽器與Web伺服器開始協商SSL連線的安全等級，也就是資訊加密的等級。

第四步：客戶端的瀏覽器根據雙方同意的安全等級，建立會話金鑰（隨機產生），然後利用網站的公鑰將會話金鑰加密，並傳送給網站。

第五步：Web伺服器利用自己的私鑰解密出會話金鑰。

第六步：Web伺服器利用會話金鑰加密與客戶端之間的通訊。
Q: 使用者訪問一個網站的時候背後的過程與步驟是怎樣的？

A: 基本流程：

利用DNS協議進行域名解析 --> 建立tcp協議三次握手過程 --> 客戶端發出訪問網站相應頁面請求（發出http協議請求報文） --> 服務端發出相應訪問頁面的響應資訊（發出http響應報文） --> 斷開tcp協議四次揮手過程
1. DNS查詢順序：Hosts表-->本地DNS快取-->上層DNS(迭代、泛洪)
2. 在本機與目標伺服器之間的路由過程，包括IP協議、ARP協議、OSPF協議、BGP協議
3. 拿到響應訊息了還需要瀏覽器進行解析渲染

記錄使用者狀態，有隱私問題

響應訊息cookie頭部行
請求訊息cookie頭部行
儲存在客戶端主機上的cookie檔案，由瀏覽器管理
Web伺服器後臺資料庫

3. Web快取/代理伺服器技術

一般由ISP架設

在不訪問伺服器的前提下滿足客戶端的HTTP請求
縮短客戶請求的響應時間
減少機構/組織的流量
在大範圍內實現有效的內容分發（CDN）

條件性GET方法更新快取的資料，解決一致性問題

2.4 Email應用

1. 郵件客戶端（user agent）

2. 郵件伺服器（mail server）

郵箱：儲存發給該使用者的Email
訊息佇列（message queue）：儲存等待傳送的Email

3. SMTP協議（Simple Mail Transfer Protocol）

客戶端：傳送訊息的伺服器
服務端：接受訊息的伺服器
使用TCP進行Email訊息的可靠傳輸
埠25
傳輸三個階段
- 握手
- 訊息傳輸
- 關閉
命令/響應互動模式
- 命令command ：ASCII文字
- 響應 response：狀態程式碼和語句

//先去qq郵箱開啟smtp，獲取授權碼
//輸入需要進行base64加密
c:telnet smtp.qq.com 25
s:220 xxx.qq.com
c:helo host //打招呼
s:250 xxx.qq.com
c:AUTH LOGIN     //登入認證
s:334 VXNbWU6 //輸入賬號
c:MTA3MxcS5jb20=
s:334 UGFc3d6 //輸入授權碼
c:dWdwaXF5Y3ZzraWhQ==
s:235 Authentication successful
c:mail from: <1073788244@qq.com> //來自
s:250 OK
c:rcpt to: <1073788244@qq.com> //發往
s:250 OK
c:data
s:354 End data with <CR><LF>.<CR><LF>.
c:here is what i want to send
c:.
s:250 OK: queued as.
c:quit
s:221 bye

MIME:多媒體郵件擴充套件，在頭部行增加擴充套件

4. 郵件訪問協議

用於從伺服器獲取郵件

POP: Post Office Protocol

較簡單，認證授權和下載

無狀態
IMAP: Internet Mail Access Protocol

更多功能，更復雜

有狀態
HTTP

2.5 DNS應用

1.DNS服務

Domain Name System

解決Internet上主機/路由器的識別問題

域名向IP地址的翻譯
主機別名
郵件伺服器別名
負載均衡：Web伺服器

多個IP地址對應一個名字

2.分散式層次式資料庫

解決的問題：
- 單點失敗問題
- 流量問題
- 距離問題
- 維護性問題
根域名伺服器
- 不知道對映訪問權威域名伺服器
- 全球13個
頂級域名伺服器(TLD, top-level domain)
- com, org,net, edu等
權威域名伺服器(Authoritative)
- 組織的域名解析伺服器
本地域名解析伺服器
- 不嚴格屬於層級體系發
- 每個ISP有一個
- 主機進行查詢傳送給本地進行代理
- 迭代查詢：代理進行多次詢問
- 遞迴查詢：代理詢問一次讓其他伺服器去找

4. DNS記錄和訊息格式

1.DNS記錄

資源記錄（RR，resource records）

format：(name, value, type, ttl)

2.DNS協議與訊息

查詢（query）和回覆（relpy）訊息

訊息格式相同

同時使用TCP（區域傳輸時）和UDP（域名解析時）

2.6 P2P應用

檔案分發比C/S架構快

1. BitTorrent

檔案分為chunk
- 獲取：稀缺優先、定期查詢鄰居持有的chunk列表
- 傳送：tit-for-tat
節點可自由加入和離開

Q：為什麼運營商會封BT？

A：很簡單，影響網路運營商超賣頻寬了。ISP尤其是國內ISP最大的問題是，給使用者提供網路接入服務，但從不保證服務質量。宣傳上的“100M頻寬光纖入戶”從來不意味著你真的能用上100M頻寬。甚至ISP從主觀上，會用各種手段限制你，不讓你用滿這100M頻寬。

拋開遠端伺服器和整體網路鏈路的因素以外，跑不滿100M最主要原因在於ISP超賣，他們手裡總共有1000M頻寬，就敢給20家住戶每家賣100M頻寬，然後祈禱這20家不要同時把100M頻寬跑滿。只要你用任何技術手段，不管是BT CT 還是ET，只要大部分使用者能這個技術穩定跑滿頻寬，ISP就會對這個技術恨得牙癢癢，恨不得封殺了之~除此以外的理由都是藉口。
連結：https://www.zhihu.com/question/310343843/answer/618352530

2. 索引設計

集中式索引：增設中央伺服器
- 單點失效問題
- 效能瓶頸
- 版權問題
洪泛式查詢：query flooding
- 覆蓋網路（overlay network）： Graph
- 有很大的網路負擔
- 查詢訊息通過已有TCP連線傳送
- 節點轉發查詢訊息
- 查詢命中反向路經返回
層次式覆蓋網路
- 介於集中與洪泛之間
- 節點和超級節點間維持TCP連線：集中
- 某些超級節點之間維持TCP連線：洪泛
- 如：skype

2.7 Socket程式設計

1. Socket API

標識通訊端點（對外）：IP地址+埠號
作業系統/程式管理（對內）：套接字描述符(socket descriptor)

型別：

SOCK_STREAM: TCP協議
SOCK_DGRAM: UDP協議
SOCK_RAW：面向網路層

函式：

WSAStartup() 使用之前呼叫，初始化socket動態連結庫
WSACleanup() 使用之後呼叫
socket() 建立套接字
closesocket() 關閉套接字，引用為0關閉
bind() 為套接字設定本地端點地址，
- 客戶程式一般不必呼叫
- 服務端使用地址萬用字元 INADDR_ANY
listen() 僅服務端，TCP連線，置伺服器端的流套接字處於監聽狀態，設定連線請求佇列大小
connect() 僅客戶端，客戶端呼叫使其與特定計算機的特定埠的套接字進行連線
accept() 伺服器端，用於TCP連線，建立一個新的套接字與客戶通訊，因為TCP連線是點對點的，實現併發的TCP伺服器
send() 有連線的方式TCP(客戶與伺服器)，或呼叫了connect函式的UDP(客戶)套接字
sendto() 無連線方式UDP(伺服器)，或未呼叫connect函式的UDP客戶端套接字
recv() 同上
recvfrom() 同上

2. API呼叫流程

網路位元組順序：實現本地位元組順序與網路位元組順序進行轉換

基本服務型別：

迴圈無連線
迴圈面向連線
併發無連線：建立子程式處理
併發面向連線

2.8 CDN

內容分發網路

DASH（Dynamic Adaptive Streaming over HTTP）經HTTP的動態適應流

可以壓縮生成相同視訊的多個版本，每個版本有不同的質量等級。

CDN管理分佈在多個地理位置上的伺服器，在它的伺服器中儲存視訊（或其他資源）的副本，並且所有試圖將每個使用者請求定向到一個將提供最好的使用者體驗的CDN位置

3. 傳輸層

傳輸層協議為執行在不同Host上的應用程式提供了一種邏輯通訊機制

位於網路層之上

依賴於網路層的服務

對網路層服務進行增強

3.1 傳輸層服務

1. 多路複用/分用

此處的複用和分用是邏輯上的概念

傳送端多路複用：處理來自多個套接字的資料，新增傳輸頭

Q: I/O多路複用技術（multiplexing）是什麼？

A：

常見的IO操作，如read和write，通常是阻塞IO，也就是說當你呼叫read時，如果沒有資料收到，那麼執行緒或者程式就會被掛起，直到收到資料。這樣在處理大量連線時可能需要很多執行緒，比如4個核要跑1000個執行緒，那麼每個執行緒的時間槽非常短，而執行緒切換非常頻繁，大量時間花費在上下文切換。

此時引入非阻塞IO的概念，通過fcntl（POSIX）或ioctl（Unix）設為非阻塞模式，這時，當你呼叫read時，如果有資料收到，就返回資料，如果沒有資料收到，就立刻返回一個錯誤，如EWOULDBLOCK。這樣是不會阻塞執行緒了，但是你還是要不斷的輪詢來讀取或寫入。

於是，我們需要引入IO多路複用的概念。多路複用是指使用一個執行緒來檢查多個檔案描述符（Socket）的就緒狀態，比如呼叫select和poll函式，傳入多個檔案描述符，如果有一個檔案描述符就緒，則返回，否則阻塞直到超時。得到就緒狀態後進行真正的操作可以在同一個執行緒裡執行，也可以啟動執行緒執行（比如使用執行緒池）。這樣在處理1000個連線時，只需要1個執行緒監控就緒狀態，對就緒的每個連線開一個執行緒處理就可以了，這樣需要的執行緒數大大減少，減少了記憶體開銷和上下文切換的CPU開銷。

接收端多路分解：使用傳輸頭資訊交付接收到的段到正確的套接字

注意：服務端一個程式有多個執行緒，一個執行緒有多個套接字

UDP的socket用二元組標識
TCP的socket用四元組標識

2.可靠資料傳輸機制

Q：什麼是可靠（reliable）？

A：不錯、不丟、不亂

通道的不可靠特性決定了可靠資料傳輸協議（RDT）的複雜性

介面的結構：

RDT版本

Reliable Data Transfer

Rdt 1.0：可靠通道

Rdt 2.0: 產生位錯誤的通道

利用校驗和檢測位錯誤
確認機制（Acknowledgments，ACK）：正確接收
NAK：告知分組有錯，重傳分組
基於這種重傳機制的rdt協議稱為ARQ（Automatic Repeat reQuest）協議
FSM(Finit State Machine)規約

Rdt 2.1: 應對ACK/NAK破壞

傳送方為每個分組增加序列號
兩個序列號（0，1）就夠用了，因為只用記住當前的序列號
接收方判斷分組是否重複
傳送方
接收方

Rdt 2.2：無NAK訊息協議

接收方通過ACK告知最後一個被正確接受的分組
傳送方接收到重複ACK之後，重傳當前分組
FSM（相比2.1有較大簡化）

Rdt 3.0: 通道既可能傳送錯誤，也可能丟失分組

傳送方等待“合理”時間，如果沒有收到ACK，重傳
新增定時器
時延有影響
效能很差
網路協議可能影響物理資源的利用

流水線協議

流水線機制提高資源利用率
需要更大的序列號範圍
需要更大的儲存空間以快取分組

滑動視窗協議

Sliding-window protocol

視窗
- 允許使用的序列號範圍
- 視窗尺寸為N: 最多有N個等待確認的訊息
滑動視窗
- 隨著協議的執行，視窗在序列號空間內向前滑動

Go-Back-N（GBN）協議

傳送方：
- 設定一個計時器
- ACK(n): 確認到序列號n(包含n)的分組均已被正確接收
- 超時Timeout(n)事件：重傳序列號大於等於n，還未收到ACK的所有分組
接收方：
- ACK機制：傳送擁有最高序列號的、已被正確接收的分組的ACK
  - 可能產生重複的ACK
  - 只需要記住唯一的expectedseqnum
- 亂序到達的分組
  - 直接丟棄-> 沒有快取
  - 重新確認序列號最大的、按序到達的分組
Selective Repeat（SR）協議

傳送方

只重傳沒有接收到ACK的分組
N個連續的序列號
用單個硬體定時器模擬多個邏輯定時器

接收方

對每個分組單獨進行確認
設定快取機制，快取亂序到達可以

序列號空間大小與視窗尺寸應滿足的關係：

$傳送方視窗尺寸+接收方視窗尺寸\le可用序列號個數(2^k, k為序列號使用位數)$

TCP可靠資料傳輸

累計確認，返回期望收到的
使用單一重傳定時器

定時器時間設定：
$TimeoutInterval=EstimatedRTT+4*DevRTT$

即EstimatedRTT+“安全邊界”

$EstimatedRTT=(1-\alpha)\cdot EstimatedRTT+\alpha \cdot SampleRTT (typically, \alpha=0.125)$

$DevRTT=(1-\beta)\cdot DevRTT+\beta \cdot |SampleRTT-EstimatedRTT| (typically, \beta =0.25)$
快速重傳機制

如果sender收到對同一資料的3個ACK，則假定該資料之後的段已經丟失，在定時器超時之前立即重傳。

Q:為什麼是三次冗餘ACK？

A: 假定通訊雙方A和B傳送4個TCP Segment

TCP segment 亂序有2/5 = 40%的概率會造成A收到三次 duplicated ACK(N);

而如果 N 丟了，則 A 有100%概率會收到三次duplicated ACK(N);

基於以上的統計，當 A 接收到三次 duplicated ACK(N)啟動 Fast Retransmit 演算法是合理的，即立馬 retransmit N，可以起到 Fast Recovery 的功效，快速修復一個丟包對 TCP 管道的惡劣影響

而如果 A 接收到二次 duplicated ACK(N)，則一定說明是亂序造成的，即然是亂序，說明資料都到達了 B，B 的 TCP 負責重新排序而已，沒有必要 A 再來啟動 Fast Retransmit 演算法

3. 流量控制機制

消除傳送發使接受方快取溢位的可能，是一種速度匹配服務，傳送發傳送速率與接收方的讀取速率匹配。

TCP流量控制：

Receiver通過在Segment的頭部欄位將RcvWindow告訴Sender

$rwnd = RcvBuffer - (LastByteRcvd - LastByteRead)$
Sender限制自己已經傳送的但還未收到ACK的資料不超過接收方的空閒RcvWindow大小

$LastByteSent - LastByteAcked \le rwnd$

4. 擁塞控制機制

傳送方維持一個叫做擁塞視窗cwnd（congestion window）的狀態變數。擁塞視窗的大小取決於網路的擁塞程度，並且動態地在變化。傳送方讓自己的傳送視窗等於擁塞視窗，另外考慮到接受方的接收能力，傳送視窗可能小於擁塞視窗。

MSS（maximun segment size）最大報文段大小，不包括TCP/IP首部的長度，典型值為1460位元組

代價：

當分組到達速率接近鏈路容量時，分組將經歷較長的排隊時延。
傳送方必須執行重傳以補償因為快取溢位而丟棄(丟失)的分組。
在多跳網路中，當分組被drop時，任何用於該分組的”上游“傳輸能力全都被浪費掉

控制方法：

端到端擁塞控制：在端到端擁塞控制方法中，網路層沒有為傳輸層擁塞控制提供顯式支援。即使在網路中存在擁塞，端系統也必須通過對網路行為的觀察(如分組丟失與時延) 來推斷擁塞的發生。

TCP 必須通過端到端的方法處理擁塞控制，因為 lP 層不會向端系統提供有關網路擁塞的反饋資訊。TCP報文段的丟失(通過超時或 3 次冗餘確認而得知)被認為是網路擁塞的一個跡象，TCP會相應地減小其傳送視窗長度。具有公平性。
- $LastByteSent-LastByteAcked\le CongWin$
- $rate\approx \frac {CongWin}{RTT} Bytes/sec$
- 加性增-乘性減（AIMD）
- Additive Increase：每個RTT將CongWin增大一個MSS--擁塞避免
  - Multiplicative Decrease：發生loss後將CongWin減半
  - 鋸齒狀

慢啟動

cwnd的值以一個MSS開始，並且每當收到一個傳輸報文段的確認時就增加1MSS（相當於變為2倍）

擁塞避免

也就是每個傳輸輪次，擁塞視窗cwnd只能線性加一，而不是像慢開始演算法時，每個傳輸輪次，擁塞視窗cwnd按指數增長。

發生超時重傳，判斷網路可能出現擁塞：

將ssthresh的值更新為發生擁塞時的cwnd的一半
將cwnd的值減小為1，並重新開始執行慢啟動演算法

快速恢復

傳送方一旦收到3個重複確認，就知道現在只是丟失了個別的報文段。於是不啟動慢開始演算法，而執行快恢復演算法

傳送方將慢開始ssthresh的值和擁塞視窗cwnd值調整為當前視窗的一半，開始執行擁塞避免演算法
也有的快恢復實現是把快恢復開始時的擁塞視窗cwnd值再增大一些，即等於新的ssthresh+3
- 既然傳送方收到3個重複的確認，就表明有3個資料包文段已經離開了網路;
- 這3個報文段不再消耗網路資源而是停留在接收方的接收快取中;
- 可見現在網路中不是堆積了報文段而是減少了3個報文段。因此可以適當把擁塞視窗擴大些。

在這裡插入圖片描述

Q: 何時將指數增長切換為線性增長：

A：當CongWin達到Loss事件前值的1/2時,即到達Threshold

新增變數Threshold，發生loss時將其設定為CongWin達到Loss事件前值的1/2

發生Timeout時，Threshold設定為1/2CongWin，直接將CongWin設為1MSS，

網路輔助的擁塞控制：在網路輔助的擁塞控制中，網路層裝置件(即路由器)向傳送方提供關於網路中擁塞狀態的顯式反饋資訊。這種反饋可以通過資料包中的某個欄位來指示鏈路中的擁塞情況。這種方法在早期的 IBM SNA 和 ATM 等體系結構中採用。

對於網路輔助的擁塞控制，擁塞資訊從網路反饋到傳送方通常有兩種方式，直接反饋資訊可以由網路路由器發給傳送方。另一種形式是，路由器標記或更新從傳送方流向接收方的分組中的某個欄位來指示擁塞的產生(可以理解為對經過一個擁塞路由器的資料包做記號)。一旦接收方收到這個有擁塞標記的分組，就會通知傳送方網路發生了擁塞。

3.2 Internet傳輸層協議

1. UDP

User Datagram Protocol

為什麼存在？

無需建立連線

實現簡單：無需維護連線狀態

頭部開銷少

沒有擁塞控制：應用可更好的控制傳送時間和速率

特點：

基於Internet IP協議
- 複用/分用
- 簡單的錯誤校驗
“Best effort”服務
- 可能丟失
- 可能非按序到達
- 在應用層增加可靠性機制
無連線
- 傳送方和接受方不需要握手
- 每個UDP段的處理獨立於其他段

應用：

流媒體（容許錯誤、速率敏感）
DNS
SNMP

可靠性保證

在應用層新增可靠性保證
與具體應用相關的錯誤恢復
在http 3.0中使用
http3.0 with google quick

報文格式：

分解示意圖：

UDP長度欄位包含首部長度

單位：位元組

校驗和（checksum）：檢測UDP段在傳輸中是否發生錯誤（如位翻轉）

2. TCP

Transmission Control Protocol

特點：

點對點
可靠的、按序的位元組流
流水線機制
傳送方/接收方快取
全雙工
面向連線
流量控制機制

報文格式：

連線管理

三次握手

三次握手（Three-way Handshake）其實就是指建立一個TCP連線時，需要客戶端和伺服器總共傳送3個包。進行三次握手的主要作用就是為了確認雙方的接收能力和傳送能力是否正常、指定自己的初始化序列號為後面的可靠性傳送做準備。實質上其實就是連線伺服器指定埠，建立TCP連線，並同步連線雙方的序列號和確認號，交換TCP視窗大小資訊。

握手過程：

剛開始客戶端處於 Closed 的狀態，服務端處於 Listen 狀態。

第一次握手：客戶端給服務端發一個 SYN (同步)報文，並指明客戶端的初始化序列號 ISN(Initial sequence number)。此時客戶端處於 SYN_SEND 狀態。

首部的同步位SYN=1，初始序號seq=x，SYN=1的報文段不能攜帶資料，但要消耗掉一個序號。
服務端得出結論：客戶端的傳送能力、服務端的接收能力是正常的。

第二次握手：伺服器收到客戶端的 SYN 報文之後，進行資源分配（可能受到SYN Flood攻擊，可以使用SYN cookie進行防禦），以自己的 SYN 報文作為應答，並且也是指定了自己的初始化序列號 ISN。同時會把客戶端的 ISN + 1 作為ack（確認號）的值，表示自己已經收到了客戶端的 SYN，此時伺服器處於 SYN_REVD 的狀態。
- 在確認報文段中SYN=1，ACK=1，確認號ack=x+1，初始序號seq=y。
- 客戶端得出結論：服務端的接收、傳送能力，客戶端的接收、傳送能力是正常的。不過此時伺服器並不能確認客戶端的接收能力是否正常。
第三次握手：客戶端收到 SYN 報文之後，會傳送一個 ACK 報文，當然，也是一樣把伺服器的 ISN + 1 作為 ack 的值，表示已經收到了服務端的 SYN 報文，此時客戶端處於 ESTABLISHED 狀態。伺服器收到 ACK 報文之後，也處於 ESTABLISHED 狀態，此時，雙方已建立起了連線。

確認報文段SYN=0，ACK=1，確認號ack=y+1，序號seq=x+1（初始為seq=x，第二個報文段所以要+1），ACK報文段可以攜帶資料，不攜帶資料則不消耗序號。
服務端得出結論：客戶端的接收、傳送能力正常，伺服器自己的傳送、接收能力也正常。

傳送第一個SYN的一端將執行主動開啟（active open），接收這個SYN併發回下一個SYN的另一端執行被動開啟（passive open）。

在socket程式設計中，客戶端執行connect()時，將觸發三次握手。

Q：為什麼要進行3次握手，不是2次或更多？

A：假設採用2次握手。如客戶端發出連線請求，但因連線請求報文丟失而未收到確認，於是客戶端再重傳一次連線請求。後來收到了確認，建立了連線。資料傳輸完畢後，就釋放了連線，客戶端共發出了兩個連線請求報文段，其中第一個丟失，第二個到達了服務端，但是第一個丟失的報文段只是在某些網路結點長時間滯留了，延誤到連線釋放以後的某個時間才到達服務端，此時服務端誤認為客戶端又發出一次新的連線請求，於是就向客戶端發出確認報文段，同意建立連線，不採用三次握手，只要服務端發出確認，就建立新的連線了，此時客戶端忽略服務端發來的確認，也不傳送資料，則服務端一致等待客戶端傳送資料，浪費資源。

四次揮手

TCP 的連線的拆除需要傳送四個包，因此稱為四次揮手(Four-way handshake)，客戶端或伺服器均可主動發起揮手動作。

剛開始雙方都處於 ESTABLISHED 狀態，假如是客戶端先發起關閉請求。四次揮手的過程如下：

第一次揮手：客戶端傳送一個 FIN 報文，報文中會指定一個序列號。此時客戶端處於 FIN_WAIT1 狀態。
- 即發出連線釋放報文段（FIN=1，序號seq=u），並停止再傳送資料，主動關閉TCP連線，進入FIN_WAIT1（終止等待1）狀態，等待服務端的確認。
第二次揮手：服務端收到 FIN 之後，會傳送 ACK 報文，且把客戶端的序列號值 +1 作為 ACK 報文的序列號值，表明已經收到客戶端的報文了，此時服務端處於 CLOSE_WAIT 狀態。
- 即服務端收到連線釋放報文段後即發出確認報文段（ACK=1，確認號ack=u+1，序號seq=v），服務端進入CLOSE_WAIT（關閉等待）狀態，此時的TCP處於半關閉狀態，客戶端到服務端的連線釋放。客戶端收到服務端的確認後，進入FIN_WAIT2（終止等待2）狀態，等待服務端發出的連線釋放報文段。
第三次揮手：如果服務端也想斷開連線了，和客戶端的第一次揮手一樣，發給 FIN 報文，且指定一個序列號。此時服務端處於 LAST_ACK 的狀態。
- 即服務端沒有要向客戶端發出的資料，服務端發出連線釋放報文段（FIN=1，ACK=1，序號seq=w，確認號ack=u+1），服務端進入LAST_ACK（最後確認）狀態，等待客戶端的確認。
第四次揮手：客戶端收到 FIN 之後，一樣傳送一個 ACK 報文作為應答，且把服務端的序列號值 +1 作為自己 ACK 報文的序列號值，此時客戶端處於 TIME_WAIT 狀態。需要過一陣子以確保服務端收到自己的 ACK 報文之後才會進入 CLOSED 狀態，服務端收到 ACK 報文之後，就處於關閉連線了，處於 CLOSED 狀態。
- 即客戶端收到服務端的連線釋放報文段後，對此發出確認報文段（ACK=1，seq=u+1，ack=w+1），客戶端進入TIME_WAIT（時間等待）狀態。此時TCP未釋放掉，需要經過時間等待計時器設定的時間2MSL後，客戶端才進入CLOSED狀態。

收到一個FIN只意味著在這一方向上沒有資料流動。客戶端執行主動關閉並進入TIME_WAIT是正常的，服務端通常執行被動關閉，不會進入TIME_WAIT狀態。

在socket程式設計中，任何一方執行close()操作即可產生揮手操作。

Q: 揮手為什麼需要四次？

A：因為當服務端收到客戶端的SYN連線請求報文後，可以直接傳送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。但是關閉連線時，當服務端收到FIN報文時，很可能並不會立即關閉SOCKET，所以只能先回復一個ACK報文，告訴客戶端，“你發的FIN報文我收到了”。只有等到我服務端所有的報文都傳送完了，我才能傳送FIN報文，因此不能一起傳送（伺服器的兩次傳送不能合併）。故需要四次揮手。

Q：釋放連線時，等待2MSL的意義?

A：MSL是Maximum Segment Lifetime的英文縮寫，可譯為“最長報文段壽命”，它是任何報文在網路上存在的最長時間，超過這個時間報文將被丟棄。

保證客戶端傳送的最後一個ACK報文段能夠到達服務端。

因為這個ACK有可能丟失，從而導致處在LAST-ACK狀態的伺服器收不到對FIN-ACK的確認報文。伺服器會超時重傳這個FIN-ACK，接著客戶端再重傳一次確認，重新啟動時間等待計時器。最後客戶端和伺服器都能正常的關閉。假設客戶端不等待2MSL，而是在傳送完ACK之後直接釋放關閉，一但這個ACK丟失的話，伺服器就無法正常的進入關閉連線狀態。

防止“已失效的連線請求報文段”出現在本連線中。

客戶端在傳送完最後一個ACK報文段後，再經過2MSL，就可以使本連線持續的時間內所產生的所有報文段都從網路中消失，使下一個新的連線中不會出現這種舊的連線請求報文段。

進一步解釋：

主動斷開的一側為A，被動斷開的一側為B。

第一個訊息：A發FIN

第二個訊息：B回覆ACK

第三個訊息：B發出FIN

此時此刻：B單方面認為自己與A達成了共識，即雙方都同意關閉連線。

此時，B能釋放這個TCP連線佔用的記憶體資源嗎？不能，B一定要確保A收到自己的ACK、FIN。

所以B需要靜靜地等待A的第四個訊息的到來：

第四個訊息：A發出ACK，用於確認收到B的FIN

當B接收到此訊息，即認為雙方達成了同步：雙方都知道連線可以釋放了，此時B可以安全地釋放此TCP連線所佔用的記憶體資源、埠號。

所以被動關閉的B無需任何wait time，直接釋放資源。

但，A並不知道B是否接到自己的ACK，A是這麼想的：

1）如果B沒有收到自己的ACK，會超時重傳FIN

那麼A再次接到重傳的FIN，會再次傳送ACK，重新計時

2）如果B收到自己的ACK，也不會再發任何訊息，包括ACK

無論是1還是2，A都需要等待，要取這兩種情況等待時間的最大值，以應對最壞的情況發生，這個最壞情況是：

ACK從A到B最多經過1MSL，超過這個時間B會重發FIN
B重發的FIN最多經過1MSL到達A

去向ACK訊息最大存活時間（MSL) + 來向FIN訊息的最大存活時間(MSL)。

這恰恰就是2MSL( Maximum Segment Life)。

等待2MSL時間，A就可以放心地釋放TCP佔用的資源、埠號，此時可以使用該埠號連線任何伺服器。

TCP的四種計時器

重傳計時器(Retransmission Timer)

目的：為了控制丟失的報文段或者丟棄的報文段。這段時間為對報文段的等待確認時間。
建立時間：在TCP傳送報文段時，會建立對次特定報文段的重傳計時器。
可能發生的兩種情況：在截止時間（通常為60秒）到之前，已經收到了對此特定報文段的確認，則撤銷計時器；在截止時間到了，但為收到對此特定報文段的確認，則重傳報文段，並且將計時器復位。
重傳時間：2*RTT（Round Trip Time，為往返時間）

堅持計時器(Persistent Timer)

目的：主要解決零視窗大小通知可能導致的死鎖問題
死鎖問題的產生：當接收端的視窗大小為0時，接收端向傳送端傳送一個零視窗報文段，傳送端即停止向對端傳送資料。此後，如果接收端快取區有空間則會重新給傳送端傳送一個視窗大小，即視窗更新。但接收端傳送的這個確認報文段有可能會丟失，而此時接收端不知道已經丟失並認為自己已經傳送成功，則一直處於等待資料的狀態；而傳送端由於沒有收到該確認報文段，就會一直等待對方發來新的視窗大小，這樣一來，雙方都處在等待對方的狀態，這樣就形成了一種死鎖問題。如果沒有應對措施，這種局面是不會被打破的。為了解決這種問題，TCP為每一個連線設定了堅持計時器。
工作原理：當傳送端TCP收到接收端發來的零視窗通知時，就會啟動堅持計時器。當計時器的期限到達時，傳送端就會主動傳送一個特殊的報文段告訴對方確認已經丟失，必須重新傳送。【這個特殊的報文段就稱為探測報文段，探測報文段只有1個位元組的大小，裡邊只有一個序號，該序號不需要被確認，甚至在計算其他部分資料的確認時該序號會被忽略。】
截止期的設定：設定為重傳時間的值。但如果沒有收到接收端的響應，則會傳送另一個探測報文段，並將計時器的值加倍並復位，直到大於門限值（一般為60秒）。在此之後，傳送端會每隔60秒傳送一個探測報文段，直到視窗重新開啟。

保活計時器(Keeplive Timer)

目的：主要是為了防止兩個TCP連線出現長時間的空閒。當客戶端與伺服器端建立TCP連線後，很長時間內客戶端都沒有向伺服器端傳送資料，此時很有可能是客戶端出現故障，而伺服器端會一直處於等待狀態。保活計時器就是解決這種問題而生的。
工作原理：每當伺服器端收到客戶端的資料時，都將保活計時器重新設定（通常設定為2小時）。過了2小時後，伺服器端如果沒有收到客戶端的資料，會傳送探測報文段給客戶端，並且每隔75秒傳送一個，當連續傳送10次以後，仍沒有收到對端的來信，則伺服器端認為客戶端出現故障，並會終止連線。

時間等待計時器(Time_Wait Timer)

時間等待計時器是在連線終止期間使用的。
當TCP關閉連線時並不是立即關閉的，在等待期間，連線還處於過渡狀態。這樣就可以使重複的FIN報文段在到達終點之後被丟棄。
時間設定：一般為報文段壽命期望值的2倍。
原文連結：https://blog.csdn.net/qq_33951180/java/article/details/60468267

遊戲伺服器協議選擇

那麼到底是用UDP還是TCP呢？

如果是由客戶端間歇性的發起無狀態的查詢，並且偶爾發生延遲是可以容忍，那麼使用HTTP/HTTPS吧。
如果客戶端和伺服器都可以獨立發包，但是偶爾發生延遲可以容忍（比如：線上的紙牌遊戲，許多MMO類的遊戲），那麼使用TCP長連線吧。
如果客戶端和伺服器都可以獨立發包，而且無法忍受延遲（比如：大多數的多人動作類遊戲，一些MMO類遊戲），那麼使用UDP吧。

這些也應該考慮在內：你的MMO客戶端也許首先使用HTTP去獲取上一次的更新內容，然後使用UDP跟遊戲伺服器進行連線。

永遠不要害怕去使用最佳的工具來解決問題。
連結：https://www.jianshu.com/p/08af0f7d335b

王者榮耀

4. 網路層

4.1 網路層服務

1. 轉發

forwarding：將分組從路由器的輸入埠轉移到合適的輸出埠

轉發表確定在本路由器如何轉發分組

2. 路由

routing：確定分組從源到目的經過的路徑

路由演算法（協議）確定通過網路的端到端路徑

路由器結構

輸入輸出埠

交換機構內，基於目的的轉發，使用最長字首匹配原則

輸出埠側，當資料包從交換機構中以高於傳輸速率的速度到達時需要緩衝，可按照一定的排程策略進行分發

分組排程策略

先來先服務
優先權排隊
迴圈和加權公平排隊

3. 連線建立

某些網路的功能

注意：網路層連線是兩個主機之間（路徑上的路由器等網路裝置參與其中）

傳輸層連線：兩個應用程式之間（對中間網路裝置透明）

4. 網路層服務模型

無連線服務（connection-less service）：資料包網路
連線服務（connection service）：虛電路網路

4.2 虛電路網路

ATM網路

虛電路（VIrtual circuits）：一條從源主機到目的主機，類似於電路的路徑

每個分組的傳輸利用鏈路的全部頻寬
每個分組攜帶虛電路標識（VCID），沿路每段鏈路一個編號
虛電路經過的每個網路裝置維護每條經過它的虛電路的連線狀態
簡化邊緣、複雜網路

虛電路信令協議（signaling protocols）

建立和拆除電路

4.3 資料包網路

Internet網路

網路層不連線
每個分組攜帶目的地址
資料包轉發表（按地址範圍劃分）
- 最長字首匹配優先
簡化網路、複雜邊緣

4.4 IPv4協議

1. IP資料包格式

首部長度以4位元組為單位，即一位代表一行
首部校驗和：只對IP首部進行校驗
總長度欄位（首部+資料），資料最大長度$2^{16} -20=65515B$
TTL(Time To Live):IP分組在網路中可以通過的路由器數（跳數），每轉發一次減一，為零丟棄分組
協議：指示IP分組封裝的是哪個協議的資料包，實現複用/分用

2. IP分片

最大傳輸單元（MTU）

不同鏈路的MTU不同

分片（fregmented）

重組（reassembled）

標識欄位：IP協議利用一個計數器，每產生一個IP分組計數器加1，作為IP分組的標識（結合源目的地址唯一標識）
標誌位：3位： | 保留 | DF（Dont Fragment）| MF（More Fragment）|
- DF=1：禁止分片
- DF=0：允許分片
- MF=1：非最後一片，有更多分片
- MF=0：最後一片（或未分片）
片偏移：13位，以8位元組為單位：一個IP分組分片封裝原IP分組資料的相對偏移量
- 區分最後一片還是未分片

分片過程：

3. IP編址(addressing)

點分十進位制IP地址

網路號（NetID）- 高位位元
主機號（HostID）- 低位位元

相同網路號構成IP子網（Subnets）

不跨越路由器

有類劃分

IP地址根據網路號和主機號來分，分為A、B、C三類及特殊地址D、E。全0和全1的都保留不用。

A類：(1.0.0.0-126.0.0.0)（預設子網掩碼：255.0.0.0或 0xFF000000）第一個位元組為網路號，後三個位元組為主機號。該類IP地址的最前面為“0”，所以地址的網路號取值於1~126之間。一般用於大型網路。

B類：(128.0.0.0-191.255.0.0)（預設子網掩碼：255.255.0.0或0xFFFF0000）前兩個位元組為網路號，後兩個位元組為主機號。該類IP地址的最前面為“10”，所以地址的網路號取值於128~191之間。一般用於中等規模網路。

C類：(192.0.0.0-223.255.255.0)（子網掩碼：255.255.255.0或 0xFFFFFF00）前三個位元組為網路號，最後一個位元組為主機號。該類IP地址的最前面為“110”，所以地址的網路號取值於192~223之間。一般用於小型網路。

D類：是多播地址。該類IP地址的最前面為“1110”，所以地址的網路號取值於224~239之間。一般用於多路廣播使用者。

E類：是保留地址。該類IP地址的最前面為“1111”，所以地址的網路號取值於240~255之間。

在IP地址3種主要型別裡，各保留了3個區域作為私有地址，其地址範圍如下：
A類地址：10.0.0.0～10.255.255.255
B類地址：172.16.0.0～172.31.255.255
C類地址：192.168.0.0～192.168.255.255

私有地址：不向特定的使用者分配，被IANA（The Internet Assigned Numbers Authority，網際網路數字分配機構）作為私有地址保留。這些地址可以在任何組織或企業內部使用，和其他Internet地址的區別就是，僅能在內部使用，不能作為全球路由地址。這就是說，出了組織的管理範圍這些地址就不再有意義，無論是作為源地址，還是目的地址。對於一個封閉的組織，如果其網路不連線到Internet，就可以使用這些地址而不用向IANA提出申請，而在內部的路由管理和報文傳遞方式與其他網路沒有差異。

回送地址：127.0.0.1。也是本機地址，等效於localhost或本機IP。一般用於測試使用。例如：ping 127.0.0.1來測試本機TCP/IP是否正常。

子網劃分：

網路號（NetID）- 高位位元
子網號（SubID）- 原網路主機號部分位元
主機號（HostID）- 低位位元

子網掩碼

形如IP地址
NetID、SubID位全取1
HostID位全取0
A類網路預設子網掩碼：255.0.0.0
B類網路預設子網掩碼：255.255.0.0
C類網路預設子網掩碼：255.255.255.0 僅能容納254個主機
將IP分組的目的IP地址與子網掩碼按位與運算，提取子網地址

4. CIDR

無類別域間路由（Classless InterDomain Routing）

消除傳統的A、B、C類地址界限
無類地址格式：a.b.c.d/x, 其中x為字首長度
提升IPv4地址空間分配效率

5. 路由聚合

route aggregation

路由聚集的目的

簡化路由轉發表的規則，提升路由定址效率

如何進行路由聚集

取消有類地址劃分，NetID+SubID不定長度
需要聚合的子網地址按位取相同的字首作為新的子網地址（超網）
轉發表合併這些子網的轉發規則為新的子網規則，同時保證為非合併前子網地址但滿足條件的地址增加更長的字首匹配規則

什麼情況下可以路由聚集

當多個子網均通過其中某個子網地址來轉發時

總結：

劃分子網的意義

提升IP地址的利用效率

按規則分配IP地址，提升IP地址的辨識度，便於定址，IP地址形成自上而下層次鮮明的結構

對不同地區不同型別的網路裝置加以區分

如何劃分子網

IP地址邏輯上分為NetID+SubID+HostID，NetID+SubID作為網路地址，HostID作為主機號

按有類地址的NetID，SubID從HostID的高bit進行借位(借n位可劃分2^n個等長的子網)，組合成網路地址

通過子網掩碼宣告網路地址的bit寬度

定長子網劃分

劃分後的幾個子網，子網掩碼相同

變長子網劃分

根據實際情況，選擇不同長度的網路地址，子網掩碼不一定相同

如何描述子網

子網閘道器描述子網的首地址

子網掩碼描述子網的大小

4.5 DHCP協議

動態主機配置協議-DHCP：Dynamic Host Configuration Protocol

特點：

從伺服器動態獲取：
- IP地址
- 子網掩碼
- 預設閘道器
- DNS伺服器名稱與IP地址
即插即用
允許地址重用
支援在用地址續租
支援移動使用者加入網路

工作過程

DHCP協議在應用層實現
- 請求報文封裝到UDP資料包中
- IP廣播
- 鏈路層廣播
DHCP伺服器內建於路由器中

4.6 NAT

Network Address Translation 網路地址轉換
我們利用埠號的唯一性實現了公網ip轉換為私網ip的這一步。PAT（NAT過載）能夠使用傳輸層埠號來標識主機，因此，從理論上說，最多可讓大約65000臺主機共用一個公有IP地址
NAT 路由器必須:

輸出資料包: 將每個輸出資料包的 (源 IP 地址, 埠號) 替換為 (NAT IP 地址, 新埠號)

遠端客戶端/伺服器使用(NAT IP地址, 新埠號)作為目標地址進行響應
記錄 (在 NAT 轉換表中) 每一 (源 IP 地址, 埠號) 到 (NAT IP 地址, 新埠號) 轉換配對
輸入資料包: 將每個輸入資料包目標欄位中的(NAT IP 地址, 新埠號) 替換為儲存在NAT 轉換表中相應的 (源 IP 地址, 埠號)

Q: 為什麼需要？

A:

只需從ISP申請一個IP地址，有地址耗盡問題

本地網路裝置IP地址的變更，無需通告外界網路

變更ISP時，無需修改內部網路裝置IP地址

內部網路裝置對外界網路不可見，即不可直接定址

引發爭議：

路由器應該只處理第3層功能

違背端到端通訊原則，應用開發人眼要考慮到NAT的存在，例如p2p應用

地址短缺問題應該由IPv6來解決

NAT在實現上將多個內部主機發出的連線複用到一個IP上，這就使依賴IP進行主機跟蹤的機制都失效了。

NAT穿透：如果客戶端想要連線到NAT後的伺服器？

靜態配置NAT（IP地址是一對一的，是一直不變的）
使用UPnP（Universal Plug and Play）網際網路閘道器協議（IGD-Internet Gateway Device）自動配置
中繼

4.7 ICMP協議

網際網路控制報文協議-ICMP（Internet Control Message Protocol）

兩類ICMP報文：

差錯報告報文
- 目的不可達
- 源抑制（Source Quench）
- 超時/超期，TTL=0
- 引數問題
- 重定向（Redirect）
網路探詢報文
- 回聲Echo請求/應答報文Reply
- 時間戳請求與應答報文

報文格式

差錯報告報文資料封裝

4.8 IPv6協議

動機：

32位地址空間很快將被分配完

資料包格式：

定長40位元組首部
不允許資料包分片
無校驗和（加快路由器的處理，因為TTL的改變而每跳需重新計算）

4.9 路由演算法

典型的路由選擇方式有兩種:靜態路由和動態路由。

靜態路由是在路由器中設定的固定的路由表。除非網路管理員干預，否則靜態路由不會發生變化。靜態路由不能對網路的改變作出反映.

動態路由是網路中的路由器之間相互通訊，傳遞路由資訊，利用收到的路由資訊更新路由器表的過程。它能實時地適應網路結構的變化。如果路由更新資訊表明發生了網路變化，路由選擇軟體就會重新計算路由，併發出新的路由更新資訊。這些資訊通過各個網路，引起各路由器重新啟動其路由演算法，並更新各自的路由表以動態地反映網路拓撲變化。動態路由適用於網路規模大、網路拓撲復雜的網路。當然，各種動態路由協議會不同程度地佔用網路頻寬和CPU資源。

靜態路由和動態路由有各自的特點和適用範圍，因此在網路中動態路由通常作為靜態路由的補充。當一個分組在路由器中進行尋徑時，路由器首先查詢靜態路由，如果查到則根據相應的靜態路由轉發分組;否則再查詢動態路由。

根據是否在一個自治域內部使用，動態路由協議分為內部閘道器協議(IGP)和外部閘道器協議(EGP)。這裡的自治域指一個具有統一管理機構、統一路由策略的網路。自治域內部採用的路由選擇協議稱為內部閘道器協議，常用的有RIP、OSPF;外部閘道器協議主要用於多個自治域之間的路由選擇，常用的是BGP和BGP-

鏈路狀態(Link State)演算法：

Dijkstra演算法

可能有震盪（oscillations）

Initailization:
N' = {u}
for all nodes v:
	if v adjacent to u
		then D(v)=c(u,v)
	else D(v)=INF

Loop:
//可以使用堆來進行加速，在對數時間中找到最小值
find w not in N' such that D(w) is a minimum 
add w to N'
update D(v) for all v adjacent to w and not in N':
	//此時更新父節點可以構建最短路徑樹
	D(v)=min(D(v),D(w)+c(w,v))
until all nodes in N'

距離向量（Distance Vector）演算法

Bellman-Ford方程動態規劃

當節點x發現他的直接相連的鏈路開銷變化或從某個鄰居收到一個距離向量的更新時，他就更新其距離向量估計值

結點獲得最短路徑的下一跳，該資訊用於轉發表中
好訊息傳播快
壞訊息傳播慢
- 可能出現無窮計數問題（count to infinity）：路由選擇環路（routing loop），y即為了到達x, 通過z路由，z又通過y路由到達x（因為此時距離最短）
- 使用毒性逆轉（poisoned reverse）/反向下毒：如果一個節點到達目的的最小費用路徑是通過某個鄰居，則通告給該鄰居到達該目的的距離為無窮大，直到路徑不通過該鄰居
  
  注意：涉及3個或更多節點，而不是兩個直接相連的鄰居節點的環路將無法用毒性逆轉技術檢測到
- 定義最大度量

4.10 Internet路由

AS（Autonomous system）：自治系統，指在一個（有時是多個）組織管轄下的所有IP網路和路由器的全體，它們對網際網路執行共同的路由策略。也就是說，對於網際網路來說，一個AS是一個獨立的整體網路。而BGP實現的網路自治也是指各個AS自治。每個AS有自己唯一的編號。

在相同AS中的路由器都執行相同的路由選擇演算法並且有彼此的資訊。在一個自治系統內執行的路由選擇演算法叫做自治系統內部路由選擇協議

IGP（Interior Gateway Protocol）：內部閘道器協議，在一個AS內部所使用的一種路由協議。一個AS內部也可以有多個路由器管理多個網路。各個路由器之間需要路由資訊以知道子網路的可達資訊。IGP就是用來管理這些路由。代表的實現有RIP（Routing Information Protocol）、OSPF（Open Shortest Path First）、IGRP(內部閘道器路由協議)。

EGP（Exterior Gateway Protocol）：外部閘道器協議，在多個AS之間使用的一種路由協議，現在已經淘汰，被BGP取而代之。

1. RIP協議

路由資訊協議（Routing Information Protocol）

2. OSPF

Open Shortest Path First

安全
採用鏈路狀態演算法-Dijkstra
允許使用多條相同費用的路徑（RIP只能選一條）
對於每條鏈路，可以針對不同的TOS（Terms of service）設定多個不同的費用度量
整合單播路由與多播路由

OSPF比RIP強大的地方是，OSPF對整網的拓撲結構瞭如指掌，一旦某一條路徑斷了，可以及時選擇備份鏈路，對通訊的影響小。

RIP是基於謠言，對整網的拓撲結構沒有概念，只知道有幾個鄰居，至於更遠的鄰居是什麼樣子，對不起，不知道！

IS-IS（intermediate system to intermediate system）與OSPF近乎相同 [IS-IS為第二層協議，OSPF為第三層協議]

3.BGP協議

Border Gateway Protocol：事實上的域間路由協議

在BGP中，分組並不是路由到一個特定的目的地址，相反是路由到CIDR化的字首，其中每一個字首表示一個子網或子網的集合，一臺路由器的轉發表將具有形式為（x, I）的表項，其中x是一個字首（例如138.16.68/22）， I是該路由器的介面之一的介面號

eBGP：從鄰居AS獲取子網可達性資訊
iBGP：將可達性資訊傳播給所有AS內部路由器

每條BGP路由包含3個元件：NEXT-HOP；ASPATH；目的字首

熱土豆演算法：對於路由器，儘可能快的將分組送出其AS（更明確地說，用可能的最低開銷），而不擔心其AS外部到目的地的餘下部分的開銷，是一種自私的演算法

路由選擇策略（由上至下執行）：

路由被指定一個本地偏好值作為其屬性之一
從餘下路由中選擇有最短AS-PATH的路由
從餘下路由中用熱土豆路由選擇
最後使用BGP識別符號選擇

ISP遵循的經驗法則：任何穿越某ISP主幹網的流量必須是其源或目的（或兩者）位於該ISP的某個客戶網路中

4.11 SDN控制平面

software define network

遠端控制器計算和分發轉發表以供每臺路由器使用，因為計算轉發表並與路由器互動的控制器是用軟體實現的，故網路是“軟體定義”的

強化控制平面：可靠、可信、效能可擴充套件、安全的分散式系統
- 故障魯棒性：控制平面的可靠分佈系統的強壯理論發揮的作用

4.12 網路管理與SNMP

SNMP（Simple Network Management Protocol）

PDU（Protocol Data Unit）

5. 資料鏈路層

鏈路層的豬蹄部分是在網路介面卡Network adapter中實現的，也被稱為網路介面卡（Network Interface Card，NIC）。位於網路介面卡核心的是鏈路層控制器，該控制器通常是一個實現了許多鏈路層服務（成幀、鏈路接入、差錯檢測等）

概述：

主機和路由器：結點（nodes）
連線相鄰結點的通訊通道：鏈路（links）
資料分組：幀（frame）

提供服務：

成幀
鏈路接入
可靠交付
差錯檢測和糾正

5.1 差錯檢測和糾正位元

Error-Detection and- Correction，EDC

漢明距離：兩個等長字串之間的漢明距離是兩個字串對應位置的不同字元的個數

檢錯碼與糾錯碼：

1. 奇偶校驗碼

parity check

採用何種校驗是事先規定好的。通常專門設定一個奇偶校驗位，用它使這組程式碼中“1”的個數為奇數或偶數。若用奇校驗，則當接收端收到這組程式碼時，校驗“1”的個數是否為奇數，從而確定傳輸程式碼的正確性；偶校驗則檢測是否為偶數。

1位元校驗位
- 檢測奇數位差錯
二維奇偶校驗
- 檢測奇數位差錯、部分偶數位差錯
- 糾正同一行/列的奇數位數

2. Internet校驗和

計算checksum

3. 迴圈冗餘校驗碼

Cyclic Redundancy Check ，CRC

有限代數理論（Galois域）

考慮d位元的資料D，傳送節點要將它傳送給接收節點。傳送方和接受方首先必須協商一個r+1位元模式，稱為生成多項式G，要求G的最高有效位的位元為1. 對於一個給定的資料段D，傳送發要選擇r個附加位元R，並將它們附加到D上，使得得到的d+r位元模式用模2算數恰好能被G整除。接受方用G去除收到的d+r位元。

【說明】“模2除法”與“算術除法”類似，但它既不向上位借位，也不比較除數和被除數的相同位數值的大小，只要以相同位數進行相除即可。模2加法運算為：1+1=0，0+1=1，0+0=0，無進位，也無借位；模2減法運算為：1-1=0，0-1=1，1-0=1，0-0=0，也無進位，無借位。相當於二進位制中的邏輯異或運算。也就是比較後，兩者對應位相同則結果為“0”，不同則結果為“1”。如100101除以1110，結果得到商為11，餘數為1，如11×11=101

編碼簡單、效能優良

5.2 多路訪問控制（MAC）協議

Multiple Access Control Protocol

採用分散式演算法決定結點如何共享通道，即決策結點何時可以傳輸資料

MAC協議分類：

通道劃分
- 將通道劃分為小的“片段”
- 將片段分配給節點獨佔使用
隨機接入
- 不分割通道，允許衝突/碰撞
- 衝突後恢復
輪流
- 節點輪流傳送，但傳送多的節點可以輪流傳送更長的時間

1. 通道劃分（channel partitioning）MAC協議

多路複用技術
TDMA：time division multiple access 分時多重進接
FDMA：frequency division multiple access 分頻多工
CDMA：code division multiple access 分碼多重進接
WDMA

2. 隨機訪問（random access）MAC協議

通道不劃分，允許衝突
採用衝突、恢復機制
- 有碰撞時，涉及碰撞的每個節點反覆地重發它的幀，直到該幀無障礙通過

時隙（sloted）ALOHA

時鐘同步
碰撞時以概率p選擇是否重傳
效率極限為37%

ALOHA協議

無時鐘同步，純分散協議
比時隙ALOHA協議更差（為其一半），更簡單

CSMA 載波監聽多路訪問協議（carrier sense multiple access）

傳送幀之前，監聽通道
由於訊號傳播延遲，可能仍有衝突
繼續傳送衝突幀，浪費通道資源

CSMA/CD（with Collision Detection）協議

短時間內可以檢測到衝突
衝突後傳輸中止，減少通道浪費
- 中止後進入二進（指數）退避
$L_{min}/R=2d_{max}/V $ 網路頻寬R 資料幀長度L 訊號傳播速度V 兩個站點之間的距離d
效能遠由於ALOHA協議
乙太網

3. 輪轉（taking turns）MAC協議

結點輪流使用通道
藍芽

輪詢（polling）

主結點輪流邀請從屬結點傳送資料

令牌傳遞（token passing）

控制令牌一次從一個結點傳遞到下一個結點
令牌-特殊幀

5.3 ARP協議

Address Resolution Protocol

1. MAC地址

或稱LAN地址，實體地址，乙太網地址

48位MAC地址，固化在網路卡的ROM中，有時也可以軟體設定
e.g:1A-2B-3C-34-AD-00
由IEEE統一管理與分配

2. 地址解析協議

ARP表：LAN中的每個IP結點（主機、路由器）維護一個表

一臺路由器對它的每個介面都有一個IP地址。對路由器的每個介面，也有一個ARP模組和一個介面卡。

查詢ARP報文是在廣播幀中傳送的，而響應ARP報文在一個標準幀中傳送

儲存某些LAN結點的IP/MAC地址對映關係：<IP地址；MAC地址；TTL>

5.4 乙太網

物理拓撲

匯流排（bus）
- 所有結點在同一衝突域（collision domain）
星形（star）

CSMA/CD演算法

檢測到衝突後進入二進位制指數退避

連續衝突次數越多，平均等待時間越長

乙太網幀結構

交換機

自學習、泛洪構建轉發表，依據MAC地址

過濾：決定轉發一個幀還是丟棄該幀

轉發：決定一個幀被導向哪個介面

特點：

消除碰撞
異質的鏈路，不同鏈路有不同速率且執行在不同媒體上
管理

交換機與路由器的區別：

交換機是二層的分組交換機，即插即用，有較高的分組過濾和轉發速率

路由器是三層的分組交換機，使用路由演算法和IP地址註冊轉發表

VLANs

virtual local area network

流量隔離（traffic isolation）
動態成員

在VLAN中轉發：通過路由（就像在獨立的交換機之間）

幹線埠- 擴充套件乙太網幀格式 802.1Q

多協議標籤交換

Multiprotocol Label Switching，MPLS

固定長度標籤

【計算機網路】資料鏈路層 | 複習筆記
2020-12-17
計算機網路筆記
網路傳輸的大小端-計算機網路複習筆記
2020-11-06
計算機網路筆記
計算機網路複習
2024-08-31
計算機網路
計算機網路複習筆記 - HTTP 1.0 / 1.1 / 2.0 的區別
2020-10-31
計算機網路筆記HTTP
計算機網路個人筆記
2024-06-09
計算機網路筆記
小白計算機網路學習筆記（更新中）
2021-02-22
計算機網路筆記
計算機網路 - 運輸層 - 學習筆記
2024-11-13
計算機網路筆記
計算機網路複習-01-概述
2018-09-15
計算機網路
計算機網路整理筆記01
2020-12-28
計算機網路筆記
計算機網路（王道考研筆記）
2020-10-30
計算機網路筆記
計算機網路 - 課程筆記
2024-09-12
計算機網路筆記
計算機網路學習筆記：第二章
2020-11-11
計算機網路筆記
計算機網路傳輸層學習筆記---（四）
2020-10-19
計算機網路筆記
計算機網路-應用層筆記
2021-01-02
計算機網路筆記
《計算機網路》讀書筆記（二）
2018-02-06
計算機網路筆記
計算機網路知識備筆記
2015-03-27
計算機網路筆記
王道計算機網路截圖筆記
2024-03-09
計算機網路筆記
計算機網路工程筆記（第十週）
2020-12-12
計算機網路筆記
計算機網路工程筆記（第五週）
2020-11-19
計算機網路筆記
菜鳥筆記之計算機網路（4）
2020-11-13
筆記計算機網路
計算機網路期末複習第四講網路應用工作原理
2020-11-27
計算機網路
計網複習筆記【附思維導圖】——【4】網路層
2020-11-27
筆記
校招面試知識點複習之計算機網路
2017-03-20
面試計算機網路
計算機四級網路工程師複習提綱
2016-03-23
計算機工程師
【計算機網路·第7版-學習筆記】第02章：物理層
2020-04-20
計算機網路筆記
【計算機網路】謝希仁筆記資料鏈路層
2021-09-09
計算機網路筆記
王道計算機網路複習（1）j第一章計算機網路的體系結構，計算機網路的概念，資源共享，計算機網路分類，計算機網路的標準化工作以及相關的組織
2020-10-01
計算機網路
校招面試知識點複習之計算機網路（更新）
2017-07-20
面試計算機網路
計算機網路自頂向下方法:第一章計算機網路和因特網課後複習題
2019-04-01
計算機網路
計算機網路——多路複用與多路分解
2020-12-06
計算機網路
計算機網路小白學習-2
2020-09-25
計算機網路
計算機知識學習路線及書籍筆記索引
2021-04-22
計算機筆記索引
計算機網路習題解答(教材計算機網路謝希仁編著)3
2008-05-26
計算機網路
【計算機網路】學習筆記，第三篇：資料鏈路層（謝希仁版）
2020-11-08
計算機網路筆記
計算機網路 -- 計算機網路的效能指標
2021-09-12
計算機網路指標
計算機網路考研複習筆記D2 分層協議與OSI參考模型
2020-11-19
計算機網路筆記協議模型
計算機網路學習筆記（10） TCP/IP協議棧之TELNET協議
2018-03-24
計算機網路筆記TCP協議
計算機網路
2024-09-10
計算機網路

計算機網路複習筆記

目錄

1 計算機網路概述

1.1 網路概念

1.2 資料交換方式

1.3 網路分類

1.4 網路的效能指標

1.5 網路體系結構

1. 概念

2. OSI參考模型

1 物理層

2 資料鏈路層

3 網路層

4 傳輸層

5 會話層

6 表示層

7 應用層

通訊過程

資料封裝

網路排錯

3. TCP/IP參考模型

4. 5層參考模型

5層結構

資料封裝

2. 應用層

2.1 體系結構

1. 客戶機/伺服器結構（Client/Server）

2. P2P結構（peer-to-peer）

3. 混合結構

2.2 程式間通訊

1. Socket

2. 定址

3. 應用層協議

2.3 Web應用

1. HTTP協議

2. Cookie

3. Web快取/代理伺服器技術

2.4 Email應用

1. 郵件客戶端 （user agent）

2. 郵件伺服器 （mail server）

3. SMTP協議（Simple Mail Transfer Protocol）

4. 郵件訪問協議

2.5 DNS應用

1.DNS服務

2.分散式層次式資料庫

4. DNS記錄和訊息格式

1.DNS記錄

2.DNS協議與訊息

2.6 P2P應用

1. BitTorrent

2. 索引設計

2.7 Socket程式設計

1. Socket API

2. API呼叫流程

2.8 CDN

3. 傳輸層

3.1 傳輸層服務

1. 多路複用/分用

2.可靠資料傳輸機制

RDT版本

流水線協議

滑動視窗協議

TCP可靠資料傳輸

3. 流量控制機制

4. 擁塞控制機制

3.2 Internet傳輸層協議

1. UDP

特點：

應用：

可靠性保證

報文格式：

2. TCP

特點：

報文格式：

連線管理

三次握手

四次揮手

4. 網路層

4.1 網路層服務

1. 轉發

1. 郵件客戶端（user agent）

2. 郵件伺服器（mail server）