HTTP2 in Action 中文版

元数据 §

HTTP/2 in Action 中文版

• 
• 书名： HTTP/2 in Action 中文版
• 作者： Barry Pollard
• 简介： 本书以易于理解、方便上手的方式，使用贴近用户的实例来解释 HTTP/2 协议。本书首先介绍为什么要升级到 HTTP/2 以及升级的方法 ；然后逐步深入，详细解释了 HTTP/2 协议本身及其对Web 开发的影响 ；之后介绍了部分高级内容，如流状态、HPACK 等 ；最后探讨了 HTTP 的未来。本书对于 Web 开发者和运维工程师来说是一本很有价值的参考书。
• 出版时间 2020-07-01 00:00:00
• ISBN： 9787121386718
• 分类： 计算机-理论知识
• 出版社： 电子工业出版社

高亮划线 §

1.3 HTTP的语法和历史 §

• 📌 强制添加Host首部 ^32517945-13-11550-11560

  • ⏱ 2021-12-08 18:02:08

• 📌 持久连接 ^32517945-13-13891-13895

  • ⏱ 2021-12-08 18:03:13

• 📌 在此基础上，HTTP/1.1增加了管道的概念，因此应该可以通过同一个持久连接发送多个请求并按顺序获取响应。 ^32517945-13-16204-16257

  • ⏱ 2021-12-08 18:14:06

• 📌 在HTTP/1.1中引入的Cache-Control HTTP首部比HTTP/1.0中的Expires首部的选项更多。 ^32517945-13-17260-17369

  • ⏱ 2021-12-08 18:16:20

• 📌 由于某些原因（见第2章），管道化并没有流行起来，并且客户端（浏览器）和服务器对管道化的支持都很差。因此，虽然持久连接允许在同一个TCP上顺序发出多个请求，这也是一个很好的性能改进，但大多数HTTP/1.1的实现仍然是遵循请求响应再请求再响应的模式的。 ^32517945-13-16577-16702

  • ⏱ 2021-12-08 18:18:34

1.4 HTTPS简介 §

• 📌 HTTPS使用公钥加密，服务器在用户首次连接时以数字证书的形式提供公钥。 ^32517945-14-3046-3082

  • ⏱ 2021-12-08 18:25:40

• 📌 当客户端连接到HTTPS服务器时，它将经历协商阶段（或者叫TLS握手）。在此过程中，服务器提供公钥，客户端和服务器协商所使用的加密方法，然后协商接下来要使用的共享密钥。（公钥加密很慢，因此公钥仅用于协商共享密钥。为了更好的性能，可用共享密钥加密后续的消息。） ^32517945-14-4863-5019

  • ⏱ 2021-12-08 18:32:12

2.1 HTTP/1.1和当前的万维网 §

• 📌 即使管道化技术得到了更好的支持，它仍然需要按照请求的顺序返回响应。 ^32517945-18-5365-5398

  • ⏱ 2021-12-09 12:51:43

• 📌 队头（HOL）阻塞问题 ^32517945-18-5473-5518

  • ⏱ 2021-12-09 12:52:13

2.2 解决HTTP/1.1性能问题的方案 §

• 📌 大多数浏览器可以为每个域名打开6个连接 ^32517945-19-1441-1460

  • ⏱ 2021-12-09 14:23:37

• 📌 为了进一步突破6个连接的限制，许多网站从子域（例如，static.example.com）提供静态资源，如图像、CSS和JavaScript，Web浏览器从而可以为每个新域名打开另外6个连接。这种技术称为域名分片 ^32517945-19-1491-1649

  • ⏱ 2021-12-09 14:24:18

• 📌 使用多个HTTP连接听起来不错，但它也有缺点。当开启多个HTTP连接时，客户端和服务器都有额外的开销：打开TCP连接需要时间，维护连接需要更多的内存和CPU资源。 ^32517945-19-2220-2301

  • ⏱ 2021-12-09 15:03:43

• 📌 TCP建立连接的开销 ^32517945-19-3608-3618

  • ⏱ 2021-12-09 16:26:34

• 📌 慢启动的问题 ^32517945-19-3619-3625

  • ⏱ 2021-12-09 16:26:37

• 📌 使用多个独立的连接也可能导致带宽问题 ^32517945-19-3626-3644

  • ⏱ 2021-12-09 16:29:45

2.5 从HTTP/1.1到HTTP/2 §

• 📌 SPDY在HTTP层实现了TCP的相关概念，所以它可以同时传输不同的HTTP消息。 ^32517945-22-1930-1971
  • ⏱ 2021-12-09 23:39:11

3.1 HTTP/2的支持 §

• 📌 安装这些代理需要将代理软件设置为该计算机上的公认证书颁发者，这样Web浏览器才会接受这些假证书。 ^32517945-26-4659-4707
  • ⏱ 2021-12-10 00:06:58

3.2 网站开启HTTP/2的方法 §

• 📌 可以卸载功能，并减少到应用服务器的请求 ^32517945-27-6589-6608
  • ⏱ 2021-12-10 00:17:26

3.3 常见问题 §

• 📌 Web浏览器仅支持基于HTTPS的HTTP/2 ^32517945-28-1463-1486
  • ⏱ 2021-12-10 00:22:48

4.1 为什么是HTTP/2而不是HTTP/1.2 §

• 📌 这里的帧和支撑HTTP连接的TCP数据包类似。当收到所有的数据帧后，可以将它们组合为完整的HTTP消息。 ^32517945-32-3404-3456

  • ⏱ 2021-12-10 00:36:07

• 📌 HTTP/2允许在单个连接上同时执行多个请求，每个HTTP请求或响应使用不同的流。通过使用二进制分帧层，给每个帧分配一个流标识符，以支持同时发出多个独立请求。当接收到该流的所有帧时，接收方可以将帧组合成完整消息。 ^32517945-32-4219-4325

  • ⏱ 2021-12-10 00:40:50

• 📌 HTTP/2连接在请求发出后不需要阻塞到响应返回（如第2章中所述，HTTP/1.1会阻塞） ^32517945-32-5247-5292

  • ⏱ 2021-12-10 10:55:45

• 📌 服务器发送响应的顺序完全取决于服务器，但客户端可以指定优先级。如果可以发送多个响应，则服务器可以进行优先级排序，先发送重要资源（例如CSS和JavaScript），然后是不太重要的资源（例如图像）。 ^32517945-32-5377-5476

  • ⏱ 2021-12-10 10:59:00

• 📌 为了防止流ID冲突，客户端发起的请求使用奇数流ID ^32517945-32-5710-5735

  • ⏱ 2021-12-10 11:03:59

• 📌 ID为0的流（图中未显示出）是客户端和服务器用于管理连接的控制流。 ^32517945-32-5879-5912

  • ⏱ 2021-12-10 11:05:00

• 📌 流的优先级控制 ^32517945-32-7670-7677

  • ⏱ 2021-12-10 11:13:44

• 📌 当数据帧在排队时，服务器会给高优先级的请求发送更多的帧。 ^32517945-32-7688-7716

  • ⏱ 2021-12-10 11:13:51

• 📌 支持跨请求压缩首部 ^32517945-32-9605-9614

  • ⏱ 2021-12-10 11:25:44

• 📌 在流的层面实现流量控制 ^32517945-32-8045-8056

  • ⏱ 2021-12-10 11:26:11

• 📌 HTTP/2添加了服务端推送的概念，它允许服务端给一个请求返回多个响应 ^32517945-32-9755-9817

  • ⏱ 2021-12-10 11:28:35

4.2 如何创建一个HTTP/2连接 §

• 📌 在HTTPS握手的过程中，可以同时完成HTTP/2协商，这就不需要在建立连接时增加一次跳转。 ^32517945-33-2028-2074

  • ⏱ 2021-12-10 11:40:45

• 📌 当HTTPS会话建立完成后，在同一个连接上的HTTP消息就不再需要这个协商过程了。类似地，后续的连接（不管是并发的额外连接，还是后来重新打开的连接）可以跳过其中的某些步骤 —— 如果它复用上次的加密密钥，这个过程就叫作TLS会话恢复。 ^32517945-33-4653-4797

  • ⏱ 2021-12-10 14:08:47

• 📌 ALPN很简单，它可以在现有的HTTPS协商消息中协商HTTP/2支持，不会引入额外的消息往返、跳转，或者其他的升级延迟。 ^32517945-33-5753-5814

  • ⏱ 2021-12-10 14:17:24

• 📌 h2（基于HTTPS的HTTP/2）和h2c（基于纯文本的HTTP/2） ^32517945-33-11651-11687

  • ⏱ 2021-12-10 14:32:55

• 📌 Web浏览器只支持基于加密连接的HTTP/2 ^32517945-33-9475-9497

  • ⏱ 2021-12-10 14:33:52

• 📌 前奏消息 ^32517945-33-15896-15900

  • ⏱ 2021-12-10 14:51:34

• 📌 对于支持HTTP/2的服务器，可以根据这个收到的前奏消息推断出客户端支持HTTP/2，它不会拒绝这个神奇的消息，它必须发送SETTINGS帧作为其第一条消息（可以为空）。 ^32517945-33-17267-17377

  • ⏱ 2021-12-10 14:52:27

4.3 HTTP/2帧 §

• 📌 WINDOW_UPDATE帧（0x8）用于流量控制 ^32517945-34-17129-17179

  • ⏱ 2021-12-10 16:07:58

• 📌 HTTP/2流量控制设置仅应用于DATA帧 ^32517945-34-17982-18028

  • ⏱ 2021-12-10 16:18:09

• 📌 由于HTTP/2的DATA帧默认支持被分成多个部分，这就没有必要使用分块编码了 ^32517945-34-28983-29047

  • ⏱ 2021-12-10 16:39:49

• 📌 ORIGIN帧 ^32517945-34-36718-36732

  • ⏱ 2021-12-10 16:47:25

• 📌 服务器使用它来宣告自己可以处理哪些源（比如域名）的请求 ^32517945-34-36880-36907

  • ⏱ 2021-12-10 16:47:31

• 📌 ALTSVC帧 ^32517945-34-35989-36003

  • ⏱ 2021-12-10 16:47:39

• 📌 允许服务端宣告获取资源时可用的其他服务 ^32517945-34-36167-36186

  • ⏱ 2021-12-10 16:47:48

5.1 什么是HTTP/2服务端推送 §

• 📌 因为CSS link标签没有async属性，而只使用标准的会导致渲染被阻塞，然后等待文件加载 ^32517945-37-2056-2233

  • ⏱ 2021-12-10 16:53:58

• 📌 HTTP/2中不是真正的双向流，一切都仍然是从客户端请求发起的。推送资源是为了响应初始请求而做出的额外响应。完成该初始请求后，流会被关闭，除非客户端发起其他请求，否则不能推送其他资源。 ^32517945-37-3937-4029

  • ⏱ 2021-12-10 16:56:26

5.3 HTTP/2推送在浏览器中如何运作 §

• 📌 资源不是被直接推到网页中，而是被推到缓存中。 ^32517945-39-443-465

  • ⏱ 2021-12-10 17:22:13

• 📌 Service workers是相当新的后台程序，它独立于网页运行，可以作为网页和网站的中间人。它可以让网站表现得更像原生应用，比如你可以在没有网络的时候运行。它们有自己的缓存和域名绑定。 ^32517945-39-2666-2767

  • ⏱ 2021-12-10 17:27:32

• 📌 HTTP/2推送缓存是一个短期的内存中的缓存，它和连接绑定，最后才使用它。 ^32517945-39-2935-2979

  • ⏱ 2021-12-10 17:28:46

• 📌 当资源从连接的推送缓存中被“认领”并拿出后，就不能再从推送缓存中使用它了。如果HTTP cache-control首部设置了缓存，则可以从浏览器的HTTP缓存中获取。 ^32517945-39-4368-4476

  • ⏱ 2021-12-10 17:32:10

• 📌 未认领的推送流容器 ^32517945-39-4698-4707

  • ⏱ 2021-12-10 17:32:26

6.2 一些HTTP/1.1优化方法是否成了反模式 §

• 📌 但是，先完整地下载一些资源（在HTTP/1.1下自然就是这样），比每个图片都下载一点要好（在HTTP/2下默认是这样，除非指定明确的优先级来阻止这种行为）。 ^32517945-49-8477-8555
  • ⏱ 2021-12-11 17:00:32

6.3 在HTTP/2下依然有效的性能优化技术 §

• 📌 建议使用tinypng.com，它可以快速压缩JPEG和PNG图像，并且不会对图像质量产生较大的影响 ^32517945-50-2176-2226

  • ⏱ 2021-12-11 17:04:36

• 📌 gzip仍然是最流行的压缩技术[17]，尽管brotli[18]等压缩算法正变得越来越流行。 ^32517945-50-4136-4372

  • ⏱ 2021-12-11 17:06:09

• 📌 由该图可知，Wikipedia主页可以被缓存3600秒（max-age=3600），或者说1小时。在1小时之后，使用该主页前必须重新验证（must-revalidate）。 ^32517945-50-10541-10677

  • ⏱ 2021-12-11 17:14:14

• 📌 如果你看到from memory cache，而不是from disk cache，则说明你是从另外一个Wikipedia页面，而不是从其他网站过来的，那这个时候相关的资源已经在最近的内存缓存中了。 ^32517945-50-11191-11340

  • ⏱ 2021-12-11 17:16:11

• 📌 之所以出现304响应码是因为浏览器发送了一个条件GET请求，如图6.11所示。 ^32517945-50-11933-12022

  • ⏱ 2021-12-11 17:18:52

• 📌 浏览器在缓存中发现首页，然后发现它已过期，之后发送一个页面请求——但是它说：“如果服务器上的页面比我的新，就发给我。使用上次发送页面时的修改时间（if-modified-since）或者eTag值（if-none-match）做比较。”eTag值比日期值更好用。它的值取决于具体实现，比如可以是内容的哈希值。如果同时提供了两个值（见图6.11），则if-none-match首部中的eTag值更优先。服务器进行检查，看到页面没更新，返回一个304响应，告诉浏览器持有的副本还可以使用。304响应没有HTTP正文部分，所以比完整的资源下载得快。 ^32517945-50-12293-12714

  • ⏱ 2021-12-11 17:21:19

• 📌 给网页添加一个cache-control配置，就算是一个短期的配置，也可以让网站运行更快（在缓存时间内直接从缓存加载），同时也可以节省带宽（就算缓存过期也可以使用304响应）。 ^32517945-50-13012-13125

  • ⏱ 2021-12-11 17:55:55

• 📌 可以使用短期缓存来做会话内的浏览性能提升，而且短期缓存也不太需要使用复杂的刷新缓存技术。 ^32517945-50-13478-13522

  • ⏱ 2021-12-11 17:59:31

• 📌 似地，在服务端使用缓存防止端点服务器频繁请求源站，这会带来显著的性能提升，即使缓存很短的时间[25]。 ^32517945-50-13523-13669

  • ⏱ 2021-12-11 18:00:27

• 📌 就算缓存了网页，当重载页面时，其也会尝试连接到网站来检查缓存的版本是否有效，并且当没有网络连接时，重载会失败。这种情况通常不会在移动应用里发生，它不允许你在离线时刷新。当网站使用Service Worker时，Service Worker可以中断请求，当离线时，其可以返回一个之前缓存的资源版本。这就使得在离线时也能使用缓存的网站，像移动端应用一样。 ^32517945-50-14938-15113

  • ⏱ 2021-12-11 18:05:39

• 📌 虽然使用较短的缓存周期，但是当资源过期时Service Worker并不从缓存中将其删除。这样我们可以使用304响应，而且不用担心长期缓存的问题 ^32517945-50-15180-15252

  • ⏱ 2021-12-11 18:07:19

7.1 流状态 §

• 📌 流是一个虚拟的概念，它是在每个帧上标示的一个数字，也就是流ID。所以关闭或创建一个流的开销，远小于创建HTTP/1.1连接 ^32517945-55-907-968

  • ⏱ 2021-12-11 18:28:28

• 📌 当客户端使用END_STREAM标志位，表明请求的HEADERS帧已经包含了请求的所有数据时，流就变成半关闭的状态，此时流只能被用来给客户端发送响应数据，客户端不能使用它再发送数据 ^32517945-55-1718-1858

  • ⏱ 2021-12-11 18:30:17

• 📌 当前，只有HTTP/2推送响应是由服务端发起的 ^32517945-55-2122-2145

  • ⏱ 2021-12-11 18:31:09

7.2 流量控制 §

• 📌 在连接开始时（使用SETTINGS帧），确定流量控制窗口大小（如果不指定，默认为65 535个8位字节）。然后每次都会从总量中减去发送的数据的大小，而后再将接收到的响应数据（通过WINDOW_UPDATE帧）大小加回去。 ^32517945-56-1067-1227

  • ⏱ 2021-12-11 23:29:34

• 📌 有一个连接层的流量控制窗口 ^32517945-56-1227-1240

  • ⏱ 2021-12-11 23:36:58

• 📌 而且每个流也有一个流量控制窗口 ^32517945-56-1256-1271

  • ⏱ 2021-12-11 23:37:08

• 📌 因为这个帧使用的流ID为0，所以这是会应用到所有流的连接层的限制 ^32517945-56-2757-2789

  • ⏱ 2021-12-11 23:39:44

7.3 流优先级 §

• 📌 同时支持依赖和权重，或者两者混合，可以大大增加优先级的灵活性 ^32517945-57-7327-7357

  • ⏱ 2021-12-13 13:54:50

• 📌 nghttp是基于Firefox实现的 ^32517945-57-10477-10496

  • ⏱ 2021-12-13 13:55:33

8.2 压缩的运作方式 §

• 📌 查表法 ^32517945-62-1057-1060

  • ⏱ 2021-12-13 14:03:56

• 📌 然而，查询表可能要包含在压缩后的数据中，包含与否取决于它是由格式识别的标准查询表还是由具体文本生成的动态查询表。 ^32517945-62-1879-1935

  • ⏱ 2021-12-13 14:09:58

• 📌 更高效的编码技术 ^32517945-62-2227-2235

  • ⏱ 2021-12-13 14:14:01

• 📌 Lookback（反查）压缩 ^32517945-62-4333-4378

  • ⏱ 2021-12-13 14:17:00

• 📌 文本中每个重复的部分都使用一个引用来代替，它标明解码器在之前多远处可以找到重复的文本，重复的文本有多长。引用（-20，3）说明向前去20个字符，然后取3个字符，替换该引用。 ^32517945-62-4862-4948

  • ⏱ 2021-12-13 14:17:50

8.4 HTTP/2的HPACK首部压缩 §

• 📌 HPACK（不是简写），它基于查询表和Huffman编码，但（关键）不是基于反查的压缩方法。 ^32517945-64-477-523

  • ⏱ 2021-12-13 14:25:20

• 📌 HPACK有一个静态表，包含61个常见的HTTP首部名称（有些还有值） ^32517945-64-1463-1498

  • ⏱ 2021-12-13 14:26:40

• 📌 可以使用索引2来压缩首部名，并编码DELETE。 ^32517945-64-2436-2485

  • ⏱ 2021-12-13 14:29:57

• 📌 除了静态表以外，HPACK还有一个连接级的动态表，从位置62开始（跟在静态表之后） ^32517945-64-3005-3046

  • ⏱ 2021-12-13 14:30:39

• 📌 带递增索引的字符串首部字段这个类型以01开头，当首部值不在表中，要将其添加到动态表中以备后续使用时，使用此类型。 ^32517945-64-5349-5467

  • ⏱ 2021-12-13 14:56:17

• 📌 Huffman编码，需要定义一个编码表，以给文本中每个字符指定不同的编码。对于HPACK，这个表被定义在规范中，所以客户端和服务器都知道要使用什么值来编码、解码首部内容。 ^32517945-64-10978-11063

  • ⏱ 2021-12-13 15:10:56

8.5 HPACK压缩实例 §

• 📌 然而，只有在发送方和接收方的HPACK动态表保持同步的时候该方法才有用，也就是说要保持HEADERS帧的顺序一致 —— 感谢TCP，它可以保证数据是有序的，刚好可以满足这个要求。 ^32517945-65-8525-8639
  • ⏱ 2021-12-13 15:24:43

8.7 HPACK的价值 §

• 📌 特别是在请求端，请求时首部数据占比很大 ^32517945-67-555-574
  • ⏱ 2021-12-13 15:36:35

9.1 TCP的低效率因素，以及HTTP §

• 📌 能够发送的最大数据量取决于拥塞窗口的大小，发出数据减小窗口大小，接收到数据再把窗口大小加大。开始时窗口比较小，只要网络能够处理那些增加的负载，它就随着时间增长。如果客户端的处理速度跟不上，窗口就会减小。 ^32517945-71-775-876

  • ⏱ 2021-12-13 15:54:29

• 📌 在连接刚启动时和连接闲置时，TCP慢启动算法会导致延迟。TCP比较小心谨慎，在闲置一段时间后，网络情况可能发生变化，所以TCP将拥塞窗口大小降低，重新进行慢启动流程，以再次找到最佳的拥塞窗口大小。 ^32517945-71-7098-7196

  • ⏱ 2021-12-13 18:12:35

• 📌 直接将拥塞窗口大小减半 ^32517945-71-8259-8270

  • ⏱ 2021-12-13 18:17:42

• 📌 并进入拥塞避免阶段 ^32517945-71-8418-8427

  • ⏱ 2021-12-13 18:17:59

• 📌 丢包带来的影响在HTTP/2中尤其严重，因为它只使用单个连接。在HTTP/2的世界中，一次丢包会导致所有的资源下载速度变慢。而HTTP/1.1可能有6个独立的连接，一次丢包只会减慢其中一个连接，但是另外5个不受影响。 ^32517945-71-8999-9107

  • ⏱ 2021-12-13 18:20:45

• 📌 流7和流9会在重传的数据到来之前被完整接收。但这些响应必须排队，因为TCP要保证顺序 ^32517945-71-10738-10780

  • ⏱ 2021-12-13 18:24:47

• 📌 更糟的是，如果因为TCP缓冲区太小，连接不能将所有乱序的数据包维护在队列里，它会丢掉一些包，要求重传。 ^32517945-71-11316-11367

  • ⏱ 2021-12-13 18:26:45

• 📌 在TCP层队头阻塞依然存在。一个流的丢包会直接影响到其他所有的流 ^32517945-71-11463-11495

  • ⏱ 2021-12-13 18:32:11

• 📌 TCP可以使用SACK（Selective Acknowledgment，选择性响应）响应乱序的数据包，以避免丢包时重传。比如发送了包110，但丢掉了包4，你可以响应包13和5~10。这时，只有包4需要重传。 ^32517945-71-19016-19122

  • ⏱ 2021-12-13 19:21:09

• 📌 TFO（TCP Fast Open，TCP快速打开)允许使用TCP三次握手的初始SYN部分发送初始数据包。 ^32517945-71-20278-20331

  • ⏱ 2021-12-13 19:23:13

• 📌 出于安全的原因，这个数据包只能在TCP重连时使用，而不能在初次连接时使用，它同时需要客户端和服务端的支持。 ^32517945-71-20364-20417

  • ⏱ 2021-12-13 19:24:06

• 📌 使用拥塞控制算法，PRR和BBR ^32517945-71-22780-22796

  • ⏱ 2021-12-13 19:28:16

9.2 QUIC §

• 📌 FEC（Forward Error Correction，前向纠错）试图通过在邻近的数据包中添加一个QUIC数据包的部分数据来减少数据包重传的需求。这个想法是，如果只丢了一个数据包，那应该可以从成功传送的数据包中重新组合出该数据包。这个方法可以类比于“网络世界的RAID 5” ^32517945-72-1944-2166

  • ⏱ 2021-12-13 19:35:01

• 📌 连接迁移旨在减少连接创建的开销，它通过支持连接在网络之间迁移来实现。 ^32517945-72-2593-2627

  • ⏱ 2021-12-13 19:38:59

• 📌 QUIC的目标是使用一次往返建立连接，通过同时担任连接层（TCP）和加密层（TLS）来实现此目标。 ^32517945-72-4340-4389

  • ⏱ 2021-12-13 19:42:59

• 📌 请求2使用在请求1中定义的首部索引（62和63）。如果请求1丢失了一部分，就无法完整读取首部，也无法知道动态表的状态，因此在收到丢失的数据包之前无法处理请求2 ^32517945-72-15449-15528

  • ⏱ 2021-12-13 20:04:22

10.1 关于HTTP/2的争议，以及它没有解决的问题 §

• 📌 第三方cookie如何时实现跨站跟踪 ^32517945-75-6341-6359

  • ⏱ 2021-12-13 20:45:01

• 📌 HTTP cookie随着每个请求被发送 ^32517945-75-8181-8201

  • ⏱ 2021-12-13 20:54:57

• 📌 这种情况具有安全隐患，特别是会招致CSRF（Cross-site Request Forgery，跨站请求伪造）攻击 ^32517945-75-8358-8500

  • ⏱ 2021-12-13 20:55:09

• 📌 使用SameSite属性[23]阻止包含cookie的跨站点请求 ^32517945-75-8548-8700

  • ⏱ 2021-12-13 20:55:21

• 📌 OSI模型和HTTP/2下的Web网络协议栈 ^32517945-75-15342-15364

  • ⏱ 2021-12-13 21:06:29

• 📌 HTTP/2中的大多数更改都处于传输层 ^32517945-75-17839-17858

  • ⏱ 2021-12-13 21:10:40

10.4 将HTTP当作一个更通用的传输协议 §

• 📌 gRPC ^32517945-78-3487-3491

  • ⏱ 2021-12-13 21:33:38

• 📌 使用HTTP语义和HTTP/2二进制成帧层[73]来实现基于Protobuf[74]的更高效的API ^32517945-78-3615-3855

  • ⏱ 2021-12-13 21:33:45

• 📌 使用HTTP启动另一个协议 ^32517945-78-4170-4183

  • ⏱ 2021-12-13 21:35:21

• 📌 包括使用HTTP CONNECT方法，和从HTTP升级连接（例如WebSockets） ^32517945-78-4325-4393

  • ⏱ 2021-12-13 21:35:31

• 📌 CONNECT方法，其可以将HTTP连接用作代理隧道，以连接到其他服务器和端口 ^32517945-78-4615-4661

  • ⏱ 2021-12-13 21:35:59

• 📌 代理的这种使用与中间人代理是不同的，后者创建了两个单独的HTTP连接。在这种情况下，只一个HTTPS连接，但有两个TCP连接，所以在设置成功之后，就像客户端直接连接到终端服务器一样。 ^32517945-78-5225-5316

  • ⏱ 2021-12-13 21:38:19

• 📌 对于较小的消息传送，WebSockets会比HTTP更高效，因为没有HTTP首部的开销 ^32517945-78-7586-7629

  • ⏱ 2021-12-13 21:42:47

• 📌 并且它还支持全双工通信 ^32517945-78-7665-7676

  • ⏱ 2021-12-13 21:42:51

• 📌 HTTP/2不支持此方法，因为它需要升级整个HTTP连接，这对只应该升级流的多路复用连接没有意义。因此，在HTTP/2之上的WebSockets应该使用CONNECT方法 ^32517945-78-7754-7948

  • ⏱ 2021-12-13 21:43:44

• 📌 客户端请求（为简单起见，不包括某些WebSockets首部字段）：服务端响应：此后，可以在该流的两个方向上传输WebSockets数据。该连接上的其他HTTP/2流可以继续使用HTTP，还可以用类似方式建立其他WebSockets通信，甚至其他的协议。 ^32517945-78-8008-8563

  • ⏱ 2021-12-13 21:49:26

读书笔记 §

本书评论 §