TCP/IP协议与UDP协议

r囧r小猫 2022-07-16 09:55 201阅读 0赞

# [TCP/IP协议与UDP协议][TCP_IP_UDP] #

## TCP/IP协议 ##

TCP/IP是“传输控制协议/因特网协议”的缩略语，指的是一些主要协议中的两个协议，这些协议也被称为因特网协议簇。TCP/IP协议可为任意的计算机系统提供网络连接，其连接可以跨越不同的网络介质、应对可能的不利条件。  
因特网的一个基本设计目标是允许广泛的网络特质，接纳诸如带宽、延时、丢包、包失序以及数据包的最大长度方面的不同。另一个目标是健壮性，能应对单个网络、网关和主机的失效，并在这种情况下仍能利用任何可用的带宽。其最终目标是实现全面的“开放系统互连”：一个因特网主机必须能够跨越不同的因特网路径，与任何其他因特网主机稳定地、有效地互操作。  
TCP/IP的强大之处在于其兼容性，它能够兼容几乎所有的低层网络架构。由于其协议都基于开放标准，这一事实更巩固了它的地位。  
因特网协议所提供的服务与OSI网络参考模型的会话层、表示层、传输层和网络层相当。正如我们在第2章描述的那样，在异构网络中的任何位置，网络层和传输层对数据编址并发送数据（可靠的或不可靠的），会话层同步两端应用程序之间的通信，表示层为应用程序准备信息。  
图3-1展示了TCP/IP协议簇与OSI网络参考模型之间的相对关系，及其与Windows Sockets模型的对比。从图中可以看到，TCP和IP并不是TCP/IP簇中仅有的两个协议。同时还应注意到，数据链路层和物理层不是因特网协议簇的组成部分。正是因为独立于低层，使得TCP/IP得以在任何网络驱动和网络介质（以太网、令牌环网、FDDI等）上运行。应用层也不包含在TCP/IP簇中，因为网络应用和操作系统平台之间的用户接口变化很大。  
   
![Center][]

图3-1　TCP/IP协议簇与OSI网络参考模型和Windows Sockets模型的比较  
下面是图3-1中提到的每个协议所提供的服务：  
会话层和表示层：  
文件传输协议（File Transfer Protocol，FTP）：文件传输。  
简单邮件传输协议（Simple Mail Transfer Protocol，SMTP）：电子邮件服务。  
远程登录（Telnet）：用于远程登录的终端协商。  
域名服务（Domain Name Services，DNS）：主机名到IP地址的映射。  
传输层：  
用户数据报协议（User Datagram Protocol，UDP）：无连接数据传输。  
传输控制协议（Transmission Control protocol，TCP）：可靠的数据传输。  
网络层：  
因特网协议（Internet Protocol，IP）：独立于硬件的寻址、路由、分片和数据包重组。  
地址解析协议（Address Resolution Protocol，ARP）：IP地址到硬件地址的映射。  
因特网控制消息协议（Internet Control Message Protocol，ICMP）：错误和控制消息。  
诸如Telnet、FTP和SMTP一类的应用（上层）协议，对于TCP/IP协议簇所提供的互操作能力是很重要的，它们为一般的网络服务提供了公共的应用协议，还可以列举很多其他的协议（例如，archie、gopher、talk、veronica和wais），但是前述3种协议向来被认为是TCP/IP的组成部分，因为它们提供了最基本的网络服务：电子邮件、文件传输和远程登录。

WinSock API提供了对传输层和网络层协议服务（即网络系统）的访问。高层协议不能通过WinSock API访问，而是必须借助WinSock应用程序来实现。域名服务（DNS）协议是一个值得注意的特例，DNS是一个“支持协议”，它使应用程序能够查找主机名以及主机地址（如果一个应用程序知道了主机名，那么就可以查找到地址；反之亦然）。这种便利的（如果不是必需的）服务可以通过WinSock API获得。本章后面将会详细地描述这个服务，并在第8章中讲解如何访问这些服务（第8章中讲解诸如gethostbyname（）和WSAAsyncGetHostByName（）等WinSock函数）。

## UDP协议 ##

无连接的传输，也被称为数据报服务，是不可靠的服务。但是，不要把“可靠性”与“质量”混为一谈，这种服务之所以是不可靠的，原因在于：它既不提供有保证的交付，也不维持数据包的顺序。如果一个数据报没有到达目的地，或者在传输过程中被损坏了，那么该服务不会向你通报错误。如果一个应用程序发送了数据报A，然后是数据报B，那么数据报B有可能先于数据报A到达（见图3-2）。  
数据报服务可以与邮政投递相类比，我们通常不认为邮政服务有什么不可靠，但是一类（first-dass）邮件并不保证投递（到达），也不维持投递顺序，当然，大多数一类邮件都能顺利地送达（我们通常并不在意送达的顺序）。  
无连接传输服务简单，而简单就是其优势，它开销小，所以效率高，因而带来性能上的优势，它也很容易使用。虽然数据报服务是不可靠的，但是采用数据报服务的应用程序却不一定不可靠，任何数据报应用程序都能够实现可靠的服务。  
接收数据的应用程序可以针对每个收到的数据报发送确认信息，发送数据的应用程序如果在给定的时间内没有收到确认信息，可以重发这个数据报。每个数据报可以携带一个顺序号或者时间戳，这样接收端可以根据需要重新建立起数据报的顺序，并且能够检测出接收的重复数据，然后丢弃它。通过在基本服务上增加上述功能来提高可靠性，这与向邮局索取发送挂号信的收据没有什么不同。  
![Center 1][]  
当一个应用程序发送了一个数据报，数据报服务并不通告其是否到达，如果应用程序发送了两个数据报，任何一个都有可能先于另一个到达  
数据报服务对于短事务（short transaction）类的应用比较理想，对于这类应用，创建和拆除一个连接的工作量比数据传输本身还要大。数据报服务对于那些本身就隐含了确认功能的应用也很合适。例如，一个应用程序向数据库服务器发送查询请求并等待回复，如果得到了完整的回复，则应用程序完成任务；如果超时后仍没有得到回复，那么应用程序就会重新发起查询请求（或者采取其他操作，例如向用户显示一个错误信息）。  
有些应用程序拿可靠性来换取更高的容量，通过采用数据报服务实现高数据吞吐量，特别是在能够容忍数据丢失的情况下。这些应用程序在应用层上对数据进行排序、提供发送端和接收端之间的应用层同步。如那些发送视频或音频信号或者从实时数据采集设备上接收采样数据的系统，都是这类应用的一些例子。  
很奇怪的是，有一些应用程序在采用“可靠”服务后反而变得不可靠。例如，一些实时的音频和视频应用程序，并不希望等待数据重传或者允许传输控制机制干扰“自然的”数据流。  
由于数据报服务是无连接的（即不与远程的某单一主机“绑定”），所以，它还能够支持多播和广播。有些应用程序需要使用同一个地址同时与多台主机通信，而面向连接的协议不能提供这种服务。  
用户数据报协议（UDP）是TCP/IP簇中的一个主要的数据报协议。因特网控制消息协议（ICMP）则是另一个数据报传输协议，可以通过使用SOCK\_RAW socket来访问ICMP。SOCK\_RAW socket是Windows Sockets API的一个可选功能，所以，ICMP并不是普遍可用的。  
像任何数据报协议一样，UDP发送和接收分离的数据分组。换言之，如果在一次发送操作中传输了一定数量的字节，那么在一次接收操作中也将接收同样数量的字节。数据在网络传输过程中，将保持其分组的边界。UDP也采用TCP/IP标准的校验和算法（16位字的1的补码和）来对所接收的数据进行粗略的校验（UDP校验和计算是TCP/IP协议栈的可选项，但是大多数栈都启用该功能）。  
UDP不提供有保证的传输。当TCP/IP实现软件接收到一个UDP数据报时，并不反馈接收验证的确认信息，UDP也不维持传输的顺序。尽管如此，就像在前面所讨论的那样，使用UDP的Windows Sockets应用程序还是能够实现可靠性和顺序化的。

## 两种协议的区别 ##

在数据传输方面，网络应用开发人员必须在面向连接协议和无连接协议之间做出选择。尽可能多地了解这些可用的传输协议的服务能力与局限性是很重要的，因为在设计Windows Sockets应用程序时，对传输协议的选择是面临的重大决策之一。首先，你需要决定应用程序为用户提供什么服务；其次，再决定哪一种传输协议最适合这个任务。  
应用程序开发人员通常也会认为：TCP的网络数据包及其处理开销将对数据的吞吐量带来不利的影响，所以他们会倾向于UDP的简洁性，然后，试图在应用程序中通过某些机制保证可靠性。采用UDP的结果是：比起使用TCP协议，开发人员付出了更多的劳动，并在应用程序中引入了更多的计算开销。“谁忽视了TCP，谁就注定要推倒重来。”  
经验法则：采用TCP吧，除非你的确有不用的理由。  
经验证明，在性价比方面，TCP的计算与网络开销对于网络吞吐量的影响可以忽略不计。采用TCP的一个最重要的理由是程序的编写更容易了。在前面部分我们给出了一些适合采用无连接协议的应用例子，下面是这类应用的一些特点：  
使用广播和多播服务。  
实时数据（如音频和视频）对延时敏感，因此，它们不能接受数据重传或诸如TCP的慢开始和Nagle算法一类的拥塞控制机制。  
需要具有内在确认功能的短事务，能接受重复的数据报。  
为了避免协议选择问题，有时可以在应用程序的设计中采用两个socket：分别为每个协议建立一个socket。例如，UNIX的“talk”应用程序采用UDP发送初始的端口查询请求，以获取可连接的端口。这个查询可以通过广播的方式发送，以发现运行talk服务器的主机，当收到肯定的回应时，返回的UDP数据报中包含了可连接的talk服务的TCP端口号。

[TCP_IP_UDP]: http://book.51cto.com/art/201209/356835.htm
[Center]: /images/20220716/21ddaa04c82e4cb1ae0c7631bf1a5d41.png
[Center 1]: /images/20220716/cfbfab0d1d3140ab94b4918ef53a7fb0.png