HTTP协议理解与应用总结

HTTP 工做原理

HTTP 协议采用请求/响应模型。客户端向服务器发送一个请求报文，服务器以一个状态做为响应。

如下是 HTTP 请求/响应的步骤：

● 客户端链接到web服务器：HTTP 客户端与web服务器创建一个 TCP 链接;

● 客户端向服务器发起 HTTP 请求：经过已创建的TCP 链接，客户端向服务器发送一个请求报文;

● 服务器接收 HTTP 请求并返回 HTTP 响应：服务器解析请求，定位请求资源，服务器将资源副本写到 TCP 链接，由客户端读取;

● 释放 TCP 链接：若connection 模式为close，则服务器主动关闭TCP 链接，客户端被动关闭链接，释放TCP 链接;若connection 模式为keepalive，则该链接会保持一段时间，在该时间内能够继续接收请求;

● 客户端浏览器解析HTML内容：客户端将服务器响应的 html 文本解析并显示;

例如：在浏览器地址栏键入URL，按下回车以后会经历如下流程：

一、浏览器向 DNS 服务器请求解析该 URL 中的域名所对应的 IP 地址;

二、解析出 IP 地址后，根据该 IP 地址和默认端口 80，和服务器创建 TCP 链接;

三、浏览器发出读取文件(URL 中域名后面部分对应的文件)的HTTP 请求，该请求报文做为 TCP 三次握手的第三个报文的数据发送给服务器;

四、服务器对浏览器请求做出响应，并把对应的 html 文本发送给浏览器;

五、释放 TCP 链接;

六、浏览器将该 html 文本并显示内容;

Request & Response

Request格式

<request-line> 好比：GET /api/index.json HTTP/1.1
<headers> 好比：Accept: */*; User-Agent: Mozilla/4.0;……
<blank line>
[<request-body>] 好比：id=1&timestamp=xxxxxx

Response格式

<status-line> 好比：HTTP/1.1 200 OK
<headers> 好比：Content-Type: application/json;……
<blank line>
[<response-body>] 好比：{"id":1,"username":"testuser"}

Status Code

http的状态码有将近60个，我这里主要记录一些常见的非正常状况下产生的状态码，在日常应用中或多或少会碰到，有助于咱们去理解和发现问题。

206 – 断点下载时用到，客户端请求了一部份内容，服务器成功把这部份内容返回给它，这时候就是用这个状态。

301 – 永久跳转，原地址不存在了，url被指向到另外一个地址。这个主要是搜索引擎相关，影响爬虫的检索行为。

302 – 临时跳转，服务器会返回一个新的url给客户端，客户端能够继续访问这个url来获取内容。

304 – 资源没有改变，客户端可使用本地缓存的内容，常见于静态内容访问。

413 – 请求实体太大。常见的状况是上传大文件，但超出了服务器(好比nginx)限制。或者请求头或请求体超出了后端的server(好比tomcat)的设置（好比当前域名下cookie太多，超出了请求头限制）

416 – 跟断点续传有关，客户端请求的范围超出了服务器上文件大小。

500 – 服务器内部错误，不能返回正常的结果。好比最多见的应用抛出空指针异常未进行处理。

502 – 网关错误。常见的状况是反向代理后端的服务器(好比resin或tomcat)没有启动。

503 – 服务不可用。好比服务器负载过高或者服务器已经中止服务。

504 – 网关超时。好比请求时长超出了服务器的响应时间限制。

Headers

http headers分为请求头(Request Header)和响应头(Response Header)两类。下面是咱们常常用到的一些header.

1.缓存控制

在互联网站的应用中，缓存几乎无处不在，在基于http的服务中，咱们也能够对一些不常改变的内容在客户端进行缓存，这样在屡次访问中能够复用缓存内容，加快访问速度，提高用户体验。http的协议里规定了一些用于缓存控制的http消息头：

Cache-Control(HTTP/1.1)/Pragma(HTTP/1.0)：指 示客户端是否进行缓存以及缓存的时间是多长。默认值是private，也就是把内容缓存在用户私有空间。好比：Cache-Control:max- age=86400,must-revalidate，这是告诉客户端所请求的资源缓存一天（max-age单位是秒，相对时间），过时以后必须进行从新 检验。

Expires：指定客户端（若是不强制刷新的话）在多长时间里能够不向服务器发请求，直接读本地缓存。

注意：

1. 优先级：Cache-Control > Expires；

2. 详细参数说明：http://condor.depaul.edu/dmumaugh/readings/handouts/SE435/HTTP/node24.html

3. 不一样浏览器的不一样行为（刷新，后退，地址栏回车等）在实现上可能有差别；

Last-Modified/If-Modified-Since：Last-Modified是服务器端返回 给客户端的资源最后修改时间戳，这样，客户端在下次请求时（好比强制刷新）会带上If-Modified-Since参数来校验资源是否有更新，没有更新 的话服务器就返回304状态码，客户端直接取本地缓存的资源。这个时候只有请求开销，没有网络传输开销。注意：时间戳必须是格林威治(GMT)时间，比 如：Last-Modified:Sat, 19 Oct 2013 09:20:15 GMT

ETag/If-None-Match：ETag是根据文件属性经过必定算法生成的资源标识，也是用来肯定客户 端请求的资源是否有更新。若是服务器返回了一个ETag值给客户端，那么下次客户端请求时会带上If-None-Match参数来校验资源是否更新，没有 更新的就返回304状态码。（效果基本等同于Last-Modified）

注意：

1. ETag须要计算，对于计算资源紧张的服务器来讲是一种消耗，因此有些网站直接不使用ETag；

2. 若是服务器在负载均衡后 面，同一个资源的请求可能分发到不一样的后端机器上，因为ETag的计算依赖于文件属性，不一样机器上内容相同的文件可能生成的ETag不一样，这样就可能使本 来内容没变的文件经过ETag校验失败。这里有两种解决方案：一是etag计算不依赖于本地机器，好比直接算文件内容的md5值；二是在负载均衡器上把相 同的url请求分发到同一台后端机器。

在咱们的实际业务场景下，http的缓存具备很是大的用途，下面列举一些：

1. 充分利用客户端的资源，好比一些客户端须要频繁访问的静态文件，像LOGO，广告图等，彻底能够缓存在客户端本地。这样能够减小网络请求，加快客户端展现，还能减小服务器请求的压力。

2. 咱们的一些静态内容，好比新闻，博客等，在被搜索引擎爬虫抓取的时候，经过控制缓存参数，就能够减小爬虫的抓取频率，减小没必要要的资源浪费。

3. 若是咱们的静态资源使用了CDN，那么设置了http缓存就能够在CDN节点上保存一份文件，减小CDN的回源次数，减小网络延时和源站服务器压力。

2.断点请求

Accept-Ranges：服务端支持断点下载时会返回这个响应头给客户端，当客户端知道这个之后就能够发送断点请求了。

Content-Length：响应信息的长度，告诉客户端当前请求返回了多少数据。这里要注意一下，用head方法提交请求时不会返回具体数据，可是这个Content-Length会返回完整数据的大小。

Range/Content-Range：客户端请求时提交名为Range的header，告诉服务器本身要请 求哪部分的数据。好比：Range: bytes=0-1023表示请求第0到1023个字节.而后服务器返回这1024个字节的内容给客户端，响应头中会带上Content-Range。 即：Content-Range: bytes 0-1023/4096，这个4096就是文件总大小。客户端下次请求能够从第1024个字节处开始，Range: bytes=1024-xxxx

3.编码

Accept-Encoding/Content-Encoding：前者是客户端支 持接收的消息编码类型。默认是identity，可选值有gzip,compress等。后者是服务器端响应信息的内容编码类型，经常使用的就是压缩。压缩的 好处显而易见，能够大大减小网络传输的开销，相对于服务器端压缩产生的cpu消耗，网络传输的减小显然更实在。常见形式：Content- Encoding: gzip,deflate,compress.一般咱们对html,js,css,xml,json之类的响应结果能够进行压缩传输。

Transfer-Encoding：response header.响应消息的传输编码类型，规定了网络传输的形式。通常都是下面这种形式：Transfer-Encoding: chunked。当服务器产生动态内容，不知道响应信息的具体长度时，能够经过这个指定分块进行传输，处理多少数据就返回多少数据，这样不用等到数据都准 备好了一次性返回。结合上面的内容编码，好比gzip，能够分块压缩并进行传输。另外，请注意，在使用这种编码传输时，咱们是看不到Content- Length的，由于内容尚未彻底生成。

4.其余

X-Forward-For：request header. 用来标识用户的真实ip，特别是经过代理(正向或反向)访问服务器或是服务器在负载均衡设备后面的状况。格式：X-forward-For: client,proxy1,proxy2,…最左边的是最接近客户端的ip。

User-Agent：request header.服务器用来识别客户端基本信息的请求头。通常这个在识别搜索爬虫的时候有用，某些场景下也能够用这个来作一些客户端的统计。

Referer：request header.客户端访问服务器时，这个Referer来指定请求来源，好比是从哪一个网站连接过来的，咱们在一些统计中会常常用到这个。另外，还有一个重 要的用途就是在须要资源防盗链的场景中来过滤非法的请求来源（可是，这个referer是客户端能够伪造的）。

Location：response header.在301/302状态码的响应头中，都会带上这个Location头，来指示客户端用新的地址去访问须要的资源。

Connection：request/response header.在http/1.1中，客户端和服务端默认都是保持链接的，也就是Connection: keep-alive.若是任何一方不想保持链接，均可以把这个值设置为close.默认状况下，客户端和服务端会保持一个长链接，这样客户端就能够用这 个链接发送屡次http请求，减小频繁建立链接带来的消耗。对于这个参数，在服务端可能要作更多的设置，好比链接keep-alive的时间，服务器内核 的一些网络参数设置(针对tcp)。

Session和Cookie

http请求是无状态的请求，可是在咱们的互联网应用中，常常须要标识用户状态信息来完成一些交互性的操做，好比用户认证要记录用户登陆状态，购物车应用要记住用户选择的商品，广告投放应用要记录用户的历史浏览行为等等。这里就会用到session和cookie了。

session:是指http请求-响应的过程当中客户端与服务器端的交互状态，这些信息被保存在服务器端，好比内存，数据库等。每一个session都有一个惟一标识，由服务器生成，这个标识也要在客户端进行保存，这样客户端在下次请求时能够带上这个标识，方便服务器判断客户端的状态。

客户端对session的支持：

1. 经过cookie保存session id，在请求时发送给服务器。

2. 经过url的参数携带session id与服务器通讯。

3. 经过表单的隐藏字段携带session id与服务器通讯。

session共享的问题：

在分布式应用中，咱们的http server通常都架在反向代理或是负载均衡设备后面，这就会面临一个session共享的问题。也就是同一个用户的多个请求可能被分发到多个不一样的机 器，若是咱们把session保存在机器本地内存中的话，就没法在多个机器间共享用户的session。这个问题，通常来讲，咱们能够有两种方式来解决：

1. 把session存放到分布式的内存(eg:memcached)或是集中式存储中(eg:database)。

2. 在反向代理或负载均衡设备上把相同用户的请求分发到同一台机器（这里要处理好机器宕机后请求从新分配的问题）。

cookie:在客户端保持状态化信息，每一个cookie内容都属于特定的域(domain)和路径(path)，出于安全考虑，不一样域或路径下的cookie不能共享。

会话cookie：没有指定过时时间，保存在内存，浏览器关闭后就失效。

持久cookie：指定了过时时间，保存在浏览器本地。

详细内容能够参考：http://en.wikipedia.org/wiki/HTTP_cookie

须要注意的是cookie会存在一些安全方面的问题。

在这里我只是总结了本身在工做中遇到的与http协议相关的一些内容的理解，http协议还有不少须要挖掘的东西，也须要不断去探索，对http协议的理解将会给咱们的开发应用带来很大的便利。

最后，推荐两个很NB的http调试工具：fiddler(windows)和charles(mac)有http代理功能，对于不是基于浏览器的http应用(好比mobile app)，能够用这两个工具来监控http请求。