高性能网络编程－陶辉

阅读笔记 网络编程

做过Nginx开发的人应该都知道一本书 "深入理解Nginx" 这本书的作者叫 陶辉，后来在网上看到他的博客，也有很多可以学习的地方，于是学习并做了一些笔记。

高性能网络编程 是csdn上的一个博客专栏，作者给自己公司培训的一个总结，有很多经验分享，最好结合 《TCP/IP协议详解》 看。

高性能服务器开发的关注点

1、如果基于通用组件编程，关注点多是在组件如何封装套接字编程细节。为了使应用程序不感知套接字层，这些组件往往是通过各种回调机制来向应用层代码提供网络服务，通常，出于为应用层提供更高的开发效率，组件都大量使用了线程（Nginx等是个例外），当然，使用了线程后往往可以降低代码复杂度。但多线程引入的并发解决机制还是需要重点关注的，特别是锁的使用。另外，使用多线程意味着把应用层的代码复杂度扔给了操作系统，大吞吐量时，需要关注多线程给操作系统内核带来的性能损耗。
基于通用组件编程，为了程序的高性能运行，需要清楚的了解组件的以下特性：怎么使用IO多路复用或者异步IO的？怎么实现并发性的？怎么组织线程模型的？怎么处理高吞吐量引发的异常情况的？

2、通用组件只是在封装套接字，操作系统是通过提供套接字来为进程提供网络通讯能力的。所以，不了解套接字编程，往往对组件的性能就没有原理上的认识。学习套接字层的编程是有必要的，或许很少会自己从头去写，但操作系统的API提供方式经久不变，一经学会，受用终身，同时在项目的架构设计时，选用何种网络组件就非常准确了。
学习套接字编程，关注点主要在：套接字的编程方法有哪些？阻塞套接字的各方法是如何阻塞住当前代码段的？非阻塞套接字上的方法如何不阻塞当前代码段的？IO多路复用机制是怎样与套接字结合的？异步IO是如何实现的？网络协议的各种异常情况、操作系统的各种异常情况是怎么通过套接字传递给应用性程序的？

3、网络的复杂性会影响到服务器的吞吐量，而且，高吞吐量场景下，多种临界条件会导致应用程序的不正常，特别是组件中有bug或考虑不周或没有配置正确时。了解网络分组可以定位出这些问题，可以正确的配置系统、组件，可以正确的理解系统的瓶颈。
这里的关注点主要在：TCP、UDP、IP协议的特点？linux等操作系统如何处理这些协议的？使用tcpdump等抓包工具分析各网络分组。

• IO 的处理细节对于整个数据的传输流程非常重要
• TCP 只要解决的三个问题：丢包， 重复，延迟

• accept的过程， syn队列和 accept队列 和 backlog参数

  若SYN队列满，则会直接丢弃请求，即新的SYN网络分组会被丢弃；如果ACCEPT队列满，则不会导致放弃连接，也不会把连接从SYN列队中移出，这会加剧SYN队列的增长。所以，对应用服务器来说，如果ACCEPT队列中有已经建立好的TCP连接，却没有及时的把它取出来，这样，一旦导致两个队列满了后，就会使客户端不能再建立新连接，引发严重问题。
  所以，如TOMCAT等服务器会使用独立的线程，只做accept获取连接这一件事，以防止不能及时的去accept获取连接。

• MTU 最大传输单元, 最大报文段长度MSS,

• 发送方法返回成功后，数据一定发送到了TCP的另一端吗？

  无论是使用阻塞还是非阻塞套接字，发送方法成功返回时（无论全部成功或者部分成功），既不代表TCP连接的另一端主机接收到了消息，也不代表本机把消息发送到了网络上，只是说明，内核将会试图保证把消息送达对方

• TCP 接收消息

  接收TCP消息的过程可以一分为二：首先是PC上的网卡接收到网线传来的报文，通过软中断内核拿到并且解析其为TCP报文，然后TCP模块决定如何处理这个TCP报文。其次，用户进程调用read、recv等方法获取TCP消息，则是将内核已经从网卡上收到的消息流拷贝到用户进程里的内存中

  • socket从接收队列读取时候是有lock的，防止多进程并发访问，后来进入的报文只能进backlog队列
  • 接收时候用到的4个队列 receive, out_of_order, prequeue, backlog

• TCP 连接的关闭

  • close 会检查fd的引用，只有引用为0才会关闭连接
  • shutdown 直接关闭连接，不管是多进程还是多线程
  • 半关闭 关闭发送消息的功能；关闭接收消息的功能

服务端开发

2个阶段：等待消息准备好，处理消息。 并且socket是非阻塞的。

首先我们要谈谈，网络编程界为什么需要反应堆？有了IO复用，有了epoll，我们已经可以使服务器并发几十万连接的同时，维持高TPS了，难道这还不够吗？
我的答案是，技术层面足够了，但在软件工程层面却是不够的

系统接口给出了高级的功能，但是没有好的软件架构也很难驾驭的了。

• 反应堆模型 定时器非常重要