tcp连接资源(tcp连接资源消耗)

整理自 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 在不同阶段的优化策略和思路，有关拥塞控制和流量控制之后再补一篇笔记。

1、面向连接的：使用TCP协议通信的双方必须先建立连接，然后才能开始数据的读写，TCP连接是全双工的，即双方的数据读写可以通过一个连接进行。完成数据交换之后，通信双方都必须断开连接以释放资源。TCP协议的这种连接是一对一的，所以基于广播和多播（目标是多个主机地址）的应用程序不能使用TCP服。而无连接协议UDP则非常适合于广播和多播。 2、流式服务：TCP的字节流服务的表现形式就体现在，发送端执行的写操作数和接收端执行的读操作次数之间没有任何数量关系，当发送端应用程序连续执行多次写操作的时，TCP模块先将这些数据放入TCP发送缓冲区中。当TCP模块真正开始发送数据的时候，发送缓冲区中这些等待发送的数据可能被封装成一个或多个TCP报文段发出。（下图3-1） 3、UPD的数据报服务：发送端应用程序每执行一次写操作，UDP模块就将其封装成一个UDP数据报并发送之。接收端必须及时针对每一个UDP数据报执行读操作（通过recvfrom系统调用），否则就会丢包（这经常发生在较慢的服务器上）。并且，如果没有指定足够的应用程序缓冲区来读取UDP数据，则UDP数据将被截断。
物联网的通信环境有Ethernet， Wi-Fi， RFID， NFC(近距离无线通信)， Zigbee， 6LoWPAN(IPV6低速无线版本)，Bluetooth， GSM， GPRS， GPS， 3G， 4G等网络，而每一种通信应用协议都有一定适用范围。AMQP、JMS、REST/HTTP都是工作在以太网，COAP协议是专门为资源受限设备开发的协议，而DDS和MQTT的兼容性则强很多

在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和udp的区别如下：1、TCP面向连接（如打电话要先拨号建立连接），UDP是无连接的，即发送数据之前不需要建立连接。2、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达。UDP尽最大努力交付，即不保证可靠交付。Tcp通过校验和，重传控制，序号标识，滑动窗口、确认应答实现可靠传输。如丢包时的重发控制，还可以对次序乱掉的分包进行顺序控制。3、UDP具有较好的实时性，工作效率比TCP高，适用于对高速传输和实时性有较高的通信或广播通信。4、每一条TCP连接只能是点到点的，UDP支持一对一，一对多，多对一和多对多的交互通信。5、TCP对系统资源要求较多，UDP对系统资源要求较少。

在介绍TCP和UDP协议之前，有必要先了解下TCP/IP模型，TCP/IP中的两个具有代表性的传输协议：TCP和UDP。 TCP/IP 是互联网相关的各类协议族的总称，比如：TCP，UDP，IP，FTP，HTTP，ICMP，SMTP 等都属于 TCP/IP 族内的协议。TCP/IP模型是互联网的基础，它是一系列网络协议的总称。这些协议可以划分为四层，分别为链路层、网络层、传输层和应用层。TCP协议全称是传输控制协议，是一种面向连接、可靠的、基于字节流的传输层通信协议，由IETF的RFC 793定义。流就是指不间断的数据结构，可以想象成水管中的水流。TCP 在传送数据之前必须先建立连接，数据传送结束后要释放连接。TCP 不提供广播或多播服务。由于 TCP 要提供可靠的，面向连接的运输服务（TCP 的可靠体现在 TCP 在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源），这难以避免增加了许多开销，如确认，流量控制，计时器以及连接管理等。这不仅使协议数据单元的首部增大很多，还要占用许多处理机资源。最初客户端和服务端都处于CLOSED（关闭）状态，客户端主动打开连接，服务端被动打开连接。--- 为了防止已经失效的连接请求又突然被服务端接收，从而产生错误。比如：A发出的第一个连接请求报文段并没有丢失，而是在网络结点时间长了，以致于延误到连接释放以后的某个时间段才到达B，但是B收到此失效的请求后，就误以为A又发出一次新的连接请求，于是就向A发出确认报文段，同意建立连接。出现失效的连接请求报文段被服务端接收的情况，从而产生错误。UDP协议全称是用户数据报协议，在网络中它与TCP协议一样用于处理数据包，是一种无连接的协议。在OSI模型中，在第四层——传输层，处于IP协议的上一层。UDP有不提供数据包分组、组装和不能对数据包进行排序的缺点，也就是说，当报文发送之后，是无法得知其是否安全完整到达的。UDP在传送数据之前不需要建立连接，远地主机在收到UDP报文后，不需要给出任何确认。虽然UDP不提供可靠交付，但在某些情况下，UDP却是最有效的一种比如QQ语音、QQ视频、直播等即时通信应用。因此 UDP 的头部开销小，只有八字节，相比 TCP 的至少二十字节要少得多，在传输数据报文时是很高效的1、连接的区别TCP面向连接，即发送数据之前先建立连接。UDP是无连接的，即发送数据之前是不需要建立连接的。2、安全方面的区别TCP是全双工的可靠通信，提供可靠的服务，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达。使用流量控制和拥塞控制。UDP是不可靠传输，尽最大努力交付，即不保证可靠交付。3、传输效率的区别TCP传输效率较低。UDP传输效率高，适用于对高速传输和实时性有较高要求的通信或广播通信。4、连接对象数量的区别TCP连接只能是点到点，一对一的。UDP支持一对一，一对多，多对一和多对多的交互通信。5、传输方式的区别TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流。适用于要求可靠传输的应用比如文件传输等。UDP面向报文，没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低，对实时应用很有用比如实时视频会议等。6、首部开销TCP首部开销最小20字节，最大60字节。 UDP首部开销小，只有8个字节。