图床服务的搭建思路
早年写过一篇关于常用图床的介绍,时过境迁,连当时最稳定的微博图床都已经不能简单地正常使用了。后来改用了一段时间 Github 图床,虽然一共没几张图片,但总感觉这是在滥用 Github 提供的免费服务,正好最近在折腾其他项目,干脆就自建了一个图床服务。这里就借机讲讲自建图床的思路。
图床的主要功能是图片的持久化存储和外部通过链接访问,由于图片的大小通常在几十 KB 到几 MB 不等,因此我们必须着重考虑以下几个因素:
早年写过一篇关于常用图床的介绍,时过境迁,连当时最稳定的微博图床都已经不能简单地正常使用了。后来改用了一段时间 Github 图床,虽然一共没几张图片,但总感觉这是在滥用 Github 提供的免费服务,正好最近在折腾其他项目,干脆就自建了一个图床服务。这里就借机讲讲自建图床的思路。
图床的主要功能是图片的持久化存储和外部通过链接访问,由于图片的大小通常在几十 KB 到几 MB 不等,因此我们必须着重考虑以下几个因素:
最近入手了个软银线路的某工的日本机器,此线路是联通友好线路,可惜机器低配高价,性价比很一般。 入手的主要原因是为了能给家里的 NAS 建立个稳定的穿透链路,由于宽带和移动网络使用的都是联通,所以其实整体体验还不错,这里贴一下相关测试,给大家个参考。
去年看到 Let’s Encrypt 宣布将在 2018 年支持 wildcard SSL 证书的消息时就一阵兴奋,虽然后来跳票了一次,但最终还是于前段时间正式支持了。本文将使用 acme.sh 这个小工具来体验下此项特性。
最近写了个简单的 chrome 插件来简化工作流程,其中一个功能就是对当前页面的 URL 进行监控以根据 URL 中的参数发起网络请求获取数据,本文主要记录本功能相关逻辑的实现。
通过 window.location.href
就可以轻松获取到当前页面的 URL ,然而想要响应当前页面的 URL 变化则需要对相应事件进行处理。
首先在 manifest.json 中添加对 tab 的操作权限:
|
|
-----BEGIN xxx-----
作为开头,以 -----END xxx-----
作为结尾,主体部分使用 base64 对 ACII 进行编码。可以储存公钥证书(服务器证书及中检证书,「xxx」为 「CERTIFICATE」)和私钥(「xxx」为「RSA等加密算法名称 PRIVATE KEY」),也可以储存两者的联合,但通常情况下,Apache 等软件都会要求将公钥和私钥分开存储到不同的文件。.pem
、.key
、.csr
、.cer
、.crt
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365
扩展名参照上文openssl x509 -in certificate.pem -text -noout
扩展名参照上文.der
、.key
、.csr
、.cer
、.crt
openssl req -x509 -newkey rsa:4096 -keyout key.der -outform der -out cert.der -days 365
扩展名参照上文openssl x509 -in certificate.der -inform der -text -noout
扩展名参照上文尽管相对于 HTTP ,HTTPS 在安全性上已经有了质的飞跃,然而简单的设置 HTTPS 仍无法避免类似于中间人攻击这样的恶意行为,而本文所要介绍的 OCSP Stapling 和 下篇文章将要介绍的 Certification Transparency 就是用来防范这些恶意行为的。
OCSP (Online Certificate Status Protocol) 通常由 CA 提供,用于在线实时验证证书是否合法有效,这样客户端就可以根据证书中的 OCSP 信息,发送查询请求到 CA 的验证地址,来检查此证书是否有效。
然而这些默认查询 OCSP 的客户端在获得查询结果的响应前势必会一直阻塞后续的事件,在网络情况堪忧的情况下(尤其是大陆地区)会造成较长时间的页面空白。
而 OCSP Stapling ,顾名思义,是将查询 OCSP 接口的工作交给服务器来做,服务器除了可以直接查询 OCSP 信息,还可以仅进行少数次查询并将响应缓存起来。当有客户端向服务器发起 TLS 握手请求时,服务器将证书的 OCSP 信息随证书链一同发送给客户端,从而避免了客户端验证会产生的阻塞问题。由于 OCSP 响应是无法伪造的,因此这一过程也不会产生额外的安全问题。
同步、异步与阻塞、非阻塞这四个概念在多线程、多进程、I/O 相关编程中非常常见。然而在不同的场景下,定义中给不同框架、操作系统功能所打上的标签常常让不熟悉这四个概念区别的人疑惑不已。本文就从许多应用层框架所依赖的 Unix 中的 5 个 I/O 模型来理解这四个概念。
在 Unix 中,有 5 种 I/O 模型:
在类 Unix 系统中,I/O 操作总是分为两个阶段:
结合生活理解这一对概念,我们假设一个场景:
由于 Disqus 在国内访问困难,Hexo NexT 主题每每尝试加载文章评论数时都会严重拖慢页面加载速度。除了期望读者能够使用一些其他的方法访问网站,其实站长和博主们还可以主动采取一些措施来解决这一问题。本文另辟蹊径,不借助 Nginx 的反向代理,而是使用 Disqus 和 LeanCloud 的公共 API 来曲径救国。使用 LeanCloud 的原因是 Hexo NexT 主题可以很方便地设置使用 LeanCloud 来统计访问数,所以从减少访问数、减轻服务器负载和资源合理利用等角度,再进一步地使用 LeanCloud 来存储评论数量数据。
参见 《Hexo的NexT主题个性化:添加文章阅读量》 一文中的 配置 LeanCloud 部分 ,注册 LeanCloud 并初始化应用。此后,我们的博客中每篇文章的信息已经通过参考文章中的方法保存到了同一张表中,因此我们只需要对这张表添加几个字段,就可以在实现本文目的的同时,避免使用 LeanCloud API 分别查询两个表的数据所带来的不必要的请求。Counter 表的字段如下图:
Brotli最初发布于2015年,用于网络字体的离线压缩。Google软件工程师在2015年9月发布了包含通用无损数据压缩的Brotli增强版本,特别侧重于HTTP压缩。其中的编码器被部分改写以提高压缩比,编码器和解码器都提高了速度,流式API已被改进,增加更多压缩质量级别。新版本还展现了跨平台的性能改进,以及减少解码所需的内存。
与常见的通用压缩算法不同,Brotli使用一个预定义的120千字节字典。该字典包含超过13000个常用单词、短语和其他子字符串,这些来自一个文本和HTML文档的大型语料库。预定义的算法可以提升较小文件的压缩密度。
使用brotli替换deflate来对文本文件压缩通常可以增加20%的压缩密度,而压缩与解压缩速度则大致不变。使用Brotli进行流压缩的内容编码类型已被提议使用“br”。
另附 Brotli 算法和其他算法的性能比较:
- Google Chrome supported Brotli from version 49.
- Microsoft Edge has Brotli in Development.
- Mozilla Firefox implemented Brotli in version 44.
- Opera supports Brotli since version 36.
- Safari, no public commitment as of October 2016.