headers
达成语义一致,新功能就可以被轻松加入进来,可见 HTTP 的灵活性很好;HTTP Cookies
能创建有状态的会话,就可以解决这个问题;TCP
进行消息传递,但连接并不是必须的。HTTP/1.0 默认为每一对 HTTP 请求/响应都打开一个单独的 TCP 连接,请求/响应 完成之后就会断开连接。HTTP 报文大致可以分为 报文首部
和 报文主体
两部分,这两部分用空行划分(CR+LF
,CR
表示回车符,十六进制是 0x0d
;LF
表示换行符,十六进制是 0x0a
)
报文首部
空行(CR+LF)
报文主体
客户端的 HTTP 报文叫做请求报文,服务器端的报文 HTTP 报文叫做响应报文。HTTP 请求报文包括:
Cookie
等);HTTP 响应报文包括:
Cookie
等);它包括:
例如:
GET /index.html HTTP/1.1
它包括:
例如:
HTTP/1.1 200 OK
方法 | 说明 | 支持的 HTTP 协议版本 |
---|---|---|
GET | 获取资源 | 1.0、1.1 |
POST | 传输资源 | 1.0、1.1 |
PUT | 更新资源 | 1.0、1.1 |
DELETE | 删除资源 | 1.0、1.1 |
HEAD | 获取报文首部 | 1.0、1.1 |
OPTIONS | 询问支持的方法 | 1.1 |
PUT
与 POST
方法的区别在于,PUT
方法是 幂等 的:调用一次与连续调用多次是等价的(即没有副作用),而连续调用多次POST
方法可能会有副作用,比如将一个订单重复提交多次。PUT
称为更新资源(比如:昵称,它只有一份),而 POST
是提交(比如任意的上传资源)。当然,这只是规范里的,具体实现还是看自家的服务器。
但是,鉴于 HTTP/1.1 的 PUT
方法自身不带验证机制,存在安全风险,因此一般的网站不使用该方法。若配合 web 应用程序的验证机制,或架构设计采用 REST 标准的 web 网站,还是能弥补这一安全性问题的。
HEAD
方法和 GET
方法一样,只是不返回报文主体部分。HEAD
方法主要用于确认 URI
的有效性及资源更新的日期等。
主要区别有这几个方面:
共有 5 类状态码:
1XX
,信息性状态码(Informational)。表示接收的请求正在处理;2XX
,成功状态码(Success)。表示请求正常处理完毕;3XX
,重定向状态码(Redirection)。表示需要进行附加操作以完成请求;4XX
,客户端错误状态码(Client Error)。表示服务器无法处理请求;5XX
,服务器端错误状态码(Server Error)。表示服务器处理请求出错。常见的一些状态码与描述:
200 OK
,表示从客户端发来的请求在服务器端被正常处理了;204 No Content
,请求处理成功,但是返回的响应报文中不包含实体的主体部分。默认情况下 204
响应是可缓存的。一个 ETag
标头包含在此类响应中;206 Partial Content
,客户端进行范围请求,并且成功执行了这部分 GET
请求。响应报文中包含 Content-Range
指定范围的实体内容;301 Moved Permanently
,永久重定向。表示请求的资源已经被分配了新的 URL,请求的资源已经被移动到了由 Location
头部指定的 URL
上;302 Found
,临时重定向。所请求的页面已经临时转移至新的 URL。304 Not Modified
,客户端有缓存的文档并发出了一个条件性的请求,服务器告诉客户端,原来缓存的文档还可以继续使用,这时就会返回 304
状态码,304
与重定向无关。400 Bad Request
,客户端请求有语法错误,不能被服务器所理解;401 Unauthorized
,请求未经授权,这个状态码必须和 WWW-Authenticate
首部一起发送,其中包含有如何进行验证的信息(比如 token
)401
表明验证信息不通过;403 Forbidden
,对请求页面的访问被禁止;404 Not Fount
,请求资源不存在;500 Internal Server Error
,表示服务器端错误的响应状态码,意味着所请求的服务器遇到意外的情况并阻止其执行请求;503 Service Unavailable
,它表示服务器尚未处于可以接受请求的状态。通常造成这种情况的原因是由于服务器停机维护或者已超载(例如某个用户使用爬虫程序导致服务器请求量过大,服务器不再接受该用户的请求)。更多 HTTP 状态码可以参考 MDN 上的文档:HTTP response status codes[1]
HTTP/1.0 默认为每一对 HTTP 请求/响应都打开一个单独的 TCP 连接,请求/响应 处理完后就会断开连接。当需要连续发起多个请求时,这种模式比多个请求共享同一个 TCP 链接更低效。
为了减轻这些缺陷,HTTP/1.1
引入了持久连接的概念:底层的 TCP 连接可以通过Connection
头部来被部分控制。
持久连接的特点是:只要任意一端没有明确的提出断开连接,则保持 TCP 连接状态。
HTTP/1.1 中,所有的连接都是持久连接。即:
Connection: keep-alive
因此默认情况下,客户端会在持久连接上发送请求,如果服务器想要明确断开连接可以将 Connection
设置成 close
。
Connection: close
HTTP 持久连接的好处在于 TCP 连接的重复建立和断开所造成的额外开销,减轻了服务器的负载。另外,减少开销的那部分时间,使 HTTP 请求和响应能更早的结束,这样 Web 页面的显示速度也就相应提高了。
从前发送请求后需要等待并收到相应才能发送下一条请求。而管线化技术出现后,可以不用等待相应也可以直接发送下一条请求,管线化技术让请求可以更快的结束。
HTTP管线化
HTTP 管线化有以下几个特点:
在 HTTP/2.0 之前,HTTP 标准的瓶颈:
然后谷歌在 2010 年推出了 SPDY,它可以说是 HTTP/2.0 的前身。SPDY 的优化:
而 HTTP/2.0 比 SPDY 更“先进”,它不仅包含 SPDY 中的优化项,而且自身还有以下特点:
二进制分帧
多路复用
并行双向字节流
服务器或客户端可以一边发送着数据流,还可以一边接收数据量。
[1]HTTP response status codes: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status
HTTP缓存:点击查看——HTTP缓存