标签：发送 报文 TCP 彻彻底底 四次 FIN 握手 客户端
三次握手
我们先提出一些问题，但是我们暂且不回答这些问题，下面我会尽我所能详尽地讲解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
标签：发送,报文,TCP,彻彻底底,四次,FIN,握手,客户端 来源： https://www.cnblogs.com/thewei/p/15512237.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。