理解HTTP

基础

https://zhuanlan.zhihu.com/p/34354434

 

一次完整的HTTP请求到响应的过程

1. 域名解析

2. 发起TCP的3次握手

3. 创建TCP链接后发起http请求

4. 服务器端响应http请求，浏览器获得html代码

5. 浏览器解析html代码，并请求html代码中的资源

6. 浏览器对页面进行渲染呈现给用户

 

https://www.cnblogs.com/YeChing/p/6337378.html

 

在 HTTP 1.0 版本中，并无官方的标准来规定 Keep-Alive 如何工做，所以实际上它是被附加到 HTTP 1.0协议上，若是客户端浏览器支持 Keep-Alive ，那么就在HTTP请求头中添加一个字段 Connection: Keep-Alive，当服务器收到附带有 Connection: Keep-Alive 的请求时，它也会在响应头中添加一个一样的字段来使用 Keep-Alive 。这样一来，客户端和服务器之间的HTTP链接就会被保持，不会断开（超过 Keep-Alive 规定的时间，意外断电等状况除外），当客户端发送另一个请求时，就使用这条已经创建的链接。

在 HTTP 1.1 版本中，默认状况下全部链接都被保持，若是加入 "Connection: close" 才关闭。目前大部分浏览器都使用 HTTP 1.1 协议，也就是说默认都会发起 Keep-Alive 的链接请求了，因此是否能完成一个完整的 Keep-Alive 链接就看服务器设置状况。

因为 HTTP 1.0 没有官方的 Keep-Alive 规范，而且也已经基本被淘汰，如下讨论均是针对 HTTP 1.1 标准中的 Keep-Alive 展开的。

注意：

• HTTP Keep-Alive 简单说就是保持当前的TCP链接，避免了从新创建链接。

• HTTP 长链接不可能一直保持，例如 Keep-Alive: timeout=5, max=100，表示这个TCP通道能够保持5秒，max=100，表示这个长链接最多接收100次请求就断开。

• HTTP 是一个无状态协议，这意味着每一个请求都是独立的，Keep-Alive 没能改变这个结果。另外，Keep-Alive也不能保证客户端和服务器之间的链接必定是活跃的，在 HTTP1.1 版本中也如此。惟一能保证的就是当链接被关闭时你能获得一个通知，因此不该该让程序依赖于 Keep-Alive 的保持链接特性，不然会有意想不到的后果。

• 使用长链接以后，客户端、服务端怎么知道本次传输结束呢？两部分：1. 判断传输数据是否达到了Content-Length 指示的大小；2. 动态生成的文件没有 Content-Length ，它是分块传输（chunked），这时候就要根据 chunked 编码来判断，chunked 编码的数据在最后有一个空 chunked 块，代表本次传输数据结束，详见这里。什么是 chunked 分块传输呢？下面咱们就来介绍一下。

HTTP 1.1 作了哪些升级：

• 缓存处理，在HTTP1.0中主要使用header里的If-Modified-Since,Expires来作为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。

• 带宽优化及网络链接的使用，HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是须要某个对象的一部分，而服务器却将整个对象送过来了，而且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它容许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和链接。

• 错误通知的管理，在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。

• Host头处理，在HTTP1.0中认为每台服务器都绑定一个惟一的IP地址，所以，请求消息中的URL并无传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上能够存在多个虚拟主机（Multi-homed Web Servers），而且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中若是没有Host头域会报告一个错误（400 Bad Request）。

• 长链接，HTTP 1.1支持长链接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP链接上能够传送多个HTTP请求和响应，减小了创建和关闭链接的消耗和延迟，在HTTP1.1中默认开启Connection： keep-alive，必定程度上弥补了HTTP1.0每次请求都要建立链接的缺点。

HTTP2.0

    二进制分帧数据层，以实现多向请求和响应、优先次序、最小化及消除没必要要的网络延迟，目的是更有效地利用底层TCP 链接；

• HTTP/2 的主要目标是改进传输性能，更有效地利用网络资源，实现低延迟和高吞吐量。从另外一方面看，HTTP 的高层协议语义并不会由于此次版本升级而受影响。全部HTTP 首部、值，以及它们的使用场景都不会变。

• HTTP/2 致力于突破上一代标准众所周知的性能限制，但它也是对以前1.x 标准的扩展，而非替代。之因此要递增一个大版本到2.0，主要是由于它改变了客户端与服务器之间交换数据的方式

二进制分帧：HTTP 2.0 的全部帧都采用二进制编码

• 帧：客户端与服务器经过交换帧来通讯，帧是基于这个新协议通讯的最小单位。

• 消息：是指逻辑上的 HTTP 消息，好比请求、响应等，由一或多个帧组成。

• 流：流是链接中的一个虚拟信道，能够承载双向的消息；每一个流都有一个惟一的整数标识符（一、2…N）；

多路复用 (Multiplexing)  :每一个域名一个长链接

    多路复用容许同时经过单一的 HTTP/2 链接发起多重的请求-响应消息。有了新的分帧机制后，HTTP/2 再也不依赖多个TCP 链接去实现多流并行了。每一个数据流都拆分红不少互不依赖的帧，而这些帧能够交错（乱序发送），还能够分优先级。最后再在另外一端把它们从新组合起来。HTTP 2.0 链接都是持久化的，并且客户端与服务器之间也只须要一个链接（每一个域名一个链接）便可。 

header压缩

    HTTP1.x的header带有大量信息，并且每次都要重复发送，HTTP/2使用encoder来减小须要传输的header大小，通信双方各自cache一份header fields表，既避免了重复header的传输，又减少了须要传输的大小。

服务端推送

• 服务器能够对一个客户端请求发送多个响应。服务器向客户端推送资源无需客户端明确地请求。

• HTTP 2.0 链接后，客户端与服务器交换SETTINGS 帧，借此能够限定双向并发的流的最大数量。

• 全部推送的资源都遵照同源策略。换句话说，服务器不能随便将第三方资源推送给客户端，而必须是通过双方确认才行。

• 服务器必须遵循请求- 响应的循环，只能借着对请求的响应推送资源

HTTP/2的多路复用和HTTP1.1中的长链接复用有什么区别？

• HTTP/1.0 一次请求-响应，创建一个链接，用完关闭；每个请求都要创建一个链接；

• HTTP/1.1 Pipeling解决方式为，若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能得到执行机会，一旦有某请求超时等，后续请求只能被阻塞，毫无办法，也就是人们常说的线头阻塞；

• HTTP/2多个请求可同时在一个链接上并行执行。某个请求任务耗时严重，不会影响到其它链接的正常执行；

 

https://mp.weixin.qq.com/s/4vDAUS_xoHxf7QGhpD4-ng

https://hit-alibaba.github.io/interview/basic/network/HTTP.html

https://www.jianshu.com/p/80e25cb1d81a