Linux作为一个强大的操作系统,提供了一系列内核参数供我们进行调优。光TCP的调优参数就有50多个。在和线上问题斗智斗勇的过程中,笔者积累了一些在内网环境应该进行调优的参数。在此分享出来,希望对大家有所帮助。
网络编程中超时时间是一个重要但又容易被忽略的问题,对其的设置需要仔细斟酌。在经历了数次物理机宕机之后,笔者详细的考察了在网络编程(tcp)中的各种超时设置,于是就有了本篇博文。本文大部分讨论的是socket设置为block的情况,即setNonblock(false),仅在最后提及了nonblock socket(本文基于linux 2.6.32-431内核)。
无论你用任何语言或者是网络库,你都可以设置网络操作的超时时间,特别是connect,read,write的超时时间。
之前我在「实战!我用“大白鲨”让你看见 TCP」这篇文章里做了 TCP 三次握手的三个实验:
为了让大家更容易「看得见」 TCP,我搭建不少测试环境,并且数据包抓很多次,花费了不少时间,才抓到比较容易分析的数据包。
之前已经分析过了keep-alive,最近在使用nodejs的keep-alive的时候发现了遗漏了一个内容。本文进行一个补充说明。我们先看一下nodejs中keep-alive的使用。
TCP重传机制主要是为了防止网路包丢弃,重传的工作方式主要借助TCP头部中的序列号和确认号来决定是否重传,重传的触发方式主要由以下几种:
收到一位读者的私信,说字节面试有这么一个问题:服务端挂了,客户端的 TCP 连接会发生什么?
机器一般过质保之后,就会因为各种各样的问题而宕机。而这一次的宕机,让笔者观察到了平常观察不到的tcp在对端宕机情况下的行为。经过详细跟踪分析原因之后,发现可以通过调整内核tcp参数来减少宕机造成的影响。
在远程服务器管理和安全数据传输中,SSH(Secure Shell)是不可或缺的工具。然而,它的便利性和安全性有时会因常见的问题而受到损害:冻结 SSH 会话。
TCP协议仅定义框架,也就是发送端和接收端需要遵循的“规则”。TCP协议的实现经过多年的改进,有了多个不同的版本。比较重要的有Tahoe、Reno、NewReno、SACK、Vegas等,有些已经成为了影响广泛的RFC文档,有些则成为了Unix/Linux操作系统的标准选项。
最近花了些时间在学习TCP/IP协议上,首要原因是由于本人长期以来对TCP/IP的认识就只限于三次握手四次分手上,所以希望深入了解一下。再者,TCP/IP和Linux系统层级的很多设计都可以用于中间件系统架构上,比如说TCP 拥塞控制算法也可以用在以响应时间来限流的中间件上。更深一层,像TCP/IP协议这种基础知识和原理性的技术,都是经过长时间的考验的,都是前人智慧的结晶,可以给大家很多启示和帮助。
笔者一直觉得如果能知道从应用到框架再到操作系统的每一处代码,是一件Exciting的事情。 今天笔者就来从Linux源码的角度看下Client端的Socket在进行Connect的时候到底做了哪些事情。由于篇幅原因,关于Server端的Accept源码讲解留给下一篇博客。 (基于Linux 3.10内核)
最近花了些时间在学习TCP/IP协议上,首要原因是由于本人长期以来对TCP/IP的认识就只限于三次握手四次分手上,所以希望深入了解一下。再者,TCP/IP和Linux系统层级的很多设计都可以用于中间件系统架构上,比如说TCP 拥塞控制算法也可以用于以响应时间来限流的中间件。更深一层,像TCP/IP协议这种基础知识和原理性的技术,都是经过长时间的考验的,都是前人智慧的结晶,可以给大家很多启示和帮助。
TCP协议是一个相当复杂的协议,其实现依赖于多个定时器的实现。在TCP套接字的初始化函数tcp_v4_init_sock中,会调用tcp_init_xmit_timers初始化TCP的各个定时器。
笔者一直觉得如果能知道从应用到框架再到操作系统的每一处代码,是一件Exciting的事情。 今天笔者就来从Linux源码的角度看下Client端的Socket在进行Connect的时候到底做了哪些事情。
这篇文章从nginx的499着手,分析整个过程中是怎么产生499行为的,以及各种往返网络包出现的原因。说说我通过这个499问题一步一步分析的整个过程,不一定正确,但很有意思。
而TCP所谓的“连接”,其实只不过是在通讯的双方维护一个“连接状态”,让它看上去好像有连接一样。所以,TCP的状态变换是非常重要的。
说到TCP协议,对于从事即时通讯/IM这方面应用的开发者们来说,再熟悉不过了。随着对TCP理解的越来越深入,很多曾今碰到过但没时间深入探究的TCP技术概念或疑问,现在是时候回头来恶补一下了。
前两天,我在微博上推荐了一篇朝花夕拾的文章:The story of one latency spike,文章中介绍了 cloudflare 工程师如何一步一步 debug 网络延迟问题,细细读来受益良多,不过我并不打算详细介绍那篇文章的细枝末节, 本文只摘录一个点:
日常Bug排查系列都是一些简单Bug排查,笔者将在这里介绍一些排查Bug的简单技巧,同时顺便积累素材^_^。
TCP是一个巨复杂的协议,因为他要解决很多问题,而这些问题又带出了很多子问题和阴暗面。所以学习TCP本身是个比较痛苦的过程,但对于学习的过程却能让人有很多收获。关于TCP这个协议的细节,我还是推荐你去看W.Richard Stevens的《TCP/IP 详解 卷1:协议》(当然,你也可以去读一下RFC793以及后面N多的RFC)。另外,本文我会使用英文术语,这样方便你通过这些英文关键词来查找相关的技术文档。 之所以想写这篇文章,目的有三个, 一个是想锻炼一下自己是否可以用简单的篇幅把这么复杂的TCP协议描清
1. rx-checksumming:校验接收报文的checksum。
前些日子,在分享网络编程知识文章的时候,有个网友私信给我留言了一条“能不能写一篇关于 TCP 滑动窗口原理的文章”。
而且,这个超时时间在不同的网络的情况下,根本没有办法设置一个死的值。只能动态地设置。 为了动态地设置,TCP引入了RTT——Round Trip Time,也就是一个数据包从发出去到回来的时间。这样发送端就大约知道需要多少的时间,从而可以方便地设置Timeout——RTO(Retransmission TimeOut),以让我们的重传机制更高效。 听起来似乎很简单,好像就是在发送端发包时记下t0,然后接收端再把这个ack回来时再记一个t1,于是RTT = t1 – t0。没那么简单,这只是一个采样,不能代表普遍情况。
刚才下班回家路上,无意中听到大街上放的歌,歌词有这么一句:“毡房外又有驼铃声声响起,我知道那一定不是你”。这一句我似乎听懂了歌者的魂牵梦绕和绝望,如果在十年前我大概只能感受出悠扬的声调里溢出的悲凉吧。
网络编程中经常会遇到一些异常的情况,定位问题需要了解协议栈的实现,以下是工作中遇到的一些常见问题的深入分析和解决思路。 问题1:server端业务进程响应心跳超时被监控进程kill,导致数据或者逻辑异常 我们的后台框架采用的是proxy,worker模型,proxy处理连接和会话,worker处理业务,proxy和worker之间通过共享内存队列进行通信,并有监控进程扫描proxy和worker的运行情况。管理进程会定时向worker发起心跳查询,防止业务进程挂起。业务worker的心跳默认是60s,如
对于云上的用户来说,业务日志里面报超时问题处理起来往往比价棘手,因为1) 问题点可能在云基础设施层,也有可能在业务软件层,需要排查的范围非常广;2) 这类问题往往是不可复现问题,抓到现场比较难。在本文里就分析下如何来分辨和排查这类问题的根本原因。
一、结论 提出这个问题说明对网络编程的一些基础原理未搞明白,先说下结论: 一个 socket 是否设置为阻塞模式,只会影响到 connect/accept/send/recv 等四个 socket API 函数,不会影响到 select/poll/epoll_wait 函数,后三个函数的超时或者阻塞时间是由其函数自身参数控制的。 二、原理分析 下面详细的解释,为了方便解释,在这之前我们先明确几个基础概念: connfd:创建 socket,主动发起连接的一端(客户端),该端调用 connect 函数主动发起
在设计架构或涉及网络时,我们都知道网络是不可靠的,可能会发生超时、断开连接、网络分区等各种问题。这些问题对于数据传输的可靠性和稳定性产生了很大的挑战。为了解决这些问题,各个组织都设立了专门的网络部门,致力于研究和解决网络问题。
提高Linux应对短连接的负载能力 在存在大量短连接的情况下,Linux的TCP栈一般都会生成大量的 TIME_WAIT 状态的socket。你可以用下面的命令看到: netstat -ant| grep -i time_wait 有时候,这个数目是惊人的: netstat -ant|grep -i time_wait |wc -l 可能会超过三四万。这个时候,我们需要修改 linux kernel 的 tcp time wait的时间,缩短之,有个 sysctl 参数貌似可以使用,它是 /proc/sy
这个属于 TCP 异常断开连接的场景,这部分内容在我的「图解网络」还没有详细介绍过,这次就乘着这次机会补一补。
这篇文章主要是从tcp连接建立的角度来分析客户端程序如何利用connect函数和服务端程序建立tcp连接的,了解connect函数在建立连接的过程中底层协议栈做了哪些事情。
主动断开连接 主动断开连接会发送,关闭事件 connec函数检测连接状态,getlasterror send发送(tcp keeplive心跳包或者有数据时检测),recv接收判断异常(无数据判断异常) linux中的 select(socket用户和内核传递数组,大小有限制) poll(同select大小无限制,链表维护) epoll(内核态数据) 拔网线 拔网线后,关闭事件不能传递,连接状态不好检测 设置连接或者发送超时,同步套接字超时设置 // platform-specific switch #i
前几天群里有个同学问,“如何让应用层强制发送RST中止连接”,而不是通过FIN包的四次交互来关闭连接。当时,我只是凭借以往的经验,猜测使用linger选项可以做到。之所以这么猜测,完全是出于对TCP和linger的理解。
如果您使用过Windows计划任务或Linux的crontab,那么对“定时任务”这个名词可能并不陌生。简言之就是在设定好的时间去执行一个任务或者根据条件循环的执行一个或多个任务。Linux下的crontab需要通过命令行操作,有了jiacrontab就可以通过WEB界面来创建计划任务,比直接使用crontab简单很多。
在后端接口性能指标中一类重要的指标就是接口耗时。具体包括平均响应时间 TP90、TP99 耗时值等。这些值越低越好,一般来说是几毫秒,或者是几十毫秒。如果响应时间一旦过长,比如超过了 1 秒,在用户侧就能感觉到非常明显的卡顿。如果长此以往,用户可能就直接用脚投票,卸载我们的 App 了。
本文是根据有赞中间件团队多年的TCP网络编程实践经验总结而来,目的是为了避免应用因各种网络异常而出现各种非预期行为,从而造成非预期的影响,影响系统稳定性与可靠性。
我本来只想写一个篇幅的文章的,但是TCP真TMD的复杂,比C++复杂多了,这30多年来,各种优化变种争论和修改。所以,写着写着就发现只有砍成两篇。
Nginx (engine x) 是一个高性能的HTTP和反向代理服务器,也是一个IMAP/POP3/SMTP服务器。
领取专属 10元无门槛券
手把手带您无忧上云