day30
-
http1.x的缺陷,实现简单是以牺牲性能为代价的
a. 客户端需要使用多个连接才能实现并发和缩短延迟。
b. 不会压缩请求和响应首部,从而导致不必要的网络流量。
c. 不支持有效的资源优先级,致使底层TCP连接的利用率下降。 -
http1.1的新特性
默认是长连接、支持流水线、支持同时打开多个tcp连接、支持虚拟机、新增状态码100、支持分块传输编码、新增缓存处理指令max-age。
虚拟机:http1.1使用虚拟主机技术,使得一台服务器拥有多个域名,并且在逻辑上可以看成多个服务器。 -
GET和POST比较
作用:GET用于获取资源,POST用于传输实体主体(传输数据)。
参数:GET和POST的请求都能使用额外的参数,但是GET的参数是以查询字符串出现在URL中的,而POST的参数是存储在实体主体中。
安全:GET方法是安全的,POST不是安全的。
幂等性:幂等的http方法,同样的请求被执行一次与连续执行多次的效果是一样的,服务器的状态(安全的http方法不会改变 服务器状态)也是一样的。所以幂等方法不应该具有副作用。所有的安全方法都是幂等的!
可缓存:请求报文的http方法本身是可缓存的,包括GET和HEAD,但是PUT和DELETE不可缓存,POST在多数情况下不可缓存,响应报文的状态码可以缓存,cache-control首部字段没指定则不缓存。 -
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。 -
IO复用
select、poll、epoll都是IO复用的具体体现。
调用select会一直阻塞直到有描述符事件到达或者等待的时间超过超时参数timeout。
比较
功能上:
select和poll的功能基本相同,一些实现细节不同
select会修改描述符,poll不会
select的描述符类型使用数组实现,默认大小1024,因此默认只能监听1024个描述符。
而poll使用链表实现,所以没有描述符数量的限制。
poll提供了更多的事件类型,并且对描述符的重复利用上比select高。
一个线程对某个描述符调用select或poll,另一个线程关闭了他,会导致调用结果不正确
速度上:
select和poll的速度都比较慢。
可移植性:
几乎所有的系统都支持select,但是只有比较新的系统支持poll。
- 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的描述符都存储在内核,不容易调试。