自顶向下方法学习笔记：运输层

各层关系

多路复用与多路分解

多路分解

多路复用

运输层报文段

UDP

优势

例子

报文结构

UDP校验和

可靠传输原理

停等协议

GBN

SR

TCP

三次握手

流

报文

捎带

往返时间估计和超时

主要事件

快速重传

选择确认

流量控制

连接管理

连接

断开

拥塞控制

拥塞窗口

拥塞监测

TCP拥塞算法

1. 各层关系

假设两家之间的多个孩子们需要通信，他们统一把每周的信件都给父母，然后父母每周去一次邮局互相发信件，在这个场景中，可以对应到：

信封上标识地址，收件人的信息：应用层报文。

所有的孩子：进程。

家庭：主机。

父母：运输层协议。

邮政服务：网络层协议。

2. 多路复用与多路分解

2.1. 多路分解

运输层将报文段中的数据交付到正确的Socket的工作。

2.2. 多路复用

在源主机上从不同Socket收集数据段，并为每个数据封装上首部信息，从而生成报文段，然后将报文段传递到网络层的工作。

2.3. 运输层报文段

源端口号	目的端口号
其它首部字段
应用层报文段

3. UDP

几乎不对IP增加其他东西，无连接

3.1. 优势

速度快。适合实时。

无连接建立，没有连接时延。

无连接状态。

分组首部开销小。TCP需20字节，UDP仅需8字节。

3.2. 例子

DNS

SNMP

RIP

NFS

3.3. 报文结构

源端口号	目的端口号
长度	检验和
应用数据

每行长度32bits（4bytes）

从此前我们构造DatagramPacket对象时必须包括长度这一参数易知除源端口号和目的端口号外，构造UDP包是需要长度的，校验和可以简单的检查一下报文段是否出了差错。

3.4. UDP校验和

发送方：对报文段中所有16bits字的和（求和时有溢出则回卷）进行反码运算，存储为校验和。

接收方：所有的16bits字求和，若为全1，则无差错。

想象下面这个情景，你要通过小红传话给小明，内容是三个数字，比如1，-2，3。你和小明经常这样传，话，而小红经常传错，于是你俩有这样一个协议，你在传话时候，把所有要传的数字求一下和并取负数，和要传的数一起告诉小红，小明收到后把所有数加起来是0，那么就说明传的东西没问题。于是你传1，-2，3，-（1-2+3）=-2，发给小红。小明收到后计算1-2+3-2=0，没问题，说明你要说的就是这几个数。这就是UDP传递的过程。

然而UDP对差错数据毫无修复能力，想一下，小明收到的数字式0，-2，3，-2，他相加之后发现结果是-1，于是他知道有数字传错了，可是不知道哪个数字错了。你只能丢弃这组数据。

4. 可靠传输原理

可靠传输协议的下层协议也许是不可靠的。比如TCP是在不可靠的IP端到端网络上实现的可靠协议传输协议。

4.1. 停等协议

rdt 1.0:无特殊行为。

rdt 2.0:差错检测，接收方反馈（ACK&NAK），重传。停等协议（发送方收到上一条反馈后才会继续发送）

为解决接收方无法分辨发送方是新数据还是重传的问题，数据分组中加了一个新字段，让发送方对其数据进行分组编号。

rdt 2.1:相对于rdt2.0，用序号标识分组。

rdt 2.2:不使用NAK，当发生错误时，重复上一个正确分组的ACK。

以上协议并没有实现对丢包的处理。为确定丢包，可以选择等待一个合适的时间（最坏时间用于估算）

rdt3.0:比特交替协议，每发送一个分组开启一个计时器，分组序号0/1交替，接收到一个分组的ACK后发送下一分组，或超时重发。

4.2. GBN

GBN协议（滑动窗口协议）中，流水线中包含以下部分：

已被确认：小于base序号。

未确认：从base序号到下一个序号。

未发送：从下一序号到base+N(回退的步数)-1序号。

不可用：保留N个序号。

发送时，先检查发送窗口是否已满，若未满则产生分组并发送，若已满，则阻塞一段时间。（现实中此处可能进行缓存，成一个生产者消费者模型）。接收到ACK则表明发送方已经正确接收到了序号n及n以前的所有分组。出现超时时，发送方重传所有已经发送但还未被确认的分组。

接收时，如果一个序号为n的分组正确接收且按序，则接收方发送一个ACK，其他情况下丢弃分组，并为最近接收到的分组重新发送ACK。接收方丢弃所有失序分组。收到的失序分组可能会被缓存。因此接收方仅需维护下一个分组的序号。

4.3. SR

SR（选择重传协议），发送方重传怀疑出错的分组，但不放弃其周围正确传输的分组。接收方对于任意顺序的正确分组都会予以ACK。失序的分组被缓存直到所有丢失分组都被收到。当接收方没有确认分组时，发送方不能向前滑动。为鉴别新发分组和重传分组，窗口大小不能超过序号空间的一半。

5. TCP

面向连接，全双工，点对点。

5.1. 三次握手

客户发送一个报文段，服务器回应一个特殊的TCP报文段响应，然后客户再用第三个报文段作为响应。前两个不包含应用层数据，第三个保文可以携带数据。

5.2. 流

TCP通过Socket传递数据流（Java的Socket编程中，可以通过getInputStream()和getOutputStream()方法来获取，写入数据）。TCP可从流中取出/放入的报文段的数据量受限于最大报文段长度。其典型值为1460字节。

5.3. 报文

源端口号	目的端口号
序号
确认号
首部长度	保留未用	URG	ACK	PSH	RST	SYN	FIN	接收窗口
因特网检验和	紧急数据指针
选项
数据

每行32bit，序号和确认号用于可靠传输。由于TCP选项字段原因，其首部长度可变，最典型为空选项，长度20字节。接收窗口指示接收方愿意接受的字节数量。RST,SYN,FIN用于建立和拆除连接。PSH指示接收方应立即将数据传输给上层，URG表示报文段存在紧急数据，紧急数据指针指向它们。

5.4. 捎带

对客户到服务器的数据的确认被装载在一个承载服务器到客户的数据的报文段中。

5.5. 往返时间估计和超时

估算时间=（1-a）旧估算时间+a新测量时间

重传时间间隔=估算时间+4*波动时间

5.6. 主要事件

从上层接收数据

定时器超时

收到ACK

5.7. 快速重传

由于接收方在接收到失序的报文时会返回最后一次接收正确的报文的+1序号。如果发送方连续三次收到同一个ACK值，则说明从该发送报文后的报文已丢失，因而重传。

5.8. 选择确认

不同于GBN和SR，TCP采用选择确认机制，发送方跳过已经被接收方选择性的确认的报文段，重传其他报文段。

5.9. 流量控制

匹配发送方和接收方的速度。客户端维护最后发送Byte和最后回应Byte以维护未被确认Byte，控制在服务端的空闲值以内。另外，当服务器空间为0后，客户端持续向服务器发送1Byte数据的报文段，直到服务端清空缓存并接收。

5.10. 连接管理

5.10.1. 连接

客户端发送一条不含数据但SYN位为1的SYN报文段并有一个随机的初始序号。

服务器提取出SYN报文段，为该TCP连接分配缓存和变量，向客户端发送不包含数据但SYN为1的有着顺延序号作为确认号，有自己初始序号的报文。

客户端也分配缓存和变量，并向服务器发送一个对服务器允许连接的确认（确认号为服务器序号的顺延），并将SYN置0，此时可以携带数据进行传输。

5.10.2. 断开

客户端发送一个首部标志位FIN为1的报文，服务器收到后发送一个确认报文，之后，服务器发送自己的FIN1报文，由客户端确认。

5.11. 拥塞控制

让发送方根据感知到的网络拥塞程度来限制其能向连接发送流量的速率。

5.11.1. 拥塞窗口

限制发送方未被确认的数据量。

5.11.2. 拥塞监测

丢包事件发生，降低发送速率。

确认到达意味成功交付，拥塞窗口扩大。

带宽试探检测。

5.11.3. TCP拥塞算法

慢启动：速度指数爬升。直到有丢包。

拥塞避免：减小窗口值后速度线性爬升。

快速恢复：