Bandwidth limiter for http.Get

<p>I have an http server and client, both written in go.</p> <p>The client runs in a restricted environment and I need to throttle the download bandwidth between the client and server. This is example client code.</p> <pre><code>res, err := http.Get(&#34;http://127.0.0.1:8890/&#34;) //Error handling here buff := bytes.NewBuffer(make([]byte, 0)) for range time.Tick(time.Second) { _, err := io.CopyN(buff, res.Body, 500) if err != nil { if err != io.EOF { panic(err) } else { break } } } </code></pre> <p>This looks good on the surface, reading at 500B/s (not my intended threshold but you get the idea). </p> <p>However. I am not convinced this has actually throttled the <strong>network</strong> traffic. If I serve 500KB to this code, I can shut the HTTP server down and it continues as it was, merrily going on. To me, it looks like <code>http.Get</code> reads all of the net traffic into <code>response.Body</code>, instead of creating an <code>io.Reader</code> for me to call at my leisure (which is what I assumed was happening underneath). </p> <p>Am I missing something here?</p> <hr/>**评论：**<br/><br/>TheMerovius: <pre><p>The network bandwidth isn&#39;t actually determined by the client. The client can do relatively little to influence it. In actuality, the server will push data as quickly as it can manage, which will then land in the buffers of the operating system your client runs on (to a good approximation. There are more complexities with intermediate routers). So, the best a client can do, is read slower from the kernel buffers, letting them fill up quicker. That <em>will</em> eventually lead to less bandwidth consumed, because it will lead to TCP backpressure (i.e. the network card will stop ACKing TCP packages that it can&#39;t buffer, which will lead the server to slowly throttle the connection), but it is a very inefficient way to do that and will lead to extra chatter on the network in-between.</p> <p>A <em>far</em> more effective strategy is to throttle the connection server-side (and you might want to do that anyway; it would be bad to rely on clients to well-behave for a safety like that). For example, you can limit the rate at which you write to the <code>http.ResponseWriter</code> given to your Handler, giving you very good control over the bandwidth used (to the lower bound of 1B/TCP idle timeout).</p></pre>Smokey_Circles: <pre><p>Ah, that answers a lot of questions I had. Thanks, wasn&#39;t sure where I needed to look to figure this one out.</p> <p>I will indeed do the throttling server side. Thanks :)</p></pre>