计算机网络阅读笔记（三）运输层

发表于 | 分类于 | 热度 ℃
| 共计 3,487 字 | 阅读时长≈ 13分钟

计算机网络第三章阅读笔记

概述

UDP：不可靠、无连接的服务

TCP：可靠、面向连接的服务

基本职责：将两个端系统间IP的交付服务拓展为运行在端系统上的两个进程之间的交付服务，称为运输层的多路复用(transport-layer multiplexing)与多路分解(demultiplexing)

多路复用与多路分解

多路分解

将运输层报文段中的数据交付到正确的套接字

实现：检查报文段中的端口号并定向到相应的套接字实现

多路复用

源主机从不同套接字中收集数据块，并为每个数据块封装上首部信息生成报文段，然后传递到网络层

无连接与面向连接的

UDP套接字通过二元组（目的IP地址，目的端口号）来标识

TCP套接字通过四元组（源IP地址，源端口号，目的IP地址，目的端口号）来标识

UDP(User Datagram Protocol)用户数据报协议

采用UDP的原因：

  1. 对发送速率有要求，并能容忍数据丢失
  2. UDP不会引入建立连接的时延，例如DNS
  3. UDP不维护连接状态
  4. 分组首部开销小

TCP：电子邮件、远程终端访问、web及文件传输

UDP：RIP路由选择表更新、SNMP简单网络管理协议 、DNS

可靠数据传输原理

可靠数据传输协议(reliable data transfer protocol) rdt1.0

直接调用udt_send函数实现

rdt2.0&自动重传请求协议(Automatic Repeat reQuest)

ARQ协议包括：

  1. 差错检测（与UDP中通过校验码检测差错类似，详见第5章）
  2. 接收方反馈（ACK与NAK）
  3. 重传

停等协议：发送方只有在确信接收方已经正确接收当前分组之后才会发送一块新数据。

rdt2.1&2.2

rdt2.0缺陷：没有考虑ACK或NAK分组受损的情况，从而发送方无法确定是发送新数据块还是重传

解决方案：为数据分组编号，当ACK或NAK分组受损时，发送方重传上一个分组，接收方也可根据编号知道发送方是否在重传前一个分组。

rdt3.0

rdt2.2缺陷：没有考虑丢包的问题

解决方案：（由发送方负责检测和恢复丢包工作）实现基于时间的重传机制，加入定时器

流水线技术(pipelining)

rdt3.0缺陷：是停等协议，性能低下

解决方案：流水线技术

影响：

  1. 必须增加序号范围
  2. 协议发送方和接收方必须缓存多个分组
  3. 具体取决于差错恢复的方式：回退N步(Go-Back-N, GBN)和选择重传(Selective repeat, SR)

回退N步(GBN)

发送方响应三类事件：

  1. 上层的调用：检查发送窗口是否已满
  2. 收到一个ACK：表示该序号及以前的所有分组已经被正确接收
  3. 超时事件：重传所有已发送但未被确认的分组

接收方：如果分组被正确接收并且按序，则为分组发送一个ACK，否则丢弃该分组，并为最近按序接受的分组重新发送ACK

选择重传(SR)

发送方动作：

  1. 上层的调用：检查发送窗口是否已满
  2. 收到一个ACK：如果分组序号在窗口内，则将该分组标记为已接收，如果其序号等于send_base，则窗口移动到具有最小序号的未被确认分组处
  3. 超时事件：重传超时的分组，每个分组都有自己的逻辑定时器

接收方动作：

  1. 分组序号在窗口内，分组被正确接收并回送对应的ACK
  2. 分组序号在窗口前，必须产生一个ACK
  3. 其他情况：忽略分组

SR接收方窗口太大困境：新分组or重传？

解决方案：窗口长度必须小于或等于序号空间大小的一半

可靠数据传输机制及其用途总结：p154

TCP(Transmission Control Protocol)传输控制协议

名词解释

  • MSS(maximum segment size)：TCP的最大报文段长度
  • MSL(maximum segment lifetime)：报文段能在网络中存在的最长时间。
  • TTL(time to live)：IP数据报在网络中能够经历的最大跳数，即能够经过的最大路由数。
  • RTT(round trip time)：指客户端到服务端往返所花时间。
  • MTU(maximum transmission unit)：最大传输单元，一个链路层帧能承载的最大数据量。
  • 序号(Sequence number)：报文段首字节字节流编号
  • 确认号(Acknowledgement number)：期望收到的下一字节的序号

估计往返时间与超时

仅为已发送但是未被确认的分组测量SampleRTT

RTT偏差：

超时间隔，初始值为1s：

快速重传

两次duplicated ACK肯定是乱序造成的

丢包肯定会造成三次duplicated ACK

快速重传：在报文段的定时器过期之前重传丢失的报文段

https://www.zhihu.com/question/21789252

流量控制

接收窗口：用于指示发送方接收方还有多少可用的缓存空间

三次握手

  1. TCP服务器进程先创建传输控制块TCB，时刻准备接受客户进程的连接请求，此时服务器就进入了LISTEN（监听）状态；
  2. TCP客户进程也是先创建传输控制块TCB，然后向服务器发出连接请求报文，这是报文首部中的同部位SYN=1，同时选择一个初始序列号 seq=x ，此时，TCP客户端进程进入了 SYN-SENT（同步已发送状态）状态。TCP规定，SYN报文段（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号。
  3. TCP服务器收到请求报文后，如果同意连接，则发出确认报文。确认报文中应该 ACK=1，SYN=1，确认号是ack=x+1，同时也要为自己初始化一个序列号 seq=y，此时，TCP服务器进程进入了SYN-RCVD（同步收到）状态。这个报文也不能携带数据，但是同样要消耗一个序号。
  4. TCP客户进程收到确认后，还要向服务器给出确认。确认报文的ACK=1，ack=y+1，自己的序列号seq=x+1，此时，TCP连接建立，客户端进入ESTABLISHED（已建立连接）状态。TCP规定，ACK报文段可以携带数据，但是如果不携带数据则不消耗序号。
  5. 当服务器收到客户端的确认后也进入ESTABLISHED状态，此后双方就可以开始通信了。

为什么TCP客户端最后还要发送一次确认呢？

一句话，主要防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误

四次挥手

  1. 客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
  2. 服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
  3. 客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
  4. 服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
  5. 客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
  6. 服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

为什么客户端最后还要等待2MSL？

MSL（Maximum Segment Lifetime），TCP允许不同的实现可以设置不同的MSL值。

第一，保证客户端发送的最后一个ACK报文能够到达服务器

https://blog.csdn.net/qzcsu/article/details/72861891

拥塞控制

原因与代价

  • 当分组的到达速率接近链路容量时，分组经历巨大的排队时延
  • 当数据报被丢失时发送方必须重传，因此引入了重传开销
  • 发送方在时延大时的不必要重传，浪费链路带宽
  • 当数据报被丢失时，丢失路由器的上游路由器做的工作都变成了无用功

控制方法

  • 端到端的拥塞控制（通过TCP报文段丢失确定）
  • 网络辅助的拥塞控制（路由器向发送方提供拥塞状态的反馈信息）（包括直接网络反馈（发送拥塞分组）和经接收方的网络反馈（标记拥塞））

TCP拥塞控制算法

指导性原则

  • 丢失的报文段意味着拥塞，应当降低发送方速率
  • 对先前未确认的报文段的确认到达时，应当增加发送方速率
  • 带宽检测：ACK到达时增加速率，丢包时减少速率

https://blog.csdn.net/goodluckwhh/article/details/10161753

慢启动

  • 在慢启动状态，cwnd的值以1个MSS开始，并且每当传输的报文段首次被确认就增加一个MSS
  • 如果存在一个由超时指示的丢包事件，发送方就将cwnd设置为1并重新开始慢启动，同时将ssthresh（慢启动阈值，cwnd=ssthresh时由慢启动进入拥塞避免模式）置为拥塞窗口值的一半。
  • 如果检测到3个冗余ACK，则进入快速恢复状态

拥塞避免

cwnd的值大约是上次拥塞时值的一半

  • 每个RTT将cwnd的值增加一个MSS（实现方式是：每受到一个新确认，就将cwnd增加一个MSS(MSS/cwnd)，这样一个RTT会接收到cwnd/MSS个确认）
  • 超时则进入慢启动状态
  • 如果检测到3个冗余ACK，则进入快速恢复状态

快速恢复

  • 收到另外的重复的ACK时，cwnd增加一个MSS。
  • 当收到确认新数据包的ACK时，把cwnd设置为ssthresh的值，转移到拥塞避免的状态
  • 超时则进入慢启动状态

回顾

加性增、乘性减(Additive-Increase, Multiplicative-Decrease, AIMD)

乘法减小：

是指不论在慢启动阶段还是拥塞避免阶段，只要出现一次超时（即出现一次网络拥塞），就把慢启动门限值ssthresh 设置为当前的拥塞窗口值乘以0.5。当网络频繁出现拥塞时，ssthresh 值就下降得很快，以大大减少注入到网络中的分组数。

加法增大：

是指执行拥塞避免算法后，在收到对所有报文段的确认后（即经过一个往返时间），就把拥塞窗口cwnd增加一个MSS 大小，使拥塞窗口缓慢增大，以防止网络过早出现拥塞

时延计算

首先要注意传输速率指的是将数据推向链路上的速率，而传播时延则对应为比特在链路上传播所需的时间，与物理媒体和链路长度有关，和RTT相对应

然后假设传播速率（发送速率）为R，一个分组长度为M，窗口大小为W=nM，发送数据大小为L

注意到R是会直接影响到拥塞窗口的大小的，因为如果R足够大，那么一个RTT时间内可以传输无数个分组，以致于接收方不停的丢包，那么就有一个最适合当前发送速率的拥塞窗口大小

假设当前处在拥塞避免阶段，每次成功接收到 个新ACK后，窗口大小都会增加M，并逐渐趋向于在一个RTT内，发送所有的 个分组，也就是 ，此时，倘若还没有出现丢包，也就说明接收方的接受速度足够快，并且没有拥塞，那么拥塞窗口继续增大，所有的RTT时间内都会有数据进行传输，传输进入稳定状态。特别的，一个RTT里并非刚好能够传整数个分组，而只是按照流水线的方式持续不断的传输以保证没有空闲。

在这种情况下，拥塞窗口大小有

计算上TCP握手所需要的时间RTT，总共时延为

0%