Skip to content

Commit 8e080ba

Browse files
代码风水师代码风水师
authored andcommitted
1、分析了TCP和UDP的头部;2、分析了滑动窗口协议;
1 parent b6e6f20 commit 8e080ba

2 files changed

Lines changed: 96 additions & 3 deletions

File tree

resource/markdown/networking/SlidingWindowProtocol.md

Lines changed: 21 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,26 @@
66

77

88

9-
<h3 style="padding-bottom:6px; padding-left:20px; color:#ffffff; background-color:#E74C3C;">滑动窗口协议的机制</h3>
9+
<h3 style="padding-bottom:6px; padding-left:20px; color:#ffffff; background-color:#E74C3C;">TCP流量控制与滑动窗口协议</h3>
1010

11-
![滑动窗口协议的机制]()
11+
![滑动窗口协议的机制](https://i.loli.net/2019/01/13/5c3b5c7c55887.png)
12+
13+
TCP滑动窗口从发送端和接收端分为发送窗口和接收窗口,各自维护着一个滑动窗口,以此来达到流量控制。
14+
15+
16+
17+
#### 关于滑动窗口协议中的概念
18+
19+
**发送端:**
20+
21+
* 已发送并收到确认:已经发送数据段,并且这些数据被接收端已确认接收;
22+
* 已发送,未收到确认:已经发送数据段,但发送端未接收到由接收端发送的已接收的确认消息;
23+
* 未发送,可以发送:在流量控制中,数据量未达发送的到阈值,是可以由发送端发送的,但发送端还未来得及发送;
24+
* 未发送,不允许发送:发送端发送的数据过多,但很多数据未被确认接收,为达到流量控制的效果,这些数据段不允许被发送。
25+
26+
**接收端:**
27+
28+
* 已发送确认并已交付主机:接收端对已接收的数据交付给内部使用,并且发送确认已收到的消息给发送端,表示客户端已收到相应的数据,避免数据丢失;
29+
* 允许接受:在接受窗口中,未达到阈值的情况下,接收端允许接受数据的窗口;
30+
* 不允许接受:为了达到流量控制,接收到不能无限制的接受数据,达到接受窗口的阈值时,接受端将不允许接受数据。
1231

resource/markdown/networking/TCPAndUDP.md

Lines changed: 75 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -10,13 +10,80 @@
1010
1111

1212

13+
**TCP的头部**
14+
15+
![TCP包首部格式](https://i.loli.net/2019/01/13/5c3b36cf5fc20.png)
16+
17+
* **32位端口号:**
18+
19+
源端口和目的端口各占16位,2的16次方等于65536,查看看端口的命令:netstat。
20+
21+
* **32位序列号:**
22+
23+
也称为顺序号(Sequence Number),简写为seq,
24+
25+
* **32位确认序号:**
26+
27+
也称为应答号(Acknowledgment Number),简写为ACK。在握手阶段,确认序号将发送方的序号加1作为回答。
28+
29+
* **4位首部长度:**
30+
31+
这个字段占4位,它的单位时32位(4个字节)。本例值为7,TCP的头长度为28字节,等于正常的长度2 0字节加上可选项8个字节。,TCP的头长度最长可为60字节(二进制1111换算为十进制为15,15*4字节=60字节)。
32+
33+
* **6位标志字段:**
34+
35+
ACK 置1时表示确认号为合法,为0的时候表示数据段不包含确认信息,确认号被忽略。
36+
37+
RST 置1时重建连接。如果接收到RST位时候,通常发生了某些错误。
38+
39+
SYN 置1时用来发起一个连接。
40+
41+
FIN 置1时表示发端完成发送任务。用来释放连接,表明发送方已经没有数据发送了。
42+
43+
URG 紧急指针,告诉接收TCP模块紧要指针域指着紧要数据。注:一般不使用。
44+
45+
PSH 置1时请求的数据段在接收方得到后就可直接送到应用程序,而不必等到缓冲区满时才传送。注:一般不使用。
46+
47+
* **16位窗口大小:**
48+
49+
又称接受窗口字段(Receive Window Field),该字段用于流量控制。用于指示接收方愿意接受的字节数量。
50+
51+
* **16位检验和:**
52+
53+
又称因特网校验和,检验和覆盖了整个的TCP报文段: TCP首部和TCP数据。这是一个强制性的字段,一定是由发端计算和存储,并由收端进行验证。
54+
55+
* **16位紧急指针:**
56+
57+
**注:**一般不使用。
58+
59+
又称紧急数据指针,只有当URG标志置1时紧急指针才有效。紧急指针是一个正的偏移量,和序号字段中的值相加表示紧急数据最后一个字节的序号。
60+
61+
* **可选与变长选项**
62+
63+
通常为空,可根据首部长度推算。用于发送方与接收方协商最大报文段长度(MSS),或在高速网络环境下作窗口调节因子时使用。首部字段还定义了一个时间戳选项。
64+
65+
最常见的可选字段是最长报文大小,又称为MSS (Maximum Segment Size)。每个连接方通常都在握手的第一步中指明这个选项。它指明本端所能接收的最大长度的报文段。1460是以太网默认的大小。
66+
67+
68+
1369
<h3 style="padding-bottom:6px; padding-left:20px; color:#ffffff; background-color:#E74C3C;">UDP</h3>
1470

1571
> UDP,User Data Protocol,用户数据报协议,面向 **非连接** 的传输协议,既传输数据前客户端和服务端 **无需** 建立连接,数据也可被传输,但 *被传输* 不带表一定传输成功。传世时直接将数据包丢给对方。
1672
1773

1874

19-
#### 对比
75+
**UPD的头部**
76+
77+
![UDP包首部格式](https://i.loli.net/2019/01/13/5c3b39228488e.png)
78+
79+
* 16位源端口号 记录源端口号,在需要对方回信时选用。不需要时可用全0。
80+
* 16位目的端口号 记录目标端口号。这在终点交付报文时必须要使用到。
81+
* 长度 UDP数据报的长度(包括数据和首部),其最小值为8B(即仅有首部没有数据的情况)。
82+
* 校验和 检测UDP数据报在传输中是否有错,有错就丢弃。该字段时可选的,当源主机不想计算校验和,则直接令该字段为全0。当传输层从IP层收到UDP数据报时,就根据首部中的目的端口,把UDP数据报通过相应的端口,上交给进程。如果接收方UDP发现收到的报文中目的端口号不正确(即不存在对应端口号的应用进程),就丢弃该报文,并由ICMP发送“端口不可达”差错报文交给发送方。
83+
84+
85+
86+
<h3 style="padding-bottom:6px; padding-left:20px; color:#ffffff; background-color:#E74C3C;">对比</h3>
2087

2188
| 对比维度\传输协议 | TCP | UDP |
2289
| :---------------- | ---------------------- | -------------------- |
@@ -25,3 +92,10 @@
2592
| 速度 |||
2693
| 使用环境 | 传输数据量少、可靠性高 | 传输数量多、可靠性低 |
2794

95+
96+
97+
> 参考资料:
98+
>
99+
> [TCP、UDP报文结构与区别](https://blog.csdn.net/cbjcry/article/details/84650730)
100+
>
101+
> [UDP协议的特点及UDP头部结构](https://blog.csdn.net/ASJBFJSB/article/details/80357111)

0 commit comments

Comments
 (0)