上个学期一直在折腾小论文的事情，这个学期终于能稍微喘口气了。
趁着最近准备面试的机会，顺便复习复习之前学过的基础知识，温故而知新。
TCP三次握手的基本原理，没什么好说的，大把大把的教材以及文章。
TCP三次握手的几个关键点：
- SYN占用一个序号，ACK不占用序号
- ack的值，其实是右侧开区间的边界值；
下面开始进入正题。
就是为什么要“第三次”握手？
为了防止已经失效的连接请求报文段突然又传送到了B，因而产生错误。
所谓“已失效的连接请求报文段”是这样产生的。
考虑一种正常情况。A发出连接请求，但因连接请求报文丢失而未收到来自B的确认。于是A再次重传一次连接请求。后来收到了确认，建立连接。数据传输完毕后，就释放了连接。A共发送了两个连接请求报文段，其中第一个丢失，第二个到达了B。没有“已失效的连接请求报文段”。
现假定出现一种异常情况，即A发出的第一个连接请求报文段并没有丢失，而是在某个网络节点长时间滞留了，以致延误到连接释放之后的某个时间才到达B。本来这是一个早已经失效的报文段。但B收到此失效的连接请求报文段后，就误认为是A又发出了一次新的连接请求。于是就向A发出确认报文段，同意建立连接。假定不采用三次握手，那么只要B发出确认，新的连接就建立了。
由于现在A并没有发出建立连接的请求，因此不会理睬B的确认，也不会向B发送数据，但B却以为新的运输连接已经建立了，并一直等待A发来数据。B的许多资源就这样白白浪费了。
采用三次握手的办法就可以防止上述现象的发生。例如在刚才的情况下，A不会向B的确认发出确认。B由于收不到确认，就知道A并没有要求建立连接。
一个比较通俗但是可能并不怎么严谨的例子：
假设有A、B两个人。
正常情况下，A先发了“Hello”给对方，然后B看到简讯回了个“Hi”，那么接下来两人就可以快乐地扯淡了。
但是，如果A发了个“Hello”后跑路了，B回了“Hi”之后就等着A后续的消息，那么结局就是B只能呆呆地盯着屏幕。
为了避免A消失了的这种情况， B只有在收到A对“Hi”的回应之后，才会正式进入聊天状态。