TCP是什么？
TCP全称是Transmission Control Protocol（传输控制协议）。在OSI（Open System Interconnect）模型（由七层组成，分别为物理层、数据链路层、网络层、传输层、会话层、表示层、应用层）中属于传输层，七层协议示意图如下：
这样分层是易于理解、学习和更新协议标准（更新某一层的协议，不会干扰到其他层）,网络分层，就像一个筛子，能快速定位故障发生的地方，更便于故障排除。
那传输层的主要作用是什么呢？传输层提供应用程序间的通信。其功能包括：一、格式化信息流；二、提供可靠传输。为实现后者，传输层协议规定接收端必须发回确认，并且假如分组丢失，必须重新发送。
TCP是面向连接的协议，其显著的特征是在传输之前需要3次握手形成会话。只有会话形成后，客户端与服务端之间才能互相发送数据。
建立TCP连接的三次握手？
因为TCP协议是双向通信的，不是一方向另一方单向通信，这就意味着双方都具备有发送与接收的能力。那怎么确定都有发送与接收能力呢？
第一步：A向B请求连接，发送信息x，等待确认（试探B的接收与发送能力）。（完成第一次握手）
第二步：B接收到A的消息后，确认消息（ACK置为1，A具有发送能力），然后向A发送消息y请求连接（y是建立在x上的，试探A的接收能力）（完成第二次握手）
第三步：A接收到B的消息，确认消息（ACK置为1，确认B具有接收与发送的能力，A进入establish状态），然后发送B消息z(z是建立在y上的)，B确认消息（A具有接收能力，B进入establish状态）（完成第三次握手）
这样建立一个TCP连接，需要客户端和服务端总共发送3个包(x、y、z)以确认连接的建立。经过这三次握手就能确定A与B都具备发送与接收的能力。图解如下：
直白地表达这过程可以为：
Client:"Server,你能接收到我的消息吗"
Server:"Client,我能接收到你的消息，你能接收我的消息吗？"
Client:"Server,我也能接收到你的消息，我们开始聊聊今天会不会下雨"
Server:"Client,好的，今天会下雨哦，balabala..."
断开TCP连接的四次挥手？
由于TCP连接时全双工的，因此，每个方向都必须要单独进行关闭，那怎么确定两个单独都关闭了呢？
第一步：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。（第一次挥手）
第二步：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。（第二次挥手）
第三步：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。（第三次挥手）
第四步：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。（第四次挥手）
这样断开TCP连接需要四次挥手，如图：
直白的类比：
男女票都要确认对方微信下线
- 四次挥手
男票："亲爱的，这么晚了，不跟你聊了，我微信下线了啊"（男票处于等待状态，等待女票回复）（第一次挥手）
女票：“亲爱的，好吧”（批准男票下线，女票也在准备下线了）（第二次挥手）
（男票看到这个继续等待，等待女票下线的信号）
女票：“那我也微信下线了”（女票告诉男票也要下线，这时女票处于等待状态，等待最后的确认，要让男票也知道自己要下线了）（第三次挥手）
男票：“好的，下吧”（告诉女票知道了。确认女票要下线了，安心了，男票下线！）（第四次挥手）
（女票看到确认信息后，知道男票晓得自己要下线了，然后可以安心下线了！）
- 两次挥手会怎么样？
男票："亲爱的，这么晚了，不跟你聊了，我微信下线了啊"（男票处于等待状态，等待女票回复）（第一次挥手）
女票：“亲爱的，好吧”（批准男票下线，女票也在准备下线了）（第二次挥手）
此时男票看到后不管女票下不下线，不回复，直接下线了（导致的结果是女票不要他了，不管我下不下线肯定不要）
- 三次挥手会怎么呀？
男票："亲爱的，这么晚了，不跟你聊了，我微信下线了啊"（男票处于等待状态，等待女票回复）（第一次挥手）
女票：“亲爱的，好吧”（批准男票下线，女票也在准备下线了）（第二次挥手）
女票：“那我也微信下线了”（女票告诉男票也要下线，这时女票处于等待状态，等待最后的确认，要让男票也知道自己要下线了）（第三次挥手）
此时男票知道女票也会下线，安心了，然后下线了（导致的结果是女票还是不要他了，因为女票不知道男票到底看到了没，就下线了，要知道女票还在等回复呢）
- 五次挥手？
男票："亲爱的，这么晚了，不跟你聊了，我微信下线了啊"（男票处于等待状态，等待女票回复）（第一次挥手）
女票：“亲爱的，好吧”（批准男票下线，女票也在准备下线了）（第二次挥手）
（男票看到这个继续等待，等待女票下线的信号）
女票：“那我也微信下线了”（女票告诉男票也要下线，这时女票处于等待状态，等待最后的确认，要让男票也知道自己要下线了）（第三次挥手）
男票：“好的，下吧”（告诉女票知道了。确认女票要下线了，安心了，男票下线！）（第四次挥手）
女票：“我看到了，那我们下线吧”（第五次挥手）
男票看到后，心想（看到了你下线啊，又要回复你，占用时间啊）要么直接下线（这是五次挥手，浪费了时间，又不回复影响不好），要么再发确认消息（这尼玛要挥手多少次啊，还能不能下线了）
所以四次挥手是最合理的，哈哈（有不合理的可以在评论里喷喷，哈哈）
为什么连接的时候是三次握手，关闭的时候却是四次握手？
因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。
