curl命令详细使用以及一次自己挖坑自己跳的经历|王彬的博客

wangbin
2020-01-01
IT

curl命令详细使用以及一次自己挖坑自己跳的经历

一. 简介

linux下如果想下载什么东西，第一想到的应该就是使用curl了，我们对它很熟悉，可其实又没那么熟悉

二.我们熟悉的curl

显示一个https h5内容

curl https://wangbin.io

下载文件

curl https://wangbin.io/blog/it/cdn.html -o cdn.html

直接使用链接名字命名

curl https://wangbin.io/blog/it/cdn.html -O

post上传文件

curl https://wangbin.io -F "a=test"

三.我们不熟悉的curl

除了上面那些常用的用法，还有很多我们不熟悉的

下载ftp文件

curl ftp://xxx.com/xxx.zip -u "用户名:密码" -o xxx.zip

curl不只支持HTTP、HTTPS协议文件的访问，还支持FTP、FTPS、TFTP、SFTP、Gopher、SCP、Telnet、DICT、FILE、LDAP、LDAPS、IMAP、POP3、SMTP和RTSP。

这个比较神奇，之前一直以为只支持HTTP、HTTPS，后面我们继续补充其他协议的使用方法

代理

curl https://wangbin.io -x 127.0.0.1:8888

使用本地127.0.0.1:8888的代理，一般是Charles或者Fiddler提供的代理服务

cookies

待补充

使用特定加密协议访问

使用openssl的ECDHE-RSA-AES128-GCM-SHA256协议访问https://svn.siyou325.com

mac上使用

curl --ciphers ECDHE-RSA-AES128-GCM-SHA256 https://svn.siyou325.com/svn -v

centos7上使用

curl --ciphers ecdhe_ecdsa_aes_128_gcm_sha_256 https://svn.siyou325.com/svn -v

两个系统之间有些差别

可以使用

openssl ciphers

查看都有哪些算法

四. 一次自己挖坑自己跳的经历

还记得上篇讲的自己搭建cdn吗，结果wangbin.io、wiki.wangbin.io、git.wangbin.io都是没问题的，但是svn.siyou325.com却是坏的。

之前也用aws的cdn服务CloudFront，svn也用不起来，当时也没找到解决方法，所以svn一直是没用过cdn的。

这次自己搭建cdn，svn也不能用，心里不是很爽，这次想找到是啥原因，最好能解决，毕竟刚买了个好的服务器搭建自己的cdn

那为啥svn直接访问源站是好的，访问自己搭建的cdn就是坏的呢？

我用的是Mac笔记本，svn客户端用的是Cornerstone，抓包工具是Charles，打开Charles然后设置Cornerstone的代理为127.0.0.1:8888,update下，发现链接服务端用的是TLSv1(TLS_RSA_WITH_AES_128_CBC_SHA)算法

本地修改/etc/hosts文件，将svn.siyou325.com的ip改为我的cdn服务器ip，然后用Cornerstone update代码，发现在ssl handshake阶段就报错了。

换回源ip就是好的，用cdn的ip就是坏的，来来回回试了好几天，中间查了nginx的日志也没发现啥其他问题，我的nginx前面还用了haproxy，查了haproxy的日志，也没发现啥报错，一直心里郁闷着不知道啥原因，所以有空就尝试尝试，就这样郁闷了好几天

一直不太能理得清思路，不过cdn不支持Cornerstone请求用的TLSv1(TLS_RSA_WITH_AES_128_CBC_SHA)协议，这个慢慢的确认了，问题可能就是在这里

那是否有个命令，可以让我指定使用TLSv1(TLS_RSA_WITH_AES_128_CBC_SHA)协议访问服务端，来进一步验证自己的想法呢，没错，就是使用curl

curl --ciphers ECDHE-RSA-AES128-GCM-SHA256 https://svn.siyou325.com/svn -v

使用这个命令的效果和Cornerstone更新代码的效果是一样的，/etc/hosts指定源ip可以正常访问通，指定cdn的ip，则ssl handshake阶段报错

又在找原因找了几天，试过查看服务器上nginx使用的哪个版本openssl

nginx -V

发现源服务器和cdn服务器用的相同的openssl版本"built with OpenSSL 1.0.2k-fips 26 Jan 2017"

试过查看服务器上openssl支持哪些算法，

# 查看openssl版本
openssl version
# openssl支持哪些算法
openssl ciphers 
# egrep加粗显示
openssl ciphers | egrep --color 'ECDHE-ECDSA-AES128-GCM-SHA256'

发现ECDHE-ECDSA-AES128-GCM-SHA256都是支持的，这就比较烦躁了，束手无策的感觉

网上搜了下类似的解决方法是升级下svn客户端，确实，我本地svn命令行的版本号是1.10.3，svn up是好的，但是Cornerstone不行，支持最高的svn版本号是1.8，应该是Cornerstone用的老的https算法的缘故

后来想着是否是这个域名的nginx配置有问题，我试试同在cdn这个服务器上的其他服务，是否是正常的呢？如果其他服务没问题，只有这个有问题，那么我就可以确定是我的配置的哪处地方错了，可以继续在这块深入下去

curl --ciphers ECDHE-RSA-AES128-GCM-SHA256 https://files.siyou325.com -v

试了https://files.siyou325.com,结果可以正常访问，那么就是我这个域名的配置有问题了

那简单，将https://files.siyou325.com的配置文件files.siyou325.com.conf内容拷贝到svn-mycdn.siyou325.com.conf,修改域名为svn.siyou325.com,然后执行

nginx -t
nginx -s reload

重新配置nginx之后，执行

curl --ciphers ECDHE-RSA-AES128-GCM-SHA256 https://files.siyou325.com -v

发现竟然是好的，万幸，那逐步修改配置提供cdn服务，看看哪一步报错就好了

结果一步步配置，最后提供了svn的cdn服务，竟然也没报错，这就神奇了

找到之前有问题的配置，然后比较了下两个的不同之处，结果发现是自己的不细心造成的，还记得之前我们说的搭建cdn的nginx配置文件么

www-mycdn.wangbin.io.conf

## backend
upstream io_wangbin_www-data  {
    # server 192.168.16.32:59002 weight=1;
    server www-data.wangbin.io:443;
}

# www-mycdn.wangbin.io;
server {

    listen       50443 ssl http2;
    listen       [::]:50443 ssl http2;

    server_name  wangbin.io;
    server_name  www.wangbin.io;

    # ssl
    ssl_certificate             /vps/save/certificate/acme/*.wangbin.io_ecc/fullchain.cer;
    ssl_certificate_key         /vps/save/certificate/acme/*.wangbin.io_ecc/*.wangbin.io.key;
    ssl_trusted_certificate     /vps/save/certificate/acme/*.wangbin.io/fullchain.cer;

    # ecc
    ssl_certificate             /vps/save/certificate/acme/*.wangbin.io_ecc/fullchain.cer;
    ssl_certificate_key         /vps/save/certificate/acme/*.wangbin.io_ecc/*.wangbin.io.key;

    # log
    access_log                  logs/wangbin.io/wangbin.io/access-wangbin-mycdn.io.log siyou325;
    error_log                   logs/wangbin.io/wangbin.io/error.log;

    # header
    add_header  X-Robots-Tag    "";

    location / {
        proxy_pass  https://io_wangbin_www-data;

        proxy_set_header Host www-data.wangbin.io;
        proxy_set_header X-Real-Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        # # proxy-protocol
        # proxy_set_header X-Real-Ip $proxy_protocol_addr;

        proxy_ssl_server_name on; # 要加上这个，不然会报502错误， peer closed connection in SSL handshake while SSL handshaking to upstream
        proxy_redirect off;
        proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
        proxy_max_temp_file_size 0;
        proxy_connect_timeout      90;
        proxy_send_timeout         90;
        proxy_read_timeout         90;
        proxy_buffer_size          4k;
        proxy_buffers              4 32k;
        proxy_busy_buffers_size    64k;
        proxy_temp_file_write_size 64k;
    }

}

看看第一个ssl_certificate的配置

/vps/save/certificate/acme/*.wangbin.io_ecc/fullchain.cer;

这儿配置的是"*.wangbin.io_ecc"，但是其实应该是"*.wangbin.io"

原因是https证书有两种，姑且叫普通的https证书和ecc证书，ecc算法更优一些，也更安全，之前为了尝试，这两个证书我都申请配置了

第一个ssl_certificate配置普通的https证书，第二个ssl_certificate配置ecc证书，这样可以在最新的浏览器上使用ecc证书，更加安全，在Cornerstone这样还使用老的https算法的地方，使用普通证书，增加通用性，毕竟我们对安全性的要求也不高

结果这儿掉进了沟里，太不应该了，做事不够仔细

四. 总结

curl命令用法很多，后面有用到新的再继续补充

我真的是不太细心，已经因为这个做错了好多事，即使告诫自己要细心，也还是会再犯，后面继续注意吧，只能这样啦，祈祷

参考：