经济观察报 周航
最近和朋友聊天，谈的话题比较集中在互联网与传统产业的关系上。
他们中好几位的企业都已是各自行业里的翘楚，做得非常成功。尽管最大的互联网企业仍然比自己小很多，然而面对整个世界都奔向互联网的趋势，大家都很茫然。
他们模模糊糊地认为，不管是主动拥抱还是被动等待，自己的行业可能最终都会跟互联网发生关系，但到底是什么样的关系，该如何应对，可以说完全没有概念。
一位国内数一数二的家电制造品牌老总对我说，“小米们”的崛起给他的心理带来了非常大的震撼，或者说惶恐。自己苦苦拼了几十年，冰箱、洗衣机、 厨房电器，几十种品类，又从国内拼到国外，勉强过了1000亿元的营业额；一个小米才两年，就那么一个产品，已经卖了100多亿，这个刺激太大了。
他无法理解这样迅速的成功，而只能从一些表层的东西去解读：小米很会炒作，很会利用社交媒体，领导者很有个人魅力，等等。
两个小时里，我只能尽量向他解释做传统企业的人和互联网人的区别。那就是后者的思维起点永远是用户，其一切行动的出发点都是用户。但传统企业离真正的终端用户非常远。
拿中国的家电制造产业来说，它的逻辑是，世界上有了什么新产品、新技术，跑过去了解甚至干脆copy一下，加进一些所谓的符合中国用户使用习惯的改造，产品出来后，还要经过非常长的销售链条——区域代理、省级代理、市县级代理，才能到最终用户手上。
所以，他每天考虑的都是渠道如何管控，用户怎么想他根本不知道。做品牌也是传统的方式，广告预算出来，电视多大比例，纸媒多大比例，互联网广告投放得非常少，即使有也只是尝试尝试，属于补充。
我不敢说完全看懂了互联网，但我曾经有一只脚在传统行业里，里面的人的心态，受到哪些束缚，我深有体会。
我问这位家电品牌老总，你有没有想过5年以后的家居行业是什么样子？你们有没有这样一个实验室，里面模拟的是未来的人居生活？他说完全没有。行业竞争这么激烈、利润超低、渠道难管理，还哪有闲暇去思考这些“遥远”的事情。
所以，他们看互联网，正如当年我做音响企业时看互联网。个性使然，我对创新和变化一直很热衷。对于渐渐热门起来的网络，我会想，是不是也去搞个网站、去阿里巴巴上做个推广，换作在时下，我肯定会想是不是也去做个App。
这就是搞互联网吗？显然不是。因为对互联网的认识非常表象，你所做的任何努力注定都不得法。尝试了一下没什么效果，回报和投入的精力和人员都不成正比，就很容易得出结论：互联网跟我做的事情、跟我的行业的关系不大。
对于互联网，我们就是旁观者，在舞台下面，是观众。
然后你就会和温水里的青蛙一样，开始时可能还感受不到压力和紧迫，但当真正的互联网侵袭到你的领地时，你可能瞬间就束手就擒。
然而，即使你看懂了，就能成功拥抱互联网吗？
我并不是没有尝试过，但和绝大多数传统企业经营者一样，我每天都忙于处理一些眼前的事情，这个月的收入多少，利润多少，这个产品的市场反应怎么样，价格和渠道怎么样……不知不觉就随波逐流了，根本跳不出来，那是一种身不由己。
所以我才决定，算了，不折腾老行业了，既然我那么看好互联网，还背着传统行业的包袱，包括好几百号人，怎么转啊。你可以说你们坐在船上就行了，我来转，但是会很累，另外船上的人又会说，头晕，你的动作太大。总之是阻力太大了。
企业越大、越成功，越不容易改变，因为身上的包袱太重了。它的潜意识总是希望去证明自己过去做的所拥有的是可以延续的。微软做surface不 太容易成功，或者说必然不会成功，为什么？因为它在PC上太成功了。尽管认识到了移动是未来，但它总想找到一个中间状态，既能延续在PC上的成功，又能够 拥抱变化，但是很显然，这个过渡的中间产物是你的需求，不是用户的需求。
如果你的出发点是利用互联网让过去的业务和公司活得更好，那么，不管你做多大的努力，宿命都是必死无疑。但是人总是能用一个看似合理的理由，自圆其说。企业也一样，微软如此，国美、苏宁也是如此。
10年之前，所有的企业还都很迷恋《基业长青》这本书。可是，哪有什么基业长青可言啊？企业渴望基业长青，就像人渴望长生不老，炼丹、锻炼，无非让寿命延长。然而，这跟大自然的规律是相悖的。企业就像人要死一样，要么被新的力量破坏、重构，要么就是消亡。
所以，对于那些老朋友，我的结论听起来会很残忍：没有办法，别抱幻想，你转不了。怎么办，要么推翻一切旧有思维，完全跳出来，从头开始；要么等待着新的互联网企业来重新去整合你的行业。只有这两条路。
历史一直如此。在一个正常的经济社会中，创新永远都是破坏性的，如果你秉着中庸之道，不想破坏原有，试图从增量上去创新，这是自欺欺人。
工业革命的蒸汽机、汽车淘汰了马车业；如今的亚马逊、eBay、淘宝逼得沃尔玛、百思买这样的大连锁企业关店，不管你有3000家还是5000家门店，到了今天都不是资源了，变成了成本。
当然，实体的东西并不会完全消失，至少在现阶段，线下的体验和展示，互联网还做不到。但人们的标准动作已经变成：到国美、苏宁，看半天摸半天，把图片一拍，回家上淘宝下单。
租车行业同样，赫兹在美国做了60年，100万台车、8000个门店，不得了了吧？但你想想跟美国整个汽车保有量上亿台相比，100万台算什么呢？这样的公司不一定会消失，但不再会是主流了。
自信者会振振有词，我们这个行业有互联网取代不了的地方，没错，但是互联网和传统行业的关系不是取代关系，而是谁主谁次、谁是枢纽谁是附属的关系。我们从小受到的革命教育就是这样，除了取代和打倒就没有别的，可互联网它是慢慢地渗透，然后颠覆原有的产业结构。
淘宝网存在了10年了，中国互联网购物目前也仅过1万亿，占整个社会的零售总值的比例不到10%，如果从这个数字来看，我们依然会觉得传统商业是主，互联网是新增。但如果看成长曲线，看趋势，那你得出的结论一定是相反的。
关于租车行业，想再多说几句。赫兹的规模化逻辑在中国还有机会，因为中国的社会目前处于一种时代的多层叠加形态，大家都有机会，但它的成长速度和空间是有限的。
这个行业未来的理想状态就是没有租车行业，汽车应该全民共享。生活中汽车已经这么多了，为什么不可以提高效率让大家来共享汽车呢？真正的互联网 为什么有这么大的威力？就是释放了最小的经济单位的活力——个人。释放越多的经济单位，越有爆炸性，而且它有自我组织性和社区性。这都是传统产业不能望其 项背的。
2.实现DNS的反向解析
实现DNS的反向解析其实和正向解析的原理是一样的，只要对DNS、DLZ、ACL和VIEW的原理深刻理解一下就可以类比互通，以和正向解析的同样的方式来实现反向解析。
插入SOA记录
INSERT INTO `dns_records` (`zone`, `host`, `type`, `data`, `ttl`,`mx_priority`,
`refresh`, `retry`, `expire`, `minimum`, `serial`, `resp_person`, `primary_ns`,`second_ns`,
`data_count`) VALUES
('201.16.172.in-addr.arpa', '@', 'SOA', 'ns1.vtest.org.', 10, NULL, 600, 3600, 86400,
10, 2011061200, 'vtest.org.', 'ns1.vtest.org.','ns2.vtest.org.',0);
插入@和NS记录
INSERT INTO `dns_records` (`zone`, `host`, `type`, `data`) VALUES
('vtest.org', '@', 'NS', 'ns1.vtest.org.'),
('vtest.org', '@', 'NS', 'ns2.vtest.org.');
插入NS和A记录
INSERT INTO `dns_records` (`zone`, `host`, `type`, `data`) VALUES
('201.16.172.in-addr.arpa', '204', 'PTR', 'www1.vtest.org.'),
('201.16.172.in-addr.arpa', '205', 'PTR', 'www2.vtest.org.');
总之设置方面一句话，只要明白zone记录的写法一切就OK了！思路方面：多类比，多尝试，遇到问题不要急于找资料，先理顺思路、分析透彻，一切慢慢来
http://itsecureadmin.com/2010/09/bind-dlz-with-mysql/
在TimesTen的优化中，如果涉及到 Replication 或者Cache Group的话，那么针对 TCP/IP相关的参数的优化对性能是有益的。因为它们俩都是通过TCP/IP协议进行数据交互的。在安装文档(install.pdf)的39页有具体的说明：
For replication, TCP send and receive buffers should be increased to a minimum of 512KB. To make these changes, add the lines:
net.ipv4.tcp_rmem=”4096 4194304 4194304″
net.ipv4.tcp_wmem=”98304 4194304 4194304″
net.ipv4.tcp_mem=”98304 4194304 4194304″
net.core.rmem_default=65535
net.core.wmem_default=65535
net.core.rmem_max=4194304
net.core.wmem_max=4194304
net.ipv4.tcp_window_scaling=1
to the /etc/sysctl.conf file and reboot.
For Cache Connect, TCP send and receive buffers should be increased to even greater values. To make these changes, add the lines:
net.ipv4.tcp_rmem=”4096 4194304 4194304″
net.ipv4.tcp_wmem=”98304 4194304 4194304″
net.ipv4.tcp_mem=”98304 4194304 4194304″
net.core.rmem_default=262144
net.core.wmem_default=262144
net.core.rmem_max=4194304
net.core.wmem_max=4194304
net.ipv4.tcp_window_scaling=1
net.ipv4.ip_local_port_range=”1024 65000″
to the /etc/sysctl.conf file and reboot.(方法: 使用 /etc/sysctl.conf 在系统启动时将参数配置成您所设置的值:)
另外一个方法:
把下面代码增加到/etc/rc.local文件, 然后保存文件, 系统重新引导的时候会自动修改下面的TCP/IP参数:
echo 256960 > /proc/sys/net/core/rmem_default
echo 256960 > /proc/sys/net/core/rmem_max
echo 256960 > /proc/sys/net/core/wmem_default
echo 256960 > /proc/sys/net/core/wmem_max
echo 0 > /proc/sys/net/ipv4/tcp_timestamps
echo 1 > /proc/sys/net/ipv4/tcp_sack
echo 1 > /proc/sys/net/ipv4/tcp_window_scaling
下面是一篇参考文章，可能会有些帮助，引用于IBM。
使用 Sockets API，我们可以开发客户机和服务器应用程序，它们可以在本地网络上进行通信，也可以通过 Internet 在全球范围内进行通信。与其他 API 一样，您可以通过一些方法使用Sockets API，从而提高 Socket 的性能，或者限制 Socket 的性能。本文探索了 4 种使用 Sockets API 来获取应用程序的最大性能并对 GNU/Linux® 环境进行优化从而达到最好结果的方法。
在开发 socket 应用程序时，首要任务通常是确保可靠性并满足一些特定的需求。利用本文中给出的 4 个提示，您就可以从头开始为实现最佳性能来设计并开发 socket 程序。本文内容包括对于 Sockets API 的使用、两个可以提高性能的 socket 选项以及 GNU/Linux 优化。
为了能够开发性能卓越的应用程序，请遵循以下技巧：
•最小化报文传输的延时。
•最小化系统调用的负载。
•为 Bandwidth Delay Product 调节 TCP 窗口。
•动态优化 GNU/Linux TCP/IP 栈。
技巧 1. 最小化报文传输的延时
在通过 TCP socket 进行通信时，数据都拆分成了数据块，这样它们就可以封装到给定连接的 TCP payload（指 TCP 数据包中的有效负荷）中了。TCP payload 的大小取决于几个因素（例如最大报文长度和路径），但是这些因素在连接发起时都是已知的。为了达到最好的性能，我们的目标是使用尽可能多的可用数据来填充每个报文。当没有足够的数据来填充 payload 时（也称为最大报文段长度（maximum segment size） 或 MSS），TCP 就会采用 Nagle 算法自动将一些小的缓冲区连接到一个报文段中。这样可以通过最小化所发送的报文的数量来提高应用程序的效率，并减轻整体的网络拥塞问题。
尽管 John Nagle 的算法可以通过将这些数据连接成更大的报文来最小化所发送的报文的数量，但是有时您可能希望只发送一些较小的报文。一个简单的例子是 telnet 程序，它让用户可以与远程系统进行交互，这通常都是通过一个 shell 来进行的。如果用户被要求用发送报文之前输入的字符来填充某个报文段，那么这种方法就绝对不能满足我们的需要。
另外一个例子是 HTTP 协议。通常，客户机浏览器会产生一个小请求（一条 HTTP 请求消息），然后 Web 服务器就会返回一个更大的响应（Web 页面）。
解决方案
您应该考虑的第一件事情是 Nagle 算法满足一种需求。由于这种算法对数据进行合并，试图构成一个完整的 TCP 报文段，因此它会引入一些延时。但是这种算法可以最小化在线路上发送的报文的数量，因此可以最小化网络拥塞的问题。
但是在需要最小化传输延时的情况中，Sockets API 可以提供一种解决方案。要禁用 Nagle 算法，您可以设置 TCP_NODELAY socket 选项，如清单 1 所示。
清单 1. 为 TCP socket 禁用 Nagle 算法
int sock, flag, ret;
/* Create new stream socket */
sock = socket( AF_INET, SOCK_STREAM, 0 );
/* Disable the Nagle (TCP No Delay) algorithm */
flag = 1;
ret = setsockopt( sock, IPPROTO_TCP, TCP_NODELAY, (char *)&flag, sizeof(flag) );
if (ret == -1) {
printf(“Couldn’t setsockopt(TCP_NODELAY)/n”);
exit(-1);
}
提示：使用 Samba 的实验表明，在从 Microsoft® Windows® 服务器上的 Samba 驱动器上读取数据时，禁用 Nagle 算法几乎可以加倍提高读性能。
技巧 2. 最小化系统调用的负载
任何时候通过一个 socket 来读写数据时，您都是在使用一个系统调用（system call）。这个调用（例如 read 或 write）跨越了用户空间应用程序与内核的边界。另外，在进入内核之前，您的调用会通过 C 库来进入内核中的一个通用函数（system_call()）。从 system_call() 中，这个调用会进入文件系统层，内核会在这儿确定正在处理的是哪种类型的设备。最后，调用会进入 socket 层，数据就是在这里进行读取或进行排队从而通过 socket 进行传输的（这涉及数据的副本）。
这个过程说明系统调用不仅仅是在应用程序和内核中进行操作的，而且还要经过应用程序和内核中的很多层次。这个过程耗费的资源很高，因此调用次数越多，通过这个调用链进行的工作所需要的时间就越长，应用程序的性能也就越低。
由于我们无法避免这些系统调用，因此惟一的选择是最小化使用这些调用的次数。幸运的是，我们可以对这个过程进行控制。
解决方案
在将数据写入一个 socket 时，尽量一次写入所有的数据，而不是执行多次写数据的操作。对于读操作来说，最好传入可以支持的最大缓冲区，因为如果没有足够多的数据，内核也会试图填充整个缓冲区（另外还需要保持 TCP 的通告窗口为打开状态）。这样，您就可以最小化调用的次数，并可以实现更好的整体性能。
技巧 3. 为 Bandwidth Delay Product 调节 TCP 窗口
TCP 的性能取决于几个方面的因素。两个最重要的因素是链接带宽（link bandwidth）（报文在网络上传输的速率）和 往返时间（round-trip time） 或 RTT（发送报文与接收到另一端的响应之间的延时）。这两个值确定了称为 Bandwidth Delay Product（BDP）的内容。
给定链接带宽和 RTT 之后，您就可以计算出 BDP 的值了，不过这代表什么意义呢？BDP 给出了一种简单的方法来计算理论上最优的 TCP socket 缓冲区大小（其中保存了排队等待传输和等待应用程序接收的数据）。如果缓冲区太小，那么 TCP 窗口就不能完全打开，这会对性能造成限制。如果缓冲区太大，那么宝贵的内存资源就会造成浪费。如果您设置的缓冲区大小正好合适，那么就可以完全利用可用的带宽。下面我们来看一个例子：
BDP = link_bandwidth * RTT
如果应用程序是通过一个 100Mbps 的局域网进行通信，其 RRT 为 50 ms，那么 BDP 就是：
100MBps * 0.050 sec / 8 = 0.625MB = 625KB
注意：此处除以 8 是将位转换成通信使用的字节。
因此，我们可以将 TCP 窗口设置为 BDP 或 1.25MB。但是在 Linux 2.6 上默认的 TCP 窗口大小是 110KB，这会将连接的带宽限制为 2.2MBps，计算方法如下：
throughput = window_size / RTT
110KB / 0.050 = 2.2MBps
如果使用上面计算的窗口大小，我们得到的带宽就是 12.5MBps，计算方法如下：
625KB / 0.050 = 12.5MBps
差别的确很大，并且可以为 socket 提供更大的吞吐量。因此现在您就知道如何为您的 socket 计算最优的缓冲区大小了。但是又该如何来改变呢？
解决方案
Sockets API 提供了几个 socket 选项，其中两个可以用于修改 socket 的发送和接收缓冲区的大小。清单 2 展示了如何使用 SO_SNDBUF 和 SO_RCVBUF 选项来调整发送和接收缓冲区的大小。
注意：尽管 socket 缓冲区的大小确定了通告 TCP 窗口的大小，但是 TCP 还在通告窗口内维护了一个拥塞窗口。因此，由于这个拥塞窗口的存在，给定的 socket 可能永远都不会利用最大的通告窗口。
清单 2. 手动设置发送和接收 socket 缓冲区大小
int ret, sock, sock_buf_size;
sock = socket( AF_INET, SOCK_STREAM, 0 );
sock_buf_size = BDP;
ret = setsockopt( sock, SOL_SOCKET, SO_SNDBUF,
(char *)&sock_buf_size, sizeof(sock_buf_size) );
ret = setsockopt( sock, SOL_SOCKET, SO_RCVBUF,
(char *)&sock_buf_size, sizeof(sock_buf_size) );
在 Linux 2.6 内核中，发送缓冲区的大小是由调用用户来定义的，但是接收缓冲区会自动加倍。您可以进行 getsockopt 调用来验证每个缓冲区的大小。。{最终缓冲区的大小还受限于linux系统的TCP/IP相关的参数配置: /proc/sys/net/core/rmem_max wmem_max rmem_default ,wmem_default }
巨帧（jumbo frame）
我们还可以考虑将包的大小从 1,500 字节修改为 9,000 字节（称为巨帧）。在本地网络中可以通过设置最大传输单元（Maximum Transmit Unit，MTU）来设置巨帧，这可以极大地提高性能。
就 window scaling 来说，TCP 最初可以支持最大为 64KB 的窗口（使用 16 位的值来定义窗口的大小）。采用 window scaling（RFC 1323）扩展之后，您就可以使用 32 位的值来表示窗口的大小了。GNU/Linux 中提供的 TCP/IP 栈可以支持这个选项（以及其他一些选项）。
提示：Linux 内核还包括了自动对这些 socket 缓冲区进行优化的能力（请参阅下面 表 1 中的 tcp_rmem 和 tcp_wmem），不过这些选项会对整个栈造成影响。如果您只需要为一个连接或一类连接调节窗口的大小，那么这种机制也许不能满足您的需要了。
技巧 4. 动态优化 GNU/Linux TCP/IP 栈
标准的 GNU/Linux 发行版试图对各种部署情况都进行优化。这意味着标准的发行版可能并没有对您的环境进行特殊的优化。
解决方案
GNU/Linux 提供了很多可调节的内核参数，您可以使用这些参数为您自己的用途对操作系统进行动态配置。下面我们来了解一下影响 socket 性能的一些更重要的选项。
在 /proc 虚拟文件系统中存在一些可调节的内核参数。这个文件系统中的每个文件都表示一个或多个参数，它们可以通过 cat 工具进行读取，或使用 echo 命令进行修改。清单 3 展示了如何查询或启用一个可调节的参数（在这种情况中，可以在 TCP/IP 栈中启用 IP 转发）。
清单 3. 调优：在 TCP/IP 栈中启用 IP 转发
[root@camus]# cat /proc/sys/net/ipv4/ip_forward
0
[root@camus]# echo “1″ > /poc/sys/net/ipv4/ip_forward
[root@camus]# cat /proc/sys/net/ipv4/ip_forward
1
[root@camus]#
表 1 给出了几个可调节的参数，它们可以帮助您提高 Linux TCP/IP 栈的性能。
表 1. TCP/IP 栈性能使用的可调节内核参数
|
可调节的参数
|
默认值
|
选项说明
|
|
/proc/sys/net/core/rmem_default
|
“110592″
|
定义默认的接收窗口大小；对于更大的 BDP 来说，这个大小也应该更大。
|
|
/proc/sys/net/core/rmem_max
|
“110592″
|
定义接收窗口的最大大小；对于更大的 BDP 来说，这个大小也应该更大。
|
|
/proc/sys/net/core/wmem_default
|
“110592″
|
定义默认的发送窗口大小；对于更大的 BDP 来说，这个大小也应该更大。
|
|
/proc/sys/net/core/wmem_max
|
“110592″
|
定义发送窗口的最大大小；对于更大的 BDP 来说，这个大小也应该更大。
|
|
/proc/sys/net/ipv4/tcp_window_scaling
|
“1″
|
启用 RFC 1323 定义的 window scaling；要支持超过 64KB的窗口，必须启用该值
|
|
/proc/sys/net/ipv4/tcp_sack
|
“1″
|
启用有选择的应答（Selective Acknowledgment），这可以通过有选择地应答乱序接收到的报文来提高性能（这样可以让发送者只发送丢失的报文段）；（对于广域网通信来说）这个选项应该启用，但是这会增加对 CPU 的占用。
|
|
/proc/sys/net/ipv4/tcp_fack
|
“1″
|
启用转发应答（Forward Acknowledgment），这可以进行有选择应答（SACK）从而减少拥塞情况的发生；这个选项也应该启用。
|
|
/proc/sys/net/ipv4/tcp_timestamps
|
“1″
|
以一种比重发超时更精确的方法（请参阅 RFC 1323）来启用对RTT 的计算；为了实现更好的性能应该启用这个选项
|
|
/proc/sys/net/ipv4/tcp_mem
|
“24576 32768 49152″
|
确定 TCP 栈应该如何反映内存使用；每个值的单位都是内存页（通常是 4KB）。第一个值是内存使用的下限。第二个值是内存压力模式开始对缓冲区使用应用压力的上限。第三个值是内存上限。在这个层次上可以将报文丢弃，从而减少对内存的使用。对于较大的 BDP 可以增大这些值（但是要记住，其单位是内存页，而不是字节）。
|
|
/proc/sys/net/ipv4/tcp_wmem
|
“4096 16384 131072″
|
为自动调优定义每个 socket 使用的内存。第一个值是为socket 的发送缓冲区分配的最少字节数。第二个值是默认值（该值会被 wmem_default 覆盖），缓冲区在系统负载不重的情况下可以增长到这个值。第三个值是发送缓冲区空间的最大字节数（该值会被 wmem_max 覆盖）。
|
|
/proc/sys/net/ipv4/tcp_rmem
|
“4096 87380 174760″
|
与 tcp_wmem 类似，不过它表示的是为自动调优所使用的接收缓冲区的值。
|
|
/proc/sys/net/ipv4/tcp_low_latency
|
“0″
|
允许 TCP/IP 栈适应在高吞吐量情况下低延时的情况；这个选项应该禁用。
|
|
/proc/sys/net/ipv4/tcp_westwood
|
“0″
|
启用发送者端的拥塞控制算法，它可以维护对吞吐量的评估，并试图对带宽的整体利用情况进行优化；对于 WAN 通信来说应该启用这个选项。
|
|
/proc/sys/net/ipv4/tcp_bic
|
“1″
|
为快速长距离网络启用 Binary Increase Congestion；这样可以更好地利用以 GB 速度进行操作的链接；对于 WAN 通信应该启用这个选项。
|
与任何调优努力一样，最好的方法实际上就是不断进行实验。您的应用程序的行为、处理器的速度以及可用内存的多少都会影响到这些参数影响性能的方式。在某些情况中，您认为有益的操作可能恰恰是有害的（反之亦然）。因此，我们需要逐一试验各个选项，然后检查每个选项的结果。换而言之，我们需要相信自己的经验，但是对每次修改都要进行验证。
提示：下面介绍一个有关永久性配置的问题。注意，如果您重新启动了 GNU/Linux 系统，那么您所需要的任何可调节的内核参数都会恢复成默认值。为了将您所设置的值作为这些参数的默认值，可以使用 /etc/sysctl.conf 在系统启动时将这些参数配置成您所设置的值。
GNU/Linux 工具
GNU/Linux 对我非常有吸引力，这是因为其中有很多工具可以使用。尽管其中大部分都是命令行工具，但是它们都非常有用，而且非常直观。GNU/Linux 提供了几个工具 —— 有些是GNU/Linux 自己提供的，有些是开放源码软件 —— 用于调试网络应用程序，测量带宽/吞吐量，以及检查链接的使用情况。
表 2 列出最有用的几个 GNU/Linux 工具，以及它们的用途。表 3 列出了 GNU/Linux 发行版没有提供的几个有用工具。有关表 3 中工具的更多信息请参阅 参考资料。
表 2. 任何 GNU/Linux 发行版中都可以找到的工具 GNU/Linux 工具 用途
ping 这是用于检查主机的可用性的最常用的工具，但是也可以用于识别带宽延时产品计算的 RTT。
traceroute 打印某个连接到网络主机所经过的包括一系列路由器和网关的路径（路由），从而确定每个 hop 之间的延时。
netstat 确定有关网络子系统、协议和连接的各种统计信息。
tcpdump 显示一个或多个连接的协议级的报文跟踪信息；其中还包括时间信息，您可以使用这些信息来研究不同协议服务的报文时间。
表 3. GNU/Linux 发行版中没有提供的有用性能工具 GNU/Linux 工具 用途
netlog 为应用程序提供一些有关网络性能方面的信息。
nettimer 为瓶颈链接带宽生成一个度量标准；可以用于协议的自动优化。
Ethereal 以一个易于使用的图形化界面提供了 tcpump（报文跟踪）的特性。
iperf 测量 TCP 和 UDP 的网络性能；测量最大带宽，并汇报延时和数据报的丢失情况。
结束语
尝试使用本文中介绍的技巧和技术来提高 socket 应用程序的性能，包括通过禁用 Nagle 算法来减少传输延时，通过设置缓冲区的大小来提高 socket 带宽的利用，通过最小化系统调用的个数来降低系统调用的负载，以及使用可调节的内核参数来优化 Linux 的 TCP/IP 栈。
在进行优化时还需要考虑应用程序的特性。例如，您的应用程序是基于 LAN 的还是会通过 Internet 进行通信？如果您的应用程序仅仅会在 LAN 内部进行操作，那么增大 socket 缓冲区的大小可能不会带来太大的改进，不过启用巨帧却一定会极大地改进性能！
最后，还要使用 tcpdump 或 Ethereal 来检查优化之后的结果。在报文级看到的变化可以帮助展示使用这些技术进行优化之后所取得的成功效果。
