本文主要是介绍图解TCP三次握手｜深度解析｜为什么是三次，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
写在前面
这篇文章我们来讲解析 TCP三次握手。
TCP 报文段
传输控制块TCB：存储了每一个连接中的一些重要信息。比如TCP连接表，指向发送和接收缓冲的指针，指向重传队列的指针，当前的发送和接收序列等等。
我们再来看一下TCP报文段的组成结构
TCP 三次握手
过程
假设有一台客户端，B有一台服务器。最初两端的TCP进程都是处于CLOSED关闭状态，客户端A打开链接，服务器端被打开链接。
一开始B的TCP服务器进程先创建传输控制块TCB，准备接受客户进程的链接请求，然后服务器进程就处于LISTEN收听状态，等待A的连接请求。
-
然后客户端进程首先创建
传输控制模块TCB。向服务端发出连接请求报文段，这是首部当中的同步位SYN=1，同时选择一个初始序号seq=x。TCP规定，SYN报文段(即SYN=1的报文段)不能写数据，但要消耗掉一个序号。
-
这时候客户端就进入了同步已发送的状态。服务端收到连接请求报文段后，如果同意建立连接，则向客户端发送确认，在确认报文段中把
SYN位和ACK位置都置为1，确认号为ack+1，同时也为自己选择一个初始序号y。同样的这个报文段也是不能写数据的，但同时要消耗掉一个序号。这时服务端进入了同步收到状态。
-
客户端收到服务端的确认之后，向服务端给出确认。确认报文段的
ACK置1，确认号ack=y+1，而自己的seq=x+1。ACK报文段是可以携带数据的，但如果不携带数据则不消耗序号，在这种情况下，下一个数据报文段的序号仍为seq=x+1。
这时候TCP已经建立了。两端都进行入了已经建立连接的阶段状态。
为什么是三次握手呢？
TCP是全双工，并且为了证明双方的收发能力只是一个表面的现象。更深层是为了防止 已失效的连接请求报文段突然又传送到了B 因而产生重复连接或者资源浪费。
我们来分析一下：
-
首先是正常情况：A发出连接请求，但因连接请求报文丢失而未收到确认。于是A再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接。
A共发送了两次连接报文请求，其中第一个丢失，第二个到达了B，没有已失效的连接请求报文段。
-
接下来是坏的情况：A发出的第一个连接请求报文段并没有丢失，而是在某些网络长时间滞留了，以致于到连接释放以后的某个时间才到达B。
本来这是一个早已失效的报文段，但B收到此失效的连接请求报文段后，就误认为是A又发出一次新的连接请求。于是B就向A发出确认报文段,同意报文连接。
但是由于现在A并没有发出建立连接的请求，因此不会理睬B的确认，也不会向B发送数据。 但B以为新的运输连接已经建立了，并一直等待A发送数据来，B的许多资源就这样白白浪费了！
- 又有一种情况是：
A接受了这次连接，所以又进行一次不必要的连接。
如果缺乏第三次握手，服务器无法知道客户端是否正确接收到了建立连接的ACK确认信号。因此，如果消息在网络中出现滞留，客户端将一直重复发送SYN请求(因为有消息滞留，意味着有客户端没收到响应，认为超时，所以重传了)，导致服务器不断建立新的连接。这将增加网络拥塞和延迟，并对整个网络性能产生负面影响。
有同学可能会疑惑，怎么A有时候接受，有时候又拒绝？？
这是因为现实的网络是很复杂的，很多情况并不是按照我们所设想或者所规划的进行，任何情况都有可能会发生。
三次握手无懈可击？
并不是无限可击。SYN-Flood攻 击是当前网络上最为常见的DDoS攻击，也是最为经典的拒绝服务攻击。
攻击者首先伪造地址对服务器发起SYN请求，服务器回应(SYN+ACK)包，而真实的IP会认为，我没有发送请求，不作回应。
服务器没有收到回应，这样的话，服务器不知道(SYN+ACK)是否发送成功，默认情况下会重试5次（tcp_syn_retries）。这样的话，对于服务器的内存，带宽都有很大的消耗。攻击者如果处于公网，可以伪造IP的话，对于服务器就很难根据IP来判断攻击者，给防护带来很大的困难。
那改进成四次握手?
三次握手有的缺陷，就算N次握手，也一样会有相关问题的出现！三次握手是在连接顺利的基础上最大地合理利用网络资源。
参考
[1] https://www.cnblogs.com/guoxiaoyu/p/17716038.html
[2] https://blog.csdn.net/u011037593/article/details/115024040
这篇关于图解TCP三次握手｜深度解析｜为什么是三次的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
