从系统cache中查看 tcp_metrics item

从系统cache中查看 tcp_metrics item
ip tcp_metrics show
  tcp_metrics会记录下之前已关闭TCP连接的状态，包括发送端CWND和ssthresh，如果之前网络有一段时间比较差或者丢包比较严重，就会导致TCP的ssthresh降低到一个很低的值，这个值在连接结束后会被tcp_metrics cache 住，在新连接建立时，即使网络状况已经恢复，依然会继承 tcp_metrics 中cache 的一个很低的ssthresh 值，对于rrt很高的网络环境，新连接经历短暂的“慢启动”后(ssthresh太小)，随即进入缓慢的拥塞控制阶段（rt太高，CWND增长太慢），导致连接速度很难在短时间内上去。而后面的连接，需要很特殊的场景之下(比如，传输一个很大的文件)才能将ssthresh 再次推到一个比较高的值更新掉之前的缓存值，因此很有很能在接下来的很长一段时间，连接的速度都会处于一个很低的水平。

TCP Metrics是Per-Host Per-Host的。也就是说，TCP Metrics表项应该是基于<源IP,目的IP>二元组的。从一台主机的角度，到达另一个特定地址主机的网络链路状况应该是被两台主机之间的所有连接所共享的。

内核使用tcp_metrics_block表示一条Metrics表项，这些表项根据<源IP,目的IP>组织在tcp_metrics_hash冲突链表表中，记录的值保存在内部tcpm_vals数组

当新建TCP连接时，内核使用下面的接口来为TCP套接字设置TCP Metrics指导下的参数

void tcp_init_metrics(struct sock *sk)

tcp_rcv_synsent_state_process --> tcp_finish_connect --> tcp_init_metrics --> tcp_get_metrics --> tcpm_new(optional)
tcp_rcv_state_process --> case TCP_SYN_RECV  ---->tcp_init_transfer --> tcp_init_metrics

 tcpm_new函数仅在第一次链接建立的时候调用，后续新建的tcp链接都可以使用曾经创建的tcp_metric

当某条TCP连接收的运行参数发生变化时，比如重新计算RTT了，内核会使用下面的接口来更新它对应的TCP Metrics表项。切记，TCP Metrics表项是Per-Host的，因此，多条TCP连接的套接字可能会更新同一条表项。

void tcp_update_metrics(struct sock *sk)

内核提供ip-tcp_metrics  ip tcp_metrics show命令查看主机上的TCP Metrics表项.

记录经典问题：No response to some SYN packets when timestamps are enabled    NAT设备+tcp_tw_recycle

或者搜索 开启tcp_tw_recycle内核参数在NAT环境会丢包 等 会有很多这样的问题

tcp_tw_recycle机制是用于内核快速回收TIME_WAIT状态的套接字。但是当网络中存在NAT设备时，该机制反而可能会导致NAT设备背后的客户端难以连接上服务器。

  导致这些问题的原因是服务器收到的SYN报文中携带的时间戳早于之前已经收到的FIN报文的时间戳，于是服务器认为该SYN报文是由于网络阻塞迟到的旧连接的SYN报文的重传，于是拒绝恢复SYN-ACK；传输链路上存在NAT设备。而缓存FIN报文时间戳的TCP Metrics是Per-Destination  Per-Host的，在有NAT的环境中，服务器看到的Destination是NAT设备，它看不到NAT设备背后还有多大的内部网络，内部网路的每台主机上无法保证SYN报文的时间戳递增。

不过后面新版本内核 把此功能去掉了linux 4.12 **tcp: remove tcp_tw_recycle**

通过netstat -s命令查看网络统计时，可以发现每次复现出TCP握手失败后，如下的一行统计值都会对应增长。linux 4.12 后删除了

[root]# netstat -s | grep timestamp
    10024 packets rejects in established connections because of timestamp