一个完整的 Web 请求到底发生了什么

阅读本文大概需要 7 分钟。

一、从输入一个网址开始

当我们在浏览器输入一个网址，然后按下回车，接下来浏览器显示了页面。网速好的话这之间可能就一秒，但在这一秒内到底发生了什么？

本文主要内容是试图记录一个完整 Web 请求的详细过程，从用户在浏览器中输入 URL 地址说起，然后浏览器如何找到服务器地址的过程，并发起请求；分析请求在达反向代理服务器内部处理过程；最后到请求在服务器端处理完成后，浏览器渲染响应页面过程。

大致过程如下：

Web请求的工作原理可以简单地归纳为：

浏览器通过 DNS 把域名解析成对应的IP地址；
根据这个 IP 地址在互联网上找到对应的服务器，建立 Socket 连接；
客户端向服务器发送HTTP协议请求包，请求服务器里的资源文档；
在服务器端，实际上还有复杂的业务逻辑：服务器可能有多台，到底指定哪台服务器处理请求，这需要一个负载均衡设备来平均分配所有用户的请求；
还有请求的数据是存储在分布式缓存里还是一个静态文件中，或是在数据库里；
当数据返回浏览器时，浏览器解析数据发现还有一些静态资源（如：css，js或者图片）时又会发起另外的请求，而这些请求可能会在CDN上，那么CDN服务器又会处理这个用户的请求。
客户端与服务器断开。由客户端解释HTML文档，在客户端屏幕上渲染图形结果。

一个 HTTP 事务就是这样实现的，看起来很简单，原理其实是挺负责的。需要注意的是客户机与服务器之间的通信是非持久连接的，也就是当服务器发送了应答后就与客户机断开连接，等待下一次请求。

但需要注意的是，从 HTTP 1.1 开始，服务器可以与客户端保持长连接，不一定是请求完成后就断开连接，这取决于服务器的操作。

二、DNS 域名解析

首先来看看最先发生的事情——DNS 域名解析，简单的说就是把域名翻译成 IP 地址。例如：把 www.test.com 这个域名翻译成对应 IP 192.168.1.1，这里只是举个例子。

如果你在浏览器中直接输入的 IP 地址，那么实际上会跳过这个步骤，否则会经理下面几部：

1、浏览器缓存检查

浏览器会首先搜索浏览器自身的 DNS 缓存，缓存时间比较短，大概只有1分钟，且只能容纳1000条缓存，看自身的缓存中是否有对应的条目，而且没有过期，如果有且没有过期则解析到此结束。

2、操作系统缓存检查 + hosts 解析

如果浏览器的缓存里没有找到对应的条目，操作系统也会有一个域名解析的过程，那么浏览器先搜索操作系统的 DNS 缓存中是否有这个域名对应的解析结果，如果找到且没有过期则停止搜索，解析到此结束。

在 Linux 中可以通过 /etc/hosts 文件来设置，可以将任何域名解析到任何能够访问的 IP 地址。如果在这里指定了一个域名对应的 IP 地址，那么浏览器会首先使用这个 IP 地址。当解析到这个配置文件中的某个域名时，操作系统会在缓存中缓存这个解析结果，缓存的时间同样是受这个域名的失效时间和缓存的空间大小控制的。

3、本地区域名服务器(Local DNS Server)解析

如果在 hosts 文件中也没有找到对应的条目，浏览器会发起一个 DNS 的系统调用，会向本地配置的首选 DNS 服务器发起域名解析请求（通过的是 UDP 协议向 DNS 的 53 端口发起请求，这个请求是递归的请求，也就是运营商的DNS服务器必须得提供给我们该域名的IP地址）。

在我们的网络配置中都会有“DNS 服务器地址”这一项，这个地址就用于解决前面所说的如果两个过程无法解析时要怎么办。操作系统会把这个域名发送给这里设置的 LDNS，也就是本地区的域名服务器。

这个 DNS 通常都提供给你本地互联网接入的一个 DNS 解析服务，例如你是在学校接入互联网，那么你的 DNS 服务器肯定在你的学校；如果你是在一个小区接入互联网的，那这个 DNS 就是提供给你接入互联网的应用提供商，即电信或者联通。大约 80% 的域名解析都到这里就已经完成了，所以 LDNS 主要承担了域名的解析工作。

4、根域名服务器解析(Root Server)

如果 LDNS 没有找到对应的条目，则由运营商的 DNS 代我们的浏览器发起迭代 DNS 解析请求。它首先是会找根域的 DNS 的 IP 地址，找到根域的 DNS 地址，就会向其发起请求。然后根域名服务器返回给本地域名服务器一个所查询域的主域名服务器(gTLD Server)地址。

5、主域名服务器(gTLD Server)

本地域名服务器(LDNS Server)再向上一步返回的 gTLD 服务器发送请求。

接受请求的 gTLD 服务器查找并返回此域名对应的 Name Server 域名服务器的地址，这个 Name Server 通常就是你注册的域名服务器，例如你在某个域名服务提供商申请的域名，那么这个域名解析任务就由这个域名提供商的服务器来完成。

Name Server 域名服务器会查询存储的域名和IP的映射关系表，正常情况下都根据域名得到目标IP记录，连同一个 TTL 值返回给 DNS Server 域名服务器。

下图汇总了上面所说的 DNS 解析过程：

三、TCP 的 3 次握手

拿到域名对应的 IP 地址后，User-Agent（一般是指浏览器）会以一个随机端口（1024 < 端口 < 65535）向服务器的 WEB 程序发起 TCP 的连接请求。

这里还涉及 ARP（地址解析协议）：是根据 IP 地址获取物理地址 (MAC 地址) 的一个协议。
当一个数据帧经过多次路由到达目的网络时，路由器只能知道其数据帧中的目的 IP 地址，而不知目标主机的硬件地址，网络层使用的是 IP地址，但是在实际网络链路上传送数据帧时，最终必须使用该网络的硬件地址，此时需要目的主机的硬件地址，就要使用 ARP 来获取到对应 IP 地址主机的物理地址。

这个连接请求（原始的 Http 请求经过 TCP/IP 4层模型的层层封包）到达服务器端后（这中间通过各种路由设备，局域网内除外），进入到网卡，然后是进入到内核的 TCP/IP 协议栈（用于识别该连接请求，解封包，一层一层的剥开），还有可能要经过Netfilter防火墙（属于内核的模块）的过滤，最终到达WEB程序，最终建立了TCP/IP的连接。

Client 首先发送一个连接试探，SYN = 1 表示这是一个连接请求或连接接受报文，同时表示这个数据报不能携带数据，seq = x 表示 Client 自己的初始序号（seq = 0 就代表这是第 0 号包），这时候 Client 进入 syn_sent 状态，表示客户端等待服务器的回复。
Server 监听到连接请求报文后，如同意建立连接，则向 Client 发送确认。报文中的 SYN 和 ACK 都置 1 ，ACK = x + 1 表示期望收到对方下一个报文段的第一个数据字节序号是 x+1，同时表明 x 为止的所有数据都已正确收到（ACK = 1 其实是 ACK = 0 + 1，也就是期望客户端的第 1 个包），seq = y 表示 Server 自己的初始序号（seq = 0 就代表这是服务器这边发出的第 0 号包）。这时服务器进入 syn_rcvd，表示服务器已经收到 Client 的连接请求，等待确认。
Client 收到确认后还需再次发送确认，同时携带要发送给 Server 的数据。ACK 置 1 表示确认号 ack= y + 1 有效（代表期望收到服务器的第 1 个包），Client自己的序号 seq= x + 1（表示这就是我的第1个包，相对于第0个包来说的），一旦收到Client的确认之后，这个TCP连接就进入 Established 状态，就可以发起请求了。

具体流程可以参看我之前的一篇文章《TCP、UDP、HTTP、HTTPS》。

四、Nginx 反向代理

1、反向代理

反向代理（Reverse Proxy）方式是指：代理服务器来接受 Internet 上的连接请求，然后将请求转发给内部网络上的服务器，并将从内部网络上服务器得到的结果返回给 Internet 上请求连接的客户端。此时代理服务器对外就表现为一个服务器，反向代理服务器对于客户端而言它就像是原始服务器，并且客户端不需要进行任何特别的设置。

反向代理的作用：

保证内网的安全，可以使用反向代理提供 WAF 功能，阻止 web 攻击。
负载均衡，通过反向代理服务器来优化网站的负载。

2、正向代理

既然有反向代理，就肯定有正向代理。什么叫正向代理呢？

正向代理（Forward Proxy）通常都被简称为代理，就是在用户无法正常访问外部资源，可以通过代理的方式，让用户绕过防火墙，从而连接到目标网络或者服务。

正向代理的工作原理就像一个跳板。

比如：我访问不了 google.com，但是我能访问一个代理服务器 A，A 能访问 google.com，于是我先连上代理服务器 A，告诉它我需要 google.com 的内容，A 就去取回来，然后返回给我。

从网站的角度，只在代理服务器来取内容的时候有一次记录，有时候并不知道是用户的请求，也隐藏了用户的资料，这取决于代理告不告诉网站。

正向代理是一个位于客户端和原始服务器(origin server)之间的服务器。为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向原始服务器转交请求并将获得的内容返回给客户端。

3、正向代理与反向代理对比

五、关闭 TCP 连接

这一步不是所有的网页都会这么做，例如网页版微信就没有关闭 TCP 连接，因为微信上别人可以随时发消息给你，实际上别人先把消息发送到了微信服务器，微信服务器再通过 TCP 链接，把消息推送到你的屏幕上。

试想一下，如果网页版微信关闭了 TCP 连接会怎样？

结果是：你不刷新网页，就永远收不到消息了。同时，如果你频繁的发消息给别人，那么就在频繁的创建连接，关闭连接，这是很消耗资源的。所以微信就干脆不关闭 TCP 连接，这样微信服务器就可以给我们的浏览器发消息。

下图是一次 Http 请求报文头部信息，其中 Connection: keep-alive 意味着这次请求结束后不会关闭 TCP 连接。

当然不是所有的 HTTP 请求都没有关闭连接，例如一篇博文，浏览器收到数据显示就可以了，没有那么多动态数据，我看完就关了，这时就应该关闭 TCP 连接，当然这还是取决于请求的服务器。说了这么多，还没说关闭连接。

关闭 TCP 连接专业点说叫做“四次挥手”，与 TCP 建立连接的“三次握手”相对应。

由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个 FIN 来终止这个方向的连接。收到一个 FIN 只意味着这一方向上没有数据流动，一个TCP连接在收到一个 FIN 后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。

具体流程可以参看我之前的一篇文章《TCP、UDP、HTTP、HTTPS》。

至此，一个 Web 请求的大致流程差不多就是这样，东西还是挺多的，如果有不完善的地方，欢迎大家补充。

参考链接
https://www.jianshu.com/p/558455228c43

·END·

程序员的成长之路

路虽远，行则必至

微信ID:cxydczzl

往期精彩回顾

没执行过 rm -rf /* 的开发不是好运维

你与一份好简历之间的距离

还在使用SimpleDateFormat？

Java程序员的成长之路

送给程序员们的经典电子书大礼包