分析SYN flooding问题时，需要知道当前有多少SYN_RECV状态的连接，总结了几种方法，供以后参考使用。
1、ss -s 这个命令最快，几乎是立即得到结果，但synrecv一直显示为0，所以没法用。除此之外，其它信息是完整的。
[code]
# ss -s
Total: 30234 (kernel 30462)
TCP: 115175 (estab 30148, closed 77237, orphaned 7771, synrecv 0, timewait 77237/0), ports 1139
Transport Total IP IPv6
* 30462 - -
RAW 0 0 0
UDP 1 1 0
TCP 37938 37938 0
INET 37939 37939 0
FRAG 0 0 0
[/code]
nginx服务器的/var/log/message里出现这个问题
[code]
kernel: possible SYN flooding on port 80. Sending cookies.
[/code]
sys + cookies 去查ip-sysctl文档（https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt）
找到这个东西
[code]
tcp_syncookies - BOOLEAN
Only valid when the kernel was compiled with CONFIG_SYN_COOKIES
Send out syncookies when the syn backlog queue of a socket
overflows. This is to prevent against the common 'SYN flood attack'
Default: 1
Note, that syncookies is fallback facility.
It MUST NOT be used to help highly loaded servers to stand
against legal connection rate. If you see SYN flood warnings
in your logs, but investigation shows that they occur
because of overload with legal connections, you should tune
another parameters until this warning disappear.
See: tcp_max_syn_backlog, tcp_synack_retries, tcp_abort_on_overflow.
syncookies seriously violate TCP protocol, do not allow
to use TCP extensions, can result in serious degradation
of some services (f.e. SMTP relaying), visible not by you,
but your clients and relays, contacting you. While you see
SYN flood warnings in logs not being really flooded, your server
is seriously misconfigured.
If you want to test which effects syncookies have to your
network connections you can set this knob to 2 to enable
unconditionally generation of syncookies.
[/code]
文中提到了另外三个配置：tcp_max_syn_backlog, tcp_synack_retries, tcp_abort_on_overflow
今天有QA童鞋反馈，mac下的chrome访问https服务时提示证书乱码，无法打开。
chrome的版本是：54.0.2840.59 (64-bit)
让QA童鞋访问https的另一个环境，却是正常的。
对比了一下两个环境的证书，另一个环境是tenging，不支持8192位的证书，所以用的是4096的。
无法访问的是openresty，证书是8192，怀疑是此问题。
把openresty下的证书换成4096位的以后，这个童鞋可以正常访问了。
目前的结果来看，8192位的证书没法用：tenging不支持，mac下的chrome不支持。还是先用4096的吧。
备忘之。
今天iOS的童鞋反馈连接出错问题：
Error Domain=NSURLErrorDomain Code=-1005 “The network connection was lost.”
看到有建议说调服务的keepalive参数，让范童鞋配合搞了一下，果然有收获：
目前的配置是：
nginx.conf
[code]
keepalive_timeout 65;
[/code]
内核配置
[code]
# cat /proc/sys/net/ipv4/tcp_keepalive_time
30
[/code]
两个值不一致，目测应该有问题。