发送确认消息的主要目的是防止无效连接请求消息突然传输到服务器。有两种情况：1。c发送一条请求消息，但由于连接请求丢失而没有收到确认，因此c重新发送一次连接请求，接收确认帧，建立连接，并在数据传输后释放连接。c发送两个连接请求消息段，其中一个丢失，第二个到达s.2。如果c发送的第一条连接请求报文没有丢失，而是长时间滞留在某个节点上，当s收到无效的连接请求报文段时，误认为c已经发送了另一条连接请求，于是向c发送确认报文段，并同意建立连接。假设没有三次握手，只要s发送一个确认，就会建立一个新的连接。对于三次握手，c不发送连接请求，因此它不关注s的连接请求确认。
用于解决网络服务的不可靠性。我觉得关键在于：第一次握手保证连通性，第二次握手保证数据传输，第三次握手保证传输结果一致
如果此时ack在网络中丢失，服务器上的tcp连接状态为synrecv，等待3秒、6秒，依次12秒重新发送synack数据包，以便客户端可以重新发送ack数据包。可以通过设置/proc/sys/net/ipv4/tcpsynack来设置服务器重新发送synack数据包的次数默认值为5。如果在指定的重新传输次数之后没有收到ack响应，服务器将在一段时间后自动关闭连接。但是，客户认为连接已经建立。如果客户机向服务器写入数据，服务器将用rst包（用于强制关闭tcp连接）进行响应，然后它可以感知服务器的错误。
-----解决方法：对不起，我不对。计时器应该在服务器端。如果发送syn和ack消息后，无法收到对消息的回复，则认为刚刚发送的消息丢失，应重新发送syn和ack消息。我说的话不权威。在网络账本上我没提过。我不知道是否会有一个在tcp/ip的详细解释。你可以去看看。
我以前做过一个基于udp的应用，主要是考虑到udp开销小，udp不可靠，但是我们的要求是可靠，所以我们要在应用层做一些工作，比如增加crc校验，设置定时器，客户端超时重传。明白这点就足够了。你去哪儿面试了？我不认为有很多协议可以问。失败后，相当于ddos攻击。将有一个半连接。在超时之前，它将占用服务器资源。------第三次握手失败，应该说是ack不匹配，没有等待远程消息。
2.通过状态图，我们可以知道当前服务器处于syn状态，对应于rcvd状态的ack报文处理代码如下
