总述

链路层

以太网只是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
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]

可能的攻击	原因
渗透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.9RTT+(1-0.9)M C是人为设定的时延离散因子	差
Jacobson	Err=M-A A=A+gErr 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才发送下个数据包

计算机网络--TCP/IP

总述

链路层