初衷：
大脑中一直存在误区：一个Web前端工作者只要完美实现产品所提需求，至于浏览器究竟是怎么工作或者其中间都经历了些什么事情，就不用刨根问底了。直到最近看见前端大神winter老师关于浏览器部分的系列文章后，方才意识到浏览器的这些知识，还得好好研究一番。
刨根问底：
1.浏览器如何工作的？
对于浏览器实现者来说，他们所做的事情就是把一个URL链接变成用户眼睛所能看见的网页。
主要过程描述：
1.浏览器首先使用HTTP或者HTTPS协议，向服务器端请求页面；
2.把请求回来的HTML解析，构建为DOM树；
3.计算DOM树上的CSS属性，对元素逐个进行渲染，得到内存中的位图；
4.合成位图，绘制到页面上。
2.http报文头部有哪些字段? 有什么意义 ?
2.1 HTTP报文：它是HTTP应用程序之间发送的数据块。这些数据块以一些文本形式的元信息开头，这些信息描述了报文的内容及含义，后面跟着可选的数据部分。这些报文都是在客户端、服务器和代理之间流动。
2.2 所有的HTTP报文都可以分为两类，请求报文和响应报文。它俩结构大致相同，只是起始行的语法不同。
请求报文的格式：
起始行： <method> <request-URL> <version>
头部： <headers>
主体： <entity-body>
响应报文的格式：
起始行： <version> <status> <reason-phrase>
头部： <headers>
主体： <entity-body>
主要的http报文头部字段以及其含义：
3.HTTP状态码
3.1详细的HTTP状态码解释请看这里：
3.2最早之前看过有位大神写过的文章中，描述的简单易记忆版的：
1XX:Informational(信息性状态码) 接收的信息正在处理
2XX：Success(成功状态码) 请求正常处理完毕
3XX：Redirection(重定向状态码) 需要进行附加操作已完成请求
4XX:Client Error(客户端错误状态码) 服务器无法处理请求
5XX:Server Error(服务器错误状态码) 服务器处理请求出错
4.TCP三次握手、四次的过程
4.1：
①TCP:Transmission Control Protocol.传输控制协议
TCP共有6个标志位，分别是：SYN(synchronous),建立联机；ACK(acknowledgement),确认；PSH(push),传输；FIN(finish),结束；RST(reset),重置；URG(urgent),紧急。
Client端发送连接请求报文，Server段接受连接后回复ACK报文，并为这次连接分配资源。Client端接收到ACK报文后也向Server段发生ACK报文，并分配资源，这样TCP连接就建立了。
②TCP在传输之前会进行三次沟通，一般称为“三次握手”；传输数据断开的时候需要进行四次沟通，一般称为“四次挥手”。
断开连接端可以是Client端，也可以是Server端
假设Client端发起中断连接请求，就先发送FIN报文。Server端接到FIN报文后，但是如果还有数据没有发送完成，则不必急着关闭Socket，可以继续发送数据。所以服务器端先发送ACK，告诉Client端：请求已经收到了，但是我还没准备好，请继续等待停止的消息。这个时候Client端就进入FIN_WAIT状态，继续等待Server端的FIN报文。当Server端确定数据已发送完成，则向Client端发送FIN报文，告诉Client端：服务器这边数据发完了，准备好关闭连接了。Client端收到FIN报文后，就知道可以关闭连接了，但是他还是不相信网络，所以发送ACK后进入TIME_WAIT状态， Server端收到ACK后，就知道可以断开连接了。Client端等待了2MSL后依然没有收到回复，则证明Server端已正常关闭，最后，Client端也可以关闭连接了至此，TCP连接就已经完全关闭了！
参考文章：这里
5. get post请求的区别：
HTTP协议中的两种发送请求的方法;这里更详细
6.浏览器事件有哪些过程? 为什么一般在冒泡阶段, 而不是在捕获阶段注册监听? addEventListener 参数分别是什么 ?
浏览器事件一般经历的过程：事件捕获、处于目标阶段、事件冒泡阶段。
考虑浏览器的兼容性
addEventListener可接受3个参数：要处理的事件名、作为事件处理程序的函数和一个布尔值。布尔值若为true，表示在捕获阶段调用事件处理程序；若为false，表示在冒泡阶段调用事件处理程序。
……（再补）
结语：
干瘪的海绵叶叶，迅速膨大吧！