1 / 46
文档名称:

传输层协议.ppt

格式:ppt   大小:1,903KB   页数:46页
下载后只包含 1 个 PPT 格式的文档,没有任何的图纸或源代码,查看文件列表

如果您已付费下载过本站文档,您可以点这里二次下载

分享

预览

传输层协议.ppt

上传人:文库新人 2022/2/4 文件大小:1.86 MB

下载得到文件列表

传输层协议.ppt

相关文档

文档介绍

文档介绍:传输层协议
第1页,本讲稿共46页
进程间通信
由于在一台计算机中同时存在多个进程,要进行进程间的通信,首先要解决进程的标识问题。TCP和UDP采用协议端口来标识某一主机上的通信进程。
必须给出全局惟一的信宿端的进程的段的最大字节数。该值范围为0到65535,默认值为536。
窗口规模因子选项为多字节选项,代码为3,长度为3字节。在TCP段的首部存在16比特的窗口大小字段,但在高吞吐和低延迟的网络中,65535字节的窗口仍然嫌小。通过在选项中采用窗口规模因子,可以增加窗口的大小。扩展后的窗口大小为:
Wn=Wo×2f
Wn为新的窗口大小,Wo为TCP首部窗口大小字段的值,f为窗口规模因子。
第14页,本讲稿共46页
时间戳选项为多字节选项,代码为8,长度为10字节。时间戳值字段由源端在发送数据段时填写,信宿端收到后,在确认数据段中将收到的时间戳值填入时间戳回显应答字段,信源端根据该时间戳值和当前时间戳可以计算出数据段的往返时间。
返回
第15页,本讲稿共46页
TCP连接的建立和拆除
TCP连接的建立
为了实现数据的可靠传输,TCP要在应用进程间建立传输连接。
从理论上讲,建立传输连接只需要一个请求和一个响应就可以了。但是由于通信子网的问题,请求有可能丢失,为了解决请求的丢失问题,常用的办法是超时重传。
客户发出连接请求时,启动一个定时器,一旦定时器超时,客户将被迫再次发起连接请求,会导致重复连接。
第16页,本讲稿共46页
解决重复连接的办法:三次握手方法。
三次握手方法要求对所有报文进行编号,TCP采用的方法是给每个字节一个32比特的序号。
每次建立连接时都产生一个新的初始序号。
序号字段位数定长,序号循环使用,序号字段位数较长,当序号循环一周回来时,使用同一序号的旧报文段早已传输完。这样,保证网络中不会同时出现来自同一源主机的相同序号的两个不同报文段。
第17页,本讲稿共46页
建立连接前,服务器端首先被动打开其熟知的端口,对端口进行监听。当客户端要和服务器建立连接时,发起一个主动打开端口的请求(临时端口)。然后进入三次握手过程:
第一次握手:由要建立连接的客户向服务器发出连接请求段,该段首部的同步标志SYN被置为1,并在首部中填入本次连接的客户端的初始段序号SEQ(例如SEQ=26500)。
第二次握手:服务器收到请求后,发回连接确认(SYN+ACK),该段首部中的同步标志SYN被置为1,表示认可连接,首部中的确认标志ACK被置为1,表示对所接收的段的确认,与ACK标志相配合的是准备接收的下一序号(ACK 26501),该段还给出了自己的初始序号(例如SEQ=29010)。对请求段的确认完成了一个方向上连接。
第18页,本讲稿共46页
第三次握手:客户向服务器发出的确认段,段首部中的确认标志ACK被置为1,表示对所接收的段的确认,与ACK标志相配合的准备接收的下一序号被设置为收到的段序号加1(ACK 29011)。完成了另一个方向上的连接。
第19页,本讲稿共46页
TCP连接的拆除
连接双方都可以发起拆除连接操作。
简单地拆除连接可能会造成数据丢失。例如,A、B两主机已建立连接并传输报文,A主机在B主机没有准备的情况下,单方面发出断开连接请求,并停止接收该连接上的数据。但断开连接请求的传输要有一段时间,而在B主机未收到断开连接请求之前,随时可能向A主机发送数据,会有丢失数据的可能性。
第20页,本讲稿共46页
解决:TCP采用和三次握手类似的方法。这里可以将断开连接操作视为在两个方向上分别断开连接操作构成。一方发出断开连接请求后并不马上拆除连接,而是等待对方的确认,对方收到断开连接请求后,发送确认报文,这时拆除的只是单方向上连接(半连接)。对方发送完数据后,再通过发送断开连接请求来断开另一个方向上的半连接。
返回
第21页,本讲稿共46页
TCP流量控制
TCP除了提供进程通信能力外,主要特点是具有高可靠性。TCP在发送端与接收端之间建立一条连接,报文需要得到接收端的确认。TCP传输的是一个无报文丢失、重复和失序的正确的数据流。
TCP采用的最基本的可靠性技术:
流量控制
拥塞控制
差错控制
第22页,本讲稿共46页
问题:在面向连接的传输过程中,发送方与接收方在发送报文的速率方面要协调一致。
若发送方一味地向网络注入数据,则可能造成网络拥塞或因接收方来不及处理而丢失数据。
若发送方每发出一个报文都等待对方的确认,势必造成效率低下。
解决:滑动窗口协议。采用滑动窗口协议既能够保证可靠性,又可以充分利用网络的传输能力。这种方案允许连续传输多个报文而不必等待各个报文的确认,能够连续发送的报文数受到窗口大小的限制