这个参数值得是client发送SYN如果server端不回复的话，重传SYN的次数。对我们的直接影响呢就是connet建立连接时的超时时间。当然Java通过一些C原生系统调用的组合使得我们可以进行超时时间的设置。在Linux里面默认设置是5,下面给出建议值3和默认值5之间的超时时间。
tcp_syn_retries timeout1 min(so_sndtimeo,3s)
2 min(so_sndtimeo,7s)
3 min(so_sndtimeo,15s)
4 min(so_sndtimeo,31s)
5 min(so_sndtimeo,63s)
下图给出了，重传和超时情况的对应图:
当然了，不同内核版本的超时时间可能不一样，因为初始RTO在内核小版本间都会有细微的变化。所以，有时候在抓包时候可能会出现（3,6,12......)这样的序列。当然Java的API有超时时间: java: // 函数调用中携带有超时时间 public void connect(SocketAddress endpoint, int timeout) ;
所以，对于Java而言，这个内核参数的设置没有那么重要。但是，有些代码可能会有忘了设置timeout的情况，例如某个版本的Kafka就是，所以它在我们一些混沌测试的情况下，容灾恢复的时间会达到一分多钟，主要时间就是卡在connect上面-_-!，而这时我们的tcp_syn_retries设置的是5，也即超时时间63s。减少这个恢复时间的手段就是:
echo 3 > /proc/sys/net/ipv4/tcp_syn_retries tcp_retries2tcp_retries2这个参数表面意思是在传输过程中tcp的重传次数。但在某个版本之后Linux内核仅仅用这个tcp_retries2来计算超时时间，在这段时间的重传次数纯粹由RTO等环境因素决定，重传超时时间在5/15下的表现为:
tcp_retries2 对端无响应5 25.6s-51.2s根据动态rto定
15 924.6s-1044.6s根据动态rto定
如果我们在应用层设置的Socket所有ReadTimeout都很小的话(例如3s),这个内核参数调整是没有必要的。但是，笔者经常发现有的系统，因为一两个慢的接口或者SQL，所以将ReadTimeout设的很大的情况。
平常这种情况是没有问题的，因为慢请求频率很低，不会对系统造成什么风险。但是，物理机突然宕机时候的情况就不一样了，由于ReadTimeOut设置的过大，导致所有落到这台宕机的机器都会在min(ReadTimeOut,(924.6s-1044.6s)(Linux默认tcp_retries2是15))后才能从read系统调用返回。假设ReadTimeout设置了个5min，系统总线程数是200，那么只要5min内有200个请求落到宕机的server就会使A系统失去响应！
但如果将tcp_retries2设置为5,那么超时返回时间即为min(ReadTimeOut 5min,25.6-51.2s),也就是30s左右，极大的缓解了这一情况。 echo 5 > /proc/sys/net/ipv4/tcp_retries2
但是针对这种现象，最好要做资源上的隔离,例如线程上的隔离或者机器级的隔离。
golang的goroutine调度模型就可以很好的解决线程资源不够的问题，但缺点是goroutine里面不能有阻塞的系统调用，不然也会和上面一样，但仅仅对于系统之间互相调用而言，都是非阻塞IO,所以golang做微服务还是非常Nice的。当然了我大Java用纯IO事件触发编写代码也不会有问题，就是对心智负担太高-_-!
物理机突然宕机和进程宕不一样值得注意的是，物理机宕机和进程宕但内核还存在表现完全不一样。
仅仅进程宕而内核存活，那么内核会立马发送reset给对端，从而不会卡住A系统的线程资源。 tcp_slow_start_after_idle
还有一个可能需要调整的参数是tcp_slow_start_after_idle，Linux默认是1，即开启状态。开启这个参数后，我们的TCP拥塞窗口会在一个RTO时间空闲之后重置为初始拥塞窗口(CWND)大小，这无疑大幅的减少了长连接的优势。对应Linux源码为:
static void tcp_event_data_sent(struct tcp_sock *tp, struct sk_buff *skb, struct sock *sk){ // 如果开启了start_after_idle,而且这次发送的时间-上次发送的时间>一个rto，就重置tcp拥塞窗口 if (sysctl_tcp_slow_start_after_idle && (!tp->packets_out && (s32)(now - tp->lsndtime) > icsk->icsk_rto)) tcp_cwnd_restart(sk, __sk_dst_get(sk)); }