当在浏览器输入一个 github.com 的请求
浏览器会检查后缀是否有 .com 从而判断得出这不是一个搜索关键词，而是一个 Url，如果没有其他的东西，则会赋予一些默认值，例如 http:// ，80 端口以及 GET 方法，无基本的身份认证。
然后请求会先经过本地 DNS 解析或者去下一个节点进行 DNS 解析，直到找到 github.com 负载均衡的 IP 地址。可惜对网络底层不太了解，要不然也能对 TCP/IP 说个一二三四出来。
image
接下来 github.com 回应说需要使用 https 307 内部重定向。因此原路返回到浏览器，浏览器将协议改为 https，默认使用 443 端口并重新发送，并使用 github 支持的什么协议 (TLS 1.0，1.1，1.2)，加密过后发送请求。
github 的负载均衡服务器会将请求放到网络应用防火墙的规则集上进行判断这是否是一个恶意的请求，如果不是则会将准备好的正文放在 http 响应中返回，可能有一些东西是早已经压缩好的。
浏览器会读取 github 的响应头，根据响应头的缓存策略进行缓存，然后将正文解压缩，可能有很多预渲染的内容，内联 CSS，JavaScript 和图像，用来减少网络请求和首次渲染时间。谁知道他们会做什么事情
此时可能还有一些额外的请求，可能本地保存了相关的 Cookie 或者是 OAuth 令牌的本地存储，这些东西都会发送到 github 用来认真我的身份，从而返回我的相关信息，昵称头像之类的...
我想即使是对网络在不熟悉的人都会听说过 OSI 七层模型
从上到下是
- 应用层 - 出发请求的逻辑
- 表示层 - HTTP
- 会话层 - TLS
- 传输层 - TCP
- 网络层 - 路由(IP)
- 数据链路层 - 帧(数据单元)
- 物理层 - 比特流
我大概也就了解这么多了
全新Chrome Devtool Performance使用指南
网友评论