网站搬迁

本站已经迁移到新的服务器,如果你看到的是这个页面的话。

这次服务器是 Ubuntu 16.04 LTS 版了,这样世界上最完美的语言 PHP 也升级到 7.0 了。当然使用的还是 Nginx 作为 web 服务器。

这些天都在看里约奥运会,这里很多商场里都放着大电视,沙发,给民众随便坐,随意的观看。

brentwood-mall-rio2016.jpg

阅读全文

Amazon CloudFront 502 cannot connect to origin

这是之前我在转用 Amazon CloudFront 的时候,遇到的一个问题,我用的是 Custom origin,是以本站的原始服务器作为源,没有使用 Amazon 的 S3。当配置完成 CDN 生效后,在访问的时候出现了 502 错误,显示 cloudfront cannot connect to origin。

在仔细检查后,发现了问题,其实在一年前或者更久之前已经遇到过这个坑了。
那就是 Amazon CloudFront 只支持有限的几个加密协议。而恰巧本站当时的加密协议中没有这几个。

Amazon CloudFront 要求的加密算法:

  • ECDHE-RSA-AES128-SHA
  • ECDHE-RSA-AES256-SHA
  • AES256-SHA
  • AES128-SHA
  • DES-CBC3-SHA
  • RC4-MD5

源服务器必须支持上面的任意一种,来建立 SSL 连接。

我的服务器之前是使用椭圆曲线算法,支持的加密协议没有包括上面的。

阅读全文

Amazon CloudFront 增加了加拿大节点

在我转用 Amazon CloudFront 的服务不久,Amazon 就宣布其 CDN 服务节点扩展到加拿大,位于多伦多和蒙特利尔这两个大城市。现在 Amazon CloudFront 的服务节点总数增加到 59个,比我上次介绍的时候多了这两个。

CloudFront 可以非常好的服务于静态,动态或者交互内容,在全球范围内都能提供高速度,低延迟的服务。

Amazon 还同时宣布,之后就在这两个地方同时支持 Amazon Route 53 服务。

现有的用户无需做任何变动,比如我选择的是

Price Class

Use All Edge Locations (Best Performance)

这样,加拿大的节点就会自动生效的。

cf_montreal_2.jpg可以看到加拿大的美丽的城市及风景,我更希望 Amazon 可以增加一个西部的节点,或者就在温哥华设置一个,使西部的用户也能从中受益。

阅读全文

开始用微博

直到前一周,我才开始使用微博,现在用了两个星期,当然首先就是有一个困扰,也许是我最初设置的时候有选择某些类别,造成的后果就是自动 follow 了很多微商,或者是股票,金融方面的账号。噼里啪啦的连着发过来私信,基本都是要入投资群,要求跟他投资的,于是我就手工去掉了很多账号。
几分钟前刚收到一条,说是"周收益 25% 以上",我相信你这是正常投资,我是那个。
cheat-1.PNG

好吧,没有关系,我愿意相信微博上还是正常的账号多。

如果你有微博帐号的,欢迎来加我好友。

点击此链接就可以了,或者复制链接到你的浏览器 http://weibo.com/i/1184345670

再或者用你的手机扫描二维码。

weibo-2d-bar.png

阅读全文

更换 CDN 服务商到 Cloudfront

差不多使用 Keycdn 有大半年了,这次又再次换回了 Amazon 的 CloudFront。

Keycdn 同 Cloudfront 的比较文章有很多,就不详细展开了,这里就提几点我比较在意的好了。

第一,节点数目

Cloudfront 在全球它有超过 57 个节点,分布在美国,欧洲,亚洲,澳洲,以及南美;其低延迟性是获得认可的。 这里有它的完整列表以及详细解释。下面只列出截至到今天为止的节点。

United States

  • Ashburn, VA (3)
  • Atlanta, GA
  • Chicago, IL
  • Dallas/Fort Worth, TX (2)
  • Hayward, CA
  • Jacksonville, FL
  • Los Angeles, CA (2)
  • Miami, FL
  • New York, NY (3)
  • Newark, NJ
  • Palo Alto, CA
  • San Jose, CA
  • Seattle, WA
  • South Bend, IN
  • St. Louis, MO

Europe

  • Amsterdam, The Netherlands (2)
  • Dublin, Ireland
  • Frankfurt, Germany (3)
  • London, England (3)
  • Madrid, Spain
  • Marseille, France
  • Milan, Italy
  • Paris, France (2)
  • Stockholm, Sweden
  • Warsaw, Poland

Asia

  • Chennai, India
  • Hong Kong (2)
  • Mumbai, India
  • Manila, the Philippines
  • New Delhi, India
  • Osaka, Japan
  • Seoul, Korea (3)
  • Singapore (2)
  • Taipei, Taiwan
  • Tokyo, Japan (2)

Australia

  • Melbourne, Australia
  • Sydney, Australia

South America

  • São Paulo, Brazil
  • Rio de Janeiro, Brazil

目前Keycdn只有25个节点,显得有点儿少。

在节点数上 Cloudfront 全面胜出。

第二,计费

Cloudfront 的计费是比较复杂的,各大区的传输费率不同,最低的美国和欧洲地区,首 10TB,每 GB 为 8.5 美分。而 keycdn 同样的地区可以做到只有 4 美分。可是Cloudfront是不限制你增加多少个域名或者网站使用的,这个部分 keycdn 是有5个免费的 zone,每增加一个zone的话,就是$1一个月。

另外Keycdn 就只有这两部分的收费了,而 cloudfront 还会收取 Request 的费用。

对于流量不是那么大,而网站数目比较多的来说,两者相差不多,可能还是 Cloudfront 更为经济一点呢。

第三,SSL及相关

两者都提供免费的 SSL 给用户使用(使用的是它们的子域名),也支持用户所提供的 ssl 证书(用于用户的cname),这里就有差别了,Cloudfront 会分两种,一种是免费的 SNI 形式的SSL 加密,而收费的专属 IP SSL加密就会要收取每月600美元。而keycdn是免费支持,显然它所支持的就是 SNI 形式的SSL加密。

而SSL加密后的流量走的是 https 协议了,同不加密的 http 流量相比,Cloudfron 的 Request 费率也是不同的,HTTPS requests 比 HTTP requests 费率高30%,或者在有的区域会更多一点。

在使用 SSL 方面, Keycdn 是支持 HTTP/2 的,这点儿非常的好,而 cloudfront 就不知道什麽时候才会支持它了。

阅读全文

AMP 页面问题的进展

之前在 Google Search Console 看到本站有不少的 AMP 页面问题,包括三类: 禁用的或者无效的 HTML 标签;非法使用的 AMP 标签;未被正确使用的 AMP 布局属性。

当时我采用的方法在前文 (修复 AMP 页面错误) 已经介绍过了,通过标签替换的方式,在 AMP 模板里做了设置。

时间已经过去了一个多月,现在查看,发现 AMP 页面收录数量有小小的增加,而统计到的错误页面也减少了50%。

其实同时我还对 Structured Data 统计到的错误也做了修复,目前统计到的情况是在 626 个页面的 4088 Items 被收录,而另外的 395 个页面上有 1198 Items 有错误信息。
在当时这个数据是 在 609 个页面上的 2148 Items 被收录,而 592 个页面的 2065 Items 含有错误。 可见修复后的情况有了很大的改善。

目前就是需要时间,等待 Google Search 不断的抓取页面,并把新的情况更新到其搜索数据库内。这个部分没法控制,只能等待。

阅读全文

MovableType 发布更新

前不久 SixApart 发布了 MovableType 6.x 安全补丁。这次还是有关 SQL injection 的问题。
从 MovableType 6.2.4 升级到 6.2.6 是非常简单的,只要覆盖源文件,然后登录后台,自动会升级数据之类的了。

最大的难题是过去用来下载最新个人版的地方,没有最新的 6.2.6,只有之前的 6.2.4。之前是到下面这个网址,输入口令就可以到下载列表,下载最新版的了。
https://www.ecbuyers.com/sixapart/catalog/campaign_products.php?page=1&campaign_id=3
mt-old-download-page.png

可以看到现在没有最新版了。

经过查询该站客服,没有答案,于是就再次搜索,后来找到的地方是在 SixApart 日本站,有相关的下载地方,不是非常方便,可以说是非常繁琐,也不容易看,毕竟不识日文。

阅读全文

HSTS Preload 通过审核

在上文提到我把包括本站在内的几个域名都提交了 HSTS Preload 的申请,之后大概过了一周的时间,就可以看到已经通过了审核。

据官方的说明,现在每周他们都会手工审核相关的申请,当然之前,在提交的时候已经有了初步的自动审查,但是最后一步的审核以及合并到列表中,则是人工操作。
本站的域名,就是 g2soft.net, 已经可以在最新的 HSTS Preload 列表中查询到。 https://cs.chromium.org/chromium/src/net/http/transport_security_state_static.json

当然也可以直接到申请页面查询,一般在提交申请的表单的地方,输入域名,然后点击按钮,就会显示当前的状态。
或者点击这个链接,就可以看到查询状态。

阅读全文

加入 HSTS Preload 申请

HSTS 是 HTTP STRICT TRANSPORT SECURITY 的缩写。意思就是强制严格 https 通讯。当浏览器访问过设有 HSTS 头的网站后,浏览器就会记下,以后都会用 HTTPS 访问该网站,无论用户输入的是 http 还是 https。目前 HSTS 已经被 Google Chrome, Firefox, Opera 以及IE。

这里在网站的 web 服务器设置 HSTS 还是会存在一定的不安全的风险,就是当用户第一次输入域名的时候,用的是 http ,还是有可能受到中间人攻击的。所以最好的办法是把你的域名加入到 HSTS Preload 列表中,Google 发起维护的一个列表,该列表会被内置在浏览器内,任何安装该浏览器的电脑,接受到用户所输入的域名后,会比对列表,如果看到已经在列表内了,那就直接用https 访问。

鉴于这些优势,DavidYin 已经把所有在用的网站都加上了证书,并且提交了四个域名的 HSTS Preload 申请。

这是我所提交的一个域名的情况:

hsts-preload-submit.png可以看到,申请已经接受,等待审核。

具体申请的条件如下:

主机必须有 HSTS Header,就是这个。

Strict-Transport-Security: max-age=16070400; includeSubDomains

阅读全文

修复 AMP 页面错误

在 Google Search Console 的报告了,可以看到本站有一百多个 AMP 错误。主要就是 Invalid usage of AMP tags。这么多的错误,还是需要修正的。于是就做了如下的检查和修正。

在 Google Chrome 的开发者工具里的控制台内,查看这些 AMP 页面,只要网址加上 #development=1 就可以了。

看到的错误主要有四部分。

1) 在标签 a 里面,有 onclick 属性,这个是 AMP 无效属性。

2) 在标签 p 或者 span 内,有 style 属性,这同样是无效的。

3) 在标签 img 里面,有 style 属性,同样要去掉。

4) 标签 iframe, 要替换成 amp-iframe 标签。

修复的过程主要参考了这篇文章,没全部看,因为是日文的,看不懂,大概的参考了中间这一段。

阅读全文
全部文章归档