計算機網絡復習筆記

本文轉載自查看原文 2021-03-02 19:53 871 課程筆記

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

固定長度標簽

免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。

猜您在找 計算機網絡復習筆記總結計算機網絡復習計算機網絡筆記計算機網絡知識點復習（一）計算機網絡知識點復習（三）計算機網絡期末復習資料計算機網絡安全復習【計算機網絡】期末復習計算機網絡知識框架總結（復習）計算機網絡_期末復習