之前我在「实战!我用“大白鲨”让你看见 TCP」这篇文章里做了 TCP 三次握手的三个实验:
为了让大家更容易「看得见」 TCP,我搭建不少测试环境,并且数据包抓很多次,花费了不少时间,才抓到比较容易分析的数据包。
TCP协议是一个相当复杂的协议,其实现依赖于多个定时器的实现。在TCP套接字的初始化函数tcp_v4_init_sock中,会调用tcp_init_xmit_timers初始化TCP的各个定时器。
使用wrk模拟http压力打nginx时,发现压测过程中持续出现重传现象,而且在高压下和低压下都会出现不同程度的重传。
机器一般过质保之后,就会因为各种各样的问题而宕机。而这一次的宕机,让笔者观察到了平常观察不到的tcp在对端宕机情况下的行为。经过详细跟踪分析原因之后,发现可以通过调整内核tcp参数来减少宕机造成的影响。
说到TCP协议,对于从事即时通讯/IM这方面应用的开发者们来说,再熟悉不过了。随着对TCP理解的越来越深入,很多曾今碰到过但没时间深入探究的TCP技术概念或疑问,现在是时候回头来恶补一下了。
上述表述的信息还是比较少的,我们在linux服务器上抓取的包一般会保存为pcap文件,然后导出到本地利用WireShark工具进行分析。
这一下,大家总算停止了灌水(这群人都不用上班的,天天划水摸鱼),开始讨论起这个问题来。
前些日子,在分享网络编程知识文章的时候,有个网友私信给我留言了一条“能不能写一篇关于 TCP 滑动窗口原理的文章”。
收到研发反馈,TCP重传严重。主机报文重传是TCP最基本的错误恢复功能,它的目的是防止报文丢失
今天我们来玩一下ChaosMesh模拟网络duplicate包的情况。同时也要看一下对应用产生的直接影响。
在后端接口性能指标中一类重要的指标就是接口耗时。具体包括平均响应时间 TP90、TP99 耗时值等。这些值越低越好,一般来说是几毫秒,或者是几十毫秒。如果响应时间一旦过长,比如超过了 1 秒,在用户侧就能感觉到非常明显的卡顿。如果长此以往,用户可能就直接用脚投票,卸载我们的 App 了。
【统计->捕获文件属性】 Statistics -> Summary,查看文件属性信息,如平均速度、包大小、包数等等
对于云上的用户来说,业务日志里面报超时问题处理起来往往比价棘手,因为1) 问题点可能在云基础设施层,也有可能在业务软件层,需要排查的范围非常广;2) 这类问题往往是不可复现问题,抓到现场比较难。在本文里就分析下如何来分辨和排查这类问题的根本原因。
在稳定性环境中,当 dble 初始化后端连接池后,后端连接池会出现连接计数器(totalConnections)和实际连接(allConnections)数量不符合的情况,理论情况下两个变量会保持最终一致性。
很简单呀,因为我做了实验和看了 TCP 协议栈的内核源码,发现要增大这两个队列长度,不是简简单单增大某一个参数就可以的。
这篇文章我想由浅到深地过一遍 TCP,不是生硬的搬出各个知识点,从问题入手,然后从发展、演进的角度来看 TCP。
TCP重传机制主要是为了防止网路包丢弃,重传的工作方式主要借助TCP头部中的序列号和确认号来决定是否重传,重传的触发方式主要由以下几种:
TCP协议仅定义框架,也就是发送端和接收端需要遵循的“规则”。TCP协议的实现经过多年的改进,有了多个不同的版本。比较重要的有Tahoe、Reno、NewReno、SACK、Vegas等,有些已经成为了影响广泛的RFC文档,有些则成为了Unix/Linux操作系统的标准选项。
收到一位读者的私信,说字节面试有这么一个问题:服务端挂了,客户端的 TCP 连接会发生什么?
TCP是一个巨复杂的协议,因为他要解决很多问题,而这些问题又带出了很多子问题和阴暗面。所以学习TCP本身是个比较痛苦的过程,但对于学习的过程却能让人有很多收获。关于TCP这个协议的细节,我还是推荐你去看W.Richard Stevens的《TCP/IP 详解 卷1:协议》(当然,你也可以去读一下RFC793以及后面N多的RFC)。另外,本文我会使用英文术语,这样方便你通过这些英文关键词来查找相关的技术文档。 之所以想写这篇文章,目的有三个, 一个是想锻炼一下自己是否可以用简单的篇幅把这么复杂的TCP协议描清
导语:本文分享了笔者现网遇到的一个文件下载慢的问题。最开始尝试过很多办法,包括域名解析,网络链路分析,AB环境测试,网络抓包等,但依然找不到原因。然后利用网络命令和报文得到的蛛丝马迹,结合内核网络协议栈的实现代码,找到了一个内核隐藏很久但在最近版本解决了的BUG。如果你也想了解如何分析和解决诡异的网络问题,如果你也想温习一下课堂上曾经学习过的慢启动、拥塞避免、快速重传、AIMD等老掉牙的知识,如果你也渴望学习课本上完全没介绍过的TCP的一系列优化比如混合慢启动、尾包探测甚至BBR等,那么本文或许可以给
在设计架构或涉及网络时,我们都知道网络是不可靠的,可能会发生超时、断开连接、网络分区等各种问题。这些问题对于数据传输的可靠性和稳定性产生了很大的挑战。为了解决这些问题,各个组织都设立了专门的网络部门,致力于研究和解决网络问题。
TCP作为一种可靠传输控制协议,其核心思想既要保证数据可靠传输,又要提高传输的效率,而用三次恰恰可以满足以上两方面的需求!
本文主要分析为什么TIME_WAIT状态的持续时间是2MSL而不是1MSL,3MSL或其它的时长,而不会详细描述为什么需要TIME_WAIT状态。
本文主要分析为什么 TIME_WAIT 状态的持续时间是 2MSL 而不是 1MSL,3MSL 或其它的时长,而不会详细描述为什么需要 TIME_WAIT 状态。阅读本文需要的预备知识:
而且,这个超时时间在不同的网络的情况下,根本没有办法设置一个死的值。只能动态地设置。 为了动态地设置,TCP引入了RTT——Round Trip Time,也就是一个数据包从发出去到回来的时间。这样发送端就大约知道需要多少的时间,从而可以方便地设置Timeout——RTO(Retransmission TimeOut),以让我们的重传机制更高效。 听起来似乎很简单,好像就是在发送端发包时记下t0,然后接收端再把这个ack回来时再记一个t1,于是RTT = t1 – t0。没那么简单,这只是一个采样,不能代表普遍情况。
1.上行吞吐量测试方法 手机作为client端,PC为server端 2.下行吞吐量测试方法 手机作为server端,PC作为client端
我本来只想写一个篇幅的文章的,但是TCP真TMD的复杂,比C++复杂多了,这30多年来,各种优化变种争论和修改。所以,写着写着就发现只有砍成两篇。
当客户端想和服务端建立 TCP 连接的时候,首先第一个发的就是 SYN 报文,然后进入到 SYN_SENT 状态。
在云函数的日常运营中,经常有用户提出要求协助排查网络问题。一般的手段就是使用 tcpdump 抓包,但是部署抓包往往是在问题发生之后,而且抓包后复现的时机也不确定,往往费时费力。本文讲述使用 BPF 记录 TCP 的重传和丢包记录,作为定位网络问题的一种辅助手段。
最近花了些时间在学习TCP/IP协议上,首要原因是由于本人长期以来对TCP/IP的认识就只限于三次握手四次分手上,所以希望深入了解一下。再者,TCP/IP和Linux系统层级的很多设计都可以用于中间件系统架构上,比如说TCP 拥塞控制算法也可以用于以响应时间来限流的中间件。更深一层,像TCP/IP协议这种基础知识和原理性的技术,都是经过长时间的考验的,都是前人智慧的结晶,可以给大家很多启示和帮助。
strace -p 28182 -s4086 -T -f [-e trace=network/process/signal]
可以看到,这些问题都是关于 TCP 是如何处理这些异常场景的,我们在学 TCP 连接建立和断开的时候,总是以为这些过程能如期完成。
最近花了些时间在学习TCP/IP协议上,首要原因是由于本人长期以来对TCP/IP的认识就只限于三次握手四次分手上,所以希望深入了解一下。再者,TCP/IP和Linux系统层级的很多设计都可以用于中间件系统架构上,比如说TCP 拥塞控制算法也可以用在以响应时间来限流的中间件上。更深一层,像TCP/IP协议这种基础知识和原理性的技术,都是经过长时间的考验的,都是前人智慧的结晶,可以给大家很多启示和帮助。
前两天,我在微博上推荐了一篇朝花夕拾的文章:The story of one latency spike,文章中介绍了 cloudflare 工程师如何一步一步 debug 网络延迟问题,细细读来受益良多,不过我并不打算详细介绍那篇文章的细枝末节, 本文只摘录一个点:
前两天看到一群里在讨论 Tomcat 参数调优,看到不止一个人说通过 accept-count 来配置线程池大小,我笑了笑,看来其实很多人并不太了解我们用的最多的 WebServer Tomcat,这篇文章就来聊下 Tomcat 调优,重点介绍下线程池调优及 TCP 半连接、全连接队列调优。
Linux TCP 协议栈具有无数个可以更改其行为的 sysctl 旋钮。 这包括可用于接收或发送操作的内存量、套接字的最大数量、可选的特性和协议扩展。
滑动窗口本质上是描述接受方的TCP数据报缓冲区大小的数据,发送方根据这个数据来计算自己最多能发送多长的数据。如果发送方收到接受方的窗口大小为0的TCP数据报,那么发送方将停止发送数据,等到接受方发送窗口大小不为0的数据报的到来。 关于滑动窗口协议,还有三个术语,分别是: 窗口合拢:当窗口从左边向右边靠近的时候,这种现象发生在数据被发送和确认的时候。 窗口张开:当窗口的右边沿向右边移动的时候,这种现象发生在接受端处理了数据以后。 窗口收缩:当窗口的右边沿向左边移动的时候,这种现象不常发生。
作者:engleliu,腾讯 PCG 开发工程师 本文主要介绍 TCP 拥塞控制算法,内容多来自网上各个大佬的博客及《TCP/IP 详解》一书,在此基础上进行梳理总结,与大家分享。因水平有限,内容多有不足之处, 敬请谅解。 一、TCP 首部格式 在了解 TCP 的拥塞控制之前,先来看看 TCP 的首部格式和一些基本概念。 TCP 头部标准长度是 20 字节。包含源端口、目的端口、序列号、确认号、数据偏移、保留位、控制位、窗口大小、校验和、紧急指针、选项等。 TCP 首部格式 1.1 数据偏移(D
我第一次写 TCP 文章是这篇:硬不硬你说了算!近 40 张图解被问千百遍的 TCP 三次握手和四次挥手面试题
TCP是一个面向连接的协议。无论哪一方向另一方发送数据之前,都必须先在双方之间建立一条连接。
TCP/IP深入学习 作为互联网时代伟大发明的TCP/IP技术可以说对当今时代产生了深刻的影响。经过近一个月的学习摸索,基本清楚了TCP/IP的面貌。由于TCP/IP在OS中位于内核态,很多细节其实用
领取专属 10元无门槛券
手把手带您无忧上云