【网络】传输层协议TCP（下）

四次挥手状态变化

流量控制

PSH标记位

URG标记位

滑动窗口

快重传

拥塞控制

延迟应答

mtu

TCP异常情况

四次挥手状态变化

之前我们讲了四次挥手的具体过程以及为什么要进行四次挥手，下面是四次挥手的状态变化

那么我们下面可以来验证一下CLOSE_WAIT这个状态，这个状态出现的条件是后调用close的一方（比如服务器）调用close之前（调用完close就进入last_ack），我们可以很容易模拟出来，直接比如让客户端先调用close，不让服务器端调用close即可，这样就可以看到这个状态

用指令netstat -natp，a表示all

这就证明一件事情，如果我们发现服务器上有大量close_wait状态的时候，这就意味着大概率我们写的服务器有BUG，主要是没有close fd

我们把服务器进程关掉就看不到这个状态了，因为进程结束会把所有文件描述符释放掉

我们可以看到图中有一个time_wait的状态，对这个就是等待一段时间，这个状态实际上是先调用close的一方收到对方的close并给应答后处于的一种状态，这个状态通常持续的时间是分钟级别的，所以我们也可以较容易的看到

这样虽然服务器进程已经关闭，但是这里的端口仍然是被占用的，这也就是为什么立即启动服务器会bind err

所以我们的处理方法就是设置地址复用

那么等待的时间是多少呢？

TCP协议规定，主动关闭连接的一方要处于TIME_WAIT状态，等待两个MSL的时间才能回到CLOSED状态

MSL是 Maximum Segment Lifetime（报文在网络中最大存活时间），我们可以看Linux中它是多长

也就是一分钟，所以TIME_WAIT的时间就是两分钟

下面解释一下为什么会等待这么长的时间

1.因为有可能我关闭了服务器后立马又绑定相同的IP和端口，这是其实是发给上一次连接的数据由于阻塞在了网络中一段时间，现在发到了服务器，这样旧报文就会影响新连接

2.或者说，四次挥手的最后一次ACK可能会丢，如果等待了2个MSL，对方没收到ACK就会超时重传，这是处于TIME_WAIT的我们就可以重新发ACK。总之，就是又重传的机会，保证让对方也关闭连接。

流量控制

有下面这样一种场景，如果A给B发消息非常快，导致B的缓冲区被打满了，那么新来的数据就会被丢弃，尽管TCP有超时重传机制，但是这样其实是不合理的，因为发送的数据被丢掉就会白白占用网络资源；不仅如此如果A发送的过于慢，这也会导致效率低下。

这上面的问题就和我们要说的流量控制有关，B可以通过应答ACK报文通告给A自己缓冲区剩余空间的大小，那么A就可以选择加快或减慢发送的速度

这里就是B就是通过报头中的16位窗口大小将自己缓冲区的大小通告给A的

那如果B的缓冲区满了，A和B就不进行数据交互了，那么A是如何知道B什么时候有空间呢？

A会向B发送窗口探测，B会向A发送窗口更新通知，这两种机制是会同时存在的。

PSH标记位

那如果B一直没空间，A就会给B发的报头中把PSH标记位置一（当然PSH标记位的应用场景不只是会这么极端），就是让B尽快向上交付，当然取走缓冲区中的数据取决于应用层，这里的意思是应用层调用read的时候不要阻塞，即使要读走的内容很少，也要尽量读走

URG标记位

这个标记位置一是指16位紧急指针有效，16位紧急指针中存着紧急数据在报文数据中的偏移量（广义的指针就是指能找到想要的数据即可），这个紧急数据一般是一个字节，通常是上层应用层规定好的。

这个大概的应用场景是：比如客户端要给服务器上传数据，上传到一半不想上传了，但是此时服务器TCP缓冲区中还有很多数据，这些数据其实都不想上传了，有了紧急指针就可以不按序到达，TCP协议可以让上层先把带有紧急指针的报文读上去，这样就可以停止上传了

滑动窗口

我们之前说过TCP发消息可以串行发，就是发一条消息等一个应答，但是这样发送效率太低。所以TCP一次发多条报文，然后等应答。

那么问题就来了，一次发多条，这些消息都是无需等待确认应答而可以继续发的数据，这个数量是怎么看的呢？

其实无需等待应答而可以继续发送数据的最大值就是滑动窗口的大小

我们可以认为滑动窗口就是发送缓冲区的一部分区域，这个区域是连续的，其中的数据都是暂时不需要应答而可以直接发送的数据

如果不考虑网络情况，滑动窗口的大小一般是对方接收缓冲区中剩余空间的大小，其实这个数据在三次握手的时候接收方就可以通过报头中的16位窗口大小告诉发送方了

我们可以把滑动窗口认为成下面的样子

其实简单来说，要维护一个窗口其实就是维护一段数组空间（可以把缓冲区看成char类型的数组），只需要两个整型变量即可，一个表示窗口开始位置，一个表示结束位置。

我们之前说过超时重传机制，就是对于已发送但是未收到应答的报文进行保存，万一报文丢失触发超时重传我们得找到那个报文，其实报文正好就存在于滑动窗口中

并且这个滑动窗口只能是向右滑动，可以变大，可以变小直至为零。因为滑动窗口的大小就取决于对方接收缓冲区的大小（暂时先这样理解，后面会说其实跟网络状况也有关系）

快重传

为了提高发送笑效率，TCP引入了快重传策略，就是当收到3个报文中具有同样的确认序号时就会重发滑动窗口的最左边的报文。

因为我们知道确认序号的意义就是确认序号之前的报文全部都收到了，接收方之所以会发三个同样的确认序号就是它收到了滑动窗口中间的一些报文，但是滑动窗口最左边（滑动窗口内）的报文没有收到，接收方收到报文后必须发确认应答，并且确认序号只能是滑动窗口左边（滑动窗口外）的已经收到的数组下标

如果没有3个呢？那就会触发超时重传

所以快重传其实是一个提效的策略，而超时重传则是一个兜底的策略

就以为有了上面的策略，所以才不会害怕滑动窗口最左侧丢包。

那如果是滑动窗口中间或最右侧丢包呢？这种情况其实最终还是转化成最左侧丢包，因为收到应答的报文会被分离出滑动窗口

对方在收到一批报文时，会发回一批应答报文，如果这个应答报文是乱序的呢？

1.首先应答报文也是有序号的，不用担心乱序问题

2.就算是乱序的，比如先收到确认序号是3001，后收到2001，其实收到3001是就已经能确定2000收到了，2001其实就可以直接丢弃了

所以就算一部分应答报文会丢失，后面的应答报文也会通告情况，所以是允许部分应答报文丢失的，这一切还是要归功于确认序号的意义上：确认序号之前的报文全部都收到了

接收数据的一方是要对报文进行排序后才能放到接收缓冲区的

我们上面说流量控制，其实滑动窗口就是流量控制的具体实现

缓冲区终归是有限的，那到头了怎么办？我们可以把缓冲区认为成是一个环状结构，滑动窗口就在这个环上循环

拥塞控制

我们发送数据看的其实不仅是通信双方的主机，还有网络

所以拥塞控制就是用来衡量网络的健康状况的

如果网络拥塞了，那么就会导致大面积丢包；如果发送量超过拥塞窗口就会导致网络拥塞

什么控制发送量呢？就是滑动窗口

每次发送数据包的时候，将拥塞窗口和接收端主机反馈的窗口大小作比较，取较小的值作为实际发送的窗口

所以滑动窗口的大小就是对方接收能力和拥塞窗口的最小值