标签：UDP 报文 TCP 计网 拥塞 Chap3 自顶向下 接字 连接

计网自顶向下 学习笔记Chap3

“Stay hungry Stay young”

第三章 运输层

3.1 概述和运输层服务

运输层协议是运行在端系统上的协议，实现了逻辑通信，一个应用程序可以使用一组不同的运输层服务，如TCP和UDP

3.1.1 运输层和网络层的关系

网络层提供的是主机之间的逻辑通信，运输层为运输在不同主机之上的进程提供了逻辑通信，运输层协议常常受制于网络层协议的时延和带宽保证。但某些服务如果底层网络协议不能提供，运输层协议也能提供。

3.1.2 因特网运输层概述

UDP（用户数据报协议）：提供不可靠、无连接的服务

TCP（传输控制协议）：为应用程序提供了一种可靠的，面向连接的服务

网络层的IP协议控制端系统间的交付服务，是不可靠的，如果将它扩展到运行在端系统上的两个进程的交付服务，就称之为运输层的多路复用和多路分解，然而UDP也是一种不可靠的协议。TCP提供可靠数据传输和拥塞控制

3.2 多路复用与多路分解

多路分解：将运输层报文段的数据交付到正确的套接字

多路复用：将报文段收集并封装上首部，传递到网络层

运输层多路复用的要求：1.套接字有唯一标识2.每个报文段有特殊字段来指示该报文端所要交付到的套接字，这些特殊字段包括源端口号字段和目的端口号字段，端口号是一个16比特的数，大小在0-65535之间，0-1023的端口号称为周知端口号，是受限制的，保留给HTTP和FTP之类的应用层协议来使用。

1.无连接（UDP）的多路复用与多路分解

clientSocket=socket(AF_INET,SOCK_DGRAM)

这种方式创建了一个UDP套接字，运输层为该套接字分配了一个端口号，这个端口号是其他应用程序未使用的，另外，在python中，可以为一个套接字关联一个特定的套接字，例如以下代码

clientSocket.bind(('',19157))
#将用户端的套接字和19157端口互联

通常应用程序的客户端采用自动分配的端口号，服务器端采用特定的自主分配的端口号

一个UDP套接字是由一个包含目的IP地址和目的端口号的二元组全面标识的。源端口号用于返回地址

2.面向连接（TCP）的多路复用与多路分解

TCP的套接字由四元组组成，<源ip地址、源端口号、目的IP地址、目的端口号>

TCP的应用程序有一个欢迎套接字，TCP客户用下图的代码创建一个套接字并发送一个连接来请求报文段

#客户端创建套接字
clientSocket=socket(AF_INET,SOCK_STREAM)
#客户端套接字与服务器建立TCP连接
clinetSocket.connect((serverName,12000))

如果运行服务器的操作系统接收到具有目的端口12000的入连接请求报文段后，就定位该服务器进程，发现该进程在接受连接时，服务器进程创建新的套接字

connectionSocket,addr=serverSocket.accept()

另外，，运输层还注意到了连接请求报文段的4元组中的4个值，所以以后的报文段，如果这4个字匹配，就会被分解到这个套接字，这也表示TCP连接建立完成了。

服务器主机可以支持很多并行的套接字。

3.Web服务器与TCP

连接套接字与进程之间并非一一对应的关系，高性能的Web服务器通常只使用一个进程，然后有多个新套接字的子线程，在应用层，曾经讲过两种HTTP协议：

• 持续连接的HTTP协议靠一个套接字来交换
• 非持续连接的每个请求/相应报文都将创建一个新的套接字，并在随后关闭，这将导致服务器的性能受到影响

3.3 无连接传输：UDP

适用UDP协议的应用有以下特点：

1. 关于发送什么数据以及何时发送的应用层控制更为精细
2. 无须连接建立，TCP连接要进行三次握手，UDP不需要进行准备，所以DNS运行在UDP之上而HTTP运行在TCP上
3. 无连接状态
4. 分组首部开销小，UDP只需8字节，而TCP需要20字节

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SqVSlpT1-1621245207583)(第三章 运输层.assets/image-20210425210949218.png)]

ps：Google的QUIC协议已经在UDP中实现了可靠传输

3.3.1 UDP报文段结构

首部由四部分组成：

1. 源端口号
2. 目的端口号
3. 长度
4. 检验和

UDP首部有4个字段，每个字段由两个字节组成

3.3.2 UDP检验和

UDP提供了差错检验功能，因为不能保证源和目的链路都提供差错检验，但这个差错检验不提供改正的能力

具体实现为，对报文段中所有的16比特字的和进行反码运算，任何溢出都要回卷（求反码），得到的结果放在检验和字段。

这种被称颂的原则叫端到端原则。

3.4 可靠传输原理

本节中只考虑单向数据传输（半双工）的情况

3.4.1构造可靠数据传输协议

1. 经完全可靠的信道的可靠数据传输：rdt1.0，考虑底层信道是完全可靠的，发送方和接收方的有限状态机均只有一个状态
2. 经具有比特差错信道的可靠数据传输：rdt2.0，采用ARQ(自动重传请求)协议，它有差错检验、接收方反馈、重传三种功能，它的发送方的有限状态机有两个状态，一个状态等待上层的调用来发送数据，一个状态等待ACK或者NAK，如果收到ACK，则回到等待的状态，如果收到NAK，则再次发送数据，仍然在等待ACK或NAK的状态，仅当接受到ACK才脱离该状态，所以rdt2.0的等待协议也叫做停等协议。接收端同样只有一种状态，当分组到达时，回应ACK或者NAK，取决于受到的分组是否受损。问题是并不知道ACK或者NAK是否传输成功、

解决方法为，添加分组序号，对于rdt2.0的停等协议而言，只要1比特就够了，只需要知道当前是否在重传上一个分组，因此推出了rdt2.1,它的接收方和发送方的状态数都是接收方的两倍。而2.2则取消了NAK。

3.经具有比特差错的丢包信道的可靠数据传输：rdt3.0，此协议考虑了底层协议出现丢包的情况，主要解决了丢包的检测问题，经一段时间没有接收到数据，就认为丢包发生，然后进行重传，此协议也被称为比特交替协议

综上可以知道，检验和、序号、定时器、肯定和否定确认是数据传输协议的要点。

3.4.2 流水线可靠数据传输协议

rdt3.0是一个停等协议，对当下网络不适用，信道的利用率太低，因此，开发出了一种流水线协议，在分组的第一个比特未到达时，就发送第二个比特，类似于流水线的工作，它会带来以下变化：

• 必须增加序号范围，对各个比特编号
• 已发送却没有确认的分组需要缓存，接收方可能需要缓存哪些已经正确接收的分组
• 出现了GBN(回退N步)以及SR(选择重传)协议，下面介绍

3.4.3 回退N步

将分组进行分割，采用滑动窗口的思想，N为窗口长度，每发送一个，窗口就向前滑动

GBN发送方必须相应三种类型的事件，包括上层的调用（检测窗口是否已满，不满就往前滑动，满了就把数据交给上层），收到ACK,超时事件的相应

接受方的响应也非常简单：

3.4.3 选择重传

只重传超时未被确认的分组，比起GBN有很大进步，因为GBN需要一次性重传大量分组。

3.5 面向连接的运输：TCP

3.5.1 TCP连接

TCP提供全双工服务：如果一台主机上的进程A与另一台主机上的进程B存在一条TCP连接，那么应用层数据就可以在进程A和进程B之间双向流通，因此，TCP不支持多播。

3.5.2 TCP报文段的组成

首部的组成：

• 32比特的序号字段和32比特的确认号字段
• 16比特的接收窗口字段，用于流量控制
• 4比特的首部长度字段，用于指示首部的长度
• 可选可变长的选项字段，用于发送方和接收方协商或高速网络环境下用作窗口调节因子使用
• 6比特的标志字段
• 目的端口号、源端口号（UDP也有）
• 检验和字段（UDP也有）

序号和确认号

序号：首字节的字节流编号

确认号：希望获得下一个字节的序号，如果有一段没收到，那么确认号就有那个序号，这叫做累计确认

3.5.3可靠数据传输

• 超时间隔加倍：重传一次后，过期时间会设置加倍，呈指数型增长
• 快速重传：在超时重传前，通过冗余ACK来检测丢包

具体的操作为：

收到ACK后，一旦ACK的序号比期望序号大，则设置当前的期望序号为这个ACK的序号，然后等待回应，如果没有回应就启动定时器，如果有回应，冗余ACK数加一，冗余ACK数大于3时，重新发送具有序号Y的报文段

• 差错恢复机制：采用独特的选择确认*机制，可以认为是选择重传和GBN协议的结合

3.5.4 流量控制

IP提供的网络服务可能会有卡顿，因此TCP为主机提供了流量控制服务，让主机维护一个接受窗口，它用于给发送方一个指示：接收方还有多少可用的缓存空间

维护一个内存变量rwnd，它代表已经接受还没读入缓存的数据量的最大限额，要保证不能超过这个限额，就不会出现流量溢出的情况。

3.5.5 TCP连接管理

TCP连接建立的方式：

1. 客户端的TCP先向服务器端的TCP发送一个特殊的TCP报文段，不包含应用层数据，里面只有一个标志位比特（SYN），另外，客户还随机地选择一个初始序号
2. 当SYN报文段的数据报到达服务器主机时，服务器会从这个数据报中提取出TCP SYN报文段，为TCP连接分配缓存和变量，SYN比特被置为1，然后服务器发送一个SYNACK报文段
3. 收到SYNACK报文段后，客户也要为连接分配缓存和变量，客户主机向服务器发送另外一个报文段，这最后一个报文段对服务器允许连接的报文段进行了确认，SYN比特被置于0，连接已经建立

这就是三次握手，因为在连接的过程中发送了三个分组，

如果要关闭连接，则由客户端发送关闭连接命令，也就是发送一个特殊的TCP报文段，叫做FIN比特，然后同样通过三次握手结束连接。在这些不同的过程中，TCP连接的状态也不同。

握手的过程中，如果收到的是RST报文段而不是SYNACK报文段，那么就代表服务器已经收到了SYN报文段，但没有运行该TCP端口的应用程序。

3.6 拥塞控制原理

3.6.1拥塞原因及代价

拥塞原因：

1.接近理想化的情况中，分组的到达速率接近链路容量时，分组经历巨大的排队时延

2.发送方在遇到大时延时所进行的不必要重传会引起路由器利用其链路带宽来转发不必要的分组副本

3.一个分组沿一条路径被丢弃时，每个上游服务器用于转发该分组到丢弃该分组所用的传输容量最终被浪费掉了

3.6.2拥塞控制方法

1. 端到端拥塞控制：网络层不提供拥塞控制时，TCP通过报文段的丢失判断产生了拥塞现象（通过超时或3次冗余确认得知）。
2. 网络辅助的拥塞控制：路由器显式地通知发送方路由器能在输出链路上支持的最大主机发送速率

3.7TCP拥塞控制

3.7.1 如何限制连接的发送流量

拥塞控制不同于流量控制，但原理类似，它同样有一个窗口称之为拥塞窗口cwnd，一个发送方中未被确认的数据量不会超过cwnd和rwnd中的最小值。rwnd过大时，可以忽略rwnd的影响

3.7.2 发送方如何感知它与目的地的路径上出现了拥塞

当出现过度的拥塞时，路由器的缓存会溢出，引起数据报被丢弃，丢弃的数据报被丢弃，这会导致丢包事件被触发（超时或者收到3个冗余ACK）。

如果没有出现过度的拥塞，发送速率越大，拥塞窗口增大越迅速。

TCP如何基于本地信息设置发送速率？

1. 一旦发生丢包的情况，降低TCP发送方的速率
2. 对未确认的报文段确认到达时，发送方的速率增加
3. 带宽检测：给定ACK指示源到目的地路径无阻塞，丢包事件显示阻塞，为了响应ACK会增加速率，但如果出现丢包就减少速率

TCP拥塞控制算法：包括慢启动、拥塞避免、快速恢复三个部分

1. 慢启动：TCP连接刚开始时，一次就传递较小的MSS,这使得初始的发送速率MSS/RTT较小，随着确认的每一次增加，传输的报文段中MSS就增加，第二次翻倍，呈指数增长

   何时结束指数增长？

   如果存在超时丢包事件，将cwnd设置为1并重新开始慢启动过程，并将第二个状态变量的值设置为ssthresh(慢启动阈值)；直接与ssthresh的值相关联，当检测到拥塞时，将ssthresh的值设置为cwnd的一半，当cwnd等于ssthresh时，结束慢启动，进入拥塞避免模式，进入拥塞避免模式后，TCP将更为谨慎地增加cwnd；最后一种结束慢启动的方式是检测到三个冗余ACK，就执行快速启动

2. 拥塞避免：进入拥塞避免状态以后，每个RTT将cwnd的值增加一个MSS，为了避免线性增长，出现超时时，重新回到类似于慢启动的初始阶段，cwnd设置为一个MSS，ssthresh的值更新为cwnd的值的一半。此时发生丢包事件后反应不那么剧烈，一旦此时发生丢包，则将ssthresh的值记录为cwnd的一半并进入快速恢复状态。

3. 快速恢复：在快速恢复阶段，每个引起TCP进入快速恢复阶段的缺失报文段都将引起冗余ACK的增加，每次增加，cwnd的值增加一个MSS。对丢失报文段的ACK到达以后，降低cwnd进入拥塞避免模式。如果发生超时事件，则执行在慢启动和拥塞避免状态中相同的动作（cwnd设置为1个MSS，ssthresh设置为一半），然后进入慢启动状态

总结：忽略慢启动阶段，一般cwnd是线性增加一个MSS，等出现三个ACK时cwnd减半
一 条 连 接 的 平 均 吞 吐 量 = 0.75 ∗ W / R T T 一条连接的平均吞吐量={0.75*W}/RTT 一条连接的平均吞吐量=0.75∗W/RTT
这是一个高度理想化的TCP稳态动态性模型。

3.7.3 公平性

每条连接都获得相同份额的链路带宽，则认为是公平的

1.公平性与UDP

UDP没有拥塞控制，也不会调节流量，所以TCP应用可能会压制TCP应用

2.公平性和并行TCP连接

当一个应用使用多条并行连接时，它占用了一条拥塞链路中较大比例的带宽，
动状态**

总结：忽略慢启动阶段，一般cwnd是线性增加一个MSS，等出现三个ACK时cwnd减半
一 条 连 接 的 平 均 吞 吐 量 = 0.75 ∗ W / R T T 一条连接的平均吞吐量={0.75*W}/RTT 一条连接的平均吞吐量=0.75∗W/RTT
这是一个高度理想化的TCP稳态动态性模型。

3.7.3 公平性

每条连接都获得相同份额的链路带宽，则认为是公平的

1.公平性与UDP

UDP没有拥塞控制，也不会调节流量，所以TCP应用可能会压制TCP应用

2.公平性和并行TCP连接

当一个应用使用多条并行连接时，它占用了一条拥塞链路中较大比例的带宽，

标签：UDP,报文,TCP,计网,拥塞,Chap3,自顶向下,接字,连接
来源： https://blog.csdn.net/weixin_45717055/article/details/116942095

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。