mirror of
https://github.com/CyC2018/Interview-Notebook.git
synced 2026-10-29 23:23:43 +00:00
Merge pull request #1500 from CyC2018/update-os-network-notes-2
Update OS and network notes
This commit is contained in:
CyC2018
+14
-14
@@ -44,13 +44,13 @@
|
||||
* [TLS 握手](#tls-握手)
|
||||
* [完整性保护](#完整性保护)
|
||||
* [HTTPS 的缺点](#https-的缺点)
|
||||
* [七、HTTP/2.0](#七http20)
|
||||
* [七、HTTP/1.1 新特性](#七http11-新特性)
|
||||
* [八、HTTP/2.0](#八http20)
|
||||
* [HTTP/1.x 缺陷](#http1x-缺陷)
|
||||
* [二进制分帧层](#二进制分帧层)
|
||||
* [服务端推送](#服务端推送)
|
||||
* [首部压缩](#首部压缩)
|
||||
* [HTTP/3](#http3)
|
||||
* [八、HTTP/1.1 新特性](#八http11-新特性)
|
||||
* [九、GET 和 POST 比较](#九get-和-post-比较)
|
||||
* [作用](#作用)
|
||||
* [参数](#参数)
|
||||
@@ -994,7 +994,18 @@ HTTPS 的报文摘要功能之所以安全，是因为计算摘要时用到了
|
||||
- 因为需要进行加密解密等过程，因此速度会更慢；
|
||||
- 需要申请和维护证书，不过 Let's Encrypt 等机构可以免费签发证书。
|
||||
|
||||
## 七、HTTP/2.0
|
||||
## 七、HTTP/1.1 新特性
|
||||
|
||||
与 HTTP/1.0 相比，HTTP/1.1 主要增加了以下特性，详细内容见上文：
|
||||
|
||||
- 默认使用长连接；
|
||||
- 支持流水线；
|
||||
- 请求必须带 Host 首部，从而支持虚拟主机；
|
||||
- 新增状态码 100 Continue；
|
||||
- 支持分块传输编码；
|
||||
- 新增缓存处理指令 max-age 和条件请求 If-None-Match。
|
||||
|
||||
## 八、HTTP/2.0
|
||||
|
||||
### HTTP/1.x 缺陷
|
||||
|
||||
@@ -1050,17 +1061,6 @@ UDP 本身不保证可靠，QUIC 在它之上自己实现了确认、重传和
|
||||
|
||||
浏览器通常先用 HTTP/2 访问，从响应首部 Alt-Svc 得知服务器支持 HTTP/3 后再切换，例如 www.example.com 的响应中有 alt-svc: h3=":443"; ma=86400。
|
||||
|
||||
## 八、HTTP/1.1 新特性
|
||||
|
||||
与 HTTP/1.0 相比，HTTP/1.1 主要增加了以下特性，详细内容见上文：
|
||||
|
||||
- 默认使用长连接；
|
||||
- 支持流水线；
|
||||
- 请求必须带 Host 首部，从而支持虚拟主机；
|
||||
- 新增状态码 100 Continue；
|
||||
- 支持分块传输编码；
|
||||
- 新增缓存处理指令 max-age 和条件请求 If-None-Match。
|
||||
|
||||
## 九、GET 和 POST 比较
|
||||
|
||||
### 作用
|
||||
|
||||
+1
-1
@@ -103,7 +103,7 @@ ssize_t recvfrom(int sockfd, void *buf, size_t len, int flags, struct sockaddr *
|
||||
|
||||
I/O 复用（I/O multiplexing）指用一个系统调用同时等待多个描述符，其中任何一个就绪就返回。Linux 上的实现依次为 select、poll 和 epoll，epoll 解决了前两者在描述符数量很多时的性能问题。
|
||||
|
||||
这里的多路复用指内核对描述符的事件通知，与 HTTP/2 在一个 TCP 连接上并发多个流不是同一个概念，见 [HTTP/2.0](HTTP.md#七http20)。
|
||||
这里的多路复用指内核对描述符的事件通知，与 HTTP/2 在一个 TCP 连接上并发多个流不是同一个概念，见 [HTTP/2.0](HTTP.md#八http20)。
|
||||
|
||||
下面用一个例子贯穿全节：服务器维护 10000 个空闲连接，任意时刻只有 1 个连接可读。
|
||||
|
||||
|
||||
@@ -120,7 +120,7 @@ Linux 的系统调用主要有以下这些：
|
||||
- 内核入口和出口的额外工作，例如启用页表隔离（Page Table Isolation, PTI，用于缓解 Meltdown 攻击）时，每次进入和退出内核都要写 CR3，内核文档给出的量级是百余个周期；
|
||||
- 内核执行的工作本身，例如参数检查、查找文件、复制数据。
|
||||
|
||||
需要注意的是，陷入内核不等于切换进程：系统调用执行完通常回到同一个线程，不一定发生上下文切换，见[进程管理](计算机操作系统%20-%20进程管理.md#5-上下文切换)。
|
||||
需要注意的是，陷入内核不等于切换进程：系统调用执行完通常回到同一个线程，不一定发生上下文切换，见[进程管理](计算机操作系统%20-%20进程管理.md#4-上下文切换)。
|
||||
|
||||
减少系统调用开销的做法主要有以下几种：
|
||||
|
||||
|
||||
@@ -2,6 +2,7 @@
|
||||
|
||||
- [概述](计算机操作系统%20-%20概述.md)
|
||||
- [进程管理](计算机操作系统%20-%20进程管理.md)
|
||||
- [进程管理 - 进阶](计算机操作系统%20-%20进程管理%20-%20进阶.md)
|
||||
- [死锁](计算机操作系统%20-%20死锁.md)
|
||||
- [内存管理](计算机操作系统%20-%20内存管理.md)
|
||||
- [设备管理](计算机操作系统%20-%20设备管理.md)
|
||||
|
||||
@@ -0,0 +1,128 @@
|
||||
# 计算机操作系统 - 进程管理 - 进阶
|
||||
<!-- GFM-TOC -->
|
||||
* [计算机操作系统 - 进程管理 - 进阶](#计算机操作系统---进程管理---进阶)
|
||||
* [经典同步问题](#经典同步问题)
|
||||
* [读者-写者问题](#读者-写者问题)
|
||||
* [参考资料](#参考资料)
|
||||
<!-- GFM-TOC -->
|
||||
|
||||
|
||||
## 经典同步问题
|
||||
|
||||
### 读者-写者问题
|
||||
|
||||
主线见[计算机操作系统 - 进程管理 · 读者-写者问题](计算机操作系统%20-%20进程管理.md#2-读者-写者问题)，那里用 count、count_mutex 和 data_mutex 实现的是读者优先：只要还有读者在读，后到的读者可以直接进入，写者要一直等待。
|
||||
|
||||
以下内容由 [@Bandi Yugandhar](https://github.com/yugandharbandi) 提供。
|
||||
|
||||
主线中的实现可能导致写者饥饿。下面的实现是写者优先的：写者进入队列之后，只需要等待在它之前进入的读者，不会被之后到达的读者一直阻塞。
|
||||
|
||||
```c
|
||||
int readcount, writecount; //(initial value = 0)
|
||||
semaphore rmutex, wmutex, readLock, resource; //(initial value = 1)
|
||||
|
||||
//READER
|
||||
void reader() {
|
||||
<ENTRY Section>
|
||||
down(&readLock); // reader is trying to enter
|
||||
down(&rmutex); // lock to increase readcount
|
||||
readcount++;
|
||||
if (readcount == 1)
|
||||
down(&resource); //if you are the first reader then lock the resource
|
||||
up(&rmutex); //release for other readers
|
||||
up(&readLock); //Done with trying to access the resource
|
||||
|
||||
<CRITICAL Section>
|
||||
//reading is performed
|
||||
|
||||
<EXIT Section>
|
||||
down(&rmutex); //reserve exit section - avoids race condition with readers
|
||||
readcount--; //indicate you're leaving
|
||||
if (readcount == 0) //checks if you are last reader leaving
|
||||
up(&resource); //if last, you must release the locked resource
|
||||
up(&rmutex); //release exit section for other readers
|
||||
}
|
||||
|
||||
//WRITER
|
||||
void writer() {
|
||||
<ENTRY Section>
|
||||
down(&wmutex); //reserve entry section for writers - avoids race conditions
|
||||
writecount++; //report yourself as a writer entering
|
||||
if (writecount == 1) //checks if you're first writer
|
||||
down(&readLock); //if you're first, then you must lock the readers out. Prevent them from trying to enter CS
|
||||
up(&wmutex); //release entry section
|
||||
|
||||
<CRITICAL Section>
|
||||
down(&resource); //reserve the resource for yourself - prevents other writers from simultaneously editing the shared resource
|
||||
//writing is performed
|
||||
up(&resource); //release file
|
||||
|
||||
<EXIT Section>
|
||||
down(&wmutex); //reserve exit section
|
||||
writecount--; //indicate you're leaving
|
||||
if (writecount == 0) //checks if you're the last writer
|
||||
up(&readLock); //if you're last writer, you must unlock the readers. Allows them to try enter CS for reading
|
||||
up(&wmutex); //release exit section
|
||||
}
|
||||
```
|
||||
|
||||
每个读者都必须先获取 readLock，而只有第一个写者需要获取 readLock，并且直到队列中没有写者时才会释放，因此这种实现可能导致读者饥饿。
|
||||
|
||||
以上两种实现总有一方可能饥饿。下面的实现使用一个先进先出的 serviceQueue 让读者和写者按到达顺序排队，获取共享数据的锁总能在有限时间内完成，因此不会出现饥饿。
|
||||
|
||||
```c
|
||||
int readCount; // init to 0; number of readers currently accessing resource
|
||||
|
||||
// all semaphores initialised to 1
|
||||
Semaphore resourceAccess; // controls access (read/write) to the resource
|
||||
Semaphore readCountAccess; // for syncing changes to shared variable readCount
|
||||
Semaphore serviceQueue; // FAIRNESS: preserves ordering of requests (signaling must be FIFO)
|
||||
|
||||
void writer()
|
||||
{
|
||||
down(&serviceQueue); // wait in line to be serviced
|
||||
// <ENTER>
|
||||
down(&resourceAccess); // request exclusive access to resource
|
||||
// </ENTER>
|
||||
up(&serviceQueue); // let next in line be serviced
|
||||
|
||||
// <WRITE>
|
||||
writeResource(); // writing is performed
|
||||
// </WRITE>
|
||||
|
||||
// <EXIT>
|
||||
up(&resourceAccess); // release resource access for next reader/writer
|
||||
// </EXIT>
|
||||
}
|
||||
|
||||
void reader()
|
||||
{
|
||||
down(&serviceQueue); // wait in line to be serviced
|
||||
down(&readCountAccess); // request exclusive access to readCount
|
||||
// <ENTER>
|
||||
if (readCount == 0) // if there are no readers already reading:
|
||||
down(&resourceAccess); // request resource access for readers (writers blocked)
|
||||
readCount++; // update count of active readers
|
||||
// </ENTER>
|
||||
up(&serviceQueue); // let next in line be serviced
|
||||
up(&readCountAccess); // release access to readCount
|
||||
|
||||
// <READ>
|
||||
readResource(); // reading is performed
|
||||
// </READ>
|
||||
|
||||
down(&readCountAccess); // request exclusive access to readCount
|
||||
// <EXIT>
|
||||
readCount--; // update count of active readers
|
||||
if (readCount == 0) // if there are no readers left:
|
||||
up(&resourceAccess); // release resource access for all
|
||||
// </EXIT>
|
||||
up(&readCountAccess); // release access to readCount
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
## 参考资料
|
||||
|
||||
- Tanenbaum A S, Bos H. Modern Operating Systems [M]. Pearson, 2014.
|
||||
- [Readers–writers problem - Wikipedia](https://en.wikipedia.org/wiki/Readers%E2%80%93writers_problem)
|
||||
+18
-125
@@ -5,8 +5,8 @@
|
||||
* [1. 进程](#1-进程)
|
||||
* [2. 线程](#2-线程)
|
||||
* [3. 区别](#3-区别)
|
||||
* [4. 协程](#4-协程)
|
||||
* [5. 上下文切换](#5-上下文切换)
|
||||
* [4. 上下文切换](#4-上下文切换)
|
||||
* [5. 协程](#5-协程)
|
||||
* [进程状态的切换](#进程状态的切换)
|
||||
* [进程调度算法](#进程调度算法)
|
||||
* [1. 批处理系统](#1-批处理系统)
|
||||
@@ -74,7 +74,21 @@ QQ 和浏览器是两个进程，浏览器进程里面有很多线程，例如 H
|
||||
- 任务之间需要隔离、一个出错不能拖垮其它任务时用多进程，例如 Chrome 把网页放在单独的渲染进程中，一个网页崩溃不影响浏览器和其它标签页；执行不受信任的代码（例如 Agent 运行模型生成的脚本）也应该放在单独的进程甚至容器中；
|
||||
- 任务之间要频繁共享数据、对创建和切换的开销敏感时用多线程，例如 Web 服务器用线程池处理请求，各线程直接读写同一份本地缓存。
|
||||
|
||||
### 4. 协程
|
||||
### 4. 上下文切换
|
||||
|
||||
上下文切换指的是 CPU 从执行一个线程改为执行另一个线程时，把当前线程的寄存器、程序计数器、栈指针等保存起来，再恢复另一个线程上次保存的值。以下情况会发生上下文切换：
|
||||
|
||||
- 时间片用完，被调度程序换下；
|
||||
- 线程主动阻塞，例如等待 I/O、等待锁、调用 sleep()；
|
||||
- 更高优先级的线程进入就绪状态。
|
||||
|
||||
需要注意的是，系统调用只是从用户态进入内核态，执行完后通常回到同一个线程，不一定发生上下文切换。
|
||||
|
||||
同一进程中的线程切换不需要换地址空间；切换到另一个进程时还要切换页表，TLB 和 CPU 缓存中原来的地址映射和数据对新进程没有用，要重新加载，这部分间接开销通常比保存寄存器更大。x86 的 PCID 可以给 TLB 表项标上所属的地址空间，切换页表时不必清空整个 TLB，没有 PCID 时每次切换页表都会清空 TLB。
|
||||
|
||||
例如把两个执行流固定在同一个 CPU 上，通过两根管道来回传 1 个字节，让它们交替运行，两个线程之间、两个进程之间每次切换都约 1.1 微秒，包含一次 read 或 write 系统调用（Linux 实测，见[附录 A1](#a1-上下文切换)）。数据量很小时两者几乎没有差别，进程切换的额外开销主要在工作集较大时体现出来。线程过多、频繁阻塞时，CPU 会把相当一部分时间花在切换上，可以用 vmstat 的 cs 列或 pidstat -w 观察每秒的切换次数。
|
||||
|
||||
### 5. 协程
|
||||
|
||||
协程（Coroutine）是在用户态实现的轻量级线程，由程序自己调度，而不是由操作系统内核调度。协程在等待 I/O 时主动让出执行权，运行时再把其它协程调度到同一个线程上执行。
|
||||
|
||||
@@ -97,20 +111,6 @@ Java 21 正式引入的虚拟线程（[JEP 444](https://openjdk.org/jeps/444)）
|
||||
|
||||
协程也不能无限创建：每个协程的栈和状态都要占内存，例如把最大堆设为 256 MB 时，启动 100 万个阻塞的虚拟线程会抛出 OutOfMemoryError。协程适合大量任务都在等待 I/O 的场景，例如每个请求都要调用下游接口、查询数据库；CPU 密集的任务没有等待可以让出，开再多协程也只能由少量线程轮流执行，不会更快。
|
||||
|
||||
### 5. 上下文切换
|
||||
|
||||
上下文切换指的是 CPU 从执行一个线程改为执行另一个线程时，把当前线程的寄存器、程序计数器、栈指针等保存起来，再恢复另一个线程上次保存的值。以下情况会发生上下文切换：
|
||||
|
||||
- 时间片用完，被调度程序换下；
|
||||
- 线程主动阻塞，例如等待 I/O、等待锁、调用 sleep()；
|
||||
- 更高优先级的线程进入就绪状态。
|
||||
|
||||
需要注意的是，系统调用只是从用户态进入内核态，执行完后通常回到同一个线程，不一定发生上下文切换。
|
||||
|
||||
同一进程中的线程切换不需要换地址空间；切换到另一个进程时还要切换页表，TLB 和 CPU 缓存中原来的地址映射和数据对新进程没有用，要重新加载，这部分间接开销通常比保存寄存器更大。x86 的 PCID 可以给 TLB 表项标上所属的地址空间，切换页表时不必清空整个 TLB，没有 PCID 时每次切换页表都会清空 TLB。
|
||||
|
||||
例如把两个执行流固定在同一个 CPU 上，通过两根管道来回传 1 个字节，让它们交替运行，两个线程之间、两个进程之间每次切换都约 1.1 微秒，包含一次 read 或 write 系统调用（Linux 实测，见[附录 A1](#a1-上下文切换)）。数据量很小时两者几乎没有差别，进程切换的额外开销主要在工作集较大时体现出来。线程过多、频繁阻塞时，CPU 会把相当一部分时间花在切换上，可以用 vmstat 的 cs 列或 pidstat -w 观察每秒的切换次数。
|
||||
|
||||
## 进程状态的切换
|
||||
|
||||
<div align="center"> <img src="pics/process-states.png" width="720px"/> </div><br>
|
||||
@@ -468,114 +468,7 @@ void writer() {
|
||||
}
|
||||
```
|
||||
|
||||
以下内容由 [@Bandi Yugandhar](https://github.com/yugandharbandi) 提供。
|
||||
|
||||
上面的实现可能导致写者饥饿。下面的实现是写者优先的：写者进入队列之后，只需要等待在它之前进入的读者，不会被之后到达的读者一直阻塞。
|
||||
|
||||
```c
|
||||
int readcount, writecount; //(initial value = 0)
|
||||
semaphore rmutex, wmutex, readLock, resource; //(initial value = 1)
|
||||
|
||||
//READER
|
||||
void reader() {
|
||||
<ENTRY Section>
|
||||
down(&readLock); // reader is trying to enter
|
||||
down(&rmutex); // lock to increase readcount
|
||||
readcount++;
|
||||
if (readcount == 1)
|
||||
down(&resource); //if you are the first reader then lock the resource
|
||||
up(&rmutex); //release for other readers
|
||||
up(&readLock); //Done with trying to access the resource
|
||||
|
||||
<CRITICAL Section>
|
||||
//reading is performed
|
||||
|
||||
<EXIT Section>
|
||||
down(&rmutex); //reserve exit section - avoids race condition with readers
|
||||
readcount--; //indicate you're leaving
|
||||
if (readcount == 0) //checks if you are last reader leaving
|
||||
up(&resource); //if last, you must release the locked resource
|
||||
up(&rmutex); //release exit section for other readers
|
||||
}
|
||||
|
||||
//WRITER
|
||||
void writer() {
|
||||
<ENTRY Section>
|
||||
down(&wmutex); //reserve entry section for writers - avoids race conditions
|
||||
writecount++; //report yourself as a writer entering
|
||||
if (writecount == 1) //checks if you're first writer
|
||||
down(&readLock); //if you're first, then you must lock the readers out. Prevent them from trying to enter CS
|
||||
up(&wmutex); //release entry section
|
||||
|
||||
<CRITICAL Section>
|
||||
down(&resource); //reserve the resource for yourself - prevents other writers from simultaneously editing the shared resource
|
||||
//writing is performed
|
||||
up(&resource); //release file
|
||||
|
||||
<EXIT Section>
|
||||
down(&wmutex); //reserve exit section
|
||||
writecount--; //indicate you're leaving
|
||||
if (writecount == 0) //checks if you're the last writer
|
||||
up(&readLock); //if you're last writer, you must unlock the readers. Allows them to try enter CS for reading
|
||||
up(&wmutex); //release exit section
|
||||
}
|
||||
```
|
||||
|
||||
每个读者都必须先获取 readLock，而只有第一个写者需要获取 readLock，并且直到队列中没有写者时才会释放，因此这种实现可能导致读者饥饿。
|
||||
|
||||
以上两种实现总有一方可能饥饿。下面的实现使用一个先进先出的 serviceQueue 让读者和写者按到达顺序排队，获取共享数据的锁总能在有限时间内完成，因此不会出现饥饿。
|
||||
|
||||
```c
|
||||
int readCount; // init to 0; number of readers currently accessing resource
|
||||
|
||||
// all semaphores initialised to 1
|
||||
Semaphore resourceAccess; // controls access (read/write) to the resource
|
||||
Semaphore readCountAccess; // for syncing changes to shared variable readCount
|
||||
Semaphore serviceQueue; // FAIRNESS: preserves ordering of requests (signaling must be FIFO)
|
||||
|
||||
void writer()
|
||||
{
|
||||
down(&serviceQueue); // wait in line to be serviced
|
||||
// <ENTER>
|
||||
down(&resourceAccess); // request exclusive access to resource
|
||||
// </ENTER>
|
||||
up(&serviceQueue); // let next in line be serviced
|
||||
|
||||
// <WRITE>
|
||||
writeResource(); // writing is performed
|
||||
// </WRITE>
|
||||
|
||||
// <EXIT>
|
||||
up(&resourceAccess); // release resource access for next reader/writer
|
||||
// </EXIT>
|
||||
}
|
||||
|
||||
void reader()
|
||||
{
|
||||
down(&serviceQueue); // wait in line to be serviced
|
||||
down(&readCountAccess); // request exclusive access to readCount
|
||||
// <ENTER>
|
||||
if (readCount == 0) // if there are no readers already reading:
|
||||
down(&resourceAccess); // request resource access for readers (writers blocked)
|
||||
readCount++; // update count of active readers
|
||||
// </ENTER>
|
||||
up(&serviceQueue); // let next in line be serviced
|
||||
up(&readCountAccess); // release access to readCount
|
||||
|
||||
// <READ>
|
||||
readResource(); // reading is performed
|
||||
// </READ>
|
||||
|
||||
down(&readCountAccess); // request exclusive access to readCount
|
||||
// <EXIT>
|
||||
readCount--; // update count of active readers
|
||||
if (readCount == 0) // if there are no readers left:
|
||||
up(&resourceAccess); // release resource access for all
|
||||
// </EXIT>
|
||||
up(&readCountAccess); // release access to readCount
|
||||
}
|
||||
|
||||
```
|
||||
这种实现在读者源源不断时可能导致写者饥饿，写者优先和按到达顺序排队的公平实现见[进阶：读者-写者问题](计算机操作系统%20-%20进程管理%20-%20进阶.md#读者-写者问题)。
|
||||
|
||||
## 进程通信
|
||||
|
||||
|
||||
+23
-19
@@ -3,7 +3,6 @@
|
||||
* [计算机网络 - 传输层](#计算机网络---传输层)
|
||||
* [UDP 和 TCP 的特点](#udp-和-tcp-的特点)
|
||||
* [选择 TCP 还是 UDP](#选择-tcp-还是-udp)
|
||||
* [在 UDP 上实现可靠传输](#在-udp-上实现可靠传输)
|
||||
* [UDP 首部格式](#udp-首部格式)
|
||||
* [TCP 首部格式](#tcp-首部格式)
|
||||
* [TCP 的三次握手](#tcp-的三次握手)
|
||||
@@ -20,6 +19,7 @@
|
||||
* [1. 慢开始与拥塞避免](#1-慢开始与拥塞避免)
|
||||
* [2. 快重传与快恢复](#2-快重传与快恢复)
|
||||
* [TCP 粘包与拆包](#tcp-粘包与拆包)
|
||||
* [在 UDP 上实现可靠传输](#在-udp-上实现可靠传输)
|
||||
* [附录：实测](#附录实测)
|
||||
* [A1 TCP 与 UDP 发送位置更新](#a1-tcp-与-udp-发送位置更新)
|
||||
* [A2 握手报文丢失](#a2-握手报文丢失)
|
||||
@@ -52,23 +52,7 @@ TCP 的可靠和按序是有代价的：一个报文段丢失后，后面已经
|
||||
|
||||
5 次实测中，TCP 的 600 条更新全部到达，但有 24～53 条的延迟超过 100 ms，最长 307～939 ms，到达时位置早已过时；UDP 丢失了 23～30 条，到达的延迟都不超过 44 ms，丢失的那一条由 50 ms 后的下一次更新补上。
|
||||
|
||||
### 在 UDP 上实现可靠传输
|
||||
|
||||
游戏中的位置可以丢，购买道具、释放技能这类消息却必须送达。既要 UDP 的低延迟、又有一部分数据必须可靠时，就要在应用层按 TCP 的思路自己实现：
|
||||
|
||||
- 序号：给每个数据包编号，接收方据此去重和排序；
|
||||
- 确认和重传：接收方回复确认，发送方超时没有收到确认就重传，超时时间根据测得的 RTT 计算；
|
||||
- 流量控制和拥塞控制：限制已发送但未确认的数据量，避免压垮接收方和网络。
|
||||
|
||||
与直接使用 TCP 相比，好处在于可以按需取舍：只对需要的消息重传，不相关的消息互不阻塞，重传和拥塞控制的参数也可以按业务调整。
|
||||
|
||||
HTTP/3 使用的 QUIC 就是在 UDP 上实现的可靠传输，并改进了 TCP 的几处设计：
|
||||
|
||||
- 包号只增不减，丢失的数据放进一个新编号的包中重传。收到确认时能分清确认的是哪一次发送，RTT 测得更准；TCP 重传时沿用原来的序号，无法区分；
|
||||
- 数据按流（Stream）组织，每个流按帧中的偏移量单独排序，一个流丢包不影响其它流；
|
||||
- 一个确认帧可以携带很多个已收到的区间，TCP 的选择确认（SACK）受首部长度限制，通常最多携带 3 个区间。
|
||||
|
||||
QUIC 选择在 UDP 上重新实现，而不是改进 TCP，是因为 TCP 实现在操作系统内核中，改动要等操作系统升级才能普及；防火墙、NAT 等中间设备还会检查甚至改写 TCP 首部，不认识的新选项可能被丢弃。QUIC 运行在用户态，随浏览器和 App 一起更新，并且加密了大部分首部，中间设备无法干预。QUIC 的握手和连接迁移见 [HTTP/3](HTTP.md#http3)。
|
||||
有一部分数据必须送达时，可以在 UDP 之上自己实现可靠传输，见[在 UDP 上实现可靠传输](#在-udp-上实现可靠传输)。
|
||||
|
||||
## UDP 首部格式
|
||||
|
||||
@@ -222,7 +206,7 @@ TCP 主要通过四个算法来进行拥塞控制：慢开始、拥塞避免、
|
||||
|
||||
### 1. 慢开始与拥塞避免
|
||||
|
||||
发送的最初执行慢开始，令 cwnd = 1，发送方只能发送 1 个报文段；当收到确认后，将 cwnd 加倍，因此之后发送方能够发送的报文段数量为：2、4、8 ...
|
||||
发送的最初执行慢开始，令 cwnd = 1，发送方只能发送 1 个报文段；每收到一个对新数据的确认，cwnd 加 1，一个轮次发出的报文段都被确认后 cwnd 就翻了一倍，因此之后每个轮次能够发送的报文段数量为：2、4、8 ...
|
||||
|
||||
实际实现中初始拥塞窗口通常更大，RFC 6928 建议初始值为 10 个报文段。
|
||||
|
||||
@@ -293,6 +277,26 @@ static String receive(DataInputStream in) throws IOException {
|
||||
|
||||
需要注意的是，长度字段来自网络，必须限制上限，否则对方发来一个 2 GB 的长度，服务器就会为它分配 2 GB 内存。
|
||||
|
||||
## 在 UDP 上实现可靠传输
|
||||
|
||||
[选择 TCP 还是 UDP](#选择-tcp-还是-udp) 中比较了游戏位置更新用 TCP 和 UDP 发送的效果。
|
||||
|
||||
游戏中的位置可以丢，购买道具、释放技能这类消息却必须送达。既要 UDP 的低延迟、又有一部分数据必须可靠时，就要在应用层按 TCP 的思路自己实现：
|
||||
|
||||
- 序号：给每个数据包编号，接收方据此去重和排序；
|
||||
- 确认和重传：接收方回复确认，发送方超时没有收到确认就重传，超时时间根据测得的 RTT 计算；
|
||||
- 流量控制和拥塞控制：限制已发送但未确认的数据量，避免压垮接收方和网络。
|
||||
|
||||
与直接使用 TCP 相比，好处在于可以按需取舍：只对需要的消息重传，不相关的消息互不阻塞，重传和拥塞控制的参数也可以按业务调整。
|
||||
|
||||
HTTP/3 使用的 QUIC 就是在 UDP 上实现的可靠传输，并改进了 TCP 的几处设计：
|
||||
|
||||
- 包号只增不减，丢失的数据放进一个新编号的包中重传。收到确认时能分清确认的是哪一次发送，RTT 测得更准；TCP 重传时沿用原来的序号，无法区分；
|
||||
- 数据按流（Stream）组织，每个流按帧中的偏移量单独排序，一个流丢包不影响其它流；
|
||||
- 一个确认帧可以携带很多个已收到的区间，TCP 的选择确认（SACK）受首部长度限制，通常最多携带 3 个区间。
|
||||
|
||||
QUIC 选择在 UDP 上重新实现，而不是改进 TCP，是因为 TCP 实现在操作系统内核中，改动要等操作系统升级才能普及；防火墙、NAT 等中间设备还会检查甚至改写 TCP 首部，不认识的新选项可能被丢弃。QUIC 运行在用户态，随浏览器和 App 一起更新，并且加密了大部分首部，中间设备无法干预。QUIC 的握手和连接迁移见 [HTTP/3](HTTP.md#http3)。
|
||||
|
||||
## 附录：实测
|
||||
|
||||
以下实验都在 Docker Desktop（Apple M1 Pro）中的 Ubuntu 24.04 容器里进行，内核为 6.10.14-linuxkit，客户端和服务器都在 127.0.0.1 上，用 iptables 丢弃指定的报文，用 tc netem 模拟时延和丢包，tcpdump 的时间换算为相对第一个报文的秒数。容器中的默认参数：
|
||||
|
||||
Reference in New Issue
Block a user