What a May Day

发表于2018-06-02由daniel

周四晚上跟生日的父母吃过晚饭后，傻乎乎的带着小梦梦在孩子王逛，一点没有意识到已经是五月的最后一天。有时候，记录的习惯更多的就是提醒自己，时间的昼夜不舍。

这个月有意识的接触了挺多人，对于鄙人这种社交贫瘠的人来说，这个月花在这方面的时间算是奢侈的了。有老友也有新朋友。一次跟新朋友印象深刻的夜谈。已经很久没有跟新认识的人如此没有负担的沟通和交流了。对了，上一次有意思的聊天也是去年的这个时候。初夏，真是一个神奇的时节，一切都开始要变得明亮而耀眼。

五月在做和要做的事情越来越多，一种此情无计可消除，才下眉头，却上心头之感。一部分算是甜蜜的负担，而立之年，一些事情逐渐跟自己是否准备好已经没有必然关系，而是直接去解决它就对了。一部分是多过去时光的辜负，亡羊补牢，希望犹未晚矣。前天看韩老师的5X兴趣社区，看到李伟龙一个视频的幕后花絮，对话挺走心的：时间只会让你老去，其他什么都不会带来；只有你想改变的时候，你才能改变。

神奇的五月，居然达成了跑渣的第一次5公里（一个都不好意思提的配速）。从去年4月份参加跑团开始跑步，到现在已经一年多了，跑步成绩上没有任何提升，也是我预料之中的。对于这件事，我其实想得很明白：我一点都不喜欢运动，但是要支撑我的情怀和要做的事情，我必须要有这个练习和准备。显然，如果保持当前的做事的节奏，也许一周一次的跑步很快就无法支撑自己在做的事情，但是只要保持这件事情的惯性，我相信这股力量不会让自己失望。

这个月最喜欢的书是吴军老师的《智能时代》。因为一直在订阅吴军老师在得到的专栏，因此书中的很多内容其实都在专栏中听过了（如此说来，维护专栏及时高产如母猪，也是需要有存货当备份的?）。有两点体会最深：

人类文明发展是一个不短加速的过程，每一次加速都会让已有产业与新结束结合形成形成新的产业，赶上这个浪潮的会以数量级的优势领先，赶不上或者不愿拥抱变革的则会被无情的淘汰。
大数据和AI是当前最有可能成为下一个时代的蒸汽机和电。超越时代是困难的，但是从思维方式上则是可以刻意练习大数据和AI思维的。对于程序员而言，这尤为重要——有很大可能性，这决定了当前的你是成为为工业时代的码农，还是智能时代的工程师。

六月会迎来自己在两个月前设定的一个deadline, 从目前看来，不容乐观。可能当时在设定这个目标的时候，其实内心的真实独白就已经是法乎其中则得其下，法乎其上则得其中。但是，总的来说，过去的两个月无论是还在发生还是已经发生的事，多少带来了一丝丝改变。

期待六月，不负好时光。

本站开启支持 QUIC 的方法与配置

发表于2018-03-16由daniel

在越来越讲究用户体验的今天，网络带宽的提高已经很难有显著的页面加载改善，而低延迟的优化往往能够起到意想不到的效果。在《TLS1.3/QUIC 是怎样做到 0-RTT 的》中我们分析了TLS1.3和QUIC在低延迟方面的原理和低延迟优势。在从源代码编译 nginx docker 镜像开启 TLS 1.3中我们已经把玩了TLS1.3，没有理由不把玩一下QUIC，对吧？

起初以为，在普及程度上，QUIC因为主要是Google主导，会曲高和寡。但是，查了一下，发现腾讯早在2017年就在生产环境应用了QUIC：让互联网更快的协议，QUIC在腾讯的实践及性能优化. 结果显示：

灰度实验的效果也非常明显，其中 quic 请求的首字节时间 (rspStart) 比 http2 平均减少 326ms, 性能提升约 25%; 这主要得益于 quic 的 0RTT 和 1RTT 握手时间，能够更早的发出请求。

此外 quic 请求发出的时间 (reqStart) 比 h2 平均减少 250ms; 另外 quic 请求页面加载完成的时间 (loadEnd) 平均减少 2s，由于整体页面比较复杂, 很多其它的资源加载阻塞，导致整体加载完成的时间比较长约 9s，性能提升比例约 22%。

既然大厂都已经发车，我司也就可以考虑跟进了。稳妥起见，决定先在自己的博客开启QUIC，然后再逐步在线上业务进行推广。

方案概览

方案非常简单：不支持QUIC的浏览器依旧通过nginx tcp 443访问；支持QUIC的浏览器通过caddy udp 443访问。

由于nginx近期没有支持QUIC的计划, 作为一名gopher, 因此这里选择caddy作为QUIC的反向代理。后面会介绍caddy的具体安装和配置方法。

对于支持QUIC的浏览器来说，第一次访问支持QUIC的网站时，会有一次服务发现的过程。服务发现的流程在QUIC Discovery
有详细介绍。概括来说，主要有以下几步：

通过TLS/TCP访问网站，浏览器检查网站返回的http header中是否包含alt-svc字段。
如果响应中含有头部：alt-svc: 'quic=":443"; ma=2592000; v="39"'，则表明该网站的UDP 443端口支持QUIC协议，且支持的版本号是draft v39; max-age为2592000秒。
然后，浏览器会发起QUIC连接，在该连接建立前，http 请求依然通过TLS/TCP发送，一旦QUIC连接建立完成，后续请求则通过QUIC发送。
当QUIC连接不可用时，浏览器会采取5min, 10min的间隔检查QUIC连接是否可以恢复。如果无法恢复，则自动回落到TLS/TCP。

这里有一个比较坑的地方：对于同一个域名，TLS/TCP和QUIC必须使用相同的端口号才能成功开启QUIC。没有什么特殊的原因，提案里面就是这么写的。具体的讨论可以参见Why MUST a server use the same port for HTTP/QUIC?

从上面QUIC的发现过程可以看出，要在网站开启QUIC，主要涉及两个动作：

配置nginx, 添加alt-svc头部。
安装和配置QUIC反向代理服务。

配置nginx, 添加`alt-svc`头部

一行指令搞定：

add_header alt-svc 'quic=":443"; ma=2592000; v="39"';

1 2	add_header alt-svc 'quic=":443"; ma=2592000; v="39"';

安装QUIC反向代理服务器caddy

上面我们提到对于同一个域名，TLS/TCP和QUIC必须使用相同的端口号才能成功开启QUIC。然而，caddy服务器的QUIC特性无法单独开启，必须与TLS一起开启，悲剧的是TLS想要使用的TCP 443端口已经被nginx占用了?

场面虽然有点尴尬，但是我们有docker：将caddy安装到docker中，然后只把本地的UDP 443端口映射到容器中即可。

于是我们创建了一个docker-caddy项目。Dockerfile 10行内搞定：

FROM ubuntu:16.04

LABEL maintainer="liudanking@gmail.com"

RUN apt-get update

RUN set -x  \
    &amp;&amp; apt-get install curl -y \
    &amp;&amp; curl https://getcaddy.com | bash -s personal &amp;&amp; which caddy

FROM ubuntu:16.04

LABEL maintainer="liudanking@gmail.com"

RUN apt-get update

RUN set -x \

&& apt-get install curl -y \

&& curl https://getcaddy.com | bash -s personal && which caddy

caddy 服务配置文件/conf/blog.conf:

https://YOUR_DOMAIN

tls YOUR_CERT_KEY_DIR/chained.pem YOUR_CERT_KEY_DIR/domain.key

proxy / http://VPS_PRIVATE_IP:81/ {

header_upstream Host YOUR_DOMAIN
header_upstream X-Real-IP {remote}
header_upstream X-Forwarded-For {remote}
header_upstream X-Forwarded-Proto {scheme}

}

log /conf/blog.log

https://YOUR_DOMAIN

tls YOUR_CERT_KEY_DIR/chained.pem YOUR_CERT_KEY_DIR/domain.key

proxy / http://VPS_PRIVATE_IP:81/ {

header_upstream Host YOUR_DOMAIN

header_upstream X-Real-IP {remote}

header_upstream X-Forwarded-For {remote}

header_upstream X-Forwarded-Proto {scheme}

}

log /conf/blog.log

启动docker:

docker run -d --name caddy-blog -p 443:443/udp -v YOUR_CERT_KEY_DIR: YOUR_CERT_KEY_DIR -v  /conf:/conf liudanking/docker-caddy caddy -quic -conf /conf/blog.conf

1 2	docker run -d --name caddy-blog -p 443:443/udp -v YOUR_CERT_KEY_DIR: YOUR_CERT_KEY_DIR -v /conf:/conf liudanking/docker-caddy caddy -quic -conf /conf/blog.conf

开启Chrome浏览器QUIC特性

在chrome://flags/中找到Experimental QUIC protocol, 设置为Enabled. 重启浏览器生效。

测试QUIC开启状态

重新访问本站https://liudanking.com, 然后在浏览器中打开：chrome://net-internals/#quic。如果你看到了QUIC sessins，则开启成功：

当然，你也可以给Chrome安装一个HTTP/2 and SPDY indicator(An indicator button for HTTP/2, SPDY and QUIC support by each website) 更加直观的观察网站对http/2, QUIC的支持情况。

深入理解 Golang HTTP Timeout

发表于2016-12-14由daniel

深入理解 Golang HTTP Timeout

背景

前段时间，线上服务器因为部分微服务提供的 HTTP API 响应慢，而我们没有用正确的姿势来处理 HTTP 超时（当然，还有少量 RPC 超时）, 同时我们也没有服务降级策略和容灾机制，导致服务相继挂掉?。服务降级和容灾需要一段时间的架构改造，但是以正确的姿势使用 HTTP 超时确是马上可以习得的。

超时的本质

所有的 Timeout 都构建于 Golang 提供的 Set[Read|Write]Deadline 原语之上。

服务器超时

server timeout

ReadTimout 包括了TCP 消耗的时间，可以一定程度预防慢客户端和意外断开的客户端占用文件描述符
对于 https请求，ReadTimeout 包括了 TLS 握手的时间；WriteTimeout 包括了 TLS握手、读取 Header 的时间（虚线部分）, 而 http 请求只包括读取 body 和写 response 的时间。

此外，http.ListenAndServe, http.ListenAndServeTLS and http.Serve 等方法都没有设置超时，且无法设置超时。因此不适合直接用来提供公网服务。正确的姿势是：

package main

import (
    "net/http"
    "time"
)

func main() {
    server := &amp;http.Server{
        Addr:         ":8081",
        ReadTimeout:  3 * time.Second,
        WriteTimeout: 5 * time.Second,
    }

    http.HandleFunc("/hi", func(w http.ResponseWriter, r *http.Request) {
        w.Write([]byte("hi"))
    })

    server.ListenAndServe()
}

package main

import (

"net/http"

"time"

)

func main() {

server := &http.Server{

Addr: ":8081",

ReadTimeout: 3 * time.Second,

WriteTimeout: 5 * time.Second,

}

http.HandleFunc("/hi", func(w http.ResponseWriter, r *http.Request) {

w.Write([]byte("hi"))

})

server.ListenAndServe()

}

客户端超时

client timeout

http.Client 会自动跟随重定向（301, 302）, 重定向时间也会记入 http.Client.Timeout, 这点一定要注意。

取消一个 http request 有两种方式：

Request.Cancel
Context (Golang >= 1.7.0)

后一种因为可以传递 parent context, 因此可以做级联 cancel, 效果更佳。代码示例：

ctx, cancel := context.WithCancel(context.TODO())  // or parant context
timer := time.AfterFunc(5*time.Second, func() {  
    cancel()
})

req, err := http.NewRequest("GET", "http://httpbin.org/range/2048?duration=8&amp;chunk_size=256", nil)  
if err != nil {  
    log.Fatal(err)
}
req = req.WithContext(ctx)

ctx, cancel := context.WithCancel(context.TODO()) // or parant context

timer := time.AfterFunc(5*time.Second, func() {

cancel()

})

req, err := http.NewRequest("GET", "http://httpbin.org/range/2048?duration=8&chunk_size=256", nil)

if err != nil {

log.Fatal(err)

}

req = req.WithContext(ctx)

行思錄 | Travel Coder

Arch, Coding, Life

分类目录归档：SiteLog

What a May Day

本站开启支持 QUIC 的方法与配置

方案概览

配置nginx, 添加`alt-svc`头部

安装QUIC反向代理服务器caddy

开启Chrome浏览器QUIC特性

测试QUIC开启状态

深入理解 Golang HTTP Timeout

深入理解 Golang HTTP Timeout

背景

超时的本质

服务器超时

客户端超时

Credits

方案概览

配置nginx, 添加alt-svc头部

安装QUIC反向代理服务器caddy

开启Chrome浏览器QUIC特性

测试QUIC开启状态

深入理解 Golang HTTP Timeout

背景

超时的本质

服务器超时

客户端超时

Credits

配置nginx, 添加`alt-svc`头部