TCP中的三次握手和四次挥手
TCP中的连接和断开可以说是在面试中经常被问到的问题之一，正好有空就总结一下，首先回顾一下TCP的相关知识点
1. TCP的基础知识
1.1 TCP的基本概念
我们知道TCP是运输层的面向连接的可靠的传输协议。面向连接的，指的就是在两个进程发送数据之前，必须先相互“握手”，确保两进程可以进行连接。并且这个传输是点对点的，即一个TCP连接中只有一个发送方和接收方；可靠的，指的是在任何网络情况下，在TCP传输中数据都将完整的发送到接收方。
1.2 TCP的报文段结构
-
源端口和目的端口：和UDP一样用于多路复用/分解来自或送到上一层
-
序号：一个报文段的序号是整个传送的字节流序列，而不是该报文段的序列
-
确认号：主机正在等待的数据的下一个字节序号
-
数据偏移：指TCP首部的长度，可变。默认长度为20字节
-
窗口：用于流量控制，用于指示接收方愿意接受的字节数量
-
标志字段：
- ACK：当该位为1时，确认号有效
- RST：该位为1时，表示TCP连接中出现异常必须强制断开连接
- SYC：该位为1时，开始建立连接，并且序号字段进行序列号初始值的设定
- FIN：该位为1时，断开连接，通信双方相互交换FIN位置为1的TCP段后断开连接
2. TCP连接
2.1 什么是连接(connection)和会话(Session)
连接是数据传输双方的契约，在设计上，连接是一种传输数据的行为，具体来说，数据收发双方的内存中都建立一个用于维护数据传输状态的对象，比如TCP 的连接组成包括一台主机上的缓存、变量和与进程连接的套接字，以及另外一台主机上的缓存、变量和与进程连接的套接字。（由端口号和IP地址组成）所以连接是网络行为状态的记录
而会话是应用的行为，比如说你在微信上给人发消息，打开应用聊天窗口和对方聊天是一个会话，但是连接只有在进行发消息、语音的时候连接才开启。其他不发消息和语音时，连接可能暂时断开，但是只要不关聊天窗口，会话时一直存在的。
总结而言，会话是应用层的概念，连接是传输层的概念，正是因为如此，在 TCP 连接的时候需要握手建立连接。
3. TCP连接建立
3.1 TCP 协议中的基本操作
也就是报文段的标志字段的含义和功能：
- SYN(Synchronization)：请求同步，一个 Host 主动向另外一个 Host 发起连接。当 SYN=1，ACK=0 时，表示这是一个请求建立连接的报文段；当 SYN=1，ACK=1 时，表示对方同意建立连接
- PSH(Push): 数据推送，一个 Host 主动向另外一个 Host 发送数据
- FIN(Finish): 请求完成，一个 Host 主动断开请求,如果 FIN=1，表示数据已经发送完成，可以释放连接。
- ACK：表示前面的确认号字段是否有效。ACK=1 时表示有效。只有当 ACK=1 时，前面的确认号字段才有效。TCP 规定，连接建立后，ACK 必须为 1
- RST：表示是否重置连接。如果 RST=1，说明 TCP 连接出现了严重错误（如主机崩溃），必须释放连接，然后再重新建立连接。
如图，开始时，两个端口都是出于closed状态，当服务器端口变成listen时，监听端口，是否有数据传来。
-
第一步：客户端向服务端发送一个特殊的TCP报文段。客户端进入SYN_SENT状态这个报文段有以下特点：
- 不包含应用层数据，封装在一个IP数据报中发送给服务器
- SYN为1（此步是ACK唯一可为0处，其他时间均为1）
- 序号段有一个随机生成的初始序号（client_isn）
-
第二步：服务器端收到上步客户端的报文段后，同时为该TCP连接分配TCP缓存和变量，并向该客户发送允许连接的报文段。服务器进入SYN_RCVD状态，这个报文段特点有：
- 不包含应用层数据
- SYN为1，ACK为1
- 确认号段被置为client_isn + 1，序号段被置为server_isn
-
第三步：客户端收到上步服务端的报文段后，客户端为该连接分配缓存和变量，同时客户端向服务器端发送报文段，这个报文端特点有：
- 可以包含应用层数据
- SYN为0，ACK为1
- 确认号段被置为server_isn + 1
两端进入ESTABLISHED状态，连接建立
4. TCP连接断开
若客户端决定要关闭该连接（服务器端也可以发起关闭）
- 第一次：客户端发送带有FIN被置为1的报文段，进入FIN_WAIT_1状态，并等待一个来自服务器的带有确认的TCP报文段。
- 第二次：服务器端收到该报文段后，向客户端发送一个确认ACK报文段，进入CLOSE_WAIT状态。
- 第三次：服务器端处理完数据后向客户端发送FIN被置为1的报文段，进入LAST_ACK状态。
- 第四次：客户端收到服务器端的FIN报文段后，向服务器端发送一个确认ACK报文段，进入TIME_WAIT状态，服务器接收到该ACK报文段后关闭，客户端在经过2MSL（与具体实现有关，典型值是20s、1分钟或2分钟）等待后关闭。
5. 关于TCP连接的面试题
5.1 如何唯一确定一个TCP连接
可以通过四个变量来确定唯一的TCP连接：源地址、源端口、目标地址、目标端口来唯一确定一个TCP连接。其中源地址和目标地址的字段在IP头部，作用是通过IP协议发送报文给哪个主机；源端口和目标端口是在TCP首部，作用是通过TCP协议发送主机中的哪个进程。
5.2 UDP和TCP有什么区别
两者的区别
- UDP面向无连接，利用IP提供无连接的传输数据服务
- UDP可以支持一对多、一对一、多对多的交互通信
- UDP不保证可靠交付数据，传输过程中可能会丢包
- UDP首部只有固定的8字节；TCP首部最短20字节，能够变化
应用场景
- UDP用于包总量较少的通信，如DNS、SNMP；还有视频、音频等多媒体通信，以及广播通信等等
- TCP用于需要保证可靠性数据交付的场景，比如FTP、HTTP
5.3 为什么是三次握手？
为什么TCP连接建立过程中不是两次或者四次，三次就是最优解了吗？首先来看看两次握手建立连接会发生什么。
两次握手
如果连接过程是两次握手来建立，在理想的网络环境下是可以完成通信建立的，但是现实的网络环境很复杂，有时候会导致历史的报文段比新的报文段先到达服务器端，这时，如果没有第三次握手，就会造成无法同步序列号情况的发生。举个例子，客户端发送新SYN报文段的序号是100，网络环境中有旧的SYN报文端的序号是80，然而现在旧的先到达服务器端，那么服务器端则会返回一个确认号为81的SYN+ACK报文段，这个时候客户端接收到的报文段和预期报文段会不一致，就会造成无法同步序列号，达不到TCP可靠运输的效果，也会浪费资源。那么如果有第三次握手，这时客户端会反馈一个RST报文段，终止这次连接，等待新的SYN到来，这样保证数据的可靠性传输。
四次握手
四次握手可以对比四次挥手，客户端和服务器端都要分别发送SYN和ACK报文段，来表示之前的SYN报文已经被成功接收。
然而四次握手可以简化成三次，第二、三次可以优化成一次。所以三次是保证可靠性传输连接的最优解。
5.4 什么是SYN 泛洪？如何避免
SYN泛洪攻击通过发送大量的TCP SYN报文段，而不完成第三次握手的步骤。因为大量的SYN报文段的发送，服务器不断为这些半开连接分配资源，导致服务器的连接资源被消耗殆尽。
如何避免，现在有一种有效的防御系统，称为SYN cookie，它是这样工作的：
- 当服务器接收到一个SYN报文段时，它并不知道该报文段是来自一个合法用户还是SYN泛洪攻击的一部分。因此服务器不会为该报文段生成一个半开连接。相反，服务器会生成一个初始TCP序列号cookie值（由目的IP地址与端口号以及仅有该服务器知道的秘密数的一个复杂函数），并发送给客户端
- 如果客户是合法的，将会返回一个ACK报文段。而且当服务器收到该ACK后，需要验证该ACK是与前面发送的SYN相对应，并生成一个具有套接字的全开的连接。如果没有返回一个ACK报文段，则初始的SYN并没有对服务器产生危害，因为服务器也没为它分配任何资源。
5.5 为什么是四次挥手
四次挥手中双方发送了FIN报文段，所以在客户端发送FIN后，服务器端接收到后首先会回一个ACK应答报文，因为此时服务器端可能还有数据没发送完，所以在服务端数据处理完后，才发送FIN报文段给客户端表示现在可以关闭连接。正是因为这个等待过程，使得比三次握手多一次。
5.6 如果已经建立了连接，客户端出现故障了怎么办？
TCP有一个机制是保活机制：定义在一个时间段内，如果没有任何连接相关的活动，TCP保活机制则开始作用，每隔一个时间间隔会发送一个探测报文，该探测报文包含的数据很少，如果连续几个探测报文都没有得到响应，说明该TCP连接已经死亡。
客户端的故障也分为这几种：
- 对端系统正常回复探测报文，TCP保活时间重置，等待下一个保活时间到来，TCP连接正常运行。
- 对端程序崩溃并重启，此时可以对探测报完进行响应，但是没有连接的有效消息，序列不符合，最后会产生RST报文，这时连接被重置。
- 对端程序彻底崩溃，无法响应探测报，经过几次连续无响应后TCP会报告此连接已经死亡
5.7 为什么需要TIME_WAIT状态
首先要说明，只有主动发起关闭连接的一方才会有TIME_WAIT状态，那么为什么会有TIME_WAIT状态，这时因为在服务端关闭后，可能还会有其他的数据报未到达客户端，所以需要再等待一段时间。一般这个时间是2MSL时间，也就是报文段在两端传输的最大往返时间。
TIME_WAIT状态太多也会导致占用过多的端口资源，会导致无法创建新的连接
参考博客：
https://mp.weixin.qq.com/s/tH8RFmjrveOmgLvk9hmrkw