小文件的快速下载，是mp3共享网络、流媒体网络、实时流媒体网络都需要考虑的问题。因此需要专门针对小文件进行下砸优化，以让整个系统的下载速度达到最优。
如果不考虑小文件的同时下载人数的话，小文件的p2p分布式下载一般存在下面几个问题：
一、对等点发现的延时、对等点占有片断信息的延时。
对等点的互相发现一般是相互的，也就是说，如果B发现了A，那么A也就能发现B。所以发现延迟的问题还不大。关键是文件片断信息的延迟，现在许多系统是是基于定时的申请-回应方式。如果是小文件，应当改为主动方式，即A下载完一个片断后，立即告诉B，这样的通知比较及时一些。
二、分块大小过大。
分块大小如果太大，会导致内容共享的延迟；分块过小，可能导致校验数据过多，造成网络传输和CPU运算的浪费。
校验数据的大小，应当小于文件的百分一，才能忽略它的影响。一个hash是16字节，故校验块只要大于1600字节，也就是1k，那么校验数据所产生的网络流量与文件的大小相比，都是微不足道的。当然，我们还要考虑这些数据的储存、计算的方便。为了谨慎起见，对于小文件一般应当将块大小设为16k。那么5M的数据，其校验数据为5k，是一个可以接受的网络流量。假设其平均每通道下载速度为30k，那么客户端每秒钟能下载2块左右，网络也是足够流畅的。
三、上传方堵塞
初始用户的上传通道如果过多，每个用户分的的带宽会非常小，每个用户都迟迟不能下载完一个校验块，相互之间的共享也就无从谈起。
上传方可以同时提供的人数如果过少，那么带宽无法充分利用（自己的带宽和下载者的带宽），所以效率也不是最佳。因此我们也需要建立模型计算，或者做实验来确定，最佳数值是多少。
不考虑网络的其它开销，整个文件传输完成的速度大约是
T = 文件大小 * log(用户数) * 上传通道数 / 带宽 * log(上传通道数)
因此，估计上传通道数在3左右都是恰当的。参看下表：
用户数 N/ln(N)
2 2.885390082
3 2.73071768
4 2.885390082
5 3.106674673
另外需要注意的是：采用了这种算法后，下载者占用了上传方的通道，那么还需要有一种让出通道的机制，否则会造成通道浪费。