第九周-云计算运维作业

1.编写一个playbook实现Nginx的两种安装过程，安装方式可通过变量传入控制

- hosts: appseevers
  remote_user: root

  vars:
	software: nginx
	version: 1.20.2
	format: .tar.gz

  tasks:
	- name: "编译需要的包"
	  yum:
		name: 
		  - gcc
		  - pcre-devel 
		  - openssl-devel
		  - zlib-devel
		state: present

	- name: nginx use yum
	 - block: 
		- name: install nginx
		  yum: 
			name: nginx
			state: present

		- name: start nginx
		  service:
			name: nginx
			state: started
			enabled: yes

	  when: install == "yum"

	 - name: rpm nginx
	  - block:  
	  - name: add group nginx
	   group:
		 name: nginx
		 system: yes
		 gid: 80

	 - name: add user nginx
	   user:
		 name: nginx
		 group: nginx
		 uid: 80
		 system: yes
		 shell: /sbin/nologin
		 create_home: no

	 - name: "下载解压"
	   unarchive:
		 src: http://nginx.org/download/{{ software }}-{{ version }}{{ format }}
		 dest: /usr/local/src
		 owner: nginx
		 group: nginx
		 remote_src: yes

	 - name: "编译需要的包"
	   yum:
		 name: 
		   - gcc
		   - pcre-devel 
		   - openssl-devel
		   - zlib-devel
		 state: present

	 - name: "编译"
	   shell:
		 chdir: /usr/local/src/{{ software }}-{{ version }}
		 removes: /usr/local/src/{{ software }}-{{ version }}/configure 
		 cmd: ./configure --prefix=/apps/nginx --user=nginx --group=nginx --with-http_ssl_module --with-http_v2_module --with-http_realip_module --with-http_stub_status_module --with-http_gzip_static_module --with-pcre --with-stream --with-stream_ssl_module --with-stream_realip_module ; make && make install

	 - name: "启动"
	  systemd:
		daemon_reload: yes
		name: nginx.service
		state: started
		enabled: yes

	 when: install == "dom" 

2.总结http协议版本和工作原理

HTTP/0.9（1991年）
只支持 GET 请求，只能传输纯文本，没有头部信息。
HTTP/1.0
增加了多种请求方法（GET、POST、HEAD），引入了 HTTP 头部信息，支持状态码和多媒体文件。
连接处理：每个请求都需要重新建立一次 TCP 连接（无连接性）。
HTTP/1.1
广泛使用的版本，提供了持久连接，允许复用同一个连接进行多个请求。引入了 Host 头部，支持虚拟主机
HTTP/2
引入了二进制分帧层，将数据分为更小的帧进行传输。支持多路复用（同一个连接中并行处理多个请求和响应）。
性能优化：提供了头部压缩（HPACK），和服务器推送（server push），显著减少了延迟和带宽消耗。
HTTP/3
特点：基于 UDP 而不是传统的 TCP，内置加密和连接复用，具有更快的连接建立时间和更好的抗丢包性能。

工作原理：
用户发起请求-服务器处理请求-服务器响应-客户端处理响应
用户发起请求：
客户端通过 URL（统一资源定位符）指定目标资源。
生成请求消息，包含请求行、请求头和可选的请求体。
服务器处理请求：
服务器接收到请求后，解析请求消息。
根据请求方法和资源路径，处理并生成响应消息。
响应消息包含状态行、响应头和可选的响应体。
服务器返回响应：
服务器将响应消息发送回客户端。
响应体可能包含 HTML 文档、图像、JSON 数据等。
客户端处理响应：
客户端解析响应消息。
根据响应头的信息处理响应体，呈现网页或处理数据。

3.总结IO模型和零复制技术的原理

五种io网络模型：

同步：synchronous，被调用者并不提供事件的处理结果相关的通知消息，需要调用者主动询问事
情是否处理完成
异步：asynchronous，被调用者通过状态、通知或回调机制主动通知调用者被调用者的运行状态

阻塞：用户需要一直等待IO操作完成才能返回用户空间
非阻塞：用户可以在等待io操作时做其他事情

1.阻塞IO
只有在内核将数据准备好前，系统调用会一直等待所有套接字，默认为阻塞方式

A拿着一支鱼竿在河边钓鱼，并且一直在鱼竿前等，在等的时候不做其他的事情，十分专心。只有鱼上钩的时，才结束掉等的动作，把鱼钓上来。

2.非阻塞io
每次客户询问内核是否有数据准备好，即文件描述符缓冲区是否就绪。当有数据报准备好时，就进行拷贝数据报的操作。当没有数据报准备好时，也不阻塞程序，内核直接返回未准备就绪的信号，等待用户程序的下一个轮寻。
但是，轮寻对于CPU来说是较大的浪费，一般只有在特定的场景下才使用。

B也在河边钓鱼，但是B不想将自己的所有时间都花费在钓鱼上，在等鱼上钩这个时间段中，B也在做其他的事情（一会看看书，一会读读报纸，一会又去看其他人的钓鱼等），但B在做这些事情的时候，每隔一个固定的时间检查鱼是否上钩。一旦检查到有鱼上钩，就停下手中的事情，把鱼钓上来。

3.信号驱动IO
信号驱动IO模型，应用进程告诉内核：当数据报准备好的时候，给我发送一个信号，对SIGIO信号进行捕捉，并且调用我的信号处理函数来获取数据报。

C也在河边钓鱼，但与A、B不同的是，C比较聪明，他给鱼竿上挂一个铃铛，当有鱼上钩的时候，这个铃铛就会被碰响，C就会将鱼钓上来。

4.IO多路转接
IO多路转接是多了一个select函数，select函数有一个参数是文件描述符集合，对这些文件描述符进行循环监听，当某个文件描述符就绪时，就对这个文件描述符进行处理。
其中，select只负责等，recvfrom只负责拷贝。
IO多路转接是属于阻塞IO，但可以对多个文件描述符进行阻塞监听，所以效率较阻塞IO的高。

D同样也在河边钓鱼，但是D生活水平比较好，D拿了很多的鱼竿，一次性有很多鱼竿在等，D不断的查看每个鱼竿是否有鱼上钩。增加了效率，减少了等待的时间。

5.异步IO
当应用程序调用aio_read时，内核一方面去取数据报内容返回，另一方面将程序控制权还给应用进程，应用进程继续处理其他事情，是一种非阻塞的状态。
当内核中有数据报就绪时，由内核将数据报拷贝到应用程序中，返回aio_read中定义好的函数处理程序。
很少有Linux系统支持，Windows的IOCP就是该模型。

零复制技术：
网络io到磁盘io通讯过程：
用户通过网络访问-访问进入内核空间socket缓存-复制到用户缓存-（需要使用磁盘）发到内核kernel缓存-内核使用DMA命令提取磁盘文件-复制到kernel缓存-缓存到用户空间，用户封装-发送到内核socket缓存-网络封装，最后到达用户
MMAP：
在用户空间做一个kernel缓存的映射，减少进入kernel缓存
的步骤，直接在用户空间访问kernel缓存
SENDFILE
取消用户空间的切换，直接都在内核空间进行转换和使用
DMA辅助的SENDFILE
直接使用kernel缓存