霄翎
TA的个人档案
个人介绍
玩过单片机，折腾过C、Java，现在觉得Python也不错
擅长的技术
- Linux
- 高分内容
- 最新动态
- 文章
- 问答
-
发表了文章 2019-11-09
业务系统 Over 阿里云性能压测的最佳实践
业务系统性能压测的最佳实践 压测工具的选择 目前主流的压测工具有 ab Jmeter 阿里云PTS 如何来选择呢，我们建议如果是简单压测，可以直接使用ab来进行，它可以通过一条命令来快速的发起指定并发数的请求。但如果需要进行复杂的压测，建议使用后两者： Jmeter是开源的压测工具，可以实现非常复杂的压测需求，比如设定一个包含很多URL的场景、配置一个施压集群来发起压测测试等等，而阿里云PTS服务，相较于Jmeter增加了许多独特的功能，比如： 施压流量来自真实CDN节点，最大限度模拟真实流量的路径 纯SaaS，无需额外安装和部署 兼容Jmeter脚本，可以平滑的复用之前的jmx脚本文件 配置界面所见即所得，对于新手非常友好 所以，我们建议大家根据实际的压测需求来选择压测工具。另外，如果您对PTS感兴趣，可以前往PTS控制台进一步了解。 阿里云上业务压测流程上的注意事项 施压前 对业务系统容量有一个预估，比如QPS、并发用户量 确定好压测时间和压测环境，尽量不要直接对生产环境压测，避免影响业务 若链路上存在SLB，建议至少使用4台施压机来压测，施压机越多，SLB的转发会越均衡 合理安排施压机的压测能力，若单台施压机无法满足施压需求，可以构建Jmeter施压集群或者使用PTS进行压测 若链路上存在安全模块，如高防、Web应用防火墙等，建议对施压机的源IP添加白名单，避免施压机被安全模块拦截 施压中 密切关注被压测的模块的各项监控 当出现瓶颈时就可以考虑停止或延迟若干分钟停止压测，避免产生无效的压测流量 施压后 结合业务数据对施压结果进行分析，确定系统是否可以达到预期的目标 出现瓶颈后，需要及时优化业务程序 压测结果相关 如何判断目标系统是否出现瓶颈？ 判断瓶颈的方法非常多，比较简单的方法之一是增加并发用户数量，查看目标系统的TPS是否同步上涨，如果没有出现增加，甚至出现了下降，说明业务系统处理每个请求的时间变长，可以近似理解为此时的业务系统就出现了瓶颈。 并发用户、RPS、TPS如何解读 名词的定义千差万别，但归根结底的形容都是类似的，以下可以作参考： 并发用户：施压机上同时去请求的用户数量，比如500个并发用户，配置的施压目标是串行的两个URL，那么施压过程中，就会有500个客户端，不停地去请求URL 1和URL 2，用户之间的请求互不影响，并发的请求，而每个用户是先请求URL 1，得到结果后在请求URL 2，得到结果后再循环请求URL 1，以此类推。 RPS：在PTS中，RPS被定义为施压机每秒发出的请求数 TPS：在PTS中，TPS被定义为压测目标每秒执行的事物数，若目标系统是基于HTTP(S)，可以理解为每秒能够执行多少HTTP请求。 那么有的同学会问了，TPS和RPS有什么差别呢？在正常情况下，RPS的数值近似等同于TPS，TPS对于一个系统来说，是恒定的，但只要施压机性能还够，RPS还可以提升，只是此时目标系统已经无法处理，可能会出现连接失败、请求超时等异常的响应，那么此时，RPS是大于TPS的，需要及时停止施压并分析目标系统为何会出现异常
-
发表了文章 2019-07-03
上云之网络搬站
概述 近年来，随着云计算越来越普及，更多的人可以随时随地的使用云资源，享受着云计算带来的红利。越来越多的企业、网站也把云平台当做主要的业务环境，其中云网络和传统的IDC会有一些差别，如何更平滑的将IDC的资源迁移到云上，如何更好地利用云网络的特性服务业务，也是一个重点要探讨的问题点。 本文结构 本文先分析传统IDC的网络特点，然后重点介绍了云计算网络的特点，最后列举了几种网络上云的方案，让大家可以做详细对比，选择自己合适的上云方法。 从IDC说起 传统的IDC架构，无外乎就是“接入层”、“汇聚层”、“核心层”，每一层工作职责分明，便于管理和维护。IDC内部网络肯定是有冗余的，防止某个设备出现异常导致单点故障，同时对外的出口在一个数据中心往往有一个或多个，规模大一些的IDC会同时接入多家运营商，保证和对端的通信质量。 在传统的IDC内部署业务时，往往是在一个IDC内构建业务，若对业务可用性要求高一些，会在同一个城市的另外一个IDC部署一套相同的业务，作为主备IDC。但这样操作的灵活性较差，若是业务需要扩容机器，往往采购过程会长达几周甚至几个月，同时使用IDC的成本也会较高，不利于中小企业的发展。 云计算网络 云计算的网络，充分的贯彻了云化的概念，包括阿里云在内的几家云计算厂商，不约而同的提出了“专有网络VPC”的概念，相较于传统IDC的网络，他有着让人着迷的特性： 租户间网络隔离 弹性伸缩 自主分配IP地址 他克服了传统IDC的劣势，随时随地都可以新建主机，同时将IP网段划分的自主权完全交给了用户，用户可以根据自己的业务需求更好的来对生产网进行地址划分，同时还保证了租户间的网络隔离，进一步提高了安全性。 我们打个比方，在传统的IDC内，我们要规划三个环境：生产环境、预发环境、开发环境，这三个环境很有可能都是在同一个网段内，无法做到严格隔离，相互之间会受到干扰，但是在云上，我们可以创建三个专有网络，它们的网段甚至都可以配置成一致的172.16.0.0/12，保证网络环境的一致性，同时这三个专有网络又是隔离的，保证了整个运维环境的稳定性。 构建混合云 说了这么多云网络的好处，有些同学就会问了，我的业务在IDC已经跑了一段时间，没办法一下子就迁到云上，有什么好的办法可以平滑的迁移吗？答案当然有，就阿里云目前的上云服务，我们提供了多种网络上云的方案。 VPN网关 VPN网关是一款基于IPSec VPN和SSL VPN的产品，数据进行加密传输，保证数据安全可靠，可以在短时间内打通两个网络，构建一个虚拟的网络环境的产品。 下面这张图说明了VPN的一个典型应用：通过SSL VPN可以将某一台终端快速的接入VPC网络，通过IPSec VPN可以让一个网络和云上VPC网络快速内网打通，为迁云提供一个过渡环境。 智能接入网关SAG 前面提到的VPN网关，一般要求云下的网络内部必须要有VPN硬件设备，来和云上的VPN网关构建链接，但如果云下网络内没有相关硬件，要怎么办呢？阿里云目前提供了一站式快速上云的产品智能接入网关SAG，无论是小型分支或门店，还是集团总部网络，都可以选择不同规格的SAG进行快速上云，阿里云提供设备，加电就上阿里云。在SAG覆盖的网络内部，可以快速的、安全的访问云上VPC的资源，快速搭建一个混合云网络。 专线 前面说了两种构建混合云的方式，主要的思路是基于现有的公网链路进行数据传输，但公网链路难免会有抖动，对于一些敏感业务，我们推荐使用专线构建混合云，保证混合云的通路质量。 下面是一个典型的场景，VBR可以理解为传统IDC中的CPE接入交换机，通过专线连接了IDC的接入交换机和云上的虚拟边界路由器VBR，打通两侧的网络，构建稳定的混合云。 该选择什么方式上云？ 说了这么多构建混合云的方法，大家可能问我该选择哪一种方式上云呢？其实没有绝对的答案，需要根据业务的实际情况来定。VPN网关、智能接入网关、专线，他们的成本依次增加，当然网络的健壮性、可靠性也是依次增加，得需要根据整个项目的成本、要求来综合考虑使用什么形态上云或构建混合云。 一般来说，VPN网关适合临时测试以及管控的备用线路；智能接入网关适合有许多门店的场景；而专线就是用来稳定的链接两个网络的终极方案。前两者跑在公网上，会受到公网链路的抖动影响，后者采用了专用链路，独享通信链路，避免了公网抖动给业务造成的影响。 终极形态 - 云企业网 最后有的同学可能会想在整个迁云过程中，需要多个网络使用多个上云的方案共存，是否可以更智能化、更简便的管理云上云下网络呢？答案就是云企业网。它可以非常方便快速的打通VPC-VPC、VPC-本地网络，通过自动路由分发及学习，提高网络的快速收敛和跨网络通信的质量和安全性，实现全网资源的互通。是目前来说比较理想的智能组网方式。同时支持上述三种上云方案，帮助大家平滑的上云。 下图展示了云企业网同时加载专线、VPN网关、智能接入网关三种产品，构建企业级混合云的拓扑，一些小的分支站点，可以使用VPN网关、智能接入网关快速上云，而一些已经部署业务的IDC短期内无法版迁到云上，则可以通过专线和云网络打通： 参考文献 IDC通过VPN网关上云方案 IDC双专线静态路由冗余上云方案 [IDC通过专线和智能接入网关主备方式上云方案](
-
发表了文章 2018-09-02
ECS弹性网卡+弹性公网IP配置最佳实践之策略路由
概述 目前阿里云ECS部分机型可以配置多张网卡（一张原生网卡+若干张弹性网卡），用来实现业务上对于系统内多网卡的需求，详细可以参考 [【新功能】弹性公网IP绑定弹性网卡新功能及最佳实践 ](https://yq.aliyun.com/articles/629383?spm=a2c4e.11163080.searchblog.9.30812ec15GS8P5 )。在使用过程中，可能会遇到多个弹性公网IP绑定到一个ECS上的原生网卡、弹性网卡上后无法通信的问题，这个时候需要检查系统内的路由配置和策略（policy rules）。 从route路由表说起 默认情况下，linux系统中都会有一张路由表，使用route或ip route就可以进行查看，如 default via 172.16.127.253 dev eth0 169.254.0.0/16 dev eth0 scope link metric 1002 172.16.112.0/20 dev eth0 proto kernel scope link src 172.16.115.242 以上起到关键作用的是第一行路由，它声明了一条默认路由，从eth0网卡中出去，目标是网关172.16.127.253。在只有一张网卡的实例中，这样的配置是没有问题的，但如果有多张网卡的情况下，入流量会从不同的网卡中进入实例，但出流量都会从eth0网卡中出去（譬如从外部ping 绑定在弹性网卡上的弹性公网IP，ICMP request包会从实例的弹性网卡中进入实例，而实例回复的ICMP reply包会从eth0中流出），导致出入路径不一致，会造成一系列的问题，如单网卡流量瓶颈、负载不均衡等问题。 真实的路由表 在linux系统中，实际上是有255张路由表的，默认使用的是254这张路由表，使用route命令展示的即是这张表中的路由条目。除此之外的路由表我们可以对它进行适当的配置，以实现自定义或高级需求。 我们可以使用ip route list table [table index]来查看系统内的路由表条目，如 [root@xiaoling-hz-test ~]# ip route list table 254 default via 172.16.127.253 dev eth0 169.254.0.0/16 dev eth0 scope link metric 1002 172.16.112.0/20 dev eth0 proto kernel scope link src 172.16.115.242 以上条目可以看到系统内默认的254号路由表内的条目，另外，还可以将index置为0来查看系统内所有的路由条目，这在需要循环遍历系统内自定义路由表时非常有用。 PS. table==253这张路由表被系统默认为是default表，建议使用1-252号路由表来添加自定义的路由条目。被linux预先定义的路由表详情可以查看系统内/etc/iproute2/rt_tables，以下是一个示例，可以看到253 - 255已经被系统定义： # # reserved values # 255 local 254 main 253 default 0 unspec # # local # #1 inr.ruhep 策略路由 为什么会需要多张路由表呢？这不得不提到策略路由，目前我们需要实现的功能是同进同出，保证从eth0口进来的包从eth0口出去，eth1进从eth1出，但弹性公网IP需要有一条默认路由来让ECS可以正常访问公网，但却又不能直接在默认路由表里添加两个目标网段是0.0.0.0，分别从eth0、eth1中出去的路由，这个时候策略路由就派上用场了，我们需要根据源地址进行策略选择。 简单来说就是配置两张路由表，路由表中分别有从eth0、eth1中出去的默认路由，在系统需要发包时，根据包的源IP进行选择，eth0的源IP就从包含eth0的路由表出去，eth1的源IP就从eth1的路由表走，从而实现同进同出。 linux系统内关于策略的索引是一个无符号的32位整型数值，所以理论上策略索引的数值可以达到4294967295之多，当然通常我们只需要使用个位数的索引条目即可。 具体的一个配置 以上说的都是理论，可能会有一些虚，下面我们来实际进行一个配置。我们特意选取阿里云官方尚未支持自动配置的镜像Ubuntu 16.04 64位来进行配置，以下是这个场景中相关参数： ECS实例网关地址：172.16.127.253 ==原生网卡信息== 名称：eth0 IP地址：172.16.116.38 绑定的弹性公网IP：47.99.42.x ==弹性网卡信息== 名称：eth1 IP地址：172.16.116.39 绑定的弹性公网IP：116.62.163.x 如何获得ECS实例完整的网卡信息 阿里云ECS控制台对于实例的网卡信息展示的不是很完全，建议通过API方法 DescribeNetworkInterfaces 来获取，若没有API调试环境，可以使用阿里云的API Explorer来调试，非常方便，以下是一个示例 URL ，点击后可以直接进入在线调试页面。 检查系统的默认配置 依次查看网卡、默认路由，可以看到系统内的配置残缺不全： root@iZbp14bxrlofsqs3d5dw43Z:~# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:16:3e:0c:72:5d brd ff:ff:ff:ff:ff:ff inet 172.16.116.38/20 brd 172.16.127.255 scope global eth0 valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 00:16:3e:10:aa:7e brd ff:ff:ff:ff:ff:ff root@iZbp14bxrlofsqs3d5dw43Z:~# ip route list table 254 default via 172.16.127.253 dev eth0 172.16.112.0/20 dev eth0 proto kernel scope link src 172.16.116.38 首先编辑/etc/network/interfaces文件，在最后加上关于eth1的定义，新添加的两行分别告诉系统在启动时自动拉起eth1、eth1的参数配置使用DHCP协议，详细的配置说明可以参考man interfaces： auto lo iface lo inet loopback auto eth0 iface eth0 inet dhcp auto eth1 iface eth1 inet dhcp 保存后执行systemctl restart networking重启网络服务，可以看到eth1网卡已经配置上IP地址了： root@iZbp14bxrlofsqs3d5dw43Z:~# ip address 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:16:3e:0c:72:5d brd ff:ff:ff:ff:ff:ff inet 172.16.116.38/20 brd 172.16.127.255 scope global eth0 valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:16:3e:10:aa:7e brd ff:ff:ff:ff:ff:ff inet 172.16.116.39/20 brd 172.16.127.255 scope global eth1 valid_lft forever preferred_lft forever 接下去就需要配置策略路由了，针对这个场景，我们定义了以下信息： ==原生网卡== 使用路由表100，策略路由优先级索引为200 添加路由的命令（网关地址根据实际情况而定）：ip route add default via 172.16.127.253 dev eth0 tab 100 添加策略的命令（源IP根据实际情况而定）：ip rule add from 172.16.116.38 tab 100 priority 200 ==弹性网卡== 使用路由表101，策略路由优先级索引为300 添加路由的命令（网关地址根据实际情况而定）：ip route add default via 172.16.127.253 dev eth1 tab 101 添加策略的命令（源IP根据实际情况而定）：ip rule add from 172.16.116.39 tab 101 priority 300 执行以上命令后，系统内策略路由就已经配好了，通过相关命令查看的结果如下（已经略去无关信息）： root@iZbp14bxrlofsqs3d5dw43Z:~# ip route list table 0 default via 172.16.127.253 dev eth0 table 100 default via 172.16.127.253 dev eth1 table 101 default via 172.16.127.253 dev eth0 172.16.112.0/20 dev eth0 proto kernel scope link src 172.16.116.38 172.16.112.0/20 dev eth1 proto kernel scope link src 172.16.116.39 root@iZbp14bxrlofsqs3d5dw43Z:~# ip rule list 0: from all lookup local 200: from 172.16.116.38 lookup 100 300: from 172.16.116.39 lookup 101 32766: from all lookup main 32767: from all lookup default 可以看到系统中增加了table==100、101的两张路由表，增加了200、300两个优先级的策略，分别指定eth0、eth1出入的规则，这样就可以做到一张网卡同进同出了。 持久化配置 以上的配置，除了网卡的IP信息可以持久化，其他的配置如路由、策略都会在重启后失效，可以把以上命令写到系统的配置文件中。理论上更优雅的方法是在/etc/sysconfig/network-scripts/ (CentOS) 、 /etc/network/ (Ubuntu)目录下将命令写到特定的文件中来解决这个问题，但无奈无法测试所有的场景，我采取了比较“暴力”的方法来统一的解决：将命令写到/etc/rc.local文件中，可以无视发行版。 比如本文中的场景，就可以将四条ip route/ip rule命令添加到rc.local中： root@iZabcdeZ:~# vim /etc/rc.local ip route add default via 172.16.127.253 dev eth0 tab 100 ip rule add from 172.16.116.38 tab 100 priority 200 ip route add default via 172.16.127.253 dev eth1 tab 101 ip rule add from 172.16.116.39 tab 101 priority 300 阿里云原生的做法 查看阿里云官方关于配置 ECS 实例的弹性网卡的说明，以下几种镜像是可以直接支持不需要手工配置： CentOS 7.3 64 位 CentOS 6.8 64 位 Windows Server 2016 数据中心版 64 位 Windows Server 2012 R2 数据中心版 64 位 实际上CentOS系统内部也是采用了类似的策略来实现的，使用ip route和ip rule命令可以查看到响应的策略，只是路由表索引和策略路由的优先级序号有些许不同，各位可以实际验证一下。 参考文献 https://www.linuxjournal.com/article/7291
-
发表了文章 2018-06-13
FTP Server Over 阿里云 最佳实践
概述 作为非常古老的协议（1971年首次提出，1980年首次应用），FTP在目前依然占有一席之地，但是由于目前IT业发展的非常迅猛，它和现在的基础架构产生了一些水土不服，本文旨在通过日常常见的案例，来介绍如何在阿里云上搭建FTP Server和FTP Client。 本文结构 本文先从FTP的协议分析，重点阐述了其中控制通道的两种连接模式，进而说明在阿里云上搭建FTP服务器可能遇到的问题，如被动模式下服务器公网IP无法获取、主动模式下无法连接等情况。 FTP协议摘选 控制通道与数据通道 在FTP协议中，通常有两个通道：控制通道和数据通道，前者用来传输控制命令，如协议握手、获得当前目录等操作，而数据通道顾名思义，就是用来传输文件数据之用，另外ls命令的结果通常也会通过数据通道来传输。 被动模式与主动模式 而被动模式和主动模式是针对如何建立数据通道而言的，这里的主动、被动是站在服务器的角度上描述的，他们的差别简单来说就是数据通道的TCP连接建立是由谁发起的，主动模式下服务器主动向客户端建立数据通道，而被动模式下，服务器是等待客户端来连接的。 这两个模式大家听到比较多的应该是被动模式，通常网上的文章都会建议客户端使用被动模式来连接，下面简单来说明一下两者的差别。 主动模式 主动模式的详细操作可以参考我之前写的一篇文章，这里节选部分信息： 以下是一次完整的交互，客户端为47.x.x.224，服务端为112.x.x.7。 对他的分析可以参考之后的一张交互图，需要重点说明的是交互图中标红的一行，这一行可以理解为数据通道的实际体现（抓包中倒数第4个包，由于我只过滤了FTP协议的包，TCP的控制包没有显示出来，这个包实际上是建立了一个新的TCP流来传输的），在这之前PORT命令是由客户端发出的，这一条报文为 PORT 47,x.x,224,39,16 其中前四个数字为十进制的IP地址，在主动模式下为客户端的IP地址，最后两个数字为端口，由于端口需要两个字节表示，所以在这里的计算方式为39x256+16=10000，那么这一条报文的意思就是告诉服务器，“我计划使用10000端口作为监听的端口，我的IP地址是47.x.x.224，你可以来连接我了进行数据传输了”。 被动模式 而被动模式最显著地差别就是在于如何建立数据通道，主动模式下是服务端去连接客户端传输数据，而被动模式下，是客户端去发起连接，向服务器建立连接。 以下是一次被动模式下的交互，客户端为30.x.x.85，服务端为47.x.x.255。 可以看出最大的区别在于红框中的命令，这一次从PORT改为PASV，之后服务器回复一条被动模式的信息，其中同样是6个数字：IP地址+端口号（端口号的计算方法和主动模式中一样），只是这一次换做服务器告诉客户端，“你现在可以连接我的47.x.x.255的47185端口了”。 这里特别提示一下，从下面的抓包截图中可以看出服务器回复的PASV响应中IP地址并不是上面提到的47.x.x.255，而是一个私网地址172.x.x.241，原因我们会在# 专有网络ECS内部署FTP Server #这一节中提到。 被动模式出现的原因 为何会同时存在被动模式和主动模式呢？在互联网的初期，由于各个终端使用的都是标准的公网IP地址，彼此时间可以互相通信，互相可见，所以在发起TCP连接时，无所谓是哪一方先发起。但随着互联网的高速发展，人们发现IP地址已经不够用了，进而诞生了NAT技术，这就在通信的双方之间插入了一个中间人，在NAT设备之后的终端对于对方是不可见的，所以只能由它来发起连接。 所以为了迎合NAT技术，FTP协议里就出现了被动模式，而且由于目前大部分FTP客户端都是在NAT设备之后，所以绝大多数情况下只能使用被动模式（当然在一些特殊的架构里主动模式还是有一定的用武之处，本文最后一节将会提及） 专有网络ECS内部署FTP Server 阿里云ECS的网络 目前阿里云ECS的网络类型有两种：经典网络与专有网络。对于经典网络的ECS来说，系统内有两张网卡：eth0和eth1，eth0为内网网卡，eth1为外网网卡。在系统内内网和外网的IP地址是静态写在配置文件里的，系统内可以直接看到。而专有网络的ECS系统内只有一张网卡eth0，所有的流量都由这张网卡出入，系统内部无法看到ECS自身的公网IP/弹性公网IP。 这就直接导致了一个问题：由于目前的网络环境下大部分客户端都会使用被动模式来连接，但是被动模式下服务器需要告诉客户端连接的IP地址，而专有网络下的ECS无法直接看到外网IP，那么就导致FTP Server将自己的私网IP告诉了客户端，客户端收到了一个私网IP自然就无法进行连接。而list、文件传输都需要走FTP协议的数据通道，所以最终导致了专有网络下搭建的FTP Server无法让客户端正常的传输数据。 解决方案 解决办法也很简单：主动告知FTP Server程序系统的外网地址，由于市面上FTP Server众多，各家的设置方式不尽相同，以下说明几个常见的FTP服务器的设置方法： vsftpd 在vsftpd的配置文件中，加入以下两行，其中替换为ECS的弹性公网地址： listen_ipv6=NO pasv_address=<EIP> IIS 打开IIS，选择服务器（注意不要选择“网站”下的ftp站点），打开右侧的“防火墙支持”，在“防火墙的外部IP地址”其中填入ECS的弹性公网地址即可。 Serv-U（最新版本） 打开管理控制台，依次选择“域”-》[对应的域]-》“域详细信息”-》“监听器”-》21端口的监听器，点击“编辑”，将ECS的弹性公网地址填入弹出的对话框中 One more thing 在撰写本文时，我发现一些客户端似乎已经提供了智能化的规避方案，如lftp提供以下参数，当出现类似的问题时会尝试使用控制通道的服务器IP地址进行数据通道的连接。 ftp:fix-pasv-address (boolean) if true, lftp will try to correct address returned by server for PASV command in case when server address is in public network and PASV returns an address from a private network. In this case lftp would substitute server address instead of the one returned by PASV command, port number would not be changed. Default is true. 另外，FileZilla也默认开启了修正被动模式下数据通道IP地址的功能： FTP的端口与ECS的安全组 ECS的安全组 阿里云上的安全组相当于一个方向墙，类似iptables或Windows防火墙，可以根据协议、源/目的IP、源/目的端口来实现特定流量的放行、拦截。在# 被动模式和主动模式 #一节中我们已经提到了FTP除了21端口以外，根据不同的模式在数据通道下还会使用到特定的端口，所以需要在ECS的安全组中放行。 FTP端口的选择策略 关于FTP两种模式下的报文交互，前文已经做了阐述，但还未说明程序是如何选择端口的，下面简单说明一下： 被动模式 - 控制通道 数据通道 客户端 主动连接服务器，随机选择本地源端口 主动连接服务器，随机选择本地源端口 服务端 被动接受客户端连接，本地默认监听21端口 被动接受客户端连接，本地随机监听端口 注：被动模式下服务端数据通道监听的端口理论上可以通过FTP程序的配置文件修改 主动模式 - 控制通道 数据通道 客户端 主动连接服务器，随机选择本地源端口 等待服务器的链接，本地监听一个随机的端口（注） 服务端 被动接受客户端连接，本地默认监听21端口 主动链接客户端，随机选择本地源端口 注：主动模式下客户端数据通道监听的端口理论上可以通过FTP程序的配置文件修改 那么可以得出在ECS上部署FTP Server，若对于安全组有严格的进出限制，那么需要放行： 控制通道监听的端口，用来接收客户端的控制命令，默认为21端口 被动模式下建议指定一个端口范围，以便在安全组中可以放行；主动模式下由于安全组出方向是默认放行的，所以理论上不需要额外的配置 如何指定被动模式下服务器数据通道监听的端口 这里依然以常见的FTP程序为例： vsftpd在配置文件里添加以下信息，其中端口的起止范围根据实际需求修改，然后重启vsftpd pasv_enable=YES pasv_min_port=10000 pasv_max_port=10020 IIS同上文提到的类似，在“FTP防火墙支持”中填入数据通道的端口范围即可 Serv-U 打开左侧“全局”菜单，选择“限制与设置” 选择右侧“设置”选项卡，页面拉到下方，可以看到“网络设置”中有一项“PASV端口范围” 根据实际情况填写即可 主动模式适用的场景 前文提到在一些特定的场景下，确实只能使用主动模式，比如说IDC和银行侧相连，银行出于安全考虑仅允许21端口入方向的流量，其余的端口都是封禁的，那么就无法使用被动模式，只能退而求其次使用主动模式。那么此时对于客户端的要求可以总结为下列几点： 客户端必须有自己的公网IP，如ECS 弹性公网IP，或者可以使用阿里云NAT网关的DNAT功能，将公网IP的部分端口映射到ECS内部的端口上 客户端上强制使用主动模式（目前大部分客户端会优先使用被动模式） 由于主动模式下数据通道是由服务器发起连接，需要在ECS安全组中放行对应的端口 客户端系统内若无法直接看到公网IP（如专有网络下的ECS、DNAT模式下，依然需要对FTP客户端进行配置，告知客户端可以连接的公网IP地址）。 关于第二、三、四点，其实和被动模式下PASV命令的响应类似，都需要在程序中作相应的配置才行，但由于这个场景下这个需求确实比较小众，我只收集了少量的客户端配置方法，其他的客户端配置方法请和程序的提供商寻求技术支持。 配置主动模式的端口和公网IP地址 lftplftp程序非常友好，在man手册中就已经说明了配置方法，依次是被动模式开关、主动模式下的IP地址、主动模式下数据通道监听的端口范围： ftp:passive-mode (boolean) sets passive FTP mode. This can be useful if you are behind a firewall or a dumb masquerading router. In passive mode lftp uses PASV command, not the PORT command which is used in active mode. In passive mode lftp itself makes the data connection to the server; in active mode the server connects to lftp for data transfer. Passive mode is the default. ftp:port-ipv4 (ipv4 address) specifies an IPv4 address to send with PORT command. Default is empty which means to send the address of local end of control connection. ftp:port-range (from-to) allowed port range for active mode. Format is min-max, or `full' or `any' to indicate any port. Default is `full'. FileZilla 主动模式相关配置可以直接在菜单栏中的“编辑”-》“设置”中配置 客户端的连接行为可以在每个FTP会话中单独配置 参考 1、阿里云金融云下FTP主动模式的讨论
-
发表了文章 2017-05-09
ECS API中Signature错误的排查方法
Signature的生成方法 将get中提交的参数（除了aks以外所有的参数）按照一定的组成规则拼成一个字符串，前面再加上GET&/&组成StringToSign，然后对StringToSign做 HMAC计算，以Access Key Secret+一个“&”号为HMAC计算的key，最终算出的字符串就是Signature。 排查思路 若碰到反馈Signature错误，可以排查以下几点： 在构造“StringToSign”时是否对key值做了A-Z的字典排序 是否将所有的参数都放入了StringToSign 计算前是否对StringToSign中的值做了urlencode，即将一些特殊的字符替换成类似%3D这样的字符串，如“=”需要替换成“%3D”，“/”要替换成“%2F”等，参见下述说明：a、 对于字符 A-Z、a-z、0-9 以及字符“-”、“_”、“.”、“~”不编码； b、 对于其他字符编码成 “%XY” 的格式，其中 XY 是字符对应 ASCII 码的 16 进制表示。比如英文的双引号（”）对应的编码就是 %22c、 对于扩展的 UTF-8 字符，编码成 “%XY%ZA…” 的格式；d、 需要说明的是英文空格（ ）要被编码是 %20，而不是加号（+）。 是否使用了指定的算法，目前Signature需要使用HMAC-SHA1算法，在Java中通过Mac mac = Mac.getInstance("HmacSHA1");来获得HMAC-SHA1算法的对象 检查HMAC-SHA1运算时是否是将Access Key Secret+&作为key（如Access Key Secret为abc，那么使用“abc&”作为运算的key），运算过程编码使用UTF-8编码 以下是一个例子 1、 比如说要查询可用的镜像，先加入除了Signature以外所有的参数（值被忽略）： [ImageOwnerAlias, SignatureVersion, Action, Format, PageSize, SignatureNonce, Version, AccessKeyId, SignatureMethod, RegionId, Timestamp] 2、 对它们进行字典排序： [AccessKeyId, Action, Format, ImageOwnerAlias, PageSize, RegionId, SignatureMethod, SignatureNonce, SignatureVersion, Timestamp, Version] 3、 挨个将它们拼接在一起（注意这个时候Timestamp中的值就已经经过了urlencode了，将“:”替换为“%3A”）： AccessKeyId=6olc8au16tjr574v222c923p&Action=DescribeImages&Format=XML&ImageOwnerAlias=system&PageSize=10&RegionId=cn-hangzhou&SignatureMethod=HMAC-SHA1&SignatureNonce=352f98b6-5fbe-489c-b8a4-5d484939a8d5&SignatureVersion=1.0&Timestamp=2015-09-12T07%3A45%3A58Z&Version=2014-05-26 4、 在前面加上GET&/&： GET&/&AccessKeyId=6olc8au16tjr574v222c923p&Action=DescribeImages&Format=XML&ImageOwnerAlias=system&PageSize=10&RegionId=cn-hangzhou&SignatureMethod=HMAC-SHA1&SignatureNonce=352f98b6-5fbe-489c-b8a4-5d484939a8d5&SignatureVersion=1.0&Timestamp=2015-09-12T07%3A45%3A58Z&Version=2014-05-26 5、 再对整个字符串做urlencode，可以看到其中的“/”、“=”和参数键值对中的“&”都已经被替换，注意最前面的GET之后的两个“&”并没有被替换： GET&%2F&AccessKeyId%3D6olc8au16tjr574v222c923p%26Action%3DDescribeImages%26Format%3DXML%26ImageOwnerAlias%3Dsystem%26PageSize%3D10%26RegionId%3Dcn-hangzhou%26SignatureMethod%3DHMAC-SHA1%26SignatureNonce%3D352f98b6-5fbe-489c-b8a4-5d484939a8d5%26SignatureVersion%3D1.0%26Timestamp%3D2015-09-12T07%253A45%253A58Z%26Version%3D2014-05-26 6、 然后构造HMAC运算的key，很简单，将Access Key Secret再加上一个“&”即可： IamAccessKeySecret& 7、 扔给电脑做HMAC-SHA1运算，然后算出来一个最终的字符串： 53wPekiWxh45TgPxVb4bkXrzZ6M= 8、 这个字符串就是最终的Signature值，然后将其加入到HTTP get请求中，组成最终的get参数字符串，特别要注意Signature加入后需要确认其中的特殊符号如“=”是否被转换为%xx的字符串。 ImageOwnerAlias=system&SignatureVersion=1.0&Action=DescribeImages&Format=XML&PageSize=10&SignatureNonce=352f98b6-5fbe-489c-b8a4-5d484939a8d5&Version=2014-05-26&AccessKeyId=6olc8au16tjr574v222c923p&Signature=53wPekiWxh45TgPxVb4bkXrzZ6M%3D&SignatureMethod=HMAC-SHA1&RegionId=cn-hangzhou&Timestamp=2015-09-12T07%3A45%3A58Z 9、 然后就可以向ECS的API服务器发送请求了 参考文档 1.官网的生成Signature文档：https://help.aliyun.com/document_detail/25492.html
滑动查看更多
滑动查看更多
-
发表了文章
2019-11-09
业务系统 Over 阿里云性能压测的最佳实践
-
发表了文章
2019-07-03
上云之网络搬站
-
发表了文章
2018-09-02
ECS弹性网卡+弹性公网IP配置最佳实践之策略路由
-
发表了文章
2018-06-13
FTP Server Over 阿里云 最佳实践
-
发表了文章
2017-05-09
ECS API中Signature错误的排查方法
-
发表了文章
2016-10-30
sshd_config 中 PermitRootLogin 的探讨
-
发表了文章
2016-10-19
JCLI使用说明文档
-
发表了文章
2016-09-24
阿里云金融云下FTP主动模式的讨论
-
发表了文章
2016-09-21
更自由的阿里云API工具JCLI
-
发表了文章
2016-09-07
JCLI诞生记（一）
滑动查看更多
暂无更多信息