传输层

网络层提供了主机之间的逻辑通信，传输层在网络层的基础上为运行在不同主机上的进程之间提供了逻辑通信功能
传输层受限于网络层提供的服务(e.g.时延和带宽)的同时，也对网络层服务进行了加强(e.g.可靠的数据传输和加密)

传输层协议

互联网的主要传输层协议包括 TCP协议 和 UDP 协议

TCP：

• 字节流
• 可靠数据传输
• 多路复用、解复用
• 流量控制
• 拥塞控制
• 不能提供的服务：时间保证、最小吞吐保证和安全
• 面向连接：要求在客户端进程和服务器进程之间建立连接
  TCP 的安全性可通过 SSL 保证

UDP：

• 数据报
• 完成进程间通信
• 多路复用、解复用
• 少量差错检查
• 不做可靠性的工作，因此可提高实时性
• 没有拥塞控制和流量控制，因此应用能够按照设定的速度发送数据

TCP VS UDP

• 连接
  • TCP 是面向连接的传输层协议，传输数据前先要建立连接。
  • UDP 是不需要连接，即刻传输数据
• 服务对象
  • TCP 是一对一的两点服务，即一条连接只有两个端点
  • UDP 支持一对一、一对多、多对多的交互通信
• 可靠性
  • TCP 可靠交付数据，数据可以无差错、不丢失、不重复、按序到达
  • UDP 尽最大努力交付，不保证可靠交付数据
• 拥塞控制、流量控制
  • TCP 有拥塞控制和流量控制机制，保证数据传输的安全性
  • UDP 没有，即使网络非常拥堵了，也不会影响 UDP 的发送速度
• 首部开销
  • TCP 首部长度较长，在没有使用选项字段时固定为 20 bytes，使用了选项字段则不定长
  • UDP 首部固定为 8 bytes
• 传输方式
  • TCP 是流式传输，没有边界，但保证顺序和可靠
  • UDP 是一个包一个包的发送，有边界，但可能会丢包和乱序
• 是否分片
  • TCP 的数据如果大于 MSS，则会在传输层进行分片，目标主机收到后，也同样在传输层组装 TCP 数据包，如果中途丢失了一个分片，只需要传输丢失的这个分片
  • UDP 本身不对数据进行分片，数据如果大于 MTU，则会在网络层进行分片，目标主机收到后，在网络层组装完数据，接着再传给传输层

传输层数据交互

将主机间交付扩展到进程间交付被称为传输层的 多路复用 与 多路分解
多路复用：从多个 socket 接收来自多个进程的报文，根据套接字对应的 IP 地址和端口号等信息对报文段用头部信息加以封装 (该头部信息用于以后的解复用)
多路分解：TCP 或 UDP 实体采用头部信息，将报文段的数据部分交给正确的 socket，从而交给正确的进程

无连接(UDP)情况下报文仅根据目标主机ip和目标端口号确定交付的目标socket
面向连接情况下报文根据源主机 ip，源端口，目标主机 ip 和目标端口确定目标 socket，服务器能够在一个 TCP 端口上同时支持多个有着不同的源 ip 或源 port 的 TCP 套接字

一台运行Web服务器的主机接收的所有报文段的母单端口都是80，当今的高性能Web服务器通常只使用一个进程，为每个新的客户端连接创建一个具有新连接套接字的新线程

可靠数据传输

可靠数据传输RDT为上层实体提供的服务抽象是：数据可以通过一条可靠的信道进行传输
借助于可靠信道，传输数据比特不会损坏(由0变1，或者相反)或丢失，且所有数据按照发送顺序进行交付
RDT通过可靠数据传输协议实现，可靠数据传输协议的下层协议也许是不可靠的

RDT1.0 => 下层信道可靠
发送方：

1. 接收上层信息
2. 打包分组
3. 发送给下层信道
   接收方：
4. 接收下层信息
5. 解包分组
6. 传递给上层信道

比特差错修正

RDT2.0 => 通过自动重传请求(Automatic Repeat reQuest, ARQ)协议解决下层信道传输中出现的比特受损情况
发送方：

1. 接收上层信息
2. 打包分组
3. 发送给下层信道
4. 等待接收方反馈
   • ACK：继续发送下一分组
   • NAK：重传当前分组
     接收方：
5. 接收下层信息
6. 检验分组
   • 正确
     1. 返回肯定确认ACK(positive acknowledgment)
     2. 解包分组
     3. 传递给上层信道
   • 错误
     1. 返回否定确认NAK(negative acknowledgment)

RDT2.0中发送方确信接收方已正确接收当前分组后发送新分组，此种协议称为停等协议

RDT2.2 => 对分组编号，在返回 ACK 中包含编号以避免 ACK 在传输过程中受损带来的影响，同时可以用发送一个上次正确接收的分组的 ACK 来替代 NAK
发送方：

1. 接收上层信息
2. 打包分组0
3. 发送给下层信道
4. 等待接收方反馈
   • ACK0：继续发送下一分组
   • 乱码/ACK1：重传当前分组
     接收方：
5. 接收下层信息
6. 检验分组序号和分组正确性
   • 正确
     1. 返回ACK0
     2. 解包分组
     3. 传递给上层信道
   • 错误
     1. 返回 ACK1(上一分组的序号)

数据丢失修正

RDT3.0 => 发送方在一定时间未收到响应后重传分组以避免丢包带来的数据丢失
发送方：

1. 接收上层信息
2. 打包分组0
3. 发送给下层信道
4. 等待接收方反馈
   • ACK0：继续发送下一分组
   • 无响应/乱码/ACK1：重传当前分组
     接收方：
5. 接收下层信息
6. 检验分组序号和分组正确性
   • 正确
     1. 返回ACK0
     2. 解包分组
     3. 传递给上层信道
   • 错误
     1. 返回ACK1(上一分组的序号)

为了实现基于时间的重传机制，发送方每次发送一个分组（包括第一次分组和重传分组）时便启动一个定时器，定时器中断则重传分组，收到ACK就中止定时器

过早超时（延迟的 ACK）也能够正常工作，但是效率较低
发送方至少需要等待这样长的时间：发送方与接收方之间的一个往返时延（可能包括中间路由器的缓冲时延）加上接收方处理一个分组所需的时间

因为分组序号在0和1之间交替，因此rdt3.0有时被称为比特交替协议(alter-nating-bit protocol)

性能提升(滑动窗口)

上述停等方式使得带宽利用率低，严重影响性能。
允许发送方发送多个分组而无须等待确认，从而提高利用率，这种技术称为流水线技术

流水线技术需求：

• 增加序号范围，使流水线中的多个分组得以区分
• 发送方和接收方缓存多个分组以重传或排序

所需序号范围和对缓冲的要求取决于数据传输协议如何处理丢失、损坏及延时过大的分组。两种通用的流水线协议包括回退N步(GBN)和选择重传(SR)

停等协议、GBN 和 SR 都属于滑动窗口协议

发送缓冲区为内存中存储可发送分组的区域，其大小决定了一次最多可发送的未经确认的分组数(停等为1)
发送窗口为发送缓冲区中已发送但是未经确认的分组构成的空间
随着缓冲区中分组的发送，发送窗口前部扩展
随着发送缓冲区尾部分组的确认，发送缓冲区向前滑动，直至尾部到达下一个未确认分组，发送窗口尾部收缩

接收窗口=接收缓冲区，只有位于接收窗口中的分组才允许接收，其他丢弃
仅在接收到尾部分组后，接收窗口向前滑动，直至尾部到达下一个未接收分组

GBN 协议中，接收窗口大小为1分组，因此接收方丢弃所有失序分组
发送方拥有发送窗口头部分组的定时器，如果出现超时，发送方需依序重传所有发送窗口内的分组
此协议接收方采用累积确认，对失序分组返回上一个正确分组的 ACK，所返回的序号为 x 的 ACK 表明接收方已正确接收了 x 及 x 以前的所有分组
对于 GBN 协议而言，发送缓冲区长度必须小于分组序号空间大小，以避免接收方无法分辨分组为新分组还是重传

SR 协议中，接收窗口尺寸大于1分组，接收方缓存接收窗口中的高序号分组直至窗口尾部分组到来，然后将一批连续分组按序向上交付
发送方为发送窗口中的每个分组保持一个定时器，如果出现超时，发送方仅重传超时的分组
此协议接收方收到分组后发送该分组的ACK，且对于重复接收到的分组依然发送ACK，以防止发送缓冲区阻塞
对于SR协议而言，发送缓冲区长度必须小于或等于分组序号空间大小的一半，以避免接收方无法分辨分组为新分组还是重传

GBN 协议实现简单，接收方所需缓存空间少，但出错时回退 N 步代价较大，SR 协议与之相反
根据不同需求选用不同协议