TCP连接需要握手的原因

TCP协议是一个非常常见的全双工协议，它保证了数据的可靠传输。

使用TCP服务的程序一般需要三次握手来建立TCP的连接，根据RFC文档可知，TCP三次握手主要是让发送方和接收方知道各自的序列号，利用序列号来维护数据的可靠传输。

TCP协议三次握手流程如下：
seq表示序列号，ack表示应答号，ack = y表示该机器希望下次接收来的序列号为y，SYN = 1表示这是一个建立序列号同步的过程，ACK = 1表示这是一个应答消息
客户端随机生成一个序列号seq = x，向服务端发送该请求（SYN = 1，seq = x， ACK = 0， ack = ？）
服务端接收到客户端的请求之后，同样生成一个随机序列号seq = y，向客户端发送应答及其序列号（SYN = 1， seq = y， ACK = 1， ack = x+1）
客户端接收到接收的消息之后，向服务端发送一个应答消息（SYN = 0， seq = x+1，ACK = 1，ack = y+1）

在第一次，第二次握手中，是不允许携带数据的，而SYN = 1表示默认消耗一个数据，所以第二次握手中消息中的ack = x+1。
而第三次握手一般是不携带数据的，所以三次握手后客户端向服务端发送的第一个消息的seq = x+1

两次握手的可行性分析

但是为什么是三次握手而不是两次呢？经过两次握手之后发送方和接收方已经知道了双方的序列号了，是不是已经可以实现同步了？这是一个网络上很多人讨论的问题，以下我的一些分析，不保证对，希望大家一起讨论。

我们可以假设TCP握手协议只有两次：
客户端随机生成一个序列号seq = x，向服务端发送该请求（SYN = 1，seq = x， ACK = 0， ack = ？）
服务端接收到客户端的请求之后，同样生成一个随机序列号seq = y，向客户端发送应答及其序列号（SYN = 1， seq = y， ACK = 1， ack = x+1）

分析一个成功的场景：
客户端向服务端进行第一次握手，服务端向客户端发送应答并发送自己的序列号
此时，客户端因为已经接受到服务端的应答，所以可以确定自己的序列号已经被服务端知道，所以它下一步可以发送实际的数据了
而服务端向客户端发送了应答，它默认客户端已经知道了自己的序列号，所以分配连接的资源，等待客户端的下一个数据
若一切运行良好，客户端下一步向服务端发送大小为9的数据(SYN = 0，seq = x+1，ACK = 0， ack = y+1)
服务端接收后向客户端发送回应（SYN = 0， seq = y+1， ACK = 1， ack = x+11）

上面是运行良好的情况，但是网络中丢包现象是极为普遍的，我们可以再假设以下的情景
1.客户端发送成功了，接收端的应答丢失
此时客户机的状态：第一次握手请求（SYN = 1，seq = x， ACK = 0， ack = ？）迟迟没有回应，认为握手请求丢失，重传握手请求
服务器的状态为：已经为客户端分配了资源，等待客户端的第一条消息（期待消息的序列号为seq = x+1）。但此时接收到的消息为（SYN = 1，seq = x， ACK = 0， ack = ？），可以再次发送一次应答信号（SYN = 1， seq = y， ACK = 1， ack = x+1），并期待这次连接成功
若这次没有产生丢包，则可以进行正常的TCP通信了

2.客户端发送的第一次的消息在网络中发生了延时，再次发送第二次消息，此时，先后两次握手陆续到达，请求连接，服务端应答消息正常抵达客户端
此时客户机状态，两条连接请求都成功，但客户端会认为只有第二条请求成功
服务器状态：服务器接收到第一条握手请求后，分配相应资源，发送应答消息，之后再次接收到一个相同客户端的第一次握手请求
这时会出现两种情况：1.服务端有能力区分这两种请求是来自同一个客户端的相同请求，将第二次到来的握手请求丢弃处理。2.服务器没有能力区分这两种请求是来自于同一个客户端的相同请求，同样为这条请求分配资源，等待客户端的应答
若是第二种情况呢，虽然最后服务器到达一定时间后会自动断开TCP连接，收回资源，但是也造成了比较大的资源浪费。（不过这样或许能减少一些网络的流量？）
对于第一种情况呢，服务端分辨是否为同一请求有三个重要参考条件（端口号，IP，SYN = 1时的seq）
从我们可以在一个浏览器中开两个网页访问同一个网站，可以看出根据前两个条件服务端无法做出区分
接下来分析seq的情况，我们假设客户端重发握手请求时与前一次都是相同的seq，这样服务端或许就可以根据此消息中的同一个端口号，IP，seq判断出是同一个握手请求了（再加一个标志位或许可以不利用seq解决这种浪费资源的情况？）。

3.第三种思考是从TCP是一个全双工的协议来看的。我们之前的思考都是建立在TCP连接后客户端先主动向服务端发送消息。当然，实际我并没有想到什么服务端先向客户端发送数据的例子
若是有需要建立连接后服务端先向客服端发送消息的情况呢？
经过以下流程
两次握手都运行良好
客户端随机生成一个序列号seq = x，向服务端发送该请求（SYN = 1，seq = x， ACK = 0， ack = ？）
服务端接收到客户端的请求之后，同样生成一个随机序列号seq = y，向客户端发送应答及其序列号（SYN = 1， seq = y， ACK = 1， ack = x+1）
此时服务端的状态：准备发送一个序列号为y+1的数据（根据默认协议）
此时客户端的状态：准备接收一个序列号为y+1的数据
若是服务端发送的应答信息产生了丢包呢，此时服务端想要发送一个序列号为y+1的数据，但是客户端并不知道服务端的序列号。
此时就出现了无法解决的的错误
当然，由于博主学识有限，并未想到有关于服务端先向客服端发送协议的情况

这样分析之后，握手两次或许可行，不过，由于第2,3种情况的原因，再加上TCP的收到消息就给出应答的机制，或许还有一些博主没想到的方面，TCP最终选择了三次握手。毕竟，3次握手肯定比2次握手来得更为可靠。