tcp握手为啥是三次？
报文类型
首先tcp的报文可以归纳为以下5种：
- SYN
- Data
- FIN
- Reset
- ACK
其中前三个分别为建立连接、数据传输、断开连接，这三种报文对方接受到一定要ACK确认，这是tcp保证可靠传输依赖的机制。如果对方在超时时间内不确认，发送方会一直重传，直到对方确认或者达到重传上限次数而reset连接。
Reset为重置连接报文，ACK为确认报文，对于这两种报文，对方接收到后不需要ACK确认，发送方也不会重传这两种类型的报文。
Reset和Ack报文为啥不需要确认？
发送Reset报文的一端，在发送完这个报文后，和该tcp session有关的内存结构体瞬间全部释放，无论对方收到或者没有收到，都没有关系了。如果对方也收到Reset报文，也会释放该TCP session相关的内存结构。如果对方没收到Reset报文，可能会继续发送让接收方弹射出Reset的报文，对最后对方一样会收到Reset报文，并最终释放内存。
这里的ACK报文，是指没有携带任何数据的裸ACK报文，对方接受到这样的ACK报文，自然也不需要ACK,否则双方要一直回复ACK导致死循坏。
有同学会说，按照这么说，TCP连接应该是四次消息交互啊：
1.A 发送SYN 报文给B，这是第一次报文交互。
- B发送ACK确认A的SYN报文，这是第二次报文交互
- B发送自己的SYN报文给A，这是第三次报文交互
- A需要ACK确认B的SYN报文，这是第四次报文交互
以上的演绎没有问题，但是报文2、3为何要分开发送呢？增加了延迟不说，同时还白白浪费了网络的带宽，完全可以将报文2、3合并起来，不就是在报文3的ACK状态位的位置置“1”就结了吗
TCP握手握的到底是啥？
TCP作为一种可靠传输控制协议，其核心思想：既要保证数据可靠传输，又要提高传输的效率，而用三次恰恰可以满足以上两方面的需求。
TCP是怎么保证可靠传随的呢？ TCP连接的一方A，由操作系统动态随机选取一个32位长的序列号（Initial Sequence Number），假设A的初始化序列号为1000，以该序列号为原点，对自己将要发送的每个字节的数据进行编号，1001，1002...，并将自己的初始序列号ISN告诉B，让B知道什么编号的数据是合法的，什么编号是非法的，同时B还对A的每一个编号的字节数据进行确认，如果A收到B的确认好为2001，意味着字节编号为1001-2000的数据都已经安全到达。 同理B也是类似的操作。
一句话总结，TCP连接握手，握的是通信双方数据原点的序列号！用此核心思想来分析整个握手过程：
四次握手：
1.1 A 发送同步信号SYN + A'sInitial sequence number
1.2 B 确认收到A的同步信号，并记录A's ISN 到本地，命名 B's ACK sequence number
1.3 B发送同步信号SYN + B's Initial sequence number
1.4 A确认收到B的同步信号，并记录B's ISN 到本地，命名 A's ACK sequence number
很显然1.2和1.3 这两个步骤可以合并，只需要三次握手，可以提高连接的速度与效率。
二次握手的过程：
2.1 A 发送同步信号SYN + A'sInitial sequence number
2.2 B发送同步信号SYN + B'sInitial sequence number + B's ACK sequence number
这里有一个问题，A与B就A的初始序列号达成了一致，这里是1000。但是B无法知道A是否已经接收到自己的同步信号，如果这个同步信号丢失了，A和B就B的初始序列号将无法达成一致。于是TCP的设计者将SYN这个同步标志位设计成占用一个字节的编号（FIN标志位也是），既然是一个字节的数据，按照TCP对有数据的TCP segment 必须确认的原则，所以在这里A必须给B一个确认，以确认A已经接收到B的同步信号。
有童鞋会说，如果A发给B的确认丢了，该如何？A会超时重传这个ACK吗？不会！TCP不会为没有数据的ACK超时重传。那该如何是好？B如果没有收到A的ACK，会超时重传自己的SYN同步信号，一直到收到A的ACK为止。
握手过程的异常情况
- 第一个包，即A发给B的SYN 中途被丢，没有到达B
A会周期性超时重传，直到收到B的确认 - 第二个包，即B发给A的SYN +ACK 中途被丢，没有到达A
B会周期性超时重传，直到收到A的确认 - 第三个包，即A发给B的ACK 中途被丢，没有到达B
A发完ACK，单方面认为TCP为 Established状态，而B显然认为TCP为Active状态：
a. 假定此时双方都没有数据发送，B会周期性超时重传，直到收到A的确认，收到之后B的TCP 连接也为 Established状态，双向可以发包。
b. 假定此时A有数据发送，B收到A的 Data + ACK，自然会切换为established 状态，并接受A的Data。
c. 假定B有数据发送，数据发送不了，会一直周期性超时重传SYN + ACK，直到收到A的确认才可以发送数据。
