应用层及Chrome浏览器相关

chrome开发者面板

Chrome 等浏览器自带的开发者工具可以很好地观察客户端延迟指标，面板左边有每个 URI 具体消耗的时间，面板的右边也是类似的瀑布图。点击某个 URI，在 Timing 页里会显示出一个小型的“瀑布图”，是这个资源消耗时间的详细分解，延迟的原因都列的清清楚楚。

指标释义

Queued at

加入队列时间，开始时间：加入浏览器请求的时间，和浏览器开始请求的时间，相对时间，相对于打开页面后经过了多久时间。（此参数一般不需要关注。）

Queued/Queueing（排队）

因为有队头阻塞，浏览器对每个域名最多开 6 个并发连接（HTTP/1.1），当页面里链接很多的时候就必须排队等待（Queued、Queueing），这里它就等待了 4.2毫秒，然后才被浏览器正式处理。（此参数只与浏览器有关）

Stalled（阻塞）

停滞，发起连接之前，有些原因使得连接过程被推迟；浏览器要预先分配资源，调度连接，花费了 11.56 毫秒。（此参数只与浏览器有关）

DNS Lookup（DNS查询）

连接前必须要解析域名，这里因为有本地缓存，所以只消耗了 0.41 毫秒。

Initial connection + SSL （初始化连接、SSL握手）

Initial connection 整个表示建立TCP连接和SSL的时间，TCP握手的时间：Initial connection - SSL建立时间。

与网站服务器建立连接的成本很高，总共花费了 270.87 毫秒，其中有 134.89 毫秒用于 TLS 握手，那么 TCP 握手的时间就是 135.98 毫秒。

Request sent（请求发送）

表示发送网络请求所花费的时间，实际发送数据非常快，只用了 0.11 毫秒。

Waiting TTFB（等待首字节）

通常称为“第一字节时间”，也就是“首字节响应时间”，花了 124.2 毫秒；TTFB 是反映服务端响应速度的重要指标，从发送请求到收到响应之间的空隙。

这个参数表示从客户端发送请求到接收到响应首字节的时间。这个时间包括了网络延迟和服务器处理请求的时间。

Content Dowload（内容下载）

接收数据也是非常快的，用了 3.58 毫秒（Content Dowload）。接收到第一个字节之后，进入陆续接收完整数据的阶段，这意味着从第一字节时间到接收到全部响应数据所用的时间。（此参数与网络和服务器有关，主要跟网络有关，除非传输一半服务器主动断开数据）

这个下载时间包含浏览器的加载、渲染时间，换做cmd请求的话，就快很多，这点尤其注意。（在实践中发现这个特别的场景。）

参考资料

• HTTP 性能优化面面观

http协议的前世今生

HTTP版本演进

HTTP 的英文全称是 Hypertext Transfer Protocol，中文是超文本传输协议，它的奠基者 是英国计算机科学家蒂姆·博纳斯·李（Tim Berners-Lee）。1990 年，他为了解决任职的 欧洲核子研究组织（CERN）里，科学家们无法方便地分享文件和信息的问题，由此创造了 HTTP 协议。

实际上，在当时也有其他一些协议能实现信息共享的功能，比如 FTP、SMTP、NNTP 等，为什么还要另外创造 HTTP 呢？这是因为这些协议并不满足博纳斯·李的需求，比如：

• FTP 只是用来传输和获取文件，它无法方便地展示文本和图片；
• NNTP 用来传输新闻，但不适合展示存档资料；
• SMTP 是邮件传输协议，缺乏目录结构。

而博纳斯·李需要的是“图形化的、只要点击一下就能进入到其他资料的系统”。鉴于以上 协议无法实现，他就设计了 HTTP。也因为这个巨大的贡献，博纳斯·李获得了 2016 年的 图灵奖，可以说是图灵奖的一次“回国”。

在 2015 年之前，HTTP 先后有 0.9、1.0、1.1 三个版本，其中 HTTP/1.0 和 1.1 合称 HTTP/1.x。虽然谷歌在 2009 年就提出了 SPDY，但最终被接纳成为 HTTP/2，也已经是 2015 年的事了。最近几年蓬勃发展的还有 HTTP/3（也就是 QUIC 上的 HTTP/2）。但从语义上说，HTTP/2 跟 HTTP/1.x 是保持一致的。HTTP/2 不同，主要是在传输过程中， 在 TCP 和 HTTP 之间，增加了一层传输方面的逻辑。

补充： RFC7540定义了 HTTP/2 的协议规范，而 HTTP/1.1 在 1999 年 6 月的RFC2616里已经确定了大部分内容。 什么叫做“语义上是一致的”呢？举个例子，在 HTTP/2 里面，header 和 body 的定义和 规则，就跟 HTTP/1.x 一样。比如 User-agent: curl/7.68.0 这样一个 header，在HTTP/1.x 里是代表了这次访问的客户端的名称和版本，而在 HTTP/2 里，依然是这个含 义，没有任何变化。从这一点上看，你甚至可以把 HTTP/2 理解为是在 HTTP/1.x 的语义的基础上，增加了一 个介于 TCP 和 HTTP 之间的新的“传输层”。也就是下图这样：

目前最新的 HTTP/3 仍在讨论过程中，还未正式发布。它也依然保持了之前版本 HTTP 的语义，但在传输层上做了彻底的“革命”：把传输层协议从 TCP 换成了 UDP。根据 w3techs.com（一家网络技术调查网站）的数据，截至 2022 年 2 月 22 日，有 25.2% 的站点已经支持了 HTTP/3。

HTTP/2 的多路复用

HTTP/2 的多路复用（Multiplexing）是其核心特性之一，它允许在单个 TCP 连接上并行交错地发送多个请求和响应，从而显著提高了性能和减少了延迟。下面是多路复用的工作方式：

• 单一TCP连接：在 HTTP/1.1 中，每个请求通常需要建立自己的 TCP 连接。而 HTTP/2 允许多个请求和响应在单一的 TCP 连接上进行传输。
• 流和帧：HTTP/2 将数据封装在“帧”中，而每个帧属于一个“流”。流是 HTTP/2 中用于传输数据的逻辑通道，每个流可以承载一个请求-响应序列。
• 交错传输：在 HTTP/2 中，服务器和客户端可以在同一个 TCP 连接上交错地发送帧。这意味着请求和响应的帧可以相互交织在一起，而不是像 HTTP/1.1 那样必须等待前一个请求完成后才能发送下一个请求。
• 流优先级：HTTP/2 允许为每个流设置优先级，这样浏览器就可以优先处理更重要的资源，如页面的首屏加载资源。
• 流量控制：虽然多路复用可以提高性能，但也可能导致某些流的数据被其他流的数据淹没。HTTP/2 通过流量控制机制来防止这种情况，允许接收方控制发送方发送数据的速度。
• 头压缩：HTTP/2 引入了 HPACK 压缩格式，对请求和响应的头部进行压缩。由于头部信息通常在多个请求中是相似的，这种压缩可以显著减少传输的数据量。
• 并行请求：客户端可以在建立 TCP 连接后立即发送多个请求，而不需要等待响应。这减少了连接建立的延迟，因为不需要为每个请求单独建立连接。
• 无阻塞：由于请求和响应是交错传输的，一个流的延迟不会阻塞其他流。这解决了 HTTP/1.1 中的队头阻塞问题，提高了资源加载的效率。
• 资源优化：服务器可以更有效地利用可用的带宽，因为它可以同时发送多个小文件，而不是一次只发送一个。
• 更好的缓存利用：由于请求和响应可以在同一个连接上并行传输，缓存的效率得到了提高，因为浏览器可以在等待一个资源加载完成的同时，开始加载其他资源。

总的来说，HTTP/2 的多路复用通过在单个连接上并行传输多个请求和响应，减少了延迟，提高了吞吐量，并优化了网络资源的使用。

参考资料：https://coolshell.cn/articles/19840.html

常用压测工具

wrk

项目主页于常用用法示例

wrk（linux用）项目主页：https://github.com/wg/wrk

运行30秒的基准测试, 使用2个线程、100个http连接:

wrk -t2 -c100 -d30s http://127.0.0.1:8080/index.html

更常用的，会加上延迟分布于超时设置，比如，

显示延时分布的统计信息 测试1分钟 100个连接 20线程 设置超时5秒

wrk --latency  -d 60s   -c 100  -t  20 --timeout 5   http://127.0.0.1:8080/index.html

wrk安装记录

如果没有lua就先安装lua：

sudo apt install lua5.3
sudo apt install luajit
sudo apt install build-essential

然后下载wrk进行编译安装。

cd wrk
make
sudo cp wrk /usr/local/bin/

wrk常用参数

wrk --latency -c 100 -t 2 --timeout 2 http://192.168.0.30/

timeout参数很重要，会严重影响结果。

Options:

-c, --connections <N>  Connections to keep open（连接数，后面跟数字，表示http连接数）
-d, --duration    <T>  Duration of test    (持续运行时长，如: 2s, 2m, 2h)
-t, --threads     <N>  Number of threads to use   (线程数，后面跟数字，代表启动线程数量)
-H, --header      <H>  Add header to request    (为每一个HTTP请求添加HTTP头   )
 --latency          Print latency statistics  (在压测结束后，打印延迟统计信息  )
 --timeout     <T>  Socket/request timeout     (超时时间)
-v, --version          Print version details      (打印正在使用的wrk的详细版本信息)

测试结果说明：

Running 10s test @ http://127.0.0.1:8089/test/get

10 threads and 2000 connections

Thread Stats   Avg(平均)      Stdev(标准差)      Max(最大)    +/- Stdev(正负一个标准差)
    Latency      42.59ms            14.57ms             298.03ms    93.27%
    Req/Sec     2.41k                 1.48k                  5.41k           55.20%
 Latency Distribution
     50%   38.85ms (50%的请求在38.85ms内)
     75%   46.06ms (75%的请求内)
     90%   54.94ms (90%的请求s内)
     99%   66.52ms (99%的请求内)
 240310 requests in 10.02s, 35.06MB read
 Socket errors: connect 0, read 315, write 708, timeout 0
Requests/sec:  23982.45（QPS，平均每秒的请求数）
Transfer/sec:      3.50MB   (每秒传输3.59MB的流量)

标准差：

简单来说，标准差是一组数据平均值分散程度的一种度量。一个较大的标准差，代表大部分数值和其平均值之间差异较大；一个较小的标准差，代表这些数值较接近平均值。标准差如果太大说明样本本身离散程度比较高，有可能系统性能波动较大。

查看当前系统有多少个wrk的线程在工作：

top -H | grep wrk

wrk2

github上下载源码：wrk2-master.zip

项目主页：https://github.com/giltene/wrk2

解压后cd wrk2-master make就得到了二进制文件，移动到bin目录即可使用。

sudo cp wrk /usr/local/bin/wrk2
sudo chmod +x /usr/local/bin/wrk2

wrk2是一个主要基于 wrk 的 HTTP 基准测试工具。

是一个被 wrk 修改以产生恒定的吞吐量负载，并将延迟细节精确到高 9s（即当运行足够长的时间时可以产生准确的 99.9999%）。

除了 wrk 的参数之外，wrk2 通过 –rate 或 -R 参数（默认为 1000）采用吞吐量参数（每秒总请求数）

-R, --rate: 采用吞吐量参数（每秒总请求数）,默认为1000

运行了30秒的基准测试, 使用2个线程、100个http连接、并保持每秒2000个请求的恒定吞吐量:

wrk2 -t2 -c100 -d30s -R2000 http://127.0.0.1:8080/index.html
wrk2 -d 3s -c 200 -t 200 -R 10 -L https://www.baidu.com

实践中一般使用wrk就够了，wrk2很少用到。

bombardier

项目主页：https://github.com/codesenberg/bombardier

简单用法示例：

bombardier -c 100 -n 100000 -l http://192.168.12.104:8888/
bombardier -c 100 -d 10s -l http://192.168.12.104:8888/

官方文档：https://pkg.go.dev/github.com/codesenberg/bombardier

安装：

直接下载可执行二进制文件。跨平台，根据需要选择对应的平台下载。

https://github.com/codesenberg/bombardier/releases

linux下：

sudo cp bombardier-linux-amd64 /usr/local/bin/bombardier
sudo chmod +x /usr/local/bin/bombardier

虚拟机压测实战记录

物理机8888端口映射到虚拟机1（wilma）的80端口

测试页面是nginx默认的首页

在虚拟机2（victoria）上进行压测

bombardier使用

记住加-l参数，结果显示延时分布。

指定连接数、总的请求数，测试多久跑完，qps多少，吞吐量多少。

bombardier -c 100 -n 100000   -t 2s  -l http://192.168.12.104:8888/

结果：

Bombarding http://192.168.12.104:8888/ with 100000 request(s) using 100 connection(s)
 100000 / 100000 [=================] 100.00% 4616/s 21s
Done!
Statistics        Avg      Stdev        Max
  Reqs/sec      4793.87    3125.60   50887.31
  Latency       21.42ms    22.67ms   274.67ms
  Latency Distribution
     50%    13.22ms
     75%    22.64ms
     90%    47.37ms
     95%    74.47ms
     99%   126.81ms
  HTTP codes:
    1xx - 0, 2xx - 100000, 3xx - 0, 4xx - 0, 5xx - 0
    others - 0
  Throughput:     4.06MB/s

指定连接数、总的请求时间，测试能跑多少请求、qps和吞吐量多少。

bombardier -c 100 -d 20s  -t 2s -l http://192.168.12.104:8888/

结果：

Bombarding http://192.168.12.104:8888/ for 10s using 100 connection(s)
[===================================] 10s
Done!
Statistics        Avg      Stdev        Max
  Reqs/sec      4715.24    2949.86   18453.86
  Latency       21.78ms    22.21ms   210.67ms
  Latency Distribution
     50%    14.27ms
     75%    26.47ms
     90%    45.55ms
     95%    66.62ms
     99%   128.28ms
  HTTP codes:
    1xx - 0, 2xx - 45982, 3xx - 0, 4xx - 0, 5xx - 0
    others - 0
  Throughput:     3.99MB/s

指定总的请求时间比较好一点，因为指定请求数的话，时间不可控，同时应该指定超时的设置。

wrk测试

wrk  -latency  -t2 -c100 -d20s --timeout 2  http://192.168.12.104:8888/

结果：

Running 10s test @ http://192.168.12.104:8888/
  2 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    29.74ms   32.44ms 257.48ms   85.28%
    Req/Sec     2.33k     1.25k    6.10k    64.00%
  46563 requests in 10.08s, 37.57MB read
Requests/sec:   4620.51
Transfer/sec:      3.73MB

wrk2测试

wrk2  -latency  -t2 -c100 -d20s --timeout 2  -R1500  http://192.168.12.104:8888/

结果：

Running 10s test @ http://192.168.12.104:8888/
  2 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    39.31ms   73.24ms 445.18ms   87.31%
    Req/Sec       -nan      -nan   0.00      0.00%
  14756 requests in 10.03s, 11.91MB read
Requests/sec:   1471.71
Transfer/sec:      1.19MB

wrk结果的排版有点混乱。

本节参考资料：

• https://blog.csdn.net/Edidaughter/article/details/131154493
• https://cloud.tencent.com/developer/article/2340410

浏览器暂时关闭quic协议

quic是http/3的基石，也是趋势和未来

虽然quic是更先进的传输层协议，但实际使用中可能会碰到问题，尤其是在大陆。

ISP兼容性问题

因为 QUIC 为了实现 UDP 的高效，会把一些 TCP 转为 UDP，但是在国内部分地区的运营商都会针对 UDP 协议QOS限速或者丢包，这就导致 UDP 效率低下，或许速度会比正常使用TCP协议还慢很多。

而谷歌的服务器，例如 Google搜索、Youtube视频等，都部署了 QUIC 服务，这意味着当你使用已开启 QUIC 功能的基于Chromium内核浏览器访问谷歌网站的时候，会尝试使用 QUIC 方式传输数据。而碰巧你当地运营商对 UDP协议歧视，然后疯狂限速或丢包，这时候你的速度就会很感人。

注意：各地区的运营商对 UDP协议的态度不一样，有的地区QOS严重，有的地区则很轻，所以关闭 QUIC 只对部分地区用户会有加速效果！ 又或者你使用代理，而服务端没有开启 UDP 转发功能(或者防火墙没开放 UDP)，那么你可能会遇到打开 Youtube视频后，视频会一直缓冲无法加载，或者是首次打开总是慢很多（因为浏览器在尝试quic协议）。

目前看来，QUIC 未普及开，并且运营商也依然我行我素的歧视 UDP 协议（跟地区运营商有关，后面也可能放开限制。可以自行实验验证试试。），所以还是先关闭的好。

代理的兼容问题

网络流量（特别是使用QUIC协议的流量）可能在未经代理的情况下直接发送，即使你的电脑配置了VPN或其他类型的网络代理。

QUIC常用于加速网络浏览器（如Chrome）与支持QUIC的服务器之间的通信。当你的电脑或浏览器配置了网络代理（例如VPN），理论上所有的网络流量都应该通过这个代理路由，从而提供数据加密、隐私保护以及绕过地理限制等功能。

然而，由于QUIC是基于UDP的，而某些代理配置可能仅针对TCP流量有效，这就导致了使用QUIC协议的流量可能绕过代理设置，直接从你的设备发送到目的地服务器。在这种情况下，即使你使用了VPN或其他代理，使用QUIC协议的流量可能仍然暴露给你的ISP（互联网服务提供商）或其他可能监视流量的第三方。

因此，如果你希望确保所有流量都通过代理，关闭Chrome中的QUIC协议是一个解决方案，这样可以避免任何潜在的直接通信，确保所有流量都经过代理处理。

chrome关闭quic

chrome://flags/#enable-quic

设置为disable。

firefox关闭quic

about:config

network.http.http3.enable

设置为false。

代理软件设置

包括客户端与服务器端，为确保配置统一兼容，能设置的都设置为关闭。

参考资料：

• https://linux.do/t/topic/36165
• https://blog.csdn.net/joeson7456/article/details/77895647

浏览器开启DoH和ECH

DoH和ECH尽量开启，可以保障一些隐私，尤其是请求的服务端支持ECH的时候。

chrome开启DoH和ECH

设置里面搜索dns，填入阿里的公共dns。

https://223.5.5.5/dns-query 或者 https://dns.alidns.com/dns-query

开启ECH：

导航到：chrome://flags/#encrypted-client-hello

启用ECH，设置为enable。

新版本（130版本以上）已经内置并且无法搜索和设置了。

firefox开启DoH和ECH

设置里面进入隐私与安全，找到基于https的dns，选择或自定义修改。

启用ECH：

在about:config页面中搜索echconfig并启用。

Doh与ECH注意事项

• 选用合适的DoH，最好是大牌的值得信任的。
• 启用DoH前，请确保当前网络与设置域名是否能够正常的https交互；国外的很多已经被GFW封禁。
• 此外，如果启用了系统代理或者软件代理，请注意DNS的优先级，设置了DoH并不一定会真正使用到。
• 如果浏览器的DoH被代理绕过，请把代理也设置DoH（大陆DNS和远程DNS都设置成DoH，如果支持的话）。

在线验证已经开启ECH

有很多在线验证的方式，列举一些：

• https://v2ex.com/cdn-cgi/trace
• https://crypto.cloudflare.com/cdn-cgi/trace/
• https://defo.ie/ech-check.php
• https://tls-ech.dev/
• https://www.cloudflare.com/zh-cn/ssl/encrypted-sni/#results

验证结果解释

以CF提供的cdn trace工具为例。

• fl：Cloudflare 服务器实例
• h：网站域名
• ip：当前访问者的IP地址
• ts：时间戳，格式为“秒.毫秒”（bash中生成同款时间戳的命令为date +%s.%3N）
• visit_scheme：访问者使用的协议
• usg：访问者使用的UserAgent信息
• colo：被访问的Cloudflare数据中心的所在位置，此处是由IANA定义的机场代码
• sliver：请求是否被拆分成多个部分进行处理或传输
• http：访问者使用的HTTP协议版本
• loc：访问者的所在地（国家）
• tls：访问者与服务器建立连接使用的TLS版本
• sni：SNI加密或明文传输
• warp：访问者是否使用了Warp服务
• gateway：访问者是否使用了Cloudflare Gateway服务
• rbi：访问者是否使用了Cloudflares Remote Browser Isolation(RBI)服务
• kex：TLS密钥交换过程中使用的交换方式

参考资料：https://lxnchan.cn/cloudflare-trace.html

chrome关闭http跳转到https

1、地址栏输入：

chrome://net-internals/#hsts

2、找到底部Delete domain security policies一栏，输入想处理的域名，点击delete。

HSTS的启用与预加载列表

许多大型和知名的公司都启用了HSTS来提高其网站的安全性。例如，Google、Facebook、Twitter、支付宝（alipay.com）等都是启用了HSTS的大型网站。这些网站通过在服务器配置中添加特定的HTTP响应头来实现HSTS，确保用户的连接始终通过HTTPS进行，从而防止中间人攻击和其他安全威胁。

HSTS预加载列表（HSTS Preload List）是另一个增强安全性的措施，它允许网站在浏览器中被硬编码，使得即使用户首次访问，浏览器也会默认使用HTTPS连接。这样的措施在Chrome、Firefox、Safari、Opera、IE11和Edge等主流浏览器中都得到了支持。

要验证一个网站是否启用了HSTS，可以通过检查网站的HTTP响应头中是否包含Strict-Transport-Security字段来确认。此外，也可以通过访问特定的在线工具，如chrome://net-internals/#hsts，来查询特定域名的HSTS策略状态。

值得注意的是，启用HSTS是一个长期承诺，特别是当网站决定加入HSTS预加载列表时。一旦网站被列入预加载列表，除非经过复杂的删除流程，否则不能轻易从列表中移除。因此，网站在启用HSTS之前需要确保其HTTPS配置的稳定性和可靠性。

HSTS预加载列表（HSTS Preload List）是一个由浏览器维护的列表，包含了启用了HTTP严格传输安全（HSTS）的网站域名。这个列表被硬编码在主流浏览器中，如Google Chrome、Mozilla Firefox、Microsoft Edge等。当用户使用这些浏览器访问预加载列表中的网站时，浏览器会自动使用HTTPS连接，即使用户输入的是HTTP URL。

• 浏览器内置：浏览器在发布新版本时，会内置一个包含启用HSTS网站的域名列表。
• 自动HTTPS：当用户尝试通过HTTP访问预加载列表中的网站时，浏览器会自动将请求升级为HTTPS。
• 首次访问保护：即使是用户首次访问这些网站，浏览器也会强制使用HTTPS，从而避免了SSL剥离攻击的风险。
• 持久性：一旦域名被添加到预加载列表中，它会在浏览器的新版本中持续存在，直到被网站管理员申请移除。

对用户的好处：

• 增强安全性：用户在访问预加载列表中的网站时，浏览器会自动确保所有通信都是加密的，减少了中间人攻击的风险。
• 保护隐私：由于所有通信都是通过HTTPS进行的，用户的个人信息和数据在传输过程中得到了保护。
• 减少点击欺诈：用户不会被误导到不安全的站点，因为浏览器会阻止所有不安全的HTTP请求。

对网站的好处

• 提高信任度：启用HSTS并加入预加载列表的网站向用户展示了它们对安全性的承诺，这有助于建立用户信任。
• 防止SSL剥离攻击：HSTS预加载列表确保即使是首次访问的用户，其连接也始终是安全的，从而减少了攻击者通过降级攻击来剥离SSL的风险。
• 提升品牌形象：作为安全实践的一部分，启用HSTS并加入预加载列表可以作为网站对用户数据保护承诺的一个标志。
• 减少配置复杂性：一旦网站被添加到预加载列表中，用户无需担心输入HTTPS，浏览器会自动处理，这减少了用户配置的复杂性。

注意事项：

• 永久性：一旦网站被添加到预加载列表中，除非通过复杂的流程申请移除，否则该网站将一直受到HSTS的保护。这意味着网站必须始终保持其HTTPS配置的有效性。
• 移除过程：如果网站需要从预加载列表中移除，这通常涉及到一个漫长的过程，并且需要等待浏览器的新版本发布才能生效。

总的来说，HSTS预加载列表是一个强大的安全特性，它为用户提供了额外的保护层，同时也提高了网站的安全性和用户信任度。

tls信息查看与排查

curl -vk https://www.baidu.com

openssl s_client -tlsextdebug -showcerts -connect www.baidu.com:443

用strace跟踪：

strace openssl s_client -tlsextdebug -showcerts -connect www.baidu.com:443

在需要分析 OpenSSL 为什么报错的时候，你可以在前面加上 strace，这对于排查根因有不少的帮助。

注意：openssl 输出结果非常多。

在 Wireshark 里导出 Cipher Suite 的方法：

在 TLS 详情中选中 Cipher Suite，右单击，选中 Copy，在次级菜单中选中 All Visible Selected Tree Items。这时，列表就被复制出来了。

除此之外，我们还在排查 TLS Alert 40 这个信息时，通过查阅RFC5246得到了答案。 所以，在遇到一些协议类型、定义相关的问题时，最好查阅权威的 RFC 文档，这样可以获得最准确的信息。

http报文headers分界线

HTTP 报文内容，分成了头部（headers）和载荷（Payload 或者 body）两部分；HTTP 规定，头部和载荷的分界线是两次 CRLF。

也就是在最后一个 header 之后，需要有两个 CRLF，这就是头部和载荷之间的分割线。

之后就是载荷（message body）的开始了。

可能引发 HTTP 400 的 PUT 请求，其 Authorization 后面也出现了两个 CRLF，这就会被认为是 headers 的结束，payload 的开始。

但实际上，后面跟的又是剩余的 HTTP 头部项，在最后一个头部之后，又是两个 CRLF。

所以这对于 Web 服务端来说就懵了：“你这说的可不是人话啊！我只能表示我不理解。”

400 Bad Request 的根因，是客户发送的 HTTP PUT 请求的格式出现了问题。

它违背了 HTTP/1.1（RFC2616）的规定，在 Authorization 头部后面，错误地添加了两次回车（CRLF）。

这样就导致服务端认为，后续的数据都属于 payload，也就导致服务器无法正常读取这个请求，只能用 HTTP 400 来反馈这种状况了。

发送http header，为什么不标注为http请求，而是psh ack呢?

没有被标注为http的原因是，这个报文并不是完整的http请求，只是前一半（headers）。

标记为PSH的话，是因为这个报文就是当时客户端的发送队列里最后一个报文，内核会对此加上PSH标志位，这个行为不是应用程序控制的。

cookie安全相关

secure和httponly属性

Set-Cookie: sessionid=123456789; Secure; HttpOnly

httpOnly 是 Cookie 中的一个属性，它的主要作用是提高 web 应用程序的安全性。

当设置了 HttpOnly 属性的 Cookie 会在服务器端创建，但不会被 JavaScript 访问。

这意味着即使攻击者在网页中注入了恶意脚本，这些脚本也无法读取带有 HttpOnly 属性的 Cookie，从而有效防止了跨站脚本攻击（XSS）中的 Cookie 泄露问题。

在实际开发中，通常建议对所有涉及身份验证或敏感信息的 Cookie 设置 HttpOnly 属性，以增强安全性。

但是，需要注意的是，即使设置了 HttpOnly 属性，也不应将重要信息存储在 Cookie 中，因为它并不能完全防止所有的攻击，如 CSRF 攻击等。

设置了Secure，sessionid Cookie值将只会在 HTTPS 连接中被发送。

需要注意的是，如果网站没有使用 HTTPS，那么 Secure 属性将不会生效，因为 HTTP 连接下不会发送带有 Secure 属性的 Cookie。

因此，为了充分利用 Secure 属性的优势，建议网站启用 HTTPS。

总结来说，Secure 属性是增强 Cookie 安全性的重要手段，通过确保 Cookie 仅在加密的 HTTPS 连接中传输，有助于保护用户数据免受中间人攻击。

此外，如果浏览器或服务器端支持，还可以将 Secure 属性与 HttpOnly 属性结合使用，以提供额外的安全保护。HttpOnly 属性可以防止客户端脚本访问 Cookie，从而减少跨站脚本攻击（XSS）的风险。

内容安全策略CSP

内容安全策略（Content Security Policy，简称 CSP）是一种额外的安全层，用于检测并削弱某些特定类型的攻击，包括跨站脚本（XSS）和数据注入攻击等 。

CSP 的主要目标是减少和报告 XSS 攻击，通过指定有效域——即浏览器认可的可执行脚本的有效来源——使服务器管理者有能力减少或消除 XSS 攻击所依赖的载体 。

CSP 的工作原理是，通过在服务器响应头中添加 Content-Security-Policy HTTP 标头，或者在 HTML 中使用 标签来定义策略。这些策略可以控制和限制网页可以加载的资源类型，比如脚本、样式表、图片等 。CSP 策略由一系列指令组成，每个指令都描述了针对某个特定资源类型的策略 。

例如，如果你想限制网页只能加载同源的脚本和样式，并且所有图片都只能从特定域名加载，可以设置如下 CSP 策略 ：

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src example.com

这个策略的含义是：

• default-src 'self'：默认情况下，只允许加载同源资源。
• script-src 'self'：脚本资源只能加载自同源。
• style-src 'self'：样式表资源也只能加载自同源。
• img-src example.com：图片资源可以加载自 example.com。

CSP 还支持报告机制，即 report-uri 指令，用于定义接收违反 CSP 策略报告的 URL，以便开发者及时了解和处理安全问题。

超级cookie

超级cookie是一种强大的跟踪技术，它能够绕过传统的隐私保护措施，对用户的网络活动进行跟踪；这种种特殊的Cookie，能够在浏览器的隐私模式下仍然保留用户信息。

它通过在用户首次访问时生成一个随机的24位整数作为指纹，并在后续访问中通过HSTS头请求多个URL来实现。

超级Cookie的主要功能是确保用户在下次访问时自动使用HTTPS通道，即使在隐私模式下也能记住用户的访问记录。

这种Cookie可以被第三方网络程序利用，例如广告和社交媒体按钮，以进行用户追踪。

Mozilla已经在最新版Firefox中修复了这一问题，而Chrome仍然保留了HTTPS记忆功能。

数字证书与公钥私钥

关于TLS/SSL证书与公钥私钥的理解，内容参考了AI回答，如Kimi等。

知识笔记

在HTTPS协议中，公钥和私钥是确保数据传输安全性的关键技术。公钥和私钥是一对非对称加密密钥，它们在SSL/TLS协议中使用，以确保数据的机密性和完整性。

• 公钥：它是可以公开的密钥，用于加密数据。在HTTPS中，服务器的公钥被包含在SSL证书中，客户端（如浏览器）使用这个公钥来加密敏感信息，如登录凭据或信用卡信息。这样，只有拥有对应私钥的服务器才能解密这些信息。
• 私钥：它是必须保密的密钥，用于解密数据。服务器使用私钥来解密客户端发送的加密信息。私钥不应该与任何人共享，也永远不应该在任何不安全的地方传输或存储。

在HTTPS的工作流程中，当客户端访问一个使用HTTPS的服务器时，服务器会向客户端发送其SSL证书，该证书包含服务器的公钥。

客户端（浏览器）会验证这个证书的有效性，包括检查证书是否由受信任的证书颁发机构（CA）签发、证书是否过期等。如果证书验证通过，客户端会生成一个随机的对称加密密钥（会话密钥），并使用服务器的公钥加密这个会话密钥，然后将其发送给服务器。服务器随后使用自己的私钥解密这个会话密钥，这样客户端和服务器就有了一个共同的密钥来加密和解密它们之间传输的数据。

数字证书是用于验证服务器身份的一种安全凭证，它由证书颁发机构（CA）签发，并且包含了公钥、证书所有者的信息以及数字签名等内容。数字证书确保了公钥的可信度，防止了中间人攻击，因为证书的数字签名可以验证公钥确实属于证书所有者，并且没有被篡改。

数字证书通常是一个文件，它包含了证书持有者的公钥、证书持有者的身份信息、证书的有效期、证书颁发机构（CA）的数字签名等内容。数字证书的文件格式可以有多种，最常见的文件后缀包括：

• .cer 或 .crt：这两种扩展名通常用于表示X.509数字证书。它们是一种文本格式，可以包含证书的完整信息。
• .pem：这是一种基于文本的文件格式，通常用于存储和交换加密材料，如证书、私钥等。PEM文件通常以"-----BEGIN CERTIFICATE-----"开头，以"-----END CERTIFICATE-----"结尾。
• .der：这是一种二进制格式的文件，用于存储X.509数字证书。与PEM格式不同，DER文件不是文本格式，而是ASN.1编码的二进制数据。
• .p7b 或 .p7c：这两种扩展名用于表示PKCS#7证书，这是一种二进制格式，可以包含单个或多个证书以及CRL（证书撤销列表）。
• .pfx 或 .p12：这两种扩展名用于表示PKCS#12文件，它是一种二进制格式，通常用于存储证书及其私钥，以及可能的中间证书。

数字证书文件的具体后缀可能会根据证书的用途和颁发机构而有所不同。在实际应用中，证书文件的后缀名有助于区分证书的格式和用途。

总结来说，HTTPS协议使用公钥和私钥来建立一个安全的通信通道，确保数据在客户端和服务器之间传输的过程中不会被未授权的第三方窃听或篡改。公钥用于加密数据，私钥用于解密数据，而数字证书用于验证公钥的合法性。

在线检测域名证书

• https://www.ssllabs.com/ssltest/analyze.html

Chrome安装包离线下载

Chrome 浏览器各版本下载大全

官网下载，windows版本示例：https://www.google.cn/chrome/?standalone=1&platform=win64&extra=stablechannel

判断网站支不支持TLS1.3

浏览器里直接查看

F12面板->安全：

通过nmap查看

nmap --script ssl-enum-ciphers -p 443 xxx.com

结果示例：

浏览器指纹

浏览器指纹知识

网站通过该技术收集您的信息，如操作系统、浏览器版本、浏览器使用的语言、您所在的时区、屏幕分辨率、电脑安装的字体等等。然后再将这些信息拼接、整合在一起，就可以形成您独特的在线指纹，也叫浏览器指纹。每个用户的浏览器指纹都是与众不同的，在互联网上几乎不可能找到与您一样的浏览器指纹。

正是由于浏览器指纹的唯一性，即使在数十亿的庞大的互联网人群中，网站也可以精准地将您识别出来。目前，浏览器指纹识别技术的识别准确率在90%以上，有的甚至能达到99%。

更详细的可以参考以下资料：

• https://blog.browserscan.net/zh/docs/browser-fingerpringting-guide
• https://www.privacyaffairs.com/zh/browser-fingerprinting/

查看浏览器指纹信息

• https://www.browserscan.net/zh
• https://fingerprintjs.github.io/fingerprintjs/
• https://www.yalala.com/
• https://uutool.cn/browser/
• https://ip77.net/

浏览器指纹相关的插件

一般有阻止获取指纹信息的，有可以自由编辑或随机设置指纹信息的，有的浏览器内置一定的防指纹，比如Brave浏览器，更多的是靠浏览器扩展/插件去实现。这些都不一定有用，需要控制变量实际做实验才能判断是否真的生效了。

• https://github.com/omegaee/my-fingerprint
• https://www.shadowlogin.cn/article/100026

服务降级的理解

在IT领域，特别是在软件开发和系统架构中，降级通常指的是在系统遇到问题或故障时，为了保持系统的可用性和稳定性，采取的一种降低服务级别的措施。这种措施的目的是为了确保核心功能的正常运行，即使在非核心功能受到影响的情况下。

服务降级是一种常见的容错策略，它有助于在系统遇到问题时保持一定的服务水平，而不是完全停止服务。这种策略在云计算、分布式系统和大型在线服务中尤为重要，因为这些系统需要处理大量的用户请求和数据，并且需要确保服务的高可用性。

服务降级（Service Degradation）的具体含义包括：

• 功能限制：在系统负载过高或某些服务不可用时，系统可能会自动停止一些非核心功能，以保证核心功能的正常运行。
• 性能降低：为了应对高流量或服务压力，系统可能会降低服务的响应速度或处理能力，以避免系统完全崩溃。
• 资源重新分配：在某些服务不可用时，系统可能会将资源重新分配给其他服务，以确保整体服务的稳定性。
• 用户界面简化：在服务降级的情况下，用户界面可能会简化，以减少服务器的负载。
• 数据准确性降低：在某些情况下，为了保持服务的可用性，可能会提供一些近似值或缓存数据，而不是实时计算或查询的数据。
• 备用方案：系统可能会启动备用方案，如使用备用服务器或备用数据源，以确保服务的连续性。