tcp长连接保持多久(tcp建立连接后多久释放)

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

一般俗说的长连接是指一直连着，短连接就是请求一次，连接一次，断开一次，都指的tcp。比如http 1.0一般就指短连接，smtp,pop3,telnet这种就可以认为是长连接。

长连接的过期时间客户端的长连接不可能无限期的拿着，会有一个超时时间，服务器有时候会告诉客户端超时时间，譬如：上图中的Keep-Alive: timeout=20，表示这个TCP通道可以保持20秒。另外还可能有max=XXX，表示这个长连接最多接收XXX次请求就断开。对于客户端来说，如果服务器没有告诉客户端超时时间也没关系，服务端可能主动发起四次握手断开TCP连接，客户端能够知道该TCP连接已经无效；另外TCP还有心跳包来检测当前连接是否还活着，方法很多，避免浪费资源。

短连接发送完数据后就会立即断掉,而长连接则会保留这个连接
短连接一般只会在client/server间传递一次读写操作。 长连接在完成一次读写之后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。短连接的优点是：管理起来比较简单，存在的连接都是有用的连接，不需要额外的控制手段。长连接有TCP保活功能，主要为探测长连接的存活状况，不过这里存在一个问题，存活功能的探测周期太长，还有就是它只是探测TCP连接的存活，属于比较斯文的做法，遇到恶意的连接时，保活功能就不够使了。 长连接和短连接主要区别在于client和server采取的关闭策略。

每两个小时，tcp自动探测一次，发现对方关闭，则断开连接 除非应用层有特殊要求（比如要求每5分钟探测一次），否则不需要关心这个问题。我记得keepalive option似乎不能设置时间，只是打开关闭keep alive选项。 设置时间是在另外的地方（好像是sysctl，或者/proc下面），而且这个时间是一个系统只有一个，一旦改变所有程序的keepalive检测时间都变。