- 分割TCP建议并不适合含有不对称路由的网络。要应用分割TCP方案，需要保证移动设备在中间介质节点间来去路由的畅通，而对一些网络来说，这要么是无法完成的，要么需要中间介质节点回溯远离无线网络边界的几级连接才能完成，这在实际上是无法实践的，而且可能导致路由不可优化（non-optimal routing）。
- 分割TCP，正如其名所示，无法解决与UDP相关的任何问题。
注意：使用分割TCP并不需要排斥对IP端对端连接的并发使用。正确的分割TCP用法是，将每个应用或每个连接都交由最终用户来管理与控制，这样，用户可决定是否对某个指定的TCP连接或应用使用分割TCP，或者直接在IP上进行端对端操作。
建议：分割TCP建议因其变更了TCP语法，因而并不建议采用。另外，无线连接上的一些定制协议如MOWGLI等，也不建议使用，因其主张：（1）改良TCP而不是重新设计；（2）在任何时候都允许端对端会话。
4.10.2 应用级代理（Application Level Proxies）
现今，应用级代理在Internet范围广泛使用，包括：Web代理缓存，中继MTAs（Mail Transfer Agents，邮件传输代理）及安全传输代理（例如SOCKS）。在“分割TCP连接”中，应用级的代理充当中间介质。因而，一些存在于无线连接中的问题，如拥挤的广域internet通道和无线LTN连接的组合，会自动扩展到其它领域。
应用协议经常要使用大量的（不必要的）往返周期、大量的报头及低效率的编码，甚至在常规应用协议操作中，有许多不必要的数据也可能传送到无线连接。在多数情况下，可简单地通过在中间介质节点处运行一个应用级代理来减轻这种超载。在LTN连接下，可将应用程序指定的增强方式告知应用级代理，这样可显著提高性能。这种代理可能使用无线连接上的增强版本的应用协议。
Montenegro, et al. Informational [Page 26]
在LTN环境中，应用层的增强会提供比任何传输级增强更显著的性能提高。
Mowgli系统提供了对客户和服务器间的附加应用级代理服务对（agent-proxy pairs）的完整支持，由移动设备上的代理和中间介质节点处的代理服务器组成。该对可以为应用程序所知，也可做到完全透明，但是，在全部连接时间内，都处于最终用户的控制之下。有关应用程序指定代理的比较好的例子参见Mowgli WWW[LAKLR95]，[LHKR96] 和WebExpress [HL96]，[CTCSM97]。
建议：使用应用级代理是有条件的，即应用必须支持代理；为应用选定的代理必须时刻受用户的控制。
4.10.3 探听及其派生（Snoop and its Derivatives）
Berkeley的SNOOP协议[SNOOP]是连接层可靠机制与分割连接方案混和的产物。它比分割TCP方案要高明，因为它保留了端对端的语法。SNOOP做如下两件事：
1. 局部（无线连接范围内）对丢失的包进行中继，而不是允许TCP用端对端方式实现。
2. 抑制由接收端回馈给发送端的重复确认信息，从而避免了快中继和发送端的拥塞避免（congestion avoidance）。
因而，SNOOP协议的设计目的是，当无线连接层在局部中继包时，避免TCP发送方进行不必要的快中继。假设一个系统不使用SNOOP代理的情况：TCP发送方S通过中间介质节点IN向接收方R发送信息包。假定发送方依次发送信息包A，B，C，D，E，并由IN将其推送至无线接收端R。假如因为无线连接错误而导致包B丢失，由中间介质节点随后对B进行了中继，在这种情况下，接收端R接收到的包依次为A，C，D，E，及B。收到包C，D和E后将触发重复确认信号。当TCP发送方收到三个重复确认信号时，它将触发快中继（将引发中继，和拥塞窗口的减小一样）。尽管链接级中继正在进行，快中继仍可发生，从而降低了吞吐效率。
Montenegro, et al. Informational [Page 27]
SNOOP [SNOOP]在中间介质节点处丢弃相应的TCP重复包（dupacks）来解决此问题。在中间介质节点处，尝试对延迟重复包（Delayed Dupacks，见4.5节）进行不加修改的近似侦听。只有当由无线错误而导致的快中继的可能性不可忽略时，这种方案才有用。特殊情况下，如果无线连接使用了stop-and-go方式的协议（或依次方式传递包），这种方案就不是很有效了。同样，如果无线连接的带宽延迟乘积小于四个段，中间介质节点在丢包被中继前发送三个新包的可能性是很小的。因为要触发快中继至少需要三个重复包，当无线带宽延迟乘积小于四个包时，殊如SNOOP和延迟重复包这样的方案就显得不太有用了（除非链路层设计的有问题）。相反，当无线带宽延迟乘积足够大，SNOOP可以表现出显著的性能提高（与标准TCP相比）。有关该主题的更深层的讨论，请参见[Vaidya99]。
延迟重复包方案在SNOOP工作良好的环境下能起到性能改善作用。通常情况下，由延迟重复包方案之所以能提高性能，就是因为它有降低因拥塞和中继错误引发的丢包率的功能。当与拥塞相关的丢包产生时，延迟中继方案会进行不必要的延迟中继，因而，在处理拥塞丢包情况时，延迟中继方案并不能象SNOOP一样提高性能。然而，仿真结果[Vaidya99]表明，延迟中继方案在中度拥塞丢包情况下，可以获得明显的性能提高。
与SNOOP类似，WTCP [WTCP]也保留了端对端的语法。在WTCP中，中间介质节点使用了一种复杂的方案来隐藏它用于恢复无线连接部分错误而消耗的时间（包括由错误恢复引发的中继，也可能包括用于处理拥塞的时间）。这种想法有助于发送方能较好地预计往返时间周期。为了工作得更有效率，它假定TCP端点（endpoint）实现RFC1323[TCPHP]中的时间戳（Timestamp）选项。然而不幸的是，支持RFC1323的TCP实现目前应用得尚不普遍。而且，WTCP要求只在中间介质节点处修改。
SNOOP和WTCP要求中间介质节点检查并操作便携移动设备和有线Internet上的TCP服务器之间的通信。除非中间介质节点也共享移动设备和其端对端连接点间的安全联系，否则，SNOOP和WTCP在IP通信处于加密状态时无法工作。
Montenegro, et al. Informational [Page 28]
它们也要求数据和相应的确认信息穿越相同的中间节点。而且，如果中间节点在传输层对穿越无线连接的信息包进行了中继，将会对链路层造成双重影响。SNOOP的设计者对此已经做了解答，即需要有个TCP感知（TCP-aware）的链路层。这是正确的解决方法：连接层和网络层应该彼此增强沟通，而不象传统OSI模型规定的那么死板。
不管在传输模式还是通道模式，经过IPSEC的ESP头加密的IP包使中间节点无法智能地处理TCP头及有效何载。这就排除了SNOOP（和WTCP）应用的可能，因为它需要在两个方向对TCP头进行检查。可能的解决包括：
- 为SNOOP（或WTCP）的中间节点建立与客户及服务器间的安全联系。
- IPSEC通道模式在SNOOP中间节点处终止。
然而，这些技术要求用户信任中间节点。用户要保护其隐私并想提高性能可以使用SSL或者端对端安全方式的SOCKS，这些在传输层已经实现了。但是它们并不象IPSEC那样可以抵御某些安全攻击（如，基于TCP顺序号的猜测攻击）。
建议：立即在中间节点处实现SNOOP。研究结果令人欣喜，它是不可见的优化，对于客户端和服务器端来说，都不需做任何修改，而只要修改中间节点（对于基本的没有SACK的SNOOP来说）就可以了。当然，如上所述，SNOOP在下面情形下还稍稍显得效率不够：
1. 无线连接提供了可靠的、按顺序的包传递；
2. 无线连接的带宽延迟乘积比四个段小。
4.10.4 用性能增强代理处理断开阶段（PEPs to handle Periods of Disconnection）
连接中断情形在无线网络中经常发生，不管是在切换（handoff）状态，还是因资源匮乏而掉线，或是一些正常的障碍，都可能引发连接中断。在中断状态下，TCP发送方无法收到它所期望的确认回应。在中继计时期满后，TCP将会关闭所有与该错误相关的拥塞窗口。当连接中断以后，中继包就没有用了。
Montenegro, et al. Informational [Page 29]
[M-TCP]致力于帮助TCP能更好地处理切换及断线状态，同时也保留了端对端语法。M-TCP增加了些元素：在无线网络边界处增设超级用户主机（supervisor host，SH-TCP）。
该中间节点监视着由发送方到移动设备的通信状况，它不会中止端对端语法，因为由中间节点发送给发送方的确认信号（ACKs）正是移动节点所发出的。其原理是对最后一个字节不做确认。因此SH-TCP能够通过将一个设置成零的窗口做为对最后字节的确认发送出去，从而关闭发送方窗口，这样，发送方就可以保持持续的模式（persist mode）。
第二种优化需要在中间节点及移动主机之间做些工作。对于后者来说，TCP需要关注当前的连接状态，以在断线时可以冻结所有的定时器。在恢复连接时，移动设备发送一个用已收到的最多字节数来标记的确认信号（ACK）。中间节点监视无线连接的通讯流，当它假定移动设备掉线后，将会向SH-TCP发出通知，由SH-TCP发送个确认信号来关闭发送方窗口（如上段所述）。当中间节点收到标记为重连接的重复确认之后，它就知道移动设备又连回来了，这时，它将向发送方发出重复确认信号（ACK），并打开窗口。发送方会退出持续模式（persist mode），重新回到以前的状态，用先前的速率进行数据传递。发送方会对之前未被移动结点确认的任何数据进行中继。只要不是覆盖操作或软件方式切换，就没关系，因为之前的中间系统可缩短窗口，并可在其收到移动设备传来的指令后立即用个新窗口来修改它。
建议：M-TCP并非是目前内定的采纳方案，因为还有许多更好的建议，同时目前的TCP/IP实现在处理零窗口还有些问题。请继续关注该领域的研究。
4.11 标题压缩选择（Header Compression Alternatives）
由于远程窄带网络（LTN）是有带宽约束的，因而对公开段中每个字节进行压缩是值得一试的。
有关TCP和IP头压缩的定义请参见[RFC1144，IPHC，IPHC-RTP，IPHC-PPP]，提供了如下好处：
- 提高了交互式应用的回应时间。
- 允许在好的线性效率下用小包来传递批量数据。
Montenegro, et al. Informational [Page 30]
