IDC笔记

AJAX中文乱码PHP完美解决（IE和Firefox兼容）

wentaiyou@126.com(kevin) — Thu,25 Aug 2011 12:28:16 +0800

近来使用AJAX发现发送给服务器端及服务器返回都会在中文字符上出现乱码.在网上找了一些解决办法.下以这个比较实际可行转来以便今后使用

众所周知，使用AJAX传送和接收中文参数时，如果不在客户端和服务器做相应的处理就会出现乱码问题，在网上相应的文章也不少，但是有的情况下很难从中找到符合自己理想的答案，我今天就是在网上找了很多，但是都差不多，讲ASP和JSP的比较多（我是用的PHP），所以到最后都没找到自己满意的答案。

AJAX的中文乱码可以大概分为两中，第一种是向服务器端发送中文参数时（xmlhttp.open(“get|post”,url,true)）,服务器端接收到的为乱码，这个也是我今天遇到的问题，没做处理之前，在IE里是正常的，但是在Firefox里面就出现了乱码，我先把接收到参数输出到一个文本里，没有发现什么问题，郁闷了，然后我就把查询语句在输出来观察（我这里是要从数据库里查出与参数相关的东西），终于发现问题，IE和Firefox输出的参数不一样，虽然汉字上都一样，但是和前后连接上有细小的区别，于是认定了是编码问题，在网上查找了相关资料，都没能解决问题，但是得到一些启示，因为AJAX发送数据都是采用UTF-8编码的方式发送的，所以要在服务器端进行编码转换（我这里页面是采用GB2312编码的，如果是采用UTF-8的话应该不会有这步的问题），所以我在服务器端进行了UTF-8转GB2312，

$str=iconv("UTF-8","GB2312",$str);

然后测试，在Firefox上顺利解决了问题，以为大公告成了，可是再到IE下测试，发现IE又出现了问题，服务器端接收到的参数没值，这下就郁闷了，突然看到发送头设置了setRequestHeader("Content-Type","application/x-www-form-urlencoded");，就找到问题所在了，然后就在发送那里进行了参数编码：

geturl=encodeURI(geturl);

       geturl=encodeURI(geturl); //两次也可以写成geturl=encodeURI(encodeURI(geturl));

xmlhttp.open("GET",geturl,true);

然后再到服务器端进行URL解码：



   $str=urldecode($str); //解码

$ str =iconv("UTF-8","GB2312",$ str);  //编码转换

   注意：解码必须在编码转换前面，不然得不到正确值

保存测试，IE和Firefox都能正常了。

第二种就是服务器端向客户端输出中文时出现乱码，这类问题网上的答案就比较多了，也都能解决，为了避免各位再去查找，我在这里就COPY下J

原因：AJAX在接收responseText或responseXML的值的时候是按照UTF-8的格式来解码的，如果服务器段发送的数据不是UTF-8的格式，那么接收responseText或responseXML的值有可能为乱码。

    解决办法：

    在服务器指定发送数据的格式：
    在jsp文件中：
    response.setContentType("text/text;charset=UTF-8");//返回的是txt文本文件
    或是
    response.setContentType("text/xml;charset=UTF-8");//返回的xml文件

     PHP:header('Content-Type:text/html;charset=GB2312');
     ASP:Response.Charset("GB2312")
     JSP:response.setHeader("Charset","GB2312");

简单制作LINUX网络安装U盘

wentaiyou@126.com(kevin) — Wed,27 Jul 2011 14:29:19 +0800

相关下载
http://syslinux.zytor.com/wiki/index.php/The_Syslinux_Project

制作教程
http://www.cnblogs.com/5tao/archive/2010/01/31/1660481.html

参照以上自己所做的如下：
1、把u盘格式化，采用fat32格式。你可以用windows或者HP优盘格式化工具进行。
2、在u盘的根创建boot文件夹，在boot下创建syslinux子文件夹
3、把下载得到的syslinux-x.xx.zip解压缩到syslinux-x.xx文件夹，在其中的win32下有syslinux.exe文件。拷贝syslinux.exe到u盘的/boot/syslinux文件夹下
4、打开命令行，切换到u盘根目录，进入/boot/syslinux文件夹，执行syslinux.exe，假设u盘的盘符为j：
在命令行下依次运行下列命令：
C:\Documents and Settings\xxxxx> J:
J:\>cd boot/syslinux
J:\boot\syslinux> syslinux.exe -ma -d /boot/syslinux j:
其中 -d /boot/syslinux是把命令生成的启动系统文件ldlinux.sys放到/boot/syslinux目录新建一个syslinux.cfg配制内容如下。
调整BIOS就可以启动了(以下面配制文件是安装centos5.6_32位系统。源来自于163，可以根据不同要求来编写自己的CFG)

配制文件syslinux.cfg
prompt 1
timeout 100
default vesamenu.c32

F1 readme.txt
F2 syslinux.cfg

label centos5.6_32
kernel /boot/os/centos5.6_32-vmlinuz method=http://mirrors.163.com/centos/5.6/os/i386/
append initrd=/boot/os/centos5.6_32-initrd.img

LABEL boothd
MENU LABEL Boot System of HD1
kernel /boot/syslinux/chain.c32
append hd1
TEXT HELP
More about currently selected:
Boot System of HD1.
ENDTEXT

LABEL boothd
MENU LABEL Boot System of HD2
kernel /boot/syslinux/chain.c32
append hd2
TEXT HELP
More about currently selected:
Boot System of HD2.
ENDTEXT

LABEL reboot
MENU LABEL Reboot
kernel /boot/syslinux/reboot.c32
TEXT HELP
More about currently selected:
reboot.
ENDTEXT

linux的启动过程(redhat)

wentaiyou@126.com(kevin) — Wed,01 Jun 2011 14:01:16 +0800

随着Linux的应用日益广泛，特别是在网络应用方面，有大量的网络服务器使用Linux操作系统。由于Linux的桌面应用和Windows相比还有一定的差距，所以在企业应用中往往是Linux和Windows操作系统共存形成异构网络。在服务器端大多使用Linux和Unix的，目前Linux的擅长应用领域是单一应用的基础服务器应用，譬如DNS和DHCP服务器、Web服务器、目录服务器、防火墙、文件和打印服务器、Intranet代理服务器。启动 Linux 系统的过程包括很多阶段。不管您是引导一个标准的 x86 处理器，还是PowerPC 机器，很多流程都惊人地相似。本文将描述了从开机到登录的 Linux 启动全过程。

（1）从BIOS到内核

    BIOS自检

    计算机在接通电源之后首先由BIOS进行自检，即进行所谓的POST（Power On Self
Test），然后依据BIOS内设置的引导顺序从硬盘、软盘或CDROM中读入“引导块”。在 PC 中，引导 Linux 是从 BIOS 中的地址 0xFFFF0 处开始的。BIOS 的第一个步骤是加电自检（POST）。POST 的工作是对硬件进行检测。BIOS 的第二个步骤是进行本地设备的枚举和初始化。给定 BIOS 功能的不同用法之后，BIOS 由两部分组成：POST 代码和运行时服务。当 POST 完成之后，它被从内存中清理了出来，但是 BIOS 运行时服务依然保留在内存中，目标操作系统可以使用这些服务。

    要引导一个操作系统，BIOS 运行时会按照 CMOS 的设置定义的顺序来搜索处于活动状态并且可以引导的设备。引导设备可以是软盘、CD-ROM、硬盘上的某个分区、网络上的某个设备，甚至是 USB 闪存。通常，Linux 都是从硬盘上引导的，其中主引导记录（MBR）中包含主引导加载程序。MBR 是一个 512 字节大小的扇区，位于磁盘上的第一个扇区中（0 道 0 柱面 1 扇区）。当 MBR 被加载到 RAM 中之后，BIOS 就会将控制权交给 MBR。

    提取 MBR 的信息

    要查看 MBR 的内容，请使用下面的命令：

    # dd if=/dev/hda of=mbr.bin bs=512 count=1 # od -xa mbr.bin

    这个 dd 命令需要以 root 用户的身份运行，它从 /dev/hda（第一个 IDE 盘）上读取前 512 个字节的内容，并将其写入 mbr.bin 文件中。od 命令会以十六进制和 ASCII 码格式打印这个二进制文件的内容。
（2）启动GRUB/LILO

    GRUB和LILO都是引导加载程序。最简单地讲，引导加载程序（boot loader）会引导操作系统。当机器引导它的操作系统时，BIOS 会读取引导介质上最前面的 512 字节（即人们所知的主引导记录（master boot record，MBR））。在单一的 MBR 中只能存储一个操作系统的引导记录，所以当需要多个操作系统时就会出现问题。所以需要更灵活的引导加载程序。

    GRUB 与 LILO 的比较

    如本文开始处所述，所有引导加载程序都以类似的方式工作，满足共同的目的。不过，LILO 和 GRUB 之间有很多不同之处：

LILO 没有交互式命令界面，而 GRUB 拥有。
LILO 不支持网络引导，而 GRUB 支持。
LILO 将关于可以引导的操作系统位置的信息物理上存储在 MBR 中。如果修改了 LILO 配置文件，必须将 LILO 第一阶段引导加载程序重写到 MBR。相对于 GRUB，这是一个更为危险的选择，因为错误配置的 MBR 可能会让系统无法引导。使用 GRUB，如果配置文件配置错误，则只是默认转到 GRUB 命令行界面。
    安全提示：

    关于安全性，任何可以接触到引导磁盘/CD 的人，只需要使用没有设置安全性的 grub.conf 或 lilo.conf，就可以绕过本文中提及的所有安全措施。特别是使用 GRUB 时，因为能够引导到单用户模式，所以是一个严重的安全漏洞。解决此问题的一个简单方法是在机器的 BIOS 中禁止通过 CD 和软盘进行引导，并确保为 BIOS 设置了一个口令，使得其他人不能修改这些设置。
   （3）加载内核

    当内核映像被加载到内存之后，内核阶段就开始了。内核映像并不是一个可执行的内核，而是一个压缩过的内核映像。通常它是一个 zImage（压缩映像，小于 512KB）或一个 bzImage（较大的压缩映像，大于 512KB），它是提前使用 zlib 进行压缩过的。在这个内核映像前面是一个例程，它实现少量硬件设置，并对内核映像中包含的内核进行解压，然后将其放入高端内存中，如果有初始 RAM 磁盘映像，就会将它移动到内存中，并标明以后使用。然后该例程会调用内核，并开始启动内核引导的过程。

    GRUB 中的手工引导

    在 GRUB 命令行中，我们可以使用 initrd 映像引导一个特定的内核，方法如下：

    grub> kernel /bzImage-2.6.14.2
   [Linux-bzImage, setup=0x1400, size=0x29672e]

    grub> initrd /initrd-2.6.14.2.img
   [Linux-initrd @ 0x5f13000, 0xcc199 bytes]

    grub> boot

    Uncompressing Linux... Ok, booting the kernel.
如果您不知道要引导的内核的名称，只需使用斜线（/）然后按下 Tab 键即可。GRUB 会显示内核和 initrd 映像列表。
   （4）执行init进程

    init进程是系统所有进程的起点，内核在完成核内引导以后，即在本线程（进程）空间内加载init程序，它的进程号是1。init进程是所有进程的发起者和控制者。因为在任何基于Unix的系统（比如Linux）中，它都是第一个运行的进程，所以init进程的编号（Process ID，PID）永远是1。如果init出现了问题，系统的其余部分也就随之而垮掉了。

    init进程有两个作用。第一个作用是扮演终结父进程的角色。因为init进程永远不会被终止，所以系统总是可以确信它的存在，并在必要的时候以它为参照。如果某个进程在它衍生出来的全部子进程结束之前被终止，就会出现必须以init为参照的情况。此时那些失去了父进程的子进程就都会以init作为它们的父进程。快速执行一下ps -af 命令，可以列出许多父进程ID（Parent Process ID，PPID）为1的进程来。

    init的第二个角色是在进入某个特定的运行级别（Runlevel）时运行相应的程序，以此对各种运行级别进行管理。它的这个作用是由/etc/inittab文件定义的。
（5）通过/etc/inittab文件进行初始化

    init的工作是根据/etc/inittab来执行相应的脚本进行系统初始化，如设置键盘、字体，装载模块，设置网络，等等。

    对于RedhatLinux来说，执行的顺序为：

/etc/rc.d/rc.sysinit            # 由init执行的第一个脚本
/etc/rc.d/rc.sysinit主要做在各个运行模式中相同的初始化工作，包括：
设置初始的$PATH变量。
配置网络。
为虚拟内存启动交换。
设置系统的主机名。
检查root文件系统，以进行必要的修复。
检查root文件系统的配额。
为root文件系统打开用户和组的配额。
以读/写的方式重新装载root文件系统。
清除被装载的文件系统表/etc/mtab。
把root文件系统输入到mtab。
使系统为装入模块做准备。
查找模块的相关文件。
检查文件系统，以进行必要的修复。
加载所有其他文件系统。
清除几个/etc文件：/etc/mtab、/etc/fastboot和/etc/nologin。
删除UUCP的lock文件。
删除过时的子系统文件。
删除过时的pid文件。
设置系统时钟。
打开交换。
初始化串行端口。
装入模块。
/etc/rc.d/rcX.d/[KS]

    首先终止“K”开头的服务，然后启动“S”开头的服务。

     对每一个运行级别来说，在/etc/rc.d子目录中都有一个对应的下级目录。这些运行级别的下级子目录的命名方法是rcX.d，其中的X就是代表运行级别的数字。比如说，运行级别3的全部命令脚本程序都保存在/etc/rc.d/rc3.d子目录中。在各个运行级别的子目录中，都建立有到/etc/rc.d/init.d子目录中命令脚本程序的符号链接，但是，这些符号链接并不使用命令脚本程序在 /etc/rc.d/init.d子目录中原来的名字。如果命令脚本程序是用来启动一个服务的，其符号链接的名字就以字母S打头；如果命令脚本程序是用来关闭一个服务的，其符号链接的名字就以字母K打头。许多情况下，这些命令脚本程序的执行顺序都很重要。如果没有先配置网络接口，就没有办法使用DNS服务解析主机名！为了安排它们的执行顺序，在字母S或者 K的后面紧跟着一个两位数字，数值小的在数值大的前面执行。比如：/etc/rc.d/rc3.d/S50inet就会在 /etc/rc.d/rc3.d/S55named之前执行。存放在/etc/rc.d/init.d子目录中的、被符号链接上的命令脚本程序是真正的实干家，是它们完成了启动或者停止各种服务的操作过程。当 /etc/rc.d/rc运行通过每个特定的运行级别子目录的时候，它会根据数字的顺序依次调用各个命令脚本程序执行。它先运行以字母K打头的命令脚本程序，然后再运行以字母S打头的命令脚本程序。对以字母K打头的命令脚本程序来说，会传递Stop参数；类似地对以字母S打头的命令脚本程序来说，会传递 Start参数。
执行/etc/ec.d/rc.local
Redhat Linux中的运行模式2、3、5都把/etc/rc.d/rc.local做为初始化脚本中的最后一个，所以用户可以自己在这个文件中添加一些需要在其他初始化工作之后，登录之前执行的命令。在维护Linux系统运转的日子里，肯定会遇到需要系统管理员对开机或者关机命令脚本进行修改的情况。如果所做的修改只在引导开机的时候起作用，并且改动不大的话，可以考虑简单地编辑一下/etc/rc.d/rc.local脚本。这个命令脚本程序是在引导过程的最后一步被执行的。
执行 /bin/login 程式

login 程序会提示使用者需输入账号及密码, 接着编码并确认密码的正确性, 若二者相合, 则为使用者进行初始化环境, 并将控制权交给 shell，即等待用户登录。
到此为止Linux启动过程全部结束。
    最后笔者使用图1解释全部过程

TCP三次握手

wentaiyou@126.com(kevin) — Tue,24 May 2011 10:24:22 +0800

在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。

　　第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；

　　第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；

　　第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。

　　完成三次握手，客户端与服务器开始传送数据，在上述过程中，还有一些重要的概念：

未连接队列：在三次握手协议中，服务器维护一个未连接队列，该队列为每个客户端的SYN包（syn=j）开设一个条目，该条目表明服务器已收到 SYN包，并向客户发出确认，正在等待客户的确认包。这些条目所标识的连接在服务器处于Syn_RECV状态，当服务器收到客户的确认包时，删除该条目，服务器进入ESTABLISHED状态。
Backlog参数：表示未连接队列的最大容纳数目。

　　SYN-ACK 重传次数　服务器发送完SYN－ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传，如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。注意，每次重传等待的时间不一定相同。

　　半连接存活时间：是指半连接队列的条目存活的最长时间，也即服务从收到SYN包到确认这个报文无效的最长时间，该时间值是所有重传请求包的最长等待时间总和。有时我们也称半连接存活时间为Timeout时间、SYN_RECV存活时间

/proc/sys/net/ipv4/参数说明

wentaiyou@126.com(kevin) — Tue,24 May 2011 10:23:28 +0800

tcp_syn_retries ：INTEGER
默认值是5
对于一个新建连接，内核要发送多少个 SYN 连接请求才决定放弃。不应该大于255，默认值是5，对应于180秒左右时间。(对于大负载而物理通信良好的网络而言,这个值偏高,可修改为2.这个值仅仅是针对对外的连接,对进来的连接,是由tcp_retries1 决定的)

tcp_synack_retries ：INTEGER
默认值是5
对于远端的连接请求SYN，内核会发送SYN ＋ ACK数据报，以确认收到上一个 SYN连接请求包。这是所谓的三次握手( threeway handshake)机制的第二个步骤。这里决定内核在放弃连接之前所送出的 SYN+ACK 数目。不应该大于255，默认值是5，对应于180秒左右时间。(可以根据上面的 tcp_syn_retries 来决定这个值)

tcp_keepalive_time ：INTEGER
默认值是7200(2小时)
当keepalive打开的情况下，TCP发送keepalive消息的频率。(由于目前网络攻击等因素,造成了利用这个进行的攻击很频繁,曾经也有cu的朋友提到过,说如果2边建立了连接,然后不发送任何数据或者rst/fin消息,那么持续的时间是不是就是2小时,空连接攻击? tcp_keepalive_time就是预防此情形的.我个人在做nat服务的时候的修改值为1800秒)

tcp_keepalive_probes：INTEGER
默认值是9
TCP发送keepalive探测以确定该连接已经断开的次数。(注意:保持连接仅在SO_KEEPALIVE套接字选项被打开是才发送.次数默认不需要修改,当然根据情形也可以适当地缩短此值.设置为5比较合适)

tcp_keepalive_intvl：INTEGER
默认值为75
探测消息发送的频率，乘以tcp_keepalive_probes就得到对于从开始探测以来没有响应的连接杀除的时间。默认值为75秒，也就是没有活动的连接将在大约11分钟以后将被丢弃。(对于普通应用来说,这个值有一些偏大,可以根据需要改小.特别是web类服务器需要改小该值,15是个比较合适的值)

tcp_retries1 ：INTEGER
默认值是3
放弃回应一个TCP连接请求前﹐需要进行多少次重试。RFC 规定最低的数值是3﹐这也是默认值﹐根据RTO的值大约在3秒 - 8分钟之间。(注意:这个值同时还决定进入的syn连接)

tcp_retries2 ：INTEGER
默认值为15
在丢弃激活(已建立通讯状况)的TCP连接之前﹐需要进行多少次重试。默认值为15，根据RTO的值来决定，相当于13-30分钟(RFC1122规定，必须大于100秒).(这个值根据目前的网络设置,可以适当地改小,我的网络内修改为了5)

tcp_orphan_retries ：INTEGER
默认值是7
在近端丢弃TCP连接之前﹐要进行多少次重试。默认值是7个﹐相当于 50秒 - 16分钟﹐视 RTO 而定。如果您的系统是负载很大的web服务器﹐那么也许需要降低该值﹐这类 sockets 可能会耗费大量的资源。另外参的考 tcp_max_orphans 。(事实上做NAT的时候,降低该值也是好处显著的,我本人的网络环境中降低该值为3)

tcp_fin_timeout ：INTEGER
默认值是 60
对于本端断开的socket连接，TCP保持在FIN-WAIT-2状态的时间。对方可能会断开连接或一直不结束连接或不可预料的进程死亡。默认值为 60 秒。过去在2.2版本的内核中是 180 秒。您可以设置该值﹐但需要注意﹐如果您的机器为负载很重的web服务器﹐您可能要冒内存被大量无效数据报填满的风险﹐FIN-WAIT-2 sockets 的危险性低于 FIN-WAIT-1 ﹐因为它们最多只吃 1.5K 的内存﹐但是它们存在时间更长。另外参考 tcp_max_orphans。(事实上做NAT的时候,降低该值也是好处显著的,我本人的网络环境中降低该值为30)

tcp_max_tw_buckets ：INTEGER
默认值是180000
系统在同时所处理的最大 timewait sockets 数目。如果超过此数的话﹐time-wait socket 会被立即砍除并且显示警告信息。之所以要设定这个限制﹐纯粹为了抵御那些简单的 DoS 攻击﹐千万不要人为的降低这个限制﹐不过﹐如果网络条件需要比默认值更多﹐则可以提高它(或许还要增加内存)。(事实上做NAT的时候最好可以适当地增加该值)

tcp_tw_recycle ：BOOLEAN
默认值是0
打开快速 TIME-WAIT sockets 回收。除非得到技术专家的建议或要求﹐请不要随意修改这个值。(做NAT的时候，建议打开它)

tcp_tw_reuse：BOOLEAN
默认值是0
该文件表示是否允许重新应用处于TIME-WAIT状态的socket用于新的TCP连接(这个对快速重启动某些服务,而启动后提示端口已经被使用的情形非常有帮助)

tcp_max_orphans ：INTEGER
缺省值是8192
系统所能处理不属于任何进程的TCP sockets最大数量。假如超过这个数量﹐那么不属于任何进程的连接会被立即reset，并同时显示警告信息。之所以要设定这个限制﹐纯粹为了抵御那些简单的 DoS 攻击﹐千万不要依赖这个或是人为的降低这个限制(这个值Redhat AS版本中设置为32768,但是很多防火墙修改的时候,建议该值修改为2000)

tcp_abort_on_overflow ：BOOLEAN
缺省值是0
当守护进程太忙而不能接受新的连接，就象对方发送reset消息，默认值是false。这意味着当溢出的原因是因为一个偶然的猝发，那么连接将恢复状态。只有在你确信守护进程真的不能完成连接请求时才打开该选项，该选项会影响客户的使用。(对待已经满载的sendmail,apache这类服务的时候,这个可以很快让客户端终止连接,可以给予服务程序处理已有连接的缓冲机会,所以很多防火墙上推荐打开它)

tcp_syncookies ：BOOLEAN
默认值是0
只有在内核编译时选择了CONFIG_SYNCOOKIES时才会发生作用。当出现syn等候队列出现溢出时象对方发送syncookies。目的是为了防止syn flood攻击。
注意：该选项千万不能用于那些没有收到攻击的高负载服务器，如果在日志中出现synflood消息，但是调查发现没有收到synflood攻击，而是合法用户的连接负载过高的原因，你应该调整其它参数来提高服务器性能。参考:
tcp_max_syn_backlog
tcp_synack_retries
tcp_abort_on_overflow
syncookie严重的违背TCP协议，不允许使用TCP扩展，可能对某些服务导致严重的性能影响(如SMTP转发)。(注意,该实现与BSD上面使用的tcp proxy一样,是违反了RFC中关于tcp连接的三次握手实现的,但是对于防御syn-flood的确很有用.)

tcp_stdurg ：BOOLEAN
默认值为0
使用 TCP urg pointer 字段中的主机请求解释功能。大部份的主机都使用老旧的 BSD解释，因此如果您在 Linux 打开它﹐或会导致不能和它们正确沟通。

tcp_max_syn_backlog ：INTEGER
对于那些依然还未获得客户端确认的连接请求﹐需要保存在队列中最大数目。对于超过 128Mb 内存的系统﹐默认值是 1024 ﹐低于 128Mb 的则为 128。如果服务器经常出现过载﹐可以尝试增加这个数字。警告﹗假如您将此值设为大于 1024﹐最好修改 include/net/tcp.h 里面的 TCP_SYNQ_HSIZE ﹐以保持 TCP_SYNQ_HSIZE*16<=tcp_max_syn_backlog ﹐并且编进核心之内。(SYN Flood攻击利用TCP协议散布握手的缺陷，伪造虚假源IP地址发送大量TCP-SYN半打开连接到目标系统，最终导致目标系统Socket队列资源耗尽而无法接受新的连接。为了应付这种攻击，现代Unix系统中普遍采用多连接队列处理的方式来缓冲(而不是解决)这种攻击，是用一个基本队列处理正常的完全连接应用(Connect()和Accept() )，是用另一个队列单独存放半打开连接。这种双队列处理方式和其他一些系统内核措施(例如Syn-Cookies/Caches)联合应用时，能够比较有效的缓解小规模的SYN Flood攻击(事实证明<1000p/s)加大SYN队列长度可以容纳更多等待连接的网络连接数，所以对Server来说可以考虑增大该值.)

tcp_window_scaling ：INTEGER
缺省值为1
该文件表示设置tcp/ip会话的滑动窗口大小是否可变。参数值为布尔值，为1时表示可变，为0时表示不可变。tcp/ip通常使用的窗口最大可达到 65535 字节，对于高速网络，该值可能太小，这时候如果启用了该功能，可以使tcp/ip滑动窗口大小增大数个数量级，从而提高数据传输的能力(RFC 1323)。（对普通地百M网络而言，关闭会降低开销，所以如果不是高速网络，可以考虑设置为0）

tcp_timestamps ：BOOLEAN
缺省值为1
Timestamps 用在其它一些东西中﹐可以防范那些伪造的 sequence 号码。一条1G的宽带线路或许会重遇到带 out-of-line数值的旧sequence 号码(假如它是由于上次产生的)。Timestamp 会让它知道这是个 '旧封包'。(该文件表示是否启用以一种比超时重发更精确的方法（RFC 1323）来启用对 RTT 的计算；为了实现更好的性能应该启用这个选项。)

tcp_sack ：BOOLEAN
缺省值为1
使用 Selective ACK﹐它可以用来查找特定的遗失的数据报--- 因此有助于快速恢复状态。该文件表示是否启用有选择的应答（Selective Acknowledgment），这可以通过有选择地应答乱序接收到的报文来提高性能（这样可以让发送者只发送丢失的报文段）。(对于广域网通信来说这个选项应该启用，但是这会增加对 CPU 的占用。)

tcp_fack ：BOOLEAN
缺省值为1
打开FACK拥塞避免和快速重传功能。(注意，当tcp_sack设置为0的时候，这个值即使设置为1也无效)

tcp_dsack ：BOOLEAN
缺省值为1
允许TCP发送"两个完全相同"的SACK。

HASH表和SYN计算的TCP会话重组--理论

wentaiyou@126.com(kevin) — Wed,13 Apr 2011 12:33:42 +0800

在网站看到一个关于TCP会话重组的理论文章感觉适用转下来以便后续研究

本文提出一种基于HASH表和SYN计算的TCP会话重组方法，它利用HASH表快速定位的特征和TCP包头中的SYN进行多连接TCP会话重组，可解决IP数据包乱序到达和TCP数据包重传问题。

一、引言

    在网络安全领域，TCP会话重组是一个必须解决的关键技术，它广泛应用在入侵检测系统、病毒监控系统、远程监控系统等产品中。只有重组后的数据包才能成为程序可理解的信息，从而对其进行监控。当前大部分入侵检测系统都实现了高效的TCP会话重组，它的难点在于解决多连接问题、IP包乱序到达和TCP会话重传问题。笔者在实际工程经验中摸索了一种基于HASH表和SYN计算的TCP会话重组方法。

二、TCP会话重组

    传输控制协议TCP（Transmission Control Protocol，RFC 793，RFC 1122，RFC 813，RFC 816，RFC 879，RFC 896，RFC 889，RFC 964）是一个在网络中提供主机到主机高可靠性通信的协议，根据RFC793规定，TCP头的结构如图1所示：

    图1 TCP包首部

    RFC793中规定，TCP头中的序号（Sequence Number）用于指定该数据包在整个会话中的位置，该序号是TCP会话重组的关键。

    图2 TCP会话重组流程

    图2中描述的流程简单地说明了利用HASH表和SYN计算进行TCP会话重组的过程，最终程序将每一个会话完整地保存到不同的文件中。在重组过程中，程序主要用到了两种关键技术：“HASH表”和TCP会话文件写指针“SYN计算”方法。“HASH表”解决了同时处理多个TCP会话的问题。“SYN计算”可以快速地计算TCP会话写入重组数据文件的位置，同时可以有效地解决IP包乱序到达和TCP会话重传问题。

    1.HASH表

    由于程序经常需要同一时刻监控多个TCP会话数据包，这些数据包掺杂在一起，因而程序在进行会话重组时需要同时处理这些不同连接的TCP包。为达到这个目的，我们采用一个HASH表来记录不同的连接信息。HASH表每个节点内包含以下信息：

     ■ TCP_Session_IDT：TCP会话标识。由TCP协议可知，每个TCP会话由源IP地址、目的IP地址、源TCP端口号和目的TCP端口号惟一标识，我们的TCP会话标识也由这四个元素组成，HASH表查找也是基于这四个元素实现。

    ■ File_IDT：文件标识。将不同TCP会话数据保存在不同名的重组数据文件内，因此每个会话都有一个文件标识相对应。

    ■ File_Init_Write_Pointer：写文件初始指针。该初始指针并不表示每个重组数据文件由此指针指向的位置开始写，而是用来计算后续文件指针的。

    ■ File_Last_Visit_time：文件最近一次被访问的时间，用于计算TCP会话超时。基于现有网络状况的考虑，TCP会话超时是不可避免的情况，应当有专门的机制来对此进行处理。我们设置了一个专门的进程来判断TCP会话是否超时，当某个文件长时间没有被访问则说明该文件对应的TCP会话已经超时，可以结束有关此会话的收集。

    利用HASH表快速查找定位的特性，我们解决了多个TCP会话同时处理的问题以及快速对多个会话进行处理的问题。

     2.SYN计算方法

    (1)Sequence Number

    本节将分析TCP头中Sequence Number在TCP数据传输过程中的作用。

    初始阶段，TCP连接刚建立时，会为后续TCP数据传输设定一个初始Sequence Number，本文用Init_Seq_NUM表示。每传送一个包含有效数据的TCP包，后续紧接着传送的TCP数据包Sequence Number会作相应的修改，如果前一个TCP包的长度为N字节，则这个包的Sequence Number为前一个包的Sequence Number加N字节。表1描述了这一过程。

    表1：TCP Sequence Number在TCP数据包传输过程中的作用。

    可以看出，Sequence Number是为了保证TCP数据包按序传输来设计的，可以有效地实现TCP数据的完整传送，特别是当数据传输出现错误时可以有效进行错误纠正。

    (2)TCP会话文件写指针SYN计算方法

    基于TCP头中的Sequence Number有一种简单而有效的TCP会话重组数据文件写指针的计算方法，在这里我们称之为SYN计算。本节将对此方法进行介绍。

    在将一个TCP包的数据内容写入到重组数据文件的时候，需要两个参数：数据长度Data Length和文件写指针Write Pointer。数据长度可以很方便地从数据包的IP头中提取，难点是如何计算TCP重组数据文件写指针。根据上文介绍的Sequence Number的作用，可利用这个值来计算写指针。

     ①记录初始Sequence Number，该值可以从携带SYN标记的TCP包中获得。

    ②用当前TCP包中的Sequence Number减去初始Sequence Number，再减去1（因为TCP SYN标记需要占用一个Sequence Number），即可以得到TCP重组数据文件的写指针Write Pointer。

     以上就是用来计算TCP重组数据文件写指针的SYN算法。即：

    ①File_Init_Write_Pointer = Init Sequence Number + 1；

    ②File_Write_Pointer = Current Sequence Number – File_Init_Write_Pointer。

    (3)特例问题

    本节分析用上述SYN算法如何实现有效处理IP数据包乱序到达和TCP数据包重传问题。

    ▲处理IP数据包乱序到达问题

    设正确的IP数据包到达顺序应该是：P1、P2、P3，对应的Sequence Number分别是：SYN1、SYN2、SYN3，有效TCP数据的大小为Len1、Len2、Len3。

     则有：SYN2 = SYN1 + LEN1，SYN3 = SYN2 + LEN2，在数据包按序到达的情况下，我们利用SYN算法可将各个TCP数据包内容正确地写入重组数据文件的对应位置。

    P1：写入从SYN1-File_Init_Write_Pointer位置到SYN1－File_Init_Write_Pointer + LEN1。

    P2：写入从SYN2-File_Init_Write_Pointer，即，SYN1 + LEN1 + - File_Init_Write_Pointer到SYN1 + LEN1 - File_Init_Write_Pointer + LEN2。

    P3：写入从SYN3-File_Init_Write_Pointer，即，SYN1 + LEN1 + LEN2 - File_Init_Write_Pointer到SYN1 + LEN1 + LEN2 - File_Init_Write_Pointer + LEN3。

    在数据包不能按序到达的情况下，设IP数据包到达的顺序为P1，P3，P2，可以发现重组数据的写入位置还是相同的，只是写入的先后不同，成了P1，P3，P2。因此，按照此种算法仍能将有效的TCP数据写入到重组数据文件的正确位置。

    ▲处理TCP数据包重传问题

    假设TCP数据传送方先传了四个TCP包TCP1、TCP2、TCP3、TCP4，Sequence Number分别为：SYN1、SYN2、SYN3、SYN4，长度分别为LEN1、LEN2、LEN3、LEN4。但是，TCP数据接收方要求从第二个TCP包开始重新传送，同时由于网络原因重传的数据包大小发生了变化，分别为：LEN2’，LEN3’，LEN4’，并有LEN2 + LEN3 + LEN4 = LEN2’ + LEN3’+ LEN4’，三个新TCP包的Sequence Number分别为：SYN1 + LEN1，SYN1 + LEN1 + LEN2’， SYN1 + LEN1 + LEN2’ + LEN3’。

    根据SYN计算法可得，第一次传输的四个数据包写入TCP重组文件的位置分别为：

    TCP1：写入位置为SYN1-File_Init_Write_Pointer到SYN1－File_Init_Write_Pointer + LEN1。

    TCP2：写入位置为SYN2-File_Init_Write_Pointer，即，SYN1 + LEN1 + - File_Init_Write_Pointer到SYN1 + LEN1 - File_Init_Write_Pointer + LEN2。

    TCP3：写入位置为SYN3-File_Init_Write_Pointer，即，SYN1 + LEN1 + LEN2 - File_Init_Write_Pointer到SYN1 + LEN1 + LEN2 - File_Init_Write_Pointer + LEN3。

    TCP4：写入位置为SYN4-File_Init_Write_Pointer，即，SYN1 + LEN1 + LEN2 + LEN3 - File_Init_Write_Pointer到SYN1 + LEN1 + LEN2 + LEN3 - File_Init_Write_Pointer + LEN4。

    当发生TCP包重传时，程序将从第二个TCP包开始重新写重组数据文件。此时的情况为：

    TCP2’：写入位置为SYN1 + LEN1 - File_Init_Write_Pointer到SYN1 + LEN1 - File_Init_Write_Pointer + LEN2’。

    TCP3’：写入位置为SYN1 + LEN1 + LEN2’ - File_Init_Write_Pointer到SYN1 + LEN1 + LEN2’ - File_Init_Write_Pointer + LEN3’。

    TCP4’：写入位置为SYN1 + LEN1 + LEN2’ + LEN3’ - File_Init_Write_Pointer到SYN1 + LEN1 + LEN2’ + LEN3’ - File_Init_Write_Pointer + LEN4’。

    由于LEN2 + LEN3 + LEN4 = LEN2’ + LEN3’ + LEN4’，因此各数据包在TCP重组数据文件中写入的最终位置两次是相同的，即实现了正确覆盖。

三、结束语

    经反复测试我们发现：利用HASH表可以快速实现对多个会话的处理；利用SYN算法可以成功实现TCP会话的恢复，并可以有效地解决IP数据包的乱序到达和TCP数据包的重传问题，误差率非常小且重组效率很高。

Mysql-5.x上的插入空值BUG

wentaiyou@126.com(kevin) — Fri,21 Jan 2011 23:05:30 +0800

这种问题一般mysql 5.x上出现。我用的mysql5.1，后面查询得知新版本mysql对空值插入有"bug",要在安装mysql的时候去除默认勾选的enable strict SQL mode。如果已经安装好了的，就在my.ini中查找sql-mode，默认为sql-mode="STRICT_TRANS_TABLES,NO_AUTO_Create_USER,NO_ENGINE_SUBSTITUTION"，将其修改为sql-mode="NO_AUTO_Create_USER,NO_ENGINE_SUBSTITUTION"，重启mysql后即可。

报错提示:
1366 - Incorrect integer value: '' for column 'id' at row

解决办法:
找到MY.INI文件将原先下面这句
sql-mode="STRICT_TRANS_TABLES,NO_AUTO_Create_USER,NO_ENGINE_SUBSTITUTION"
换成如下:
sql-mode="NO_AUTO_Create_USER,NO_ENGINE_SUBSTITUTION"

PHP-38条PHP编码优化加速技巧

wentaiyou@126.com(kevin) — Mon,27 Dec 2010 15:21:53 +0800

1. 尽量采用大量的PHP内置函数。
2. echo 比 print 快。
3. 不要把方法细分得过多，仔细想想你真正打算重用的是哪些代码？
4. 在执行for循环之前确定最大循环数，不要每循环一次都计算最大值。
5. 注销那些不用的变量尤其是大数组，以便释放内存。
6. 并非要用类实现所有的数据结构，数组也很有用。
7.  $row[‘id’]的效率是$row[id]的7倍。
8. 在包含文件时使用完整路径，解析操作系统路径所需的时间会更少。
9. 如果你想知道脚本开始执行（译注：即服务器端收到客户端请求）的时刻，使用$_SERVER[‘REQUEST_TIME’]要好于time()。
10. 检查是否能用strncasecmp，strpbrk，stripos函数代替正则表达式完成相同功能。
11. str_replace函数比preg_replace函数快，但strtr函数的效率是str_replace函数的四倍。
12. 如果一个字符串替换函数，可接受数组或字符作为参数，并且参数长度不太长，那么可以考虑额外写一段替换代码，使得每次传递参数是一个字符，而不是只写一行代码接受数组作为查询和替换的参数。
13. 使用选择分支语句（译注：即switch case）好于使用多个if，else if语句。
14. 用@屏蔽错误消息的做法非常低效。
15.  打开apache的mod_deflate模块。
16.  数据库连接当使用完毕时应关掉。
18.  错误消息代价昂贵。
19. 尽量不要在for循环中使用函数，比如for ($x=0; $x < count($array); $x)每循环一次都会调用count()函数。
20.  在方法中递增局部变量，速度是最快的。几乎与在函数中调用局部变量的速度相当。
21.  递增一个全局变量要比递增一个局部变量慢2倍。
22.  递增一个对象属性（如：$this->prop++）要比递增一个局部变量慢3倍。
23.  递增一个未预定义的局部变量要比递增一个预定义的局部变量慢9至10倍。
24.   仅定义一个局部变量而没在函数中调用它，同样会减慢速度（其程度相当于递增一个局部变量）。PHP大概会检查看是否存在全局变量。
25. 方法调用看来与类中定义的方法的数量无关，因为我（在测试方法之前和之后都）添加了10个方法，但性能上没有变化。
26. 派生类中的方法运行起来要快于在基类中定义的同样的方法。
27. 调用带有一个参数的空函数，其花费的时间相当于执行7至8次的局部变量递增操作。类似的方法调用所花费的时间接近于15次的局部变量递增操作。
28. 用单引号代替双引号来包含字符串，这样做会更快一些。因为PHP会在双引号包围的字符串中搜寻变量，单引号则不会。当然，只有当你不需要在字符串中包含变量时才可以这么做。
29. 用echo 输出多个字符串时，用逗号代替句点来分隔字符串，速度更快。
30. Apache解析一个PHP脚本的时间要比解析一个静态HTML页面慢2至10倍。尽量多用静态HTML页面，少用脚本。
31. 除非脚本可以缓存，否则每次调用时都会重新编译一次。引入一套PHP缓存机制通常可以提升25%至100%的性能，以免除编译开销。
32. 尽量做缓存，可使用memcached。memcached是一款高性能的内存对象缓存系统，可用来加速动态Web应用程序，减轻数据库负载。对运算码(OP code)的缓存很有用，使得脚本不必为每个请求做重新编译。
33. 当操作字符串并需要检验其长度是否满足某种要求时，你想当然地会使用strlen()函数。此函数执行起来相当快，因为它不做任何计算，只返回在zval 结构（C的内置数据结构，用于存储PHP变量）中存储的已知字符串长度。但是，由于strlen()是函数，多多少少会有些慢，因为函数调用会经过诸多步骤，如字母小写化（译注：指函数名小写化，PHP不区分函数名大小写）、哈希查找，会跟随被调用的函数一起执行。在某些情况下，你可以使用isset() 技巧加速执行你的代码。
Ex.（举例如下）
if (strlen($foo) < 5) { echo “Foo is too short”; }
vs.（与下面的技巧做比较）
if (!isset($foo{5})) { echo “Foo is too short”; }
调用isset()恰巧比strlen()快，因为与后者不同的是，isset()作为一种语言结构，意味着它的执行不需要函数查找和字母小写化。也就是说，实际上在检验字符串长度的顶层代码中你没有花太多开销。
34. 当执行变量$i的递增或递减时，$i++会比++$i慢一些。这种差异是PHP特有的，并不适用于其他语言，所以请不要修改你的C或Java代码并指望它们能立即变快，没用的。++$i更快是因为它只需要3条指令(opcodes)，$i++则需要4条指令。后置递增实际上会产生一个临时变量，这个临时变量随后被递增。而前置递增直接在原值上递增。这是最优化处理的一种，正如Zend的PHP优化器所作的那样。牢记这个优化处理不失为一个好主意，因为并不是所有的指令优化器都会做同样的优化处理，并且存在大量没有装配指令优化器的互联网服务提供商（ISPs）和服务器。
35. 并不是事必面向对象(OOP)，面向对象往往开销很大，每个方法和对象调用都会消耗很多内存。
36. 如果在代码中存在大量耗时的函数，你可以考虑用C扩展的方式实现它们。
37. 评估检验(profile)你的代码。检验器会告诉你，代码的哪些部分消耗了多少时间。Xdebug调试器包含了检验程序，评估检验总体上可以显示出代码的瓶颈。
38. mod_zip可作为Apache模块，用来即时压缩你的数据，并可让数据传输量降低80%。

Centos Permission denied: http错误

wentaiyou@126.com(kevin) — Sat,18 Dec 2010 14:06:03 +0800

CentOS 下启动Httpd 失败，报

(13)Permission denied: make_sock: could not bind to address [::]:8000

因为小于1024 的端口只能是ROOT占用，但8000已经大于这个数值。

Google 一下，发现原来是 SELinux  安全机制的作用。

  查看一下预定义

  #semanage port -l

http_cache_port_t              tcp      3128, 8080, 8118, 11211, 10001-10010
http_cache_port_t              udp      3130, 11211
http_port_t                         tcp      80, 443, 488, 8008, 8009, 8443

soundd_port_t                  tcp      8000, 9433, 16001

原来8000 已经被预定义占用了，所有不能使用8000端口。

  # semanage port -a -t http_port_t -p tcp 81

为Http 服务增加一个端口 81 ，同时将httpd 的端口改成 81 ，启动成功。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/maoxiang/archive/2010/07/08/5720464.aspx

LINUX-多网卡识别顺序的问题

wentaiyou@126.com(kevin) — Tue,14 Dec 2010 22:31:32 +0800

参考：
使用linux系统时会出现这样的情况，当你安装了某个网卡的驱动程序时，或者安装了与网卡相关的程序后。

网卡会出现所谓的漂移现象。(注意：不是飘逸)。可能的表象为:

（1）:网卡顺序颠倒，比如之前你的网线连接的网口为eth0,当安装某个网卡的驱动后，可能它的名字变为eth0或者eth3,等等情况。

(2):网卡名字改变，这种情况倒不是eth0到eth1的改变，而是很诡异的变化，比如eth0找不到了，多了个网卡名字叫 __tmp3183921382193__

这个确实让人很恼火。因为有人可能会通过ifconfig | grep eth来获取信息从而完成一些开发工作，如果网卡名字变得乌七八糟了，程序肯定会出错。

(3):光口网卡和电口网卡顺序乱了，或者交叉。

总之我们的目的就是：能够指定某个网卡的名字为我们想要的物理设备。做法如下:

第一步，识别谁是谁。

要使用网卡，首现要知道哪个名字对应的哪个物理设备，做法为:从交换机拉一根网线，从上到下挨个接到网卡上面，注意每次只能接一个网卡，接上后通过ethtool命令来查看是否连着网线，比如

[root@AS5 ~]# ethtool eth0
Settings for eth0:
Supported ports: [ MII ]
Supported link modes:   10baseT/Half 10baseT/Full
                         100baseT/Half 100baseT/Full
                         1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes:  10baseT/Half 10baseT/Full
                         100baseT/Half 100baseT/Full
                         1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 2
Transceiver: external
Auto-negotiation: on
Supports Wake-on: g
Wake-on: d
Link detected: yes

看到了eth0的状态为连接着网线。如果Linked detected:no,则说明没有连接网线。

如此区分开哪个设备的名字是什么，标注好。

第二步：获取每个网卡的MAC地址

ifconfig -a能看到所有网络设备。

通过 ifconfig -a | grep HWaddr 来获取每个设备的MAC地址。

比如:

[root@AS5 ~]# ifconfig  -a | grep HWaddr
eth0      Link encap:Ethernet  HWaddr 00:30:48:7F:B5:CA
eth1      Link encap:Ethernet  HWaddr 00:30:48:7F:B5:CB
eth2      Link encap:Ethernet  HWaddr 00:04:23:A6:81:E0
eth3      Link encap:Ethernet  HWaddr 00:04:23:A6:81:E1

拿到了每个网卡的MAC地址。

第三步：进行MAC和网卡名称绑定。

我们都知道，对于RedHat的系统，网络的配置文件在:/etc/sysconfig/network-scripts/ifcfg-ethX

中存着，N=0，1，2。。。

比如:root@AS5 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
# nVidia Corporation MCP55 Ethernet
DEVICE=eth0
ONBOOT=yes
HWADDR=00:30:48:7f:b5:ca
TYPE=Ethernet
NETMASK=255.255.255.0
IPADDR=192.168.42.231
GATEWAY=192.168.42.1
BOOTPROTO=static
#NAMESERVER=202.106.0.20

这个文件是对网卡进行初始化的配置文件。

比如如果我们想指定网卡MAC地址为MAC1的设备名称为ethn,那么，修改文件

/etc/sysconfig/network-scripts/ifcfg-ethn

在里面添加MAC地址绑定和名字的配置信息

DEVICE=ethn

HWADDR=MAC1（比如00:30:48:7f:b5:ca）

其它配置信息不受影响。

当对所有网卡实现绑定后，reboot系统，应该就可以了。

还有一点需要注意，就是驱动对应关系的文件:

/etc/modprobe.conf

要在该文件中修改，确保某个设备使用的就是对应它的驱动，比如:

cat /etc/modprobe.conf
alias eth0 forcedeth
alias eth1 forcedeth
alias scsi_hostadapter aic79xx
alias scsi_hostadapter1 sata_nv
alias scsi_hostadapter2 usb-storage
alias eth2 e1000
alias eth3 e1000

说明eth0和eth1用的forcedeth的驱动，eth2和eth3用的是e1000的驱动。