qq_32680371的博客

网络模型与网络收发流程我们经常说七层负载均衡、四层负载均衡，或者三层设备、二层设备等等，这里说的二层、三层、四层、七层都来自国际标准化组织制定的开放式系统互联通信参考模型（Open System Interconnection Reference Model），简称为 OSI 网络模型。OSI模型把网络互联的框架分为应用层、表示层、会话层、传输层、网络层、数据链路层以及物理层等七层，每个层负责不同的功能：1、应用层，负责为应用程序提供统一的接口。2、表示层，负责把数据转换成兼容接收系统的格式。3、会

reactor模式必须有一个event_pool线程不断的循环获取事件，读取IO数据，同时注册事件处理回调函数，当读取到IO事件后，调用相应的事件处理函数。但是由于业务逻辑与IO分离了，这种反人类的编程方式，其实现还是有一定的难度的。本文就介绍一下常见的reactor模式，下一篇博文将写一个案例程序。在服务器端，根据accept，IO，事件处理逻辑所在的线程，可以划分为：1、single reactor thread模式2、single reactor+worker模式3、master-slave-

堵塞IO与非堵塞IO的区别1、对于read操作。当缓冲区有数据时，堵塞IO与非堵塞IO都是能读多少数据就读多少数据读完立即返回，返回值为读取到的字节数。当缓冲区为空时，对于堵塞IO会堵塞住，CPU会切换给其他进程或者线程；对于非堵塞IO，read函数会返回-1并且设置错误码为EAGIAN或者EWOULDBLOCK。2、对于write操作。当缓冲区足够容纳要写入数据时，堵塞与非堵塞IO都会把全部数据都写入缓冲区后立即返回，返回值为写入的大小。当缓冲区不足时，对于堵塞IO，write操作会堵塞住，CPU切换

本文参考epoll源码分析文档：https://www.nowcoder.com/discuss/26226edge-triggered VS level-triggered在我的博文《Linux的select poll epoll的IO多路复用》中介绍过：level-triggered即条件触发，只要满足事件的条件，比如有数据需要读，就一直不断地把这个事件传递给用户；edge-triggered即边缘触发，只有第一次满足条件的时候才触发，之后就不会再传递同样的事件了。一般来说边缘触发的效率比条件触

IO多路复用什么是IO多路复用呢？我们可以把诸如标准输入输出、套接字等看成是IO的一路，当任何一路有事件发生时，内核就通知应用程序去获取事件。Linux下有select，poll，epoll三种IO多路复用技术，本来就介绍一下他们的用法。selectselect函数的原型如下：int select(int maxfd, fd_set *readset, fd_set *writeset, fd_set *exceptset, const struct timeval *timeout);//返回：若

服务端开发的同学，可能经常发现，bind的时候会提示"bind failed: Address already in use"，本文我们就对这个问题分析一下。当连接的一方主动关闭连接，在接收到对端的 FIN 报文之后，主动关闭连接的一方会在 TIME_WAIT 这个状态里停留一段时间，这个时间大约为 2MSL。当通过服务器端发起的关闭连接操作，引起了一个已有的 TCP 连接处于 TME_WAIT 状态，正是这个 TIME_WAIT 的连接，使得服务器重启时，继续绑定在同样的地址与端口时出现了"bind f

TCP真的可靠么？我们都说TCP是可靠的，但是TCP真的就那么可靠么？1、当TCP的发送端调用write(或send)函数，发送数据的时候，只是把数据拷贝到发送缓冲区中，数据怎么发送什么时候发送，是由TCP/IP协议控制的。如果发送端调用完write函数后，崩溃了，那么发送缓冲区中的数据就丢失了。当发送缓冲区中的数据发送出去后，接收方返回的ACK报文到达后，发送缓冲区中的数据就会删除了，接收方的应用程序是否已经处理，对于发送方来说是无法感知到的。2、当接收方接收到数据的时候，是把数据存放在接收缓冲区里

TCP正常情况下关闭连接，接收方是可以感知到的。但是如果一方由于异常（如网络异常，主机崩溃等），FIN报文还没有发出，那么如果正常的一方没有发送报文，是无法感知到连接已经异常了。由于这种情况下感知不到对端的异常，故如果不做保活，会浪费服务端的资源，更重要的是可能会导致系统异常。Linux keepalive机制为此linux提供了keepalive选项，默认是关闭的。如果需要再客户端保活，可以把客户端的keepalive功能打开，这样客户端就可以感知到服务器的异常；如果需要再服务端保活，可以把服务端的打

接收方窗口大小通知在《TCP滑动窗口与缓冲区》的博文中说过接收方会通知发送方滑动窗口的大小，但是如果应用程序每调用read函数读出一些数据，就通知发送方，那么网络中将会有大量的只通知对方窗口大小的报文，而每个TCP报文都会添加几十字节的头部信息，也就是说这个报文的有效负载非常低，网络带宽将浪费在这些小报文上。实际上RFC有优化的，不会缓冲区一变大，就通知对方接收窗口大小的，很多情况下是同数据报文或者ACK报文一块通知的。ACK应答优化TCP是可靠连接的，每个数据报文都得收到对方的ACK应答，才能从发送

在《TCP滑动窗口与缓冲区》的博文中，TCP发送方会根据接收方的窗口大小来调整发送窗口的大小，接收方会尽可能的扩大接收窗口，从而要求发送方更快的发送报文，然而网络的发送能力有限，当超过网络的传输能力时，就会发生丢包，丢包后只有等到超时后，再重发，那么发送速率就会提不上去。更有甚者如果整个网络的所有连接都这样发送报文，那么整个网络将会拥堵不堪，最终导致整个网络瘫痪。为此TCP引入了拥塞控制，用于控制网络的发送速度。拥塞控制包括：慢启动，快速重传，快速恢复，拥塞避免。慢启动由于TCP报文会通过不同的多个网络

当我们创建一个TCP连接时，细心的同学可能会发现，使用free命令会看到cache占用的空间会相应增加。在高并方的场景下，连接会占用大量的空间。这一节我们就谈谈TCP的滑动窗口与缓冲区。

TCP 4次挥手过程

TCP三次握手过程：

TCP（Transmission Control Protocol）传输控制协议是一种面向连接的、可靠的、基于字节流的传输层协议。报文格式如下：1、源端口号、目的端口号同IP数据报中的源IP与目的IP唯一确定一条TCP连接。2、序号（4字节）与确认序号（4字节）：是TCP可靠传输的关键部分。序号是本报文段发送的数据组的第一个字节的序号。在TCP传送的流中，每一个字节一个序号。确认序号，即ACK，指明下一个期待收到的字节序号，表明该序号之前的所有数据已经正确无误的收到。确认序号只有当ACK标志为1时才有