tcp连接资源(资源监视器tcp连接是什么)

在cmd运行窗口中输入DOS命令netstat，即可查看电脑的tcp连接。具体操作请参照以下步骤。1、进入电脑系统后，在键盘上同时按下“win+R”键，调出运行窗口。2、然后在出现的窗口中，输入“cmd”字样，点击确定按钮。3、然后便会进入到cmd的运行界面中，如图所示。4、然后再输入DOS命令【netstat】，再按键盘上的回车键。5、完成以上设置后，即可查看电脑的tcp连接情况。
如何查看tcp连接的几种方法：方法一：通过命令提示符程序（cmd.exe）。第一步，查看TCP连接使用命令netstat -ano -p tcpnetstat -ano | find "ESTABLISHED"注释：1.如果使用find就不用再使用-p来指定是不是tcp协议了。2.参数-o表示显示发起连接的进程的ID（PID）（Displays the owning process ID associated with each connection.）注意：中英文符号的输入差别。第二步，使用tasklist列出发起连接的进程。使用命令：tasklist | find "4288"注释：tasklist命令本身有很可以使用和有用的参数，如使用筛选器（/FI    filter）和指定输出格式（/FO    format），但这里使用了find，所以依然不需要指定任何参数。方法二：使用PowerShell轻松查看，一行命令出结果。方法三：在图形界面窗口中，通过Windows自带的“资源管理器（Resource Monitor）”来查看TCP连接。较快捷的打开方法是先打开“任务管理器（Task Manager，Ctrl+Shift+Esc）”，然后切换到“性能（Performance）”，在窗口右下角就能找到（可能需要管理员权限）。
建议你可以用抓包软件Wireshark进行抓包，然后进行分析，可以清楚的看到每一次连接（三次握手）和每一次释放（四次握手）；包括帧的格式都清楚可见……

理论上来说是保持的。TCP连接，当网络通信时采用TCP协议时，在真正的读写操作之前，server与client之间必须建立一个连接，当读写操作完成后，双方不再需要这个连接时它们可以释放这个连接，连接的建立是需要三次握手的，而释放则需要4次握手，所以说每个连接的建立都是需要资源消耗和时间消耗的。TCP保活的必要性：TCP的长连接理论上只要连接建立后，就会一直保持着。但有时有一些防火墙之类的软件会自动检查主机的网络连接状况，比如说如果发现某个连接在几分钟之内都没有数据通讯，则会关闭这个连接。有时客户端与服务器需要实时的检测连接状态，就是需要知道对方是否还在线，如果对方不在线了，需要做相应的处理，这是就需要通过发送心跳包的方法监测链路的状态。导致 TCP 连接断连的因素 ：理想状态下，一个 TCP 连接可以被长期保持。然而，在实际应用中，客户端或服务器端上维持的一个看似正常的 TTCP 连接可能已经断连。TCP 连接主要受到两个方面的影响而导致断连：网络中间节点和客户端 / 服务器节点参与通信的两方节点。在实际网络应用中，两个主机之间的通信往往需要穿越多个中间节点，例如路由器、网关、防火墙等。因此，两个主机之间 TCP 连接的保持同样会受到中间节点的影响，尤其是会受到防火墙（软件或硬件防火墙）的限制。防火墙是一种装置，有多种不同的实现方式（软件实现、硬件设备实现或是软硬件相结合实现），它需要依据一系列规则对进出的信息流进行扫描，并允许安全（符合规则）的信息交互、阻止不安全（违反规则）的信息交互。防火墙的工作特性决定了要维护一个网络连接就需要耗费较多的资源，并且企业防火墙常常位于企业网络的出入口，长时间维护非活跃的 TCP 连接必将导致网络性能的下降。因此，大部分防火墙默认会关闭长时间处于非活跃状态的连接而导致 TCP 连接断连。类似的，如果中间节点异常导致如果中间节点异常导致来自客户端关闭连接的请求无法传递到服务器端，也将导致服务器端的相应连接发生断连。另一方面，对于一个 TCP 连接两端的主机而言，创建 TCP 连接需要耗费一定的系统资源。如果不再使用某个连接，那么我们总是希望进行通信的两个主机能够主动关闭相应的连接，以便释放所占用的系统资源。然而，如果由于客户端出现异常 ( 例如崩溃或异常重启 ) 而导致连接未能正常关闭，这将导致服务器端的连接断连。 无论是客户端节点或是服务器端节点，断连的 TCP 连接已经不能传递任何信息，因此，维护大量断连的 TCP 连接将导致系统资源的浪费。这种系统资源的浪费可能并不会对客户端节点带来太大问题；然而，对于服务器主机而言，这可能会导致系统资源（尤指内存资源和 socket 资源）被耗尽而拒绝为新的用户请求提供服务。因此在实际应用中，服务器端需要采取相应的方法来探测 TCP 连接是否已经断连。

TCP协议是在TCP/IP协议模型中的运输层中很重要的一个协议、负责处理主机端口层面之间的数据传输。主要有以下特点：1.TCP是面向链接的协议，在数据传输之前需要通过三次握手建立TCP链接，当数据传递完成之后，需要通过四次挥手进行连接释放。2.每一条TCP通信都是两台主机和主机之间的，是点对点传输的协议。3.TCP提供可靠的、无差错、不丢失、不重复，按序到达的服务。4.TCP的通信双方在连接建立的任何时候都可以发送数据。TCP连接的两端都设有发送缓存和接收缓存，用来临时存放双向通信的数据。5.面向字节流。在数据传输的过程中如果报文比较长的话TCP会进行数据分段传输，每一条分段的TCP传输信息都带有分段的序号，每一段都包含一部分字节流。接收方根据每段携带的的序号信息进行数据拼接，最终拼接出来初始的传输数据。但是在整个传输的过程中每一段TCP携带的都是被切割的字节流数据。所以说TCP是面向字节流的。a.TCP和UDP在发送报文时所采用的方式完全不同。TCP并不关心应用程序一次把多长的报文发送到TCP缓存中，而是根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节（UDP发送的报文长度是应用程序给出的）。b.如果应用程序传送到TCP缓存的数据块太大，TCP就可以把它划分短一些再传。TCP也可以等待积累有足够多的字节后再构建成报文段发送出去。各字段含义：源端口：发送端的端口号目的端口：接收端的端口号序号：TCP将发送报文分段传输的时候会给每一段加上序号，接收端也可以根据这个序号来判断数据拼接的顺序，主要用来解决网络报乱序的问题确认号：确认号为接收端收到数据之后进行排序确认以及发送下一次期待接收到的序号，数值 = 接收到的发送号 + 1数据偏移：占4比特，表示数据开始的地方离TCP段的起始处有多远。实际上就是TCP段首部的长度。由于首部长度不固定，因此数据偏移字段是必要的。数据偏移以32位为长度单位，因此TCP首部的最大长度是60（15*4）个字节。控制位：URG：此标志表示TCP包的紧急指针域有效，用来保证TCP连接不被中断，并且督促 中间层设备要尽快处理这些数据;ACK：此标志表示应答域有效，就是说前面所说的TCP应答号将会包含在TCP数据包中;有两个取值：0和1， 为1的时候表示应答域有效，反之为0;PSH：这个标志位表示Push操作。所谓Push操作就是指在数据包到达接收端以后，立即传送给应用程序， 而不是在缓冲区中排队;RST：这个标志表示连接复位请求。用来复位那些产生错误的连接，也被用来拒绝错误和非法的数据包;SYN：表示同步序号，用来建立连接。SYN标志位和ACK标志位搭配使用，当连接请求的时候，SYN=1， ACK=0;连接被响应的时候，SYN=1，ACK=1;这个标志的数据包经常被用来进行端口扫描。扫描者发送 一个只有SYN的数据包，如果对方主机响应了一个数据包回来 ，就表明这台主机存在这个端口;但是由于这 种扫描方式只是进行TCP三次握手的第一次握手，因此这种扫描的成功表示被扫描的机器不很安全，一台安全 的主机将会强制要求一个连接严格的进行TCP的三次握手;FIN： 表示发送端已经达到数据末尾，也就是说双方的数据传送完成，没有数据可以传送了，发送FIN标志 位的TCP数据包后，连接将被断开。这个标志的数据包也经常被用于进行端口扫描。窗口：TCP里很重要的一个机制，占2字节，表示报文段发送方期望接收的字节数，可接收的序号范围是从接收方的确认号开始到确认号加上窗口大小之间的数据。后面会有实例讲解。校验和：校验和包含了伪首部、TCP首部和数据，校验和是TCP强制要求的，由发送方计算，接收方验证紧急指针：URG标志为1时，紧急指针有效，表示数据需要优先处理。紧急指针指出在TCP段中的紧急数据的最后一个字节的序号，使接收方可以知道紧急数据共有多长。选项：最常用的选项是最大段大小（Maximum Segment Size，MSS），向对方通知本机可以接收的最大TCP段长度。MSS选项只在建立连接的请求中发送。放在以太网帧里看TCP的位置TCP 数据包在 IP 数据包的负载里面。它的头信息最少也需要20字节，因此 TCP 数据包的最大负载是 1480 - 20 = 1460 字节。由于 IP 和 TCP 协议往往有额外的头信息，所以 TCP 负载实际为1400字节左右。因此，一条1500字节的信息需要两个 TCP 数据包。HTTP/2 协议的一大改进， 就是压缩 HTTP 协议的头信息，使得一个 HTTP 请求可以放在一个 TCP 数据包里面，而不是分成多个，这样就提高了速度。以太网数据包的负载是1500字节，TCP 数据包的负载在1400字节左右一个包1400字节，那么一次性发送大量数据，就必须分成多个包。比如，一个 10MB 的文件，需要发送7100多个包。发送的时候，TCP 协议为每个包编号（sequence number，简称 SEQ），以便接收的一方按照顺序还原。万一发生丢包，也可以知道丢失的是哪一个包。第一个包的编号是一个随机数。为了便于理解，这里就把它称为1号包。假定这个包的负载长度是100字节，那么可以推算出下一个包的编号应该是101。这就是说，每个数据包都可以得到两个编号：自身的编号，以及下一个包的编号。接收方由此知道，应该按照什么顺序将它们还原成原始文件。收到 TCP 数据包以后，组装还原是操作系统完成的。应用程序不会直接处理 TCP 数据包。对于应用程序来说，不用关心数据通信的细节。除非线路异常，否则收到的总是完整的数据。应用程序需要的数据放在 TCP 数据包里面，有自己的格式（比如 HTTP 协议）。TCP 并没有提供任何机制，表示原始文件的大小，这由应用层的协议来规定。比如，HTTP 协议就有一个头信息Content-Length，表示信息体的大小。对于操作系统来说，就是持续地接收 TCP 数据包，将它们按照顺序组装好，一个包都不少。操作系统不会去处理 TCP 数据包里面的数据。一旦组装好 TCP 数据包，就把它们转交给应用程序。TCP 数据包里面有一个端口（port）参数，就是用来指定转交给监听该端口的应用程序。应用程序收到组装好的原始数据，以浏览器为例，就会根据 HTTP 协议的Content-Length字段正确读出一段段的数据。这也意味着，一次 TCP 通信可以包括多个 HTTP 通信。服务器发送数据包，当然越快越好，最好一次性全发出去。但是，发得太快，就有可能丢包。带宽小、路由器过热、缓存溢出等许多因素都会导致丢包。线路不好的话，发得越快，丢得越多。最理想的状态是，在线路允许的情况下，达到最高速率。但是我们怎么知道，对方线路的理想速率是多少呢？答案就是慢慢试。TCP 协议为了做到效率与可靠性的统一，设计了一个慢启动（slow start）机制。开始的时候，发送得较慢，然后根据丢包的情况，调整速率：如果不丢包，就加快发送速度；如果丢包，就降低发送速度。Linux 内核里面 设定 了（常量TCP_INIT_CWND），刚开始通信的时候，发送方一次性发送10个数据包，即"发送窗口"的大小为10。然后停下来，等待接收方的确认，再继续发送。默认情况下，接收方每收到 两个TCP 数据包，就要 发送 一个确认消息。"确认"的英语是 acknowledgement，所以这个确认消息就简称 ACK。ACK 携带两个信息。发送方有了这两个信息，再加上自己已经发出的数据包的最新编号，就会推测出接收方大概的接收速度，从而降低或增加发送速率。这被称为"发送窗口"，这个窗口的大小是可变的。注意，由于 TCP 通信是双向的，所以双方都需要发送 ACK。两方的窗口大小，很可能是不一样的。而且 ACK 只是很简单的几个字段，通常与数据合并在一个数据包里面发送。即使对于带宽很大、线路很好的连接，TCP 也总是从10个数据包开始慢慢试，过了一段时间以后，才达到最高的传输速率。这就是 TCP 的慢启动。TCP 协议可以保证数据通信的完整性，这是怎么做到的？前面说过，每一个数据包都带有下一个数据包的编号。如果下一个数据包没有收到，那么 ACK 的编号就不会发生变化。举例来说，现在收到了4号包，但是没有收到5号包。ACK 就会记录，期待收到5号包。过了一段时间，5号包收到了，那么下一轮 ACK 会更新编号。如果5号包还是没收到，但是收到了6号包或7号包，那么 ACK 里面的编号不会变化，总是显示5号包。这会导致大量重复内容的 ACK。如果发送方发现收到 三个 连续的重复 ACK，或者超时了还没有收到任何 ACK，就会确认丢包，即5号包遗失了，从而再次发送这个包。通过这种机制，TCP 保证了不会有数据包丢失。TCP是一个滑动窗口协议，即一个TCP连接的发送端在某个时刻能发多少数据是由滑动窗口控制的，而滑动窗口的大小实际上是由两个窗口共同决定的，一个是接收端的通告窗口，这个窗口值在TCP协议头部信息中有，会随着数据的ACK包发送给发送端，这个值表示的是在接收端的TCP协议缓存中还有多少剩余空间，发送端必须保证发送的数据不超过这个剩余空间以免造成缓冲区溢出，这个窗口是接收端用来进行流量限制的，在传输过程中，通告窗口大小与接收端的进程取出数据的快慢有关。另一个窗口是发送端的拥塞窗口(Congestion window)，由发送端维护这个值，在协议头部信息中没有，滑动窗口的大小就是通告窗口和拥塞窗口的较小值，所以拥塞窗口也看做是发送端用来进行流量控制的窗口。滑动窗口的左边沿向右移动称为窗口合拢，发生在发送的数据被确认时（此时，表明数据已被接收端收到，不会再被需要重传，可以从发送端的发送缓存中清除了），滑动窗口的右边沿向右移动称为窗口张开，发生在接收进程从接收端协议缓存中取出数据时。随着发送端不断收到的被发送数据的ACK包，根据ACK包中的确认序号和通告窗口大小使滑动窗口得以不断的合拢和张开，形成滑动窗口的向前滑动。如果接收进程一直不取数据，则会出现0窗口现象，即滑动窗口左边沿与右边沿重合，此时窗口大小为0，就无法再发送数据。在TCP里，接收端(B)会给发送端(A)报一个窗口的大小，叫Advertised window。1.在没有收到B的确认情况下，A可以连续把窗口内的数据都发送出去。凡是已经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用。2.发送窗口里面的序号表示允许发送的序号。显然，窗口越大，发送方就可以在收到对方确认之前连续发送更多数据，因而可能获得更高的传输效率。但接收方必须来得及处理这些收到的数据。3.发送窗口后沿的后面部分表示已发送且已收到确认。这些数据显然不需要再保留了。4.发送窗口前沿的前面部分表示不允许发送的，应为接收方都没有为这部分数据保留临时存放的缓存空间。5.发送窗口后沿的变化情况有两种：不动（没有收到新的确认）和前移（收到了新的确认）6.发送窗口前沿的变化情况有两种：不断向前移或可能不动（没收到新的确认）TCP的发送方在规定时间内没有收到确认就要重传已发送的报文段。这种重传的概念很简单，但重传时间的选择确是TCP最复杂的问题之一。TCP采用了一种自适应算法，它记录一个报文段发出的时间，以及收到响应的确认的时间这两个时间之差就是报文段的往返时间RTT。TCP保留了RTT的一个加权平均往返时间。超时重传时间RTO略大于加权平均往返时间RTT：即Round Trip Time，表示从发送端到接收端的一去一回需要的时间，tcp在数据传输过程中会对RTT进行采样（即对发送的数据包及其ACK的时间差进行测量，并根据测量值更新RTT值，具体的算法TCPIP详解里面有），TCP根据得到的RTT值更新RTO值，即Retransmission TimeOut，就是重传间隔，发送端对每个发出的数据包进行计时，如果在RTO时间内没有收到所发出的数据包的对应ACK，则任务数据包丢失，将重传数据。一般RTO值都比采样得到的RTT值要大。如果收到的报文段无差错，只是未按序号，中间还缺少一些序号的数据，那么能否设法只传送缺少的数据而不重传已经正确到达接收方的数据？答案是可以的，选择确认就是一种可行的处理方法。如果要使用选项确认SACK，那么在建立TCP连接时，就要在TCP首部的选项中加上“允许SACK”的选项，而双方必须都事先商定好。如果使用选择确认，那么原来首部中的“确认号字段”的用法仍然不变。SACK文档并没有明确发送方应当怎么响应SACK.因此大多数的实现还是重传所有未被确认的数据块。一般说来，我们总是希望数据传输的更快一些，但如果发送方把数据发送的过快，接收方就可能来不及接收，这会造成数据的丢失。所谓流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。在计算机网络中的链路容量，交换节点中的缓存和处理机等，都是网络的资源。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫做拥塞。拥塞控制方法：1.慢开始和拥塞避免2.快重传和快恢复3.随机早期检测1.一开始，客户端和服务端都处于CLOSED状态2.先是服务端主动监听某个端口，处于LISTEN状态（比如服务端启动，开始监听）。3.客户端主动发起连接SYN，之后处于SYN-SENT状态（第一次握手，发送 SYN = 1 ACK = 0 seq = x ack = 0）。4.服务端收到发起的连接，返回SYN，并且ACK客户端的SYN，之后处于SYN-RCVD状态（第二次握手，发送 SYN = 1 ACK = 1 seq = y ack = x + 1）。5.客户端收到服务端发送的SYN和ACK之后，发送ACK的ACK，之后处于ESTABLISHED状态（第三次握手，发送 SYN = 0 ACK = 1 seq = x + 1 ack = y + 1）。6.服务端收到客户端的ACK之后，处于ESTABLISHED状态。（需要注意的是，有可能X和Y是相等的，可能都是0，因为他们代表了各自发送报文段的序号。）TCP连接释放四次挥手1.当前A和B都处于ESTAB-LISHED状态。2.A的应用进程先向其TCP发出连接释放报文段，并停止再发送数据，主动关闭TCP连接。3.B收到连接释放报文段后即发出确认，然后B进入CLOSE-WAIT(关闭等待)状态。TCP服务器进程这时应通知高层应用进程，因而从A到B这个方向的连接就释放了，这时TCP连接处于半关闭状态，即A已经没有数据发送了。从B到A这个方向的连接并未关闭，这个状态可能会持续一些时间。4.A收到来自B的确认后，就进入FIN-WAIT-2(终止等待2)状态，等待B发出的连接释放报文端。5.若B已经没有向A发送的数据，B发出连接释放信号，这时B进入LAST-ACK(最后确认)状态等待A的确认。6.A再收到B的连接释放消息后，必须对此发出确认，然后进入TIME-WAIT（时间等待）状态。请注意，现在TCP连接还没有释放掉，必须经过时间等待计时器（TIME－WAIT timer）设置的时间2MSL后，A才进入CLOSED状态。7。B收到A发出的确认消息后，进入CLOSED状态。以请求百度为例，看一下三次握手真实数据的TCP连接建立过程我们再来看四次挥手。TCP断开连接时，会有四次挥手过程，标志位是FIN，我们在封包列表中找到对应位置，理论上应该找到4个数据包，但我试了好几次，实际只抓到3个数据包。查了相关资料，说是因为服务器端在给客户端传回的过程中，将两个连续发送的包进行了合并。因此下面会按照合并后的三次挥手解释，若有错误之处请指出。第一步，当主机A的应用程序通知TCP数据已经发送完毕时，TCP向主机B发送一个带有FIN附加标记的报文段（FIN表示英文finish）。第二步，主机B收到这个FIN报文段之后，并不立即用FIN报文段回复主机A，而是先向主机A发送一个确认序号ACK，同时通知自己相应的应用程序：对方要求关闭连接（先发送ACK的目的是为了防止在这段时间内，对方重传FIN报文段）。第三步，主机B的应用程序告诉TCP：我要彻底的关闭连接，TCP向主机A送一个FIN报文段。第四步，主机A收到这个FIN报文段后，向主机B发送一个ACK表示连接彻底释放。这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方也未必全部数据都发送给对方了，所以己方可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送。原因有二：一、保证TCP协议的全双工连接能够可靠关闭二、保证这次连接的重复数据段从网络中消失先说第一点，如果Client直接CLOSED了，那么由于IP协议的不可靠性或者是其它网络原因，导致Server没有收到Client最后回复的ACK。那么Server就会在超时之后继续发送FIN，此时由于Client已经CLOSED了，就找不到与重发的FIN对应的连接，最后Server就会收到RST而不是ACK，Server就会以为是连接错误把问题报告给高层。这样的情况虽然不会造成数据丢失，但是却导致TCP协议不符合可靠连接的要求。所以，Client不是直接进入CLOSED，而是要保持TIME_WAIT，当再次收到FIN的时候，能够保证对方收到ACK，最后正确的关闭连接。再说第二点，如果Client直接CLOSED，然后又再向Server发起一个新连接，我们不能保证这个新连接与刚关闭的连接的端口号是不同的。也就是说有可能新连接和老连接的端口号是相同的。一般来说不会发生什么问题，但是还是有特殊情况出现：假设新连接和已经关闭的老连接端口号是一样的，如果前一次连接的某些数据仍然滞留在网络中，这些延迟数据在建立新连接之后才到达Server，由于新连接和老连接的端口号是一样的，又因为TCP协议判断不同连接的依据是socket pair，于是，TCP协议就认为那个延迟的数据是属于新连接的，这样就和真正的新连接的数据包发生混淆了。所以TCP连接还要在TIME_WAIT状态等待2倍MSL，这样可以保证本次连接的所有数据都从网络中消失。硬件速度网络和服务器的负载请求和响应报文的尺寸客户端和服务器之间的距离TCP 协议的技术复杂性TCP 连接建立握手；TCP 慢启动拥塞控制；数据聚集的 Nagle 算法；用于捎带确认的 TCP 延迟确认算法；TIME_WAIT 时延和端口耗尽。介绍完毕，就这？是的，就这。补充：大部分内容为网络整理，方便自己学习回顾，参考文章：TCP 协议简介TCP协议图文详解什么是TCP协议？wireshark抓包分析——TCP/IP协议TCP协议的三次握手和四次挥手TCP协议详解TCP带宽和时延的研究(1)

整理自 CSDN 公众号1. 客户端TCP 三次握手的开始是客户端发起 SYN，如果服务端没有及时回复，那么会重传，重传的间隔和次数是可控的，默认是五次，第一次间隔 1 秒，第二次 2 秒，第三次 4 秒，第四次 8 秒，第五次16 秒，最终超时时间是 63 秒，因此在优化时可以修改重传次数和间隔，以尽快把错误暴露给应用程序。2. 服务端的半连接队列优化服务端在第一次返回 SYN + ACK 时，就会把这次请求维护进一个半连接队列，这个队列用来维护尚未完成的握手信息（相对于全连接），如果这个队列溢出了，服务端就无法继续接受新的请求了，这也是 SYN Flood 攻击的点。通过一个命令 netstat -s 可以得到累计的、由于半连接队列已满引发的失败次数，隔几秒执行一次就可以知道这个次数是否有上升的趋势以及分析是否正常。这种 SYN Flood 攻击之所以成立，是因为维护这个半连接队列一定要分配一定的内存资源，那么应对的方式之一 syncookies 就是如何不分配资源的前提下，可以确认是一次有效的连接并 establish。syncookies 的工作原理是，服务器使用一种算法，计算出一个哈希值，它包含了客户端发来请求的部分信息，再将这个哈希值和 SYN+ACK 一起返回给客户端，客户端也经过一些运算，再返回给服务端，那么服务端根据这个返回值和之前的计算值比较，如果合法，就可以建立有效连接，从而不会占据半连接队列的内存。应对 SYN 攻击时，只需将 syncookies 的参数值调为 1（半连接队列溢出时启用），即可。相当的，可以增大半连接队列，但是要和 accept 的队列同时增大才有效，（否则会导致 accept 队列溢出同样丢失 TCP 连接）此时，对于客户端来说已经是 established 状态，但是还要再返回给服务端一个 ACK，服务端收到后，服务端才是 established 状态并开始传数据，如果网络不稳定，同样的，服务端会重发 SYN+ACK，当网络不稳定时，应该增加服务端重发 SYN+ACK 的次数。3. 服务端的 accept 队列优化当连接已经建立、应用程序尚未调用时，TCP 连接会被保存在一个 accept 队列中，如果进程未能及时调用，就会导致 accept 队列溢出，溢出部分连接将被默认丢弃。对此可以做的是，选择向客户端发送 RST 报文，告知关闭这个连接，丢弃握手过程。打开这一功能需要将 tcp_abort_on_overflow 参数设置为 1。如果想让客户端了解是由于 accept 队列溢出造成连接失败可以这样做。当 tcp_abort_on_overflow 参数设置为 0 时，则如果 accept 队列溢出，就会丢弃客户端传来的 ACK（用于最后一次握手）。应对高并发流量时，更好的选择是 tcp_abort_on_overflow 参数设置为 0，这样对于客户端它的状态仍然是 established，客户端会定时发送带有 ack 报文的发送数据请求，一旦服务端的 accept 队列有空位，那么连接仍有可能建立成功。所以只有很确定在一段时间内 accept 都是将溢出的状态，才推荐 tcp_abort_on_overflow 参数设置为 1。同样的，可以调整 accept 队列长度，也可以查看累计的由于溢出导致丢失的连接总数，来判断趋势。在 Linux 3.7 内核版本之后，提供了 TCP Fast Open 功能，这个功能如此生效：初次建立 TCP 连接时，客户端在第一个 SYN 包中传入一个请求 cookie，表明打开 fast open 功能，服务端对应生成一个 cookie 给客户端，除此之外，三次握手没有不同，但是，在 cookie 没有过期之前，下一次再连接的时候，客户端发送带有 cookie 的 SYN 包，服务端校验了 cookie 有效以后，就可以开始传输数据了，从而节约了一个往返的时间消耗。TCP Fast Open 功能需要服务端和客户端同时打开才能生效。（备注一个之前看到差点忘了的知识点。当主动方收到被动方的 FIN 报文后，内核会回复 ACK 报文给被动方，同时主动方的连接状态由 FIN_WAIT2 变为 TIME_WAIT，在 Linux 系统下大约等待 1 分钟后，TIME_WAIT 状态的连接才会彻底关闭。1. 主动方的优化关闭的方式有两种 RST 和 FIN，RST 是暴力关闭连接的方式，安全关闭连接则必须四次挥手。FIN 报文关闭则可以使用 close 和 shutdown 两种函数来实现。close 相对来说是“不优雅”的，调用 close 的一方的连接叫做「孤儿连接」，会同时关闭读和写，而 shutdown 可以控制是读还是写。关闭读的时候，会丢弃接收缓冲区里的所有数据，如果后续再接受到数据，也会悄悄丢弃，并发送 ACK，对方不会知道被丢弃了。关闭写的时候，会把发送缓冲区的数据全部发送并发送 FIN。（1）FIN_WAIT1 的优化主动方发送 FIN 以后，进入 FIN_WAIT1 状态，如果迟迟没收到 ACK，会定时重发 FIN，重发次数由 tcp_orphan_retries 参数控制，默认为 8 次，如果处于 FIN_WAIT1 状态的连接过多，应该考虑降低次数，重发次数超过参数时，连接会被直接关闭。如果遇到恶意攻击，可能无法发送出 FIN，因为 TCP 按顺序发送所有包， FIN 也不能绕过，另外如果对方的接收窗口已经满了，发送方也无法再发送数据。此时应该做的是调整 tcp_max_orphans 参数，它定义了「孤儿连接」的最大数量，当系统中的孤儿连接超过参数值，新增的孤儿连接不会再处于 FIN_WAIT1 状态，而是会被 RST 报文直接关闭。（只会影响 CLOSE 函数关闭的连接，不会影响 shutdown 关闭的，不会影响还有读或写的可能）（2）FIN_WAIT2 的优化主动方收到 ACK 后，会处于 FIN_WAIT2，因为被动方还可能有数据发送，如果是 shutdown 关闭，那它也可能还会发送数据，但是对于 close 关闭的连接，无法再发送和接收数据，保持在 FIN_WAIT2 的状态已经没有太大意义，tcp_fin_timeout 控制了这个状态下连接的持续时长，默认值是 60 秒。这个时间和 TIME_WAIT 状态时长是一致的。（3）TIME_WAIT 的优化TIME_WAIT 和 FIN_WAIT2 的时间是一致的，都是 2MSL，1MSL 表示一个报文在网络中存活的最长时间（报文每经过一次路由器的转发，IP 头部的 TTL 字段就会减 1，减到 0 时报文就被丢弃，这就限制了报文的最长存活时间），那么为什么是等待 2MSL 呢，其实就是允许报文至少丢失一次、再发送一次，这样第一个丢失了，等待的时间里第二个 ACK 还会到达，为什么不是 4MSL 以上呢，这是一个概率的问题，如果一个网络丢包率达到 1%，那么连续两次丢包的概率是万分之一，不必为了这种概率增加等待的时长。TIME_WAIT 有存在的意义，但是太多保持在这种状态的连接会占用双方资源，占据客户端的端口资源和服务端的系统资源。Linux 提供了 tcp_max_tw_buckets 参数，当 TIME_WAIT 的连接数量超过该参数时，新关闭的连接就不再经历 TIME_WAIT 而直接关闭。这个参数的设定应该取一个平衡点，即既不会太少导致高并发时产生连接间数据错乱的问题，也不会太多而导致耗尽端口和线程资源。对于用户端来讲，还可以启用 tcp_tw_reuse 参数来复用处于 TIME_WAIT 状态的连接（来节约接口资源。）这个参数有几个前提，一个是只有客户端可以打开，一个是 TIME_WAIT 状态也要保持 1 秒，另一个是要同步打开时间戳功能，报文带上时间戳就可以避免没有了 2MSL 时长以后的混乱情况，时间戳过期的报文就会被丢掉。另外对于 TIME_WAIT，还可以调整 socket 选项，来达到调用 close 关闭连接时跳过四次挥手直接关闭的效果，但不推荐。2. 被动方的优化首先，被动方收到 FIN 时，会自动回复 ACK，接着等待应用程序调用 close/shutdown 来结束连接，再发送 FIN。如果系统中同时查看到多个连接处于 CLOSE_WAIT 状态，则需要排查是否是应用程序出了故障。然后，当被动方也发送了 FIN 以后，还需要等待主动方回复一个 ACK，如果迟迟没收到，也会重发 FIN，重发次数也是 tcp_orphan_retries 参数控制，这点和主动方的优化一致，可以调整次数。（需确认被动方是否有 tcp_max_orphans 参数）3. 如果双方同时关闭？1.ACK 延迟目前在 TCP 中每传输一个报文都要求接收方进行确认，大量短而频繁的确认报文给网络带来了很多开销。因此采取了延迟 ACK 策略来减少 ACK 的数量，就是接收方收到一个报文以后，不会立即发送 ACK，而是等待 1~200ms，这期间若有回送数据报文就捎带确认，但收到两个连续数据报文或者等待超时则发送一个独立确认。有效减少了 ACK 的数量，改善了 TCP 的整体性能。2. 滑动窗口接收方的接收缓冲区不是不变的，接收到新的会变小，应用程序取出后又会变大，因此接收方会把自己当前的接收窗口大小放在 TCP 头告知发送方，如果不考虑拥塞控制，发送方的窗口大小「约等于」接收方的窗口大小。对于这一点，可以把 tcp_window_scaling 配置设为 1（默认打开）来扩大 TCP 通告窗口至 1G 大小。要使用这一选项，需要主动方在 SYN 中先告知，被动方在 SYN 中再反馈。但是缓冲区并非越大越好，还要考虑网络吞吐的能力。如果缓冲区与网络传输能力匹配，那么缓冲区的利用率就达到了最大化。3. 调整缓冲区大小这里需要说一个概念，就是带宽时延积，它决定网络中飞行报文的大小，它的计算方式：（1）发送缓冲区的调整发送缓冲区是自行调节的，当发送方发送的数据被确认后，并且没有新的数据要发送，就会把发送缓冲区的内存释放掉。接收缓冲区要复杂一些：上面三个数字单位都是字节，它们分别表示：（2）接收缓冲区的调整接收缓冲区可以根据系统空闲内存的大小来调节接收窗口：（3）内存的判断那么如何判断内存紧张或充分呢？上面三个数字单位不是字节，而是「页面大小」，1 页表示 4KB，它们分别表示：在实际的场景中，TCP 缓冲区最小值保持默认 4K 即可，来提高并发处理能力；最大值则尽可能靠近带宽时延积，来最大化网络效率。总结以上：为了提高并发能力、提高网络效率，我们要充分利用网络能力和自己的内存。网络这方面就是将缓冲区大小的极值尽可能靠近带宽时延积，而同时对缓冲区的自动调节需要结合内存来判断，这个 TCP 内存的判断是通过系统内存计算出来的几个值来划分的，在不同区间会对分配给缓冲区的内存大小进行调整。以上就是 TCP 在不同阶段的优化策略和思路，有关拥塞控制和流量控制之后再补一篇笔记。

HDD由于物理结构原因4K随机性能很差。4K随机多通道在日常中的体现比如开机快慢（后台无数进程同时加载），见到桌面后如果是SSD，马上操作几个程序也没事；要是机械硬盘开机见到桌面得等一两分钟，多点程序就要死机；排除这方面的原因后，电脑日常操作还卡，或者玩游戏卡，就要排查下了。 1、卫士/管家/毒霸/杀毒/火绒/鲁大师等最好全卸载。2、不建议修复漏洞补丁。