健康头条

http1.1与http2.0

2023-04-18 18:16 由 板栗拌饭 发表于 #前端开发

一、http是什么

通俗来讲，http就是计算机通过网络进行通信的规则，是一个基于请求与响应，无状态的，应用层协议。常用于TCP/IP协议传输数据。目前任何终端之间任何一种通信方式都必须按Http协议进行，否则无法连接。tcp(三次握手，四次挥手)。

  • 请求与响应：客户端请求、服务端响应数据。
  • 无状态：协议对于事务的处理是没有记忆能力，客户端第一次与服务器建立连接发送请求时需要进行一系列的安全认证匹配操作，因此增加页面等待时间，当客户端向服务端发送请求，服务端响应完毕后，两者断开链接，也不保存连接状态。
  • TCP/IP:Http使用TCP作为它的支撑运输协议。Http客户机发起一个与服务器的TCP连接，一旦连接建立，浏览器（客户机）和服务器进程就可以通过套接字接口（socket interface）访问TCP。

二 http三个组成部分

http请求由三部分构成，分别是：请求头、消息报头、请求正文

  • 请求方法：get、post、head、put、delete

 

  • GET方法与POST方法的区别

区别一：
get重点在从服务器上获取资源，post重点在向服务器发送数据；
区别二：
get传输数据是通过URL请求，以field（字段）= value的形式，置于URL后，并用"?"连接，多个请求数据间用"&"连接，如http://127.0.0.1/Test/login.action?name=admin&password=admin，这个过程用户是可见的；
post传输数据通过Http的post机制，将字段与对应值封存在请求实体中发送给服务器，这个过程对用户是不可见的；
区别三：
Get传输的数据量小，因为受URL长度限制，但效率较高；

Post可以传输大量数据，所以上传文件时只能用Post方式；

区别四：
get是不安全的，因为URL是可见的，可能会泄露私密信息，如密码等；
post较get安全性较高；
区别五：
get方式只能支持ASCII字符，向服务器传的中文字符可能会乱码。
post支持标准字符集，可以正确传递中文字符。

  • 常见的HTTP相应状态码

　　　　返回的状态
　　　　1xx：指示信息--表示请求已接收，继续处理
　　　　2xx：成功--表示请求已被成功接收、理解、接受
　　　　3xx：重定向--要完成请求必须进行更进一步的操作
　　　　4xx：客户端错误--请求有语法错误或请求无法实现
　　　　5xx：服务器端错误--服务器未能实现合法的请求


　　　　200：请求被正常处理
　　　　204：请求被受理但没有资源可以返回
　　　　206：客户端只是请求资源的一部分，服务器只对请求的部分资源执行GET方法，相应报文中通过Content-Range指定范围的资源。
　　　　301：永久性重定向
　　　　302：临时重定向
　　　　303：与302状态码有相似功能，只是它希望客户端在请求一个URI的时候，能通过GET方法重定向到另一个URI上
　　　　304：发送附带条件的请求时，条件不满足时返回，与重定向无关
　　　　307：临时重定向，与302类似，只是强制要求使用POST方法
　　　　400：请求报文语法有误，服务器无法识别
　　　　401：请求需要认证
　　　　403：请求的对应资源禁止被访问
　　　　404：服务器无法找到对应资源
　　　　500：服务器内部错误
　　　　503：服务器正忙

 

  • 请求URL：他与报文头的host属性组成完整的URL
  • 3⃣️协议名称以及版本号（http1.1）
  • 4⃣️HTTP请求头（报文头）：包含Request与Response两个部分

    HTTP请求头提供了关于请求，响应或者其他的发送实体的信息。HTTP的头信息包括通用头、请求头、响应头和实体头四个部分。每个头域由一个域名，冒号（:）和域值三部分组成（属性名：属性值）。 

  1. 通用头标：即可用于请求，也可用于响应，是作为一个整体而不是特定资源与事务相关联。
  2. 请求头标：允许客户端传递关于自身的信息和希望的响应形式。
  3. 响应头标：服务器和于传递自身信息的响应。
  4. 实体头标：定义被传送资源的信息。即可用于请求，也可用于响应。

　　　

  • 5⃣️是报文体，它将一个页面表单中的组件值通过param1=value1&param2=value2的键值对形式编码成一个格式化串，它承载多个请求参数的数据。不但报文体可以传递请求参数，请求URL也可以通过类似于“/chapter15/user.html? param1=value1&param2=value2”的方式传递请求参数。

三、HTTP发展史（HTTP1.1与HTTP2.0）

1. Http0.9：该协议诞生之初的作用是传输超文本内容HTML，并且只支持GET请求。

　　　　协议定义了客户端发起请求、服务端响应请求的通信模式。所以当时的请求报文只有一行：

GET + 请求的文件路径

 

2.  Http1.0：浏览器希望通过HTTP来传输脚本、样式、图片、音视频等不同类型的文件　　

  • 增加了HEAD、POST等新方法
  • 增加了响应状态码，标记可能的错误原因
  • 引入了协议版本号概念
  • 引入了HTTP header的概念，让HTTP处理请求和响应更加灵活
  • 传输的数据不再局限于文本

http1.0缺点：

HTTP/1.0最主要的缺点还是跟HTTP/0.9一样，每一个TCP连接只能发送一个HTTP请求，服务器发送完响应，就关闭连接。如果后面需要请求新的数据，则需要再次建立TCP连接，但是TCP建立连接的三次握手成本比较高，并且TCP连接初始的时候发送数据的速度相对较慢，有一个慢启动和拥塞避免的阶段。极端情况，如果每次请求的数据很少，但是请求很频繁，这样每次请求很少的数据都需要建立连接然后断开。

解决办法：

为了解决这个问题，在1.0版本使用了一个非标准的Connection头部字段。当客户端再请求头部信息里面带上Connection：keep-alive的时候，服务器在发送完响应数据之后，就不会断开TCP连接了，从而达到复用同一个TCP连接的目的。但是由于不是标准字段，不同的实现可能导致表现得不一致，因此不能从根本上解决这个问题。

HTTP/1.0最核心的改变是增加了头部设定，头部内容以键值对的形式设置。请求头部通过 Accept 字段来告诉服务端可以接收的文件类型，响应头部再通过 Content-Type 字段来告诉浏览器返回文件的类型。头部字段不仅用于解决不同类型文件传输的问题，也可以实现其他很多功能如缓存、认证信息等。

 

 3.  Http1.1

  • 长连接：引入了 TCP 连接复用，即一个 TCP 默认不关闭，可以被多个请求复用
  • 并发连接：对一个域名的请求允许分配多个长连接（缓解了长连接中的「队头阻塞」问题）
  • 引入管道机制（pipelining），一个 TCP 连接，可以同时发送多个请求。（响应的顺序必须和请求的顺序一致，因此不常用）
  • 增加了 PUT、DELETE、OPTIONS、PATCH 等新的方法
  • 新增了一些缓存的字段（If-Modified-Since, If-None-Match）
  • 请求头中引入了 range 字段，支持断点续传
  • 允许响应数据分块（chunked），利于传输大文件
  • 强制要求 Host 头，让互联网主机托管称为可能

HTTP管道机制（pipelining）

它指的是在一个TCP连接内，多个HTTP请求可以并行，客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能 够区分出每次请求的响应内容。

随着网络的发展，HTTP 1.1 还是暴露出一些局限性:

  • 虽然加入 keep-alive 可以复用一部分连接，但域名分片等情况下仍然需要建立多个connection，耗费资源，给服务器带来性能压力。
  • pipeling 只部分解决了队头阻塞（ HOLB）。 HTTP 1.1 尝试使用 pipeling 来解决队头阻塞问题，即浏览器可以一次性发出多个请求（同个域名、同一条 TCP 链接）。 但 pipeling 要求返回是按序的，那么前一个请求如果很耗时（比如处理大图片），那么后面的请求即使服务器已经处理完，仍会等待前面的请求处理完才开始按序返回。
  • 协议开销大，没有相应的压缩传输优化方案。 HTTP/1.1 在使用时，header 里携带的内容过大，在一定程度上增加了传输的成本，并且每次请求 header 基本不怎么变化，尤其在移动端增加用户流量。

HTTP/1.1 通过长连接减少了大量创建/断开连接造成的性能消耗，但是它的并发能力受到限制，表现在两个方面：

HTTP/1.1 中使用持久连接时，一个连接中同一时刻只能处理一个请求。当前的请求没有结束之前，其他的请求只能处于阻塞状态，这种情况被称为队头阻塞
浏览器为了减轻服务器的压力，限制了同一个域名下的 HTTP 连接数，一般为 6 ~ 8 个。为了解决数量限制，出现了 域名分片 技术，其实就是资源分域，将资源放在不同域名下 (比如二级子域名下)，这样就可以针对不同域名创建连接并请求，以一种讨巧的方式突破限制，但是滥用此技术也会造成很多问题，比如每个 TCP 连接本身需要经过 DNS 查询、三步握手、慢启动等，还占用额外的 CPU 和内存，对于服务器来说过多连接也容易造成网络拥挤、交通阻塞等。
SPDY：HTTP1.X的优化（改进版HTTP/1.1）
2012年google提出了SPDY的方案，优化了HTTP1.X的请求延迟，解决了HTTP1.X的安全性，具体如下：

  • 降低延迟： 针对HTTP高延迟的问题，SPDY优雅的采取了多路复用（multiplexing）。多路复用通过多个请求stream共享一个tcp连接的方式，解决了HOL blocking的问题，降低了延迟同时提高了带宽的利用率。
  • 请求优先级（request prioritization）：多路复用带来一个新的问题是，在连接共享的基础之上有可能会导致关键请求被阻塞。SPDY允许给每个request设置优先级，这样重要的请求就会优先得到响应。比如浏览器加载首页，首页的html内容应该优先展示，之后才是各种静态资源文件，脚本文件等加载，这样可以保证用户能第一时间看到网页内容。
  • header压缩：前面提到HTTP1.x的header很多时候都是重复多余的。选择合适的压缩算法可以减小包的大小和数量。
  • 基于HTTPS的加密协议传输：大大提高了传输数据的可靠性。
  • 服务端推送（server push）：可以让服务端主动把资源文件推送给客户端。当然客户端也有权利选择是否接收。

 4.  Http2.0

2015 年正式发布的 HTTP/2 默认不再使用 ASCII 编码传输，而是改为二进制数据，来提升传输效率。

客户端在发送请求时会将每个请求的内容封装成不同的带有编号的二进制帧（Frame），然后将这些帧同时发送给服务端。服务端接收到数据之后，会将相同编号的帧合并为完整的请求信息。同样，服务端返回结果、客户端接收结果也遵循这个帧的拆分与组合的过程。

有了二进制分帧后，对于同一个域，客户端只需要与服务端建立一个连接即可完成通信需求，这种利用一个连接来发送多个请求的方式称为多路复用。每一条路都被称为一个stream（流）。

特点：

  • 二进制协议： HTTP/1.1版本的头部信息是文本，数据部分可以是文本也可以是二进制。HTTP/2版本的头部和数据部分都是二进制，且统称为‘帧’
  • 多路复用： 废弃了 HTTP/1.1 中的管道，同一个TCP连接里面，客户端和服务器可以同时发送多个请求和多个响应，并且不用按照顺序来。由于服务器不用按顺序来处理响应，所以避免了“对头堵塞”的问题。
  • 头部信息压缩： 使用专用算法压缩头部，减少数据传输量，主要是通过服务端和客户端同时维护一张头部信息表，所有的头部信息在表里面都会有对应的记录，并且会有一个索引号，这样后面只需要发送索引号即可
  • 服务端主动推送： 允许服务器主动向客户推送数据
  • 数据流： 由于HTTP/2版本的数据包不是按照顺序发送的，同一个TCP连接里面相连的两个数据包可能是属于不同的响应，因此，必须要有一种方法来区分每一个数据包属于哪个响应。HTTP/2版本中，每个请求或者响应的所有数据包，称为一个数据流（stream），并且每一个数据流都有一个唯一的编号ID，请求数据流的编号ID为奇数，响应数据流的编号ID为偶数。每个数据包在发送的时候带上对应数据流的编号ID，这样服务器和客户端就能分区是属于哪一个数据流。最后，客户端还能指定数据流的优先级，优先级越高，服务器会越快做出响应。

缺点：

HTTP/2虽然解决了许多问题，但在TCP协议级别上仍然存在类似的队头问题，而TCP仍然是Web的构建基础。当 TCP 数据包在传输过程中丢失时，在服务器重新发送丢失的数据包之前，接收方无法确认传入的数据包。由于 TCP 在设计上不遵循 HTTP 之类的高级协议，因此单个丢失的数据包将阻塞所有进行中的 HTTP 请求的流，直到重新发送丢失的数据为止。这个问题在不可靠的连接上尤为突出，这在无处不在的移动设备时代并不罕见。

5.HTTP/3

  • HTTP/2 由于采用二进制分帧进行多路复用，通常只使用一个 TCP 连接进行传输，在丢包或网络中断的情况下后面的所有数据都被阻塞。
  • HTTP/2 的问题不能仅靠应用程序层来解决，因此协议的新迭代必须更新传输层。但是，创建新的传输层协议并非易事。传输协议需要硬件供应商的支持，并且需要大多数网络运营商的部署才能普及。

幸运的是还有另一种选择。UDP 协议与 TCP 一样得到广泛支持，但前者足够简单，可以作为在其之上运行的自定义协议的基础。**UDP 数据包是一劳永逸的：没有握手、持久连接或错误校正。**HTTP3 背后的主要思想是放弃 TCP，转而使用基于 UDP 的 QUIC （快速UDP互联网连接）协议。

与 HTTP2 在技术上允许未加密的通信不同，QUIC 严格要求加密后才能建立连接。此外，加密不仅适用于 HTTP 负载，还适用于流经连接的所有数据，从而避免了一大堆安全问题。建立持久连接、协商加密协议，甚至发送第一批数据都被合并到 QUIC 中的单个请求/响应周期中，从而大大减少了连接等待时间。如果客户端具有本地缓存的密码参数，则可以通过简化的握手重新建立与已知主机的连接。

为了解决传输级别的线头阻塞问题，通过 QUIC 连接传输的数据被分为一些流。流是持久性 QUIC 连接中短暂、独立的“子连接”。每个流都处理自己的错误纠正和传递保证，但使用连接全局压缩和加密属性。每个客户端发起的 HTTP 请求都在单独的流上运行，因此丢失数据包不会影响其他流/请求的数据传输。

6.各版本对比

 

HTTP的三次握手🤝与四次挥手🙋‍♂️

一个完整的HTTP是包含请求与响应的，所以需要通过TCP来创建连接通道

一个TCP通道可以通过多个HTTP请求

一般来讲需要通过三次握手来确认连接过程，规避因为网络原因从而产生的资源消耗，从而创建TCP连接

三次握手

  • 第一次握手： 客户端发送syn包(syn=x)到服务器，并进入SYN_SEND状态，等待服务器确认；
  • 第二次握手： 服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；
  • 第三次握手： 客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=y+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。
  • 握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。

 

四次挥手
与建立连接的“三次握手”类似，断开一个TCP连接则需要“四次握手”。

  • 第一次挥手： 主动关闭方发送一个FIN，用来关闭主动方到被动关闭方的数据传送，也就是主动关闭方告诉被动关闭方：我已经不 会再给你发数据了(当然，在fin包之前发送出去的数据，如果没有收到对应的ack确认报文，主动关闭方依然会重发这些数据)，但是，此时主动关闭方还可 以接受数据。
  • 第二次挥手： 被动关闭方收到FIN包后，发送一个ACK给对方，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号）。
  • 第三次挥手： 被动关闭方发送一个FIN，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，我的数据也发送完了，不会再给你发数据了。
  • 第四次挥手： 主动关闭方收到FIN后，发送一个ACK给被动关闭方，确认序号为收到序号+1，至此，完成四次挥手。

 

HTTP/1.0与HTTP/1.1的区别

  • 长连接

HTTP 1.1支持长连接（PersistentConnection）和请求的管道（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启Connection: Keep-Alive； HTTP1.0默认使用短连接，规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪 每个客户也不记录过去的请求。要建立长连接，可以在请求消息中包含Connection: Keep-Alive头域，如果服务器愿意维持这条连接，在响应消息中也会包含一个Connection: Keep-Alive的头域。

  • 缓存处理

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

Expires：浏览器会在指定过期时间内使用本地缓存，指明应该在什么时候认为文档已经过期，从而不再缓存它，时间为格林威治时间GMT。例如: Expires: Thu, 19 Nov 1981 08:52:00 GMT

Last-Modified：请求对象最后一次的修改时间 用来判断缓存是否过期 通常由文件的时间信息产生

Date：生成消息的具体时间和日期，即当前的GMT时间。例如:Date: Sun, 17 Mar 2013 08:12:54 GMT

If-Modified-Since：客户端存取的该资源最后一次修改的时间，用来和服务器端的Last-Modified做比较

Set-Cookie: 用于把cookie 发送到客户端。例如: Set-Cookie: PHPSESSID=c0huq7pdkmm5gg6osoe3mgjmm3; path=/

Pragma:no-cache：客户端使用该头域说明请求资源不能从cache中获取，而必须回源获取。

  • 带宽优化

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/2与SPDY的区别

  1. HTTP2.0 支持明文 HTTP 传输，而 SPDY 强制使用 HTTPS
  2. HTTP2.0 消息头的压缩算法采用 HPACK，而非 SPDY 采用的 DEFLATE

HTTP/1.1与HTTP/2的区别

  • 新的二进制格式（Binary Format），HTTP1.x解析是基于文本的，基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。
  • 多路复用（MultiPlexing），即连接共享，即每一个request都是是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。
  • header压缩，如上文中所言，对前面提到过HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。
  • 服务端推送（server push），同SPDY一样，HTTP2.0也具有server push功能。

HTTP/2的多路复用和HTTP/1.X中的长连接复用的区别

  1. HTTP/1.X 一次请求-响应，建立一个连接，用完关闭；每一个请求都要建立一个连接；
  2. HTTP/1.1 Pipeling解决方式为，若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行机会，一旦有某请求超时等，后续请求只能被阻塞，毫无办法，也就是人们常说的线头阻塞；
  3. HTTP/2多个请求可同时在一个连接上并行执行。某个请求任务耗时严重，不会影响到其它连接的正常执行；

HTTP/1.1与HTTP/2性能对比

官网提供了多种版本的对比测试有HTTP1.1与HTTP2的比较，还有服务器端推送(server-push)不同个数之间的比较：（由于网络延迟不同，测试结果或有差异）

 

可以看到分别使用HTTP/1.1和HTTP/2加载同一张由多张小图片组成的大图片：HTTP/1.1用了7.41s，而HTTP/2只用了1.47s。HTTP2比HTTP/1.1快了将近5倍。
因为为了加载这张大图，需要请求许多的小图，HTTP/1.1采用的是串行请求，所以速度要比采用并行请求的HTTP/2要慢上许多。

HTTP与HTTPS的区别

  • HTTPS

HTTPS是以安全为目标的 HTTP 通道，是 HTTP 的安全版。HTTPS 的安全基础是 SSL。SSL 协议位于 TCP/IP 协议与各种应用层协议之间，为数据通讯提供安全支持。

SSL 协议可分为两层：

SSL 记录协议（SSL Record Protocol），它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。

SSL 握手协议（SSL Handshake Protocol），它建立在 SSL 记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。

  • HTTPS的优点
  1. 使用 HTTPS 协议可认证用户和服务器，确保数据发送到正确的客户机和服务器。
  2. HTTPS 协议是由SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，要比 HTTP 协议安全，可防止数据在传输过程中不被窃取、修改，确保数据的完整性。
  3. HTTPS 是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。
  • HTTPS的缺点
  1. HTTPS 协议握手阶段比较费时，会使页面的加载时间延长近。
  2. HTTPS 连接缓存不如 HTTP 高效，会增加数据开销，甚至已有的安全措施也会因此而受到影响。
  3. HTTPS 协议的安全是有范围的，在黑客攻击、拒绝服务攻击和服务器劫持等方面几乎起不到什么作用。
  4. SSL 证书通常需要绑定 IP，不能在同一 IP 上绑定多个域名，IPv4 资源不可能支撑这个消耗。
  5. 部署 HTTPS 后，因为 HTTPS 协议的工作要增加额外的计算资源消耗，例如 SSL 协议加密算法和 SSL 交互次数将占用一定的计算资源和服务器成本。
  6. HTTPS 协议的加密范围也比较有限。最关键的，SSL 证书的信用链体系并不安全，特别是在某些国家可以控制 CA 根证书的情况下，中间人攻击一样可行。
  • 与HTTP的区别
  1. HTTP 是超文本传输协议，信息是明文传输，HTTPS 则是具有安全性的 SSL 加密传输协议。
  2. HTTP与HTTPS的连接方式不同，端口也不同，HTTP端口用的是80，HTTPS端口用的是443。
  3. HTTP 的连接很简单，是无状态的。HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全。(无状态的意思是其数据包的发送、传输和接收都是相互独立的。无连接的意思是指通信双方都不长久的维持对方的任何信息。)
  4. HTTPS协议需要申请证书，一般免费的证书很少。

HTTP优化

  • 启用长连接。TCP 和 SSL 建立新连接的成本是非常高的，有可能会占到客户端总延迟的一半以上。长连接虽然不能优化连接握手，但可以把成本“均摊”到多次请求里，这样只有第一次请求会有延迟，之后的请求就不会有连接延迟，总体的延迟也就降低了。
  • 数据压缩编码不仅可以使用标准的gzip，还可以使用新压缩算法br，有更好的压缩效果。除此之外，对于HTTP协议传输的各种格式数据，我们可以有针对性地采用特殊的压缩方式。
  • HTML/CSS/JavaScript 属于纯文本，就可以采用特殊的压缩，去掉源码里多余的空格、换行、注释等元素。
  • 图片在 HTTP 传输里占有非常高的比例，虽然它本身已经被压缩过了，不能被 gzip、br 处理，但仍然有优化的空间。比如说，去除图片里的拍摄时间、地点、机型等元数据，适当降低分辨率，缩小尺寸。图片的格式也很关键，尽量选择高压缩率的格式，有损格式应该用 JPEG，无损格式应该用 Webp 格式。
  • 刚才说的几种数据压缩针对的都是 HTTP 报文里的 body，在 HTTP/1 里没有办法可以压缩 header，但我们也可以采取一些手段来减少 header 的大小，不必要的字段就尽量不发（例如 Server、X-Powered-By）
  • 对于小文本或者小图片，可以使用资源合并的方式，把许多小资源合并成一个大资源，用一个请求全下载到客户端，然后客户端再切分后使用，好处是节省了请求次数，缺点是可能会缓存有影响，可能降低缓存的可用性
  • 尽量不使用重定向。重定向引发的客户端延迟也很高，它不仅增加了一次请求往返，还有可能导致新域名的 DNS 解析。

  • 利用好缓存，为每个资源都添加 ETag 和 Last-modified 字段，再用 Cache-Control、Expires 设置好缓存控制属性。

 

热门相关：最强狂兵   天启预报   寂静王冠   仗剑高歌   仗剑高歌