网络编程&&多线程编程

非阻塞模式下，send recv connect、accept函数的情况研究

• connect

  • 阻塞模式下(超时时间75s)：客户端调用connect触发tcp三次握手，仅在连接建立成功或出错时返回
  • 非阻塞模式下（如select + connect）：调用connect会立即返回EINPROCESS，但TCP通信仍在进行中，利用io复用函数（如select）来检查这个连接是否建立成功
    1. 连接建立成功时，描述符可写
    2. 连接建立出错时，描述符可读写

调用connect连接一般的超时时间是75s, 但是在程序中我们一般不希望等这么长时间采取采取动作。 可以在调用connect之前设置套接字非阻塞,然后调用connect,此时connect会立刻返回, 如果连接成功则直接返回0（成功）， 如果没有连接成功，也会立即返回并且会设置errno为EINPROCESS,这并不是一个致命错误,仅仅是告知你已经在连接了,你只要判断是它就继续执行后面的逻辑就行了,比如select.通过select设置超时来达到为connect设定超时的目的

• socket在什么情况下可读写?

• 可读

1. 接收缓冲区（读缓冲区）有数据，一定可读
2. 对方正常关闭socket，也是可读 （该连接的读这一半关闭，接收到fin报文）
3. 对于侦听socket，有新连接到达也可读=
4. socket有错误发生

• 可写
  1.socket的发送缓冲区（写缓冲区）中的数据字节大于等于该socket的发送缓冲区低水位标记的当前大小
  2.socket有错误发生
  3.该连接的写这一半关闭

listen accept connect对应三次握手的哪一次

listen(int socket, int backlog)调用：

• 针对linux内核2.2之后：
  维护了两个队列：一个syn队列（半连接队列）、一个accept队列（完整的连接队列），backlog指的是等待accept的完全建立的套接字队列长度

accept调用：

只取连接建立成功的连接，不取半连接。

connect调用：

参照上面针对阻塞和非阻塞下的情况（都是会取三次握手成功的连接）。

Nagle算法：

当一个TCP连接中有在传数据（那些已发送但还未经确认的数据），小的报文段就不能被发送，直到所有的在传数据都收到ACK。并且在收到ACK后，TCP需要收集这些小数据，将其整合到一个报文段中发送。虽然nagle算法可以减少网络中小分组的个数，但是对于那些需要实时预览的通讯程序而言，客户端可能需要不断发送更新数据并得到服务器的响应，这种情况下nagle算法会造成客户端明显的延迟，所以需要禁用nagle算法，设置套接字TCP_NODELAY

黏包问题：

• 发送端引起的黏包问题：则主要归因于TCP nagle算法
• 接受端引起的黏包问题：由于接收方用户进程不及时接收数据，从而导致粘包现象

解决方法：

• 禁用nagle算法
• 发送固定长度的消息
• 把消息的尺寸与消息一块发送
• 使用特殊标记来区分消息间隔

SO_LINGER选项（优雅关闭）：

用来设置延迟关闭的时间，等待套接字发送缓冲区中的数据发送完成，若没有设置该选项，在发送完FIN后会立即进行一些清理工作并返回，若设置了，会在清理前等待一段时间。SO_LINGER选项的作用是等待发送缓冲区中的数据发送完成，但是并不保证发送缓冲区中的数据一定被对端接收（对端宕机或线路问题），只是说会等待一段时间让这个过程完成。如果在等待的这段时间里接收到了带数据的包，还是会给对端发送RST包，并且会reset掉套接字，因为此时已经关闭了接收通道 。https://www.cnblogs.com/javawebsoa/p/3201324.html

Linux网络TCP连接大量CLOSE_WAIT和TIME_WAIT的情况发生：

1. 太多TIME_WAIT：

• 短连接过多，修改内核参数，让服务器能够快速回收和重用那些TIME_WAIT的资源。http1.1意识到了这个问题，默认启用了keep-live来解决这个问题（即在一次TCP连接中可以持续发送多份数据而不会断开连接。通过使用keep-alive机制，可以减少tcp连接建立次数，也意味着可以减少TIME_WAIT状态连接，以此提高性能和提高http服务器的吞吐率）
• 设置TCP选项SO_REUSEADDR

端口复用允许在一个应用程序可以把 n 个套接字绑在一个端口上而不出错。同时，这 n 个套接字发送信息都正常，没有问题。但是，这些套接字并不是所有都能读取信息，只有最后一个套接字会正常接收数据。

2. 太多CLOSE_WAIT：那就是对方发送一个FIN后，程序自己这边没有进一步发送ACK以确认。换句话说就是在对方关闭连接后，程序里没有检测到，或者程序里本身就已经忘了这个时候需要关闭连接，于是这个资源就一直被程序占用着。这个时候快速的解决方法是：
   一、关闭正在运行的程序，这个需要视业务情况而定。
   二、尽快的修改程序里的bug，然后测试提交到线上服务器。

• Epoll LT和ET的区别：

LT：支持阻塞和非阻塞IO，当接收到读请求时，若没有去处理请求，在下一次epoll_wait（）请求还是会返回（立即返回）
ET：仅支持非阻塞IO

当我们关闭一个描述符时（close（fd）），会从epoll中的监听列表中删除（从红黑树中删除）

• epoll_wait()

int epoll_wait(int epfd, struct epoll_event *events,
                      int maxevents, int timeout);

当最后一个超时参数设置为0时，epoll_wait()立即返回，不阻塞在事件就绪上，会导致cpu占用率过高（可能到达100%），设置为-1时则是阻塞知道事件就绪。

• EPOLLONESHOT

如果是多线程在处理，一个SOCKET事件到来，数据开始解析，这时候这个SOCKET又来了同样一个这样的事件，而你的数据解析尚未完成，那么程序会自动调度另外一个线程或者进程来处理新的事件，这造成一个很严重的问题，不同的线程或者进程在处理同一个SOCKET的事件，这会使程序的健壮性大降低而编程的复杂度大大增加！！即使在ET模式下也有可能出现这种情况！！

• 解决方法：如果对描述符socket注册了EPOLLONESHOT事件，那么操作系统最多触发其上注册的一个可读、可写或者异常事件，且只触发一次。。想要下次再触发则必须使用epoll_ctl重置该描述符上注册的事件，包括EPOLLONESHOT 事件。

• EWOULDBLOCK

用于非阻塞，不需要重新读或者写（非阻塞accept时，无新连接时会返回该错误码）

• EINTER

操作被中断唤醒，需重新读写

• EPOLLRDHUP

在使用 2.6.17 之后版本内核的服务器系统中，对端连接断开触发的 epoll 事件会包含 EPOLLIN | EPOLLRDHUP，即 0x2001。有了这个事件，对端断开连接的异常就可以在底层进行处理了，不用再移交到上层。

详见：https://blog.csdn.net/midion9/article/details/49883063

读写锁

• 条件变量+互斥量

写：
lock()
while(w > 0 || r > 0)
  cond.wait()
w = 1;
unlock()

writing.....

lock()
w = 0;
cond.notify()
unlock()

读:
lock()
while(w > 0)
  cond.wait()
r++;
unlock()

reading....

lock()
r--
if(r == 0)
  cond.notify()
unlock()

• 读写互斥量（两个互斥量）

lock(writeMutex)
writing.......
unlock(writeMutex)

lock(readMutex)
if(readnum == 0)
  lock(writeMutex)
readnum++;
unlock(readMutex)

reading....

lock(readMutex)
readnum--
if(readnum == 0)
  unlock(writeMutex)
unlock(readMutex)

• 两个信号量（相当于两个互斥量，信号量初始化为1）

单例模式

• 饿汉模式是线程安全的

class singleton
{
protected:
    singleton()
    {}
private:
    static singleton* p;
public:
    static singleton* initance();
};
singleton* singleton::p = new singleton;
singleton* singleton::initance()
{
    return p;
}

• 懒汉模式是线程不安全的

//加锁的懒汉
class singleton
{
protected:
    singleton()
    {
        pthread_mutex_init(&mutex);
    }
private:
    static singleton* p;
public:
    static pthread_mutex_t mutex;
    static singleton* initance();
};

pthread_mutex_t singleton::mutex;
singleton* singleton::p = NULL;
singleton* singleton::initance()
{
    if (p == NULL)//竞态
    {
        pthread_mutex_lock(&mutex);
        if (p == NULL)
            p = new singleton();
        pthread_mutex_unlock(&mutex);
    }
    return p;
}

如何提高服务器的并发量：

• 使用epoll边缘触发
• http优化
• 数据库优化
• redis做mysql缓存
• 负载均衡
  • http重定向

在使用HTTP重定向来实现服务器集群负载均衡的过程中，需要一台服务器作为请求调度者。用户的一项操作需要发起两次HTTP请求，一次向调度服务器发送请求，获取后端服务器的IP，第二次向后端服务器发送请求，获取处理结果。

• DNS负载均衡
• 反向代理负载均衡

我们知道，所有发送给我们网站的请求都首先经过反向代理服务器。那么，反向代理服务器就可以充当服务器集群的调度者，它可以根据当前后端服务器的负载情况，将请求转发给一台合适的服务器，并将处理结果返回给用户。

• 修改参数
  默认情况下，linux限制同时打开文件描述符的数量

TCP可靠性保证

• 确认应答与序列号

TCP传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答。也就是发送ACK报文。这个ACK报文当中带有对应的确认序列号，告诉发送方，接收到了哪些数据，下一次的数据从哪里发。

• 超时重传
• 三次握手、四次挥手

• 为什么两次握手不行？
  1.SYN FLOOD攻击 2.防止网络中失效的报文（MSL：报文在网络中存活的时间）再次成功连接

• 流量控制（滑动窗口）
• 拥塞控制

各类包大小

MTU

• 在链路层工作：
  1500字节（数据包大小） 加头信息有14字节，尾部校验和FCS占了4字节，总共大小1518字节
• 在网络层
  MTU - 20（ip首部）

MSS

• 在传输层
  udp：MTU - 20 （ip首部）- 8(udp首部)
  tcp：MTU - 20（ip首部）- 20（tcp首部）

TCP最大连接数

在进行TCP连接时，系统为每个TCP连接创建一个socket句柄，而每个句柄也是一个文件句柄，因此TCP连接数受限于linux可打开文件数。

其次，一个socket连接由四元组标识，理论上1个端口能接受来自一个主机65535（最大端口数）个连接，主机可能有n个，所以端口数限制不了tcp的连接数。

MaxUserPort：端口数的配置参数，可设置，可能默认值为5000，其实已经够用了。

线程的状态

1. 新建状态（new）
2. 就绪状态（runnable）
3. 阻塞状态（blocked）
4. 运行状态（running）

5. 死亡状态（Dead）

   
   image.png