<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>浮山狼de博客 &#187; system</title>
	<atom:link href="https://www.fushanlang.com/tag/system/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.fushanlang.com</link>
	<description>next station - 下一站，活在当下，且行且思</description>
	<lastBuildDate>Sat, 29 Nov 2014 15:14:11 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=4.2.5</generator>
	<item>
		<title>sysctl.conf网络内核参数说明(转)</title>
		<link>https://www.fushanlang.com/sysctl-conf-network-kernel-parameter-description-rpm-2340/</link>
		<comments>https://www.fushanlang.com/sysctl-conf-network-kernel-parameter-description-rpm-2340/#comments</comments>
		<pubDate>Fri, 13 Dec 2013 03:44:05 +0000</pubDate>
		<dc:creator><![CDATA[fushanlang]]></dc:creator>
				<category><![CDATA[linux]]></category>
		<category><![CDATA[system]]></category>

		<guid isPermaLink="false">http://www.fushanlang.com/blog/?p=2340</guid>
		<description><![CDATA[<p>下面是我的理解，可能有误，仅供参考。</p> <p>要调优，三次/四次握手必须烂熟于心。</p> <p>client                  server (SYN_SENT)      —&#62;  (SYN_RECV) (ESTABLISHED)   &#60;— —&#62;  (ESTABLISHED)</p> <p>client(主动)            server (FIN_WAIT_1)    —&#62;    (CLOSE_WAIT) (FIN_WAIT_2)    &#60;— (TIME_WAIT)     &#60;—    (LAST_ACK) —&#62;    (CLOSED)</p> <p>大家熟知的 SYN flooding/SYN spoofing 就是在 SYN_RECV 的状态下发起的进攻。这种由于 TCP/IP 协议引起的缺陷只能防治而不好根治，除非换了 TCP/IP。通过下面的方式，可以在一定程度上缓解 DDOS 攻击。</p> 增大半连接的队列，即 backlog queue 人工干预以减少 SYS_RECV 的时间，可以降低第一个重传包的时间或者减少重传的次数 <p>检测 SYN 攻击，可以使用 netstat 命令查看当前的连接类型以及连接数目,如果发现有大量的 SYN_RECV,就值得怀疑了: $ netstat -tuna &#124; grep <span style="color:#777"> . . . &#8594; Read More: <a href="https://www.fushanlang.com/sysctl-conf-network-kernel-parameter-description-rpm-2340/">sysctl.conf网络内核参数说明(转)</a></span>]]></description>
				<content:encoded><![CDATA[<p>下面是我的理解，可能有误，仅供参考。</p>
<p>要调优，三次/四次握手必须烂熟于心。</p>
<p>client                  server<br />
(SYN_SENT)      —&gt;  (SYN_RECV)<br />
(ESTABLISHED)   &lt;—<br />
—&gt;  (ESTABLISHED)</p>
<p>client(主动)            server<br />
(FIN_WAIT_1)    —&gt;    (CLOSE_WAIT)<br />
(FIN_WAIT_2)    &lt;—<br />
(TIME_WAIT)     &lt;—    (LAST_ACK)<br />
—&gt;    (CLOSED)</p>
<p>大家熟知的 SYN flooding/SYN spoofing 就是在 SYN_RECV 的状态下发起的进攻。这种由于 TCP/IP 协议引起的缺陷只能防治而不好根治，除非换了 TCP/IP。通过下面的方式，可以在一定程度上缓解 DDOS 攻击。</p>
<ul>
<li>增大半连接的队列，即 backlog queue</li>
<li>人工干预以减少 SYS_RECV 的时间，可以降低第一个重传包的时间或者减少重传的次数</li>
</ul>
<p>检测 SYN 攻击，可以使用 netstat 命令查看当前的连接类型以及连接数目,如果发现有大量的 SYN_RECV,就值得怀疑了:<br />
<code>$ netstat -tuna | grep :80 | awk '{print $6}' | sort | uniq -c</code></p>
<p>或者可以通过 wget/curl 从远端实际来测试一下访问的速度：<br />
<code>$ time wget -O /dev/null www.example.com</code><br />
正常情况下，其 real time 在个位数(s)左右，如果出现长达数十秒乃至几百秒的情况，有可能是此类情况。</p>
<p>最简单的方式是通过 syncookie 实现，Linux 还实现了一种称作 SYN cookie 的机制，开启：<br />
<code># echo 1 &gt; /proc/sys/net/ipv4/tcp_syncookies</code></p>
<p>该机制会在服务器收到 SYN 请求后，构造一个带有 ISN(initial sequence number)的 SYN/ACK 包，该 ISN 称为 cookie，其实就是一个哈希。通过此就可以验证客户端的真实性了<br />
<strong>注意：</strong>SYN cookie 机制不会使用到 backlog queue，因此不必担心 queue 被填满然后服务器主动放弃连接。</p>
<p>使用了 SYN cookie 之后，在 /var/log/kern.log 会发现不少如下的 log，起作用了 <img src="https://s.w.org/images/core/emoji/72x72/1f609.png" alt="😉" class="wp-smiley" style="height: 1em; max-height: 1em;" /><br />
possible SYN flooding on port 80. Sending cookies</p>
<p>除了使用 syncookie，还可以修改 backlog queue 来达到目的。backlog queue 是一个用来处理在三次握手过程中带有 SYN 标志的包的数据结构，可以用来控制系统同时处理的最大连接，当达到该阈值后，接下来的请求会被系统丢弃。这需要系统开辟额外的内存来处理进来的包。如果处理的不好会导致系统内存耗尽，导致严重的性能问题。</p>
<p>tcp_max_syn_backlog 定义了 backlog queue 的半连接数量：<br />
<code># echo 90000 &gt; /proc/sys/net/ipv4/tcp_max_syn_backlog</code></p>
<p>当客户端发起 SYN 请求后，服务端会立刻发送 SYN+ACK 的回应，该次半连接会到 backlog queue 中，服务器会等待客户返回 ACK，如果在一段时间内没有应答，服务器会重新发送刚刚的 SYN+ACK，经历了几次还是没有回应后，服务器会主动断开此次半连接。<br />
我们就可以修改重发的次数来减少整个半连接的时间：<br />
<code># echo 3 &gt; /proc/sys/net/ipv4/tcp_synack_retries</code></p>
<p>——————————————————————————-<br />
|Value|    Time of retransmission      |         Total time         |<br />
——————————————————————————-<br />
|1       | in 3rd second                          |            9 seconds      |<br />
——————————————————————————-<br />
|2       | in 3rd and 9th second            |            21 seconds   |<br />
——————————————————————————-<br />
|3       | in 3rd, 9th and 21st second  |            45 seconds    |<br />
——————————————————————————-<br />
这张表格显示了不同重传次数消耗的总时间</p>
<p>上面属于 passive 连接，也就是客户端连接服务端，还有个相反的 active TCP connection 参数：<br />
<code># echo 3 &gt; /proc/sys/net/ipv4/tcp_syn_retries</code></p>
<p>tcp_fin_timeout 参数会通知 kernel 在 FIN_WAIT_2 状态 sockets 的存活时间，根据理解应该是 server 主动终止，像下面这样。</p>
<p>server                        client<br />
(FIN_WAIT_1)    —&gt;    (CLOSE_WAIT)<br />
(FIN_WAIT_2)    &lt;—<br />
(TIME_WAIT)     &lt;—    (LAST_ACK)<br />
—&gt;    (CLOSED)</p>
<p>当处于 CLOST_WAIT 的 client 有意(攻击)/无意(client 突然崩溃等)不发 fin 来继续时，server 会一直停留在 FIN_WAIT_2 状态，造成资源的浪费。<br />
可以适当的减小该时间：<br />
<code># echo 15 &gt; /proc/sys/net/ipv4/tcp_fin_timeout</code></p>
<p>跟 tcp_fin_timeout 相关的有 tcp_max_orphans 参数，表示没有跟任何用户文件相关联的 socket 最大个数，超出的将被内核丢弃。<br />
建议该参数只增加不减小，但增加也意味着内存的消耗增加：<br />
<code># echo 327680 &gt; /proc/sys/net/ipv4/tcp_max_orphans</code></p>
<p>相关的 tcp_orphans_retries 关闭本端 TCP 连接前的重试次数，默认 7，高负载的 webserver 建议可以减小。这里解释了设置为 0 的情况。</p>
<p>下面这三个参数一起解释：<br />
tcp_tw_recycle<br />
tcp_tw_reuse<br />
tcp_timestamps</p>
<p>其中 tcp_tw_recycle/tcp_tw_reuse 这两个官方的建议保持默认为 0，而 tcp_timestamps 这个参数在特定的情况开启会引起很严重的问题(via <a href="http://serverfault.com/questions/235965/why-would-a-server-not-send-a-syn-ack-packet-in-response-to-a-syn-packet">1</a>, <a href="http://serverfault.com/questions/307376/many-different-tcp-timestamps-through-nat-device-cause-server-to-drop-packets-p">2</a>)。</p>
<p>基本的情况就是，你的客户或者你的服务器在一个 NAT 后面，如果开启这个参数，会导致服务器能收到三次握手的 SYN 但是不会返回任何的 SYN+ACK，其结果是客户无法访问你的网站。可以通过 tcpdump 或者下面的这个查看：<br />
<code># netstat -s | grep timestamp</code></p>
<p>tcp_timestamps 是 tcp 协议中的一个扩展项，通过时间戳的方式来检测过来的包以防止 PAWS(Protect Against Wrapped  Sequence numbers)，可以提高 tcp 的性能，2.6 的内核默认是打开的。只要 client/server/nat/loadbalancer 不同时打开该选项就不会出现上面的问题。与之相关的包括 tcp_tw_recycle，如果 tcp_timestamps 和 tcp_tw_recycle 同时开启，就会开启时间戳选项，导致上面的问题。如果有上述的网络结构，比较合理的方式是禁用 tcp_tw_recyle 而开启 tcp_timestamps。禁用了 tcp_tw_recycle 其 TIME_OUT sockets 回收功能就没了，可以配合 tcp_tw_reuse 让 TIME_WAIT 降下来。</p>
<p>netdev_max_backlog 这个参数跟 TCP 的传输队列有关,发送队列长度是 txqueuelen ，netdev_backlog 则决定接收队列的长度。<br />
前者通过 ifconfig 命令改变：<br />
<code># ifconfig eth0 txqueuelen 10000</code><br />
对于高吞吐的网络而言，默认的 100 肯定是不够的，一个 rrt 为 120ms 的千兆以太网络，可以设置成 10000 以上的值。</p>
<p>对于接受端而言，需要修改的话就涉及到了 /proc/sys/net/core/netdev_max_backlog 了，如果接收包的速度大于内核能处理的速度，则需要队列来维持，此数值表示最大队列值。默认为 1000，如果超过该数值，会引起丢包，根据实际情况增大。</p>
<p>对于网络不是很好的情况，可以开启 tcp_sack 参数。该实现是 TCP 的一个选项，称为 Selective Acknowlegement(SACK)，默认开启，对于千兆网络可以关闭，能提高一定的性能。</p>
<p>keepalive 的情况，Linux 内置支持，只需要开启相应的内核参数就可以了，主要是下面三个：<br />
tcp_keepalive_time 表示 TCP 发出第一个 keepalive 信息之前等待的时间，默认为 7200<br />
tcp_keepalive_intvl keepalive 的时间间隔，默认是 75<br />
tcp_keepalive_probes 触发的次数，默认是 9</p>
<p>ip_local_port_range 128M 内存以上的机器默认是 32768 61000，可以进一步扩大 10240 65535，尽量不要使用 1024 周围的，避免冲突。</p>
<p>以上只是网络内核参数的一小小部分，有待继续补充。</p>
<p>ref:</p>
<p>http://www.frozentux.net/ipsysctl-tutorial/chunkyhtml/tcpvariables.html<br />
http://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt<br />
http://www.symantec.com/connect/articles/hardening-tcpip-stack-syn-attacks<br />
http://www.saview.net/archives/201</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<h3 class="zemanta-related-title" style="margin: 0 0 10px 0; padding: 0; clear: both;">Related articles across the web</h3>
<ul class="zemanta-article-ul zemanta-article-ul-image" style="margin: 0; padding: 0; overflow: hidden;">
<li class="zemanta-article-ul-li-image zemanta-article-ul-li" style="padding: 0; background: none; list-style: none; display: block; float: left; vertical-align: top; text-align: left; width: 104px; font-size: 12px; margin: 0 5px 10px 0;"></li>
<li class="zemanta-article-ul-li-image zemanta-article-ul-li" style="padding: 0; background: none; list-style: none; display: block; float: left; vertical-align: top; text-align: left; width: 104px; font-size: 12px; margin: 0 5px 10px 0;"><a style="padding: 2px; display: block; text-decoration: none;" href="http://networking.answers.com/tcp-ip/tcp-and-ip-all-you-need-to-know-about-network-basics" target="_blank"><img style="border-radius: 3px; box-shadow: 0 1px 4px rgba(0, 0, 0, 0.2); padding: 0; margin: 0; border: 0; display: block; width: 100px; max-width: 100%;" alt="" src="http://i.zemanta.com/158573031_150_150.jpg" /></a><a style="display: block; overflow: hidden; text-decoration: none; line-height: 12pt; height: 80px; padding: 5px 2px 0 2px;" href="http://networking.answers.com/tcp-ip/tcp-and-ip-all-you-need-to-know-about-network-basics" target="_blank">TCP and IP: All You Need to Know About Network Basics</a></li>
<li class="zemanta-article-ul-li-image zemanta-article-ul-li" style="padding: 0; background: none; list-style: none; display: block; float: left; vertical-align: top; text-align: left; width: 104px; font-size: 12px; margin: 0 5px 10px 0;"><a style="padding: 2px; display: block; text-decoration: none;" href="http://www.c0t0d0s0.org/archives/7665-tcp_init_wnd_chk.html" target="_blank"><img style="border-radius: 3px; box-shadow: 0 1px 4px rgba(0, 0, 0, 0.2); padding: 0; margin: 0; border: 0; display: block; width: 100px; max-width: 100%;" alt="" src="http://i.zemanta.com/noimg_7_150_150.jpg" /></a><a style="display: block; overflow: hidden; text-decoration: none; line-height: 12pt; height: 80px; padding: 5px 2px 0 2px;" href="http://www.c0t0d0s0.org/archives/7665-tcp_init_wnd_chk.html" target="_blank">tcp_init_wnd_chk</a></li>
<li class="zemanta-article-ul-li-image zemanta-article-ul-li" style="padding: 0; background: none; list-style: none; display: block; float: left; vertical-align: top; text-align: left; width: 104px; font-size: 12px; margin: 0 5px 10px 0;"><a style="padding: 2px; display: block; text-decoration: none;" href="http://ranjan01.wordpress.com/2013/11/07/tuning-tcp-sockets-for-web-server/" target="_blank"><img style="border-radius: 3px; box-shadow: 0 1px 4px rgba(0, 0, 0, 0.2); padding: 0; margin: 0; border: 0; display: block; width: 100px; max-width: 100%;" alt="" src="http://i.zemanta.com/218557505_150_150.jpg" /></a><a style="display: block; overflow: hidden; text-decoration: none; line-height: 12pt; height: 80px; padding: 5px 2px 0 2px;" href="http://ranjan01.wordpress.com/2013/11/07/tuning-tcp-sockets-for-web-server/" target="_blank">Tuning TCP Sockets for web server</a></li>
</ul>
]]></content:encoded>
			<wfw:commentRss>https://www.fushanlang.com/sysctl-conf-network-kernel-parameter-description-rpm-2340/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

<!-- Dynamic page generated in 0.206 seconds. -->
<!-- Cached page generated by WP-Super-Cache on 2025-10-28 17:09:36 -->
