tcp连接
TCP建立连接：三次握手
TCP关闭连接：四次挥手
time_wait状态产生的原因
1）为实现TCP全双工连接的可靠释放
由TCP状态变迁图可知，假设发起主动关闭的一方（client）最后发送的ACK在网络中丢失，由于TCP协议的重传机制，执行被动关闭的一方（server）将会重发其FIN，在该FIN到达client之前，client必须维护这条连接状态，也就说这条TCP连接所对应的资源（client方的local_ip,local_port）不能被立即释放或重新分配，直到另一方重发的FIN达到之后，client重发ACK后，经过2MSL时间周期没有再收到另一方的FIN之后，该TCP连接才能恢复初始的CLOSED状态。如果主动关闭一方不维护这样一个TIME_WAIT状态，那么当被动关闭一方重发的FIN到达时，主动关闭一方的TCP传输层会用RST包响应对方，这会被对方认为是有错误发生，然而这事实上只是正常的关闭连接过程，并非异常。
2）为使旧的数据包在网络因过期而消失
为说明这个问题，我们先假设TCP协议中不存在TIME_WAIT状态的限制，再假设当前有一条TCP连接：(local_ip, local_port, remote_ip,remote_port)，因某些原因，我们先关闭，接着很快以相同的四元组建立一条新连接。本文前面介绍过，TCP连接由四元组唯一标识，因此，在我们假设的情况中，TCP协议栈是无法区分前后两条TCP连接的不同的，在它看来，这根本就是同一条连接，中间先释放再建立的过程对其来说是“感知”不到的。这样就可能发生这样的情况：前一条TCP连接由local peer发送的数据到达remote peer后，会被该remot peer的TCP传输层当做当前TCP连接的正常数据接收并向上传递至应用层（而事实上，在我们假设的场景下，这些旧数据到达remote peer前，旧连接已断开且一条由相同四元组构成的新TCP连接已建立，因此，这些旧数据是不应该被向上传递至应用层的），从而引起数据错乱进而导致各种无法预知的诡异现象。作为一种可靠的传输协议，TCP必须在协议层面考虑并避免这种情况的发生，这正是TIME_WAIT状态存在的第2个原因。
https://blog.csdn.net/qzcsu/article/details/72861891
https://blog.csdn.net/u013616945/article/details/77510925
为什么不能改成两次握手？
有人会困惑为什么要进行三次握手呢（两次确认）？这主要是为了防止已失效的请求连接报文忽然又传送到了，从而产生错误。
假定A向B发送一个连接请求，由于一些原因，导致A发出的连接请求在一个网络节点逗留了比较多的时间。此时A会将此连接请求作为无效处理 又重新向B发起了一次新的连接请求，B正常收到此连接请求后建立了连接，数据传输完成后释放了连接。如果此时A发出的第一次请求又到达了B，B会以为A又发起了一次连接请求，如果是两次握手：此时连接就建立了，B会一直等待A发送数据，从而白白浪费B的资源。 如果是三次握手：由于A没有发起连接请求，也就不会理会B的连接响应，B没有收到A的确认连接，就会关闭掉本次连接。
---------------------
原文：https://blog.csdn.net/b954960630/article/details/81861579
相关阅读
C#连接数据库时Appsettings 与connectionStrings的区
一、.Appsettings与connectionStrings的区别，它俩都是App.config中的两个元素；AppSettings是ASP.NET1.1时期用的,在.NET Framework
Linux 命令之软连接详解 1.软连接的创建 创建测试文件及文件夹 [root@server6 ~]# mkdir test_chk [root@server6 ~]# touch te
Windows: 第一步，修改注册表项 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\rdpwd\Tds\tc
今天在用有线宽带时，出现重启电脑能够连接宽带，但是很快就会断网，之后就连接不上，解决的方法是 重新装一边这个驱动，之后就可以上网了
3、strcat 复制连接 strcat将str2的字符串复制到str1的尾端，不覆盖str1进行复制， using namespace std; #include<iostream> #incl