感觉 AWS 的轻量+CDN 很香，想长期用有没有充值办法？
syqhcc · 204 天前 · 3505 次点击
这是一个创建于 204 天前的主题，其中的信息可能已经有所发展或是发生改变。
没有信用卡该怎么长期用？
生产环境，所以不想买成品号。
CDN AWS 轻量 成品26 条回复 • 2020-09-18 19:21:40 +08:00
asdf2020 1
asdf2020 204 天前
没有办一张就好了啊，*简单安全的方式了
kerro1990 2
kerro1990 204 天前
办一张多好
liqiu 3
liqiu 204 天前 ❤️ 1
如果不想办信用卡，中行或者中信有 master card/visa 的借记卡也可以去看看
LnTrx 4
LnTrx 204 天前
在 AWS 现有的模式下，没有银行卡 和 长期稳定使用 难以兼容
hakono 5
hakono 204 天前 via Android
AWS 的轻量+CDN 是什么意思？ aws 没有 轻量+CDN 这个 cdn 只有 cloudfront 啊
qianmianyao 6
qianmianyao 204 天前 via iPhone
@hakono 备案域名+国内 cdn 呗
boluo 7
boluo 204 天前
买代金券
LnTrx 8
LnTrx 204 天前
@hakono lightsail 有一个自带的 CDN，虽然本质上还是 cloudfront，但售卖、使用的方式对不少人来说更实惠
mason961125 9
mason961125 204 天前
生产环境还想着白嫖？喜欢灵车漂移？
wtks1 10
wtks1 204 天前 via Android ❤️ 1
@mason961125 楼主没说白嫖啊，他是想问没信用卡怎么充值

mason961125 11
mason961125 204 天前
@wtks1 #10 AWS 支持银联卡啊，储蓄卡都可以啊我记得。
shequ2046 12
shequ2046 204 天前
这太简单了，给我 100 就给你完美的充值解决方案。
shequ2046 13
shequ2046 204 天前
@LnTrx 和 Global Accelerator 比效果如何，国内是走 cn2+gia 么？目前项目用的是 Global Accelerator，流量开销蛮大的。。。打算试试看了。。。
shequ2046 14
shequ2046 204 天前
@hakono 新出的
shutongxinq 15
shutongxinq 204 天前
打电活给客服，有的是不同的付款方式
jadec0der 16
jadec0der 204 天前
aws 地址写中国，可以用银联卡人民币付款
jadec0der 17
jadec0der 204 天前 ❤️ 2
https://aws.amazon.com/cn/about-aws/whats-new/2019/06/us-commercial-regions-now-accept-chinese-yuan-payments-from-china-based-customers/
shequ2046 18
shequ2046 204 天前
简单测试了一下，CDN 用的是 cloudfront，国内延时 150+，完全没用，结束。
stabc 19
stabc 204 天前
@jadec0der LZ 说的是没有信用卡，不是没有外币信用卡。
oahebky 20
oahebky 204 天前 via Android
为什么用我老婆做头像
wql 21
wql 204 天前 via Android
没有信用卡就去办一张，或者中国银行 /中信银行 /工商银行搞一张外币标志的借记卡。
ljsh093 22
ljsh093 204 天前 via iPhone
这个 cdn 感觉开跟没开没区别啊？ ip 没变化线路也没变化，我 vps 开在日本，楼主是什么配置的？
dzdh 23
dzdh 204 天前
@wql @syqhcc
长城跨境通国际借记卡
https://www.boc.cn/bcservice/bc2/201704/t20170426_9329829.html

@mason961125 支持储蓄卡?美区也是?
nksky 24
nksky 204 天前
@shequ2046 cloudfront 有国内节点
fordoo 25
fordoo 204 天前
@nksky aws 海外版本没有国内节点，国内的话选择就太多了
dorothyREN 26
dorothyREN 203 天前
有做代付款业务的。

Android Studio的app工程编译生成的apk运行在手机或者模拟器。  有时为了调试一些工具类， 我们想运行Java代码在jvm中， 那该怎么办呢？

目前有2种方法 :
1、在Java文件中添加main方法，  鼠标点击到main方法里任意地方，  使得光标停在main函数里。 然后点击鼠标右键， 选择Run ‘MainActivity main()’或者Debug ‘MainActivity main’就行了。 too easy！！！

2、新建个Java  Library， 并设置运行方式。

点击Edit Configuration

选择Application后， 设置Name、Main class、Use class of Module并点击OK。

选择运行方式为Java， 然后点击绿色运行按钮就行了。

如何看待 Baidu Cloud CDN 回源 TTFB 高达 2.1 秒？
2 nobodynight · 203 天前 · 3064 次点击
这是一个创建于 203 天前的主题，其中的信息可能已经有所发展或是发生改变。
简述
这是一个技术讨论主题，与大家分享和探讨业务中遇到的问题。其中包含工程团队的一部分调查过程和结论，希望听一听大家的观点，指出调查结论中可能存在的错误或忽略的问题。

值得注意的是，请不要在该主题内添加任何与主题无关或违反社区指导原则的回复内容，包括但不限于：云计算服务提供商代理商销售广告、优惠活动和垃圾内容等。谢谢！

定义
CDN: Content Delivery Network 的缩写，指提供静态资源缓存和交付功能的一组地理上分散的服务器。
Baidu Cloud: 指公有云计算服务提供商 百度智能云，与 百度云加速 和 百度网盘 无关。
TTFB: Time To First Byte 的缩写，指等待初始 HTTP 响应（不包括内容下载）所花费的时间。
回源: 指当 HTTP 请求的静态资源未命中 内容分发网络 所有缓存层时向源服务器发起 HTTP 请求并拉取资源的行为。
其他未明确定义的词汇和术语，请参阅 Internet 上的定义。

调查
技术细节
根据 Baidu Cloud 提供的信息，Baidu Cloud CDN 采用三层缓存架构。其中*层为边缘服务器，第二层和第三层为中心源服务器。如果客户端请求的资源未命中*层、第二层和第三层缓存，则由第三层中心源服务器向源服务器发起回源请求并拉取资源，后由第三层、第二层和*层缓存，缓存策略和缓存驱逐策略是未明确定义的。

由于网络和成本优势，源服务器由 Tencent COS （ Tencent Cloud 提供的对象存储服务）提供。如果第三层中心源服务器请求的资源未命中 Tencent COS，则由 Tencent COS 向上游源服务器发起回源请求并拉取资源，后遵循对象生命周期策略进行存储。通常情况下，新的静态资源会主动推送到 Tencent COS 进行存储。

边缘服务器和中心源服务器之间通过公网建立连接，中心源服务器和源服务器通过公网建立连接，中心源服务器和源服务器均接入 BGP （ Border Gateway Protocol 的缩写）多线网络。

客户端和边缘服务器之间通过公网建立连接，采用基于 TCP/IP 的 TLS 1.3 和 HTTP/2 协议通信。中心源服务器（第三层）和源服务器之间采用基于 TCP/IP 的 TLS 1.2 和 HTTP/1.1 协议通信。

在调查过程中涉及的边缘服务器位于 中国-河南省-洛阳市，ISP （ Internet Service Provider 的缩写）为 中国电信。中心源服务器（第三层）位于 中国-山东省-青岛市，回源路由选择 ISP 为 中国电信。源服务器位于 中国-北京。

更多相关细节由于 Baidu Cloud 认为涉及商业机密（根据 商业保密协议 和 公司内部安全规定），故而没有提供。

发生了什么
在下文中我们将按照事情发生的先后次序讲述，时区均为 Asia/Shanghai 。

2020/8/30
工程团队发现现网某外部静态资源请求的 TTFB 增大至 1.2 秒左右，通过检查响应该请求的服务器 IP 地址和响应头部确定边缘服务器由 Baidu Cloud CDN 提供。进一步分析发现，当一个分段请求未命中缓存时可复现该问题。如果一个请求未命中缓存，那么流量将回到缓存服务器背后（上游）的源服务器，因此初步怀疑回源过程中可能存在问题。为快速排除源服务器可能存在的问题，工程团队即刻检查了监控台相关指标数据，但没有迹象表明源服务器工作异常。为进一步验证这些数据的正确性，工程团队使用内部 Analysis & Diagnosis 平台手动诊断源服务器的工作状况，其诊断过程包括从内部和外部向源服务器直接发送数个分段请求、等待响应和下载数据，诊断结果显示 TTFB 浮动于 88 ~ 110 毫秒之间，没有发现问题。

由于我们无法确定问题究竟发生在回源过程中的哪一个阶段，所以便通过 Baidu Cloud 工单系统向 Baidu Cloud CDN 团队提单询问回源流程、边缘服务器和中心源服务器的网络接入情况，以便于进一步定位问题原因。

2020/8/31
次日，我们收到 Baidu Cloud 工作人员在工单内提供的一些基本信息，并表示对于该问题乐意提供分析协助。为便于双方沟通和分析问题原因，工程团队在 Baidu Cloud CDN 发布了一个测试域名，并将其源服务器配置为在 Tencent COS 发布的测试 Bucket （对象存储桶），其中包含一个大小约 4.7 MB 的测试音频文件。为便于分析定位回源过程中潜在的问题，测试域名被配置为不缓存任何静态资源。

准备就绪后，我们通过 Baidu Cloud 工单系统在工单内进一步提供了工程团队的初步调查结论、复现方式和测试数据。值得一提的是，从客户端向测试域名发起的一个分段请求的 TTFB 增大至 1.4 秒，这可能是由于网络波动所致。

大约 3 个小时后，我们收到 Baidu Cloud CDN 团队在工单内提供的分析回复，称 TLS 协议的性能损耗和未配置缓存导致回源链路较长是造成该问题的原因，对此我们并不认同。首先 Baidu Cloud CDN 团队应该了解测试域名没有配置缓存的原因，其次全链路 TLS 协议的性能损耗（包括但不限于：握手和加解密数据等）理论上不应该如此之大，很显然这不是一个负责任的回复。

Baidu Cloud 工作人员在工单内收到我们的反驳回复后，称会再次向 Baidu Cloud CDN 团队核实该问题是否符合预期。

2020/9/1
次日，我们收到 Baidu Cloud CDN 团队产品经理在工单内的回复，称该问题是符合预期的，并认为未配置缓存是造成该问题的原因，单个例子无法体现问题。很显然这依旧不是一个负责任的回复，甚至怀疑 Baidu Cloud CDN 团队是否有就该问题进行过分析，我们对此感到非常失望。

为了进一步体现在该问题上 Baidu Cloud CDN 产品与其他服务提供商的差距，工程团队在其他上游 CDN 服务提供商（包括但不限于：Tencent Cloud 、Alibaba Cloud 和 Upyun 等）上发布了相同的测试域名和配置，然后进行了数个对比测试。结果显示在相同的测试方式下，到其他上游 CDN 服务提供商的分段请求的 TTFB 常见浮动于 270 毫秒左右，*低为 161 毫秒，*高为 297 毫秒。值得注意的是，上游 CDN 服务提供商之间的架构不同，因此对比测试的结果仅用于反应在一个或多个场景限定下的差距。

值得一提的是，当我们通过 Baidu Cloud 工单系统在工单内向 Baidu Cloud CDN 团队请求获取更多有关该问题和证明其观点的关键数据（包括但不限于：边缘服务器、中心源服务器和源服务器之间通信链路的延时、路由、丢包率和各流程耗时等）时没有得到任何回复。为进一步推动调查，无奈之下我们于次日通过 Baidu Cloud 提供的投诉渠道提交了有关投诉。

2020/9/3
令人高兴的是，这一举动似乎正在改变我们与 Baidu Cloud CDN 团队的沟通效率。在提交有关投诉后，我们于次日（ 9 月 3 日）接到了 Baidu Cloud 客户经理的来电，并就相关问题进行沟通协调。

大约一个小时后，我们收到 Baidu Cloud CDN 团队在工单内提供的测试数据和观点，其中包括但不限于从 Baidu Cloud CDN 中心源服务器（第三层）到源服务器的网络连通情况、DNS 调度结果、链路延时（ ICMPv4 ）、链路路由和使用 CURL 直接请求源服务器的连接、响应和用时情况（用户态、内核态和子进程）等。

工程团队立即对 Baidu Cloud CDN 团队提供的数据进行检查。Baidu Cloud CDN 团队认为源服务器响应用时过长是造成该问题的原因，因为从用时情况来看 CURL 进程的生命周期约 1.39 秒（包括但不限于等待 I/O 操作完成等）。进一步检查后发现，Baidu Cloud CDN 团队使用 CURL 从中心源服务器（第三层）向源服务器发起的 HTTP 请求不是分段请求，这意味着还额外包括完整的内容下载用时。

值得注意的是，1.39 秒内包括但不限于：DNS 解析查询、建立 TCP/IP 连接、TLS 握手、发送 HTTP 请求、等待 HTTP 响应头和下载 HTTP 响应内容等流程的用时。我们不认可 Baidu Cloud CDN 团队的观点，因为这些数据不能排除源服务器存在问题，也无法证明源服务器没有问题，在数据不足的情况下将 CURL 进程生命周期时间当作源服务器的响应用时未免有些牵强。

为获取从中心源服务器（第三层）到源服务器的 HTTP 请求的各个流程用时情况，工程团队通过 Baidu Cloud 工单系统在工单内请求 Baidu Cloud CDN 团队协助在中心源服务器（第三层）上重新执行带有给定参数的 CURL 命令行。给定的 CURL 命令行将向源服务器发送一个 HTTP 分段请求并下载内容的前 10 个字节，以测量 HTTP 请求的各个流程的用时情况。从 Baidu Cloud CDN 团队提供的给定 CURL 命令行的运行结果来看，从中心源服务器（第三层）到源服务器的 HTTP 请求 TTFB 为 236 ~ 395 毫秒，结果符合预期。

工程团队认为 Baidu Cloud CDN 的 Range 回源功能可能存在问题，无法以正确或*佳方式处理 HTTP 分段请求。边缘服务器或中心源服务器（第二层或第三层）在接收到源服务器的响应和响应内容后并未立即发送到上一层，其中的一层或多层可能存在策略缓冲逻辑。我们通过 Baidu Cloud 工单系统在工单内将这一观点告知于 Baidu Cloud CDN 团队。

Baidu Cloud CDN 团队在工单内收到我们的观点后通过电话与我们取得联系，Baidu Cloud CDN 团队的软件开发工程师认为我们的观点有误，并坚持认为该问题是由源服务器造成的。通过向 Baidu Cloud CDN 软件开发工程师核实，确认 Range 回源功能不包含策略缓冲逻辑，边缘服务器和中心源服务器在接收到源服务器的响应和响应内容后会即刻发送到上一层。

为进一步排除现有源服务器可能存在的问题，工程团队将测试域名的源服务器配置为在 BOS （ Baidu Cloud 对象存储服务）发布的测试 Bucket，其中包含的对象与现有 Bucket 一致。工程团队向测试域名发送了数个 HTTP 分段请求，然后等待响应和下载响应内容。测试结果相比预期更为严重，其 HTTP 分段请求的 TTFB 高达 1.57 ~ 2.17 秒。

令人失望的是，Baidu Cloud CDN 软件开发工程师依然坚持认为该问题是由源服务器造成的，理由是从客户端直接向源服务器发送数个 HTTP 请求，然后等待响应和下载响应内容的总用时为 3.3 ~ 3.6 秒，对此我们无法认同。僵持过后，Baidu Cloud CDN 软件开发工程师认为边缘服务器和中心源服务器（第二层和第三层）之间的公网链路较长是造成该问题的原因，因为:

从客户端向 BOS 发送一个 HTTP 请求、等待响应和下载响应内容总用时 1.18 秒。
从客户端向测试域名发送一个 HTTP 请求、等待响应和下载响应内容的总用时约 2.29 秒。
则边缘服务器和中心源服务器（第二层和第三层）之间的通信用时约 2.29 秒 – 1.18 秒 = 1.11 秒。这的确是有可能的，但是我们无法认同链路用时的计算方式。由于工程团队没有边缘服务器和中心源服务器或相关跟踪工具的直接访问权限，因此无法分析边缘服务器和中心源服务器之间的通信用时情况。

工程团队通过向测试域名首页发送数个 HTTP 请求、等待响应和下载响应内容以评估边缘服务器和中心源服务器的通信用时情况，从测试结果来看 TTFB 为 122 ~ 504 毫秒（常见于 250 毫秒左右），Baidu Cloud CDN 软件开发工程师的观点不成立。

Baidu Cloud CDN 团队未提供更多有关回复。

2020/9/7
数天后，我们收到 Baidu Cloud 工作人员在工单内的回复，称该问题正在进一步处理中。值得一提的是，Baidu Cloud 工作人员在向工单添加新回复的同时，将工单状态一并更改为待反馈状态。如果我们在有限时间内没有回复，该工单将被 Baidu Cloud 工单系统自动确认并关闭。在我们的追问之下，Baidu Cloud CDN 团队仍然声称该问题是符合预期的，更多技术细节由于安全规定无法对外提供。

*后，该工单被 Baidu Cloud 工作人员主动关闭。

调查结论
工程团队认为 Baidu Cloud CDN 边缘服务器和中心源服务器（第二层和第三层）可能没有正确处理 HTTP 分段请求，一个或多个回源流程可能存在问题。边缘服务器或中心源服务器（第二层或第三层）从源服务器接收到响应和响应内容后可能没有立即将其发送到上一层，其中一层或多层可能存在策略缓冲逻辑，造成当一个或多个 HTTP 分段请求未命中边缘服务器和中心源服务器（第二层和第三层）缓存并回源时 TTFB 增大至秒级。

边缘服务器和中心源服务器（第二层和第三层）之间的公网链路情况可能是进一步减轻或恶化该问题的原因之一，没有迹象表明源服务器是影响或造成该问题的原因之一。

总结
我们对 Baidu Cloud 调查和解决问题时的工作态度非常失望，自 2020 年以来也越发感觉 Baidu Cloud 工作态度和产品质量在不断下降。不可否认的是，如果一个静态资源已经缓存于边缘服务器或中心源服务器，则该问题在缓存驱逐前发生的可能性较低，但并不意味着问题不存在。

大家如何看待呢？

第 1 条附言 · 201 天前
9 月 19 日
第 2 条附言 · 201 天前
9 月 19 日
为进一步排除现有源服务器可能存在的问题，工程团队将测试域名的源服务器配置为在测试环境发布的测试静态资源服务器的 VIP 地址，其提供与现有 Bucket 一致的对象（文件），一名网络工程师使用内部 Analysis & Diagnosis 平台手动分析通过逻辑网络 L4 网关的流量和网络性能遥测数据。与 Tencent COS 或 BOS 不同，用于测试的静态资源服务器在处理一个或多个 HTTP 请求时不需要从底层数据库索引目标对象，这意味着 TTFB 将大约减少 100 毫秒左右，L4 网关与用于测试的静态资源服务器保持 TCP/IP 长连接。

工程团队分别使用 HTTP 和 HTTPS (TLS) 协议向测试域名发送了数个 HTTP 分段请求、等待响应和下载前 10 个字节的响应内容。对于 HTTP 协议，其分段请求的 TTFB 为 1.09 ~ 1.74 秒。对于 HTTPS (TLS) 协议，其分段请求的 TTFB 为 1.10 ~ 2.48 秒，罕见*高 3.95 秒。

通过检查已收集的网络性能遥测数据发现，源服务器使用 TCP/IP 协议向中心源服务器（第三层）发送数据时的丢包率*高为 0.0005%，实际网络延时为 32 毫秒左右。意外丢弃的数据包已重传，没有发现 TCP/IP 连接握手异常（包括但不限于：SYN Timeout、ACK Delayed 等），没有迹象表明源服务器和内网相关网络设备是造成丢包的原因之一。

进一步分析网络流量发现，Baidu Cloud CDN 中心源服务器（第三层）的一个或多个回源流程可能存在问题。中心源服务器（第三层）将使用 3 ~ 4 个 VIP 地址（可能对应集群内一台或多台服务器）按次序向源服务器发送 3 ~ 4 个 HTTP 请求，其中只有*后一个 HTTP 请求是分段请求，分段范围由原 HTTP 请求指定。每发送一个 HTTP 请求后，中心源服务器（第三层）将等待源服务器响应并下载响应内容，然后接着发送下一个 HTTP 请求。源服务器为每一个 HTTP 请求发送 HTTP 响应标头和响应内容的用时分别为小于 1 毫秒和 137 ~ 154 毫秒，从中心源服务器（第三层）接收下一个 HTTP 请求的间隔时间为 411 ~ 507 毫秒。

很显然中心源服务器（第三层）向源服务器发送多个 HTTP 请求、等待响应和下载响应内容的行为是造成该问题的原因之一。我们暂时无法确定该行为是否是一个错误或特性，Baidu Cloud CDN 团队拒*提供更多技术细节。

附 关于该主题内的多个回复：

测试数据来自多个不同地区的边缘服务器，暂没有迹象表明其中一个或多个地区的边缘服务器 IDC 是造成该问题的原因之一。
全球边缘网络由多个上游 CDN 服务提供商和云服务提供商组成，由调度系统决定将哪些地区和运营商的终端调度到 Baidu Cloud CDN。
baidu cloud 服务器 CDN19 条回复 • 2020-09-22 17:30:40 +08:00
ryd994 1
ryd994 203 天前 via Android ❤️ 1
要证明源服务器没问题，在源服务器抓包即可。先看看非 TLS 能否复现。不能复现的话可以考虑自签证书，部署到同一环境的另一台服务器上。

抓包同时可以确认是否有重传。1 秒以上的网络延迟是很罕见的。但是 Linux TCP syn timeout 就是 1 秒。所以超过秒的延迟非常可能是程序内部的问题或者 TCP 重传。

还有你这整个机翻腔，我看的时候感觉还是翻回英文更省力更容易理解。
ragnaroks 2
ragnaroks 203 天前
百度云减速?
opengps 3
opengps 203 天前 via Android
cdn 超过一秒确实有点离谱了
stevenhawking 4
stevenhawking 203 天前
哈哈哈哈 就在几天前, BaiduTrust 重新定义免费的事情还记得吗?
bunnyblueair 5
bunnyblueair 203 天前
没有百度账号 无法评论
whitehack 6
whitehack 203 天前
还有大可能是 腾讯的源服务器会给你加上延迟.
因为我遇到过. 简单点说就是一个小 CDN 提供商 -> 去腾讯服务器回源, 速度比你这慢多了. 0.2 秒-10+秒

去其它任何云服务商的服务器回源都没有发现问题.

所以.往这个方向上去测试看看吧. 说不定百度云就是个背锅的
whitehack 7
whitehack 203 天前
再补充一下, 只有 那个 CDN 提供商的 IP 去回源才慢. 用其它多个 ip 都没有发现问题.
billlee 8
billlee 203 天前
其它边缘节点有没有问题，CDN 边缘机房的可靠性不高
kangsheng9527 9
kangsheng9527 203 天前
cdn 的话还是使用，google groupcache 分片式*好。。。
xuzheliang 10
xuzheliang 203 天前
@whitehack 如果真是这样，那可真是太险恶了。不是被人提醒，很难发现

AlexaZhou 11
AlexaZhou 203 天前
直接用脚投票吧，换 阿里 /腾讯 /华为 云
Niphor 12
Niphor 203 天前
周末有瓜吃
realpg 13
realpg 202 天前
换个正经的 CDN 提供商不香么
nobodynight 14
nobodynight 201 天前
@ryd994 是的，只是之前没有迹象表明源服务器是造成该问题的原因之一。现已分析网络流，请您参阅该主题的附言部分哈。经网络的同学确认，没有发现 SYN Timeout 或 TCP Timeout Retrans 现象。至于是否易于理解的问题，我个人感觉还好，内容摘录自内部调查报告的一部分。
nobodynight 15
nobodynight 201 天前
@whitehack 这个问题建议您先排查一下 CDN 服务提供商的回源 IDC 到源服务器的网络路由情况，也可以进一步分析一下 Tencent Cloud 网内的网络流和源服务器日志。如果没有找到问题，可以提工单让 VPC 的同学协助看下。也许您可以提供更多细节？
nobodynight 16
nobodynight 201 天前
@billlee 暂没有迹象表明其中一个或多个地区的边缘服务器 IDC 是造成该问题的原因之一，详情请您参阅该主题的附言部分哈。
mytsing520 17
mytsing520 200 天前
可考虑部署前端 HTTPS 到后端 HTTP 的方式绕开未命中的情况
mytsing520 18
mytsing520 200 天前
打错，是回源阶段 TTFB 时间长
nobodynight 19
nobodynight 199 天前
@mytsing520 目前 TLS 1.2 握手用时为 100 ~ 150 毫秒左右，暂没有迹象表明 TLS 是造成该问题的主要原因之一。中心源服务器（第三层）通过公网与源服务器建立 TCP 连接通讯，放弃 TLS 将导致部分链路的数据传输不受保护，且不合规。

naoh1000 · 202 天前 · 5795 次点击
这是一个创建于 202 天前的主题，其中的信息可能已经有所发展或是发生改变。
经常看见使用 OpenSSH Client 连接服务器的 V 友。想问一下这样怎么上传文件到服务器（比如密钥一类的）是不是还需要安装一个 SFTP 客户端，这样的话为什么不直接安装 Xshell 类的工具？ scp 命令太麻烦了。

服务器 上传 sftp scp64 条回复 • 2020-09-22 09:39:54 +08:00
daimaosix 1
daimaosix 202 天前 ❤️ 1
使用 rz 和 sz 命令试试
youngxuesong 2
youngxuesong 201 天前
yum install lrzsz
了解下 rz 和 sz 命名
nonduality 3
nonduality 201 天前
如果是在 Linux/Mac 下，安装 lftp，然后 lftp sftp://remote_host，就能以 ftp 的方式上传下载文件、文件夹，超级方便。
vision1900 4
vision1900 201 天前
服务器上安装 filebrowser: https://github.com/filebrowser/filebrowser
然后就会获得一个优雅安全的 Web 界面
masker 5
masker 201 天前 via Android ❤️ 8
scp 搭配 ssh config 怎么会麻烦呢
xcstream 6
xcstream 201 天前
winscp
IvanLi127 7
IvanLi127 201 天前 via Android
rsync
des 8
des 201 天前
sshfs
geekvcn 9
geekvcn 201 天前 via iPhone
scp 指令或者 gui 封装软件比如 winscp 之类的
everydaystruggle 10
everydaystruggle 201 天前
可以试试 mobaxterm

37Y37 11
37Y37 201 天前 ❤️ 1
很多支持 zomdem 协议的客户端，都可以用 rzsz 命令进行上传下载，关于 zomdem 协议介绍及实现，之前在写 webssh 项目的时候写过这篇文章介绍： https://blog.ops-coffee.cn/s/poc2i859lqwiy1usq2rfjw
charlie21 12
charlie21 201 天前
MobaXterm 完事了，啥命令都不用记
smilingsun 13
smilingsun 201 天前 via Android
今天看 Chromebook 上看到一个 sftp mount，挺直观的。
Windows 也可以 http://makerlab.cs.hku.hk/index.php/en/mapping-network-drive-over-ssh-in-windows
prasanta 14
prasanta 201 天前 via Android
nc
superlc 15
superlc 201 天前 via iPhone
mac 的话 iterm2 装了插件可以直接拖到窗口里
priaaa2019 16
priaaa2019 201 天前
https://www.bitvise.com/ssh-client
小白建议用这个，基本全解决了。
vhysug01 17
vhysug01 201 天前
scp，nc 都很好用呀，怎么会麻烦？
包括现在编辑器都有 sftp 插件，可以选择文件夹直接上传的，用来本地编辑代码，服务器运行，特别方便
HertzHz 18
HertzHz 201 天前
还是 XShell 好
JavaIO 19
JavaIO 201 天前
一般分为 Windows 电脑或者 mac 电脑上传文件到 linux 服务器或者 Windows 服务器的好几种情况，

具体的步骤可以看详细文档教程：leffz.com/ssh

如果觉得麻烦的话，可以在服务器安装宝塔面板，直接在后台面板上传文件很简单。
CallMeReznov 20
CallMeReznov 201 天前
用习惯命令行 scp 后 什么 rz sz 完全没有在想过.
fs418082760 21
fs418082760 201 天前
你需要这个 MobaXterm，神器！
opiviqo 22
opiviqo 201 天前
nc scp
yeqizhang 23
yeqizhang 201 天前
@vision1900 这个 go 写的程序是真的棒。*近用过好几个好用的工具都是 go 语言写的。
ShallowAi 24
ShallowAi 201 天前 via Android
WinSCP 一直用这个
icegaze 25
icegaze 201 天前 via Android
*简单的不是 filezillaFtp 吗？
有 windows 版本客户端
jiangzm 26
jiangzm 201 天前
不明白 scp 命令麻烦在哪里，认证和 ssh 一样啊
AoTmmy 27
AoTmmy 201 天前 via Android
推荐 Termius，好看好用，全端同步
不过新版重新连接的按钮没了是真蛋疼。。
edk24 28
edk24 201 天前
scp 命令 远程拷贝
xiadong1994 29
xiadong1994 201 天前 via iPhone
scp 就是 cp 的变种，有什么麻烦的？
psterman 30
psterman 201 天前
@vision1900 #4 安装时提示已经拒*连接
LokiSharp 31
LokiSharp 201 天前 via iPhone
sftp
Desiree 32
Desiree 201 天前
命令才是*快的
arch9999 33
arch9999 201 天前
ssh-copy-id: ???
lysS 34
lysS 201 天前
我上传到云，再 url 下载
NerverLibis 35
NerverLibis 201 天前 via iPhone
openssh 本身就支持 sftp…你这什么问题？
yalin 36
yalin 201 天前
zmode 协议
HannibaI 37
HannibaI 201 天前
Host *
ServerAliveInterval 180
Compression yes

ControlMaster auto
ControlPath /tmp/ssh_%r@%h:%p
ControlPersist 2h

Host server
HostName 10.0.0.xxx
User
xxxx

$ ssh-copy-id server
$ scp ./FC2-PPV-10086 server:~
Themyth 38
Themyth 201 天前
我在 Mac 下用的是 sftp 命令 ……
njwangchuan 39
njwangchuan 201 天前
少量文件：scp
文本、代码类：git 命令他不香吗
媒体类文件：sftp
云存储工具：s3cmd
ruicky 40
ruicky 201 天前
*近刚好有这个需求，我的解决方案：
Windows：xshell 使用 rs -y 命令调出选择文件，上传即可。
Mac OS：SecureCR，需要上传文件时，托转到窗口，选择 zmodoulm upload

一闪都能满足需求。
dany813 41
dany813 201 天前
收藏下
handsomeroger 42
handsomeroger 201 天前
推荐 MobaXterm
Flash1 43
Flash1 201 天前
sftp
Flash1 44
Flash1 201 天前
xshell 自带
hzjseasea 45
hzjseasea 201 天前
scp nc
Akesudia 46
Akesudia 201 天前
WinSCP 就是图形化的 scp，不用改服务器配置。
xabc 47
xabc 201 天前
dlload.com 内网部署一个
way2explore2 48
way2explore2 201 天前
rsync +1
ryanlid 49
ryanlid 201 天前
ssh-copy-id -i ~/.ssh/id_rsa.pub user@ip
weifan 50
weifan 201 天前
@youngxuesong 这个要看协议是否支持
Sheldon1898 51
Sheldon1898 201 天前
scp 语法基本和 cp 差不多，用了 scp，再没用过 winscp 和 xftp
wangchonglie 52
wangchonglie 201 天前
我觉得自己搭建一个小型的文件共享服务器很方便~
shuax 53
shuax 201 天前
winscp 可视化传文件
Bantes 54
Bantes 201 天前
kodexplorer?
liuzhaowei55 55
liuzhaowei55 201 天前 via iPhone
rsync 命令行工具
vscode remote 可视化工具
oneisall8955 56
oneisall8955 201 天前 via Android
偶尔上传文件 scp *简单了，没必要安装其他的
no1xsyzy 57
no1xsyzy 201 天前
https://lists.mindrot.org/pipermail/openssh-unix-dev/2019-March/037672.html
The scp protocol is outdated, inflexible and not readily fixed. We
recommend the use of more modern protocols like sftp and rsync for
file transfer instead.

OpenSSH 团队已经不推荐使用 SCP 了

另外一个很邪道的东西：
https://linux.cn/article-12606-1.html
jupyter 作为远程管理控制台……
太邪门了，但我根本找不出可以反驳的点，jupyter 作为远程管理控制台基本没什么毛病
libook 58
libook 201 天前
需要频繁进行文件操作，GUI 肯定是*方便的，其次是将远程文件系统 mount 到本地，再次是使用 scp 、rsync 之类的指令。

如果本地有桌面环境的话，Linux 可以用桌面自带的文件管理器直接走 SFTP 连目标服务器，Windows 和 MacOS 可以用开源、安全、功能齐全的 Cyberduck，或者不在乎捆绑商业性组件就用 Filezilla 。

直接 mount 的话可以考虑用 SSHFS 。
newtype0092 59
newtype0092 201 天前
@jiangzm 之前一直 scp，后来加了一层跳板机，禁止外网连接了，scp 有什么方法过跳板机么？
yulgang 60
yulgang 201 天前
关键字 Mount remote directory using SSH
shaojz2005 61
shaojz2005 201 天前
@priaaa2019 这个是很不错
wizardoz 62
wizardoz 201 天前
scp 配合 ohmyz.sh 你值得拥有
UnknownR 63
UnknownR 201 天前
Termius 你值得拥有
ZocXTerminal 也还可以
我只想把文件拖进去就可以上传
Joyboo 64
Joyboo 200 天前
@AoTmmy termius 是好用，但不支持 szrz，这是致命的一点

填充多边形（fill）

概述
fill函数的功能是根据结点之间连线的封闭区域绘制多边形。

fill函数的签名为：matplotlib.pyplot.fill(*args, data=None, **kwargs)

参数说明如下：

*args：根据x,y位置确定结点绘制多边形，可添加一个可选的颜色标记。数据结构为x, y, [color]序列，支持多组x, y, [color]序列。必备参数。
*args的应用方式如下：

plt.fill(x, y)
plt.fill(x, y, “b”)
plt.fill(x, y, x2, y2)
plt.fill(x, y, “b”, x2, y2, “r”)

data：带标签的数据对象。可索引对象。可选参数。
例如：plt.fill(“time”, “signal”, data={“time”: [0, 1, 2], “signal”: [0, 1, 0]})

**kwargs：matplotlib.patches.Polygon对象的相关属性。

fill函数的返回值为matplotlib.patches.Polygon对象列表。

案例1
注意！多边形是根据数据的顺序依次绘制的，因此，相同的结点由于顺序不同可能填充出来的多边形效果也不同。
例如：同样的数据，*个子图绘制了封闭五边形，第二个子图未绘制封闭的五边形，注意结点的次序。
如果想绘制封闭的多边形需要逆时针依次绘制（坐标点位置）。

import numpy as np
import matplotlib.pyplot as plt

a = [5, 10, 15, 10, 5]
b = [5, 5, 10, 15, 10]

c = [5, 5, 10, 15, 10]
d = [5, 10, 5, 10, 15]

e = [1, 2, 2, 1]
f = [3, 3, 4, 4]

plt.subplot(221)
plt.plot(a, b, ‘o’)
plt.fill(a, b, ‘r’)
for index, item in enumerate(zip(a, b), 1):
plt.text(item[0], item[1], index)

plt.subplot(222)
plt.plot(c, d, ‘o’)
plt.fill(c, d, alpha=0.5)
for index, item in enumerate(zip(c, d), 1):
plt.text(item[0], item[1], index)

plt.subplot(223)
plt.fill(e, f)

plt.subplot(224)
plt.fill(“time”, “signal”,
data={“time”: [2, 4, 4], “signal”: [3, 4, 3]})

plt.show()

案例2

import numpy as np
import matplotlib.pyplot as plt

x = np.linspace(0, 5 * np.pi, 1000)

y1 = np.sin(x)
y2 = np.sin(2 * x)

plt.fill(x, y1, color=”g”, alpha=0.3)
plt.fill(x, y2, color=”b”, alpha=0.3)

plt.show()

找不同

LeetCode——找不同
题目描述：
给定两个字符串 s 和 t，它们只包含小写字母。

字符串 t 由字符串 s 随机重排，然后在随机位置添加一个字母。

请找出在 t 中被添加的字母。

示例 1：

输入：s = “abcd”, t = “abcde”
输出：“e”
解释：‘e’ 是那个被添加的字母。
示例 2：

输入：s = “”, t = “y”
输出：“y”
示例 3：

输入：s = “a”, t = “aa”
输出：“a”
示例 4：

输入：s = “ae”, t = “aea”
输出：“a”

提示：

0 <= s.length <= 1000
t.length == s.length + 1
s 和 t 只包含小写字母

来源：力扣（LeetCode）
链接：https://leetcode-cn.com/problems/find-the-difference
著作权归领扣网络所有。商业转载请联系官方授权，非商业转载请注明出处。

解题思路：

解法一：

我们将两个字符串分别用两个字典存储起来，字符作为键，该字符的出现次数作为值。
然后我们遍历dic_t，判断该字符是否在dic_s中，如果不在就说明他是加进去的字符，返回即可；如果在，则判断其在两个字典中对应的值是否相同（即出现次数），如果相同则继续遍历，如果不同则说明他是加进去的字符，返回即可。

解法二：

我们先将两个字符串排序好；
再遍历比较，若两个字符不同则说明是新加的，返回即可。

解法一python代码：

class Solution(object):
def findTheDifference(self, s, t):
“””
:type s: str
:type t: str
:rtype: str
“””
dic_s = {}
dic_t = {}
for str_s in s:
if str_s in dic_s:
dic_s[str_s] += 1
else:
dic_s[str_s] = 1
for str_t in t:
if str_t in dic_t:
dic_t[str_t] += 1
else:
dic_t[str_t] = 1
for key in dic_t.keys():
if key in dic_s:
if dic_t[key] == dic_s[key]:
continue
else:
return key
else:
return key

解法二python代码：

class Solution(object):
def findTheDifference(self, s, t):
“””
:type s: str
:type t: str
:rtype: str
“””
s = sorted(s)
t = sorted(t)
for i in range(len(t)):
if i < len(s):
if t[i] == s[i]:
continue
else:
return t[i]
else:
return t[i]

利用python实现利用追赶法解决线性方程组

追赶法
大二在读，能力有限，轻喷
python实现追赶法解方程组，通篇都是低级函数，适合初学者学习

jieshu=int(input(“矩阵的阶数：”))
print(“请输入a”)
a=[]
for i in range(jieshu-1):
x=float(input())
a.append(x)
print(“请输入b”)
b=[]
for i in range(jieshu):
x=float(input())
b.append(x)
print(“请输入c”)
c=[]
for i in range(jieshu-1):
x=float(input())
c.append(x)
print(“请输入f”)
f=[]
for i in range(jieshu):
x=float(input())
f.append(x)
beita=[]
arf=[]
y=[]
x=[]
for i in range(jieshu-1):
beita.append(0)
for i in range(jieshu):
arf.append(0)
for i in range(jieshu):
y.append(0)
for i in range(jieshu):
x.append(0)
for i in range(jieshu-1):

if i == 0:
beita[0]=c[0]/b[0]
else:

beita[i]=c[i]/(b[i]-a[i-1]*beita[i-1])
for i in range(jieshu):
if i==0:
y[0]=f[0]/b[0]
else:
y[i]=(f[i]-a[i-1]*y[i-1])/(b[i]-a[i-1]*beita[i-1])
for i in range(jieshu):
wuhu=jieshu-i
if wuhu==jieshu:
x[jieshu-1]=y[jieshu-1]
else:
x[wuhu-1]=y[wuhu-1]-beita[wuhu-1]*x[wuhu]
print(‘beita=’,beita)
print(‘y=’,y)
print(‘x=’,x)
for i in range(jieshu):
print(‘x’,i+1,’=’,x[i])

在写程序的时候总会遇到测试一个小的功能或者算法，这个时候如果每次都通过运行android程序来测试就太浪费时间了。studio也可以直接运行java程序。下面就直接贴步骤：

1 在已经建立的项目中添加新的module，然后选择JavaLibrary

2 填写新的module的信息，然后会生成对应的module和类，这个时候会有新的build.gradle生成

3这个时候已经完成了创建。但是不能直接点击运行键，这个时候需要设置一下。然后选择application，通过配置Name,mainclass, module名称来实现运行的配置。

4 配置之后就可以直接运行了。如果想要删除掉的话，直接在项目的settings.gradle文件中删除对应的module就可以。