面试题:在浏览器输入“google.com”后都发生了什么?

百家 作者:聊聊架构 2018-09-19 12:01:41

“在浏览器地址栏中输入 google.com,然后按下回车键,之后会发生些什么?”

这是我最喜欢的面试题之一。有人可以连续说上几天,试图完整地回答这个问题。我也想说说我的答案。当我在一个面试中被问到这个问题时,我滔滔不绝地讲了 10 分钟,直到面试官打断了我。然后,即使是在面试结束之后,我还在想有些东西还没有讲完。

那么究竟会发生些什么?

首先,浏览器将会分析你输入的内容。通常,如果输入的内容里包含了“.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 有多好,我应该使用它而不是其他浏览器。

我认为差不多就是这样,一切都发生在一眨眼的功夫内。

有哪些明显不一样的地方?

让我们来看看 DNS 查找:

我以前见过 google.com 会返回多个 IP 地址,但现在可能不再是这种情况了。他们以前似乎使用了 round-robin,但现在不再使用这种方式了。StackOverflow 上有个问题对此进行了解答(https://stackoverflow.com/questions/10257969/is-it-possible-that-one-domain-name-has-multiple-corresponding-ip-addresses)。

网络层

在正式回答这个问题时,你可能会提到 OSI 模型,虽然我也知道这个模型,但并不精通。经过一番研究之后,我发现网络层是这样的:

  1. 应用层——发起请求的逻辑

  2. 表示层——HTTP

  3. 会话层——TLS

  4. 传输层——TCP

  5. 网络层——数据包路由(IP)

  6. 数据链路层——帧(就像是数据包的容器)

  7. 物理层——比特流

在进行 TLS 握手时,在确定协议之后它们会交换证书,这点被我漏掉了。网络方面的知识不是我的强项。

在浏览器中打开 google.com,并禁用缓存:

  • 我漏掉了主机名规范化——是一个 301 状态码。

  • 从 HTTP 到 HTTPS 的纠正是一个 307 内部重定向。

  • 然后它下载字体、logo 图像和我的头像。没有 API 调用,说明他们在页面中推送我的个人信息,并将其与响应消息捆绑在一起。

响应消息

以上是 IE 11 和 Chrome 响应消息的比较。

  • IE11 和 Chrome 之间没有太大的不同。这说明他们是在服务器端而不是客户端进行 user-agent 嗅探,我可以在回答问题时提到这一点。

  • 出乎意料的是,Chrome 的响应消息大了 22KB。我在想是不是因为语音搜索功能导致的,因为在 IE 11 中没有这项功能。IE11 可能需要 polyfill 并进行 Chrome 推广,但这有点扯远了,我也不想再进一步折磨自己了。

  • 即使我在 Chrome 中清除了 Cookie,它仍会在第一次请求时发送 Cookie,但在 IE 11 中不会这样。

让我们来了解一下渲染机制!

上面是 Chrome 为你渲染的第一个页面。

  • script 标签上没有使用 async 或 defer 属性,只有 nonce 属性。我正在了解 nonce,它似乎与安全有关。我猜他们想要使用这些阻塞脚本。我敢确定他们在某个时候对 async 和 defer 进行过 fiddle 分析,最后决定不使用这两个属性。

  • 需要注意的是:完整的响应消息包含了一堆乱七八糟的 JavaScript、CSS 和 HTML 混合代码。他们没有遵循任何代码拆分规则。

现在回到这个问题本身

对于开发人员而言,这可能不是一个很好的面试问题,因为答案涉及到太多网络知识。但这是我喜欢的问题类型,因为是开放性的,还包含了一些猜测的成分。面试官因此就有机会问候选人“你认为 TLS 是如何建立的”之类的问题,看看候选人如何思考,看看他们的创意能力,看看他们的极限是什么(比如是不是有耐心)。

那么,你最喜欢的面试问题是什么?

英文原文:https://dev.to/antonfrattaroli/what-happens-when-you-type-googlecom-into-a-browser-and-press-enter-39g8


腾讯 AI Lab 近日发布世界上首款自动化深度学习模型压缩框架 PocketFlow,据悉,这是一款面向移动端 AI 开发者的自动模型压缩框架。

从市面上热门的 Caffe、TensorFlow、CNTK、Keras 等到腾讯最新发布的 PocketFlow,AI 框架多种多样,更有向移动端倾斜的趋势。面对企业中的不同业务线,我们该如何选择适合自己的框架?如何规避不同框架的缺点将优势最大化?

AICon 全球人工智能与机器学习技术大会上,老师木将作为出品人,与大家一起探讨 AI 工具和框架选型,以及 AI 平台搭建,企业如何基于已有大数据基础设施引入人工智能平台,有哪些难点,需要注意哪些事情等,还将讨论如何构建一个专门的人工智能团队,并为团队成员配备必要的知识和技能,以便让他们能够正确应用 AI 技术。

大会 6 折报名倒计时最后两周,感兴趣的小伙伴识别下图二维码或点击“阅读原文”即可报名,团购更优惠,详情咨询:18514549229(同微信)。

关注公众号:拾黑(shiheibook)了解更多

[广告]赞助链接:

四季很好,只要有你,文娱排行榜:https://www.yaopaiming.com/
让资讯触达的更精准有趣:https://www.0xu.cn/

公众号 关注网络尖刀微信公众号
随时掌握互联网精彩
赞助链接