浏览器将分析输入。通常情况下, 如果输入中有". 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搜索页面的应用程序我的身份。
我知道我以前见过google.com返回包中带有多个IP地址,但似乎不再是这种情况了。似乎他们之前常常使用轮巡策略,但现在不再使用了。 这个StackOverflow提问涉及了此情况。我已忘记了它被称为轮2。
在一个正式结构化回答中,你可能会参考我有所了解但并不精通的OSI模型。在查阅资料之后,我将它视为如下的网络分层映射:
应用 - 触发请求的逻辑
表示层 - HTTP
会话 - TLS
传输 - TCP
网络 - 路由 (IP)
数据链路 - 帧 (可看做数据包的容器)
物理层 - 比特流
我记得在TLS中他们会在协议协商时交换证书。
网络并不是我的强项。
我记得主机名规范化——这是一个301。
从HTTP到HTTPS的校正是一个307内部重定向。
然后它下载字体、商标图像和我的头像图像。如果没有API调用,这意味着他们会在页面中推送我的个人资料信息并将其与返回数据捆绑在一起 - 因此当你点击google.com而不仅仅是提供缓存资产时,他们会进行实际的数据检索。
评论删除后,数据将无法恢复
评论(64)
引用来自“kang138”的评论
我还以为你要教我访问google!!!!!!google.com 的响应时间过长。
请试试以下办法:
检查网络连接
检查代理服务器和防火墙
运行 Windows 网络诊断
ERR_CONNECTION_TIMED_OUT
这才是真实发生的结果。