如果客户端先发送fin关闭文件描述符那就接受不了服务器发的fin，所以要保留读的文件描述符，shutdown，关闭读或者写或者读写，
当我们调用close，对方也调用close，如果还有数据，服务器也要保证把数据刷过去再调用close，调用close就行，操作系统完成。 这只是说有这样的接口。
四次挥手，小双方发消息完没完不一定是同时的，所以ack和fin不能捎带应答，所以就是四次挥手，有些情况双方都想断开，所以也可能三次挥手，握手挥手本质都是四次，因为他们各自特征决定的。
客户端关，服务器不关，服务器状态进入close wait 客户端状态一直是findwait2,
服务器端用完一个文件描述符，必须关，不关，就可能处于closewait，一直占用文件描述符，这也是资源，有限的，这叫文件描述符泄露问题，
客户端最后发出ack就算四次完成，而服务器要收到，所以客户端要等待一段时间，客户端金额入timewait状态
-
客户端调用
close()\\rightarrow 内核发送FIN（第一次挥手） \\rightarrow 服务端内核自动ACK（第二次挥手）。此时客户端已单方面闭门谢客。 -
服务端应用处理完后手，也调用
close()\\rightarrow 服务端内核发送FIN（第三次挥手） \\rightarrow 客户端内核自动ACK（第四次挥手）。此时连接彻底寿终正寝。
最大报文存活时间：一个报文从主机发送到网络，发了很多报文，有个统计数据，统计报文最大生存时间，
客服端给服务器发的消息，某个发送的消息判定超时了，超时重发，但是这个消息没丢，他还在某个路由器卡着，四次挥手做完了，但是这个消息还是活着。后来客户端关闭后立即再重启，端口一致，这个报文可能就直接到来了。就可能影响下次连接建立过程和数据通信过程。
主动断开一方一定是最后能接收数据的一方，所以要有等待时间。为了让历史残留报文在网络中消散，不会影响下一次网络连接和通信。等待期间来了报文直接丢弃。
虽然概率低，但是一旦有，tcp多设备多连接大概率每天都会实现。
主动断开连接一方要进入timewait，再次重启，并没有close，链接还在使用，端口号也在使用，再次绑定就失败。这样就可以对网络中残留的报文进行丢弃
如果最后一次ACK丢失那么对方一定，timewait期间没有在收到fin就证明对方收到ack， 较大概率保证握手是正常完成的。
这样即使服务器崩了，也能立即重启，但是网络中丢失报文再进来怎么办，通信时候，服务器做ack时候，我知道 客户端从哪发数据，如果data序号和期望不匹配也可以丢弃，双方握手时，双方会进行序号随机化，你从多少开始我从多少开始，就可以振别出来，还会根据缓冲区大小计算上界。
滑动窗口：
看课件7滑动窗口
快重传，如果收不到三个就用超时重传
收到ack，滑动窗口右滑就把数据丢弃掉，没有收到应答就不要滑动，这就是暂存。
最左侧丢了，1001-2000丢了，ack只能1001，滑动窗口不动，为了进行超时重传和快重传，
中间丢失，滑动窗口首先向右滑动到中间丢失的位置，因为根据确认序号的定义，是我已经收到的报文，就变成最左侧丢失
最右边丢了，也是向右滑动，在丢失部分停下来，转化为最左侧丢失
所有报文都触发超时重传，如果同时收到3个以上相同序号ack取消超时用快重传
