谈网络中的数据收发处理

事先说明下情况：
写socket 的时候，一般都是会在 数据包 加上【包头】，指示这个数据包的size。

（消息防篡改可能还会加密， 再校验）
可以参考【对称加密算法】，【非对称加密算法】

0.网络拥堵问题

- 无线移动 信号不稳定
- 有线带宽占满，网络阻塞。阻塞超时，会重传。  
 
     (超时越多，重传越多)↓
   ↑(重传越多，超时越多)
 
 
    严重的场合,会陷入循环。
    所有才有下面，修改
 
 
- 有的操作系统或者程序，会有优化处理  
     * windows的 [Nagle](https://en.wikipedia.org/wiki/Nagle%27s_algorithm)
     * google BBR 会自动根据网络状况，修改滑动窗口大小。  [google BBR](https://github.com/google/bbr)

所以 网络上TCP协议的校验， 是TCP协议上的。为了做重传。

但实际结果：延时高的时候，当然数据不一定正确 or 不一定能传送到

这个时候，就需要我们自己定义包头， 收发端 一起来规范格式。

防止数据出问题，可以在业务层 做处理， TCP协议毕竟是80~90年代的产物，不是那么靠谱。
（ 当然最近版的linux 内核好像对网络层 改动很大。提高了很多性能。

微软估计也是因为技术创新这点，才拥抱Linux的吧。 ）

1.网络中的 数据包结构设计

一般是  { [package size]   [ md5  ]    [buffer  .....  ]  }
 size:     4Byte       32byete          packageSize

- package头的size 是固定的长度， （里面一般是[buffer]的size）
- md5 size 随意，看你自己要生成多少位的数据了，一般是32个字符， 32byte   (不一定非要MD5  可以用其他校验方式)
- buffer   一般是对这个buffer 进行MD5, package size就是他的长度。

2.是否 有【粘包】这个概念

一般是指数据包 ，每次recv 大小不明确，

- 2.1 正常情况
        - 如果先 detach() recv thread，再 detach() send thread，就没有问题。这是没有问题的。
 
- 2.2 异常情况
        - 如果先 detach() send thread，再 detach() recv thread. 如果另一端，收到后立马再发送。 
    
           则因为，send() 之后，没有recv(), 导致前面send()的数据包可能丢失。
           那么这次 recv()的数据，包含上次（上上次， 上上上次）远程 echo的数据， 所以会导致数据 变成以下状态.(可能完整,可能不完整)
           
            //假设一个完整数据包就是 "data"字符
           * ta...}{data... }  //缺少da
           *{data...}{da...    //缺少ta
           *{data...}{data...} //运气好,没有丢失数据
           
 
        - 还有一种是，socket开启后，recv()正常，然后再shutdownRecv() 没有接收数据，在缓存中，  下次开启recv()时，导致网络中(接受方网络硬件中的缓存)也会出现以上问题。

            当发送方send()数据后,
                数据可能在网络中(光纤线路, 机房路由中),
                可能在你的路由器,
                可能在 你的主机 网卡缓存中(你还没有取), 
                可能 recv()处理出错
                可能 你正确recv()数据后, 你的业务流程 却没有处理(软件崩溃,断电,资源耗尽 等等)
                必须完成业务逻辑, 进行持久化.  才能完整一个业务流程.  
            中间任何环节都可能存在问题.

结论：

    一般是没有网络粘包这个说法的。 一般情况下 TCP的SYN 序号，和重传  已经足够处理大部分网络阻塞，延时需求  
    只不过 有的场合 会出现点意外，如果业务设计 做到足够好，就可以不用管粘包
    就像陈硕说的，服务器并不是要保证7*24小时正常运行，而是无论哪台机器，出问题之后，还能保证业务100%不出错
 
        无论哪种，处理数据不知道每个包的大小，处理起来就格外麻烦。所以需要处理socket 业务的时候好好考虑下。
        1.包格式
        2.异常的时候，该结束  还是独自解析粘包的数据？（业务设计的时候，如何保持强一致性）  ==》回复接收成功
        3.包的校验
相关： setsockopt 设置 SO_LINGER 选项， 保证socket close之前，把数据发送出去。

3.网络IO模型

简单网络IO模型有（不讨论API,网上资源已经足够多了。 linux 可以在这里查看资料 https://www.kernel.org/doc/man-pages/ ）

- 阻塞
    * 一recv,一send
    * 一recv,多send
    
- 非阻塞
    * send thread, recv thread（哪有业务，就处理哪，效率最高）
 
 
- 半阻塞
    * send 为非阻塞，recv 为阻塞
    * recv 为非阻塞，send 为阻塞

其实我一直觉得 [Registered I/O] 就是微软对Linux [epoll]的致敬。

• windows:select/iocp/[Registered I/O]
• linux:select/poll/ epoll
• freebsd:kqueue

转载请注明来源-