HTTP

HTTP method

Roy Fielding博士在2000年提出了表征状态转移 （REST）。它是一种基于 HTTP 协议的网络应用的接口风格。
依照规定，比如GET、POST、PUT和DELETE，分别与资源的获取、创建、更新和删除相对应。
HTTP 协议定义了以下8种标准的方法：

• GET：请求获取指定资源。
• HEAD：请求指定资源的响应头。 服务器在响应值中返回首部，不返回实体的主体部分
• POST：向指定资源提交数据。 起初是用来向服务器输入数据的。实际上，通常会用它来支持HTML的表单。表单中填好的数据通常会被送给服务器，然后由服务器将其发送到要去的地方。
• PUT：请求服务器存储一个资源。（让服务器用请求的主体部分来创建一个由所请求的URL命名的新文档，或者，如果那个URL已经存在的话，就用干这个主体替代它）
• DELETE：请求服务器删除指定资源。
• TRACE：回显服务器收到的请求，主要用于测试或诊断。（会在目的服务器端发起一个环回诊断，最后一站的服务器会弹回一个TRACE响应并在响应主体中携带它收到的原始请求报文。TRACE方法主要用于诊断，用于验证请求是否如愿穿过了请求/响应链。）
• CONNECT：HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
• OPTIONS：返回服务器支持的HTTP请求方法。（请求web服务器告知其支持的各种功能。可以查询服务器支持哪些方法或者对某些特殊资源支持哪些方法。）

创建标准的REST服务需要实现四个HTTP谓词。每个谓词会覆盖一个操作：

• GET：获取
• POST：新增
• PUT：更新
• DELETE：删除

URI统一资源标识符：URL统一资源定位符+ URN统一资源名称

HTTP request报文结构是怎样的

rfc2616中进行了定义：

1. 首行是Request-Line包括：请求方法，请求URI，协议版本，CRLF
2. 首行之后是若干行请求头，包括general-header，request-header或者entity-header，每个一行以CRLF结束
3. 请求头和消息实体之间有一个CRLF分隔
4. 根据实际请求需要可能包含一个消息实体
   一个请求报文例子如下：

GET /Protocols/rfc2616/rfc2616-sec5.html HTTP/1.1
Host: www.w3.org
Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
Referer: https://www.google.com.hk/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: zh-CN,zh;q=0.8,en;q=0.6
Cookie: authorstyle=yes
If-None-Match: "2cc8-3e3073913b100"
If-Modified-Since: Wed, 01 Sep 2004 13:24:52 GMT

name=qiu&age=25

HTTP response报文结构是怎样的

rfc2616定义：

1. 首行是状态行包括：HTTP版本，状态码，状态描述，后面跟一个CRLF
2. 首行之后是若干行响应头，包括：通用头部，响应头部，实体头部
3. 响应头部和响应实体之间用一个CRLF空行分隔
4. 最后是一个可能的消息实体
   响应报文例子如下：

HTTP/1.1 200 OK
Date: Tue, 08 Jul 2014 05:28:43 GMT
Server: Apache/2
Last-Modified: Wed, 01 Sep 2004 13:24:52 GMT
ETag: "40d7-3e3073913b100"
Accept-Ranges: bytes
Content-Length: 16599
Cache-Control: max-age=21600
Expires: Tue, 08 Jul 2014 11:28:43 GMT
P3P: policyref="http://www.w3.org/2001/05/P3P/p3p.xml"
Content-Type: text/html; charset=iso-8859-1

{"name": "qiu", "age": 25}

Http 和 Https的区别

Http 是一个简单的请求-响应协议（应用层)，运行在TCP之上，信息是明文传输。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应，但客户端和服务器都无法验证对方的身份。

Https 是身披SSL(Secure Socket Layer安全套接层)外壳的 Http，添加了传输加密和身份认证机制，具有安全性。

二者存在以下不同：

• 端口不同：Http 和 Https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443
• Http 的连接很简单，是无状态的。Https 协议是由 SSL+http协议 构建的可进行加密传输、身份认证的网络协议，比http协议安全。
• 开销：Https 需要到CA （Certificate Authority，证书颁发机构）申请证书，一般免费证书较少，因而需要一定费用
• 资源消耗：和 Http 通信相比，Https 通信会由于加减密处理消耗更多的CPU和内存资源；

(无状态的意思是其数据包的发送、传输和接收都是相互独立的。无连接的意思是指通信双方都不长久的维持对方的任何信息。)

Https 的加密机制是一种共享密钥加密和公开密钥加密并用的混合加密机制。

https主要解决三个安全问题：

1. 内容隐私
2. 防篡改
3. 确认对方身份

https并不是直接通过非对称加密传输过程，而是有握手过程，握手过程主要是和服务器做通讯，生成私有秘钥，最后通过该秘钥对称加密传输数据。还有验证证书的正确性。 证书验证过程保证了对方是合法的，并且中间人无法通过伪造证书方式进行攻击

1. 对称密钥加密：加密和解密使用同一个密钥的方式，这种方式存在的最大问题就是密钥发送问题，即如何安全地将密钥发给对方；
2. 非对称加密：密钥成对出现，分为公钥和私钥；公钥可以随意发布，但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理，对方接收到加密信息后，使用自己的私钥进行解密。
   　　
   由于非对称加密的方式不需要发送用来解密的私钥，所以可以保证安全性；但是和对称加密比起来，它非常的慢，所以我们还是要用对称加密来传送消息，但对称加密所使用的密钥我们可以通过非对称加密的方式发送出去。

从浏览器地址栏输入url到显示页面的步骤(以HTTP为例)

1. 在浏览器地址栏输入URL
2. 浏览器查看缓存，如果请求资源在缓存中并且新鲜，跳转到转码步骤
   1. 如果资源未缓存，发起新请求
   2. 如果已缓存，检验是否足够新鲜，足够新鲜直接提供给客户端，否则与服务器进行验证。
   3. 检验新鲜通常有两个HTTP头进行控制Expires和Cache-Control：
      • HTTP1.0提供Expires，值为一个绝对时间表示缓存新鲜日期
      • HTTP1.1增加了Cache-Control: max-age=,值为以秒为单位的最大新鲜时间
3. 浏览器解析URL获取协议，主机，端口，path
4. 浏览器组装一个HTTP（GET）请求报文
5. 浏览器获取主机ip地址，过程如下：
   1. 浏览器缓存
   2. 本机缓存
   3. hosts文件
   4. 路由器缓存
   5. ISP DNS缓存
   6. DNS递归查询（可能存在负载均衡导致每次IP不一样）
6. 打开一个socket与目标IP地址，端口建立TCP连接，三次握手如下：
   1. 客户端发送一个TCP的SYN=1，seq=x的包到服务器端口；标志位，序列号
   2. 服务器发回SYN=1， ACK=1， seq=y，ack=x+1的响应包
   3. 客户端发送ACK=1， seq=x+1，ack=y+1
7. TCP链接建立后发送HTTP请求
8. 服务器接受请求并解析，将请求转发到服务程序，如虚拟主机使用HTTP Host头部判断请求的服务程序
9. 服务器检查HTTP请求头是否包含缓存验证信息如果验证缓存新鲜，返回304等对应状态码
10. 处理程序读取完整请求并准备HTTP响应，可能需要查询数据库等操作
11. 服务器将响应报文通过TCP连接发送回浏览器
12. 浏览器接收HTTP响应，然后根据情况选择关闭TCP连接或者保留重用，关闭TCP连接的四次挥手如下：
    1. 主动方发送FIN=1， seq= u报文
    2. 被动方发送ACK=1， seq=v，ack=u+1报文
    3. 被动方发送FIN=1， ACK=1， seq=w，ack=u+1报文
    4. 主动方发送ACK=1， seq=u+1, ack=w+1报文
13. 浏览器检查响应状态码：是否为1XX，3XX， 4XX， 5XX，这些情况处理与2XX不同
14. 如果资源可缓存，进行缓存
15. 对响应进行解码（例如gzip压缩）
16. 根据资源类型决定如何处理（假设资源为HTML文档）
17. 解析HTML文档，构建DOM树，下载资源，构造CSSOM树，执行js脚本，这些操作没有严格的先后顺序，以下分别解释
18. 构建DOM树：
    1. Tokenizing：根据HTML规范将字符流解析为标记
    2. Lexing：词法分析将标记转换为对象并定义属性和规则
    3. DOM construction：根据HTML标记关系将对象组成DOM树
19. 解析过程中遇到图片、样式表、js文件，启动下载
20. 构建CSSOM树：
    1. Tokenizing：字符流转换为标记流
    2. Node：根据标记创建节点
    3. CSSOM：节点创建CSSOM树
21. 根据DOM树和CSSOM树构建渲染树:
    1. 从DOM树的根节点遍历所有可见节点，不可见节点包括：1）script,meta这样本身不可见的标签。2)被css隐藏的节点，如display: none
    2. 对每一个可见节点，找到恰当的CSSOM规则并应用
    3. 发布可视节点的内容和计算样式
22. js解析如下：
    1. 浏览器创建Document对象并解析HTML，将解析到的元素和文本节点添加到文档中，此时document.readystate为loading
    2. HTML解析器遇到没有async和defer的script时，将他们添加到文档中，然后执行行内或外部脚本。这些脚本会同步执行，并且在脚本下载和执行时解析器会暂停。这样就可以用document.write()把文本插入到输入流中。同步脚本经常简单定义函数和注册事件处理程序，他们可以遍历和操作script和他们之前的文档内容
    3. 当解析器遇到设置了async属性的script时，开始下载脚本并继续解析文档。脚本会在它下载完成后尽快执行，但是解析器不会停下来等它下载。异步脚本禁止使用document.write()，它们可以访问自己script和之前的文档元素
    4. 当文档完成解析，document.readState变成interactive
    5. 所有defer脚本会按照在文档出现的顺序执行，延迟脚本能访问完整文档树，禁止使用document.write()
    6. 浏览器在Document对象上触发DOMContentLoaded事件
    7. 此时文档完全解析完成，浏览器可能还在等待如图片等内容加载，等这些内容完成载入并且所有异步脚本完成载入和执行，document.readState变为complete, window触发load事件
23. 显示页面（HTML解析过程中会逐步显示页面）

http常用状态码(http-status-code):

HTTP请求结构： 请求方式 + 请求URI + 协议及其版本 　　
HTTP响应结构： 状态码 + 原因短语 + 协议及其版本

1×× : 请求已被接受，正在处理

2×× : 请求成功，请求被成功处理
200 OK
201 Created 已创建，成功请求并创建了新的资源

3×× : 重定向，要完成请求必须进行进一步处理
301 : 永久性转移（http->https）
302 ：暂时性转移
304 ： 已缓存（浏览器缓存验证：走缓存(服务端觉得你之前请求过这个东西，而且服务器上的那一份没有发生变化, 告诉客户端用缓存 就行)

4×× : 客户端错误，请求不合法
400：Bad Request, 请求有语法问题
401：Unauthorized 未授权/请求要求用户的身份认证
403：拒绝请求（跨域了）
404：Not found，客户端所访问的页面不存在

5×× : 服务器端错误，服务器不能处理合法请求
500 ：Internal Server Error 服务器内部错误
502 网关错误
503 ： 服务不可用，稍等
505 HTTP Version Not Supported

---

2xx:表示成功
200 OK 表示所有东西都正常
204 表示请求成功,但是服务端没有内容给你
3xx: 表示重定向
301 永久重定向(当访问一个永久重定向的网站的时候,一个域名被指向一个其他网站,且是永久的)Moved Permanently。永久重定向，该操作比较危险，需要谨慎操作：如果设置了301，但是一段时间后又想取消，但是浏览器中已经有了缓存，还是会重定向。
302 临时重定向Fount，但是会在重定向的时候改变 method: 把 POST 改成 GET，于是有了 307
307，Temporary Redirect。临时重定向，在重定向时不会改变 method

304 走缓存(服务端觉得你之前请求过这个东西,而且服务器上的那一份没有发生变化,告诉客户端用缓存 就行)

4xx: 表示客户端错误
400 参数传递不当, 导致的错误
401 权限不够导致的
403 服务端已经理解请求,但是拒绝响应
404 客户端请求的资源或者数据不存在(发现请求接口404, 有两种情况一种是咱们写错接口了或者服务端还没部署)
5xx: 表示服务端错误(遇到以5开头的错误去找服务端错误)
500 服务端内部错误
502 网关错误

http全部状态码

• 1XX：信息状态码
  100 Continue：客户端应当继续发送请求。这个临时相应是用来通知客户端它的部分请求已经被服务器接收，且仍未被拒绝。客户端应当继续发送请求的剩余部分，或者如果请求已经完成，忽略这个响应。服务器必须在请求万仇向客户端发送一个最终响应
  101 Switching Protocols：服务器已经理解力客户端的请求，并将通过Upgrade消息头通知客户端采用不同的协议来完成这个请求。在发送完这个响应最后的空行后，服务器将会切换到Upgrade消息头中定义的那些协议。
• 2XX：成功状态码
  200 OK：请求成功，请求所希望的响应头或数据体将随此响应返回
  201 Created：
  202 Accepted：
  203 Non-Authoritative Information：
  204 No Content：
  205 Reset Content：
  206 Partial Content：
• 3XX：重定向
  300 Multiple Choices：
  301 Moved Permanently：
  302 Found：
  303 See Other：
  304 Not Modified：
  305 Use Proxy：
  306 （unused）：
  307 Temporary Redirect：
• 4XX：客户端错误
  400 Bad Request:
  401 Unauthorized:
  402 Payment Required:
  403 Forbidden:
  404 Not Found:
  405 Method Not Allowed:
  406 Not Acceptable:
  407 Proxy Authentication Required:
  408 Request Timeout:
  409 Conflict:
  410 Gone:
  411 Length Required:
  412 Precondition Failed:
  413 Request Entity Too Large:
  414 Request-URI Too Long:
  415 Unsupported Media Type:
  416 Requested Range Not Satisfiable:
  417 Expectation Failed:
• 5XX: 服务器错误
  500 Internal Server Error:
  501 Not Implemented:
  502 Bad Gateway:
  503 Service Unavailable:
  504 Gateway Timeout:
  505 HTTP Version Not Supported:

HTTP2.0

HTTP2.0的特点是：在不改动HTTP语义、方法、状态码、URI及首部字段的情况下，大幅度提高了web性能。（基于SPDY协议）

SPDY是Speedy的昵音，意为“更快”。它是Google开发的基于TCP协议的应用层协议。目标是优化HTTP协议的性能，通过压缩、多路复用和优先级等技术，缩短网页的加载时间并提高安全性。SPDY协议的核心思想是尽量减少TCP连接数。SPDY并不是一种用于替代HTTP的协议，而是对HTTP协议的增强

HTTP1.x有以下几个主要缺点：

1. HTTP/1.0一次只允许在一个TCP连接上发起一个请求，HTTP/1.1使用的流水线技术也只能部分处理请求并发，仍然会存在队列头阻塞问题，因此客户端在需要发起多次请求时，通常会采用建立多连接来减少延迟。
2. 单向请求，只能由客户端发起。
3. 请求报文与响应报文首部信息冗余量大。
4. 数据未压缩，导致数据的传输量大。

1.二进制传输
HTTP2.0中所有加强性能的核心是二进制传输，在HTTP1.x中，我们是通过文本的方式传输数据。基于文本的方式传输数据存在很多缺陷，文本的表现形式有多样性，因此要做到健壮性考虑的场景必然有很多，但是二进制则不同，只有0和1的组合，因此选择了二进制传输，实现方便且健壮。
在HTTP2.0中引入了新的编码机制，所有传输的数据都会被分割，并采用二进制格式编码。

为了保证HTTP不受影响，那就需要在应用层（HTTP2.0）和传输层（TCP or UDP）之间增加一个二进制分帧层。
在二进制分帧层上，HTTP2.0会将所有传输的信息分为更小的消息和帧，并采用二进制格式编码，其中HTTP1.x的首部信息会被封装到Headers帧，而Request Body则封装到Data帧。

2. 多路复用
在HTTP1.0中，我们经常会使用到雪碧图、使用多个域名等方式来进行优化，都是因为浏览器限制了同一个域名下的请求数量，当页面需要请求很多资源的时候，队头阻塞（Head of line blocking）会导致在达到最大请求时，资源需要等待其他资源请求完成后才能继续发送。
HTTP2.0中，有两个概念非常重要：帧（frame）和流（stream）。
帧是最小的数据单位，每个帧会标识出该帧属于哪个流，流是多个帧组成的数据流。
所谓多路复用，即在一个TCP连接中存在多个流，即可以同时发送多个请求，对端可以通过帧中的表示知道该帧属于哪个请求。在客户端，这些帧乱序发送，到对端后再根据每个帧首部的流标识符重新组装。通过该技术，可以避免HTTP旧版本的队头阻塞问题，极大提高传输性能。

3. Header压缩
在HTTP1.0中，我们使用文本的形式传输header，在header中携带cookie的话，每次都需要重复传输几百到几千的字节，这着实是一笔不小的开销。
在HTTP2.0中，我们使用了HPACK（HTTP2头部压缩算法）压缩格式对传输的header进行编码，减少了header的大小。并在两端维护了索引表，用于记录出现过的header，后面在传输过程中就可以传输已经记录过的header的键名，对端收到数据后就可以通过键名找到对应的值。

4. 服务器Push
在HTTP2.0中，服务端可以在客户端某个请求后，主动推送其他资源。
可以想象一下，某些资源客户端是一定会请求的，这时就可以采取服务端push的技术，提前给客户端推送必要的资源，就可以相对减少一点延迟时间。在浏览器兼容的情况下也可以使用prefetch。

5. 更安全
HTTP2.0使用了tls的拓展ALPN做为协议升级，除此之外，HTTP2.0对tls的安全性做了近一步加强，通过黑名单机制禁用了几百种不再安全的加密算法。