传输层协议TCP（3）

理解 TIME_WAIT 状态

• TCP 协议规定,主动关闭连接的一方要处于 TIME_ WAIT 状态,等待两个MSL(maximum segment lifetime)的时间后才能回到 CLOSED 状态.

• 我们使用 Ctrl-C 终止了 server, 所以 server 是主动关闭连接的一方, 在TIME_WAIT 期间仍然不能再次监听同样的 server 端口;

• MSL 在 RFC1122 中规定为两分钟,但是各操作系统的实现不同, 在 Centos7 上默认配置的值是 60s;

• 可以通过 cat /proc/sys/net/ipv4/tcp_fin_timeout 查看 msl 的值;

想一想, 为什么是 TIME_WAIT 的时间是 2MSL?

• MSL 是 TCP 报文的最大生存时间, 因此 TIME_WAIT 持续存在 2MSL 的话

• 就能保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失(否则服务器立刻重启, 可能会收到来自上一个进程的迟到的数据, 但是这种数据很可能是错误的);

• 同时也是在理论上保证最后一个报文可靠到达(假设最后一个 ACK 丢失, 那么服务器会再重发一个 FIN. 这时虽然客户端的进程不在了, 但是 TCP 连接还在, 仍然可以重发 LAST_ACK);

解决 TIME_WAIT 状态引起的 bind 失败的方法

在 server 的 TCP 连接没有完全断开之前不允许重新监听, 某些情况下可能是不合理的

• 服务器需要处理非常大量的客户端的连接(每个连接的生存时间可能很短, 但是每秒都有很大数量的客户端来请求).

• 这个时候如果由服务器端主动关闭连接(比如某些客户端不活跃, 就需要被服务器端主动清理掉), 就会产生大量 TIME_WAIT 连接.

• 由于我们的请求量很大, 就可能导致 TIME_WAIT 的连接数很多, 每个连接都会占用一个通信五元组(源 ip, 源端口, 目的 ip, 目的端口, 协议). 其中服务器的 ip 和端口和协议是固定的. 如果新来的客户端连接的 ip 和端口号和 TIME_WAIT 占用的链接重复了, 就会出现问题.

使用 setsockopt()设置 socket 描述符的选项 SO_REUSEADDR 为 1, 表示允许创建端口号相同但 IP 地址不同的多个 socket 描述符

小结: 对于服务器上出现大量的 CLOSE_WAIT 状态, 原因就是服务器没有正确的关闭socket, 导致四次挥手没有正确完成. 这是一个 BUG. 只需要加上对应的 close 即可解决问题.

滑动窗口

这是序列与反序列化的过程，在这个过程中，发送缓冲区中的一部分是滑动窗口

发送方，一次向对方发送多少数据由滑动窗口决定，滑动窗口：无需等待确认应答而可以继续发送数据的最大值

滑动窗口的大小由对方的接受能力决定，收到报文中win文件的大小，start是报文序号确认序号，end=start+win

滑动窗口不会向左滑动

滑动窗口如果弄丢报文怎么办？

那么如果出现了丢包, 如何进行重传? 这里分两种情况讨论.

情况一: 数据包已经抵达, ACK 被丢了.

这种情况下, 部分 ACK 丢了并不要紧, 因为可以通过后续的 ACK 进行确认;

情况二: 数据包就直接丢了.

• 当某一段报文段丢失之后, 发送端会一直收到 1001 这样的 ACK, 就像是在提醒发送端 "我想要的是 1001" 一样;

• 如果发送端主机连续三次收到了同样一个 "1001" 这样的应答, 就会将对应的数据 1001 - 2000 重新发送;

• 这个时候接收端收到了 1001 之后, 再次返回的 ACK 就是 7001 了(因为 2001 - 7000)接收端其实之前就已经收到了, 被放到了接收端操作系统内核的接收缓冲区中;这种机制被称为 "高速重发控制"(也叫 "快重传").

快重传和超时重传进行对比来说，超时重传属于超时和没有应答才会出现，属于是兜底

快重传和超时重传的底层是滑动窗口，确认消息的时候是连续的，因为滑动窗口是不能跳跃的

时重传属于超时和没有应答才会出现，属于是兜底

快重传和超时重传的底层是滑动窗口，确认消息的时候是连续的，因为滑动窗口是不能跳跃的

TCP没有发出去放在自身的窗口等待后面的重传。