同事在使用 sftp 连接服务器的时候出现错误信息：session is down，已经自行检查了服务器地址，端口，用户名，密码等种种可能出现低级失误的地方，结果找不到原因。
记一次sftp故障
1
分类目录归档：Technical
谈谈JSONAPI在PHP中的应用
现在服务端程序员的主要工作已经不再是套模版，而是编写基于 JSON 的 API 接口。可惜大家编写接口的风格往往迥异，这就给系统集成带来了很多不必要的沟通成本，如果你有类似的困扰，那么不妨关注一下 JSONAPI，它是一个基于 JSON 构建 API 的规范标准，一个简单的 API 接口大致如下所示：
JSONAPI
简单说明一下：根节点中的 data 用来放置主对象的内容，其中 type 和 id 是必须要有的字段，用来表示主对象的类型和标识，其它简单的属性统统放置到 attributes 里，如果主对象存在一对一、一对多等关联对象，那么放置到 relationships 里，不过只是通过 type 和 id 字段放置一个链接，关联对象的实际内容统统放置在根接点中的 included 里。
在同一个系统里使用多个版本的软件
如果你有几房姨太太的话，那么想让她们和平共处，多半是痴人说梦。对程序员而言，虽然他们不会有娶几个老婆的好运气，但是很可能会遇到在同一个系统里使用多个版本的软件的情况，一旦处理不好，同样会焦头烂额。
SYN丢包的几个例子
史上最LOW的PHP连接池解决方案
大多数 PHP 程序员从来没有使用过连接池，主要原因是按照 PHP 本身的运行机制并不容易实现连接池，于是乎 PHP 程序员一方面不得不承受其它程序员的冷嘲热讽，另一方面还得面对频繁短链接导致的性能低下和 TIME_WAIT 等问题。 继续阅读
实战Guzzle抓取
SYN和RTO
前两天，我在微博上推荐了一篇朝花夕拾的文章：The story of one latency spike，文章中介绍了 cloudflare 工程师如何一步一步 debug 网络延迟问题，细细读来受益良多，不过我并不打算详细介绍那篇文章的细枝末节， 本文只摘录一个点：
When debugging network problems the delays of 1s, 30s are very characteristic. They may indicate packet loss since the SYN packets are usually retransmitted at times 1s, 3s, 7s, 15, 31s.
为什么是 1 秒、3 秒、7 秒、15 秒、31 秒？说来惭愧，我以前从没有注意过 SYN 重建时的时间特征，知耻而后勇，正好借此机会来一探究竟。
如何快速判断配置文件的路径
最近使用 pip 的时候感觉速度太慢了，感觉有必要改成豆瓣的豆瓣的镜像，可我记不清 pip 的配置文件路径了，当然可以用搜索引擎查询一下，不过还有更快的方法：strace！
shell> strace -eopen pip 2>&1 | grep pip.conf
open("/etc/xdg/pip/pip.conf", O_RDONLY) = ...
open("/etc/pip.conf", O_RDONLY) = ...
open("/root/.pip/pip.conf", O_RDONLY) = ...
open("/root/.config/pip/pip.conf", O_RDONLY) = ...
如此一来，我们很容易就能看出配置文件的路径，甚至还能看出多个配置文件的加载顺序。此外，通过此技巧还能看到一些意想不到的信息，比如 nginx 的例子：
shell> strace -eopen /usr/local/nginx/sbin/nginx 2>&1 | grep conf
open("/usr/local/nginx/conf/nginx.conf", O_RDONLY) = ...
open("/usr/local/nginx/conf/mime.types", O_RDONLY) = ...
open("/etc/resolv.conf", O_RDONLY) = ...
open("/etc/nsswitch.conf", O_RDONLY) = ...
除了 nginx.conf 等常见的配置文件，我们还可以发现其加载了 nsswitch.conf 等不常见的配置文件，通过研究这些细节，可以让我们更透彻的理解问题。
通过实例入门Golang
如果想学会一门新语言，不仅要多读文档，还要多看别人写的代码，更要强迫自己用新语言多写代码。我在学习 Golang 之前，读过好几本相关的书籍，不过总感觉没真正学会，于是我决定动手用 Golang 写一个能用的工具试试，因为 Golang 最大的优势就是 goroutine 和 channel，所以我觉得实现一个简版的 ab（Web 压力测试工具）应该是一个不错的选择，用 Golang 磕磕绊绊总算实现了预想的功能，能够计算 Requests per second 和 Time per request 的值，不过总感觉写出来的代码不够漂亮，于是我又找来 hey 的代码前后读了几遍，然后结合自己的理解临摹了一遍，感觉总算是入门了。
说说压力测试工具
系统写好了，能不能顺利上线？一般来说我们需要做一些压力测试来判断。比如系统预计每天一百万的接口访问量，并且访问时段主要集中在早八点到晚八点，那么平均下来 RPS 大约是 22 次左右，不过用户的访问量通常不会很平均，假设峰值流量是平均流量的 3 到 5 倍的话，那么我们可以推断出项目要想顺利上线，RPS 至少应该达到 66+ 次，110+ 次更好。由此可见上线前用压力测试工具测试 RPS 是一个很重要的环节。