TCP与UDP协议.ppt
《TCP与UDP协议.ppt》由会员分享，可在线阅读，更多相关《TCP与UDP协议.ppt（25页珍藏版）》请在冰点文库上搜索。
TCP与UDP,TCP/IP传输层有两个并列的协议，TCP和UDP。
其中，TCP（TransportControlProtocol，传输控制协议）是面向连接的，相当于OSI的TP4，而且两者确实有许多相似之处。
UDP（UserDatagramProtocol，用户数据报协议）是无连接的，相当于OSI的TP0。
一般情况下，TCP和UDP共存于一个网间网中，前者提供高可靠性服务，后者提供高效率服务。
高可靠性的TCP用于一次传输大量报文的情形（如文件传输、远程登录等）；高效率的UDP用于一次传输少量报文（尤其是交易型应用）的场合，其可靠性由应用程序提供。
TCP要解决各种可靠性问题，因而比较复杂；UDP几乎直接建立在IP协议之上，相对简单得多。
TCP和UDP共存于一个网间网中的事实告诉我们，在计算机网络中，可靠性并不比效率更重要，只有可靠性而无效率的协议在某些应用场合下是根本没有用的，对二者的选择取决于应用的环境和需要。
TCP与UDP,IP数据报采用无连接的数据报机制，对数据只是尽力传送，至于传输是否正确、有序，不采取任何措施。
因此，TCP/IP的可靠性体现在传输层。
传输层有两个协议，其中UDP协议是无连接的，因此传输层向它的上层协议提供的服务质量主要依靠TCP协议来保证，因为TCP提供面向连接的服务，称为端到端可靠性。
传输层连接管理,传输层连接管理，包括连接端点的标识、建立传输连接的模型、建立连接与撤除连接这样几个问题。
1.连接端点的标识在建立连接的时候，必须显式地给出全局唯一的信宿端的地址。
一个全局的传输服务用户应该用以下四个域来标识：
TSAP，NSAP，主机地址，网络号当网络层是无连接的（IP协议就是），NSAP便可以忽略。
TCP/IP把TSAP叫做端口（port）。
一个端口拥有一个本地唯一的端口号。
作为一种逻辑结构，TCP/IP端口可以随机分配，但有一部分保留下来供系统专用。
前者称为自由端口，后者称为保留端口。
保留端口只占很小一部分，以全局方式进行分配，就是后面我们要提到的服务器进程。
每一个标准的服务器都拥有一个全局公认的端口号，不同机器上同样的服务器，其端口号相同。
自由端口占全部端口的绝大部分，以本地方式进行分配。
TCP/IP传输层的两个协议（TCP与UDP），,传输层连接管理,他们各有自己的保留端口与自由端口，且保留端口号的范围都是0255。
不同协议的端口之间没有任何联系，不会互相干扰。
同一个保留端口在TCP和UDP中可能对应于不同类型的应用进程，也可能对应于相同类型的应用进程。
我们进一步来分析一下端口号。
在同一台计算机上，当一个应用程序运行的时候，就分配给它一个端口。
这里有三个问题。
第一，什么时候、哪一个应用程序运行，是随机的。
第二，同一个应用程序在不同时刻运行所分配的端口号一般不会相同，也就是说，一个应用程序并不拥有固定的端口号。
第三，同一台主机上拥有的应用程序是有限的，不可能你需要什么程序就有什么程序。
2.建立传输连接的模型传输连接必须面向进程，必须用到对方的端点地址TSAP。
问题是，发起连接的一方如何知道对方哪个应用程序正在运行；即使正在运行，分配给它的端口号又是多少呢？
传输层连接管理,广泛使用的客户-服务器模型巧妙地解决了这个问题。
客户（发起连接的一方）发出连接请求。
服务器（接受连接的一方）中有一个特殊的后台进程，叫进程服务器。
进程服务器随系统一起启动并常驻内存，它拥有一个全局公认的TSAP。
客户根据对方的主机地址和进程服务器TSAP向对方进程服务器发起连接请求，在请求报文中同时给出自己的TSAP及所在的主机地址。
进程服务器监听其公认TSAP，一旦收到连接请求，便建立一条临时连接。
客户通过临时连接向进程服务器发送一个报文，告诉它希望得到的服务。
进程服务器便选择一个自由TSAP，并fok一个运行具体服务程序的新进程，将新TSAP传给新进程。
进程服务器再向客户发回新TSAP，并终止临时连接，继续监听公认TSAP。
客户再与具体服务器之间通过新TSAP建立新连接，并在新连接上开始正式通信。
传输层连接管理,以上建立传输连接的模型是由ARPANET首先提出来的，称ARPANET初始连接协议。
显而易见的缺点是，客户怎么能知道某台服务器上正好能提供它所需要的服务呢（即是否存在相应的应用程序）。
一种改进的模型是取消进程服务器，对每一具体服务器均分配一个公认TSAP。
再提供一个名字服务器，它也占用一个公认TSAP。
根据服务名字，可以从名字服务器中查出对应的公认TSAP。
客户先从名字服务器中查出具体服务器的公认TSAP，再直接与具体服务器建立连接，即可获得所需服务。
3.建立连接在理想的情况下，一个成功的建立传输连接的过程如图8.45所示。
图中，T-CONNECT表示传输层连接类原语，request、indication、response和confirm分别是连接请求、指示、响应与确认原语。
比如T-CONNECTrequest表示层连接请求原语。
建立连接时，客户发送一个请求报文，服务,传输层连接管理,器若愿意接收请求，则发回一个响应报文。
这样连接就建立起来。
这是一个合情合理的过程，很容易理解。
传输层连接管理,然而问题并没有那么简单，因为子网不是理想的，不是所有子网都能保证分组能正确及时地传到信宿端，因为分组可能在传送过程中丢失。
解决分组丢失的常用方法是使用超时重传。
最难解决的问题是，请求根本没有丢失，而是在子网中存储起来，过一段时间后，又突然出现在服务器端。
在无连接数据报子网中，尤其可能出现这种情况。
这就是所谓延迟重复问题。
消除重复连接有三种方法：
消除重复连接本身，消除重复连接请求，三次握手建立连接。
（1）消除重复连接。
遵循消除重复连接的思路，有两种具体方法可以考虑，即利用过时连接表和非重复TSAP地址。
（2）消除重复连接请求。
消除重复连接请求总的想法是删除在网络中滞留的陈旧分组，方法是给每一分组赋予一个,传输层连接管理,生存时间（TimeToLive，简称TTL）。
分组一进入网络，立刻开始生存时间计数，到时候尚未到达信宿机者，一律被抛弃，从网间网中被清除。
（3）三次握手建立连接。
即便是有了TTL这样的机制，也难保没有重复请求报文出现，最后的解决办法是在建立连接的机制上做文章，三次握手（three-wayhandshaking）方法就是一种很常用的机制。
三次握手方法首先要求对本次连接的所有报文进行编号，常用的方法是取当前时钟的最低n位作为初始序号。
由于序号域具有足够的长度，可以绝对保证序号循环一周回来时，使用同一序号的旧报文早已传输完毕。
这样网络中不会出现关于同一连接、同一序号的两个不同报文。
三次握手解决的问题是：
假设A机向B机发出连接请求，但请求报文丢失，而一个延迟的重复的旧请求报文到达B，如果B接受此请求，连接就会错误地建立起来。
传输层连接管理,面向连接的传输要求A机和B机以同步方式进行报文传输，双方发出的第一个报文均给出一个本地独立的初始序号。
在双方一来一回的报文交换过程中，回报文要对收到的上一个来报文加以确认。
在三次握手法的第一次中，A机向B机发出连接请求（简称CR），其中包含A机端的初始报文序号（比如X）。
第二次，B机收到CR后，发回连接确认（CC），其中，包含B机端的初始报文序号（比如Y），以及B机对A机初始序号X的确认。
第三次，A机向B机发送X序号数据，其中包含对B机初始Y的确认。
三次握手法的操作过程如图8.46所示。
由于A机在本端对报文进行编号，它知道哪些序号是过时的。
假如B收到一个过时连接请求CR（初始序号=X1），并确认之。
A机判断出CC（确认=X1）是过时的，将发送一个拒绝报文REJ（确认=Y），表示对来自B机的CC（初始序号=Y，确认=X1）的拒绝。
于是便不会在旧的重复连接请求上建立错误连接了。
传输层连接管理,图8.46三次握手示意,传输层连接管理,4.撤除连接撤除连接比建立连简单，但也可能造成数据丢失，因为连接的双方都可以发起撤除连接操作。
假设A、B两机建立连接并传输报文。
在A机毫无准备的情况下，B机单方面发出断连请求，并立刻终止接收该连接上数据。
在A机未收到断连请求之前，随时可能向B机发送数据，于是便有了数据丢失的可能性。
为了解决此问题，要再次使用三次握手法。
一方发出断连请求后并不立即撤除连接，而要等待对方确认；对方收到请求后，发送确认报文，并撤除连接；发起方收到确认后最后撤除连接。
传输层的其他问题,传输层的其他几个问题包括滑动窗口协议、传输层多路复用以及崩溃恢复，下面分别叙述。
（1）滑动窗口协议。
滑动窗口协议的作用有二：
其一是保证数据传输的可靠性，其二是实现流量控制。
网关和接收端可以通过某种方式通知发送方改变其窗口大小，以限制发方报文注入网络的速度，达到流控之目的。
（2）传输层多路复用。
TCP/IP的网络层不提供连接，所以不存在向下多路复用问题。
向上多路复用指多个传输连接使用一个网络连接，其目的在于充分利用虚电路带宽，降低传输开销。
TCP/IP就属此种类型。
（3）崩溃恢复。
这是传输层最难解决的问题之一。
有两种情况，一是网络连接崩溃，一是主机崩溃。
不管是那种崩溃，主机都会丢失未确认的数据或关于传输状态的信息。
为了恢复崩溃，发送端向所有主机广播一个查询报文，宣告自己已经崩溃，希望得知其它主机所有打开连接的状态，以此为依据进行恢复。
用户数据报协议UDP,用户数据报协议UDP（UserDatagramProtocol）建立在IP协议之上，提供无连接的数据报传送。
相对于IP协议，它唯一增加的能力是提供协议端口，以保证进程通信。
基于UDP的应用程序在不可靠子网上必须自己解决可靠性（如报文丢失、重复、失序、流控等）。
UDP虽然不可靠而TCP/IP依然还要采用它的理由是UDP的高效率。
一条UDP报文就叫一条用户数据报，分为头标和数据区，如图UDP报文格式所示。
各字段的意义如下：
信源端口（SOURCEPORT）：
发送端UDP端口，当不需要返回数据时，该域置0。
信宿端口（DESTINATIONPORT）：
接收端UDP端口。
长度（LENGTH）：
以字节计的整个报文长度，最小值为8（头标长）。
用户数据报协议UDP,校验和（CHECKSUM）：
这是一个可选域，置0时表示未选，全1（负0的反码）表示校验和为0。
UDP建立在IP之上，意味着整个UDP报文封装在IP数据报中传送，如图UDP报文封装所示。
所谓封装实际上是发送端UDP软件将UDP报文交给IP软件后，IP软件在前面加一个头标，构成IP数据报，这一过程相当于将UDP报文装入IP数据报数据区。
值得注意的是，UDP数据报中不指定信源主机和信宿主机地址，因为这没有必要，传输层只需识别端口，而不用识别主机，识别主机的工作由互联网层（IP软件）完成。
UDP校验和是一个可选域，这是其效率的又一体现，因为计算校验和是很花费时间的，如果应用程序对效率的兴趣远远高于对可靠性的兴趣，就可以不选此域。
UDP校验和还有一个与众不同的特点：
除UDP数据报本身外，它还覆盖一个附加头标，该头标并非UDP数据报的有效成分，称为伪头标（pseudoheader），其格式如图UDP伪头标所示。
图8.47UDP报文格式,用户数据报协议UDP,0151631,头标,数据区,用户数据报协议UDP,其中填充域的目的在于使伪头标为16比特的整数倍，协议域（PROTO）含协议类型码（17代表UDP），UDP长度（UDPLENGTH）域含UDP数据报（不包括伪头标）长度。
使用伪头标是为了验证UDP数据报是否传到正确的信宿端。
UDP数据报信宿端地址包括两部分：
信宿主机地址和信宿端口号，UDP数据报本身只包含信宿端口号，由伪头标补充信宿主机地址部分。
UDP数据报发送、接收端计算校验和时，均加上伪头标信息。
假如接收端发现校验和正确，则在一定程度上说明UDP数据报到达了正确主机上的正确端口。
UDP伪头标来自于IP头标，因此在计算UDP校验和之前，UDP首先必须从IP层获取有关信息。
换言之，UDP与IP层之间存在一定程度的交互作用。
这是对分层原则的违背，但这种违背是出于实际的需要，在原有的分层结构上不得不做的折衷。
UDP校验和的计算方法与IP数据报头标校验和的计算方法完全相同。
在UDP/IP协议栈中，UDP校验和是保证数据正确性的唯一手段。
用户数据报协议UDP,一个UDP端口是一个可读、可写的软件结构，内部有一个接收报文缓冲区。
发送数据时，UDP软件构造一个数据报，然后将它交给IP软件，便完成所有的工作。
接收数据时，UDP软件先要判断接收数据报信宿端口是否与当前使用的某端口匹配。
若是，则将数据报放入相应接收队列，否则，抛弃该数据报，并向信源端发送“端口不可到达”ICMP报文。
即使端口匹配成功，如果端口队列已满，也要将数据报抛弃。
传输控制协议TCP,这是一个完整的传输协议的典范，除提供和UDP一样的进程通信能力外，其主要特点是可靠性高，几乎可以解决所有的可靠性问题。
它提供面向连接的流传输。
流是一个无报文丢失、无重复和失序的正确的数据序列。
流相当于一个管道，从一端放入什么，从另一端可以照原样取出什么。
1.接口和套接字在传输层协议接收到数据后，为了区分数据是发送给哪一个应用程序的，于是在TCP协议中引入了端口（Port）和套接字（Socket）的概念。
每个端口有一个16位的标志符，称为端口号，标识传输层协议和应用程序之间的数据接口。
端口号是由不同的主机上的TCP协议独立分配的，所以不能全局唯一。
端口号、IP协议与IP地址结合起来，称为套接字，就可以在全网范围内唯一标识一个端口了。
在TCP协议中，一条连接两端的套接字就可以唯一标识该连接了。
传输控制协议TCP,使用TCP协议的网络应用程序可以分为两类：
一类应用程序为其它主机提供服务，这类应用程序称为服务程序。
另一类应用程序使用服务程序提供的服务，它们主动向服务程序发送连接请求，称为客户程序。
客户程序可以任意选择其进行通信的端口的端口号，而服务器程序则使用较固定的端口号。
例如TELNET的服务端使用23号端口，FTP使用21号端口，E-MAIL应用的服务器端使用25号端口等。
服务程序运行之后，就在各自的端口上等待。
如果希望使用某一台主机的相应的服务，只要往该服务对应的套接字上发送数据就可以了。
例如，如果希望远程登录到一台工作站上，则向该工作站的23号端口发送消息。
工作站收到数据后，TCP根据端口号知道应该把数据发送到TELNET的服务器程序去处理。
2.确认与超时重传这是TCP采用的最基本的可靠性技术。
TCP流的特点是无结构的字节流。
这在TCP的基本传输单元（段格式）中体,传输控制协议TCP,现为段不定长。
可变长TCP段给确认与超时重传机制带来的结果是所谓“累计确认”。
TCP确认针对流中的字节，而不是段。
一般情况下，接收方确认已正确收到的、最长的、连续的流前部，每个确认指出下一个希望接收的字节（比流前部字节数大1的位置）。
3.TCP的流控制与拥塞控制这两者都是基于滑动窗口协议来实现的。
流控的目的是尽量避免因接收缓冲区溢出而丢失大量数据，从而导致许多重传。
拥塞控制的目的是尽量避免由于子网能力不足，从而导致网关数据报超载而引起的严重延迟现象。
TCP通过控制发送窗口的大小来限制发送端向网间网注入报文的速度从而达到控制拥塞的目的。
拥塞控制涉及两种窗口大小值：
一是接收方所通告的窗口大小（即在确认中所指出的本端缓冲区大小），二是发送端的拥塞窗口限制，又叫拥塞窗口。
发送窗口的大小是二者中的最小者。
在非拥塞状态下，拥塞窗口,传输控制协议TCP,和接收方通告窗口大小相等。
一旦发现拥塞，TCP将减小拥塞窗口。
TCP发现拥塞的途径有两条：
一是来自ICMP的源抑制报文，一是报文丢失现象。
TCP假定大多数报文丢失都源于拥塞。
为迅速抑制拥塞，TCP采取成倍递减拥塞窗口的策略。
拥塞结束后，TCP又采取一种算数级窗口恢复策略，以避免迅速增加窗口大小造成的振荡。
这种策略称为慢启动。
4.TCP连接建立与撤除均采用三次握手法。
TCP连接是一个全双工的数据通道（由两个半连接组成），当关闭一个方向上的半连接后，另一方面的连接依然可以正常操作。
为此TCP采用一种变形的三次握手法。
5.Push操作,传输控制协议TCP,TCP段不定长，为提高传输效率，往往要收集到足够信息后才发送一段。
这在实时性要求很高的场合（比如交互终端访问）是不实用的。
为此，TCP提供了强迫数据传送机制。
TCP向应用程序提供push操作，以强迫传输当前流中的数据而不必等待缓冲区满。
当TCP软件收到push操作指令后，将段头标中的PSH位置1，并迅速将本段发送出去。
接收端收到PSH位置1的段后，立即将它交给应用程序。
通过这种方式得到最及时传送的数据称为紧急数据（urgentdata）。
6.TCP段格式段是TCP传输数据的基本单位，分头标与数据区两大部分，其格式如下图所示。
源端口域、信宿端口域、校验和域、数据区域等跟UDP报文相同。
下面解释其余各域的意义。
传输控制协议TCP,04810162431,TCP段格式,传输控制协议TCP,序号（SEQUENCENUMBER）：
段中数据在发送端数据流中的位置。
确认号（ACKNOWLEDGE）：
本机希望下一个接收的字节的序号。
TCP采用捎带技术，在发送数据的段中捎带对对方数据的确认。
头标长度（HLEN）：
以32比特为单位的段头标长度。
该域是针对变长的选项域设计的。
码位（CODEBITS）：
段的目的与内容。
码位中各位的标识和含义（从左到右）依次是：
URG（紧急指针域有效），ACK（确认域有效），PSH（push操作），RST（连接复位），SYN（同步序号），FIN（发送方已到达字节末尾）。
窗口（WINDOWS）：
通告接收端接收缓冲区大小。
升级会员 