TCP的传输连接管理

概要

传输连接有三个阶段，即：连接建立、数据传送和连接释放。

TCP 连接的建立都是采用客户服务器方式。

主动发起连接建立的应用进程叫做客户(client)。
被动等待连接建立的应用进程叫做服务器(server)。

TCP的建立连接（用三次握手建立TCP连接）

图片说明
STEP1(SYN)：客户端要与服务器建立连接，因此它向服务器发送一个带有SYN(同步序列号)的段，该段通知服务器客户端要开始通信了，并且以什么序列号开始段
STEP2(SYN+ACK)：服务器通过设置SYN-ACK信号位来相应客户端的请求，ACK=1表示该段的确认号有效了，确认号告诉对方，刚刚的请求我收到了，SYN表示可能使用哪个序列号
STEP3(ACK)：客户端确认服务器的相应，ACK=1,确认号告诉对方，你的相应我收到了

然后开始实际的数据传输

步骤1和2建立一个方向——客户端到服务器的连接参数（序列号），并且确认该参数
步骤2和3建立另一个方向服务器-客户端的连接参数（序列号），并且确认该参数

利用上述方法，建立了全双工通信
前两步（请求连接-确认收到请求）已经可以建立连接了，为什么还要再发第三个包（再次确认）呢？
如果没有第三个包的话会出现什么情况呢？
比如A发送了一个建立连接请求，但是这个包绕了远路，A一直没等到B的确认，然后A就重新再发一个请求，这个请求很快就到了，B就给A回了个确认请求，然后A之前发的那个请求又到B了，B一看又来一个建立请求建立，那我就再回一个确认请求吧，但是后面这个请求确认到A之后，A就不认了，我都已经建立连接了啊，然后B就在那儿等着了，这样会造成B的资源浪费，如果这样的情况多了，就会导致B的资源瘫痪
但是如果加上第三个包呢，B在等着A的再次确认，如果等不到，B就自动释放连接了。
例子：
图片说明

用三次握手建立 TCP 连接的各状态
A发送完请求连接后，状态变为SYN-SENT;等收到确认后，再发送一个确认后变为ESTABLISHED
B接收到请求后，发送确认后，状态变为SYN-RCVD，再收到确认后，变为ESTABLISHED
图片说明

TCP的连接释放（四次挥手）

图片说明

数据传输结束后，通信的双方都可释放连接。现在 A 的应用进程先向其 TCP 发出连接释放报文段，并停止再发送数据，主动关闭 TCP 连接.（A 把连接释放报文段首部的 FIN = 1，其序号seq = u，等待 B 的确认）
B 发出确认，确认号 ack = u+1，而这个报文段自己的序号 seq = v。TCP 服务器进程通知高层应用进程。 (从 A 到 B 这个方向的连接就释放了，TCP 连接处于半关闭状态。B 若发送数据，A 仍要接收。)
若 B 已经没有要向 A 发送的数据，其应用进程就通知 TCP 释放连接。
A 收到连接释放报文段后，必须发出确认。
为什么是四次呢？
因为双方都可以进行释放连接，都需要发送释放连接的请求并且得到对面的确认
下面我们来看另一个问题，看图中的状态，对于A来说，再发送了对面的请求释放确认后，它的状态变为了TIME-WAIT,这是为什么呢，为什么还需要再等2MSL才能变为CLOSED，而不是直接变为CLOSED？
因为如果我发完确认包后就关闭连接，那么万一这个确认包在路上丢了，B会再发一个请求释放过来，但是这个时候我已经关闭连接了，如果我还等着，那我收到他的再一个请求关闭就可以再发言一个确认包了。