从系统层的角度来看网络，它包括：包含硬件的主机平台、操作系统（OS）和应用软件。端到端性能涉及到主机系统的特性，例如内存、I/O、带宽和CPU速度、操作系统以及应用程序。要维护一定的吞吐量，主机系统必须可以从应用缓冲中移动数据，通过内核到达网络接口缓冲区，而且这一过程的速度必须比网络接口的要快。
如今的计算机由于具备更快、更宽的I/O和内存总线、更快的处理器、更多的内存以及加速的磁盘传输，所以它们大多不再受硬件的限制。另外制造商减少了数据从应用程序转移到网络接口时内存之间的拷贝速度。正因为这种“零拷贝”堆栈的变化，OS就可以快到几G每秒的速度来驱动网络。
因此如果硬件和OS不限制端到端Internet的性能，那么可能还有么原因呢？回答这个问题需要讨论以下几点：网络配置，网络协议和应用程序
配置局限
双工错配的情况只是网络配置问题中的一种。网络中50%以上的故障问题都是由快速以太网双工错配所引起的。在这种情况下，网络和主机NIC无法正确的自动确定链接的全/半双工设置。双工错配情况可以引起一个方向的数据包的严重丢失。如果是使用必须双向传输的协议，比如TCP/IP，双工错配会引起更严重的问题。
必须使用高带宽测试来查看是否存在双工错配的情况。但在一个方向上探测时，这种方法不管用，因为半双工配置的接口需要冲突检测来控制，但是全双工配置的接口却不需要。所以这样阻止了从那个方向来的任何信息。
当带宽测试侦测到问题时，除非在网络的第二层和第三层的每一个设备周围正确安装了探针，否则无法找到问题发生的地点。一些较新的诊断工具，例如Network Configuration Tester可以较容易的找到这些问题。该系统在客户端计算机上使用Java脚本来执行带宽测试，并且可以通过测试远程服务器的内核变量来决定链接的某些特性。
另一个配置问题是由于同一个网络路径上不同速度和类型的连接所造成的。例如，一个公司可能有一个从校园网到本地ISP的DS3（45M/秒）上行链路，而计算机之间还同时存在快速以太网链接。如今诸如pathchar、pchar和clink之类的诊断工具都可以用来检测网络路径的链接类型、速度和反应时间（来回程时间）。在今后的两年内，这些工具都会得到普遍应用。
最大传输单元（MTU）的大小是网络配置的另一个关键。IEEE 802.3以太网协议指定MTU为1500个字节。而一个应用程序的最大数据吞吐量同它的数据包大小是成正比的。从理论上来看，大的数据包可以导致大的吞吐量。大多数吉比特以太网交换机和路由器都支持Jumbo Frames，它可以使MTU的大小达到9000字节，因此可以在不丢失数据包的同时提供更高的数据吞吐量。然而，由于吉比特以太网Jumbo Frames协议缺少必要的标准，所以这样很容易导致互操作性的问题。
协议问题
网络协议对网络性能也会产生一定的影响。例如，TCP协议内建了一些控制算法，它们可以控制网络收发数据时协议所发挥的作用。但是根本的前提是多个TCP流都应该可以各自分享到一定的网络资源。如果一个链接阻塞，所有共享该链接的TCP流都会减少它们的传输速率来缓解这个链接。这就是所谓的TCP延迟。
运用现有的TCP算法，少量的数据丢失可能会对网络或应用程序的性能产生很大的影响。运用这种算法，如果在一个来回程丢失一个数据包将会使吞吐量下降50%而到最低点，只有在这个时帧内检测到无数据丢失时，数据吞吐量才会上升。
有一些大数据量、高速度数据传输的应用程序试图解决Internet的TCP延迟问题。这些应用程序包括：在接近终端用户的服务器上分段传输和高速缓存应用程序数据，同时为单个应用使用多数据流，以及使用基于UDP的协议（可以通过误差修正或丢失数据块的批量中继来获取可靠性）。
另一种方法就是使用错误修正代码（ECC）在终端重建一些丢失的数据包。因此只有大数据量的丢失才会被重发，因为它们可能无法从代码模式被恢复。
研究工作者正在思考如何快速恢复丢失的包，而不会对网络的可靠性产生负面影响。其中的一个关键技术就是为TCP协议设计出新的冲突控制算法，它不能导致单个包的丢失，而是维持正常的使用。有一些新的算法的确能改善网络的性能，但还是存在一些问题，例如它们所使用的带宽是否超出了应得的范围。
除了TCP延迟以外，另一个网络协议问题和缓冲区有关。端到端性能是由链接速度和两个终端系统之间的距离所决定的，它同样也决定数据包是否会被延迟。当平台和网络速度增加时，传输单个包的时间就会减少，因此在一个时帧内就可以传输更多的数据包。网络中包含的数据量取决于带宽同延迟相乘的结果。
如果主机缓冲区空间太小，而且发送数据的主机使用了可靠的协议，例如TCP，那么它就会停止传输；否则，如果使用的是其它协议，比如UDP，接受主机将会丢失数据包。虽然OS经常用应用程序设置所需缓冲区的大小，但大多数情况下缓冲区大小都会被错误设置。因此，缓冲区大小通常都是使用系统的默认值，而且这些默认值通常在LAN上都得到了优化。
虽然有一些工具可以支持手动获取缓冲区的最优设置，但目前正在研制一种自动调整算法。这种算法可以分配适当的缓冲区空间给所使用的网络路径。但是这些工具对每一个不同的网络流需要作出独立的设置，当前的OS对所有的网络流只存在一种设置。
为了增强网络的性能，一些开放资源的OS增加了将内核数据到自动调整的应用程序上的功能。
应用程序的因素
应用程序相关的问题也可能对网络性能产生较大的影响。例如LAN上运行正常的交互式应用程序可能无法链接到跨洋的WAN上。跨国传输的额外反应时间和噪音干扰将会导致应用程序不能允许的数据延迟。如果服务器的磁盘I/O子系统很慢的话，那么应用程序只有在磁盘读写完毕时才能被装载。另外由于网络速度比磁盘读取要快得多，所以文件传输一般都达不到预期的速率，因为文件传输速率会直接受到网络速度的影响。
应用程序的调试和编辑工具必须可以用来寻找和解决瓶颈问题，而且基于网络的应用程序还需要内建的机制来缓解不可避免的数据包丢失和延迟问题。
解决该问题的一个方法就是在两个运行应用程序的主机之间运行带宽测试。可以使用Iperf之类的工具来测试参数（例如，端到端的噪音干扰、吞吐量、数据包的丢失和延迟）
网络的属性对应用程序会产生最大的影响。例如，如果反应时间和噪音干扰超出了特定的参数，那么一些实时的应用程序可能就起不到任何作用。虽然不存在任何标准模式来判断合适的属性，但是网络管理员可以凭借经验，在应用程序的基础上设计出适合它们的性能标准。
工具是否正确使用
大多数现有改善网络性能的工具都缺乏专门的技术支持。这些工具必须得到改进，使得终端用户可以得知网络的端到端性能以及QoS的水平。
有一些工具可以用来检测网络的性能以及应用程序在网络上所属的层次。例如，ping、trace-route和nslookup（nslookup可以解决DNS相关的问题）。但是这些工具限制了端到端的诊断能力。
有一些功能更强大的免费和开放资源的工具，例如Iperf、pathchar和pchar。后面的两个工具可以用来估计带宽、吞吐量、反应时间、包丢失、排队长度以及网络路径等属性。Pchar和clink只不过是pathchar最早使用的算法的两种不同的执行过程。
所有这些工具在探测网络层的问题时更加有效。但是除非在整个网络路径上存在匹配的和校准的探测指针也运行同样的工具（或工具代理），否则就很难杜绝这些网络节点上的探测设备出现问题。激活的工具需要发送者（客户端）和接收者（服务器）或是在所有需要检测的机器上运行一对同等意义的匹配程序。代理就是“侦听”同远程单元的联系和会话，或者联系其它单元的程序。一些代理程序具有内建智能，它可以确定代理能联系上哪个系统，代理需要联系的系统以及它们需要交换哪些信息。
例如，如果主机上运行着Iperf服务器，而且其它以客户模式运行Iperf的系统还可以访问该主机的地址，如果这些客户端设置为自动测试它们自己和该服务器（或任何其它Iperf服务器）之间的路径，那么客户端就可以提供关于同终端用户之间链接的质量信息。
一些难题
虽然商业工具的界面变得越来越友好，文档越来越简明，并且更易于管理，但是价格却越来越贵。
工具NetIQ's Chariot可以测试网络端到端性能并且内建在大多数协议栈中。该工具如果同公司的应用程序扫描器联合使用可以模仿一定数量的应用程序。它还可以用来评估自动分布的性能。
工具Concord Communications's eHealth Suite 包括可以确定制定服务层是否可用的个性化应用客户端。
测试和测量工具SmartBits， AX/4000和CenterOp可以用来分析不同条件下网络的性能。
很难找到可以在网络第二层提供追溯功能的工具，这种追溯功能基本上是隐私的。如果应用程序涉及到第三层以上或者在平台中内建了网络层代理，例如Iperf或NetIQ代理，那么测试也不一定会准确。如果按照硬件、OS和中间件来配置终端平台，那么就可以使用平台上运行的基于SNMP服务的信息。
配置应用程序的功能更为复杂。一些应用程序试图执行端到端的检测，但是基本上很难提供应用程序之外的任何有用的信息。这些检测机制很少提供或根本没有关于，或是控制OS、网络路径节点的信息。
