除夕夜在看《开端》，看了前几集，就似乎了有一种熟悉的感觉。

从程序员的视角来看，《开端》就是发现了一个bug后定位根因并解决的过程。期间不断通过重现bug排除错误答案。

重现第六次时，试图对bug视而不见，选择逃避。后因bug重现概率过高被boss强行拉回继续定位。

重现第十次时，确认了bug根因来源于程序内部，并非由外部API或环境因素触发。

又经过六次重现，排除了两个嫌疑重大的逻辑。

重现到第十七次，算是定位到了直接原因。

又花了七次重现，才最终定位到根因并解决bug。

什么是无锁编程

无锁编程，即访问多线程共享数据时，不加/解锁。

这里的“锁”并不特指mutex，还包括使用semaphore、条件变量、信号等构造出的线程挂起等待机制。甚至我们不使用这些操作系统提供的支撑，也可以写出一个“有锁”的接口（在接口中死等某个变量，类似spinlock）。

无锁操作，通常被抽象成方法、接口。比如说针对一个无锁的队列，pop、push就是它的无锁操作。Herlihy & Shavit 给无锁操作给出一个简洁的定义：调用无锁操作时，无论如何都不应该产生任何阻塞。

无锁编程有如下几点优势：

• 加锁，等待锁涉及系统调用，影响性能。无锁编程没有这部分的性能损耗。
• 不会产生死锁

支撑无锁编程的系统算法与接口

RMW原子操作

这里先介绍RMW原子操作，因为这是支撑各类无锁编程算法的基础。

原子操作的想必大家都熟知，它是指不会被线程调度机制打断的操作；这种操作一旦开始，就一直运行到结束，中间不会有任何上下文切换。

RMW（read-modify-write）原子操作，是指把“读-改-写”三步指令合并到一个原子操作里。例如以下两例，实现数的原子性增减

• Win32中的_InterlockedIncrement
• IOS中的OSAtomicAdd32

RMW原子操作需要CPU的支撑，当前各类主流的CPU都提供了类似的功能。

CAS

CAS（compare-and-swap）是一种RMW原子操作，它将以下操作封装在一个原子操作里：

• 读变量*p
• 对比*p与变量old
• 如果*p与old不相同，不做任何操作。
• 如果*p与old相同，将另一变量new赋值给*p

伪代码如下：

1
2
3
4
5
6

function cas(p: pointer to int, old: int, new: int) is
    if *p ≠ old
        return false

    *p ← new
    return true

在实际应用中，CAS函数常常返回*p的当前值。例如，想用CAS构造一个栈的push和pop，伪代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

push(node):
    curr := head
    old := curr
    node->next = curr
    while (old != (curr = CAS(&head, curr, node))) {
        old = curr
        node->next = curr
    }

pop():
    curr := head
    old := curr
    next = curr->next
    while (old != (curr = CAS(&head, curr, next))) {
        old = curr
        next = curr->next
    }
    return curr

阅读全文

O-RAN

无线网络建设一直是运营商网络综合成本（TCO）的最主要部分，大致占比在60%～70%。大部分运营商刚经历4G网络的巨大投资，就将面对5G网络的投资建设压力。

5G网络不同于4G网络，5G网的速度快，带宽大，频段高。也就是说，5G网络的穿透性会远差于4G网络。因此，未来中国就需要成百万甚至上千万的5G小基站。同时，5G网络又是运营商必须投资的网络，大规模建网势必带来极大的耗资。在“无线互联网”流量收入增长放缓、语音收入下降的背景下，垂直行业是运营商必须进入的“蓝海市场”，拓展运营商的盈利能力将是5G网络的首要任务。垂直行业的新业务意味着更多样的业务类型、更复杂的网络管理，需要更高效的资源管理方案以及更灵活的网络架构以便于开展业务创新。

在这一大背景下，2018年，在西班牙巴塞罗那一年一度的世界移动大会（MWC）期间，中国移动，美国AT&T，德国电信，日本NTT DOCOMO，法国的O-RANge宣布了O-RAN联盟的诞生。由运营商主导的O-RAN产业联盟应运而生，提出了“开放”和“智能”两大核心愿景。

O-RAN推动以下四个方向的发展：

• 接口开放化：把基站内部原有的封闭接口的开放，在这个基础上，不同厂家的软件才有可能无缝配合，以此降低对单一厂商的依赖，鼓励创新，降低成本。
• 软件开源化：推动无线协议栈开源，共享代码，降低研发成本，让产业企业把更多精力聚焦在核心算法和差异化功能软件的研发上。
• 硬件白盒化：将传统基站的专用硬件用通用服务器代替，充分进行软硬件解耦，降低行业门槛，吸引更多中小企业参与竞争。
• 网络智能化：RAN开放和解耦之后，可以引人工智能，实现复杂组网环境下的高效运维管理，提升频谱资源的利用率，降低网络能耗。

O-RAN制定的标准，是3GPP标准的补充和增强。如图一所示：在3GPP定义的E1，F1，NG，Xn，X2的基础上，O-RAN进一步开放，定义了O1，O2，E2，A1，Open-FH等接口

为制定各类规范，O-RAN下设10个工作组（WG）：

• WG1 - Use Cases and Overall Architecture Workgroup
• WG2 - Non-real-time RIC and A1 Interface Workgroup
• WG3 - Near-Real-time RIC and E2 Interface Workgroup
• WG4 - Open Fronthaul Interfaces Workgroup
• WG5 - Open F1/W1/E1/X2/Xn Interface Workgroup
• WG6 - Cloudification and Orchestration Workgroup
• WG7 - White-box Hardware Workgroup
• WG8 - Stack Reference Design Workgroup
• WG9 - Open X-haul Transport Workgroup
• WG10 - OAM for O-RAN

OpenRAN

2016年，Facebook发起了一个叫做TIP（Telecom Infra Project，电信基础设施）的项目，下面包含了很多子项目，其中就有一个OpenRAN的项目计划。

2017年，全球运营商巨头沃达丰把自己研究的SDR RAN的成果奉献给了TIP，并创建OpenRAN工作组，旨在建立一个基于通用服务器，可软件定义技术的白盒化RAN解决方案。参与OpenRAN的运营商成员以欧美地区为主，中国的三大运营商都没有参与。项目由沃达丰和西班牙电信牵头，沃达丰负责全力推进。传统设备商中，除诺基亚积极参与之外，爱立信，华为和中兴都没有参与。此外新晋设备商三星对此也非常激进。此外，希望夹缝生存，在通信市场分得一杯羹的大量欧美新兴的中小设备商的参与非常积极，他们已经在全球开始部署OpenRAN商用网络，并开始组建自己的生态系统。

O-RAN/OpenRAN比较

跟O-RAN联盟不同，OpenRAN工作组并没有对开放网络的内外部接口进行严格规范的定义，他们积极鼓励各运营商和设备商进行Open RAN网络的实际部署，并在外场进行互操作测试。

总体而言，O-RAN和OpenRAN这两个组织的参与成员虽然不尽相同，推进策略也各有侧重，但其目标和产品方案却大体一致，拥有非常广泛的共同语言。在2020年2月份，两者携起手来，共同在欧洲成立了开放测试和集成中心（OTIC），共享资源来进行Open RAN的研究和推进。OpenRAN组织与会使用和参考O-RAN制定的标准来推动开放式基站的部署。

O-RAN是侧重制定标准，而OpenRAN则侧重部署验证与产业推广。

引用

概念

上节中提到，Rust中，无Copy Trait的数据类型的函数传参，等效于所有权的转移。因此当函数退出时，接收所有权的变量作用域结束，数据就被销毁。那么，是否有办法让函数传参不发生所有权的转移？

有的！

Rust提供了被称为“引用”的机制。如下例：

1
2
3
4
5
6
7
8
9

fn main() {
    let s1 = String::from("hello");
    let len = calculate_length(&s1);
    println!("The length of '{}' is {}.", s1, len);
}

fn calculate_length(s: &String) -> usize {
    s.len()
}

以上程序可以被正常运行，变量s不会在离开自己的作用域时销毁其指向的数据，因为它并不拥有数据的所有权。

引用的常见编译错误

错误1

1
2
3
4
5
6
7
8

fn main() {
    let s = String::from("hello");
    append_string(&s);
} 

fn append_string(s: &String) {
    s.push_str(" world");
}

编译结果：

1
2
3
4
5
6
7
8
9
10

$ cargo build
   Compiling hello v0.1.0 (/home/spencer/share/my_code/rust_prj/hello)
error[E0596]: cannot borrow `*s` as mutable, as it is behind a `&` reference
  --> src/main.rs:14:5
   |
13 | fn append_string(s: &String) {
   |                     ------- help: consider changing this to be a mutable reference: `&mut String`
14 |     s.push_str(" world");
   |     ^ `s` is a `&` reference, so the data it refers to cannot be borrowed as mutable

解析：引用是默认是不可变的，修改引用变量指向的数据是被禁止的。

可变引用

概念

Rust允许我们使用mut将某个引用声明为“可变引用”

1
2
3
4
5
6
7
8
9

fn main() {
    let mut s = String::from("hello");
    append_string(&mut s);
    println!("{}", s);
}

fn append_string(some_string: &mut String) {
    some_string.push_str(", world");
}

以上程序可以被正常执行，append_string函数的入参类型被指定为&mut String，即可变引用的String类型。append_string中完成了对入参的修改。

Rust以数据访问安全著称。那么它是如何在支持可变引用的情况下，仍然可以避免数据的竞争的？大家可以通过以下编译错误的例子体会一下。

可变引用常见的编译错误

错误2

1
2
3
4
5
6

fn main() {
    let mut s = String::from("hello");
    let r1 = &mut s;
    let r2 = &mut s;
    println!("{}, {}", r1, r2);
}

编译结果 ：

1
2
3
4
5
6
7
8
9
10
11

   Compiling hello v0.1.0 (/home/spencer/share/my_code/rust_prj/hello)
error[E0499]: cannot borrow `s` as mutable more than once at a time
 --> src/main.rs:5:14
  |
4 |     let r1 = &mut s;
  |              ------ first mutable borrow occurs here
5 |     let r2 = &mut s;
  |              ^^^^^^ second mutable borrow occurs here
6 | 
7 |     println!("{}, {}", r1, r2);
  |                        -- first borrow later used here

解析：以上例子中，r1和r2都为s的可变引用，且在同一个作用域中。Rust编译不不允许这样的代码存在。因为r1和r2可以在同一个作用域操作同一份数据，会产生数据竞争。

当我们用大括号将r1的作用域加以限制之后，r1和r2的作用域不再重叠，就可以编译通过了。如下：

1
2
3
4
5
6
7

fn main() {
    let mut s = String::from("hello");
    {
        let r1 = &mut s;
    }
    let r2 = &mut s;
}

错误3

1
2
3
4
5
6
7

fn main() {
    let mut s = String::from("hello");
    let r1 = &mut s;
    s.push_str(" world");
    r1.push_str(" hello2");
    println!("{}", s);
}

编译结果 ：

1
2
3
4
5
6
7
8
9

error[E0499]: cannot borrow `s` as mutable more than once at a time
 --> src/main.rs:4:5
  |
3 |     let r1 = &mut s;
  |              ------ first mutable borrow occurs here
4 |     s.push_str(" world");
  |     ^ second mutable borrow occurs here
5 |     r1.push_str(" hello2");
  |     -- first borrow later used here

解析：与上一个错误类似，同样也出现了“second mutable borrow occurs here”的提示。而发生此错误的地方，是第4行使用原始变量s做了数据修改的操作。编译器将使用原始可变变量做的数据修改，视为另一种可变引用。于是，s和r1产生了数据竞争，编译失败。

更确切地说，在以下三个条件同时满足时，会产生数据竞争，发出编译错误：

• 两个或两个以上的pointer（包含所有者，可变引用）指向同一份数据。
• 其中至少一个可变引用指会向空间写入数据。
• 没有同步数据的访问机制。

引用的原则：

• 任何时刻，一个变量只能有
  • 一个可变引用，或者
  • 多个不可变引用
  • 以上两点不可同时存在
• 引用应该总是合法的

所有权

Rust所有权三原则

1. Each value in Rust has a variable that’s called its owner. （Rust中每一个变量都有一个所有者。）
2. There can only be one owner at a time.（在任一时刻，所有者有且仅有一个。）
3. When the owner goes out of scope, the value will be dropped.（当所有者离开其作用域后，它所拥有的数据会被释放。）

所有权相关编译错误

错误1

代码段1：

1
2
3

let s1 = String::from("hello");
let s2 = s1; 
println!("{}, world!", s1);

编译结果：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

   Compiling ownership v0.1.0 (file:///projects/ownership)
error[E0382]: borrow of moved value: `s1`
 --> src/main.rs:5:28
  |
2 |     let s1 = String::from("hello");
  |         -- move occurs because `s1` has type `String`, which does not implement the `Copy` trait
3 |     let s2 = s1;
  |              -- value moved here
4 | 
5 |     println!("{}, world!", s1);
  |                            ^^ value borrowed here after move

error: aborting due to previous error

For more information about this error, try `rustc --explain E0382`.
error: could not compile `ownership`

解析：String的所有权从s1转移到s2后，不能再使用s1访问数据。否则违反原则2。

然而，对于下面这段代码，似乎产生了与代码段1矛盾的编译结果。

代码段2：

1
2
3
4
5

fn main() {
    let u1:u32 = 20;
    let u2 = u1; 
    println!("{}, world!", u1);
}

如果按代码段1的逻辑，u2=u1时，数字20的所有权传移给u2，u1应该不能再被访问。然而这段代码可以被正确地编译，这是为什么呢？

原因是：针对u32类型的数据，rust赋予其Copy特性（trait）。凡是拥有Copy trait的数据类型，“=”都表示数据的复制而非传有权的转移。因此在u2=u1之后，u2和u1里，都保存有20这一整型数据。

以下数据类型有Copy trait：

• 所有整型：u32 u64等
• 布尔型
• 所有浮点型：f32 f64等
• 字符型：char
• 元组（Tuples）：如果组成元组的每个成员都有Copy trait，那么此元组也有Copy trait。

错误2

代码段3

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

fn main() {
    let x = 5;
    print_int(x);
    println!("{}", x);
    let s = String::from("hello");
    print_string(s);
    println!("{}", s);
}

fn print_string(some_string: String) {
    println!("{}", some_string);
}

fn print_int(some_integer: i32) {
    println!("{}", some_integer);
}

编译结果：

1
2
3
4
5
6
7
8
9
10
11
12
13

$ cargo build
   Compiling hello v0.1.0 (/home/spencer/share/my_code/rust_prj/hello)
error[E0382]: borrow of moved value: `s`
 --> src/main.rs:9:20
  |
7 |     let s = String::from("hello");
  |         - move occurs because `s` has type `String`, which does not implement the `Copy` trait
8 |     print_string(s);
  |                  - value moved here
9 |     println!("{}", s);
  |                    ^ value borrowed here after move

error: aborting due to previous error

解析：函数的传参赋值，视作与“=”有相同的作用。即：变量s被传入print_string函数后，它的所有仅传移给some_string，又因为原则三：“当所有者离开其作用域后，它所拥有的数据会被释放。”some_string所拥有的字符串数据，在离开print_string之后，即被释放。因此第9行的println!("{}", s);对s的访问编译失败。
而对整型数据的传参，则不存在类似的问题。因为整型数据有Copy trait，传参意味着数据的复制，而不是所有权的转移。因此第4行println!("{}", x);并没有编译失败。

TCP连接建立的条件

我们这里从TCP连接建立的前提入手。TCP连接建立的前提，是通信的双方都要知道本方和对方的发送和接收功能，都是正常的。也就是在TCP连接建立之前，有以下八个待确认项。

三次握手

第一次握手

客户端向服务端发送连接请求报文段。该报文段的头部中SYN=1，ACK=0，seq=x。
服务端接收到报文后，可以确认客户端的发送功能，服务端的接收功能，都是正常的。

第二次握手

服务端收到连接请求报文段后，如果同意连接，则会发送一个应答：SYN=1，ACK=1，seq=y，ack=x+1。
客户端接收到第二次握手报文后，可以确认服务端的发送功能，客户端的接收功能是正常的。不过，此时服务端并不知道自己的发送功能，客户端的接收功能是否正常。

第三次握手

当客户端收到连接同意的应答后，还要向服务端发送一个确认报文段，表示：服务端发来的连接同意应答已经成功收到。该报文段的头部为：ACK=1，seq=x+1，ack=y+1
此时，服务端就可以确认自己的发送功能，客户端的接收功能是正常的。

至此，八个确认项都确认完成。服务端和客户端就可以开始愉快地通信了。

Hello World

家里迎来了新成员。真是很可爱。但免不了的手忙脚乱，新手爸爸还不太会抱娃。我最近的睡觉时间提前到了21:30，进入养生模式。就是为了每晚给娃留出2小时哭闹哄睡的时间。

OneCmd

这个博客更新得少了，最近个人项目的重心转到另一个项目中。我估且把它称为OneCmd。工作上本来就忙，现在又多了个娃，我估了一下进度（每周投入2~6小时）。OneCmd估计一年后才能上线。随性吧，反正也是玩票。

工作

工作上，其实挺不如意的。项目进度紧，其实这倒不是最难的，难的是向兄弟部门和领导解释我们的工作量。为啥别人眼里的任务的工作量，和我们认为的任务的工作量，总是差距这么大。

平安

最后再回到孩子身上，当抱抱起柔软的它时，之前对它的种种抱负都消失不见了。唯独希望，你平安喜乐。

Linux提供了非常丰富的手段，供我们来评估一个进程的内存占用。top，/proc/[pid]/status，/proc/[pid]/statm等等。什么RSS，RES，VIRT，到底哪个才是真正的进程使用内存量？

有没有简单的手段直接就能知识一个进程的内存占用？很遗憾地说，没有。因为内存的使用，本来就不简单。

但是我们可以找到相对简单的方式。

进程的内存分布

我们要先从进程的内存分布说起。Linux下，一个进程的内存分布如下：

从低到高，分别包括：

1. 文本段，也叫代码段，是对象文件或内存中程序的一部分，其中包含可执行指令。通常代码段是共享的，对于经常执行的程序，只有一个副本需要存储在内存中，代码段是只读的，以防止程序以外修改指令。
2. 初始化的数据段，是程序的虚拟地址空间的一部分，它包含有程序员初始化的全局变量和静态变量，可以进一步划分为只读区域和读写区域。例如，C中的char=“hello world”的全局字符串，以及main(例如全局)之外的int debug=1这样的C语句。
3. 未初始化的数据段，通常称为bss段，这个段的数据在程序开始之前有内核初始化为0，包含所有初始化为0和没有显示初始化的全局变量和静态变量，
4. 堆，堆是动态内存分配通常发生的部分。堆是由程序员自己分配的（malloc kmalloc等）。堆区域由所有共享库和进程中动态加载的模块共享。
5. 栈，存放临时变量，以及每次调用函数时调用栈。每当调用一个函数时，返回到的地址和关于调用者环境的某些信息的地址，比如一些机器寄存器，就会被保存在栈中。然后，新调用的函数在栈上分配空间，用于自动和临时变量。

要评估一个进程的内存占用，就是要把以上几个段的内存占用一一加起来。

Linux环境下内存信息的几个来源

/proc/[pid]/status

此文件包含了有关内存使用情况的重要信息，以Vm为前缀。

• VmPeak / VmSize：最大/当前进程正在占用的内存总大小。听起来不错，但实际上，这并不是一个好的评估内存的数据的办法。因为它包含了 1）申请但实际上未使用的内存。（malloc一段地址空间，但不使用它） 2）共享库使用的代码段地址空间，会被多个进程的VmSize同时统计。即存在重复统计的问题。
• VmHWM / VmRss：最大时/当前应用程序正在使用的物理内存的大小。没有被交换到swap的内存。是评估进程内存使用量的重要依据。
• VmData：包含initialized data+bss+heap。通常不准确，原因是heap的大小不准确。系统常常出于优化性能的考虑，多申请栈空间。
• VmExe：代码段中不包含lib的部分，即进程可执行文件的部分
• VmLib： 代码段中lib的部分。

VmSize = VmRss + 申请但未使用的内存块

/proc/[pid]/smap

这个文件反应了运行时的进程的在内存中的完整分布。这是一张完整的清单。通过它可以看到对应进程所关联的所有的内存信息（包含共享的，和私有的）

smap示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

7fc4d49df000-7fc4d49e1000 rw-p 001eb000 08:01 2102913                    /lib/x86_64-linux-gnu/libc-2.27.so
Size:                  8 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Rss:                   0 kB
Pss:                   0 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:            0 kB
Anonymous:             0 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  8 kB
SwapPss:               8 kB
Locked:                0 kB
THPeligible:		0

几个关键字段：

• Rss：是进程的物理内存占用，包括进程本身和所有链接库，RSS = private + share
• Pss：链接库的共享内存平摊计算后的使用内存，（比如一个动态库有5个人引用，则将其代码段和共享内存除于5），PSS = private + share / share_num
• Shared_Clean：和其他进程共享的未改写页面
• Shared_Dirty：和其他进程共享的已改写页面
• Private_Clean：未改写的私有页面页面 
• Private_Dirty：已改写的私有页面页面

其中：
private = private_clean + private_dirty： 这个数据一般能够比较准确反映一个进程内部占用的内存，在内存优化的时候使用这个作为参考值比较合理，进程的物理内存占用就是smaps中所有的private的相加（链接的动态库的也要统计进去）。

总结

• /proc/[pid]/status中，VmSize 因包含重复统计和未实际使用的内存，存在夸大的情况。VmHWM / VmRss 是相对理想的内存评估依据。
• 想要得到确定的内存使用量，将/proc/[pid]/smap中的所有Private_Clean和Private_Dirty累加起来，是很好的解决方案。

昨晚和蚊子斗争了一晚上，斗争到睡不着。得出感悟，以下：

结论：打蚊子与找bug真是一模一样。

目标

用docker打包一个image，这个image的容器实现打包输出”hello docker”

打包过程

搜索基线

我们计划使用echo命令打印，echo命令基于bash。因此，我们先搜索看看是否有bash相关的image。

1
2
3
4
5
6

~$ sudo docker search bash
NAME                           DESCRIPTION                                     STARS               OFFICIAL            AUTOMATED
bash                           Bash is the GNU Project's Bourne Again SHell    232                 [OK]                
basho/riak-kv                  Docker image for running a minimal Riak KV c…   29                                      
...

可以看到官方的bash image。因此我们可以基于此image来打包生成我们自己的image。

Dockerfile编写

创建一个目录hello_docker，在下面创建子目录app，Dockerfile，和脚本hello.sh

1
2
3
4
5

spencer@ubuntu:~/my_docker/hello_docker$ tree .
.
├── app
├── Dockerfile
└── hello.sh

hello.sh中，就是我们的容器需要执行的指令。

1

echo "hello docker"

Dockerfile是此步的关键，其内容是：

1
2
3
4

FROM bash
WORKDIR /app
COPY hello.sh .
CMD [ "bash", "hello.sh" ]

解释：

• FROM: 表示当前image基于bash这个官方image来打包
• WORKDIR: 指定容器工作目录，此目录下的内容，才会被打包进容器
• COPY: 将脚本拷贝进工作目录。注意，此命令的第一个参数是基于宿主机上的当前路径的，也就是Dockerfile所在的目录的相对路径，第二个参数的是基于WORKDIR的相对路径（此例中是app目录）
• CMD: 指定了容器运行起来后，默认要执行的脚本

可以看出，Dockerfile中，除了CMD指令外，其它指令即是在告诉docker框架，如何一步一步地生成image。

打包生成容器

执行以下命令打包：

1

docker image build -t hello_docker .

打包完成后，验证一下image已生成

1
2
3

spencer@ubuntu:~$ docker image ls
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
hello_docker        latest              39dc2cd8ee2b        16 minutes ago      15.2MB

运行容器

1
2

spencer@ubuntu:~$ docker run hello_docker
hello docker

搞定！

Dockerfile是打包image的关键，此例中只用到了简单的几个。如果想进一步了解Dockerfile，请参考这里。