网络编程中超时时间是一个重要但又容易被忽略的问题,对其的设置需要仔细斟酌。在经历了数次物理机宕机之后,笔者详细的考察了在网络编程(tcp)中的各种超时设置，于是就有了本篇博文。本文大部分讨论的是socket设置为block的情况,即setNonblock(false)，仅在最后提及了nonblock socket(本文基于linux 2.6.32-431内核)。
在后端接口性能指标中一类重要的指标就是接口耗时。具体包括平均响应时间 TP90、TP99 耗时值等。这些值越低越好，一般来说是几毫秒，或者是几十毫秒。如果响应时间一旦过长，比如超过了 1 秒，在用户侧就能感觉到非常明显的卡顿。如果长此以往，用户可能就直接用脚投票，卸载我们的 App 了。
TCP重传机制主要是为了防止网路包丢弃，重传的工作方式主要借助TCP头部中的序列号和确认号来决定是否重传，重传的触发方式主要由以下几种：
Linux作为一个强大的操作系统，提供了一系列内核参数供我们进行调优。光TCP的调优参数就有50多个。在和线上问题斗智斗勇的过程中，笔者积累了一些在内网环境应该进行调优的参数。在此分享出来，希望对大家有所帮助。
收到一位读者的私信，说字节面试有这么一个问题：服务端挂了，客户端的 TCP 连接会发生什么？
机器一般过质保之后，就会因为各种各样的问题而宕机。而这一次的宕机，让笔者观察到了平常观察不到的tcp在对端宕机情况下的行为。经过详细跟踪分析原因之后，发现可以通过调整内核tcp参数来减少宕机造成的影响。
** 若TIME_WAIT事件设置过短, 会导致错误后果 TIME_WAIT结束过早, 导致之前迷失的第三次握手突然到达, 新连接突然成功
今天我们来玩一下ChaosMesh模拟网络duplicate包的情况。同时也要看一下对应用产生的直接影响。
对于TCP的初始接收窗口大小，linux和centos的实现是不一样的，如linux内核3.10版本的初始接收窗口定义为10mss，但centos 3.10内核中的初始窗口大小定义为TCP_INIT_CWND * 2，即20*MSS大小。(看着linux源码在centos7.4系统上测试，纠结了好久。。)
前两天，我在微博上推荐了一篇朝花夕拾的文章：The story of one latency spike，文章中介绍了 cloudflare 工程师如何一步一步 debug 网络延迟问题，细细读来受益良多，不过我并不打算详细介绍那篇文章的细枝末节， 本文只摘录一个点：
ARQ:自动重传请求(Automatic Repeat-reQuest,ARQ)是OSI模型中数据链路层的错误纠正协议之一. RTO:Retransmission TimeOut FEC:Forward Error Correction
TCP是一个巨复杂的协议，因为他要解决很多问题，而这些问题又带出了很多子问题和阴暗面。所以学习TCP本身是个比较痛苦的过程，但对于学习的过程却能让人有很多收获。关于TCP这个协议的细节，我还是推荐你去看W.Richard Stevens的《TCP/IP 详解 卷1：协议》（当然，你也可以去读一下RFC793以及后面N多的RFC）。另外，本文我会使用英文术语，这样方便你通过这些英文关键词来查找相关的技术文档。 之所以想写这篇文章，目的有三个， 一个是想锻炼一下自己是否可以用简单的篇幅把这么复杂的TCP协议描清
而且，这个超时时间在不同的网络的情况下，根本没有办法设置一个死的值。只能动态地设置。 为了动态地设置，TCP引入了RTT——Round Trip Time，也就是一个数据包从发出去到回来的时间。这样发送端就大约知道需要多少的时间，从而可以方便地设置Timeout——RTO（Retransmission TimeOut），以让我们的重传机制更高效。 听起来似乎很简单，好像就是在发送端发包时记下t0，然后接收端再把这个ack回来时再记一个t1，于是RTT = t1 – t0。没那么简单，这只是一个采样，不能代表普遍情况。
作者：engleliu，腾讯 PCG 开发工程师 本文主要介绍 TCP 拥塞控制算法，内容多来自网上各个大佬的博客及《TCP/IP 详解》一书，在此基础上进行梳理总结，与大家分享。因水平有限，内容多有不足之处， 敬请谅解。 一、TCP 首部格式 在了解 TCP 的拥塞控制之前，先来看看 TCP 的首部格式和一些基本概念。 TCP 头部标准长度是 20 字节。包含源端口、目的端口、序列号、确认号、数据偏移、保留位、控制位、窗口大小、校验和、紧急指针、选项等。 TCP 首部格式 1.1 数据偏移（D
TCP协议是一个相当复杂的协议，其实现依赖于多个定时器的实现。在TCP套接字的初始化函数tcp_v4_init_sock中，会调用tcp_init_xmit_timers初始化TCP的各个定时器。
欢迎去gitbook（https://legacy.gitbook.com/@rogerzhu/）看到完整版。 如果对和程序员有关的计算机网络知识，和对计算机网络方面的编程有兴趣，虽然说现在这种“看不见”的东西真正能在实用中遇到的机会不多，但是我始终觉得无论计算机的语言，热点方向怎么变化，作为一个程序员，很多基本的知识都应该有所了解。而当时在网上搜索资料的时候，这方面的资料真的是少的可怜，所以，我有幸前两年接触了这方面的知识，我觉得我应该把我知道的记录下来，虽然写的不一定很好，但是希望能给需要帮助的人多个参
之前我在「实战！我用“大白鲨”让你看见 TCP」这篇文章里做了 TCP 三次握手的三个实验：
本文主要介绍了在Linux系统中，如何通过配置TCP参数来优化网络性能。主要包括了TCP的四次挥手释放连接、TCP的慢启动和快速恢复、TCP的保活机制以及TCP的延迟应答机制等方面的内容。通过这些优化措施，可以大大提高Linux网络性能，减少网络拥堵和丢包现象，提高整体的网络吞吐量和连接的稳定性。
Linux内核net/socket.c定义了一套socket的操作api。图1展示了socket层所处与TCP/IP协议栈之上和应用层之下。
上述表述的信息还是比较少的，我们在linux服务器上抓取的包一般会保存为pcap文件，然后导出到本地利用WireShark工具进行分析。
执行主动关闭的那端经历了这个状态，并停留MSL（最长分节生命期）的2倍，即2MSL。
openGauss闪回功能能够有选择性的高效撤销一个已提交事务的影响，从人为错误中恢复。在采用闪回技术之前，只能通过备份恢复、PITR等手段找回已提交的数据库修改，恢复时长需要数分钟甚至数小时。采用闪回技术后，恢复已提交的数据库修改前的数据，只需要秒级，而且恢复时间和数据库大小无关。适用于：
转载自： http://blog.sina.com.cn/s/blog_781b0c850100znjd.html
前言 说到TCP协议，相信大家都比较熟悉了，对于TCP协议总能说个一二三来，但是TCP协议又是一个非常复杂的协议，其中有不少细节点让人头疼点。本文就是来说说这些头疼点的，浅谈一些TCP的疑难杂症。那么从哪说起呢？当然是从三次握手和四次挥手说起啦，可能大家都知道TCP是三次交互完成连接的建立，四次交互来断开一个连接，那为什么是三次握手和四次挥手呢？反过来不行吗？ 疑症 1 ：TCP 的三次握手、四次挥手 下面两图大家再熟悉不过了，TCP的三次握手和四次挥手见下面左边的”TCP建立连接”、”TCP数据传送
作者：morganhuang，腾讯 IEG 后台开发工程师 说到 TCP 协议，相信大家都比较熟悉了，对于 TCP 协议总能说个一二三来，但是 TCP 协议又是一个非常复杂的协议，其中有不少细节点让人头疼点。本文就是来说说这些头疼点的，浅谈一些 TCP 的疑难杂症。那么从哪说起呢？当然是从三次握手和四次挥手说起啦，可能大家都知道 TCP 是三次交互完成连接的建立，四次交互来断开一个连接，那为什么是三次握手和四次挥手呢？反过来不行吗？ 疑症（1）TCP 的三次握手、四次挥手 下面两图大家再熟悉不过了，
硬件设备及镜像 主板为：Yuzuki Lizard V851S开发板 宿主机环境：ubuntu 22.04 SDK版本：Yuzukilizard的github上的Docker镜像 img为：github上Yuzukilizard释放的镜像：[01]v851s_linux_lizard_uart0_2022_12_29.img v851s_linux_lizard_uart0_2022_12_29.img
我们想要在GUI界面内展示simulink模型的运行状态，可以通过给模型中特定模块绑定监听事件，当模块发生特定事件后调用我们绑定的函数，在函数当中获取模型中的其他参数值
之前文章《Linux服务器性能评估与优化(一)》太长，阅读不方便，因此拆分成系列博文：
MySQL5.7 默认参数下我们开启了半同步，在一个事务提交（commit） 的过程时，在 MySQL 层的 write binlog 步骤后，Master 节点需要收到至少一个 Slave 节点回复的 ACK （表示收到了binlog ）后，才能继续下一个事务；
导语：本文分享了笔者现网遇到的一个文件下载慢的问题。最开始尝试过很多办法，包括域名解析，网络链路分析，AB环境测试，网络抓包等，但依然找不到原因。然后利用网络命令和报文得到的蛛丝马迹，结合内核网络协议栈的实现代码，找到了一个内核隐藏很久但在最近版本解决了的BUG。如果你也想了解如何分析和解决诡异的网络问题，如果你也想温习一下课堂上曾经学习过的慢启动、拥塞避免、快速重传、AIMD等老掉牙的知识，如果你也渴望学习课本上完全没介绍过的TCP的一系列优化比如混合慢启动、尾包探测甚至BBR等，那么本文或许可以给
最近花了些时间在学习TCP/IP协议上，首要原因是由于本人长期以来对TCP/IP的认识就只限于三次握手四次分手上，所以希望深入了解一下。再者，TCP/IP和Linux系统层级的很多设计都可以用于中间件系统架构上，比如说TCP 拥塞控制算法也可以用在以响应时间来限流的中间件上。更深一层，像TCP/IP协议这种基础知识和原理性的技术，都是经过长时间的考验的，都是前人智慧的结晶，可以给大家很多启示和帮助。
packetdrill 是一个跨平台的脚本工具，可以用来测试整个 TCP/UDP/IP 网络栈实现的正确性和性能，从系统调用一直到硬件网络接口，从 IPv4 到 IPv6。
笔者一直觉得如果能知道从应用到框架再到操作系统的每一处代码，是一件Exciting的事情。 今天笔者就来从Linux源码的角度看下Server端的Socket在进行listen的时候到底做了哪些事情(基于Linux 3.10内核)，当然由于listen的backlog参数和半连接hash表以及全连接队列都相关，在这一篇博客里也一块讲了。
在嵌入式linux上移植LCD（这里指彩色点阵式LCD）的驱动，通常说来，并不是很困难的事。最简单的方法，就是找到linux中，现有的LCD驱动的参数设置的代码，直接修改参数即可。复杂点的方法，就要添加LCD驱动相关的结构体，设备描述，等。但不管怎么样，LCD的参数设置是最终肯定要面对的问题。1075083208
QMQ（Qunar Message Queue）诞生于去哪儿网，初版基于MySQL存储。随着集团业务系统越发倚重消息解耦上下游，业务量的上涨随之带来消息量的增长，MySQL作为存储的瓶颈也越发明显。
本文是根据有赞中间件团队多年的TCP网络编程实践经验总结而来，目的是为了避免应用因各种网络异常而出现各种非预期行为，从而造成非预期的影响，影响系统稳定性与可靠性。
对于云上的用户来说，业务日志里面报超时问题处理起来往往比价棘手，因为1) 问题点可能在云基础设施层，也有可能在业务软件层，需要排查的范围非常广；2) 这类问题往往是不可复现问题，抓到现场比较难。在本文里就分析下如何来分辨和排查这类问题的根本原因。
MySQL发展至今，在高可用性方面不断前进，从最初的异步复制、半同步复制、群组复制，演进到现在的InnoDB Cluster和InnoDB Replica Set。在这一篇里将说明各种高可用架构以及其适用的场景。
1 . Android 版本目录 : platforms 中存储了各个 Android 版本编译时需要的动态库与静态库资源 , 如 android-29 中就是该版本对应的本地库资源 ;
MySQL发展至今，在高可用性方面不断前进，从最初的异步复制、半同步复制、群组复制，演进到现在的InnoDB Cluster和InnoDB Replica Set。本文将说明各种高可用架构以及适用场景。
这篇文章我想由浅到深地过一遍 TCP，不是生硬的搬出各个知识点，从问题入手，然后从发展、演进的角度来看 TCP。
前一篇「硬不硬你说了算！近 40 张图解被问千百遍的 TCP 三次握手和四次挥手面试题」得到了很多读者的认可，在此特别感谢你们的认可，大家都暖暖的。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
