iso七层
应用层-表示层-会话层-传输层-网络层-数据链路层-物理层
tcp/ip四层
应用层————-传输层-网络层-数据链路层
Promise：好像一个容器，保存着某个未来才会结束的事件结果（一个异步操作）。
promise对象代表一个异步操作，其结果有三种状态：pending（进行中）、resolved（fulfilled已完成）、rejected（已失败）
Promise对象实例.then()/catch()
异步执行函数，
将原来的异步回调写法分离出来，在异步操作执行完后，用链式调用的方式执行回调函数。
不然需要封装一个回调函数，当作参数传入需要异步执行的函数中去；但是如果有多层回调呢？如果回调本身又是一个异步操作，执行完也需要相应的回调函数，如果用老办法那就要封装N个回调函数，当作参数传给异步执行的函数中去。而用promise就可以在then方法中继续写promise对象并返回，继续调用then来进行回调操作。
promise的精髓：状态，用维护状态，传递状态的方式来使回调函数能够及时调用
resolve函数：将Promise对象的状态从Pending变为Resolved，在异步操作成功时调用，并将异步操作的结果，作为参数传递出去；reject函数：将Promise对象的状态从Pending变为Rejected，在异步操作失败时调用，并将异步操作报出的错误，作为参数传递出去。then()可以接受两个回调函数作为参数。第一个回调函数是Promise对象的状态变为Resolved时调用，第二个回调函数是Promise对象的状态变为Reject时调用。其中，第二个函数是可选的，不一定要提供。这两个函数都接受Promise对象传出的值作为参数。.catch(function(reason){})：两个作用：
1.指定reject的回调函数。
2.类似try/catch，可以捕获then方法中第一个参数（也就是异步函数执行resolve的回调函数）中的异常，reason就是异常信息，程序不会报错卡死，而是会进入到catch中
.all([异步操作函数的数组]).then(function(results){})：可以并行执行多个异步函数，最终返回一个promise对象，多个异步操作的函数返回的数据放进一个数据传给then()，也就是results。应用场景：页面需要加载各种资源，都加载完后再进行页面的初始化。 等执行的最慢的异步函数执行完后执行回调。
.race([异步操作函数的数组]).then(function(results){})：同all方法，只是all是等所有的异步操作完成再回调，也就是需要等最慢的执行完；race是最快的异步函数执行完后执行回调，当然，同时剩余的异步操作函数也在执行。
Promise也有一些缺点。首先，无法取消Promise，一旦新建它就会立即执行，无法中途取消。其次，如果不设置回调函数，Promise内部抛出的错误，不会反应到外部。第三，当处于Pending状态时，无法得知目前进展到哪一个阶段（刚刚开始还是即将完成）。跨终端
移动端web app
<meta name="viewport" content="width=device-width,initial-scale=1,user-scalable=no">svg
闭包的使用场景
构造私有变量，使其不能在外部被随意更改，又可以通过指定的函数接口来操作，类似于私有变量的get、set方法
escape():对这些@ - _ + . /不编码，数字也不编码，返回的是字符的unicode编码值
decodeURI():特殊字符不编码，比如：http://www.haorooms.com/My%20first/
decodeURIComponent() ：特殊字符也编码;
比如：http%3A%2F%2Fwww.haorooms.com%2FMy%20first%2F
跨域：
jsonp：只能get请求，因为是src里请求
bind()直接绑定在元素上，不人为地设置stopPropagation，就会一直向上冒泡触发所有祖先元素的该事件；不会绑定那些后来动态添加的元素；元素很多时会有效率问题。
live()：$(‘a’).live(‘click’,function(){alert(‘That tickles!’)}) 全部绑定到document上，当有事件冒泡到document上，就查看该事件是否发生在a上的click事件，是的话则执行。相比较bind()可以动态绑定，即使这个元素是后来新加进来的。
delegate()：更精确的可以在小范围绑定事件，跟bind相比实现动态绑定，但仍然需要查找在哪个元素上发生了事件。
三次握手
建立TCP连接需要三次握手, 而断开连接需要执行四次挥手.
三次握手: 首先Client端发送连接请求报文，Server段接受连接后回复ACK报文，并为这次连接分配资源。Client端接收到ACK报文后也向Server段发生ACK报文，并分配资源，这样TCP连接就建立了。
- 第一步: 客户机的TCP先向服务器的TCP发送一个连接请求报文. 这个特殊的报文中不含应用层数据, 其首部中的SYN标志位被置1. 另外, 客户机会随机选择一个起始序号seq=x(连接请求报文不携带数据,但要消耗掉一个序号)
- 第二步: 服务器端的TCP收到连接请求报文后, 若同意建立连接, 就向客户机发送请求, 并为该TCP连接分配TCP缓存和变量. 在确认报文中,SYN和ACK位都被置为1, 确认号字段的值为x+1, 并且服务器随机产生起始序号seq=y(确认报文不携带数据, 但也要消耗掉一个序号). 确认报文同样不包含应用层数据.
- 第三步: 当客户机收到确认报文后, 还要向服务器给出确认, 并且也要给该连接分配缓存和变量. 这个报文的ACK标志位被置为1, 序号字段为x+1, 确认号字段为y+1
四次挥手
- 第一步: 客户机打算关闭连接,就向其TCP发送一个连接释放报文,并停止再发送数据,主动关闭TCP连接, 该报文的FIN标志位被置1, seq=u, 它等于前面已经传送过的数据的最后一个字节的序号加1(FIN报文即使不携带数据,也要消耗掉一个序号)
- 第二步: 服务器接收连接释放报文后即发出确认, 确认号是ack=u+1, 这个报文自己的序号是v, 等于它前面已传送过的数据的最后一个自己的序号加1. 此时, 从客户机到服务器这个方向的连接就释放了, TCP连接处于半关闭状态. 但服务器若发送数据, 客户机仍要接收, 即从服务器到客户机的连接仍未关闭.
- 第三步: 若服务器已经没有了要向客户机发送的数据, 就通知TCP释放连接, 此时其发出FIN=1的连接释放报文
- 第四步: 客户机收到连接释放报文后, 必须发出确认. 在确认报文中, ACK字段被置为1, 确认号ack=w+1, 序号seq=u+1. 此时, TCP连接还没有释放掉, 必须经过等待计时器设置的时间2MSL后, A才进入到连接关闭状态.