| |
|
|
| 首页 淘股吧 股票涨跌实时统计 涨停板选股 股票入门 股票书籍 股票问答 分时图选股 跌停板选股 K线图选股 成交量选股 [平安银行] |
| 股市论谈 均线选股 趋势线选股 筹码理论 波浪理论 缠论 MACD指标 KDJ指标 BOLL指标 RSI指标 炒股基础知识 炒股故事 |
| 商业财经 科技知识 汽车百科 工程技术 自然科学 家居生活 设计艺术 财经视频 游戏-- |
| 天天财汇 -> 科技知识 -> 在公网上，HTTPS能否完全取代HTTP？ -> 正文阅读 |
|
|
[科技知识]在公网上，HTTPS能否完全取代HTTP？ |
| [收藏本文] 【下载本文】 |
|
在公网上，HTTPS能否完全取代HTTP？ 关注问题?写回答 [img_log] 互联网 HTTPS HTTP 在公网上，HTTPS能否完全取代HTTP？ |
|
可以。事实上，HTTPS早就完全取代HTTP了。 首先我们要算一下加密算法的消耗。在老掉牙的、主频仅有2.3GHZ的4代i7 4712MQ上测试，其结果为： |
|
|
|
|
|
|
|
|
|
|
|
而非对称加密算法消耗就大一些： |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
注意以上数据是在2.3GHZ主频的4代i7上面跑出来的。这款CPU可能比现在的手机CPU都高明不了多少。 但，即便在这款CPU上，AES 128的加密速度也可以轻松超过100MB/s，甚至在特定加密模式中可达500~600MB/s。这个速度已经远超当时的机械硬盘能达到的传输速率。 至于延迟（setup key and IV），则最高不过是0.8x个微秒而已（注意是微秒，也就是不足千分之一个毫秒；而非对称加密的单位是毫秒，常用的RSA 2048的加密/解密分别需要0.21/4.81个毫秒，这个延迟相对来说还是很可观的）。 如果你做过系统分析、或者主持开发过web服务系统，就知道，web服务器的主要消耗在数据库查询/硬盘读取上。 至于逻辑处理……web服务系统都用PHP这种解释执行的渣渣了，它在乎这点消耗？ 尤其是，在全球反监听运动的推动下，目前的web服务器已经全盘HTTPS化了；这个需求也迫使之后各家的CPU全部内置硬件加密支持、且效率越来越高。 比如，在2.4G主频的i5-9300H上面、通过AES-NI指令集加速后，AES加密已经达到1.99GB/s的惊人速率了： |
|
|
且加密/解密时间只需73/111个CPU周期，这个延迟对web应用这种粗笨玩意儿来说完全可以忽略不计。 更恐怖的是，通过FPGA加速，2005年的AES加密速率都已经可以跑到70Gbit/s了： |
|
|
而如果在GPU上跑的话，速度也可以更快： |
|
|
总之，使用HTTPS完全取代HTTP是个早已解决的问题。 当然，“传统”的http协议设计是无连接模式，每次请求都要与服务器握手。 这对无加密的http来说无所谓；但对需要加密的HTTPS来说，每次握手都要重新验证双方证书（需要动用非对称加密算法如RSA，且需RSA2048位或其他算法的对应强度）、通过D-H算法协商新密钥、然后才能启用AES通讯。这个延迟和计算消耗都是非常大的。 如果再考虑DNS-over-https的开销，首次访问的延迟人肉都能感觉出来了。 尤其在类似RPC这样的应用场景里，每次都验证、协商……那实在太恐怖了。 幸好，业界也早已有了http长连接方案；只要保持连接不断开，那么之后的每次http请求都可以直接利用之前协商的密钥，无需每次都走流程了。 另一个麻烦是CDN。 简单说，现在的WEB架构压根不会用昂贵的通用服务器或计算节点通过企业自己购置的专线提供静态内容访问。这在任何方面都太不合算了。 正确的做法是把图片、视频乃至新闻文本、设置页面格式的css文件等等统统放在自建或者购买的第三方CDN服务器上；只有用户登录、上传/修改内容才会抵达源服务器——然后新修改的内容被迅速同步到CDN服务器上。 CDN服务器由专门的CDN服务商维护；这种服务商会就近在各大城市购买便宜量大的城域网带宽（注意是城域网带宽，不是骨干网带宽，后者成本太高了。买城域网就地缓存更划算）；然后逐层缓存内容，以更低的成本向服务区域的用户提供极大的带宽。 你的用户用了多少带宽、你的静态内容占了多少T的存储空间，你就付他们多少钱。 比如，我曾经刚发个帖子就把链接给外地的朋友；然后对方就会告诉我，看不见，是不是被删了？ 我自己检查，有啊，我能看见！ 然后再一转念，得了，你先别着急，过个几分钟再看吧——估计内容没同步到你那边的CDN。 果然， 稍微一等，能看到了。 不过，既然CDN经常是第三方服务器，它又如何缓存https的加密内容呢？ 这里需要一个前置知识：在http时代，一切都是明文；CDN可以把http通信中携带的任何文本、图片、视频信息都自动识别和缓存下来；但现在https是全文加密的，你怎么识别其中的静态内容呢？ 答案是极其的简单粗暴和……不靠谱。 简单说就是他们会给CDN持有的私钥签署一份证书，证明它也是合法的持有知乎域名的服务器！ 当然，这样漏洞太大；因此稍微讲究一点的还会在源头就把静态内容分离出来、单独放在一个类似http://img.zhihu.com或者http://static.content.zhihu.com的域名下，然后把这个域名签署给CDN服务商。 总之，借助CDN，你在网上一个月5美元租一个2M公网带宽的、最便宜的VPS，然后把自己的技术博客/日记/照片放在上面，它可能也能撑得起上百万用户群的访问！ 只要你别搞太多的互动，足够了。毕竟都是CDN服务的， 除了登录、留言等会改变原始内容的操作外，压根不会回源。 CDN的存在实质上是把“逻辑密集型访问”和“内容密集型访问”给分开了；前者瓶颈一般在数据库访问、复杂的处理逻辑以及服务器间通讯（比如和支付服务器联络以完成交易等）上面；后者则主要卡在磁盘随机访问性能上。 至于加密那点需求，对已经进入淘汰周期的、超多核心的EPYC CPU来说不过是点毛毛雨。 更有甚者，喏： |
|
|
|
|
|
没错。较新的EPYC以及Intel的服务器CPU已经支持安全内存加密（SME）和安全加密虚拟化（SEV）了。 简单说，这个技术可以把内存中的操作系统核心数据和虚拟机内存里面的要害信息加密，从而使得哪怕你采用冷冻内存技术也无法读取核心机密；或者，哪怕你在宿主系统以hypervisor身份攻击虚拟机，也无法触及它内部的机密！ CPU-内存这种恐怖的带宽/延迟要求都能加密保护（虽然仅仅保护了要害信息），http那点可怜巴巴的、拿php这种解释执行的语言都足够支持的应用……对现在的服务器来说，的确需要一点性能消耗，但真不是什么无法解决的难题。 PS：又看了眼资料（还是懒得在上面花太多时间，哈哈），TME/SME是直接集成于内存控制器的。也就是说它并不是之前以为的“只加密要害信息”，而是加密了整个主内存。 在这个基础上，SEV进一步为每个虚拟机设置了一个单独的加密密钥；这就使得宿主操作系统（hypervisor）也无法窥探虚拟机内的任何内容。这就彻底避免了一旦黑客攻陷宿主机（或者从某个虚拟机逃逸成功、攫取宿主机权限后）、以宿主机为跳板攻击虚拟机的可能。 换句话说，目前的加密硬件已经足以撑满DDR5的超高带宽了——想想也是，2005年借助FPGA都已经能达到70GBps的AES加密带宽了，如今都20年了，如果还搞不定内存带宽，那研究人员也可以买块豆腐一头碰死在上面了。 PS2：找AI问了一下，intel/AMD的内存加密技术用的是AES128甚至AES256（昨晚自己琢磨，以为可能采用RC4之类流加密，从而极限降低带宽损耗和访问延迟；没想到居然一步到位上了AES128/256）；在DDR5上，它带来的延迟低于10~15%，性能损耗在最差情况下仍低于10%；典型值在1%~10%之间；除了内存密集型任务，实际损耗在7%以下，典型值为1~4%，尤其在选择仅加密要害信息后，性能损耗更低。 送礼物 还没有人送礼物，鼓励一下作者吧 |
|
不能 加密的开销不利于极限吞吐量 在特定内网等可信环境，没有必要考虑加密改善安全性，明文http在低配设备上吞吐快得多 单线程四万兆跑满https的设备到现在还没出现呢，理想内网都不可能，因为单核不够用 |
|
不能,最近碰到一个相当头疼的问题 想用Websocket搓游戏客户端,HTTPS必须强制开启WSS,也就是加了SSL的websocket. 因为服务端纯手搓Websocket部分,因此使用了WSS代理,对于连接部分怎么抓都多了几百毫秒的延迟。后面看来看去，就是消耗在了SSL连接的部分。 对于需要多次一次性交互但有延迟要求的业务来说，已经是肉眼感知的到的延迟了。 其实连接时的延迟还好，问题是数据直接传输仍然比TCP直连多了几十毫秒的延迟。 AES Invcipher速度仅有十几兆每秒,也就是说如果你传输10KB数据,就能造成毫秒级以上的延迟了. 对于延迟需求较高的业务,实在是非常严重的影响了. 其实我自己都不是很想用web做业务端程序,TCP直连都丝滑的一笔 奈何对用户来说,开个网页就能用实在是太方便了. 唉! ====================================================== 很多同志认为延迟应该不可能那么高,所以这里我放上我的测试代码部分,我的测试节点放在了TCP connect的api调用部分 |
|
|
websocket则放在了这里(Webassembly Emscripten) |
|
|
在数据处理部分,tcp直连和websocket走的是同一套数据处理层,所以用tcp作为对照组, |
|
|
可以看到TCP连接时间<1ms,哪怕发送1MB的数据,延迟基本都在4ms以内 然后Websocket连接,按照以上代码,开始连接到连接确认,仅本地127.0.0.1的延迟就达到了150ms(有些时候甚至超过了300ms),发送1MB数据,延迟接近50ms,600kb约30ms,和大小呈正相关的关系 |
|
|
但TCP直连和大小关系不大,因为两个连接的服务端数据处理流程都是一致的,都是收缓存-拼接-分帧,websocket多了一个按字节异或的流程,但这个处理流程耗费应该是忽略不计的.,所以这个延迟应该不是网络传输或者服务端数据处理造成的. 当然从连接层面看,websocket必定是会比TCP连接慢几倍,因为websocket基于TCP,在TCP连接后,客户端需要发送Upgrade包,在服务端收到后,回应Switching Protocols后,客户端收到,这个链接才算正式建立,因此连接慢数倍以上这个是肯定有的,因此如果网络情况不好,tcp连接在十毫秒以上,websocket几十ms这个非常有可能,而wss加上ssl握手部分,可能在这个基础上再次翻倍. 但本地回环网络连接也超过数百毫秒,可能和chrome底层的数据处理机制有关. 而正常的数据包发送,tcp基于流式的,websocket则需要拼包,多出来的几十毫秒,应该也不是网络传输的实际延迟, 但本地回环网络数据传输延迟也超过数十毫秒,仍然只能说可能和chrome底层的数据处理机制有关. |
|
不能，举个栗子：登录路由器后台：192.168.1.1，此时一定用的是http，因为加了不安全的自签证书会被提示不安全（特别地，proxmox VE的默认自签证书强行https个人认为是异端，你不能要求每个用户都给ip地址映射一个域名，如果有，那也应该由nginx/tomcat反代完成https部署） 如果路由器管理界面他给你了一个域名（例如http://tplogin.cn），那么在局域网内也不会是https,因为路由器返回的内容无法证明它是证书的拥有者（毕竟随便把密钥满世界路由器乱放那还加个毛线密，分分钟给你中间人劫持了）并不能让内网访问更加安全 |
|
HTTPS只是用TLS来传输HTTP，并没有对HTTP协议作改动。 所以，根本就不是什么取代的问题，HTTPS存在，HTTP就存在。 不加密的HTTP流量倒是越来越少了，因为现代CPU已经硬件支持相关加解密算法，不存在运行效率问题了。 一般开发调试时，还是会用HTTP，方便抓包，上线前再切换成HTTPS，再做一些回归测试和HTTPS特有的用例。 送礼物 还没有人送礼物，鼓励一下作者吧 |
|
帮大家回忆下：http时代的互联网是什么样子？ 大型网站比如优酷会被运营商塞入弹窗广告 下载地址比如游戏安装包会被替换为别的东西，比如诈骗或者sq软件。 小网站更惨，直接给你替换成别的网站。 时至今日网民、站长没有继续被花式x，应该由衷谢谢https |
|
可以的； 市场端 Chrome 浏览器就是不遗余力的 HTTPS 吹； Google 先把 HTTPS 权重提高，让不部署 SSL的网站排名被靠后倒逼企业普及HTTPS； Chrome 把未部署HTTPS的网站标记为不安全，甚至在输入表单的页面还会高亮，让企业投鼠忌器不得不部署 HTTPS； -- 政策端 斯诺登事件无疑让各国民众企业开始重视数据保护，防劫持监听就是其中重要一环；中国也陆续推出《密码法》、《网络安全法》，开始明确企业对于数据保护的权责；无疑，政策端已经开始倒逼企业开始重视 HTTPS； -- 供给端 美帝的提速降费：ISRG 推出的 LetsEncrypt 无疑将HTTPS的部署成本降低至冰点，90天加API续期让不少开发者、小公司惊呼我曹真香；LetsEncrypt甚至将自己的自动申领协议写入RFC成为互联网标准； 众多商业 CA 开始重视起低端市场，DigiCert 与部分渠道合作的低端品牌月签发量合计150万张，无疑现在部署HTTPS的成本已经接近冰点； 你问什么时候适合部署HTTPS？ 别问，问就是现在； HTTPS确实能取代HTTP协议；即使内网IP，也可以解析域名来实现全加密；甚至DNS over HTTPS都已经成为RFC标准，还有什么不能被 TLS 的呢？ - - - 帝玺，商用加密证书，提供IP证书、EV证书、通配符证书；私信我可获得6个月体验； https://www.digital-sign.com.cn/ |
|
并不能. 一个最明显的例子. 有部分分布式系统/微服务架构系统, 其组件内部通讯就是走的 http. 这种组件内通讯有什么上 https 的必要么请问? |
|
HTTP 的全称是啥？Hyper Text Transfer Protocol，超文本传输协议，HTTP 定义出了“报文” (message) 的概念，没有 HTTP，只用 TCP，收发两端操作的是 stream：当你作为一个 stream 的 consumer 的时候，你不知道它什么时候有 data 可以读，也不知道在下一次读 data 的时候，可以读到多少，类似的，你作为 producer，你不知道它什么时候可以 write，也不知道可以 write 的时候可以 write 多长的数据。换句话说 stream，或者 TCP 它本身是 boundless 的，你每一次只能读或者写消息的片段 (fragment，或者 chunk），而不能一次性读/写一个完整的 message。 到了 HTTP 咱们才有了报文的概念，就好像是你一次性可以用 HTTP 发送一个报纸，一张纸，或者一本书的内容，而且，接收端是可以一次性接收完全完整的消息报文的。当然，如有必要，并且 HTTP 协议实现支持，“用户”某些时候也可以直接操作底层的 TCP 连接。 所以，我希望能够一次性收/发完整的 message 而不是每一次收发零碎的 chunks 再自己组成完整的 frame，我又不希望自己实现 procotol framer，不希望重复造轮子，我也不希望当我有可以大的 message 需要发送时，需要憋屈地等待 socket 文件每一次 ready 时写入那么一部分并且自己更新 buffer，那么我可以用 HTTP。 然而现在，你说要用 HTTPS 取代 HTTP，这就相当于说，你把 HTTP 的 framing 功能和 TLS 的安全功能捆绑在了一起，捆绑销售，强制售卖了，等于说是。这时如果我认为 TLS 是不必要的，那我就不能用 HTTP，只能再自己手动实现一套 framer 和 serializer，显然这是不合理的。 我们这么类比：HTTPS 就好比登山靴，HTTP 就好比拖鞋。当然我们知道登山靴也安全，舒适，可是你能说，登山靴就可以完全取代拖鞋吗？显然登山靴的穿脱比拖鞋要麻烦一些，而且登山靴进水了也不舒适所以不能穿着它来洗澡，登山靴和拖鞋有各自的适用范围，当你只是希望防滑、避免脚部直接接触地面，而不需要户外登山，那么拖鞋就足够了。 假设要在内网起一个临时地 HTTP server 或者一个功能简单的 HTTP server，假设这时已经没有了 plaintext HTTP 只要 HTTPS，那么证书你如何签发呢？如果是自签的证书你需要在客户端手动信任，或者提前在内网部署好私有 PKI，如果是用公共 CA 签发，那你需要注册一个域名，或者需要连接到公网才能获取到证书，就算是通过 DNS 验证域名所有权，也需要把签发了的证书传进内网。所以很麻烦，只是想起一个简单的 HTTP server 而已。 |
|
HTTPS基于HTTP啊，怎么替代？ HTTPS就是加密的HTTP，本质上是儿子和爹的关系。 再说，全用HTTPS，难道内网也全用HTTPS吗？环回地址和机内通信也用HTTPS？嫌CPU性能过剩？ |
|
HTTPS并不能完全取代HTTP，但它是在HTTP基础上的重要增强，用于提供更高级别的安全性和数据加密。HTTPS通过在HTTP协议之上添加SSL/TLS层，实现了对通信内容的加密，这防止了中间人攻击和数据窃听。它的SSL证书验证机制还可以确保用户连接到的是可信网站，增加了用户的隐私保护。 尽管HTTPS对于涉及敏感信息的应用场景（如电子商务、银行交易等）是必要的，但在一些不太注重隐私和安全的地方，比如简单的网页浏览或内部企业网络，HTTP仍然是可用的选择，因为其更轻量级，性能上可能会有优势。因此，HTTP和HTTPS在许多场景下是共存的，并非一种替代关系。 很多人还是会觉得HTTPS实施有门槛，这个门槛在于需要权威CA颁发的SSL证书。从证书的选择、购买到部署，传统的模式下都会比较耗时耗力。 其次，HTTPS普遍认为性能消耗要大于HTTP，因为与纯文本通信相比，加密通信会消耗更多的CPU及内存资源。如果每次通信都加密，会消耗相当多的资源，平摊到一台计算机上时，能够处理的请求数量必定也会随之减少。但事实并非如此，用户可以通过性能优化、把证书部署在SLB或CDN，来解决此问题。举个实际的例子，“双十一”期间，全站HTTPS的淘宝、天猫依然保证了网站和移动端的访问、浏览、交易等操作的顺畅、平滑。通过测试发现，经过优化后的许多页面性能与HTTP持平甚至还有小幅提升，因此HTTPS经过优化之后其实并不慢。 HTTP的缺点 HTTP主要有这些不足： 1.通信使用明文，内容可能被窃听 |
|
|
2.不验明通信方身份，因此有可能遭遇伪装 |
|
|
3.无法验证报文的完整性，所以有可能已经篡改 |
|
|
HTTPS是身披ssl外壳的HTTP 通常情况下HTTP是直接和tcp层进行通信的。当使用ssl时，则演变成HTTP先和ssl通信，ssl再和tcp通信的了。 |
|
|
加密技术 讲解ssl前，科普一下加密方法，ssl采用的是一种叫做“公开密钥加密”的加密处理方式。 对称加密 加密和解密用的是同一个密钥的方式称为对称加密，也叫做共享密钥加密。 |
|
|
对称加密在发送加密信息时也需要将密钥发送给对方，但这样可以被攻击者截取，就不安全了 |
|
|
非对称加密 非对称加密又称作公开密钥加密，它可以很好的解决对称加密密钥被截取的问题。 非对称加密采用一对非对称的密钥，一把叫做私有密钥，一把叫做公有密钥。 使用非对称加密，发送密文一方使用对方的公有密钥进行加密处理，对方收到加密信息后，再使用自己的私有密钥进行解密。 |
|
|
HTTPS采用混合加密机制 HTTPS采用对称加密和非对称加密所混合的加密机制。 若密钥能安全交换，那么有可能仅考虑非对称加密。 但是非对称加密与对称加密相比，处理速度相对较慢。 |
|
|
公开密钥的认证 使用数字证书认证机构和其颁布的公开密钥证书进行认证。即让第三方独立机构进行验证。 |
|
|
|
|
|
私有密钥是保存在服务器端的～ 注意！：认证是要钱的！！！ HTTPS安全通信机制： |
|
|
下图是完整的HTTPS的通信过程 |
|
|
为什么HTTPS不是那么普及 1.加密通信与纯文本通信相比，消耗更多的cpu和内存资源 2.购买证书是要钱的！ 3.少许对客户端有要求的情况下，会要求客户端也必须有一个证书。 （这里客户端证书，其实就类似表示个人信息的时候，除了用户名/密码，还有一个ca认证过的身份，应用个人证书一般来说，别人是无法模拟的，所以这样更能更深的确认自己的身份。目前少数个人银行的专业版是这种做法，具体证书可能是拿U盘作为一个备份的载体。） HTTPS一定是繁琐的 1.本来简单的HTTP协议，一个get，一个response，由于HTTPS还要密钥和确认加密算法的需要，单握手就需要6/7个往返，任何应用中，过多的round trip 肯定影响性能。 2.接下来才是具体的HTTP协议，每一次响应或者请求，都要求客户端和服务器对会话做加密/解密，尽管对称加密/解密效率比较高，可是仍然要消耗过多的cpu，为此有专门的ssl芯片，如果cpu性能比较低的话，肯定会降低性能，从而不能serve更多的请求。 HTTPS的好处 1.seo方面 谷歌曾在2014年8月份调整搜索引擎算法，并称“比起同等HTTP网站，采用HTTPS加密的网站在搜索结果中的排名将会更高。” 百度也曾在站长平台声明，HTTPS有一定的排名优待。 2.安全性 尽管HTTPS并非绝对安全，掌握根证书的机构，掌握加密算法的组织同样可以进行中间人形式的攻击。但HTTPS仍是现行架构下最安全的解决方案，主要有以下几个好处： （1）使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器； （2）HTTPS协议是由ssl+HTTP协议构建的可进行加密传输，身份认证的网络协议，要比HTTP协议安全，可防止数据在传输过程中不被窃取，改变，保证数据的完整性。 （3）HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。 HTTPS的坏处 虽然说HTTPS有很大的优势，担起相对来说，还是有些不足之处，具体来说，有以下2点： 1。seo方面 据ACM CoNEXT数据显示，使用HTTPS协议会使页面的加载时间延长近50%，增加10%到20%的耗电，此外，HTTPS还会影响缓存，增加数据开销和功耗，甚至已有安全措施也会收到影响。 而HTTPS协议的加密范围也比较有限，在黑客攻击，拒绝服务攻击，服务器劫持等方面几乎起不到什么作用。 最关键的是，ssl证书的信用链体系并不安全，特别是在某些国家可以控制ca根证书的情况下，中间人攻击一样可行。 2。经济方面 （1）ssl证书需要收费，功能越强大的证书费用越高，个人网站，小网站没有必要，一般也不会用。 （2）ssl证书通常需要绑定ip，不能再在同一个ip上绑定多个域名，ipv4资源不可能支撑这个消耗（ssl扩展可以部分解决这个问题，但是比较麻烦，而且要求浏览器，操作系统支持，Windows XP就不支持这个扩展，考虑到xp的装机量，这个特性几乎没有）。 （3）HTTPS连接缓存不如HTTP高效，大流量网站如非必要也不会采用，流量成本太高。 （4）HTTPS连接服务器端资源占用高很多，支持访客稍多的网站需要投入更大的成本，如果全部采用HTTPS，基于大部分计算资源闲置的假设的vps的平均成本会上去。 （5）HTTPS 协议握手阶段比较费事，对网站的响应速度有负面影响，如非必要，没有理由牺牲用户体验。 现在HTTPS已经趋于成熟，很多缺点是可以优化和弥补的。比如：打开速度问题完全可以通过cdn加速解决，很多IDC（互联网内容提供商）也在着手推出免费证书和一站式HTTPS搭建服务，不久HTTPS成本将会大大缩小！ |
|
可以，但是问题在于老设备无法取代。 对于程序员来说，写一个新的协议、建一个新的系统都不是难事，最难的是版本控制，要让新的协议兼容老的协议，这真的是一件很难很恶心的事。 尤其是http本身就有http1.1，http2，http3，而http3甚至无法取代前两个，一方面和底层原理相关，但更多的是设备更新。 就像ipv6其实完全可以取代ipv4，但设备更新是最难的问题。 |
|
2024 年公网上不该有 HTTP 存在了。 （根据 zero trust 的理论在内网也不该有） |
|
。。。 现在为了所谓的安全，https免费证书3个月就需要请求一次了。 啥钱都要赚。 |
|
不能。 1、内网环境，不需要。 2、很多单向提供资讯的网站不需要，比如一个企业官网（就是展示一下企业介绍和产品介绍），要什么HTTPS。打开快，设计美观就好。 |
|
HTTPS 是基于 HTTP 的，在技术层面没有什么取代之说。后者的进化必然联动前者。如果完全取代就是不允许另一方使用的话，在应用场景中可以存在。 如果是这样的话，公网环境是可以的。而且不排除未来有可能完全取代 HTTP。 Google 的一些新域名例如 .app .dev 出生自带"防护"，它们必须工作在 HTTPS 连接中。浏览器访问这些域名就不会尝试 HTTP 协议，即使你有开放 HTTP 浏览器也禁止你访问。 例如你访问我的博客。你无论如何都访问不了 HTTP 的版本，因为浏览器不允许。所以我用 .dev 域名时连 HSTS 都是懒得配的。当然这个限制在其它的 HTTP 客户端库上不一定存在。 在互联网领域浏览器是举足轻重的，未来强制你公网走 HTTPS 是有可能的。至于内网就大可不必用了，不至于说你访问路由器还要配个 HTTPS。只会徒增麻烦。 送礼物 还没有人送礼物，鼓励一下作者吧 |
|
Https协议基于http啊，你怎么取代？ https是在tcp和http之间加了一层安全层！ |
|
极端情况下，当你的设备有TCP库但是应用层没有的时候，http你甚至如果水平够你甚至能用汇编搓出来，但https找个轻量级的可移植的库都很难... |
|
可以是可以，但是有些场合下没必要，也麻烦，比如单机环境下或者内网环境下，部署数字证书系统和域名系统需要的时间精力往往会超过真正的业务。 |
|
基于商业证书作为信任的证书也是垃圾 送礼物 还没有人送礼物，鼓励一下作者吧 |
|
|
| [收藏本文] 【下载本文】 |
| 科技知识 最新文章 |
| 百度为什么越来越垃圾了? |
| 百度为什么越来越垃圾了? |
| 为什么程序员总是发现不了自己的Bug? |
| 出现在抖音评论区里边的算命真不真？ |
| 你认为 C++ 最不应该存在的特性是什么？ |
| 为什么 Windows 的兼容性这么强大，到底用了 |
| 如何看待Nvidia禁止使用翻译工具将cuda运行 |
| 为何苹果搞了十年的汽车还是难产，小米很快 |
| 该不该和AI说谢谢? |
| 为什么突破性的技术总是最先发生在西方？ |
| 上一篇文章 下一篇文章 查看所有文章 |
|
|
|
| 股票涨跌实时统计 涨停板选股 分时图选股 跌停板选股 K线图选股 成交量选股 均线选股 趋势线选股 筹码理论 波浪理论 缠论 MACD指标 KDJ指标 BOLL指标 RSI指标 炒股基础知识 炒股故事 |
| 网站联系: qq:121756557 email:121756557@qq.com 天天财汇 |