图解TCP三次握手｜深度解析

本文主要是介绍图解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有时候接受，有时候又拒绝？？
这是因为现实的网络是很复杂的，很多情况并不是按照我们所设想或者所规划的进行，任何情况都有可能会发生。