免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
楼主: wlmqgzm

[C++] ASIO,无锁,高并发,高可靠, 统一,网络架构,抗DOS,低端4核心服务器CPU 每秒87万QPS ECHO [复制链接]

论坛徽章:
9
程序设计版块每日发帖之星
日期:2015-10-18 06:20:00程序设计版块每日发帖之星
日期:2015-11-01 06:20:00程序设计版块每日发帖之星
日期:2015-11-02 06:20:00每日论坛发贴之星
日期:2015-11-02 06:20:00程序设计版块每日发帖之星
日期:2015-11-03 06:20:00程序设计版块每日发帖之星
日期:2015-11-04 06:20:00程序设计版块每日发帖之星
日期:2015-11-06 06:20:00数据库技术版块每周发帖之星
日期:2015-12-02 15:02:47数据库技术版块每日发帖之星
日期:2015-12-08 06:20:00
发表于 2015-10-24 11:33 |显示全部楼层
本帖最后由 wlmqgzm 于 2015-10-27 09:25 编辑

回复 48# cokeboL

其实说白了, 就是程序员要尽力做到逻辑上不丢包.  

为了说清楚这个问题, 还是讲个虚拟的故事吧:  

BOSS让网络专家开发了一个状态采集服务器A,  BOSS安排三个程序员:菜鸟程序员, 资深程序员, 大神程序员 分别完成三个子项目B,C,D子项目向状态采集服务器报告状态的客户端代码, 要求: 先完成一个简单的联调程序, 包括连接, 发送一个测试数据包, 拆除连接, 退出.  代码要高效, 出错可以重发, 不出错不重发, 不浪费网络资源, 但是要保证采集服务器收到数据. 因为服务器端压力很大, 为了节约服务器资源, 服务器只负责收, 对客户端无回馈信息.  这是个典型的单向服务器-客户端模型, 也是最简单的通信模型.

三个程序员拿到项目,  开始动手写起了代码.

菜鸟程序员很快完成子项目B的代码, 代码中, 他设置了错误检测语句, 确认发包的代码返回出错则重发, 不出错不重发, 发完之后, 为了提高效率, 他使用了硬关闭hard_close, 然后程序退出.  但只过了一会,菜鸟程序员埋的地雷爆炸了,他的数据包没有被发送到采集服务器A, 采集服务器上什么信息都没有.  

资深程序员仔细的编写了子项目C的联调代码, 设置了错误检测语句, 对各种情况都充分的考虑, 确认出错则重发, 不出错不重发, 发完之后, 为了安全可靠, 他使用了保守的软关闭soft_close, 然后程序退出. 采集服务器A收到了测试数据包, 一切似乎都很好很正常,  但是资深程序员为自己的未来之路埋设了地雷, 这个地雷什么时候爆炸不知道, 运气好的话, 也许永远都不会有人踩上去.  

大神程序员同样认真的编写了子项目D的代码, 同样设置了错误检测, 发送代码也是返回出错则重发, 不出错不重发, 发完之后, 他使用shutdown send, (TCP/IP将EOF标志附加在发送缓存队列的最后), 然后, 进入接收状态, 期望能够在收端收到些什么东西, 1毫秒之后, 收端没有收到任何有效字节的东西, 只返回了错误检测EOF, 大神确认此期间没有错误, close,   然后退出了程序.  否则,启动重连重发.  大神程序员不仅仅依赖错误检测, 他更依赖正确信号, 他没有给自己埋地雷.

hard_close清除了TCP/IP发送缓冲区的数据, 缓冲区中未发出的数据包丢失在黑洞之中, 了无踪迹. 代码B的数据根本就没有发出去.
soft_close之后数据还在发送, 如果网络中断或者拥塞, 很偶然的情况下, 数据包同样丢失了, 但是代码C却对此一无所知, 未能弥补网络错误.
代码D收到了服务器端发过来的EOF标志, 就说明数据已经被完整的接收了, 这个是正确标志, 说明任务真正完成了.
代码D完整的流程如下:
客户端发完数据, shutdown send,  (TCP/IP将EOF标志附加在发送缓存队列的最后), 服务器端从缓冲区中收数据, 收到最后一个字节以后, 给出错误, 检测到EOF标志(文件结束标志), 服务器端shutdown send/both或者soft close/hard close,  TCP/IP都将EOF标志附加在发送缓存队列的最后, 然后该标志被传送到客户端, 客户端收到此标志, 就确认客户端发送的每一个字节都已经被服务器端接收,于是close,  数据已经被完整发送到服务器A了.

论坛徽章:
9
程序设计版块每日发帖之星
日期:2015-10-18 06:20:00程序设计版块每日发帖之星
日期:2015-11-01 06:20:00程序设计版块每日发帖之星
日期:2015-11-02 06:20:00每日论坛发贴之星
日期:2015-11-02 06:20:00程序设计版块每日发帖之星
日期:2015-11-03 06:20:00程序设计版块每日发帖之星
日期:2015-11-04 06:20:00程序设计版块每日发帖之星
日期:2015-11-06 06:20:00数据库技术版块每周发帖之星
日期:2015-12-02 15:02:47数据库技术版块每日发帖之星
日期:2015-12-08 06:20:00
发表于 2015-10-24 12:04 |显示全部楼层
本帖最后由 wlmqgzm 于 2015-10-24 12:05 编辑

已经完成DOS模块, DOS模块的效率非常高, 对代码的影响很小, 使用了最快的hash表, 后续还要测试一段时间, 看能否继续改进.

目前性能32万QPS ECHO.  比前面有所提高, 主要的改进是:
1)对收发数据的错误处理的判断代码, 进行了整合, 合并, 减少了判断.
2)对acceptor单独一个线程, 这样后台管理也是一个独立线程, 2个线程之间必须要交换数据, 使用了目前最高效率的队列, 号称wait_free的spsc lock-free queue, 做到了零等待, 双并发, 因此, 总体效率比较高. 目前使用了三组io_service, 1组单线程做后台管理, 1组单线程做acceptor, 1组多线程做收发数据.

guo@guo-desktop:~$ ab -n 10000000 -c 100 -k htt p://127.0.0.1:1971/jjjjjjjjjjjjj
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd,
Licensed to The Apache Software Foundation,

Benchmarking 127.0.0.1 (be patient)
Completed 1000000 requests
Completed 2000000 requests
Completed 3000000 requests
Completed 4000000 requests
Completed 5000000 requests
Completed 6000000 requests
Completed 7000000 requests
Completed 8000000 requests
Completed 9000000 requests
Completed 10000000 requests
Finished 10000000 requests


Server Software:        
Server Hostname:        127.0.0.1
Server Port:            1971

Document Path:          /jjjjjjjjjjjjj
Document Length:        0 bytes

Concurrency Level:      100
Time taken for tests:   31.288 seconds
Complete requests:      10000000
Failed requests:        0
Non-2xx responses:      10000000
Keep-Alive requests:    10000000
Total transferred:      1190000000 bytes
HTML transferred:       0 bytes
Requests per second:    319606.71 [#/sec] (mean)
Time per request:       0.313 [ms] (mean)
Time per request:       0.003 [ms] (mean, across all concurrent requests)
Transfer rate:          37141.80 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       9
Processing:     0    0   0.1      0       5
Waiting:        0    0   0.1      0       5
Total:          0    0   0.1      0      10

Percentage of the requests served within a certain time (ms)
  50%      0
  66%      0
  75%      0
  80%      0
  90%      0
  95%      1
  98%      1
  99%      1
100%     10 (longest request)

论坛徽章:
36
子鼠
日期:2013-08-28 22:23:29黄金圣斗士
日期:2015-12-01 11:37:51程序设计版块每日发帖之星
日期:2015-12-14 06:20:00CU十四周年纪念徽章
日期:2015-12-22 16:50:40IT运维版块每日发帖之星
日期:2016-01-25 06:20:0015-16赛季CBA联赛之深圳
日期:2016-01-27 10:31:172016猴年福章徽章
日期:2016-02-18 15:30:3415-16赛季CBA联赛之福建
日期:2016-04-07 11:25:2215-16赛季CBA联赛之青岛
日期:2016-04-29 18:02:5915-16赛季CBA联赛之北控
日期:2016-06-20 17:38:50技术图书徽章
日期:2016-07-19 13:54:03程序设计版块每日发帖之星
日期:2016-08-21 06:20:00
发表于 2015-10-24 12:16 |显示全部楼层
回复 51# wlmqgzm


    好像跟我问的问题无关。。。
   
    楼主前提假定了软硬件系统正常和网络畅通,故事说的也都是tcp之上的用法,我比较想听的故事是非民用级别的那些~

论坛徽章:
9
程序设计版块每日发帖之星
日期:2015-10-18 06:20:00程序设计版块每日发帖之星
日期:2015-11-01 06:20:00程序设计版块每日发帖之星
日期:2015-11-02 06:20:00每日论坛发贴之星
日期:2015-11-02 06:20:00程序设计版块每日发帖之星
日期:2015-11-03 06:20:00程序设计版块每日发帖之星
日期:2015-11-04 06:20:00程序设计版块每日发帖之星
日期:2015-11-06 06:20:00数据库技术版块每周发帖之星
日期:2015-12-02 15:02:47数据库技术版块每日发帖之星
日期:2015-12-08 06:20:00
发表于 2015-10-24 12:18 |显示全部楼层
回复 48# cokeboL

目前程序员主要做这些是为了满足, 在同一个机房内, 在稳定的以太网环境下, 即使客户端主动重启, 例如:软件升级, 不丢失一个有效数据包.

这些经过程序员的努力是可以做到的, 就是在软件流程上, 按照规范设计, 很多人为可以避免的丢包情况, 我们都把它挽回了.

尤其多数情况下, 关键核心应用都在一个机房, 没有多少外界因素,

这样很多版本升级, 主备切换之类的事情, 影响就基本可以消除,  对于关键性应用, 涉及到钱的网络服务器, 这些都很重要.


   

论坛徽章:
9
程序设计版块每日发帖之星
日期:2015-10-18 06:20:00程序设计版块每日发帖之星
日期:2015-11-01 06:20:00程序设计版块每日发帖之星
日期:2015-11-02 06:20:00每日论坛发贴之星
日期:2015-11-02 06:20:00程序设计版块每日发帖之星
日期:2015-11-03 06:20:00程序设计版块每日发帖之星
日期:2015-11-04 06:20:00程序设计版块每日发帖之星
日期:2015-11-06 06:20:00数据库技术版块每周发帖之星
日期:2015-12-02 15:02:47数据库技术版块每日发帖之星
日期:2015-12-08 06:20:00
发表于 2015-10-24 12:43 |显示全部楼层
本帖最后由 wlmqgzm 于 2015-10-24 12:47 编辑

回复 53# cokeboL

对于非民用级别, 这些我前面说过了, 要在TCP/IP和应用层中间, 加1-2层, 这1-2层代码,

国内各大电信级别设备制造商, 中国银监会等等, 各系统都有自己的设计构造, 与各外界计算机接口, 都有类似的东西.  

过去, 一直没有比较统一的思路.各系统数据交换格式,以及校验比较混乱.  Google等公司开源了部分代码, 提供了一些解决的思路.

一个功能点是数据切分,  Google先开源了Google protbuff, 后开源了Google flatbuff,  其中, 国内人多数只用protbuff, 但是, 实际上flatbuff性能更高, 高几倍的性能, Google flatbuff后开源, 所以, 使用的人不多,  Google一般都是把淘汰的东西, 拿出来开源, 内部应该有更好的东西了.

另外一个功能点就是  校验和高效加解密.  这个一般是关键性应用才使用的, 算非民用级别的东西, 这些是关键性应用等需要的. 例如: 航天的TCP/IP中间层,  这一层对应用是透明的, 或者是半透明的, 应用层不需要特殊处理, 就可以得到, 更可靠的数据.

我准备后续做的就是这部分, 去掉了加解密部分不做, 做数据切分 +数据校验,  尽力跟Google的设计比拼一下, 还要一段时间努力, Google里面做protobuff 和flatbuff的都是牛人,

我过去没有做过类似的项目, 怕考虑不周, 慢慢做.



论坛徽章:
36
子鼠
日期:2013-08-28 22:23:29黄金圣斗士
日期:2015-12-01 11:37:51程序设计版块每日发帖之星
日期:2015-12-14 06:20:00CU十四周年纪念徽章
日期:2015-12-22 16:50:40IT运维版块每日发帖之星
日期:2016-01-25 06:20:0015-16赛季CBA联赛之深圳
日期:2016-01-27 10:31:172016猴年福章徽章
日期:2016-02-18 15:30:3415-16赛季CBA联赛之福建
日期:2016-04-07 11:25:2215-16赛季CBA联赛之青岛
日期:2016-04-29 18:02:5915-16赛季CBA联赛之北控
日期:2016-06-20 17:38:50技术图书徽章
日期:2016-07-19 13:54:03程序设计版块每日发帖之星
日期:2016-08-21 06:20:00
发表于 2015-10-24 13:00 |显示全部楼层
楼主,我没理解你指的数据切分是啥意思

Google protbuff在我眼里就是个序列化反序列化工具,相比json xml之类的还要生成代码或者动态解析也要消息格式配置
除了性能和节省流量,不如json xml灵活
flatbuff没用过
但是性能再怎么好也不如自己定制的比如我们之前公司项目也有用自己实现的生成代码工具,每个message的encode decode
都是生成相应的内存段打包解包代码,接口统一罢了,只定制这些功能所以肯定没pb那么强大,但也不需要那么大坨东西

我自己写过lua序列化反序列化动态解析的工具,选哪种只是看项目中哪种更方便并且没有瓶颈就可以了

至于加密校验,这些当然也都有,否则随便就被人抓包看明文好破解和攻击了

如果楼主指的非民用级别是序列化反序列化一层,加密校验一层,那我就没什么想了解的了,这些大家都在搞,不会的人才没搞

论坛徽章:
9
程序设计版块每日发帖之星
日期:2015-10-18 06:20:00程序设计版块每日发帖之星
日期:2015-11-01 06:20:00程序设计版块每日发帖之星
日期:2015-11-02 06:20:00每日论坛发贴之星
日期:2015-11-02 06:20:00程序设计版块每日发帖之星
日期:2015-11-03 06:20:00程序设计版块每日发帖之星
日期:2015-11-04 06:20:00程序设计版块每日发帖之星
日期:2015-11-06 06:20:00数据库技术版块每周发帖之星
日期:2015-12-02 15:02:47数据库技术版块每日发帖之星
日期:2015-12-08 06:20:00
发表于 2015-10-24 13:59 |显示全部楼层
本帖最后由 wlmqgzm 于 2015-10-24 14:38 编辑

回复 53# cokeboL

好吧, 先说一个真实的事情,  时间久了,  原文可能有出入, 靠记忆转写.

"TCP/IP校验不足"造成的"黑客入侵"事件

美国某著名的金融交易公司发生的虚假的 "非法入侵案", 某交易网络中断三天, 交易缓慢, 损失巨大.

某公司的网络, 号称是全世界最安全的网络, 5级防火墙, 清一色的全世界最好的设备, IBM, CISCO....., 其中IBM是那种号称双计算双校验, 永不出错系列的超级计算机,

不说内存硬盘之类的, 即使是CPU核心, 也是每一步计算至少2个CPU同步计算, 计算结果同步硬件对比, 出错自动同步重做, 永不出错, 全部是硬件级的校验.

机房是那种安全级别最高的, 层层有授权, 平常基本没有人能够进入核心, 号称永不停机.

某天, 突然一级告警, 某个方向的交易数据提示, 检测到"非法的篡改的交易数据", 不是一条两条, 是铺天盖地的信息.  "黑客攻击???"  这是首先的反应......

很快各地纷纷告警, 交易被冻住了, 失去响应.  毕竟是超级大公司, 各类专家云集, 连续三天, 动用了所有可能动用的手段,  没有找到原因, 暗藏的黑手, 无影无踪........

老板已经通知了有关政府部门, 并且得到了强力支持, 全国专家云集, 一定要找到黑手, 不达目的, 绝不罢休, 三天没有抓住这个黑客,

后来其实很快已经有专家意识到, 问题可能出在内部, 但是,在没有证据的情况下, 谁都不敢乱说.

BOSS也坚持即使是内部原因, 也一定要找到, 绝不能轻易重启动服务器, 否则, 内部的炸弹不直到什么时候还会爆发.

第三天, 救火英雄出现了, 后来成为公司技术主管,  他找到了原因: TCP/IP校验不足的问题.

1) 为了保证可靠和高性能, 数据格式是定长的, 代码非常简洁易懂, 所有的数据全部有多组校验, 发现多组校验码不正确, 即可判断"交易数据"被篡改, 多个交易记录不一致, 触发一级告警.

2) 某台服务器是最后一道防火墙, 数据在这里做最后检查,确认后, 进入交易核心,  信息在进入核心前还有多次校验多次加密,  都没有用. 因为最后一道防火墙把这些包装在外面的校验层都去掉了.

3) 由于某种原因, 交易流的近一半是经过2)某个socket连接进核心的, 某socket单条连接上的流量惊人. 后来, 这条连接上的交易都失败了.该socket的流量将经过CISCO对称网络, 抵达核心层. 单CISCO路由器下线不影响服务.

4) 某台CISCO路由器(机房内)在某种情况下, 一个bit出现错误, 该bit位刚好是要转发的IP包的长度字节中的一位, 并且刚好是最低位. 路由器的内存无校验, 无法纠正此错误.
    某数据包进入路由器, 和出路由器的一个数据包, 少了一个字节.  一个数据包的一个字节丢失的错误是造成整个事件的根本原因.

5) TCP/IP的校验码是16位的, 有6.5万分之一, 不能检测错误状态. 对于此单字节丢失, 恰好, 未能给予检测出.

6) 数据格式定长, 因此, 从这个数据包以后, 来自于某链路的全部交易数据都被系统认为是"非法的篡改的交易数据".

后来,系统的交易日志, 确认, 将所有日志数据向后移动一个字节, 并从上个日志补上最后一个字节, 就都正确了.

总之, 这个人也是牛人, 发现了所有的问题, 并且解释了所有的前因后果, 所以, 后来被提升为主管.


讲这个故事, 就是要说明一下, TCP/IP层与应用层之间, 为什么要加一层, 校验层, 这个校验层很有讲究的.
这个故事里, 该公司也有校验的, 还有几组校验, 算法各不相同, 还有私有算法的.

另外, 也有人说, 我们公司每天交易上亿,从未出过错误, 我相信TCP/IP.
其实吧, 在同一个HUB上, 不经过路由器的话,  不加校验也没有问题, 因为, TCP/IP的底层, 以太网接口层, 校验码的长度远超TCP/IP层, 也够用了.



论坛徽章:
0
发表于 2015-10-24 14:34 |显示全部楼层
楼主很强大,很想学习,不知道能否开源

论坛徽章:
9
程序设计版块每日发帖之星
日期:2015-10-18 06:20:00程序设计版块每日发帖之星
日期:2015-11-01 06:20:00程序设计版块每日发帖之星
日期:2015-11-02 06:20:00每日论坛发贴之星
日期:2015-11-02 06:20:00程序设计版块每日发帖之星
日期:2015-11-03 06:20:00程序设计版块每日发帖之星
日期:2015-11-04 06:20:00程序设计版块每日发帖之星
日期:2015-11-06 06:20:00数据库技术版块每周发帖之星
日期:2015-12-02 15:02:47数据库技术版块每日发帖之星
日期:2015-12-08 06:20:00
发表于 2015-10-24 14:53 |显示全部楼层
本帖最后由 wlmqgzm 于 2015-10-24 15:32 编辑

回复 58# sqfasd

现在是无业游民状态,  先做吧, 从未做过网络库, 首次做高性能网络架构, 还不知道最终结果如何.  

自己也是一般的程序员, 以前见过大神级别的程序员, 知道一些做网络软件的知识, 呵呵.

希望这个项目能够帮助我找个合理薪水的IT岗位,  唉.

开源什么的, 都没有搞过, 以后再考虑,

在这里跟大家讨论一下, 谈一下自己的技术思路, 也比单写代码有意思.  呵呵呵呵呵

论坛徽章:
36
子鼠
日期:2013-08-28 22:23:29黄金圣斗士
日期:2015-12-01 11:37:51程序设计版块每日发帖之星
日期:2015-12-14 06:20:00CU十四周年纪念徽章
日期:2015-12-22 16:50:40IT运维版块每日发帖之星
日期:2016-01-25 06:20:0015-16赛季CBA联赛之深圳
日期:2016-01-27 10:31:172016猴年福章徽章
日期:2016-02-18 15:30:3415-16赛季CBA联赛之福建
日期:2016-04-07 11:25:2215-16赛季CBA联赛之青岛
日期:2016-04-29 18:02:5915-16赛季CBA联赛之北控
日期:2016-06-20 17:38:50技术图书徽章
日期:2016-07-19 13:54:03程序设计版块每日发帖之星
日期:2016-08-21 06:20:00
发表于 2015-10-24 17:03 |显示全部楼层
回复 57# wlmqgzm


    楼主你如果描述成民用级别的校验和非民用级别的校验我就了解了。。
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP