由于https严重影响建站，本博客是全网首家揭晓https的弊端，第1篇《详解99.9%的网站没必要用https》于2018年上线，本人是webshu.com的站长(于2003年建立)，从事编程。以前的https测速只能借助第三方网站，测试的结果是，https总是比http慢，https的多路复用也比http慢(测试结果如链接)；最近的几个月，我终于想到了https速度测试的程序方法，就是用file_get_contents()函数分别远程调用https、http文件，然后对比程序完成后的运行时间。(本次编写的测试工具，是分别调用20次。)

的确，在最近的1年的时间里，整个互联网的https的速度、稳定性，比过去的https有了很大的提升，现在无论是用自签名测试、还是certbot，我在不同时间测试了不少于100次，就是隔好长时间，突然访问一个用certbot建立的https测试站，肉眼观察的感官，现在2026年的https的速度，和http的速度肉眼较难看出区别了，https的稳定性也大为提高。

本https速度测试工具下载：(作者：自由勇)
http://st.auiou.com/f/grate/speedofhttps.zip (大小：1KB)

使用方法：
1. 本程序测试的结果是用www访问主机内网的速度，有点类似于用电脑ping自己的路由器，用file_get_contents()来访问主机内网，能精确得到http、https这2者之间的速度差。

2. 该程序共有3个文件，其中test.php是主程序，可放在http或https站点，httpok.php必须放在http站点，httpsok.php必须放在https站点(不能是自签名https)。

3. 需要确保VPS的http可以访问，为了防止博客站点设置了自动把http页Rewrite到https页，通常用http://VPS的IP地址，就可以正常访问，如果不能访问，需要在Apache、Nginx里，用自己的二级域名新建一个http站点A。

4. test.php和httpok.php这2个文件，必须放在VPS的网站根目录如/var/www/html、或/usr/share/nginx/www、或/usr/share/nginx/html，或者放在http站点A的根目录，然后用 http://VPS的IP地址/httpok.php 测试能否访问。

注意事项：httpok.php所在的站点，最好是纯http站点，如果是https站点，则需要观察是否会自动跳转到https的链接，如果自动跳转到https，在测试结果的http这一栏的20次访问都会显示“第X次获取失败”，需要在Apache、或Nginx的配置文件里，临时删除Rewrite，然后重启Apache或Nginx。

5. httpsok.php文件，放在https站点、或https博客的根目录，我在测试中发现PHP 7.X或以上，这个https站点必须是SSL如certbot，不能是自签名，PHP 5.X可以是自签名。

6. 然后用 https://自己的https站点或博客/httpsok.php 测试能否访问。

7. 编辑test.php，必须修改 $ur1[1] 和 $ur1[2] 这2个值，如下图箭头所指的位置。其中，$ur1[1]为VPS的IP地址，或者http站点A的域名；$ur1[2]为https站点的域名。

注意事项：$ur1[1] 和 $ur1[2] 这2个值，要和test.php所在的VPS，都是同一VPS，这样才能在内网的环境中，得到精确的数据。

8. 访问这个test.php，例如 http://VPS的IP地址/test.php，或者 http://站点A/test.php

9. 如果显示“第X次获取失败”，必须在上述的步骤4、6里先测试，使httpok.php、httpsok.php这2个文件必须能访问。

此程序的原理：
原始的程序为：

<?php
//先测试http的访问速度
$start=microtime(true);
$e1=@file_get_contents('http://104.223.**.**/httpok.php');
$end=microtime(true);
echo ($end-$start).'<br>';

//再测试https的访问速度

$start=microtime(true);
$e1=@file_get_contents('https://testsite.auiou.com/httpsok.php');
$end=microtime(true);
echo ($end-$start);
?>

注：上述程序为原理，无访问成功的验证。

做成测试工具后，就是一次分别获取http、https的访问时间，用循环程序每次各获取20次，并增加了访问成功的验证，如果显示“第X次获取失败”说明该测试工具没有正确安装，导致http或https访问失败，必须在上述的步骤4、6里先测试。

下列测试结果的解读：
1. 在程序里我没有把20次的测试结果，再做出一个平均值，没有必要统计平均值，因为平均值无法体现稳定性，要看大面积的测试结果，所以这里罗列20次，其实次数越多，越有参考意义。

2. 可以看出https整体的速度比http慢，香港主机+PHP 7.4，https比http大约慢0.01秒～0.12、0.14秒；美国主机+PHP 5.5+https自签名，https比http大约慢0.04秒，PHP 7.4未测试。

这个https的数据目前还是比较不错的，这也是为什么现在的https的访问速度和http经常看不出区别。

但有时候，还是有区别的，有时候会达到0.2秒～0.4秒。其实就是这个差别，网站的极限吞吐量，http是https的3～10倍。

示例，比如我这次测试的是香港主机，环境是Debian 11+PHP 7.4，https为certbot，即Let’s Encrypt，测试结果如：

美国主机+Ubuntu 14+PHP 5.5，自签名https测试：

美国主机+Debian 11+PHP 7.4，因为未配置，有时间再测试，会更新此部分。

关于http2
这几年互联网出现的https，并不一定是http2，即https≠http2，这是我这几天刚发现的。因为我想测试现在安装的最新的https，是不是http3，然后用这个工具 https://http3check.net

测试的结果是，Debian 11算是较高的系统版本了，Debian 11下内置的certbot安装命令，安装的Let’s Encrypt，输入我的https地址，测试结果，并没有支持http2、http3。

也就是http2和http3有一点类似的是，安装https时，并不是全自动安装http2、http3，需要另外安装依赖包、或者编译安装，步骤较为繁琐。

关于最新的http3加速
我在网站搜索了http3的安装方法，也查到了http3加速的原理。网上说http3是基于UDP的QUIC协议，网上的资料观点是http基于TCP协议，TCP会有队头阻塞问题；http3的QUIC协议解决了队头阻塞问题。

这个我暂时没有时间测试，因为http3的安装比较繁琐。http3能否比http快，也可以用本文的工具进行测试。

关于http2、http3多路复用原理的初步重要分析
因为这涉及到http2、http3的多路复用，是不是真的会比http快？在 前面 使用第三方https测速网站，做了https的多路复用的速度测试，结果是https始终比http慢。

http2、http3多路复用，是怎样实现的？我在网络查询了很多的技术资料，就是把主程序文件里引用加载的图片、CSS、JS多次请求合并为一次，实现加速。

但实际上很难做到，很有可能几乎不可能。http2、http3在开发之初是这样设想的，但并不能实现。图片、CSS、JS这些元素，实际运行起来，还是和http一样是分别依次请求的，验证的方式是实际测试http页、https页加载多个图片、CSS、JS元素所花的时间。

实际的情况，https并未实现多个文件合并发送加速，这时候如果用http测试，会发现http会更快。

多路复用的测试工具的制作，非常难，因为需要模拟浏览器的多线程加载图片、CSS、JS元素。不像本文的https测速工具，只测试单个http、https文件的速度。这是因为浏览器对图片、CSS、JS这些元素的加戴，无论是http还是https，本身就是多线程的，会在打开网页的时候，几十个图片文件同时加载，而不是这张图片加载完毕、再加载下一张，http是这样，https也是这样，完全不需要https的“多路复用”，因为http本身就是多线程的。

如果https的多路复用，把这些网页图片、CSS、JS元素，合并为一次请求，那么本质上是不是合并为一个文件包呢？因为如果不是合并为一个文件包，那么还是需要多次请求。

假设这个合并为一个文件包的技术确实现实了，如果不能实现边下载文件包边在浏览器端解压缩，需要等全部加载完成再解压缩，那么反而会慢很多。所以，多路复用在短时间内只是一个开发目标、或者口号，很可能并未实现。

关于http的TCP协议队头阻塞的问题，通过本测试工具，连续用http的方式极速www调用网站的文件20次，可以看出总花费的时间总是0.0005秒、0.0006秒，非常短，总是比https快。可以看出，http的阻塞，比https的阻塞少得多。

网页加速重要的方法是网页启用G-ZIP，网页的访问速度大约提高1倍，这和https无关，因为http能启用G-ZIP，https也能启用G-ZIP。启用G-ZIP的方法是在PHP文件的最前面写入：

<?php ob_start('ob_gzhandler');?>

或者在Apache、Nginx的配置文件里实现。

G-ZIP类似于Winzip，主要是对文本字符，如汉字、英文、HTML这些文本的部分进行压缩，实现明显加速，而对于图片、MP3等文件的压缩率非常低，加速很有限。

关于网页的加密方法
数据加密，完全可以自主开发，不必统一使用SSL。SSL除了安装繁琐，需要定期续期，就像国内现在的小区，绝大部分有电梯的小区，电梯都必须刷卡，必须交物业费，电梯卡才给续期，物业美其名曰“升级”。

这个SSL的续期，很像电梯卡的续期。只有少数人，才能发现电梯必须刷卡，并不是为了安全，而是催收物业费。

SSL的出现，能够带动多少就业，别有用心。

http真的不安全吗？
从2018年开始，Chrome浏览器把http打上了“不安全”的标注，之后有一些浏览器跟风，比如苹果手机自带的Safari浏览器。如果说“http不安全”，到目前为止，尚未发现有“http不安全”的安全事件。这说明，主张“http不安全”的发起人，是别有用心。

解决“不安全”标识唯一的办法
博客是https最大的推动力之一，由于现在99%以上的博客都安装https，http的地位会一年比一年低。每一个https站点上线，就是为https这种道德绑(隔开)架投了一票。

其实，大部分博主在5～10年之内都会关站，这个比例大约是90%，因为最近我不得不清理失效的博友留言的链接，1029个博客，只剩下102个有效链接。所以，博客没有必须安装https。

在2013年之前，智能手机还没有普及，那时候的网上银行，必须使用电脑，而工商银行一直只支持IE浏览器，工商银行的网站有不支持当前浏览器的提示(如火狐)，后来支持Chrome 41。

同样，如果您是一位http、极限吞吐量的深度支持者，那么如果有一个流量大的网站，可以把这些给http标注“不安全”的浏览器，通过UA，都限制访问，把页面提示的风格做得工整、权威一点，并提示用户改用指定的浏览器，这是我一直很想做、又迫不得已的事情。

迫不得已，是因为我是Goo(隔开)gle的深度粉丝，Goo(隔开)gle就是http这件事做得特别不好，别的事情都很好。

关于博客、网站和搜索引擎
最好的搜索引擎无疑是Goo(隔开)gle，但在国内无法访问很多年了。从2026年开始，百度大规模地清空博客、个人网站的收录，只收录1～5页。

清空的原因，可能是百度收到了政策，只要没有IC(隔开)P备(隔开)案、或者没有使用https，你的博客、或者网站都会清空收录，就在最近几个月刚发生的事情。

360的so.com，还尚未有这个政策，正常收录。

博客有必要让搜索引擎收录吗？
在互联网相对早期，也就是2005年～2015年这段时间，非常有必要。由于搜索引擎的收录，每天至少能稳定增加30～100个以上的访问量。

然而，由于百度这次大规模对博客的收录清空，让我突然发现一件事情，搜索引擎不收录就不收录吧，因为搜索引擎带来的流量，有一部分是问问题的，但也有很多会由路人转为深度粉。

以前的路转粉用户，已经足够了。其实，一个博客如果有100位粉丝，有100个人知道你，就已经很多了。

更何况，如果你去别的博客的评论稍微留一下言(10个博客就足够，没必要发spam)，每天30以上的访问量是十分保底稳定的事情。

既然百度由于苛刻的条件不收录博客，那么百度也不再是搜索引擎，博客则自动变为“个人IP时代”。

我的博客在建立之初的几年里，也曾达到稳定每天访问几百人，因为那时候有Goo(隔开)gle的PR值。但如今看来，这些都没有意义，访问量反而花费了自己大量的时间来关注。

这几天本来我打算专门写一篇《如何快速打造一个优秀博客》，就是因为百度不再收录博客，那么绝大部分的访问量(90%以上)，基本上是没有意义的。只有博主有稳定的收益，才有真正的意义。因此，什么博客、微博、微信、朋友圈、微信群、QQ群、论坛、快手、抖音……等一切的网络社交平台，99%以上都是没有意义的。

打造一个优秀博客，就是假设如果自己已经年赚30万、或者10万、300万的情况下(这3个顺序我是特意这样排序的，本来应该把300万放在最前面，但太难了)，会怎样写博客，哪些话该说、哪些话不该说。

为什么很少见到香港人写博客？

因为有钱人没有时间，或者有时间的有钱人，他们是不理人的。

所以，这会形成一个良性循环，一旦假设自己有钱，那么一定会慢慢或多或少地出现一个机会相匹配。

我这辈子最后悔的事情之一，就是2004年初去了深圳，一去就是5年多。当时就是因为去了深圳，导致webshu.com停更。如果我没有去深圳，那么我的这个网站就不会停更。

如果能回到过去，我现在会对20多年前的自己说，一定要假设如果自己已经年赚30万、或者10万、300万，那么会做什么？

博客只要达到100篇～400篇就足够了，写得再多，意义似乎不是那么大，因为需要花费相当庞大的时间，除了练笔、爱好，写博客的本质，只要是以贡献内容为主，很多时候也成了免费贡献打工。

https能否为网站提速？
提速目前是不可能的，反而降速，速度使用本文的工具，就能做出实际的对比。如果博客、网站慢，并不是因为http，而是瓶颈在于MySQL，MySQL是非常慢的数据库。到目前为止，http只会比https快。

后面如果我有时间，也会尝试用Go语言写程序，然后实际对比PHP和Go语言的速度(PHP的运行速度很快，PHP 7.4计算100万次，耗时0.05秒)，用前面的《秒会+实战PHP程序设计培训(2)》的思路，是可以快速上手之前不会的语言的，就是移植、翻译、搜索引擎查资料的过程。

这个移植的难度，主要取决于语言自身的语法简洁程度，通常7天就能上手。由于Go语言和PHP语言现在有个共同之处，是内置在Linux主机的软件仓里，能一键全自动安装，且Go语言、PHP都占用资源极小。

Shell程序由于语法太啰嗦，即使上手，开发速度也会以几何级的速度减慢。

http是否会泄露用户的密码？
如前文的分析：
详解99.9%的网站没必要用https；http与https涉及的名誉问题；https安全吗？
详解99.9%的网站没必要用https(续2)：新发现
详解99.9%的网站没必要用https(续3)：关于网络安全

对于防止密码泄露，http和https的安全程度几乎是一样的，因为在客户端(用户的电脑)本身仍然可以有办法获得用户输入的密码。也就是说，如果厂家认为http有密码的安全问题，https则存在同样的风险。

区别是，登录时，https在发送密码(input表单)是加密传输的，厂商完全可以把<input type=password>这个表单在输入时单独做加密，这样submit发送时的密码本身就是加密的，而不是明文传输，或者web开发者用JavaScript自行做加密(我已经在程序中实现，并投入应用)，使用户提交的密码为非明文。

https能防止后(隔开)门吗？
不能，对后(隔开)门的安全性能和http完全一样。因为在 前文 试验和分析，通过 $_GET['x']，能给网页传输任意数据，甚至是任意的可执行程序。

这个后(隔开)门，仅需要21字节就能实现。

这个后(隔开)门，并非是程序的语言漏洞，也不是病毒，任何杀毒软件都检测不出来，而是基础的编程语句。由于是基础的编程语句，可在任何的web协议如https、以及未来所有更高安全的web协议中执行。

这个后(隔开)门的过程，并不是由于$_GET[]不安全，而是web开发者提前在这个程序里，写入获得$_GET[]数据的程序、并让这些数据变成可执行程序。如果没有写这个后(隔开)门，则$_GET[]是安全的。

后(隔开)门是否存在，由web程序的开发者决定，http和https都无法对其进行识别。

(本文5000余字，编辑超过200次，使用6个多小时完成，写到深夜，写作不易，请求关注。)