Chapter5 传输层
Chapter5 传输层
传输层概述
传输层是只有主机才有的层次
功能:
提供进程和进程之间的逻辑通信
传输层提供应用进程之间逻辑通信(
端到端
通信 )网络层提供的是主机到主机的通信
复用和分用
- 复用:发送方不同的应用进程都可以使用同一个传输层协议传送数据
- 分用:传输层在剥去报文的首部后能把这些数据正确交付到目的应用进程
向高层屏蔽了低层网络核心的细节
- 如网络拓扑,路由协议等
- 进程看见的是两个传输层实体之间的一条端到端的逻辑通信信道
- 信道对上层的表现因传输层协议的不同而不同
传输层对收到的报文进行差错检测。
- TCP发现报文段出错,则要求重发
- UDP发现报文段出错,则直接丢弃
网络层中IP数据报首部的检验字段只检验首部是否出错,不检查数据部分。
提供面向连接和无连接的传输协议
网络层无法同时实现两种协议,要么只提供面向连接服务(虚电路),要么只提供无连接服务(数据报)
端口
端口是传输层服务访问点(TSAP
),用于标识主机中的某个应用进程
软件端口
不用进程ID?
进程ID的定义依赖于特定操作系统
一个应用进程常常需要与网络中的多个主机中的进程通信
端口号长度为16bit,能表示65536个不同的端口号。
- ==服务端使用==
- 熟知端口号或系统端口号(0 ~ 1023)
- FTP:控制是21数据是20
- TELNET:23
- SMTP:25
- DNS:53(UDP)
- TFTP:69(UDP)
- HTTP:80
- RPC:111(UDP)
- SNMP:161(UDP)
- HTTPS:443
- 登记端口号(1024 ~ 49151)
- 供没有熟知端口号的应用程序使用
- 须在 IANA 登记,以防重复
- 熟知端口号或系统端口号(0 ~ 1023)
- 客户端/短暂端口号(49152 ~ 65535 )
- 客户进程临时使用
套接字
端口号拼接到IP地址即构成套接字
socket=(主机IP地址:端口号)
套接字唯一标识了网络中的一个主机和它上面的一个进程
IP
区分不同主机,端口号
区分不同应用进程,套接字
区分不同通信端点。
每一条 TCP 连接唯一地被通信两端的两个端点(即两个套接字)所确定
TCP 连接 ={socket1, socket2} = {(IP1: port1), (IP2: port2)}
(协议
、源地址
、目的地址
、源端口号
、目的端口号
)唯一标识一次传输层通信
无连接服务和面向连接服务
用户数据报协议UDP User Datagram Protocol
传输控制协议TCP Transmission Control Protocol
传输的数据单位:
- OSI术语称为TPDU(Transport Protocol Data Unit)
- TCP/IP体系称为TCP报文段(segment)或UDP用户数据报
特性 | TCP(传输控制协议) | UDP(用户数据报协议) |
---|---|---|
连接方式 | 面向连接,需要建立连接(三次握手) | 无连接,不需要建立连接 |
可靠性 | 可靠传输,数据包丢失会重传 | 不可靠传输,不保证数据到达 |
顺序保证 | 保证数据按顺序到达 | 不保证数据顺序 |
流量控制 | 有流量控制机制 | 无流量控制机制 |
拥塞控制 | 有拥塞控制机制 | 无拥塞控制机制 |
传输速度 | 较慢(开销大,但可靠) | 较快(开销小,但不可靠) |
首部开销 | 较大,通常为 20 字节 | 较小,通常为 8 字节 |
数据传输单位 | 流(Stream) | 报文(Datagram) |
是否支持广播/多播 | 不支持广播和多播 | 支持广播和多播 |
是否有错误校验机制 | 有(包括重传机制) | 有(只校验,不重传) |
协议 | FTP文件传送协议 TELNET电传机网络 SMTP简单邮件传送协议 HTTP超文本传送协议 HTTPS BGP |
DNS域名系统 TFTP简单文件传送协议 RIP路由信息协议 网际组管理协议IGMP 动态主机配置协议DHCP 简单网络管理协议SNMP RPC |
UDP协议
UDP是无连接的传输层协议,它为应用层提供了一种不可靠的数据传输服务
在IP层数据报服务上仅增加:复用和分用,差错检测。
实现分用时依据的首部字段是
目的端口号
UDP特点*
无连接,即发送数据之前不需要建立连接,收到UDP报文后也不需要给出任何确认
使用尽最大努力交付,即不保证可靠交付,同时也不使用拥塞控制
使用UDP的网络应用,其数据可靠性由应用层负责
是面向报文的。没有拥塞控制,很适合多媒体通信的要求
- 故网络中的拥塞不会影响主机发送效率
支持一对一、一对多、多对一和多对多的交互通信
首部开销小,只有 8 个字节
UDP报文
- UDP首部8B,包括源端口号,目的端口号,长度,校验和。
源端口
:2B,源端口号,需要对方回信时选用,否则全0目的端口号
:2B,目的端口号,终点交付报文时必须使用长度
:2B,UDP首部和UDP数据的总长度,单位字节- 最小值为8B,即仅有首部
校验和
:2B,检验UDP首部和UDP数据的正确性,如果为0,表示不检验
- UDP分用:传输层将UDP数据报根据不同端口上交给不同应用进程
- 如果接收方UDP发现端口号不正确,则丢弃报文,并且由ICMP发送差错报文给发送方
UDP校验
伪首部:
- 12B,模仿IP首部,只在计算校验和时出现
- 源IP地址 (4B),目的IP地址 (4B),0 (1B),UDP协议号17 (1B),UDP长度 (2B)
作用
伪首部既不向下传送也不向上递交,而仅仅是为了计算运输层的检验和。
IP只计算包头校验和,UDP计算整个数据报的校验和
二进制反码求和的运算规则如下:
①从低 位到高位逐列进行计算,1和1相加是0并产生进位 1
②若最 高位相加后产生进位,则最后得到的结果要在最低位加1,该过程也称回卷
在发送端:
- 填上伪首部
- 全0填充UDP首部的检验和字段
- 若数据部分不是偶数个字节,则末尾添加1个全0字节(只添加不发送)
- 伪首部+首部+数据部分采用二进制反码,然后分16位一组求和
- 把和求反码填入检验和字段
- 去掉伪首部,发送
在接收端:
- 填上伪首部
- 为伪首部+首部+数据部分采用二进制反码求和
- 结果全为1则没有差错,否则丢弃数据报/交给应用层并附上差错警告。
- 如果检验处UDP数据报是错误的,则可以丢弃,也可以交付给上层,但是需要附上错误报告
- 通过伪首部,可以检查源端口号、目的端口号、UDP、数据报的数据部分,还可以检查IP数据报的源IP地址和目的IP地址。
不考虑NAT,跨网络IP通信,一定保持不变的只有目的IP地址
UDP总长度、UDP 检验和、IP 检验和、FCS 帧检验序列( 不同链路MTU 的限制,则需要进行分片处理)
在不同的链路上,目的 MAC 地址都有所不同
TCP协议
TCP特点*
面向连接的传输层协议
- 其连接是逻辑链接
- 传输数据前必须先建立连接,数据传输完毕后要释放连接
每条TCP连接只能有两个端点,每一条TCP连接只能是点对点的(一对一)
TCP提供可靠交付的服务
- 保证传输的数据无差错,不丢失,不重复,且按序到达。
TCP提供全双工通信
允许通信双方的应用进程在任何时候都能发送数据。所以TCP连接的两端都设有发送缓存和接收缓存,用来临时存放双方通信的数据。
发送缓存
- 发送应用程序传送给发送方TCP准备发送的数据
- TCP已发送但尚未收到确认的数据
接收缓存
按序到达的数据,但尚未被接收应用程序读取的数据
不按序到达的数据
TCP是面向字节流的
- 其将应用程序传下来的数据块视为一连串无结构的字节流
UDP报文长度由发送的应用进程决定,TCP报文长度根据接收方的窗口值和网络拥塞程度决定。
TCP和IP区别
IP协议提供的是不可靠的、“面向非连接”的服务
TCP协议提供的是可靠的、“面向连接”的服务
TCP协议实现的是主机应用程序之间的通信,IP协议只实现主机之间的通信
TCP协议是以IP协议为基础实现的,给应用层提供服务;
IP协议为TCP协议提供服务。IP协议负责将数据从一台主机传输到另一台主机,而TCP协议保证传输的正确性
TCP报文
TCP报文段既可以运载数据,也可以建立连接,释放连接和应答
TCP报文字段:
源端口和目的端口
:各2B,传输层和应用层的服务接口,复用和分用功能依靠端口号实现序号seq
:4B,32位的序号,用来标识本报文段所发送的数据的第一个字节的序号确认号ack
:4B,期望收到对方下一个报文段的第一个数据。若确认号为N,则表明到N-1为止的数据已经正确收到数据偏移
:4位,指首部长度- 单位是4B
- 最大值为15,60B
保留位
:6位,保留位,目前没有使用紧急位URG
:1位- URG = 1时表示报文段中有高优先级的数据,可以插队发送
确认位ACK
:1位- ACK=1时确认号字段ack才有效
- 在连接建立后所有传送的报文段都必须把ACK置为1
推送位PSH
:1位- PSH =1时接收方尽快交付接受进程,不用等到缓存填满
复位位RST
:1位- RST=1时表示TCP连接中出现严重差错,必须释放、重新建立传输链接
同步位SYN
:1位- SYN=1时表示连接请求(ACK=0)或连接接受(ACK=1)报文段
终止位FIN
:1位- FIN = 1时表示此报文段发送方数据已经发完,要求释放连接
窗口
:2B,16位,允许对方发送的数据量,单位是1B校验和
:2B,校验和字段检验范围包括首部和数据两部分与UDP一样,要在TCP报文段前加上12B的伪首部
紧急指针
:2B,只有在URG=1时才有意义,指出本报文段中紧急数据共多少字节。选项
:长度可变- 最大报文长度MSS
- 告知对方报文段中数据最大长度,双方可使用不同的MSS
- 缺省MSS=536字节
- 窗口扩大、时间戳、选择确认等等。
- 最大报文长度MSS
填充
:为了使整个首部长度是4B
的整数倍
可靠传输
可靠:保证接收方进程从缓存区读出的字节流和发送方发出的字节流是完全一样的
TCP使用了校验,序号,确认和重传等机制来达到目的
校验
TCP的校验机制与UDP校验一样
序号
- 序号建立在字节流的基础上,TCP首部的序号保证数据能有序交给应用层
确认
接收方可能传输数据,同时捎带确认。
确认报文段有确认号字段ack。
==TCP的确认是对报文段的==,不是对字节/分组的
- TCP的确认机制是接收方向发送方发送确认信息,确认信息中包含了期望收到的下一个字节的序号。
- 发送方缓存区会存储已发送未收到确认的报文段,以便需要时重传。
- TCP默认使用
累积确认
- 即只确认数据流中至第一个丢失字节为止的字节
- 例如收到1,2,3,7,8;4,5,6丢失,则返回的确认报文段中,确认号字段为4
重传
两种事件会导致TCP重传: 超时
和 冗余ACK
。
超时
TCP发送一个报文段后,对其设置计时器,如果到重传时间后还未收到确认,则重传这一报文段。
由于传输层往返时延方差很大,TCP采用自适应算法
往返时间RTT:一个报文发出和收到确认的时间差
加权平均往返时间
- 第一次测量到RTT样本时, RTTS就取为该值
以后每测量到一个新的RTT样本,重新计算
0<a<1,推荐值是 0.125, a越小,RTT值更新越慢, a越大,RTT值更新越快
超时重传时间 RTO
- 应略大于
- 第一次测量时, 为测量到的 RTT 样本值的一半
- 在以后的测量中,重新计算
- 0< β<1,推荐值是 0.25
冗余确认
每当比期望序号大的失序报文段到达时,发送一个冗余ACK,指明下一个期待字节的序号。
发送方已发送1,2,3,4,5;2丢失;
接收方收到1,返回给1的确认(ack=2)
接收方收到3,返回给1的确认(ack=2)
接收方收到4,仍然返回给1的确认(ack=2)
接收方收到5,仍然返回给1的确认(ack=2)
当发送方收到同一个报文段的 三次
冗余ACK后,就可认为跟在这个被确认报文段后的报文段已经丢失,于是 快速重传
这个报文段
发送方收到3个对于报文段1的冗余ACK:认为报文段2丢失,重传2号报文段
流量控制
- 流量控制的目的是消除发送方和接收方之间的数据传输速率不匹配的问题。
- TCP采用基于
滑动窗口协议
的流量控制机制。 - 接收方根据自己接收缓存的大小,动态调整发送方的发送窗口大小,这称为接收窗口
rwnd
,单位字节- TCP报头中都携带有窗口大小字段
- 发送方根据当前网络拥塞程度的估计而确定的窗口值,称为拥塞窗口
cwnd
- 其大小与网络带宽和时延密切相关
- 发送方的发送窗口 = min(接收窗口rwnd,拥塞窗口cwnd}
拥塞控制和流量控制的区别在于
流量控制是为了保护接收方,而拥塞控制是为了保护网络。
滑动窗口是一种实现流量控制的方法,而不是拥塞控制的方法。
虽然在拥塞控制的机制中用到了滑动窗口,但这并不是滑动窗口的作用。
持续计时器(persistence timer)
- TCP为每一个连接设有一个持续计时器
- 只要一方收到对方的零窗口通知,就启动持续计时器
- 若持续计时器设置的时间到,就发送一个零窗口探测报文段(仅 携带1字节的数据),而对方在确认这个探测报文段时给出当前 窗口值
- 若窗口仍然是零,则收到这个报文段的一方就重新设置持续计时器
- 若窗口不是零,则死锁的僵局就可以打破了
可以用不同的机制来控制TCP报文段的发送时机
- 缓存数据达到一定量就发送
- TCP维持一个变量,它等于最大报文段长度MSS
- 只要缓存中存放的数据达到MSS字节时,就组装成一个TCP报文段发送出去
- 应用进程控制 – 由发送方的应用进程指明要求发送报文段,即推送(push)操作
- 定时发送
- 发送方的一个计时器期限到了,这时就把当前已有的缓存数据装入报文段( 但长度不能超过 MSS)发送出去
拥塞控制
- 出现拥塞条件:对资源需求的总和>可用资源
- 网络资源:链路带宽、路由节点缓存及处理能力等
- 单一地增加资源并不能解决拥塞
- 增加缓存容量,报文可在缓存中排队,但如果路由器处理能力和出口链路带宽未增加,报文排队时间过长,发送主机将超时重发→拥塞没有解决
- 拥塞恶性循环:TCP重传机制
- 拥塞控制:防止过多数据注入网络,保证网络中路由器或链路不致过载。
- 全局性的过程,涉及所有主机和路由器
- 往往是指点对点的通信量的控制,是端到端的问题
- 抑制发送端发送数据的速率,使得接收端能够及时地处理接收到的数据
- 拥塞控制两种方法:
开环控制
:在设计网络时事先将有关发生拥塞地因素考虑周到,力求网络在工作时不产生拥塞;这是一种静态
的预防方法,一旦整个系统启动并运行,中途就不再需要修改。闭环控制
:事先不考虑有关发生拥塞的各种因素,采用检测网络系统去监视,及时检测哪里出现了拥塞,然后将拥塞信息传到合适的地方,以便调整网络系统的运行,并解决出现的问题。闭环控制是基于反馈环路的概念,是一种动态
的方法。
- 维护
两个窗口
:- 接收窗口
rwnd
:反应接收方容量,接收方根据TCP首部窗口字段通知发送方。 - 拥塞窗口
cwnd
:反应网络当前容量,发送方根据网络拥塞程度动态调整。 - 发送窗口上限值:上述两个之间最小的一个。
- 接收窗口
发送窗口上限值=min(rwnd,cwnd)
慢启动
- 令cwnd=1,即一个最大报文段长度MSS
- 每收到一个报文段的确认后,将cwnd加一
- 宏观上,每经过一个往返时间RTT,cwnd就
加倍
- 直至增加到一个规定的慢启动门限
ssthresh
(阈值) ,然后采用拥塞避免算法
拥塞避免
- 每经过一个往返时延RTT就把发送方的拥塞窗口 cwnd加一
- 使拥塞窗口cwnd按线性规律缓慢增长。
- 算法归纳如下:
- cwnd<ssthresh,使用
慢启动算法
- cwnd>ssthresh,停止使用慢启动算法而改用
拥塞避免算法
- cwnd=ssthresh,既可以用慢启动算法,又可以用
拥塞避免算法
(通常做法)
- cwnd<ssthresh,使用
网络拥塞处理
- 如果发送方判断网络出现拥塞,即出现
超时
情况- 慢开始门限 ssthresh 设置为==当前 cwnd 的
一半
(不能小于2)== - 将 cwnd 置为
1
,并重新开始慢启动算法
- 慢开始门限 ssthresh 设置为==当前 cwnd 的
- 目的是迅速减少主机发送到网络中的分组数,使得拥塞路由器有足够时间把队列中积压的分组处理完。
- 拥塞避免无法完全避免拥塞,只能使网络不同意出现拥塞
- cwnd单位:MSS,一个最大报文段长度
- 注意:在慢开始阶段,如果当前2cwnd>ssthresh,则下一个RTT后的cwnd等于ssthresh,而不是2cwnd,如图中第16~第17轮次。
快重传
- 如果发送方在超时时间内未收到确认报文,说明网络中发生了拥塞,此时 发送方应尽早地减小窗口宽度
- 每当接收方收到一个失序的报文段,就发出重复确认,以便使发送方及早知道有报文段没有到达接收方
- 发送方连续收到
三个冗余ACK
后,不必等待超时重传定时器到期,就立即重传丢失的报文段
快恢复
- 发送方连续收到
三个冗余ACK
- 将 ssthresh 设置为当前 cwnd 的
一半
- cwnd 置为 ssthresh
当前数值
- 进入
拥塞避免算法
- 将 ssthresh 设置为当前 cwnd 的
- 发送方预防网络发生拥塞,而由于可以收到连续的报文,故网络没有发生严重拥塞,所以跳过了慢启动算法,直接进入
拥塞避免算法
,称为快恢复
。
连接管理
TCP传输连接有三个阶段
- 连接建立
- 数据传送
- 连接释放
TCP连接的建立和释放需要经过三次握手和四次挥手
TCP连接是全双工的,即双方都可以同时发送数据
==TCP解决的三个问题==
为什么一定要连接
- 使双方确知对方存在
- 允许双方协商参数
- 能够对运输实体资源进行分配
TCP连接的建立采用 客户/服务器方式
- 客户端
Client
:主动发起建立连接的应用进程称为 - 服务器
Server
:被动等待建立连接的应用进程称为
- 客户端
连接建立
三次握手
:建立连接时,客户端和服务器端需要发送SYN,SYN+ACK,ACK三个报文段。建立连接前
:服务器处于LISTEN
收听状态。第一次握手
:客户端发送连接请求报文段,SYN=1,Seq=x(初始序号),ACK=0,客户端进入SYN_SENT
同步已发送 状态,等待服务器确认。第二次握手
:服务器收到连接请求报文段后,如果同意建立连接,则会发送一个连接确认报文段,SYN=1,ACK=1,Seq=y,ack(确认号)=x+1,服务器进入SYN_RCVD
同步收到 状态。第三次握手
:客户端收到连接确认报文段后,还要向服务器发送一个确认报文段,ACK=1,Seq=x+1,ack=y+1,客户端进入ESTABLISHED
已建立 状态,完成TCP连接的建立。
不同的TCP连接不能使用相同的初始序号,避免新的连接中传送旧链接中滞留的部分
第二次握手不能携带数据,也要消耗一个序号
第三次握手如果不携带数据则不消耗序号
服务器端的资源是第二次握手时分配的,客户端资源是第三次握手时分配的
服务器容易收到SYN洪泛攻击,攻击者连续发送大量SYN报文,但却不对SYN ACK报文做出响应,服务器内部数据结构满,无法响应正常用户的TCP连接请求
==为什么采用3次握手而不是2次?==
- 防止“失效的连接请求”在服务器端占用资源
- 客户端发出了连接请求,但该数据报在网络中某处滞留了
- 客户端等待超时后,重发连接请求,服务器响应,建立连接
- 滞留的连接请求又到达服务器端,如果采用2次握手,服务器将建立一个连接,分配资 源(缓冲区、定时器、…) → 占用资源且长期存活
连接释放
- 参与TCP连接的两个进程中任何一个都能终止连接。
以下假设客户端先挥手。
四次挥手
:释放连接时,客户端和服务器端需要发送FIN,ACK,FIN,ACK四个报文段。第一次挥手
:客户端向TCP发送连接释放报文段,FIN=1,Seq=u,客户端进入FIN_WAIT_1
终止等待1 状态,停止发送数据,但对方可以继续发送数据。第二次挥手
:服务器收到连接释放报文段后,发送一个确认报文段,ACK=1,Seq=v,ack=u+1,服务器进入CLOSE_WAIT
关闭等待 状态,此时TCP连接处于半关闭状态。期间
:客户端到服务器端的连接已经释放,但服务器到客户端的连接还没有释放,服务器发送的数据客户端仍需接收。第三次挥手
:服务器向客户端发送连接释放报文段,ACK=1,FIN=1,Seq=w,ack=u+1,服务器进入LAST_ACK
最后确认 状态。第四次挥手
:客户端收到连接释放报文段后,发送一个确认报文段,ACK=1,Seq=u+1,ack=w+1,客户端进入TIME_WAIT
时间等待 状态,等待可能出现的对方的最后一个ACK。在2MSL
最长报文段寿命 后,客户端进入CLOSED
关闭 状态,完成TCP连接的释放。
TCP服务器释放连接的最短时间:1.5RTT
关闭连接前等待2MSL时间的原因
为了保证A发送的最后一个ACK报文段能够到达B
防止“已失效的连接请求报文段”出现在本连接中
A在发送完最后一个ACK报文段后,再经过时间2MSL,就可以使本连接持续的时间内所产生的所有报文段,都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段
题目
TCP以MSS大小将数据分割发送/重发
TCP 在 40Gb/s 的线路上传送数据,若 TCP 充分利用了线路的带宽,则经过895ms的时间TCP 会发生序号绕回(使用了之前用过的字节序号)
面向字节 每秒可传送5×10^9字节的数据,
2\^32/5x10\^9=0.859
>
主机甲和主机乙之间建立一个TCP连接,TCP最大段长度为1000字节,若主 机甲的当前拥塞窗口为4000字节,在主机甲向主机乙连续发送2个最大段后, 成功收到主机乙发送的第一段的确认段,确认段中通告的接收窗口大小为 2000字节,则此时主机甲还可以向主机乙发送的最大字节数是:1000B
发送窗口=min(2000B,4000B)=2000B
已发送但未确认的数据量为1000B
设 TCP 的拥塞窗口的慢开始门限值初始为8(单位为报文段),当拥塞窗口上升到 12 时发生超时,TCP 开始慢开始和拥塞避免,则第13 次传输时拥塞窗口的大小为7
1 2 4 8 9 10 11 12 1 2 3 4 6 7
这是什么东西啊啊啊啊啊啊
甲和乙刚建立 TCP 连接,并约定最大段长为 2KB,假设乙总是及时清空缓存,保证接收窗口始终为20KB,ssthresh为16KB,若双向传输时间为10ms,发送时延忽略不计,且没有发生拥塞的情况,则经过(B)甲的发送窗口第一次达到 20KB。
A. 40ms B.50ms C.60ms D.70ms
1 2 4 8 9 10
2(1MSS)—>4(2MSS)—>8(4MSS)—>16(8MSS)—>18(9MSS)—>20(10MSS)
经过1个RTT 收到新确认 改变cwnd
例如第一轮收到确认之后,cwnd=2MSS
假设在没有发生拥塞的情况下,在一条往返时延RTT为 10ms 的线路上采用慢开始控制策略。若接收窗口的大小为 24KB,最大报文段 MSS 为2KB,则发送方能发送出第一个完全窗口(也就是发送窗口达到 24KB)需要的时间是(B)。
1 2 4 8 16(12)
A. 30msB.40msC.50msD.60ms
甲向乙发起一个 TCP 连接,最大段长 MSS=1KB,RTT=3ms,乙的接收缓存为 16KB且乙的接收缓存仅有数据存入而无数据取出,则甲从连接建立成功至发送窗口达到8KB,需经过的最小时间以及此时乙的接收缓存的可用空间分别为()。
1 2 4 8
9ms 9kb
H3 的发送窗口等于0时,下一个待发送段的序号是20K+ 101 =20×1024 + 101 =20581。 H3 从发送第1个段到发送窗口等于0时刻为止,共耗费了5RTT(每个 RTT 传输的数据 量依次为 1KB、2KB、4KB、8KB、5KB),平均数据传输速率是 20KB+(5×200ms) = 20×1024×8b/s=163.84kb/s.
假定 TCP 报文段载荷是 1500B,最大分组存活时间是 120s,要使得 TCP 报文段的序列号不会循环回来而重叠,线路允许的最快速度是多大?(不考虑帧长限制)
120s内共2^32B个载荷
TCP 报文段载荷是1500B,因此可以发送23861个报文段
CP 开销是20B,IP 开销是20B,以太网开销是26B (18B 的首部和尾部,7B 的前同步码,1B的帧开始定界符)
1566×8×23861=299Mb/s
在一个 TCP 连接中,信道带宽为 100Mbs,单个报文大小为 1000B,发送窗口固定为 60,端到端时延为 20ms。TCP 最多能达到的平均数据传输速率是多少?信道利用率是多少?(只考虑单向传输,确认报文的发送时延、各层协议的首部开销均忽略不计
平均数据传输速率=窗口内可发送的总数据量/等待第一个确认所需的时间
也就是:
一个客户向服务器请求建立TCP连接。客户在TCP连接建立的三次握手中的最后一个报文段中捎带上一些数据,请求服务器发送一个长度为L字节的文件。假定:(1)客户和服务器之间的数据传输速率是R字节/秒,客户与服务器之间的往返时间是RTT(固定值)。 (2)服务器发送的TCP报文段的长度都是M字节,而发送窗口大小是nM字节。(3)所有传送的报文段都不会出错(无重传),客户收到服务器发来的报文段后就及时发送确认。(4)所有的协议首部开销都可忽略。所有确认报文段和连按建立阶段的报文段的长度都可忽略(即忽略这些报文段的发送时间)。试证明,从客户开始发起连接建立到接收服务器发送的整个文件多需的时间T是:
T=2RTT+L/R 当nM>R(RTT)+M
或T=2RTT+L/R+(K-1)[M/R+RTT-nM/R] 当nM<R(RTT)+M
其中,K=[L/nM],符号[x]表示若x不是整数,则把x的整数部分加1
证明:1.如果发送方的发送窗口大小大于或等于所要发送的报文的大小,无需考虑发送完窗口内的所有数据后没收到第一个数据的确认报文而产生的等待时间。
nM(窗口大小)> R(RTT)(传输数据的最小长度)+M(一个TCP报文段的长度)
所以:总时间T=传播时延2RTT(3次握手+客户端一次性发送所有数据)+发送时延L/R
2.发送窗口小于报文大小。
总时间T=传播时延2RTT(3次握手+客户端一次性发送所有数据)+发送时延L/R+发送方等待的时间
由滑动窗口的机制可知在发送方发完窗口内所有数据后由于未收到第一个数据的确认所以陷入等待
例如编号:1,2,3,4,5,6,7…窗口大小为3,则1,2,3发送完毕后进入等待至收到1的确认。由题意得收到1的确认紧接着就是2,3的确认相当于收到1的确认后窗口紧接着就后移3然后重复以上。从把1放到链路到收到1上到收到1的确认总时间M/R+RTT,发送时间是nM/R,发送方等待时间 t =M/R+RTT-nM/R。(这个前提是窗口后面还有大于一个窗口的数据,因为要满足发送方的发送时间是nM/R)
K=[L/nM],得到共有K个窗口,停顿的次数为K-1窗口的等待时间是(K-1)[M/R+RTT-nM/R],依题意最后一次发送完毕便结束(这个时间在L/R中)。
T=2RTT+L/R+(K-1)[M/R+RTT-nM/R]