在线tcp连接(tcp长连接)

你好，很高兴为你解答！ 根据你的描述，只要你的服务器IP地址是公网的，就可以直接连，服务器一般放置在公网上，有固定的IP地址。 希望我的回答可以帮助你，安徽电信祝您生活愉快。

1)统计80端口连接数2）统计httpd协议连接数3）、统计已连接上的，状态为“established4)、查出哪个IP地址连接最多,将其封了.1、查看apache当前并发访问数：对比httpd.conf中MaxClients的数字差距多少。2、查看有多少个进程数：3、可以使用如下参数查看数据统计httpd进程数，连个请求会启动一个进程，使用于Apache服务器。表示Apache能够处理1388个并发请求，这个值Apache可根据负载情况自动调整。4341netstat -an会打印系统当前网络链接状态，而grep -i "80"是用来提取与80端口有关的连接的，wc -l进行连接数统计。最终返回的数字就是当前所有80端口的请求总数。netstat -an会打印系统当前网络链接状态，而grep ESTABLISHED 提取出已建立连接的信息。 然后wc -l统计。最终返回的数字就是当前所有80端口的已建立连接的总数。查看Apache的并发请求数及其TCP连接状态：TIME_WAIT 8947 等待足够的时间以确保远程TCP接收到连接中断请求的确认FIN_WAIT1 15 等待远程TCP连接中断请求，或先前的连接中断请求的确认FIN_WAIT2 1 从远程TCP等待连接中断请求ESTABLISHED 55 代表一个打开的连接SYN_RECV 21 再收到和发送一个连接请求后等待对方对连接请求的确认CLOSING 2 没有任何连接状态LAST_ACK 4 等待原来的发向远程TCP的连接中断请求的确认TCP连接状态详解LISTEN： 侦听来自远方的TCP端口的连接请求SYN-SENT： 再发送连接请求后等待匹配的连接请求SYN-RECEIVED：再收到和发送一个连接请求后等待对方对连接请求的确认ESTABLISHED： 代表一个打开的连接FIN-WAIT-1： 等待远程TCP连接中断请求，或先前的连接中断请求的确认FIN-WAIT-2： 从远程TCP等待连接中断请求CLOSE-WAIT： 等待从本地用户发来的连接中断请求CLOSING： 等待远程TCP对连接中断的确认LAST-ACK： 等待原来的发向远程TCP的连接中断请求的确认TIME-WAIT： 等待足够的时间以确保远程TCP接收到连接中断请求的确认CLOSED： 没有任何连接状态LAST_ACK 5SYN_RECV 30ESTABLISHED 1597FIN_WAIT1 51FIN_WAIT2 504TIME_WAIT 1057其中的SYN_RECV表示正在等待处理的请求数；ESTABLISHED表示正常数据传输状态；TIME_WAIT表示处理完毕，等待超时结束的请求数。查看Apache并发请求数及其TCP连接状态查看httpd进程数（即prefork模式下Apache能够处理的并发请求数）：返回结果示例：1388表示Apache能够处理1388个并发请求，这个值Apache可根据负载情况自动调整，我这组服务器中每台的峰值曾达到过2002。查看Apache的并发请求数及其TCP连接状态：返回结果示例：LAST_ACK 5SYN_RECV 30ESTABLISHED 1597FIN_WAIT1 51FIN_WAIT2 504TIME_WAIT 1057其中的SYN_RECV表示正在等待处理的请求数；ESTABLISHED表示正常数据传输状态；TIME_WAIT表示处理完毕，等待超时结束的请求数。状态：描述CLOSED：无连接是活动 的或正在进行LISTEN：服务器在等待进入呼叫SYN_RECV：一个连接请求已经到达，等待确认SYN_SENT：应用已经开始，打开一个连接ESTABLISHED：正常数据传输状态FIN_WAIT1：应用说它已经完成FIN_WAIT2：另一边已同意释放ITMED_WAIT：等待所有分组死掉CLOSING：两边同时尝试关闭TIME_WAIT：另一边已初始化一个释放LAST_ACK：等待所有分组死掉vim /etc/sysctl.conf编辑文件，加入以下内容：net.ipv4.tcp_syncookies = 1net.ipv4.tcp_tw_reuse = 1net.ipv4.tcp_tw_recycle = 1net.ipv4.tcp_fin_timeout = 30然后执行 /sbin/sysctl -p 让参数生效。net.ipv4.tcp_syncookies = 1 表示开启SYN cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。net.ipv4.tcp_fin_timeout 修改系统默认的 TIMEOUT 时间客户端与服务器端建立TCP/IP连接后关闭SOCKET后，服务器端连接的端口状态为TIME_WAIT是不是所有执行主动关闭的socket都会进入TIME_WAIT状态呢？有没有什么情况使主动关闭的socket直接进入CLOSED状态呢？主动关闭的一方在发送最后一个 ack 后就会进入 TIME_WAIT 状态 停留2MSL（max segment lifetime）时间这个是TCP/IP必不可少的，也就是“解决”不了的。也就是TCP/IP设计者本来是这么设计的主要有两个原因1。防止上一次连接中的包，迷路后重新出现，影响新连接（经过2MSL，上一次连接中所有的重复包都会消失）2。可靠的关闭TCP连接在主动关闭方发送的最后一个 ack(fin) ，有可能丢失，这时被动方会重新发fin, 如果这时主动方处于 CLOSED 状态 ，就会响应 rst 而不是 ack。所以主动方要处于 TIME_WAIT 状态，而不能是 CLOSED 。TIME_WAIT 并不会占用很大资源的，除非受到攻击。还有，如果一方 send 或 recv 超时，就会直接进入 CLOSED 状态如何合理设置apache httpd的最大连接数？手头有一个网站在线人数增多，访问时很慢。初步认为是服务器资源不足了，但经反复测试，一旦连接上，不断点击同一个页面上不同的链接，都能迅速打开，这种现象就是说明apache最大连接数已经满了，新的访客只能排队等待有空闲的链接，而如果一旦连接上，在keeyalive 的存活时间内（KeepAliveTimeout，默认5秒）都不用重新打开连接，因此解决的方法就是加大apache的最大连接数。1.在哪里设置？apache 2.24，使用默认配置（FreeBSD 默认不加载自定义MPM配置），默认最大连接数是250在/usr/local/etc/apache22/httpd.conf中加载MPM配置（去掉前面的注释）：Include etc/apache22/extra/httpd-mpm.conf可见的MPM配置在/usr/local/etc/apache22/extra/httpd-mpm.conf，但里面根据httpd的工作模式分了很多块，哪一部才是当前httpd的工作模式呢？可通过执行 apachectl -l 来查看：Compiled in modules:core.cprefork.chttp_core.cmod_so.c看到prefork 字眼，因此可见当前httpd应该是工作在prefork模式，prefork模式的默认配置是：StartServers5MinSpareServers 5MaxSpareServers10MaxClients150MaxRequestsPerChild 02.要加到多少？连接数理论上当然是支持越大越好，但要在服务器的能力范围内，这跟服务器的CPU、内存、带宽等都有关系。查看当前的连接数可以用：ps aux | grep httpd | wc -l或：pgrep httpd|wc -l计算httpd占用内存的平均数:ps aux|grep -v grep|awk '/httpd/{sum+=$6;n++};END{print sum/n}'由于基本都是静态页面，CPU消耗很低，每进程占用内存也不算多，大约200K。服务器内存有2G，除去常规启动的服务大约需要500M（保守估计），还剩1.5G可用，那么理论上可以支持1.510241024*1024/200000 = 8053.06368约8K个进程，支持2W人同时访问应该是没有问题的（能保证其中8K的人访问很快，其他的可能需要等待1、2秒才能连上，而一旦连上就会很流畅）控制最大连接数的MaxClients ，因此可以尝试配置为：StartServers5MinSpareServers 5MaxSpareServers10ServerLimit5500MaxClients 5000MaxRequestsPerChild 100注意，MaxClients默认最大为250，若要超过这个值就要显式设置ServerLimit，且ServerLimit要放在MaxClients之前，值要不小于MaxClients，不然重启httpd时会有提示。重启httpd后，通过反复执行pgrep httpd|wc -l 来观察连接数，可以看到连接数在达到MaxClients的设值后不再增加，但此时访问网站也很流畅，那就不用贪心再设置更高的值了，不然以后如果网站访问突增不小心就会耗光服务器内存，可根据以后访问压力趋势及内存的占用变化再逐渐调整，直到找到一个最优的设置值。(MaxRequestsPerChild不能设置为0，可能会因内存泄露导致服务器崩溃）更佳最大值计算的公式：apache_max_process_with_good_perfermance < (total_hardware_memory / apache_memory_per_process ) * 2apache_max_process = apache_max_process_with_good_perfermance * 1.5附：实时检测HTTPD连接数：watch -n 1 -d "pgrep httpd|wc -l"

使用TCP/IP协议连接PLC时如果经常出现通讯中断的情况，那么就要做出如下检查，以确定问题所在。首先，检查网络连接线的好坏，从外观上判断其是否有破损，挤压，或其它损坏现象，若直观查看无法判断最好使用测线仪进行测试，这样更为准确。其次，检查电脑网卡，系统是否有报警故障，网卡运行是否正常，电脑主机是否有腐蚀，灰尘等环境因素造成的系统运行卡顿。最后，通过网络测试查看数据发送和接收的速度，并且要查看周围是否有其他网络干扰情况
发生通讯问题时，最好在线监视下TCP_CONNECT、TCP_SEND、TCP_RECV 指令的Error、Status参数值，来判断故障原因 通讯示例文档：补充：9表示：TCP_CONNECT、ISO_CONNECT 或 UDP_CONNECT 指令正使用此连接 ID 执行。 plc与上位机tcp通讯，那plc一般是做服务器、被动连接，TCP_CONNECT的Req接常ON信号（不要加上|P|用脉冲触发），Active接常OFF信号。
通常有两种技术 方法1:应用层自己实现的心跳包 由应用程序自己发送心跳包来检测连接是否正常,大致的方法是:服务器在一个 Timer事件中定...方法2：TCP的KeepAlive保活机制 因为要考虑到一个服务器通常会连接多个客户端，因此由用户在应用层自己实现心跳包，代码较多 且稍显复杂，而利用TCP／IP协议层为内置的KeepAlive功能来实现心跳功能则简单得多。

原文地址: http://f543711700.iteye.com/blog/978044发送消息的时候是UDP打洞,登陆的时候使用HTTP~因为登陆服务器其实就是一个HTTP服务器,只不过不是常用的那些,那个服务器是腾讯自行开发的！！！QQ客户端在局域网内，当你打开QQ登录到QQ服务器时，通过外网，你的客户端与QQ服务器建立了一个长连接。你可以用netstat -bn看到此连接的状态是 establish此时，在QQ服务器那面看到的连接的IP是你们局域网对外的IP。举个例子：这是一个假象。通过QQ服务器看到的连接是：这样，防火墙上的31234口对应的就是你机器的55579口。（由于你是发起方，这个数是变化的。动态的）当有信息给你时，QQ服务器只需要发给防火墙的55579口即可。（这里防火墙作了地址翻译）不管UDP还是TCP，最终登陆成功之后，QQ都会有一个TCP连接来保持在线状态。这个TCP连接的远程端口一般是80，采用UDP方式登陆的时候，端口是8000。因此，假如你所在的网络开放了80端口（80端口是最常用端口。。就是通常访问Web的端口，禁掉它的话，你的网络对你来说价值已经不大了），但没有屏蔽腾讯的服务器IP，恭喜你，你是可以登陆成功QQ的。采用UDP协议，通过服务器中转方式。大家都知道，UDP 协议是不可靠协议，它只管发送，不管对方是否收到的，但它的传输很高效。但是，作为聊天软件，怎么可以采用这样的不可靠方式来传输消息呢？于是，腾讯采用了上层协议来保证可靠传输：如果客户端使用UDP协议发出消息后，服务器收到该包，需要使用UDP协议发回一个应答包。如此来保证消息可以无遗漏传输。之所以会发生在客户端明明看到“消息发送失败”但对方又收到了这个消息的情况，就是因为客户端发出的消息服务器已经收到并转发成功，但客户端由于网络原因没有收到服务器的应答包引起的。因为用户一般都是在局域网内,地址都为私有IP,腾讯服务器是如何将信息转发到用户的?首先先介绍一些基本概念：最先提出的是基本的NAT，它的产生基于如下事实：一个私有网络（域）中的节点中只有很少的节点需要与外网连接（呵呵，这是在上世纪90年代中期提出的）。那么这个子网中其实只有少数的节点需要全球唯一的IP地址，其他的节点的IP地址应该是可以重用的。因此，基本的NAT实现的功能很简单，在子网内使用一个保留的IP子网段，这些IP对外是不可见的。子网内只有少数一些IP地址可以对应到真正全球唯一的IP地址。如果这些节点需要访问外部网络，那么基本NAT就负责将这个节点的子网内IP转化为一个全球唯一的IP然后发送出去。(基本的NAT会改变IP包中的原IP地址，但是不会改变IP包中的端口)关于基本的NAT可以参看RFC 1631另外一种NAT叫做NAPT，从名称上我们也可以看得出，NAPT不但会改变经过这个NAT设备的IP数据报的IP地址，还会改变IP数据报的TCP/UDP端口。基本NAT的设备可能我们见的不多（呵呵，我没有见到过），NAPT才是我们真正讨论的主角。看下图：有一个私有网络10. . .*，ClientA是其中的一台计算机，这个网络的网关（一个NAT设备）的外网IP是155.99.25.11(应该还有一个内网的IP地址，比如10.0.0.10)。如果Client A中的某个进程（这个进程创建了一个UDPSocket,这个Socket绑定1234端口）想访问外网主机18.181.0.31的1235端口，那么当数据包通过NAT时会发生什么事情呢？首先NAT会改变这个数据包的原IP地址，改为155.99.25.11。接着NAT会为这个传输创建一个Session（Session是一个抽象的概念，如果是TCP，也许Session是由一个SYN包开始，以一个FIN包结束。而UDP呢，以这个IP的这个端口的第一个UDP开始，结束呢，呵呵，也许是几分钟，也许是几小时，这要看具体的实现了）并且给这个Session分配一个端口，比如62000，然后改变这个数据包的源端口为62000。所以本来是（10.0.0.1:1234->18.181.0.31:1235）的数据包到了互联网上变为了（155.99.25.11:62000->18.181.0.31:1235）。一旦NAT创建了一个Session后，NAT会记住62000端口对应的是10.0.0.1的1234端口，以后从18.181.0.31发送到62000端口的数据会被NAT自动的转发到10.0.0.1上。（注意：这里是说18.181.0.31发送到62000端口的数据会被转发，其他的IP发送到这个端口的数据将被NAT抛弃）这样Client A就与Server S1建立以了一个连接。呵呵，上面的基础知识可能很多人都知道了，那么下面是关键的部分了。看看下面的情况：接上面的例子，如果Client A的原来那个Socket(绑定了1234端口的那个UDP Socket)又接着向另外一个Server S2发送了一个UDP包，那么这个UDP包在通过NAT时会怎么样呢？这时可能会有两种情况发生，一种是NAT再次创建一个Session，并且再次为这个Session分配一个端口号（比如：62001）。另外一种是NAT再次创建一个Session，但是不会新分配一个端口号，而是用原来分配的端口号62000。前一种NAT叫做SymmetricNAT，后一种叫做ConeNAT。我们期望我们的NAT是第二种，呵呵，如果你的NAT刚好是第一种，那么很可能会有很多P2P软件失灵。（可以庆幸的是，现在绝大多数的NAT属于后者，即Cone NAT）好了，我们看到，通过NAT,子网内的计算机向外连结是很容易的（NAT相当于透明的，子网内的和外网的计算机不用知道NAT的情况）。但是如果外部的计算机想访问子网内的计算机就比较困难了（而这正是P2P所需要的）。那么我们如果想从外部发送一个数据报给内网的计算机有什么办法呢？首先，我们必须在内网的NAT上打上一个“洞”（也就是前面我们说的在NAT上建立一个Session），这个洞不能由外部来打，只能由内网内的主机来打。而且这个洞是有方向的，比如从内部某台主机（比如：192.168.0.10）向外部的某个IP(比如：219.237.60.1)发送一个UDP包，那么就在这个内网的NAT设备上打了一个方向为219.237.60.1的“洞”，（这就是称为UDP HolePunching的技术）以后219.237.60.1就可以通过这个洞与内网的192.168.0.10联系了。（但是其他的IP不能利用这个洞）。呵呵，现在该轮到我们的正题P2P了。有了上面的理论，实现两个内网的主机通讯就差最后一步了：两边都无法主动发出连接请求，谁也不知道谁的公网地址，那我们如何来打这个洞呢？我们需要一个中间人来联系这两个内网主机。现在我们来看看一个P2P软件的流程，以下图为例：首先，Client A登录服务器，NAT A为这次的Session分配了一个端口60000，那么ServerS收到的Client A的地址是202.187.45.3:60000，这就是Client A的外网地址了。同样，ClientB登录Server S，NAT B给此次Session分配的端口是40000，那么ServerS收到的B的地址是187.34.1.56:40000。此时，Client A与Client B都可以与ServerS通信了。如果Client A此时想直接发送信息给Client B，那么他可以从ServerS那儿获得B的公网地址187.34.1.56:40000，是不是Client A向这个地址发送信息ClientB就能收到了呢？答案是不行，因为如果这样发送信息，NATB会将这个信息丢弃（因为这样的信息是不请自来的，为了安全，大多数NAT都会执行丢弃动作）。那该怎么办呢？ 首先我们假设Server S是219.237.60.1：7000，当Clinet A（202.187.45.3：60000）向Server S（219.237.60.1：7000）发送数据包，Server S是可以正常接收到数据，因为它是属于外型开放的服务器端口。当Server S收到数据包后可以获知Clinet A（202.187.45.3：60000）对外通信的临时session信息（这个叫临时的端口，假设是60000会过期，具体时间不同，一般是每30S发送一个keep住连接以保证端口维持通信连接不断）Server S此时应将次信息保存起来。而同时，Client B (192.168.0.10:40000)也在时刻向Server S发送心跳包，Server S就向Client B (192.168.0.10:40000)发送一个通知，让Client B(192.168.0.10:4000) 发送探测包（这个数据包最好发几个），Client B(192.168.0.10:4000)在收到通知后在向Server S发送反馈包，说明以向自己以向Client A(192.168.0.20:60000)发送了探测包，Server S在收到反馈之后再向Client A(192.168.0.20:60000)转发反馈包，Client A(192.168.0.20:60000)在收到数据包之后在向原本要求请求的Client B(192.168.0.10:4000)发送数据包，此时连接已经打通，实现穿透。Client B(192.168.0.10:4000)会将数据包转发给Client A(192.168.0.20:60000)从而在转发给内网内网IP:192.168.0.1。 对于Symmetric NAPT的情况，网上有人说可以通过探测端口的方式，不过成功率并不高，我建议可用服务器进行中转。另外，最好在数据包发送前先检测是否进行的是同个NAT的情况，也就是内网发内网，如果是，直接发送即可，而无需通过外网再绕回来。

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