image.png
三次握手是建立连接，四次挥手是关闭连接
TCP不允许连接处于半打开状态的时候单向传输数据。
TCP允许连接处于半关闭状态的时候单向传输数据。
本质上是四次握手，但是在三次握手的时候，服务器把ACK和SYN一起发送给客户端，ack是用来打开客户端的发送通道，syn是用来打开服务器的发送通道，从而，原本是需要4次握手的，现在降为3次握手了。
四次挥手可以用netstat看到6种状态。
主动方：先关闭连接的一方
被动方：后关闭连接的一方
服务器常常是主动关闭连接的一方。
因为http是单向传输协议——
服务器接收完请求才能生成响应，发送完响应后会立刻关闭TCP连接（好处是及时地释放了资源，可以为更多用户服务）
四次挥手中只有2种报文——
FIN和ACK。
谁发出
FIN报文，表示它将不再发送任何数据，关闭这一方的传输通道。
ACK报文，通知对方：你方的发送通道已经关闭。
主动方的优化
关闭连接的方式有多种——
- 不安全的方式有：内核发送
RST报文（属于不走四次挥手，强行关闭连接）来关闭。（如果报文延迟or重复传输，会导致数据错乱） - 安全的方式：必须通过
四次挥手，四次挥手是进程调用close或者shutdown函数发起的，它俩都会向对方发送FIN报文。
image.png
主动方发送FIN报文后，如果一直收不到对方返回的ACK报文，就会重发（内核定时重发FIN报文）。当重发的次数达到设定的上界的时候，连接就会直接关闭掉。
所以说，在性能优化上，调低重发次数就可以了。
But如果遇到了恶意攻击，FIN报文就根本发不出去，因为TCP的2个特性——
- TCP一定要保证报文是有序发送的
-
TCP有流量控制功能，如果接收方将接收窗口设置为0，发送方就不能发送数据了。
解决恶意攻击的方案是——调整孤儿连接的最大数量。
shutdown函数和close函数的不同——
不能让孤儿连接持续太久
TIME_WAIT状态的保持（60s）是可以避免数据错乱的。因为被动方如果一直没收到ACK报文，会一直重发FIN报文。新连接可能会被这个重发的FIN报文错误关闭，所以需要保持一段时间的TIME_WAIT。
保持的时间是60s的原因是这样的——
和2MSL有关系。
TIME_WAIT状态的存在也会消耗系统资源。因为TIME_WAIT状态的端口就无法供新连接使用。
所以为了节省资源，我们也要设定TIME_WAIT的连接数量。
但是如果并发很多，那么同时处于TIME_WAIT的连接数量也会变多，这个时候就需要增大TIME_WAIT的连接数量，从而减少不同的连接之间数据错乱的概率。
但是内存有限，不能不断增加TW的数量，因此可以让新连接复用TW状态的端口。
被动方的优化
image.png
当被动方处于CLOSE_WAIT状态的时候，连接已经处于半关闭状态了，所以进程如果想要关闭连接，只能调用close函数。
被动方也要发送FIN报文，如果一直等不到ACK报文，内核就会一直重发FIN报文（这点和主动方重发是一样的策略）
因为被动方发送FIN报文是在调用close函数后，如果调用close函数的速度很快，那么被动方就可能同时发送ACK+FIN报文，这样四次握手就变成了三次握手（特殊情况）
还有一种很神奇的特例——连接双方同时关闭连接。
这种情况发生的时候，两方都会认为自己是主动方，所以都会进入FIN_WAIT1的状态，FIN报文的重发次数还是有参数可以控制。
因为双方发送FIN后，都在等待ACK，但是都等来了FIN报文，所以会有一个新的状态CLOSING，替代了原先的FIN_WAIT2。
那么这个时候，内核（双方）会回复ACK确认对方发送通道是否关闭，因为一直收不到ACK，所以CLOSING状态会在重发FIN报文的情况下关闭。
总结
- 我们谈到的优化，本质上是从主动方和连接方的连接状态来调整系统参数，从而可以在特定的情况下，及时的释放资源，节省资源。
- 主动方为了处理丢包的情况，可以在一个上限内重发FIN报文。
- 孤儿连接的数量太多也会占用系统资源，所以要给孤儿连接的数量设定一个上限，超过这个上限的时候，连接就会直接释放。
- 因为TIME_WAIT状态也会持续60s，为了防止TW占用太多的资源，也要设定TW连接的数量，超过的时候也会直接释放TW连接。除了直接释放，也可以通过设置参数让新连接复用TW状态的端口。
- 提升TCP的性能，需要观察连接状态，比如，出现大量的CLOSE_WAIT状态的连接的时候，应该从代码中找问题。
- 当被动方发送FIN报文后，在等ACK的时候，也要控制
重发FIN报文的次数。