我上次假期烤了一个烤肉pizza，因为和面的时候出了点意外（水太多），肉没有预处理，而且选的鸡肉不是鸡胸肉，骨头太多。另一方面，烤箱温度和时间都没控制好，因此最后吃起来一般般。吸取了上次的经验，这次把过程给记录了下来，虽然和面仍失水准，并且最后的结果虽然有点焦，但吃起来还是不错的！

我把我的步骤大致说说。

天宇找了个好玩的2D纸娃娃系统，叫做charas.EX.

工具很不错，虽然有点儿简陋，不过想想已经十年历史了也挺正常的。charas.EX带了很多像素风格的素材，可以满足很多小游戏的需求。

看了一期BBC美食纪录片，我也顺便介绍一下广东的饮食文化。

广东料理（Cantonese Cuisine）是我们俗称的粤菜，也包括了在潮汕那一带的客家菜。有句话说“四条腿除了板凳，带翅膀的除了飞机，广东人都敢吃”，虽是高级黑，但广东的饮食的确很丰富，这是因为很久以前这边很缺乏食物，所以吃的东西比较广。

总流程图

接收流程

TCP接收到数据之后会写入到TCP本身的Buffer里，然后会拷贝到应用层（亦即我们的应用程序）的接收Buffer中。在满足以下条件时，TCP接收Buffer的数据会被写入到到应用层的接收Buffer并且recv()返回：

• TCP头部中的PSH被置为1
• TCP接收Buffer溢出
• 数据在TCP接收Buffer中存放的时间超过了0.5s

发送流程

应用层的发送Buffer把数据写入到TCP的Buffer中：
如果应用层的发送Buffer超过了TCP发送Buffer的大小，就会发生阻塞，直到把所有数据写入到TCP的Buffer中才会返回。

在TCP进行Nagle优化时，如果发送的Buffer太大并且满足了Nagle算法优化场合，TCP就会先发送部分数据，这时候对端就会出现我们平时所说的粘包或者残包，需要在业务上进行拼接和解析。

结语

这个系列到此结束了，主要讲述了TCP协议的一些比较底层的理论问题，也许大多数人甚至是从事网络通信（如写服务器）的程序员也不一定了解过，工作上也几乎很少用到。不过有必要建议还是花点时间了解一下，不一定要深究，但至少对得起自己的情怀和职业呀。。

参考书籍：《TCP/IP详解》

应用层的发包一般指调用系统的socket api的过程。

E2E数据发送与接收时序（流程）图

画一个流程图方便理解上一章的内容：

基本行为

（1） 发包的时机
每个ACK都有可能触发发包，是否发包取决于根据’(2)’中的公式所算结果是否大于零。

• RTT测量的ACK会启动发包。（这一条是错的）
• 重复ACK会启动发包。
• 紧跟在重复ACK后回复的第一个新的ACK会启动发包。
• 快速重传、超时重传也会启动发包。
  （2）发包的数量：
  发送端根据启动发包时刻的发送窗口、接收窗口、拥塞窗口大小来确定发包数量。计算公式如下：
  发包数量 = min(发送窗口大小, 接收窗口大小, 拥塞窗口大小) - 已发送未确认数据的字节数

基本行为

接收端的基本行为有：接收数据包、回复ACK，适当时将数据送往应用层缓冲区。

（1）一般情况下收到2个包回1个ACK，除非第二个数据包在200ms内没有收到（这种情况下所回复的ACK被成为Delayed-ACK, 200ms定时器则称为Delayed-ACK Timer）。
（2）如果出现丢包情况，对于后续收到的每一个数据包则重新回复ACK.
（3）重传的数据包收到之后，会和之前收到的所有数据包一起回复ACK.
（4）还有就是，满足以下任何一个条件时数据都会被送往应用层缓冲区：

• 应用程序通过recv()方法准备接收数据
• TCP头部中的PSH标识被置为1
• TCP接收Buffer溢出了
• 数据在TCP接收Buffer中存放的时间超过了500ms

TCP接收端处理流程图

Flatbuffers的编译器有个-c参数选项，这个选项需要一个个传入.fbs文件的路径，给维护带来很大的不便。昨晚改了下flatbuffers的编译器代码，把cpp代码生成器生成的部分变量名以及生成的cxx文件后缀改掉了，这样看起来违和感没那么强，符合Coeus的代码风格。本来也想把-c选项改成支持’‘通配符的，这样便可以肆无忌惮地给出一个目录让编译器自己去遍历.fbs文件。但回头一想这似乎不应该是编译器做的事情，所以就把这个想法搁掉了。于是写了个简单的python脚本(2.7.x)，用来维护fbs文件并且把生成的cxx文件输出到指定目录。

FlatBuffers提供的Schemas (又叫IDL, Interface Definition Language) 语法在于c-like, 无论对于C语言用户还是其它IDL用户来说都很容易掌握。