[翻译]Dropbox Web 服务启用 HTTP/2:经验和观察

Haowei Yuan | 2016年5月11日 最近,为了启用 HTTP/2,我们 Dropbox 的流量团队升级了前端的 Nginx 服务器。本文将分享我们迁移到 HTTP/2 的过程中的体验和新发现。整个过程较为顺利,但还是有发现一些坑,也许对大家有帮助。

背景:HTTP/2 与 Dropbox Web 服务架构

HTTP/2 (RFC 7540) 是 HTTP 协议的新的大版本。它基于 SPDY 协议,而且相比于 HTTP/1.1 提供了好多性能优化。这些优化包括:更高效的报头压缩、Server Push、多路复用等等。至今,过半浏览器已经支持HTTP/2。 Dropbox 使用开源的 Nginx 做 SSL 终结前端和为流量提供七层负载均衡。升级前,我们的前端服务器跑的是基于 Nginx 1.7 的软件,并且支持 SPDY。另一个升级的动力来自,虽然 Chrome 目前既支持 SPDY 也支持 HTTP/2 ,但他们很快会在5月15日 放弃SPDY支持。如果那时不支持 HTTP/2 ,我们的 Chrome 用户就会从 SPDY 降级到使用 HTTP/1.1。

HTTP/2 升级步骤

升级 HTTP/2 对我们来说是个直截、而且平滑的切换。Nginx 1.9.5 增加了 HTTP/2 模块(也由 Dropbox 共同协助),并默认弃用了 SPDY 支持。我们当时就决定升级到 Nginx 1.9.15,即那时的最新稳定版。 用 Nginx 升级 HTTP/2 只需对配置文件做小小的改动。只需将 http2 关键字增加到 listen 指令后面。因为我们之前启用了 SPDY,所以只需将 spdy 替换成 http2

升级前 (SPDY): listen A.B.C.D:443 ssl spdy;

升级后 (HTTP/2): listen A.B.C.D:443 ssl http2**;**

当然,您或许会需要浏览完整的 Nginx HTTP/2 配置选项,好针对某些特定的场景做优化。 部署方面,我们首先在小流量机器上启用 HTTP/2 了一个星期,同时线上依然使用 SPDY。在确定了正确性,并且评估了性能之后,HTTP/2 才全量启用。 http2 transition 从 SPDY 到 HTTP/2 的平滑切换 (60 分钟的流量数据) 上图展示了从 SPDY 到 HTTP/2 的平滑切换。余留的 HTTP/1.1 连接在图中没有显示。我们分别在大约第 23 、第36 和第 50 分钟,逐步将所有前端 Web 服务器启用了 HTTP/2。在此之前,在线连接既有小流量机器的 HTTP/2 流量,也有线上机器的 SPDY 流量。如您所见,基本上所有 SPDY 连接着的客户端最终都转移到了 HTTP/2 上。

观测

在小流量机器上启用了 HTTP/2 后,我们紧密地监测着性能。观察得到的既有代表 HTTP/2 的高效性能的数据,也有一些由于 HTTP/2 的实现还较新而产生的坑。

性能提升

我们观测到流入带宽开销显著降低,这是由更高效的报头(Header)压缩(HPACK)带来的。 traffic bandwidth 降低的流入带宽开销 (24 个小时的流量数据) 上图展示了HTTP/2 只在小流量机器上启用时,小流量和线上机器平均(每台机器)的带宽开销。每一台小流量机器和线上机器都从负载均衡服务器上拿到了几乎一样大的流量。可以看到,启用 HTTP/2 以后,入网带宽流量降低很显著(差不多50%)。值得一提的是,虽然我们之前在所有小流量和线上机器启用了 SPDY,但并没有开启 SPDY 的报头压缩,因为有一个相关联的安全问题 (CVE-2012-4929 也就是 CRIME)存在。至于出网流量,则并没有显著的改变,因为报头在响应流量中通常只占很小一部分。

一些坑

更新: POST 请求延迟增加和 REFUSED_STREAM 错误h的问题在最近的 Nginx 1.11.0 版本 已经得到了修正。 变更后新的 P50 请求延迟的数据图在文末附上。 POST请求延迟提高了。当我们在小流量机器上启用 HTTP/2 时,发现延迟中位数上升了。下图展示了小流量和线上机器之间的 P50 请求延迟(P50 request latency,即 50% 的请求延迟比这个时间短,下同)。经过调查这个问题,我们发现,延迟是由 POST 请求产生的。更深入研究之后,这个行为看起来是归咎于 Nginx 1.9.15 的某些实现而产生的。相关的讨论可以在 Nginx 邮件列表 中找到。 request latency P50 响应延迟提高 (24 个小时的流量数据) 注意在此看到的 P50 请求延迟提高的百分比(大约变成 1.5 倍)取决于特定的流量负荷。在大部分情况下,增加的负担对我们来说大约是一个 RTT(round trip time,往返延时) 那么多,并没有太影响我们的关键性能。然而,如果您的流量负荷包含许多小的、对延迟敏感的 POST 请求,那么增加的延迟时间是您考虑是否升级到 Nginx 1.9.15 的重要考虑因素。 为所有内容都启用 HTTP/2 要小心,尤其是当您不能控制客户端的时候。由于 HTTP/2 还是比较新,从我们的经验来看,一些客户端/库和服务器的实现还不是兼容得很好,例如:

  • 使用 Nginx 1.9.15,如果客户端试图在获知帧(Frame)的连接设置(SETTING)之前发送 数据(DATA)帧,POST 请求就会得到 REFUSED_STREAM 错误。我们发现 Swift SDK 存在该问题。值得一提的是,监测 Nginx 错误日志在部署过程中至关重要,而观察到这个错误信息需要把错误日志的记录严重等级提升到 INFO 。
  • Chrome 未能正确处理带有 NO_ERROR 的 RST_STREAM 帧,引发了一些与 Nginx 1.9.14 之间的问题 (Chromium Issue #603182)。 Nginx 1.9.15 提供了该问题的临时解决方案。
  • 在没有窗口空间时,Nghttp2 不会发送 END_STREAM 信号, 这个问题也在前述的 Nginx 邮件列表 中有讨论。

由于我们的 API 用户可能涉及到各种第三方 HTTP 库,我们需要进行更充分的测试才能为我们的 API 开启 HTTP/2 支持。

调试工具

CloudFlare 已经有一篇 总结得很好的 HTTP/2 调试工具总结。另外,我们发现 Chrome 的 Net-internals 工具 (Chrome 中通过 chrome://net-internals/#http2 可以访问) 也很有用。下图是当开启一个新的指向 www.dropbox.com 的会话时,Net-internals 工具记录帧的传输的截屏。 开启一个新的 HTTP/2 会话时 Net-internals 的截屏 总之,我们平滑的迁移到了 HTTP/2。以下是本文的内容的再次概括:

  • Nginx 中开启 HTTP/2 很简单。
  • 由于报头压缩的存在,入网带宽流量开销显著会降低。
  • 由于 Nginx 1.9.15 的某些 HTTP/2 实现,POST 请求的延迟会提高。
  • 当现有实现的兼容性还不够全面的时候,为所有内容都开启 HTTP/2 要小心。
  • 小流量验证和 Nginx 错误日志检查可以帮助尽早发现潜在的问题。

我们希望本文对有兴趣给服务器开启 HTTP/2 和对网络感兴趣的人有帮助。也欢迎收到您从下方的评论框给予的反馈。 更新: POST 请求延迟的增加和 REFUSED_STREAM 错误的问题在最近的 Nginx 1.11.0 版本 已经得到了修正。 下图展示了小流量机器变更了之后, P50 请求延迟比例 (小流量机器和线上机器延迟时间的比例) 降低了。要注意图中线上机器的 P50 请求延迟在之前为了支持 HTTP/2 升级到 Nginx 1.9.15 的时候有所增加。 Reduced P50 latency 变更之后 P50 请求延迟比例降低了 (4 个小时的流量数据) 贡献者: Alexey Ivanov, Dmitry Kopytkov, Dzmitry Markovich, Eduard Snesarev, Haowei Yuan, and Kannan Goundan


评论翻译

Haowei Yuan 由于有人感兴趣,我们在小流量机器上启用 HTTP/2 以后,P95 请求延迟比例(小流量机器和线上机器的比值)保持在接近 1.0 。

参考文档


原文地址:enabling-http2-for-dropbox-web-services-experiences-and-observations/ 首发于众成翻译Dropbox Web 服务启用 HTTP/2:体验和观测

[翻译]为什么迁移到 HTTPS 有利于网站统计

2016年06月06日 联邦机构要求将所有联邦网站在 2016 年底前都迁移成只能通过 安全的 HTTPS-only 连接 访问的网站。您也许不知道的是,转换成 HTTPS 后,您网站的引流页面的追踪效果会提升。 Https internet security concept doguhakan/iStock/Thinkstock 近日,一位联邦员工在某个 在线社区 上透露,二月底,有突发的巨量的从 Wikipedia.org 到某个联邦网站的引流。比引流巨大更奇怪的是,这些突发流量全都单单指向一个来源地址 (en.wikipedia.org),而不是从其它具体的页面来的。这突发的巨量引流,和空缺的具体来源页面,都是她希望解决的谜团。 幸运的是,一群社区会员很快找出了问题所在。症结在于:当访客从 HTTPS 网站点击一个指向 HTTP 站点的链接时,相应的 referer 信息会丢失,而 Google Analytics 就将该流量标记成“直接访问”。但是,从一个 HTTPS 站点到另一个 HTTPS 网站则是会带上引流数据的。本人之前写到过 使用某些短链接服务将导致 referer 丢失,短链接和 HTTP 引流问题都会导致所谓的 “不明流量”。本质上,“不明流量” 就是无法确定来源的访问,而 Google Analytics 将所有不明流量都归入只能知道是 “直接访问” 那一类。 然而,在这个特定的事例中,故事仍有波澜。Wikipedia 实际上已于 2015 年六月 从 HTTP 迁移到了 HTTPS。在那时,几乎所有从 wikipedia.org 到 HTTP 站点的引流数据都消失了。但是,2016年2月,Wikipedia 实现了 “referrer 策略” ,允许他们对所有的跳出链接设置一个统一的引流来源地址,包括指向 HTTP 站点的链接。他们选择将 referrer 设为 Wikipedia 的域名(带上语言标记),而不是外链到另一个站点的某个具体页面。所以,实际上被当成“直接访问”了几个月的流量突然又带上来源信息出现了,只不过,带上的来源很单一,都是来自 en.wikipedia.org 的。 某个联邦站点的来自 wikipedia.org 流量的截屏. 当 2015 年 6 月 Wikipedia 迁移至 HTTPS 时几乎完全变平了,又在 2016 年 2 月时由于 Wikipedia 新设置的引流策略重新出现了. 某个联邦站点的来自 wikipedia.org 流量的截屏. 当 2015 年 6 月 Wikipedia 迁移至 HTTPS 时几乎完全变平了,又在 2016 年 2 月时由于 Wikipedia 新设置的引流策略重新出现了. 不幸的是,并不是所有 HTTPS 网站都会像 Wikipedia 那样充分的应用 referrer 策略。也就是说,如果您的网站依然是 HTTP 的,则会有潜在的很大百分比的引流流量都被丢入 “直接访问” 的深渊里。而且鉴于 referrer 策略控制在导入流量给您的其它 HTTPS 站点手中,您就是想解决这个问题也无能为力。 当然,除非,您迁移到 HTTPS。 Tim Lowden is the Acting Program Manager for the Digital Analytics Program (DAP). For more information about DAP or to become a DAP participating agency, please contact DAP via email.


评论翻译

原文评论指出,虽然 HTTPS 指向 HTTP 的链接不带 referrer ,但是 HTTP 的站点指向 HTTPS 的链接是会带上 referrer 的。 也就是说,迁移到 HTTPS 以后,就可以享受到来自 HTTP 和 HTTPS 的两种 referrer 。


原文地址:Why Switching to HTTPS Will Make Your Analytics Better 首发地址:众成翻译:为什么迁移到 HTTPS 有利于网站统计

Windows 7 修改用户文件夹的方法

Windows 7 安装好了以后,有个 %USERPROFILE% 的变量默认指向 C:/Users/{用户名} 。一些应用程序的设置、临时文件等等都放在这个目录下面。 所以这个目录会非常庞大,至少有 5G 以上。 然而 Windows 7 的 C 盘空间很容易就不够用了。Windows 系统的硬盘分区设计就是个错误。 那么怎么把这个默认的用户目录改到另外一个盘,比如 D 盘呢?

首先,将 C:/Users 目录整体拷贝到 D 盘:

  1. 按一下“Windows”键,输入“计算机管理”之后按“Enter”,呼出“计算机管理器”;
  2. 鼠标点击“Administrator”,选择属性,而后在随后的对话框中去掉“帐户已禁用”之前的勾,而后关闭“计算机管理器”;
  3. 注销当前用户(注意,不是“切换用户”),而后以“Administrator”登录
  4. 打开命令行窗口,输入以下命令:
robocopy "C:\Users" "D:\Users" /E /COPYALL /XJ /XD "C:\Users\Administrator"
  1. 注销Administrator,重新用你的用户名登录Windows7,而后到“计算机管理器”里禁用Administrator;

以上和 “百度经验” 里面的方法一样。

接下来需要用 mklink 命令将 C:/Users 目录创建成指向 D:/Users 的接合(Junction)。 但是,当 C:/Users 目录存在时,无法 mklink 成功。 可是,C:/Users 目录总是有文件被占用,Windows 7 不允许删除它。

所以,先要解除 C:/Users 文件夹的删除限制

  1. 上一步复制完成后,重启电脑,进入注册表:运行Regedit ;
  2. 进入这个地址: HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionProfileList
  3. 找到含有 {你的用户名} ,比如 Administrator 设置信息的项,我这里是“S-1-5-21-3304176512-2651245909-2883396162-500” ;
  4. 修改”ProfileImagePath”的值为“D:/Users/{你的用户名}”
  5. 有强迫症可以把所有用户名的都改了,我只有一个用户常用所以没改别的,反正待会儿登录的那个用户名一定要改。

现在重新启动电脑, C:/Users/{你的用户名} 的功能已经被 D:/Users/{你的用户名} 取代了,自然可以删除了。

现在,终于可以彻底用 D:/Users 替换 C:/Users 目录的功能。

终于可以 rmdir 删除 C:/Users 目录了。 若还有百度拼音什么的非系统进程占用 C:/Users ,用任务管理器关掉占用的进程。 并创建目录接合,将 C:/Users 都指向 D:/Users。 用管理员身份打开 cmd ,输入以下命令:

rmdir "C:\Users" /S /Q
mklink /J "C:\Users" "D:\Users"

成功

重新启动电脑,用户目录至此全部修改成功。

参考文章

TotalPoll Lite 简体中文汉化包

TotalPoll 是一个 WordPress 的投票插件(DEMO地址)。其免费版本叫做 TotalPoll Lite,下载地址: https://wordpress.org/plugins/totalpoll-lite/ [caption id=”attachment_2292” align=”alignnone” width=”772”]TotalPoll DEMO - Picture Contest TotalPoll DEMO - Picture Contest[/caption] TotalPoll 简单易用,傻瓜方便,界面美观,SEO 友好,移动优先,无论是外观还是理念都比较现代。 为了方便老妈使用,我做了一个 TotalPoll Lite 的基本汉化包,日常功能和用户界面都是中文了。现在放出来提供免费下载。 [caption id=”attachment_2301” align=”alignnone” width=”1354”]TotalPoll Lite 汉化截图 TotalPoll Lite 汉化截图[/caption] 请将 totalpoll-zh.mototalpoll-zh.po 文件不改名,直接放入 \languages 目录中,简体中文版 WordPress 会自动识别并启用汉化。 若需要修改,请下载 poedit 自行修改。

配置本地的 .gitignore

有的时候会需要屏蔽一些本地的文件,如果这时候有洁癖,不想修改项目 .gitignore 并提交,可以采用本地全局 .gitignore 文件的方法。

git config --global core.excludesfile ~/.gitignore_global

其中 ~/.gitignore_global 就是本地的全局 .gitignore 文件。文件中每一行都会作为补充,应用于本地所有 git 项目中 。

参考文章

https://help.github.com/articles/ignoring-files/