部分 TCP 内核参数彻底了解

tcp_max_syn_backlog
——————-
端口最大 backlog 内核限制。此参数限制 服务端应用程序 可以设置的端口最大 backlog 值 (对应于端口的 syn_backlog 和 backlog 队列长度)。动机是在内存有限的服务器上限制/避免应用程序配置超大 backlog 值而耗尽内核内存。如果应用程序设置 backlog 大于此值，操作系统将自动将之限制到此值。

tcp_abort_on_overflow
———————
当 tcp 建立连接的 3 路握手完成后，将连接置入 ESTABLISHED 状态并交付给应用程序的 backlog 队列时，会检查 backlog 队列是否已满。若已满，通常行为是将连接还原至 SYN_ACK 状态，以造成 3 路握手最后的 ACK 包意外丢失假象 —— 这样在客户端等待超时后可重发 ACK —— 以再次尝试进入 ESTABLISHED 状态 —— 作为一种修复/重试机制。如果启用 tcp_abort_on_overflow 则在检查到 backlog 队列已满时，直接发 RST 包给客户端终止此连接 —— 此时客户端程序会收到 104 Connection reset by peer 错误。

警告：启用此选项可能导致高峰期用户访问体验到 104: Connection reset by peer 或 白屏 错误(视浏览器而定)。在考虑启用此选项前应先设法优化提高 服务端应用程序 的性能，使之能更快 接管、处理 连接。

tcp_syncookies
————–
在 tcp 建立连接的 3 路握手过程中，当服务端收到最初的 SYN 请求时，会检查应用程序的 syn_backlog 队列是否已满。若已满，通常行为是丢弃此 SYN 包。若未满，会再检查应用程序的 backlog 队列是否已满。若已满并且系统根据历史记录判断该应用程序不会较快消耗连接时，则丢弃此 SYN 包。如果启用 tcp_syncookies 则在检查到 syn_backlog 队列已满时，不丢弃该 SYN 包，而改用 syncookie 技术进行 3 路握手。

警告：使用 syncookie 进行握手时，因为该技术挪用了 tcp_options 字段空间，会强制关闭 tcp 高级流控技术而退化成原始 tcp 模式。此模式会导致 封包 丢失时 对端 要等待 MSL 时间来发现丢包事件并重试，以及关闭连接时 TIME_WAIT 状态保持 2MSL 时间。该技术应该仅用于保护 syn_flood 攻击。如果在正常服务器环境中服务器负载较重导致 syn_backlog 和 backlog 队列满时，应优化 服务端应用程序 的 负载能力，加大应用程序 backlog 值。不过，所幸该参数是自动值，仅在 syn_backlog 队列满时才会触发 (在队列恢复可用时此行为关闭)。

NOTE 1:
服务端应用程序设置端口 backlog 值，内核理论上将允许该端口最大同时接收 2*backlog 个并发连接”请求”(不含已被应用程序接管的连接) —— 分别存放在 syn_backlog 和 backlog 队列 —— 每个队列的长度为 backlog 值。syn_backlog 队列存储 SYN_ACK 状态的连接，backlog 则存储 ESTABLISHED 状态但尚未被应用程序接管的连接。

NOTE 2:
syn_backlog 队列实际上是个 hash 表，并且 hash 表大小为 2 的次方。所以实际 syn_backlog 的队列长度要 略大于 应用程序设置的 backlog 值 —— 取对应 2 的次方值。

NOTE 3:
当 backlog 值较小，而高峰期并发连接请求超高时，tcp 建立连接的 三路握手 网络时延将成为瓶颈 —— 并发连接超高时，syn_backlog 队列将被充满而导致 `can’t connect` 错误。此时，再提高服务端应用程序的吞吐能力已不起作用，因为连接尚未建立，服务端应用程序并不能接管和处理这些连接 —— 而是需要加大 backlog 值 (syn_backlog 队列长度) 来缓解此问题。

NOTE 4:
启用 syncookie 虽然也可以解决超高并发时的 `can’t connect` 问题，但会导致 TIME_WAIT 状态 fallback 为保持 2MSL 时间，高峰期时会导致客户端无可复用连接而无法连接服务器 (tcp 连接复用是基于 四元组值必须不相同，就访问同一个目标服务器而言， 三元组值不变，所以此时可用的连接数限制为仅 src_port 所允许数目，这里处于 TIME_WAIT 状态的相同 src_port 连接不可复用。Linux 系统甚至更严格，只使用了 三元组…)。故不建议依赖 syncookie。

最近在开发一款多线程音乐下载播放器的服务端.

包括tcp应用服务器和服务容器的代码.

刚开始进行压力测试的时候频繁出现Connection reset by peer异常,

并且成功的连接数不超过50个.

google一下发现

出现Connection reset by peer比较常见的原因是：

服务器的并发连接数超过了其承载量，服务器会将其中一些连接Down掉；

.连接被防火樯或proxy中断，或防火墙和代理设置不当。

 

对于第一种原因,

回想起tcp/ip详解第一卷协议中提到过:

bsd的socket的tcp连接队列的默认长度是5,

 

backlog   用于在TCP层接收链接的缓冲池的最大个数，这个个数可在应用层中的listen函数里设置，当客户链接请求大于这个个数(缓冲池满），其它的未进入链接缓冲池的客户端在tcp层上tcp模块会自动重新链接，直到超时（大约57秒后）

 

我们的应用层的链接完成是要从tcp层的链接缓冲池中移出一个（accept函数实现）

 

因此我在本机测试的时候,连接数超过50就报Connection reset by peer.

是因为连接数限制,操作系统(当前系统为win2k.)把超出的连接丢弃的原因.

我兴冲冲地把serversocket的backlog设置为200,可以支持

200个线程每休息2s发送一次请求,请求的等待时间为5s.

也就是大约每7s进行一次请求应答.

计算下来,1s能进行30次请求应答.

 

另外记录一下SO_LINGER

3.2 How do I control the amount of time a socket will linger before resetting?

When a socket wishes to terminate a connection it can "linger", allowing unsent data to be transmitted, or it can "reset" which means that all unsent data will be lost. You can explicitly set a delay before a reset is sent, giving more time for data to be read, or you can specify a delay of zero, meaning a reset will be sent as the java.net.Socket.close() method is invoked.

The socket option SO_LINGER controls whether a connection will be aborted, and if so, the linger delay. Use the java.net.Socket.setSoLinger method, which accepts as parameters a boolean and an int. The boolean flag will activate/deactivate the SO_LINGER option, and the int will control the delay time.

摘自 http://www.davidreilly.com/java/java_network_programming/

[syswatch@xikang-dmz-app5 ~]$ /sbin/sysctl -a | grep _syn

error: permission denied on key 'kernel.cad_pid'

net.ipv4.tcp_max_syn_backlog = 1024

net.ipv4.tcp_syncookies = 1

net.ipv4.tcp_synack_retries = 5

net.ipv4.tcp_syn_retries = 5

error: permission denied on key 'kernel.cap-bound'

Linux中查看socket状态： cat /proc/net/sockstat…

Linux中查看socket状态：
cat /proc/net/sockstat #（这个是ipv4的）

sockets: used 137 TCP: inuse 49 orphan 0 tw 3272 alloc 52 mem 46 UDP: inuse 1 mem 0 RAW: inuse 0 FRAG: inuse 0 memory 0 

说明：
sockets: used：已使用的所有协议套接字总量
TCP: inuse：正在使用（正在侦听）的TCP套接字数量。其值≤ netstat –lnt | grep ^tcp | wc –l

TCP: orphan：无主（不属于任何进程）的TCP连接数（无用、待销毁的TCP socket数）

TCP: tw：等待关闭的TCP连接数。其值等于netstat –ant | grep TIME_WAIT | wc –l

TCP：alloc(allocated)：已分配（已建立、已申请到sk_buff）的TCP套接字数量。其值等于netstat –ant | grep ^tcp | wc –l

TCP：mem：套接字缓冲区使用量（单位不详。用scp实测，速度在4803.9kB/s时：其值=11，netstat –ant 中相应的22端口的Recv-Q＝0，Send-Q≈400）

UDP：inuse：正在使用的UDP套接字数量
RAW：
FRAG：使用的IP段数量