当前位置：首页 > news >正文

Can201-Introduction to Networking:Transport Layer 传输层

news 2025/7/14 13:30:34

1.传输层服务

1.1传输服务Transport services

1.2传输层与网络层的区别 Transport vs. Network layer

2.多路复用/多路分解 Multiplexing/demultiplexing

2.1多路分解的工作原理 How demultiplexing works

2.2无连接的多路分解（UDP）Connectionless demultiplexing (UDP)

2.3 面向连接的多路分解（TCP）Connection-oriented demux

3可靠数据传输reliable data transfer

3.1介绍：

3.2 rdt1.0：在可靠信道上的可靠传输rdt1.0: reliable transfer over a reliable channel

3.3rdt2.0：具有位错误的信道 rdt2.0: channel with bit errors

3.3.1 RDT2.1

3.3.2 RDT 2.2：再优化（一个无NAK的协议）

3.4 RDT 3.0：存在错误和丢包的信道

3.4.1性能

4.流量控制flow control

5.连接管理Connection Management

5.1两路握手

5.2三路握手 3-way handshake

5.3关闭连接 closing a connection

6.拥塞控制 Principles of congestion control

6.1拥塞的情景1 Causes/costs of congestion: scenario 1

6.2拥塞的情景2 Causes/costs of congestion: scenario 2

6.2.1理想化假设：

6.2.2 现实情况：

6.3 拥塞的情景3 Causes/costs of congestion: scenario 3

6.4堵塞的成本：costs of congestion:

6.5拥塞控制的方法：Approaches to Congestion Control

7.流水线通讯 Pipelined communication

7.1停止等待协议rdt3.0: stop-and-wait operation

7.2.流水线协议（Pipelined Protocols）

7.3 两种通用的流水线协议：回退N步（Go-Back-N）和选择性重传（Selective Repeat）

Two forms: Go-Back-N and Selective repeat

7.3.1回退N步（Go-Back-N，GBN）：

7.3.2选择性重传（Selective Repeat，SR）：

7.4.回退N步（Go-Back-N）：

7.4.1发送方sender

7.4.2 接收方receiver

7.4.3 运行

7.5选择重传Selective repeat

7.5.1 发送方窗口，接收方窗口 sender, receiver windows

7.5.2发送方 Sender

7.5.3接收方 Receiver

7.5.4选择性重传在行动中Selective repeat in action

7.5.5 困境dilemma

8.UDP：用户数据报协议User Datagram Protocol [RFC 768]

8.1特性：Feature

8.2 UDP：段头格式 segment header

8.3 UDP：校验 checksum

9.TCP：

9.1概览 RFCs：793, 1122, 1323, 2018, 2581

9.2 分段结构：segment structure

9.3 往返时间（Round Trip Time, RTT），超时（Timeout）

9.4 发送方事件：sender events:

9.5 TCP确认生成

9.6重传场景retransmission scenarios

9.6.1快速重传 fast retransmit

9.7 TCP拥塞控制：TCP Congestion Control

9.7.1 TCP发送速率：TCP sending rate

9.7.2 TCP：检测和响应丢包 detecting, reacting to loss

9.7.3阻塞避免 --> 指数增长转变为线性增长的阈值设置

9.7.4 TCP慢开始 TCP Slow Start

9.7.5.显式拥塞通知 Explicit Congestion Notification (ECN)

9.7.6 TCP吞吐量 TCP throughput

1.传输层服务

1.1传输服务Transport services

- 提供在不同主机上运行的应用进程之间的逻辑通信Provide logical communication between app processes running on different hosts

- 传输协议在端系统中运行 Transport protocols run in end systems

• 发送端：将应用消息分解为段，传递给网络层Send side: breaks app msg into segments, passes to network layer

• 接收端：将段重新组装为消息，传递给应用层

Rcv side: reassembles segments into messages, passes to app layer

1.2传输层与网络层的区别 Transport vs. Network layer

- 网络层Network layer：

主机之间的逻辑通信 logical communication between hosts

- 传输层Transport layer：

进程之间的逻辑通信 logical communication between processes

• 依赖并增强网络层服务 Relies on, enhances, network layer services

2.多路复用/多路分解 Multiplexing/demultiplexing

- 发送方的多路复用：multiplexing at sender:

·处理来自多个套接字的数据，为他们添加传输层头信息（稍后用于多路分解），传递到网络层

handle data from multiple sockets, add transport header (later used for demultiplexing)

- 接收方的多路分解：demultiplexing at receiver:

·使用头信息将接收到的段分发到正确的套接字 use header info to deliver received segments to correct socket

2.1多路分解的工作原理 How demultiplexing works

- 主机接收IP数据报 Host receives IP datagrams

• 每个数据报具有源IP地址和目的IP地址 Each datagram has source IP address, destination IP address

• 每个数据报携带一个传输层段 Each datagram carries one transport-layer segment

• 每个段具有源端口号和目的端口号 Each segment has source, destination port number

- 主机使用IP地址和端口号将段定向到合适的套接字

Host uses IP addresses & port numbers to direct segment to suitable socket

2.2无连接的多路分解（UDP）Connectionless demultiplexing (UDP)

- 创建的套接字具有主机本地的端口号： Created socket has host-local port number

Socket = socket(AF_INET, SOCK_DGRAM)

Socket.bind(('', 12345))

- 当创建数据报并发送到UDP套接字时，必须指定：When creating datagram to send into UDP socket, must specify

• 目的IP地址 Destination IP address

• 目的端口号 Destination port number

clientSocket.sendto(msg, (server_name, server_port))

- 当主机接收到UDP段时：When host receives UDP segment

• 检查段中的目的端口号 Checks destination port # in segment

• 将UDP段定向到该端口号对应的套接字 Directs UDP segment to socket with that port #

--->

具有相同目的端口号但源IP地址和/或源端口号不同的IP数据报将被定向到目的地的同一套接字

IP datagrams with same dest. port #, but different source IP addresses and/or source port numbers will be directed to same socket at dest

- 示例：

******* p3的端口是6428，p2和p1两个不同的进程如果想要给p3发送UDP报文，需要标明自己的源端口号和目的端口号。那么源端口号的用处是什么呢？主要是用来作为返回地址，也就是32可以再向p1 和 p2传送了

2.3 面向连接的多路分解（TCP）Connection-oriented demux

- TCP套接字由四元组标识：TCP socket identified by 4-tuple

• 源IP地址 source IP address

• 源端口号 source port number

• 目的IP地址 dest IP address

• 目的端口号 dest port number

- 多路分解：接收方使用这四个值将段定向到适当的套接字 Demux: receiver uses all four values to direct segment to appropriate socket

- 服务器主机可能支持许多同时的TCP套接字Server host may support many simultaneous TCP sockets:

• 每个套接字由其自己的四元组标识 each socket identified by its own 4-tuple

- Web服务器为每个连接的客户端提供不同的套接字 Web servers have different sockets for each connecting client

• 非持久性HTTP将为每个请求使用不同的套接字non-persistent HTTP will have different socket for each request

- 服务器能够根据源IP地址和源端口号来区分来自不同客户的报文段

- 示例

*****主机C作为服务器，主机A向其建立了一个HTTP会话，主机B向其建立了两条HTTP会话，三台主机都是有着自己唯一的IP地址。主机A与主机B的源端口号是相同的，这不是问题，因为B根据IP地址能够分辨。

3可靠数据传输reliable data transfer

3.1介绍：

- 不可靠信道的特性将决定可靠数据传输协议（rdt）的复杂性characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt)

- rdt面临的服务很复杂，需要向上层提供可靠的数据传输，但是依赖的下层服务却不怎么可靠，可能会出错、丢失、乱序

3.2 rdt1.0：在可靠信道上的可靠传输rdt1.0: reliable transfer over a reliable channel

- 底层信道完全可靠 Underlying channel perfectly reliable

• 无位错误No bit errors

• 无数据包丢失No loss of packets

- 为发送方和接收方分别使用单独的有限状态机：Separate FSMs for sender, receiver

• 发送方将数据发送到底层信道Sender sends data into underlying channel

• 接收方从底层信道读取数据Receiver reads data from underlying channel

3.3rdt2.0：具有位错误的信道 rdt2.0: channel with bit errors

- 底层信道可能在数据包中翻转位（0变1，1变0）Underlying channel may flip bits in packet

• 使用校验和检测位错误Checksum to detect bit errors

- 错误中恢复的方式：Question : how to recover from errors:

• 确认（ACKs）：接收方告诉发送方数据包接收正常Acknowledgements (ACKs): receiver tells sender that pkt received OK

• 否定确认（NAKs）：接收方告诉发送方数据包有错误Negative acknowledgements (NAKs): receiver tells sender that pkt had errors

> 发送方在收到NAK后重新传输数据包sender retransmits pkt on receipt of NAK

- rdt2.0中的新机制（超出rdt1.0）：New mechanisms in rdt2.0 (beyond rdt1.0):

• 错误检测 Error detection

• 接收方反馈：控制消息（ACK，NAK）从接收方到发送方Receiver feedback: control msgs (ACK,NAK) rcvr->sender

- 有限状态机规范FSM specification

·发送方：

> 发送方两个状态：一个是等待上层的调用，一个是等待NAK或者ACK；

> 发送方初始化等待上层的调用，等待上层发数据，rdt_send(data)，data来之后要把它封装成packet，在封装的时候要计算checksum检验和，data、checksum一起封装成packet，通过下层接口把它放出去（udt_send(sndpkt)）；放完之后进入等待接收方反馈的状态，如果对方给的是ACK就什么都不做，等待上层调用新的data，然后发新的data；如果对方给的是NAK，把刚刚封装的packet重放一遍，这里就是检错重传，传完之后还要等对方的ACK或者NAK，直到收到ACK才传新的

·接收方：

> 接收方只有一个状态：等待下层的调用。

> 接收方等待下层的调用，如果接收方来了一个分组，没有出错，（没有corrupt，没有腐败，D和EDC通过了差错控制编码关系，通过了校验），然后就解封装，通过层间接口往上交，然后还要向发送方发送ACK。如果收到一个分组错了，没通过校验，给对方发一个NAK

- 无错误场景 vs 错误场景

3.3.1 RDT2.1

- 解决RDT 2.0缺陷！

·问题1：如果ACK/NAK被破坏了怎么办？发送方不知道接收方发生了什么！

> 方法：如果ACK/NAK被破坏，发送方重传当前的数据包

·问题2:不能只是重传 -> 可能会出现重复

> 方法：

发送方为每个数据包添加序列号

接收方丢弃（不向上传递）重复的数据包（注：有可能出现重复的分组，但是接收方是能够检测出重复的分组的，因为增加了序号，重复了就扔了，扔了仍然发一个ACK，从而发送方再发一个新的）

- 有限状态机规范

·发送方处理出错的ACK/NAK

> 初始化等待上层调用0，也就是说来了data封装packet序号是0，然后还有checksum，通过下层接口把它放出去，然后等待ACK或NAK 0，如果接收到的是ACK，那么就进入等待来自上层的调用1在；如果ACK或者NAK分组本身出错或者收到NAK，就要把packet0重传一遍，有可能出现重复，接收方是可以通过序号把他校验出来。1的状态和0的状态是对称的，发送方有4个状态

·接收方处理出错的ACK/NAK

> 接收方就两个状态：等待来自下层的调用0、等待来自下层的调用1。发送方从0案开始接收方就从0开始，发送方从1开始接收方就从1开始。接收方在等待序号0分组，这时来了分组、没出错、是序号0分组，把packet当中data取出来，data取出来通过层间接口交给上层，形成ACK，ACK本身也要chksum，通过层间接口把他放出去；然后到了等待1的状态，然后收到一个分组、没出错、是一个序号1的分组，然后解封装、向上交付、形成ACK往下交，然后又回到等待0分组的状态。假如发了0之后等待1，这时来了一个分组，分组没出错，但是来的是0分组，给对方一个ACK的packet，然后通过层间接口把它放出去（ACK重放）。如果等待1，这时来了一个分组，分组出错了，给对方NAK

> 共有三种事件：一种是分组是对的也是等待的分组，解封装、向上交付、形成ACK往下交；一种是分组是对的但不是等待的分组，形成ACK往下交；还有一种是分组是错的，形成NAK往下交

- 讨论

发送方Sender：

·在分组中加入序列号 seq # added to pkt

·两个序列号（0，1）就足够了【区分出老的和新的就行】

·一次只发送一个未经确认的分组【停等协议】

·必须检测ACK/NAK是否出错（需要EDC）【ACK确认也需要校验】Must check if received ACK/NAK corrupted

·状态数变成了两倍Twice as many states

> 必须记住当前分组的序列号为0还是1State must “remember” whether “expected” pkt should have seq # of 0 or 1

接收方：Receiver

·必须检测接收到的分组是否是重复的Must check if received packet is duplicate

> 状态会指示希望接收到的分组的序号为0还是1state indicates whether 0 or 1 is expected pkt seq #

注意：接收方并不知道发送方是否正确收到了其ACK/NAKreceiver can not know if its last ACK/NAK received OK at sender

3.3.2 RDT 2.2：再优化（一个无NAK的协议）

- 与RDT 2.1具有相同的功能，只使用ACK（把ACK编号）

·接收方不是发送NAK，而是为最后正确接收的数据包发送ACK

> 接收方必须明确包含被ACK的数据包的序列号

- 发送方收到重复的ACK时，会采取与收到NAK相同的行动：重传当前数据包

- 有限状态机规范（红色是与2.1版本的不同）

3.4 RDT 3.0：存在错误和丢包的信道

- 新的假设：

·底层信道也可能丢失数据包（数据、ACK）

·校验和、序列号、ACK、重传会有帮助……但还不够

- 方法：

·发送方等待“合理”的时间来接收ACK

·如果在这段时间内没有收到ACK，则重传

·如果数据包（或ACK）只是被延迟（而不是丢失）：

>重传将会是重复的，但序列号已经处理了这个问题

>接收方必须指定被ACK的数据包的序列号

>需要倒计时定时器

- 有限状态基规范

·来了data，0号，checksum计算形成分组放出去，start_timer启动超时定时器。在等待的时候如果超时定时器启动了，就把刚刚形成的分组重放一遍，重放之后仍然要启动一个超时定时器。另外是等待ack0号确认的时候，收到的ack0不知道是啥，要重发packet0；还有一个等待ack0确认的时候收到的是ack1，等待超时定时器启动重发分组。】

·超时定时器在发送方放完一个分组之后要启动，在发送方等待确认的时候，超时事件启动之后要把刚刚形成的分组重放一遍，仍然再启动超时定时器；在等待ack0的时候收到ack1 or 在等待ack1的时候收到ack0，这时候说明发出去的分组出错了（没通过校验），没有直接重放一遍刚刚的分组，而是等待超时事件启动，然后再把刚刚的分组重放一遍，然后这时候仍然需要把超时定时器启动

- 运行：

3.4.1性能

- RDT 3.0是正确的，使用停等操作，但性能很差。rdt3.0 is correct, but performance stinks

- 例如：1 Gbps链路，15毫秒传播延迟，8000比特数据包：1 Gbps link, 15 ms prop. delay, 8000 bit packet

·发送方利用率——发送方忙于发送的时间比例。Usender: utilization – fraction of time sender busy sending

·如果RTT=30毫秒,每30毫秒发送1KB数据包:在1 Gbps链路上的吞吐量为33kB/秒。if RTT=30ms, 1KB pkt every 30 msec: 33kB/sec throughput over 1 Gbps link

- 网络协议限制了物理资源的使用！ Network protocol limits use of physical resources!

4.流量控制flow control

- 接收方控制发送方，以防止发送方发送数据过快过多，导致接收方的缓冲区溢出。Receiver controls sender, so sender won’t overflow. Receiver’s buffer by transmitting too much, too fast

- 接收方通过在接收方至发送方的TCP分段头部中包含rwnd（接收窗口）值来“宣告”其空闲缓冲区大小。Receiver “advertises” free buffer space by including rwnd value in TCP header of receiver-to-sender segments

- RcvBuffer大小可以通过套接字选项设置（典型默认值为4096字节）。

RcvBuffer size set via socket options (typical default is 4096 bytes)

- 许多操作系统会自动调整RcvBuffer。many operating systems auto-adjust RcvBuffer

- 发送方将未确认（“在途”）数据量限制在接收方的rwnd值内。Sender limits amount of unacked (“inflight”) data to receiver’ s rwnd value

- 保证接收缓冲区不会溢出。 Guarantees receive buffer will not overflow

5.连接管理Connection Management

- 在交换数据之前，发送方/接收方进行“握手”：Before exchanging data, sender/receiver “handshake” :

·同意建立连接（双方都知道对方愿意建立连接）Agree to establish connection (each knowing the other willing to establish connection)

·同意连接参数Agree on connection parameters

5.1两路握手

- 两路握手有时会失效

·变量延迟Variable delays

·由于消息丢失导致的消息重传（例如req_conn(x)）Retransmitted messages (e.g. req_conn(x)) due to message loss

·消息重排序Message reordering

·无法“看到”对方Can’t “ see ” other side

- 半开放连接： - 重复数据传输

5.2三路握手 3-way handshake

- 三次握手步骤：

·客户端发送SYN：客户端发送一个SYN消息，其中SYNbit=1表示这是一个同步请求，Seq=x是客户端选择的初始序列号。

·服务器发送SYN-ACK：服务器收到SYN消息后，发送一个SYN-ACK消息作为响应，其中SYNbit=1和ACKbit=1表示这是一个同步确认，Seq=y是服务器的初始序列号，ACKnum=x+1是对客户端SYN消息的确认。

·客户端发送ACK：客户端收到SYN-ACK消息后，发送一个ACK消息，其中ACKbit=1表示这是一个确认，ACKnum=y+1是对服务器SYN-ACK消息的确认。

- 三路握手的FSM

5.3关闭连接 closing a connection

- 客户端和服务器各自关闭他们的连接端Client, server each close their side of connection

- 发送FIN位=1的TCP分段Send TCP segment with FIN bit = 1

- 对收到的FIN回应ACK Respond to received FIN with ACK

- 在接收到FIN时，ACK可以与自己的FIN合并 On receiving FIN, ACK can be combined with own FIN

- 可以处理同时的FIN交换Simultaneous FIN exchanges can be handled

6.拥塞控制 Principles of congestion control

- 拥塞：太多源发送太多数据过快，网络无法处理”

Informally: “too many sources sending too much data too fast for network to handle”

- 与流量控制不同！Different from flow control!

- 表现：Manifestations:

·丢包（路由器缓冲区溢出）lost packets (buffer overflow at routers)

·延迟长（在路由器缓冲区排队）long delays (queueing in router buffers)

6.1拥塞的情景1 Causes/costs of congestion: scenario 1

- 两个发送方，两个接收方 Two senders, two receivers

- 一个路由器，无限缓冲区 One router, infinite buffers

- 输出链路容量：R Output link capacity: R

- 无需重传 no retransmission

6.2拥塞的情景2 Causes/costs of congestion: scenario 2

- 一个路由器，有限缓冲区One router, finite buffers

- 发送方重传超时的数据包 Sender retransmission of timed-out packet

- 应用层输入等于应用层输出：application-layer input = application-layer output

λin = λout

- 传输层输入包括重传transport-layer input includes retransmissions

λ'in ≥ λin

6.2.1理想化假设：

- 完美认知Idealization: perfect knowledge

·发送方仅在路由器缓冲区可用时发送数据。Sender sends only when router buffers available

- 已知的丢包 Idealization: known loss

·数据包可能会因为路由器缓冲区已满而被丢弃。packets can be lost, dropped at router due to full buffers

·发送方只有在数据包被确认丢失时才会重传。Sender only resends if packet known to be lost

6.2.2 现实情况：

- 重复Realistic: duplicates

·数据包可能会因为路由器缓冲区已满而丢失或被丢弃。Packets can be lost, dropped at router due to full buffers

·发送方可能会过早地超时，导致发送两份副本，而这两份副本都被送达。Sender times out prematurely, sending two copies, both of which are delivered

***当以R/2的速率发送时，一些数据包是重传的，包括被送达的重复副本。

when sending at R/2, some packets are retransmissions including duplicated that are delivered!

6.3 拥塞的情景3 Causes/costs of congestion: scenario 3

- 四个发送方Four senders

- 多跳路径 Multi-hop paths

- 超时/重传 Timeout/retransmit

- 随着红色λin’增加，所有到达上层队列的蓝色数据包都被丢弃，蓝色吞吐量趋近于0。

as red lin ’ increases, all arriving blue pkts at upper queue are dropped, blue throughput -> 0

6.4堵塞的成本：costs of congestion:

- 为了一定的“好传”（goodput），需要做更多的工作（重传）。More work (retrans) for given “goodput”

- 不必要的重传：链路携带了数据包的多个副本。Unneeded retransmissions: link carries multiple copies of pkt

> 好传（goodput）减少。decreasing goodput

- 当数据包被丢弃时，任何“用于该数据包的上游传输容量都被浪费了！”When packet dropped, any “upstream transmission capacity used for that packet was wasted!

6.5拥塞控制的方法：Approaches to Congestion Control

- 端到端拥塞控制 End-to-end congestion control

·网络层不提供拥塞控制的支持Network layer does not provide support for congestion control

·传输层必须从网络行为中推断Trans layer has to infer from network behavior

·TCP将控制窗口大小TCP will control the size of window

- 网络辅助拥塞控制Network-assisted congestion control

·路由器向发送方和/或接收方提供反馈（单个一位）Routers provide feedback to sender and/or receiver (a single one bit)

7.流水线通讯 Pipelined communication

7.1停止等待协议rdt3.0: stop-and-wait operation

- 在停止等待协议 (Stop-and-Wait Protocol) 中，发送方在发送一个数据包后会等待接收方的确认 (ACK) 信号，然后再发送下一个数据包。这种操作方式确保了数据的可靠传输，但效率较低，因为它在等待确认时不进行任何其他操作。

7.2.流水线协议（Pipelined Protocols）

- 流水线（Pipelining）: 发送方允许有多个“在传输中”的、尚未被确认的数据包。Pipelining: sender allows multiple, “in-flight”, yet-to-beacknowledged pkts

·必须增加序号的范围：用多个bit表示分组的序号

·在发送方/接收方要有缓冲区【发送方发送完毕之后从，把分组保持在缓冲区当中，以便于检错重发或者是超时重发，在接收端要有一个缓冲区的目的是发送方发送的速率和接收方收到的速率可能不一样，需要一个缓存来对抗速度的不一致性】

>发送方缓存：未得到确认，可能需要重传

>接收方缓存：上层用户取用数据的速率 ≠ 接收到的数据速率；接收到的数据可能乱序，排序交付（可靠）

- 流水线：提高了利用率Pipelining: increased utilization

·增加n,能提高链路利用率

·但当达到某个n，其u-100%时，无法再通过增加n，提高利用率

>瓶颈转移了->链路带宽

7.3 两种通用的流水线协议：回退N步（Go-Back-N）和选择性重传（Selective Repeat）

Two forms: Go-Back-N and Selective repeat

7.3.1回退N步（Go-Back-N，GBN）：

- 发送方可以在流水线中最多有N个未确认的数据包。

Sender can have up to N unacked packets in pipeline

- 接收方只发送累积确认（ack）。Receiver only sends cumulative ack

• 如果有间隙（gap），则不会确认数据包。Doesn’t ack packet if there’ s a gap

- 发送方为最旧的未确认数据包设置定时器。Sender has timer for oldest unacked packet

• 当定时器超时时，重传所有未确认的数据包。When timer expires, retransmit all unacked packets

7.3.2选择性重传（Selective Repeat，SR）：

- 发送方可以在流水线中最多有N个未确认的数据包。Sender can have up to N unacked packets in pipeline

- 接收方对每个数据包发送单独的确认（ack）。Rcvr sends individual ack for each packet

- 发送方为每个未确认的数据包维护一个定时器。Sender maintains timer for each unacked packet

• 当定时器超时时，只重传那个未确认的数据包。When timer expires, retransmit only that unacked packet

7.4.回退N步（Go-Back-N）：

7.4.1发送方sender

- k位序列号（k-bit seq #）：数据包头中的序列号由k位组成。

- 窗口：最多允许N个连续的未确认数据包，即“窗口”大小为N。window” of up to N, consecutive unacked pkts allowed

- ACK(n)：确认所有序列号小于等于n的数据包——称为“累积确认”。ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK”

• 可能会收到重复的确认（参见接收方部分）。may receive duplicate ACKs (see receiver)

- 最旧的未确认数据包的定时器Timer for oldest in-flight pkt：

·为最早发送但尚未确认的数据包设置定时器。

- 超时(n)：当定时器超时时，重传序列号为n的数据包以及窗口内所有序列号更高的数据包。Timeout(n): retransmit packet n and all higher seq # pkts in window

- 发送方拓展到FSM sender extended FSM

7.4.2 接收方receiver

- 扩展有限状态机（FSM）extended FSM

- 仅发送ACK：总是为正确接收到的、具有最高按序序列号的数据包发送确认（ACK）。

ACK-only: always send ACK for correctly-received pkt with highest in-order seq #

• 可能会生成重复的ACK。may generate duplicate ACKs

• 只需要记住expectedSeqNum（期望收到的序列号）。need only remember expectedseqnum

- 乱序数据包：out-of-order pkt

• 丢弃（不缓存）：不进行接收端缓存！discard (don’t buffer): no receiver buffering

• 重新发送具有最高按序序列号的数据包的ACK。re-ACK pkt with highest in-order seq #

- 总结：在GBN协议中，接收方只会确认按序到达的最高序列号的数据包，乱序到达的数据包会被丢弃，并且会重复发送对最高按序序列号数据包的确认。接收方只需要记录期望接收的序列号，不需要缓存乱序的数据包。

7.4.3 运行

- 在接收端，乱序的不缓存；

- 因此哪个n分组丢失了GB到那个分组n;

- 即使n以后的分组传送都是正确的

7.5选择重传Selective repeat

- 接收方单独确认所有正确接收的数据包Receiver individually acknowledges all correctly received pkts

·根据需要缓冲数据包，以便最终按顺序交付给上层buffers pkts, as needed, for eventual in-order delivery to upper layer

- 发送方只重传未收到确认的数据包 Sender only resends pkts for which ACK not received

·每个未确认的数据包都有发送方计时器sender timer for each unACKed pkt

- 发送方窗口Sender window

·N个连续的序列号N consecutive seq #’ s

·限制已发送但未确认的数据包的序列号 limits seq #s of sent, unACKed pkts

7.5.1 发送方窗口，接收方窗口 sender, receiver windows

7.5.2发送方 Sender

- 来自上层的数据：data from above

·如果是窗口中下一个可用的序列号，则发送数据包If next available seq # in window, send pkt

- 超时(n)：timeout(n):

·重新发送数据包n，重启计时器Resend pkt n, restart timer

- 收到ACK(n)在[sendbase, sendbase+N]范围内：

·将数据包n标记为已接收 Mark pkt n as received

·如果n是未确认的最小序列号，将窗口基地址推进到下一个未确认的序列号 If n smallest unACKed pkt, advance window base to next unACKed seq #

7.5.3接收方 Receiver

- 数据包n在[rcvbase, rcvbase+N-1]范围内：

·发送ACK(n)

·乱序：缓冲

·有序：交付（同时交付缓冲的有序数据包），将窗口推进到下一个未接收的数据包deliver (also deliver buffered, in-order pkts), advance window to next not-yet-received pkt

- 数据包n在[rcvbase-N, rcvbase-1]范围内：

·发送ACK(n)

- 否则：忽略

7.5.4选择性重传在行动中Selective repeat in action

7.5.5 困境dilemma

- 示例：Example

·序列号：0, 1, 2, 3

·窗口大小=3

·接收方在两种情况下无法区分！

·在情况(b)中，重复的数据被当作新的接受。

8.UDP：用户数据报协议User Datagram Protocol [RFC 768]

8.1特性：Feature

- 简单直接 Simple and straightforward

- 尽力而为 Best effort

- 可能会丢失 Lost

- 无连接 Connectionless

·无握手过程 No handshaking

·每个UDP段独立处理，与其他段无关 Each UDP segment handled independently of others

> 可能乱序到达应用层 Out-of-order to APP

- UDP用途：

·流媒体应用 Streaming multimedia apps

·DNS

- 基于UDP的可靠传输：Reliable transfer over UDP

• 在应用层增加可靠性 Add reliability at application layer

• 应用特定的错误恢复Application-specific error recovery

- UDP优势

·无需连接建立（这可能会增加延迟） No connection establishment (which can add delay)

·简单：发送方和接收方没有连接状态 Simple: no connection state at sender, receiver

·头部尺寸小 Small header size

·无拥塞控制：UDP可以以所需的速度快速发送数据No congestion control: UDP can blast away as fast as desired

8.2 UDP：段头格式 segment header

8.3 UDP：校验 checksum

- 目标：检测传输段中的“错误” Goal: detect “errors” in transmitted segment

- 发送方：Sender

·将段内容（包括头部字段）视为一系列16位整数 Treat segment contents, including header fields, as sequence of 16-bit integers

·校验和：伪头部、UDP头部和UDP数据的加法（反码求和）Checksum: addition (one’ s complement sum) of pseudo header, UDP header and UDP data

·发送方将校验和值放入UDP校验和字段Sender puts checksum value into UDP checksum field

- 接收方：Receiver

·计算接收到的段的校验和 Compute checksum of received segment

·检查计算出的校验和是否等于校验和字段的值：Check if computed checksum equals checksum field value

> 否 - 检测到错误 error detected

> 是 - 未检测到错误。但仍可能存在错误no error detected. But maybe errors nonetheless

- 框架：

- 校验和计算：

·注意：当相加数字时，最高有效位产生的进位需要加到结果中Note: when adding numbers, a carryout from the most significant bit needs to be added to the result

9.TCP：

9.1概览 RFCs：793, 1122, 1323, 2018, 2581

- 点对点：Point-to-point:

·一个发送方，一个接收方one sender, one receiver

- 可靠，有序的字节流：Reliable, in-order byte stream :

·没有“消息边界”no “message boundaries”

- 管道化：Pipelined

·TCP拥塞和流量控制设置窗口大小TCP congestion and flow control set window size

- 全双工数据：Full duplex data:

·在同一连接中双向数据流bi-directional data flow in same connection

- 连接导向：Connection-oriented:

·握手（交换控制消息）在数据交换前初始化发送方、接收方状态

handshaking (exchange of control msgs) inits sender, receiver state before data exchange

- 流量控制：Flow controlled:

- 发送方不会压倒接收方sender will not overwhelm receiver

9.2 分段结构：segment structure

- URG：紧急数据（通常不使用）

- ACK：确认号有效

- PSH：立即推送数据（通常不使用）

- RST、SYN、FIN：连接建立（设置、拆除、命令）

- checksum：互联网校验和（与UDP相同）

- sequence number，acknowledgement number：按字节计数数据（不是分段！）

- receive window：接收方愿意接受的字节数

- 序列号：Sequence numbers:

·标识发送的数据包的顺序，确定收到的分组是新的还是重传的分组

- 确认号：Acknowledgements

·告知发送方接收方已经成功接收到的数据包

·预期从对方接收的下一个字节的序列号。Seq # of next byte expected from other side

·累积确认。Cumulative ACK

9.3 往返时间（Round Trip Time, RTT），超时（Timeout）

- 估计RTT方法：

·SampleRTT：从分段传输到收到确认的测量时间。SampleRTT: measured time from segment transmission until ACK receipt

>忽略重传。Ignore retransmissions

·SampleRTT会变化，想要一个“更平滑”的估计RTT。SampleRTT will vary, want estimated RTT “smoother”

·平均几个最近的测量值，而不仅仅是当前的SampleRTT。Average several recent measurements, not just current SampleRTT

- 计算公式：

·指数加权移动平均 Exponential weighted moving average

·过去样本的影响以指数速度快速减少Influence of past sample decreases exponentially fast

·典型值：α = 0.125

- 超时间隔：估计的RTT加上“安全边际”。Timeout interval: EstimatedRTT plus “safety margin”

·估计的RTT变化大 -> 更大的安全边际。large variation in EstimatedRTT -> larger safety margin

·从估计的RTT估计SampleRTT的偏差：Estimate SampleRTT deviation from EstimatedRTT:

9.4 发送方事件：sender events:

- 从应用程序接收数据：Data rcvd from app:

·创建带有序列号的分段Create segment with seq #

·序列号是分段中第一个数据字节的字节流编号 Seq # is byte-stream number of first data byte in segment

·如果尚未运行，则启动计时器Start timer if not already running

>将计时器视为针对最旧未确认分段的Think of timer as for oldest unacked segment

>到期间隔：TimeOutIntervalExpiration interval: TimeOutInterval

- 超时：Timeout

·重传导致超时的分段Retransmit segment that caused timeout

·重启计时器 Restart timer

- 收到确认（Ack）：Ack rcvd:

·如果确认号确认了之前未确认的分段 If ack acknowledges previously unacked segments

>更新已知已被确认的内容Update what is known to be ACKed

>如果仍有未确认的分段，则启动计时器Start timer if there are still unacked segments

- 图示：

9.5 TCP确认生成

- 延迟确认

·接收方事件：收到预期序列号的有序分段。所有直到预期序列号的数据已经确认。Event at receiver：arrival of in-order segment with expected seq #. All data up to expected seq # already ACKed

·接收方行动：延迟确认。等待最多500毫秒以接收下一个分段。如果没有下一个分段，发送确认。delayed ACK. Wait up to 500ms for next segment. If no next segment, send ACK

- 累积确认

·接收方事件：收到预期序列号的有序分段。有一个延迟的分段待确认。Event at receiver：arrival of in-order segment with expected seq #. One delayed segment has ACK pending

·接收方行动：立即发送单个累积确认，确认两个有序分段。immediately send single cumulative ACK, ACKing both in-order segments

- 重复确认：

·接收方事件：收到序列号高于预期的乱序分段。检测到间隙。Event at receiver：arrival of out-of-order segment higher-than-expect seq. # . Gap detected

·接收方行动：立即发送重复确认，指示下一个预期字节的序列号。immediately send duplicate ACK, indicating seq. # of next expected byte

- 立即确认：

·接收方事件：收到部分或完全填补间隙的分段。arrival of segment that partially or completely fills gap

·接收方行动：如果分段从间隙的低端开始，立即发送确认。immediate send ACK, provided that segment starts at lower end of gap

9.6重传场景retransmission scenarios

- 丢失ACK场景 - 过早超时场景 - 累积确认

9.6.1快速重传 fast retransmit

- 超时周期通常相对较长：Time-out period often relatively long:

·在重新发送丢失的数据包之前会有较长的延迟。Long delay before resending lost packet

- 通过重复确认（duplicate ACKs）检测丢失的分段。Detect lost segments via duplicate ACKs

·发送方经常连续发送多个分段。Sender often sends many segments back-to-back

·如果一个分段丢失，很可能会出现许多重复确认。 If segment is lost, there will likely be many duplicate ACKs.

- 如果发送方收到相同数据的3个确认（“三重重复确认”），请重新发送序列号最小的未确认分段。if sender receives 3 ACKs for same data (“triple duplicate ACKs”), resend unacked segment with smallest seq #

·很可能未确认的分段已丢失，因此不需要等待超时。likely that unacked segment lost, so don’ t wait for timeout

9.7 TCP拥塞控制：TCP Congestion Control

- 策略：加性增加，乘性减少（AIMD）

Strategy: additive increase multiplicative decrease (AIMD)

- 方法：发送方增加传输速率（窗口大小），探测可用带宽，直到发生丢包Approach: sender increases transmission rate (window size), probing for usable bandwidth, until loss occurs

·加性增加：在检测到丢包之前，每个RTT（往返时间）将拥塞窗口cwnd增加1个MSS（最大报文段大小）Additive increase: increase cwnd (congestion window) by 1 MSS （ Maximum Segment Size） every RTT until loss detected

·乘性减少：在丢包后将cwnd减半Multiplicative decrease: cut cwnd in half after loss

9.7.1 TCP发送速率：TCP sending rate

- 大致上：发送cwnd字节的数据，等待RTT以接收ACK确认，然后发送更多字节。Roughly: send cwnd bytes, wait RTT for ACKS, then send more bytes

- 发送方限制传输：Sender limits transmission:

- cwnd是动态的，是感知到的网络拥塞的函数。cwnd is dynamic, function of perceived network congestion

9.7.2 TCP：检测和响应丢包 detecting, reacting to loss

- 丢包由超时指示：Loss indicated by timeout:

·当TCP发送方在预定的超时时间内没有收到确认（ACK），它会认为数据包已经丢失。

·cwnd设置为1 MSS；cwnd set to 1 MSS;

· 窗口随后呈指数增长（如慢开始）至阈值，然后线性增长。window then grows exponentially (as in slow start) to threshold, then grows linearly

- 丢包由3个重复ACK指示：TCP RENO Loss indicated by 3 duplicate ACKs: TCP RENO

·TCP使用快速重传机制，当发送方收到三个重复的ACK时，它会认为这些重复ACK对应的数据包之后的数据包已经丢失

·重复ACKs表明网络能够传递一些分段；Dup ACKs indicate network capable of delivering some segments

·TCP RENO中会cwnd减半，然后窗口线性增长。cwnd is cut in half window then grows linearly

- TCP Tahoe总是在超时或收到3个重复ACK时将cwnd设置为1。TCP Tahoe always sets cwnd to 1 (timeout or 3 duplicate acks)

9.7.3阻塞避免 --> 指数增长转变为线性增长的阈值设置

- 当cwnd达到超时前其值的一半时。When cwnd gets to 1/2 of its value before timeout.

- 实现：

·变量ssthresh（慢启动阈值） variable ssthresh

·在丢包事件中，ssthresh被设置为丢包事件前cwnd的一半。on loss event, ssthresh is set to 1/2 of cwnd just before loss event

9.7.4 TCP慢开始 TCP Slow Start

- 当连接开始时，指数级增加速率直到第一次丢包事件：When connection begins, increase rate exponentially until first loss event:

·最初cwnd = 1 MSS*（最大报文段大小） Initially cwnd = 1 MSS* (maximum segment size)

·每个RTT将cwnd翻倍 Double cwnd every RTT

·通过接收到的每个ACK来增加cwnd Done by incrementing cwnd for every ACK received

- 总结：初始速率较慢，但呈指数级快速增长Summary: initial rate is slow but ramps up exponentially fast

****MSS是一个动态值，默认值为536(576-40)，对于以太网最大值为1460(1500-40)

MSS is a dynamic value, default = 536(576-40), for Ethernet max value = 1460(1500-40)

9.7.5.显式拥塞通知 Explicit Congestion Notification (ECN)

- 网络辅助拥塞控制：Network-assisted congestion control:

·IP头部有两个位（ToS字段），由网络路由器标记以指示拥塞。Two bits in IP header (ToS field) marked by network router to indicate congestion

·拥塞指示被传递到接收主机。Congestion indication carried to receiving host

·接收方（在IP数据报中看到拥塞指示）在接收方至发送方的ACK分段上设置ECE位，以通知发送方拥塞情况。Receiver (seeing congestion indication in IP datagram) ) sets ECE bit on receiver-to sender ACK segment to notify sender of congestion