rsync同步文件到远程机器，卡住10多秒--问题解决过程

rsync同步文件到远程机器，卡住10多s--问题解决过程

背景

以前大体介绍过，我们这边是做运维平台的。如果要形象化理解，那么，比如jenkins这种喜闻乐见的软件大致了解吧，jenkins就经常需要同步文件/版本包到远程机器上，jenkins怎么实现的，没去了解。

我们这边算是自研了类似jenkins这类软件，其中，同步文件主要用的是rsync工具，作为非专业运维，来现在公司之前，甚至没用过rsync，scp用得更多。

来了之后也没怎么用这个，因为我没负责这块业务，自己事情也多，所以就懒了。

这次是同事遇到相关问题，我就带着对rsync的一知半解，参与了排查，所幸问题不难，解决了。

问题描述

这个图，因为是公司内的图，所以打码比较厉害。

简单来说，就是客户端机器通过rsync命令，同步本机的一个文件到target服务器的21000端口（target服务器上的21000端口有rsync的服务端在监听，负责接收文件）。

然后运行后，输出了一行提示：

connected to target服务器

就卡住不动了。

然后再过上10多s，程序才正常跑完。

同事也很纳闷，要同步的文件才2kb，怎么要10多s呢？

问题分析过程

熟悉我的同学可能知道，我有点喜欢抓包（甚至有时候，应该先去看日志才是最优的，但就是想不起来先去看日志）

我就在群里看着上面那个图，发了条抓包语句，让他试试。

你这可能得抓包。
tcpdump -i eth1 host target服务器 and tcp port 21000 -w 21000.pcap

这条语句，意思就是，在eht1网卡上抓包，因为tcp是四元组嘛（源端主机、源端端口、目的端主机、目的端接口），我们这里就是抓host为“target服务器”且端口为21000的包，然后写到21000.pcap这个文件。

然后过了一会想起来，这个是线上机器，写到21000.pcap这个文件后，也没法下载到本机来分析。

于是就让同事换了个命令去执行：

tcpdump -i eth1 host xxxx and tcp port 21000 -Ann

这个就是不写文件了，-Ann直接打印到console。

然后，我们再次去执行那个rsync命令，这次就看到了奇怪的一幕了：

• 首先是正常的三次握手
• 接下来，客户端在18:06:58，发起请求，请求体只能认出来："@RSYNCD:30.0"
• 接下来，服务端表示收到该请求
• 再接下来，服务端过了10多s后，返回了。返回体："@RSYNCD 30.0"

我们想想，客户端发起了请求，请求体是@RSYNCD:30.0之类的，看起来像是协商版本啥的；服务端隔了15s返回，也返回了一个版本信息（合理猜测）。

我又想起，好像之前在哪里看到资料，说rsync版本低了，有类似问题。

我就让同事去看看别的正常的服务器上的版本，是什么情况。同事看完后，表示版本无差异。

那其实就陷入僵局了，唯一的思路就是：先去看看这个rsync协议是啥样的，客户端为啥发了个这个过去，服务端要一直卡住呢。

现在，我们至少已经知道了问题的范围：应该是这个rsync服务端的反应有点问题，至于是为啥导致他反应这么慢，那就要去网上查了，看看有什么可能的原因。（我没有target服务器的ssh权限，没有想起来去服务端查看）

然后接下来，就是开始在google、百度上各种搜，关键字换来换去，最终查到了一些资料。

首先是rsync的协议，https://blog.csdn.net/hyforthy/article/details/18091869

和我抓的包的内容进行了应证，讲得还是基本准确的。

但是没有找到更多的细节，其实我是想知道官方文档有没有提到这种：什么情况下，收到客户端发的版本协商请求后，会卡住10多s。

但是很遗憾，官方文档也没讲这些。

最终，也就根据现象，调整关键字，找到了一些网上人的踩坑记录，发给同事看看。

网上的文档如下（https://blog.csdn.net/weixin_30488313/article/details/97145611）：

然后转手发给了同事，让他跟着这里面去检查。

这边我的意思就是，rsync服务端，收到客户端请求后，是可以拿到客户端的ip的，某些情况下，有些软件，经常会拿着这个ip，去反查一下ip对应的hostname，因此，我就推断是这个原因。

不过当时已经是周五下班时间了，我也没有rsync服务端机器的权限，没办法排查。同事应该是又有其他问题紧急处理了。

我们就都没管了。

今天想起来这个事情，问了下同事，同事说，就是这个问题，一模一样。

解决办法，采用了简单的方式，修改了hosts文件；

• 或者机器连接的的dns系统能解析到客户端ip也是可以解决这个问题的。
• 再或者就是，升级rsync服务端，升级后，支持不解析客户端ip。

总结

展示了日常处理问题的一些方法，希望对大家有所帮助。

另外，扯点闲篇，深圳终于疫情好了不少了，上周还是2天出一次小区，一户只能出去一个。

由于我这边是合租，平时大家也没沟通，不知道别人用没用出去的名额，我也就懒得出去了，所以是小区里宅了一周多。再加上之前的两周居家，算起来，居家已经3周多了。。

明天终于可以去公司上班了，不想待家里了，真没多少效率，太考验自制力了。

这两天出了东航的事情，也给我提了个醒，之前看到知乎问题是，有个年轻人去世了，家里老人挨家银行去问，看看有没有儿子的钱存在该银行。

总之很麻烦。

这还是现金存款部分，要是再有个什么基金、港美股、保险、证券账户、虚拟货币等各类资产，怕是家人也不知道，真要有点啥，那个钱，就要是给国家做贡献了（问题是国家也不会去动你的账户。。这就算是dead account了）。

所以，有些钱，是不是可以直接给到家人账号呢？可以想想。