这个标题看起来可能有点笼统，请大家谅解：）先说说这个优化场景，和《tcp性能优化之避免慢启动》是一个场景。
问题的起因
在海量用户高并发访问的大型网站后台，有一些基本的系统维护需求。比如迁移海量小文件，就是从一些机器拷贝海量小碎文件到另一些机器，来完成一些系统维护的基本需求。 请不要小看这样的需求，这是服务器领域乃至云计算领域几个最复杂的问题之一，量变到质变，由量大引起的难题。今天在我这篇文章中，我只说这个如何避免大量握手来提升tcp层的传输加速问题。
言归正传，大量握手为什么会对拷贝海量小文件的需求造成重大性能损失？
举个简单的例子，我们对每个文件都采用独立的tcp连接来传输（循环使用scp拷贝就是这个例子的实际场景，很常见的用法）。那么工作过程应该是，每传输一个文件建立一个连接，三次握手连接，传输小文件（也许只是1至2个tcp包，我们在这先假定一个包就能传完这个小文件），四次握手断开。朋友们可以算一算，假设传输一个小文件只需要一个tcp数据包和一个ack包，那么在这样的传输策略之下，为了传输这一个数据包，需要额外的七个包来为这2个包服务。性能消耗比是2:7（三次握手请求和四次握手断开）。。。
综上，依据我的另一篇博文《tcp性能优化之避免慢启动》，服务器性能损失的计算应该很简单了，拿这个策略来计算，性能损失7/（2 7）=7/9。
如何避免握手，进而优化tcp传输性能
很简单，尽量把大量小文件放在一个tcp连接中排队传输。一次性建立连接，逐步经过慢启动，后续的文件传输全部处于高速通道中传输，用这样的方式来彻底避免多次握手对性能的消耗，进而提升性能。
题外话，实际上这种传输策略带来的性能提升不仅仅归功于避免了多次握手，事实上也避免了大量的慢启动，这个对海量小文件传输的性能消耗也非常致命，但是这是另一个问题，本篇不多加介绍。详见《tcp性能优化之避免慢启动》
随着多核服务器的兴起，以及现代网卡的多通道技术的迅猛发展，现在我们解决这一问题的通常做法是绑定多cpu的多核到网卡的多个通道，然后由cpu的核来均分传输这些小文件，每个核用一个tcp连接来排队发送分到的小文件。