http协议总结

该文是对刘超老师的网络文章的总结

1.http协议介绍

      http是属于应用层的协议，底下是用tcp协议来支持的，所以他也是可靠的协议。同时因为tcp的三次握手和四次挥手比较麻烦，所以http中默认是开启了 Keep-Alive 的，这样建立的 TCP 连接，就可以在多次请求中复用。
      http协议现在广泛用在网页中，我们访问网页，需要一个叫做URL的统一资源定位符。例如http://www.baidu.com，其中www.baidu.com是域名，我们通过这个前面http就是指http协议，通过这个url我们可以访问服务器，其中www.baidu.com这个域名可以通过DNS来转换成一个ip地址，当然www.baidu.com这个域名在DNS层做了负载均衡，所以我们在访问百度这个网站是经常ip会有所变动。
      本地客户端和服务器之间进行传递消息用到的http协议他主要包含三个部分。第一部分是请求行，第二部分是请求的首部，第三部分才是请求的正文实体

1.1、请求行介绍

      请求行中有方法，URL和版本。方法主要有get，post和put。其中对于访问网页来讲，最常用的类型就是 GET。顾名思义，GET 就是去服务器获取一些资源信息。另外一种类型叫做 POST。它需要主动告诉服务端一些信息，而非获取。要告诉服务端什么呢？一般会放在正文里面。正文可以有各种各样的格式。常见的格式也是 JSON。有一种类型叫 PUT，就是向指定资源位置上传最新内容。但是，HTTP 的服务器往往是不允许上传文件的，所以 PUT 和 POST 就都变成了要传给服务器东西的方法。在实际使用过程中，这两者还会有稍许的区别。POST 往往是用来创建一个资源的，而 PUT 往往是用来修改一个资源的。版本现在主要有1.1和2.0。

1.2、首部介绍

      首部是 key value，通过冒号分隔。这里面，往往保存了一些非常重要的字段。例如，Accept-Charset，表示客户端可以接受的字符集。防止传过来的是另外的字符集，从而导致出现乱码。再如，Content-Type 是指正文的格式。例如，我们进行 POST 的请求，如果正文是 JSON，那么我们就应该将这个值设置为 JSON。

2.http的发送和接收过程

      http是基于tcp协议的，tcp是一种流式面向连接的协议，看起来像是一条水流不断的传输二进制数据，所以在应用层就需要将数据转换成二进制数据然后交给tcp来进行传输。在tcp处会通过移动窗口和ack机制来保证数据的有序行和完整性。然后tcp完成后再通过ip来进行发送，再ip层先是通过arp协议来找到目标ip，然后进行转发，其中要清楚ip只是我们用来定位用的，具体下一跳是网关还是目标机器都是通过mac来进行寻址。在服务器收到http请求后然后以同样的方式将数据传递给客户端

3.http2.0的优化

      因为http是基于tcp协议的，所以每一次请求必须要等到服务器回复后才能发出下一次请求，这样可能会在请求队列中发生拥堵。HTTP 2.0 利用虚拟的并发性成功解决了 HTTP 1.1 的队首阻塞问题。

3.1、请求首部中k-v数据优化

      HTTP 1.1 在应用层以纯文本的形式进行通信。每次通信都要带完整的 HTTP 的头，而且不考虑 pipeline 模式的话，每次的过程总是像上面描述的那样一去一回。这样在实时性、并发性上都存在问题。为了解决这些问题，HTTP 2.0 会对 HTTP 的头进行一定的压缩，将原来每次都要携带的大量 key value 在两端建立一个索引表，对相同的头只发送索引表中的索引。

3.2、并发性优化

      HTTP 2.0 协议将一个 TCP 的连接中，切分成多个流，每个流都有自己的 ID，而且流可以是客户端发往服务端，也可以是服务端发往客户端。流是有优先级的。
      HTTP 2.0 还将所有的传输信息分割为更小的消息和帧，并对它们采用二进制格式编码。常见的帧有 Header 帧，用于传输 Header 内容，并且会开启一个新的流。再就是 Data 帧，用来传输正文实体。多个 Data 帧属于同一个流。过这两种机制，HTTP 2.0 的客户端可以将多个请求分到不同的流中，然后将请求内容拆成帧，进行二进制传输。

4、修改http底层tcp为QUIC

      因为 HTTP 2.0 也是基于 TCP 协议的，TCP 协议在处理包时是有严格顺序的。当其中一个数据包遇到问题，TCP 连接需要等待这个包完成重传之后才能继续进行。但这样也会造成如果前面的请求没有收到，后面的请求会堵塞。可以利用QUIC协议来进行改善。

4.1、自定义连接机制

      在TCP中利用源 IP、源端口、目的 IP、目的端口来进行标识，同时如果网络不好断开了会使得进行三次握手和四次挥手重试，但是基于 UDP，就可以在 QUIC 自己的逻辑里面维护连接的机制，不再以四元组标识，而是以一个 64 位的随机数作为 ID 来标识，而且 UDP 是无连接的，所以当 IP 或者端口变化的时候，只要 ID 不变，就不需要重新建立连接。

4.2、自定义重传机制

      TCP 为了保证可靠性，通过使用序号和应答机制，来解决顺序问题和丢包问题。其中的自适应重传算法的超时是通过采样往返时间 RTT 不断调整的。但是在重传过程中不清楚对端的ack包回复对应的试哪一个请求包，因为在重试中会有很多的请求包发送过去，并且这些请求包的序号是一致的。这样对RTT的时间就不是很准，而QUIC 也有个序列号，是递增的。任何一个序列号的包只发送一次，下次就要加一了。例如，发送一个包，序号是 100，发现没有返回；再次发送的时候，序号就是 101 了；如果返回的 ACK 100，就是对第一个包的响应。如果返回 ACK 101 就是对第二个包的响应，RTT 计算相对准确。是这里有一个问题，就是怎么知道包 100 和包 101 发送的是同样的内容呢？QUIC 定义了一个 offset 概念。QUIC 既然是面向连接的，也就像 TCP 一样，是一个数据流，发送的数据在这个数据流里面有个偏移量 offset，可以通过 offset 查看数据发送到了哪里，可以判断100和101是否是相同包。

4.3、无阻塞的多路复用

      QUIC包不会造成堵塞。

4.4、自定义流量控制

在 TCP 协议中，接收端的窗口的起始点是下一个要接收并且 ACK 的包。一旦 ACK 了一个系列号，就说明前面的都到了，所以只要前面的没到，后面的到了也不能 ACK，就会导致后面的到了，也有可能超时重传，浪费带宽。QUIC 的 ACK 是基于 offset 的，每个 offset 的包来了，进了缓存，就可以应答，应答后就不会重发，中间的空挡会等待到来或者重发即可，而窗口的起始位置为当前收到的最大 offset，从这个 offset 到当前的 stream 所能容纳的最大缓存，是真正的窗口大小。显然，这样更加准确。