原文

HTTP可以使用UDP吗？
HTTP不可以使用UDP，HTTP需要基于可靠的传输协议，而UDP不可靠

https://zh.wikipedia.org/wiki/HTTP/3

HTTP/3 是即将到来的第三个主要版本的HTTP协议，使用于万维网。与其前任HTTP/1.1和HTTP/2不同，在HTTP/3中，将弃用TCP协议，改为使用基于UDP协议的QUIC协议实现。[1]

此变化主要为了解决HTTP/2中存在的队头阻塞问题。由于HTTP/2在单个TCP连接上使用了多路复用，受到TCP拥塞控制的影响，少量的丢包就可能导致整个TCP连接上的所有流被阻塞。

QUIC（快速UDP网络连接）是一种实验性的网络传输协议，由Google开发，该协议旨在使网页传输更快。在2018年10月28日的邮件列表讨论中，互联网工程任务组（IETF） HTTP和QUIC工作组主席Mark Nottingham提出了将HTTP-over-QUIC更名为HTTP/3的正式请求，以“明确地将其标识为HTTP语义的另一个绑定……使人们理解它与QUIC的不同”，并在最终确定并发布草案后，将QUIC工作组继承到HTTP工作组。[2] 在随后的几天讨论中，Mark Nottingham的提议得到了IETF成员的接受，他们在2018年11月给出了官方批准，认可HTTP-over-QUIC成为HTTP/3。[3]

2019年9月，HTTP/3支持已添加到Cloudflare和Google Chrome（Canary build）。Firefox Nightly将在2019年秋季之后添加支持。[4]

In computer science, an anonymous pipe is a simplex FIFO communication channel that may be used for one-way interprocess communication (IPC).

Ref: https://en.wikipedia.org/wiki/Anonymous_pipe

"什么是TCP粘包"在面试中似乎还挺常见，仓库删掉了这个问题的说明，还是有必要了解一下的。首先“TCP粘包”不是TCP的问题，而是应用开发者的问题。

现象：一次recv就得到了多次send的数据,就好像多次发送的数据粘在了一起。
原因：因为TCP是面向字节流的,只负责把数据以有序的字节流的形式发出，把几次发过来的数据区分开是应用层需要做的事情。
处理办法：
1.固定包长的数据包。
顾名思义，即每个协议包的长度都是固定的。举个例子，例如我们可以规定每个协议包的大小是 64 个字节，每次收满 64 个字节，就取出来解析（如果不够，就先存起来）。这种通信协议的格式简单但灵活性差。如果包内容不足指定的字节数，剩余的空间需要填充特殊的信息，如 \0（如果不填充特殊内容，如何区分包里面的正常内容与填充信息呢？）；如果包内容超过指定字节数，又得分包分片，需要增加额外处理逻辑——在发送端进行分包分片，在接收端重新组装包片（分包和分片内容在接下来会详细介绍）。
2. 以指定字符（串）为包的结束标志。
这种协议包比较常见，即字节流中遇到特殊的符号值时就认为到一个包的末尾了。例如，我们熟悉的 FTP协议，发邮件的 SMTP 协议，一个命令或者一段数据后面加上"\r\n"（即所谓的 CRLF）表示一个包的结束。对端收到后，每遇到一个”\r\n“就把之前的数据当做一个数据包。这种协议一般用于一些包含各种命令控制的应用中，其不足之处就是如果协议数据包内容部分需要使用包结束标志字符，就需要对这些字符做转码或者转义操作，以免被接收方错误地当成包结束标志而误解析。
3. 包头 + 包体格式。
这种格式的包一般分为两部分，即包头和包体，包头是固定大小的，且包头中必须含有一个字段来说明接下来的包体有多大。

参考资料：https://www.zhihu.com/question/20210025

借这个仓库补充了很多知识。看到操作系统最下方 TODO 里有 IPC，分享一下我最近在复习时总结的笔记，希望对其他同学有帮助：

1. 进程间的通信方式
2. I/O 多路复用、select / poll / epoll

补充一下我的校招面试题汇总分享，大家可以作为本仓库的补充阅读资料：

https://imageslr.com/2020/07/08/tech-interview.html

校招经验分享：

https://imageslr.com/2021/autumn-recruit.html

MySQL架构

MySQL日志

错误日志：记录出错信息，也记录一些警告信息或者正确的信息。
查询日志：记录所有对数据库请求的信息，不论这些请求是否得到了正确的执行。
慢查询日志：设置一个阈值，将运行时间超过该值的所有SQL语句都记录到慢查询的日志文件中。
二进制日志：记录对数据库执行更改的所有操作。
中继日志：中继日志也是二进制日志，用来给slave 库恢复
事务日志：重做日志redo和回滚日志undo

主从复制

复制的基本原理
slave 会从 master 读取 binlog 来进行数据同步
三个步骤
master将改变记录到二进制日志（binary log）。这些记录过程叫做二进制日志事件，binary log events；
salve 将 master 的 binary log events 拷贝到它的中继日志（relay log）;
slave 重做中继日志中的事件，将改变应用到自己的数据库中。MySQL 复制是异步且是串行化的。

复制的基本原则
每个 slave只有一个 master
每个 salve只能有一个唯一的服务器 ID
每个master可以有多个salve
复制的最大问题
延时

参考：MySQL 三万字精华总结 + 面试100 问，和面试官扯皮绰绰有余（收藏系列）

grpc对标restful api 好像也会出现在面试题中

字节跳动研发岗位内推，长期有效

【岗位】后端/前端/Android/iOS/测试/算法/数据分析......；社招/实习/校招均可，社招开放初级/中级/高级各种级别
【福利待遇】业界TOP的薪酬回报+快速发展的平台+过亿用户产品+自由极客技术氛围、六险一金、弹性工作不打卡、免费三餐下午茶、无限量零食水果、租房补贴、免费健身房...

社招/实习

通过内推链接: https://job.toutiao.com/s/kAvrHkR 自助投递即可, 投递即算作内推

校招

字节跳动校招内推码: YZGYZWU 投递链接: https://job.toutiao.com/s/Jjq9YQT

热招部门

• 生活服务
• 国际化电商

校招/实习/社招，有任何简历、岗位、内推进度、面试等等相关的问题都可以通过邮件(邮箱在我的GitHub个人简介中)问我，一天之内回复。欢迎大家来交个朋友

文中说如果服务端没收到第二次握手的 ACK，此时客户端发送数据，服务端会以 RST 回应
但根据这个回答，作者的观点是此时服务端收到客户端的数据，会自然切换到 established 状态，且接收数据。在评论中作者回答了原因是：

除了第一个SYN报文，其它报文都需要有ACK。

因此服务端能收到数据 + ACK number。
请问原文说服务端会以 RST 回应有相关证据吗？

关于TCP三次握手为什么不能是两次的原因：

• 首先，两次握手无法保证Client正确接收第二次握手的报文，从而无法保证Client和Server之间建立的是双向的对称“链路”，也无法保证Client和Server之间成功互换初始序列号。
• 其次，可能出现已失效的连接请求报文被Server再次接收，从而可能建立不需要的连接，浪费资源。

如DNS劫持原理，预防方法以及DNS解析过程等

感谢您的代码，很简洁，对我准备面试非常受用!

但是我发现merge_sort的终止条件应该为if len(lst) <= 1 而不是if not lst，否则程序会无限递归。

def merge_sort(lst):
    if len(lst) <= 1:
        return lst
    mid = len(lst) // 2
    left = merge_sort(lst[:mid])
    right = merge_sort(lst[mid:])
    return merge(left, right)

def merge(left, right):
    l, r, res = 0, 0, []
    while l < len(left) and r < len(right):
        if left[l] < right[r]:
            res.append(left[l])
            l += 1
        else:
            res.append(right[r])
            r += 1
    return res + left[l:] + right[r:]

您好，请问我可以clone一份笔记放在我的个人网站上进行学习整理吗？github上查看不太方便。如果可以的话，我会在开头详细注明来源。

协程是一种用户态的轻量级线程，协程的调度完全由用户控制。协程拥有自己的寄存器上下文和栈。协程调度切换时，将寄存器上下文和栈保存到其他地方，在切回来的时候，恢复先前保存的寄存器上下文和栈，直接操作栈则基本没有内核切换的开销，可以不加锁的访问全局变量，所以上下文的切换非常快。

协程多与线程进行比较

1. 一个线程可以多个协程，一个进程也可以单独拥有多个协程，这样python中则能使用多核CPU。

2. 线程进程都是同步机制，而协程则是异步

3. 协程能保留上一次调用时的状态，每次过程重入时，就相当于进入上一次调用的状态

数据库还有一些待更的,一年没有更新了

操作系统中，这个"协程多与线程进行比较"问题有错别字，应该是“协程与多线程进行比较”。

这个问题好像闲置了许久没有问答了 作者是不是太忙了把他忘记了

不知道为什么三个backslashes在.md format里不管用。。。于是只好将pull request改成issue。sigh。
以下是一个哲学家就餐问题的伪代码。代码来自本人的OS课（测试过）

问题描述：有五位哲学家围绕着餐桌坐，每一位哲学家要么思考，要么吃饭。为了吃饭，哲学家必须拿起两双筷子（分别放于左右两端）不幸的是，筷子的数量和哲学家相等，所以每只筷子必须由两位哲学家共享。

#define N 5  // number of philosopher
#define LEFT (i + N - 1)%N // number of i's left neighbors
#define RIGHT (i + 1)%N // number of i's right neighbors
#define THINKING 0
#define HUNGRY 1
#define EATING 2
typedef int semaphore;
int state[N]; // array to keep track of everyone's state
semaphore mutex = 1; // mutual exclusion of critical region
semaphore s[N]; 

void philosopher(int i) {
	while (TRUE) {
		think();
		take_forks(i);
		eat();
		put_forks(i);
	}
}

void take_forks(int i) {
	down(&mutex); // enter critical region
	state[i] = HUNGRY; // record that i is hungry
	test_forks(i); // try to acquire two forks
	up(&mutex); // exit critical region
	down(&s[i]); // block if forks are not acquired
}

void put_forks(int i) {
	down(&mutex); // enter critical region
	state[i] = THINKING; // record that has finished eating
	test_forks(LEFT); // see if left neighbor can now eat
	test_forks(RIGHT); // see if right neighbor can now eat
	up(&mutex); // exit critical region
}

void test_forks(int i) {
	if (state[i] == HUNGRY && state[LEFT] != EATING && state[RIGHT] != EATING) {
		state[i] = EATING;
		up(&s[i]);
	}
}

第四点中，“使用Hash算法对握手消息进行摘要计算，并对摘要使用之前产生的密钥加密（对称算法）；将加密后的随机密钥和摘要一起发送给服务器”，需要对摘要加密吗？

计算机网络 “TCP如何最大利用带宽？”这一部分中的部分字体无法显示 如下图所示

感谢大佬分享。

这个问题没有答案。
链接如下：

https://github.com/wolverinn/Waking-Up/blob/master/Computer%20Network.md#http%E5%8F%AF%E4%BB%A5%E4%BD%BF%E7%94%A8udp%E5%90%97

您的原文是：“不可重复读**（Nonrepeatable Read）：在同一个事务中，某查询操作在一个时间读取某一行数据和之后一个时间读取该行数据，发现数据已经发生修改（可能被更新或删除了）；”

不可重复读应该是侧重于更新，没有删除
幻读侧重于插入、删除
希望求证后更改！

操作系统那一节里，有关信号量的描述：
信号量(Semaphore)：初始化操作、P操作、V操作；P操作：信号量-1，检测是否小于0，小于则进程进入阻塞状态；V操作：信号量+1，若小于等于0，则从队列中唤醒一个等待的进程进入就绪态
小于等于应该改成大于等于吧?

这个问题是我自己根据笔记提出的，整理得出：

问题：说一下四种隔离级别的实现原理？
未提交读（Read Uncommited）：啥都不做
（一级封锁协议 ----> 解决丢失修改）
提交读（Read Commited）：二级封锁协议 ----> 解决脏读
可重复读（Repeatable Read）: 三级封锁协议 ----> 解决不可重复读
可串行化（Serializable）：强制事务串行执行 ----> 解决幻读问题