(本期会谈到网传http的延迟是22毫秒，https延迟是64毫秒，实际当时的速测并非如此，并非是3倍的关系，实测2026年8月以前大约56.74倍，现在大约16倍。) 就在2026-08-20 12:20的时候，这个 https测速工具 做了更新，因为网络上的时间单位都是毫秒，所以这个工具改成了毫秒，并做了一个平均值。

然后我测试了一下，发现http的延迟没变，平均0.39毫秒～1.2毫秒，https的延迟平均在6.3毫秒～25毫秒，更多是集中在12毫秒～16毫秒，现在的https速度直接是原来的3倍～4倍多。我的VPS服务器没有任何改动，也没有安装http3(太繁琐)，当时我用 uptime 命令，发现服务器被服务商重启了，是2个多小时之前重启的，这个时间也太巧合了。说明https，大约是在2天多以前、或几天前整体大提速的，分别使用香港、美国的VPS，Debian 11+PHP 7.4测试，结果都一样。

现在的http和https的延迟差异、互联网生态
在2026年8月之前，http平均每次延时0.75毫秒，测试使用的是Let’s Encrypt的SSL证书，环境是Debian 11+PHP 7.4，https平均每次延时42.56毫秒(波动较小)，https的延迟是http的56.74倍。

这次https大提速之后，https的速度是原来的3倍～4倍多，但是波动比原来大很多。

互联网生态
经过这次大提速之后，https页的访问速度，和http较难看出访问速度的差异。https现在比http大约慢12毫秒，之前https比http大约慢41.81毫秒。

访问速度差异较小。但现在的延迟(倍数)差距大约是16倍(https的延迟大约是http的16倍)，对应的并发极限也是大约16倍(http的并发极限大约是https的16倍)，对于访问量稍微大一点的站点，比如100人～200人同时在线，可能就会出现影响，更不用说几千人同时在线的站点。

另外，https的不便之处，是续期繁琐，经常需要惦记SSL证书什么时候过期。自动续期的命令不如原来好用了，Debian 11、12、13均不支持开机任务rc.local，手工添加rc.local也不生效，服务器时不时会自动重启，导致定时任务crontab命令会失效。

另一个不便之处是https将来随时可能会全面收费，且价格不菲，可以参考现在的价格，新网、阿里云、腾讯云、west.cn，SSL证书普遍的价格是基础型150元/半年，且只支持一个单域名。

如果有多个域名、二级域名，光是SSL证书就是一笔不少的额外费用，一年几千元。

在试行全面收费的初期，可能也会有超低价的SSL证书，但维护十分繁琐(续期问题)，免费的都不想用，且影响访问速度。

在SSL证书还没有强制使用的时候，大约是2014年～2017年，Go(隔开)Daddy的SSL证书是9.9美元/年。

关于web的隐私属性
以前传统的http模式下，cookie也是加密的，使用MD5加密。表单<input>里的信息，浏览器完全可以仅对这部分做加密，从而实现密码的安全。

http模式下，cookie登录页，例如电子邮箱、需要登录才能查看的论坛页，本身具有私密属性。

为什么2018年时，某浏览器不把http页全面禁止访问？
因为2018年时，互联网上的网页，https的占有率大约不到1% 。如果当时把http页全面禁止访问，或者在http出现页面型的严重警告，会使某浏览器的市场占有率在全球大跌，可能接近清零。

他们在地址栏给http打上“不安全”的提示，逐渐培养SSL证书的市场占有率。

一句话证明http是安全的
如前文，现在的Debian、Ubuntu、CentOS系统，系统内置的软件仓，都是使用http协议下载。某浏览器说“http不安全”，就等于是说Linux系统不安全。

http是安全的，另一个原因是人们是被浏览器的误导宣传到“http不安全”的视角，浏览器厂商用这种方式提升SSL证书的占有率，赚取庞大的利润，实际上http的这些危险的因素较难发生，因为攻击的技术学习门槛极高，攻击者也需要去工作，需要多种因素同时叠加，才能使危险的情形最终发生，可能性很低，浏览器厂商在不使用https的提前下，完全可以修复这些潜在的漏洞。

为什么互联网目前还无法全面封杀http、禁止80端口？
因为Debian/Ubuntu/CentOS系统下，系统内置的软件仓，全部是http链接。

如果在www上，全面封杀http、禁止80端口，Linux服务器将会无法工作，全部瘫痪。

国内的网站生态
国内的很多企业网站、医院网站，仍然使用http。https证书安装之后，并非一劳永逸，因为需要经常额外关注这个原本不需要的SSL证书何时过期，维护门槛较高。

SSL证书是由美国的公司运营，对于中文网站的内容应该几乎是接近0审查，他们看不懂中文。

因为非(隔开)法网站也能申请SSL证书，也能获得SSL证书的“可信网站”的属性。所以SSL证书的“可信网站”的属性，不具有权威，SSL证书=可信网站 这个命题是假的，网站是否可信，是取决于这个网站的历史口碑。

网传的http和https延迟时间
网传http的延迟是22毫秒，https延迟是64毫秒，实际速测并非如此。当时这位作者的测速方式，应该是把自家宽带，距离服务器的路程的所有路由延迟也算上了。因为他测得的https、http的延迟差距是64-22=42毫秒，正好和我测得的41.81毫秒相吻合。

他的测试程序，当时应该是运行在本机电脑，而不是运行在服务器上。

这个http、https的延迟、测速工具，下载地址如这里：(作者：自由勇)
http://st.auiou.com/f/grate/speedofhttps.zip (大小：1KB)

使用方法如这里

这个工具成功运行的关键是http站点必须能正常访问，不要让http自动跳转到https，如果有Rewrite语句，需要删除Rewrite语句，然后重启Apache或Nginx。

这个工具，必须运行在自己的VPS上、或博客根目录，这就相当于是和服务器的机房最近的宽带，能减去互联网上的路由延迟，从而直接获取http、或https的精确延迟时间。

这个http、https延迟、测速工具的原理是：

1. 用microtime()函数开始计时。
2. 用file_get_contents()函数获取自己VPS上的http、或https文件。
3. 再次用microtime()函数计时，减去上一次计时的时间，就是http、或https的精确延时时间。

自签名https的延时测速
测试环境分别为Ubuntu 14+PHP 5.5.9，Debian 11+PHP 7.4，测试多次，都是同一家的美国洛杉矶主机：

Ubuntu 14+PHP 5.5.9+自签名https：
CPU：Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
http：平均0.40毫秒
https：平均43.79毫秒

Debian 11+PHP 7.4+自签名https：
CPU：Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz
http：平均0.61毫秒
https：平均23.13毫秒

测试结果，说明这次的https大提速，自签名https和第三方SSL认证证书的速度一样，自签名https一样提速了。

但是，Ubuntu 14+PHP 5.5.9的https速度还和以前一样，没有提速。说明这次https大提速，对老系统、或者老PHP版本，没有提速。