curl 메모 2020

개시하다

https://qiita.com/hijili/items/63a7ed4885974810e036
맨을 읽는다고 하지만 컬의 맨은 좀 넉넉한 부분이에요.
이것은 얼렁뚱땅하지만 찾기 어려운 사용법을 기록하는 비망록이다.
위에서 말한 바와 같이 Qita의view 수는 많은데 업데이트가 안 됐구나...그래서 젠으로 옮겼어요.이 프로그램은 다음 버전의 WSL 환경(Fedora Remix for WSL)에서 방송된다.(버젼 때 프로토콜 같은 게 나왔는데...)

$ curl --version
curl 7.66.0 (x86_64-redhat-linux-gnu) libcurl/7.66.0 OpenSSL/1.1.1g-fips zlib/1.2.11 brotli/1.0.7 libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.2.0) libssh/0.9.4/openssl/zlib nghttp2/1.41.0
Release-Date: 2019-09-11
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS brotli GSS-API HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz Metalink NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets

$ uname -a
Linux xxx 4.4.0-18362-Microsoft #1049-Microsoft Thu Aug 14 12:01:00 PST 2020 x86_64 x86_64 x86_64 GNU/Linux

버젼 조심하세요.

예를 들어centos만 상당히 큰 차이가 있다(이하 2010/09/23시).실행 환경이 불안정할 때 하위 옵션이 호환되지 않도록 주의하십시오.
centos8: curl-7.61.1-12.el8.x86_64.rpm
http://mirror.centos.org/centos/8/BaseOS/x86_64/os/Packages/
centos7: curl-7.29.0-57.el7.x86_64.rpm
http://mirror.centos.org/centos/7/os/x86_64/Packages/
centos6: curl-7.19.7-53.el6_9.x86_64.rpm(2010/11/30 지원 종료)
http://mirror.centos.org/centos/6/os/x86_64/Packages/

시간 초과 연결

시간을 초과하면 주위에 빠지기 쉽다.대충 이하로 조절하면 됩니다.
일반적으로 -m{대기의 극한초}를 더하면 기본적으로 k(잡다)
-m가 없으면 중간에 대답이 없으면 평생 찔려 다칠 수 있으니 주의하세요.

--connect-timeout <seconds>

서버에 연결하는 시간 초과입니다.기본값은 300s(후술)

-m | --max-time <second>

curl 전체 처리에 필요한 시간의 최대 값

--retry <num>

실패(시간 초과 또는 5xx)의 재시도 횟수(기본 0)
처음엔 1초, 다음에도 안 되면 2초, 이렇게 곱절로 기다려서 최대 10분까지
이 일대는 --retry-delay와 --retry-max-time로 지정할 수 있습니다
이해하기 어려우니까 한번 해보고 싶은데 아무래도 선조들이 계셔서...

각종 도구의 시간 초과 설치 집합.md at master · hiboma/hiboma · GitHub

curl, wget,nc 등 시간 초과 기본값도 검증되었습니다.

여담:--happy-eyballs-timeout-ms

happy-eyeballs 알고리즘 v6 우선 시간?(기본 200ms)
오랫동안 이런 옵션을 못 봤어요...(7.59.0부터 시작).happy-eyeballs는 v6와 v4 두 마리 모두 갈 수 있는 견우가 있을 때 사용하는 비교적 좋은 물건(잡다)으로 v6 우선초를 지정하는 것 같다.man의 설명과 RFC 6555(8305 업데이트)의 설명이 일치하지 않습니다... 아, 깊이 들어가지 마세요(여보세요

시간 초과 기본값 토크

만약 아무것도 시간을 초과하지 않았다면, 값은 얼마입니까?이런 말은 간혹 나오지만 맨에도 쓰여 있지 않다.이것은 환경 요소를 포함한다.
예를 들어 아무리 해도 닿지 않는 곳에서curl을 치면 AWS의 Amazon Linux1미묘한 end of life 접근 같은 경우 2분 정도 시간이 초과된다.Connection timed out으로 표시(exit code 7)

[AmazonLinux]$ time LANG=C curl -v 8.8.8.8:81
* Rebuilt URL to: 8.8.8.8:81/
*   Trying 8.8.8.8...
* TCP_NODELAY set
* connect to 8.8.8.8 port 81 failed: Connection timed out
* Failed to connect to 8.8.8.8 port 81: Connection timed out
* Closing connection 0
curl: (7) Failed to connect to 8.8.8.8 port 81: Connection timed out

real    2m9.518s
user    0m0.006s
sys     0m0.005s

사용 중인 WSL1 환경일 경우 20초 동안 시간이 초과됩니다.Connection refused (exit code 7)

[WSL1 fedora-limix]$ time LANG=C curl -v 8.8.8.8:81
*   Trying 8.8.8.8:81...
* TCP_NODELAY set
* connect to 8.8.8.8 port 81 failed: Connection refused
* Failed to connect to 8.8.8.8 port 81: Connection refused
* Closing connection 0
curl: (7) Failed to connect to 8.8.8.8 port 81: Connection refused

real    0m21.037s
user    0m0.000s
sys     0m0.047s

WSL2라면 30초가 초과된다(이것은 의외의 경험이고 예상치 못한 실패다.Connection timed out으로 표시(exit code 7)

[WSL2 fedora-limix]$ time LANG=C curl -v 8.8.8.8:81
*   Trying 8.8.8.8:81...
* TCP_NODELAY set
* connect to 8.8.8.8 port 81 failed: Connection timed out
* Failed to connect to 8.8.8.8 port 81: Connection timed out
* Closing connection 0
curl: (7) Failed to connect to 8.8.8.8 port 81: Connection timed out

real    0m32.123s
user    0m0.018s
sys     0m0.001s

이게 무슨 차이야.응, 리눅스의 동작은 스트리트에서 보는 게 좋을 거야.

$ strace -s0 -ft curl -v 8.8.8.8:81
12:00:15 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
  :
12:00:15 connect(3, {sa_family=AF_INET, sin_port=htons(81), sin_addr=inet_addr("8.8.8.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
  :
12:00:00 poll([{fd=3, events=POLLOUT|POLLWRNORM}], 1, 0) = 0 (Timeout)
  :
12:00:00 poll([{fd=3, events=POLLOUT}], 1, 1000) = 1 ([{fd=3, revents=POLLOUT|POLLHUP}])

# AmazonLinux
12:02:25 getsockopt(3, SOL_SOCKET, SO_ERROR, [110], [4]) = 0

# WSL1
12:00:00 getsockopt(3, SOL_SOCKET, SO_ERROR, [ECONNREFUSED], [4]) = 0

connect시스템에서 호출한 후 돌아오는 시간은errno와 다르다.그렇다면 connect시스템에서 호출한 후에 어떻게 될까요? 그렇다면 리눅스는 당연히 리눅스 내부에서 실행된 것이고 WSL은 윈도 시스템으로 전환되어 호출되었는데... 이 부근의 사이트는 비교적 이해하기 쉽다고 생각합니다.이 점에 따라 아무것도 지정하지 않을 때의 동작도 달라진다.
WSL 아키텍처 - roy-n-roy 노트

일반 Linux의 TCP 시간 초과로 curl 오류 발생

Amazon Linux(통상적인 Linux)의 경우 상술한 시간 초과 조사에서도 나타났지만, 내부 핵 파라미터의 net도 나왔다.ipv4.tcp_syn_리트리스에 따라 동작을 결정합니다.tcpdump로 조를 보면 알 수 있습니다.

[AmazonLinux]$ cat /proc/sys/net/ipv4/tcp_syn_retries
6

# pingを打ちつつパケットを見ると、6回リトライしていることが分かる
[AmazonLinux]$ tcpdump -i eth0 -nn host 8.8.8.8
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
14:14:00.678034 IP 172.26.13.8.47618 > 8.8.8.8.81: Flags [S], seq 2744376366, win 26883, options [mss 8961,sackOK,TS val 228126919 ecr 0,nop,wscale 7], length 0
14:14:01.680106 IP 172.26.13.8.47618 > 8.8.8.8.81: Flags [S], seq 2744376366, win 26883, options [mss 8961,sackOK,TS val 228127921 ecr 0,nop,wscale 7], length 0
14:14:03.696105 IP 172.26.13.8.47618 > 8.8.8.8.81: Flags [S], seq 2744376366, win 26883, options [mss 8961,sackOK,TS val 228129937 ecr 0,nop,wscale 7], length 0
14:14:07.952101 IP 172.26.13.8.47618 > 8.8.8.8.81: Flags [S], seq 2744376366, win 26883, options [mss 8961,sackOK,TS val 228134193 ecr 0,nop,wscale 7], length 0
14:14:16.144096 IP 172.26.13.8.47618 > 8.8.8.8.81: Flags [S], seq 2744376366, win 26883, options [mss 8961,sackOK,TS val 228142385 ecr 0,nop,wscale 7], length 0
14:14:32.272101 IP 172.26.13.8.47618 > 8.8.8.8.81: Flags [S], seq 2744376366, win 26883, options [mss 8961,sackOK,TS val 228158514 ecr 0,nop,wscale 7], length 0
14:15:05.808103 IP 172.26.13.8.47618 > 8.8.8.8.81: Flags [S], seq 2744376366, win 26883, options [mss 8961,sackOK,TS val 228192051 ecr 0,nop,wscale 7], length 0
★ここで諦める

strace에서 보듯이 이때connect의 오류로 110(ETIMEDOUT)이 되돌아오면curl의 exit가 7이 되고 메시지에ETIMEDOUT의 오류 내용(Connectiod out)이 표시됩니다.
참고로 실제로curl의 기본값은 300초(5분)로 설정되어 있습니다.
https://github.com/curl/curl/blob/master/lib/connect.h#L43
따라서 리트리트 수를 늘리면 이게 작용한다.

[AmazonLinux]$ echo 10 > /proc/sys/net/ipv4/tcp_syn_retries
[AmazonLinux]$ time LANG=C curl -v 8.8.8.8:81
* Rebuilt URL to: 8.8.8.8:81/
*   Trying 8.8.8.8...
* TCP_NODELAY set
* Connection timed out after 300482 milliseconds
* Closing connection 0
curl: (28) Connection timed out after 300482 milliseconds

real    5m0.490s
user    0m0.016s
sys     0m0.000s

이 경우 리눅스 핵 오류 전curl 기본 시간 초과 300초가 승리하고 오류 코드도 28(curl 시간 초과)로 변경됩니다.5분이면 잘 안 보이죠?

WSL1의 TCP 시간 초과로 인해 curl 오류 발생

위에서 설명한 대로 WSL1의 시스템 호출은 최종적으로 Windows의 시스템 호출이 됩니다.즉, Windows 측 시스템 호출에 따른 TCP 시간 초과에 따라 달라집니다.21초면 Windows가 아닐까... 잘 모르겠는데 살짝 누르면 다음과 같은 상황이 발생합니다.
TCP 접속 제한 시간 21초 정보
PowerShell의 컬도 같은 결과니까 그렇죠(적당히).왜 connection refused가 됐을까...

PS C:\Users\hijili> Measure-Command { curl 8.8.8.8:81 -v }
詳細: GET http://8.8.8.8:81/ with 0-byte payload
curl : リモート サーバーに接続できません。
発生場所 行:1 文字:19
+ Measure-Command { curl 8.8.8.8:81 -v }
+                   ~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest]、WebExce
    ption
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 21
Milliseconds      : 43
Ticks             : 210431872
TotalDays         : 0.000243555407407407
TotalHours        : 0.00584532977777778
TotalMinutes      : 0.350719786666667
TotalSeconds      : 21.0431872
TotalMilliseconds : 21043.1872

WSL2의 TCP 시간 초과로 인해 curl 오류 발생

30초...?확실히 모른다.WSL2는 기본적으로 독립된 VM이라고 생각해도 괜찮을 것 같은데...Linux Kernel의 tcp 내장 기생충은 Linux와 거의 같기 때문에 30초면 타임아웃이 되는 이치를 몰라...윈도에 익숙한 분이 알려주세요.
따라서 환경에 따라 시간 초과 처리 방법도 다르기 때문에 지정해야 한다.

웹 애플리케이션에서 POST에서 데이터를 테스트하고 싶습니다.

조금의 ascii말:-d|-데이터

$ curl -X POST -d "hogehoge" 127.0.0.1 

파일 내용 보내기:열기@파일 지정

$ curl -X POST -d @input_file.txt 127.0.0.1

표준 입력법으로 건네주고 싶습니다: @-k로

$ cat input_file.txt | curl -X POST -d @- 127.0.0.1

안 됩니다. 인코딩 URL이 없습니다!:안심하세요. - 데이터-urlencode입니다.

$ curl -X POST --data-urlencode @input_file.txt 127.0.0.1

누군 줄 알아, 제이슨이야:-H|-header로 대머리 지목해

$ curl -v -X POST -H "Content-Type: application/json" --data-urlencode @input_file.json 127.0.0.1

HTTP를 통해 방향을 바꿀 때

방향을 바꾸는 것은 어떤 헤더입니까? 시도하고 싶을 때 yahoo의 80번을 방문하면 443로 방향을 바꿉니다.미안합니다.

$ curl -v www.yahoo.co.jp
*   Trying 183.79.250.251:80...
* TCP_NODELAY set
* Connected to www.yahoo.co.jp (183.79.250.251) port 80 (#0)
> GET / HTTP/1.1
> Host: www.yahoo.co.jp
> User-Agent: curl/7.66.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 301 Redirect
< Date: Wed, 23 Sep 2020 11:06:32 GMT
< Connection: keep-alive
< Via: http/1.1 edge2573.img.umd.yahoo.co.jp (ApacheTrafficServer [c s f ])
< Server: ATS
< Cache-Control: no-store
< Location: https://www.yahoo.co.jp:443/
< Content-Type: text/html
< Content-Language: en
< Content-Length: 1
<

* Connection #0 to host www.yahoo.co.jp left intact

# -LをつければLocationヘッダに従ってcurlがつないでくれる
$ curl -L -v www.yahoo.co.jp
   :

바디를 보고 싶지 않으면 다음과 같은 내용을 추가할 수 있다.
- v: 헤드 출력 (표준 오류 발생)
- Ss: 진행 상태 표시

$ curl -v -Ss -L www.yahoo.jp > /dev/null

참고 자료

curl의 사용 방법은 많은 것을 정리했군요...기본적인 부분은 다음과 같은 사이트입니다...
curl 명령 | hydrocul의 노트

끝말

어쨌든 젠으로 보고 싶은 기사야.이렇게 얇은 기사를 젠젠이 (전혀) 싫어 이렇게 말해도 어쩔 수 없어
그리고 기사에서 이미지를 어떻게 선택해야 할지 고민이 많았어요. 그런데 컬의 기사라서 곱슬머리 이미지를 선택했어요. 아시겠죠?(알고 있나 2 브리즈번)
예?부임에 꼭 가야 하나...???