在《深入解析常见三次握手异常》 这一文中，我们讨论到如果发生连接队列溢出而丢包的话，会导致连接耗时会上涨很多。那如何判断一台服务器当前是否有半/全连接队列溢出丢包发生呢？
本期分享一个比较常见的⽹络问题--丢包。例如我们去ping⼀个⽹站，如果能ping通，且⽹站返回信息全⾯，则说明与⽹站服务器的通信是畅通的，如果ping不通，或者⽹站返回的信息不全等，则很可能是数据被丢包了，类似情况想必⼤家都不陌⽣。针对⽹络丢包，本⽂提供⼀些常见的丢包故障定位⽅法，希望能够帮助⼤家对⽹络丢包有更多的认识，遇到丢包莫要慌，且跟着⼀起来涨姿(知)势(识)···
基于「丢包反馈」的协议是一种 被动式 的拥塞控制机制，其依据网络中的 丢包事件 来做网络拥塞判断。即便网络中的负载很高时，只要没有产生拥塞丢包，协议就不会主动降低自己的发送速度。
在 Linux 系统下，丢包是一个较为常见的问题。由于丢包导致的网络问题可能会给用户带来不好的体验，因此解决 Linux 网络丢包问题是必不可少的。本文将介绍如何在 Linux 系统下进行网络丢包排查。
最近工作中遇到某个服务器应用程序 UDP 丢包，在排查过程中查阅了很多资料，我在排查过程中基本都是通过使用 tcpdump 在出现问题的各个环节上进行抓包、分析在那个环节出现问题、针对性去排查解决问题，对症下药，最后终究能够解决问题。但是这种情况大多是因为服务本身的问题，如果是环境问题、操作系统、甚至硬件的问题，可能从服务本身出发不能解决问题，但是这篇文章另辟蹊径，从外部环境分析可能丢包的原因，看完之后，很受用，部分章节对原文有所修改，下面分享出来供更多人参考。
最近工作中遇到某个服务器应用程序 UDP 丢包，在排查过程中查阅了很多资料，总结出来这篇文章，供更多人参考。
最近就有个读者加了我的绿皮聊天软件，女生，头像挺好看的，就在我以为她要我拉她进群发成人专升本广告的时候。
有很多新手朋友在买来服务器之后不知道自己的服务器到底好不好，有时候快有时候又慢得令人发指；或者刚买来的时候速度不错，用久了却越用越卡；又或者总是间歇性的抽风。
对于云上的用户来说，业务日志里面报超时问题处理起来往往比价棘手，因为1) 问题点可能在云基础设施层，也有可能在业务软件层，需要排查的范围非常广；2) 这类问题往往是不可复现问题，抓到现场比较难。在本文里就分析下如何来分辨和排查这类问题的根本原因。
运维过程中，最复杂的问题，莫过于网络的问题，而网络问题最烦的就是无法复现，这篇介绍一个强大的网络模拟工具Netem
收到研发反馈，TCP重传严重。主机报文重传是TCP最基本的错误恢复功能，它的目的是防止报文丢失
本文将引入一个思路：“在 Kubernetes 集群发生网络异常时如何排查”。文章将引入 Kubernetes 集群中网络排查的思路，包含网络异常模型，常用工具，并且提出一些案例以供学习。
Linux内核是高并发服务的关键组件之一。以下是一些可用于优化Linux内核的配置。
本节所涉及的概念有文件储结构（包括索引节点和目录项）、虚拟文件系统VFS、Linux I/O分类和磁盘的性能指标。涉及到的命令有stat、 df、iostat、 cat /proc/slabinfo、slabtop、pidstat和iotop。
网络数据传输：数据帧传输，由网卡读取并放入设备缓冲区ring buffer，当网络数据包到达的速率快于内核处理的速率时，ring buffer很快会被填满，新来的数据包将被丢弃。
在稳定性环境中，当 dble 初始化后端连接池后，后端连接池会出现连接计数器（totalConnections）和实际连接（allConnections）数量不符合的情况，理论情况下两个变量会保持最终一致性。
上面所有的这些网络指标都可以通过Linux的图形化的监控来获得， 这样就可以拿到实时的数据，帮助我们来分析对应的问题。我们使用的是开源的软件，性能也非常强大。
导语：本文分享了笔者现网遇到的一个文件下载慢的问题。最开始尝试过很多办法，包括域名解析，网络链路分析，AB环境测试，网络抓包等，但依然找不到原因。然后利用网络命令和报文得到的蛛丝马迹，结合内核网络协议栈的实现代码，找到了一个内核隐藏很久但在最近版本解决了的BUG。如果你也想了解如何分析和解决诡异的网络问题，如果你也想温习一下课堂上曾经学习过的慢启动、拥塞避免、快速重传、AIMD等老掉牙的知识，如果你也渴望学习课本上完全没介绍过的TCP的一系列优化比如混合慢启动、尾包探测甚至BBR等，那么本文或许可以给
在客户业务应用中,采用TCP协议的占据了绝大多数,这方面也有丰富的资料可以参考;但是在UDP协议方面,由于应用较少,相关的资料也很少.TCP的性能调优需要调整一系列参数,而决定UDP通信性能的因素于此截然不同.本文将通过实验给读者做验证.
一、CPU 良好状态指标 CPU利用率：User Time <= 70%，System Time <= 35%，User Time + System Time <= 70%。 上下文切换：与CPU利用
无论是软件开发人员，还是测试人员，亦或是运维人员，都需要掌握一些常用的基础网络知识，以用于日常网络问题的排查。这些基本的网络知识与概念，不仅日常工作会用到，跳槽时的笔试面试也会用到。本文结合多年来的工作实践，来详细讲述一下作为IT从业人员要掌握的一些基本网络知识。
udp 数据包的理论长度是多少，合适的 udp 数据包应该是多少呢？
Linux 网络协议栈是根据 TCP/IP 模型来实现的，TCP/IP 模型由应用层、传输层、网络层和网络接口层，共四层组成，每一层都有各自的职责。
Debug 网络质量的时候，我们一般会关注两个因素：延迟和吞吐量（带宽）。延迟比较好验证，Ping 一下或者 mtr[1] 一下就能看出来。这篇文章分享一个 debug 吞吐量的办法。
本文整理了在实践过程中使用的Linux网络工具，这些工具提供的功能非常强大，我们平时使用的只是冰山一角，比如、、、等。 本文不会深入研究这些命令的强大用法，因为每个命令都足以写一篇文章，本文只是简单地介绍并辅以几个简单demo实例，旨在大脑中留个印象，平时遇到问题时能够快速搜索出这些工具，利用强大的工具，提供一定的思路解决问题。 ping 使用这个命令判断网络的连通性以及网速，偶尔还顺带当做域名解析使用（查看域名的IP）： ping google.com 默认使用该命令会一直发送ICMP包直到用户手动中止，
图片下载走的 k8s ingress，这个 ingress 路径对应后端 service 是一个代理静态图片文件的 nginx deployment，这个 deployment 只有一个副本，静态文件存储在 nfs 上，nginx 通过挂载 nfs 来读取静态文件来提供图片下载服务，所以调用链是：client --> k8s ingress --> nginx --> nfs。
Ping是Linux系统常用的网络命令，它通常用来测试与目标主机的连通性，我们经常会说“ping一下某机器，看是不是开着。它是通过发送ICMP ECHO_REQUEST数据包到网络主机，并显示响应情况，这样我们就可以根据它输出的信息来确定目标主机是否可访问（但这不是绝对的）。
今天线上业务出现了大量语音合成问题,本以为是服务出问题,但是经过排查发现服务一切正常就是合成的特别慢,在TTS语音合成服务那边也没有大量的任务堆积,这边也一直再发送需要合成的数据过去,这种情况只能说明在传输需要合成的语句的时候出现了问题,这时候第一个排查的就是网络问题,可能是网络大量丢包造成的数据传输问题,于是开始使用ping命令查看,发现确实有丢包,但是通过ping又没有办法发现是哪个地方丢包,这个时候聪明的你肯定想到我们用traceroute命令来检测数据包传输到哪个地方不传了,但是我发现这个并不能说明什么,因为丢包不是完全丢,而是丢一部分,这个时候想有没有一个命令是ping和traceroute的合体,于是google了一下,发现mtr刚好满足我的需求,于是使用记录并分享.
（图片说明：TCP 是以太网协议和 IP 协议的上层协议，也是应用层协议的下层协议。）
如果你的Linux服务器突然负载暴增，告警短信快发爆你的手机，如何在最短时间内找出Linux性能问题所在？
开始我怀疑PHP有问题，但是通过查询Nginx的access日志，发现里面记录的PHP响应时间「$upstream_response_time」非常小，此外还通过Strace命令仔细核对了是否存在耗时的操作，结果一无所获，所以基本排除了PHP的嫌疑。
BBR对TCP性能的提升是巨大的，它能更有效的使用当下网络环境，Youtube应用后在吞吐量上有平均4%提升（对于日本这样的网络环境有14%以上的提升）：
本文章来自我的微信个人技术公众号---网络技术修炼，公众号中总结普及网络基础知识，包括基础原理、网络方案、开发经验和问题定位案例等，欢迎关注。
工具：htop, net-tools, ping, iperf, UnixBench 等
wget http://fossies.org/linux/privat/iperf-3.1.3.tar.xz
【统计->捕获文件属性】 Statistics -> Summary，查看文件属性信息，如平均速度、包大小、包数等等
本文介绍了在技术社区中如何从各个维度来评估和监控系统的性能，并通过实例介绍了常见的性能监控指标和工具。
对于基于互联网的通信应用（比如IM聊天、推送系统），数据传递时使用TCP协议相对较多。这是因为在TCP/IP协议簇的传输层协议中，TCP协议具备可靠的连接、错误重传、拥塞控制等优点，所以目前在应用场景上比UDP更广泛一些。
近期，掘金发出技术专题的邀约，我也是紧跟潮流，写了一篇关于网络协议的性能优化与性能评估的文章，本篇文章主要讲了三个大方向包括：网络协议的性能指标、性能优化策略、性能评估方法；并针对这三个方面进行深入的分析，希望与大家一起交流分享。
这是TCP/IP协议栈系列的第二篇文章，之前的一篇理解TCP/IP协议栈之HTTP2.0感兴趣可以看下，今天一起来学习下一个热点问题。
本文主要探讨了在网络游戏领域，从客户端到服务器的网络延迟对于玩家游戏体验的影响。针对MOBA、FPS、MMORPG等多种类型的游戏，分析了在弱网环境下，TCP协议和UDP协议的加速方案。最后，文章介绍了腾讯云智营网优产品，提供了免费试用入口。
直接改iptables配置就可以了：vim /etc/sysconfig/iptables。
uname命令用于打印当前系统相关信息（内核版本号、硬件架构、主机名称和操作系统类型等）。
TCP是一个有状态通讯协议，所谓的有状态是指通信过程中通信的双方各自维护连接的状态。
在互联网后端日常开发接口的时候中，不管你使用的是C、Java、PHP还是Golang，都避免不了需要调用mysql、redis等组件来获取数据，可能还需要执行一些rpc远程调用，或者再调用一些其它restful api。 在这些调用的底层，基本都是在使用TCP协议进行传输。这是因为在传输层协议中，TCP协议具备可靠的连接，错误重传，拥塞控制等优点，所以目前应用比UDP更广泛一些。 相信你也一定听闻过TCP也存在一些缺点，那就是老生常谈的开销要略大。但是各路技术博客里都在单单说开销大、或者开销小，而少见不给出具体的量化分析。不客气一点，这都是营养不大的废话。经过日常工作的思考之后，我更想弄明白的是，开销到底多大。一条TCP连接的建立需要耗时延迟多少，是多少毫秒，还是多少微秒？能不能有一个哪怕是粗略的量化估计？当然影响TCP耗时的因素有很多，比如网络丢包等等。我今天只分享我在工作实践中遇到的比较高发的各种情况。
导言｜nettrace工具自上线以来，受到了业界的广泛关注。特别是复杂的云原生网络环境中，nettrace 工具通过报文跟踪、网络诊断的方式为用户解决了多次疑难网络问题。今天就以OpenCloudOS为例，介绍在云原生场景中nettrace如何快速进行网络故障诊断。 工具简介 1）背景 在一些场景下（特别是云原生场景），Linux 系统中的网络部署变得越来越复杂。一个 TCP 连接，从客户端到服务端，中间可能要经过复杂的 NAT、GRE、IPVS 等过程，网络报文在节点（主机）上的处理路径也变得越来越长
作者：engleliu，腾讯 PCG 开发工程师 本文主要介绍 TCP 拥塞控制算法，内容多来自网上各个大佬的博客及《TCP/IP 详解》一书，在此基础上进行梳理总结，与大家分享。因水平有限，内容多有不足之处， 敬请谅解。 一、TCP 首部格式 在了解 TCP 的拥塞控制之前，先来看看 TCP 的首部格式和一些基本概念。 TCP 头部标准长度是 20 字节。包含源端口、目的端口、序列号、确认号、数据偏移、保留位、控制位、窗口大小、校验和、紧急指针、选项等。 TCP 首部格式 1.1 数据偏移（D
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
云直播
