TCP为什么需要三次握手

网上给出的最常见的解释是：
若是两次握手，那么可能会产生不可避免的死锁：当客户端发起一个SYN请求，服务器会返回一个ACK确认该请求，然后建立单方向连接。此时若该ACK丢失，那么客户端将会无法得知服务器是否准备好。这种情况下，客户端不会建立反方向的连接，这将导致客户端一直等待ACK，而服务器端则在一直等待客户端发送数据，造成死锁。
这个解释问题在于：客户端不会一直傻傻的等待ACK，当一段时间ACK没有收到，它会认为服务器端没有收到自己发送的SYN请求，因此超时后会选择重发SYN，而不断重发的SYN中，总会有ACK返回，死锁自然解除。因此这个解释是不太令人信服的。
特南鲍姆在《计算机网络》中给出的一个例子是：
当客户端发起一个SYN请求，然而由于网络问题，超时未得到回应，于是客户端重新发起一个SYN请求，服务器端接收到了该SYN请求，建立起一个连接。但某个时候旧的请求绕了远路一段时间后才被服务器端接收到。
网上的一种看法是：
若是两次握手，那么服务器接收到旧的SYN请求后会响应一个ACK，两端连接建立完成。但由于客户端并不认为这个请求是有效的，则根本不会理睬返回的ACK，于是服务器一直等待客户端发送数据，而客户端不理睬服务器，这将造成资源的极大浪费。
这个问题在于：既然假设了两次握手就能建立一个连接，那么客户端只要收到了ACK确认，就没有义务再次检验这个请求是否是旧的。它将像下一种看法一样开启这条连接的另一副本（即不只是建立了单方面连接，在第一次握手后服务器端建立单方面连接，第二次握手后客户端不会是close状态，而是建立起反方向连接，这导致建立起一个完整TCP连接的副本）。
特南鲍姆的《计算机网络》看法是：
若是两次握手，那么服务器接收到旧的SYN请求后会响应一个ACK，两端连接建立完成。这将开启了一个新的连接，这个连接是之前发起连接的另一个实例（由于四元组相同），这将会导致两个连接可能同时存在，可能导致一个消息被重复发送。
我认为这种看法是合理的，因为为了避免序号预测攻击，每一次连接前会商定初始序列号，由于我们假定是两次握手，那么对于一个旧的SYN请求，客户端没有义务进行验证它的初始序列号。但我们加了初始序列号这个功能，就是为了避免旧的SYN请求有效，客户端应当对其进行验证。这导致初始序列号机制与两次握手机制出现两难，因此两次握手一定是不合理的。
接着我们论述为什么三次握手可以解决这一问题：
为了解决延迟报文段被视为有效的问题，我们引入了可变的初始序列号机制。因此当服务器接收到一个旧的请求时，它首先并不知道这个请求是否是旧的，因此仍然回复一个ACK确认该SYN段，但客户端发现该ACK对应的ack字段期望的值（初识序列号加1）对应的是一个已经过时的请求，因此不会建立单方面连接，并向服务器端发送第三次握手的通知（类似NAK），此时服务器端了解自己是被一个已经过时了的请求欺骗了，于是释放自己单方面的连接。最终结果是两个单方面连接都未建立，也即连接未建立，因此也没有浪费资源。
此外，我们还有关于为什么是三次握手而不是两次握手的原因补充：
为了实现可靠数据传输，TCP协议的通信双方，都必须维护一个序列号，以标识发送出去的数据包中，哪些是已经被对方收到的。三次握手的目的不仅在于让通信双方了解一个连接正在建立，还在于交换并确认初始序列号。如果只是两次握手，至多只有连接发起方的起始序号能被确认，另一方选择的序列号得不到确认。
附：这里仍有一个问题尚未解决：为了区分新旧SYN请求，相邻两次要使用不同的初识序列号，但就使用Wireshark抓包的结果来看，每次SYN（包括重发的）都是使用0作为初始序列号，这相当令人困惑