概览日期：2018-4-26目标：了解从输入URL到页面加载完成的过程总时间：一天完成状态：基本流程就实现了。为什么想知道从输入网址到页面加载完成的过程中发生了什么？因为课程参考资料中的建站技术包括HTML、HTML5、XHTML、CSS、SQL、JavaScript等，PHP、ASP.NET、WebServices最受欢迎的答案是什么？一，而且这张图只是展示了一个很基本的前后端交互流程。由于自己有基础，基本了解所列的相关概念，所以会抽出时间和我一起拓展学习。当您打开浏览器并输入一个URL时，您是否发现浏览器会为您提供一些您似乎知道并且与您键入的内容匹配的URL？实际上，当我们在浏览器中输入网址时，浏览器就会开始智能匹配可能出现的网址。浏览器会从历史、书签等中找到可能对应你输入的字符串的URL，然后进行智能提示，输入URL后，我们按下回车键，浏览器就会发起请求。如果URL是域名而不是IP地址，则进行域名解析。什么是域名解析？IP地址是标识网络上站点的数字地址。为了方便记忆，这里用域名代替IP地址来标识站点地址。域名解析是域名到IP地址的转换过程。域名解析是按照以下步骤进行的（部分内容涉及计算机网络知识）：我们本地硬盘下有一个hosts（windows下路径为C:\Windows\System32\drivers\etc）文件,用于将一些常用的网站域名转换与其对应的IP地址建立关联的“数据库”。一般来说，系统会先自动从hosts文件中寻找对应的IP地址。如果有，会直接使用hosts文件中的IP地址，然后直接确认端口。如果上一步没有找到，浏览器就会调用解析程序。并成为DNS服务器的客户端，将需要解析的域名放在DNS请求报文中，以UDP用户数据报的形式发送给本地DNS服务器。如果本地DNS服务器找到对应域名的IP地址，则发送相应的IP地址，如果在回复报文中返回IP地址，如果在上一步没有找到，即本地DNS服务器没有知道查询域名的IP地址，由于从主机到本地DNS服务器的查询是递归查询，此时本地DNS服务器会使用DNS客户端的身份继续向其他的发送查询请求报文根DNS服务器。从本地DNS服务器到根DNS服务器的查询是一个迭代查询。当找到对应域名的IP地址后，将结果返回给最初发起查询请求的浏览器。递归查询：在这种模式下，DNS服务器收到客户端的请求，必须返回一个准确的查询结果给客户端。如果DNS服务器在本地没有保存查询到的DNS信息，服务器会（为客户端）查询其他服务器，并将返回的查询结果返回给客户端。迭代查询：在这种模式下，DNS服务器接收来自客户端的请求。如果DNS服务器在本地没有存储要查询的DNS信息，DNS服务器会向客户端提供可以解析查询请求的其他DNS服务器的地址，以便客户端向客户端发送请求。这个DNS服务器提交请求，依次循环，直到返回查询结果。经过以上步骤，浏览器已经获取到输入域名的IP地址，可以进行下一步操作了。浏览器获取IP地址后，需要确认端口。默认端口是80。一个服务器可能提供不同的服务。这些服务通过端口来区分。您可以指定端口号。浏览器获取IP地址并确认端口后，会向目标服务器发起HTTP请求。HTTP请求是通过TCP连接发送的（如果是HTTPS，需要先建立SSL连接，再建立TCP连接，下面的讨论都是基于HTTP）。浏览器会向目标服务器生成一个HTTP请求如下请求报文一般包括请求方法、请求URI、协议版本、请求头字段等，HTTP请求准备好后，HTTP请求报文会分为message段从应用层传输到传输层后，就会发起到目标服务器的TCP连接，开始TCP三次握手。流程如图：大体上可以理解为：A主动呼叫B：嘿，你能听到我吗（SYN=1,seq=x），然后A开始等待B的应答（SYN-SENT状态）。此时A不知道B是否能听到B的话。A听到A的话，可以确认自己能听到A，但是还需要确认A是否能听到他听到自己的声音，所以B说：我能听到你的声音（ACK=1,ack=x+1），你能听到我的声音吗（SYN=1，seq=y），然后B开始等待A的恢复（SYN-RECD状态）A听到B的话后，A可以确认两件事。一是B可以听到，二是也可以听到B，A可以随时说和听（ESTABLISHED状态）。但是此时B还在等待，不知道A能不能听到，所以这时候A需要回复B说：我能听到你的声音（ACK=1，ack=y+1），并开始开心Let'schat~(seq=x+1)，B听到这句话后可以随时交谈和倾听（ESTABLISHED状态）。在第三次握手报文中穿插补充知识，为什么是三次握手而不是两次或四次？有一种观点认为三次握手是基于TCP协议的可靠性（Reliability）要求。这是确认可以发送和接收两个传输的最少次数。如果两次都不能确定，那么四次就多余了。但它并不完全可靠。不管握手多少次，都只能说明这次握手是靠谱的。它不能保证后续的数据传输总是可靠的，因为通道是不可靠的。当然，三次握手至少可以说明曾经是靠谱的。这是两次握手无法做到的，四次或更多次握手只会增加可信度的结论。所以这次握手只是保证可靠性的基本需要。TCP协议的可靠性（注意区分完整性）更多是由校验和、定时器超时重传、确认机制决定的。书中也提到了《计算机网络》这个问题之后，给出的解释是：三次握手是为了防止服务器接收到无效的连接请求报文段，导致出错。具体例子如下：客户端发送的一个连接请求报文段并没有丢失，而是长时间停留在某个网络节点，以至于延迟到连接释放后的某个时间才到达服务器.原来这是一个已经过期的段。但是，服务端在收到无效的连接请求报文后，误认为是客户端再次发送的新的连接请求。然后向客户端发送确认消息段，同意建立连接。假设不使用“三次握手”，只要服务器发送确认，就建立了新的连接。但是由于客户端还没有发出建立连接的请求，所以会忽略服务器的确认，不会向服务器发送数据。但是服务端认为新的连接已经建立，一直等待客户端发送数据。这样就浪费了服务器的很多资源。“三次握手”的方法可以防止上述现象的发生。比如刚才的情况，客户端不会发送确认给服务器的确认。由于服务端没有收到确认，就知道客户端没有请求建立连接。连接建立后，开始数据传输。虽然浏览器知道目标服务器的IP和端口，但是数据飞过来是不可能的吧？HTTP请求段将从传输层传输到网络层，并在网络层封装成IP数据包。网络层指定到达目标服务器的路径（所谓的传输路由），并将数据包传输给对方。网络层封装后的IP报文会进一步传输到下一层---数据链路层，然后再次封装成MAC数据帧结构，因为IP地址之间的通信依赖于MAC地址（固定的网卡所属的地址）address），所以MAC数据帧结构中会有ARP协议解析后的MAC地址（不一定是目标服务器的MAC地址，因为实际上通信的双方很少在同一局域网(LAN)。将通过中继路由）。数据链路层的MAC数据帧再向下传输，然后到达物理层。这里需要注意的是，物理层考虑的是数据比特流如何在连接到各种计算机的传输介质上传输，而不是具体的传输介质。.物理层需要保证原始数据能够在各种物理介质上传输，它规定了传输介质的机械特性、电气特性、功能特性和工艺特性：常见的传输介质包括双绞线、电缆、光缆、无线信道等，物理层的任务就是使数据能够在这些传输介质上传输。通过MAC地址匹配，数据通过传输介质到达目标服务器的物理层。物理层接收数据比特流，然后向上传输到服务器的数据链路。在数据链路层，MAC数据帧会进行封装的逆运算，还原成IP包，然后向上发送到网络层，网络层也会进行封装的逆运算，还原成IP包一个HTTP请求报文（分割后的一个小报文）然后将这些报文上传到传输层，在传输层根据原来的序号重新组装成一个完整的HTTP请求报文，再上传到应用层，HTTP协议应用层的会开始对请求进行处理，这个处理可能会直接返回静态资源，也可能会经过PHP、JAVA等语言处理，处理完成后会返回一个HTTP响应，从而生成一个HTTP响应消息，类似于HTTP的请求消息结构，然后这个响应消息会“走”请求消息的路径到达浏览器。浏览器收到HTTP响应，然后有可能释放TCP连接，也有可能重新使用这个TCP连接发送新的请求（持久连接），这里看一下TCP的释放联系。与TCP连接建立的三次握手不同，TCP连接的释放是四次挥手。客户端和服务端都可以发起关闭请求，也有两者同时发起关闭请求的情况。中微客户端A发起关闭请求：同样通俗的解释：A给B传输完文件，于是对B说：我要传输的文件已经完成，我要下线了（seq=u,鳍=1)。然后A等待B的回复（FIN-WAIT-1状态）。B看到A的消息后回复A说：知道了，不过我还有文件给你(ACK=1,ack=u+1,seq=v)。B进入等待他的文件被传输的状态（CLOSE-WAIT状态）。A收到B的回复后，不能下线，于是继续等待B的文件上传（FIN-WAIT-2状态）。几分钟后，B的文件上传了。这时他对A说：我的文件传输完了，我也下线（seq=w，FIN=1，ACK=1，ack=u+1），然后B等待A的回复确认真的可以下线（LAST-ACK状态）A收到B的回复后，对A说：OK，那就下线（ACK=1，seq=u+1，ack=w+1）。此时A会等待一段时间（2MSL，TIME-WAIT状态），B收到后会下线（CLOSE状态），然后2MSL时间到后，A也会下线（CLOSE状态状态）。为什么服务器B在收到A的断线请求后没有立即同意断线？当服务器B收到断开连接的请求时，服务器可能还有数据没有发送，所以服务器先发送一个确认信号，等数据全部发送完后才同意断开连接。为什么它挥手四次而不是建立连接？三次因为TCP连接是全双工模式，当服务器B收到A的断开连接请求时，只是说明A没有东西要发送给服务器B，但是此时服务器B到A的传输可能还没有结束，所以服务器B需要给A一个ACK报文，确认收到了A的断线请求，然后继续向A发送信息。发送完成后，服务器B会向A发送一个断线请求的报文段，并等待A收到并发送回复ACK报文后释放连接。也就是说，对于A来说，他要向B发出请求，等待B的确认。对于B来说，他也需要向A发送请求，等待A的确认。两者都要经过这两个过程才能完全释放TCP连接，而不仅仅是释放方面。建立连接只需要建立，不受数据的影响，而释放连接还需要考虑数据是否已经传输，所以在建立连接时，B确认收到A的建立请求，B发送建立请求。这一步可以合并为一步建立TCP连接。第二次握手，但必须在连接释放时分开。为什么A在最后一次握手后等待2MSL？先解释一下MSL，MSL指的是最长消息段寿命，RFC793建议两分钟，但其实可以根据实际情况来定，也就是说一个消息段最长可以存在的时间是MSL这是为了保证A发送的最后一个ACK报文可以到达服务器B，如果ACK报文丢失，服务器B没有收到，B会超时，重传第三次握手的FIN+ACK报文给A，此时正在等待A可以收到重传的FIN+ACK报文，并再次向服务器B发送ACK报文，并重启2MSL定时器。最后的结果是A和B都正常进入CLOSE状态。如果A在发送ACK报文后直接释放A-->B连接，那么A将收不到B重传的FIN+ACK报文，也无法重发ACK`报文，那么B就无法正常按steps释放B-->A的连接，防止下一次新连接出现“过期连接请求报文”，因为一个报文段的生存期是MSL，所以A在发送完最后一个ACK报文段后，又经过一个2MSL的时间，本次连接持续时间内产生的所有报文段都会在网络中消失，这样这些旧的报文段就不会出现在下一次新的连接中。浏览器稍后会检查HTTP的响应状态，主要通过响应码来判断1xx：表示通知信息，比如请求已经收到或者正在处理2xx：表示成功，成功接收并处理了操作3xx：表示重定向，以及通常必须采取进一步的行动才能完成请求4xx：表示客户端错误5xx：表示服务器错误如果可以缓存响应，则浏览器会将响应存储在缓存中浏览器根据以下内容解码响应HTTP头信息，决定如何处理这些响应，并显示响应，将响应作为HTML示例浏览器开始从上到下，从左到右加载HTML文档。一开始会遇到声明，然后根据声明，浏览器就会知道使用哪种规范来解析文档，然后再继续加载解析的同时生成DOM树。当加载过程中遇到外部CSS文件时，浏览器会再次请求获取CSS文件（过程同上），获取到CSS后会生成一个CSSRule树。DOM树和CSSRule树生成Render树，页面可以在loading的时候开始渲染。渲染树和DOM树的关系：那些不可见的DOM元素（比如
…，display=none的元素）不会被插入到渲染树中；有些节点是绝对定位的或者是浮动的，这些节点会脱离文本流，所以它们在渲染树和DOM树中的位置不同，渲染树标识真实的位置，并使用一个占位符结构标识它们的原始位置位置，以及它们在DOM树上的原始位置。渲染包括“布局”和“绘制”两个步骤。所谓“布局”是指给每个DOM节点在浏览器窗口中的准确位置，“绘制”是指遍历Render树将布局好的DOM节点绘制到屏幕上。浏览器继续加载和呈现。如果遇到放在中，则无法加载标签，页面自然无法渲染，这样会导致JS代码执行完之前，页面是一片空白，用户体验很差。一般看到长长的空白页面，很想直接关闭。因此，建议将所有的