HTTP的请求报文结构和响应报文结构
HTTP请求报文主要由请求行、请求头、空行、请求正文（Get请求没有请求正文）4部分组成。
1、请求行
由三部分组成，分别为：请求方法、URL以及协议版本，之间由空格分隔；
请求方法包括GET、HEAD、PUT、POET、TRACE、OPTIONS、DELETE以及扩展方法，当然并不是所有的服务器都实现了所有的方法，部分方法即便支持，出于安全性的考虑也是不同的；
协议版本的格式为：HTTP/主版本号.次版本号，常用的有HTTP/1.0和HTTP/1.1；
2、请求头
请求头部为请求报文添加了一些附加信息，由“名/值”对组成，每行一对，名和值之间使用冒号分隔。
常见请求头如下：
3、空行
请求头的最后会有一个空行，表示请求头部结束，接下来为请求正文，这一行非常重要，必不可少。
4、请求正文
可选部分，比如GET请求就没有请求正文。
HTTP响应报文主要由状态行、响应头、空行、响应正文4部分组成。
1、状态行
由3部分组成，分别为：协议版本、状态码、状态码描述，之间由空格分隔；
2、响应头
与请求头类似，为响应报文添加一些附加信息。
常见响应头如下：
3、空行
4、响应正文
常见HTTP首部字段
A、通用首部字段（请求报文与响应报文都会使用的首部字段）
Date：创建报文时间
Connection：连接的管理
Cache-Control：缓存的控制
Transfer-Encoding：报文主体的传输编码方式，如Transfer-Encoding: chunked。
B、请求首部字段（请求报文会使用的首部字段）
Host：请求资源所在服务器
Accept：可处理的媒体类型
Accept-Charset：可接收的字符集
Accept-Encoding：可接受的内容编码
Accept-Language：可接受的自然语言
Referer：HTTP Referer是header的一部分，当浏览器向web服务器发送请求的时候，一般会带上Referer，告诉服务器我是从哪个页面链接过来的，服务器可以获得一些信息用于处理。比如从我主页上链接到一个朋友那里，他的服务器就能够从HTTP Referer中统计出每天有多少用户点击我主页上的链接访问他的网站。如果是CSRF攻击传来的请求，Referer字段会是包含恶意网址的地址，这时候服务器就能识别出恶意的访问。
C、响应首部字段（响应报文会使用的首部字段）
Accept-Ranges：可接受的字节范围
Location：另客户端重新定向到的URI
Server：HTTP服务器的安装信息
D、实体首部字段（请求报文与响应报文的实体部分使用的首部字段）
Allow：资源可支持的HTTP方法
Content-Type：实体主类的类型
Content-Encoding：实体主体适用的编码方式
Content-Language：实体主体的自然语言
Content-Length：实体主体的字节数
Content-Range：实体主体的位置范围
HTTP状态码含义
200 OK 服务器已成功处理了请求并提供了请求的网页。
202 Accepted 已经接受请求，但处理尚未完成。
204 No Content 没有新文档，浏览器应该继续显示原来的文档。
206 Partial Content 客户但进行了范围请求。响应报文中由Content-Range指定实体内容的范围。实现断点续传。
-----------------------------------------------------------------------------------------------------
301 Moved Permanently 永久性重定向。请求的网页已永久移动到新位置。
302（或307） Moved Temporatily 临时性重定向。请求的网页临时移动到新位置。
304 Not Modified 未修改。自从上次请求后，请求的内容未修改过。
-----------------------------------------------------------------------------------------------------
401 Unauthorized 客户试图未经授权访问受密码保护的页面。应答终会包含一个WWW-Authenticate头，浏览器据此显示用户名字/密码对话框，然后再填写合适的Authorization头后再次发出请求。
403 Forbidden 服务器拒绝请求。----------403.6-IP address rejected
404 Not Found 服务器上不存在客户机所请求的资源。
-----------------------------------------------------------------------------------------------------
500 Internal Server Error 服务器遇到一个错误，使其无法为请求提供服务。
HTTP中有关缓存的首部字段有哪些？HTTP的浏览器缓存机制？
1、Last-Modified和If-Modified-Since
简单地说，Last-Modified和If-Modified-Since都是用于记录页面最后修改时间的HTTP头信息，只是Last-Modified是由服务器王客户但发送的HTTP头，而If-Modified-Since则是由客户端往服务器发送的头，当再次请求本地存在的缓存页面时，客户端会通过If-Modified-Since头把浏览器缓存页面的最后一次被服务器修改的时间一起发到服务器去，服务器会把这个时间与服务器上实际文件的最后修改时间进行比较，通过这个时间戳判断客户端的页面是否是最新的，如果不是最新的，就返回HTTP状态码200和新文件内容，客户端收到之后，会丢弃旧文件，把新文件缓存起来，并显示到浏览器中；如果是最新的，则返回304告诉客户端其本地缓存的页面是最新的，就直接把本地缓存文件显示到浏览器中，这样在网络上传输的数据量就会大大减少，同时也减轻了服务器的负担。
1）什么是“Last-Modified”
在浏览器第一次请求某一个URL时，服务器端的返回状态是200，内容是你请求的资源，同时有一个Last-Modified的属性标记此文件在服务器端最后被修改的时间，格式类似这样：Last-Modified:Fri, 12 May 2010 18:53:33 GMT
客户端第二次请求此URL时，浏览器会向服务器传送If-Modified-Since报头，询问该时间之后文件是否有被修改过：If-Modified-Since: Fri, 12 May 2010 18:53:33 GMT
如果服务器的资源没有变化，则自动返回HTTP 304状态码，内容为空，这样就节省了传输数据量。当服务器端代码发生改变或者重启服务器时，则重新发出资源，返回和第一次请求时类似，从而保证不向客户端重复发出资源，也保证当服务器有变化时，客户端能够得到最新的资源。
2、ETag和 If-None-Match
ETag和 If-None-Match是一种常用的判断资源是否改变的方法。类似于Last-Modified和If-Modified-Since。但是有所不同的是Last-Modified和If-Modified-Since只判断资源的最后修改时间，而ETag和 If-None-Match可以是资源的任何属性，比如资源的MD5等。
ETag和 If-None-Match的工作原理是在HTTP Response中添加ETags信息。当客户端再次请求该资源时，将在HTTP Request中加入If-None-Match信息（也就是ETags的值）。如果服务器验证资源的ETags没有改变（该资源的内容没有改变），将返回一个304状态；否则，服务器将返回200状态，并返回该资源和新的ETags。
1）什么是“ETag”？
服务器为每个资源分配对应的ETag值，根据资源的内容得到其值。当资源内容发生改变时，其值也会改变。以下是服务器端返回的格式：
ETag:"50b1c1d4f775c61:df3"
客户端的查询更新格式是这样的：
If-None-Match:W/"50b1c1d4f775c61:df3"
如果ETag没有改变，则返回状态304，这也和Last-Modified一样。
扩展1：Last-Modified和ETags如何帮助提高性能？
聪明的开发者会把Last-Modified和ETags请求的HTTP报头一起使用，这样可利用客户端的缓存。因为服务器首先产生Last-Modified/Etag标记，服务器可在稍后使用它来判断页面是否已经被修改。本质上，客户端通过将该记号传回服务器要求服务器验证其（客户但）缓存。
扩展2：既然有了Last-Modified，为什么还要用ETag字段呢？
1）某些文件修改非常频繁，比如在秒以下的时间内进行修改，If-Modified-Since能检查到的粒度是秒级的，这种修改无法体现。
2）一些文件也许会周期性的更改，但是它的内容并不改变（仅仅改变修改的时间），这个时候我们并不希望客户端认为这个文件被修改了，而重新GET；
3）某些服务器不能精确的得到文件的最后修改时间。
因此，HTTP/1.1利用Entity Tag 头提供了更加严密的验证。Last-Modified与ETag一起使用时，服务器会优先验证ETag的值。
3、Expires/Cache-Control（优先使用）
用来控制缓存的失效日期，控制浏览器是直接从浏览器缓存取数据还是重新发请求到服务器取数据。
Expires是web服务器响应消息头字段，在响应HTTP请求时告诉浏览器在过期时间前浏览器可以直接从浏览器缓存取数据，而无需再次请求。Expires的一个缺点是，返回的到期时间是服务器端的时间。这样就存在一个问题，如果客户端的时间与服务器的时间相差很大（比如时间不同步，或者跨时区），那么误差就很大，所以在HTTP1.1版开始，使用Cache-Control: max-age=(秒)替代。
当服务器发出响应的时候，可以通过两种方式来告诉客户端缓存请求：
第一种是Expires，比如：Expires: Sun, 16 Oct 2016 05:43:02 GMT
不过Expires有缺点，比如说，服务端和客户端的时间设置可能不同，这就会使缓存的失效可能并不能精确地按服务器的预期进行。
第二种是Cache-Control，比如：Cache-Control: max-age=315360000
这里声明的是一个相对的秒数，表示从现在起，315360000秒内缓存都是有效的，这样就避免了服务端和客户端时间不一致的问题。
但是Cache-Control是HTTP1.1才有的，不适用于HTTP1.0，而Expires既适用于HTTP1.0，也适用于HTTP1.1，所以说在大多数情况下，同时发送这两个头回是一个更好的选择，当用户端两种头都能解析的时候，会优先使用Cache-Control。
过程如下：
（1）客户端请求一个页面（A）。
（2）服务器返回页面A，并再给A加上一个Last-Modified和ETag。
（3）客户端展现该页面，并将页面连同Last-Modified和ETag的值一起缓存。
（4）客户再次请求页面A，并将上次请求时服务器返回的Last-Modified和ETag的值一起传递给服务器。
（5）服务器检查该Last-Modified或ETag，并判断出该页面自上次客户端请求之后还未被修改，直接返回响应304和一个空的响应体。
1.首先在服务器创建一个简单的HTML文件，用浏览器访问一下，成功表示HTML页面。Fiddler就会产生下面的捕获信息。
需要留意的是：
（1）因为是第一次访问该页面，客户端发请求时，请求头中没有If-Modified-Since标签。
（2）服务器返回的HTTP状态码是200，并发送页面的全部内容。
（3）服务器返回的HTTP头标签中有Last-Modified，告诉客户端页面的最后修改时间。
2.在浏览器中刷新一下页面，Fiddler就会产生下面的捕获信息。
需要注意的是：
（1）客户端发HTTP请求时，使用If-Modified-Since标签，把上次服务器告诉它的文件最后修改时间返回到服务器端了。
（2）因为文件没有改动过，所以服务器返回的HTTP状态码是304，没有发送页面的内容。
3.用文本编辑器稍微改动一下页面文件，保存。再用浏览器访问一下，Fiddler就会产生下面的捕获信息。
需要注意的是：
（1）客户端发HTTP请求时，使用If-Modified-Since标签，把上次服务器告诉它的文件最后修改时间返回到服务器端了。
（2）因为文件被改动过，两边的时间不一致，所以服务器返回的HTTP状态码是200，并发送新页面的全部内容。
（3）服务器返回的HTTP头标签中有Last-Modified，告诉客户端页面的新的最后修改时间。
HTTP1.1和HTTP1.0的区别。（HTTP1.1版本的4个特性）
1、默认持久连接和流水线
HTTP/1.1默认使用持久连接，只要客户端服务端任意一端没有明确提出断开TCP连接，就一直保持连接，在同一个TCP连接下，可以发送多次HTTP请求。同时，默认采用流水线的方式发送请求，即客户端每遇到一个对象引用就立即发出一个请求，而不必等到收到前一个响应之后才能发出下一个请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送相应结果，以保证客户端能够区分出每次请求的相应内容，这样也显著地减少了整个下载过程所需要的时间。
HTTP/1.0默认使用短连接，要建立长连接，可以在请求消息中包含Connection: Keep-Alive头域，如果服务器愿意维持这条连接，在响应消息中也会包含一个Connection: Keep-Alive的头域。Connection请求头的值为Keep-Alive时，客户端通知服务器返回本次清秋节过后保持连接；Connection请求头的值为close时，客户端通知服务器返回本次请求结果后关闭连接。
2、分块传输数据
HTTP/1.0可用来指定实体长度的唯一机制是通过Content-Length字段。静态资源的长度可以很容易的确定，但是对于动态生成的响应来说，为获取它的真是长度，只能等它完全生成之后，才能正确地填写Content-Length的值，这便要求缓存整个响应，在服务器端占用大量的缓存，从而延长了响应用户的时间。
HTTP/1.1引入了被称为分块（chunked）的传输方法。该方法使发送方能将消息实体分割为任意大小的组块（chunk），并单独地发送它们。在每个组块前面，都加上了该组块的长度，使接收方可确保自己能够完整地接收到这个组块。更重要的是，在最末尾的地方，发送方生成了长度为零的组块，接收方可据此判断整条消息都已安全地传输完毕。这样也避免了在服务器端占用大量的的缓存。Transfer-Encoding:chunked向接收方指出：响应将被分组块，对响应分析时，应采取不同于非分组块的方式。
3、状态码 100 Continue
HTTP/1.1加入了一个新的状态码 100 Continue，用于客户端在发送POST数据给服务器前，征询服务器的情况，看服务器是否处理POST数据。
当要POST的数据大于1024字节的时候，客户端并不会直接就发起了POST请求，而是会分为2步：
（1）发送一个请求，包含一个Except: 100-continue，询问Server是否愿意接受数据。
（2）接收到Server返回的100 continue应答以后，才把数据POST给Server。
这种情况通常发生在客户端准备发送一个冗长的请求给服务器，但是不确认服务器是否有能力接收。如果没有得到确认，而将一个冗长的请求包发送给服务器，然后包被服务器给抛弃了，这种情况挺浪费资源的。
4、Host域
HTTP1.1在Request消息头里多了一个Host域，HTTP1.0则没有这个域。在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，这个IP地址上只有一个主机。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机，并且它们共享一个IP地址。
常用的HTTP方法有哪些？
注意：只有POST和PUT方法才有请求内容。
GET：用于请求访问已经被URI（统一资源标识符）识别的资源，可以通过URL传参给服务器。
POST：用于传输信息给服务器，主要功能与GET方法类似，但一般推荐使用POST方式。
PUT：传输文件，报文主体中包含文件内容，保存到对应URI位置。
HEAD：获得报文首部，与GET方法类似，只是不返回报文主体。
DELETE：删除文件，与PUT方法相反，删除对应URI位置的文件。
OPTIONS：查询相应URL支持的HTTP方法。
注意：并非所有的服务器都实现了这几个方法。有的服务器还实现了自己持有的HTTP方法，称为扩展方法。
GET：GET可以说是最常见的了，它本质就是发送一个请求来取得服务器上的某一资源。资源通过一组HTTP头和呈现数据返回给客户端。GET请求中，永远不会包含呈现数据。
HEAD：HEAD和GET本质是一样的，区别在于HEAD不含有呈现数据，而仅仅是HTTP头信息。有的人可能觉得这个方法没什么用，其实不是这样的。想象一个业务情景：欲判断某个资源是否存在，我们通常用GET，但这里用HEAD则意义更加明确。
PUT：这个方法比较少见。HTML表单也不支持这个。本质上来讲，PUT和POST极为相似，都是向服务器发送数据，但它们之间有一个重要区别，PUT通常指定了资源的存放位置，而POST没有，POST的数据存放位置由服务器自己决定。举个例子：如一个用于提交博文的URL，/addBlog。如果用PUT，则提交的URL会是像这样的“/addBlog/abc123”，其中的abc123就是这个博文的地址。而如果用POST，则这个地址会在提交后由服务器告知客户端。目前大部分博客都是这样的。显然，PUT和POST用途是不一样的。具体用哪个还取决于当前业务场景。
DELETE：删除某一个资源。基本上这个也很少见。不过还是有一些地方比如amazon的S3云服务里面就用的这个方法来删除资源。
POST：向服务器提交数据。这个方法用途广泛，几乎目前所有的提交操作都是靠这个完成。
OPTIONS：这个方法很有趣，但极少使用。它用于获取当前URL所支持的方法。若请求成功，则它会在HTTP头中包含一个名为“Allow”的头，值是所支持的方法，如“GET,POST”。
TRACE：请求服务器回送收到的请求信息，主要用于测试和判断，所以是安全的。
HEAD、GET、OPTIOINS和TRACE视为安全的方法，因为它们只是从服务器获得资源而不对服务器做任何修改；但是HEAD、GET、OPTIONS在用户端不安全，而POST则影响服务器上的资源。
GET虽然不修改服务器数据，但是GET方法通过URL请求来传递用户的输入；HEAD只获得消息的头部，但是数据传入也是通过URL。 这样对客户端而言并不安全。
TRACE方法对与服务端和用户端一定是安全的。
HTTP的请求方式get和post的区别？
1、GET一般用于获取或者查询资源信息，这就意味着它是幂等的（对于同一个URL的多个请求返回同样的结果）和安全的（没有修改资源的状态），而POST一般用于更新资源信息，POST既不是安全的，也不是幂等的。
2、采用GET方法时，客户端把要发送的数据添加到URL后面（就是把数据放置在HTTP协议头中，GET是通过URL提交数据的），并用“？”连接，各个变量之间用“&”连接；
HTTP协议没有对URL长度进行限制，由于特定的浏览器及服务器对URL的长度在限制，所以传递的数据量有限；
通过GET提交数据，用户名和密码将明文出现在URL上，因为（1）登陆页面有可能被浏览器缓存；（2）其他人查看浏览器的“历史记录”，那么别人就可以拿到你的账号和密码了。
而POST把要传递的数据放到HTTP请求报文的消息体中；HTTP协议也没有进行大小限制，起限制作用的是服务器处理程序的能力。但是，传送的数据量比GET方法更大些；由于传递的数据在消息体中，安全性高，但其实用抓包软件（如httpwatch）进行抓包的话，可以看到传递的数据内容的。
3、GET请求的数据会被浏览器缓存起来，会留下历史记录；而POST提交的数据不会被浏览器缓存，不会留下历史记录。