### TCP 三次握手过程是怎样的？
TCP的建立连接是通过三次握手来进行的。三次握手的过程如下图：
说实话这个很好理解,我称之为N字型
首先我们理解到建立连接是一个虚的概念了对吧?那么我们来设计一个可靠的TCP,首先建立连接是必须的吧?相当于我们打电话,总要先说一句喂---wei?(面向连接正是这个意思!)
那么这里顺便谈谈他们很爱问的一个问题
首先你(客户端)要和我(服务端)打电话,我们再要说出内容时,都需要先确定下,网络如何?对方能否听到吧?
而上图中蓝色的SYN相当于就是问候服务器能否听到,然后服务器的ACK对应的就是我能听到,
而这里我们说的"我能听到"在现实中映射到TCP中就代表着ACK而且是SYN,因为接下来对方会回复你说"好"或者说"原本要和你说的内容"也即是绿色的ACK
然后两次的话,是必然不可行的,双方都确认对方能接收信息才能说这个连接建立成功,那么能准确证明两个不行吗?首先要双方都确认必然要2SYN和2ACK,那么很明显两个ACK的分配,要么(1,1),要么(2,0)这里2,0可以顺序相反,(2,0)意味着单方发出两个ACK必然不行!(1,1)意味着双方都发ack,那么必然在时间上有交错,因为同时发的话,这个ack就没用了,ack有用的前提是收到syn后再发,同时时间交错则也只能保障单次ack生效,在前发的ack无效
所以证毕,至少三次握手
那么四次可行吗?肯定可以啊,不谈那些不太荒唐的,你把server的ack和syn拆分后就可以了,只不过比较浪费带宽
到此如果要实现上述功能我们只需要SYN和ACK便够了,那么又为何带上SeqNum呢?以及ACK的时候要对应的+1呢?仅仅是说对暗号的情况吗?因为我们计算机会维持多个tcp连接,通过这个来知道他对应的是哪个连接吗?是的,但是仅此而已吗?
所以更深层上三次握手还能实现其他功能:
下面是小林的解释,我来用我自己的话,来让自己更好地了解,首先情况是服务端seqNum为90的这个报文发送后,重启了那么又重新想向服务端建立连接,所以发了个新的seqNum为100,如果90的报文仍然到达了服务端,那么服务端会再发送90对应的90+1的ACK+SYN,那么这时你客户端不就可以确认了吗?你就会弄一个RST位为1的报文,给服务端,效果类似说"打错了",然后之后100的服务端会再发送100+1,
同理我们这个"N"的下一个折角处也是可以防止服务端重启后,这个SYN+ACK导致的历史链接的问题
然后值得注意的一点是,如果服务端收到客户端报文的顺序是：「旧 SYN 报文」->「新 SYN 报文」
那么服务端并不是说同样地给这个返回RST,因为谁是挑战者不好说!对他来讲90可能是新的也可能是旧的,100同样,所以他采用的是认定先来的
所以他返回的是ChangeACK报文给客户端,这个 ack 报文并不是确认收到「新 SYN 报文」的，而是上一次的 ack 确认号，也就是91（90+1）。说白了,解玲还需系铃人,所以这个RST报文只能由他们的原先发送者确认是否结束
序列号在 TCP 连接中占据着非常重要的作用，所以当客户端发送携带「初始序列号」的 SYN 报文的时候，需要服务端回一个 ACK 应答报文，表示客户端的 SYN 报文已被服务端成功接收，那当服务端发送「初始序列号」给客户端的时候，依然也要得到客户端的应答回应，这样一来一回，才能确保双方的初始序列号能被可靠的同步。
如果只有「两次握手」，当客户端发生的 SYN 报文在网络中阻塞，客户端没有接收到 ACK 报文，就会重新发送 SYN ，由于没有第三次握手，服务端不清楚客户端是否收到了自己回复的 ACK 报文，所以服务端每收到一个 SYN 就只能先主动建立一个连接
如果客户端发送的 SYN 报文在网络中阻塞了，重复发送多次 SYN 报文，那么服务端在收到请求后就会建立多个冗余的无效链接，造成不必要的资源浪费。