浏览器将分析输入。
通常情况下, 如果输入中有". com", 它不会认为你在输入搜索词而是判断这是一个url, 它会检查输入是否有协议头,如果没有, 它会在其开头添加"http://"。
由于你没有指定一系列http协议功能, 因此它将假定使用默认值, 如端口80、GET方法和无基本身份认证。
然后, 它将创建一个http请求并发送该请求。
( 我对我的底层网络知识没有信心, 但如果一定要说, 我会说一些关于MAC地址、TCP数据包传输、丢包处理等。
)但无论如何, 一个对"google. com"DNS的查找将会发生, 如果它还没有对此的缓存,DNS服务将应答一系列IP地址列表, 因为"google. com"不是单IP的网站,在默认情况下浏览器会选择第一个。
因此, http 请求从一个节点跳转到另一个节点, 直到它找到google. com负载均衡器的IP地址。
这不会持续很久, 谷歌会回应说, 你需要使用https-假定是301永久重定向。
它会原路返回到你的浏览器, 浏览器将协议更改为 https, 默认使用443端口并重新发送。
这一次,TLS握手将在负载均衡器和浏览器客户端之间进行。
我不是100%确定其工作原理, 但我知道该请求会告诉谷歌, 它支持什么协议 (TLS 1.0, 1.1, 1.2) ,然后谷歌将响应 "让我们使用1.2吧"。
之后使用TLS加密发送请求。
谷歌接下来要做的是将其放到负载均衡器上的网络应用程序防火墙规则集上, 看看它是否是一个恶意请求。
当这通过之后, 安全连接可能已被终止 (因为PCI-DSS规则规定你不需要加密内部流量), 请求将被分配到其CDN中的某个池上, 而google端缓存主页将在http响应中返回。
可能是预先压缩的。
谷歌的响应头将由浏览器读取,根据响应头的缓存策略进行缓存,然后正文将被解压缩。
而且因为这是谷歌,它可能是超优化的:
压缩,可能是许多预渲染内容、内联CSS、JavaScript和图像,以减少网络请求和首次渲染时间。
但该请求将触发一系列其他请求,所有这些请求都是并发的,因为它应该运行HTTP/2。
当这些请求正在进行时,JavaScript会被解析,可能没有阻塞,因为他们在标签上使用了defer属性 - 或者async。
但浏览器可能已经渲染了搜索框并且正在顶部的工具栏上工作,这将需要一些额外的网络请求 - 我可能已经有一个cookie或可能是带有OAuth令牌的本地存储 - 或我可能是使用Chrome并且它已经知道我是谁,并且使用auth的请求会被发送到他们的Google+ API上,告诉Google搜索页面的应用程序我的身份。
另一个请求将被发送, 以获取我的头像图像。
他们可能在浏览器上看看我是否未使用 chrome, 在这种情况下, 他们会有弹出一个工具栏提示, 告诉我:
chrome 是真的很棒, 我应该使用它, 而不是其他任何浏览器。
此时需要冷静下来,因为所有这些都发生在一秒以内。