Udp

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 前言 本文将从功能特性上对比与TCP协议的差别。KCP有大量的思想借鉴了TCP的思想，最终得到的设计方案也与QUIC协议有很多的类同之处，很值得学习和研究。 特性对比 黄色表示新加的功能或者有较大的优化 绿色表示较小的优化 打赏萌叔

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1. 前言 KCP协议是一种快速可靠传输ARQ(Automatic Repeat-reQuest)协议，能以比TCP浪费10%-20%的带宽的代价，换取平均延迟降低 30%-40%，且最大延迟降低三倍的传输效果。它跟QUIC协议一样也是基于UDP协议的实现。KCP从TCP协议中借鉴了大量的思路，是理解TCP/IP协议栈的非常好的资料。 补充说明下，无论是QUIC还是KCP只有在弱网络条件下，相比TCP才有优势。 KCP协议在网络分层模型的位置 +-----------------+ | SESSION | +-----------------+ | KCP(ARQ) | +-----------------+ | FEC(OPTIONAL) | +-----------------+ | CRYPTO(OPTIONAL)| +-----------------+ | UDP(PACKET) | +-----------------+ | IP | +-----------------+ | LINK | +-----------------+ | PHY | +-----------------+ KCP的设计者有意识的把KCP依赖的网络通讯给解耦了 纯算法实现，并不负责底层协议（如UDP）的收发，需要使用者自己定义下层数据包的发送方式，以 callback的方式提供给 KCP。 如果读者阅读 skywind3000/kcp 源码，可能会发现如下代码 test.cpp // 创建模拟网络：丢包率10%，Rtt 60ms~125ms vnet = new LatencySimulator(10, 60, 125); 测试和验证是不需要再真实网络上进行。 skywind3000/kcp 只是设计了最初的协议, 包括 非延迟ACK 快速重传（TCP协议也有） 非退让流控(拥塞控制，和TCP实现类同) xtaci/kcp-go 在此基础上，又增加了 加密机制 FEC(Forward Error Correction)前向纠错 PS: skywind3000和xtaci其实是大学同学 ...

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1. 引言 今天有朋友问萌叔，consul能否在大规模生产环境下进行应用。场景是总计大约10w+台机器，分为3 ~ 4个机房，单个机房最多3w万+机器。这个问题大的，可把萌叔吓了跳，部门里面consul集群的规模也就是1k+, 还分好几个机房。 不过他的问题确实也让我十分好奇，consul是否有能力支撑这么规模，我决定针对每个可能性能瓶颈进行定量分析 2. 分析 在进行分析前，我们来看看可能遇到瓶颈有哪些？ 下图是consul在多DC情况下的体系架构图 2.1 明确一些概念 consul agent分2种模式server模式和client模式。在每个机房consul server(以下简称为server)会部署3 ~ 5台, 其余的consul节点都是consul client(以下简称为server)。 server的数量不宜过多，否则选主的速度会变慢 数据(包括kv数据，service信息，node信息)都是分机房存储的，由所在机房的server负责。如果需要请求其它机房的数据，则server会将请求转发到对应的机房。 比如dc1的某个应用app1想要获取dc2中key “hello"对应的值 过程如下 app1 --> client --> server(dc1) --> server(dc2) 如果读者仔细观察会发现,consul中，很多api都是可以加上dc参数的 consul kv get hello -datacenter dc2 每个dc的所有server构成一个raft集群，client不参与选主。注意上图的leader和follower标识。 单个机房内部consul节点之间有gossip(端口8301) 机房与机房之间 server节点之间有gossip(端口8302) 2.2 可能的瓶颈 2.2.1 client对server的RPC请求 client使用server的TCP/8300端口发起RPC请求, 管理service、kv都要通过这个端口，它们之间是长连接。 1个机房如果有3w+机器，则client和server至少要建立3w+长连接。 不过萌叔观察了一下，3w+长连接是相对均匀的分布在多个server上的，也就是说如果你有6台consul server, 那么每个server最多处理5k个长连接。还是可以接收的。 对于server的处理能力我简单压测了一下。大约是15k qps Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz 4核CPU 8G内存 ...