作为www的传输协议，HTTP很简单：client与remote server建立connection，然后发送request，server处理这个request，返回response，然后关闭这个connection。

但是这个如此简单的过程存在着一些问题：

先看request:

GET /index.html HTTP/1.0 /*表明动作是GET,要获取的东东是/index.html*/
Accept: text/plain /*这里可以有n多的headers,在rfc822里有说明*/
Accept: text/html
Accept: */*
User-Agent: OnlyVC-1.0 /*客户端的实现名称*/

server给出response:

HTTP/1.0 200 OK
Server: MDMA/0.1
MIME-version: 1.0
Content-type: text/html
Last-Modified: Tue Mar 11 00:25:33 2008
Content-Length: 2003
/*注意,这里一定要有一个空行!*/
<title>OnlyVC.cn</title>
<h1> welcome to OnlyVC.cn </h1>.....

OK，到此为止，做web的人肯定都知道

Next，我们可以借助像tcpdump等工具去看看HTTP，限于篇幅这里不粘贴数据了，我们可以把一个过程分成6个stage，在这个过程中需要注意一个重要的衡量指标：Round Trip Time（RTT），这个值时说一个packet从一端发送到另一端，然后再回来所用的时间。但是TCP有个很怪的毛病，简单来说就是建立连接时是先发几个小packet测测速度，然后再开始传输数据，这个过程叫做Slow Start。

HTTP1.1是不需要等待一个packet发送过去然后被确认（acknowledged）了再发送下一个packet的，我们可以发送一个packet，不管它如何，再发送下一个。

对于RFC里2 connection per hostname的设计在当时是合乎情理的，但是对于现在的Internet应用来说，已经远远不够了。但是反过来，作为一个website的开发者来看，对于一个页面使用的resources分布到多个hostname上还是有必要的，但是这个hostname的数量最好在2~4个为宜。如果页面有大量resources需要引用，尤其是对于产品较多的集合型网站，cookie的大小还是比较可观的，如果我们所有的内容都来自于一个域，假设1个页面有30张图片，cookie大小为20k，那就是有30*20=600k的东西被做了一次没用的传输，分布在其他hostname后是减少cookie-taking的一个好办法，因为cookie是有作用域的。