P协议和UDP协议.docx
《P协议和UDP协议.docx》由会员分享，可在线阅读，更多相关《P协议和UDP协议.docx（51页珍藏版）》请在冰点文库上搜索。
P协议和UDP协议
第二章TCP协议和UDP协议
2.1概述
本章从网络程序设计角度提供足够的细节以理解如何使用TCP协议和UDP协议。
同时提供这些协议的实际设计、具体实现和相关的本卷须知。
本章的焦点是计算机网络传输层效劳，即面向连接效劳和面向无连接效劳，它们所使用的相关协议分别是TCP协议和UDP协议。
目前绝大多数的客户效劳器应用程序都使用TCP协议或UDP协议。
这两个协议使用网络层协议IP：
IPv4或IPv6。
尽管应用程序可以绕过传输层直接使用IPv4或IPv6，但这种方法（称为原始套接口）使用较少。
UDP是一个简单的传输层协议，应用程序写一个数据报到UDP套接口，由它封装成IPv4或IPv6数据报，然后发送到目的地址。
但是，UDP并不能保证UDP数据报最终能够到达目的地。
使用UDP进行程序设计所遇到的问题是缺乏可靠性。
如果要确保一个数据报能够到达目的地，必须在应用程序中建立相应的特性，主要包括：
来自另一端确实认、超时、重传等等。
每个UDP数据报都有一定的长度，可以把一个数据报看作一个记录。
如果数据报最终正确地到达目的地（即分组到达目的地且校验和正确），那么该数据报的长度将传递给接收方的应用进程。
而TCP是一个字节流协议，无记录边界。
向应用程序提供的TCP效劳与UDP效劳不同。
首先，TCP提供客户与效劳器的连接；其次，TCP提供可靠性；第三，TCP通过给所发送数据的每一个字节关联一个序列号进行排序；第四，TCP提供流量控制。
总之，UDP协议是一种简单的、不可靠的数据报协议，而TCP协议是一种复杂的、可靠的字节流协议。
只有正确理解这两个协议提供给应用程序的效劳，才能清楚这些协议能够处理什么，应用程序又需要处理什么。
只有深入理解TCP协议和UDP协议的某些特征，才能更容易编写健壮的、高效的客户效劳器程序。
2.2UDP：
用户数据报协议
UDP是一个简单的面向数据报的传输层协议：
进程的每个输出操作刚好产生一个UDP数据报，该数据报导致一个IP数据报的发送。
图2-1显示了作为IP数据报的UDP数据报的封装。
IP数据报
UDP数据报
IP报头
UDP报头
UDP数据
20字节8字节
图2-1UDP封装
RFC768[Postel1980]是UDP的官方描述。
UDP不提供可靠性：
它发送应用程序数据到IP层的数据报，但不保证这些数据报到达其目的地。
鉴于这种不可靠性，我们或许认为应防止UDP而总使用一个可靠的协议。
应用程序应注意所产生IP数据报的大小。
假设超出网络的MTU，该IP报会被分段。
这适用于数据报从源到目的所跨越的每个网络，不只是适用于发送主机的第一个网络。
2.2.1UDP报头
图2-2列出了UDP报头的各个域。
图2-2UDP报头
端口号标识出发送进程和接收进程。
由于IP已将到来的IP数据报分解复用为TCP和UDP，这意味着TCP端口号由TCP查看，UDP端口号由UDP查看。
TCP端口号与UCP端口号无关。
尽管二者无关，但假设一个众所周和的效劳TCP和UDP都提供，端口号通常取同一个值。
UDP长度域是以字节为单位的UDP数据和UDP报头之长，其最小值为８。
该UDP长度是冗余的，IP报含有其总长度，故UDP报长为该总长度减去IP报头长度。
2.2.2UDP校验和
UDP校验和覆盖UDP和UDP数据。
而IP报头中的校验和仅覆盖该IP报头，它不涉及IP数据报中的任何数据。
UDP和TCP均在其报头中有覆盖其报头和数据的校验和。
对UDP而言，校验和是可选的，而TCP则是必需的。
首先，UDP数据报的长度可以是奇数个字节，而校验和算法是加16位字。
解决方法是在尾部追加0的填充字节，而这填充字节仅为计算校验和所需。
另外，UDP和TCP均在UDP报中包含一个12字节的伪报头以计算校验和。
该伪报头包含IP报头的某些域，目的是让UDP检测数据确已到达正确的目的端。
如果发送者确实计算了校验和并且接收者检测出校验和错误，则该UDP数据报会被简单地扔弃，不产生错误信息。
UDP校验和是端对端校验和。
它由发送者计算，然后由接收者验证。
这用于捕捉在发送者与接收者之间任何地方的UDP报头或数据所发生的任何改动。
尽管UCP校验和是可选的，但他们应该总是能翻开的。
尽管这在单一的LAN上可能是可接受的，因为在数据链路帧上的循环冗余检查能够检测到该帧的大多数错误，当这些数据报穿越路由器时，所有位都关闭。
不管相信与否，某些带有软硬件缺陷的路由器会修改所转发的数据报中的某些位。
如果端到端UDP校验和被关闭，那么这些错误是不可检测的。
同时也应看到某些路据链路协议没有任何形式的数据链路校验和。
TCP校验错误率比UDP要高，这可能是因为系统的TCP连接倾向于“长距离”，而UDP主要用于本地。
2.3TCP：
传输控制协议
TCP提供了一种可靠的面向连接的字节流传输层效劳，TCP将用户数据打包形成报文段；它发送数据后启动一个定时器；通信的另一端对收到的数据进行确认，对乱序的数据重新排序，丢弃重复数据；TCP提供端到端的流量控制，并计算和验证一个强制性的端到端检查和。
目前，许多流行的网络应用程序如Telnet、FTP、Rlogin和SMTP都使用TCP。
下面主要介绍TCP为应用层提供的效劳以及TCP首部中各个字段的含义。
2.3.1TCP提供的效劳
尽管TCP和UDP都使用相同的网络层（IP），TCP却向应用层提供与UDP完全不同的效劳。
TCP提供一种面向连接的、可靠的字节流效劳。
面向连接是指两个使用TCP的应用（典型的情况是顾客/效劳员模型）在彼此交换数据之前必须先建立一个TCP连接。
这个过程与打类似。
在一个TCP连接中，只能是双方进行通信，而播送和多播不能用于TCP。
TCP通过以下方式来提供可靠性：
●应用数据被分割成TCP认为最适合发送的数据块。
这和UDP完全不同，应用程序产生的数据报长度保持不变。
由TCP传递给IP的信息单位称为报文段或段（segment）。
●当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。
如果不能及时收到一个确认，将重发这个报文段。
这里要求发送端在收到确认信息前必须保存该报文段的副本，一旦不能及时收到确认信息，才能重发该报文段。
●当TCP收到发自TCP连接另一端的数据，它将发送一个确认。
通常这个确认不是立即发送，将延迟几分之一秒。
●TCP将保持它首部和数据的检查和。
这是一个端到端的检查和，目的是检查数据在传输过程中的变化。
如果收到一个段的检查和有过失，TCP将丢弃这个报文段，同时向该报文段的发送方发送否认的信息，表示收到的报文段有错误，希望对方重发该报文段。
●TCP报文段作为IP数据报中的数据来传送，而IP数据报的到达可能乱序，因此TCP报文段的到达也可能乱序。
如果必要，TCP将对收到的数据进行重新排序，将收到的数据以正确的顺序提交给应用层。
●IP数据报会发生重复，因此TCP的接收端必须丢弃重复的数据。
●TCP提供流量控制。
TCP连接的每一方都有固定大小的缓冲空间。
TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据。
这种控制将防止较快主机致使较慢主机的缓冲区溢出。
两个应用程序通过TCP连接交换8bit字节构成的字节流。
TCP不在字节流中插入标识符，通常称为字节流效劳（bytestreamservice）。
如果一方的应用程序先传10个字节，又传30字节，再传40字节；连接的另一方将无法了解发送方每次发送了多少字节。
收方可以分4次接收这80字节，每次接收20字节。
通信双方一方将字节流放到TCP连接上，同样的字节流将出现在TCP连接的另一端。
另外，TCP对字节流的内容不作任何解释。
TCP不知道传输的数据字节流是二进制数据、还是ASCII字符、EBCDIC字符或其它类型数据。
对字节流的解释由TCP连接双方的应用层解释。
这种对字节流的处理方式与Unix操作系统对文件的处理方式相似。
Unix的内核对一个应用读或写的内容不作任何解释，而是交给应用程序处理。
2.3.2TCP的首部
TCP数据被封装在一个IP数据报中，如图2-3所示。
图2-4显示了TCP首部的数据格式。
如果不计任选字段，它通常是20个字节。
每个TCP段都包含源端和目的端的端口号，用于定位接收和发送应用进程，端口号是由本地操作系统分配的，在单机内部是唯一的；而一个主机的IP地址唯一地标识了网络中的主机。
因此，这两个值和IP首部中的源端IP地址和目的端IP地址唯一确定一个TCP连接。
一个IP地址和一个端口号也称为一个插座（socket）。
这个术语最早出现在TCP标准（RFC793）中，后来它成为表示伯克利版的网络编程接口。
一个插座对（socketpair）（包括客户IP地址、客户端口号、效劳器IP地址和效劳器端口号的四元组）可以唯一确定互连网络中每个TCP连接的双方。
序号用来标识从TCP发送端向TCP接收端发送的数据字节流，它表示在这个报文段中的第一个数据字节。
如果将字节流看作在两个应用程序之间的单向流动，则TCP用序号对每个字节进行计数。
序号是32位的无符号数，序号到达232-1后又从0开始。
当建立一个TCP连接时，SYN标志置1。
序号字段包含由这个主机选择的该连接的初始序号ISN（InitialSequenceNumber）。
由于SYN标志消耗了一个序号，该主机要发送数据的第一个字节序号为ISN加1。
在TCP连接中每个传输的字节都被计数，确认序号包含发送确认的一端所期望收到的下一个序号。
因此，确认序号应当是上次已经成功收到数据字节序号加1。
只有ACK标志为1时，确认序号字段才有效。
发送ACK无需任何代价，因为32bit确实认序号字段和ACK标志一样，总是TCP首部的一局部。
因此，一旦一个TCP连接建立起来，这个字段总是被设置，ACK标志也总是被设置为1。
TCP连接为应用层提供全双工效劳，数据能在两个方向上独立地进行传输。
因此，连接的每一端必须保持每个方向上的传输数据序号。
TCP可以描述为一个没有选择确认或否认的滑动窗口协议。
TCP缺少选择确认是因为TCP首部中确实认序号表示发方已成功收到字节，但还不包含确认序号所指的字节。
当前还无法对数据流中选定的局部进行确认。
例如，如果1~1024字节已经成功收到，下一个报文段中包含序号从2049~3072的字节，收端并不能确认这个新的报文段，它所能做的就是发回一个确认序号为1025的ACK。
它也无法对一个报文段进行否认。
例如，如果收到包含1025~2048字节的报文段，但它的检查和有错误，TCP接收端所能做的就是发回一个确认序号为1025的ACK。
首部长度给出首部中32bit字的数目。
使用这个字段是因为任选字段的长度是可变的。
这个字段占4个bit，因此TCP最多有60字节的首部。
如果没有任选字段，正常的首部长度是20字节。
在TCP首部中有6个标志比特，它们中的多个可以被同时置1。
表2-1说明了每个比特的具体含义：
表2-1：
TCP首部中6个标志比特的含义
标志比特
含义
URG
紧急指针（urgentpointer）有效
ACK
确认序号有效
PSH
接收方应该尽快将这个报文段交给应用层
RST
重建TCP连接
SYN
同步序号用来发起一个连接
FIN
发送端完成发送任务
TCP的流量控制由连接的每一端通过声明的窗口大小来提供。
窗口大小为字节数，起始于确认序号字段指明的值，这个值是接收端正期望接收的字节。
窗口大小是一个16bit字段，因此窗口大小最大为65535字节。
检查和覆盖了整个的TCP报文段，包括TCP首部和TCP数据。
这是一个强制性的字段，一定是由发端计算和存储，并由收端进行验证。
TCP检查和的计算和UDP检查和的计算相似。
只有当URG标志置1时紧急指针才有效。
紧急指针是一个正的偏移量，和序号字段中的值相加表示紧急数据最后一个字节的序号。
TCP的紧急方式是发送端向接收端发送紧急数据的一种方式。
最常见的可选字段是最长报文大小，即MSS（MaximumSegmentSize）。
每个连接方通常都在通信的第一个报文段（为建立TCP连接而设置SYN标志的那个报文段）中指明这个选项。
它指明本端所能接收的最大长度的报文段。
TCP报文段中的数据局部是可选的。
有些TCP报文段不包含数据，例如，在一个连接建立或一个连接终止时，通信双方交换的报文仅有TCP首部。
如果一方没有数据要发送，也使用没有任何数据的首部来确认收到的数据。
在处理超时的许多情况下，也会发送不带任何数据的报文段。
2.3.3TCP连接的建立和释放
2.3.3.1TCP连接的建立
TCP是一个面向连接的协议，通信双方在发送数据之前都必须建立一个TCP连接。
为了建立一个TCP连接，通常需要以下一些操作：
1．请求端发送一个SYN段指明客户想要连接的效劳器的端口，以及初始序号（ISN）。
这个SYN段为报文段1。
2．效劳器发回包含效劳器的初始序号的SYN报文段（报文段2）作为应答。
同时，将确认序号设置为客户的ISN加1以对客户的SYN报文段进行确认。
一个SYN占用一个序号。
3．客户必须将确认序号设置为效劳器的ISN加1以对效劳器的SYN报文段进行确认（报文段3）。
这三个报文段的传递完成了一个TCP连接的建立，如图2-5所示，这个过程也称为三次握手（three-wayhandshake）。
发送第一个SYN的一端执行主动翻开（activeopen）。
接收这个SYN并发回下一个SYN的另一端执行被动翻开（passiveopen）。
当一端为建立TCP连接而发送它的SYN时，它为该连接选择一个初始序号ISN。
ISN随时间变化，因此每个TCP连接都将具有不同的ISN。
RFC793指出ISN可看作是一个32比特的计数器，每4ms加1。
这样选择序号的目的在于防止在网络中被延迟的分组在以后又被传送，而导致某个TCP连接的一方对它作出错误的解释。
不同的操作系统对序号的选择不同。
在BSD4.4中，系统初始化时初始的发送序号被初始化为1。
这种方法违背了HostRequirementsRFC（在这个代码中的一个注释确认这是一个错误）。
2.3.3.2TCP连接的释放
建立一个TCP连接需要三次握手，而释放一个TCP连接需要经过4次握手，这是由于TCP的半关闭（half-close）造成的。
一个TCP连接是全双工的，因此每个方向必须单独地进行关闭。
即当TCP连接的一方完成它的数据发送后就能发送一个FIN来终止这个方向的连接；当TCP连接的另一端收到一个FIN，它必须通知应用层对方已经终止了那个方向上的数据传送。
发送FIN通常是应用层进行关闭的结果。
收到一个FIN只意味着在这个方向上没有数据流动。
一个TCP连接在收到一个FIN后仍能发送数据。
这种情况对于利用半关闭的应用是可以的，尽管在实际的应用中只有很少的TCP应用程序这样做。
正常的关闭过程如图12-5所示。
首先进行关闭的一方（发送第一个FIN报文的一方）将执行主动关闭，而TCP连接的另一方（收到这个FIN报文的一方）执行被动关闭。
通常情况下，一方完成主动关闭而另一方完成被动关闭。
图2-6显示了释放一个TCP连接的典型握手顺序。
在这个图中，发送FIN将导致应用程序关闭它们的连接，这些FIN的ACK是由TCP软件自动产生的。
一个TCP连接通常是由客户端发起的，这样第一个SYN从客户传到效劳器。
每一端都能主动关闭这个连接（即首先发送FIN报文）。
然而，一般由客户端决定何时终止连接，因为客户进程通常由用户交互控制。
2.3.4最大报文段长度
最大报文长度（MSS）表示TCP传往另一端的最大块数据的长度。
当一个TCP连接建立时，连接的双方都要通告各自的MSS。
在有些相关资料中，将最大报文长度看作可“协商”选项。
但它并不是在任何条件下都可以协商。
当建立一个TCP连接时，每一方都有用于通告它期望接收的MSS选项（MSS选项只能出现在SYN报文段中）。
如果一方不接受来自另一方的MSS值，则MSS就定为默认值536字节（这个默认值允许20字节的IP首部和20字节的TCP首部以适合576字节的IP数据报）。
通常，如果没有分段发生，MSS值越大性能越好。
报文段越大允许每个报文段传送的数据就越多，相对IP和TCP首部有更高的网络利用率。
当TCP发送一个SYN报文段时，或者由于一个本地应用进程想发起一个TCP连接，或者是由于另一端的主机收到了一个TCP连接请求，它能将MSS值设置为外出接口上的MTU长度减去固定的IP首部和TCP首部长度。
对于以太网来说，MSS值可以到达1460字节。
对于使用IEEE802.3的封装，它的MSS值可以到达1452字节。
由于许多BSD的实现版本需要MSS的值是512的倍数，对于BSD/386和SVR4的MSS值为1024。
许多其它的系统，如SunOS4.1.3、Solaris2.2和AIX3.2.2等，当TCP连接都在一个本地以太网上时都规定MSS值为1460。
许多测试结果说明在以太网上1460的MSS在性能上比1024的MSS更好。
通常，如果目的IP地址为“非本地的（nonlocal）”，MSS的默认值是536。
而区分地址是本地的还是非本地的是很简单的，如果目的IP地址的网络号和子网号都和源IP地址的网络号和子网号相同，则是本地的；否则是非本地的。
如果目的IP地址的网络号与源IP地址的网络相同，但子网号不同，则可能是本地的，也可能是非本地的。
大多数TCP实现版都提供了一个配置选项，让网络系统管理员说明不同的子网是本地的还是非本地的，这个选项的设置将确定MSS可以选择尽可能的大（到达外出接口的MTU长度）或者是默认值536。
MSS值让主机限制连接的另一端发送数据报的长度，同时主机也能控制它发送数据报的长度，这样可以使以较小MTU连接到一个网络上的主机防止分段，从而提高了网络的通信性能。
2.3.5TCP的半关闭
TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。
这就是所说的半关闭。
这种情况只有很少的应用程序使用它。
为了使用这个特性，编程接口必须为应用程序提供一种方式来说明“一方已经完成了数据传送，因此发送一个结束报文（FIN报文段）给另一端，但该方还想接收来自另一端的数据，直到接收了结束报文（FIN报文段）”。
图2-7描述了一个半关闭的典型例子。
图中，客户端开始半关闭，当然也可以效劳员端开始半关闭。
初始端发出FIN报文段，接着是另一端对这个FIN的ACK报文段。
这里客户端虽然发送了FIN报文段，但它仍能够接收来自对方的数据，在图中只显示了一个数据报文段和一个ACK报文段，但实际可能发送了许多数据报文段。
当收到半关闭的一端在完成它的数据传送后，将发送一个FIN报文段以关闭这个方向的连接。
当对第二个FIN报文段进行确认后，这个连接就彻底释放了。
2.3.6同时关闭
通常情况下，TCP连接的一方发送第一个FIN报文段执行主动关闭，但TCP双方都执行主动关闭也是可能的，TCP协议也允许这样的同时关闭（simultaneousclose）。
如图2-8所示。
当应用层发出关闭命令时，两端均从ESTABLISHED变为FIN_WAIT_1。
这种状态的变化将导致TCP双方各发送一个FIN报文段，两个FIN报文段经过网络传输后分别到达另一端。
TCP的每一端收到FIN报文段后，状态由FIN_WAIT_1变化为CLOSING，并发送最后的ACK报文段。
当收到最后的ACK报文段时，状态变化为TIME_WAIT。
同时关闭与正常关闭使用的报文段交换数目相同。
2.3.7TCP选项
TCP首部可以包含选项局部，在最初的TCP标准中定义的选项是选项表结束、无操作和最大报文段长度。
新的RFC，例如RFC1323中定义了新的TCP选项，这些选项的大多数只在最新的TCP实现中提供。
图2-9显示了当前TCP选项的格式，这些选项的定义来自于RFC793和RFC1323。
每个TCP选项的开始是1字节的kind字段，该字段说明选项的类型。
kind字段为0和1的选项仅占一个字节。
其它的选项在kind字节后还有len字节，它说明的长度是指总长度，包括kind字节和len字节。
设置无操作选项的原因是在于允许发方填充字段为4字节的倍数。
其它kind值为4、5、6和7的四个选项称为ACK及回显选项。
由于回显选项已经被时间戳选项取代，而目前定义的选择ACK选项仍未定论，而且并未包括在RFC1323中。
2.3.8TCP的性能
TCP已经在从1200b/s的拨号SLIP链路到以太数据链路上运行了许多年。
在80年代和90年代初期，以太网是运行TCP/IP最主要的数据链路方式。
尽管TCP在比以太网速率高的环境（如T2线、FDDI等）下也能够正常运行，但在这些高速网络环境下，TCP的某些限制就会暴露出来。
下面介绍关于TCP的一些修改建议，这些建议可以使TCP在高速率网络环境下获得最大的吞吐量。
2.3.8.1路径MTU发现
每个网络中的数据链路层对数据单元的长度都有一个限制，例如对于以太网，它的最大值是1518字节。
链路层的这个特性称为最大传输单元（MTU），不同类型的网络大多数都有一个上限。
当在同一个网络上的两台主机互相进行通信时，该网络的MTU是十分重要的。
如果两台主机的通信要通过多个网络，那么每个网络的链路层可能有不同的MTU。
在这里，重要的不是两台主机所在网络的MTU值，而是两台通信主机路径中的最小MTU，它被称为路径MTU。
路径MTU是决定主机之间通信性能的重要因素。
两台主机之间的路径MTU不一定是一个常数，它取决于当时路由算法所选择的路由。
而选路不一定是对称的（从节点A到节点B的路由可能与节点B到节点A的路由不同），因此路径MTU在通信两个方向上不一定是相同的。
RFC1191文件描述了路径MTU的发现机制，即在任何时候确定路径MTU的方法。
这是在两个主机之间的路径上任何网络上的最小MTU。
路径MTU发现在IP首部中继承并设置“不要分片（DF）”比特，来发现当前路径上的路由器是否需要对正在发送的IP数据报进行分片。
如果一个待转发的IP数据报被设置DF比特，而其长度又超过了MTU，那么路由器将返回ICMP不可达的过失。
目前的操作系统只有少数支持路径MTU发现，例如Solaris2.x支持路径MTU发现，将来会有越来越多的操作系统支持这个功能。
TCP的路径MTU发现按如下方式进行：
在建立TCP连接时，TCP使用输出接口或对端声明的MSS中的最小MTU作为起始的报文段大小。
路径MTU的发现不允许TCP超过对端声明的MSS。
如果对端没有指定一个MSS，则默认值为536。
一旦选定了起始的报文段大小，在该连接上的所有被TCP发送的IP数据报都将被设置DF比特。
如果某个中间路由器需要对一个设置了DF标志的数据报进行分片，它就丢弃这个数据报，并产生一个ICMP的“不能分片”过失。
如果收到一个“不能分片”的ICMP过失，TCP就减少段大小并进行重传。
如果路由器产生的是一个较新的该类ICMP过失，则报文段大小设置为下一跳的MTU减去IP和TCP的首部长度。
如果是一个较旧的该类ICMP过失，则必须尝试下一个可能的最小MTU。
当由这个ICMP过失引起的重传发生时，拥塞窗口不需要变化，但要启动慢启动。
由于路由经常动态变化，因此在最后一次减少路径MTU的一段时间以后，可以尝试使用一个较大的值（直到等于对端声明的MSS或输出接口MTU的最小值）。
RFC1191推荐这个时间间隔为10分钟，操作系统Solaris2.2使用的时间间隔是30分钟。
在对非本地目的地。
默认的MSS通常是53
升级会员 