导图社区 运输层
计算机网络运输层对应课本谢希仁 包含运输层的所有知识点。OSI七层模型中的物理层、数据链路层和网络层,它们是面向网络通信的低三层协议。运输层负责端到端的通信,既是七层模型中负责数据通信的最高层,又是面向网络通信的低三层和面向信息处理的最高三层之间的中间层。干货满满,赶快收藏学起来吧!
编辑于2020-07-03 11:14:31内带考研408专业课考纲 计算机网络全书,适合考研期末考试等复习 参考的是比较流行的课本--谢希仁版 历时一个月精心制作如有错误或不当之处请谅解 包含原书中的所有研究生考试的知识点 感谢你的使用考研加油
计算机网络运输层对应课本谢希仁 包含运输层的所有知识点。OSI七层模型中的物理层、数据链路层和网络层,它们是面向网络通信的低三层协议。运输层负责端到端的通信,既是七层模型中负责数据通信的最高层,又是面向网络通信的低三层和面向信息处理的最高三层之间的中间层。干货满满,赶快收藏学起来吧!
包含常见的递归分治算法,动态规划,贪心算法常见的算法,典型的算法配有代码.
社区模板帮助中心,点此进入>>
内带考研408专业课考纲 计算机网络全书,适合考研期末考试等复习 参考的是比较流行的课本--谢希仁版 历时一个月精心制作如有错误或不当之处请谅解 包含原书中的所有研究生考试的知识点 感谢你的使用考研加油
计算机网络运输层对应课本谢希仁 包含运输层的所有知识点。OSI七层模型中的物理层、数据链路层和网络层,它们是面向网络通信的低三层协议。运输层负责端到端的通信,既是七层模型中负责数据通信的最高层,又是面向网络通信的低三层和面向信息处理的最高三层之间的中间层。干货满满,赶快收藏学起来吧!
包含常见的递归分治算法,动态规划,贪心算法常见的算法,典型的算法配有代码.
运输层
概述
进程之间的通信
运输层向它上面的应用层提供通信服务
属于面向通信部分的最高层,用户功能的最底层
主机之间的通信
两个主机中的应用进程相互通信
端点不是主机而是主机的进程
网络层是主机到主机的
两个协议

用户数据报协议UDP
不需要建立连接
传输控制协议TCP
面向连接的服务
复用
应用层所有的应用进程都可以通过运输层再传送到IP层
分用
运输层从IP层收到数据后必须交付给指明的应用进程
协议端口号/端口
虽然通信终点是应用进程,但是进程是动态的所以使用端口
报文送到端口就行剩余的交给TCP
是抽象的软件端口
只有本地意义,与其他计算机无关
端口分类
服务器端
熟知端口/系统端口
0--1023
FTP
21
TELNET
23
SMTP
25
DNS
53
TFTP
69
HTTP
80
SNMP
161
SNMP(trap)
162
登记端口
1024--49151
需要在IANA按照手续登记
客户端
短暂端口
49152-65535
由客户端自行分配,客户端进程短暂使用
UDP
特点
无连接
尽最大努力交付
不保证可靠交付,不需要维护复杂的连接状态
面向报文
UDP对应用层交下来的报文添加首部之后就交给IP层,不合并不拆分,保留报文边界
没有拥塞控制
网络拥塞不会导致源主机的发送速率降低
源主机的发送速度可以是恒定的----IP电话视频会议
支持1对1,一对多,多对1,多对多
首部开销小
8个字节
首部格式
源端口
需要对方回信的时候选用,不需要的时候可以置为0
目的端口
长度
min=8(只有首部)
检验和
首部长度
每个字段都是2个字节
TCP
特点
面向连接的运输层协议
只能两个端点1对1
可靠交付
数据无差错,不丢失,不重复,不失序
全双工通信
面向字节流
TCP将数据看成无结构的字节流
端点
套接字/插口
IP地址+端口号
可靠传输的工作原理
理想的环境
信道不产生差错
不管发送方的速度多快,接收方总能来的及处理收到的数据
停止等待协议
无差错
一个分组发送完就暂停收到确认回复后继续发送
有差错/自动重传请求ARQ
B检测到差错就直接丢弃
超时重传
B在经历过一段时间后还未收到确认,就认为分组丢失,重新发送
一个分组一个超时计时器
注意
A在发送一个分组后应该保留这个分组的副本只有收到确认后才清除这个副本
分组和确认分组都必须进行编号
超时计时器设置的重传时间应该比数据在分组传输的平均往返时间更长一些
由于会产生时延且为不确定因素
确认丢失和确认迟到
如果分组正常送到,但是确认分组丢失,A仍然在超时后重传
这个时候B如果又收到了那个分组,丢弃这个分组并向A发送确认
信道利用率
低

需要等待上一个分组的成功信息
连续ARQ协议
使用发送窗口
发送方每收到一个确认就向前移动一个
接收方一般使用累计确认的方式,接受分组后,对按序到达的最后一个分组发送确认
优点
容易实现,即使确认丢失也不用重传
缺点
不能向发送方反映出接收方已经正确收到的所有分组的信息
比如发送五个分组,第三个没有收到,对于345的状态则是未知的,要重新发送三个分组哪怕只有一个没收到....
容易受线路质量的影响
首部
TCP的所有功能都体现在首部中
格式

源端口
目的端口
2个字节
序号
4字节
本报文段所发送的数据的第一个字节的序号
上一个序号是301长度为100,那么这次的就是401
确认号
4字节
期望收到对方下一个报文段的第一个数据字节的序号
数据偏移
4位
TCP报文段的数据起始位置距离TCP报文段的起始位置有多远
其实就是首部长度
保留
6位
目前为0
控制位
分类
紧急URG
紧急指针有效
这个报文含有紧急数据,应该尽快传送 优先级很高,不再按照原来的排队方式了插入到最前面
确认ACK
为1的时候确认号才有效
在连接建立后所有传送的数据报都必须把ACK置为1
推送PSH
加快传输,希望对方能快速回应
不再等待缓存区填满,立即写出和读入
复位RST
出现严重差错必须释放连接并重新建立
有时还用于拒绝会话报文或者建立连接
同步SYN
连接建立时用来同步序号,下文会具体解释
终止FIN
用来释放连接
长度
各占1位---1有效0无效
窗口
2字节
指的是发送本报文的一方的接受窗口---不是自己的发送窗口
目的
告诉对方,从本报文段的确认号算起,接收方目前允许对方发送的数据量
窗口值作为接收方让发送方设置其发送窗口的依据。
值是经常发生变化的,这与接收方有关
紧急指针
2字节
仅在URG=1时才有效
表示本报文段中的紧急数据的字节数
紧急数据结束后就是普通数据
选项
长度可变
MAX=40字节
为0的时候TCP的首部长度是20
内容
最大报文长度MSS
过小
每次发送数据的长度远远小于首部长度--使运输层和数据链路层开销增大网络利用率降低
过大
每次发送数据远远大于运输层的最大分组长度---需要分片(网络层开销增大)
尽可能大但是尽量不使IP层产生分片
窗口扩大
3字节
见下文
移位值S
1字节
MAX=14
新的窗口值等于TCP首部中的窗口位数从16增大到(16 + S)。移位值允许使用的最大值是14,相当于窗口最大值增大到2(16 + 14) - 1 = 230 -1
时间戳
10字节
时间戳值
4字节
时间戳回送回答字段
4字节
功能
计算往返时间RTT
处理TCP序号超过2^32的情况
防止序号绕回
选择确认
见下文
长度
20字节加选项(0--40)
滑动窗口
单位:字节
发送窗口确定
根据B发过来的确认报文得知窗口值(20),确认号30
31之前的都已经收到
表明A的发送窗口大小是20,起始值是31
在A收到B的确认之前A可以连续把窗口内的数据发送出去
确认之前的数据都要暂时保留,以便超时重传使用
状态
不变
没有收到确认
收到确认但是恰好通知窗口变小使得发送窗口不变
前移
收到新的确认
窗口不允许向后
发送方的分组构成
已发送已接收
已发送未确认
允许发送还未发送
位于滑动窗口内
不允许发送
与缓存的关系
缓存空间和序号空间是有限的
实际上缓存或者窗口中的字节数是非常之大的
发送方的缓存
发送应用程序传给TCP准备发送的数据
TCP已经发送但是还未确认的数据
接收方缓存
按序到达的,但是未被接收应用程序读取的数据
未按序到达的数据
注意
A的窗口大小由B决定
A的窗口不一定和B的一样大
由于时延造成滞后
未按序到达的数据不应丢弃临时存储下来放在接收窗口中,按序交付给上层
具有累计确认的功能
接收方可以将确认信息放在自己需要发送的数据上捎带去
接收方不能过分的推迟发送确认
捎带不会经常发生
超时重传的时间(ROT)选择
TCP中最复杂的问题
自适应算法/Karn算法
记录发送时间和确认时间将这个时间认为是RTT
平滑往返时间TCP保留RTT的加权平均往返时间RTTs

RTO应该略微大于加权平均往返时间
RTTD是偏差的加权平均值

问题:如何判断当前的确认报文是对发送报文还是重传报文进行确认
如果重传就不再参与计算RTTs
问题:上述问题解决方案带来新问题:时延突然增加,超时重传的时间将得不到更新
报文每重传一次就将RTO增大一些
选择确认SACK
只传送缺少的数据不重新传已经到达接收方的数据
原理
将未收到的部分的序号发给发送主机
发送主机只重发接收方没有接收到的数据
流量控制
让发送方的速率不要太快,让接收方能来得及接收
当窗口值是0的时候表示不再让发送主机发送数据
当窗口值为0的时候TCP为每一个连接设置一个持续计时器,时间到期的时候就发送一个0窗口探测报文(只携带1字节数据),对方将给出现在的窗口值
控制传输效率
三种机制
TCP维持一个变量,等于最大报文段长度MSS。当数据达到MSS字节时,就组装成一个TCP报文发送出去
由发送方的应用进程指明要求发送报文段
TCP支持的推送操作
计时器的期限到了就将已有的缓存装入报文段发送出去(小于MSS)
Nagle算法
内容
若发送应用程序要将数据逐个字节的送到TCP的发送缓存,则发送方就将第一个数据字节先发送出去,
后面的数据先缓存起来
第一个数据字符收到确认后将缓存中的所有数据组装成一个报文段发送出去
继续缓存随后的数据
只有收到上一个报文的确认时才继续发送
使用场景
网络速率较慢,数据到达速度较快(RTT短)的网络
问题
糊涂窗口综合征
接收方缓存已经满了,数据来临的时候应用进程读取一个字节,并返回确认--窗口值是1,发送方立即发送一个字节数据,这样反复下去
解决
让接收方等待一段时间
等到就收缓存已经有一半空闲的空间
满足一个即可
避免出现大量小数据报文
拥塞控制
拥塞
一段时间内对网络中的某一资源需求超过了该资源能提供的可用部分
网络性能将变坏
产生因素
某个结点的缓存太小
大量数据因为无法缓存而丢弃
处理机的处理速度太慢
目的
防止过多的数据注入网络,这样可以使网络中的路由器或者链路不过载
前提
网络能承受现有的网络负荷
是一个全局性的过程,设计所有主机所有路由器等
概念区分
拥塞控制是全局问题,流量控制是点到点通讯量的控制(端到端)
作用

具体方法
分类
开环控制
考虑很周到,提前设置好一旦运行就不能再修改了
闭环控制
基于反馈环路
检测网络系统以便检测到拥塞在何处何时发生
将拥塞发生的信息传送到可采取行动的地方
调整网络系统的运行来解决出现的问题
几种常见的方法
慢开始和拥塞控制
拥塞控制
发送方维持一个叫做拥塞窗口的状态变量
大小取决于网络的拥塞程度
发送方让自己的发送窗口等于拥塞窗口(发送方主动的)
接收方调整窗口的值不大于发送方的拥塞窗口
慢开始
开始发送数据的时候由小到大逐渐增大发送窗口
即增大拥塞窗口
每个传输轮次拥塞窗口加倍
拥塞避免
拥塞窗口缓慢增大,每次加一而不是加倍
综合使用
初始化的时候拥塞窗口cwnd设置为1门限值(ssthresh)为16
执行慢开始算法
直到cwnd==ssthresh后改用拥塞避免
执行拥塞避免
使窗口值线性增长
发生拥塞,ssthresh也可能发生改变
执行拥塞避免
乘法减小,加法增大
出现拥塞时ssthresh减半
快重传和快恢复
快重传
要求接收方每收到一个失序的报文段就立即发出重复确认
如:重复确认M2让发送方知道M3还没到
快恢复
当发送方收到3个重复确认的时候,执行乘法减小算法,门限值ssthresh减半
接下来为了预防网络发生拥塞,不执行慢开始
发送方认为网络很有可能没有发生拥塞
因为有好几个报文已经成功送达了
这时慢开始的cwnd值设置为ssthresh的一半再进行加法增大
注意:实际上发送窗口的值要大于接收窗口
随机早期检测RED
尾部丢弃策略
内容
路由器的队列是按照先进先出FIFO的规则处理来的分组
当分组已经满的时候再到达的分组都将丢弃
影响
由于丢失的分组是一连串的所以发送方出现超时重传,使TCP进入拥塞控制的慢开始状态
有可能使全局许多TCP都进入慢开始造成全局同步
效率变得极低
RED
使路由器的队列维持两个参数,即队列长度的最小门限THmin和最大门限THmax。 每到一个分组就计算平均长度Lan
算法内容
如果Lan小于THmin,就把新到来的分组放入队列进行排队
Lan大于THmax,就把新到来的分组丢弃
lan位于THmax和THmin之间,就按照一定的概率随机丢弃分组
目的
提前检测出来拥塞,让一部分TCP进行拥塞控制,避免全局性的拥塞控制
连接管理
存在的问题
要使每一方能够知道对方的存在
允许双方协商一些参数
能够对运输实体资源进行分配
运输连接的三个阶段
连接建立
三次握手
A是主动打开连接B被动打开
过程
B的TCP服务器进程先创建传输模块TCB,准备接收客户进程的连接请求
A的TCP也是先创建TCB,然后向B发送连接请求报文段进入SYN-SENT状态
首部的同步位SYN=1,初始序号seq=x
TCP规定SYN=1时不带任何数据但是要消耗一个序号
B收到报文后,如果同意建立连接,向A发送确认同时进入SYN-RCVD状态
SYN=1,ACK=1,确认号ack=x+1同时自己为自己选择一个序号seq=y
A收到B的确认后向B发送确认A进入ESTABLISHED(已经建立连接)状态
ACK=1,确认号ack=y+1,seq=x+1
可以携带数据,如果不带数据就不消耗序号即下一个还是x+1
第二次确认的原因
为了防止已经失效的报文突然传送给B
已经失效的报文
A的第一个请求没有丢失只是延迟了,当B发送确认报文后又到达了,B会误认为A又请求建立一个新连接,B就再次确认,A如果不理睬B的确认报文那么这个多出来的连接将一直存在消耗资源
数据传送
连接释放/四次握手
过程
A的应用进程先向TCP发出连接释放报文段,并停止发送数据,主动关闭TCP连接
FIN=1,seq=u,终止报文消耗一个序号(不一定带数据)
当前处于半关闭状态即A已经停止发送,但是还能接收
A收到B的确认后进入终止等待2状态
B如果没有什么发送的了就向A发送连接释放报文
FIN=1
B进入最后确认状态,等待A的确认
A收到B的释放请求后必须发出确认进入时间等待状态
ACK=1,ack=w+1,seq=u+1
经过时间等待计时器设置的2MSL后A才关闭
为什么A要等到2MSL后才释放呢?
保证A最后的ACK成功送达
如果期间再次收到B的FIN+ACK报文,A就再次发送一次确认,接着再次等待2MSL
保证所有失效的请求报文段完全失效,使下一个TCP不能收到旧的TCP请求报文
保活计时器
如果双方一个出现故障没有正确退出,将在每个保活计时器周期内(两个小时)确认一下对方的在线情况,如果一连10个探测报文段都没有响应就关闭这个连接
TCP的有限自动机