2019.05.22 - HTTP、HTTPS与QUIC 协议

最新推荐文章于 2024-08-27 22:18:49 发布

jaylixueji_csdn

最新推荐文章于 2024-08-27 22:18:49 发布

阅读量1.2k

点赞数

分类专栏：网络协议文章标签： http https quic

本文链接：https://blog.csdn.net/weixin_42359693/article/details/90376012

版权

网络协议专栏收录该内容

6 篇文章 0 订阅

订阅专栏

HTTP协议

HTTP 协议虽然很常用，也很复杂，重点记住 GET、POST、 PUT、DELETE 这几个方法，以及部分重要的首部字段。

HTTP 请求的准备

浏览器会将 www.163.com 这个域名发送给 DNS 服务器，让它解析为 IP 地址。
HTTP 是基于 TCP 协议的，建立 TCP 连接（三次握手）。
- 目前使用的 HTTP 协议大部分都是 1.1。在 1.1 的协议里，默认是开启 Keep-Alive 的，这样建立的 TCP 连接，就可以在多次请求中复用，利于减少资源的浪费。

HTTP请求的构建

请求报文格式
HTTP 的报文大概分为三大部分。第一部分是请求行，第二部分是请求的首部，第三部分才是请求的正文实体。

第一部分：请求行

在请求行中，URL 就是http://www.163.com ，版本为 HTTP 1.1。
方法有几种类型。

GET

GET 就是去服务器获取一些资源。
对于访问网页来讲，要获取的资源往往是一个页面或其他的格式，比如说返回一个 JSON 字符串，返回什么是由服务器端的实现决定的。

POST

POST是主动告诉服务端一些信息，而非获取。要告诉的信息一般会放在正文里面。正文有各种各样的格式，比如 JSON。

PUT

PUT 就是上传最新内容。但是，HTTP 的服务器往往是不允许上传文件的，所以 PUT 和 POST 就都变成了要传给服务器东西的方法。
在实际使用中，POST 往往是用来创建资源的，而 PUT 往往是用来修改资源的。
不常用。

DELETE

DELETE 就是用来删除资源的。
不常用。

第二部分：首部字段

请求行下面就是我们的首部字段。首部是 key value，通过冒号分隔。这里面保存一些非常重要的字段。

Accept-Charset（字符集）

Accept-Charset：表示客户端可以接受的字符集，防止出现乱码。

Content-Type（正文格式）

Content-Type：是指正文的格式。例如，我们进行 POST 的请求，如果正文是 JSON，那么我们就应该将这个值设置为 JSON。

Cache-control与If-Modified-Since（缓存控制）

Cache-control：用来控制缓存，当客户端发送的请求中包含 max-age 指令时，如果判定缓存层中，资源的缓存时间数值比指定时间的数值小，那么客户端可以接受缓存的资源；当指定 max-age 值为 0，那么缓存层通常需要将请求转发给应用集群。
If-Modified-Since：也是关于缓存的。如果服务器的资源在某个时间之后更新了，那么客户端就应该下载最新的资源；如果没有更新，服务端会返回“304 Not Modified”的响应，那客户端就不用下载了，也会节省带宽。

缓存

为啥要使用缓存呢？那是因为一个非常大的页面有很多东西。

场景：例如，我浏览一个商品的详情，里面有这个商品的价格、库存、展示图片、使用手册等等。商品的展示图片会保持较长时间不变，而库存会根据用户购买的情况经常改变。如果图片非常大，而库存数非常小，如果我们每次要更新数据的时候都要刷新整个页面，对于服务器的压力就会很大。
对于这种高并发场景下的系统，在真正的业务逻辑之前，都需要有个接入层，将这些静态资源的请求拦在最外面。
架构如下图。
Nginx 这一层，它如何处理 HTTP 协议呢？
- 对于静态资源，有 Vanish 缓存层。当缓存过期的时候，才会访问真正的 Tomcat 应用集群。
- 对于动态资源，有 Redis缓存层。

HTTP 请求的发送

HTTP 协议是基于 TCP 协议的，所以它使用面向连接的方式发送请求，通过 stream 二进制流的方式传给对方。当然，到了 TCP 层，它会把二进制流变成一个的报文段发送给服务器。
详见第14讲 | HTTP协议：看个新闻原来这么麻烦（趣谈网络协议 - 极客时间）

HTTP 响应/返回的构建

HTTP 的返回报文也是有一定格式的。这也是基于 HTTP 1.1 的。

状态码

状态码会反应 HTTP 请求的结果。
常见状态码。。。。。。

首部字段

接下来是返回首部的key value。
Retry-After：告诉客户端应该在多长时间以后再次尝试一下。“503 错误”是说“服务暂时不再和这个值配合使用”。
Content-Type：在返回的头部里也有Content-Type，表示返回的是 HTML，还是 JSON。

HTTP 响应/返回的发送

构造好了返回的 HTTP 报文，接下来就是把这个报文发送出去。还是交给 Socket 去发送，还是交给 TCP 层，让 TCP 层将返回的 HTML，也分成一个个小的段，并且保证每个段都可靠到达。
这些段加上 TCP 头后会交给 IP 层，然后把刚才的发送过程反向走一遍。虽然两次不一定走相同的路径，但是逻辑过程是一样的，一直到达客户端。
客户端发现 MAC 地址符合、IP 地址符合，于是就会交给 TCP 层。根据序列号看是不是自己要的报文段，如果是，则会根据 TCP 头中的端口号，发给相应的进程。这个进程就是浏览器，浏览器作为客户端也在监听某个端口。
当浏览器拿到了 HTTP 的报文。发现返回“200”，一切正常，于是就从正文中将 HTML 拿出来。HTML 是一个标准的网页格式，浏览器只要根据这个格式，展示出一个绚丽多彩的网页。

以上就是一个正常的 HTTP 请求和返回的完整过程。

HTTP 2.0

HTTP 协议也在不断地进化，在 HTTP1.1 基础上便有了 HTTP 2.0。

HTTP 2.0的特性

压缩表头，建立索引

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

切分连接为多个流

另外，HTTP 2.0 协议将一个 TCP 的连接中，切分成多个流，每个流都有自己的 ID，而且流可以是客户端发往服务端，也可以是服务端发往客户端。它其实只是一个虚拟的通道。流是有优先级的。

消息和帧

HTTP 2.0 还将所有的传输信息分割为更小的消息和帧，并对它们采用二进制格式编码。常见的帧有：
- Header 帧：用于传输 Header 内容，并且会开启一个新的流。
- Data 帧：用来传输正文实体。多个 Data 帧属于同一个流。
通过这两种机制，HTTP 2.0 的客户端可以将多个请求分到不同的流中，然后将请求内容拆成帧，进行二进制传输。这些帧可以打散乱序发送，然后根据每个帧首部的流标识符重新组装，并且可以根据优先级，决定优先处理哪个流的数据。