tcp协议为什么要三次握手(为什么要使用三次握手协议)

本文主要内容1、TCP数据包格式TCP数据包格式如下：注意到中间还有几个标志位：数据包格式当中，最重要的是理解序号和确认序号。TCP为什么是稳定可靠的，与序号与确认序号这套机制紧密相关，这也是TCP的精髓。2、TCP的三次握手众所周知，TCP协议是可靠的，而UDP协议是不可靠的。在一些场景中必须用TCP，比如说用户登录，必须给出明确答复是否登录成功等。而有些场景中，用户是否接收到数据则不那么关键，比如网络游戏当中，玩家射出一颗子弹，另外的玩家是否看到，完全取决于当前网络环境，如果网络卡顿，就会有玩家已经被射杀，但界面仍然刷新不出来的情况。这种情形适合UDP。为了保证TCP协议可靠，在建立连接之时就要得到保证。最初两端的TCP进程都处于CLOSED关闭状态，A主动打开连接，而B被动打开连接。（A、B关闭状态CLOSED——B收听状态LISTEN——A同步已发送状态SYN-SENT——B同步收到状态SYN-RCVD——A、B连接已建立状态ESTABLISHED）B服务器进程就处于LISTEN（收听）状态，等待客户的连接请求。若有，则作出响应。3、TCP的传输和确认TCP 传输的可靠性，可以用一句话归结：每收到对方数据，就发送 ACK 进行确定，发送方发送后没有收到 ACK 就隔一段时间重发。就是 A 向 B 发送消息（下面将 TCP 的报文直接看做是消息，消息一词跟 TCP 报文混用），B 收到消息后需要向 A 发送 ACK。这个 ACK 相当于返回结果，没有返回结果，A 就重新发送消息。归纳起来，A 有 3 种消息需要确认。另外 A 也可以发送 RST 消息，代表出错了。出错消息不需要确认。RST 也可以当成返回接口，替代正常的 ACK。返回 ACK，表示消息发送并处理成功，返回 RST 表示消息处理失败。因为通过网络传输，还有第三种结果，就是不确定成功失败。这样归纳起来。就有三种返回结果。这两种具体情况，A 根本识别不了，都只能重发。4、TCP的序号和确认序号A 向 B 发送消息，假如同时发送 a、b、c、d 消息，因为通过网络，这些消息的顺序并非固定的。而 B 返回 ACK 结果，这样就有一个问题，这个结果到底对应了哪个消息？另外当 A 超时重发后，原来的消息延时一段时候，又重新到达了 B，这样 B 就收到两条相同的消息，那么 B 怎么确定这两条消息是相同的呢？为了解决这个对应问题，每一条消息都需要有一个编号，返回结果也应该有一个编号。TCP 的序号可以看成是发送消息的编号，确认序号可以看成是返回结果的编号。有了编号，重复的消息才可以忽略，返回结果(ACK)才可以跟消息对应起来。当建立连接的时候，TCP 选定一个初始序号，之后每发送一个数据包（消息），就将序号递增，保证每发送不同的数据包，数据包的序号都是不同的。TCP 是这样处理的：SYN、FIN 也需要递增序号。不然 A 向 B 重发多个 SYN 或者 FIN, B 根本判断不了 SYN 是否相同，这样就不可以忽略重复的数据包了。当 TCP 发送 ACK 时，相当于返回结果，需要带有确认序号，以便跟发送的消息对应起来。当发送包编号为 a，递增长度为 len。其中 SYN 和 FIN 可以看成是递增长度为 1。这条消息可以这样表示为：现在来回顾三次握手过程。 A 发送序列号x给 B ， B 回复 A 确认号 x+ 1，同时发送序列号 y， A 接收到 B 的回复后，再回复确认号 y+1，同时发送序列号 x+1。给对方的回复一定是接收到的序号加1（或者是数据长度），这样对方才能知道我已经收到了，这样才能保证TCP是可靠的。

. TCP的三次握手最主要是防止已过期的连接再次传到被连接的主机。 如果采用两次的话，会出现下面这种情况。比如是A机要连到B机，结果发送的连接信息由于某种原因没有到达B机；于是，A机又发了一次，结果这次B收到了，于是就发信息回来，两机就连接。传完东西后，断开。结果这时候，原先没有到达的连接信息突然又传到了B机，于是B机发信息给A，然后B机就以为和A连上了，这个时候B机就在等待A传东西过去。2. 三次握手改成仅需要两次握手，死锁是可能发生 考虑计算机A和B之间的通信，假定B给A发送一个连接请求分组，A收到了这个分组，并发送了确认应答分组。按照两次握手的协定，A认为连接已经成功地建立了，可以开始发送数据分组。可是，B在A的应答分组在传输中被丢失的情况下，将不知道A是否已准备好，不知道A建议什么样的序列号，B甚至怀疑A是否收到自己的连接请求分组。在这种情况下，B认为连接还未建立成功，将忽略A发来的任何数据分组，只等待连接确认应答分组。而A在发出的分组超时后，重复发送同样的分组。这样就形成了死锁

在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。 第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器 进入SYN_RECV状态；第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入 ESTABLISHED状态，完成三次握手。通过这样的三次握手，客户端与服务端建立起可靠的双工的连接，开始传送数据。 三次握手的最主要目的是保证连接是双工的，可靠更多的是通过重传机制来保证的。

最近一段时间，看了Linux内核中的网络部分源码。在看完之后，一个很基本又经典的问题又浮现在我的脑海即“TCP协议为什么需要三次握手”，以前看过一些文章，但自己觉得都不是很清晰。下午有了点自己的想法，记录一下。 我们知道，TCP协议是一个面向连接的，可靠，全双工的传输协议。其中全双工的意思是说，通信双方可以同时发送，接收数据，类似于打电话。那么为了能确保这样的连接可以成功建立，至少需要保证通信双方至少可以可靠地发送，接受一次数据。为了方便叙述，假设参与通信的双方称为A,B。则在建立连接时，需要让A和B都认为自己和对方都可以发送，接收数据。在连接还没开始建立时，双方均认为自己无法发送和接收数据。方便表述，列表如下（左上角的字母表示站在谁的视角）假设A发起TCP连接，向B发送SYN包。如下图所示。在B还未收到该SYN包之前，A和B的对自身能力的认知的变化是，A可以认识到自己是有发送数据包的能力的，至于自己能否接收数据包，B能否接收，能否发送数据包，都是未知的，就认为没有此能力。如下图在B接收到SYN包后，B就可以认为自己有接收数据包的能力，也可以知道对端A有发送数据包的能力（因为接收到了SYN包）。A的认知还未变化，如下图所示。B收到SYN包后，按照协议，会发送SYN+ACK包。如下图所示。在这之后，在A接收到该包之前。B就可以认为自己有发送包的能力。此时，A，B的认知变为：在A收到SYN+ACK包后，A就可以认为自己有接收数据包的能力，并且B成功收到了自己的SYN数据包，B也有了接收数据的能力。同时这个SYN+ACK是B发来的，也就知道了B有发送数据的能力。此时，A，B的认知变成：在此时，看到A端已经可以认为自己，对端B都具有了发送，接收的能力。但这是B还无法确认A有正常接收自己数据包的能力。所以需要A再次发送一个ACK包，来让B确认自己可以正常接收数据包，“点亮”B的所有“认知”。从而正常地进行全双工通信，如下图：在B成功接收A发来的ACK包后，A,B就都可以认为自己，对端都有发送和接收数据的能力。如下图 从以上流程可以看到，3次握手，是可以让通信双发达成自己，对方都可以进行正常全双工通信认知的最少“捂手”次数。所以TCP选择了3次握手~

我们要知道TCP是全双工的，即客户端在给服务器端发送信息的同时，服务器端也可以给客户端发送信息。而半双工的意思是A可以给B发，B也可以给A发，但是A在给B发的时候，B不能给A发，即不同时，为半双工。单工为只能A给B发，B不能给A发；或者是只能B给A发，不能A给B发。rn在三次握手之后，A和B都能确定：我说的话，你能听到；你说的话，我也能听到。这样，就可以开始正常通信了。rn更多关于tcp为什么三次握手，进入：https://m.abcgonglue.com/ask/9df0911615834948.html?zd查看更多内容