阿里云DTS作为数据世界高速传输通道的建造者，每周为您分享一个避坑技巧，助力数据之旅更加快捷、便利、安全。
导读
在DTS的所有用户问题中，网络问题出现的概率居高不下，很大程度上是由于DTS的链路复杂性，从源数据库到DTS再从DTS到目的数据库，任意的一个部位发生网络不通、网络质量问题都有可能导致DTS任务的中断，或者延迟。
而在所有的网络不通问题中，“专线/VPN网关/智能网关” 或者 “CEN” 方式接入数据源的任务占比最多，一方面，以这2种接入方式接入的客户大多数是以VBR + 物理专线、VPN网关等方式连接了一个较远位置的网络环境，由于距离远加上网络链路可能具有不确定性因此网络质量并不能得到很好的保障；另一方面，由于这个目的网络环境可能是用户私网IDC、他云VPC等阿里云不可控的一个环境，其路由情况、数据库版本可能都并非是标准的，因此阿里云无法直接进行排查，必须依靠用户做跨网络域问题的排查，效率大打折扣
因此，本文希望以一种最简单的模型，简述DTS网络不通问题的排查方法，并给出一些简单的验证思路及手段，排查方向对了才能事半功倍。
网络不通问题概览
首先我们从TCP/IP的协议出发来定义一下 如何构造一个畅通的网络通道，不出现下方这种令人烦躁的报错。
配置任务时网络不通的报错图
定义开始
首先什么是TCP/IP协议？怎么确保TCP/IP协议是畅通的？ 以下是我从百度百科找到的回答：
TCP/IP（Transmission Control Protocol/Internet Protocol）即传输控制协议/网间协议.......... TCP 有3次握手和4次挥手............
说这么多其实关联不到实际的业务场景，不如我们直接给出这样一个极简的模型，并给出更为极简的定义：
“当DTS的流量可以以1号剪头的方向正确到达用户数据库，并且用户数据库的回流量可以以2号箭头的方向正确到达DTS，则网络畅通”
极简DTS&数据库网络通信图
接着我们对上图做一些填充，便得到了较完整的一张通信拓扑图：在这张图中，DTS和用户数据库之间需要经过 基础网络组件、专有网络VPC、下云/上云通道（也就是通常意义的专线或者VPN）最终到达用户数据库。
完整DTS&数据库网络通信拓扑图
但是这里左侧DTS和基础网络组件对于用户来说都是不可见的，右侧3个组件（专有网络VPC、下云/上云通道、用户数据库）对于用户是可见的，因此我们重新定义下刚才提出的更为极简的定义：
“当DTS注入专有网络VPC的流量可以以1号箭头的方向正确到达用户数据库，并且用户数据库的回流量可以以2号箭头的方向正确到达专有网络VPC，则网络畅通。”
我们这里已经定义好了一个畅通网络的必要条件，但是没有提到一个参数：专有网络VPC 是哪个专有网络VPC？
答案揭晓，实际上就是在配置DTS任务时，用户选择的“已和源端数据库联通的VPC”。（目标同理）
此时，我们有必要再更新一下刚才更为极简的定义：
“当DTS注入用户配置任务时选择的专有网络VPC的流量可以以1号箭头的方向正确到达用户数据库，并且用户数据库的回流量可以以2号箭头的方向正确到达用户配置任务时选择的专有网络VPC，则网络畅通。”
最终，我们解答并定义了这个问题 如何构造一个畅通的网络通道。但如何确认呢？如何确定我们构造的网络就是满足畅通网络要求的？
下面我们就从2部分探讨一下排查与验证思路：
- 排查下云流量部分
- 排查上云流量部分
排查下云流量部分
祭出我们的极简模型图，并给出下云部分畅通网络的极简定义：
DTS注入用户配置任务时选择的专有网络VPC的流量可以以1号箭头的方向正确到达用户数据库
极简模型图
那么在确认下云流量正确到达前，总得知道流量长的什么样子，否则分析无从谈起。
我们这里直接给出一个报文的模型：源IP我们称为云服务IP，是各种100.104开头的网段，目的IP就是用户的数据库IP，DTS注入用户VPC的流量会以这种形式在用户网络内流转，并随着用户的各种交换机路由表一路流动到用户数据库。
下云流量报文模型
那么这个源IP的网段如何确认呢？
可参考DTS的白名单网段进行确认，云服务IP网段在各region都是不一样的，数量也不一样
如果配置都正确要如何确认下云通道是畅通的呢？
可以使用tcpdump的抓包命令，在用户数据库上，进行抓包查看
sudo tcpdump net 100.104
如果你能在shell的回显，看到图示的来自100.104网段报文信息在不断更新的话，就说明数据库机器收到了来自云上云服务网段的流量。
排查上云流量部分
再次祭出我们的极简模型图，并给出上云部分畅通网络的极简定义：
用户数据库的回流量可以以2号箭头的方向正确到达用户配置任务时选择的专有网络VPC
极简模型图
书接上文，我们的下云流量有了，那么紧接着数据库会向云上做回包，这个回包的目的IP就是 下云流量的源IP，因此我们给出上云流量的报文模型
上云流量报文模型
接着就需要确认报文有没有回到云上了，那么可以执行如下这个命令：
MTR 100.104.X.X
但MTR哪个地址呢？
想确认这个100.104.X.X的地址具体是什么，可以采用刚才的方法 sudo tcpdump net 100.104，查看来源IP是什么
确认100.104 IP是什么的方法
做完MTR后可通过路径点得知由数据库发出的报文是否回到了阿里云上，由于手里没有现成的专线测试环境因此就不给大家演示了。
大多数上云不通的情况是报文根本没出非阿里云环境，还在这个网络域内徘徊，多半是由于一些路由配置问题导致回程的路由没有指向VBR的云下互联地址，或者指向云下的VPN网关。当然具体是什么情况就需要用户的网工进行排查了。
总结
本篇主要从DTS角度提出了一个 “畅通网络”的极简版定义，并且讨论了一套最简单的网络不通排查思路，是定性的分析，主要是回答：“有没有下云”和“有没有上云” 这2个问题，可以起到售后介入前用户自行排查的作用。但是针对更为复杂的场景，需要定量分析的，本篇没有涉及。比如还有其他更极端的情况，报文已经确认上云了，但是没有回到用户填写的那个VPC；报文已经下云了，但是用户数据库没有接到；这就属于更为复杂的网络问题，需要借助更综合的知识分析，也不在本篇的讨论范围内。
网络问题综合性较强，牵扯部门多，覆盖范围广，因此排查周期长、难度大。从我们的心得而言，如果是运行中链路遇见网络问题，那么尽量从变更入手，很可能是变更引发的问题；如果是配置中链路遇见网络问题，多半是用户的网络规划中缺失了 云服务IP网段 这个方面的规划。
快来关注
- 数据传输服务（Data Transmission Service，简称DTS）支持关系型数据库、NoSQL、大数据（OLAP）等数据源，集数据迁移、订阅、实时同步、校验功能于一体，能够解决公共云、混合云场景下，远距离、秒级异步数据传输难题。其底层基础设施采用阿里双11异地多活架构，为数千下游应用提供实时数据流，已在线上稳定运行7年之久，是一款沉淀了丰富实践经验的可靠产品。点击了解更多DTS相关信息
- 欢迎加入钉群讨论交流：
#DTS避坑指南”
