传输控制协议(Transmission Control Protocol, TCP) (上)

类别:软件工程 点击:0 评论:0 推荐:
TCP协议主为了在主机间实现高可靠性的包交换传输协议。本文将描述协议标准和实现的一些方法。因为计算机网络在现代社会中已经是不可缺少的了,TCP协议主要在网络不可靠的时候完成通信,对军方可能特别有用,但是对于政府和商用部门也适用。TCP是面向连接的端到端的可靠协议。它支持多种网络应用程序。TCP对下层服务没有多少要求,它假定下层只能提供不可靠的数据报服务,它可以在多种硬件构成的网络上运行。下面的图是TCP在层次式结构中的位置,它的下层是IP协议,TCP可以根据IP协议提供的服务传送大小不定的数据,IP协议负责对数据进行分段,重组,在多种网络中传送。

TCP的上面就是应用程序,下面是IP协议,上层接口包括一系列类似于操作系统中断的调用。对于上层应用程序来说,TCP应该能够异步传送数据。下层接口我们假定为IP协议接口。为了在并不可靠的网络上实现面向连接的可靠的传送数据,TCP必须解决可靠性,流量控制的问题,必须能够为上层应用程序提供多个接口,同时为多个应用程序提供数据,同时TCP必须解决连接问题,这样TCP才能称得上是面向连接的,最后,TCP也必须能够解决通信安全性的问题。

网络环境包括由网关(或其它设备)连接的网络,网络可以是局域网也可以是一些城域网或广域网,但无论它们是什么,它们必须是基于包交换的。主机上不同的协议有不同的端口号,一对进程通过这个端口号进行通信。这个通信不包括计算机内的I/O操作,只包括在网络上进行的操作。网络上的计算机被看作包传送的源和目的结点。特别应该注意的是:计算机中的不同进程可能同时进行通信,这时它们会用端口号进行区别,不会把发向A进程的数据由B进程接收的。

进程为了传送数据会调用TCP,将数据和相应的参数传送给TCP,于是TCP会将数据传送到目的TCP那里,当然这是通过将TCP包打包在IP包内在网络上传送达到的。接收方TCP在接收到数据后会通信上层应用程序,TCP会保证接收数据顺序的正确性。虽然下层协议可能不会保证顺序是正确的。这里需要说明的是网关在接收到这个包后,会将包解开,看看是不是已经到目的地了,如果没有到,应该走什么路由达到目的地,在决定后,网关会根据下一个网络内的协议情况再次将TCP包打包传送,如果需要,还要把这个包再次分成几段再传送。这个落地检查的过程是一个耗时的过程。从上面,我们可以看出TCP传送的基本过程,当然具体过程可能要复杂得多。

在实现TCP的主机上,TCP可以被看成是一个模块,和文件系统区别不大,TCP也可以调用一些操作系统的功能,TCP不直接和网络打交道,控制网络的任务由专门的设备驱动模块完成。TCP只是调用IP接口,IP向TCP提供所有TCP需要的服务。通过下图我们可以更清楚地看到TCP协议的结构。



上面已经说过了,TCP连接是可靠的,而且保证了传送数据包的顺序,保证顺序是用一个序号来保证的。响应包内也包括一个序列号,表示接收方准备好这个序号的包。在TCP传送一个数据包时,它同时把这个数据包放入重发队列中,同时启动记数器,如果收到了关于这个包的确认信息,将此包从队列中删除,如果计时超时则需要重新发送此包。请注意,从TCP返回的确认信息并不保证最终接收者接收到数据,这个责任由接收方负责。

每个用于传送TCP的通道都有一个端口标记,因为这个标记是由每个TCP终端确定的,因此TCP可能不唯一,为了保证这个数值的唯一,要使用网络地址和端口号的组合达到唯一标识的目的,我们称这个为了套接字(Socket),一个连接由连接两端的套接字标识,本地的套接字可能和不同的外部套接字通信,这种通信是全双工的。

通过向本地端口发送OPEN命令及外部套接字参数建立连接,TCP返回一个标记这个连接的名称,以后如果用户需要使用这个名称标记这个连接。为了保存这个连接的信息,我们假设有一个称为传输控制块(Transmission Control Block,TCB)的东西来保存。OPEN命令还指定这个连接的建立是主动请求还是被动等待请求。下面我们要涉及具体的功能了,TCP段以internet数据报的形式传送。IP包头传送不同的信息域,包括源地址和目的地址。TCP头跟在internet包头后面,提供了一些专用于TCP协议的信息。下图是TCP包头格式图:


源端口:16位;

目的端口:16位

序列码:32位,当SYN出现,序列码实际上是初始序列码(ISN),而第一个数据字节是ISN+1;

确认码:32位,如果设置了ACK控制位,这个值表示一个准备接收的包的序列码;

数据偏移量:4位,指示何处数据开始;

保留:6位,这些位必须是0;

控制位:6位;

窗口:16位;

校验位:16位;

优先指针:16位,指向后面是优先数据的字节;

选项:长度不定;但长度必须以字节记;选项的具体内容我们结合具体命令来看;

填充:不定长,填充的内容必须为0,它是为了保证包头的结合和数据的开始处偏移量能够被32整除;

 

我们前面已经说过有一个TCB的东西了,TCB里有存储了包括发送方,接收方的套接字,用户的发送和接收的缓冲区指针等变量。除了这些还有一些变量和发送接收序列号有关:

发送序列变量

SND.UNA - 发送未确认

SND.NXT - 发送下一个

SND.WND - 发送窗口

SND.UP - 发送优先指针

SND.WL1 - 用于最后窗口更新的段序列号

SND.WL2 - 用于最后窗口更新的段确认号

ISS - 初始发送序列号

 

接收序列号

RCV.NXT - 接收下一个

RCV.WND - 接收下一个

RCV.UP - 接收优先指针

IRS - 初始接收序列号

下图会帮助您了解发送序列变量间的关系:



当前段变量

SEG.SEQ - 段序列号

SEG.ACK - 段确认标记

SEG.LEN - 段长

SEG.WND - 段窗口

SEG.UP - 段紧急指针

SEG.PRC - 段优先级

连接进程是通过一系列状态表示的,这些状态有:LISTEN,SYN-SENT,SYN-RECEIVED,ESTABLISHED,FIN-WAIT-1,FIN-WAIT-2,CLOSE-WAIT,CLOSING,LAST-ACK,TIME-WAIT和 CLOSED。CLOSED表示没有连接,各个状态的意义如下:

LISTEN - 侦听来自远方TCP端口的连接请求;

SYN-SENT - 在发送连接请求后等待匹配的连接请求;

SYN-RECEIVED - 在收到和发送一个连接请求后等待对连接请求的确认;

ESTABLISHED - 代表一个打开的连接,数据可以传送给用户;

FIN-WAIT-1 - 等待远程TCP的连接中断请求,或先前的连接中断请求的确认;

FIN-WAIT-2 - 从远程TCP等待连接中断请求;

CLOSE-WAIT - 等待从本地用户发来的连接中断请求;

CLOSING - 等待远程TCP对连接中断的确认;

LAST-ACK - 等待原来发向远程TCP的连接中断请求的确认;

TIME-WAIT - 等待足够的时间以确保远程TCP接收到连接中断请求的确认;

CLOSED - 没有任何连接状态;

TCP连接过程是状态的转换,促使发生状态转换的是用户调用:OPEN,SEND,RECEIVE,CLOSE,ABORT和STATUS;传送过来的数据段,特别那些包括以下标记的数据段SYN,ACK,RST和FIN;还有超时,上面所说的都会时TCP状态发生变化。

 

下面的图表示了TCP状态的转换,但这图中没有包括错误的情况和错误处理,不要把这幅图看成是总说明了。



 

3.3. 序列号

请注意,我们在TCP连接中发送的字节都有一个序列号。因为编了号,所以可以确认它们的收到。对序列号的确认是累积性的,也就是说,如果用户收到对X的确认信息,这表示在X以前的数据(不包括X)都收到了。在每个段中字节是这样安排的:第一个字节在包头后面,按这个顺序排列。我们需要认记实际的序列空间是有限的,虽然很大,但是还是有限的,它的范围是0到2的32次方减1。我想熟悉编程的一定知道为什么要在计算两个段是不是相继的时候要使用2的32次方为模了。TCP必须进行的序列号比较操作种类包括以下几种:

(a) 决定一些发送了的但未确认的序列号;

(b) 决定所有的序列号都已经收到了;

(c) 决定下一个段中应该包括的序列号。

对于发送的数据TCP要接收确认,处理确认时必须进行下面的比较操作:

SND.UNA = 最老的确认了的序列号;

SND.NXT = 下一个要发送的序列号;

SEG.ACK = 接收TCP的确认,接收TCP期待的下一个序列号;

SEG.SEQ = 一个数据段的第一个序列号;

SEG.LEN = 数据段中包括的字节数;

SEG.SEQ+SEG.LEN-1 = 数据段的最后一个序列号。

请注意下面的关系:

SND.UNA < SEG.ACK =< SND.NXT

如果一个数据段的序列号小于等于确认号的值,那么整个数据段就被确认了。而在接收数据时下面的比较操作是必须的:

RCV.NXT = 期待的序列号和接收窗口的最低沿;

RCV.NXT+RCV.WND-1 = 最后一个序列号和接收窗口的最高沿;

SEG.SEQ = 接收到的第一个序列号;

SEG.SEQ+SEG.LEN-1 = 接收到的最后一个序列号;

 

上面几个量有如下关系:

RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND 或 RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND

测试的第一部分是检查数据段的开始部分是否在接收窗口中,第二部分是检查数据段的结束部分是否也在接收窗口内;上面两个检查通过任何一个就说明它包括窗口要求的数据。实际中的情况会更复杂一些,因为有零窗口和零数据段长,因此我们有下面四种情况:

段长度
接收窗口
测试

0
0
SEG.SEQ = RCV.NXT

0
>0
RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND

>0
0
不可接受

>0
>0
RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND或RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND


请注意接收窗口的大小可以为零,在窗口为零时它只用来接收ACK信息,因此对于一个TCP来说,它可以使用零大小窗口在发送数据的同时接收数据。即使接收窗口的大小为零,TCP必须处理所有接收到信息的RST和URG域。

我们也应用计数的方式保护了一些特定的控制信息,这是通过隐式地使用一些控制标记使数据段能够可靠地重新发送(或确认)为达到的。控制信息并不在段数据空间中传送,因此,我们必须采用隐式指定序列号进行控制。SYN和FIN是需要保护的控制量,这两个控制量也只在连接打开和关闭时使用。SYN被认为是在第一个实际数据之间的数据,而FIN是最后一个实际数据之后的数据。段长度(SEG.LEN)包括数据和序列号空间,如果出现了SYN,那么SEG.SEQ是SYN的序列号。

初始序列号选择

协议对于特定连接被重复使用没有什么限制。连接是由一对套接字定义的。新的连接实例被定义为连接的另一次恢复,这就带来了问题:TCP如果确定多个数据段是从以前连接的另一次恢复中取得的呢?这个问题在连接迅速打开和关闭,或因为内存原因被关闭然后又迅速建立后显示特别突出。

为了避免混乱,用户必须避免因此恢复使用某一连接,而使序列号发生混乱。我们必须保证序列号的正确性,即使TCP失败,根本不知道以前的序列号是什么的情况下也要保证序列号的正确性。当新的连接被创建时,产生一个新的初始序列号(ISN)产生子,它用来选择一个新的32位ISN。产生子和32位时钟的低度位字节相关,低位字节的刷新频率大概是4微秒,因此ISN的循环时间大概是4.55小时。因此我们把网络包的最长生存时间(MSL)小于4.55小时,因此我们可以认为ISN是唯一的。对于每个连接都有发送序列号和接收序列号,初始发送序列号(ISS)由发送TCP选择,而初始接收序列号是在连接建立过程中产生的。

对于将要连接或初始化的连接,两个TCP必须和对方的初始序列号同步。这通过交换一个控制位SYN和初始序列号完成。我们把带有SYN的数据段称为"SYNs"。同步的获得过程这里就不重复了,每方必须发送自己的序列号并返回对对方序列号的确认。

1) A --> B SYN 本方序列号是X

2) A <-- B ACK 本方序列号被确认

3) A <-- B SYN 对方序列号是Y

4) A --> B ACK 确认对方序列号

上面的第2步和第3步可以合并,这时可以成为3阶段,所以我们可以称它为三消息握手。这个过程是必须的,因为序列号不和全局时钟关联,TCP也可以有不同的机制选择ISN。接收到第一个SYN的接收方不可能知道这个数据段是不是被延时,除非它记住了在连接上使用的最近的序列号(这通常是不可能的),因此它必须要求发送者确认。

为了保证TCP获得的确认是刚才发送的段产生的,而不是仍然在网络中的老数据段产生的,因此TCP必须在MSL时间之内保持沉默。在本文中,我们假设MSL=2小时,这是出于工程的需要,如果用户觉得可以,他可以改变MSL。请注意如果TCP重新初始化,而内存中的序列号正在使用,不需要等待,但必须确认使用的序列号比当前使用的要大。

如果一台主机在未保留任何序列号的情况下失败,那么它应该在MSL时间之内不发出任何数据段。下面将会这一情况进行说明。TCP的实现可以不遵守这个规定,但是这会造成老数据被当成新数据接收,而新数据被当成老数据拒绝的情况。

每当数据段形成并进入输出队列,TCP会为它指定序列空间中的一个值。TCP中多复本检测和序列算法都依赖于这个地址空间,在对方发送或接收之前不会超过2的32次方个包存在于输出队列中。所有多余的数据段都会被删除。如果没有这个规定,会出现多个数据段被指定同一个序列号的情况,会造成混乱。数据段中序列号的多少和数据段中的字节数一样多。

在通常情况下,TCP保留下一个要发送的序列号和还未确认的最老的序列号,不要在没有确认的时候就再次使用,这样会有些风险,也正是因为这样的目的,所以序列空间很大。对于2M的网络,要4.5小时来耗尽序列空间,因为一个数据段可能的最大生存时间也不过十几分之一秒,这就留下了足够的空间;而在100M的网络上需要5.4分钟,虽然少了点,但也可以了。

如果在实现TCP时没有为保存序列号留下空间,那清除多余的包可能就不能实现了,因此推荐这种类型的TCP实现最好在失败后等待MSL时间,这样保证多余的包被删除。这种情况有时候也可能会出现在保留序列号的TCP实现中。如果TCP在选择一个另一个TCP连接正在使用的序列号时,这台主机突然失败了,这就产生了问题。这个问题的实质在于主机不知道它失败了多久,也不知道多余的复本是不是还在网络中。

处理这种问题的方法是等待MSL时间,如果不这样就要冒着对方错误接收数据的危险,要等待的时间也就称为“沉默时间”。实现者可以让用户选择是不是等待,但是无论用户如何也不见得非要等待MSL时间。

本文地址:http://com.8s8s.com/it/it32404.htm