浏览器输入一个URL之后发生了什么？
- URL解析
- DNS解析
- TCP连接
- TSL连接
- HTTP请求
- TCP挥手
- 接收并解析响应
URL 解析
主要分为：
- 协议，eg http,https
- 域名或者ip地址，eg www.baidu.com
域名相对于ip地址来说，更方便人们记忆，但是实际的网络传输中使用的是ip地址
- 端口号，不同的协议对应不同的端口号，一般可以不写，eg http是80，https是443
- 请求的资源或路径，默认不写就是 /index
DNS 解析
根据域名找到对应的ip
首先会在本机查找浏览器缓存，如果没有查操作系统缓存
如果还没有，就后台向本机已经通过DHCP配置好的DNS服务器发起一个查询递归请求
DNS服务器会首先查询自己的缓存，如果没有就向分布式DNS域名系统发起迭代查询，依次是根域名服务器，顶级域名服务器，权限域名服务器
TCP连接
- 第一次发送连接请求
- SYN=1表示这是一个TCP连接请求报文段
- seq设为x,作为TCP客户进程所选的初始序号
- TCP规定SYN=1的报文段不能携带数据，但要消耗掉一个序号
- 第二次发送请求连接请求确认报文段
- SYN=1和ACK=1表示这是一个TCP连接请求确认报文段
- seq设为y,作为TCP服务进程所选的初始序号
- ack=x+1,这是对TCP客户进程所选的初始序号的确认
- 因为SYN=1，所以不能携带数据，但要消耗掉一个序号
- 第三次发送请求连接确认的确认
- ACK=1,表示这是一个普通的TCP确认报文段
- seq=x+1,第一次发送请求连接，TCP客户进程所选的初始序号x,不携带数据，但是消耗一个序号
- ack=y+1,这是对TCP服务进程所选的初始序号的确认
- 普通的确认报文段可以携带数据
- 如果不携带数据，则不消耗序号；在这种情况下，下一个发送的序号seq仍为x+1
q: 第三次确认是否多余？
不多余。这是为了防止已失效的连接请求报文段突然又传到了服务器而导致错误，造成服务端资源浪费
假如我们把连接改为两次握手，就会产生如下错误情况
TSL 连接
q: Http和Https的区别？
- Http是明文传输，容易遭到窃听和篡改，Https对传输内容做了加密
- Http缺乏报文完整性验证，Https对报文做了验证
- Http缺乏身份验证，Https加入了身份验证机制
- 两者的默认端口不一样，HTTP 默认端口号是 80，HTTPS 默认端口号是 443。
如果你输入http://www.taobao.com ， 你首先会获得一个重定向的响应
然后浏览器重新发起对https://www.taobao.com 的请求
TSL 连接的过程如下：
消息发送与验证
HTTP请求
建立连接后，浏览器发起Http请求，Http报文如下
TCP 挥手
客户端和服务端都可以释放连接
- 第一次发送释放连接请求
- FIN=1和ACK=1,表示这是一个TCP连接释放报文段
- seq=u,u为上一次发送请求的seq+1，即已传发送过的字节序号+1
- ack=v,表示对上一次请求确认的确认 ，即服务端已收到的字节序号+1
- TCP规定FIN=1的报文段即使不携带数据也要消耗一个序号
- 第二次发送对释放连接请求的确认
- ACK=1，表示这是一个普通的确认
- seq=v,v为服务端以收到的字节序号+1（正好和第一次请求的ack一致）
- ack=u+1,这是对连接释放报文段的确认
中间服务端可能还要有数据进行发送
- 第三次发送，TCP服务端发送TCP连接释放报文段
- FIN=1和ACK=1,表示这是一个TCP连接释放报文段
- seq=w，是因为服务端可能又发送了若干数据
- ack=u+1是对第一次请求连接释放报文段的重复确认
- 第四次TCP客户端发送普通确认报文段
- ACK=1，表示这是一个普通的确认
- seq=u+1,是因为第一次发送请求时消耗了一个字节序列
- ack=w+1，这是对第三次请求的确认
q: 最后等待2MSL是否有必要？
有必要。如果最后一次TCP报文段丢失，则服务端会一直等待或者重传，浪费资源
q: 服务端如何发现客户端故障？
接收并解析响应
参考资料
- 浏览器输入url发生了
- 在浏览器输入 URL 回车之后发生了什么（超详细版） - 知乎 (zhihu.com)
- 从输入URL到页面加载的过程？如何由一道题完善自己的前端知识体系！ | Dailc的个人主页 (dailichun.com)