简要过程
1、使用DNS域名解析；
2、发起TCP的3次握手
3、建立TCP连接后发起http请求；
4、服务器响应http请求，浏览器得到返回response；
5、浏览器解析response，并请求其它的资源（如js、css、图片等）；
6、浏览器对页面进行渲染。
举个🌰
访问一个网址的时候，例如www.baidu.com，具体流程如下
- 对www.baidu.com这个网址进行DNS域名解析到IP
- 通过IP，使用ARP地址解析协议，找到对应的服务器，发起TCP三次握手
- 建立TCP请求后，发起HTTP请求（例如TOMCAT部署的springMVC程序）
- 服务器响应HTTP请求，返回RESPONSE
- 游览器解析response，并请求其它的资源文件（js、css等）
- 游览器进行渲染界面
注：DNS域名解析采用的是递归查询的方式，软考时有考过，先从本地的DNS缓存中查找—>缓存中没有的话就去找根域名服务器—–>根域名服务器找不到继续找下一级，这样递归查找到再返回给游览器。
具体细节
域名解析
1）首先会搜索浏览器自身的DNS缓存（缓存时间比较短，大概只有1分钟，且只能容·和他们纳1000条缓存）
2）如果浏览器自身的缓存里面没有找到，那么浏览器会搜索系统自身的DNS缓存
3）如果还没有找到，那么尝试从 hosts文件里面去找
4）在前面三个过程都没获取到的情况下，就递归地去域名服务器去查找，
TCP连接
到了大家都非常熟悉的三次🤝和四次👋流程
正常的QA：
Q: 为什么连接的时候是三次握手，关闭的时候却是四次握手？
A: 因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，”你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。
Q: 为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？
A: 一方面是为了等待这个客户重新连接的时候可以进行复用，另一方面必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。
Q: 如果TCP连接丢失了第三个ACK包怎么办？
A: 如果丢失了ACK包，SERVER端将该TCP连接的状态为SYN_RECV，并且依次等待3秒、6秒、12秒后重新发送SYN+ACK包，以便Client重新发送ACK包。如果超过设定的次数，将会断开连接。但是Client认为这个连接已经建立，如果Client端向Server写数据，Server端将以RST包响应，方能让Client感知到Server的错误。
参考资料