如何测量 SSH 隧道的带宽？
我正在使用 subprocess python 模块在 Linux 上运行带有 OpenSSH 的 SSH 隧道。 我想知道从该 SSH 隧道发送和接收了多少字节。
我怎样才能找到它？
I'm running a SSH Tunnel with OpenSSH on linux using the subprocess python module.
I want to find out how many bytes were sent and received from that SSH tunnel.
How can I find it out?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
ssh(1)没有为此提供任何机制。操作系统没有为此提供机制。使用例如tcpdump(1)进行数据包嗅探是一种选择，但这可能需要 root 权限，并且仅在与远程建立ssh(1)连接时才近似应用程序外部的对等点。 IPTables Accounting 会给你类似的权衡，但可能比 tcpdump(1) 的开销少得多。如果您不介意非常近似，您可以跟踪发送到子流程和从子流程读取的所有数据。
ssh(1)会在加密之前压缩数据，因此您可能会高估发送的数据量，但ssh(1)也会产生一些重新加载的开销键控、通道控制、消息真实性等等，因此它甚至可能接近“平均”数据。当然，如果沿途的路由器决定丢弃所有其他数据包，您的 TCP 堆栈将发送两倍的数据，甚至更多。
确实非常近似。
ssh(1)provides no mechanism for this. The OS does not provide a mechanism for this. Packet sniffing with e.g.tcpdump(1)is an option, but that would probably require root privileges, and would only be approximate ifssh(1)connections are made to the remote peer outside of your application. IPTables Accounting would give you similar tradeoffs, but would probably be much less overhead thantcpdump(1).If you don't mind being very approximate, you could keep track of all the data you send to and read from your subprocess.
ssh(1)will compress data before encrypting it, so you might over-estimate the amount of data sent, butssh(1)will also have some overhead for re-keying, channel control, message authenticity, and so on, so it might even come close for 'average' data.Of course, if a router along the way decides to drop every other packet, your TCP stack will send twice the data, maybe more.
Very approximate indeed.
您可以使用 pv 之类的方法来测量原始 ssh 传输：
ssh user@remote -t "cat /dev/urandom" |光伏发电/dev/空
ssh user@remote -t “pv > /dev/null” < /dev/urandom
（你可以尝试使用 /dev/zero - 但如果你使用 ssh 压缩，你会得到一个非常不真实的传输率。）
You could measure the raw ssh transfer with something like pv:
ssh user@remote -t "cat /dev/urandom" | pv > /dev/null
ssh user@remote -t "pv > /dev/null" < /dev/urandom
(you could try with /dev/zero - but if you are using ssh compression, you'd get a very unreal transfer rate.)