PHPChina网友需求：123.badu.com 自动转向www.baidu.com/123 并且保持域名还是123.baidu.com
地址：http://bbs.phpchina.com/thread-169014-1-1.html
经过摸索，终于找到了实现方法，就是通过使用Apache的Rewrite和Proxy实现跨主机透明转发，不改变地址栏的URL网址。
下面是实现步骤：
1. 在123.baidu.com的.htaccess文件中开启重写规则：
RewriteEngine On
RewriteRule ^(.*)$ http://www.baidu.com/123/$1 [P,L]
2. 在Apache的配置文件中开启以下模块：
mod_rewrite.so
mod_proxy.so
mod_proxy_http.so
3. 重启Apache服务器，载入最新的配置。
转载自：http://hi.baidu.com/fising/blog/item/54fa5bafbd1840f0faed507e.html
上一部分"流程简介"， 我们大致了解了下HTTP请求的流程，这一篇我向大家介绍下如何利用Telnet来模拟Http请求---访问百度。
我们直接开始吧！
1、打开"运行"->cmd进入命令环境；
2、输入"telnet www.baidu.com 80"，回车后 ,屏幕为全黑，此时我们利用快捷键"Ctrl+](右中括号)"来打开本地回显功能，这样我们就可以看见我们所打的东西了，如图：（注本阶段执行过程和以 下的过程均要求操作时间尽可能短，因为时间一长，便会被认为断开连接。）
3、单击回车，进行编辑状态。
4、输入："GET / HTTP/1.1"后回车,在第二段接着输入："HOST:"然后按回车，这样一个简单的HTTP请求就完成了，接着我人只要再按下回车，便向服务器递交 这个请求了。如图：（我们来看一下这个是什么意思：GET表示请求方式，/表示请求的根目录下的文件，HTTP/1.1表示HTTP协议版本，HOST就 是一个消息头，据某些朋友说1.1的版本一定要加一个"HOST:"可是我实验后发现"HOST :"不加仍旧可以正常发送请求，但是GET HTTP这个必须大写，否则就该请求无法发送）
5、接收服务器返回，这步其实不需要我们来做，因为当我们发送请求后，只需几秒钟，我们便会收到来自服务器反应.
怎么样，大家会了吗？以上只是用GET方式进行请求，当然还可以用POST方式进行请求，只是POST我这不方便做实验，所以就不写了。大概的格式给大家参考下：
POST /localhost/login.aspx HTTP/1.1
HOST:
Content-Type:application/x-www-form-urlencoded
Content-Length:10
uid=xxxxxx
参考：
1.张孝祥老师的HTTP协议详解
2.关于HTTP的请求头可以参考：http://hi.baidu.com/Ê«Õ¹/blog/item/13c2e3ddb3a133ee77c638cd.html
小转一篇，出处未知。
前言：经常检查Apache的连接数，同样会发现很多无用的Time_Wait连接。有人说这是正常的，是因为一个请求中途中断造成的;还有人说微 软的 IE连接时产生的Time_wait会比用Firefox连接时多。个人认为有一定的Time_wait是正常的，如果超过了连接数的比例就不是很 正常，所以还是找来方法解决一下。
检查net.ipv4.tcp_tw当前值，将当前的值更改为1分钟：
[root@aaa1 ~]# sysctl -a|grep net.ipv4.tcp_tw
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_tw_recycle = 0
[root@aaa1 ~]#
vi /etc/sysctl
增加或修改net.ipv4.tcp_tw值：
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
使内核参数生效：
[root@aaa1 ~]# sysctl -p
[root@aaa1 ~]# sysctl -a|grep net.ipv4.tcp_tw
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
设置这两个参数： reuse是表示是否允许重新应用处于TIME-WAIT状态的socket用于新的TCP连接； recyse是加速TIME-WAIT sockets回收
用netstat再观察正常
这里解决问题的关键是如何能够重复利用time_wait的值，我们可以设置时检查一下time和wait的值
#sysctl -a | grep time | grep wait
net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60
net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120
这样的现象实际是正常的，有时和访问量大有关，设置这两个参数： reuse是表示是否允许重新应用处于TIME-WAIT状态的socket用于新的TCP连接； recyse是加速TIME-WAIT sockets回收
说明：
net.ipv4.tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时，
[文章作者：张宴 本文版本：v1.1 最后修改：2007.07.27 转载请注明出处：http://blog.s135.com]
这两天搭建了一组Apache服务器，每台服务器4G内存，采用的是prefork模式，一开始设置的连接数太少了，需要较长的时间去响应用户的请求，后来修改了一下Apache 2.0.59的配置文件httpd.conf：
引用
# prefork MPM
# StartServers: number of server processes to start
# MinSpareServers: minimum number of server processes which are kept spare
# MaxSpareServers: maximum number of server processes which are kept spare
# MaxClients: maximum number of server processes allowed to start
# MaxRequestsPerChild: maximum number of requests a server process serves
StartServers 10
MinSpareServers 10
MaxSpareServers 15
ServerLimit 2000
MaxClients 2000
MaxRequestsPerChild 10000
查看httpd进程数（即prefork模式下Apache能够处理的并发请求数）：
Linux命令：
引用
ps -ef | grep httpd | wc -l
返回结果示例：
1388
表示Apache能够处理1388个并发请求，这个值Apache可根据负载情况自动调整，我这组服务器中每台的峰值曾达到过2002。
查看Apache的并发请求数及其TCP连接状态：
Linux命令：
引用
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
（这条语句是从新浪互动社区事业部技术总监王老大那儿获得的，非常不错）
返回结果示例：
LAST_ACK 5
SYN_RECV 30
ESTABLISHED 1597
FIN_WAIT1 51
FIN_WAIT2 504
TIME_WAIT 1057
其中的SYN_RECV表示正在等待处理的请求数；ESTABLISHED表示正常数据传输状态；TIME_WAIT表示处理完毕，等待超时结束的请求数。
关于TCP状态的变迁，可以从下图形象地看出：
点击在新窗口中浏览此图片
状态：描述
CLOSED：无连接是活动的或正在进行
LISTEN：服务器在等待进入呼叫
SYN_RECV：一个连接请求已经到达，等待确认
SYN_SENT：应用已经开始，打开一个连接
ESTABLISHED：正常数据传输状态
FIN_WAIT1：应用说它已经完成
FIN_WAIT2：另一边已同意释放
ITMED_WAIT：等待所有分组死掉
CLOSING：两边同时尝试关闭
TIME_WAIT：另一边已初始化一个释放
LAST_ACK：等待所有分组死掉
已经遇到过两次了，打开一片空白，没有任何提示。
1次是Discuz！首页打开时一片空白，但UCenter又可以打开，登录进后台stat index.php，发现文件的修改日期有问题，被修改日期是6月16日，论坛改版做好后，很久没有修改过这些文件了。估计是被人入侵了！网上有说是编码问题。难道别人把我文件的编码修改了？查看了下备份目录，刚好在6月13日有个备份，把它解压缩出来，覆盖掉原来的，一切恢复正常。
2次是朋友的一个很简单的站，打开是一个空白页面，对比过配置文件，发现跟其他站点的配置一样，怀疑会不会是程序不能在二级目录下运行，就把该主机的根目录设置为那二级目录，结果打开还是不行，又改回来，查看了Nginx的日志，没有错。最后去程序官方，重新下载了一个，直接在服务器上解压缩，再访问，一切正常。注意啊！估计是从Windows传文件上去时，文件出现的问题。无论是SFTP还是FTP，都记得要用binary（二进制）方式上传。这样是最保险的！