分类: LINUX
2018-11-29 12:52:17
一直都想整理一下关于TCP方面的白话文章,可是拖延症导致迟迟未动手,这次公司技术分享,终于动手整理一下。内容太多,分成两篇 http://blog.chinaunix.net/uid-27105712-id-5794026.html
tcp 协议 是互联网中最常用的协议 , 开发人员基本上天天和它打交道,对它进行深入了解。 可以帮助我们排查定位bug和进行程序优化。下面我将就TCP几个点做深入的探讨
客户端:收到 ack 后 分配连接资源。 发送数据
服务器 : 收到 syn 后立即 分配连接资源
2、三次握手缺陷:
当ack 丢失后, 服务器认为连接建立了,等待客户端发送数据。 但是客户端并没有建立连接。服务器一直在等待数据,耗费资源。
PS: 网上有说法是什么TCP全双工需要互相确认,个人觉得和这个没有任何关系的。
客户端:收到ACK, 立即分配资源
服务器:收到ACK, 立即分配资源
3、四次、五次、六次...握手?缺陷: 同样问题, 最后一个ACK,服务器没有收到, 这是 客户端分配了资源, 但是服务器没有分配资源。 客户端并不知道,继续发送数据。服务器会返回 RST 信号。 因此问题影响不大。
既然三次握手也不是100%可靠, 那四次,五次,六次。。。呢? 其实都一样,不管多少次都有丢包问题。
client 只发送一个 SYN, server 分配一个tcb, 放入syn队列中。 这时候连接叫半连接状态;如果server 收不到 client 的ACK, 会不停重试 发送 ACK-SYN 给client 。重试间隔 为 2 的 N 次方 叠加(2^0 , 2^1, 2^2 ....);直至超时才释放syn队列中的这个 TCB;
在半连接状态下, 一方面会占用队列配额资源,另一方面占用内存资源。我们应该让半连接状态存在时间尽可能的小
当client 向一个未打开的端口发起连接请求时,会收到一个RST回复包
当listen 的 backlog 和 somaxconn 都设置了得时候, 取两者min值
3、当前连接队列大小查看
Recv-Q 是accept 队列当前个数, Send-Q 设置最大值
4、SYN队列满的情况
这种SYN洪水攻击是一种常见攻击方式,就是利用半连接队列特性,占满syn 队列的 资源,导致 client无法连接上。
解决方案:
为什么不像握手那样合并成三次挥手? 因为和刚开始连接情况,连接是大家都从0开始, 关闭时有历史包袱的。server(被动关闭方) 收到 client(主动关闭方) 的关闭请求FIN包。 这时候可能还有未发送完的数据,不能丢弃。 所以需要分开。事实可能是这样
当然,在没有待发数据,并且允许 Delay ACK 情况下, FIN-ACK合并还是非常常见的事情,这是三次挥手是可以的。
3、二次挥手行不行同上
4、半关闭(CLOSE_WAIT)CLOSE_WAIT 是被动关闭方才有的状态。
被动关闭方 [收到 FIN 包 发送 ACK 应答] 到 [发送FIN, 收到ACK ] 期间的状态为 CLOSE_WAIT, 这个状态仍然能发送数据。 我们叫做半关闭, 下面用个例子来分析:
这个是我实际生产环境碰到的一个问题,长连接会话场景,server端收到client的rpc call 请求1,处理发现请求包有问题,就强制关闭结束这次会话, 但是 因为client 发送 第二次请求之前,并没有去调用recv,所以并不知道 这个连接被server关闭, 继续发送 请求2 , 此时是半连接,能够成功发送到对端机器,但是recv结果后,遇到连接已经关闭错误。
5、同时关闭CLOSE_WAIT 和 后面提到的 TIME_WAIT 一样,都是存在潜在危害,CLOSE_WAIT 状态下 文件句柄资源没有释放。要知道系统 句柄资源也是有限的。要尽快释放close掉。
如果 client 和 server 恰好同时发起关闭连接。这种情况下,两边都是主动连接,都会进入 TIME_WAIT状态
4、TIME_WAIT 状态
TIME_WAIT 状态 是主动关闭方才有的状态:这种状态下有个让开发人员都很苦恼的普遍性问题,端口耗尽, 我们知道,端口数据类型是 unsigned short。 最大值是 65535. 所以 一台机 上 最多分配 65535个端口(不考虑accept的tcp资源情况下,也可以看成一台机器最多只能分配这么链接数)。
然而,TIME_WAIT* 持续保持时间是 2*MSL( Maximum segment lifetime)。 默认是 2分钟。( 通过这个可以修改 /proc/sys/net/ipv4/tcp_fin_timeout)。想想在并发高的机器上 2分钟 很容易发起超过 6w多个短链接请求。 这时候就出现端口不够用,connect 错误“Cannot assign requested address” 。
TIME_WAIT的如此设计是为了解决2个问题:
以下两种讨论的两种情况都是 假设 前后两次连接都是相同四元组( 源ip,源端口,目的ip,目的端口),都是属于 "在不相关的连接中接受延迟的段"现象
1、被动关闭方在LAST_ACK状态(已经发送FIN),等待主动关闭方的ACK应答,但是 ACK丢掉, 主动方并不知道,以为成功关闭。因为没有TIME_WAIT等待时间,可以立即创建新的连接, 新的连接发送SYN到前面那个未关闭的被动方,被动方认为是收到错误指令,会发送RST。导致创建连接失败。
2、主动关闭方断开连接,如果没有TIME_WAIT等待时间,可以马上建立一个新的连接,但是前一个已经断开连接的,延迟到达的数据包。 被新建的连接接收,如果刚好seq 和 ack字段 都正确, seq在滑动窗口范围内(只能说机率非常小,但是还是有可能会发生),会被当成正确数据包接收,导致数据串包。 如果不在window范围内,则没有影响( 发送一个确认报文(ack 字段为期望ack的序列号,seq为当前发送序列号),状态变保持原样)
TIME_WAIT 问题比较比较常见,特别是CGI机器,并发量高,大量连接后段服务的tcp短连接。因此也衍生出了多种手段解决。虽然每种方法解决不是那么完美,但是带来的好处一般多于坏处。还是在日常工作中会使用。
1、改短TIME_WAIT 等待时间
2、禁止Socket lingering
这种情况下关闭连接,会直接抛弃缓冲区中待发送的数据,会发送一个RST给对端,相当于直接抛弃TIME_WAIT, 进入CLOSE状态。同样因为取消了 TIME_WAIT 状态,会有前面两种问题小概率发生。
3、tcp_tw_reuse
net.ipv4.tcp_tw_reuse选项是 从 TIME_WAIT 状态的队列中,选取条件:1、remote 的 ip 和端口相同, 2、选取一个时间戳小于当前时间戳; 用来解决端口不足的尴尬。
那么如果我能在新连接中识别出此包为非法包,是不是就可以丢掉这些无用包,解决问
需要实现这些功能,需要扩展一下tcp 包头。 增加 时间戳字段。 发送者 在每次发送的时候。 在tcp包头里面带上发送时候的时间戳。 当接收者接收的时候,在ACK应答中除了TCP包头中带自己此时发送的时间戳,并且把收到的时间戳附加在后面。也就是说ACK包中有两个时间戳字段。结构如下:
那我们接下来一个个分析tcp_tw_reuse是如何解决TIME_WAIT的两个问题的
tcp_tw_reuse 使用有三个条件:
1、必须开启 timestamp,通过 net.ipv4.tcp_timestamp 参数设置, linux 2.6 后缺省是打开的;
2、必须客户端和server同时支持 timestamp. 在连接握手阶段协商:当一方不开启时,两方都将停用timestamps。比如client端发送的SYN包中带有timestamp选项,但server端并没有开启该选项。则回复的SYN-ACK将不带timestamp选项,同时client后续回复的ACK也不会带有timestamp选项。当然,如果client发送的SYN包中就不带timestamp,双向都将停用timestamp。
3、 tcp_tw_reuse 只对outgoing connections 有效。也就是发起连接方 client 有效。 server端产生新的连接是不会复用 TIME_WAIT 资源
4、tcp_tw_recycle
tcp_tw_recycle自 Linux内核4.12版以来,已被弃用, 大家可以放心的不用了
tcp_tw_recycle 也是借助 timestamp机制。顾名思义, tcp_tw_reuse 是复用 端口,并不会减少 TIME-WAIT 数量。你去查询机器上TIME-WAIT 数量,还是 几千几万个,这点对有强迫症的同学感觉很不舒服。tcp_tw_recycle 是 提前 回收 TIME-WAIT资源。会减少 机器上 TIME-WAIT 数量。
tcp_tw_recycle 工作原理是。
动态缩小TIME-WAIT 时间, 不再是 2*MSL时间回收来回收TIME-WAIT资源,而是根据 RTO(Retransmission TimeOut)即重传超时时间, 这个时间根据一套特定算法来动态计算,当TIME-WAIT 停留时间大于 RTO。系统释放资源。 这招可以减少TIME-WAIT 数量
为了解决TIME-WAIT 收到不相关连接数据包的问题, 内核会纪录 TIME-WAIT 状态下 最后一次 收到包的时间戳,和ip地址等信息。(注意是IP地址没有端口信息哦)。如果收到连接SYN包(注意只在连接时候检测哦),先检查remote IP 有没有 相关的 TIME-WAIT状态,如果有则比较时间戳,如果时间戳比最后一次收到时间戳还要小,则这个包被认为是延迟包,丢弃掉。
存在问题: 一般情况下我们不建议使用tcp_tw_recycle , 因为它在 存在 NAT 网关的时候。 会出问题。NAT是地址共享, 而 tcp_tw_recycle 机制下恰恰又是根据ip纪录时间戳信息的。在 NAT下,多台机器上client。 对于server 可能是同一个IP。由于客户端的时间戳可能不一致。会导致连接不上问题。
NAT网络在国内使用非常普遍,家庭网络基本上NAT网络, N个设备共享一个IP地址。 公司办公网基本上也是如此。