V2EX › qgy18 的所有回复 › 第 32 页 / 共 54 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 28 29 30 31 32 33 34 35 36 37 ... 54

❮

❯

2016-02-17 11:10:45 +08:00

回复了 VmuTargh 创建的主题 › 健康 › 过敏检测结果出来了，真的感觉药丸

@yeqiu
晚上排毒，这个科学松鼠会之前专门反驳过啊。
http://songshuhui.net/archives/62528

2016-02-17 09:29:48 +08:00

回复了 est 创建的主题 › 分享发现 › http/2 的缩写是 h2 。。。。。

从最开始就是这样的。在草案阶段 TLS 里的 NPN / ALPN 扩展中就用类似 h2-14 的字符表示这是 HTTP/2 协议的第 14 版草案；转正之后就直接用 h2 了。

广告下我之前写的 HTTP/2 资料汇总：
https://imququ.com/post/http2-resource.html

2016-02-12 21:11:00 +08:00

回复了 neilp 创建的主题 › 分享创造 › [更新] le 支持 letsencrypt 的最新 ECC 证书啦

没记错的话， 521 已经被 Chrome 废弃了。
http://security.stackexchange.com/questions/100991/why-is-secp521r1-no-longer-supported-in-chrome-others

2016-02-11 23:44:54 +08:00

回复了 qgy18 创建的主题 › 分享发现 › Let's Encrypt can now sign ECDSA keys!

@vibbow
@Daniel65536

根证书 ECC 估计比较难，根证书要进入各大操作系统 / 浏览器没个几年肯定不行，它现在是跟 DST 交叉认证。但中间证书确实应该用 ECC ，这样 TLS 握手中 Server 发送的 Certificate 就更小了，现在大概只小了 500 字节。

兼容性方面，除了 Android 2 和 Windows XP （ firefox 除外），基本都支持 ECC 证书，感觉还好。反正 Let's Encrypt 家的中间证书之前也不被 XP 信任。

http://i.imgur.com/jphYLst.png

2016-02-11 23:07:19 +08:00

回复了 qgy18 创建的主题 › 分享发现 › Let's Encrypt can now sign ECDSA keys!

我的博客已经用上了：

http://i.imgur.com/XJy9Qeb.png

https://imququ.com

2016-02-06 20:42:04 +08:00

回复了 KyL 创建的主题 › HTTP › 如果浏览器发送的 HTTP Request 中使用了 Keep-alive，服务器如何得知这个 Request 已经读取完成？

@KyL 应该也是可以的，但是浏览器发送的数据一开始很容易得到 Content-Length ，没必要 chunked 啊。

2016-02-06 19:37:01 +08:00

回复了 KyL 创建的主题 › HTTP › 如果浏览器发送的 HTTP Request 中使用了 Keep-alive，服务器如何得知这个 Request 已经读取完成？

不得不安利一下我的这篇文章：
https://imququ.com/post/transfer-encoding-header-in-http.html

2016-02-04 13:18:36 +08:00

回复了 rori 创建的主题 › 问与答 › 不同厂商 SSl 之间速度有差异？

HTTPS 网站确实更慢，因为多了 TLS 层。
HTTPS 网站优化一般分为两部分，围绕 TLS 和围绕应用层协议，如 HTTP/2 。
https://imququ.com/post/optimize-tls-handshake.html

2016-02-03 09:49:46 +08:00

回复了 Orzzzz 创建的主题 › 分享创造 › 做了一个内涵图的站，一共 3650 张，写代码累了可以去开心一下哦～

看了大概 20 页，发现不少重复的。

2016-02-02 22:48:09 +08:00

回复了 terence4444 创建的主题 › 分享发现 › 看了那么久，你们有没有觉得“敬业福”是新型猴戏？🐒

其实还有一种可能：最终宣称有 4 亿用户集齐一套，实际上只给出 2 亿套。这样运营成本就从 2 亿变成变成 1 亿了。
互联网公司耍起这种手段来还是很得心应手的。

2016-02-02 13:02:47 +08:00

回复了 wujunze 创建的主题 › 宽带症候群 › 网站搬新家求测速!

挺快的，我也是阿里云 https://imququ.com

2016-01-31 01:44:06 +08:00

回复了 xiaodaigou 创建的主题 › 前端开发 › @qgy18 贵站怎么做的优化啊，速度快到哭

@chemzqm
1 、对！ localStorage 丢失但 cookie 健在时，确实要刷两次。极端情况下还会无限刷新，前面拿百度家的页面玩了下。但是正常情况下 localStorage 基本都是跟 cookie 一起被清除，实际统计结果也确实如此；
2 、移动端确实很多奇葩情况，很多 Android APP 内置 Webview 甚至都不会开启 localStorage 功能，没有 setDomStorageEnabled(true)。我们现在的缓存率大概在 70% 左右，收益还是不错的；
3 、其实真不是为了省流量，如果要省流量用外链就好了，后续访问有协商缓存 / 强缓存也不费流量。内联 + localStorage 主要还是为了省连接数，顺带节省流量。移动网络现在带宽上来了，但是时延还是很大，多一个新的外链光 DNS / TCP 就得好几百毫秒；

另外，目前在移动端 HTTP/2 的研究中我遇到以下问题：
1 、支持度不高。不过这不是什么大问题，移动端更新换代很快；
2 、浏览器中， HTTP/2 必须基于 HTTPS 部署，而移动端 HTTPS 的连通性更差。前不久做的实验，在一个 HTTP 页面加载同域 HTTPS 图片，对比加载 HTTP 图片，不可用率高了 3%；
3 、 HTTP/2 的单一连接数多路复用，要求同域，或者不同域但同 IP 、同证书。这一点实际部署起来很麻烦，尤其是在有 CDN 的情况下；

2016-01-30 16:59:40 +08:00

回复了 milklee 创建的主题 › 分享发现 › 被 Chrome 网上应用店坑了一把

精简？你说的是 uglifyjs 一类的代码压缩么？ Google 这么做应该是被市场里那些各种加返利链接的扩展所迫，加强代码 Review 了。
我之前还写过文章吐槽过 Chrome ：
https://imququ.com/post/chrome-extensions-and-user-privacy.html

2016-01-30 12:42:13 +08:00

回复了 xiaodaigou 创建的主题 › 前端开发 › @qgy18 贵站怎么做的优化啊，速度快到哭

@qgy18 貌似图片地址多打了一个 v ，更新下：

http://i.imgur.com/hXJmvAH.gif

2016-01-30 12:41:08 +08:00

回复了 xiaodaigou 创建的主题 › 前端开发 › @qgy18 贵站怎么做的优化啊，速度快到哭

@Troevil 另外，如果这个 cookie 标记被无意设置为 HTTP Only ，那么 JS 就清不掉它了。然后刷新后服务端还是会认为本地有 localStorage 缓存，就会无限刷新。这个问题正常使用中肯定不会出现，但是我们评估 localStorage 方案时考虑过。

我刚录了一个 gif 演示如何玩坏百度的 localStorage 方案（纯属无聊，这种问题各家都不会处理）：

http://i.imgur.com/hXJmvAH.gifv

2016-01-30 12:32:43 +08:00

回复了 xiaodaigou 创建的主题 › 前端开发 › @qgy18 贵站怎么做的优化啊，速度快到哭

@Troevil 非常正确！
如果 cookie 标记被清了，服务端无法知道本地 localStorage 里还有缓存，就会输出全量。

但是！如果 cookie 标记还在，但是 localStorage 被清除了，服务端就不知道该输出全量了，只能依靠 JS ，在读不到本地 localStorage 时清掉本地 cookie 标记再刷新。

针对这个问题我们之前做过一些策略，例如发现出现这种情况，就额外存一个 Cookie 标记，针对有这个标记的用户一段时间内只输出全量。后面做了一个统计，发现几乎没有这种情况发生。

2016-01-30 11:40:51 +08:00

回复了 xiaodaigou 创建的主题 › 前端开发 › @qgy18 贵站怎么做的优化啊，速度快到哭

@Troevil 不需要，第一次服务端输出：
<style id="all_css">...</style><script>L.h2l("all_css","all_css")</script>

第二次服务端输出：
<script>L.l2h("all_css:2")</script>

也就是第一次就是正常的资源内联，顺带存到 localStorage 里；第二次才是走本地读取。

2016-01-30 11:05:06 +08:00

回复了 xiaodaigou 创建的主题 › 前端开发 › @qgy18 贵站怎么做的优化啊，速度快到哭

@chemzqm
1 、为什么首次访问用户需要重新加载两次页面？这个难以想象，如果有这种严重问题，这个方案如何能发布上线。

2 、这个方案我们业务中只针对移动端使用。你也可以看到百度 / 神马移动搜索都采用了这个方案。这是移动端头部外链对性能影响特别大，会显著增加白屏时间。所以一般在移动端，宁可将资源完全内联来牺牲缓存，也不会在头部引入外链。 HTTP/2 的调研一直在做，但是在移动端普及还不理想，尤其是在 Android 端，只有 Chrome 47 才支持，随着时间的推移，优化手段也会随之改进的。对了， HTTP/2 的 Server Push 就是用来解决资源内联的问题，但 Server Push 也不是没有弊端，具体可以看我这几篇文章：
https://imququ.com/post/http2-and-wpo-1.html
https://imququ.com/post/server-push-in-http2.html
https://imququ.com/post/cache-aware-server-push-in-h2o.html
https://imququ.com/post/golomb-coded-sets.html

3 、前面说过，我们业务中实际的方案，如果 A 页面在 localStorage 中存放了 1 、 2 两个资源； B 页面需要 1 、 2 、 3 三个资源时，服务端只会输出 3 这个资源的全量内联。因为我们有高度压缩的 cookie 来存放资源标识及对应版本信息。

4 、确实，从字符串 eval / new Function 执行的代码不好调试。但我们有参数，禁用所有 localStorage 策略，这时候页面资源就跟普通内联没区别了。

5 、我们业务中有 noscript 标签，如果禁用 cookie ，会跳转到极速版——极速版不需要任何 JS 就可以工作得很好——因为我们正常版禁用了 JS ，就算 css 能加载也基本无法使用，交互太多了。

我的博客是我的试验田，我用在我博客中的策略并不一定适合用在业务中——这个我之前多次强调过。

而在业务中是否启用某个策略，需要更完善的考虑、数据支持以及配套设施。例如我们业务代码中所有资源都是外链形式书写，如果要编译为内联，加一个自定义属性即可；如果要内联 + localStorage ，就换成另外的自定义属性；如果什么都不加，那最后就会自动压缩合并 + 发布到 CDN 。

1 ... 28 29 30 31 32 33 34 35 36 37 ... 54

❮

❯