问题背景网络路径不一致，或者说是网络路径来回不一致，再专业点可以说是网络路径不对称，以上种种说法，做网络方向的工程师肯定会更清楚些，用简单的描述就是：A 与 B 通讯场景，C 和 D 代表中间路径可能存在的 N 个不同设备 A -> B 方向经过了这样的路径，A — C — B B -> A 方向经过了这样的路径，B — D — A以上网络场景实际挺常见的，正常通讯没有任何问题。开篇明
转载
2024-09-19 12:49:23
245阅读
TCP是基于不可靠的网络实现可靠的传输，肯定也会存在掉包的情况，如果通信中发现缺少数据或者丢包，那么，最大的可能在于程序发送的过程或者接收的过程出现问题。 例如服务端要给客户端发送大量数据，Send频率很高，那么就很有可能在Send环节出现错误（1.程序处理逻辑错误，2.多线程同
转载
2024-04-21 17:19:08
539阅读
TODO: 此篇比较杂乱, 待整理 !!!术语解释解决网络问题的思路流控理论网络性能问题拥塞重传RTO: 丢包的 Retransmission Timeout 被触发 -> 进入超时重传阶段超时重传快速重传选择重传: SACk延迟确认: Delayed ACK来自: <<一篇关于Vmware的文章>> , <<来点有深度的>>含义: 当需要发送
转载
2024-03-21 22:52:00
56阅读
概述： 在平时的运维过程中，我们经常会遇到一些数据传输的问题，在我们平时遇到的数据传输问题中定位难度从难到易基本为：数据传输慢不符合预期、数据传输过程有丢包、数据传输被终止或网络断开连接。 如果要对数据流分析抓包是最直接的办法，它可以帮助你更快的定位问题。最常用的抓包工具：wireshark（w
转载
2024-03-28 21:55:29
345阅读
今天使用wireshark来分析一下tcp的一些原理。首先我们建立一个tcp服务器。const net = require('net');
net.createServer().listen(11111);再建立一个tcp客户端。const net = require('net');
net.connect({port: 11111, host: '192.168.8.226'})我们逐个情况分析
转载
2024-07-03 06:01:06
722阅读
流媒体播放中，常常需要借助wireshark从TCP层面对交互过程进行分析，本文记录一些常见的TCP异常报文及其分析。乱序与丢包1、[TCP Previous segment not captured] [TCP Previous segment not captured]报文指的是在TCP发送端传输过程中，该Seq前的报文缺失了。一般在网络拥塞的情况下，造成TCP报文乱序、丢包时，会出现该标志。
转载
2024-05-07 11:48:51
491阅读
第二次握手：服务端返回一个ACK(对客户端连接请求的应答)+SYN(表示服务端发起连接请求)，并且包含服务端的一个初始序列号seq=0，同时返回一个确认号ack=1第三次握手：客户端给服务端返回一个ACK(对服务端连接请求的应答)，并更新自己的序列号seq=1，返回一个确认号ack=1Wireshark分析握手过程这是我发起连接请求后抓到的数据包第一次握手：可以看到，客户端发起一个SYN请求，初始
问题背景首先，案例来自于互联网，数据包分析过程相对简单，但对个人来说，算是之前没实际碰到的情况，因此分享一下。 问题描述当第一次查看数据包文件时，一眼就能看到 “Bad TCP” 的鲜艳着色，这说明或多或少存在着问题。 打开分析-专家信息： 看到了 Previous segment not captured，可能都知道发生丢包了，99.99%的情况下包丢失发生在互连设备上，有可能是设备过载，也有可
转载
2024-02-23 19:06:27
933阅读
TCP协议有两个比较重要的控制算法，一个是流量控制，另一个就是阻塞控制(详见学习笔记-TCP拥塞控制)。为什么需要流量控制双方在通信的时候，发送方的速率与接收方的速率是不一定相等，如果发送方的发送速率太快，会导致接收方处理不过来，这时候接收方只能把处理不过来的数据存在缓存区里(失序的数据包也会被存放在缓存区里)。如果缓存区满了发送方还在疯狂着发送数据，接收方只能把收到的数据包丢掉，大量的丢包会极大
1、引言 传输控制协议（TransportControlProtocol，TCP）是目前Internet中广泛采用的一种传输协议，它为各个主机之间提供可靠、按序传输、端到端的数据包传输服务。TCP拥塞控制是其成功的重要因素。TCP拥塞控制的前提是网络拥塞为数据丢失的唯一原因，即只要终端检测出有数据丢失，均认为是网络拥塞所致，于是调用拥塞
《网络排查案例课》01 | 网络模型和工具：网络为什么要分层？七层模型；四层 / 五层模型；五元组；四元组
===============================================
OSI 的七层模型，和 TCP/IP 的四层 / 五层模型
五元组：传输协议类型、源 IP、源端口、目的 IP、目的端口
四元组：源 IP、源端口、目的 IP、目的端口七层模型；四层 / 五层模型
转载
2024-09-11 22:27:49
312阅读
wireshark是非常流行的网络封包分析软件，功能十分强大。可以截取各种网络封包，显示网络封包的详细信息。使用wireshark的人必须了解网络协议，否则就看不懂wireshark了。为了安全考虑，wireshark只能查看封包，而不能修改封包的内容，或者发送封包。wireshark能获取HTTP，也能获取HTTPS，但是不能解密HTTPS，所以wireshark看不懂HTTPS中的内容，
关于TCP三次握手和四次挥手大家都在《计算机网络》课程里学过，还记得当时高超老师耐心地讲解。大学里我遇到的最好的老师大概就是这位了，虽然他只给我讲过《java程序设计》和《计算机网络》，但每次课几乎都动手敲代码或者当场做实验。好了不扯了，下面进入正题。 关于三次握手和四次挥手的理论部分可以在很多资料上找到，我今天动手抓了几个包验证书上的理论，毕竟那
转载
2024-03-22 09:41:26
213阅读
1 问题现象在视频专网（局域网）中，通过GB/T 28181视频平台接入大量的网络摄像机，比如上百、上千，甚至上万台。当系统同一时刻实况点播并发的视频路数较多时，常常会在客户端或电视墙监视器上，出现视频卡顿、花屏、绿屏等现象。是视频平台软件媒体转发性能跟不上，支撑不起当前的系统压力；还是网络带宽出现瓶颈、负载过高引起丢包；抑或是服务器/客户机配置不够，媒体转发或解码时，机器资源（CPU占
转载
2024-05-31 14:28:48
551阅读
一.根据定位问题到解决问题的思路：1.确认网络链路问题，ping测和traceroute确认链路是否健康。如果链路有问题，找对应网络管理员排查网络。2.确认系统问题，通过wireshark或者tcpdump在应用系统两端抓包，定位问题所在，排查是发送或者接受系统网卡、性能问题3.从tcp应用本身排查，通过在程序上添加调试代码，核查是否应用逻辑处理问题二.考虑TCP协议为什么会丢包，在什么样的情况下
转载
2024-03-22 16:46:47
527阅读
TCP:TCP/IP通过三次握手建立一个连接。这一过程中的三种报文是：SYN，SYN/ACK，ACK。第一步是找到PC发送到网络服务器的第一个SYN报文，这标识了TCP三次握手的开始。如果你找不到第一个SYN报文，选择Edit -> Find Packet菜单选项。选择Display Filter，输入过滤条件：tcp.flags，这时会看到一个flag列表用于选择。选择合适的flag，tc
转载
2024-03-25 06:51:53
3254阅读
Debug 网络质量的时候，我们一般会关注两个因素：延迟和吞吐量（带宽）。延迟比较好验证，Ping 一下或者 mtr[1] 一下就能看出来。这篇文章分享一个 debug 吞吐量的办法。看重吞吐量的场景一般是所谓的长肥管道(Long Fat Networks, LFN, rfc7323[2]). 比如下载大文件。吞吐量没有达到网络的上限，主要可能受 3 个方面的影响：发
转载
2024-03-20 08:16:22
935阅读
TCP 核心问题之 顺序与丢包时隔多年，终于记起这个系列挖的坑还没写完。首先补充一点之前没提到的应答的知识累积应答 （cumulative acknowledgment）顾名思义，累积起来一起应答。（PS 我看网上不少会叫 累计应答，但我感觉更像是积累，所以我更倾向于称之为累积）TCP 在发包的是后会带有 id ，这个包 id 的起始值在三次握手的阶段会确定好一个数。TCP 需要发送端和接收端保存
流量、电量、弱网环境怎么测？|Android App性能测试白皮书 背景介绍
Android用户也许会经常碰到以下的问题：1）应用后台开着，手机很快没电了——应用耗电大；2）首次/非首次启动应用，进入应用特别慢——应用启动慢；3）应用使用过程中，越来越卡——CPU能力不足/内存泄露；4）应用页面卡顿——帧率较低、页面卡顿。因此，对开发的Android应用，必须对其进行性能测试，不然将会直接
前面我们演示分析了100+个wireshark TCP实例，拥塞控制部分也介绍常见的拥塞处理场景以及4种拥塞撤销机制，但是我们一直使用的都是reno拥塞控制算法。实际上拥塞控制发展到今天已经有了各种各样的拥塞控制算法，而且普遍认为单纯基于丢包的reno拥塞控制算法已经不适应当前internet网络了，最近谷歌又折腾出了一个BBR拥塞控制算法，对比国内，还没有一个在TCP领域有突出贡献的公司，谷歌在
