TCP协议整理_重传风暴-CSDN博客

本文链接：https://blog.csdn.net/tianxia_taiping/article/details/90129314

文章目录

TCP 状态机异常分析
三次握手的异常
四次握手的异常
TCP协议疑难杂症全景解析-摘录

TCP 状态机异常分析

1.出现大量的SYN_RECV

外部流量攻击
对付SYN FLOOD的话，真正起作用的是：
sysctl -w net.ipv4.tcp_syncookies=1 #启用使用syncookies
sysctl -w net.ipv4.tcp_synack_retries=1 #降低syn重试次数

2.出现大量的SYN_SENT

内部中病毒

3.出现大量的CLOSE_WAIT

内部代码有问题，没有关闭连接

4.出现大量的TIME_WAIT

存在大量的短连接

5.出现大量的LASK_ACK

需要减少retry次数

6.出现大量的FIN_WAIT2

对端有问题没有回fin包，
调整tcp_fin_timeout的超时时间

7.出现大量的FIN_WAIT1

对端可能拒绝服务
需要减少retry次数

三次握手的异常

1.第一次握手丢包：

默认情况下，connect()是阻塞式的，如果请求无法发送到服务器，那么connect会进行一段很长时间的等待和重试

2.第二次握手丢包：

对于客户来说，依然是connect超时，所以处理方式和第一次握手丢包是一样的。对于服务器来说，由于收不到第三次握手请求，所以会进行等待重传，直到多次重传失败后，关闭半连接。

3.第三次握手丢包：

由于客户在发送第三次握手包后，不再等待确认，就直接进入了ESTABLISHED状态，所以一旦第三次握手失败，客户和服务器的状态就不同步了。当然，此时服务器会进行多次重发，一旦客户再次收到SYN+ACK（第二次握手请求），会再次确认。不过，如果第三次握手一直失败，则会出现，客户已经建立连接，而服务器关闭连接的情况。随后，一旦客户向服务器发送数据，则会收到一条RST回应，告诉用户连接已经重置，需要重新进行三次握手。

四次握手的异常

1.第一次握手丢包：

FIN_WAIT1丢失会导致客户重传，如果多次重传失败，则客户超时关闭连接，而服务器依然保持ESTABLISHED状态。如果服务器主动发送数据，则会收到一个RST包，重置连接。

2.第二次握手丢包：

由于服务器第二次握手不会重发，所以即使丢包也不管，直接向对方发送FIN，此时客户执行”同时关闭“的流程（这个流程后面再说），等待TIME_WAIT时间后关闭。在客户进入TIME_WAIT之后，自己由于FIN没有响应，会重发，如果被客户TIME_WAIT收到并发送LAST-ACK，则流程正常结束，如果反复重发没有响应，那么超时关闭

3.第三次握手丢包：

服务器会持续等待在LAST_ACK状态，而客户会持续等待在FIN_WAIT2状态，最后双方超时关闭

4.第四次握手丢包：

客户端进入TIME_WAIT状态，等待2MSL，服务器由于收不到LAST-ACK则进行重发，如果多次重发失败，则超时关闭

https://blog.csdn.net/dog250/article/details/6612496

TCP协议疑难杂症全景解析-摘录

TCP/IP的漂亮之处在于：协议越往上层越复杂。
链路其实就是始发与一个设备，通过一根线，终止于另一个设备。我们把一条链路称为“一跳”。因此一个端到端的网络包含了“很多跳”。

IP设计为分组转发协议，力求简单：路由、转发
TCP的作用是传输控制，点对点实现，精华就是传输和控制

实际上最开始的时候，TCP并不考虑性能，效率，公平性，正是考虑了这些，TCP协议才复杂了起来。

TCP协议有两重身份
作为网络协议，它弥补了IP协议尽力而为服务的不足，实现了有连接，可靠传输，报文按序到达。
作为一个主机软件，它和UDP以及左右的传输层协议隔离了主机服务和网络，它们可以被看做是一个多路复用/解复用器，将诸多的主机进程数据复用/解复用到IP层。

TCP要点有四，一：有连接，二：可靠传输，三：数据按序到达，四：端到端流量控制。
演变过程中加入了五：拥塞控制

1.有连接

疑难杂症1：3次握手和4次挥手

3次握手建立一条连接，该握手初始化了传输可靠性以及数据顺序性必要的信息
3次是保证达到上述目的的最低次数。
4次挥手因为TCP是全双工

疑难杂症2：TIME_WAIT状态

每次建立连接的时候序列号都是随机产生的，并且这个序列号是32位的，会回绕
1.正常的结束2端的连接 2.让ack和fin2个包尽可能的失活(2MSL)
将TIME_WAIT的值设置的很低是一种冒险行为,最好的方式就是，不要重用一个连接。

疑难杂症3：重用一个连接和重用一个套接字

这2个含义不同
tcp_tw_reuse是内核选项，而SO_REUSEADDR用户态的选项

2.传输可靠性

传输可靠性是靠确认号实现的

疑难杂症4：超时时间的计算

RTT，代表一个TCP分段的往返时间
除了考虑每两次测量值的偏差之外，其变化率也应该考虑在内，如果变化率过大，则通过以变化率为自变量的函数为主计算RTT(如果陡然增大，则取值为比较大的正数，如果陡然减小，则取值为比较小的负数，然后和平均值加权求和)，反之如果变化率很小，则取测量平均值。这是不言而喻的，这个算法至今仍然工作的很好。

疑难杂症5：超时计时器的管理-每连接单一计时器

采取每一个TCP连接单一计时器的设计则成了一个默认的选择
设计单一计时器有两个原则：
1.每一个报文在长期收不到确认都必须可以超时；
2.这个长期收不到中长期不能和测量的RTT相隔太远。

设计原则：
a.发送TCP分段时，如果还没有重传定时器开启，那么开启它。
b.发送TCP分段时，如果已经有重传定时器开启，不再开启它。
c.收到一个非冗余ACK时，如果有数据在传输中，重新开启重传定时器。
d.收到一个非冗余ACK时，如果没有数据在传输中，则关闭重传定时器。
重传定时器超时后，依次做下列3件事情：
[4.1]. 重传最早的尚未被TCP接收方ACK的数据包
[4.2]. 重新设置RTO 为 RTO * 2（“还原定时器”），但是新RTO不应该超过RTO的上限(RTO有个上限值，这个上限值最少为60s)
[4.3]. 重启重传定时器。

疑难杂症6：何时测量RTT

将时间戳放入协议头的时间戳字段，然后接收端将其回显在ACK即可，然后发送端收到ACK后，取出时间戳，和当前时间做算术差，即可完成一次RTT的测量。

3.数据顺序性

数据顺序性是靠序列号实现的。

疑难杂症7：确认号和超时重传

确认号是接收端发出的，接收端只确认按序到达的最后一个TCP分段
接收端会丢弃任何重复的数据，即使丢弃了重复的数据，其ACK还是会照发不误的。
重传风暴，一个分段丢失，引起大量的重传,重传风暴只能加重其拥塞程度

疑难杂症8：乱序数据缓存以及选择确认

选择确认SACK:接收端会显式告诉发送端需要重传哪些分段而不需要重传哪些分段。
这无疑避免了重传风暴。

对SACK进行了扩展，提出了D-SACK
利用第一块SACK数据中描述重复接收的不连续数据块的序列号参数，其他SACK数据则描述其他正常接收到的不连续数据。这样发送方利用第一块SACK，可以发现数据段被网络复制、错误重传、ACK丢失引起的重传、重传超时等异常的网络状况，使得发送端能更好调整自己的重传策略。
D-SACK优点：
1）发送端可以判断出，是发包丢失了，还是接收端的ACK丢失了。(发送方，重传了一个包，发现并没有D-SACK那个包，那么就
是发送的数据包丢了；否则就是接收端的ACK丢了，或者是发送的包延迟到达了)
2）发送端可以判断自己的RTO是不是有点小了，导致过早重传(如果收到比较多的D-SACK就该怀疑是RTO小了)。
3）发送端可以判断自己的数据包是不是被复制了。(如果明明没有重传该数据包，但是收到该数据包的D-SACK)
4）发送端可以判断目前网络上是不是出现了有些包被delay了，也就是出现先发的包却后到了。

疑难杂症9：TCP序列号的回绕的问题

回绕在计算机里面太常见了，只需要能识别出来即可解决
如今可以用时间戳选项来辅助作为序列号的一个识别的部分

4.端到端的流量控制

端到端的流量控制使用滑动窗口来实现
滑动窗口的原理非常简单，基本就是一个生产者/消费者模型

当接收端通知一个zero窗口的时候，发送端的发送窗口也变成了0，也就是发送端不能发数据了。
起码有一个主动探测的机制。为解决0窗口的问题，TCP使用了Zero Window Probe技术，缩写为ZWP
发送端在窗口变成0后，会发ZWP的包给接收方，来探测目前接收端的窗口大小，一般这个值会设置成3次，每次大约30-60秒（不同的实现可能会不一样）。
如果3次过后还是0的话，有的TCP实现就会发RST掉这个连接。

疑难杂症10：流量控制的真实意义

流量控制会很有效的协调两端的流量匹配,但是会造成网络利用率下降
造成这种局面的原因在于，滑动窗口只是限制了最大发送的数据，却没有限制最小发送的数据，
结果导致一些很小的数据被封装成TCP分段，报文协议头所占的比例过于大，造成网络利用率下降

5.端到端意义上的TCP协议效率

三个问题：
1.
问题：接收端处理慢，导致接收窗口被填满
解决：窗口通告
2.
问题：接收端处理慢，导致接收窗口被填满
解决：Nagle算法
3.
问题：确认号(ACK)本身就是不含数据的分段，因此大量的确认号消耗了大量的带宽
解决：延迟ACK

问题1几乎总是出现在接收端窗口满的情况下，而问题2几乎总是发生在窗口闲置的情况下，问题3看起来是最无聊的，然而由于TCP的要求，必须要有确认号，而且一个确认号就需要一个TCP分段，这个分段不含数据，无疑是很小的。
三个问题都导致了网络利用率的降低

Nagle 算法的规则：
[1]如果包长度达到 MSS ，则允许发送；
[2]如果该包含有 FIN ，则允许发送；
[3]设置了 TCP_NODELAY 选项，则允许发送；
[4]设置 TCP_CORK 选项时，若所有发出去的小数据包（包长度小于 MSS ）均被确认，则允许发送；
[5]上述条件都未满足，但发生了超时（一般为 200ms ），则立即发送

疑难杂症11：糊涂窗口解决方案和Nagle算法

糊涂窗口综合症患者希望发送端积累TCP分段，而Nagle算法确实保证了一定的TCP分段在发送端的积累
Nagle算法可以缓解糊涂窗口综合症，却不是治本的良药

疑难杂症12：Nagle算法和延迟ACK

延迟ACK实际上是在增加延迟的代价下加强了Nagle算法。在延迟ACK加Nagle算法的情况下，接收端只有不断有数据要发回，才能同时既保证了发送端的分段积累，又保证了延迟不增加，同时还没有或者很少有空载的ACK。

疑难杂症13：到底何时可以发送数据

有不同的优化方案

疑难杂症14：《TCP/IP详解(卷一)》中Nagle算法的例子解读

竞态问题
这种不加锁的发送方式是合理的，也是最高效的，因此TCP的处理语义会做出判断，丢弃一切不该接收或者重复接收的分段的。

6.IP网络之上的TCP

端到端的TCP协议和IP协议之间的矛盾
端到端的TCP只能看到两个节点，那就是自己和对方，它们是看不到任何中间的路径的。
忽略得了IP网络的情况，势必需要一种拥塞控制机制，反应路径的拥塞情况。

疑难杂症15：拥塞控制的本质

只有在以下情况下拥塞控制才会起作用：
a.两个或两个以上的连接(其中一个一定要是TCP，另一个可以是任意连接)经过同一个路由器或者同一个链路时；
b.只有一个TCP连接，然而它经过了一个路由器时。
拥塞控制需要完成以下两个任务：1.公平性；2.拥塞之后退出拥塞状态。

疑难杂症16：影响拥塞的因素

拥塞控制是一个整体的机制，它不偏向于任何TCP连接公平性
分段在经过路由器的时候排队和处理总是会有时延，因此最终肯定会丢包的重传风暴
丢包的延后性也会加重拥塞

拥塞控制的策略：
慢启动
拥塞避免
快速重传
快速恢复

慢启动要从1个MSS开始增加拥塞窗口，
而快速重传/快速恢复则是一旦收到3个冗余ACK，不必进入慢启动，而是将拥塞窗口缩小为当前阀值的一半加上3，
然后如果继续收到冗余ACK，则将拥塞窗口加1个MSS，直到收到一个新的数据ACK，将窗口设置成正常的阀值，开始加性增加的阶段

疑难杂症17：超时重传和收到3个冗余ACK后重传

超时重传：一般是因为网络出现了严重拥塞
收到3个冗余ACK后重传：般是路由器故障或者轻度拥塞或者其它不太严重的原因引起的

疑难杂症18：为何收到3个冗余ACK后才重传

如果仅仅收到一个乱序的分段，那很可能被中间路由器重排了，那么另一个分段很可能马上就到，然而如果连续收到了3个分段都没能弥补那个缺漏，那很可能是它丢失了，需要重传
3个冗余ACK是一种权衡，在减少不必要重传和确实能检测出单个分段丢失之间所作的权衡。
注意，冗余ACK是不能捎带的。

疑难杂症19：乘性减和加性增的深层含义

拥塞窗口的增加受惠的只是自己，而拥塞窗口减少受益的大家，可是自己却受到了伤害
恰恰就是这种乘性减实现了公平性
拥塞窗口的1个MSS的改变影响一个TCP发送者，为了使得自己拥塞窗口的减少影响更多的TCP发送者-让更多的发送者受益，那么采取了乘性减的策略。

疑难杂症20：TCP连接的传输稳定状态是什么

发送端的发送窗口怎么确定，它取的是拥塞窗口和接收端通告窗口的最小值
三种发送窗口的稳定状态：
a.IP互联网络上接收端拥有大窗口的经典锯齿状
b.IP互联网络上接收端拥有小窗口的直线状态
c.直连网络端点间的满载状态下的直线状态

a为大多数常态
b接收端能力太水
c端和端之间独享带宽

主动的拥塞避免
1.试探性的检测，然后拥塞窗口被动的进行乘性减
2.通过持续观测RTT的方式来主动调整拥塞窗口的大小而不是一味的加性增
3.计算两个差值的乘积：(当前拥塞窗口-上一次拥塞窗口)x(当前的RTT-上一次的RTT)
如果结果是正数，则拥塞窗口减少1/8，若结果是负数或者0，则窗口增加一个MSS。

疑难杂症21：路由器和TCP的互动

路由器能不能做点什么帮助检测拥塞呢
这种方式就是当路由器检测到自己发生轻微拥堵的时候随机的丢包
随机丢包而不是连续丢包对于TCP而言是有重大意义的，随机丢包会使TCP发现丢弃了个别的分段而后续的分段仍然会到达接收端，
这样TCP发送端就会接收到3个冗余ACK，然后进入快速重传/快速恢复而不是慢启动。