中国建设银行e路通网站,做公司网站要走哪些流程,苏州建设公司网站,免费的ppt制作软件文章目录运输层概述运输层端口号、复用与分用的概念UDP和TCP的对比TCP的流量控制TCP的拥塞控制TCP超时重传时间的选择TCP可靠传输的实现TCP的运输连接管理TCP的连接建立(3次握手)TCP的连接释放(4次挥手)TCP报文段的首部格式运输层概述
这里我们对运输层进行概述#xff0c;之…
文章目录运输层概述运输层端口号、复用与分用的概念UDP和TCP的对比TCP的流量控制TCP的拥塞控制TCP超时重传时间的选择TCP可靠传输的实现TCP的运输连接管理TCP的连接建立(3次握手)TCP的连接释放(4次挥手)TCP报文段的首部格式运输层概述
这里我们对运输层进行概述之前文章所介绍的计算机网络体系结构中的物理层数据链路层以及网络层他们共同解决了将主机通过异构网络互联起来所面临的问题实现了主机到主机的通信
如图所示局域网1上的主机与局域网2上的主机通过互联的广域网进行通信网络层的作用范围是主机到主机但实际上在计算机网络中进行通信的真正实体是位于通信两端主机中的进程。
Ap是应用进程的英文缩写词如何为运行在不同主机上的应用进程提供直接的通信服务是运输层的任务运输层协议又称为端到端协议如图所示运输层的作用范围是应用进程到应用进程也称为端到端。
接下来我们从计算机网络体系结构的角度来看运输层。这是通信双方应用层中的应用进程。假设AP1与AP4之间进行基于网络的通信AP2与AP3之间进行基于网络的通信在运输层需要不同的端口来对应不同的应用进程然后通过网络层及其下层来传输应用层报文。如图所示接收方的运输层通过不同的端口将收到的应用层报文交付给应用层中相应的应用进程。
需要注意的是这里的端口并不是指看得见摸得着的物理端口而是指用来区分不同应用进程的标识符。为了简单起见在学习和研究运输层时我们可以简单的认为运输层直接为应用进程间的逻辑通信提供服务。逻辑通信的意思是运输层之间的通信好像是沿水平方向传送数据但事实上这两个运输层之间并没有一条水平方向的物理连接要传送的数据是沿着图中上下多次的虚线方向传送的运输层向高层用户屏蔽了下面网络核心的细节如网络拓扑所采用的路由选择协议等它是应用层看见的就好像是在两个运输层实体之间有一条端到端的逻辑通信信道根据应用需求的不同因特网的运输层为应用层提供了两种不同的运输层协议面向连接的TCP协议和无连接的UDP协议。这两种协议就是本文要讨论的主要内容。
运输层端口号、复用与分用的概念 复用就是可以重复使用的意思即各个应用层协议都可以使用TCP协议分用就是TCP根据端口号将报文分给不同的应用进程。 关于端口号的概念 接下来我们介绍发送方的复用和接收方的分用
如图所示这是收发双方的应用进程
发送方的某些应用进程所发送的不同应用报文在运输层使用UDP协议进行封装这称为UDP复用。而另一些应用进程做发送的不同应用报文在运输层使用TCP协议进行封装这称为TCP复用运输层使用端口号来区分不同的应用进程。不管是使用运输层的UDP协议封装成的UDP用户数据报还是使用TCP协议封装成的TCP报文段在网络层都需要使用IP协议封装成IP数据报这称为IP复用。IP数据报首部中协议字段的值用来表明IP数据报的数据载荷部分封装的是何种协议数据单元取值为6表示封装的是TCP报文段取值为17表示封装的是UDP用户数据报接收方的网络层收到IP数据报后进行IP分用若IP数据报首部装协议字段的值为17则把IP数据报的数据载荷部分所封装的UDP用户数据报上交运输层的UDP若协议字段的值为6则把IP数据报的数据载荷部分所封装的TCP报文段上交运输层的TCP。运输层对UDP用户数据报进行UDP分用对TCP报文段进行TCP分用也就是根据端口号将它们交付给上层相应的应用进程。 下面我们给出TCP/IP体系的应用层常用协议所使用的运输层熟知端口号
不管在运输层使用UDP还是TCP协议在网络层都需要使用IP协议IP数据报首部中协议字段的值表明了IP数据报数据载荷部分封装的是何种协议数据单元。 接下来我们通过一个实例来进一步说明运输层端口号的作用
如图所示用户PC,DNS服务器WEB服务器通过交换机进行互联它们处于同一个以太网中DNS服务器中记录有web域名所对应的IP地址我们在用户PC中使用网页浏览器来访问WEB服务器的内容在网页浏览器的地址栏中输入WEB服务器的域名 过程如下 用户PC中的DNS客户端进程会发送一个DNS查询请求报文其内容为域名www.porttest.com所对应的IP地址是什么 DNS查询请求报文需要使用运输层的UDP协议封装成UDP用户数据报其首部中的源端口字段值在短暂端口号49151到65535中挑选一个未被占用的用来表示DNS客户端进程例如49152。目的端口字段的值设置为53这是DNS服务器端进程所使用的熟知端口号。之后将UDP、用户数据报封装在IP数据报中通过以太网发送给DNS的服务器 DNS服务器端收到该数据报后从中解封出UDP用户数据报UDP首部中的目的端口号为53这表明应将该UDP用户数据报的数据载荷部分也就是DNS查询请求报文交付给本服务器中的DNS服务器端进程DNS服务器端进程解析DNS查询请求报文的内容然后按其要求查找对应的IP地址 之后会给用户PC发送DNS响应报文及内容为域名www.porttest.com所对应的IP地址是192.168.0.3DNS响应报文需要使用运输层的UDP协议封装成UDP用户数据报其首部中的源端口字段的值设置为熟知端口号53表明这是DNS服务器端进程所发送的UDP用户数据报目的端口字段的值设置为49152这是之前用户PC中发送DNS查询请求报文的 DNS客户端进程所使用的短暂端口号之后将UDP用户数据报封装在IP数据报中通过以太网发送给用户PC。 用户PC收到该数据报后从中解封出UDP用户数据报UDP首部中的目的端口号为49152这表明应将该UDP用户数据报的数据载荷部分也就是DNS响应报文交付给用户PC中的DNS客户端进程DNS客户端进程解析DNS响应报文的内容。就可知道自己之前所请求的WEB服务器的域名所对应的IP地址为192.168.0.3。 现在用户PC中的HTTP客户端进程可以向WEB服务器发送HTTP请求报文了。HTTP请求报文需要使用运输层的TCP协议封装成TCP报文段其首部中的原端口字段的值在短暂端口号49151到65535中挑选一个未被占用的用来表示HTTP客户端进程例如仍然使用之前用过的49152目的端口字段的值设置为80这是HTTP服务器端进程所使用的熟知端口号。之后将TCP报文段封装在IP数据报中通过以太网发送给WEB服务器 WEB服务器收到该数据报后从中解封出TCP报文段TCP首部中的目的端口号为80这表明应该将该TCP报文段的数据载荷部分也就是HTTP请求报文交付给本服务器中的HTTP服务器端进程。HTTP服务器端进程解析HTTP请求报文的内容然后按其要求查找首页内容之后会给用户PC发送HTTP响应报文其内容是 HTTP客户端所请求的首页内容。HTTP响应报文需要使用运输层的TCP协议封装成TCP报文段其首部中的原端口号字段的值设置为熟知端口号80表明这是HTTP服务器端进程所发送的TCP报文段目的端口字段的值设置为49152这是之前用户PC中发送HTTP请求报文的HTTP客户端进程所使用的短暂端口号。之后将TCP报文段封装在IP数据报中通过以太网发送给用户PC 用户收到该数据报后从中解封出TCP报文段TCP首部中的目的端口号为49152这表明应该将该TCP报文段的数据载荷部分也就是HTTP响应报文交付给用户PC中的HTTP客户端进程解析HTTP响应报文的内容并在网页浏览器中进行显示这样我们就可以在网页浏览器中看到WEB服务器所提供的首页内容了
内容小结如下
UDP和TCP的对比
UDP和TCP是TCP体系结构运输层中的两个重要协议如图所示这是TCP/IP体系结构。它的运输层有两个非常重要的协议UDP和TCP。在使用TCP/IP体系结构的网络通信中这两个协议的使用频率仅次于网际层的IP协议TCP/IP体系结构应用层中的某些协议有的需要使用运输层的TCP提供的服务而另一些协议需要使用运输层的UDP提供的服务。 UDP是用户数据报协议的英文缩写词TCP是传输控制协议的英文缩写词
接下来我们将从几个方面对这两个协议进行比较
如图所示这是因特网上的两台主机他们在运输层使用UDP协议进行通信纵坐标为时间 使用UDP协议的通信双方可以随时发送数据。 使用TCP协议的通信双方在进行数据传输之前必须使用三报文握手来建立TCP连接TCP连接建立成功后才能进行数据传输结束后必须使用四报文挥手来释放TCP连接。 需要注意的是这里所谓的连接是指逻辑连接关系而不是物理连接。
综上所述UDP是无连接的而TCP是面向连接的
来看这个对比项
这是某个局域网上的需要UDP协议进行通信的4台主机其中任何一台主机都可向其他三台主机发送广播也可以向某个多播组发送多播还可以向某台主机发送单播也就是说UDP支持单播多播以及广播。换句话说UDP支持一对一一对多以及一对全的通信。再来看使用TCP协议的情况使用TCP协议的通信双方在进行数据传输之前必须使用三报文握手来建立TCP连接TCP连接建立成功后通信双方之间就好像有一条可靠的通信信道通信双方使用这条基于TCP连接的可靠信道进行通信很显然 TCP仅支持单播也就是一对一的通信。
接下来我们来对比这两个协议对应用报文的处理
先来看使用UDP协议的情况发送方的应用进程将应用层报文交付给运输层的UDPUDP直接给应用层报文添加一个UDP首部使之成为UDP用户数据报然后进行发送。需要说明的是为了简单起见我们忽略运输层下面的各层处理接受方的UDP收到该UDP用户数据报后去掉UDP首部将应用层报文交付给应用进程也就是说UDP对应用进程交下来的报文既不合并也不拆分而是保留这些报文的边界。换句话说UDP是面向应用报文的再来看使用TCP协议的情况发送方的TCP把应用进程交付下来的数据块仅仅看作是一连串的无结构的字节流TCP并不知道这些待传送的字节流的含义仅将他们编号并存储在自己的发送缓存中。TCP根据发送策略从发送缓存中提取一定数量的字节构建TCP报文段并发送。接收方的TCP一方面从所接收到的TCP报文段中取出数据载荷部分并存储在接收缓存中一方面将接收缓存中的一些字节交付给应用进程TCP不保证接收方应用进程所收到的数据块与发送方应用进程和发出的数据块具有对应大小的关系。例如发送方应用进程交给发送方的TCP共10个数据块但接收方的TCP可能只用了4个数据块就把收到的字节流交付给了上层的应用进程但接收方应用进程收到的字节流必须和发送方应用进程发出的字节流完全一样。当然接收方的应用进程必须有能力识别收到的字节流把它还原成有意义的应用层数据也就是说 TCP是面向自字节流的这正是TCP实现可靠传输流量控制以及拥塞控制的基础。 需要说明的是为了突出示意图的要点我们只画出了一个方向的数据流在实际网络中基于TCP连接的两端可以同时进行TCP报文段的发送和接收也就是全双工通信。另外图中TCP报文段的数据部分只包含了几个字节实际当中一个TCP报文段包含上千个字节是很常见的。 再来看下一个对比项
我们曾介绍过TCP/IP体系结构的网际层向其上层提供的是无连接不可靠的传输服务当运输层使用UDP协议时向其上层提供的也是无连接不可靠的传输服务发送方给接收方发送UDP用户数据报若传输过程中用户数据报受到干扰而产生误码接收方UDP可以通过该数据报首部中的校验和字段的值检查出产生误码的情况但仅仅丢弃该数据报其他什么也不做。发送方给接收方发送UDP用户数据报如果该数据报被因特网中的某个路由器丢弃了发送方UDP不做任何处理因为UDP向上层提供的是无连接不可靠的传输服务。因此对于UDP用户数据报出现的误码和丢失等问题UDP并不关心。基于UDP的这个特点UDP适用于实时应用例如IP电话、视频会议等。再来看使用TCP协议的情况尽管网际层中的IP协议向上层提供的是无连接不可靠的传输服务也就是说 IP数据报可能在传输过程中出现丢失或误码但只要运输层使用TCP协议就可向其上层提供面向连接的可靠传输服务。我们可将其想象成使用TCP协议的收发双方基于TCP连接的可靠性到进行数据传输不会出现误码丢失、乱序以及重复等传输差错。TCP适用于要求可靠传输的应用例如文件传输。
最后我们再来对比一下UDP用户数据报的首部与TCP报文段的首部
一个UDP用户数据报由首部和数据载荷两部分构成其首部格式如图所示仅有4个字段每个字段长度为2个字节。由于UDP不提供可靠传输服务它仅仅在网际层的基础上添加了用于区分应用进程的端口因此他的首部非常简单仅有8个字节1个TCP报文段由首部和数据载荷两部分构成其首部格式如图所示这比UDP用户数据报的首部复杂的多其最小长度为20字节最大长度为60字节这是因为TCP要实现可靠传输流量控制、拥塞控制等服务其首部自然会比较复杂首部中的字段比较多首部长度也比较长
内容小结如下
TCP的流量控制
这里我们介绍TCP的流量控制
一般来说我们总是希望数据传输的更快一些但如果发送方把数据发送的过快接收方就可能来不及接收这就会造成数据的丢失所谓流量控制就是让发送方的发送速率不要太快要让接收方来得及接收利用滑动窗口机制可以很方便的在TCP连接上实现对发送方的流量控制
我们来举例说明假设主机A和B是因特网上的两台主机它们之间已经建立了TCP连接A给B发送数据B对A进行流量控制这是主机A中带发送数据的字节序号假设主机A发送的每个TCP报文段可携带100字节数据因此图中每个小格子表示100个字节数据的序号在主机A和B建立TCP连接时B告诉A我的接收窗口为400因此主机A将自己的发送窗口也设置为400这意味着主机A在未收到主机B发来的确认时可将序号落入发送窗口中的全部数据发送出去。
接下来我们举例说明主机B对A的流量控制
主机A将发送窗口内序号1~ 100的数据封中成一个TCP报文段发送出去发送窗口内还有300字节可以发送。 这里的seq是TCP报文段首部中的序号字段取值1表示TCP报文段数据载荷的第一个字节的序号是1这里的DATA表示这是TCP数据报文段 主机A将发送窗口内序号101~ 200的数据封中成一个TCP报文段发送出去发送窗口内还有200字节可以发送主机A将发送窗口内序号201~300的数据封中成一个TCP报文段发送出去但该报文段在传输过程中丢失了主机A发送窗口内还有100字节可以发送。主机B对主机A所发送的201号以前的数据进行累计确认并在该累计确认中将窗口字段的值调整为300也就是对主机A进行流量控制。 这里的大写ACK是TCP报文段首部中的标志位取值1表示这是一个TCP确认报文段小写ack是TCP报文段首部中的确认号字段取值201表示序号201之前的数据已全部正确接收现在希望收到序号201及其后续数据。RWND是TCP报文段首部中的窗口字段取值300表示自己的接收窗口大小为300。 主机A收到该累计确认后将发送窗口向前滑动使已发送并收到确认的这些数据的序号移出发送窗口。 由于主机B在该累计确认中将自己的接收窗口调整为了300因此主机A相应的将自己的发送窗口调整为300。目前主机A发送窗口内的序号为201~ 500也就是主机A还可以发送这300字节其中201~ 300号字节是已发送的数据若重传计时器超时他们会被重传。301号到400号字节以及401号到500号字节还未被发送可被分别封中在一个TCP报文段中发送。主机A现在可将发送缓存中序号1~200的字节数据全部删除了因为已经收到了主机B对他们的累计确认。 主机A将发送窗口内序号301~ 400个数据封中成一个TCP报文段发送出去发送窗口内还有100字节可以发送 主机A将发送窗口内序号401~500的数据封中成一个TCP报文段发送出去至此序号落在发送窗口内的数据已经全部发送出去了不能再发送新数据了。 现在发送窗口内序号201~300这100个字节数据的重传计时器超时了主机A将它们重新封中成一个TCP报文段发送出去暂时不能发送其他数据。 主机B收到该重传的TCP报文段后对主机A所发送的501号以前的数据进行累计确认并在该累计确认中将窗口字段的值调整为100。这是主机B对主机A进行的第二次流量控制。 主机A收到该累计确认后将发送窗口向前滑动使已发送并收到确认的这些数据的序号移出发送窗口。由于主机B在该累计确认中将自己的接收窗口调整为了100因此主机A相应的将自己的发送窗口调整为100。目前主机A发动窗口内的序号为501~ 600也就是主机A还可以发送这100字节主机A现在可将发送缓存中序号201~ 500的字节数据全部删除了因为已经收到了主机B对他们的累积确认 主机A将发送窗口内序号501~600的数据封中成一个TCP报文段发送出去至此序号落在发送窗口内的数据已经全部发送出去了不能再发送新数据了。主机B对主机A所发送的601号以前的数据进行累计确认并在该领域确认中将窗口字段的值调整为0。这是主机B对主机A进行的第三次流量控制。 主机A收到该累计确认后将发送窗口向前滑动使已发送并收到确认的这些数据的序号移出发送窗口。由于主机B在该累计确认中将自己的接收窗口调整为了0因此主机A相应的将自己的发送窗口调整为0。 目前主机A不能再发送一般的TCP报文段了主机A现在可将发送缓存中序号501~600的字节数据全部删除了因为已经收到了主机B对他们的累计确认 假设主机B向主机A发送了0窗口的报文段后不久主机B的接收缓存又有了一些存储空间于是主机B向主机A发送了接收窗口等于300的报文段然而这个报文段在传输过程中丢失了主机A一直等待主机B发送的非0窗口的通知而主机B也一直等待主机A发送的数据如果不采取措施这种互相等待而形成的死锁局面将一直持续下去。 为了解决这个问题TCP为每一个连接设有一个持续计时器只要TCP连接的一方收到对方的0窗口通知就要启动持续计时器。若持续计时器超时就要发送一个0窗口探测报文仅携带一字节的数据而对方在确认这个探测报文段时给出自己现在的接收窗口值。如果接收窗口仍然是0那么收到报文段的一方要重新启动持续计时器如果接收窗口不是0那么死锁的局面就可以被打破了。
在本例中主机A收到零窗口通知时就要启动一个持续计时器当持续计时器超时主机A立刻发送一个仅携带一字节数据的零窗口探测保温段假设主机B此时的接收窗口又为0了主机B就在确认零窗口探测报文段时给出自己现在的接收窗口值为零。主机A再次收到零窗口通知就要再次启动一个持续计时器当持续计时器超时主机A立刻发送一个零窗口探测报文段假设主机B此时的接收缓存又有了一些存储空间于是将自己的接收窗口调整为了300主机B就在确认零窗口探测报文段时给出自己现在的接收窗口值为300这样就打破了死锁的局面。 同学们可能会有这样的疑问主机A所发送的零窗口探测报文段到达主机B时如果主机B此时的接收窗口仍然为0那么主机B根本就无法接受该报文段又怎么会针对该报文段给主机A发回确认呢实际上TCP规定即使接收窗口为0也必须接受零窗口探测报文段确认报文段以及携带有紧急数据的报文段。
请大家再来思考一下这个问题。如果零窗口探测报文段丢失了会出现怎样的问题呢还能否打破死锁的局面呢回答是肯定的因为零窗口探测报文段也有重传计时器当重传计时器超时后零窗口探测报文段会被重传。
内容小结如下
TCP的拥塞控制
首先来看拥塞控制的基本概念 我们使用上图来说明拥塞控制的作用
横坐标是输入负载代表单位时间内输入给网络的分组数量纵坐标是吞吐量代表单位时间内从网络输出的分组数量具有理想拥塞控制的网络在吞吐量达到饱和之前网络吞吐量应等于所输入的负载故吞吐量曲线是45度的斜线但当输入负载超过某一限度时由于网络资源受限吞吐量就不再增长而保持水平线也就是吞吐量达到饱和这就表明输入的负载中有一部分损失掉了。例如输入到网络中的某些分组被某个节点丢弃了。虽然如此在这种理想的拥塞控制作用下网络的吞吐量仍然维持在其所能达到的最大值。然而实际的网络情况就很不同了。我们再来看这条吞吐量曲线随着输入负载的增大网络吞吐量的增长率逐渐减小也就是在网络吞吐量还未达到饱和时就已经有一部分的输入分组被丢弃了。当网络的吞吐量明显的小于理想的吞吐量时网络就进入了轻度拥塞的状态。更值得注意的是当输入负载到达某一数值时网络的吞吐量反而随输入负载的增大而减小这时网络就要进入了拥塞状态当输入负载继续增大到某一数值时网络的吞吐量就要减小为零此时网络就要无法工作了这就是所谓的死锁。因此进行拥塞控制是非常有必要的。实际的拥塞控制曲线应该尽量接近理想的拥塞控制曲线。
接下来我们介绍TCP的4种拥塞控制算法他们分别是
慢开始拥塞避免快重传快恢复
我们来举例说明TCP这4种拥塞控制算法的基本原理为了集中精力讨论拥塞控制我们假定如下条件
一数据是单方向传送的而另一个方向只传送确认。二接收方总是有足够大的缓存空间因而发送方发送窗口的大小仅由网络的拥塞程度来决定。三以TCP最大报文段MSS的个数为讨论问题的单位而不是以字节为单位。
假设这是TCP的发送方和接收方发送方给接收方发送TCP数据报文段接收方收到后给发送方发送TCP确认报文段 我们前面说过送方发送窗口的大小仅由网络的拥塞程度来决定所以这里发送窗口的大小和拥塞窗口一样的大正常情况下并不一定是这样的。 首先来看慢开始算法为了更清楚的显示出拥塞控制过程我们还可以绘制这样一幅拥塞窗口随传输轮次变化的图横坐标为传输轮次传输轮次是指发送方给接收方发送数据报文段后接收方给发送方发回相应的确认报文段。一个传输轮次所经历的时间其实就是往返时间。请注意往返时间并非是恒定的数值使用传输轮次是为了强调把拥塞窗口所允许发送的报文段都连续发送出去并收到了对已发送的最后一个报文段的确认。
纵坐标是拥塞窗口它会随网络拥塞程度以及所使用的拥塞控制算法动态变化。 在TCP双方建立逻辑连接关系时拥塞窗口的值被设置为1我们在图上标出传输轮次0时的拥塞窗口值为1另外还需设置慢开始门限的初始值本例采用16我们也将它在图中标出在执行慢开始算法时发送方每收到一个对新报文段的确认时就把拥塞窗口值加1然后开始下一轮的传输当拥塞窗口值增长到慢开始门限值时就要改为执行拥塞避免算法。 由于发送方当前的拥塞窗口值是1而发送窗口值等于拥塞窗口值因此发送方当前只能发送1个TCP数据报文段换句话说拥塞窗口值是几就能发送几个数据报文段如图所示发送方发送0号数据报文段接收方收到后给发送方发回对0号报文段的确认报文段 发送方收到该确认报文段后将拥塞窗口值加1增大到2我们在图中标出该值这意味着发送方现在可以发送1~ 2号共两个数据报文段接收方收到后给发送方发回对1~2号报文段的确认报文段 发送方收到后将拥塞窗口值加2增大到4。我们在图中标出该值发送方现在可以发送3~ 6号共4个数据报文段接收方收到后给发送方发回对3~6号报文段的确认报文段发送方收到后将拥塞窗口值加四增大到8 我们在图中标出该值发送方现在可以发送7~14号共8个数据报文段接收方收到后给发送方发回对7 ~ 14号报文段的确认报文段发送方收到后将拥塞窗口值加8增大到16我们在图中标出该值发送方当前的拥塞窗口值已经增大到了慢开始门限值之后我们要改用拥塞避免算法也就是每个传输轮次结束后拥塞窗口值只能线性加一而不像慢开始算法那样每个传输轮次结束后拥塞窗口值按指数规律增长 发送方现在可以发送15 ~ 30号共16个数据报文段接收方收到后给发送方发回对15 ~ 30号报文段的确认报文段发送方收到后将拥塞窗口值加一增大到17。我们在图中标出该值现在可以发送31~47号共17个数据报文段接收方收到后给发送方发回对31 ~47号报文段的确认报文段发送方收到后将拥塞窗口值加一增大到18。我们在图中标出该值 随着传输轮次的增加拥塞窗口值每轮次都线性加一例如当前拥塞穿口值增加到了24发送方现在可以发送171~194号共24个数据报文段。假设这24个数据报文段在传输过程中丢失了几个这必然会造成发送方对这些丢失报文段的超时重传。发送方以此判断网络很可能出现了拥塞需要进行以下工作。 1.将慢开始门限值更新为发生拥塞时拥塞窗口值的一半网络发生拥塞时的拥塞窗口值是24因此更新慢开始门限值为该值的一半即12 2.将拥塞窗口值减小为1并重新开始执行慢开始算法如图所示当慢开始执行到拥塞窗口值增大到新的慢开始门限值时就要停止使用慢开始算法转而执行拥塞避免算法。
通过本例可以看出我们可以总结出
TCP发送方一开始使用慢开始算法让拥塞窗口值从一开始按指数规律增大当拥塞窗口值增大到慢开始门限值时停止使用慢开始算法转而执行拥塞避免算法让拥塞窗口值按线性加1的规律增大当发生超时重传时就要判断网络很可能出现了拥塞采取相应的措施一方面将慢开始门限值更新为发生拥塞时拥塞窗口值的一半另一方面将拥塞窗口值减小为一并重新开始执行慢开始算法。拥塞窗口值又从一开始按指数规律增大当增大到了新的慢开始门限值时停止使用慢开始算法转而执行用在避免算法让拥塞窗口值按线性加1的规律增大。
需要注意的是
慢开始是指一开始向网络注入的报文段少而并不是指拥塞窗口值增长速度慢拥塞避免也并非指完全能够避免营塞。而是只在拥塞避免阶段将拥塞窗口值控制为按线性规律增长使网络比较不容易出现拥塞 慢开始和拥塞避免是1988年就提出的TCP拥塞控制算法也就是TCP的Tahoe版本1990年又增加了两个新的拥塞控制算法以便改进TCP的性能这就是快重传和快恢复被称为TCP的Reno版本。有时个别报文段会在网络中丢失但实际上网络并未发生拥塞这将导致发送方超时重传并误认为网络发生了拥塞。
例如在之前的例子中当拥塞窗口值增大到24时发生了超时重传而网络此时并没有发生拥塞但是发送方却误认为网络发生了拥塞于是发送方把拥塞窗口值减小为1并错误的启动慢开始算法因而降低了传输效率。 采用快重传算法可以让发送方尽早知道发生了个别报文段的丢失。所谓快重传是发送方尽快进行重传而不是等超时重传计时器超时再重传
这就要求接收方不要等待自己发送数据时才进行捎带确认而是要立即发送确认即使收到了失序的报文段也要立即发送对已收到的报文段的重复确认发送方一旦收到三个连续的重复确认就将相应的报文段立即重传而不是等该报文段的重传计时器超时再重传
我们来举例说明快重传算法
发送方发送1号数据报文段接收方收到后给发送方发回对1号报文段的确认在该确认报文段到达发送方之前发送方还可以将发送窗口内的2号数据报文段发送出去接收方收到后给发送方发回对2号报文段的确认。在该确认报文段到达发送方之前发送方还可以将发送窗口内的3号数据报文段发送出去但该报文段丢失了接收方自然不会给发送方发回针对该报文段的确认发送方还可以将发送窗口内的4号数据报文段发送出去接收方收到后发现这不是按序到达的报文段因此给发送方发回针对2号报文段的重复确认表明我现在希望收到的是三号报文段但是我没有收到三号报文段而是收到了未按序到达的报文段发送方还可以将发送窗口内的5号数据报文段发送出去接收方收到后发现这不是按序到达的报文段因此给发送方发回针对2号报文段的重复确认发送方还可以将发送窗口内的6号数据报文段发送出去接收方收到后发现这不是按需到达的报文段因此给发送方发回针对2号报文段的重复确认至- 此发送方会收到三个连续的对二号报文段的重复确认就要立即重传三号报文段接收方收到后给发送方发回针对6号报文段的确认表明序号到六为止的报文段都正确接收了这样就不会造成对三号报文段的超时重传而是提早进行了重传。对于个别丢失的报文段发送方不会出现超时重传也就不会误认为出现了拥塞而错误的降低拥塞窗口值为最小值一使用快重传可以使整个网络的吞吐量提高约20% 再来看快恢复算法发送方一旦收到三个重复确认就知道现在只是丢失了个别的报文段于是不启动慢开始算法而是执行快恢复算法
发送方将慢开始门限值和拥塞窗口值调整为当前窗口值的一半开始执行拥塞避免算法
也有的快恢复实现是把快恢复开始时的拥塞窗口值再增大一些也就是等于新的慢开始门限值加三。这样做的理由是
既然发送方收到三个重复的确认就要表明有三个数据报文段已经离开了网络这三个报文段不再消耗网络资源而是停留在接收方的接收缓存中。可见现在网络中不是堆积的报文段而是减少了三个报文段因此可以适当把用塞窗口值扩大一些。
接下来我们给出TCP拥塞窗口值在拥塞控制时的变化情况举例里面包含了TCP拥塞控制的4种算法 TCP发送方一开始使用慢开始算法让拥塞窗口值从一开始按指数规律增大当增大到慢开始门线初始值时停止使用慢开始算法转而执行拥塞避免算法让拥塞窗口值按线性加1的规律增大。 当发生超时重传时就要判断网络可能出现了拥塞采取相应的措施一方面将慢开始门限值更新为发生拥塞时拥塞窗口值的一半另一方面将拥塞窗口值减小为一并重新开始执行慢开始算法。 拥塞窗口值又从一开始按指数规律增大当增大到了新的慢开始门限值时停止使用慢开始算法转而执行拥塞避免算法让拥塞窗口值按线性加1的规律增大。 当发送方收到三个重复的确认时就要进行快重传和快恢复也就是更新慢开始门限值为当前拥塞窗口值的一半并将拥塞窗口值也取为新的慢开始门限值转而执行拥塞避免算法让拥塞窗口值按线性加1的规律增大。
TCP超时重传时间的选择
超时重传时间的选择是TCP最复杂的问题之一。我们来举例说明假设主机A和B是因特网上的两台主机他们之间已经建立了TCP连接纵坐标为时间现在主机A给主机B发送TCP数据报文段0并记录下当前的时间。主机B收到后给主机A发送相应的确认报文段。主机A收到确认报文段后记录下当前的时间那么主机A记录下的这两个时间它们的差值就是报文段的往返时间RTT由于这是第0个报文段的RTT我们就用RTT0来表示。试想一下如果我们将超时重穿时间RTO的值设置的比RTT0的值小会出现怎样的情况很显然这会引起报文段不必要的重传使网络负荷增大。
那么如果将超时重传时间RTO的值设置的远大于RTT0的值又会出现怎样的情况很显然这会使重传推迟的时间太长使网络的空闲时间增大降低了传输效率。 综合上述两种情况我们可以得出这样的结论超时重传时间RTO的值应该设置为略大于报文段往返时间RTT的值。至此同学们可能会觉得超时重传时间的选择也并不是很复杂然而 TCP下层是复杂的互联网环境主机A所发送的报文段可能只经过一个高速率的局域网也有可能经过多个低速率的网络并且每个IP数据报的转发路由还可能不同。
例如现在主机A给主机B发送TCP数据报文段一主机B收到后给主机A发送相应的确认报文段主机A这次测得的报文段往返时间RTT一如图所示显然RTT1远大于RTT0如果超时重装时间RTO还是我们之前所确定的略大于RTT0的话这对于数据报文段1是不合适的会造成该报文段不必要的重传。 这样看来超时重传时间的选择确实不那么简单了我们不能直接使用某次测量得到的RTT样本来计算超时重装时间RTO但是我们可以利用每次测量得到的RTT样本计算加权平均往返时间RTTS这样可以得到比较平滑的往返时间。当测量到第一个RTT样本时RTTS的值直接取为第一个RTT样本的值以后每测量到一个RTT样本时都按该公式来计算新的RTT S值。
在上式中阿尔法的取值大于等于0且小于一若阿尔法很接近于零则新RTT样本对RTTS的影响不大若阿尔法很接近于一则新RTT样本对RTTS的影响较大已成为建议标准的RFC6298推荐的阿尔法值为1/8即0.125用这种方法得出的加权平均往返时间RTTS的值就要比测量出的RTT的值更加平滑。 显然超时重穿时间RTO的值应略大于加权平均往返时间RTTS的值。 下面我们给出RFC6298建议使用的超时重传时间RTO的计算公式该公式中的RTTS是加权平均往返时间我们刚刚介绍过它的计算方法RTTD是RTT偏差的加权平均计算方法如下当测量到第一个RTT样本时RTTD的值取为该样本值的一半以后每测量到一个RTT样本时都按该公式来计算新的RTTD的值。在上式中贝塔的取值大于等于0且小于1已成为建议标准的RFC6298推荐的贝塔值为1/4即0.25。我们可以发现不管是RTTS还是RTTD都是基于所测量到的RTT样本进行计算的。如果所测量到的RTT样本不正确那么所计算出的RTTS和RTTD自然就要不正确进而所计算出的超时重穿时间RTO也就不正确。 然而往返时间RTT的测量确实是比较复杂的。我们来举例说明主机A给主机B发送TCP数据报文段但该报文段在传输过程中丢失了当超时重传计时器超时后主机A就重传该报文段主机B收到后给主机A发送确认报文段。现在问题来了主机A收到该确认报文段后无法判断该报文段是对原报文段的确认还是对重传报文段的确认。该报文段实际上是对重传报文段的确认也就是说正确的RTT应该是这一段时间。但是如果主机A误将该确认当做是对原报文段的确认也就是误认为这段时间是RTT则所计算出的RTTS和RTO就会偏大降低了传输效率。
再来看另一种情况主机A给主机B发送TCP数据报文段主机B收到后给主机A发送确认报文段由于某种原因该确认报文段没有在正常时间内到达主机A这必然会导致主机A对之前所发送的数据报文段的超时重传。现在问题又来了主机A收到迟到的确认报文段后无法判断该报文段是对原报文段的确认还是对重传报文段的确认。该报文段实际上是对原报文段的确认也就是说正确的RTT应该是这一段时间。但是如果主机A误将该确认当做是对重传报文段的确认也就是误认为这段时间是RTT则所计算出的RTTS和RTO就会偏小这会导致报文段没有必要的重传增大网络负荷。
通过这两个例子可以看出当发送方出现超时重传后收到确认报文段时是无法判断出该确认到底是对原报文段的确认还是对重传报文段的确认也就是无法准确测量出RTT进而无法正确计算超时重传时间RTO。因此针对出现超时重传时无法测准往返时间RTT的问题Karn提出了一个算法在计算加权平均往返时间RTTS时只要报文段重传了就要不采用其往返时间RTT样本也就是出现重传时不重新计算RTTS进而超时重传时间RTO也不会重新计算。然而这要引起了新的问题设想出现这样的情况报文段的时延突然增大了很多并且之后很长一段时间内都会保持这种时延因此在原来得出的重传时间内不会收到确认报文段于是就重传报文段。根据Karn算法不考虑重传的报文段的往返时间样本这样超时重传时间就要无法更新这会导致报文段反复被重传。因此要对Karn算法进行修正方法是报文段每重传一次就把超时重传时间RTO增大一些典型的做法是将新RTO的值取为旧RTO值的两倍。
接下来我们举例说明TCP超时重传时间的计算这是测量得到的第一个RTT样本RTT1。根据RTTS1的计算公式可知RTTS1的值.根据RTTDE的计算公式可知RTTD1的值在根据IPO的计算公式可计算出RTO1的值这是测量得到的第二个RTT2根据RTTS2的计算公式和阿尔法的值和写出计算RTTS2的表达式将之前计算出的RTTS1的值和本次测量得到的RTT2的值代入干涉可计算出RTTS2的值。根据RTTD的计算公式和贝塔的值可写出计算RTTD2的表达式将之前计算出的RTTD1RTTS,1以及本次测量得到的RTT2的值代入该式可计算出RTTD2的值。再根据RTO的计算公式可计算出RTO2的值。假设这是测量得到的第3个和第4个RTT样本。计算一下RTO3和RTO4的值分别是多少答案如图所示相信大家都能正确解答。假设这是测量得到的第5个RTT样本但是根据RTO4的值可知在收到确认之前就会产生超时重传。我们之前介绍过若出现超时重传则不采用上述公式计算RTO而是将新RTO的值取为旧RTO值的两倍。因此RTO5的值取为两倍的RTO4的值。 内容小结如下
TCP可靠传输的实现
TCP基于以字节为单位的滑动窗口来实现可靠传输
我们来举例说明这是因特网上的两台主机他们之间已经建立了一个TCP连接为了简单起见我们假定数据传输只在一个方向进行换句话说发送方给接收方发送TCP数据报文段接收方给发送方发送相应的TCP确认报文段这样的好处是使讨论仅限于两个窗口也就是发送方的发送窗口和接收方的接收窗口。TCP的滑动窗口是以字节为单位的。 现在假设发送方收到了一个来自接收方的确认报文段在报文段首部中的窗口字段的值为20也就是接收方表明自己的接收窗口的尺寸为20字节确认号字段的值为31这表明接收方希望收到下一个数据的序号是31而序号30为止的数据已经全部正确接收了。 因此发送方根据这两个字段的值构造出自己的发送窗口。为了简单起见我们假定网络不存在拥塞问题也就是发送方在构造自己的发送窗口时仅考虑接收方的接收窗口而不考虑拥塞窗口。由于本例中接收方告诉发送方自己的接收窗口尺寸为20因此发送方将自己的发送窗口尺寸也设置为20发送方在没有收到接收方确认的情况下可以把发送窗口内的数据依次全部发送出去凡是已经发送过的数据在未收到确认之前都必须暂时保留以便在超时重传时使用。 发送窗口后沿的后面部分是已发送并已收到确认的数据字节的序号这些数据字节显然不需要再保存在发送缓存中了可以将它们删除。发送窗口前沿的前面部分是当前不允许发送的数据字节的序号。 然后我们说说发送窗口前沿的移动情况和后延的移动情况。 其中发送窗口的前沿还可能向后收缩这发生在接收方通知的窗口变小了但TCP标准强烈不赞成这样做因为很可能发送方在收到这个通知之前就已经发送了窗口中的许多数据现在又要收缩窗口不让发送这些数据显然就会产生错误。 现在假定发送方将发送窗口内序号31~ 41的数据封装在几个不同的报文段中发送出去此时发送窗口的位置并没有改变发送窗口内序号31~41的数据已经发送但未收到确认而序号42 ~50的数据是允许发送但还未发送的。请同学们思考一下我们如何描述发送窗口的状态换句话说如果我们要编程实现滑动窗口机制那么对于发送窗口的状态应该如何标记和维护呢如图所示可以使用三个指针P1、P2、P3分别指向相应的字节序号这样小于P1的就是已发送并已收到确认的部分大于等于P3的是不允许发送的部分。 我们再来看看接收方的接收窗口它的尺寸为20在接收窗口外面到30号为止的数据是已经发送过相应确认并已交付给应用进程的数据因此无需再保留这些数据可将他们从接收缓存中删除了。接收窗口内31~ 50号数据是允许接收的数据接收窗口外51号及其后续数据目前不允许接收。假设发送方之前发送的封装有32和33号数据的报文段到达了接收方由于数据序号落在接收窗口内所以接收方接受他们并将他们存入接收缓存但是他们是未按序到达的数据因为31号数据还没有到达这有可能是丢了也有可能是滞留在网络中的某处。请注意接收方只能对按序收到的数据中的最高序号给出确认因此接收方发出的确认报文段中的确认序号仍然是31也就是希望收到31号数据窗口字段的值仍是20表明接收方没有改变自己接收窗口的大小 发送方收到该确认报文段后发现这是一个针对31号数据的重复确认就知道接收方收到了未按序到达的数据由于这是针对31号数据的第一个重复确认因此这并不会引起发送方针对该数据的快重传。另外接收方通知的窗口尺寸仍是20因此发送方保持自己的发送窗口尺寸为20现在假设封装有31号数据的报文段到达了接收方方接受该报文段将其封装的31号数据存入接收缓存接收方现在可将接收到的31~33号数据交付给应用进程 然后将接收窗口向前移动三个序号并给发送方发送确认报文段。该确认报文段中窗口字段的值仍为20表明接收方没有改变自己接收窗口的大小确认号字段的值为34这表明接收方已经收到了序号33为止的全部数据。 现在假设又有几个数据报文段到达了接收方他们封装有37 38以及40号数据这些数据的序号虽然落在接收窗口内但他们都是未按需到达的数据只能先暂存在接收缓存中。假设接收方先前发送的确认报文段到达了发送方发送方接收后将发送窗口向前滑动三个序号发送窗口的尺寸保持不变这样就有新序号51~ 53落入发送窗口内而序号31~ 33移出了发送窗口现在可将31~33号数据从发送缓存中删除了因为已经收到了接收方针对他们的确认 发送方继续将发送窗口内序号42~53的数据封装在几个不同的报文段中发送出去现在发送窗口内的序号已经用完了发送方在未收到接收方发来确认的情况下不能再发送新的数据序号落在发送窗口内的已发送数据如果迟迟收不到接收方的确认则会产生超时重传。
接下来我们还要对TCP可靠传输的实现做几点补充说明
内容小结如下
TCP的运输连接管理
TCP的连接建立(3次握手) TCP是面向连接的协议它基于运输连接来传送TCP报文段 TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的过程。 TCP运输连接有以下三个阶段 第一个阶段是建立TCP连接也就是通过三报文握手来建立TCP连接。第二个阶段是数据传送也就是基于已建立的TCP连接进行可靠的数据传输。第三个阶段是释放连接也就是在数据传输结束后还要通过四报文挥手来释放TCP连接 TCP的运输连接管理就是使运输连接的建立和释放都能正常的进行。 TCP的连接建立要解决以下三个问题
第一使TCP双方能够确知对方的存在第二使TCP双方能够协商一些参数例如最大窗口值是否使用窗口扩大选项和时间戳选项以及服务质量等第三使TCP双方能够对运输实体资源例如缓存大小连接表中的项目等进行分配
接下来我们就来看看TCP使用三报文握手建立连接的具体过程 这是两台要基于TCP进行通信的主机其中一台主机中的某个应用进程主动发起TCP连接建立称为TCP客户。另一台主机装被动等待TCP连接建立的应用进程称为TCP服务器。我们可以将TCP建立连接的过程比喻为握手握手需要在TCP客户和服务器之间交换三个TCP报文段 最初两端的TCP进程都处于关闭状态一开始 TCP服务器进程首先创建传输控制块用来存储TCP连接中的一些重要信息例如 TCP连接表指向发送和接收缓存的指针指向重传队列的指针当前发送和接收序号等。之后就要准备接受TCP客户进程的连接请求。此时TCP服务器进程就要进入监听状态等待TCP客户进程的连接请求。TCP服务器进程是被动等待来自TCP客户进程的连接请求而不是主动发起因此称为被动打开连接。 TCP客户进程也是首先创建传输控制块然后在打算建立TCP连接时向TCP服务器进程发送TCP连接请求报文段并进入同步已发送状态。TCP连接请求报文段首部中的同步位SYN被设置为1表明这是一个TCP连接请求报文段序号字段seq被设置了一个初始值X作为TCP客户进程所选择的初始序号。请注意TCP规定SYN被设置为1的报文段不能携带数据但要消耗掉一个序号。由于TCP连接建立是由TCP客户进程主动发起的因此称为主动打开连接。 SYN表示synchronization原意是同步的意思。打开就意味着客户端想和服务端进行数据的同步在同步以后(也就是三次握手之后)客户端和服务端就可以互相发送消息。 seq表示sequence原意为序号。需要这个seq是因为应用程序可能连续发送多个序号给服务器有了seq就可以有依据判断哪些是累赘信息ack搭配seq用于确认数据是否准确是否正常通信。并且这个seq序号是随机生成的作为初始值来进行后续的判断依据保证了通道唯一性 TCP服务器进程收到TCP连接请求报文段后。如果同意建立连接则向TCP客户进程发送TCP连接请求确认报文段并进入同步已接收状态。该报文段首部中的同步位SYN和确认位ACK都设置为1表明这是一个TCP连接请求确认报文段。序号字段seq被设置了一个初始值Y作为TCP服务器进程所选择的初始序号确认号字段ack的值被设置成了X1这是对TCP客户进程所选择的初始序号的确认。请注意这个报文段也不能携带数据因为它是SYN被设置为1的报文段但同样要消耗掉一个序号 ACK表示Acknowledgment原意为确认。当ACK和SYN一起开启表示确认同步 小写的ack表示的确认序号也就是说光有自己的序号seq还不够还要有确认序号ack这个ack是根据客户端的序号1得到的这样客户端在收到号码后-1就知道是不是自己发送的TCP报文了 TCP客户进程收到TCP连接请求确认报文段后还要向TCP服务器进程发送一个普通的TCP确认报文段并进入连接已建立状态。该报文段首部中的确认位ACK被设置为1表明这是一个普通的TCP确认报文段序号字段seq被设置为X1这是因为 TCP客户进程发送的第一个TCP报文段的序号为X并且不携带数据因此第二个报文段的序号为X1。请注意TCP规定普通的TCP确认报文段可以携带数据但如果不携带数据则不消耗序号。在这种情况下所发送的下一个数据报文段的序号仍是X1确认号字段ack被设置为Y1这是对TCP服务器进程所选择的初始序号的确认。 TCP服务器进程收到该确认报文段后也进入连接已建立状态。现在TCP双方都进入了连接已建立状态他们可以基于已建立好的TCP连接进行可靠的数据传输了。
想一想为什么TCP客户进程最后还要发送一个普通的TCP确认报文段这是否多余换句话说能否使用两报文握手建立连接
答案是并不多余不能简化为两报文握手
我们来举例说明考虑这样一种情况 TCP客户进程发出一个TCP连接请求报文段但该报文段在某些网络节点长时间滞留了这必然会造成该报文段的超时重传。假设重传的报文段在TCP服务器进程正常接收TCP服务器进程给TCP客户进程发送一个TCP连接请求确认报文段并进入连接已建立状态。 请注意由于我们改为两报文握手因此TCP服务器进程发送完TCP连接请求确认报文段后进入的是连接已建立状态而不像三报文握手那样进入同步已接收状态并等待TCP客户进程发来针对TCP连接请求确认报文段的普通确认报文段。 TCP客户进程收到TCP连接请求确认报文段后进入TCP连接已建立状态但不会给TCP服务器进程发送针对该报文段的普通确认报文段现在 TCP双方都处于连接已建立状态他们可以相互传输数据之后可以通过四报文挥手来释放连接TCP双方都进入了关闭状态 一段时间后之前滞留在网络中的失效的TCP连接请求报文段到达了TCP服务器进程TCP服务器进程会误认为这是TCP客户进程又发起了一个新的TCP连接请求于是给TCP客户进程发送TCP连接请求确认报文段并进入连接已建立状态。该报文段到达TCP客户进程由于TCP客户进程并没有发起新的TCP连接请求并且处于关闭状态因此不会理会该报文段但TCP服务器进程已进入了连接已建立状态他认为新的TCP连接已建立好了并一直等待TCP客户进程发来数据这将白白浪费TCP服务器进程所在主机的很多资源。
内容小结如下
TCP的连接释放(4次挥手)
TCP通过四报文挥手来释放连接
我们来举例说明 数据传输结束后TCP通信双方都可以释放连接现在TCP客户进程和TCP服务器进程都处于连接已建立状态。假设使用TCP客户进程的应用进程通知其主动关闭TCP连接TCP客户进程会发送TCP连接释放报文段并进入终止等待1状态。 该报文段首部中的终止位FIN(Finish的缩写)和确认位ACK的值都被设置为1表明这是一个TCP连接释放报文段同时也对之前收到的报文段进行确认。序号seq字段的值设置为U它等于TCP客户进程之前已传送过的数据的最后一个字节的序号加1。请注意TCP规定终止为FIN等于1的报文段即使不携带数据也要消耗掉1个序号确认号ack字段的值设置为v它等于TCP客户进程之前已收到的数据的最后一个字节的序号加1。 TCP服务器进程收到TCP连接释放报文段后会发送一个普通的TCP确认报文段并进入关闭等待状态 该报文段首部中的确认为ACK的值被设置为1表明这是一个普通的TCP确认报文段序号seq字段的值设置为V它等于TCP服务器进程之前已传送过的数据的最后一个字节的序号加1这也与之前收到的TCP连接释放报文段中的确认号匹配确认号ACK字段的值设置为U1这是对TCP连接释放报文段的确认。 TCP服务器进程这时应通知高层应用进程TCP客户进程要断开与自己的TCP连接此时从TCP客户进程到TCP服务器进程这个方向的连接就释放了这时的TCP连接属于半关闭状态也就是TCP客户进程已经没有数据要发送了但TCP服务器进程如果还有数据要发送TCP客户进程仍要接收也就是说从TCP服务器进程到TCP客户进程这个方向的连接并未关闭这个状态可能会持续一段时间TCP客户进程收到TCP确认报文段后就进入终止等待2状态等待TCP服务器进程发出的TCP连接释放报文段。 若使用TCP服务器进程的应用进程已经没有数据要发送了应用进程就要通知其TCP服务器进程释放连接。由于TCP连接释放是由TCP客户进程主动发起的因此TCP服务器进程对TCP连接的释放称为被动关闭连接TCP服务器进程发送TCP连接释放报文段并进入最后确认状态。 该报文段首部中的终止位FIN和确认位ACK的值都被设置为1表明这是一个TCP连接释放报文段同时也对之前收到的报文段进行确认。现在假定序号seq字段的值为W这是因为在半关闭状态下TCP服务器进程可能又发送了一些数据确认号ACK字段的值为U1这是对之前收到的TCP连接释放报文段的重复确认。 TCP客户进程收到TCP连接释放报文段后必须针对该报文段发送普通的TCP确认报文段之后进入时间等待状态 该报文段首部中的确认为ACK的值被设置为1表明这是一个普通的TCP确认报文段序号SEQ字段的值设置为U1这是因为TCP客户进程之前发送的TCP连接释放报文段虽然不携带数据但要消耗掉一个序号确认号ACK字段的值设置为W1这是对所收到的TCP连接释放报文段的确认。 TCP服务器进程收到该报文段后就要进入关闭状态而TCP客户进程还要经过两倍的MSL后才能进入关闭状态。MSL的意思是最长报文段寿命RFC793文档建议为两分钟
也就是说 TCP客户进程进入时间等待状态后还要经过4分钟才能进入关闭状态这完全是从工程上来考虑的。对于现在的网络MSL取为两分钟可能太长了因此TCP允许不同的实现和根据具体情况使用更小的MSL值。 那么 TCP客户进程在发送完最后一个确认报文段后为什么不直接进入关闭状态而是要进入时间等待状态两倍MSL后才进入关闭状态这是否有必要呢
来看这种情况TCP服务器进程发送TCP连接释放报文段后进入最后确认状态TCP客户进程收到该报文段后发送普通的TCP确认报文段并进入关闭状态而不是时间等待状态。然而该TCP确认报文段丢失了这必然会造成TCP服务器进程对之前所发送的TCP连接释放报文段的超时重传并仍处于最后确认状态。重传的TCP连接释放报文段到达TCP客户进程由于TCP客户进程属于关闭状态因此不理睬该报文段这必然会造成 TCP服务器进程反复重传TCP连接释放报文段并一直处于最后确认状态而无法进入关闭状态。
因此时间等待状态以及处于该状态两倍MSL的时长可以确保TCP服务器进程可以收到最后一个TCP确认报文段而进入关闭状态。另外TCP客户进程在发送完最后一个TCP确认报文段后再经过两倍MSL时长就可以使本次连接持续时间内所产生的所有报文段都从网络中消失这样就可以使下一个新的TCP连接中不会出现旧连接中的报文段。以上就是TCP通过4报文挥手释放连接的过程。 最后我们再来看看TCP中饱和计时器的作用。设想这样一种情况TCP双方已经建立了连接后来TCP客户进程所在的主机突然出现了故障显然 TCP服务器进程以后就不能再收到TCP客户进程发来的数据因此应当有措施使TCP服务器进程不要再白白等待下去。换句话说TCP服务器进程应该如何发现这种情况
方法就是使用保活计时器。TCP服务器进程每收到一次TCP客户进程的数据就要重新设置并启动保活计时器若保活计时器定时周期内未收到TCP客户进程发来的数据则当保活计时器到时后TCP服务器进程就向TCP客户进程发送一个探测报文段以后每隔75秒钟发送一次若一连发送10个探测报文段后仍无TCP客户进程的响应TCP服务器进程就认为TCP客户进程所在主机出了故障接着就要关闭这个连接
内容小结如下
TCP报文段的首部格式 接下来我们就来看看TCP报文段的首部格式TCP报文段的首部格式与IP数据报的首部格式类似都是由二十字节的固定首部和最大四十字节的扩展首部构成。 我们首先来看源端口和目的端口字段
源端口字段占16比特用来写入源端口号而源端口号用来标识发送该TCP报文段的应用进程目的端口号字段占16比特用来写入目的端口号而目的端口号用来标识接收该TCP报文段的应用进程。
我们来举例说明源端口和目的端口的作用
假设主机中的浏览器进程要访问WEB服务器中的WEB服务器进程为了简单起见我们仅从运输层端口号这个角度来举例说明而不考虑其他细节。例如ARP、域名解析TCP连接建立等。 当在浏览器地址栏中输入了外部服务器的域名后浏览器进程会构建一个封装有HTTP请求报文的TCP报文段该报文段首部中的源端口字段会填写一个短暂端口号例如49152用来标识发送该报文段的浏览器进程目的端口字段会填写熟知端口号80因为是用HTTP协议的WEB服务器进程默认监听该端口 WEB服务器收到该TCP报文段后从中解封出HTTP请求报文并根据TCP报文段首部中目的端口字段的值80将HTTP请求报文上交给WEB服务器进程WEB服务器进程根据HTTP请求报文的内容进行相应处理并构建一个HTTP响应报文HTTP响应报文需要封装成TCP报文段进行发送。该报文段首部中的源端口字段会填写熟知端口号80用来标识发送该TCP报文段的WEB服务器进程而目的端口字段会填写49152这是主机中需要接收该TCP报文段的浏览器进程所对应的端口号。 主机收到该TCP报文段后从中解封出HTTP响应报文并根据TCP报文段首部装目的端口字段的值49152将HTTP响应报文上交给浏览器进程浏览器进程对HTTP响应报文的内容进行解析并显示。
接下来我们再来看看与TCP实现可靠传输相关的序号字段确认号字段以及确认标志位ACK。 例如这是一个TCP报文段它有首部、数据载荷两部分构成数据载荷中的每个字节数据都有序号如图所示请注意他们是字节数据的序号而不是内容。对于本例首部中序号字段应填入的10进制值为166用来指出数据载荷的第一个字节的序号为166 我们来举例说明这三个字段的作用
TCP客户进程发送一个TCP报文段该报文段首部中序号字段的取值为201这表示该TCP报文段数据载荷的第一个字节的序号为201假设数据载荷的长度为100字节首部中确认号字段的取值为800这表示TCP客户进程收到了TCP服务器进程发来的序号到799为止的全部数据现在期望收到序号从800开始的数据为了使确认号字段有效首部中的确认标志位ACK的值必须设置为1。 TCP服务器进程收到该报文段后也给TCP客户进程发送TCP报文段该报文段首部装序号字段的取值为800这表示该TCP报文段数据载荷的第一个字节的序号为800这正好与TCP客户进程的确认相匹配假设数据载荷的长度为200字节首部中确认号字段的取值为301这表示TCP服务器进程收到了TCP客户进程发来的序号到300为止的全部数据现在期望收到序号从301开始的数据为了使确认号字段有效首部中的确认标志为ACK的值必须设置唯一。
我们再来看数据偏移字段 TCP报文段首部中的保留字段占6比特保留为今后使用目前应至为0。 我们再来看看窗口字段 该字段占16比特以字节为单位该字段指出的是发送本报文段的一方的接收窗口窗口值作为接收方让发送方设置其发送窗口的依据这是以接收方的接收能力来控制发送方的发送能力也就是所谓的流量控制需要注意的是发送窗口的大小还取决于拥塞窗口的大小也就是应该从接收窗口和拥塞窗口中取小者 TCP报文段首部中的校验和字段占16比特用来检查整个TCP报文段在传输过程中是否出现了误码与UDP类似。在计算校验和时要在TCP报文段的前面加上12字节的尾首部具体的校验算法就不再赘述了因为它仅仅是一种检测算法与TCP的其他重要功能相比检错算法并不是重点。 接下来我们来看同步标志位SYN该标志位在TCP连接建立时用来同步序号 如图所示TCP通过三报文握手建立连接的过程TCP客户进程发送的TCP连接请求报文段首部中的同步标志位SYN被置1表明这是一个TCP连接请求报文段TCP服务器进程发送的TCP连接请求确认报文段首部中的同步标志位SYN被置1确认为ACK也被置1表明这是一个TCP连接请求确认报文段。 再来看看终止标志位FIN该标志位用来释放TCP连接 如图所示TCP通过四报文挥手释放连接的过程不管是TCP客户进程还是TCP服务器进程他们所发送的TCP连接释放报文段首部中的终止标志位FIN都被置1表明这是TCP连接释放报文段 首部中的复位标志位RST用来复位TCP连接当RST等于1时表明TCP连接出现了异常必须释放连接然后再重新建立连接RST置1还可以用来拒绝一个非法的报文段或拒绝打开一个TCP连接 首部中的推送标志位PSH用来实现推送操作。当接收方的TCP收到该标志位为1的报文段会尽快上交应用进程而不必等到接收缓存都填满后再向上交付。 首部中的紧急标志位URG和紧急指针字段用来实现紧急操作。紧急标志为URG取之为1时紧急指针字段有效取值为0时紧急指针字段无效紧急指针字段占16比特以字节为单位用来指明紧急数据的长度。当发送方有紧急数据时可将紧急数据插队的发送缓存的最前面并立刻封装到一个TCP报文段中进行发送。紧急指针会指出本报文段数据载荷部分包含了多长的紧急数据紧急数据之后是普通数据接收方收到紧急标志为1的报文段会按照紧急指针字段的值从报文端数据载荷部分取出紧急数据并直接上交应用进程而不必在接收缓存中排队。 TCP报文段首部除了24节的固定部分还有最大40节的选项部分增加选项可以增加TCP的功能。 由于选项的长度可变因此还需要使用填充字段来确保报文段首部能被四整除。这是因为数据偏移字段也就是首部长度字段是以四字节为单位的如果选项的长度加上20字节固定首部的长度不能被4整除则需要使用填充字段来确保首部能被四整除。
内容小结如下;
