【java网络】深究TCP——建立连接三次握手；释放连接四次挥手

TCP的运输连接管理

TCP是面向连接的协议。
连接是用来传送TCP报文的。

过程：连接建立——数据传送——连接释放

解决问题：

• 要使每一方能够确知对方的存在；
• 要允许双方协商一些参数（如最大窗口值，是否使用窗口扩大选项和时间戳选项以及服务质量等）
• 能够对运输实体资源（如缓存大小、连接表中的项目等）进行分配

方式：客户服务器方式 （主动客户，被动服务器）

TCP建立连接：三次握手

TCP建立连接的过程叫做握手，需要交换三个TCP报文段；

看上图可能一头雾水，因为都是英文：
所以我们先把英文字母搞清楚：

• 同步SYN：首部结构
  在连接建立时用来同步序号。当SYN=1而ACK=0时，表明这是一个连接请求报文段。对方若同意连接，则在响应的报文段中使SYN=1,ACK=1。

• seq：初始序号

• 确认ACK：首部结构 仅当ACK=1，该字段有效

• ack：确认号；ack=x+1

• CLOSED：关闭状态

• LISTEN：收听状态

• SYN-SENT：同步已发送状态

• SYN-RCVD：同步收到状态

• ESTABLISHED：已建立连接状态
  知道了这些英文字母的含义，就很简单了；
  A主动打开连接，B被动打开连接

• 一开始，B的TCP服务器进程先创建传输控制块TCB，准备接受客户进程的连接请求。然后服务器进程就处于LISTEN（收听）状态，等待客户的连接请求。如有则做出响应。

• A的TCP客户进程也是首先创建传输模块TCB。然后在打算建立连接时，向B发出连接请求报文段，这时首部中的同步位SYN-1，同时选择一个初始序号seq=x。TCP规定，SYN报文段（即SYN=1的报文段）不能携带数据，但要消耗一个序号。这时，TCP服务器进程进入SYN-RCVD（同步收听）状态

• B收到连接请求报文段后，如同意连接，则向A发送确认。在确认报文段中应把SYN位和ACK位都置1，确认号ack=x+1，同时也为自己选择一个初始序号seq=y。请注意，这个报文段也不能携带数据，但同样要消耗一个序号，这是TCP服客户进程进入SYN-SENT（同步已发送）状态

• TCP客户进程收到B的确认后，还要向B给出确认。确认报文段的ACK置1，确认号ack=y+1，而自己的序号seq=x+1.TCP规定，ACK的报文段可以携带数据。但如果不携带数据则不消耗序号，在这种情况下，下一个报文段的序号任然是seq=x+1.这时，TCP连接已经建立，A进入ESTABLISHED状态

• 当B收到A的确认后，也进入ESTABLISHED状态

上面给出的连接建立过程叫做三报文握手。

刚开始看觉得有点蒙，很麻烦；
但和生活联系起来就很好理解；
比如你要跟人家约饭；
你（主动请求方）：约吗
他（被动接受方）：好的
你（主动请求方）：好我一会下来
这是不是需要三条消息才能成功；

为什么还要第三条呢？
假如你在说了约饭之后不想和他约饭了，又或者网卡了，这是两年前发的消息，说明你的请求链接已经失效，但他不知道，就一直在等。如果只采用两条就约饭成功，他就一直在等待，明显没有达到效果。

反过来再想为什么A最后还有发送一次确认呢？
一目了然了
防止已失效的连接请求报文段突然又传送到了B因而产生错误
已失效的报文段怎么产生的呢？
A发送的连接请求没有丢失，在某些网络结点长时间滞留，就早已失效。
可能出现的情况：
A：A请求报文丢失未能收到B的回复，会重传这种情况，这是正常情况；
B：A发送后经过时间延误到达B，这是一个已经失效的报文段，但B认为连接已经开始就一直在等A发来数据，造成资源浪费。

TCP连接释放：四次挥手

同样，先搞清楚英文单词

• 终止FIN：用来释放一个连接。当FIN=1时，表明此报文段的发送方的数据已发送完毕，并要求释放连接
• seq：序号
• 确认ACK：首部结构 仅当ACK=1，该字段有效- -
• ESTAB-LISHED：已建立连接
• FIN-WAIT-1：终止等待1
• CLOSE-WAIT：关闭等待
• FIN-WAIT-2：终止等待2
• TIME-WAIT：时间等待
• LAST-ACK：最后确认
• CLOSED：关闭

就拿上文中约饭的例子来类比吧；
A：吃完饭对B说，吃完了，我们走吧
B：听到后就说好，
A：收到B的回应，开始收拾（此时A没有发）
B：B也没有要吃的饭了，对A说好了
A：收到B的回应，等待B听到自己说的这句话
然后走了；

其实差不多就是这样一个过程；

• 数据传输结束后，通信双方都可释放连接。现在A和B都处于ESTABLISHED状态。A的应用进程先向其TCP发出连接释放报文段，并停止再发生数据，主动关闭TCP连接。A把连接释放报文段首部控制为FIN置1，其序号seq=u，它等于前面已传送过的数据的最后一个字节的序号加1，这时A进入FIN-WAIT-1（终止等待1）状态，等待B的确认。请注意，TCP规定，FIN报文段即使不携带数据，它也消耗一个序号。
• B收到连接释放报文段后即发出确认，确认号ack=u+1，而这个报文段自己的序号是v，等于B前面已传送过去的数据的最后一个字节的序号加1.然后B就进入CLOSE-WAIT（关闭等待）状态。TCP服务器进程这时
  应通知高层应用进程，因而从A到B这个方向的连接就释放了，这时的TCP连接处于半关闭状态，即A已经没有数据要发送了，但B若发送数据，A仍要接收。也就是说，从B到A这个方向的连接并未关闭，这个状态可能会持续一段时间。
• A收到来自B的确认后，就进入FIN-WAIT-2（终止等待2）状态，等待B发出的连接释放报文段。
• 若B已经没有要向A发送的数据，其应用进程就通知TCP释放连接。这时B发出的连接释放报文段必须使FIN=1.现假定B的序号为w（在半关闭状态B可能又发送了一些数据）。B还必须重复上次已发送过的确认号ack=u+1.这时B就进入LAST-ACK（最后确认）状态，等待A的确认。
• A在收到B的连接释放报文段后，必须对此发出确认。在确认报文段中把ACK置1，确认号ack=w+1,而自己的序号是seq=u+1（根据TCP标准，前面发送过的FIN报文段要消耗一个序号）。然后进入到TIME-WAIT（时间等待）状态。请注意，现在TCP连接还没有释放掉。必须经过时间等待计时器设置的时间2MSL后，A才进入到CLOSED状态。时间MSL叫做最长报文段寿命，RFC793建议设为2分钟。但这完全是从工程上来考虑的，对于现在的网络，MSL=2分钟可能太长了一些。因此TCP允许不同的实现可根据具体情况使用更小的MSL值。因此，从A进入到TIME-WAIT状态后，要 经过4分钟才能进入到CLOSED状态，才能开始建立下一个新的连接。当A撤销相应的传输模块TCB后，就结束了这次的TCP连接。

为什么要等待呢？

1. 保证A发送的最后一个ACK报文段能够到达B。加入A发送报文段丢失，此时B就收不到，所以需要超时重传。接着A再重传一次需要耗时。
2. 防止已失效的连接请求报文段出现在本链接中。A在发送完最后一个ACK报文段后，再经过时间2MSL，就可以使下一个新的连接中不会出现这种旧的连接请求报文段。

还有一个保活计时器；
例：客户端出现故障，服务器每收到一次客户的数据，就重新设置保活计时器，时间设置通常是两小时。如果两小时还没收到则发送一个探测报文段，以后每隔75秒发一次，如果十次后仍无客户的响应。则服务器认为客户端出了故障，关闭这个连接。