畅谈linux下TCP（上）

tcp 协议 是互联网中最常用的协议 ， 开发人员基本上天天和它打交道，对它进行深入了解。 可以帮助我们排查定位bug和进行程序优化。下面我将就TCP几个点做深入的探讨

客户端：收到 ack 后 分配连接资源。 发送数据

服务器 : 收到 syn 后立即 分配连接资源

客户端：收到ACK， 立即分配资源

服务器：收到ACK， 立即分配资源

既然三次握手也不是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值

Recv-Q 是accept 队列当前个数， Send-Q 设置最大值

这种SYN洪水攻击是一种常见攻击方式，就是利用半连接队列特性，占满syn 队列的 资源，导致 client无法连接上。

解决方案:

为什么不像握手那样合并成三次挥手? 因为和刚开始连接情况，连接是大家都从0开始， 关闭时有历史包袱的。server(被动关闭方) 收到 client(主动关闭方) 的关闭请求FIN包。 这时候可能还有未发送完的数据，不能丢弃。 所以需要分开。事实可能是这样

当然，在没有待发数据，并且允许 Delay ACK 情况下， FIN-ACK合并还是非常常见的事情，这是三次挥手是可以的。

同上

CLOSE_WAIT 是被动关闭方才有的状态 。

被动关闭方 [收到 FIN 包 发送 ACK 应答] 到 [发送FIN， 收到ACK ] 期间的状态为 CLOSE_WAIT， 这个状态仍然能发送数据。 我们叫做 半关闭 , 下面用个例子来分析:

这个是我实际生产环境碰到的一个问题，长连接会话场景，server端收到client的rpc call 请求1，处理发现请求包有问题，就强制关闭结束这次会话， 但是 因为client 发送 第二次请求之前，并没有去调用recv，所以并不知道 这个连接被server关闭， 继续发送 请求2 ， 此时是半连接，能够成功发送到对端机器，但是recv结果后，遇到连接已经关闭错误。

如果 client 和 server 恰好同时发起关闭连接。这种情况下，两边都是主动连接，都会进入 TIME_WAIT状态

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、选取一个时间戳小于当前时间戳； 用来解决端口不足的尴尬。

现在端口可以复用了，看看如何面对前面TIME_WAIT 那两种问题。 我们仔细回顾用一下前面两种问题。 都是在新建连接中收到老连接的包导致的问题 ， 那么如果我能在新连接中识别出此包为非法包，是不是就可以丢掉这些无用包，解决问题呢。

需要实现这些功能，需要扩展一下tcp 包头。 增加 时间戳字段。 发送者 在每次发送的时候。 在tcp包头里面带上发送时候的时间戳。 当接收者接收的时候，在ACK应答中除了TCP包头中带自己此时发送的时间戳，并且把收到的时间戳附加在后面。也就是说ACK包中有两个时间戳字段。结构如下:

那我们接下来一个个分析tcp_tw_reuse是如何解决TIME_WAIT的两个问题的

4、tcp_tw_recycle

tcp_tw_recycle 也是借助 timestamp机制。顾名思义， tcp_tw_reuse 是复用 端口，并不会减少 TIME-WAIT 数量。你去查询机器上TIME-WAIT 数量，还是 几千几万个，这点对有强迫症的同学感觉很不舒服。tcp_tw_recycle 是 提前 回收 TIME-WAIT资源。会减少 机器上 TIME-WAIT 数量。

tcp_tw_recycle 工作原理是。

TCP/IP 的分层管理

TCP/IP 协议按照层次分为 4 层：应用层、传输层、网络层、数据链路层。 对于分层这个概念，大家一定不陌生，比如我们的分布式架构体系中会分为业务层、服务层、基础支撑层。比如docker，也是基于分层来实现。所以我们会发现，复杂的程序都需要分层，这个是软件设计的要求，每一层专注于当前领域的事情。如果某些地方需要修改，我们只需要把变动的层替换掉就行，一方面改动影响较少，另一方面整个架构的灵活性也更高。 最后，在分层之后，整个架构的设计也变得相对简单了。

分层负载

了解了分层的概念以后，我们再去理解所谓的二层负载、三层负载、四层负载、七层负载就容易多了。

一次 http 请求过来，一定会从应用层到传输层，完成整个交互。只要是在网络上跑的数据包，都是完整的。可以有下层没上层，绝对不可能有上层没下层。

二层负载

二层负载是针对 MAC，负载均衡服务器对外依然提供一个 VIP（虚 IP），集群中不同的机器采用相同 IP 地址，但是机器的 MAC 地址不一样。当负载均衡服务器接受到请求之后，通过改写报文的目标 MAC 地址的方式将请求转发到目标机器实现负载均衡

二层负载均衡会通过一个虚拟 MAC 地址接收请求，然后再分配到真实的 MAC 地址

三层负载均衡

三层负载是针对 IP，和二层负载均衡类似，负载均衡服务器对外依然提供一个 VIP（虚 IP），但是集群中不同的机器采用不同的 IP 地址。当负载均衡服务器接受到请求之后，根据不同的负载均衡算法，通过 IP 将请求转发至不同的真实服务器

三层负载均衡会通过一个虚拟 IP 地址接收请求，然后再分配到真实的 IP 地址

四层负载均衡

四层负载均衡工作在 OSI 模型的传输层，由于在传输层，只有 TCP/UDP 协议，这两种协议中除了包含源 IP、目标 IP 以外，还包含源端口号及目的端口号。四层负载均衡服务器在接受到客户端请求后，以后通过修改数据包的地址信息（IP+端口号）将流量转发到应用服务器。

四层通过虚拟 IP + 端口接收请求，然后再分配到真实的服务器

七层负载均衡

七层负载均衡工作在 OSI 模型的应用层，应用层协议较多，常用 http、radius、dns 等。七层负载就可以基于这些协议来负载。这些应用层协议中会包含很多有意义的内容。比如同一个Web 服务器的负载均衡，除了根据 IP 加端口进行负载外，还可根据七层的 URL、浏览器类别来决定是否要进行负载均衡

比如：在nginx层做7层均衡，让一个uid的请求尽量落到同一个机器上

---