探网络系列（1）-TCP三次握手&Render Tree页面渲染=>从输入URL到页面显示的过程？

最近工做之余一直在温故js系列，想知新，想提高，以小技术点为节奏去回顾。今天忽然想到回顾一下这个http知识，http知识有太多深层次须要学习，今天简要回顾，浅析下这个技术点。
主要经过五个步骤浅析这个过程，有错误的地方，烦请斧正，互相学习。

一、发送URL，请求IP地址

当发送一个URL请求时，无论这个URL是Web页面的URL仍是Web页面上每一个资源的URL，浏览器都会开启一个线程来处理这个请求，同时在远程DNS服务器上启动一个DNS查询，让浏览器得到请求对应的IP地址。
（这儿涉及的“DNS 查询和经过 Socket 发送数据”知识点见连接文章）

二、TCP三次握手

浏览器与远程 Web 服务器经过 TCP 三次握手协商来创建一个 TCP/IP 链接。该握手包括一个同步报文，一个同步-应答报文和一个应答报文，这三个报文在 浏览器和服务器之间传递。该握手首先由客户端尝试创建起通讯，然后服务器应答并接受客户端的请求，最后由客户端发出该请求已经被接受的报文。

ACK: ACK=1表示该报文段中有确认号须要处理。
SYN: SYN=1 ACK=0代表是创建链接请求报文段，SYN=1 ACK=1代表赞成创建链接报文。
FIN: FIN=1表示对端的数据已经发送完毕，要求释放链接。

第一次握手：创建链接

客户端发送链接请求报文段，将SYN值设为1，Sequence Number为x。客户端进入SYN_SEND状态，等待服务器的确认。

第二次握手：服务器收到SYN报文段

服务器收到客户端SYN报文段，须要对这个SYN报文段进行确认，设置Acknowledgment Number为x+1(Sequence Number+1)。同时，本身本身还要发送SYN请求信息，将SYN值设为1，Sequence Number设为y。服务器端将上述全部信息放到一个报文段（即SYN+ACK报文段）中，一并发送给客户端，服务器进入SYN_RECV状态。

第三次握手：客户端收到SYN+ACK报文段

客户端收到服务器的SYN+ACK报文段后将Acknowledgment Number设置为y+1，向服务器发送ACK报文段，这个报文段发送完毕之后，客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手。

完成三次握手，客户端与服务器开始传送数据，在上述过程当中，还有一些重要的概念：

未链接队列：在三次握手协议中，服务器维护一个未链接队列，该队列为每一个客户端的SYN包（syn=j）开设一个条目，该条目代表服务器已收到SYN包，并向客户发出确认，正在等待客户的确认包。这些条目所标识的链接在服务器处于Syn_RECV状态，当服务器收到客户的确认包时，删除该条目，服务器进入ESTABLISHED状态。 Backlog参数：表示未链接队列的最大容纳数目。

SYN-ACK 重传次数：服务器发送完SYN－ACK包，若是未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传，若是重传次数超过系统规定的最大重传次数，系统将该链接信息从未链接队列中删除。注意，每次重传等待的时间不必定相同。

未链接存活时间：是指未链接队列的条目存活的最长时间，也即服务从收到SYN包到确认这个报文无效的最长时间，该时间值是全部重传请求包的最长等待时间总和。有时咱们也称未链接存活时间为Timeout时间、SYN_RECV存活时间。

为何是3次握手？

图片及问题转自jimmy_thr的https://segmentfault.com/a/11...

很简单呀，由于3次就够了,干吗用4次。23333. 举个例子吧，假如是2次的话， 可能会出现这样一个状况。

当客户端发送一次请求A后，可是A在网络延迟了好久， 接着客户端又发送了一次B，可是此时A已经无效了。 接着服务器相应了B，并返回TCP链接头，创建链接(这里就2次哈)。 而后，A 历经千山万水终于到服务器了， 服务器一看有请求来了，则接受，因为一开始A带着的TCP格式都是正确的，那么服务器，理所应当的也返回成功链接的flag，可是，此时客户端已经判断该次请求无效，废弃了。 而后服务器，就这么一直挂着(浪费资源)，形成的一个问题是，md, 这个锅是谁的？ 因此，为了保险起见，再补充一次链接就能够了。因此3次是最合适的。在Chinese中，以3为起称为多，若是你用4，5，6，7，8...次的话，这不更浪费吗？

三、服务器响应200

TCP/IP 链接创建后，浏览器会经过该链接向远程服务器发送 HTTP 的 GET 请求。远程服务器找到资源并使用 HTTP 响应返回该资源，值为200的 HTTP 响应状态表示一个正确的响应。

四、生成Render Tree

客户端开始下载资源。请求返回后，便进入了咱们关注的前端模块。浏览器会解析 HTML 成树形的数据结构DOM，生成 DOM Tree，浏览器将CSS代码解析成树形的数据结构CSSOM，生成 CSS Rule Tree。
DOM 和 CSSOM 都是以 Bytes → characters → tokens → nodes → object model 这样的方式生成最终的数据。DOM树的构建过程是一个深度遍历过程：当前节点的全部子节点都构建好后才会去构建当前节点的下一个兄弟节点。

DOM Tree和CSS Rule Tree结合生成Render Tree。

display:none 的节点不会被加入Render Tree，而visibility: hidden 则会。
• display : 隐藏对应的元素但不挤占该元素原来的空间。
• visibility: 隐藏对应的元素而且挤占该元素原来的空间
因此，若是某个节点最开始是不显示的，设为display:none是更优的。

五、渲染页面

布局

有了Render Tree，浏览器知道网页中有哪些节点、各个节点的CSS定义以及他们的从属关系。接着就开始布局，计算出每一个节点在屏幕中的位置。

渲染

浏览器已经知道了哪些节点要显示、每一个节点的CSS属性是什么、每一个节点在屏幕中的位置是哪里。就进入了最后一步，按照算出来的规则，经过显卡，把内容画到屏幕上。

而 javascript 又能够根据 DOM API 操做DOM。好比JS修改了DOM或者CSS属性，也会从新触发布局和渲染的执行过程。

关于这个问题到这儿就能够结束了......图已放，情未了，那顺便把TCP四次挥手也写这，结合图去分析。

遗留：TCP四次挥手

第一次挥手：客户端想分手

假设客户端想要关闭链接，客户端发送一个 FIN 标志位置为1的包(FIN=1，seq=x)，表示本身已经没有数据能够发送了，可是仍然能够接受数据。
发送完毕后，客户端进入 FIN_WAIT_1 状态。

第二次挥手：服务端也想分手

服务器端确认客户端的 FIN包，发送一个确认包(ACK=1，ACKnum=x+1)，代表本身接受到了客户端关闭链接的请求，但尚未准备好关闭链接。
发送完毕后，服务器端进入 CLOSE_WAIT 状态，客户端接收到这个确认包以后，进入FIN_WAIT_2 状态，等待服务器端关闭链接。

第三次挥手：服务端准备好分手

服务器端准备好关闭链接时，向客户端发送结束链接请求，FIN置为1(FIN=1，seq=y)。
发送完毕后，服务器端进入 LAST_ACK 状态，等待来自客户端的最后一个ACK。

第四次挥手：分手

客户端接收到来自服务器端的关闭请求，发送一个确认包(ACK=1，ACKnum=y+1)，并进入 TIME_WAIT状态，等待可能出现的要求重传的 ACK包。
服务器端接收到这个确认包以后，关闭链接，进入 CLOSED 状态。
客户端等待2MSL（2MSL，2 Maximum Segment Lifetime）以后，没有收到回复，确保服务器端确实是关闭了，客户端也关闭链接，进入 CLOSED状态。

学知识不会是为了面试，由于面试会一层层的深刻，不知道的就是不知道，不能逞强，最后坑了本身。多研究研究，才是真理。come on , basketball.