现象：
1 | root@raspberrypi:~# hcitool lescan |
解决方法：
可以先尝试：
1 | sudo hciconfig hci0 down |
如果还未正常工作或者检查状态为DOWN，可以尝试
1 | sudo service bluetooth restart |
解决mac下brew link python出错
1 | $ brew link python |
解决方法：
1 | $ sudo mkdir /usr/local/Frameworks |
验证:
1 | $ brew link python |
使2用hcitool lescan时出现错误：Set scan parameters failed: Operation not permitted
1 | $ brew link python |
解决方法：
1 | $ sudo mkdir /usr/local/Frameworks |
验证:
1 | $ brew link python |
HTTPS 之 TLS 性能调优
HTTPS（HTTP over SSL）是以安全为目标的 HTTP 通道，可以理解为 HTTP + SSL/TLS，即在 HTTP 下加入 SSL/TLS 层作为安全基础。其中 TLS 的前身是 SSL，目前广泛使用的是 TLS 1.2。
TLS性能调优
TLS 被普遍认为会使服务变慢，主要是早期 CPU 还很慢，只有少数站点买得起加密服务。但是今天计算能力不再是 TLS 的瓶颈。2010年，Google 默认情况下对其电子邮件服务上启用了加密，之后他们表示 SSL/TLS 不再花费昂贵的计算成本：
1 | 在我们的前端服务上，SSL/TLS 计算只占 CPU 负载的不到 1%，每个连接只占不到 10KB 的内存，以及不到 2% 的网络开销。 |
1. 延迟和连接管理
网络通讯的速度由两个主要因素决定：带宽和延迟。
- 带宽：用来衡量在单位时间内有多少数据可发送
- 延迟：描述一个消息从一端发送到另一端接收所需的时间
其中，带宽是次要因素，因为通常你可以随时购买更多带宽；而延迟则是无法避免的，因为它是在数据通过网络连接传输时被强加的限制。
延迟对 TLS 影响特别大，因为它有自己精心设计的握手，在连接初始化的时候额外增加了两个往返。
1.1 TCP优化
每个 TCP 连接都有一个称为 拥塞窗口 的速度极限，这个窗口最初时较小，在可靠性能保证的情况下随时间增长。这种机制被称为 慢启动。
因此，对于所有的 TCP 连接，启动速度很慢，对于 TLS 连接情况则更糟糕，因为 TLS 握手协议消耗了宝贵的初始连接字节（当拥塞窗口较小时）。如果拥塞窗口足够大，那么慢启动不会有额外的延迟。但是，如果较长的握手协议超过了拥塞窗口的大小，发送方必须将它拆分为两块，先发送一块，等待确认（一个往返），增加拥塞窗口，然后再发送剩下的部分。
1.1.1 拥塞窗口调优
启动速度限制被称为 初始拥塞窗口。RFC6928 建议初始拥塞窗口设置为10个网络段（约15KB）。早期的建议是使用2-4个网络段起步。
在旧版本的Linux平台上，可以改变路由的初始拥塞窗口：
1 | # ip route | while read p; do ip route change $p initcwnd 10; done |
1.1.2 防止空闲时慢启动
慢启动可以作用于一段时间内没有任何流量的连接上，降低其速度，并且速度下降地非常快。 在 Linux 上，可以在连接空闲时禁用慢启动：
1 | # sysctl -w net.ipv4.tcp_slow_start_after_idle=0 |
可以通过将该设置添加到 /etc/sysctl.conf 配置使其永久生效。
1.2 长连接
大部分情况下 TLS 性能影响集中在每一个连接的开始握手阶段。一个重要的优化技术是在连接数允许的情况下尽可能保持每个连接不断开。
现在的趋势是使用事件驱动的 WEB 服务器，通过使用固定的线程池（甚至单个线程）处理所有通讯，从而减少每个连接的成本以及被攻击的可能性。
长连接的缺点是在最后一个 HTTP 连接完成之后，服务器在关闭连接之前会等待一定时间，虽然一个连接不会消耗太多的资源，但是降低了服务器的总体伸缩性。长连接适用于客户端突发大量请求的场景。
1 | 当配置较大的长连接超时时间时，限制并发连接数以免服务器超负荷是至关重要的。通过测试调整服务器，使其运行在容量限制内。如果 TLS 是由 OpenSSL 处理的，请确保服务器正确设置 SSL_MODE_RELEASE_BUFFERS 标识。 |
1.3 HTTP/2.0
HTTP/2.0 是 二进制协议，具备 多路复用 和 头部压缩 等特性，可以提升性能。
1.4 CDN
使用 CDN 可以实现世界级的性能，它利用地理上分散的服务器提供边缘缓存和流量优化。
当用户离你的服务器越远，访问网络就越慢，在这种情况下连接建立是一个很大的限制因素。为了服务器尽可能靠近最终用户，CDN 经营着大量的地理分布的服务器，它可以提供两种降低延迟的方式，即边缘缓存和连接管理。
1.4.1 边缘缓存
由于 CDN 服务器贴近用户，可以将你的文件提供给用户，就像你的服务器真的在那里一样。
1.4.2 连接管理
如果你的内容是动态的、用户特定的，那么久无法通过 CDN 缓存数据。但是，一个不错的 CDN 即使没有任何缓存，也能通过连接管理提供帮助，那就是它可以通过长时间保持的长连接消除大部分建立连接的成本。
建立连接期间大部分的时间都花在等待上面。为了尽量较少等待，CDN 通过自己的基础设置将流量路由到距离目的地最近的一个点。因为是 CDN 自己完全可控的服务器，它可以内部保持长连接很长一段时间。
当使用 CDN 时，用户连接到最近的 CDN 节点，这只有很短的距离，TLS 握手的网络延迟也很短；而 CDN 与服务器之间可以直接复用已有的远距离长连接。这意味着与 CDN 快速初始 TLS 握手后，用户与服务器就建立了有效连接。
2. TLS协议优化
在连接管理之后我们可以专注于 TLS 的性能特征，具备对 TLS 协议进行安全和速度调优的知识。
2.1 密钥交换
使用 TLS 最大的成本除了延迟以外，就是用于安全参数协商的 CPU 密集型加密操作。这部分通讯称为密钥交换（key exchange）。密钥交换的 CPU 消耗很大程度上取决于服务器选择的私钥算法、私钥长度和密钥交换算法。
密钥长度
破解密钥的难度取决于密钥的长度，密钥越长越安全。但较长的密钥同时也意味着需要花费更多时间进行加密和解密。密钥算法
目前有两种密钥算法可用：RSA 和 ECDSA。当前 RSA密钥算法推荐最小长度2048位（112位加密强度），将来更多会部署3072位（128位加密强度）。ECDSA在性能和安全性上要优于 RSA，256位的 ECDSA （128位加密强度）提供和 3072位的 RSA 一样的安全性，却有更好地性能。密钥交换
目前有两种可用的密钥交换算法：DHE 和 ECDHE。其中 DHE 太慢不推荐使用。 密钥交换算法的性能取决于配置的协商参数长度。对于 DHE，常用的1024和2048位，分别提供80和112位安全等级。对于 ECDHE，安全和性能取决于一种称为 曲线 的东西。secp256r1提供128位安全等级。
你在实践中不能随意组合密钥钥和密钥交换算法，但可以使用由协议指定的组合。
2.2 证书
一次完整的 TLS 握手期间，服务器会把它的证书链发送给客户端验证。证书链的长度和正确性对握手的性能有很大影响。
使用尽可能少的证书
证书链里的每个证书都会增大握手数据包，证书链中包含太多证书有可能导致 TCP 初始拥塞窗口溢出。只包含必需的证书
证书链里包含非必需证书是个常见错误，每个这样的证书会给握手协议额外增加1-2KB。提供完整的证书链
服务器必须提供一个被根证书信任的完整证书链。使用椭圆曲线证书链
因为 ECDSA 私钥长度使用更少的位，所以 ECDSA 证书会更小。避免同一张证书绑定过多域名
每增加一个域名都会增加证书的大小，对于大量域名来说会有明显的影响。
2.3 吊销检查
虽然证书吊销状态在不断变化，并且用户代理对证书吊销的行为差异很大，但是作为服务器，要做的就是尽可能快地传递吊销信息。
使用 OCSP
信息的证书 OCSP 被设计用于提供实时查询，允许用户代理只请求访问网站的吊销信息，查询简短而快速（一个HTTP请求）。相比之下 CRL 是一个包含大量被吊销证书的列表。使用具有快速且可靠的 OCSP 响应程序的 CA
不同 CA 之间的 OCSP 响应程序性能不同，在你向 CA 提交之前先检查他们的历史 OCSP 响应程序。 另一个选择 CA 的标准是它更新 OCSP 响应程序的速度。部署 OCSP stapling
OCSP stapling 是一种允许在 TLS 握手中包含吊销信息（整个OCSP响应）的协议功能。启用之后，通过给予用户代理进行吊销检查的全部信息以带来更好地性能，可以省去用户代理通过独立的连接获取 CA 的 OCSP 响应程序来查询吊销信息。
2.4 协议兼容
如果你的服务器与一些新版本协议的特性（例如TLS 1.2）不兼容，浏览器可能需要通过与服务器进行多次尝试，才能协商一个加密的连接。确保良好的 TLS 性能的最好方式是升级最新的 TLS 协议栈以支持较新的协议版本和扩展。
2.5 硬件加速
随着 CPU 速度的不断提高，基于软件的 TLS 实现在普通 CPU 上已经运行得足够快，无需专门的加密硬件就能处理大量的 HTTPS 请求。但安装加速卡或许能够提升速度。
HTTP缓存的应用，不仅仅是max-age
相信不管是做前端开发还是后端开发的同学，或多或少在开发过程中接触过缓存的概念。最简单的例子就是前端对于静态资源–即css、js、图片等文件资源进行缓存。但是大部分同学知道的可能就是设置
Cache-Control: max-age=xxx来设置资源的过期时间，然而缓存的运用在互联网中可谓是无处不在，一个好的缓存方案可以大大提升服务的性能，而一个不好的缓存方案可能会导致网站的可用性降低。所以今天我们就来聊聊HTTP协议中的缓存。
首先HTTP协议中主要涉及缓存的Header就是Cache-Control和Expires，目前阶段来说Expires已经渐渐被淘汰了，所以我们主要讲讲Cache-Control。
Cache-Control并不是只有指定max-age过期时间这么一种使用方式，事实上这只是Cache-Control最基础的用法，我们来看看Cache-Control有哪些可以设置的值
- private、public和no-cache用来指定客户端和代理缓存的可缓存性
- max-age和s-maxage用来指定客户端和代理缓存的缓存时间
- must-revalidate和proxy-revalidate用来指定缓存过期后是否必须验证才能使用
- no-store用来表明任何地方都不应该缓存内容
- 其他一些不常用的设置
首先大家必须要弄清楚的一点是，缓存不仅仅只有浏览器可以缓存，互联网中存在着各式各样的代理缓存。HTTP仅仅是一个应用层的协议，在数据传输的过程中逃不开各种中继的设备，而本身HTTP是明文传输的，所以每个中继设备都可以解析HTTP数据包中的内容，所以如果某个中继设备想，他就可以成为一个代理缓存（想想曾经的某些运行商做的事）。当然HTTP的代理缓存更多还是服务假设者自己做的，但是本质上是一个意思。
那么相对于大家都知道的客户端缓存，代理缓存有什么好处呢？最明显的优势就是：客户端缓存是一对一的，但是代理缓存是一对多的。
从这张图中我们可以看到，对于同一个源服务器可以存在不同的代理（有些CDN就近获取资源就有用到缓存的知识）。如果这些代理都开启来缓存功能，那么用户一在第一次访问数据的时候，代理通过源服务器获取资源返回给用户，并同时缓存来这个请求，这时候用户二再次来请求的时候，就不需要经过源服务器，直接从代理缓存读取就可以来。
所以对于耗时操作而且数据修改不频繁的数据，开启代理缓存对于性能的提升是非常明显的，哪怕你每次缓存的时间只有5秒，对于并发量很高请求带来的性能提升也是不可估量的。
当然这个操作源服务器通过自己设置缓存也可以实现，但是代理缓存的好处是，如果你的代理离用户足够近，那么减少的延时也是非常明显的。比如如果你的服务器在美国纽约，如果你不在国内设置一个代理缓存，那么所有数据都要跨国半个地球再绕回来，而有代理缓存的情况就不一样来。
那么说回来，怎么控制代理缓存的使用？还是靠HTTP协议，在HTTP协议的发展历史中，已经有非常多的实践让协议进行修改和发展，所以目前的缓存方案可以说已经比较完善了。一般来说，代理缓存服务器都会对最新的HTTP协议的标准进行实现，并且适当兼容老得标准，一般不会出现一些魔改实现。所以只要你对HTTP协议的缓存方案充分了解，那么你就可以很好得使用代理服务器的缓存了。
最主要的你需要知道：
- 如何控制代理服务是否缓存或者缓存多少时间
- 代理缓存时候可以提供过期缓存的内容
- 如何进行缓存验证
知道这些之后，配合一个好用的代理缓存，相信能对你的服务带来很大的性能提升。
最后，HTTP协议是所有WEB相关开发的同学都必须要牢牢掌握的基础，仅仅知道POST、GET、Content-Type并不算理解HTTP协议，HTTP协议中还有非常多好玩又好用的内容等着大家去发掘。
Sublime Text 3 -- There are no packages available for installation
错误现象
Sublime Text 3 在安装Package Control的时候会出现类似如下错误：
开启debug时，console里会出现如下提示：
1 | Package Control: Found previously exported CA bundle at /Users/.../Library/Application Support/Sublime Text 3/Packages/User/oscrypto-ca-bundle.crt (272085 bytes) |
特别是用了代理的时候。
解决办法
很多Google中找到的办法都不能解决，可以尝试以下的粗暴办法:
- 清空 /Users/…/Library/Application Support/Sublime Text 3/Packages/User/oscrypto-ca-bundle.crt
- 将console中提示有SSL问题的域名根证书加入到oscrypto-ca-bundle.crt即可
以packagecontrol.io为例，
可以通过GeoTrust官网根证书清单（https://www.geotrust.com/resources/root-certificates/）找到GeoTrust Global CA的公钥(https://www.geotrust.com/resources/root_certificates/certificates/GeoTrust_Global_CA.pem)
channel_v3.json里涉及的相关公钥
GeoTrust Global CA
相关域名
packagecontrol.io
sublimerge.com
1 | -----BEGIN CERTIFICATE----- |
via： https://www.geotrust.com/resources/root_certificates/certificates/GeoTrust_Global_CA.pem
DigiCert High Assurance EV Root CA
相关域名
codeload.github.com
bitbucket.org
github.com
s3.amazonaws.com
1 | -----BEGIN CERTIFICATE----- |
via: https://ev-root.chain-demos.digicert.com/info/index.html
DST Root CA X3
相关域名:
packages.monokai.pro
downloads.sourceforge.net
sublime.wbond.net
1 | -----BEGIN CERTIFICATE----- |
via: https://letsencrypt.org/certificates/
Certum Trusted Network CA
相关域名：
serwer1784570.home.pl
1 | -----BEGIN CERTIFICATE----- |
via: https://www.certum.eu/en/cert_expertise_root_certificates/#CTNCA
MWeb for Mac 2.2.4 [CR]
MWeb 是一款Mac上专业的Markdown写作、记笔记、静态博客生成软件，是一站式的 Markdown 编辑和静态网站生成解决方案，支持大量 Markdown 扩展语法，很不错！
[MWeb 在 Mac App Store上售价人民币98元]
MWeb for Mac 2.2.4 介绍
「MWeb 获得少数派 2015 年度 Mac App」(http://sspai.com/topic/best-apps-2015/)
“ MWeb 是一站式的 Markdown 编辑和静态网站生成解决方案 - Mac玩儿法（www.waerfa.com）”
“ MWeb 是一款性价比很高的 Markdown 编辑器，它所能做的事绝对让你物有所值。 - 少数派（sspai.com）”
mac下nodejs更新到最新版本
第一步：使用npm安装n模块
n模块是专门用来管理nodejs版本的
1 | sudo npm install -g n |
提示 : 如果不使用sudo作为前缀，很可能出现权限访问异常导致安装失败
第二步：升级nodejs
升级nodejs是有两种方法：
第一种是升级到最新版本
1 | sudo n latest |
第二种是升级到稳定版本
1 | sudo n stable |
提示 : 建议是稳定版本
更多n模块管理请搜索【nodejs n模块使用说明】
权限相关的异常：
1 | npm ERR! Darwin 16.4.0 |
提示 : 解决方案是在命令前加sudo
File qpress-1.1-isatty-include.patch of Package qpress
From: Andreas Stieger andreas.stieger@gmx.de
Date: 2013-01-28 19:18:21 +0000
Subject: [PATCH] fix compiler warning about isatty()
Upstream: sent to lar@quicklz.com
Fix compiler error
qpress.cpp: In function ‘int main(int, char**)’:
qpress.cpp:1039:39: error: ‘isatty’ was not declared in this scope
1 | --- a/qpress.cpp 2010-09-23 20:09:26.000000000 +0100 |