什么是TCP协议
传输控制协议（TCP，Transmission Control Protocol）是一种面向连接的、可靠的、基于字节流的传输层通信协议。
三次握手
当服务端与客户端建立链接时，需要经过三次握手的过程：
- A向B发送同步数据的请求，A -----SYN------> B
- B向A发送同步数据请求+确认，B -----SYN+ACK------> A
- A向B发送确认，A -----ACK------> B
过程如下图
当三次握手完成后，客户端与服务端各自会开辟出一块儿缓存区，用于服务上层应用程序来接受和发送请求，如此双方便建立了可靠的连接
为什么不是两次握手或者四次握手？
首先我们要明确的一点是，TCP的核心思想为：既要保证数据可靠传输，又要提高传输的效率，而用三次恰恰可以满足以上两方面的需求
TCP报文是交由IP网络来负责运输，IP网络并不能保证TCP报文一定能够到达目的地，所以需要TCP自行确认报文是否发送到目的地，因此无论哪一方收到请求之后都需要返回ack确认码来告诉对方已经收到信息，所以两次握手是无法达到核心思想中两方面的需求
TCP看似复杂，其实可以归纳为以下5种报文：
-
SYN
-
Data （唯一携带用户数据）
-
FIN
-
Reset
-
ACK
其中1、2、3分别为建立连接、数据传输、断开连接，这三种报文对方接收到一定要ACK确认，为何要确认，因为这就是可靠传输的依赖的机制。如果对方在超时时间内不确认，发送方会一直重传，直到对方确认为止、或到达重传上限次数而Reset连接。
4、5 为重置连接报文、确认ACK报文，这两种报文对方接收到要ACK确认吧？不需要！自然发送方也不会重传这2种类型的报文。
为何Reset报文不需要ACK确认?
因为发送Reset报文的一端，在发送完这个报文之后，和该TCP Session有关的内存结构体瞬间全部释放，无论对方收到或没有收到，关系并不大。
如果对方收到Reset报文，也会释放该TCP Session 的相关内存结构体。
如果对方没有收到Reset 报文，可能会继续发送让接收方弹射出Reset报文的报文，到最后对方一样会收到Reset 报文，并最终释放内存。
为何ACK报文不需要ACK确认?
这里的ACK报文，是指没有携带任何数据的裸ACK报文，对方收到这样的ACK报文，自然也不需要ACK。否则，对方为了ACK己方的ACK，那己方收到对方的ACK，也要ACK对方的ACK，这就是一个死循环，永无止息。
所以为了避免这个死循环，一律不允许ACK对方的裸ACK报文。
那么按照这么说，TCP连接应该是四次消息交互啊。
-
A 发送SYN报文给B，这是第一次报文交互。
-
B发送ACK确认A的SYN报文，这是第二次报文交互
-
B发送自己的SYN报文给A，这是第三次报文交互
-
A需要ACK确认B的SYN报文，这是第四次报文交互
以上的演绎没有问题，但是报文2、3为何要分开发送呢？增加了延迟不说，同时还白白浪费了网络的带宽，完全可以将报文2、3合并起来，不就是在报文2的ACK状态位的位置置“1”就结了吗？
这就是三次消息交互的由来！
四次挥手
当客户端与服务器断开链接时，需要经过四次挥手的过程
- A向B发送中止请求，A -----FIN------> B
- B向A发送确认，B -----ACK------> A
- B向A发送中止请求，B -----FIN------> A
- A向B发送确认，A -----ACK------> B
经过四次挥手之后，AB双方会释放掉三次握手时所建立的缓存，因此连接也就不复存在了
那为什么在握手的时候第2、3步可以合并，但是挥手时却不能合并呢？
- 第一次挥手：当主动方发送断开连接的请求（即FIN报文）给被动方时，仅仅代表主动方不会再发送数据报文了，但主动方仍可以接收数据报文。
- 第二次挥手：被动方此时有可能还有相应的数据报文需要发送，因此需要先发送ACK报文，告知主动方“我知道你想断开连接的请求了”。这样主动方便不会因为没有收到应答而继续发送断开连接的请求（即FIN报文）。
- 第三次挥手：被动方在处理完数据报文后，便发送给主动方FIN报文；这样可以保证数据通信正常可靠地完成。发送完FIN报文后，被动方进入LAST_ACK阶段（超时等待）
- 第四次挥手：如果主动方及时发送ACK报文进行连接中断的确认，这时被动方就直接释放连接，进入可用状态。
这里需要注意一点，TCP的报文是会存在叠加的情况，即有可能会看到2和3同时出现在同一次请求中，但是这并不代表四次挥手变为了三次挥手，2和3之间已经没有了数据报文的发送，2和3的报文出现了叠加状态（这是我自己的理解）
