总述
链路层
三个基本需求:
1.封装帧
假如传输(实际不可能)ASCII码文本,使用控制字符SOH(Start of Header,0x01)及EOT(End of Transmission,0x04)作帧定界符
最大传送单元(Maximun Transfer Unit):数据部分长度上限
2.透明传输
字节/字符填充:假如传输(实际不可能)ASCII码文本,数据中出现“EOT”将导致误解,通过在数据中"SOH",“EOT"前插入"ESC”(0x1B)转义字符,接收端送入网络层之前去掉ESC即可
3.差错检测
比特差错:0 --> 1
误
码
率
B
E
R
(
B
i
t
E
r
r
o
r
R
a
t
e
)
=
差
错
比
特
数
传
输
比
特
数
误码率BER(Bit Error Rate)=\frac{差错比特数}{传输比特数}
误码率BER(BitErrorRate)=传输比特数差错比特数
循环冗余校验CRC(Cyclic Redundancy Check):
以太网
以太网: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
代理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
]
×
4
B
y
t
e
≤
60
B
y
t
e
=
20
+
40
(
选
项
)
首部长度[4,15] \times 4Byte \leq \color{red}60Byte = 20 + 40(选项)
首部长度[4,15]×4Byte≤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
)
+
上
一
片
的
报
文
大
小
8
B
y
t
e
上一片的报文偏移(起始=0) + \frac{上一片的报文大小}{8 Byte}
上一片的报文偏移(起始=0)+8Byte上一片的报文大小保证重组装顺序
分片数据大小(Byte) = 除IP首部外的大小 =
m
a
x
(
8
n
)
≤
M
T
U
max(8n)\leq MTU
max(8n)≤MTU,注意最后一个分片<46时垫片
生存时间(TTL,time to live):设定可以经过的最大路由器数目,经过一个路由器自减1
协议:告知下一首部类别,TCP=6,UDP=17,ICMP=1
检验和只校验首部,从格式可以看出一定有偶数个字节求
∑
n
16
b
i
t
\sum\limits_{}^{n}16bit
∑n16bit
选项
防火墙阻止几乎所有的TCP/IP选项设置报文通过!!
选项码 = 复制位(1)+选项类(3)+选项号(5)
复制位 = 1(复制选项到所有分片) / 0(仅复制给第一个分片)
选项码 | 长度 | 指针 | IP地址队列 |
---|---|---|---|
0x89=严选 | 选项总长度 | 最多 60 − 20 − 3 4 B y t e / I P = 9 \frac{60-20-3}{4 Byte/IP}=9 4Byte/IP60−20−3=9个IP地址 | |
0x83=宽选 | 选项总长度 | 最多 60 − 20 − 3 4 B y t e / I P = 9 \frac{60-20-3}{4 Byte/IP}=9 4Byte/IP60−20−3=9个IP地址 | |
0x87=记录IP | 选项总长度 | 下次写入IP位置 | 记录区: I P 1 , I P 2... IP1,IP2... IP1,IP2... |
源路由选择:按源给出的路由IP顺序经过,测试路由连通性 或 吞吐量
实现方式:比如由路由器调整指针逐一取出下一站IP
严格源(站)路由选择—指定路由间直连
宽松源(站)路由选择—指定的路由顺序之间可以插入其他未指定的路由(搭桥)
记录路由:记录从源开始的出口IP,一去一回路由器的进出口便都被记录,选项总长度
≤
39
=
3
+
60
−
20
−
3
4
B
y
t
e
/
I
P
\color{red}\leq 39= 3+\frac{60-20-3}{4 Byte/IP}
≤39=3+4Byte/IP60−20−3,指针=40表示溢出
也不是所有的路由器都支持路径记录!!
选项码 | 长度 | 指针 | 溢出个数 | 格式标志 | IP地址队列 |
---|---|---|---|---|---|
0x44=记录时间 | ≤ 40 \color{red}\leq 40 ≤40 | 写入位置 | 4bit | 4bit | 36Byte |
Ping IP -R
记录时间戳:记下经过的时间(格林威治Universal Time,ms和IP地址)
溢出(OverFlow)未能记录的数据个数
标志(FlaG)控制时间戳选项格式
0=不记录IP
1=4
×
\times
× (IP + 时间)
3=只记录 到达源初始化给定IP 的时间
注意路由时间不一定同步!!
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 n o w − T s t a r t T_{往返}=T_{now}-T_{start} T往返=Tnow−Tstart)
对回显报文的处理方式随系统等不定,结果和协议、端口号均有关(如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前:最小子网容量28=256,或216=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)
校验是可选的,由于 ∑ n ( 16 b i t ) \sum\limits_{}^{n}{(16bit)} ∑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)
特性 | 功能 |
---|---|
面向连接 | 点对点(应用)三次握手四次挥手 只能单播!!! |
可靠 |
收
包
后
延
迟
确
认
省
资
源
{
客
户
端
延
迟
200
m
s
或
收
到
第
二
个
数
据
报
后
捎
带
A
C
K
应
用
程
序
取
走
数
据
后
返
回
真
实
的
缓
冲
区
大
小
收包后延迟确认省资源\begin{cases}\color{red}客户端延迟200ms或收到第二个数据报后捎带ACK&\\应用程序取走数据后返回真实的缓冲区大小\end{cases}
收包后延迟确认省资源{客户端延迟200ms或收到第二个数据报后捎带ACK应用程序取走数据后返回真实的缓冲区大小 未及时确认将重发 首身校验和 IP失序,重发 ⇒ TCP排序,重复丢弃 流量(收发速率)控制 |
字节流 Byte Stream Service | 根据MMS将应用层数据“分批OR拼接”成合适大小 不解释内容 抓不到完全一样的包 |
端口号 :[SIP+DIP+Protocol(TCP/IP)+SPort+DPort] = 五元组 确定 一个 session
[IP+Port] = socket(socket pair)插口(插口对),实时连接状态监控防火墙“根基”
序号 :数据第一个字节序号,[0~232-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
]
×
4
=
60
B
y
t
e
=
5
×
4
B
y
t
e
首
部
+
40
B
y
t
e
选
项
[2^4-1] \times 4 = 60 Byte = 5 \times 4 Byte 首部 + 40 Byte选项
[24−1]×4=60Byte=5×4Byte首部+40Byte选项
无效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开始握手协商时有效 每 包 数 据 大 小 < M S S − 20 I P 头 − 20 T C P 头 ≤ M T U − 20 − 20 ≤ 1460 B y t e 每包数据大小<MSS-20IP头-20TCP头\\\leq MTU-20-20\leq 1460Byte 每包数据大小<MSS−20IP头−20TCP头≤MTU−20−20≤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+=2ACK次数-1,逐渐增加
min(拥塞窗口,通告窗口),实现慢启动
通过带宽时延乘积
通
道
容
量
(
b
i
t
)
=
带
宽
(
b
/
s
)
×
往
返
时
间
(
s
)
\color{red}通道容量(bit)=带宽(b/s)\times 往返时间(s)
通道容量(bit)=带宽(b/s)×往返时间(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
⇓
出现超时丢包,
s
s
t
h
r
e
s
h
=
m
i
n
(
c
w
n
d
,
a
w
n
d
)
2
ssthresh=\frac{min(cwnd,awnd)}{2}
ssthresh=2min(cwnd,awnd)更新门限
重初始化 cwnd=1,cwnd指数增长
⇓
\Downarrow
⇓
某次cwnd>ssthresh,过渡至拥塞避免
cwnd线性增长,1RTT内cwnd+=1MSS
3次重复ACK ⇒ 快速重传+快速恢复 (丢包速率减半)
收到重复ACK能够确认后续包,并没有严重的网络拥塞
⇓
\Downarrow
⇓
无视超时重传定时器,直接重传ACK_NUM包
⇓
\Downarrow
⇓
快速恢复,收到第三个ACK时,
s
s
t
h
r
e
s
h
=
c
w
n
d
2
,
c
w
n
d
=
s
s
t
h
r
e
s
h
+
3
M
S
S
ssthresh=\frac{cwnd}{2},cwnd=ssthresh+3MSS
ssthresh=2cwnd,cwnd=ssthresh+3MSS
⇓
\Downarrow
⇓
仍然收到重复ACK,cwnd = cwnd+1,cwnd<awnd,使能发送下一数据包
⇓
\Downarrow
⇓
新的ACK确认丢失分组后所有的包进行的确认(对应滑动窗口左边缘合拢),
c
w
n
d
=
s
s
t
h
r
e
s
h
cwnd=ssthresh
cwnd=ssthresh
⇓
\Downarrow
⇓
拥塞避免算法
路由表会保存cwnd,RRT,RTO等历史信息
应用层
DNS
HTTP
统一资源定位符(Uniform Resource Locator,URL)因特网上标准的资源地址
[协议类型]: //[访问资源需要的凭证信息]@[服务器地址]:[端口号]/[资源层级UNIX文件路径][文件名]?[查询]#[片段ID]
其中[访问凭证信息]、[端口号]、[查询]、[片段ID]都属于选填项。
FTP
TFTP
Trivial File Transfer Protocol,简单文件传输协议是一种停止等待协议:收到ACK才发送下个数据包