轻松解决百万并发的Nginx，你知道它是怎么处理这些网络事件的吗

接下来看上面这张图，比如主机 A 就是一台家里的笔记本电脑，那么主机 B 就是一台服务器，上面跑着 Nginx 服务。从主机 A 发送一个 HTTP 的 GET 请求到主机 B，这样的一个过程中主要经历了哪些事件?通过上图数据流部分可以看出：

应用层里发送了一个 GET 请求 -> 到了传输层，这一步主要在做一件事，就是浏览器打开了一个端口，在 windows 的任务管理器中可以看到这一点，他会把这个端口记下来以及把 Nginx 打开的端口比如 80 或者 443 也记到传输层 -> 然后在网络层会记下我们主机所在的 IP 和目标主机，也就是 Nginx 所在服务器公网 IP -> 到链路层以后 -> 经过以太网 -> 到达家里的路由器(网络层)，家中的路由器会记录下所在运营商的一些下一段的 IP -> 通过广域网 -> 跳转到主机 B 所在的机器中 -> 报文会经过链路层 -> 网络层 -> 到传输层，在传输层操作系统就知道是给那个打开了 80 或者 443 的进程，这个进程自然就是 Nginx -> 那么 Nginx 在他的 HTTP 状态处理机里面(应用层)就会处理这个请求。

在上述过程中网络报文扮演了一个怎样的角色呢?

数据链路层会在数据的前面 Header 部分和 Footer 部分添加上源 MAC 地址和源目的地址 -> 到了网络层则是 Nginx 的公网地址(目的 IP 地址)和浏览器的公网地址(源 IP 地址)-> 到了 TCP 层(传输层)，指定了 Nginx 打开的端口(目的端口)和浏览器打开的端口(源端口)-> 然后应用层就是 HTTP 协议了。

这就是一个报文，也就是说我们发送的 HTTP 协议会被切割成很多小的报文，在网络层会切割叫 MTU，以太网的每个 MTU 是 1500 字节;在 TCP 层(传输层)呢会考虑中间每个环节中最大的一个 MTU 值，这个时候往往每个报文只有几百字节，这个报文大小我们称为叫 MSS ，所以每收到一个 MSS 小于这么大小的一个报文时其实就是一个网络事件。

这个时候，我们来看下 TCP 协议中许多事件是怎样和我们日常调用的一些接口(比如Accept、Read、Write、Close)是怎样关联在一起的?

TCP 协议与非阻塞接口

（编辑：常州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!