非阻塞模式下，send recv connect、accept函数的情况研究
-
connect
- 阻塞模式下(超时时间75s)：客户端调用connect触发tcp三次握手，仅在连接建立成功或出错时返回
- 非阻塞模式下（如select + connect）：调用connect会立即返回EINPROCESS，但TCP通信仍在进行中，利用io复用函数（如select）来检查这个连接是否建立成功
- 连接建立成功时，描述符可写
- 连接建立出错时，描述符可读写
调用connect连接一般的超时时间是75s, 但是在程序中我们一般不希望等这么长时间采取采取动作。 可以在调用connect之前设置套接字非阻塞,然后调用connect,此时connect会立刻返回, 如果连接成功则直接返回0（成功）， 如果没有连接成功，也会立即返回并且会设置errno为EINPROCESS,这并不是一个致命错误,仅仅是告知你已经在连接了,你只要判断是它就继续执行后面的逻辑就行了,比如select.通过select设置超时来达到为connect设定超时的目的
-
socket在什么情况下可读写?
- 可读
- 接收缓冲区（读缓冲区）有数据，一定可读
- 对方正常关闭socket，也是可读 （该连接的读这一半关闭，接收到fin报文）
- 对于侦听socket，有新连接到达也可读=
- 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的情况发生：
- 太多TIME_WAIT：
- 短连接过多，修改内核参数，让服务器能够快速回收和重用那些TIME_WAIT的资源。http1.1意识到了这个问题，默认启用了keep-live来解决这个问题（即在一次TCP连接中可以持续发送多份数据而不会断开连接。通过使用keep-alive机制，可以减少tcp连接建立次数，也意味着可以减少TIME_WAIT状态连接，以此提高性能和提高http服务器的吞吐率）
- 设置TCP选项SO_REUSEADDR
端口复用允许在一个应用程序可以把 n 个套接字绑在一个端口上而不出错。同时，这 n 个套接字发送信息都正常，没有问题。但是，这些套接字并不是所有都能读取信息，只有最后一个套接字会正常接收数据。
- 太多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，其实已经够用了。
线程的状态
- 新建状态（new）
- 就绪状态（runnable）
- 阻塞状态（blocked）
- 运行状态（running）
-
死亡状态（Dead）
image.png
