So how does syscall happens, actually? If you look up the definition of the write, you will see the following function signature:

In the Linux world, syscall in most case is the only way for userspace programs to interact with kernel, and utilize the full power that the Linux kernel offers.

In this series, we will take a deep dive into Linux system call, not theriotically, but practically. We will start from the very beginning, and gradually build up a full picture of Linux system call.

**Protocol Buffers(protobuf)**有两种序列化编码方式：二进制格式(wire format) 和 文本格式(text format)

其中wire format是protobuf的默认编码格式，可以高效地通过网络传输； text format是一种类似JSON的表示方式，可以方便地用于调试和手动编写/编辑消息。

这篇文章记录一下wire format的编码格式

最近组里的项目需要自己写一套消息序列化协议来代替protobuf， 所以顺便研究了一下protobuf的原理，以便在造轮子的时候借鉴一下其设计上的优雅之处。

首先介绍一下Protocol Buffers， 这是由Google开发的一种无关语言、无关平台、高可扩展性、轻量级的结构化数据序列化格式。 它使用一种模式定义语言来描述数据结构，可以通过protoc编译器将其编译成对应语言的代码。

Protocol Buffers数据格式在不同语言和平台间具有高度一致性， 生成的代码也具有相似的功能，因此其通常作为分布式组件和微服务之间数据通信的序列化协议。

TCP是面向连接的协议，因此在数据传输之前需要先建立连接状态，传输完成后需要断开连接。

在建立连接、数据传输和断开连接时TCP会发生一系列同步过程，TCP连接的状态也随之发生变化， 因此可以将TCP连接看作一个状态机模型。 事实上，TCP标准为TCP连接规定了若干种状态，并且随着各个过程发生转换。

TCP是一个有状态的，面向连接的协议，其在下层不可靠传输的基础上提供了一层抽象， 使连接双方可将TCP看作一个能够可靠传输数据的端到端通道， 保证接收方从TCP层收到的数据与发送方送往TCP层的数据的内容和顺序一致。

TCP 首部字段结构

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

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Acknowledgment Number                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       |     |  Control Bits   |                               |
|  Data | Rese|N|C|E|U|A|P|R|S|F|                               |
| Offset| rved|S|W|C|R|C|S|S|Y|I|            Window             |
|       |     | |R|E|G|K|H|T|N|N|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Checksum            |         Urgent Pointer        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options                    |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             data                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

CRC简介

CRC(Cyclic Redundancy Check, 循环冗余校验) 是在数字通信和数据存储领域常用的一种错误检测算法, 由于该算法硬件实现简单, 且容易进行数学分析, 尤其善于检测信道干扰所导致的误码, 因此得到了广泛应用。 CRC算法由W. Wesley Perterson于1961年发表。

前言

读完CS: APP第三章后，终于来到了期待已久的Bomb Lab环节，可能由于我拿到的是B&O提供的Self-Handout Version，加上之前有一点Re经验，所以难度没有现象中那么大，花了半个晚上就做完了。但是第一遍做的时候并没有仔细的一点一点读汇编，基本上是看个大概然后依靠直觉就得到答案了，这里再重新认真做一遍做个记录

前言

一开始看到这个lab的时候看到是对数据类型进行底层位操作，感觉还是挺简单的，毕竟规则都已经讲过了，但是实际做的时候发现还是有点难度的，最终花了两个晚上完成了这个lab，写一下总结