curl 命令行--rate选项详解按时间单位精确控制串行传输启动频率【免费下载链接】curlA command line tool and library for transferring data with URL syntax, supporting DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, MQTTS, POP3, POP3S, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET, TFTP, WS and WSS. libcurl offers a myriad of powerful features项目地址: https://gitcode.com/GitHub_Trending/cu/curl--rate是 curl 提供的请求速率控制选项它让用户可以按秒、分钟、小时甚至天为单位限制传输的启动频率而非传输过程中的带宽非常适合批量抓取、轮询类脚本以及对目标服务器做有礼节的串行访问。本文以 curl 仓库中的 rate.md 文档为主体结合 src/tool_getparam.c 与 src/tool_operate.c 的源码实现完整讲解其语法、默认行为、边界条件与实战用法。--rate是什么限制请求频率而非传输速度--rate max request rate指定的是 curl 在单位时间内最多允许启动多少次传输即请求速率。文档给出的定义是Specify the maximum transfer frequency you allow curl to use - in number of transfer starts per time unit.在不加该选项时curl 会以尽可能快的速度依次启动下一个传输加上--rate后如果前一个传输完成得比允许的速率更快curl 会主动等待到满足速率要求才启动下一次传输。这一点与--limit-rate限制每秒传输字节数有本质区别--rate管的是多长时间内发起几次请求--limit-rate管的是传输过程中每秒最多多少字节。二者相互独立可以搭配使用分别参见 limit-rate.md 文档。--rate属于connection global类别连接类全局选项在 rate.md 的元信息中标注Scope: global、Multi: single意味着它对一次命令行调用中的全部串行传输统一生效。语法与时间单位N/U表达式请求速率以N/U形式提供其中N是整数U是时间单位单位含义说明ssecond秒每秒允许的传输次数mminute分钟每分钟允许的传输次数hhour小时每小时允许的传输次数dday天每 24 小时允许的传输次数默认单位是每小时如果省略/U例如直接写--rate 10则含义是每小时最多 10 次传输。官方示例curl --rate 2/s $URL ... # 每秒最多 2 次传输 curl --rate 3/h $URL ... # 每小时最多 3 次传输 curl --rate 14/m $URL ... # 每分钟最多 14 次传输8.10.0 版本新增能力分子 N 也可以带单位。此前N/U中的 N 只能是1 个时间单位内的次数从 8.10.0 起可以写成数量/多单位时间的形式curl --rate 5/15s $URL ... # 每 15 秒不超过 5 次传输 curl --rate 3/4h $URL ... # 每 4 小时不超过 3 次传输注意表达式中不允许出现空格即--rate 5 /15s这类写法是无效的。工作原理如何在串行传输之间踩点--rate只对串行serial传输生效。当一次命令行给出多个 URL 时curl 逐个发起传输其节奏受控于速率设置假设设定为每分钟 10 次则 curl 不会在上一次传输开始后不足 6 秒就启动下一次请求60 秒 ÷ 10 6 秒如果单次传输本身耗时较长超过了速率要求的间隔则下一个传输会立即开始不会额外等待因为实际速率已经慢于设定值若传输完成得比允许的速率快curl 会等待剩余时间使传输启动时刻保持均匀间隔。毫秒级精度内部计时使用毫秒分辨率因此--rate 1000/s每秒 1000 次即每 1 毫秒一次是理论上可表达的上限。超过 1000 次/秒时放开限制如果设定的允许频率超过每秒 1000 次curl 会直接按不受限处理unrestricted此时该选项实际上不产生任何节流效果。与--retry、--parallel的关系关联选项交互行为--parallel--rate无任何效果。并行模式下传输是并发启动的速率控制只服务于串行场景--retry重试传输时走的是--retry-delay的独立重试等待逻辑不套用--rate的节奏设置也就是说重试产生的额外请求不会占用--rate的配额节奏重试之间的间隔完全由 retry-delay.md 决定两条控制链路互不干扰。源码级实现从参数解析到毫秒间隔等待--rate的实现在 curl 命令行工具层不涉及 libcurl 库 API。核心链路分两步。第一步set_rate()把表达式换算成每次传输最小间隔毫秒数解析逻辑位于 src/tool_getparam.c 的set_rate()函数。其思路是先把N/U拆出分子传输次数denominator与分母时间单位根据单位把时间换算成毫秒数numerators→1000、m→60×1000、h→60×60×1000默认、d→24×60×60×10008.10.0 起支持N/多单位写法即在/后先解析一个数量再乘以上述基准毫秒数做溢出与合法性检查分子小于 1、或denominator numerator都会返回错误分别触发unsupported --rate unit、too large --rate unit等报错信息最终global-ms_per_transfer numerator / denominator即相邻两次传输启动之间至少间隔的毫秒数保存于 src/tool_cfgable.h 中OperationConfig的ms_per_transfer字段。例如--rate 10/m会被换算为60×1000 / 10 6000毫秒与文档中每分钟 10 次则至少间隔 6 秒完全对应。第二步single_transfer()循环中的等待逻辑串行传输主循环位于 src/tool_operate.c。每次传输结束后代码会测量本次传输实际耗时timediff_t milli curlx_timediff_ms(curlx_now(), start); if(milli global-ms_per_transfer) { notef(Transfer took % CURL_FORMAT_CURL_OFF_T ms, waits %ldms as set by --rate, milli, (long)(global-ms_per_transfer - milli)); /* The transfer took less time than wanted. Wait a little. */ curlx_wait_ms((long)(global-ms_per_transfer - milli)); }即若本次传输耗时小于ms_per_transfer就补足差值再启动下一个若传输本身已经慢于设定节奏则零等待直接继续。这也印证了文档中在允许频率内尽快开始下一次传输的行为描述。顺带一提--limit-rate背后的令牌桶与--rate不同--limit-rate走的是 libcurl 内部的令牌桶token bucket限速器实现在 lib/ratelimit.c 与 lib/ratelimit.hCurl_rlimit_*系列函数由 lib/setopt.c 在设置CURLOPT_MAX_RECV_SPEED_LARGE/CURLOPT_MAX_SEND_SPEED_LARGE时初始化。令牌桶按秒发放令牌供字节消费可配置 burst突发上限Curl_rlimit_wait_ms()返回还需等待多少毫秒令牌才会再次可用。它解决的是传输过程中每秒最多多少字节的问题与--rate的传输启动频率是两个正交维度。测试用例与实战场景仓库中的 HTTP 测试套件实际使用了--rate来控制请求节奏tests/http/test_03_goaway.py--rate 30/m每分钟 30 次即每 2 秒一次配合 curl 多 URL 下载验证服务器 reload 时连接的优雅关闭行为tests/http/test_12_reuse.py同样以--rate 30/m放缓请求节奏验证KeepAliveTimeout导致连接超时后每条请求都建立新连接的行为。典型的实战场景包括批量抓取/爬取curl --rate 1/s -o page_#1.html https://example.com/item/[1-100]以每秒 1 次的速度礼貌地抓取 100 个页面避免对目标站点造成瞬时压力API 轮询--rate 4/m每 15 秒一次与--retry 5 --retry-delay 10搭配既能控制常规请求频率又能在失败重试时走独立的重试间隔长周期任务--rate 1/h或--rate 1/d适合每天定时任务的温和访问节奏。小结要点说明功能定位限制串行传输的启动频率次/时间单位语法--rate N/UU 支持s/m/h/d默认h8.10.0 起 N 可带多单位如5/15s精度与上限毫秒级超过 1000/s 视为不限速生效范围仅串行传输--parallel下无效与重试的关系重试间隔由--retry-delay独立控制互不影响底层实现src/tool_getparam.c 解析为ms_per_transfersrc/tool_operate.c 在传输间隙补足等待【免费下载链接】curlA command line tool and library for transferring data with URL syntax, supporting DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, MQTTS, POP3, POP3S, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET, TFTP, WS and WSS. libcurl offers a myriad of powerful features项目地址: https://gitcode.com/GitHub_Trending/cu/curl创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
curl 命令行 `--rate` 选项详解：按时间单位精确控制串行传输启动频率
curl 命令行--rate选项详解按时间单位精确控制串行传输启动频率【免费下载链接】curlA command line tool and library for transferring data with URL syntax, supporting DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, MQTTS, POP3, POP3S, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET, TFTP, WS and WSS. libcurl offers a myriad of powerful features项目地址: https://gitcode.com/GitHub_Trending/cu/curl--rate是 curl 提供的请求速率控制选项它让用户可以按秒、分钟、小时甚至天为单位限制传输的启动频率而非传输过程中的带宽非常适合批量抓取、轮询类脚本以及对目标服务器做有礼节的串行访问。本文以 curl 仓库中的 rate.md 文档为主体结合 src/tool_getparam.c 与 src/tool_operate.c 的源码实现完整讲解其语法、默认行为、边界条件与实战用法。--rate是什么限制请求频率而非传输速度--rate max request rate指定的是 curl 在单位时间内最多允许启动多少次传输即请求速率。文档给出的定义是Specify the maximum transfer frequency you allow curl to use - in number of transfer starts per time unit.在不加该选项时curl 会以尽可能快的速度依次启动下一个传输加上--rate后如果前一个传输完成得比允许的速率更快curl 会主动等待到满足速率要求才启动下一次传输。这一点与--limit-rate限制每秒传输字节数有本质区别--rate管的是多长时间内发起几次请求--limit-rate管的是传输过程中每秒最多多少字节。二者相互独立可以搭配使用分别参见 limit-rate.md 文档。--rate属于connection global类别连接类全局选项在 rate.md 的元信息中标注Scope: global、Multi: single意味着它对一次命令行调用中的全部串行传输统一生效。语法与时间单位N/U表达式请求速率以N/U形式提供其中N是整数U是时间单位单位含义说明ssecond秒每秒允许的传输次数mminute分钟每分钟允许的传输次数hhour小时每小时允许的传输次数dday天每 24 小时允许的传输次数默认单位是每小时如果省略/U例如直接写--rate 10则含义是每小时最多 10 次传输。官方示例curl --rate 2/s $URL ... # 每秒最多 2 次传输 curl --rate 3/h $URL ... # 每小时最多 3 次传输 curl --rate 14/m $URL ... # 每分钟最多 14 次传输8.10.0 版本新增能力分子 N 也可以带单位。此前N/U中的 N 只能是1 个时间单位内的次数从 8.10.0 起可以写成数量/多单位时间的形式curl --rate 5/15s $URL ... # 每 15 秒不超过 5 次传输 curl --rate 3/4h $URL ... # 每 4 小时不超过 3 次传输注意表达式中不允许出现空格即--rate 5 /15s这类写法是无效的。工作原理如何在串行传输之间踩点--rate只对串行serial传输生效。当一次命令行给出多个 URL 时curl 逐个发起传输其节奏受控于速率设置假设设定为每分钟 10 次则 curl 不会在上一次传输开始后不足 6 秒就启动下一次请求60 秒 ÷ 10 6 秒如果单次传输本身耗时较长超过了速率要求的间隔则下一个传输会立即开始不会额外等待因为实际速率已经慢于设定值若传输完成得比允许的速率快curl 会等待剩余时间使传输启动时刻保持均匀间隔。毫秒级精度内部计时使用毫秒分辨率因此--rate 1000/s每秒 1000 次即每 1 毫秒一次是理论上可表达的上限。超过 1000 次/秒时放开限制如果设定的允许频率超过每秒 1000 次curl 会直接按不受限处理unrestricted此时该选项实际上不产生任何节流效果。与--retry、--parallel的关系关联选项交互行为--parallel--rate无任何效果。并行模式下传输是并发启动的速率控制只服务于串行场景--retry重试传输时走的是--retry-delay的独立重试等待逻辑不套用--rate的节奏设置也就是说重试产生的额外请求不会占用--rate的配额节奏重试之间的间隔完全由 retry-delay.md 决定两条控制链路互不干扰。源码级实现从参数解析到毫秒间隔等待--rate的实现在 curl 命令行工具层不涉及 libcurl 库 API。核心链路分两步。第一步set_rate()把表达式换算成每次传输最小间隔毫秒数解析逻辑位于 src/tool_getparam.c 的set_rate()函数。其思路是先把N/U拆出分子传输次数denominator与分母时间单位根据单位把时间换算成毫秒数numerators→1000、m→60×1000、h→60×60×1000默认、d→24×60×60×10008.10.0 起支持N/多单位写法即在/后先解析一个数量再乘以上述基准毫秒数做溢出与合法性检查分子小于 1、或denominator numerator都会返回错误分别触发unsupported --rate unit、too large --rate unit等报错信息最终global-ms_per_transfer numerator / denominator即相邻两次传输启动之间至少间隔的毫秒数保存于 src/tool_cfgable.h 中OperationConfig的ms_per_transfer字段。例如--rate 10/m会被换算为60×1000 / 10 6000毫秒与文档中每分钟 10 次则至少间隔 6 秒完全对应。第二步single_transfer()循环中的等待逻辑串行传输主循环位于 src/tool_operate.c。每次传输结束后代码会测量本次传输实际耗时timediff_t milli curlx_timediff_ms(curlx_now(), start); if(milli global-ms_per_transfer) { notef(Transfer took % CURL_FORMAT_CURL_OFF_T ms, waits %ldms as set by --rate, milli, (long)(global-ms_per_transfer - milli)); /* The transfer took less time than wanted. Wait a little. */ curlx_wait_ms((long)(global-ms_per_transfer - milli)); }即若本次传输耗时小于ms_per_transfer就补足差值再启动下一个若传输本身已经慢于设定节奏则零等待直接继续。这也印证了文档中在允许频率内尽快开始下一次传输的行为描述。顺带一提--limit-rate背后的令牌桶与--rate不同--limit-rate走的是 libcurl 内部的令牌桶token bucket限速器实现在 lib/ratelimit.c 与 lib/ratelimit.hCurl_rlimit_*系列函数由 lib/setopt.c 在设置CURLOPT_MAX_RECV_SPEED_LARGE/CURLOPT_MAX_SEND_SPEED_LARGE时初始化。令牌桶按秒发放令牌供字节消费可配置 burst突发上限Curl_rlimit_wait_ms()返回还需等待多少毫秒令牌才会再次可用。它解决的是传输过程中每秒最多多少字节的问题与--rate的传输启动频率是两个正交维度。测试用例与实战场景仓库中的 HTTP 测试套件实际使用了--rate来控制请求节奏tests/http/test_03_goaway.py--rate 30/m每分钟 30 次即每 2 秒一次配合 curl 多 URL 下载验证服务器 reload 时连接的优雅关闭行为tests/http/test_12_reuse.py同样以--rate 30/m放缓请求节奏验证KeepAliveTimeout导致连接超时后每条请求都建立新连接的行为。典型的实战场景包括批量抓取/爬取curl --rate 1/s -o page_#1.html https://example.com/item/[1-100]以每秒 1 次的速度礼貌地抓取 100 个页面避免对目标站点造成瞬时压力API 轮询--rate 4/m每 15 秒一次与--retry 5 --retry-delay 10搭配既能控制常规请求频率又能在失败重试时走独立的重试间隔长周期任务--rate 1/h或--rate 1/d适合每天定时任务的温和访问节奏。小结要点说明功能定位限制串行传输的启动频率次/时间单位语法--rate N/UU 支持s/m/h/d默认h8.10.0 起 N 可带多单位如5/15s精度与上限毫秒级超过 1000/s 视为不限速生效范围仅串行传输--parallel下无效与重试的关系重试间隔由--retry-delay独立控制互不影响底层实现src/tool_getparam.c 解析为ms_per_transfersrc/tool_operate.c 在传输间隙补足等待【免费下载链接】curlA command line tool and library for transferring data with URL syntax, supporting DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, MQTTS, POP3, POP3S, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET, TFTP, WS and WSS. libcurl offers a myriad of powerful features项目地址: https://gitcode.com/GitHub_Trending/cu/curl创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
