由于近期国内网络出版服务管理规定的出台,Apple 在华的部分业务似乎遇到了一点小麻烦,与此同时关于 App Store 下载缓慢的问题也又开始讨论起来。
原本是老生常谈的问题，无奈如今一些群体中的反智主义盛行，导致「不愿意好好弄清楚事情是怎么回事，并且通过行动有意无意地鼓励大家不要去好好弄清楚事情是怎么回事」的人呈指数性增长。另一方面，虽说处在自由言论的环境下，但无意义的、有人身攻击性质的、不礼貌的争辩越来越多。事实上，Apple 的互联网服务的确是有一定的问题，不然也不会有「Apple 公司的各项互联网服务基本上是在打云计算的脸：从不伸缩，通过拒绝服务的方式抹平峰值访问量」的调侃。之前自己有过这方面的优化和调教经验，但是当时由于时间关系，事后依然是没留下什么实质性的资料和文档（又一个没留下资料的栗子），不过今天就抽出一点时间来简单谈谈 App Store 在国内下载缓慢的问题以及相关的优化经验。
Apple 基础服务层级简析Web Service
Apple 的 Web Service 是由 Amazon 的 AWS 提供的自然不用多说，而且今年 Apple 也有建立自己 D...阅读全文

在 Dropbox ，我们的运维团队于近日升级了前端 Nginx 服务器开启了 web 服务的 HTTP/2 支持。在本篇文章中，我们将就此次 HTTP/2 的升级过渡，分享我们的一些经验以及相关发现。总体来说此次升级还算平滑，然而依旧踩了很多的“坑”碰到了不少注意事项，希望会对他人有所帮助。
背景：HTTP/2 以及 Dropbox web 服务架构HTTP/2（RFC 7540）是新一代的 HTTP 协议版本，它基于 SPDY，相比于 HTTP/1.1 提供了数项性能优化。这些优化包括：更高效的首部压缩（Header compression）、服务端推送（Server push）、同一连接上的流复用（Stream multiplexing），等等。如今，HTTP/2 已经被大部分浏览器所支持。Dropbox 使用开源的 Nginx 处理 SSL 连接并且对 web 流量进行七层的负载均衡。在升级之前我们前端的 Web 服务器运行的是 Nginx 1.7 并且支持 SPDY。另一个顾虑则是 Chrome 虽同时支持 SPDY 以及 HTTP/2 ，但是官方将会在 5 月 15 起，...阅读全文

毫无疑问，Web 性能的终极目标是减少到用户端的延迟。让用户能够尽快的打开前端网页并进行相关交互。
就 HTTP 而言，理想的协议应该看起来是这样的：
而对于客户端来说，应该尽可能发送少的数据给服务器，从服务端下载尽可能少的数据，尽可能减少 Round Trips客户端与服务器无论是哪一边，额外的数据流都会带来额外的延迟开销，与此同时也更容易出现拥塞和丢包问题,这无疑严重影响了性能。多余的 Round Trip 同样会增加延迟，尤其是在移动网络下（100ms 是让用户感觉到系统立即做出响应的时间上限）那么究竟理想中的 HTTP 是什么样的，而我们又该如何去优化？
HTTP/1.1HTTP/1.1 这个协议本身有很多的优点，不幸的是性能并不在其中。一个典型的页面请求是这样的：
显然这并不理想
HTTP/1 是 chatty 类的协议 ，因为需要不断的去向服务器请求新东西，首先是 HTML 其次是 CSS 和 JavaScript，每一次的交换都增加了额外或者是更多的 Round Trip 延迟，明显和「尽可能减少 Round Trips」的目标背道而驰。其次，页面上的请求增加了...阅读全文

作为 TJ 的首个创业项目- Apex Ping,在一些 hardcore 的人眼里，从更深层次的技术角度上讲,可能有时会觉得有些失望,但是从美学和 UI 方面来谈,也许能让人眼前一亮。
从 16 年 4 月 23 日在 Medium上发声说「我要成立自己的公司啦:Apex Software」到 6 月 17 日正式宣布并上线第一个 APM 模块 Apex Ping，时隔个把个月，我也在 Medium 和 Twitter 上时刻跟踪着动态。并且在第一时间试用了一下 Apex Ping，总体来说体验可以，前端方面则是 React + D3 用以呈现数据，后端则是利用 AWS 的  Lambda，并且他们开源了一些工具。
当然，以 TJ 的水准，UI 上的优雅自然不用多说。
Time Status 很有意思，包括:
DNS 解析时间 (NAME LOOKUP)连接建立时间 (CONNECT)TLS 握手时间 (TLS HANDSHAKE)TTFB (FIRST BYTE)响应时间(RESPONSE)重定向时间（REDIRECTS）看的出来，后端用的估计是 CURL 手法。之前一基本...阅读全文

至少在过去的 HTTP 1.x 时代，网页性能优化的关键大部分的因素并不在于高带宽，而是低延迟（Low latency）。而如何去优化延迟，就显得格外重要。
如果把时间开销分为两部分，那么一部分和带宽成反比，而一部分和延迟成正比。很多时候人会想当然地以为带宽一定是瓶颈。其实不然，而绝大多数用户基本上只有在等待下载大文件时才对时间开销有感觉，而这时候瓶颈必然是带宽。但实际上如果你做一些分析（profiling）的话，你才能知道你手头上的问题瓶颈在带宽还是延迟。关于 HTTP 请求的瓶颈分析，这里就不谈太多了，具体推荐参考这篇HTTP 请求的 TCP 瓶颈分析，文笔不错、思路也是清晰透彻，实乃分析之典范。如果你会用 Chrome 的来分析 Network 的话，你就会发现小文件如 JS/CSS 的瓶颈其实在延迟。
问题是如何最大化的减少延迟带来的影响？DNS 缓存DNS 预获取（DNS-Prefectch）DNS prefetching is an attempt to resolve domain names before a usertries to follow a link...阅读全文