http keep-alive与tcp keep-alive

http keep-alive与tcp keep-alive

http keep-alive与tcp keep-alive,不是同一回事,意图不一样。http keep-alive是为了让tcp活得更久一点,以便在同一个连接上传送多个http,提高socket的效率。而tcp keep-alive是TCP的一种检测TCP连接状况的保鲜机制。tcp keep-alive保鲜定时器,支持三个系统内核配置参数:

echo 1800 > /proc/sys/net/ipv4/tcp_keepalive_time

echo 15 > /proc/sys/net/ipv4/tcp_keepalive_intvl

echo 5 > /proc/sys/net/ipv4/tcp_keepalive_probes

keepalive是TCP保鲜定时器,当网络两端建立了TCP连接之后,闲置idle(双方没有任何数据流发送往来)了 tcp_keepalive_time后,服务器内核就会尝试向客户端发 送侦测包,来判断TCP连接状况(有可能客户端崩溃、强制关闭了应用、主机不可达等等)。如果没有收到对方的回答(ack包),则会在 tcp_keepalive_intvl后再次尝试发送侦测包,直到收到对对方的ack,如果一直没有收到对方的ack,一共会尝试 tcp_keepalive_probes次,每次的间隔时间在这里分别是15s,
30s, 45s, 60s, 75s。如果尝试tcp_keepalive_probes,依然没有收到对方的ack包,则会丢弃该TCP连接。TCP连接默认闲置时间是2小时,一般 设置为30分钟足够了。也就是说,仅当nginx的keepalive_timeout值设置高于tcp_keepalive_time,并且距此tcp连接传输的最后一
个http响应,经过了tcp_keepalive_time时间之后,操作系统才会发送侦测包来决定是否要丢弃这个TCP连接。一般不会出现这种情况, 除非你需要这样做。

时间: 2024-08-18 05:21:00

http keep-alive与tcp keep-alive的相关文章

TCP 连接与TCP keep alive 保活检测机制

生产环境中一台2核4G的linux服务器TCP连接数时常保持在5-7w间徘徊,查看日志每秒的请求数也就100-200,怎么会产生这么大的TCP连接数.检查了下客户端上行的HTTP协议,Connection 头字段是Keep-Alive,并且客户端在请求完之后没有立即关闭连接.而服务端的设计也是根据客户端来的,客户端上行如果Connection:Keep-Alive,服务端是不会主动关闭连接的.在客户端与服务端交互比较频繁的时候,这样的设计还是比较合理的,可以减少TCP的重复握手.显然如果只交互一

(转)RTSP - RTP over TCP

Normally, RTSP provide streaming over UDP. By nature, UDP is a better choice as it provides robust streaming capability for media. However, it is unlikely to use UDP for streaming over the Internet. 通常来说,RTSP提供UDP方式发送RTP流.当然,发送流媒体时,UDP往往是更好的选择.但是,在互联

RTSP - RTP over TCP

Normally, RTSP provide streaming over UDP. By nature, UDP is a better choice as it provides robust streaming capability for media. However, it is unlikely to use UDP for streaming over the Internet. 通常来说,RTSP提供UDP方式发送RTP流.当然,发送流媒体时,UDP往往是更好的选择.但是,在互联

c#网络通信框架networkcomms内核解析之十一 TCP连接与UDP连接

连接是通信的核心 客户端一般只会有一个连接 服务器端会维护成千上万的连接 在服务器端连接的维护工作是由NetworkComms静态类来完成的,当有新的客户端请求,服务器上会创建相应的连接,并把连接注册到NetworkComms静态类中.当连接断开后,NetworkComms通信框架会自动把相应连接的引用从NetworkComms静态类中删除. 连接的类图: 在V3以上版本中,数据监听部分已从Connnection类中提取出去成为一个单独的类: TCPConnectionListener   ,使

TCP的定时器

TCP为每条连接建立七个定时器,依次为:连接建立定时器.重传定时器.延时ACK定时器.持续定时器.保活定时器.FIN_WAIT_2定时器和TIME_WAIT定时器.实际上,为了提高效率,内核中只使用了四个定时器来完成七个定时器的功能. TCP定时器的实现涉及以下文件: net/ipv4/tcp_timer.c TCP的定时器 net/ipv4/inet_connection_sock.c 基于连接的传输控制块实现 net/ipv4/tcp_output.c TCP的输出 net/ipv4/tcp

Linux下关于TCP的keep alive的实现源码分析

TCP下的Keep Alive 我们常说的TCP的keep alive,就是为了保证连接的有效性,在间隔一定的时间发探测包,根据回复来确认该连接是否有效.通常上层应用会自己提供心跳检测机制,而Linux内核本身也提供了从内核层面的确保连接有效性的方式. 在sock 函数中可以设置是否需要打开keep alive开关,默认建立socket 是关闭keep alive的.代码如下 optval = 1; optlen = sizeof(optval); if(setsockopt(s, SOL_SO

[6] MQTT,mosquitto,Eclipse Paho---MQTT消息格式之CONNECT消息格式分析

在"[3] MQTT,mosquitto,Eclipse Paho---如何使用 Eclipse Paho MQTT工具来发送订阅MQTT消息?"一文中我已经和大家简单讲述了如何使用Eclipse Paho MQTT.那么当我们点击"Connect"按钮,究竟在TCP协议层发生了什么?如何通过MQTT规定的协议和TCP的二进制数据进行对比,从而更加深入的学习MQTT的消息格式呢?笔者将带领大家以CONNECT消息格式为例子,分析第一个MQTT的消息格式, MQTT的

Wireshark抓包常见出现错误

转自这里 1.   tcp out-of-order(tcp有问题) 解答: 1).    应该有很多原因.但是多半是网络拥塞,导致顺序包抵达时间不同,延时太长,或者包丢失,需要重新组合数据单元 因为他们可能是通过不同的路径到达你电脑上面的. 2).    CRM IT 同仁上礼拜来跟我反应一个问题,由他们客服系统藉由邮件主机要寄送给客户的信件,常常会有寄送失败的问题,查看了一下 Log,发现正常的信件在主机接收 DATA 完成后会记录收到的邮件大小,然后开始进行后续寄送出去的处理,但这些有问题

[转]HTTP的长连接和短连接

本文原链接:http://www.cnblogs.com/cswuyg/p/3653263.html   本文总结&分享网络编程中涉及的长连接.短连接概念.     关键字:Keep-Alive,并发连接数限制,TCP,HTTP 一.什么是长连接 HTTP1.1规定了默认保持长连接(HTTP persistent connection ,也有翻译为持久连接),数据传输完成了保持TCP连接不断开(不发RST包.不四次握手),等待在同域名下继续用这个通道传输数据:相反的就是短连接. HTTP首部的C

C#作业总结 (5)

这一块总结程序的核心部分,局域网内的聊天,这部分我没有使用固定的服务器,而是通过UDP确定聊天的对象,然后双方通过TCP进行聊天,点对点式的聊天. 首先分析一段TCP的服务器和客户端的代码,基本这个代码看懂了就差不多 服务器部分 #region 通信协议说明 // CONNECT|客户端名称 服务器接收 发送不同的客户端 初始化聊天室 // LISTEN|聊天室其他用户名称 客户端接收 初始化聊天室 // CHAT|客户名称|内容 服务器接收 发送消息 // JOIN|客户端名称 客户端接收 增