1. position: absolute的 containing block 问题
position: absolute的元素的包含块（containing block） 总是最近定位的祖先元素（nearest positioned ancestor）。所谓定位，即position是relative, absolute, fixed。
如果没有最近定位的祖先，那么包含块就是 initial containing block 。问题的难点就在谁是 initial containing block ？
在我的（可能包括很多人）潜意识里，initial containing block显然就是<body>。wow，@ｙoo提供的例子打脸了：
<body>
<style>
body{height: 200vh; background-color: green;}
.demo{position: absolute; top: 0; left: 0; bottom: 0; right: 0; background-color: yellow;}
</style>
<div class="demo"></div>
</body>可以看到，背景黄色的.demo占满整个窗口。调整body高度，.demo的高度始终不变，即跟<body>无关。所以<body>不是 initial containing block 。然后<html>是么？也不是。那么谁是？
http://www.w3.org/TR/CSS2/visudet.html:
The containing block in which the root element lives is a rectangle called the initial containing block. For continuous media, it has the dimensions of the viewport and is anchored at the canvas origin; it is the page area for paged media. The 'direction' property of the initial containing block is the same as for the root element.
概念有点晦涩，就屏幕媒体而言，
initial containing block是一个长方形，尺寸和视口（窗口，window）一致，定位于画布（绘制整个文档的canvas，不要与<canvas>元素混淆）的起点。 可以看作（但不是）没有滚动时的窗口。
所以我们可以看到例子中.demo恰好铺满窗口，不论<html>/<body>怎么变动。
为什么通过position: absolute; top: 0; bottom: 0;来确认initial containing block？
当同时指定绝对定位元素的top和bottom，且height没有指定，或者是auto/100%，那么top和bottom都会起作用，指定对包含块的上下距离。通过这个原理，我们在以上例子中，调整body高度而.demo的高度不变，确认body不是initial containing block。
- 共 1 页
- 1
引言
TCP 建立连接与断开连接的过程
TCP 三次握手（连接过程）
第一次握手
客户端向服务端发送连接请求报文段。该报文段中包含自身的数据通讯初始序号。请求发送后，客户端便进入 SYN-SENT 状态。
第二次握手
服务端收到连接请求报文段后，如果同意连接，则会发送一个应答，该应答中也会包含自身的数据通讯初始序号，发送完成后便进入 SYN-RECEIVED 状态。
第三次握手
当客户端收到连接同意的应答后，还要向服务端发送一个确认报文。客户端发完这个报文段后便进入 ESTABLISHED 状态，服务端收到这个应答后也进入 ESTABLISHED 状态，此时连接建立成功。
为什么需要三次握手，2次不行吗？
喂喂喂，我是A，你听的到吗？ B：在在在，我能听到，我是B，你能听到我吗? A：(听到了，老子不想理你) B：喂喂喂？听不听到？我X，对面死了，我挂了。。
如果只有 2 次的话，B 并不清楚 A 是否收到他发过去的信息。
TCP 四次挥手（断开链接）
第一次挥手
若客户端 A 认为数据发送完成，则它需要向服务端 B 发送连接释放请求。
第二次挥手
B 收到连接释放请求后，会告诉应用层要释放 TCP 链接。然后会发送 ACK 包，并进入 CLOSE_WAIT 状态，此时表明 A 到 B 的连接已经释放，不再接收 A 发的数据了。但是因为 TCP 连接是双向的，所以 B 仍旧可以发送数据给 A。
第三次挥手
B 如果此时还有没发完的数据会继续发送，完毕后会向 A 发送连接释放请求，然后 B 便进入 LAST-ACK 状态。
PS：通过延迟确认的技术（通常有时间限制，否则对方会误认为需要重传），可以将第二次和第三次握手合并，延迟 ACK 包的发送。
第四次挥手
A 收到释放请求后，向 B 发送确认应答，此时 A 进入 TIME-WAIT 状态。该状态会持续 2MSL（最长报文段寿命，指报文段在网络中生存的时间，超时会被抛弃） 时间，若该时间段内没有 B 的重发请求的话，就进入 CLOSED 状态。当 B 收到确认应答后，也便进入 CLOSED 状态。
SYN 泛洪攻击
我们已经知道，TCP 只有经过三次握手才能连接，而 SYN 泛洪攻击就是针对 TCP 握手过程进行攻击：
攻击者发送大量的 SYN 包给服务器（第一次握手成功）
服务器回应(SYN + ACK）包（第二次握手成功）
但是攻击者不回应 ACK 包（第三次握手不进行）
导致服务器存在大量的半开连接，这些半连接可以耗尽服务器资源，使被攻击服务器无法再响应正常 TCP 连接，从而达到攻击的目的
幸运的是，一种称为 SYN cookie 的有效防御现在已部署在大多数主要的操作系统中：
原文
第 193 题：TCP 的三次握手和四次挥手，了解泛洪攻击么