目录
四次挥手状态变化
流量控制
PSH标记位
URG标记位
四次挥手状态变化
之前我们讲了四次挥手的具体过程以及为什么要进行四次挥手，下面是四次挥手的状态变化
那么我们下面可以来验证一下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协议可以让上层先把带有紧急指针的报文读上去，这样就可以停止上传了
