Blog IP 被墙 …

目录:Blog | 标签:Blog , EC2 , GFW | 发表时间: Jun 20, 2013

Blog 里面并没有写什么和谐的内容，自己的 vps 也没有用来翻墙，最多就是搭了个 dabr 上推而已，而且还是使用 https 访问的，想来 gfw 还不至于能牛逼到这个地步。所以原因估计是同网段的某个 IP 中了招，被连带到了吧。
不过 EC2 上面换 IP 还真心方便啊，鼠标点两下就换了，比其他 VPS 还要发 ticket 的方便快捷不少。
没什么了，主要是证明我还活着，额。。

Update: 据说是封了所有使用免费证书的 IP，好吧，我又换了个 IP，看看是不是会被再墙

SPDY 简介

目录:笔记 | 标签:http , spdy | 发表时间: Jan 7, 2013

之前的文章提到过本站已启用了 SPDY 协议，只要使用最新的 Firefox, Chrome, Opera 浏览器访问就是使用的 SPDY 协议。那么什么是 SPDY 协议呢？和 HTTP 相比又有什么优点呢？下面就是我自己的一些理解：

HTTP 为什么慢

下面是我认为影响比较大的原因：

请求是串行的，只有等上一个请求应答接收完之后才能发送下一个请求。如果有个请求应答时间很长，则会导致后续的请求都阻塞住。就算是在有 HTTP pipelining 的时候也好不到哪儿去，因为对于客户端同时提交的多个请求，服务器应答的时候必须按照同样的顺序进行应答，因此如果某个请求的应答时间很长，同样会导致后面的应答阻塞。
连接建立的开销。现在的浏览器为了避免上面提到的问题，都会采用多连接的方式，在有丢包和延迟的情况下面，建立连接代价是比较高的。而且 TCP 都会有一个慢启动的过程，而网页一般都比较小，往往这条连接还没有（或刚刚达到）最佳的速度就把内容下载完成，请求其他内容时又要重新完成慢启动的过程。

其他原因，影响应该不是那么明显：

只能有客户端主动发起连接，不能服务器进行推送。
头部没有压缩。

SPDY 做了什么

详细的协议介绍可以直接看其协议文档，这里简单的说一下，SPDY 在一个 TCP 流中分出了多个 SPDY 通道（协议里面叫做 stream），每个通道完成一个请求和应答，并且这些通道是并行的。这样一来就一举解决了上面提到的问题：

请求在不同的通道中，并且可以并行，那么浏览器就可以一起把需要的资源请求同时发给服务器，而服务器也可以同时处理这些请求，同时将应答回复给客户端。不会出现等待每个请求或者某个应答才能继续的问题。
由于一条 TCP 就能有多个通道（现有协议规定可以创建 2G 个，客户端与服务端各可创建 1G 个），因此客户端和服务器就只需要一条 TCP 连接即可，因此就不会有建立连接的开销，也没有慢启动那些的问题。
SPDY 的头部总是压缩的，这样可以减少传输量。
SPDY 的通道双方都可以创建，因此服务器可以主动推送资源，不需要被动等待客户端请求。
通道在创建的时候可以指定优先级，可以让重要的请求优先处理。

SPDY 现状

新闻上说 HTTP 2.0 的第一个草案就是直接拷贝 SPDY 的协议文档，因此 SPDY 很有希望成为以后的 HTTP 2.0 标准。

不过至少在成为标准之前，SPDY 还没有自己的独有端口，那如何使用该协议呢？Google 提出了在 HTTPS 之上使用 SPDY，只需要增加一个 SSL 的扩展协议 NPN，在 SSL 协商的同时协商出上层使用的协议，这样在 SSL 握手完成后，客户端与服务器就知道上层的应用是 SPDY 还是普通 HTTP，从而使用相应的协议进行处理。这样做的好处就是对用户透明，不需要显示使用类似 spdy:// 这样的前缀去指定使用 SPDY 协议，现有的网页也不需要修改，只需要对浏览器和服务端进行升级即可。

Pagespeed 笔记

目录:笔记 | 标签:http , pagespeed | 发表时间: Dec 27, 2012

这是我这几天看 pagespeed 的一些笔记，由于我并不是搞 web 开发的，文中的内容只是我自己的一些理解，所以可能并不一定正确。

pagespeed 是 google 出品的一款 apache 模块，其中有多达 40 种的优化手段，可以帮助提升网站的加载速度。其主要优化方法有以下几种：

减少页面的大小
减少浏览器的连接数量
提高浏览器渲染速度

减少页面的大小

在减少页面大小方面，pagespeed 提供了以下选项：

Collapse Whitespace
Combine Heads
Elide Attributes
Minify JavaScript
Optimize Image
Remove Comments
Remove Quotes
Rewrite CSS
Rewrite Style Attributes
Trim URLS

这些选项所做的基本上就是以下几点：

对于 html, css, js 文件：
- 去掉不必要的空格
- 去掉注释
单独对于 js 文件：
- 类似 jsmin 方法压缩 js
对于图片：
- 将小图片进行内联，目的是为了减少连接数
- 重新压缩图片，以减少大小
- png 转换为 jpg，jpg 转换为 webp

这每一个优化选项在开启了 gzip 压缩的服务器上面效果可能都不是很明显，不过一点一点的积累之后效果也是可以的。对于那些没有对 js 压缩过的网页，可能 Minify JavaScript 效果是最好的。

减少浏览器的连接数量

一般来说，在网页方面，减少连接数要比减少文件大小效果要好。

因为在有 gzip 压缩的情况下面，页面都是比较小的，而且能减少的大小也是很小的。有时候减少文件大小并不能减少传输的包个数，比如：4K的文件优化后为 3K，其实都需要 3 个 TCP 包才能传输完成。

而一个请求的代价则会多很多，首先，请求头部与应答头部的开销；其次，多一个请求可能会多一个 TCP 连接，新建 TCP 连接的开销。

在减少浏览器连接数上，pagespeed 提供了以下选项：

Combine CSS
Flatten CSS Imports
Inline CSS
Combine JavaScript
Inline JavaScript
Move CSS Above Scripts
Configuration file directive to shard domains
Sprite Images

看名字就能猜到其功能。

对于 css：主要就是将页面中的多个 css 合并为一个，将小的 css 文件内联到页面中，将 imports 的 css 也进行内联。

对于 js：主要也是将多个 js 合并为一个，将小的 js 文件进行内联。

对于 css 中的背景图片，Sprite Images 可以将多个背景图片合并为一个。

提高浏览器渲染速度

提高浏览器渲染速度其实是比较难的，不过 Google 自己就是做浏览器的，清楚的知道什么样的网页可以更快的进行渲染。可以使用的选项如下：

Convert Meta Tags
Defer JavaScript
Inline Preview Images
Lazyload Images
Move CSS to Head
Optimize Image
Rewrite Style Attributes

感觉比较有效果的是 Inline Preview Images 和 Lazyload Images。

Inline Preview Images 打开之后先加载低画质的图片，待高画质图片下载完成之后在加载高画质图片。

Lazyload Images 则只加载显示区域的图片。淘宝的页面应该就是使用类似这个的技术。

缓存改进

其实这个可以归为减少浏览器连接数，不过我还是把他单独列出来了，主要思想就是把资源尽可能的缓存在浏览器，这样浏览器访问页面的时候就直接使用本地缓存而不用向服务器发送请求了。提供的选项如下：

Extend Cache
Extend Cache PDF
Local Storage Cache
Outline CSS
Outline Javascripts

Extend Cache 修改资源的名称，在原有名称后面加上该资源的 hash 值，然后在资源的 http 应答头部中将缓存时间设置很长（比如 1 年），那么后续的页面如果还有引用该资源，则不会向服务器进行请求。如果资源有改动，那么 hash 值就会改变，因此浏览器会认为是不同的资源，然后发送请求获取新资源，当然引用资源的 html 页面是不能被缓存的。

Outline CSS/Javascripts 将页面中内联的 CSS/JS 进行外联，这样的好处是：CSS/JS 可以被缓存，如果多个页面用到同一个资源的话，可以节省传输量；如果 html 经常改动，那么 CSS/JS 的缓存也能减少传输量；如果 CSS/JS 很长，外联可以使 html 文件变小，可以让浏览器先加载 html 进行显示。当然外联的坏处也是显然的：增加了浏览器的请求数。