TCP/UDP深入理解

一 TCP状态机

CLOSED:初始状态。

LISTEN:服务器端的某个SOCKET处于监听状态，可以接受连接了。

SYN_RCVD: 这个状态表示接受到了SYN报文，在正常情况下，这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态，很短暂，基本上用netstat你是很难看到这种状态的，除非你特意写了一个客户端测试程序，故意将三次TCP握手过程中最后一个ACK报文不予发送。因此这种状态时，当收到客户端的ACK报文后，它会进入到ESTABLISHED状态。

SYN_SENT: 这个状态与SYN_RCVD遥想呼应，当客户端SOCKET执行CONNECT连接时，它首先发送SYN报文，因此也随即它会进入到了SYN_SENT状态，并等待服务端的发送三次握手中的第2个报文。SYN_SENT状态表示客户端已发送SYN报文。

ESTABLISHED：表示连接已经建立了。

FIN_WAIT_1: 这个状态要好好解释一下，其实FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。

FIN_WAIT_2：上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你，稍后再关闭连接。

TIME_WAIT: 表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。

CLOSING: 这种状态比较特殊，实际情况中应该是很少见，属于一种比较罕见的例外状态。正常情况下，当你发送FIN报文后，按理来说是应该先收到（或同时收到）对方的ACK报文，再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢？其实细想一下，也不难得出结论：那就是如果双方几乎在同时close一个SOCKET的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态，表示双方都正在关闭SOCKET连接。

CLOSE_WAIT: 这种状态的含义其实是表示在等待关闭。当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。

LAST_ACK: 它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了

状态过程详解：

服务器端首先执行LISTEN 原语进入被动打开状态（ LISTEN ），等待客户端连接；

当客户端的一个应用程序发出CONNECT 命令后，本地的 TCP 实体为其创建一个连接记录并标记为 SYN SENT 状态，然后给服务器发送一个 SYN 报文段；

服务器收到一个 SYN 报文段，其 TCP 实体给客户端发送确认 ACK 报文段同时发送一个 SYN 信号，进入 SYN RCVD 状态；

客户端收到 SYN +ACK 报文段，其 TCP 实体给服务器端发送出三次握手的最后一个 ACK 报文段，并转换为 ESTABLISHED 状态；

服务器端收到确认的 ACK 报文段，完成了三次握手，于是也进入 ESTABLISHED 状态。在此状态下，双方可以自由传输数据。

当一个应用程序完成数据传输任务后，它需要关闭 TCP 连接。假设仍由客户端发起主动关闭连接。 

客户端执行 CLOSE ，本地的 TCP 实体发送一个 FIN 报文段并等待响应的确认（进入状态 FIN WAIT 1 ）；

服务器收到一个 FIN 报文段，它确认客户端的请求发回一个 ACK 报文段，进入 CLOSE WAIT 状态；

客户端收到确认 ACK 报文段，就转移到 FIN WAIT 2 状态，此时连接在一个方向上就断开了；

服务器端应用得到通告后，也执行 CLOSE 原语关闭另一个方向的连接，其本地 TCP 实体向客户端发送一个 FIN 报文段，并进入 LAST ACK 状态，等待最后一个 ACK 确认报文段；

客户端收到 FIN 报文段并确认，进入 TIMED WAIT 状态，此时双方连接均已经断开，但 TCP 要等待一个 2 倍报文段最大生存时间 MSL （Maximum Segment Lifetime ），确保该连接的所有分组全部消失，以防止出现确认丢失的情况。当定时器超时后， TCP 删除该连接记录，返回到初始状态（ CLOSED ）。

服务器收到最后一个确认ACK 报文段，其 TCP 实体便释放该连接，并删除连接记录，返回到初始状态（ CLOSED ）。

二 TCP建立连接的三次握手和释放连接的四次挥手

 

建立连接三次握手

1）  主机A发送一个SYN段到主机B告诉B想要连接的主机端口，以及初始的序列号（ISN：x）(报文段1)

2） 主机B应答，服务器发回包含B的初始序号的SYN报文段(报文段2)作为应答。同时，将确认序号ACK设置为客户的ISN加1以对A的SYN报文段进行确认。

3) 主机A必须将确认序号ACK设置为B的ISN加1以对B的SYN报文段进行确认(报文段3)

 

四次挥手断开连接

1）现在的网络通信都是基于socket实现的，当客户端将自己的socket进行关闭时，内核协议栈会向服务器自动发送一个FIN置位的包，请求断开连接。

2）服务器端B收到请客端的FIN断开请求后，内核协议栈会立即发送一个ACK包作为应答，表示已经收到客户端的请求

3）服务器运行一段时间后，关闭了自己的socket。这个时候内核协议栈会向客户端A发送一个FIN置位的包，请求断开连接

4）客户端A收到服务端B发来的FIN断开请求后，会发送一个ACK做出应答，表示已经收到服务端的请求

为什么建立连接协议是三次握手，而关闭连接却是四次握手呢？

这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后，它可以把ACK和SYN（ACK起应答作用，而SYN起同步作用）放在一个报文里来发送。但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。

三 TCP数据封装与解封

解封时，在主机B上，驱动程序从以太网上接收到数据，然后将数据去除头部和尾部并行CRC校验后，将正确的数据传递给IP层，IP层剥去IP头，进行校验，将数据发送给TCP层。TCP层将TCP的头部剥去，根据应用程序的标识符判断是否发送给应用程序

UDP数据封装与解封与TCP类似