问：最近，我的企业遇到了一些网络问题。事实上，我是一名Oracle DBA，但是，我对网络问题是如何影响我的应用感到越来越好奇。基本上，我每个星期都使用PING命令来检查网络是否正常。结果是，从客户端向DB服务上发送的数据包3.6%都会丢失。

　　我怎样才可以知道这个3.6%的值是否仍然可以接受的呢？是否这个值对某种类型的应用是坏的，而对其它的又是好的呢？

　　我实在不知道从何处着手，您能给我一个总体的思路或者一些我可以通过Google搜索来进行研究的因素吗？

　　最后，我想说的一点是我并不需要知道在何处以及为何网络性能是糟糕的，我想了解的是何时糟糕的网络性能会影响应用。

　　答：很高兴你提出这个问题。问得非常好！在各种不同的企业中，应用开发员用于确保他们应用性能良好的好方法之一就是了解应用调用是如何影响数据行为的。为了更好地说明，我称这种方法为Tarzan影响。大多数应用开发员都倾向于创建假定为无限制的本地网络访问的应用，同时是以单个而不是大量的请求来调用数据库/文件服务器。这就转化为网络工程师传统上所称的请求-响应应用。由于客户端要为每条信息等待整个网络的延迟，因此，数据库的每个请求会加剧网络延迟或者丢包；如果在最初的传输中就发生了丢失，那么影响是加倍的。如果Tarzan穿越整个丛林，它不会每次只摘下一个香蕉然后给大猩猩带回来，对吧？当然不是。它会制作一个篮子，然后一次外出就带回一篮子香蕉。它可以一次带回尽可能多的香蕉。然而，这里面也有一定的风险，因此需要一个改良的方法来了解它一次能从丛林中安全地带回多少香蕉。

　　如果Tarzan在丛林中摔跤了，并且弄丢了整个篮子的香蕉，那该怎么办？这里就是我们要解决的关于丢失的问题。如果数据包在网络上丢失了，那么基于TCP的连接会发生什么情况呢？我该如何重新找到这一篮子的水果呢？为了让问题简单点，我们假设我们并没有在网络优化上使用任何特定的机制，但是，如果我们意识到在延迟敏感和失真环境中我们需要它们的帮助，那么它们也是很值得研究的。首先，了解TCP事实上有一个TCP Slow Start的机制，它是一种用来了解环境是如何失真的方法，技术上称为拥塞避免和肯定应答。它通过在等待应的期间发送小增量的数据包到较大数据包的方式来缓慢地提升传输的窗口大小。（假定Tarzan开始是带2个香蕉给大猩猩，接着是4个，然后是8个，以此来了解到底它带多少香蕉给大猩猩是安全的。）如果在传输的过程中发生了传输丢失，那么下次传输的数据包数目就必须减半。TCP在检测到丢失时，就会在不需要得到应答的情况下减少数据包的数目。在因特网上有一些非常典型的锯齿图来阐明这个行为。

　　理想情况下，没有丢失是最好的。但是，只要应用开发员允许，TCP内部会有一些机制可以更好地处理丢包。假如我们的编码每次只请求一个数据段，那么TCP窗口大小就没有机会增加，因此我们就基本上每次在丛林中只带回一个香蕉。因此，这种类型的行为是不切实际的。请求-响应应用中3.6%的数据包丢失是相当糟糕的，因为每个数据包丢失都必须等待整个网络延迟发现后再重新传输。如果应用编码将TCP窗口大小默认设置得足够高，同时发生数据包丢失，那么用户不大可能感觉到所增加的有效网络延迟是因为数据包的重新传输引起的。因此你要小心了。同时，此处的一个重点是明确地以数据包大小、分布或行为来区分在网络中发送的ICMP数据跟应用层的流量是不一样的。因此，在可能的情况下，在ICMP流量上监控应用层数据的重新传输和丢失对于更精确地了解丢失对我们的应用的影响往往是一个非常好的做法。不管我们怎么做，只需要记住其实就有一个丛林要通过罢了！

　　下面是一些你应该在Google搜索的关键字：TCP慢启动、TCP选择性应答、延迟应答、Nagle算法以及拥塞避免。