原创文档，转载请将原文url地址标明
我们介绍了很多的http等相关的工具，以及一些相关的东西， 那么http到底是什么？基本工作过程是什么？
http是一个协议，一个网络上传输数据的协议，可以用来传递文本，可以用来传递文件等等。
一．浅析HTTP协议
HTTP协议是什么？
为了方便理解，我们可以考虑一个例子，若是我们需要快递一个东西从北京到上海，我们比较简单的办法是：叫一个快递公司的，他们会上门来取东西。在取东西过程中，他会要求您将您的东西包装到一个包装箱或者包装袋等等一些容器中。 然后他还要您添一些单据，例如：邮寄的地址，收获人地址，电话等等。
若是上海收件方收到后，回复您一些东西，方法也同上面类似。
我们考虑：
1. 包裹中的东西，一般就是货物，是邮寄的主体
2. 包裹外边的表单是，方便货物周转的描述或者协助，放到外面，容易观察或者获取的，或者大家一看都明白的。
整个http过程就像北京邮寄东西到上海然后再从上海获得回寄的东西的全部过程。
整个过程包括两部：
A.北京寄东西到上海 邮寄人主动发起 可以叫做request
B.上海相关人员收到后，处理 然后回寄东西给你 叫做相应 response。
那么无论request及response都包括：数据的主体（包裹内的东西body）， 数据的描述信息（包裹外面的单据header）等。
下面我们来简要在描述一下http协议
简单来说，就是一个基于应用层的通信规范：双方要进行通信，大家都要遵守一个规范，这个规范就是HTTP协议。
HTTP协议能做什么？
很多人首先一定会想到：浏览网页。没错，浏览网页是HTTP的主要应用，但是这并不代表HTTP就只能应用于网页的浏览。HTTP是一种协议，只要通信的双方都遵守这个协议，HTTP就能有用武之地。比如咱们常用的QQ，迅雷这些软件，都会使用HTTP协议(还包括其他的协议)。
HTTP协议如何工作？
大家都知道一般的通信流程：首先客户端发送一个请求(request)给服务器，服务器在接收到这个请求后将生成一个响应(response)返回给客户端。
在这个通信的过程中HTTP协议在以下4个方 面做了规定：
1. Request和Response的格式
Request格式：
HTTP请求行
（请求）头
空行
可选的消息体
注：请求行和标题必须以<CR><LF>作为结尾（也就是，回车然后换 行）。空行内必须只有<CR><LF>而无其他空格。在HTTP/1.1 协议中，所有的请求头，除Host外，都是可选的。
实例：
GET / HTTP/1.1
Host: www.iigrowing.cn
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
If-Modified-Since: Mon, 25 May 2009 03:19:18 GMT
Response格 式：
HTTP状态行
（应答）头
空行
可选的消息体
实例：
HTTP/1.1 200 OK
Cache-Control: private, max-age=30
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Expires: Mon, 25 May 2009 03:20:33 GMT
Last-Modified: Mon, 25 May 2009 03:20:03 GMT
Vary: Accept-Encoding
Server: Microsoft-IIS/7.0
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Date: Mon, 25 May 2009 03:20:02 GMT
Content-Length: 12173
消息体的内容（略）
如上图是用httpwatch记录的一次典型http通讯过程。图中左侧 蓝色区域为request相关内容， 右侧红色区域为response相应内容。
其中两个黄色区域分别为 request及response的头部区域
其中两个绿色区域分别为request及response的body区域（消息体）
所有http的头部信息是不能省略的。 Body根据情况可以省略，例如request过程中经常根据需要省略信息，但是request若是提交表单一般就不能省略了。上传文件中body也不能省略了。
关于HTTP headers的简要介绍，请查看：Quick reference to HTTP headers
二． 建立连接的方式
HTTP支持2中建立连接的方式：非持久连接和持久连接(HTTP1.1默认的连接方式为持久连接)。
这两种连接方式的建立非常重要，但是涉及到很多内容，我们这里仅仅是简单介绍一下，大家可以看一下，了解一下，随着后面http相关工具及内容的逐步开展，对网络及tcp，http等知识的认识的提高，理解下面的事情就容易些了。到时候自然就明白了。
学习是需要一个过程，成长也是需要一个过程，重要的是每天进步一点点。
1) 非持久连接
非持久连接情况下从服务器到客户传送一个Web页面的步骤。假设该贝面由1个基本HTML文件和10个JPEG图像构成，而且所 有这些对象都存放在同一台服务器主机中。再假设该基本HTML文件的URL为：www.iigrowing.cnom/index.html。
下面是具体步骡:
1.HTTP客户初始化一个与服务器主机www.iigrowing.cnom中的HTTP服务器的TCP连接。HTTP服务器使用默认端口号80监听来自HTTP客户的连接建立 请求。
2.HTTP客户经由与TCP连接相关联的本地套接字发出—个 HTTP请求消息。这个消息中包含路径名/somepath/index.html。
3.HTTP服务器经由与TCP连接相关联的本地套接字接收这 个请求消息，再从服务器主机的内存或硬盘中取出对象/somepath/index.html，经由同一个套接字发出包含该对象的响应消息。
4.HTTP服务器告知TCP关闭这个TCP连接(不过TCP 要到客户收到刚才这个响应消息之后才会真正终止这个连接)。
5.HTTP客户经由同一个套接字接收这个响应消息。TCP连 接随后终止。该消息标明所封装的对象是一个HTML文件。客户从中取出这个文件，加以分析后发现其中有10个JPEG对象的引用。
6.给每一个引用到的JPEG对象重复步骡1-4。
上述步骤之所以称为使用非持久连接，原因是每次服务器发出一个对象后，相应的TCP连接就被关闭，也就是说每个连接都没有持续到可用于传送其他 对象。每个TCP连接只用于传输一个请求消息和一个响应消息。就上述例子而言，用户每请求一次那个web页面，就产生11个TCP连接。
2) 持久连接
非持久连接有些缺点。首先，客户得为每个待请求的对象建立并维护一个新的连接。对于每个这样的连接，TCP得在客户端和服务器端分配TCP缓冲区，并维持TCP变量。对于有可能同时为来自数百个不同 客户的请求提供服务的web服务器来说，这会严重增加其负担。其次，如前 所述，每个对象都有2个RTT的响应延长——一个RTT用于建立TCP连接，另—个RTT用于请求和接收对象。最后，每个对象都遭受TCP缓启动，因为每个TCP连接都起始于缓启动阶段。不过并行TCP连接的使用能够部分减 轻RTT延迟和缓启动延迟的影响。
在持久连接情况下，服务器在发出响应后让TCP连接继续打开 着。同一对客户/服务器之间的后续请求和响应可以通过这个连接发送。整个Web页面(上例中为包 含一个基本HTMLL文件和10个图像的页面)自不 用说可以通过单个持久TCP连接发送:甚至存放在同一个服务器中的多个web页面也可以通过单个持久TCP连接发送。通常，HTTP服务器在某个连接闲置一段特定时间后 关闭它，而这段时间通常是可以配置的。持久连接分为不带流水线(without pipelining)和带流水线(with pipelining)两个版本。如果是不带流水线的版本，那么客户只在收到前一个请求的响应后才发出新的请求。这种情况 下，web页面所引用的每个对象(上例中的10个图像)都经历1个RTT的延迟，用于请求和接收该对象。与非持久连接2个RTT的延迟相 比，不带流水线的持久连接已有所改善，不过带流水线的持久连接还能进一步降低响应延迟。不带流水线版本的另一个缺点是，服务器送出一个对象后开始等待下一 个请求，而这个新请求却不能马上到达。这段时间服务器资源便闲置了。
HTTP/1.1的默认模式使用带流水线的持久连接。这种情况下，HTTP客户每碰到一个引用就立即发出一个请求，因而HTTP客户可以一个接一个紧挨着发出各个引用对象的请求。服务器收到这些请求后，也可以一个接一个紧挨着发 出各个对象。如果所有的请求和响应都是紧挨着发送的，那么所有引用到的对象一共只经历1个RTT的延迟(而不是像不带流水线的版本那样，每个引用到的对象都各有1个RTT的延迟)。另外，带流水线的持久连接中服务器空等请求的时间比较少。与非持久连接相比，持久连接(不论是否带流水线)除 降低了1个RTT的响应延迟外，缓启动延迟也比较小。其原因在于既然各个对象使用同一个TCP连接，服务器发出第一个对象后就不必再以一开始的缓慢速率发送后续对象。相反，服务器可以按照第一 个对象发送完毕时的速率开始发送下一个对象。
