计算机网络协议.docx
- 文档编号:17710648
- 上传时间:2023-08-03
- 格式:DOCX
- 页数:47
- 大小:287.14KB
计算机网络协议.docx
《计算机网络协议.docx》由会员分享,可在线阅读,更多相关《计算机网络协议.docx(47页珍藏版)》请在冰点文库上搜索。
计算机网络协议
计算机网络协议
————————————————————————————————作者:
————————————————————————————————日期:
计算机网络协议教案
一、TCP/IP协议族的结构和协议
TCP/IP协议簇是Internet的基础,也是当今最流行的组网形式。
TCP/IP是一组协议的代名词,包括许多别的协议,组成了TCP/IP协议簇。
其中比较重要的有SLIP协议、PPP协议、IP协议、ICMP协议、ARP协议、TCP协议、UDP协议、FTP协议、DNS协议、SMTP协议等。
TCP/IP协议并不完全符合OSI的七层参考模型。
传统的开放式系统互连参考模型,是一种通信协议的7层抽象的参考模型,其中每一层执行某一特定任务。
该模型的目的是使各种硬件在相同的层次上相互通信。
而TCP/IP通讯协议采用了4层的层级结构,每一层都呼叫它的下一层所提供的网络来完成自己的需求。
(一)熟悉Internet地址结构
(二)了解Internet地址的概念
互联网上的每个接口必须有一个唯一的In tern e t地址(也称作IP地址)。
I P地址长32 bit。
In te r net地址并不采用平面形式的地址空间,如1、2、3等。
IP地址具有一定的结构,五类不同的互联网地址格式如图1-5所示。
这些32位的地址通常写成四个十进制的数,其中每个整数对应一个字节。
这种表示方法称作“点分十进制表示法(Dotted decimal notation)”。
例如,作者的系统就是一个B类地址,它表示为:
14 0.25 2.1 3 .33。
区分各类地址的最简单方法是看它的第一个十进制整数。
图1-6列出了各类地址的起止范围,其中第一个十进制整数用加黑字体表示。
需要再次指出的是,多接口主机具有多个I P地址,其中每个接口都对应一个IP地址。
由于互联网上的每个接口必须有一个唯一的IP地址,因此必须要有一个管理机构为接入互
联网的网络分配IP地址。
这个管理机构就是互联网络信息中心(InternetNetworkInformationCentre),称作In terNIC。
I nterNIC只分配网络号。
主机号的分配由系统管理员来负责。
有三类IP地址:
单播地址(目的为单个主机)、广播地址(目的端为给定网络上的所有主
机)以及多播地址(目的端为同一组内的所有主机)。
二、熟悉Internet协议通信原理及报文格式
(一)控制报文协议
ICMP协议
引言
I CMP经常被认为是I P层的一个组成部分。
它传递差错报文以及其他需要注意的信息。
ICM P报文通常被I P层或更高层协议( TCP或UDP)使用。
一些ICMP报文把差错报文返回给用户进程。
ICM P报文是在IP数据报内部被传输的,如图6 - 1所示。
ICMP的正式规范参见RFC792[Posterl1981b]。
ICMP报文的格式如图6-2所示。
所有报文的前4个字节都是一样的,但是剩下的其他字节则互不相同。
下面我们将逐个介绍各种报文格式。
类型字段可以有 15个不同的值,以描述特定类型的ICMP报文。
某些I C MP报文还使用代码字段的值来进一步描述不同的条件。
检验和字段覆盖整个ICMP报文。
使用的算法与我们在 3 .2节中介绍的I P首部检验和算法相同。
ICMP的检验和是必需的。
ICMP报文的类型
各种类型的I CMP报文如图6-3所示,不同类型由报文中的类型字段和代码字段来共同决定。
图中的最后两列表明I CMP报文是一份查询报文还是一份差错报文。
因为对ICMP差错报文有时需要作特殊处理,因此我们需要对它们进行区分。
例如,在对ICMP差错报文进行响应时,永远不会生成另一份ICMP差错报文(如果没有这个限制规则,可能会遇到一个差错产生另一个差错的情况,而差错再产生差错,这样会无休止地循环下去)。
当发送一份ICMP差错报文时,报文始终包含IP的首部和产生IC MP差错报文的IP数据报的前8个字节。
这样,接收IC MP差错报文的模块就会把它与某个特定的协议(根据 I P数据报首部中的协议字段来判断)和用户进程(根据包含在IP数据报前8个字节中的T C P或UDP报文首部中的TC P或UD P端口号来判断)联系起来。
下面各种情况都不会导致产生ICMP差错报文:
1)ICMP差错报文(但是,I CMP查询报文可能会产生IC MP差错报文)。
2)目的地址是广播地址(见图3-9)或多播地址(D类地址,见图1 -5)的IP数据报。
3) 作为链路层广播的数据报。
4)不是IP分片的第一片(将在11.5节介绍分片)。
5) 源地址不是单个主机的数据报。
这就是说,源地址不能为零地址、环回地址、广播地址或多播地址。
这些规则是为了防止过去允许IC MP差错报文对广播分组响应所带来的广播风暴。
ICMP地址掩码请求与应答
ICMP地址掩码请求用于无盘系统在引导过程中获取自己的子网掩码(3 .5节)。
系统广播它的ICMP请求报文(这一过程与无盘系统在引导过程中用RA R P获取IP地址是类似的)。
无盘系统获取子网掩码的另一个方法是BOO TP协议,我们将在第16章中介绍。
I C MP地址掩码请求和应答报文的格式如图6-4所示。
ICMP报文中的标识符和序列号字段由发送端任意选择设定,这些值在应答中将被返回。
这样,发送端就可以把应答与请求进行匹配。
我们可以写一个简单的程序(取名为icmp addrmask),它发送一份IC M P地址掩码请求报文,然后打印出所有的应答。
由于一般是把请求报文发往广播地址,因此这里我们也这样做。
目的地址(1 40 .252. 1 3.6 3)是子网14 0 .252 .1 3.32的广播地址(见图3 -12)。
ICMP时间戳请求与应答
ICMP时间戳请求允许系统向另一个系统查询当前的时间。
返回的建议值是自午夜开始计算的毫秒数,协调的统一时间(CoordinatedUniversalTime,UTC)(早期的参考手册认为
UTC是格林尼治时间)。
这种I CMP报文的好处是它提供了毫秒级的分辨率,而利用其他方法从别的主机获取的时间(如某些U nix系统提供的rdat e命令)只能提供秒级的分辨率。
由于返回的时间是从午夜开始计算的,因此调用者必须通过其他方法获知当时的日期,这是它的一个缺陷。
请求端填写发起时间戳,然后发送报文。
应答系统收到请求报文时填写接收时间戳,在发送应答时填写发送时间戳。
但是,实际上,大多数的实现把后面两个字段都设成相同的值
(提供三个字段的原因是可以让发送方分别计算发送请求的时间和发送应答的时间)。
(二)用户数据报协议
UDP协议
引言
UD P是一个简单的面向数据报的运输层协议:
进程的每个输出操作都正好产生一个U D P
数据报,并组装成一份待发送的I P数据报。
这与面向流字符的协议不同,如TC P,应用程序产生的全体数据与真正发送的单个IP数据报可能没有什么联系。
UD P数据报封装成一份IP数据报的格式如图11-1所示。
RFC768[Postel1980]是UDP的正式规范。
U D P不提供可靠性:
它把应用程序传给I P层的数据发送出去,但是并不保证它们能到达
目的地。
由于缺乏可靠性,我们似乎觉得要避免使用 UDP而使用一种可靠协议如T C P。
我们在第17章讨论完T C P后将再回到这个话题,看看什么样的应用程序可以使用UD P。
应用程序必须关心IP数据报的长度。
如果它超过网络的MTU(2 . 8节),那么就要对IP数据报进行分片。
如果需要,源端到目的端之间的每个网络都要进行分片,并不只是发送端主机连接第一个网络才这样做(我们在 2 .9节中已定义了路径 MTU的概念)。
在11.5节中,我们将讨论IP分片机制。
UDP首部
U D P首部的各字段如图11-2所示。
端口号表示发送进程和接收进程。
在图1- 8中,我们画出了T C P和U DP用目的端口号来分用来自IP层的数据的过程。
由于I P层已经把I P数据报分配给TC P或U D P(根据I P首部中协议字段值),因此TCP端口号由TCP来查看,而UDP端口号由U D P来查看。
T CP端口号与U DP端口
号是相互独立的。
U DP长度字段指的是U DP首部和UDP数据的字节长度。
该字段的最小值为8字节(发送一份0字节的UDP数据报是OK)。
这个U D P长度是有冗余的。
I P数据报长度指的是数据报全长(图3-1),因此UD P数据报长度是全长减去IP首部的长度(该值在首部长度字段中指定,如图3-1所示)。
UDP检验和
UDP检验和覆盖UDP首部和U DP数据。
回想IP首部的检验和,它只覆盖I P的首部— 并不
覆盖IP数据报中的任何数据。
UD P和TCP在首部中都有覆盖它们首部和数据的检验和。
UDP的检验和是可选的,而TCP
的检验和是必需的。
尽管UD P检验和的基本计算方法与我们在3.2节中描述的 IP首部检验和计算方法相类似
(16bit字的二进制反码和),但是它们之间存在不同的地方。
首先, UDP数据报的长度可以为
奇数字节,但是检验和算法是把若干个16bit字相加。
解决方法是必要时在最后增加填充字节
0,这只是为了检验和的计算(也就是说,可能增加的填充字节不被传送)。
其次,UDP数据报和T CP段都包含一个12字节长的伪首部,它是为了计算检验和而设置的。
伪首部包含 IP首部一些字段。
其目的是让UD P两次检查数据是否已经正确到达目的地(例如,I P没有接受地址不是本主机的数据报,以及IP没有把应传给另一高层的数据报传给UDP)。
UDP数据报中的伪首部格式如图11- 3所示。
在该图中,我们特地举了一个奇数长度的数据报例子,因而在计算检验和时需要加上填充字节。
注意,UD P数据报的长度在检验和计算过程中出现两次。
如果检验和的计算结果为0,则存入的值为全1(65535),这在二进制反码计算中是等效的。
如果传送的检验和为0,说明发送端没有计算检验和。
如果发送端没有计算检验和而接收端检测到检验和有差错,那么 U DP数据报就要被悄悄地丢弃。
不产生任何差错报文(当IP层检测到IP首部检验和有差错时也这样做)。
UDP检验和是一个端到端的检验和。
它由发送端计算,然后由接收端验证。
其目的是为了发现UDP首部和数据在发送端到接收端之间发生的任何改动。
尽管U D P检验和是可选的,但是它们应该总是在用。
在8 0年代,一些计算机产商在默认条件下关闭UD P检验和的功能,以提高使用UDP协议的NFS(Network)的速度。
在单个局域网中这可能是可以接受的,但是在数据报通过路由器时,通过对链路层数据帧进行循环冗余检验(如以太网或令牌环数据帧)可以检测到大多数的差错,导致传输失败。
不管相信与否,路由器中也存在软件和硬件差错,以致于修改数据报中的数据。
如果关闭端到端的U DP检验和功能,那么这些差错在 UDP数据报中就不能被检测出来。
另外,一些数据链路层协议(如SLIP)没有任何形式的数据链路检验和。
IP分片
(三)传输控制协议
TCP协议
即传输控制协议,它提供的是一种可靠的数据流服务。
当传送受差错干扰的数据,或举出网络故障,或网络负荷太重而使网际基本传输系统不能正常工作时,就需要通过其他的协议来保证通信的可靠。
TCP就是这样的协议。
TCP采用“带重传的肯定确认”技术来实现传输的可靠性。
并使用“滑动窗口”的流量控制机制来提高网络的吞吐量。
TCP通信建立实现了一种“虚电路”的概念。
双方通信之前,先建立一条链接然后双方就可以在其上发送数据流。
这种数据交换方式能提高效率,但事先建立连接和事后拆除连接需要开销。
TCP的服务
尽管T CP和U DP都使用相同的网络层(I P),TCP却向应用层提供与UD P完全不同的服务。
T C P提供一种面向连接的、可靠的字节流服务。
面向连接意味着两个使用T CP的应用(通常是一个客户和一个服务器)在彼此交换数据之前必须先建立一个TCP连接。
这一过程与打电话很相似,先拨号振铃,等待对方摘机说“喂”,然后才说明是谁。
在第18章我们将看到一个 TCP连接是如何建立的,以及当一方通信结束后如何断开连接。
在一个TCP连接中,仅有两方进行彼此通信。
在第1 2章介绍的广播和多播不能用于TCP。
TCP通过下列方式来提供可靠性:
• 应用数据被分割成TCP认为最适合发送的数据块。
这和UDP完全不同,应用程序产生的数据报长度将保持不变。
由TCP传递给IP的信息单位称为报文段或段(segm ent)(参见图1-7)。
在18. 4节我们将看到TCP如何确定报文段的长度。
• 当TC P发出一个段后,它启动一个定时器,等待目的端确认收到这个报文段。
如果不能及时收到一个确认,将重发这个报文段。
在第 21章我们将了解TCP协议中自适应的超时及重传策略。
• 当TCP收到发自TCP连接另一端的数据,它将发送一个确认。
这个确认不是立即发送,通常将推迟几分之一秒,这将在19 .3节讨论。
• T CP将保持它首部和数据的检验和。
这是一个端到端的检验和,目的是检测数据在传输过程中的任何变化。
如果收到段的检验和有差错,T CP将丢弃这个报文段和不确认收到
此报文段(希望发端超时并重发)。
•既然TCP报文段作为IP数据报来传输,而IP数据报的到达可能会失序,因此TCP报文段的到达也可能会失序。
如果必要, TCP将对收到的数据进行重新排序,将收到的数据以正确的顺序交给应用层。
•既然I P数据报会发生重复,TCP的接收端必须丢弃重复的数据。
•TCP还能提供流量控制。
TCP连接的每一方都有固定大小的缓冲空间。
TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据。
这将防止较快主机致使较慢主机的缓冲
区溢出。
两个应用程序通过TCP连接交换8bit字节构成的字节流。
TC P不在字节流中插入记录标识
符。
我们将这称为字节流服务(bytestreamservice)。
如果一方的应用程序先传10字节,又传
2 0字节,再传50字节,连接的另一方将无法了解发方每次发送了多少字节。
收方可以分4次接收这80个字节,每次接收20字节。
一端将字节流放到TCP连接上,同样的字节流将出现在T CP连接的另一端。
另外,TCP对字节流的内容不作任何解释。
TC P不知道传输的数据字节流是二进制数据,还是A SCI I字符、EBCDIC字符或者其他类型数据。
对字节流的解释由T CP连接双方的应用层解释。
TCP的首部
TCP数据被封装在一个I P数据报中,如图17-1所示。
每个T C P段都包含源端和目的端的端口号,用于寻找发端和收端应用进程。
这两个值加上IP首部中的源端I P地址和目的端IP地址唯一确定一个TC P连接。
有时,一个IP地址和一个端口号也称为一个插口(s ocket)。
这个术语出现在最早的TCP规范(RFC 7 93)中,后来它也作为表示伯克利版的编程接口(参见1.1 5节)。
插口对(socke tp air)(包含客户IP地址、客户端口号、服务器 IP地址和服务器端口号的四元组)可唯一确定互联网络中每个TCP连接的双方。
序号用来标识从TCP发端向TCP收端发送的数据字节流,它表示在这个报文段中的的第一个数据字节。
如果将字节流看作在两个应用程序间的单向流动,则TCP用序号对每个字节进行计数。
序号是32bit的无符号数,序号到达2 3 2-1后又从0开始。
当建立一个新的连接时,SYN标志变1。
序号字段包含由这个主机选择的该连接的初始序号ISN(InitialSequenceNumber)。
该主机要发送数据的第一个字节序号为这个ISN加1,因为SYN标志消耗了一个序号(将在下章详细介绍如何建立和终止连接,届时我们将看到 FIN标志也要占用一个序号)。
既然每个传输的字节都被计数,确认序号包含发送确认的一端所期望收到的下一个序号。
因此,确认序号应当是上次已成功收到数据字节序号加1。
只有AC K标志(下面介绍)为1时确认序号字段才有效。
发送ACK无需任何代价,因为32 bit的确认序号字段和A CK标志一样,总是TCP首部的一部分。
因此,我们看到一旦一个连接建立起来,这个字段总是被设置,ACK标志也总是被设置为1。
T CP为应用层提供全双工服务。
这意味数据能在两个方向上独立地进行传输。
因此,连接的每一端必须保持每个方向上的传输数据序号。
TCP可以表述为一个没有选择确认或否认的滑动窗口协议(滑动窗口协议用于数据传输将在20 . 3节介绍)。
我们说TCP缺少选择确认是因为TC P首部中的确认序号表示发方已成功收到字节,但还不包含确认序号所指的字节。
当前还无法对数据流中选定的部分进行确认。
例如,如果1~1 0 24字节已经成功收到,下一报文段中包含序号从204 9~3072的字节,收端并不能确认这个新的报文段。
它所能做的就是发回一个确认序号为1025的ACK。
它也无法对一个报文段进行否认。
例如,如果收到包含1025~2048字节的报文段,但它的检验和错,TCP接收端所能做的就是发回一个确认序号为10 25的ACK。
在2 1. 7节我们将看到重复的确认如何帮助确定分组已经丢失。
首部长度给出首部中32bit字的数目。
需要这个值是因为任选字段的长度是可变的。
这个字段占4bit,因此T CP最多有6 0字节的首部。
然而,没有任选字段,正常的长度是2 0字节。
在TCP首部中有6个标志比特。
它们中的多个可同时被设置为1。
我们在这儿简单介绍它们的用法,在随后的章节中有更详细的介绍。
URG 紧急指针(u rgent pointer)有效(见20. 8节)。
ACK确认序号有效。
PSH 接收方应该尽快将这个报文段交给应用层。
R ST 重建连接。
SY N同步序号用来发起一个连接。
这个标志和下一个标志将在第18章介绍。
FIN发端完成发送任务。
TCP的流量控制由连接的每一端通过声明的窗口大小来提供。
窗口大小为字节数,起始于确认序号字段指明的值,这个值是接收端正期望接收的字节。
窗口大小是一个16bit字段,因而窗口大小最大为65535字节。
在24. 4节我们将看到新的窗口刻度选项,它允许这个值按比例变化以提供更大的窗口。
检验和覆盖了整个的TCP报文段:
T CP首部和TCP数据。
这是一个强制性的字段,一定是由发端计算和存储,并由收端进行验证。
TCP检验和的计算和 U DP检验和的计算相似,使用如11 .3节所述的一个伪首部。
只有当URG标志置1时紧急指针才有效。
紧急指针是一个正的偏移量,和序号字段中的值相加表示紧急数据最后一个字节的序号。
T CP的紧急方式是发送端向另一端发送紧急数据的一种方式。
我们将在20. 8节介绍它。
最常见的可选字段是最长报文大小,又称为MSS(MaximumSegment Size)。
每个连接方通常都在通信的第一个报文段(为建立连接而设置S YN标志的那个段)中指明这个选项。
它
指明本端所能接收的最大长度的报文段。
我们将在18.4节更详细地介绍MSS选项,TCP的其他选项中的一些将在第2 4章中介绍。
从图17-2中我们注意到T CP报文段中的数据部分是可选的。
我们将在18章中看到在一个连接建立和一个连接终止时,双方交换的报文段仅有 TCP首部。
如果一方没有数据要发送,也使用没有任何数据的首部来确认收到的数据。
在处理超时的许多情况中,也会发送不带任何数据的报文段。
(四)其他协议
TFTP(TrivialProtocol)即简单文件传送协议,最初打算用于引导无盘系统
(通常是工作站或X终端)。
和将在第2 7章介绍的使用TCP的文件传送协议(F T P)不同,为了
保持简单和短小,TFT P将使用U DP。
T FTP的代码(和它所需要的 UDP、I P和设备驱动程序)
都能适合只读存储器。
在开始工作时,TFTP的客户与服务器交换信息,客户发送一个读请求或写请求给服务器。
在一个无盘系统进行系统引导的正常情况下,第一个请求是读请求(RR Q)。
图15 -1显示了5
种T FTP报文格式(操作码为1和2的报文使用相同的格式)。
TF TP报文的头两个字节表示操作码。
对于读请求和写请求( WRQ),文件名字段说明客
户要读或写的位于服务器上的文件。
这个文件字段以0字节作为结束(见图15-1)。
模式字段
是一个ASC II码串netascii或o ct et(可大小写任意组合),同样以0字节结束。
neta sc i i
表示数据是以成行的A SC II码字符组成,以两个字节—回车字符后跟换行字符(称为CR /LF)
作为行结束符。
这两个行结束字符在这种格式和本地主机使用的行定界符之间进行转化。
octe t则将数据看作8bit一组的字节流而不作任何解释。
每个数据分组包含一个块编号字段,它以后要在确认分组中使用。
以读一个文件作为例
子,TFTP客户需要发送一个读请求说明要读的文件名和文件模式( mode)。
如果这个文件能被
这个客户读取,TFTP服务器就返回一个块编号为1的数据分组。
TFTP客户又发送一个块编号
为1的ACK。
TF TP服务器随后发送块编号为2的数据。
TF TP客户发回块编号为2的A CK。
重复
这个过程直到这个文件传送完。
除了最后一个数据分组可含有不足5 12字节的数据,其他每个
数据分组均含有51 2字节的数据。
当TF TP客户收到一个不足512字节的数据分组,就知道它收
到最后一个数据分组。
在写请求的情况下,TFTP客户发送WRQ指明文件名和模式。
如果该文件能被该客户写,
TFTP服务器就返回块编号为0的A CK包。
该客户就将文件的头 512字节以块编号为1发出。
服
务器则返回块编号为1的ACK。
这种类型的数据传输称为停止等待协议。
它只用在一些简单的协议如TFT P中。
在20.3节
中将看到TCP提供了不同形式的确认,能提供更高的系统吞吐量。
T FTP的优点在于实现的简单而不是
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 计算机网络 协议