CH7-0

Andy Gao

2023-05-10

notes › network

network

传输层基础

传输层概述

传输层（Transport Layer）主要关注在网络中的两个主机之间的数据传输，提供端到端的可靠性和服务质量。

网络层（Network Layer）位于传输层下方，主要负责处理数据在网络中的路由和转发。

总结来说，传输层主要关注主机之间的端到端数据传输，确保数据的可靠性和服务质量，而网络层则更关注在网络中的路由和转发，决定数据在网络中的路径和目标地址。

传输层功能

传输层基本服务：将主机间交付扩展到进程间交付，通过复用和分用实现

(发送端)复用:传输层从多个应用收集数据，交给网络层发送
(接收端)分用:传输层将从网络层收到的数据，交付给正确的应用

传输层的主要功能包括：

分段和重组：传输层将来自应用层的数据分割成更小的数据块，称为分段。这些分段包括序列号，以便在目标主机上正确地重组数据。在接收端，传输层根据序列号重新组装分段，还原为完整的数据。
可靠的数据传输：传输层使用可靠的传输协议（如TCP）来确保数据的可靠传输。它通过使用确认和重传机制来处理丢失的数据、损坏的数据和乱序的数据，以确保数据在网络中正确地到达目标主机。
流量控制：传输层通过流量控制机制来协调发送方和接收方之间的数据传输速率，以防止接收方因处理过多数据而不堪重负。这样可以确保在网络中的各个部分之间平衡数据的流动。
拥塞控制：传输层还负责控制数据在网络中的拥塞程度。通过使用拥塞控制算法，传输层可以检测到网络中的拥塞情况，并采取相应的措施来减少数据的发送速率，以避免拥塞进一步恶化。

UDP

提供的额外功能很少,只是标记了

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Length             |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Data                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Source Port：16位字段，表示源端口号，标识发送方的应用程序或进程。
Destination Port：16位字段，表示目标端口号，标识接收方的应用程序或进程。
Length：16位字段，表示UDP头加上UDP数据的总长度，以字节为单位。
Checksum：16位字段，用于校验UDP头和数据的完整性。校验和的计算涉及UDP头、UDP数据以及伪首部的部分。

所以实际上只能提供进程标识与校验两个新功能.

所以UPD有以下几个特点是显然的.

udp特点

无连接,不可靠

发送前不需建立链接,想发就发.减小开销与时延;

不限制发送速率(没有拥塞控制和流量控制)
面向报文:

一次交付一整个完整的报文,不合并也不拆分
支持一对多\多对一
首部开销小

TCP

TCP基本可看做UDP互补

TCP特点

可靠性：TCP通过序列号、确认应答、重传和超时机制等方法来确保数据传输的可靠性。它可以处理丢失、乱序或重复的数据，并保证数据的正确性和顺序性。
流量控制和拥塞控制：TCP通过滑动窗口和拥塞控制算法来控制数据的发送速率，以防止网络拥塞和接收方不堪重负。
面向字节流：TCP将应用层的数据作为字节流进行传输，不保留应用程序发送数据的边界。接收端会将接收到的字节流重新组装成应用层可用的数据。(分段)
较慢的连接建立和关闭：与UDP相比，TCP需要进行三次握手和四次挥手的连接建立和关闭过程，这增加了一定的延迟。
全双工通信
只能一对一

以下是一个使用RFC标准格式的TCP头的示例代码块：

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Acknowledgment Number                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Data |           |U|A|P|R|S|F|                               |
| Offset| Reserved  |R|C|S|S|Y|I|            Window             |
|       |           |G|K|H|T|N|N|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Checksum            |         Urgent Pointer        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options                    |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

在上述代码块中，我们可以看到TCP头的结构，具体字段如下：

Source Port：16位字段，表示源端口号，标识发送方的应用程序或进程。
Destination Port：16位字段，表示目标端口号，标识接收方的应用程序或进程。
Sequence Number：32位字段，用于对TCP数据流中的字节进行编号，用于排序和重组数据。
Acknowledgment Number：32位字段，表示期望接收方接收到的下一个字节的编号。用于确认已经成功接收到的数据。

注意这里的编号是面对字节流而不是报文,所以在下面滑动窗口里,下一个包的ACK是上一个包的ACK加上接收包的报文长度
Data Offset：4位字段，表示TCP头的长度，以32位字（4字节）为单位。
Reserved：6位字段，保留位，未使用，必须为0。
Control Flags：6位字段，包括URG（紧急数据标志）、ACK（确认标志）、PSH（推送标志）、RST（重置标志）、SYN（同步标志）和FIN（结束标志）。
Window：16位字段，表示接收窗口大小，用于流量控制。
Checksum：16位字段，用于校验TCP头和数据的完整性。校验和的计算涉及TCP头、TCP数据以及伪首部的部分。
Urgent Pointer：16位字段，指示紧急数据的位置，仅在URG标志被设置时有效。
Options：可变长度字段，用于携带可选的TCP选项，如最大段大小（MSS）、窗口扩大因子等。
Padding：可变长度字段，用于填充，以保证TCP头长度是32位字的倍数。

面向流

TCP 不关心应用进程一次把多长的报文发送到 TCP 缓存
TCP 对连续的字节流进行分段，形成 TCP

tcp的三次握手,四次挥手

TCP连接的握手过程通常称为"三次握手"。下面是简单的描述：

第一次握手：客户端向服务器发送一个同步序列编号（SYN）标志的TCP数据包，表示客户端想要建立连接。客户端选择一个随机的初始序列号，并将其放在数据包中。
第二次握手：服务器接收到客户端发送的TCP数据包后，会回复一个带有确认序列编号（ACK）和同步序列编号（SYN）标志的数据包。服务器将确认序列编号设置为客户端的初始序列号加1，并选择自己的随机初始序列号。
第三次握手：客户端收到服务器发送的确认数据包后，会向服务器发送一个带有确认序列编号（ACK）标志的数据包，确认服务器的初始序列号。客户端将确认序列编号设置为服务器的初始序列号加1。

通过这个三次握手过程，客户端和服务器都确认彼此已准备好进行通信，建立了可靠的TCP连接。

我想,原理是双方通过序列编号互相确认传到哪了.

在关闭连接时，TCP使用四次挥手过程。下面是简单的描述：

第一次挥手：当客户端决定关闭连接时，它发送一个带有结束（FIN）标志的数据包给服务器。客户端不再发送数据，但仍然可以接收数据。
第二次挥手：服务器接收到来自客户端的结束数据包后，会发送一个带有确认（ACK）标志的数据包给客户端，表示它已收到了结束请求。
第三次挥手：服务器发送一个带有结束（FIN）标志的数据包给客户端，表示服务器也准备关闭连接。服务器不再发送数据，但仍然可以接收数据。
第四次挥手：客户端收到服务器发送的结束数据包后，发送一个带有确认（ACK）标志的数据包给服务器，确认收到了结束请求。此时，客户端和服务器都完成了关闭连接的过程。

我想,原理是双方FIN后不立即停止接受,这样保证了不错过.

FIN后得不到确认,过一段时间自己终止.

拥塞

当短暂发生输入> 输出速率时，利用队列吸收突发到来的分组
但是如果输入>输出速率持续存在，队列将溢出，即发生拥塞

➢网络层见证拥塞
• 只有它可以提供直接反馈
➢传输层导致拥塞
• 只有它可以减少提供的负载

最大-最小公平分配

计算:

所有流量从速率为0开始
增加流量，直到网络中出现新的瓶颈
固定瓶颈流量的速率
转到步骤2，查看是否有剩余流量

TCP拥塞控制

慢启动（Slow Start）：在TCP连接刚建立时，发送方会以较小的拥塞窗口（Congestion Window）开始发送数据。然后，每当收到一个确认（ACK）时，拥塞窗口会按指数增加，这导致发送方逐渐加大发送的数据量。
拥塞避免（Congestion Avoidance）：当拥塞窗口达到一个阈值（拥塞避免阈值）时，发送方会采用线性增加的方式增加拥塞窗口，而不是指数增加。这有助于避免过快地占用网络资源，以减少拥塞的发生。
快速重传（Fast Retransmit）：如果发送方连续收到3个重复的确认，这表明有一个数据包丢失，发送方会立即重传该数据包，而不必等待超时。

重复的ACK：当接收方收到乱序的数据包时，它会发送重复的ACK，其中确认序列号与之前已经确认过的数据包的序列号相同。这是因为接收方只需告知发送方它已经收到数据，并期望接收(按照顺序的)下一个数据包。

接收方只在收到连续的、按顺序的数据包时才会发送连续的ACK。如果发送方接收到重复的ACK，意味着接收方收到了后续的数据包，但未收到之前的某个数据包。
快速恢复（Fast Recovery）：在进行快速重传后，发送方会将拥塞窗口减半，然后逐渐增加。这有助于减少拥塞的影响，并在不必等待超时的情况下恢复发送速率。
拥塞超时（Timeout）：如果发送方在一段时间内没有收到确认，就认为有一个数据包丢失，并将拥塞窗口减半，然后重新开始慢启动过程。

拥塞窗口(CWND congestion window)的目标是带宽延迟乘积（Bandwidth Delay Product）

带宽延迟乘积在 TCP 拥塞控制中用于确定合适的发送窗口大小。它由网络链路的带宽和往返时延（Round-Trip Time，RTT）的乘积得出。带宽延迟乘积代表了在网络链路中可以容纳的未确认数据量。通过设置拥塞窗口大小为带宽延迟乘积，TCP 可以在不超过链路容量的情况下充分利用网络带宽。

具体来说，带宽延迟乘积等于链路的传输速率（以比特/秒为单位）乘以 RTT（以秒为单位）。例如，如果链路的带宽是 1 Mbps，RTT 是 100 毫秒，那么带宽延迟乘积就是 1 Mbps * 0.1 秒 = 100,000 比特。这意味着 TCP 发送窗口的大小应该与此相当，以便充分利用链路容量。

AIMD是加法增大乘法减小的缩写，是一种用于TCP拥塞控制的算法1它的基本思想是：当网络没有出现拥塞时，就逐渐增大拥塞窗口，使发送速率按线性规律增长；当网络出现拥塞时，就大幅减小拥塞窗口，使发送速率按指数规律下降2AI和MD分别指的是加法增大和乘法减小的过程。加法增大是指每经过一个往返时间RTT，就把拥塞窗口增加一个最大报文段的大小；乘法减小是指当发生超时或连续三个重复确认时，就把拥塞窗口减半

客户端状态名	客户端状态解释	服务器端状态名	服务器端状态解释
CLOSED	初始状态，没有活动的TCP连接	CLOSED	初始状态，没有活动的TCP连接
SYN_SENT	客户端发送SYN报文请求建立连接	SYN_RECEIVED	服务器端接收到SYN报文，等待对应的ACK报文
ESTABLISHED	连接已建立，双方可以传输数据	ESTABLISHED	连接已建立，双方可以传输数据
FIN_WAIT_1	客户端发送了连接释放请求（FIN报文）	CLOSE_WAIT	服务器端接收到连接释放请求（FIN报文）
FIN_WAIT_2	客户端接收到服务器端的连接释放确认（ACK报文）	LAST_ACK	服务器端发送了（FIN报文），等待关闭
TIME_WAIT	收到服务器端的（FIN报文）等待可能的延迟报文重传结束	LAST_ACK
CLOSED	连接已关闭，无活动的TCP连接	CLOSED	收到客户端的ACK,连接已关闭，无活动的TCP连接

主动关闭：主动关闭是指发起关闭连接的一方，通常是客户端。在主动关闭中，客户端发送连接释放请求（FIN报文），并等待服务器端的确认（ACK报文）。主动关闭的一方会主动发起关闭操作，即主动发送关闭请求。
被动关闭：被动关闭是指接收到关闭请求的一方，通常是服务器端。在被动关闭中，服务器端接收到客户端发送的连接释放请求（FIN报文），并发送确认（ACK报文）。被动关闭的一方会被动地接受关闭请求，并发送确认响应。

ACK时钟

滑动窗口的 ACK 时钟是指在 TCP 协议中，接收方使用的一种机制，用于确定何时发送确认（ACK）以确认已接收的数据。

在 TCP 的滑动窗口协议中，接收方会维护一个接收窗口（Receive Window），用于指示发送方可以发送的数据量。发送方根据接收方的接收窗口大小来确定发送的数据量，并将数据分成多个数据段发送。

接收方收到数据后，会使用 ACK 时钟来决定何时发送确认。ACK 时钟是一个计时器，接收方会在收到数据后启动该计时器。计时器的持续时间通常是一个较小的时间间隔，例如几毫秒。

接收方会在 ACK 时钟计时器到期之前收集接收到的数据，并将一个确认（ACK）发送给发送方。这样可以减少确认的数量，并提高传输效率。当 ACK 时钟到期时，接收方会发送确认，即使接收窗口中还有一些数据尚未完全接收。

通过使用 ACK 时钟，接收方可以尽量将多个 ACK 集中发送，以减少网络中的确认流量。这有助于提高网络的利用率和传输效率。

ACK保持确定的速率传回发送端 (这个速率基本撒谎给你等于最慢链路的速率,这样链路中的队列就不存在了,传输更加稳定.)

计算:TCP拥塞控制

• 例如，网络： 10Mbps， RTT=100ms
• 目标：拥塞窗口cwnd = 带宽延迟积 =10×0.1= 1Mb = 网络中能够承载的数据量

或者说,速率大致为 cwnd/RTT

传输层进阶

我估计主要是了解…可以对比着知道每一种新协议采取什么手段解决了什么问题大概就ok了

拥塞控制

原有tcp拥塞控制有什么问题?

tahoe:重新慢启动–>下凸
reno MD:窗口减半–>锯齿状

如果带宽时延积(BDP)比较大,加性探测时间较长,窗口呈锯齿状,很多带宽未利用

考虑TCP-BIC

TCP-BIC: Binary Increase Congestio–>上凸

折半查找,大大快于线性查找

BIC存在带宽不公平性问题

BIC以ACK时钟驱动拥塞窗口的更新， RTT较短的连接会更快到达满载窗口，占据更多的带宽，产生不公平性问题（RTT-fairness）

CUBIC

不再根据RTT间隔调整窗口,而是将BIC连续化用三次函数拟合BIC算法曲线.

拥塞窗口从RTT的函数变成时间t的函数

新的BDP:BBR

BBR: Bottleneck Bandwidth and Round-trip time，

带宽时延积： BDP=BtlBw*RTprop

BBR的优化思路
• 试图测量最佳点（即BtlBw）
• 尽量将cwnd收敛到BtlBw
• 从而避免拥塞丢包和排队

但是

Max BW和min RTT不能同时被测得

• 要测最低延迟RTprop ，就要保证链路队列为空，网络中分组越少越好， cwnd较小
• 要测最大带宽BtlBw ，就要把瓶颈链路填满，此时buffer中存在排队分组，延迟较高

新型传输层协议QUIC

建立相互独立的多个子流,一个子流数据包丢失不影响其他子流

以Connection ID识别连接，即使IP地址/端口发生变化也无需重连

TCP存在的问题

RTO造成队头阻塞，严重降低传输性能 \

RTO（Retransmission Time Out）是 TCP（传输控制协议）中的一个参数，用于确定在未收到确认的情况下，发送方重传数据的等待时间。

TCP多流复用加剧了队头阻塞

如网页传输中，每个单独的图片即为一个数据流，不同数据流之间相互独立,为每个数据建立一个TCP连接很低效/因此出现了多流复用

多流复用时,任何一个流被阻塞所有流都会被阻塞

QUIC解决方案

建立相互独立的多个子流,一个子流数据包丢失不影响其他子流

TCP重传歧义

TCP的重传包使用和原包相同的序号,返回的ACK不能确定是对原包还是重传包,导致RTT计算错误.

quic解决方案

• QUIC的packet number单调递增，对于重传包也会递增packet number，避免RTO
• 每个packet number只会出现一次， ACK没有歧义！
• QUIC接收端记录收到包与发出ACK之间的时延，并发馈给发送端，方便发送端更准确地测量RTT

TCP基于ip:端口

QUIC基于connection id

• QUIC使用Connection ID来表示每个连接
• IP地址或端口的变化不影响对原有连接的识别
• 客户IP地址或端口发生变化时， QUIC可以快速恢复

支持wifi到数据的链接

传输协议QUIC-小结

➢为什么需要QUIC： TCP存在的问题

• RTO队头阻塞问题，多流复用加剧
• TCP握手过程引入很大的时延
• 移动用户底层短连接，难以支撑上层业务的长连接
• 应用优化TCP的难度高

➢QUIC协议

• 基于UDP在跨层优化的用户态实现
• 优化了TLS加密建连的握手过程
• 优化重传，包序号持续递增，避免RTO并实现精准RTT测量
• 以Connection ID识别连接，即使IP地址/端口发生变化也无需重连
• 各个流的传输相互独立，消除了队头阻塞问题

多路径传输协议MPTCP-小结

➢动机：网络设备通常有多个接口

➢优势

• 带宽聚合、可靠性、平滑切换链路

➢MPTCP连接管理

• 基于TCP实现，单个路径上运行一个TCP流
• 未改变TCP头的基础定义，仅添加新的选项
• 连接过程：初始化、附加子流、路径管理、关闭连接

➢MPTCP数据调度

• 将属于同一个数据流的数据包调度到不同的路径上传输
• 降低数据乱序到达对网络性能产生的不利影响

就是说,既然一个网络设备有多个接口,我就全用上,多一个总比少一个好

DC(Data Center)TCP核心思想

➢根据交换机队列的瞬时长度标记ECN (Explicit Congestion Notification)

• 使用显式的拥塞反馈能够更好地控制突发流量

➢根据拥塞程度精细调整发送窗口

• TCP: 𝑐𝑤𝑛𝑑 ← 𝑐𝑤𝑛𝑑/2
• DCTCP: 𝑐𝑤𝑛𝑑 ← 𝑐𝑤𝑛𝑑 × 1 - 𝛼/2
• 𝛼: 使用显示拥塞信号得到的“拥塞程度–+*47\

*±99999999999999999999999999999999