运输层详解 绝地灬酷狼 2023-06-06 12:06 2阅读 0赞 ## 一、概述 ## **运输层: 主机到主机数据传输,负责从应用层接收消息,并传输应用层的message,到达目的后将消息上交应用。** ![在这里插入图片描述][20191011160651301.png] **在运行不同主机上应用进程之间提供逻辑通信** 运输协议运行在端系统中 发送方:将应用报文( messages )划分为报文段(segments),传向网络层 接收方:将段重新装配为报文,传向应用层 应用程序可供使用的运输协议不止一个 因特网:TCP和UDP ## 二、多路复用和多路分解 ## 一个进程有一个或多个**套接字**(socket),它相当于从网络向进程传递数据和从进程向网络传递数据的门户。 #### 1、定义 #### **多路分解**:将运输层报文段中的数据交付到正确的套接字的工作。 **多路复用**:在源主机从不同套接字种收集数据块,并为每个数据块封装上首部信息从而生成报文段,然后将报文段传递到网络层。 ![在这里插入图片描述][20191011161736362.png] #### 2、无连接的多路复用与多路复用 #### 2.1、UDP套接字由二元组全面标识 : 目的地IP地址 目的地端口号 2.2、当主机接收UDP段时: 在段中检查目的地端口号 将UDP段定向到具有该端口号的套接字 **具有不同源IP地址和/或源端口号的IP数据报(目的IP地址和端口号相同)定向到相同的套接字** ![在这里插入图片描述][20191011163354897.png] #### 3、面向连接的多路复用与多路复用 #### 3.1、TCP套接字由四元组(4-tuple)标识: 源IP地址 源端口号 目的IP地址 目的端口号 接收主机使用这四个值来将段定向到适当的套接字 3.2、服务器主机可能支持许多并行的TCP套接字: 每个套接字由其自己的四元组标识 3.3、Web服务器对每个连接的客户机具有不同的套接字 非持久HTTP将为每个请求具有不同的套接字 ![在这里插入图片描述][20191011163917505.png] ## 三、无连接运输:UDP ## #### 1、特点 #### **1.1、“尽力而为”服务** UDP段可能丢包 对应用程序交付失序 **1.2、无连接** 在UDP发送方和接收方之间无握手 每个UDP段的处理独立于其他段 #### 2、优点 #### * **无须建立连接**。不会引入建立连接的时延。 * **无连接状态**。不用维护连接状态,一般能支持更多的传送。 * **关于发送什么数据以及何时发送控制更加精细**。没有拥塞控制机制。 * **分组首部小**。每个 TCP 报文段都有20个字节的首部开销,而 UDP 只有8个字节的开销。 #### 3、UDP报文结构 #### **UDP 首部开销只有8个字节** ![在这里插入图片描述][20191011172102903.png] #### 4、UDP检验和 #### **UDP检验和提供了差错检测功能**。 发送方: 将段内容处理为16比特整数序列 检查和: 段内容的加法(反码和) 发送方将检查和放入UDP检查和字段 接收方: 计算接收的段的检查和 核对计算的检查和是否等于检查和字段的值: NO – 检测到差错 YES – 无差错检测到。 ![在这里插入图片描述][20191011172823987.png] 求和,回卷,求反后的结果就是检验和。 **接收方:传送后,把全部的3个16bit(原始两个16bit、检验和)加在一起。如果该分组中没有出现错误,和的结果应该是 `1111111111111111` 。如果有 0,说明分组传送出现了错误**。 ## 四、可靠数据传输原理 ## #### 1、构造可靠数据传输协议 #### **1.1、完全可靠信道的可靠数据传输:rdt1.0** 有限状态机(Finite-State Machine,FSM) **1.2、具有比特差错信道的可靠数据传输:rdt2.0** 肯定确认(positive acknowledgment,ACK) 否定确认(negative acknowledgment,NAK) (1)数据出错后处理方式 自动重传请求协议(Automatic Repeat request,ARQ) (2)rdt2.0新增加机制(与rdt1.0比较) * 检错 * 反馈:ACK——1, NAK——0 * 重传 停等协议(stop and wait) **1.3、处理ACK、NAK:rdt2.1** 加入**序号**,一个 bit 就够了,01判断是否重传(和前一个是否一样) **1.4、无NAK协议:rdt2.2** 与rdt2.1一样的功能,仅使用ACK 代替NAK,接收方对最后正确接收的分组发送ACK 接收方必须明确地包括被确认分组的序号 在发送方重复的ACK导致如同NAK相同的动作:重传当前分组 **1.5、具有比特差错的丢包信道的可靠数据传输:rdt3.0** ![在这里插入图片描述][20191011175444510.png] 冗余数据分组(duplication data packet) 倒计数定时器(countdown timer):判断是否超时 **比特交替协议(alternating-bit protocol)** ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjEwOTAxMg_size_16_color_FFFFFF_t_70]![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjEwOTAxMg_size_16_color_FFFFFF_t_70 1] #### 2、流水线可靠数据传输协议 #### **2.1、流水线——停等协议** ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjEwOTAxMg_size_16_color_FFFFFF_t_70 2] 解决流水线的差错恢复有两种基本方法:回退 N 步(Go-Back-N,GBN)、选择重传(Selective Repeat,SR) **回退 N 步** 和 **选择重传** 都是**滑动窗口协议**(sliding-window protocol) (1)发送方和接收方都具有一定容量的缓冲区(即窗口),允许发送站连续发送多个幀而不需要等待应答 (2)发送窗口就是发送端允许连续发送的帧的序号表,发送端可以不等待应答而连续发送的最大帧数称为发送窗口的尺寸 (3)接收窗口是接收方允许接收的帧的序号表,凡落在接收窗口内的帧,接收方都必须处理,落在接收窗口外的帧被丢弃。接收方每次允许接收的帧数称为接收窗口的尺寸 ![在这里插入图片描述][20191011184327743.png] **2.2、回退 N 步(GBN)** **发送窗口尺寸为N;接收窗口尺寸为1。** ![在这里插入图片描述][20191011184858141.png] 特征:累计确认 当接收到每一个连续的 ACK (例如 ACK 0,ACK 1)时,窗口向前滑动。 **简单来说:正确接收就发送 ACK 正确序号,数据丢失就把丢失的分组 ACK 序号返回,在同一个窗口内的所有数据都丢弃,都返回第一个出现问题的 ACK 序号,发送窗口起始位置滑动到丢数据位置(根据返回的 ACK),再以窗口大小重传丢失数据** (1)发送方: 发送窗口滑动的条件:收到1个新的确认分组 超时重传时,回退N个重传,通常重传多个分组 (2)接收方: 接收窗口滑动的条件:收到期望序号的分组 累计ACKs:s及以前的分组均正确接收 **对失序分组的处理:丢弃,重发(已按序接收分组的)ACK** (3)Go-Back-N不足: (效率明显高于停等协议)但仍有不必要重传的问题 ![在这里插入图片描述][20191011185410954.png] **2.3、选择重传(SR)** **发送窗口尺寸为N;接收窗口尺寸为N。** ![在这里插入图片描述][20191011190734383.png] 特征:独立ACK,重传单个分组 当接收到一个 ACK 时,窗口向前滑动。 **简单来说:接收方正确接收就发送 ACK 正确序号,数据丢失就把丢失的分组 ACK 序号返回,把同一个窗口后面的数据先缓存,返回正确 ACK,发送方发送丢失的分组,得到后面正确的 ACK 暂时不响应,返回丢失数据第二次正确的 ACK 才滑动窗口** 独立ACK: 对每个分组使用单独的确认 需N个定时器,若某个分组超时,则重传该分组 接收窗口为N,对非按序到达的分组进行缓存 (1)发送方: 发送窗口滑动的条件:收到最低位置分组的确认 超时重传时,仅重传超时的单个分组 (2)接收方: 接收窗口滑动的条件:收到最低位置的分组 (3)单独ACK: **对失序分组的处理:接收窗口内缓存,发对应ACK;接收窗口外丢弃** **2.4、可靠数据传输机制及用途总结** ![在这里插入图片描述][20191011192118688.png] ## 五、面向连接的运输:TCP ## #### 1、TCP 概述 #### ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjEwOTAxMg_size_16_color_FFFFFF_t_70 3] #### 2、TCP报文结构 #### ![在这里插入图片描述][20191012102950197.png] (1)**源端口号**:表示发送端端口号,字段长为16位。 (2)**目标端口号**:表示接收端口号,字段长为16位。 (3)**序列号(seq)**:为当前端成功发送的数据位数(由计算机生成的一个随机数作为其初始值,以后再将每次成功转发过去的字节数累加到初始值上表示数据的位置 )。 (4)**确认号**:为当前端成功接收的数据位数+1。(表示下一次应该收到的数据位置,发送端收到这个确认应答以后可以认为在这个序号以前的数据都已经被正常接收) (5)**首部长度**:该字段长度为4位,单位为4字节(32位)。TCP首部长度不包括选项的话,是20个字节。 (6)**保留位**:该字段主要是为了以后扩展时使用,其长度为6位。一般设置为0,即使收到的包在该字段不为0,此包也不会丢弃。 (7)**标志位**:字段长为 8 位,每一位从左到右分别为 CWR、ECE、URG、ACK、PSH、RST、SYN、FIN。这些控制标志也叫做控制位。当他们的对应位上值为 1 时,具体含义如下: CWR:CWR 标志与后面的 ECE 标志都用于 IP 首部的 ECN 字段,ECE 标志为 1 时,则通知对方已将拥塞窗口缩小; ECE:若其值为 1 则会通知对方,从对方到这边的网络有阻塞。在收到数据包的 IP 首部中 ECN 为 1 时将 TCP 首部中的 ECE 设为 1.; URG:该位设为 1,表示包中有需要紧急处理的数据,对于需要紧急处理的数据,与后面的紧急指针有关; ACK:该位设为 1,确认应答的字段有效,TCP规定除了最初建立连接时的 SYN 包之外该位必须设为 1; PSH:该位设为 1,表示需要将收到的数据立刻传给上层应用协议,若设为 0,则先将数据进行缓存; RST:该位设为 1,表示 TCP 连接出现异常必须强制断开连接; SYN:用于建立连接,该位设为 1,表示希望建立连接,并在其序列号的字段进行序列号初值设定; FIN:该位设为 1,表示今后不再有数据发送,希望断开连接。当通信结束希望断开连接时,通信双方的主机之间就可以相互交换 FIN 位置为 1 的 TCP 段。每个主机又对对方的 FIN 包进行确认应答之后可以断开连接。不过,主机收到 FIN 设置为 1 的 TCP 段之后不必马上回复一个 FIN 包,而是可以等到缓冲区中的所有数据都因为已成功发送而被自动删除之后再发 FIN 包; (8)**窗口大小**:接收缓冲区的大小,TCP不允许发送超过此处所示大小的数据。 (9)**校验和**:发送端填充,CRC校验,接收校验不通过,则认为数据有问题。和UDP的区别是,UDP校验的是数据本身,TCP校验的不仅包含TCP首部,而且包含TCP数据部分。 (10)**紧急指针**:只有在URG为1时有效,该字段为1表示本报文的段中的紧急数据的指针。 (11)**选项**:用于提高TCP的传输性能。需要根据首部长度进行控制,其最大长度为40字节。 (12)**数据**:真实有效数据 ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjEwOTAxMg_size_16_color_FFFFFF_t_70 4] #### 3、TCP建立连接:三次握手 #### ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjEwOTAxMg_size_16_color_FFFFFF_t_70 5] #### 4、TCP断开连接:四次挥手 #### ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjEwOTAxMg_size_16_color_FFFFFF_t_70 6] (1)**第一次挥手**: 首先,客户端发送一个FIN,用来关闭客户端到服务器的数据传送,然后等待服务器的确认。其中终止标志位FIN=1,序列号seq=x。 (2)**第二次挥手**: 服务器收到这个FIN,它发送一个ACK,确认ack为收到的序号+1。 (3)**第三次挥手**: 关闭服务器到客户端的连接,发送一个FIN给客户端。 (4)**第四次挥手**: 客户端收到FIN后,并发回一个ACK报文确认,并将确认序号seq设置为收到序号+1。首先进行关闭的一方将执行主动关闭,而另一方执行被动关闭。 ## 六、TCP拥塞控制 ## #### 1、原因 #### 拥塞(Congestion):当大量的分组进入网络,超出了网络的处理能力时,会引起网络局部或整体性能下降,这种现象称为拥塞。不加控制的拥塞甚至导致整个网络瘫痪。 **不同于流量控制!** 表现: 丢包 (路由器缓冲区溢出) 长时延 (路由器缓冲区中排队) ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjEwOTAxMg_size_16_color_FFFFFF_t_70 7] #### 2、拥塞控制方法 #### 间接控制:端到端拥塞控制 直接控制:网络辅助的拥塞控制 ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjEwOTAxMg_size_16_color_FFFFFF_t_70 8] #### 3、拥塞控制机制 #### **3.1、慢启动** 慢启动阶段是以 **指数增长** 一般在一半是停止慢启动。 慢启动阈值 ssthresh=cwnd/2 **3.2、AIMD(加增倍减算法)** 慢启动过后,增长阶段返回正确 ACK,每次增加一个报文。 只要产生一次丢包,传送报文数量减半。 ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjEwOTAxMg_size_16_color_FFFFFF_t_70 9] **3.3、超时事件后的保守机制** (1)基本思想 3个冗余ACK指示网络还具有某些传送报文段的能力 直接超时,则更为 “严重” (2)收到3个冗余确认后: CongWin减半 窗口再线性增加 (3)但是超时事件以后: CongWin值设置为1 MSS 窗口再指数增长 到达一个阈值 (Threshold) 后,再线性增长 ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjEwOTAxMg_size_16_color_FFFFFF_t_70 10]当CongWin < Threshold时,发送者处于慢启动阶段, CongWin指数增长 当CongWin > Threshold时,发送者处于拥塞避免阶段, CongWin线性增长 当出现3个冗余确认时, 阈值Threshold设置为CongWin/2,且CongWin设置为Threshold 当超时发生时,阈值Threshold设置为CongWin/2,并且CongWin设置为1 MSS [20191011160651301.png]: /images/20230601/f987d5b8c5064689b20b2cb676437889.png [20191011161736362.png]: /images/20230601/141ce9a2f57343249290200afe7d6247.png [20191011163354897.png]: /images/20230601/73dca37f301a48dd82f699740336ed5e.png [20191011163917505.png]: /images/20230601/94745e52ffb84453bd92db736795c3f7.png [20191011172102903.png]: /images/20230601/13a2862f3c954255b458f681d7b67bf3.png [20191011172823987.png]: /images/20230601/8a88c95fff364e2ca3f3d36dabd8560e.png [20191011175444510.png]: /images/20230601/5b435244937d4f2fbf6579aaaec78213.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjEwOTAxMg_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20191011180225721.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjEwOTAxMg==,size_16,color_FFFFFF,t_70 [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjEwOTAxMg_size_16_color_FFFFFF_t_70 1]: /images/20230601/3a303c4e427040eba123a41e33e4d427.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjEwOTAxMg_size_16_color_FFFFFF_t_70 2]: /images/20230601/e5a29d453e504b859e8bb1126fcf0f28.png [20191011184327743.png]: /images/20230601/5321fc249d6a4fb183bbab1ee2460248.png [20191011184858141.png]: /images/20230601/e3808c0a17584955956f9bde0fe24ab0.png [20191011185410954.png]: /images/20230601/6eb5940e22194455902c1a1ac21d15fa.png [20191011190734383.png]: /images/20230601/57b65c0e6f24485ca5a39cd277ab69db.png [20191011192118688.png]: /images/20230601/9ca7ca355a9d4994b703b4d7c9ca1722.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjEwOTAxMg_size_16_color_FFFFFF_t_70 3]: /images/20230601/193ea2bed65f4ee1bef6b87d713413d2.png [20191012102950197.png]: /images/20230601/da1ed3af872f40909991d814a00f140e.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjEwOTAxMg_size_16_color_FFFFFF_t_70 4]: /images/20230601/7d91e7f1427443bca0657ad211d521ae.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjEwOTAxMg_size_16_color_FFFFFF_t_70 5]: /images/20230601/281489fdbf7f4091a8ec24710b4a8a98.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjEwOTAxMg_size_16_color_FFFFFF_t_70 6]: /images/20230601/a77d145b81a746999fc376462258d69a.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjEwOTAxMg_size_16_color_FFFFFF_t_70 7]: /images/20230601/e0c556feb3ce4e9d8afad1e04ab7091c.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjEwOTAxMg_size_16_color_FFFFFF_t_70 8]: /images/20230601/622fa8721d684111930e1c969f091558.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjEwOTAxMg_size_16_color_FFFFFF_t_70 9]: /images/20230601/c807f3f89f5c4618a4d6c9fdf8424b86.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjEwOTAxMg_size_16_color_FFFFFF_t_70 10]: /images/20230601/72d16c244b3e4b959e95c67f9c73e0d1.png
相关 计算机网络-运输层 目录 一、运输层概述 二、运输层端口号、复用和分用的概念 (一)端口号 (二)发送方的复用和接收方的分用 (三)TCP/IP体系的应用层常用协议所使用的运输层熟知端口 爱被打了一巴掌/ 2023年10月13日 09:05/ 0 赞/ 87 阅读
相关 计算机网络——运输层 一、 运输层的两个主要协议 > (1) 用户数据报协议 UDP (User Datagram Protocol) > (2) 传输控制协议 TCP (Transmis 电玩女神/ 2023年10月06日 18:04/ 0 赞/ 62 阅读
相关 运输层详解 一、概述 运输层: 主机到主机数据传输,负责从应用层接收消息,并传输应用层的message,到达目的后将消息上交应用。 ![在这里插入图片描述][20191011160 绝地灬酷狼/ 2023年06月06日 12:06/ 0 赞/ 3 阅读
相关 浅谈运输层 一. 概述 首先看两个图吧 ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG 今天药忘吃喽~/ 2022年04月02日 12:26/ 0 赞/ 325 阅读
相关 网络层、运输层复习 文章目录 以太网帧(Frame)格式 ARP协议:用来识别主机ip地址和mac地址的映射 网络层数据包(Packet,也叫分 ゝ一纸荒年。/ 2021年11月23日 14:10/ 0 赞/ 548 阅读
相关 运输层 一、运输层的基本概念 从通信和信息处理的角度看,运输层向它上面的应用层提供通信服务,它属于面向通信部分的最高层,同时也是用户功能中的最低层。只有位于网络边缘部分的主机的协 绝地灬酷狼/ 2021年09月30日 20:34/ 0 赞/ 459 阅读
相关 运输层 运输层 一、运输层协议概述 1. 进程之间的通信 2. 运输层的两个主要协议 二、用户数据报协议 UDP 三、控制传输协议 T 迈不过友情╰/ 2021年08月20日 00:26/ 0 赞/ 611 阅读
还没有评论,来说两句吧...