Render Tree页面渲染

从输入URL到页面显示的过程

今天的文章又简单又不简单！

为什么说它简单呢？   因为TCP的三次握手基本上都是学IT最开始就学的东西

为什么说它不简单呢？   因为TCP包含太多的知识面和点了！

HTTP知识有太多层次需要学习，今天只浅析一下

 如果需要深入了解的话可以围绕以下几个问题进行：

一、从输入URL到浏览器接收的过程发生了什么？

1、从按动键盘到CPU

2、CPU内部的处理过程

3、从CPU到操作系统内核

4、从操作系统GUI到浏览器

二、浏览器如何向网卡发送数据？ 

1、HTTP请求的发送

2、DNS查询过程

3、通过Socket发送数据

4、Socket在内核中的实现

5、底层网络协议 

 三、数据如何从本机网卡发送到服务器？

1、从内核到网络适配器（network interface card）

2、连接WI-FI路由的情况如何处理

3、运营商网络内的路由转发过程

4、主干网间的传输过程

5、IDC内网传输过程

6、服务器的CPU如何处理

 四、服务器接收到数据后会进行哪些处理？

1、负载均衡

2、LVS

3、反向代理

4、Web server中的处理

5、进入后端语言处理过程

6、Web框架（Framework）

7、读取数据

五、服务器返回数据后浏览器如何处理

1、从01到字符

2、外链资源的加载

3、JavaScript的执行

4、从字符到图片

5、跨平台2D绘制库

6、CPU合成

 六、浏览器如何将页面展现出来？

1、Framebuffer

2、从内存到LCD

3、LCD显示

TCP的三次握手&Render Tree 页面渲染  --  从输入URL到页面显示的过程

1、发送URL、请求IP地址

      当发送一个URL请求时，不管这个URL是Web页面的URL还是Web页面上每个资源的URL，浏览器都会开启一个线程来处理这个请求，同时在远程DNS服务器上启动一个DNS查询，让浏览器获得请求对应的IP地址。

 2、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次就够了,干嘛用4次。23333. 举个例子吧，假如是2次的话， 可能会出现这样一个情况。

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

3、服务器相应200

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

4、生成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是更优的。

5、页面渲染

布局

　　有了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状态

。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

OVER

TCP三次握手想详解的了解

或想知道文章开头问题的解答

推荐URL

http://fex.baidu.com/blog/2014/05/what-happen/

本文章为博主网络收集整合文章

TCP三次握手