引用

概念

上节中提到，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，请参考这里。

近来成了一篇论文，发表于IHMSC 2018。把近来学习的神经网络知识应用到网络流量识别中。

论文主旨

这篇论文并没有高深的理论研究，可以说是一篇纯应用性质的论文。
把SDN与神经网络结合起来，去实现一个网络流量分类系统。
SDN与神经网络可以说是一对神仙CP。

SDN：

• 全局性的网络抽象，很方便地收集大量流量特征
• 在服务器端可以提供快速的算力支持
• 网络可编程

神经网络：

• 需要大量的数据以供训练
• 需要大算力

把这对神仙CP结合起来，SDN负责收集训练流量数据，用于训练神经网络。然后将实时流量数据，输入到训练好的神经网络中，即可得到实时的流量分类数据。

论文下载

下载链接

感恩

让我比较感恩的是，这个论文研究纯属兴趣，与公司的工作没有太大的关系。但主管仍然对我的研究给予了支持。在一个纯工程团队中，能让我有机会做算法的研究与应用。
更让我高兴的一点是：在论文发表了半年之后，这份研究的成果也反哺了公司中一个项目，应用到实际项目中，反哺了公司对我的投资。