为什么建立连接是三次握手，而关闭连接却是四次挥手呢？

这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方也未必全部数据都发送给对方了，所以己方可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送。

1. TCP的三次握手最主要是防止已过期的连接再次传到被连接的主机。
如果采用两次的话，会出现下面这种情况。
比如是A机要连到B机，结果发送的连接信息由于某种原因没有到达B机；于是，A机又发了一次，结果这次B收到了，于是就发信息回来，两机就连接。传完东西后，断开。结果这时候，原先没有到达的连接信息突然又传到了B机，于是B机发信息给A，然后B机就以为和A连上了，这个时候B机就在等待A传东西过去。
2. 三次握手改成仅需要两次握手，死锁是可能发生
考虑计算机A和B之间的通信，假定B给A发送一个连接请求分组，A收到了这个分组，并发送了确认应答分组。按照两次握手的协定，A认为连接已经成功地建立了，可以开始发送数据分组。可是，B在A的应答分组在传输中被丢失的情况下，将不知道A是否已准备好，不知道A建议什么样的序列号，B甚至怀疑A是否收到自己的连接请求分组。在这种情况下，B认为连接还未建立成功，将忽略A发来的任何数据分组，只等待连接确认应答分组。而A在发出的分组超时后，重复发送同样的分组。这样就形成了死锁

window.onload来延迟加载也是可以的。

seajs-preload:用这种方式可以实现特定的模块执行之前依赖的模块已经加载完成，这也是一种预加载!

HTML5页面资源预加载(Link prefetch)写法：prefetch表示当subresources都加载完成以后才加载；subresource表示当前页面必须加载的资源；chrome浏览器和FF浏览器甚至支持prerender，不过ff用的是next表示预先渲染!
<!-- 预加载整个页面 -->
<link rel="prefetch" href="http://www.webhek.com/misc/3d-album/" />
<!-- 预加载一个图片 -->
<link rel="prefetch" href=" http://www.webhek.com/wordpress/wp-content/uploads/2014/04/b-334x193.jpg " />

转载于:https://www.cnblogs.com/wengwj/p/9336418.html