我明白这样的标题，有一定的争议性。但是它事关每个人的利益，所以无法避免这个问题。使用https，原本是每个人的自由，想用就用，不想用也可以不用。这样贴近每个的利益，又有争议性的话题，只能尽量深度去解析它，最后再得出结论。没有人会和自己的利益过不去，所以当一个人发现某样东西的好处时，争议便不存在了。

好在第1篇挂了这一年多以来，没有任何人对这篇提出反对的立场，因为文章也是用客观的数据，来阐述事实。也有很多人，在这之前，本身就是处于相同的立场。

这个新发现是，这几年来，每天晚上的国外网站特别慢，比白天慢了几倍～10倍以上，比如访问Godaddy、name.com、networksolutions这些域名管理的网站，很多网页需要十几秒以上才能打开。晚上访问国内、亚洲的网站，速度依然很快。

这是为什么呢？

在晚上访问自己的美国VPS上的站点(http)，速度也很慢，但是不会慢到十几秒以上才能打开，比如白天0.5秒打开，晚上大概1-3秒打开。

原因就是国外网站启用了https，造成在中国访问很慢。

同国的传输速度
如果访客和服务器之间的ping值在100 ms以内，路由也少很多，那么无论是白天、还是晚上，无论是http、还是https，访问速度都会很快。

ping值在100 ms或160 ms以上，中间经过更多的路由，如果当中有某个路由线路遇到带宽瓶颈，会使速度暴降。比如在同国的美国VPS间传输，前几天发现速度经常在150 MB/s以上，比如173 MB/s；但是在中国下载美国VPS的文件在晚上只有5 KB～20 KB/s。

https的速度变化
从上述的同国的传输速度规律来看，实践中，发现一位博友用国内主机，https的访问速度特别快。(当然，此时如果用http访问，其实会更快)

由于https比http多了几次握手，原本http并不快的国外服务器，用https慢了很多很多。

尤其是到了晚上的网络高峰期，在国内，访问国内的https网站，感觉不到速度下降；但是，国外的https网站，慢了5-10倍以上。

同样的，在西方国家访问他们国内的https网站，无论白天还是晚上，都感觉不到速度下降。

总之，结论就是：
1. 同国，或者ping值在100 ms以内的服务器，https无论白天还是晚上，速度都快。
2. 国外服务器，用https会有明显的速度下降，晚上特别慢，慢了5-10倍以上。

也有一些线路较好的cn2美国服务器，晚上用https访问，速度还是快的。

https究竟安全在哪里？
防止传输中，被路由服务器监(隔开)听；防止运营商在web页中添加广告(即劫(隔开)持)。劫(隔开)持，在我们这边不多见，只有宽带快到期时，会在web页添加续费的提示。

防止传输中，被路由服务器监(隔开)听，这个无法彻底避免。无论是post，还是web实体页，只要有数据传输，都会有对应的方法获取。例如web实体页，假设路由服务器记录了经过的URL，服务器在自身用wget命令，或者wget+修改UA的方式，就可以模拟客户端，从而获取web页。

防止密码被获取明文？
“防止”的目的，是假设万一有损害利害的对象存在。
https并不能彻底防止密码被获取明文，只能降低传输中，post数据被路由服务器监(隔开)听的机率。

假设万一正好客户端存在着病毒传播者事先针对浏览器种下的病毒，能够获取明文密码，那么这种情况下，无论是http，还是https，都能够获取，和传输方式没有关系。为了解决这个问题，我在前年设想了一个方案，今年已经在帐号系统里完成了该方案，即：

例如密码是123456，让JavaScript产生动态数据如afds62,323s,adfsaf2,65fs4,sa6df4a。每刷新一次，这些动态数据都是不同的。

还有一个至关重要的步骤，明文的密码的input框，必须放在<form></form>这外。而经过加密的input框，是用JavaScript从明文框获取的，用onchange、document.all.abc.value的方法。

JavaScript代码完全可以隐藏，隐藏的方法是将JavaScript程序写在(动态的扩展名)的JS文件中，该JS文件中写入不缓存到浏览器、并用访问来源判断，只限本域名内访问。

这种自行设计的加密规则，自身可以防止任何病毒的威胁，就是即使是在有病毒的机器里，依然永远不会受病毒的影响。所以加强数据安全，在这方面就是如此容易。如果您愿意的话，在这个基础上，还可以再进一步加强验证，或者开发“数字证书”。

防止数据被监(隔开)听的方案设计
https的方式是对数据进行hash加密。
我们完全可以用自行设计数据加密的方式，其运行效率可能要比https高100-10000倍以上。因为https确实额外地增加了服务器CPU资源，有一个流传甚广的数据是40%。

无论是5%，还是10%，还是40%，都是不小的数据。它对较高流量的站点的影响，并不是对应的5%、10%、40%这样的影响。有可能无影响，也可能会有很大的影响。这个数值会一直变化，有可能会慢几倍，也可能会低于10%。

自行设计数据加密，方法可以有无限种。下列分享几个我常用的方式，只要您的加密规则不专项去公布、不深度公开解析算法，那么自行设计的加密方式，哪怕是世界顶尖的黑(隔开)客，他也永远无法还原。因为这是一种捉迷藏的游戏，和技术含量无关。由于还原很消耗精力，所以没有人会闲到去还原这些数据。即使他用了30年终于还原了，这些数据对他也没有用处。

1. 半角字符，例如This is my coat. 这句话，用自定义加密法后是：jZubpd!zn!tj!tiU
2. 中文字符的加密有无数种。
a) 如果出于避开敏(隔开)感(隔开)词，只需打乱文字的排列顺序，然后在客户端用JavaScript还原。
打乱顺序的方法有很多种，比如整体倒着来，或者用穿插的顺序。例如“都是不小的数据”这句话：
倒写法：据数的小不是都
穿插法：都的是数不据小
还可以用 倒写法+穿插法。
b) 如果想彻底完全加密，可用一定规则的替换法，将所有文字替换，看到的文字全是乱码。

经过这种加密，能看到“都是不小的数据”这句话，只有客户端，任何路由服务器看到的都是乱码。

自行设计数据加密程序的CPU占用率
相对于大量的hash算法和反解析，自行设计的加密算法，上述的几个实例，建议写入数据库时直接写入加密后的数据，而不要写入 加密+还原 的数据。这样，读取数据时，会直接提取加密后的数据，此时提取数据不额外占用CPU资源；否则如果是 写入 加密+还原 的数据，则提取数据时需要重新再做一次加密，会占用一点CPU资源，但是资源占用远比hash算法要少得多，约不到1/100～1/10000。

提取服务器里加密后的数据后，传给客户端。在客户端，用JavaScript进行还原，还原的过程中会占稍微用一点客户端浏览器的资源，这个资源的占用也可以几乎忽略不计，因为它相对应的JavaScript程序，一旦运行完毕，便不再重复运行，此时不再占用客户端的CPU资源。

https并不是唯一的出路
上述列举了这些没有https时，数据的加密方法，是想说明https并不是唯一的出路。并且，也有很多站点采用了https，但是密码是明文存储的。
所以，https对于安全级别的提升，是有限的，并非是终极的安全方式。

SSL并非是新鲜事物。2003年、2004年我在浏览很多国外网站的时候，就看到一些站点有 √ 符号的Verisign的标志，那就是SSL认证、可信网站认证。2015年、2016年我的博客更新很少，回来之后，发现有很多中文博客都突然转用了https。在这之前，大部分中文博客还是使用http。

经过大量的搜索、数据对比，最终得到了标题的结论：99.9%的网站没必要用https。

喜欢用https，有很多是博客的博主，也有老博主；
喜欢用http，有很多是站长，或者老博主。

因为对于站长来说，用处不大的https，安装、维护https是一项繁琐的工作，尤其是域名、二级域名多的时候，需要一个域名一个域名地一一安装，一一定期维护。而且会降低访问速度，增加服务器CPU资源的损耗，站长当然不喜欢https。
对于站长来说，安装https唯一的好处是：顺应潮流、好看、增加网站的可信度。

https真的提高了网站的可信度？
很多第三方的https，大部分是不需要任何审核，安装了就能直接用，然后在浏览器呈现绿锁。
这个审核，其实本身就是一种“伪命题”，审核时，只要网站不太离谱，都能通过审核。
即使这种审核真的存在，审核者巴不得赶快完成、结束他的这项工作，会很快给通过审核。总之，审核的原则是只要网站不太离谱。
因此，https、SSL并不具有权威。这种“权威”，不过是SSL销售商做的宣传，或者有的用户自己骗自己(因为最终的结果是导致更好用的http会被群体废弃)。

https能加速吗？
我做了HTTPS的多组站外响应测试，HTTPS的多路复用跑分测试。测试的结果，http总是比https快。在多路复用中，https并没有传说中的快，反而是多图片加载中，http比https稍快一点。

如果主机使用大陆、香港或者亚洲的机房，https基本上速度影响不大。但是使用美国主机在白天，或者美国主机在晚上的网络高峰，大家可以去掉301跳转，分别测试http、https，http明显比https快、稳定很多，而且不是一、两倍的差距，总体可能慢了4～10倍以上。

服务器上自建第三方PHP程序，使用https
这类第三方PHP程序，例如YOU(隔开)2(隔开)PHP这类，最好使用https，防止G(隔开)F*。
最好使用自签名https，和第三方认证https的区别是少了第三方认证，其余都是一样的。这种情况，使用自签名https的理由是，自签名https安装特别方便，安全级别和第三方认证https又完全一样，只是首次访问有个安全提示。

与此同时，最好不要使用自己的博客主域名。可以用IP访问，或者备用域名，或者用hosts建立一个虚拟域名。

自签名https的安装方法如前文 http://www.auiou.com/relevant/00001512.jsp

https能否防止G(隔开)F*？
不能，只能减少机率。确实能减少流量当中，中招的机率，但是不能完全防止。
因为博客页中的文字，最终是明文呈现，检测方可以获得博客、网站中的明文。(也有很多人在博客中使用https，是为了防止这一点，其实不能防止。)

网站帐号、会员系统、登录页面是否必须用https？
IT圈内目前较公认的观点是网站帐号、会员系统、登录页面，最好用https；网站可用、可不用https。所以，建网站时，可以参考这个原则，至少网站帐号、会员系统，可以让人看起来在心理上至少有可信度。

但是如果从技术方面稍微深入思考、对比一下，从上述的“https究竟安全在哪里”和“防止数据被监(隔开)听的方案设计”的这2个副标题以下的文字部分来看，https无法彻底防止客户端里<form></form>里的明文密码框被专项病毒获取，解决的办法是无论是http还是https，都将明文密码框放在<form></form>之外，或者开发者使用更复杂的自定义规则，能够很大地降低不安全的机率。

所以在密码传输方面，https是否真的安全，是需要分情况的。

实质上，http发送的密码如果事先在客户端加过密，那么安全级别和https是完全一样的。
如果http、https都发送明文密码，那么https的安全级别比http好一些，但是都不完全安全。

80端口和443端口哪个安全？
80端口的历史非常久远，目前我们大家尚未看到80端口不安全的大规模新闻。
http除了使用默认的80端之外，可以自定义使用任意端口(已经被占用的端口如21、22、110、465、443等除外)。
https默认用443端口。

各个端口不安全、或者潜在的不安全，我个人尚未有这方面的资料和数据。

但是这里可以从另一个侧面来说，有些web动态语言，如PHP，可以把任意的字符串，转化成可执行的语句。这本是web动态语言的一个重要功能，有了这个功能可以让程序更加强大。但如果这个功能被某些第三插件非(隔开)法(隔开)利用，如博客第三方插件、博客皮肤，只要是任意的php文件，那么他可以轻松写入这个语句，这就是后(隔开)门，而且任何杀毒软件都查不出来，因为这个语句本身是符合正确语法的程序语句。

我试验了一下，这个后(隔开)门，最短可以做到仅为21字节，即：函数(@$_GET['x'])

是哪个函数，为了公共安全，无法公布。在第三方插件、博客皮肤里，写入这个后(隔开)门后，可以通过get来实现入侵者想要实现的任意功能，几乎可以控制服务器上的所有站点。

基于这个原理，一旦程序中存在后(隔开)门，那么所有的端口都是不安全的，哪怕是443端口。因为443端口，可以和80端口一样运行web动态语言。

几个月前国内出现一次某面板是否有后(隔开)门的风波。后(隔开)门可以在任意的web动态语言里植入，而且可以用很短的字节，由于它是捉迷藏的游戏，通常很难让人发现，而且任何杀毒软件也查不出来。所以，是否存在后(隔开)门，完全取决于程序作者的良心，或者有的人没有这方面的技术。

很多程序很多时候只有程序作者一个人懂。这是因为程序开发的工作量很大，比如一个几万行代码的程序，光是里面的几百行、1000行代码，一般人也没有兴趣去解读。完全解读整个项目的程序，可能还要花费开发时3倍以上的时间。这就造成了程序里的后(隔开)门，是很难被发现的。

在大约17-18年前，PHP 5刚出来不久的前后，那时的web编程教程，有一章是web动态语言的安全性对比，当时是用ASP、PHP、CGI、JSP做比较。当时的比较是ASP安全性最低，PHP中等，CGI高。如今随着年代的推移，动态语言自身有了很大变化，凡是功能越多的语言，那么它的安全性，实质上会越低，例如上述提到的仅为21字节的万能后(隔开)门。在这一层面上，功能和安全，是存在一定的矛盾取舍。

安全和隐私
从上述的功能和安全的规律来看，我们时刻处在一个潜在的不安全的网络环境。我们无法知道哪个软件不安全，哪个系统不安全，只能用一些杀毒软件来检测，只要杀毒软件不报有毒，基本可以放心，但是有很多不安全代码是杀毒软件查不出来的，因为它自身是符合正确语法的程序语句。

前些天有网友曾说，“在网络上，隐私是最不值钱的东西”，当时一下触动了我多年来自身对隐私保护的观点。这好比在现实中，人穷的时候，周围的人不会尊重自己的自尊，也不尊重自己的隐私。

隐私，对于每个人都是不同的。有的人，有些事情不想让人知道，有些事情让人知道了无所谓。
当然，有很多“隐私”不必刻意去宣扬，保持低调不会有错。

在网络上，帐号、密码，财务的帐号、密码，都是属于最高级别的隐私；涉及人身安全、个人名誉、或者会破坏人际关系的信息，也是最高级别的隐私。

除此之外，并没有太多不可告人的隐私。人们关注的更多的是工作、温饱、收入、家人，社会地位，面子。

确实需要高度隐私加密的信息，则尽量不用第三方程序、第三方插件，尽量自行开发数据加密算法。

因为业内对https已经有一定的尊崇，https似乎会让人感觉体面。但是造成的后果是，更好用的http会被渐渐抛弃，正如很多人用https，现在回不去http。
https实质上，并没有提高太多的安全级别。

前文：详解99.9%的网站没必要用https (2018)