計算機網絡--TCP/IP

總述

鏈路層

以太網 只是IntelCorp、Xerox、Digital Equipment Corp幾家公司聯合公佈的 一種 CSMA/CD 媒體接入方法(載波偵聽多路訪問，Carrier Sense Multiple Access with Collision Detection)

IEEE 802是另一種鏈路層協議，具有邏輯鏈路控制(LLC)
802.3是以太網，針對整個CSMA/CD網絡
802.4針對令牌總線網絡
802.5針對令牌環網絡

以太網

目的地址(6B)	源地址(6B)	類型(2B)	46B < 數據幀 < 1500B	CRC 4B
x	x	0800	IP數據包
x	x	0806	ARP 請求 28B + 16 PAD墊片
x	x	0835	RARP 請求 28B + 16 PAD墊片

MTU(Maximum Transmission Unit)=1500，經過不同MTU路由器的數據會被多次分片，因此分片發生在路由器出口方向，直到目的IP才進行組裝
校驗只計算首部

802.3

目的地址(6B)	源地址(6B)	長度(2B)	DSAP (1B)	SSAP (1B)	cntl (1B)	org code(3B)	類型(2B)	38 B < 數據幀 < 1492B	CRC 4B

ARP協議

ARP緩存表：將IP地址動態映射到MAC地址，解析出下一跳的MAC地址

目的地址(6B)	源地址(6B)	類型(2B)	硬件類型(2B)	協議類型(2B)	硬件地址長度(1B)	協議地址長度(1B)	操作OP(2B)	源MAC	源IP	目的MAC	目的IP
目的MAC	源MAC	0806	1=以太網	0800=IP	MAC=6	IP=4	1=ARP請求 2=ARP應答 3=RARP請求 4=RARP應答	源MAC	源IP	目的MAC	目的IP

原理見維基百科
老化機制：不用的IP-MAC映射就刪掉

ARP廣播

Gratuitous ARP

功能1：設備重啓後ARP廣播查詢自己的IP，若有迴應，IP已被佔用，和現有其他設備衝突
功能2：接收到ARP廣播的設備將根據 源MAC 和 源IP 更新自己的ARP映射表

因此攻擊者可以瘋狂用自己的MAC廣播受害IP，從而使得發往受害IP的報送給自己，從而“毒化”IP

Windows上抓Gratuitous ARP的方法！

代理ARP(aproxy ARP)

路由器(及網關)本身佔有一個IP地址
IP routing 的路由，解析IP地址，直連地址直髮，非直連送默認網關轉發
No IP routing 的路由
$\Downarrow$
沒有路由能力，每次IP訪問將對所有MAC地址發送ARP請求
$\Downarrow$
若路由器開啓了aproxy ARP，收到這個ARP請求且知道目的IP轉發方向時
$\Downarrow$
單播一個ARP應答（“目的IP在我這個MAC這!”）
$\Downarrow$
No IP Routing的設備便將 proxy ARP 路由的MAC地址裝入以太幀首部，共享一個(代理路由的)MAC地址

優點	使本身沒有IP或 IP Routing 的設備能夠工作
缺點	防火牆問題，迴環問題

防火牆問題

若防火牆未開啓代理ARP，外部對內部IP的訪問將全部失效，因爲防火牆路由不知道目的IP的MAC，丟棄這個幀

迴環問題

代理成環，ARP後來優先，所以目的IP的MAC在R4給出的真實值和R1代理給出的"僞"MAC之間徘徊

網絡層

不可靠(ureliable)—不保證數據包順序送達，發生錯誤丟棄數據包，向信源返回ICMP錯誤信息
無連接(connectionless)—完全獨立處理數據包(不維護數據報順序，但維護片順序)

ipconfig /all 或 netstat -an 查看當前鏈接狀態

首部

IP版本 = 4 or 6
IP首部總長 = $首部長度[4,15] \times 4Byte \leq \color{red}60Byte = 20 + 40(選項)$Byte
服務類型 = 3bit優先級 + 4bit TOS + 0

最小時延	最大吞吐量	最高可靠性	最小費用

總長度 = 首部 + 數據 = 60~65535 Byte

標識(identification)：要滿足片 < MUT ，因此數據段過長時被分片，分片後每個片的IP除標誌(flag)和片偏移不同外，其他完全複製(包括標識)，因此標識相同代表傳輸的是同一TCP數據報

標誌(flag)

未使用	分片 (Do not Fragment)	片未完 (More Fragment)
0	1=不分片,通過MTU較小的鏈路時路由直接丟包,返回不可達ICMP	0=數據報文的最後一個分片

片偏移 = $上一片的報文偏移(起始=0) + \frac{上一片的報文大小}{8 Byte}$保證重組裝順序
分片數據大小(Byte) = 除IP首部外的大小 = $max(8n)\leq MTU$，注意最後一個分片<46時墊片
生存時間(TTL,time to live)：設定可以經過的最大路由器數目，經過一個路由器自減1
協議：告知下一首部類別，TCP=6，UDP=17，ICMP=1
檢驗和只校驗首部，從格式可以看出一定有偶數個字節求$\sum\limits_{}^{n}16bit$

選項
防火牆阻止幾乎所有的TCP/IP選項設置報文通過！！
選項碼 = 複製位(1)+選項類(3)+選項號(5)
複製位 = 1(複製選項到所有分片) / 0(僅複製給第一個分片)

選項碼	長度	指針	IP地址隊列
0x89=嚴選	選項總長度		最多$\frac{60-20-3}{4 Byte/IP}=9$個IP地址
0x83=寬選	選項總長度		最多$\frac{60-20-3}{4 Byte/IP}=9$個IP地址
0x87=記錄IP	選項總長度	下次寫入IP位置	記錄區：$IP1,IP2...$

源路由選擇：按源給出的路由IP順序經過，測試路由連通性 或 吞吐量
實現方式：比如由路由器調整指針逐一取出下一站IP
嚴格源(站)路由選擇—指定路由間直連
寬鬆源(站)路由選擇—指定的路由順序之間可以插入其他未指定的路由(搭橋)
記錄路由：記錄從源開始的出口IP，一去一回路由器的進出口便都被記錄，選項總長度 $\color{red}\leq 39= 3+\frac{60-20-3}{4 Byte/IP}$，指針=40表示溢出
也不是所有的路由器都支持路徑記錄！！

選項碼	長度	指針	溢出個數	格式標誌	IP地址隊列
0x44=記錄時間	$\color{red}\leq 40$	寫入位置	4bit	4bit	36Byte

Ping IP -R

記錄時間戳：記下經過的時間(格林威治Universal Time，ms和IP地址)
溢出(OverFlow)未能記錄的數據個數
標誌(FlaG)控制時間戳選項格式
0=不記錄IP
1=4$\times$ (IP + 時間)
3=只記錄 到達源初始化給定IP 的時間
注意路由時間不一定同步！！

IPv4的兩種擴充方法：NAT和CIDR

ICMP

被認作IP的部分，傳遞差錯報文和信息，供TCP/UDP使用，從而給用戶進程反饋
舉例ICMP錯誤報文：

校驗和 會 校驗整個ICMP段
出錯的IP報首部提供錯誤信息
TCP/UDP的首部8個字節包含端口的信息，以反饋給源主機通知源進程
因此使用UDP不可靠傳輸，第一片數據包丟失就沒法返回ICMP(進程的端口號)

不再產生差錯報文的情況

擦錯報文

廣播地址IP(廣播風暴)

ARP廣播(廣播風暴)

除第一個外的其他IP分片(只有第一個分片纔有TCP/UDP頭部8字節的端口信息)

客戶端口號隨機(臨時端口號)，服務器端口號固定(知名端口號)

Ping 程序
集成在系統內核中
主機發送一份ICMP回顯請求報文給主機(服務器)，等待ICMP回顯應答
可測試IP可達性，獲得往返時間(如Linux $T_{往返}=T_{now}-T_{start}$)
對回顯報文的處理方式隨系統等不定，結果和協議、端口號均有關(如Ping不到卻可以訪問)
比如：Windows的標識符和進程無關

注意和IP首部中的選項段的差別

Traceroute 程序
原理1：TTL字段=0或1時，路由器不再轉發該報文，並向源發出ICMP超時“錯報”
原理2：僞造高端口號，必然長生ICMP端口不可達“錯報”
使用UDP協議，依次設置TTL=1，1，1，2，3…(第一個路由時間測三次)得到ICMP超時，根據記錄計算往返時間，收到端口不可達ICMP時表示已到達目的IP
防火牆TTL不執行-1，因此防火牆不可見


微軟自研的Tracer和Traceroute有不同但標準一致
使用ICMP request回顯請求，同時設置TTL=1，2，3…
到目的IP後回送的是 ICMP Reply

網絡地址轉換

NAT(Network Address Translation)
IP數據包再通過路由器或防火牆時，重寫源或目的IP地址的技術(又稱網絡掩蔽，IP掩蔽)
解決IPv4地址短缺，網絡地址也是資源(=成本)

思考，PC1 與 PC2 同時訪問一個IP，這個目的IP返回的包在“過關”時映射會有兩個子網IP，即PC1,PC2，那麼這個包傳給誰呢？
NAT拆解徹底一點，拆到並修改 TCP/UDP 的端口號，那麼返回的包本身也帶有端口號的話，就能按對應的端口號進行IP的選擇(如：NAPT)
注意：分片的IP報文，除頭部外分片沒有TCP/UDP頭部，沒有端口信息，也就無法實現地址映射

內網IP	外網IP
192.168.1.55：1	219.152.168.222：9200
192.168.1.56：2	219.152.168.222：9200

無類別域間路由

CIDR，Classless Inter-Domain Routing，基於可變長子網掩碼(VLSM)
VLSM前：最小子網容量2⁸=256，或2¹⁶=65535，分配給公司太大或者太小，個體用戶又很分散無法聚合，增加運營公司負擔
VLSM後：192.168.0.0/16，通過後綴指定主網位數，從而根據需求容量劃分子網
IPv4劃分爲

類別	DEC	高8位	私有段
A類	0.0.0.0 — 127.255.255.255	0000 0000 — 0111 1111	10.0.0.0 — 10.255.255.255
B類	128.0.0.0 — 191.255.255.225	1000 0000 — 1011 1111	172.16.0.0 — 172.31.255.255
C類	192.0.0.0 — 223.255.255.255	1100 0000 — 1101 1111	192.168.0.0 — 192.168.255.255
D類羣播	224.0.0.0 — 239.255.255.255	1110 0000 — 1110 1111
E類保留	240.0.0.0 — 255.255.255.255	1111 0000 ---- 1111 1111

首位和最後一位保留做廣播調試用，如192.168.0.0和192.168.255.255
部分網段做特殊或私有段
私有段是給組織機構建立內網而保留的段
0.0.0.0 DHCP動態獲取IP之前地址
ping的結果和操作系統有關！！

環回口 用例
作用：節省封裝過程(廣播對象包括自己)
ping 調用ICMP 經 環回口 回

環回口地址通常爲127.0.0.1

VPN局部代理路由策略：網關路由器 通過環回口實現內網通信
目的IP地址內網？ + 源IP地址內網？ ⇒ 送到網關環回口 ⇒ 返回了內網未能進入外網

路由交換

PC端除非開啓，否則不具備轉發功能

ICMP重定向
擁有IP Routing的設備(如路由器)能夠根據決策下一跳，不理睬ICMP重定向
但沒有的設備只能走默認網關R1，當R1轉發某報文時發現報文進端口=出端口，那麼R1就不必經過，直接給R2就好，於是在轉發第一個報文的同時，向源發送ICMP重定向報文，更新源的路由表

爲什麼有了MAC標識唯一的物理地址，還需要IP地址呢？
很簡單，全世界每天都在生產新的網卡(或具有mac地址的設備)，應該沒有設備能存儲的下所有點到點的MAC地址路徑，即便存下，每經過一箇中傳設備查找的效率也很低，因此用IP地址既能解決MAC不變但MAC接入網絡的空間會變(坐飛機)，也能提高路徑搜索的效率
爲什麼根據 IP 地址查詢物理所在地，而不是 mac 地址？

動態路由協議(DHCP)

路由表查詢順序：
主機地址? ⇒ 網絡地址？ ⇒ 默認表項

傳輸層

UDP(User Datagram Protocol)

不管應用層數據多大，添加一個UDP頭部，一個IP頭部，根據MTU(1500B)封裝分片發送，因此UDP纔是造成IP分片的原因，因此UDP是數據報協議(容易抓到完全一樣的包)

UDP實際最大長度$\leq$ 65535，和系統接口(API)，內核實現均有關
應用也不一定能一次性接收這麼多數據

僞首部是從IP首部中提取，並不真實存在，用於IP頭部校驗外，再次檢查目的地是否正確，避免IP欺騙攻擊(IP spoofing attack method)

校驗是可選的，由於$\sum\limits_{}^{n}{(16bit)}$存在奇數個字節的情況，因此奇數情況下在數據末尾補0實現16bit和校驗，且補的1字節不被髮送節省資源

//校驗過程
while (sum>>16){
sum = (sum & 0xffff) + (sum >> 16)
};
checksum = ~sum;

當UDP連接一個不存在的端口時，返回一個ICMP端口不可達差錯(不可靠傳輸，對比TCP)

使用場景	優點
DNS	不握手 ⇒ 快 多Sever同時發送查詢請求
TFTP Trivial File Transfer Protocol	程序簡單小，可以嵌入無盤工作站 可向多IP同時下載
語音視頻	支持組播域廣播 可以丟包

ICMP源站抑制差錯

UDP進程可能拒收ICMP源站抑制差錯，因爲UDP發完了事結束進程，返回源時可能進程已經不在
TCP進程一定會接收ICMP源站抑制差錯，因爲TCP可靠傳輸必重傳，收到ICMP調慢發送速率
如果是接收端緩存溢出，(IP,UDP)目的已達，應用層問題，不會有ICMP錯誤報文

單播，組播與廣播

是三種IP地址

網卡的兩種模式	普通模式	混合(雜合)模式
區別	只接收目的MAC是本地IP的包 廣播或組內組播的包	全都要！(eg:抓包程序)

使用廣播IP相對組播IP會消耗更多CPU資源，需要應用層判斷是否有進程監聽所需

TCP(Transmission Control Protocol)

特性	功能
面向連接	點對點(應用)三次握手四次揮手 只能單播！！！
可靠	$收包後延遲確認省資源\begin{cases}\color{red}客戶端延遲200ms或收到第二個數據報後捎帶ACK&\\應用程序取走數據後返回真實的緩衝區大小\end{cases}$ 未及時確認將重發 首身校驗和 IP失序，重發 ⇒ TCP排序，重複丟棄 流量(收發速率)控制
字節流 Byte Stream Service	根據MMS將應用層數據“分批OR拼接”成合適大小 不解釋內容 抓不到完全一樣的包

端口號    ：[SIP+DIP+Protocol(TCP/IP)+SPort+DPort] = 五元組 確定 一個 session
                  [IP+Port] = socket(socket pair)插口(插口對)，實時連接狀態監控防火牆“根基”
序號       ：數據第一個字節序號，[0~2³²-1]循環序號，SYN，FIN各用掉一個序號
                 全雙工=同時記錄進/出序號

初始化序列號ISN(Initial Sequence Number)
系統不停更新，使用時TCP截取ISN作爲第一次握手序列號
隨機初始化序列號ASA的預防作用

可能的攻擊	原因
滲透OS	倘若初始化序列號規律增長，黑客通過連續多次連接TCP 得到ISN增長規律，從而判斷出系統使用的OS
會話劫持	多次探測得到 ISN 規律，盲猜SN，進而模仿出[IP+Port+SN]

確認序號：期望下一個包的第一個字節的序號=已收到最後一個字節的序號 + 1，ACK=1時有效

不能選擇確認/否認：校驗和錯誤/丟包 ⇒ 不能跳過第一個錯誤/丟失的包的序號去確認後面正確的包，否認指不能告知發送方丟包原因 新標準可以(SACK標誌位)

首部長度：$[2^4-1] \times 4 = 60 Byte = 5 \times 4 Byte 首部 + 40 Byte選項$
無效6位：可被用來攻擊，反之也可能被防火牆視爲攻擊丟棄

Flag	作用
URP(urgent pointer)	發送緊急數據
ACK(Acknowladge)	除三次握手第一個包SYN=1外，其他包均有確認ACK=1
PSH(Push)	數據儘快交付應用層(現在不被信任失效)
RST(Reset)	復位，釋放連接
SYN	序號+1，第一次握手
FIN	序號+1，四次揮手

窗口大小：接收方可用緩存大小(Byte) ⇒ 發送方收到ACK之前一口氣可發送數據量，流量控制
                  實際計算窗口大小時，從應用層發來/取走緩衝區數據和ACK的時機考慮
校驗和    ：同樣併入僞首部進行校驗，必須校驗！！！
緊急指針：URG=1有效，序號+緊急指針=緊急數據最後一字節序號

選項	功能
MSS最大數據段長度 Maximum Segment Size	不包括TCP首部，SYN=1開始握手協商時有效 $每包數據大小<MSS-20IP頭-20TCP頭\\\leq MTU-20-20\leq 1460Byte$，使鏈路上分片較少
窗口擴大因子	針對(現代)超高速以太網一發緩衝區就滿的問題進行的改進

實驗：捕捉！三次握手四次揮手~

特性	解釋
socket	一個線程對應一個端口
指數退避	0、2(+2S)、6(+4S)、14(+8S)、30(+16S) 超時停止 或 一直重傳，多次退避後間隔不再變化
半閉連接	全雙工，只關閉一個方向，多見於第三次揮手之前
MSL 最大生存時間 Maximun Segment Lifetime	長短與系統有關 最後一次FIN_ACK可能丟失，服務器會一直重傳FIN 因此保留socket[SIP+DIP+SP+DP+TCP/IP] TIME_WAIT = 2MSL(一去一回) 確認服務器未重傳之後再重新建立連接纔不會“接口更換新進程”時歧義 故一般客戶端主動斷開連接，否則2MSL將長時間佔用服務器資源
平滑時間=MSL	同上避免重啓的同端口新進程歧義(解決辦法RST) 重啓後等待MSL時間纔開始接收 多數OS重啓時間>>MSL故省略平滑時間

TCP應用50%是塊數據流(FTP,SMTP,等)，50%是交互數據流(Telnet等)

RST

異常	復位
服務端的FIN始終未到	沒有有序釋放(orderly release)，爲防止服務端故意佔用客戶端資源 防火牆通常向客戶端發送RST包 促使客戶端從FIN_WAIT2轉變TIME_WAIT結束（見狀態遷移） 異常釋放(abortive release)
訪問不存在的端口	第一次握手直接返回一個tcp.flags.ack=1,tcp.flags.rst=1的重置包 eg：重啓後同端口的新進程(沒有三次握手就收到數據) “不知所云”，直接返回RST復位，重新三次握手

幫助應用層處理效率更高，發送端直接丟棄待發包，接收端根據”異常終止”的判斷採取相應措施

滑動窗口

接收方窗口=通告窗口(Announcement Window)

名詞	本意
窗口	對方的緩衝區(ACK=1，WIN=size)
滑動	數據上滑動，左邊緣=ACK_NUM(確認序列號)
合攏	收到ACK=1
張開	接收方應用層取走數據，清理緩衝區，向右移動 右邊緣=左邊緣+WIN
收縮	RFC極力反對基本不再使用

發送方不必按窗口大小飽和發送
超高速網絡，窗口小 ⇒ “一發就滿”，降級成“停止等待”
低速網絡，窗口大 ⇒ 網絡擁塞，丟包，慢啓動

慢啓動

slow start
發送方一次性發送多個報文段直至收到窗口更新
但低速網絡環境中會丟包，ICMP要求重傳，因此採用慢啓動，逐步擴大窗口，直至返回ACK確認的速率與發包速率相同，從而建立相對穩定的窗口大小
發送方窗口 稱 擁塞窗口(congestion window，cwnd)
連接開始建立時，cwnd初始化爲1MSS，收到一個ACK，cwnd+=2^ACK次數-1，逐漸增加
min(擁塞窗口，通告窗口)，實現慢啓動


通過帶寬時延乘積 $\color{red}通道容量(bit)=帶寬(b/s)\times 往返時間(s)$
表示鏈路上能夠承載的數據容量，從而實現理想情況下的 進=出，得到擁塞窗口大小

超時重傳

定時器種類	功能
重傳定時器	發包便開啓，超時未受ACK則重傳，指數退避
堅持(persist)定時器	發送方WIN_SIZE=0時啓動 發送方定時嗅接收方WIN_SIZE，等待ACK刷新WIN_SIZE ACK丟失，發送方WIN_SIZE=0，接收方始終等數據 ⇒ 死鎖 接收方不是每次嗅探(WindowProbe)都返回ACK刷新
保活(keepalive)定時器	空閒端—>掉線端，檢測掉線時間，應該交給應用負責！
2MSL定時器	最後的揮手計時

模糊窗口綜合徵(Silly Window Syndrome)
細碎的可用緩存空間通告，網路利用效率低
接收方：等待若干報文段大小的可用緩存，纔會返回ACK+WIN更新窗口，避免細碎報文
發送方：等待滿長度或半窗口長度報文段，除非是最後一個報文

超時重傳時間RTO RetransMision TimeOut	根據往返時間RTT計算	實時性
RFC 793	RTT=0.9*RTT+(1-0.9)*M C是人爲設定的時延離散因子	差
Jacobson	Err=M-A A=A+g*Err D=D+h*(|Err|-D) RTO=A+4*D	好

擁塞避免

超時 ⇒ 慢啓動 + 擁塞避免
$\Downarrow$
初始化cwnd=1，慢啓動門限(ssthresh)=65535
$\Downarrow$
cwnd指數增長
慢啓動min(cwnd，awnd)，cwnd和擁塞有關，awnd=接收方可用緩衝區大小
$\Downarrow$
出現超時丟包， $ssthresh=\frac{min(cwnd，awnd)}{2}$更新門限
重初始化 cwnd=1，cwnd指數增長
$\Downarrow$
某次cwnd>ssthresh，過渡至擁塞避免
cwnd線性增長，1RTT內cwnd+=1MSS

3次重複ACK ⇒ 快速重傳+快速恢復 (丟包速率減半)
收到重複ACK能夠確認後續包，並沒有嚴重的網絡擁塞
$\Downarrow$
無視超時重傳定時器，直接重傳ACK_NUM包
$\Downarrow$
快速恢復，收到第三個ACK時，$ssthresh=\frac{cwnd}{2}，cwnd=ssthresh+3MSS$
$\Downarrow$
仍然收到重複ACK，cwnd = cwnd+1，cwnd<awnd，使能發送下一數據包
$\Downarrow$
新的ACK確認丟失分組後所有的包進行的確認(對應滑動窗口左邊緣合攏)，$cwnd=ssthresh$
$\Downarrow$
擁塞避免算法

路由表會保存cwnd，RRT，RTO等歷史信息

應用層

DNS

HTTP

統一資源定位符（Uniform Resource Locator，URL）因特網上標準的資源地址
[協議類型]: //[訪問資源需要的憑證信息]@[服務器地址]:[端口號]/[資源層級UNIX文件路徑][文件名]?[查詢]#[片段ID]
其中[訪問憑證信息]、[端口號]、[查詢]、[片段ID]都屬於選填項。

FTP

TFTP

Trivial File Transfer Protocol，簡單文件傳輸協議是一種停止等待協議：收到ACK才發送下個數據包

SMTP/POP3

SSL

SNMP