这个问题已经是老生常谈了，更是经常被某厂作为面试的压轴题，网上也有很多文章但最近闲的无聊，然后就自己做了一篇笔记，大致流程URL 解析、DNS 查询、TCP 连接、处理请求、接受响应、渲染页面
第一步 URL地址解析;首先判断你输入的是一个合法的URL还是一个待搜索的关键词并且根据你输入的内容进行自动完成、字符编码等操作
第二步 浏览器去万网或者阿里云DNS查找该域名的IP地址判断是否存在
第三步 建立TCP连接(三次握手)发起http请求(浏览器根据解析得到的IP地址向web服务器发送一个HTTP请求)
第四步 服务器返回一个http请求响应
第五步 浏览器解析HTML代码并请求html中的静态资源（js,css）
第六步 浏览器对该响应进行解码渲染显示
第六步 页面显示完成后浏览器发送异步请求
第七步 关闭TCP连接（四次挥手）一、DNS域名解析
1.浏览器查找自己的DNS缓存，如果有直接返回，如果没有进行步骤二
2.操作系统查找自己的DNS缓存，如果有直接返回给浏览器，如果没有进行步骤三
3.操作系统查找自己的本地host文件，如果有返回给浏览器，如果没有则进行步骤四
4.操作系统向本地域名服务器发起请求，查找本地DNS缓存，如果有，返回给操作系统，然后操作系统返回给浏览器，如果没有进行步骤五5.操作系统向根域名服务器发起请求得到顶级域名服务器的IP，然后根域名服务器向顶级域名服务器发起请求得到权限域名服务器的IP，顶级域名服务器再向权限域名服务器发起请求得到IP，本地域名服务器返回给操作系统IP，同时将IP缓存起来，操作系统将IP返回给浏览器，同时将IP缓存起来
需要注意的地方：递归方式：一路查下去中间不返回，得到最终结果才返回信息（浏览器到本地DNS服务器的过程）
二、过程中使用到的协议
该过程中使用到了ARP,IP,SOFP
ARP（地址解析协议）：他主要解决的是同一个局域网内主机或路由器IP地址和MAC地址之间的映射问题。
工作过程：当源主机要发送数据的时候，他会查看自己的ARP高速缓存中是否有目的主机IP地址对应的MAC地址，如果与，则直接发送，如果没有，他就会向本网段所有主机发送ARP请求分组，接到请求的主机查看目的IP与自己的IP是否相等，如果不等就忽略，如果相等，就把源主机的IP和MAC写入自己的ARP高速缓存，如果之前有就覆盖掉，然后把自己的MAC写入ARP相应包，源主机接到ARP响应包后把目的主机的IP和MAC地址写入ARP高速缓存，并且利用此信息发送数据
| OSI七层模型 |
TCP/IP四层模型 |
对应网络协议 |
| 应用层（Application） | 应用层 | HTTP、TFTP, FTP, NFS, WAIS、SMTP |
| 表示层（Presentation） | Telnet, Rlogin, SNMP, Gopher | |
| 会话层（Session） | SMTP, DNS | |
| 传输层（Transport） | 传输层 | TCP, UDP |
| 网络层（Network） | 网络层 | IP, ICMP, ARP, RARP, AKP, UUCP |
| 数据链路层（Data Link） | 数据链路层 | FDDI, Ethernet, Arpanet, PDN, SLIP, PPP |
| 物理层（Physical） | IEEE 802.1A, IEEE 802.2到IEEE 802.11 |
OSI引进了服务、接口、协议、分层的概念，TCP/IP借鉴了OSI的这些概念建立TCP/IP模型。
OSI先有模型，后有协议，先有标准，后进行实践；而TCP/IP则相反，先有协议和应用，再提出了模型，且是参照OSI模型。
OSI是一种理论下的模型，而TCP/IP已经被广泛应用，称为网络互联实施上的标准
TCP与IP的区别
| TCP |
IP | |
| 连接方式 | TCP面向连接（如打电话要先拨号建立连接） | UDP是无连接的，即发送数据之前不需要建立连接 |
| 数据可靠性 | TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达 | UDP尽最大努力交付，即不保证可靠交付;因为UDP没有TCP那些可靠的机制，在数据传递时，如果网络质量不好，就会很容易丢包 |
| 技术性实施 | Tcp通过校验和重传控制、序号标识、滑动窗口、确认应答实现可靠传输；丢包时的重发控制可以对次序乱掉的分包顺序控制 | UDP具有较好的实时性，工作效率比TCP高，适用于对高速传输和实时性有较高的通信或广播通信 |
| 面向的对象 | 每一条TCP连接只能是点到点的 | UDP支持一对一，一对多，多对一和多对多的交互通信 |
| 对资源要求 | TCP对系统资源要求较多 | UDP对系统资源要求较少 |
| 工作效率 | 慢，效率低，占用系统资源高 |
快，UDP没有TCP的握手、确认、窗口、重传、拥塞控制等机制，UDP是一个无状态的传输协议，所以它在传递数据时非常快 |
| 安全性 | 因为TCP有确认机制、三次握手机制，这些也导致TCP容易被人利用，实现DOS、DDOS、CC等攻击.... | UDP较TCP被攻击者利用的漏洞就要少一些；但UDP也是无法避免攻击的，比如：UDP Flood攻击…… |
四、TCP建立连接三次握手、四次挥手
第一次握手：客户端发送一个TCP的SYN标志位置1的包指明客户打算连接的服务器的端口，以及初始序号X,保存在包头的序列号(Sequence Number)字段里。
第二次握手：服务器发回确认包(ACK)应答。即SYN标志位和ACK标志位均为1同时，将确认序号(Acknowledgement Number)设置为客户的ISN加1以.即X+1。
第三次握手：客户端再次发送确认包(ACK) SYN标志位为0,ACK标志位为1.并且把服务器发来ACK的序号字段+1,放在确定字段中发送给对方.并且在数据段放写ISN的+1
第一次挥手：客户端发送一个FIN，用来关闭服务端到Server的数据传送，客户端进入FIN_WAIT_1状态。
第二次挥手：服务端 收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），服务端进入CLOSE_WAIT状态
第三次挥手：服务端发送一个FIN，用来关闭Server到Client的数据传送，服务端进入LAST_ACK状态。
第四次挥手：客服端收到FIN后，服务端进入TIME_WAIT状态，接着发送一个ACK给服务端，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。
为什么连接的时候是三次握手，关闭的时候却是四次握手？
因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，”你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。
五、服务器收到浏览器发送的请求信息，返回一个响应头和一个响应体
1、HTTP 请求报文格式
Host:接收请求的服务器地址，可以是ip也可以是端口号
User-Agent：发送请求的应用程序名称
Connection:指定与连接相关的属性，Connection:Keep-Alive
Accept-Charset:指定可接收的编码格式
Accept-Encoding:指定可接收的数据压缩格式
Accept-Language:指定可以接收的语言2、HTTP响应报文格式
浏览器接收到来自服务器的响应资源后，会对资源进行分析。首先查看 Response header，根据不同状态码做不同的事（比如上面提到的重定向）如果响应资源进行了压缩（比如 gzip），还需要进行解压；然后对响应资源做缓存，根据响应资源里的 MIME[3] 类型去解析响应内容（比如 HTML、Image各有不同的解析方式）
http响应报文由状态行、响应头、空行、响应正文四部分组成
状态行：协议版本、状态码、状态描述，之间用空格分开
响应头：Server:服务器应用程序软件的名称和版本号
Content-Type:相应正文的类型（是图片还是二进制）
Content-Length:相应正文的长度
Content-Charset:相应正文的使用编码
Content-Encoding:相应正文使用的数据压缩格式
Content-Language:相应正文使用的语言六、页面渲染
浏览器收到服务器发送的响应头和响应体，进行客户端渲染，生成Dom树、解析css样式、js交互
不同的浏览器内核，渲染过程也不完全相同，但大致流程都差不多
