文章目录
- nginx 的配置
- nginx 命令行
- SSL／TLS 协议如何保证http消息安全的？
- 对称加密与非对称加密
- Nginx 的基础架构
- 1.Nginx 的请求流程
- 2.Nginx 的进程结构（多进程利用CPU,不会崩）
- 3. reload的内部实现
- 4.热升级的内部实现
- 5.优雅的关闭 worker 进程 (只有worker进程才会处理请求,主要针对http请求)
- 6. 网络收发与Nginx事件对应关系
- 6. Nginx事件驱动模型
- 7. Nginx中epoll的使用
- epoll_wait 获取句柄时，检测 rdlist 中事件有无就行了，ovflist 只是怕在拷贝的时候，产生新的事件的一个暂存的地方！！！！！
nginx 的配置
- 二进制
- nginx.conf
- access.log 记录http访问
- err.log 定位问题
nginx 命令行
- -g 覆盖配置文件
- -p 指定运行目录
- -c 使用指定的配置文件
- -s 发送信号
- -t,-T 检查配置文件语法
- -v 版本
重载：nginx -s reload
日志切割：nginx -s reopen 重新开一个日志文件
SSL／TLS 协议如何保证http消息安全的？
对称加密与非对称加密
性能好
在这里回答一个问题：如何不间断Nginx服务来升级Nginx?其实就是不能停止服务？
见 reload的内部实现
Nginx 的基础架构
1.Nginx 的请求流程
线程池处理阻塞
2.Nginx 的进程结构（多进程利用CPU,不会崩）
进程与线程的区别－－＞可以扯到Nginx的进程结构
master 中一般不会加入第三方模块
重点：一个master进程，多个worker 进程（干活的，与CPU核绑定），进程间通信采用共享内存
3. reload的内部实现
重点：
如何优雅关闭？：关闭监听－＞处理完连接后关闭进程
原先的master进程不会退出，为了版本回退
有可能原先的worker 进程出现了客户端长时间没有处理，这里最新的Nginx 建立了一个定时器
旧的就只是存在多一个进程而已．
4.热升级的内部实现
不对 master 进程发送信号
5.优雅的关闭 worker 进程 (只有worker进程才会处理请求,主要针对http请求)
- 设置定时器
worker_shutdown_timeout - 关闭监听句柄
- 关闭空闲连接（连接池中的连接）
- 在循环中等待全部连接关闭
- 退出进程
6. 网络收发与Nginx事件对应关系
6. Nginx事件驱动模型
epoll_wait -> worker进程 -> 从kernel 取出->
Nginx会让CPU密集型的第三方模块分段使用CPU
7. Nginx中epoll的使用
Nginx如何从kernel中获得就绪事件? 2.6内核之前（出现epoll）
epoll_wait 获取句柄时，检测 rdlist 中事件有无就行了，ovflist 只是怕在拷贝的时候，产生新的事件的一个暂存的地方！！！！！
（1）什么是活跃的连接?
正在进行请求与响应的连接
（2）红黑树是如何知道有事件到来的？
网卡发现报文后，内核可以直接从地址定位到事件（感觉这个就可以回答开心学长 的提问了，哈哈哈）
（3）事件的操作
- 当需要操作（添加，删除，修改）某个事件时，操作的是树；O(logn)
- 当某个事件发生时，系统把它加入到链表中。
（4）epoll 的好处?
- 基于epoll的事件多路复用减少了进程间切换的次数，使得操作系统少做了相对于用户任务来说的无用功。(相对于原先的多进程模型来讲（一个事件一个进程）)
- epoll比select等多路复用方式来说，减少了遍历循环及内存拷贝的工作量，因为活跃连接只占总并发连接的很小一部分。
8. Nginx的请求切换
可以看出，Nginx在用户态完成了切换，这就和协程很像了，不是吗？
这个协程其实是用nginx的事件驱动机制实现的