作者回复: 对,口误啦,谢谢指出。对于请求而言,才需要大量上下文信息,连接不需要。
作者回复: 后端慢的话,可以考虑nginx加缓存来缩短响应时间,或者压测客户端增大读超时时间。499是客户端读超时关连接造成的,加了proxy_ignore_client_abort on; 也不解决问题。推荐从超时时间或者优化响应速度入手。
作者回复: 谢谢
作者回复: nginx打印access.log时,这条请求的response肯定已经发出去了,但只是nginx进程把write请求提交给linux kernal了,至于kernal有没有发到交换机,交换机有没有给到机房的路由器,有没有从广域网发到客户网络,等等,都是不可知的。
如果抓包不现实,那么就看端口吧,把remote_addr和remote_port打印到access日志中,然后对照浏览器上的src_port看。
作者回复: 第5部分课程也涉及较多OS知识
作者回复: 抓个包,access日志把remoteaddr和remoteport也打印下,看看是不是因为丢包先
作者回复: 不太一样,nginx内存池与http协议相关度很大,当请求结束时、连接关闭时统一释放。
作者回复: 进程防止DDOS攻击效果不行,大规模的攻击下还没到进程就已经崩了。如果只是应对小流量,可以考虑openresty+waf
作者回复: 压测工具超时设置大一些
作者回复: 在第3部分的第3课会讲它们的区别和使用场景。
作者回复: 预先分配一部分,但没有释放,仅在请求结束后全部释放掉该内存池。第3部分课程里,会详细介绍,包括对应着哪些指令。