前面已经介绍了tcp协议的三次握手和四次挥手。如下图所示，tcp通信过程包括三个步骤：建立tcp连接通道（三次握手）、数据传输、断开tcp连接通道（四次挥手）。
这里进一步探究tcp三路握手和四次挥手过程中的状态变迁以及数据传输过程。先看tcp状态状态转换图。
上半部分是tcp三路握手过程的状态变迁，下半部分是tcp四次挥手过程的状态变迁。
- closed：起始点，在超时或者连接关闭时候进入此状态，这并不是一个真正的状态，而是这个状态图的假想起点和终点。
- listen：服务器端等待连接的状态。服务器经过 socket，bind，listen 函数之后进入此状态，开始监听客户端发过来的连接请求。此称为应用程序被动打开（等到客户端连接请求）。
- syn_sent：第一次握手发生阶段，客户端发起连接。客户端调用 connect，发送 syn 给服务器端，然后进入 syn_sent 状态，等待服务器端确认（三次握手中的第二个报文）。如果服务器端不能连接，则直接进入closed状态。
- syn_rcvd：第二次握手发生阶段，跟 3 对应，这里是服务器端接收到了客户端的 syn，此时服务器由 listen 进入 syn_rcvd状态，同时服务器端回应一个 ack，然后再发送一个 syn 即 syn ack 给客户端。状态图中还描绘了这样一种情况，当客户端在发送 syn 的同时也收到服务器端的 syn请求，即两个同时发起连接请求，那么客户端就会从 syn_sent 转换到 syn_revd 状态。
- established：第三次握手发生阶段，客户端接收到服务器端的 ack 包（ack，syn）之后，也会发送一个 ack 确认包，客户端进入 established 状态，表明客户端这边已经准备好，但tcp 需要两端都准备好才可以进行数据传输。服务器端收到客户端的 ack 之后会从 syn_rcvd 状态转移到 established 状态，表明服务器端也准备好进行数据传输了。这样客户端和服务器端都是 established 状态，就可以进行后面的数据传输了。所以 established 也可以说是一个数据传送状态。
上面就是 tcp 三次握手过程的状态变迁。结合第一张三次握手过程图，从报文的角度看状态变迁：syn_sent 状态表示已经客户端已经发送了 syn 报文，syn_rcvd 状态表示服务器端已经接收到了 syn 报文。
下面看看tcp四次挥手过程的状态变迁。结合第一张四次挥手过程图来理解。
- fin_wait_1：第一次挥手。主动关闭的一方（执行主动关闭的一方既可以是客户端，也可以是服务器端，这里以客户端执行主动关闭为例），终止连接时，发送 fin 给对方，然后等待对方返回 ack 。调用 close() 第一次挥手就进入此状态。
- close_wait：接收到fin 之后，被动关闭的一方进入此状态。具体动作是接收到 fin，同时发送 ack。之所以叫 close_wait 可以理解为被动关闭的一方此时正在等待上层应用程序发出关闭连接指令。前面已经说过，tcp关闭是全双工过程，这里客户端执行了主动关闭，被动方服务器端接收到fin 后也需要调用 close 关闭，这个 close_wait 就是处于这个状态，等待发送 fin，发送了fin 则进入 last_ack 状态。
- fin_wait_2：主动端（这里是客户端）先执行主动关闭发送fin，然后接收到被动方返回的 ack 后进入此状态。
- last_ack：被动方（服务器端）发起关闭请求，由状态2 进入此状态，具体动作是发送 fin给对方，同时在接收到ack 时进入closed状态。
- closing：两边同时发起关闭请求时（即主动方发送fin，等待被动方返回ack，同时被动方也发送了fin，主动方接收到了fin之后，发送ack给被动方），主动方会由fin_wait_1 进入此状态，等待被动方返回ack。
- time_wait：从状态变迁图会看到，四次挥手操作最后都会经过这样一个状态然后进入closed状态。共有三个状态会进入该状态
- 由closing进入：同时发起关闭情况下，当主动端接收到ack后，进入此状态，实际上这里的同时是这样的情况：客户端发起关闭请求，发送fin之后等待服务器端回应ack，但此时服务器端同时也发起关闭请求，也发送了fin，并且被客户端先于ack接收到。
- 由fin_wait_1进入：发起关闭后，发送了fin，等待ack的时候，正好被动方（服务器端）也发起关闭请求，发送了fin，这时客户端接收到了先前ack，也收到了对方的fin，然后发送ack（对对方fin的回应），与closing进入的状态不同的是接收到fin和ack的先后顺序。
- 由fin_wait_2进入：这是不同时的情况，主动方在完成自身发起的主动关闭请求后，接收到了对方发送过来的fin，然后回应 ack。
下面来看看这个看似有点多余的time_wait状态：从上面进入time_wait状态的三个状态动作来看（可以直接看状态变迁图）都是主动方最后回应一个ack（closing实际上前面的那个fin_wait_1状态就已经回应了ack）。
先考虑这样的一个情况，假如这个最后回应的ack丢失了，也就是服务器端接收不到这个ack，那么服务器将继续发送它最终的那个fin，因此客户端必须维护状态信息（time_wait）允许它重发最后的那个ack。如果没有这个time_wait状态，客户端处于closed状态（开头就说了closed状态实际并不存在，是我们为了方便描述假想的），那么客户端将响应rst，服务器端收到后会将该rst分节解释成一个错误，也就不能实现最后的全双工关闭了（可能是主动方单方的关闭）。所以要实现tcp全双工连接的正常终止（两方都关闭连接），必须处理终止过程中四个分节任何一个分节的丢失情况，那么主动关闭连接的主动端必须维持time_wait状态，最后一个回应ack的是主动执行关闭的那端。从变迁图可以看出，如果没有time_wait状态，我们将没有任何机制来保证最后一个ack能够正常到达。前面的fin，ack正常到达均有相应的状态对应。
还有这样一种情况，如果目前的通信双方都已经调用了 close()，都到达了closed状态，没有time_wait状态时，会出现这样一种情况，现在有一个新的连接被建立起来，使用的ip地址和端口和这个先前到达了closed状态的完全相同，假定原先的连接中还有数据报残存在网络之中，这样新的连接建立以后传输的数据极有可能就是原先的连接的数据报，为了防止这一点，tcp不允许从处于time_wait状态的socket 建立一个连接。处于time_wait状态的 socket 在等待了两倍的msl时间之后，将会转变为closed状态。这里time_wait状态持续的时间是2msl（msl是任何ip数据报能够在因特网中存活的最长时间），足以让这两个方向上的数据包被丢弃（最长是2msl）。通过实施这个规则，我们就能保证每成功建立一个tcp连接时，来自该连接先前化身的老的重复分组都已经在网络中消逝了。
综上来看：time_wait存在的两个理由就是
可靠地实现tcp全双工连接的终止；
允许老的重复分节（数据报）在网络中消逝。