在client一直给server发送小数据的时候，接受到一个回应会在非常长的时间以后，可是将多个小数据写操作合并成一个写操作，问题就没了。
这个事件的缘由可能是TCP_NODELAY的原因
如今大概明确。是因为nagle算法在捣乱。
TCP/IP协议中。不管发送多少数据，总是要在数据前面加上协议头，同一时候，对方接收到数据。也须要发送ACK表示确认。为了尽可能的利用网络带宽，TCP总是希望尽可能的发送足够大的数据。（一个连接会设置MSS參数，因此。TCP/IP希望每次都可以以MSS尺寸的数据块来发送数据）。
Nagle算法就是为了尽可能发送大块数据。避免网络中充斥着很多小数据块。
Nagle算法的基本定义是随意时刻，最多仅仅能有一个未被确认的小段。
所谓“小段”。指的是小于MSS尺寸的数据块，所谓“未被确认”。是指一个数据块发送出去后。没有收到对方发送的ACK确认该数据已收到。
举个样例，一開始client端调用socket的write操作将一个int型数据(称为A块)写入到网络中，因为此时连接是空暇的（也就是说还没有未被确认的小段）。因此这个int型数据会被立即发送到server端，接着，client端又调用write操作写入‘/r/n’（简称B块），这个时候。A块的ACK没有返回。所以能够觉得已经存在了一个未被确认的小段，所以B块没有立即被发送，一直等待A块的ACK收到（大概40ms之后），B块才被发送。整个过程如图所看到的：
这里还隐藏了一个问题，就是A块数据的ACK为什么40ms之后才收到？这是由于TCP/IP中不唯独nagle算法，另一个ACK延迟机制。当Server端收到数据之后，它并不会立即向client端发送ACK，而是会将ACK的发送延迟一段时间（如果为t），它希望在t时间内server端会向client端发送应答数据，这样ACK就行和应答数据一起发送。就像是应答数据捎带着ACK过去。在我之前的时间中，t大概就是40ms。这就解释了为什么'/r/n'(B块)总是在A块之后40ms才发出。
假设你觉着nagle算法太捣乱了，那么能够通过设置TCP_NODELAY将其禁用。当然，更合理的方案还是应该使用一次大数据的写操作，而不是多次小数据的写操作。