计网笔记-计网总结-计网复习提纲- 第五章运输层

本文链接：https://blog.csdn.net/weixin_47071411/article/details/123624027

第五章运输层

重要概念

运输层为互相通信的应用进程提供逻辑通信
端口，套接字的意义
无连接UDP特点
面向连接TCP特点
在不可靠网络上实现可靠传输的工作原理，停止等待协议和ARQ协议
TCP的滑动窗口、流量控制、拥塞控制和连接管理

5.1 运输层协议概况

运输层向应用层提供服务，是面向通信最高层，用户功能最低层，主机的协议栈才有运输层，路由器转发分组只用到下三层功能。

为什么需要运输层
真正通信实体是主机中进程，IP层通信实体是两台主机，无法交付到主机中进程，运输层是应用进程之间的通信。

运输层重要功能，复用和分用

复用：发送方不同应用进程可以使用同一个运输层协议传输数据
分用：接收方的运输层在剥去报文首部后能把数据正确交付于目的应用进程

逻辑通信：从应用层来看，只要把应用层报文交付给下面运输层，运输层就可以把报文传送给对方运输层，就好像沿运输层水平方向直接传送数据，但其实并不是，逻辑通信-好像是这样通信，事实上并非真的这样通信。

网络层为主机之间提供逻辑通信，运输层为应用进程之间提供端到端的逻辑通信

运输层对收到报文进行差错检测，而IP数据报只检测首部是否出现差错，不检查数据部分

运输层两种协议，面向连接的TCP(可靠信道)和无连接的UDP(不可靠信道)

UDP User Datagram Protocol 用户数据报协议传输单元-UDP用户数据报

TCP Transmission Control Protocol 传输控制协议传输单元-TCP报文段

UDP传送数据前不需要建立连接，远地主机收到UDP报文后不需要给出然后确认，效率高，应用层协议DNS,RIP,DHCP使用到UDP P206

TCP提供面向连接服务，传送数据前得建立连接，结束得释放连接，所以他得增加开销：确认、流量控制、计时器、连接管理。应用层协议 HTTP、IGMP等用到它

端口的意义

运输层分用时得使一种标志来区分不同应用进程，不能使用进程标识符(一个整数)，因为不同操作系统进程标识符不一样，而且将进程作为通信终点也不好，因为进程创建销毁都是动态的，通信另一方根本无法识别进程，所以使用协议端口号，简称端口，只要把报文交付到主机端口，交付到进程由TCP或UDP完成

这种叫软件端口是一种应用层协议进程与运输实体层进行交互的地址，硬件端口是不同硬件设备进行交互的接口

TCP/IP层16位端口号，端口号只具备本地意义，标记各个应用层进程与运输层交互时的接口，不同计算机之间端口号没有关联

熟知端口号，服务器端使用的端口号，客户端使用的端口号

5.2 用户数据报协议 UDP

UDP只在IP数据报服务之上增加很少一点功能：复用、分用、差错检测

UDP特点

无连接
尽最大努力交付，即不保证可靠交付
UDP面向报文，应用层交付给它的报文，它直接封装好交付给IP层，不合并不拆分，拆不拆分由IP层决定
UDP没有拥塞控制，网络出现的拥塞不影响主机发送速率，实时应用(IP电话、实时视频会议)要求主机以恒定速率发送数据，且允许丢失一些数据，不允许时延太大，适合用UDP(UDP效率比TCP高)
UDP支持一对一、一对多、多对一、多对多的交互通信
UDP首部开销小，只有8字节，TCP20

接收方UDP发现端口号不正确，用网际控制报文协议ICMP发送端口不可达给发送方。

UDP首部格式

源端口，对方回信时用 2Byte
目的端口，终点交付报文时用 2Byte
长度。最小8，仅有首部 2Byte
检验和，检验传输过程数据报是否出错 2Byte

伪首部

5.3 传输控制协议TCP概述

TCP最主要特点

TCP是面向连接的运输层协议，得建立连接，释放连接
每条TCP通道只能有两个端点，即TCP连接是点对点的
提供可靠交付，通过TCP传输数据无差错不丢失不重复
TCP提供全双工通信，TCP连接的两端都设有发送缓存和接受缓存
面向字节流，接收方应用程序收到数据块数和发送方应用程序交付给TCP数据块数大小可能不一样。TCP与UDP发送报文采取方式完全不同，TCP发送的一个报文段包含多少字节取决于对方给出的窗口值和网络拥堵程度，不像UDP取决于应用进程一次把多长的报文段送到缓存，应用进程一次发送一字节到缓存，可以积累到字节多才发送，一次发送的报文太长可以划分短一点再发送出去

每一条TCP连接有两个端点，连接的端点叫套接字/插口

套接字 socket= (IP地址：端口号)

每个TCP连接唯一地被通信两端的两个端点(两个套接字)所确认

TCP连接 ::={socket1,socket2}={(IP1:port1),(IP2:port2)}

同一个IP地址可以用不同TCP连接，同一个端口号可以出现在多个不同TCP连接中

5.4 可靠传输的工作原理

理想的传输条件下不需要任何措施就可以实现可靠传输

传输信道不产生差错
不管发送方以多块速度发送信息，接收方总能及时处理数据

现实不具备以上条件，采取可靠传输协议，使用差错检测，当检测到出现差错让发送方重传，接受方来不及处理数据时，告知发送方降低发送数据的速度，这样不可靠的传输信道就可以实现可靠传输了。

停止等待协议：

每发送一个分组就停止发送，等待对方的确认，收到确认后再发送下一个分组
收到有差错的报文后，接受端直接丢弃，发送端没收到响应，超时重传(为每一个已发送分组设置超时计算器，计时器到期前收到回应，撤销，没收到回应，重传)
保留已发送分组副本，直到收到确认
分组和确认分组得编号
重传时间应该设置比分组传输平均往返时间长一点，重传时间太短太长都不好
确认丢失和确认迟到
效率很低

采用流水线传输

连续ARQ协议
滑动窗口协议

连续ARQ协议，维持发送窗口，连续把发送窗口的分组发出去，接收方采取累计确认方式，对按序收到最后一个分组发送确认，收到确认后发送方滑动窗口或重传。

5.5 TCP报文段首部格式

源端口和目的端口
序号seq：报文段第一个字节在排序上的位置
确认号ack：接收端期望收到下一个报文第一个字节的序号
数据偏移：TCP报文的数据部分距离首部位置，即首部的长度
保留:保留为今后使用
紧急URG：URG=1,告知系统尽快传送，直接改变排队顺序，将它排在缓存数据前面
确认ACK：ACK=1确认号字段有效，ACK=0确认号字段无效，连接建立后所有报文段中ACK置1
推送PSH：PSH=1，不等缓存填满直接发送出去
复位RST：RST=1，表明TCP连接出现严重错误，必须释放连接
同步SYN：连接建立时同步序号，SYN=1,ACK=0连接请求报文段，对方若同意建立连接，SYN=1,ACK=1
终止FIN：FIN=1释放连接
窗口：窗口值作为接收方让发送方设置其发送窗口的依据，之所以限制是因为接收端缓存空间有限
检验和：检验范围包括首部和数据，计算时要加上伪首部
紧急指针：当URG=1时，它指出报文段中紧急数据的字节数
选项：可使用可不使用，有最大报文段长度、窗口扩大等选项，不使用时TCP首部20个字节，使用时得加上一些填充字节使首部为4的倍数

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mxZSyCwC-1647788184555)(第五章运输层.assets/屏幕截图 2022-03-19 153049.png)]

5.6 TCP可靠传输的实现

以字节为单位的滑动窗口(P1、P2、P3)(B只能对按序收到数据的最高序号给出确认) P221

选择确认SACK，是选项字段，设法只传送缺少的数据，不重传已经正确到接收方的数据

5.7 TCP的流量控制

流量控制就是让发送方的发送速率不要太快，要让接收方来得及接受。

A向B发送数据，连接建立时，B告诉A我的接受窗口rwnd(receive window)=400,发送方的发送窗口不能超过接收方的接受窗口，窗口单位字节

B向A发送rwnd=0,B又有缓存空间了，发送rwnd=400,但报文丢失了，A一直等待B发送窗口非0通知，B一直等待A发送数据，造成死锁，解决措施，每个TCP连接设有持续计时器，连接的一方收到0窗口通知后，启动计时器，时间到期，发送零窗口探测报文段，对方收到后发送现在窗口值，仍然为0时，重置计时器，窗口不为0，打破死锁僵局

控制TCP发送出缓存中报文段的时机

第一种机制：缓存数据到达最大报文段长度
第二种机制：应用进程指明发送报文段，PUSH操作
第三种机制：计时器期限到了就发送

TCP广泛使用Nagle算法

应用进程将要发送数据逐字节发送到TCP缓存
发送方先把第一个字节发送出去，把后面字节缓存起来
收到第一个数据字符的确认后，再把所有缓存组装成一个报文段发送出去
继续缓存后面到达的数据
收到前一个报文段的确认才发送下一个报文段
到达的数据达到发送窗口的一半/报文段最大长度，立即发送一个报文

糊涂窗口综合征：接收端窗口只能容纳一字节，发送端每次只发送一字节，但是封装首部字节数大，资源浪费。解决方法：让接收方等待一段时间/等待到接收缓存有一半空间

5.8 TCP的拥塞控制

网络资源：带宽、交换节点缓存、处理机，当网络资源需求大于资源可用部分，网络性能变坏，产生拥塞。

当任意增加一些资源，可以解决网络拥塞错

假如网络拥塞，只增加交换点缓存空间，而处理机性能未改变，将使得交换点中排队的数据报更多，排队等待时间更长，造成更多重传，网络资源将造成更大浪费

拥塞控制是防止过多数据注入网络，使网络中的路由器和链路不过载

流量控制是指点对点通信量的控制

拥塞控制方案：

增大网络可用资源
减少用户对某些资源的需求

控制理论角度看待拥塞问题

开环控制：设计网络时就考虑好拥塞因素，系统运行中途不再改正
闭环控制：基于反馈环路采取措施，监控网络、传送拥塞信息到采取行动的地方、调整网络系统运行

拥塞控制方法四种算法

慢开始：开始发送数据时从小到大增大发送窗口即增大拥塞窗口数值，增大值为min(N,SMSS),N为上一次发送cwnd的值，即当窗口小于SMSS时，下一次加倍
拥塞避免：当到达慢开始门限ssthresh，让cwnd(拥塞窗口congestion window)每次按线性规律增长，比如说每次加1
快重传:让发送方尽早知道发生了个别报文段的丢失，接收方不要等到主机发送数据才捎带确认，而是立即发送确认，即使收到失序的报文段也要立即发送确认，让发送方立即重传，避免出现超时的情况，因为出现超时，就是发送方没有收到应当到的确认，它会猜想网络出现了拥塞，而不是传输时分组不小心丢失，然后调小拥塞窗口，开始慢开始，可能设置ssthresh=cwnd/2,cwnd=1
快恢复:当知道发送方有分组传输时丢失了，不是超时，不启动慢开始，启动快恢复算法，ssthresh=cwnd/2，cwnd=ssthresh

上方没有考虑接收方窗口(通知窗口)，一定要保证cwnd<rwnd

网络层的策略对TCP拥塞控制影响最大的是路由器的分组丢弃策略，路由器队列一般按照FIFO(First In First Out),当队列已经满了的时候，将丢弃再到达的所有分组，这样将导致很多TCP连接同时进入慢开始状态，也就是全局同步，使得全网通信量突然下降，网络恢复正常后，全网通信量又突然增加，所以采用AQM来避免全局同步

主动队列管理AQM(Active Queue Management)，主动就是不要等路由器的队列满了之后再丢弃分组，而是队列长度到达某个值之后按照某个概率p把新到达的分组丢弃，提前提醒发送方放慢发送速率

AQM有很多种实现方法，比如说随机早期检测RED(random early detection)

队列长度未达到最小门限，直接放入队列
当队列长度大于最小门限小于最大门限，以概率p丢弃新到达分组
当大于最大门限，把新到达的分组直接丢弃

5.9 TCP的运输连接管理

TCP运输连接三阶段

连接建立
数据传输
连接释放

三报文握手建立TCP连接

主机A是运行TCP客户程序，主机B运行TCP服务器程序，A主动打开连接，B被动打开连接
B的TCP服务器首先创建传输控制模块TCB(存储每一个连接的重要信息)，从CLOSED转向LISTEN(收听)状态
A也创建传输控制模块TCB，然后向B发送连接请求报文段(SYN同步报文段)，首部SYN=1,seq=x(选定初始序号，消耗一个序号),SYN报文段不能携带任何数据，A进入SYN-SENT(同步已发送阶段)
B收到请求报文后，如果同意建立连接，向A发送确认，SYN=1,ACK=1(确认ACK=1),seq=y(选择一个初始序列号),ack=x+1，同样消耗一个序号，B进入SYN-RVCD(同步收到状态)
A收到确认后，还要向B给出确认，报文ACK=1,seq=x+1,ack=y+1,ACK报文不携带数据的话不消耗序号，但seq=x已经被同步报文消耗了，此时连接已经建立A进入ESTABLISHED(连接已建立)状态，B收到报文也进入ESTABLISHED(established:adj 已确定的)状态

可以将B给A的SYN同步报文段拆成两个报文段，可以先发送确认报文段ACK=1,ack=x+1再发送同步报文段SYN=1,seq=y,就变成了四报文握手，效果是一样的

为什么A最后还是要发送确认报文，即为什么不能二次握手

防止已失效的连接请求报文突然又传送到B，产生错误
比如：假如二次握手，A第一次发送请求连接报文，那个报文段被滞留了，A以为请求连接报文段丢失了，所以重传，B收到请求后回送确认建立连接后，数据传输后释放连接，此时滞留的报文到达B，B以为A又要建立连接，然后对A回送确认，二次握手的话只要B发送确认连接就建立，而A没有发出连接请求，不理睬B的确认，不会向B发送数据，B因为连接已建立会一直等待A发来数据，浪费通信资源，但若是三报文，A根本不会对B的确认回送确认，B收不到确认就知道A根本没有建立连接

TCP的连接释放:四报文握手

A、B处于ESTALISHED状态，A向B发起连接释放报文，发送报文FIN=1,seq=u,A进入FIN-WAIT-1(终止等待1)状态，FIN报文即使不携带数据也得消耗一个序号
B收到报文段后发出确认，ACK=1,ack=u+1,seq=v,B进入CLOSE-WAIT(关闭等待状态)，从A到B的连接就释放了，TCP连接处于半关闭状态，B到A的连接并未关闭，还可进行数据传输
A收到来自B的确认，进入FIN-WAIT-2(终止等待2)状态，等待B发出的释放连接报文段
B没有向A发送的数据了，B发送释放连接报文段，FIN=1,ACK=1,seq=w,ack=u+1,B的序号不一定是v+1,因为过程中可能有数据传输，假定为w,B进入LAST-ACK(最后确认)状态，等待A的确认
A收到B的连接释放请求，需要发送确认，ACK=1,ack=w+1,seq=u+1,进入到TIME-WAIT(时间等待)状态，TCP连接还没释放掉，得等时间等待计时器设置的时间2MSL后，A才进入CLOSED状态
B收到确认报文就立即进入CLOSED状态，关闭连接，B比A结束TCP连接早
MSL Maximum Segment(部分; 份) Lifetime 最长报文段寿命，推荐MSL=2min

为什么A在TIME-WAIT要保持2MSL的等待时间

保证A发送的最后一个ACK报文段能够到达B，防止A发送的确认报文丢失后，B超时重传发送结束连接报文，A能够再收到结束报文段再发送确认，如果A立即关闭连接，就收不到B重发的结束报文，B无法自然结束
防止上一节出现“已失效的连接请求报文”出现在本连接中，经过2MSL后，本连接持续时间内产生的所有报文段在网络中消失，使下一个连接不会出现这种旧的连接请求报文

保活计时器：隔固定时间探测客户端是否有响应，是否出现故障。如果发现客户端没有响应，主动关闭连接