网络编程 on codedump notes

KCP 1.4源码分析

Thu, 05 Nov 2020 22:08:40 +0800

概述 #

KCP是基于UDP协议之上的ARQ协议实现。TCP虽然使用的更广泛，但是在某些实时性要求更高的领域（如实时音视频、即时在线游戏等），会更倾向于使用基于UDP的可靠传输协议。

在项目的官网上，对KCP是这么介绍的：

KCP是一个快速可靠协议，能以比 TCP 浪费 10%-20% 的带宽的代价，换取平均延迟降低 30%-40%，且最大延迟降低三倍的传输效果。纯算法实现，并不负责底层协议（如UDP）的收发，需要使用者自己定义下层数据包的发送方式，以 callback的方式提供给 KCP。连时钟都需要外部传递进来，内部不会有任何一次系统调用。

UDP并不是一个可靠的传输协议，如果数据没有发送成功并不会自动重传，KCP基于UDP协议之上实现了自己的ARQ协议，所以在继续介绍KCP协议之前，先大体了解一下ARQ协议。

ARQ的两种模式 #

KCP在UDP之上，自己实现了可靠性的算法，即给UDP加上了诸如超时重传、流量控制等机制，这些都是为了保证ARQ协议的运作。

ARQ协议(Automatic Repeat-reQuest)，即自动重传请求，是传输层的错误纠正协议之一，它通过使用确认和超时两个机制，在不可靠的网络上实现可靠的信息传输。

ARQ的实现通常有如下两种模式。

停等ARQ协议（stop-and-wait） #

停等ARQ协议，意味着每个数据在发送出去之后，在没有收到对端的接收回复之前，将一直等待下去，而不会继续发送新的数据包。如果超时还未收到应答，就会自动重传数据包，以保证数据的可靠性。

下图是两种情况下停等协议的示意图：

stop-and-wait

上图：正常不出错情况下运行的停等协议，消息2必须在发送方收到了消息1的对端确认回复之后才能发送出去。
下图：出错情况下运行的停等协议，发送方发现消息1超时还未收到应答，就触发了针对消息1的重传机制。在这之前消息2都不会被发出去。

协议栈如何确认这个“超时时间”呢？答案是根据数据往返时间动态估算出来的RTO（Retransmission TimeOut，重传超时时间）时间来确认的。

连续ARQ协议（Continuous ARQ） #

可以看到，停等协议的机制是“一应一答”式的，对带宽的利用率不高，传输效率不高。

连续ARQ协议，可以一次性发送多个数据，而不必像停等协议那样需要等待上一个数据包的确认回复才能继续发送数据。

在使用连续ARQ协议的时候，接收方也并不会针对每一个收到的数据包进行确认应答，而只需应答确认最大的那个数据包，这时就认为在此之前的数据包都收到了。

这种模式称为“UNA（unacknowledge，即第一个未应答数据包的序列号，小于该序列号的数据包都已经确认被接收到）”模式，与之对应的是，停等协议是ACK模式。

然而，即便是可以一次发送多个数据包，也不意味着可以不受控制的发送数据，因为还要受到几种流量窗口的限制，这部分被称为“流量控制”。

拥塞窗口 #

拥塞窗口更多是对网络上经过的网络设备总体网络情况的一个预估。因为在真正发送数据时，并不清楚这时候的网络情况，因此启动时拥塞窗口会有一个初始值，然后根据以下几种算法进行动态的调整：

慢启动：在启动时让拥塞窗口缓慢扩张。
退半避让：在发生网络拥堵时让拥塞窗口大小减半。
快重传：在网络恢复时尽快的将数据发送出去。

滑动窗口 #

拥塞窗口是对外部网络情况的一种动态的检测，而滑动窗口则是进程本身接收缓冲区的控制，滑动窗口就是接收方用来通知发送方本方接收缓冲区大小的。由于一个网络进程分为协议层和应用层，如果协议层接收数据很快，但是应用层消费数据很慢，这个滑动窗口就会缩小，通过这种方式来通知对端放缓数据的发送，因为接收方已经忙不过来了。

KCP作为一个ARQ协议，内部就是要实现对以上这些机制的支持。

如果对TCP协议的实现有一些了解，可以看到上述的对端确认回复、超时重传、拥塞窗口、滑动窗口等概念，在TCP中就有，KCP自己实现的ARQ机制，与TCP对比起来有如下的不同点：

在TCP中，超时之后的RTO时间直接翻倍（即RTO2），而在KCP启用了快速模式之后，RTO的超时时间是1.5，避免RTO时间的快速增长。
TCP协议在丢包时会直接重传丢的那个包之后的所有数据包，KCP只会选择性的重传真正丢失的数据包。
TCP为了充分利用带宽，会延迟发送ACK应答对端，这样会导致计算出来的RTT时间过大，KCP的ACK是否延迟发送则可以调节。
KCP 正常模式同 TCP 一样使用公平退让法则，即发送窗口大小由：发送缓存大小、接收端剩余接收缓存大小、丢包退让及慢启动这四要素决定。但传送及时性要求很高的小数据时，可选择通过配置跳过后两步，仅用前两项来控制发送频率。

本文基于KCP 1.4版本对其实现做分析。

术语概念 #

在展开讨论之前，首先介绍相关的术语概念。

ARQ：Automatic Repeat-reQuest，自动重传请求协议。KCP就是其中一种ARQ协议的实现。
MTU：Maximum Transmission Unit，最大传输单元，链路层规定的每一帧最大长度，通常为1500字节。
MSS：Maximum Segment Size，最大分段大小。通常为MTU-协议头大小。
RTT：Round-Trip Time，数据往返时间，即发出消息到接收到对端消息应答之间的时间差。
RTO：Retransmission TimeOut，重传超时时间，根据收集到的RTT时间估算。
rwnd：Receive Window，接收窗口大小，接收端通过该数据通知发送端本方接收窗口大小。
cwnd：Congestion Window，拥塞窗口大小，影响发送方发送数据大小。
ack：acknowledge，接收端接收到一个数据包之后，通过应答该数据包序列号来通知发送端接收成功。
una：unacknowledge，即第一个未应答数据包的序列号，小于该序列号的数据包都已经确认被接收到。
ssthresh：Slow Start threshold，慢启动阈值，用于在发生拥塞的情况下控制窗口的增长速度。

数据结构 #

报文定义 #

每个KCP数据报文，其定义如下，注释中描述了每个字段的含义：

glog C++版本代码分析

Mon, 29 Jul 2019 11:43:56 +0800

本文基于glog CPP版本的0.4.0版本，对glog的实现机制做一些简单的分析记录。

概述 #

要记录一条日志，分为两个阶段：

首先生成日志。
然后将日志内容输出到相应的设备，如标准输出、文件等。

以下就分两部分展开对glog的分析。

日志的生成 #

一般有两种生成日志数据的方式：

类printf的方式，将需要输入的数据格式化。
类C++ stream流的方式，提供出来operator «操作符供输入数据。

前者的好处在于可以对输入的数据格式进行严格检查，不匹配的情况下编译器会进行告警。缺点则是不够灵活。后者的好处是灵活，除了用了进行一般的日志输入，还可以写出类似

CHECK_IF(某条件不成立) << 输出日志

的操作。

glog中选择了第二种方式。

首先来看glog对外暴露的用于日志输入的接口。其对应的宏是：

#define LOG(severity) COMPACT_GOOGLE_LOG_ ## severity.stream()

#define COMPACT_GOOGLE_LOG_INFO google::LogMessage( \
    __FILE__, __LINE__)
#define COMPACT_GOOGLE_LOG_WARNING google::LogMessage( \
    __FILE__, __LINE__, google::GLOG_WARNING)

从中可以看到glog中每一条日志，都对应一个LogMessage的类，然后将返回其中的stream()对象输入日志数据。

每个LogMessage内部有一个名为LogMessageData的成员，用于保存这些数据，其中比较重要的成员有以下几个：

char message_text_[LogMessage::kMaxLogMessageLen+1]; // 用户存储日志的固定长度数组，大小为30KB。
LogStream stream_; // 用于接收用户日志的C++stream，构造时传入上面的message_text_来构造，所以实际写数据会到message_text_中。
void (LogMessage::*send_method_)(); // 用户最终发送日志数据的函数指针。
timestamp_、tm_time_：保存日志时间相关的成员。

实际根据日志创建出一个LogMessage对象时，会根据不同类型的日志，传入不同的send_method函数指针，而每个不同的LogMessage构造时都会去调用其内部的Init函数完成LogMessageData的构造，Init函数主要做的事情有：

存储send_method函数指针。
获取当前的系统时间，存放到相应的成员中。

而LOG之类的宏，实际返回的就是LogMessageData的stream指针，待到一切的输入完毕，这一条日志对应的LogMessage就会被析构，其析构函数内又会调用成员函数Flush，这个函数最终完成将日志输出的操作：

void LogMessage::Flush() {
  // ...
  {
    MutexLock l(&log_mutex);
    (this->*(data_->send_method_))();
    ++num_messages_[static_cast<int>(data_->severity_)];
  }
  // ...
}

有了以上的准备，实际回头来看一个日志的输入

线上存储服务崩溃问题分析记录

Sat, 13 Apr 2019 12:04:59 +0800

注：本文为重新发布2017-06-17所写博客，以下为正文部分。

上周我们的存储服务在某个线上项目频繁出现崩溃，花了几天的时间来查找解决该问题。在这里，将这个过程做一下记录。

加入调试信息 #

由于问题在线上发生，较难重现，首先想到的是能不能加上更多的信息，在问题出现时提供更多的解决思路。

首先，我们的代码里，在捕获到进程退出的信号比如SIGABRT、SIGSEGV、SIGILL等信号时，会打印出主线程的堆栈，用于帮助我们发现问题。

但是在崩溃的几次情况中，打印出来的信息并不足以帮助我们解决问题，因为打印的崩溃堆栈只有主线程，猜测是不是在辅助线程中发生的异常，于是采取了两个策略：

ulimit命令打开线上一台服务器的coredump，当再次有崩溃发生时有core文件产生，能够帮助发现问题。
加入了一些代码，用于在崩溃的时候同时也打印出所有辅助线程的堆栈信息。

在做这两部分工作之后，再次发生崩溃的情况下，辅助线程的堆栈并无异常，core文件由于数据错乱也看不出来啥有用的信息来。

复现问题 #

由于第一步工作受挫，接下来我的思路就在考虑怎么能在开发环境下复现这个问题。

我们的存储服务在其他项目上已经上线了有一段时间了，但是并没有出现类似的问题。那么，出现问题的项目，与其他已经上线的服务有啥不同，这里也许是一个突破口。

经过咨询业务方，该业务的特点是：

单条数据大：有的数据可能有几KB，而之前的项目都只有几百字节。
读请求并发大，而其他业务是写请求远大于读请求。

由于我们的存储服务兼容memcached协议，出现问题时也是以memcached协议进行访问的，所以此时我的考虑是找一个memcached压测工具，模拟前面的数据和请求特点来做模拟压测。

最后选择的是twitter出品的工具twemperf，其特点是可以指定写入缓存的数据范围，同时还可以指定请求的频率。

有了这个工具，首先尝试了往存储中写入大量数据量分布在4KB~10KB的数据，此时没有发现服务有core的情况出现。然后，尝试构造大量的读请求，果然出现了core情况，重试了几次，都能稳定的重现问题了。

有了能稳定重现问题的办法，总算给问题的解决打开了一个口子。

首次尝试 #

此时，可以正式的在代码中查找问题的原因了。

来大概说明一下该存储服务的架构：

主线程负责接收客户端请求，并且进行解析。
如果是读请求，将分派给读请求处理线程，由这个线程与存储引擎库进行交互，查询数据。此时该线程数量配置为2。
存储引擎库负责存储落地到磁盘的数据，类似leveldb，只不过这部分是我们自己写的存储引擎。
在读线程从存储引擎中查询数据返回后，将把数据返回给主线程，由主线程负责应答客户端。

server

在这几步中，第1和第4步是在主线程中进行的，第2和第3步是在读存储引擎线程中进行的。在这个过程中，如果同一个客户端有多个读请求，那么只有按照这四步在处理完毕一个读请求之后，才会继续从该客户端中取出下一个请求进行处理。

在几次重现问题的过程中，发现出错的都是在第2步和第4步中，该请求客户端的数据结构某些成员出现了错乱，即要访问的指针地址已经无效了，导致的错误。

指针无效，一般来说有两种可能性：

被无效地址覆盖了这个指针。
指针已经被释放的情况下继续使用。

当时尝试把一些错误的指针地址打印出来，发现有几次都是是字符串“pcm*”的16进制表示，当时在想这个特殊的字符串到底是什么，百思不得其解的时候，一位曾经使用过mcperf工具的同事，想起来mcperf做压测时的key就是"mcp"开头的，而因为是小端方式，所以如果使用这个类型的字符串，去覆盖指针，那么就变成了"pcm"。我们很快验证了这个说法，mcperf确实是以这个为前缀来写入数据的。

此时，猜测问题的原因在于：当读存储引擎线程去访问存储引擎时，某些错误导致从存储引擎读出来的数据，将客户端请求数据写乱，从而导致了崩溃。

由于同时有两个读存储引擎的线程，猜测这里是不是因为多线程访问出了问题，导致的错误呢？

为了验证这个问题，最简单的办法就是将线程数量改成1，重新用mcperf试了几次，确实没有再次出现问题。此时已经是周五，我们缓了一口气，打算以此修改暂时上测试环境利用周末的时间观察一下情况。

柳暗花明 #

前面提到过，猜测问题出现的原因，是多线程访问存储引擎时将某个数据写错乱了，导致其中的指针无效。

clang和gcc 4.8有对应的编译参数，可以用来检测内存错误的写操作，即Address Sanitizer工具。为了兼容线上比较老的系统，之前我们的服务都是在gcc 4.1的环境下进行编译的，为了使用这个工具，首先需要折腾到满足gcc版本号大于4.8的系统上进行编译。

然而，在折腾编译并且运行后，同样使用mcperf的情况下，并不能看到有内存错误覆盖写的提示，我尝试了多次都没有看到。难道是工具没有起作用？

为了验证该工具的作用，我简单在出错代码的前面加入了一段肯定有问题的代码，比如：

char a[100] = {'0'};
a[100] = '1';

而在加入这段有问题的代码之后再次运行，就能看到编译器对这段代码的提示。可见，Address Sanitizer工具是起作用的。那么，前面的过程中没有看到问题，只能说明一个问题：并没有内存错误写的情况发生。

此时想到另一个可能，就是有没有可能是多线程在没有保护的情况下访问了某段数据导致的问题？

gcc同样也有类似的工具来检查这类错误，即Thread Sanitizer工具。然而，在给项目Makefile加入该编译参数后，程序一运行就退出了，根本看不出什么有用的信息来。

此时想到的另一个工具是valgrind。大多数时候，valgrind只是用来做内存泄露检测的，其实它也可以用来做线程数据竞争的检查，使用参数 –tool=helgrind 即可。使用valgrind之后，打印出来疑似有问题的代码如下：

valgrind

到了这里，猜测问题的原因就是由于多线程访问数据导致的错误。

因为有多个处理读请求数据的线程，首先猜测的是不是某些错误的处理，导致了可以在同一时间多个线程都操作该请求客户端的数据。但是通过review代码，发现这部分处理是没有问题的，另外在访问存储引擎查询数据时，入口处也确实进行了加锁的操作。

TCP协议笔记

Wed, 27 Feb 2019 21:01:43 +0800

概述 #

tcpip

应用层：通常也称为“七层”，这是大部分服务器工作的层次，如HTTP 服务器等，位于应用层上的信息分组成为报文（message）。识别不同应用层的信息是通过端口号，即不同的端口号提供不同的服务。
传输层：通常也称为“四层”，TCP、UDP协议工作在这一层，位于这一层的分组称为报文段（segment）。
网络层：通常也称为“三层”，负责将数据包（datagram）从一台主机移动到另一台主机。
接口层：通常也称为“二层”，链路层分组称为帧（frame）。

TCP协议格式 #

tcp-header

端口号：tcp使用端口号来标记目标和源端口，tcp头中并没有ip地址信息，根据前面的tcp/ip模型，ip地址这是三层做的事情。
序号（Sequence Number）：用于对tcp字节流进行编号，以解决网络包乱序问题。
确认号（Acknowledgement Number）：用于确认接收到的报文段序号，用来解决丢包问题。
窗口：用于通知对端接收窗口大小，用于解决流控问题。
TCP标志位，用于控制TCP协议状态机的，包括以下几个：
- ACK：只有这个标志位置位时，前面的确认号字段才有效。
- SYN：在连接建立时用来同步序号。当 SYN=1，ACK=0 时表示这是一个连接请求报文段。若对方同意建立连接，则响应报文中 SYN=1，ACK=1。
- FIN：用来释放一个连接，当 FIN=1 时，表示此报文段的发送方的数据已发送完毕，并要求释放连接。
- RST：重置连接，比如向一个不存在监听服务的端口发请求时，就会收到RST包。
TCP选项：这部分可选，不属于TCP头部必然存在的部分。
- MSS（Maximum Segment Size，最大报文长度）：MSS选项用于在TCP连接建立时，收发双方协商通信时每一个报文段所能承载的最大数据长度。为了达到最佳的传输效能，TCP协议在建立连接的时候通常要协商双方的MSS值，这个值TCP协议在实现的时候往往用MTU值代替（需要减去IP数据包包头的大小20Bytes和TCP数据段的包头20Bytes）所以一般MSS值1460。

TCP连接的建立和终止 #

连接建立 #

tcp-connect

以上图说明建立TCP连接的过程，其中左边的A为客户端，右边的B为服务器：

B调用listen系统命令，进入监听状态，等待客户端的连接。
A向B发送连接请求报文，其中TCP标志位里SYN=1，ACK=0，选择一个初始的序号x。
B收到请求报文，向 A 发送连接确认报文，SYN=1，ACK=1，确认号为 x+1，同时也选择一个初始的序号 y。
A 收到 B 的连接确认报文后，还要向 B 发出确认，确认号为 y+1，序号为 x+1。
B 收到 A 的确认后，连接建立。

以上就是TCP建立连接的三次握手过程，以上流程还需要补充的是：

对于建链接的3次握手，主要是要初始化Sequence Number 的初始值。通信的双方要互相通知对方自己的初始化的Sequence Number（缩写为ISN：Inital Sequence Number）——所以叫SYN，全称Synchronize Sequence Numbers。也就上图中的 x 和 y。这个号要作为以后的数据通信的序号，以保证应用层接收到的数据不会因为网络上的传输的问题而乱序（TCP会用这个序号来拼接数据）。
第三次握手是为了防止失效的连接请求到达服务器，让服务器错误打开连接。客户端发送的连接请求如果在网络中滞留，那么就会隔很长一段时间才能收到服务器端发回的连接确认。客户端等待一个超时重传时间之后，就会重新请求连接。但是这个滞留的连接请求最后还是会到达服务器，如果不进行三次握手，那么服务器就会打开两个连接。如果有第三次握手，客户端会忽略服务器之后发送的对滞留连接请求的连接确认，不进行第三次握手，因此就不会再次打开连接。

backlog参数与SYN Flood攻击 #

listen系统调用中，会传入一个backlog参数，man文档对其的解释是：

zeromq所谓的“无锁消息队列”

Sat, 09 Feb 2019 20:10:13 +0800

本文基于zeromq 4.3.0版本，分析其无锁消息队列的实现。

概述 #

zeromq这个网络库，有以下几个亮点：

从以往的面向TCP流的网络开发，变成了面向消息的开发。应用层关注的是什么类型的消息，库本身解决网络收发、断线重连等问题。
将这些消息的传输模式封装成几个模式，应用开发者只需要关注自己的业务符合什么模式，采用搭积木的方式就能构建起应用服务。
内部实现无锁消息队列用于对象间通信，类似actor模式。

基本架构 #

zeromq内部运行着多个io线程，每个io线程内部有以下两个核心组件：

poller：即针对epoll、select等事件轮询器的封装。
mailbox：负责接收消息的消息邮箱。

可以简单理解IO线程做的事情是：内部通过一个poller，监听着各种事件，其中包括针对IO线程的mailbox的消息，以及绑定在该IO线程上的IO对象的消息。

即这是一个per-thread-per-loop的线程设计，线程之间的通信通过消息邮箱来进行。

除了io线程之外，io对象也有mailbox，即如果想与某个IO对象通信也是通过该mailbox进行。由于消息邮箱是zeromq中的重要组成部分，下面将专门分析zeromq是如何实现的。

所有需要收发消息的对象都继承自object_t：

class object_t
{
public:
  object_t (zmq::ctx_t *ctx_, uint32_t tid_);
  void process_command (zmq::command_t &cmd_);
private:
  zmq::ctx_t *ctx;//  Context provides access to the global state.
  uint32_t tid;//  Thread ID of the thread the object belongs to.
  void send_command (command_t &cmd_);
}

而IO对象之间的命令通过command_t结构体来定义：

struct command_t
{
  //  Object to process the command.
  zmq::object_t *destination;

  enum type_t
  {
    ...
  } type;

  union {
    ...
  } args;
};

可以看到，zeromq实现对象间相互通信依赖于mailbox，本文重点在分析其无锁队列的实现上。

Libuv代码简单分析

Wed, 23 Jan 2019 08:43:49 +0800

本文基于libuv 1.x版本进行简单的分析。

数据结构 #

uv__io_t #

uv__io_t用来表示一个IO事件。

其成员包括：

成员	说明
uv__io_cb cb	IO事件被触发的回调函数
void* pending_queue[2]	pending队列
void* watcher_queue[2]	watcher队列
unsigned int pevents	pending的事件mask，等待下一次被添加到事件中
unsigned int events	当前的事件mask
int fd	事件fd

queue #

libuv的queue实现比较奇葩，一个queue里面的元素会有两个指针，一个指向队列前一个成员，一个指向队列下一个成员，在这里不做阐述，看到类似：

void* watcher_queue[2]

这样子定义了有两个void*指针的数组知道这是一个队列就好了。

uv_timer_t #

定义定时器的结构体，libuv中使用最小堆来维护定时器。

一般而言，都是首先从这个最小堆数据结构中获得距离当前最近的定时器，然后拿到它的超时时间，以该超时时间做为下一次loop事件循环的时间，某些情况下会无视这个值，比如存在idle handler的情况下，此时会以0做为超时时间。

uv_handle_t及其子类 #

uv_handle_t是libuv中所有handler的基类，libuv中实现继承的手段也比较奇葩：

类成员定义放在宏里。
继承自某个基类的子类按照继承顺序依次放它前面基类的宏。

比如uv_tcp_t继承自uv_stream_t，而后者又继承自uv_handle_t，三者的定义如下：

struct uv_handle_s {
  UV_HANDLE_FIELDS
};

struct uv_stream_s {
  UV_HANDLE_FIELDS
  UV_STREAM_FIELDS
};

struct uv_tcp_s {
  UV_HANDLE_FIELDS
  UV_STREAM_FIELDS
  UV_TCP_PRIVATE_FIELDS
};

代码中可以看到：