这篇文章的内容是相当初级的，但我认为它很重要。几乎我们业务中的一切事物都依赖于在更低级别上对事物的抽象和特殊化，但是抽象只是一定程度上的抽象。在某些理想情况下，接口是干净的、定义良好的并且有针对的；应用程序不担心OS的工作方式，OS不必担心硬件的工作方式，OSI模型的第四层也不必担心第三层的工作方式。

　　假设您是某一级别的专家，并假定您之下的级别都工作正常。但这样做真的有用吗？如果正在编写一个应用程序，那么知道OS的工作方式并且了解数据库存储字符的方式实际上会更好一些，好的OS必须担心硬件的工作方式，如果您认为TCP并不担心IP的实现方式，那么您错得很离谱。

　　因此，在这里，假定使用的是运行在OSI 第七层之上的Web应用程序和服务，我们将降低n个层去查看第四层（甚至更低），看看那里放生了什么。我们还将讨论TCP与UDP之间的差异、什么是多播、为什么有时它起作用、而有时它又不起作用。相信我，这会有用，这会引出有关PTSpy在G6中的工作方式的一些信息，以及关于如何更好使用它的一些想法。

　　因此，让我们从HTTP开始。它是与我们在这里做的大部分工作直接有关的协议。HTTP以及其他大多数应用网络（SQL*NET、ALI Search等）都运行在网络层的第七层，即应用层，该层位于在第四层操作的TCP的顶部。那么什么是TCP呢？

　　TCP（传输控制协议，Transmission Control Protocol）和UDP是Internet的主要底层网络协议之一。这两个协议都构建在另一个协议（IP，即Internet Protocol）之上 。IP作用于TCP和UDP之下的网络层（第三层）。因此，要理解TCP，让我们先来看看IP。然后我们将继续前进，讨论TCP在IP的顶部做什么。

　　IP：Internet Protocol

　　IP提供将数据包从一个地方路由到另一个地方的基本能力。它实现这一点的方式是：为每个“位置”或“网络上的设备”提供一个指定的地址（即IP地址），并根据该地址指定这些设备应该如何移动数据包。现在，IP和位于它之下的协议层（第二层，即数据连接层，通常由Ethernet或WiFi表示）之间的功能上的差异在于：在第二层上，设备总是确实知道如何将数据包发送到网络上的每个设备。在第二层上，要么确实知道如何将数据发送到目的地（顺便说一句，目的地通常用“MAC地址”表示），要么不可能将数据发送到目的地。（例如，Ethernet和WiFi只是在整个网络上广播数据包，希望目标接收者听到其MAC地址并挑选出该数据包。如果没有这样的地址，或者目标接收者没有听到该地址，那么Ethernet无法将数据包发送到目的地。[顺便说一句，网络“嗅探器”也是通过使用此广播来工作的。]调制解调器拨号连接中使用的PPP可以将任何数据发送到某个目的地，只要您拨号连接到机器。）

　　IP怎样提供连接单独网络的方法呢？如果这样连接，那么一个网络上的设备就可以将数据发送到另一个网络上的设备，无需知道这些设备在哪里以及如何正确到达那儿。这里要谈到互联网络（inter-net），即“网络之间”的应用。网络互联是通过指定路由规则来实现的，路由规则定义了网络设备对带有目标地址的数据包应该做什么。该规则大致如下：如果目的地是本地（即您知道该地址在哪儿，因为它在同一网络上），则将数据包发送到目的地；否则，将数据包发送到非常符合该目标地址的路由器列表中的某个地址。路由器遵从完全相同的规则，除非假定它同时属于两个或多个网络，这样就会有多个本地目的地，通常还有一个更长的用于未知目的地的其他路由器列表。

　　现在非常明确的是，IP只是提供了将数据包发送到通过惟一IP地址指定的目的地的能力。它可以将数据包发送到任何网络的任何地方（与其他低级协议不同），但仅此而已。值得注意的是：

　　它不提供传送、接收或失败的通知。

　　它不提供 “端口数字”或其他在目标IP地址上分组数据包的方法的任何信息。

　　它不提供双向通信。

　　它是无序的，否则按某种特殊的方式将多个数据包分为一组。

　　IP最简单的类比邮政服务。将一张写好地址的明信片投入邮箱，然后邮政部门就会将这张明信片发送到您写的地址。是否发送到目的地，您就不得而知了。在明信片到达目的地时，您不知道室友是否读了它。如果您想得到答复，收件人无法在同一张卡片上写字并将它递回给邮局的人；收件人必须写自己的短信条，贴上邮票，写上地址，然后再亲自将它发送。

　　TCP：Transmission Control Protocol（传输控制协议）

　　虽然IP没有提供任何其他功能，但TCP确实提供了一些功能。如果您查看了IP没有提供的功能的列表，然后对比邮政服务的类似列表，您会说“当然可以进行双向通信。人们通常来回写信，并且总在进行交流，”或者您会说“您可以请求收件人或者邮政服务人员给您发送一封回执。”再或者可以说“得了，虚伪的家伙，您可以在明信片上写上编号，按顺序发送它们，并告诉收件人按顺序阅读它们，让您知道是否有遗漏，”那么您是正确的。这确实是TCP所做的事情。它获得基本IP（或邮政服务），指定如何使用它，并指定在消息中放入哪些内容来获得所有这些额外的功能。

　　所以，TCP的真正作用是实现IP设备之间的多个可信赖连接的概念。这是什么意思呢？意思是说您可以发送关于某一特定会话（端口或连接）的连续消息（数据包），而这些数据包会按发送它们的顺序被接收，在已发送数据包之间不会有遗漏的数据包。（此外，也没有重复的数据包。）确保这一点得以实现的方式是：在每个数据包上贴上端口号和序列号，前者用于区分和确认多个连接或会话，后者用于让收件人确认传输过程中数据可能的丢失时间。此外，它指定收件人必须肯定接收的每个数据字节（没必要明确声明，可以简单地说“我接收了到13456字节的所有字节”；也可以选择性地予以肯定，“我接收了845和13433之间的所有字节”），这样发送者就可以知道是否有遗漏的数据需要重发。最后要说明的是，每个连接在不明确说明的情况下都是双向的，而且收件人可以在不明确重新填写地址的情况下只将数据发送“回来”（类似于随每个数据包发送了一个自动填写地址的回应信封）。

　　如您所见，如果数据包丢失，或者是不按顺序到达目的地的，那么TCP实际上有一大堆工作要做。如果我们继续与邮政服务进行类比，那么在这里TCP有点像您的私人助理，他为您收集邮件、对邮件进行分组、按顺序排列邮件、将它带给您阅读、取得您的回应、将邮件组织好并发送回来。如果邮政服务是非常可靠的，那么私人助理的工作非常简单，他只是一个将纸张来回传递的中间人。如果邮政服务有很多疏漏，或者您有许多邮件，那么私人助理必须多做很多工作，请求重新发送邮件，并追踪和存储大量消息。

　　UDP: User Datagram Protocol（用户数据报协议）

　　从另一方面说，UDP要简单得多。它做了IP所做的工作，但又增加了端口的概念，因此您可以根据IP地址将消息发送给特定收件人。它不需要排序、连接、双向通信或确认。

　　您可能认为UDP是不可靠的，因为如您所知，TCP被认为是同类协议中最可靠的。但实际上，在通过相同的网络段，或者在通过具有良好质量调整并且没有过多通信量的LAN时，UDP还是非常可靠的。如果没有数据包遗漏并且这些数据包是按顺序到达的（在短LAN链接上，这是最常出现的情况），则无需进行任何数据包重发，因为所有确认和围绕着TCP的等待都只是一种开销浪费，并且会产生延时。对于可以忍受数据包丢失的应用程序（比如说，实时音频和视频通信），UDP通常是一个好的选择，即使在不怎么好的网络上也是如此。还可以将UDP用于短消息和通知。例如，DHCP和DNS都使用UDP。值得关注的是，Unix Network File System（NFS）在LAN上使用的也是UDP。尽管您认为文件系统应该使用可靠的TCP连接，但NFS的实现者们认为他们可以使用UDP获得更好的性能，并构建他们自己的确保可靠性的机制，这主要由应用程序决定。

　　顺便说一句，UDP之所以称为“用户数据报协议”是因为它是由操作系统的人设计的。“数据报”只是“数据包”的另一种说法。“用户”在这里并不意味着像您这样的用户；它表示计算机上的一个程序，该程序不是操作系统的一部分。人们认为IP是低级的，它由编写部分OS的人使用，尽管UDP提供了大多数类似功能（数据报），但它仍被设计用于“用户”（非OS）程序。

　　多播

　　在这里，当暗示IP（以及UDP和TCP）将数据包从某个网络上的设备发送到另一个设备时，我稍微简化了一下TCP/IP/UDP的讨论。更确切地说，IP将数据包从一个IP地址发送到另一个IP地址。多播的诀窍在于同一时间将相同数据包发送到多个设备，某些IP地址可以设计为多播地址，并被设计为同一时间可用于许多设备。

　　关于IP多播，我知道的第一件事是只存在UDP多播，没有TCP多播这回事。为什么呢？多播的重点是提高网络效率，将同一数据包发送给尽可能多的可能未知的计算机。但是每个TCP连接可能需要重发不同的丢失的数据包，或者可能存在不同延迟、不同顺序的到达和数据包集。因此，为每个可能的设备管理和发送所有数据包是与资源有关的，甚至可能违背使用多播的初衷。（这是无论无何也不可能的，因为多播无法知道数据包实际发往的地方。）

　　此外，根据词语的逆构法，常规的非多播UDP（和TCP）消息被称为单播。

　　下一件需要知道的事情是，多播通常不是通过路由器发送到另一个网络的。其中的一些原因如下：

　　多数多播数据包都有一个很低的TTL：所有IP数据包都有一个生存时间，即TTL。与DNS记录不同，IP数据包的TTL是指数据包到达其目的地所制造的最大网络跳数。单播数据包通常允许跨越大约30个网络（即被发送或“跳跃”29个路由器）。跨越网络很少超过15个跳跃，因此，该限制实际上扼杀了陷入配置不好的网络中的循环的数据包。但大多数发送多播的应用程序将TTL设置为一个较低的数值，通常为0（那儿的消息甚至不需要离开初始设备）、1（消息只能到达本地网络上的计算机）或者2（消息将通过一个路由器）。让打算多播到未知机器的应用程序通过整个校园网络的情况是很少见的，在整个Internet上更少见。

　　多数路由器上设置的TTL阈值很高：许多网络路由器，特别是WAN路由器和Internet网关路由器，有一个更高的TTL阈值设置，因此，它们不会发送TTL低于（比如说）15的多播数据包。这样可以阻止本地网络以外的多播的意外泄露。

　　路由器根本不能配置用于路由多播，或者只能为特定地址配置，抑或用于组播数据包。

　　UDP多播看起来可能有点奇怪，但它实际上比您想象得更普通。它不能用于Web视频站点，比如YouTube，因为这些站点需要在用户需要时立刻发送视频，而不是在同一时间给所有用户发送视频，并且UDP多播不能用于VoIP通信量。但是，可将UDP多播用于应用程序中的许多发现和自动配置，如Skype、iTunes和uPnP。还可以将它用于ALUI门户的少数地方。

　　间谍日志（Spy Logging）

　　自G6发布之后，Spy（以前称为PTSpy）和Plumtree Logging Framework（AL-something Logging Toolkit或类似东西）都使用UDP来完成工作。有消息要记录的应用程序正是通过UDP来发送消息。现在来回想一下，UDP并不担心诸如实际交付、顺序、纠错和流控制之类的事。消息可以以“发送后就去处理其他工作”或“将它扔进邮箱，然后永远忘记它”的方式将消息发送出去。不存在记录或等待，因此，对于程序而言，发送消息是非常便宜和快捷的。

　　事实上，对于通过UDP将日志消息发送出去的程序而言，花费是相当大的，因为它将检查是否应该过滤消息。因此，G6门户（以及collab、api服务器和自动服务器等）不受检查的干扰，只是无条件地将UDP日志消息发送出来即可。

　　相反，5.x和更早的门户版本是肯定进行记录的：在程序继续下一个操作之前，每条消息都被写入文件（或屏幕）。这对性能产生很大的影响，以致于只能在正积极进行调试时进行追踪，甚至随后必须限制记录的内容。显示UDP数据包造成的延迟是如此之短，以致于G6追踪的次数更多，并且它会在整个程序运行期间发送追踪消息。

　　现在，我们还有一组从网络读取这些UDP数据包的程序。最熟悉的是Spy本身，它捕获数据包，选出您想查看的数据包，并且只显示这些数据包。这些程序中还包括Logger Service，其工作原理类似，但它会重新格式化这些消息，并将它们写入一个文本文件。

　　您甚至可能并不实际知道ALUI G6 Logging Framework将使用UDP来发送日志消息，因为通常应用程序被设置为“仅本地记录”，将数据包TTL设置为零，不允许数据包离开初始计算机（但可以由同一计算机上的目标进行选择）。同时，Spy实际上是与应用程序一起安装的。在启动Spying时，它只从本地应用程序中挑选数据包，这看起来类似于以前的5.x PTSpy，只进行本地连接，并本地安装应用程序。但实际上，Spy消息的应用程序和查看器现在通过网络紧密耦合在一起，而运行是彼此独立的。

　　因为UDP提供了极大的性能优势，所以在必要时，我们有如此多的详细记录可用，但是因为UDP不可靠的特性，因此也存在一些日志消息丢失的可能性。这事实上并不是一个灾难，但是如果您正在进行调试并且不知道可能发生什么，那么可能是有点恼人。门户上有许多活动（因此有一大堆消息要发送）时，可能发生这种情况，网络非常繁忙，因此数据包会丢失，或者捕获程序运行得非常慢。实际上，最常见的情况是：消息在Spy程序运行缓慢时丢失，可能是因为机器繁忙，也可能是其他一些资源问题造成的。我们发现，在将内容写入屏幕时，尤其是在使用X-Windows Spy时，可能遗漏许多消息。

　　我通常建议在Unix上使用命令行记录仪。

　　还有一件要注意的事是，Spy通常是通过UDP多播，而不是单播发送出去的。这意味着，首先，选取多个程序并从单个应用程序读取和记录日志消息是有可能的。例如，在您以交互方式查看Spy时，Logging Service可能正将相同或不同的一组消息记录到某个文件。其次，您还可以使用远程机器上的单个（或多个）程序远程监视多个应用程序。只需确保该应用程序的“仅本地记录”选项被设置为false即可，而您的网络和陆游器会将数据包从ALUI应用程序路由到记录监听器。接着，只需打开Spy，选择View->Set Filters，然后选择Edit->Add Message Sender即可。Spy会寻找配置用来通过网络上的UDP多播完成记录的应用程序（并且该应用程序可以搜索Spy），并允许您选择捕获和记录消息。

　　Collab群集

　　在配置Collaboration Server群集时也需要用到UDP。Collab群集用于Collab服务器之间的缓存失效（cache invalidation）。当在某台Collab服务器上更新一个对象时，需要将一条消息发送给所有服务器以识别该对象。这是一条短而简单的消息。

　　有几种配置可以设置Collab发送该消息。最常见的两种配置应该是“lan群集”配置和“lan多播群集”配置。这两种配置都使用UDP来发送消息。单播配置要求用户列出每个服务器配置中的群集中的其他每台服务器，但只在服务器可实际到达彼此的网络上工作。多播设置需要的配置和配置维护更少一些，因为用户要做的是将每个配置上的多播监听地址设置为相同值，但这样会存在一定的风险，网络可能不支持服务器之间的多播，或不在服务器之间进行多播。此外，在不进行网络追踪来寻找Collab缓存无效消息的情况很难确定是否能正常运行，就大部分Collab而言，会运行得很好，并且可能不会有用户注意到不同服务器间的缓存中存在不一致性。

　　好了，我希望这篇文章具有信息性、很有趣并且很有用。

原文出处：http://dev2dev.bea.com/blog/gkanapathy/archive/2007/07/tcp_udp_unicast.html