究竟会发生些什么？ 首先，浏览器将会分析你输入的内容。通常，如果输入的内容里包含了“.com”，浏览器不会认为你输入的是一个搜索关键字。在确定它是一个 URL 之后，浏览器会检查它是否指明了某种协议，如果没有，就会在开头添加“http://”。因为你没有指定具体的 HTTP 协议选项，所以浏览器会使用默认值，如端口 80、GET 方法、不使用基本的身份验证。 然后它会创建一个 HTTP 请求并将请求发送出去。我对底层的网络知识不是很了解，否则我会说一些有关 MAC 地址、TCP 数据包传输、如何处理数据包丢失的东西。但不管怎样，它肯定会先进行 DNS 查找，如果在缓存中找不到，DNS 服务会返回一个 IP 地址列表，因为“google.com”不只对应一个 IP 地址。浏览器会默认选择第一个。我不确定它们是否具有区域性，也不知道究竟是如何使用 IP 地址列表的，我只知道有这么一串 IP 地址存在。 HTTP 请求从一个节点跳到另一个节点，直到到达 google.com 负载均衡器的 IP 地址。这不会持续很长时间，谷歌会告诉你需要使用 HTTPS——假设它会使用 301 状态码来告诉你需要进行重定向。这个状态码被发送回你的浏览器，浏览器将协议改为 HTTPS，使用默认的 443 端口，并重新发送请求。这次，在负载均衡器和浏览器之间会发生 TLS 握手。我不是百分之百清楚握手过程是怎么回事，但我知道请求会告诉 Google 它支持哪些协议（TLS 1.0,1.1,1.2），Google 会回答“那就让我们使用 1.2 吧”，然后就通过 TLS 加密发送请求。 我认为 Google 要做的下一件事是通过负载均衡器上的 Web 应用程序防火墙规则来检查它是否是恶意请求。在通过检查后，安全连接可能就终止了（因为 PCI-DSS 安全标准规定不需要加密内部流量），请求将被分配到 CDN 池中，然后通过 HTTP 响应返回 Google 主页，可能是预先压缩过的。 浏览器将读取返回的消息响应头，根据响应头的缓存策略对内容进行缓存，然后正文将被解压缩。Google 可能对消息做过优化，比如对正文进行了缩小化，包括很多预渲染内容、内联 CSS、JavaScript 和图像，以便减少网络请求数和首次渲染时间。然后这个请求将触发一系列其他请求，所有这些请求都是并发的，因为使用了 HTTP/2。在发出这些请求的同时，JavaScript 会被解析，可能会使用非阻塞模式，因为标签上使用了 defer 或 async。 此时，浏览器可能已经渲染好了搜索框，并对顶部的工具栏做一些事情，这需要一些额外的网络请求——我可能已经有 Cookie 了，或者是带有 OAuth 令牌的本地存储——或我使用的是 Chrome，所以它已经知道我是谁，然后将请求和认证信息发送给 Google+ API，告诉 Google 搜索应用程序我是谁。 另一个请求将被发送给服务器，用来获取我的头像。这个时候，他们可以嗅探我是不是在使用 Chrome，如果不是，他们会弹出一个工具提示框，告诉我 Chrome 有多好，我应该使用它而不是其他浏览器。 我认为差不多就是这样，一切都发生在一眨眼的功夫内。

搜索