tcp为什么不是2次握手(tcp为什么不是四次握手)

这也是个问题但是这肯定比二次握手好些 A认为连接成功B发送的确认丢失了 不是还有个RST标志吗这个会复位连接的

为什么不是两次 我们先来将三次握手这个过程捋一遍。(S-服务端，C-客户端)第一次握手后，S可以确认自己收报文与C发报文的功能都正常，而C呢，它什么都不能确认。第二次握手后，C可以确认自己的收发报文与S的收发报文功能都正常，也就是认为连接已建立。那么第三次呢，S也可以确认双方能够正常通信。假想一下，如果我们去掉了第三次呢？因为我们不进行第三次握手，所以在S对C的请求进行回应(第二次握手)后，就会理所当然的认为连接已建立，而如果C并没有收到S的回应呢？此时，C仍认为连接未建立，S会对已建立的连接保存必要的资源，如果大量的这种情况，S会崩溃。 因此第三次握手是必要的。

三次握手的目的：是为了确认双方都有收发数据的能力。 第一次： A->B，证明A有发消息的能力。第二次： ->B && B->A，证明B有收消息，并且有发消息的能力。第三次： A->B，证明A有收消息的能力。 二次握手达不到目的，四次多余。

1.采用两次握手，那么若Client向Server发起的包A1如果在传输链路上遇到的故障，导致传输到Server的时间相当滞后，在这个时间段由于Client没有收到Server的对于包A1的确认，那么就会重传一个包A2，假设服务器正常收到了A2的包，然后返回确认B2包。由于没有第三次握手，这个时候Client和Server已经建立连接了。再假设A1包随后在链路中传到了Server，这个时候Server又会返回B1包确认，但是由于Client已经清除了A1包，所以Client会丢弃掉这个确认包，但是Server会保持这个相当于“僵尸”的连接。 所以采用两次握手，有可能会浪费Server的网络资源。形象解释：1，客户发一个暧昧的消息，给服务员2，服务员收到，看了消息，很高兴，马上回信(此时客户还不知道服务收到)3，客户特别高兴收到服务员关系确认的消息，(但是服务员还不知道客户收到了，如果没收到得重发，理论上来说，直到海枯石烂=-=)4，服务员终于收到了客户关系确认的消息，悬着的心终于放下了5，于是客户跟服务员真正建立了 一条可靠的通道，毕竟两人都知道那是行得通的。。。所以至少得三次才能确认关系不用三次的话，server不能确定client是否收到自己的消息如果没有收到，可能client根本没收到，或者client响应了，但server没收到如果你用过对讲机你就会明白：C ->S: 你能听到吗？S->C: 听到。你能听到我吗？ C->S:听到。
为什么不是两次 我们先来将三次握手这个过程捋一遍。(S-服务端，C-客户端)第一次握手后，S可以确认自己收报文与C发报文的功能都正常，而C呢，它什么都不能确认。第二次握手后，C可以确认自己的收发报文与S的收发报文功能都正常，也就是认为连接已建立。那么第三次呢，S也可以确认双方能够正常通信。假想一下，如果我们去掉了第三次呢？因为我们不进行第三次握手，所以在S对C的请求进行回应(第二次握手)后，就会理所当然的认为连接已建立，而如果C并没有收到S的回应呢？此时，C仍认为连接未建立，S会对已建立的连接保存必要的资源，如果大量的这种情况，S会崩溃。 因此第三次握手是必要的。

建立连接的过程是利用客户服务器模式，假设主机A为客户端，主机B为服务器端。 （1）TCP的三次握手过程：主机A向B发送连接请求；主机B对收到的主机A的报文段进行确认；主机A再次对主机B的确认进行确认。（2）采用三次握手是为了防止失效的连接请求报文段突然又传送到主机B，因而产生错误。失效的连接请求报文段是指：主机A发出的连接请求没有收到主机B的确认，于是经过一段时间后，主机A又重新向主机B发送连接请求，且建立成功，顺序完成数据传输。考虑这样一种特殊情况，主机A第一次发送的连接请求并没有丢失，而是因为网络节点导致延迟达到主机B，主机B以为是主机A又发起的新连接，于是主机B同意连接，并向主机A发回确认，但是此时主机A根本不会理会，主机B就一直在等待主机A发送数据，导致主机B的资源浪费。 （3）采用两次握手不行，原因就是上面说的失效的连接请求的特殊情况。
其实就是。 你瞅啥。瞅你咋地。来咱俩好好唠唠 剩下的就不可描述的传输上了。
如果是二次握手那么连接接受方只知道自己同意不知道请求方是否同意（即请求是否可信）防止意外中断。如果是四次握手那么多余一次无确认（ack）意义，在信号逻辑设计又要求最简原则。综上3次握手最好，