Curl like a boss

Comandos legais

Upload de arquivos

curl \
  -i -X POST -H "Content-Type: multipart/form-data" \
  -F "campo1=valor1" \
  -F "postFieldName=@<filePath>" \
  <URL>

Tshoot

i="0"
while [ $i -lt $2 ]
do
date
curl -w "@curl-format.txt" -k https://$3:$1/site
i=$[$i+1]
done

então

\n
            time_namelookup:  %{time_namelookup}\n
               time_connect:  %{time_connect}\n
            time_appconnect:  %{time_appconnect}\n
           time_pretransfer:  %{time_pretransfer}\n
              time_redirect:  %{time_redirect}\n
         time_starttransfer:  %{time_starttransfer}\n
                            ----------\n
                 time_total:  %{time_total}\n
\n

Ou ainda

curl -w "NameLookup: %{time_namelookup}\\nTimeConnect: %{time_connect}\\nTimeTotal %{time_total}\\n" -s http://seusite.com -o /dev/null

Sobre os campos

time_namelookup in this example takes a long time. To exclude DNS resolver performance from the figures, you can resolve the IP for cURL: –resolve www.zasag.mn:443:218.100.84.167. It may also be worth looking for a faster resolver :).

time_connect is the TCP three-way handshake from the client’s perspective. It ends just after the client sends the ACK - it doesn’t include the time taken for that ACK to reach the server. It should be close to the round-trip time (RTT) to the server. In this example, RTT looks to be about 200 ms.

time_appconnect here is TLS setup. The client is then ready to send it’s HTTP GET request.

time_starttransfer is just before cURL reads the first byte from the network (it hasn’t actually read it yet). time_starttransfer - time_appconnect is practically the same as Time To First Byte (TTFB) from this client - 250 ms in this example case. This includes the round trip over the network, so you might get a better guess of how long the server spent on the request by calculating TTFB - (time_connect - time_namelookup), so in this case, the server spent only a few milliseconds responding, the rest of the time was the network. time_total is just after the client has sent the FIN connection tear down.

By Fuji

tcpdump -i eth0 -A -s 10240 'tcp port 8000 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)' | egrep --line-buffered "^........(GET |HTTP\/|POST |HEAD )|^[A-Za-z0-9-]+: " | sed -r 's/^........(GET |HTTP\/|POST |HEAD )/\n\1/g'