概述
运输层协议有 用户数据报协议UDP、传输控制协议TCP,还有流控制传输协议SCTP。前面我学习了应用进程利用系统调用创建了套接字,它包含了本机的IP地址以及应用层与传输层通信的端口号。在应用层来看,两个主机之间的通信实质是两个进程之间的通信,而在运输层来看,是两个端口之间的通信。下面将分别讨论运输层的这三个协议。
1、用户数据包协议UDP
UDP是无连接的,它尽最大努力交付,并且它是面向报文的,即应用进程传下来的报文原封不动的加上头部后给IP层,在接收端将IP层传上来的报文去掉首部后原封不动的交给应用进程。
UDP首部8个字节,UDP计算校验和的方法和IP数据包有些类似,不同的是IP数据包值检验首部,而UDP数据报是把首部和数据一起检验的(每16位相加)。另外要注意的是UDP在求校验和时要添加12字节的伪首部,伪首部包括源和目的IP地址等信息,容易分析这打破了TCP/IP协议严格分层的概念,因为在UDP进行校验和计算时是不知道IP地址的,IP地址对它来说应该是透明的。这就需要UDP与IP层进行通信以获取IP地址。
2、传输控制协议TCP
TCP是面向连接的,此连接上只能有两个端点。它提供可靠交付,面向字节流。
TCP首部20字节,计算校验和的方法和UDP类似。TCP有中几个比较重要点,我将之归纳为:
- 连接的建立与释放
- 累积确认
- 滑动窗口
- 流量控制
接收端B向发送端A发送了零窗口的报文,A接收到。但是当B的窗口有了空间时,向A发送的窗口大小的报文丢失了,这样A一直等B的报文,而B也会一直等A发送数据,陷入僵局。为了解决这个问题,TCP协议规定A在收到对方零窗口的通知后会定时向B发零窗口探测报文,若窗口不为零,则有开始发送数据。
为了保证传输效率还需考虑两个问题:
发送端的应用进程将字节逐个写入发送窗口时,每一次发送一个那效率一定是很低的。为了解决这个问题TCP中广泛地使用Nagle算法。即先把第一个字节发送出去,在收到接收端确认之前,收集应用进程写进窗口的数据,当收到确认后再将此时窗口中的数据全部发送出去,或者是在窗口数据增加到一半时也可发送。
另一个问题是接收方的窗口太小,假设为1时,那它会通知发送端发送窗口改为1,这样也会是效率极低。解决这个问题要从两个方面入手。1. 接收端:等有了较大的窗口空间了再发出确认报文并通知当前接收端窗口的大小。2. 发送端:发送方不要发送太小的报文段。
- 拥塞控制
慢开始算法:开始将拥塞窗口cwnd设置为1(一个最大报文段长度),收到确认(一个轮次)后cwnd改为2,发送两个报文,再收到确认后cwndg改为4,发送4个报文。。。。 依次拥塞窗口大小指数增长。
拥塞避免 让cwnd缓慢增大,每一个轮次增加1。依次拥塞窗口大小线性增长。
TCP设置了一个慢开始门限ssthresh。当cwnd<ssthresh时,采用慢开始算法,cwnd指数增加;当cwnd>ssthresh时转为拥塞避免算法,cwnd线性增长。当网络出现超时,可能发生了拥塞,将ssthresh减半。
该算法可归纳为:乘法减小,加法增大。
后面还有块重传和块恢复算法,块重传是在发送发接连收到3个重复确认,就立即重传对方需要的数据,而不是等到重传定时器复位之后。块重传可以提高网络的吞吐量。快恢复就是在发送发接连收到3个重复确认后将cwnd减小为原来ssthresh的一半,之后再执行拥塞控制算法。
随机早期检测RED 是在路由器平均队列长度到大某一门限时,以概率p随机丢弃分组,以防止网络进入拥塞最坏的情况。
3、流控制传输协议SCTP
未完待续。。。。。。
最后
以上就是正直绿草为你收集整理的运输层相关协议的学习笔记的全部内容,希望文章能够帮你解决运输层相关协议的学习笔记所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复