这是一个创建于 2991 天前的主题，其中的信息可能已经有所发展或是发生改变。
刚刚测试下 https 下载和 Http 下载速度对比。同站点单线程下载速度 https 只有 http 的 30%左右，看来 https 有些情况下还是不要应用
 | 1 cxbig 2017-08-03 05:54:27 +08:00 用不用还不是看你业务。。。有安全需要的肯定要换更贵的服务器。 |
 | 2 whileFalse 2017-08-03 06:40:01 +08:00 via iPhone 确定是 https 的锅？ https 对连接速度有一定影响，但下载较大文件时一般瓶颈不在 https。 你用来测试的文件多大？ |
 | 3 Actrace 2017-08-03 07:16:10 +08:00 没错，现在很多人都是无脑上 https。 实际上 http 和 https 最好是理智对待，大部分静态资源都推荐用 http 来部署，从 http 协议上来说，相对比较简单轻量，并且可以被 isp 缓存，免费的 cdn。 除非一些要求安全性的内容或者资源，再启用 https 通道来传输。 |
 | 4 Mutoo 2017-08-03 07:28:38 +08:00 ftp http sftp https 哪个快？ |
 | 5 Afanyiyu 2017-08-03 07:34:39 +08:00 via Android @Actrace 同意。现在有些人宣扬任何时候都 https，其实还是要理智选择。相信一般不会所有资源都需要 https 的，还是要根据实际情况来。 |
 |  1 安全成为刚需的时候，10%我也会用 安全是为了装逼的时候，90%我也不用 |
 | 8 cloveric 2017-08-03 08:00:19 +08:00 via Android 1 看用途了啊。。 |
 | 9 choury 2017-08-03 08:01:16 +08:00 via Android 启用 http2 了没有 |
 | 10 Devmingwang 2017-08-03 08:35:02 +08:00 加 1，如果不启用 http2 的话 https 当然慢，慢的要死。 我也赞成上面其他人说的话，视频，图片类静态资源使用 http 还是这样比较好的，如果是下载程序之类的，或者是网页的话那就的确有必要上 https 了。 |
| 11 Devmingwang 2017-08-03 08:35:45 +08:00 要是网站用上 https 的话，访问会更容易，万一哪天网站被墙还可以借助 sniproxy 来访问。 |
 | 12 sagaxu 2017-08-03 09:00:26 +08:00 via Android 4 http 被 ISP 注入太严重了，加个广告或者推广下载个 APP 太常见了 |
 | 13 yidinghe 2017-08-03 09:02:56 +08:00 via Android 提供文件校验码，或者文件自带校验，这样可以防范篡改。 |
 | 15 aksoft 2017-08-03 09:04:40 +08:00 http2 的话 不慢，cdn 之类的 有支持 https 了。安全的话没啥用，就为了左边的“安全”两个字。google 有加分项。 |
 | 17 momocraft 2017-08-03 09:10:42 +08:00 测过 https 慢在哪里吗？ |
 | 18 janxin 2017-08-03 09:13:40 +08:00 看场景吧，下载没有单独测试过，可能其实还好。 但是网页 HTTP2 其实不错的，这图是我们 HTTP 和 HTTPS/2 的对比，当然可能也和我们 HTTP 访问没做优化有关...  |
 | 19 txydhr 2017-08-03 09:28:30 +08:00 via iPad 1 https 可以防止运营商强奸 Google 当年上 https 的目的，防止 isp 篡改内容还是最主要的目的，另外还可以防止运营商搜集用户搜索数据 |
 | 20 bkmi 2017-08-03 09:28:54 +08:00 via Android 1 楼上几位理智论的同学可能不太清楚 isp 劫持,连 apk 都给你替换掉，还指望什么安全，另外混用时浏览器都给你标了不安全 |
 | 21 love4taylor PRO |
 | 22 honeycomb 2017-08-03 09:34:49 +08:00 via Android |
 | 23 imnpc 2017-08-03 09:41:00 +08:00 HTTP2 + HTTPS 解决问题... |
| 24 janxin 2017-08-03 09:47:04 +08:00 wget 试了一下下载阿里云 MongoDB 镜像，文件大小 30M，速度没有 LZ 说的这么夸张啊？ $ wget https://mirrors.aliyun.com/mongodb/apt/ubuntu/dists/xenial/mongodb-org/3.2/multiverse/binary-amd64/mongodb-org-tools_3.2.16_amd64.deb --2017-08-03 09:44:16-- https://mirrors.aliyun.com/mongodb/apt/ubuntu/dists/xenial/mongodb-org/3.2/multiverse/binary-amd64/mongodb-org-tools_3.2.16_amd64.deb Resolving mirrors.aliyun.com... 115.28.122.210, 112.124.140.210 Connecting to mirrors.aliyun.com|115.28.122.210|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 31757838 (30M) [application/octet-stream] Saving to: ‘ mongodb-org-tools_3.2.16_amd64.deb ’ mongodb-org-tools_3.2.16_amd64. 100%[======================================================>] 30.29M 1.00MB/s in 33s 2017-08-03 09:44:49 (940 KB/s) - ‘ mongodb-org-tools_3.2.16_amd64.deb ’ saved [31757838/31757838] $ wget http://mirrors.aliyun.com/mongodb/apt/ubuntu/dists/xenial/mongodb-org/3.2/multiverse/binary-amd64/mongodb-org-tools_3.2.16_amd64.deb --2017-08-03 09:45:10-- http://mirrors.aliyun.com/mongodb/apt/ubuntu/dists/xenial/mongodb-org/3.2/multiverse/binary-amd64/mongodb-org-tools_3.2.16_amd64.deb Resolving mirrors.aliyun.com... 115.28.122.210, 112.124.140.210 Connecting to mirrors.aliyun.com|115.28.122.210|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 31757838 (30M) [application/octet-stream] Saving to: ‘ mongodb-org-tools_3.2.16_amd64.deb.1 ’ mongodb-org-tools_3.2.16_amd64. 100%[======================================================>] 30.29M 863KB/s in 34s |
 | 25 zpf124 2017-08-03 09:48:11 +08:00 @honeycomb 你太小看各大运营是的本事了， 人知道你完整 url 干啥，粗暴一点的直接根据 url 最后一节的 xxx.apk 文件名匹配拦截， 当然 如果你的下载链接是 download/123456，然后后端程序去读取对应资源，那估计只要你不是做的特别大确实是没事。 |
| 26 imnpc 2017-08-03 09:49:47 +08:00 刚测试了 100M 文件 http https+http2 下载速度无差别 |
 | 27 Showfom PRO 楼主你自己没优化好吧 https 也就是 tls 握手的时候稍微消耗点资源 怎么可能只有 30% 基本上肉眼都可以忽略 还有一种情况就是你本地 isp 对 443 端口限速了 嘿嘿 |
 | 28 mengskysama 2017-08-03 09:51:54 +08:00 via iPhone 带不带 s 下载过程应该是没差的，带宽跑不满应该是其他原因 |
 | 29 linus3389 2017-08-03 09:53:49 +08:00 存一些杂七杂八的静态资源完全没必要上 HTTPS 程序员都是理性生物，可控范围都会为了性能做到极致的 最大的可能就是某天你 BOSS 过来找你“为什么别人家网站是绿的，我们就不行？快，给我整上!” |
 | 30 isCyan 2017-08-03 09:54:56 +08:00 via Android 30% 不可能的事 |
| 31 zpf124 2017-08-03 09:55:47 +08:00 正常情况下，https 比 http 唯一更消耗资源和时间的地方就是在建立连接交换秘钥的时候， 而下载文件一般都是稳定的不断开的长连接啊，在这种情况下按道理 tsl 消耗的时间在整个下载过程占得比例应该非常低啊。 所以 是电脑太垃圾了，处理数据解密的能力太差？ 还是 cdn 缓存了，但 cdn 只支持 http 缓存导致？ 再或者下载软件支持 p2p，https 的时候 p2p 支持不太好？ |
 | 32 usedname 2017-08-03 10:14:08 +08:00 via Android 免费的 CDN,嗯，附带免费的网络劫持 |
 | 34 121121121 2017-08-03 10:22:24 +08:00 http 下载快应该就是运营商的劫持缓存了吧 |
 | 35 Sendya 2017-08-03 10:50:17 +08:00 我见过我下载 LOL Client，12MB/s 从阿里云服务器上下载一个随机生成的 100Mb.bin 文件 500Kb/s 没错（使用 https，阿里云开的按量计费 100M 带宽），它就是长宽。 鉴于楼主的情况，https 真吉儿慢 |
 | 36 TestSmirk 2017-08-03 11:19:54 +08:00 via Android 证书验证完了就没啥事了吧。。 |
 | 37 xierch 2017-08-03 12:29:05 +08:00 via Android 2 绝大部分资源都有 HTTPS 的必要…… 就算只是做下载，内容被掉包、掺私货加广告也很蛋疼。 此外还有一些隐私方面的好处… 少数应用另有措施检查所下内容的签名、hash，倒是可以考虑只用 HTTP ……比如各 Linux 发行版的软件源，全是公开内容、带签名认证，就经常这样做。但就算这种场景，现在也都开始陆续上 HTTPS 了，因为可能受到重放攻击（ https://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.pdf ）。 总之我觉得「无脑上 HTTPS 」挺好的…… |
 | 38 tomczhen 2017-08-03 12:39:23 +08:00 via Android 说不用全局 HTTPS 的显然是不了解劫持能做到什么地步。 |
 | 39 flyingghost 2017-08-03 12:45:50 +08:00 7 1，下载做 https 就是为了防劫持防篡改。 你下.apk 我就给你篡改包。 你不用.apk 做 url 我也可以看 mimetype。 你连 mimetype 都换掉我也可以缓存 content 部分做旁路分析，下一个请求遇到同 url 我就可以调包了。 apk、js 劫持已经是常见思路了。图片也可以帮你打水印啊。 2，https 成本在建立连接，以及加密上。建立连接成本确实高，但针对一个连接来说，尤其在下载场合，这点增加微乎其微。加密是对称加密，对现代 cpu 都不是事。 3，CDN 照样可以 https。现在 CDN 连证书都不跟你要，他们送。 4，下载后再校验这活，首先没有自动化机制得自己实现，其次还得考虑签名的成本。md5 之类散列倒是成本低，就得好好设计防止把 payload 和散列一起篡改了。 5，实用角度来讲，http 的生存空间越来越尴尬了。混合内容浏览器会警告，iOS 直接不予支持。 无脑 https，省心省力，好处多多。自从上了 https，我们网站和 API 接口的安全措施都可以不那么费神了。 |
 | 40 Quaintjade 2017-08-03 12:51:49 +08:00 @Mutoo sftp 应该最慢，因为那是 ssh ftp。要比也应该是 ftps (ftp over ssl/tls) |
 | 41 billwang 2017-08-03 13:00:02 +08:00 https 在某些情况下还是非常有必要的，我们这边电信就在 618 的时候劫持了京东和淘宝，不带 https 的分分钟给你加推广尾巴。现在登录阿里妈妈获取推广链接无法获取，必须用 https 方式才可以。 |
 | 42 mineqiqi 2017-08-03 14:22:31 +08:00 https 下载慢？ lol |
 | 43 BOYPT 2017-08-03 14:31:00 +08:00 楼主应该是被 qos 了，这锅 https 不背 |
 | 44 Aquila 2017-08-03 14:38:30 +08:00 via Android 防止运营商强奸，防止被 wall 盯上，打死我我也不敢把 https 关掉 |
 | 45 Balthild 2017-08-03 14:45:38 +08:00 via Android 运营商牛逼到什么程度？牛逼到我用 Web IDE 编辑 js 文件，结果一打开发现是运营商劫持代码。 不上 HTTP 根本没法活。 |
 | 46 jiabing520a 2017-08-03 14:48:07 +08:00 1 @t123yh <meta http-equiv="Content-Security-Policy" cOntent="upgrade-insecure-requests"> 可以的，在相应的页面的 <head> 里加上这句代码 |
 | 47 SmashPHP 2017-08-03 14:51:11 +08:00 运营商免费 CDN ？真是 Naive，等被 ISP 劫持的时候，你就知道怎么哭了 再说，既然 HTTP 真有某些人吹的这么好，那为什么百度淘宝天猫京东纷纷上了全站 HTTPS ？莫非贵司自认为自己的技术团队比百度阿里巴巴京东腾讯还要强？真是自不量力 |
 | 48 sgissb1 2017-08-03 15:09:44 +08:00 不要认为 https 就真的可以防劫持，只是大家不一定会去碰 https 的连接。因为网银等一些关键业务就是在用 https。 有一种静态破解 ssl 的方式叫做报文回放，也有一种你永远绕不过去的槛，那就是重定向到某个你自己都不知道哪来的 https proxy。 |
 | 49 rswl 2017-08-03 15:11:29 +08:00 不至于差这么多吧 |
 | 50 raysonx 2017-08-03 15:23:25 +08:00 via Android 1 看了一下楼上的很多人，显然被运营商插入得还不够厉害 |
| 51 honeycomb 2017-08-03 15:53:22 +08:00 1 @zpf124 "你太小看各大运营是的本事了， 人知道你完整 url 干啥，粗暴一点的直接根据 url 最后一节的 xxx.apk 文件名匹配拦截， " 请说明一下，在启用 HTTPS 时，运营商(本事确实很大)如何知道完整 URL。 |
| 53 honeycomb 2017-08-03 16:03:09 +08:00 |
 | 54 2643595423 2017-08-03 16:06:06 +08:00 运营商可以问你要网费 滑稽 |
 | 55 QAPTEAWH 2017-08-03 16:07:26 +08:00 @flyingghost 散列肯定是 https 单独获取啊 |
 | 56 mengzhuo 2017-08-03 16:15:51 +08:00 说 http 好的,是没被 ISP 强奸过. 插东西算好的了^ 见过把状态码都改掉的么? 我们还真碰到了. lz4 压缩的东西,硬生生改成了 gzip, 然后客户端就跪了. 最后权衡再三,连资源包都改成了 https |
| 57 SmashPHP 2017-08-03 16:37:31 +08:00 @lslqtz 运营商对你的明文流量有无限制的分析、修改和重定向能力 @QAPTEAWH 客户端下载发现 hash 不符合重新下载被运营商投毒发现 hash 不符合重新下载被运营商投毒被运营商投毒... 无限循环。有这个重新下载的时间 https 早传输完了。而且，你都部花了精力去部署 hash 的 https，为什么不顺便上全站 https，真是为了反对而反对 @sgissb1 你是来搞笑的吧，还报文回放，麻烦你来给我重放一个看看。https 每个 socket 连接都会验证证书，交换密钥。攻击者截获请求，重新发送，因为 socket 不同，密钥也不同，后台解密后是一堆乱码，所以 https 本身就是防止重放攻击的。然后重定向搞 SNI Proxy 有什么用吗？ V2EX 上又不是没有用 SNI Proxy 反代 Google 的教程，你来给我解密一个看看 成天只想着搞大新闻，我看你还是要学习一个，Naive ！ |
 | 59 LeoEatle 2017-08-03 17:12:10 +08:00 via iPhone HTTPS 明明也适合静态资源啊！多路复用不需要再握手就能传送大量图片 |
| 60 zpf124 2017-08-03 17:12:51 +08:00 1 @honeycomb 可能是你我理解你最初回复的那位内容时出了歧义， 我理解为 他说的 内容是反驳“理智使用 https ”这种论调的人， 所以他内容里指的就是 http 情况下 isp 劫持非常泛滥。 然后以为你说的内容也是指在 http 协议下的情况。 |
| 61 LeoEatle 2017-08-03 17:14:08 +08:00 via iPhone 说真的，要不是现在 ISP 技术不高超，你敢用 HTTP 我可以劫持到 P 图片再备份到另一个系统，各种监视全都能做 |
 | 63 HarrisonZ 2017-08-03 17:30:03 +08:00 都直接 http/2 了，还用 http 的不嫌慢吗 |
| 64 sgissb1 2017-08-03 17:31:18 +08:00 @SmashPHP 当然从你只会说 socket 这个字眼来看，你应该是不了解比 socket 更底层的。下次出来喷人，麻烦搞懂了再来说。^_^ |
| 65 zpf124 2017-08-03 17:32:06 +08:00 @sgissb1 哪有那么容易， 现在想要劫持 https 页还行得通的主要就是中间人， 在你首次访问域名时，先 dns 解析到中间人的网站上，然后中间人相当于正向代理你的访问 去该发 https 请求。实际 是 用户 http -> 中间人 -> https 站点。 而且现在这个问题也有了一些解决方案了，就是 [hsts preload list]( https://hstspreload.org/)， 目前正在普及，几大浏览器厂商都支持了，处理方案就是缓存一个 hsts 列表，在用户访问列表内的网站时，直接强制使用 https，中间人又不可能拥有合法的证书。 到这种地步了 中间人要再想劫持 那他就得学学 阿里 和 12306 诱导用户安装 rootCA 了。 |
 | 66 panda1001 2017-08-03 17:38:39 +08:00 via Android 没有在腾讯云备案的域名 http 访问非 80 端口也会被拦截，而 https 就没事，做个测试也拦截真是醉了 |
| 67 sgissb1 2017-08-03 17:59:53 +08:00 @zpf124 https 也不是不能劫持，确实大多数办法都是中间人的方式。不过也要看配置，如果有傻鸟配置了对称加密，或者不重新交换证书的情况下，一般长连就容易出事了。 我们以前是做边缘设备的，就有傻逼用户这样干过。最后我们部门还差点背黑锅。。。。。不过我们是仅仅针对 ssl 通讯，这个比 https 来说广泛多了。毕竟 https 本质也只是 http+ssl，上面玩在多花样也本质变不了。 所以这事吧。。。。。还真因为我曾经的工作关系。。。。。我知道一些。 不过对于连接时间比较短的连接，并且密钥更新周期相对长一点的情况，还是可以破，只是难度较大。某些特定网络下，就算连接时间短，就算是非对称定时更新密钥的情况，破还是有希望的（非中间人）。 破解 ssl 通讯的办法其实业内都知道，只不过由于协商好了私钥之后，由于定期更新了私钥，所以导致破解难度加大（这里不包含暴力破解）。只要拿到双方的解密私钥，还是有希望的。不过没有亲自试验过（没那个能耐，当时我们有个大神玩过友商的设备，还写了个工具模拟正常通讯）。 至于“数据搬运工”们来说，要拿到解密密钥还是并非难事，有了解密的私钥，一样能看到你在干啥，只不过不能插入信息而已（因为没加密密钥）。 说到底也不算安全，真安全是别人解密不开，也加密不进去。 |
 | 68 jingniao 2017-08-03 18:29:06 +08:00 via Android http 的运营商劫持啊代理之类，真的很严重，我有时候用 vps 中转下载，电信网 http 绝大多数被重定向到四川的一个机房，文件不一致也不是没遇到过。就算是 https，你服务器配置不对被降级也说不过来 |
 | 69 feather12315 2017-08-03 19:25:33 +08:00 via Android 对于现代 CPU 来说，加密解密时间可以忽略不计，但在网络传输过程中的确增加了一些开销。比如目前最常见的 AES-128-GCM，GCM 用于认证，类似于 hash 函数的机制，把那一块数据映射为定长的 hash 值，用以保证所传输的数据不被篡改 |
| 70 zpf124 2017-08-03 19:58:00 +08:00 @sgissb1 对于你们设备的 ssl 不太懂，你们设备应该没有证书合法性的校验吧。 https 的证书 需要 rootCA 颁发的，rootCA 相当于 顶级的担保人，都是内置到各个操作系统中的，这部分 rootCA 对那些证书颁发机构担保，再由证书颁发去给对下面的域名证书做担保。 每次浏览器用 https 时都会根据网站发过来的证书，按照 rootCA -> ca -> 网站证书 的顺序一级一级询问下一级证书是否合法。 而且传输过程必须使用不对症加密， 网站私钥是不会让外人知道的。 |
 | 72 lyhiving 2017-08-03 22:48:22 +08:00 via Android 如果是支付或者下载 apk 这种，必须 HTTPS。 |
 | 73 FrankFang128 2017-08-03 23:23:54 +08:00 你这么在意速度，就不应该用 HTTPS。 等你在意安全&防篡改的时候再考虑 HTTPS。 |
 | 75 wwqgtxx 2017-08-04 10:09:07 +08:00 @sgissb1 单纯的 SSL 通讯是很容易被中间人的，所以 SSH 才会在发现连接的服务器 SSL 证书指纹不一样的时候让你确认是不是合法的服务器，只不过大部分人都无脑的点 YES 而已。而 HTTPS 的安全性在 SSL 的基础上增加了基于证书链的机制，使得除非你能控制证书颁发机制，否则没有那么容易中间人 而对于传输过程中的秘钥破解问题，你是觉得 AES 的加密真的就那么不堪一击么，要是 AES-256 能那么容易破解，那 HTTPS 还有什么推进的必要 真正在 HTTPS 通讯中只有在交换对称加密秘钥的时候才是用非对称的方式加密，后面还是用协商好的秘钥进行对称加密的，一般都是 AES 家族或者是 CHACHA20 系列，你该不会以为真正的通讯过程中一直在用他们最初交换的非对称秘钥进行数据加密解密吧 |
 | 76 tangren OP @whileFalse 100M 1T 10T 都试过 |
| 78 momocraft 2017-08-04 10:17:06 +08:00 @tangren 这些都发生在 ssl 通道建立之前而且流量不大时间不长，在长时间连接时对平均速度的影响应该有限。所以我说问的是 "测过" |
 | 79 lslqtz 2017-08-04 15:16:37 +08:00 |
| 80 honeycomb 2017-08-04 15:24:07 +08:00 via Android @lslqtz 这种事情（防火墙内置 ca 的情况）据说在一些企业内有出现，当然也可能是企业的私有 ca/自签名证书的形式 |
 | 81 Williamp 2017-08-09 16:50:14 +08:00 @tangren You should enable http/2 for getting faster connection for https. There are lots of benefits comes with http/2. You should also refer this thread http/2https://www.v2ex.com/t/334548#r_4000479 to know more about http/2 benefits. |
| 82 Williamp 2017-08-09 16:51:19 +08:00 You should enable http / 2 for getting faster connection for https. There are lots of benefits comes with http / 2. You should also refer this thread t/334548#r_4000479 to Know more about http / 2 benefits. |
Select Language