问题背景生产环境与第三方相连时，丢包频繁发生。 具体现象可以表现为APP应用服务器未接收到消息，而抓取包则表示为RST
生产通信方式为https，APP应用前端有SSL和F5负载，业务入口有NAT转换，然后通过SSL卸载https，http请求经过F5负载均衡到两台APP应用服务。
问题分析错误地报告了由于消息链路有点长，启动的客户端没有收到来自服务端的回复，但服务端的表示没有收到交易，这只能进行分组处理
客户端错误分析unexpected end of flom server服务器意外文件退出
导致此问题的直接原因是返回的数据丢包导致了此错误。
可能有三个根本原因：
服务端程序代码有问题网络链路中的网络设备有故障，如SSL和F5。 如果网络安全策略的配置原因(如IP限制和恶意扫描拒绝)不符合安全策略，则数据包将被直接丢弃。 服务端代码有问题
如果是代码问题，那应该是特定的场景，会出现特定的情况，但该问题会随机发生，可能是时间和时间，而不是特定的情况。
网络链接设备问题
通过分组网链路设备接收到消息后，向后转发，但被向后拒绝
网络安全策略配置问题
这非常有可能，在某些情况下，服务端销毁了数据包，所以我们也从这个角度进行了详细调查
服务端情况分析服务端的APP应用没有对应消息录入的日志，但可以判断网络设备已经进行了传输，对应的问题应该出现在几个APP应用服务器的配置上，但与APP应用码无关
问题解决方案1、防火墙配置检查为了查询问题，直接关闭防火墙2，sysctl的ipv4相关参数net.IP v4.TCP _ tw _ recycle=1net.IP v4.TCP _ ttty
net.IP v4.TCP_tw_recycle=1net.IP v4.TCP _ timestamps=0.不同时打开TCP _ timestamps和TCP _ tw _ recycle的场景
全NAT下
FULL NAT在客户端请求VIP时，不仅替换了包的dst ip，还替换了包的src ip； 但是VIP
返回客户端时也替换了src ip
lvs后端是web服务器。
假设web服务器打开了两个参数： tcp的tcp_timestamps和tcp_tw_recycle。 那么，有以下情况
RFC1323包含以下说明：
anadditionalmechanismcouldbeaddedtothetcp，a per-hostcache of
thelasttimestampreceivedfromanyconnection.thisvaluecouldthen
beusedinthepawsmechanismtorejectoldduplicatesegmentsfrom
earlierincarnationsoftheconnection，if the timestamp clock can be
guaranteedtohavetickedatleastoncesincetheoldconnectionwas
open.thiswouldrequirethatthetime-waitdelayplusthertt
togethermustbeatleastonetickofthesender’stimestampclock.such
anextensionisnotpartoftheproposalofthisrfc。
TCP具有为每个连接缓存最新时间戳的行为，如果在后续请求中时间戳小于缓存的时间戳，则TCP将被视为无效，这可能意味着相应的数据包将被丢弃。 这意味着，同一源IP连接到同一目标端口的数据包的时间戳必须递增
Linux是否启用此行为取决于tcp_timestamps和tcp_tw_recycle。 tcp_timestamps在缺省情况下处于选中状态，因此打开tcp_tw_recycle时实际上会启用此行为。
目前，许多企业将LVS用于负载均衡。 通常是前面的LVS，后面的多个后端服务器。 这实际上是NAT，请求到达LVS后，修改地址数据并传输到后端服务器。
但是，时间戳数据保持不变。 对于后端服务器来说，请求的源地址是LVS的地址，web端口被复用，因此从后端服务器来看，来自原本不同客户端的请求经过LVS的传输
可能被视为同一连接，客户端可能时间不匹配，这会导致时间戳不一致，并丢弃后续数据包。
具体表示通常是客户端发送的SYN，但是服务端不对ACK作出响应，也可以在下面的命令中确认
认数据包不断被丢弃的现象注意点
tw_reuse，tw_recycle 必须在客户端和服务端timestamps 开启时才管用（默认打开），其实意思就是假如服务端和客户端两边有一边timestamps没开启。tw_reuse和tw_recycle都没啥作用tw_reuse 只对客户端起作用，开启后客户端在1s内回收。reuse就是重用time_wait的socket连接。 服务端同一个端口被连接理论上是没限制的。tw_recycle 对客户端和服务器同时起作用，开启后在 3.5*RTO 内回收，RTO 200ms~ 120s 具体时间视网络状况。 内网状况比tw_reuse 稍快，公网尤其移动网络大多要比tw_reuse慢，优点就是能够回收服务端的TIME_WAIT数量
对于客户端
作为客户端因为有端口65535问题，TIME_OUT过多直接影响处理能力，打开tw_reuse 即可解决，不建议同时打开tw_recycle，帮助不大。tw_reuse 帮助客户端1s完成连接回收，基本可实现单机6w/s请求，需要再高就增加IP数量吧。如果内网压测场景，且客户端不需要接收连接，同时tw_recycle 会有一点点好处。对于服务端
打开tw_reuse无效，因为是客户端连接web服务器，服务端肯定不会重用socket去主动连接客户端。这个参数服务器一般用不到，除非web服务器又作为客户端去连接后端数据库才用到。但是web服务器作为客户端连接数据库达到6万端口的限制时你的数据库早承受不了压力瘫痪了。一般数据库5000连接数就已经很高了。
tw_resue这个参数，只有客户端用得到。意思就是重用处于time_wait的socket连接。
线上环境 tw_recycle 不要打开 服务器处于NAT 负载后，或者客户端处于NAT后（这是一定的事情，基本公司家庭网络都走NAT）；
公网服务打开就可能造成部分连接失败，内网的话到时可以视情况打开； 有些负载均衡设备会把timestamp
都给清空，后端web服务器开启不开启tw_recycle都无所谓了。
服务器TIME_WAIT 高怎么办
服务器time_wait不用担心，因为我是服务端，是客户端很多IP和端口主动连接我的一个端口，比如连接我的80端口。很可能出现一种情况就是虽然我机器上有10万个time_wait连接。但是我的端口才用到一个80端口。
不像客户端有端口限制，处理大量TIME_WAIT Linux已经优化很好了，每个处于TIME_WAIT 状态下连接内存消耗很少，
而且也能通过tcp_max_tw_buckets = 262144 配置最大上限，现代机器一般也不缺这点内存。
总结下来
总之，生产中，服务器不管有没有在nat设备后面.
tcp_tw_recycle不开启就行了。默认就是不开启的状态，值为0
tcp_timestamps保持默认开启就行了，值为1
tcp_tw_reuse.客户端最好开启。负载均衡设备连接web服务器时，辅助均衡设备也尽量开启
关于服务器端出现大量time_wait，有些人会问，我是web服务器端，为什么会出现客户端那种time_wait。
其实关于time_wait，它是出现在主动请求关闭连接的那一段。 服务器主动关闭http的连接。它就转变为了客户端。
发起断开连接这个动作，不是说就一定是客户端发起断开的。很多时候都是服务器端先发起断开连接操作。比如很多http服务器，短连接。很多时候服务器主动断开。
服务出现tcp连接问题可以先查看下下面，看看是否有很多，很多时候就是开启了tcp_tw_recycle导致的
参考：https://www.cnblogs.com/nmap/p/6435057.html