HTTP

2017-01-02 约 2398 字预计阅读 5 分钟

http请求格式

示例：

GET /mix/76.html?name=kelvin&password=123456 HTTP/1.1
Host: www.fishbay.cn
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, sdch
Accept-Language: zh-CN,zh;q=0.8,en;q=0.6

http响应格式

HTTP/1.1 200 OK
Server: nginx
Date: Mon, 20 Feb 2017 09:13:59 GMT
Content-Type: text/plain;charset=UTF-8
Vary: Accept-Encoding
Cache-Control: no-store
Pragrma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: no-cache
Content-Encoding: gzip
Transfer-Encoding: chunked
Proxy-Connection: Keep-alive

{"name":"sss","age":1}

响应状态码

1xx: 指示信息–表示请求已接收，继续处理
2xx: 成功–表示请求已被成功接收、理解、接受
3xx: 重定向–要完成请求必须进行更进一步的操作
4xx: 客户端错误–请求有语法错误或请求无法实现
5xx: 服务器端错误–服务器未能实现合法的请求

常用请求头

请求头	说明	示例
Accept	可接受的响应内容类型（Content-Types）。	Accept: text/plain
Accept-Charset	可接受的字符集	Accept-Charset: utf-8
Accept-Encoding	可接受的响应内容的编码方式。	Accept-Encoding: gzip, deflate
Accept-Language	可接受的响应内容语言列表。	Accept-Language: en-US
Cache-Control	用来指定当前的请求/回复中的，是否使用缓存机制。	Cache-Control: no-cache
Connection	客户端（浏览器）想要优先使用的连接类型	Connection: keep-alive Connection: Upgrade
Cookie	由之前服务器通过Set-Cookie（见下文）设置的一个HTTP协议Cookie	Cookie: $Version=1; Skin=new;
Content-Length	以8进制表示的请求体的长度	Content-Length: 348
Content-Type	请求体的MIME类型（用于POST和PUT请求中）	Content-Type: application/x-www-form-urlencoded
Range	表示请求某个实体的一部分，字节偏移以0开始。	Range: bytes=500-999
Referer	表示浏览器所访问的前一个页面，可以认为是之前访问页面的链接将浏览器带到了当前页面。Referer其实是Referrer这个单词，但RFC制作标准时给拼错了，后来也就将错就错使用Referer了。	Referer: http://itbilu.com/nodejs

我们可以看到这里规律就是多个单词首字母大写，中间中划线间隔。

响应头

请求头	说明	示例
Cache-Control	通知从服务器到客户端内的所有缓存机制，表示它们是否可以缓存这个对象及缓存有效时间。其单位为秒	Cache-Control: max-age=3600
Content-Encoding	响应资源所使用的编码类型。	Content-Encoding: gzip
Content-Language	响就内容所使用的语言	Content-Language: zh-cn
Content-Length	响应消息体的长度，用8进制字节表示	Content-Length: 348
Content-Type	当前内容的MIME类型	Content-Type: text/html; charset=utf-8
Location	用于在进行重定向，或在创建了某个新资源时使用。	Location: http://www.itbilu.com/nodejs
Refresh	用于重定向，或者当一个新的资源被创建时。默认会在5秒后刷新重定向。	Refresh: 5; url=http://itbilu.com
Set-Cookie	设置HTTP cookie	Set-Cookie: UserID=itbilu; Max-Age=3600; Version=1

http一次流程

一次HTTP请求的过程：

在浏览器中输入URL，并按下回车键浏览器向DNS服务器请求解析该URL中的域名对应的IP地址(如果是IP请求，则不需要该步骤) 解析出IP后，根据IP和端口号，和服务器建立TCP连接浏览器向服务器发送请求，该请求报文作为TCP三次握手的第三个报文发送给服务器服务器做出响应，把数据发送给浏览器通信完成，断开TCP连接浏览器解析收到的数据并显示

持久连接

每次http连接都要先tcp三次握手，使用完后再释放连接，这样有点浪费。

http1.0方案

http1.0 keep-alive连接的客户端通过包含Connection:Keep-Alive首部请求将一条里连接保持在打开状态。

如果服务器愿意为下一条请求将连接保持复用，就在响应中包含相同的首部Connection:Keep-Alive,如果响应中没有Connection:Keep-Alive首部，客户端就认为服务器不支持keep-alive,会在发挥响应报文之后关闭连接。

服务器可以随时关闭空闲的Keep-Alive连接，并可随意限制Keep-Alive连接所处理事务的数量。 Keep-Alive是响应中的可选首部，只有在提供Connection:Keep-Alive时才有效，在这个可选字段中我们支持：

Connection:Keep-Alive
Keep-Alive:max=5,timeout=120

timeout估计了服务端希望连接保持的在活跃状态的时间，max是估计还希望为多少个事务保持此连接的活跃状态。

http1.0的规则

http1.0中keep-alive并不是默认的，客户端必须发送一个Connection:Keep-Alive首部来激活
Connection:Keep-Alive首部每次都需要，如果没有这个，那么服务端就会在本条请求后断开。
客户端在响应中发现没有Connection:Keep-Alive首部就知道服务端关闭连接了。

http1.1方案

HTTP／1.1逐渐停止了对keep-alive连接的支持，用一种名为持久连接（persistent connection）的改进型设计取代了它。持久连接的目的与keep—alive连接的目的相同，但工作机制更优一些。

与HTTP／1.0＋的keep—alive连接不同，HTTP／1.1持久连接在默认情况下是激活的。除非特别指明，否则HTTP／1.1假定所有连接都是持久的。要在事务处理结束之后将连接关闭，HTTP／1.1应用程序必须向报文中显式地添加一个 Connection：close首部。这是与以前的HTTP协议版本很重要的区别，在以前的版本中，keep—alive连接要么是可选的，要么根本就不支持。

http1.1管道化连接

HTTP／1.1允许在持久连接上可选地使用请求管道。这是在keep—alive连接上的进一步性能优化。在响应到达之前，可以将多条请求放入队列。当第一条请求通过网络流向地球另一端的服务器时，第二条和第三条请求也可以开始发送了。在高时延网络条件下，这样做可以降低网络的环回时间，提高性能。

对管道化连接有几条限制。 ·如果HTTP客户端无法确认连接是持久的，就不应该使用管道。 ·必须按照与请求相同的顺序回送HTTP响应。HTTP报文中没有序列号标签，因此如果收到的响应失序了，就没办法将其与请求匹配起来了。 HTTP客户端必须做好连接会在任意时刻关闭的准备，还要准备好重发所有未完成的管道化请求。如果客户端打开了一条持久连接，并立即发出了10条请求，服务器可能在只处理了，比方说，5条请求之后关闭连接。剩下的5条请求会失败，客户端必须能够应对这些过早关闭连接的情况，重新发出这些请求。 ·HTTP客户端不应该用管道化的方式发送会产生副作用的请求（比如POST）。总之，出错的时候，管道化方式会阻碍客户端了解服务器执行的是一系列管道化请求中的哪一些。由于无法安全地重试POST这样的非幂等请求，所以出错时，就存在某些方法永远不会被执行的风险。

目录