三次握手
我们先提出一些问题，但是我们暂且不回答这些问题，下面我会尽我所能详尽地讲解TCP的三次握手过程，然后看完你可以在评论区留下你对问题的答案，我们可以一起探讨。
- 为什么要握手
- 为什么是三次而不是两次或者四次
- 相比不需要握手的UDP有什么优点和缺点
- 握手的过程可以携带数据吗
- 握手的过程会带来什么安全问题吗
TCP被称为是面向连接的，这是因为一个应用进程可以开始向另一个应用进程发送数据之前，这两个进程必须先互相“握手”，以建立确保数据传输的参数。
下面放一张图
首先cilent向server发送SYN（用于建立连接的字段）报文，这里seq取一个随机数（不知道seq作用的可以另外单独理解，不妨碍理三次握手），这个报文是不携带数据的，然后发送完之后，cilent就变成SYN_SENT状态（等待接受ack报文）并且可能建立发送缓冲区，然后server接受到cilent的请求连接报文之后（第一次握手），发送SYN-ACK报文，同样不携带数据，在这一时间也可能建立接受缓冲区，注意到这里，因为这个特质，导致服务器可能被洪范攻击
（假如攻击者发送大量TCP SYN报文（第一次握手），然后又不进行第三次握手，服务器就要为这些大量的第一次握手分配资源（比如缓存），导致服务器的连接资源被消耗殆尽（当然魔高一尺，道高一丈，有一种防御系统SYNcookie可以应对））
最后客户端接受到SYN-ACK报文后发送第三次握手，注意这一次握手是可以携带数据的
整个过程就像你游戏开语音，你进去csgo的时候，会主动开麦（客户端），喂喂听得到吗，然后队友说能听到，你能听到我的吗（第二次握手），最后你说，我也能听到你说话，接下来我们怎么怎么打（第三次握手），假如两次握手的话，我是知道队友能听见我说话了我也能听见队友说话了，但是你管队友了吗。四次的话，废话少说吧就
TCP的握手确保了双方都能全双工地进行通信，使得通信是有保障的，当然这样也会浪费一些时间，但是是值得的，大部分重要的事情还是求稳比较好，这也是TCP存在的意义，可靠且值得交付。
好了讲完之后我再给大家留个问题，那个seq有什么作用大家能回答吗（提醒，假如我说喂，你听得到吗，假如对面恰巧没带耳机，没听到怎么办，又或者团队游戏，他不知道是哪个人在发言怎么办）
四次挥手
- 为什么是四次挥手
- 为什么要TIME_WAIT或者CLOSE_WAIT
- TIME_WAIT的时间设置为多长比较好
老规矩先上图
这是一个较为简单的报文交换图，中间省去了很多状态（都是逻辑状态，省略了就省略了吧）。因为是全双工通信，所以当客户端首先发送FIN报文时，就是想告诉服务器，它要关闭连接了，接收到ACK进入一个FIN_WAIT2的状态，这个时候客户端就已经不在发送数据了。那么问题来了，还要保持连接干嘛？为什么不直接关闭连接
那是因为客户端的数据是发送完了，服务端数据还不一定发送完了呢。你问人家一个问题，你是问完了，人家还不一定回答完了你就打断人家不太好吧。所以当服务端发送完数据后就发送FIN报文给客户端，这个时候客户端再发送ACK告诉服务端说收到。
但是注意！！这个时候连接还没有关闭噢，你想想，假如这个ack报文丢失了怎么办，前面的报文丢失，都可以超时重传，但是这里客户端你就直接关闭连接，假如ack丢失，服务端一直在等你的答复你却已经走了，是不是也不太好。所以即使发送完最后的ack应答报文，会有一个TIME_WAIT的时间，这样当ack丢失时，服务端超时未收到会再发一次FIN，客户端就知道丢失了重传
那么这个wait的时间是多久呢，因为当超过一个MSL时，重发FIN，重发FIN最多需要一个MSL，客户端知道丢失的时间最长为2MSL，所以wait的时间为2MSL