低延迟与用户体验杂谈

发表于2018-02-27由daniel

最近在做系统设计梳理的时候，明显感觉到「低延迟」已经成为被提及越来越频繁、考量权重越来越大的因素。并且，越是靠用户近的系统，对延迟越敏感，对用户体验影响越大，对低延迟要求越高。

HTTP/2如今（2018.02）已经逐渐普及，其设计的第一目标就是降低延迟。主要采用了两个手段来解决：

TCP连接复用。连接复用减少了TCP每次握手带来的延迟，同时避免了每次新建TCP连接的窗口慢启动带来的数据吞吐开启延迟。
使用数据分帧解决队头阻塞问题。当然，这个问题HTTP/2解决得不彻底，具体可以参见《当我们在谈论HTTP队头阻塞时，我们在谈论什么？》了解细节。

HTTP/2毕竟只能解决应用层的低延迟问题。如果要继续降级延迟，就需要下潜到传输层。因此，Google的QUIC和TLS 1.3应运而生。QUIC目前主要是Google主导，除去其自家的服务，如Google搜索首页，G+等，支持的网站还非常少。TLS 1.3则由标准化组织加持，目前在最新的OpenSSL、nginx已经支持。TLS 1.3能够做到新连接3RTT，恢复连接2RTT（TLS 1.2分别是4RTT, 3RTT；而2RTT已经与http的RTT持平！），的确非常吸引人。

回顾WEB技术过去十几年的发展，很多的特性引入和改进都是基于降低延迟。有些是技术层面的，比如上面提到的HTTP/2的低延迟设计、DNS查询缓存、HTTP1.1并发多个TCP连接请求资源、雪碧图等；有些是用户体验层面的，比如异步加载/预加载js资源、优先加载影响首屏渲染的CSS资源、避免使用大表布局、图片渐变加载、过渡动画等。

而这些年技术层面的发展其实都是受物理定律限制的。祭出程序员延迟心经Latency Numbers Every Programmer Should Know:

Latency Comparison Numbers
--------------------------
L1 cache reference                           0.5 ns
Branch mispredict                            5   ns
L2 cache reference                           7   ns                      14x L1 cache
Mutex lock/unlock                           25   ns
Main memory reference                      100   ns                      20x L2 cache, 200x L1 cache
Compress 1K bytes with Zippy             3,000   ns        3 us
Send 1K bytes over 1 Gbps network       10,000   ns       10 us
Read 4K randomly from SSD*             150,000   ns      150 us          ~1GB/sec SSD
Read 1 MB sequentially from memory     250,000   ns      250 us
Round trip within same datacenter      500,000   ns      500 us
Read 1 MB sequentially from SSD*     1,000,000   ns    1,000 us    1 ms  ~1GB/sec SSD, 4X memory
Disk seek                           10,000,000   ns   10,000 us   10 ms  20x datacenter roundtrip
Read 1 MB sequentially from disk    20,000,000   ns   20,000 us   20 ms  80x memory, 20X SSD
Send packet CA-&gt;Netherlands-&gt;CA    150,000,000   ns  150,000 us  150 ms

Notes
-----
1 ns = 10^-9 seconds
1 us = 10^-6 seconds = 1,000 ns
1 ms = 10^-3 seconds = 1,000 us = 1,000,000 ns

Credit
------
By Jeff Dean:               http://research.google.com/people/jeff/
Originally by Peter Norvig: http://norvig.com/21-days.html#answers

Contributions
-------------
Some updates from:       https://gist.github.com/2843375
'Humanized' comparison:  https://gist.github.com/2843375
Visual comparison chart: http://i.imgur.com/k0t1e.png
Animated presentation:   http://prezi.com/pdkvgys-r0y6/latency-numbers-for-programmers-web-development/latency.txt

Latency Comparison Numbers

--------------------------

L1 cache reference 0.5 ns

Branch mispredict 5 ns

L2 cache reference 7 ns 14x L1 cache

Mutex lock/unlock 25 ns

Main memory reference 100 ns 20x L2 cache, 200x L1 cache

Compress 1K bytes with Zippy 3,000 ns 3 us

Send 1K bytes over 1 Gbps network 10,000 ns 10 us

Read 4K randomly from SSD* 150,000 ns 150 us ~1GB/sec SSD

Read 1 MB sequentially from memory 250,000 ns 250 us

Round trip within same datacenter 500,000 ns 500 us

Read 1 MB sequentially from SSD* 1,000,000 ns 1,000 us 1 ms ~1GB/sec SSD, 4X memory

Disk seek 10,000,000 ns 10,000 us 10 ms 20x datacenter roundtrip

Read 1 MB sequentially from disk 20,000,000 ns 20,000 us 20 ms 80x memory, 20X SSD

Send packet CA->Netherlands->CA 150,000,000 ns 150,000 us 150 ms

Notes

-----

1 ns = 10^-9 seconds

1 us = 10^-6 seconds = 1,000 ns

1 ms = 10^-3 seconds = 1,000 us = 1,000,000 ns

Credit

------

By Jeff Dean: http://research.google.com/people/jeff/

Originally by Peter Norvig: http://norvig.com/21-days.html#answers

Contributions

-------------

Some updates from: https://gist.github.com/2843375

'Humanized' comparison: https://gist.github.com/2843375

Visual comparison chart: http://i.imgur.com/k0t1e.png

Animated presentation: http://prezi.com/pdkvgys-r0y6/latency-numbers-for-programmers-web-development/latency.txt

软件工程师无论是做什么职位和方向，心里都应该对此有B树。

有了这些当前人类所认识的物理极限，才能做到在「在边界内做事情」(这句话不是我说的，第一次看到这句话是吴军老师的《硅谷来信》)。

举个例子，当前人类认知范围内最快的速度是光速，这是一个上限，而广泛使用的光纤通信速度大概是光速的2/3。那么，要想优化上海到加州的网络延迟，无论你如何优化线缆布设以及质量，RTT都不可能低于127ms. 因此，如你所见，这些年虽然新架设了不少新的跨太平洋光缆，但是最优网络延迟没有什么太大变化，反倒是这些光缆带来的扩容让网络拥塞得到了缓解，让我们感觉出口网络「好像」更快了。

那么在光速这个物理边界的限制下，我们要如何降低延迟呢？显然，固定的两点之间的网络延迟是无法突破该边界的（这里不讨论空间扭曲力场?‍♀️）。但是，很多时候，我们要解决的问题是「让用户感觉延迟低」就可以了。

在这个思想下，CDN应运而生。将内容分发到距离用户近的网络节点来降低用户访问延迟。这个idea非常简单，甚至简陋，但是非常有效，并且廉价。

顺着这个思路下去，如果把算力分发到距离用户近的节点，那是不是也可以让用户觉得计算任务也变快了呢？在一定程度上，这是可以做到的。比如，我们使用了数十年运行于浏览器的javascript，以及我们的多IDC、多主架构方案，都有这方面的考量。近来流行的serverless、边缘计算其实也可以是认为是将算力部署到离用户尽可能近的物理位置或业务流程中。

有时候，技术参数指标的提升在短期内是难以低成本解决的。这个时候，尽量避免死磕参数，投入100%的精力去换取1%的性能提升。可以尝试从设计交互上给用户形成反应很快的体验，降低体感延迟。比如，1）耗时的任务后台化并给出进度条；2）区块处理的逻辑任务尝试修改成流处理，加速部分处理结果的输出，典型应用如以视频直播服务为代表的流媒体服务全力优化首屏播放延迟；批处理任务每处理完一个子任务就反馈结果等。

不仅软件系统的延迟影响着用户体验，硬件更是如此。现在人们普遍认为iPhone的用户体验是优于安卓的。因素有很多，那些复杂的系统参数普通用户未必搞得懂，但是很多用户却承认在滑动屏幕的时候iPhone比安卓更加「跟手指」，打开应用也「感觉更快」。「跟手指」这个体验跟苹果的软件+硬件的技术优化有关，目前安卓阵营也没有赶上。打开app快则是典型的交互优化：苹果打开app未必真的比安卓快，但是从点击app图标到显示story board的确非常快。无论苹果是否鸡贼，至少从这个层面看，它的确是非常了解延迟与用户体验之间的奥义的。至于苹果每次升级系统「故意」让老设备变卡……咳，咳，同学，你怎么有又抬杠呢?

喜欢汽车并且喜欢驾驶的朋友一定知道甚至深入研究过这几款车：马自达3/6/BRZ/86-宝马M2/M4-保时捷718/911。排名分先后，每一辆都是不同级别的驾驶者之车，也是很多玩车朋友的玩车升级路线。这些车都是「运动取向」，这是一个非常抽象的概念，普通消费者未必明白，但是你会发现他们的消费者大多会用「操控好」「响应快」来评价这些车。如果你是参数党，你会发现其实这些车在同级别中都不是最好的，但却是给人愉悦感最强的。

由物及人，当上司交给你一个任务的时候，有反馈好过无反馈，快反馈好过慢反馈。

总结

在节奏日益变快的今天，低延迟很多时候意味着良好的用户体验。而做到低延迟可以通过技术优化，也可以通过一些产品的交互方式和有选择的强调某些方面来让用户感觉很快。内容比较分散，但是都是顺着这根主线，希望你也有所思考和收获。

参考文献

Introducing Zero Round Trip Time Resumption (0-RTT)

当我们在谈论HTTP队头阻塞时，我们在谈论什么？

发表于2018-02-17由daniel

近来访问网站，明显感觉支持HTTP/2的网站越来越多了，对行业来说是个好趋势。HTTP/2的RFC虽然写的很厚，但是总结起来就做了以下几件事：

通过TCP多路复用降低延迟；
单个TCP连接上允许乱序request-response，解决队头堵塞问题；
实现层面上，大部分浏览器要求HTTP/2必须开启TLS，一定程度上解决数据安全问题。

其中，队头阻塞问题真的被解决了吗？

HTTP/1.1为什么会队头阻塞？

HTTP/1.1通过pipelining管道技术实现一次性发送多个请求，以期提高吞吐和性能，如上图中的序列2。然而，这种技术在接收响应时，要求必须按照发送请求的顺序返回。如果，第一个请求被堵塞了，则后面的请求即使处理完毕了，也需要等待，如上图中的序列3。

那么，HTTP/2是怎么解决这个问题的呢？那就是数据分帧：多个请求复用一个TCP连接，然后每个request-response都被拆分为若干个frame发送，这样即使一个请求被阻塞了，也不会影响其他请求，如上图序列4所示。问题完美解决了？准确说，只解决了一部分。

如果队头阻塞的粒度是http request这个级别，那么HTTP/2 over TCP的确解决了HTTP/1.1中的问题。但是，HTTP/2目前实现层面上都是基于TCP（没错，HTTP从来没有说过必须通过TCP实现，你可以用它其他传输协议实现哟），因此HTTP/2并没有解决数据传输层的对头(包)阻塞问题。

如上图所示，当第一个数据包发生丢包的时候，TCP协议会发生阻塞会进行数据重传。虽然TCP有快速重传等机制来缓解这个问题，但是只能是缓解。无法完全避免。

如何解决传输层的队头阻塞问题？

应用层无法解决传输层的问题。因此要完全解决队头阻塞问题，需要重新设计和实现传输层。目前而言，真正落地在应用的只看到Google的QUIC. 它的原理简单讲，就是使用UDP实现了一个可靠的多路复用传输层。我们知道UDP是面向数据报文的，数据包之间没有阻塞约束，QUIC就是充分利用这个特性解决传输层的队头阻塞问题的。当然，QUIC的协议实现有非常多的细节，而这方面Google确实做得非常好，如果你想进一步了解，可以关注他们的开源实现。

需要说明的是，当前的QUIC实现使用HPACK压缩http header, 受限于当前HPACK算法实现，在QUIC中的header帧也是受队头阻塞的。但是粒度已经降低到了帧这个级别，并且仅会在header帧中出现。实际使用中，出现的概率已经非常低了。

小结

HTTP/2 over TCP(我们接触最多的HTTP/2)解决了http request级别的队头阻塞问题
HTTP/2 over QUIC解决了传输层的队头阻塞问题（除去header frame），是我们理解的真正解决了该问题。

Golang反射的使用的正确姿势

发表于2016-04-22由daniel

Golang反射的使用的正确姿势

Go本身不支持模板，因此在以往需要使用模板的场景下往往就需要使用反射(reflect). 反射使用多了以后会容易上瘾，有些人甚至会形成一种莫名其妙的鄙视链。文人相轻，看来在需要动手指的领域历来如此:) 。反射有两个问题，在使用前需要三思：

大量的使用反射会损失一定性能
Clear is better than clever. Reflection is never clear.

Go的类型设计上有一些基本原则，理解这些基本原则会有助于你理解反射的本质：

变量包括 <type, value> 两部分。理解这一点你就知道为什么nil != nil了。
type包括 static type和concrete type. 简单来说 static type是你在编码是看见的类型，concrete type是runtime系统看见的类型。
类型断言能否成功，取决于变量的concrete type，而不是static type. 因此，一个 reader变量如果它的concrete type也实现了write方法的话，它也可以被类型断言为writer.
Go中的反射依靠interface{}作为桥梁，因此遵循原则3. 例如，反射包.Kind方法返回的是concrete type, 而不是static type.

Talk is cheap, show some code:

package main

import (
    "fmt"
    "reflect"
)

type T struct {
    A int
    B string
}

func main() {
    t := T{23, "skidoo"}
    tt := reflect.TypeOf(t)
    fmt.Printf("t type:%v\n", tt)
    ttp := reflect.TypeOf(&t)
    fmt.Printf("t type:%v\n", ttp)
    // 要设置t的值，需要传入t的地址，而不是t的拷贝。
    // reflect.ValueOf(&t)只是一个地址的值，不是settable, 通过.Elem()解引用获取t本身的reflect.Value
    s := reflect.ValueOf(&t).Elem()
    typeOfT := s.Type()
    for i := 0; i < s.NumField(); i++ {
        f := s.Field(i)
        fmt.Printf("%d: %s %s = %v\n", i,
            typeOfT.Field(i).Name, f.Type(), f.Interface())
    }
}

// 输出结果
// t type:main.T
// t type:*main.T
// 0: A int = 23
// 1: B string = skidoo

package main

import (

"fmt"

"reflect"

)

type T struct {

A int

B string

}

func main() {

t := T{23, "skidoo"}

tt := reflect.TypeOf(t)

fmt.Printf("t type:%v\n", tt)

ttp := reflect.TypeOf(&t)

fmt.Printf("t type:%v\n", ttp)

// 要设置t的值，需要传入t的地址，而不是t的拷贝。

// reflect.ValueOf(&t)只是一个地址的值，不是settable, 通过.Elem()解引用获取t本身的reflect.Value

s := reflect.ValueOf(&t).Elem()

typeOfT := s.Type()

for i := 0; i < s.NumField(); i++ {

f := s.Field(i)

fmt.Printf("%d: %s %s = %v\n", i,

typeOfT.Field(i).Name, f.Type(), f.Interface())

}

// 输出结果

// t type:main.T

// t type:*main.T

// 0: A int = 23

// 1: B string = skidoo

行思錄 | Travel Coder

Arch, Coding, Life

分类目录归档：Performance

低延迟与用户体验杂谈

总结

参考文献

当我们在谈论HTTP队头阻塞时，我们在谈论什么？

HTTP/1.1为什么会队头阻塞？

如何解决传输层的队头阻塞问题？

小结

Golang反射的使用的正确姿势

Golang反射的使用的正确姿势