我有一个奇怪的主意。据我所知，我听说过使用UDP传输文件的软件，从而减少了TCP数据包中的开销。
如果我的应用程序需要TCP，并且我的LAN已设置了与海岸另一端的另一个数据中心进行通信的软件，并且在其末端进行了软件设置。是否可以通过UDP发送实际数据，而不是在两端模拟TCP？
有人对此类项目有任何想法或信息吗？
如果您询问是否可以将UDP用作Layer 2，则答案是肯定的。有多种协议可让您使用UDP传输创建到另一个网络的隧道，例如L2TP甚至IPsec (with NAT traversal)。您也可以在application layer上执行此操作。
如果您问是否可以在UDP中实现TCP，答案是否定的。首先，TCP packets和UDP packets的格式不兼容。其次，TCP和UDP具有不同的协议号（在IP header中看到），这意味着发往UDP端口的TCP流量将不会传递到正确的上层协议。
TCP和UDP都建立在IP之上，但是TCP使用不同的数据包结构，并且在第2层上无法使用UDP数据包模拟TCP。
当然，如果您同时控制源和目标，则可以为TCP数据包创建可靠的UDP隧道。这将需要UDP数据包正文中的一些内部信息（数据包编号，ack / nack标志）。
有一个有趣的项目http://udt.sourceforge.net/
这是建立在UDP之上的具有广播功能的可靠文件传输机制。
PseudoTCP是在UDP之上实现TCP算法的协议。引入它是因为TCP的NAT遍历比UDP复杂得多。但是某些P2P应用程序确实需要在节点之间进行可靠的数据传输。
据我所知，有两个PseudoTCP变体：Libjingle和Libnice。Libjingle是Google的开放源代码库，最初用于gtalk。您可以看一下libjingle中的文件共享示例：https://developers.google.com/talk/libjingle/file_share。最近，Chrome桌面还使用libjingle的PseudoTCP实现来实现可靠的连接。
如果我的应用程序需要TCP，并且我的LAN具有用于通讯的软件设置，与海岸另一侧的另一个数据中心一起使用软件在他们的末端设置。是否可以通过发送实际数据UDP，而不是在两端都模拟TCP？
没有UDP套接字与TCP套接字位于不同的名称空间中。您将无法在一端写入UDP，而在另一端无法发送或接收TCP。 TCP和UDP是对等协议；两者都存在于IP之上的层。您不能使用一个来欺骗另一个。
是的，您可以在UDP上开发一个模拟TCP的协议。但是，如果您完全模拟TCP，从技术上讲它将有更多开销。因为TCP是作为数据包实现的，而模拟的TCP是在数据包的主体中实现的。
如果只需要TCP的一两个功能（例如基本排序），则在UDP中实现它很有用。
Halo使用2-3（IIRC）UDP协议来模拟TCP的不同功能，然后使用完整的TCP来初始化游戏状态。 I Shot You First Networking, GDC publication
例如，在一种情况下，他们发送3个重复的UDP数据包以克服数据包丢失。
如果在两端控制软件，并且构建自己的协议具有成本效益，那么UDP可以具有通用性。
现在在Linux-3.18 +上执行此操作的一种方法是使用Foo over UDP（FOU），它实现了通用UDP封装（GUE）。这是一个不错的introduction to FOU，并且是ip-fou的手册页。
或者，如果您想使用基于[开源] UDP的文件传输系统，则UDT，UFTP，Tsunami-UDP甚至Google的QUIC之类的东西。
嗯，我相信。您需要在两端使用代理，但是应该可以。
您将要遇到的最大问题是，UDP的设计理念是，您不必担心某些数据包是否永远不会到达另一端。
这里有一些更多信息的链接：
http://www.cyberciti.biz/faq/key-differences-between-tcp-and-udp-protocols/
恕我直言，通过UDP传输文件不是一个好主意。
TCP的问题在于其算法，而不是其标头。
您当然可以在UDP之上实现TCP算法。这实际上与在UDP数据报内部隧道传输TCP数据报相同。但是，所有要做的就是为每个数据包增加更多字节的开销，并需要另一个端点来解包这些数据包。
UDP本身只是IP之上的薄薄垫片：它是访问IP分组交换网络的便捷方法，而不必深入内核或从路由器接收特殊处理。在UDP之上实现可靠传输的主要原因是摆脱TCP算法，而转向更高效的协议。上面提到FileCatalyst是一家这样做的公司，而我自己的公司Data Expedition，Inc.也这样做。
所以您可以在UDP之上实现TCP算法，但您不想这样做。
您可以模拟类似通过UDP的连接，也可以添加可靠性检查以及排序和重传等。 -但是，它仍然不是TCP，它只是发挥作用。
当然，目的之一可以是一种适应性的“集线器”或“代理”。那么，您就没有2端解决方案，而实际上是4端解决方案-一对带有“真实” TCP，另一对带有“自编织”“ TCP”-您将其与适当制作的程序组合在一起。