问题描述：

在FullNAT在使用过程中，在开启SYNProxy的情况下，采用CURL去连接某个URL，会有偶尔卡顿一下，命令如下：

for i in `seq 1 10000`;do curl -o '/dev/null' -w "%{time_total}:%{time_connect}:%{time_appconnect}:%{time_starttransfer}\n" http://192.168.1.100 >> fullnat.txt ; done
100 582 100 582 0 0 54356 0 --:--:-- --:--:-- --:--:-- 58200
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 582 100 582 0 0 54586 0 --:--:-- --:--:-- --:--:-- 58200
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
以上命令偶尔会出现6s左右的超时等待。这个事情很神奇，为什么是6s呢，不是其他数字呢，如果是丢包的话，时间为什么这么固定呢，猜测这可能跟程序的实现有关系？

抓包复现：

我们在FullNAT机器和RealServer机器同时抓包。如下图：

第一张图是在fullnat机器上抓的，是从client到fullnat的包，第二张图在real server上抓的，是从fullnat到real server的包，从图中可以看出，从xx.xx.116.25到xx.xx.48.24，xx.xx.116.25是client，xx.xx.48.24为fullnat的vip,从第一张图中看出，完成了三次握手以后，client就开始请求数据包，但是请求数据包一直没有回应，在超时以后一直进行重发。难道是请求数据包时丢了？我们从real server上的抓包情况可以得到结果。client从03秒(抓包机器时间设置相差3分钟，单秒数是对的)开始发送数据包，但是real server从09秒时才开始3次握手建立连接。建立连接以后，并且将重发的包又转发了一遍。那么，我们从二张图中得出，导致延迟的原因是fullnat和real server建立连接的过程中，第一个syn包丢了或者没有送出来，才导致了这6秒的延时，那么为什么是6s呢，这得从fullnat代码中查看，经过代码搜索，终于找到了蛛丝马迹。
在ip_vs_proto_tcp.c文件中：

1158 int sysctl_ip_vs_tcp_timeouts[IP_VS_TCP_S_LAST + 1] = {
1159 [IP_VS_TCP_S_NONE] = 2 * HZ,
1160 [IP_VS_TCP_S_ESTABLISHED] = 90 * HZ,
1161 [IP_VS_TCP_S_SYN_SENT] = 3 * HZ,
1162 [IP_VS_TCP_S_SYN_RECV] = 30 * HZ,
1163 [IP_VS_TCP_S_FIN_WAIT] = 3 * HZ,
1164 [IP_VS_TCP_S_TIME_WAIT] = 3 * HZ,
1165 [IP_VS_TCP_S_CLOSE] = 3 * HZ,
1166 [IP_VS_TCP_S_CLOSE_WAIT] = 3 * HZ,
1167 [IP_VS_TCP_S_LAST_ACK] = 3 * HZ,
1168 [IP_VS_TCP_S_LISTEN] = 2 * 60 * HZ,
1169 [IP_VS_TCP_S_SYNACK] = 30 * HZ,
1170 [IP_VS_TCP_S_LAST] = 2 * HZ,
1171 };
1161行中的IP_VS_TCP_S_SYN_SENT代表了当fullnat和real server 的第一syn包发送失败以后超时重传的时间,如果synproxy在第二个三次握手时，第一个syn包发送失败或者被丢弃，重发的时间间隔为3s，这就解释了为什么是超时6s,估计是fullnat发送了3次syn包，但是前两次都丢弃了，或者fullnat前两个根本没有发包。从抓包的结果来看，fullnat确实没有发送前2个包，我们进一步在fullnat中打日志查看。在ip_vs_conn.c文件中，对超时的连接有处理：

881 static void ip_vs_conn_expire(unsigned long data)
...
901 /*
902 * Retransmit syn packet to rs.
903 * We just check syn_skb is not NULL, as syn_skb
904 * is stored only if syn-proxy is enabled.
905 */
906 spin_lock(&cp->lock);
907 if (cp->syn_skb != NULL && atomic_read(&cp->syn_retry_max) > 0) {
908 atomic_dec(&cp->syn_retry_max);
909 if (cp->packet_xmit) {
910 tmp_skb = skb_copy(cp->syn_skb, GFP_ATOMIC);
911 cp->packet_xmit(tmp_skb, cp, pp);
912 }
913 /* statistics */
914 IP_VS_INC_ESTATS(ip_vs_esmib, SYNPROXY_RS_ERROR);
915 spin_unlock(&cp->lock);
916 goto expire_later;
917 }
918 spin_unlock(&cp->lock);
Read More →