经典TCP性能问题

  某PHP服务通过Nginx将后面的tair封装了一下，让其他应用通过http协议访问Nginx来 get 和 set 操作tair。上线后一切测试正常，每次操作几毫秒，但有个应用的value是300K，这个时候set一次要300毫秒以上。 没有任何并发压力，单线程单次操作也要这么久。

  这个延迟没有道理，为什么会这样？

  因为TCP协议为了做一些带宽利用率、性能的优化，而做了特殊处理，如Delay Ack和Nagle算法。这个原因对于理解TCP基本概念后能在实战中了解一些TCP其它方面的性能和影响。

  大家都知道TCP是可靠传输，可靠的核心是收到包后回复一个ack来告诉对方已收到。

  截图中的Nignx - 8085端口收到了一个http request请求，然后回复了一个ack包给client，接着回复了一个 http response 给 client。回复的ack包长度66，实际内容长度为0。ack信息放在TCP包头里面，也就是说，这里发了一个66字节的空包给客户端来告诉客户端收到请求了。

  逻辑没问题，符合TCP核心可靠传输的意义。但问题是：带宽效率不高。能优化吗？

  这里的优化就是delay ack。