support TCP_NODELAY option

[xiamengyu]

Add setNoDelay method for Request, this method can enable TCP_NODELAY option.

[kornelski]

I don't see a reason to add buffering delay for requests. Why do you need this?

[xiamengyu]

This is not add a delay for a request, this is support TCP_NODELAY option to disable TCP Nagle algorithm.
We found some TCP packages are delayed because of TCP Nagle algorithm.
This commit can support under layer TCP_NODELAY option to disable TCP Nagle algorithm.

[kornelski]

1. In Node Nagle's algorithm is off by default, so without this change it's always off (good). With this change it's on or off.

2. I don't see default set for this._noDelay anywhere, so it's undefined, and !!this._noDelay makes false, so your change makes it slow by default.

[kornelski]

https://nodejs.org/api/net.html#net_socket_setnodelay_nodelay
noDelay defaults to true.

So if true is the default used by node, and therefore used by superagent, the only use for this function is to set it to false. Why would you need to set nodelay to false?

[xiamengyu]

noDelay defaults to true

This means the param noDelay is true when you call setNoDelay without pass a param.
The same web page says 'By default TCP connections use the Nagle algorithm'. So I need a option to disable Nagle algorithm(enable TCP_NODELAY option).

[xiamengyu]

Here is the source code of nodejs socket.setNoDelay(): lib/net.js

Socket.prototype.setNoDelay = function(enable) {
  if (!this._handle) {
    this.once('connect',
              enable ? this.setNoDelay : () => this.setNoDelay(enable));
    return this;
  }

  // backwards compatibility: assume true when enable is omitted
  if (this._handle.setNoDelay)
    this._handle.setNoDelay(enable === undefined ? true : !!enable);

  return this;
};

[kornelski]

Ah! I see. I'm sorry I misread that documentation page.

I've tried this change and I tried to see how much it affects the speed, but I'm not seeing any effect:

describe('benchmark', function(){
    it('nodelay', function(){
      this.timeout(1000000);
      const https = require('https');
      return Array.from(Array(100)).reduce(prev => prev.then(() => {
        return request
          .head('https://geekhood.net/robots.txt') // remote serv in case localhost is special
          .agent(new https.Agent({ keepAlive: false }))
          .set('connection', 'close')
      }), Promise.resolve());
    });
  });

With and without nodelay I'm seeing about the same speed (tested on macOS).

[xiamengyu]

Thank you for you merged this commit and added benchmark for it.
The delay of Nagle algorithm happens on some special situations, that not always happen.
Here is the Algorithm:

if there is new data to send
  if the window size >= MSS and available data is >= MSS
    send complete MSS segment now
  else
    if there is unconfirmed data still in the pipe
      enqueue data in the buffer until an acknowledge is received
    else
      send data immediately
    end if
  end if
end if

By the way, may be it's a good choice for user (who use superagent) to choose enable TCP_NODELAY or not.
I see TCP_NODELAY is enabled by default in superagent now, and user can not disable it.
Nagle's algorithm sometimes can save network resource, may be some situations need Nagle's algorithm, but user can not disable TCP_NODELAY in superagent.

[kornelski]

Yes, since I didn't see any negative side effect, I've enabled it all the time just in case.

As far as I understand cost/benefit of Nagle's algorithm depends on how the data is sent — whether it's sent all at once, or sent bit by bit.

In case of superagent user has absolutely no control over this. All of the sending happens in Node's underlying HTTP request library. Since nodelay doesn't seem to affect anything, I presume Node already sends all headers at once.

So I don't see why user would need to have control over this, since it doesn't depend on the user, but depends on Node's implementation. In case of superagent there should clearly exist a right and wrong setting, and there shouldn't be a need to let user set it to a wrong value.