Linux UDP严重丢包问题的解决
测试系统在Linux上的性能发现丢包率极为严重，发210000条数据，丢包达110000之巨，丢包率超过50%。同等情形下Windows上测试，仅丢几条数据。形势严峻，必须解决。考虑可能是因为协议栈Buffer太低所致，于是先看看默认情况：
sysctl -a |grep net.core
发现
net.core.rmem_max = 131071
net.core.rmem_default = 112640
修改吧，变大一点，变成10M，然后reboot（应该重启某个服务即可）
然后查网卡收包情况：
netstat -su
结果如下：
Udp:
97690 packets received
112310 packets to unknown port received.
0 packet receive errors
20 packets sent
发现数据在网卡就丢了，判断可能是防火墙引起的，于是执行命令：
iptables -L
结果如下：
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
证明iptables启动，于是停止防火墙：
service iptables stop
这个命令即时生效，开启防火墙的命令：
service iptables start
如果要彻底关闭防火墙，则需要重启后生效
开启： chkconfig iptables on
关闭： chkconfig iptables off
在开启了防火墙时，做如下设置，开启相关端口，
修改/etc/sysconfig/iptables 文件，添加以下内容：
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
重新测试，没丢一条数据。
linux 内核参数调整说明
所有的TCP/IP调优参数都位于/proc/sys/net/目录。例如, 下面是最重要的一些调优参数, 后面是它们的含义:
1. /proc/sys/net/core/rmem_max — 最大的TCP数据接收缓冲。
2. /proc/sys/net/core/wmem_max — 最大的TCP数据发送缓冲。
3. /proc/sys/net/ipv4/tcp_timestamps — 时间戳在(请参考RFC 1323)TCP的包头增加12个字节。
4. /proc/sys/net/ipv4/tcp_sack — 有选择的应答。
5. /proc/sys/net/ip
相关文档：
//获取本机MAC地址函数QString GetLocalMac()
{
int sock_mac;
struct ifreq ifr_mac;
char mac_addr[30];
sock_mac = socket( AF_INET, SOCK_STREAM, 0 );
if( sock_mac == -1)
{
perror("create socket falise...mac\n");
return "";
}
memset(&ifr_mac,0,sizeof(ifr_mac));
......
前一篇博客还写了自己写的端口转发工具，今天偶然在网上看到讲命名管道和netcat配合的用法，被彻底雷倒了。
原来以为netcat做不到，原来是自己想不到，而不是netcat做不到……
方法如下：
$ mknod backpipe p
&n ......
不常用但非常实用的命令
UNIX命令是测试必备的知识，除了一些常用的命令需要熟悉以外，有很多非常有用但是不常用的命令也需要了解，这样对工作有很大的帮助，这里提供一些我平常工作中累积的知识，希望能帮助到大家 ^_^
1、统计所有文件中的记录数：wc -l filename
2、查看共享内存：ipcs -m
3、vi中的批量字符匹配（a- ......
我已经半年没有使用 Windows 的方式工作了。Linux 高效的完成了我所有的工作。
GNU/Linux 不是每个人都想用的。如果你只需要处理一般的事务，打游戏，那么你不需要了解下面这些了。
我不是一个狂热的自由软件份子，虽然我很喜欢自由软件。这篇文章也不是用来推行自由软件运动的，虽然我� ......
