秋招C++开发学习之路day25

day30

1. http1.x的缺陷，实现简单是以牺牲性能为代价的
   a. 客户端需要使用多个连接才能实现并发和缩短延迟。
   b. 不会压缩请求和响应首部，从而导致不必要的网络流量。
   c. 不支持有效的资源优先级，致使底层TCP连接的利用率下降。

2. http1.1的新特性
   默认是长连接、支持流水线、支持同时打开多个tcp连接、支持虚拟机、新增状态码100、支持分块传输编码、新增缓存处理指令max-age。
   虚拟机：http1.1使用虚拟主机技术，使得一台服务器拥有多个域名，并且在逻辑上可以看成多个服务器。

3. GET和POST比较
   作用：GET用于获取资源，POST用于传输实体主体（传输数据）。
   参数：GET和POST的请求都能使用额外的参数，但是GET的参数是以查询字符串出现在URL中的，而POST的参数是存储在实体主体中。
   安全：GET方法是安全的，POST不是安全的。
   幂等性：幂等的http方法，同样的请求被执行一次与连续执行多次的效果是一样的，服务器的状态（安全的http方法不会改变 服务器状态）也是一样的。所以幂等方法不应该具有副作用。所有的安全方法都是幂等的！
   可缓存：请求报文的http方法本身是可缓存的，包括GET和HEAD，但是PUT和DELETE不可缓存，POST在多数情况下不可缓存，响应报文的状态码可以缓存，cache-control首部字段没指定则不缓存。

4. IO模型
   unix下五种：
   阻塞式IO、非阻塞式IO、IO复用、信号驱动式IO、异步IO
   阻塞式IO：应用进程被阻塞，直到数据从内核缓冲区复制到应用进程缓冲区中才返回。再阻塞过程中，其他的应用进程还可以执行，并不是整个系统的阻塞，这种模型的CPU利用率比较高
   非阻塞式IO：应用进程执行系统调用后，内核返回一个错误码。应用进程可以继续执行，但是需要不断地执行系统调用来获知IO是否完成，称作轮询。由于CPU要处理更多的系统调用，所以CPU的利用率比较低。
   IO复用：使用select或者poll等待数据，并且可以等待多个套接字的任何一个变为可读。这一过程会被阻塞，当某一个套接字可读时返回，之后再使用recvfrom把数据从内核复制到进程中。他可以让单个进程具有处理多个IO事件的能力，又被称作事件驱动IO。
   信号驱动IO：相比于非阻塞式的轮询方式，信号驱动IO的CPU利用率更高。
   异步IO：系统调用会立即返回，应用进程可以继续执行，不会被阻塞。异步IO与信号驱动IO的区别在于，异步IO的信号是通知应用进程IO完成，而信号IO的信号是通知应用进程可以开始IO。

5. IO复用
   select、poll、epoll都是IO复用的具体体现。
   调用select会一直阻塞直到有描述符事件到达或者等待的时间超过超时参数timeout。

比较
功能上：
select和poll的功能基本相同，一些实现细节不同
select会修改描述符，poll不会
select的描述符类型使用数组实现，默认大小1024，因此默认只能监听1024个描述符。
而poll使用链表实现，所以没有描述符数量的限制。
poll提供了更多的事件类型，并且对描述符的重复利用上比select高。
一个线程对某个描述符调用select或poll，另一个线程关闭了他，会导致调用结果不正确
速度上：
select和poll的速度都比较慢。
可移植性：
几乎所有的系统都支持select，但是只有比较新的系统支持poll。

6. epoll
   epoll_ctl()用于向内核注册新的描述符或者改变某个描述符的状态。已注册的描述符在内核中会被维护在一颗红黑树上。进程调用epoll_wait()可以得到事件完成的描述符。
   epoll只需要将描述符从进程缓冲区向内核缓冲区拷贝一次，并且进程不需要通过轮询来获取事件完成的描述符，只有活跃的FD（描述符）才会调用callback函数。所以效率不会碎FD数目增加而降低。
   epoll仅适用于linux OS
   epoll比select和poll更加灵活而且没有描述符数量的限制。
   epoll对多线程友好，一个线程调用epoll_wait（），另一个线程关闭它，也不会产生不确定结果。

工作模式：
epoll的描述符事件有两种触发模式：LT（水平触发）和ET（边缘触发）
LT：当epoll_wait监测到描述符事件到达时，将此事件通知进程，进程可以不立即处理该事件，下次调用epoll_wait时会再次通知进程。是默认的模式。
ET：通知后进程立即处理事件，下次调用就不会再得到事件到达的通知。减少了epoll事件被重复触发的次数，所以效率比LT模式高。

应用场景：
select、poll、epoll都有各自的使用场景
select应用场景：
select的超时参数timeout为1ns，而poll和epoll的为1ms。所以select更加适用于对实时性要求比较高的场景，比如核反应堆控制。
select可移植性高，几乎被所有主流平台所支持。
poll应用场景：
poll没有最大描述符数量的限制，如果平台支持且对实时性要求不高，应该用poll。
epll应用场景：
只需要运行在linux平台上，有大量的描述符需要同时轮询，并且这些链接最好是长连接
如果监控小于1000个描述符，没必要用epoll，不能体现epoll的优势。
需要监控的描述符状态变化多，且都非常短暂，也不用epoll。因为epoll中的所有描述符都存储在内核中，造成每次需要对描述符的状态改变都需要epoll_ctl进行系统调用，降低效率。且epoll的描述符都存储在内核，不容易调试。