linux内核怎样运行编译

1.下载内核，官方网站地址：www.kernel.org

2.解压（路径自选）

3.进入到解压的内核源码文件夹，运行make menuconfig，如果不裁剪内核，那么可以直接保存配置退出

4.make bzImage-->make modules-->mke modules_install-->make install（有些版本可能需要运行mkinitramfs -o intrd.img-内核版本号 内核版本号）

5.修改grub文件，将新内核加入进去

我来说下吧 本身你这个问题问的有点歧义 不知道你问的是内核编译 还是模块编译 两个不是一个东西 尽管模块加载后 也是内核的一部分 看看其他的回答 以为是单纯的内核的编译了 模块本身在linux下面是可以分为静态和动态加载的 要是采用静态加载的话 就是从新编译内核 和内核的编译基本是一回事 但是多采用动态加载 这个也简单点

从你的下面的模版可以看出 你是想写驱动程序吧 驱动一般作为动态加载的就可以了 写好你的c文件 格式和上面的差不多 然后GCC编译 生成.o文件，不要生成可执行文件 （ 如果是玩Embedded 就下载到目标板了 minicom 的使用） 如果是就在linux机器上 直接执行 insmod lsmod rmmod 这些就好了 这里也是简单的说下了 内核的编译 写驱动程序 本身就是个比较难得事情了 要个很长的时间去学习了 慢慢积累 好运

HTTP 3 ，它来了，QUIC（quick udp internet connection “快速 UDP 互联网连接”）正如其名一样，它就是快。其正在标准化为新一代的互联网传输协议。是由google提出的使用udp进行多路并发的传输协议。

QUIC解决了什么问题呢？从上世纪90年代至今，互联网一直按照一成不变的模式发展着。使用ipv4进行路由，使用tcp进行连接层面的拥塞控制，并保证其传输的可靠性，使用tls层进行安全加密和身份验证，使用http进行应用的数据传输。

这么多年的发展，这些协议只是小部分或者细节上有了改变，tcp提出了几个新的拥塞控制算法，tls改变了加密方式，http层进化出了h2。但是互联网发展至今，网络传输的内容越来越大，用户对传输的时延，带宽提出越来越大的要求。

tcp虽然也在拥塞控制上提出了一些优秀的拥塞控制算法，如BBR但是限制于其对 *** 作系统内核版本的要求，tcp 的 TFO，windows *** 作系统又支持不好等。导致想要切换成更高效的协议成本巨大。

这里列出几个主要的矛盾。

1、协议历史悠久导致中间设备僵化。

2、依赖于 *** 作系统的实现导致协议本身僵化。

3、建立连接的握手延迟大。

4、队头阻塞。

QUIC孕育而生，其抛开了TCP直接采用UDP，如一些拥塞算法，可靠性保证机制，不再依赖 *** 作系统内核，而是可以自定义。

Quic 相比现在广泛应用的 http2+tcp+tls 协议有如下优势：

1、减少了 TCP 三次握手及 TLS 握手时间。

2、改进的拥塞控制。

3、避免队头阻塞的多路复用。

4、连接迁移。

5、前向冗余纠错。

有些防火墙只允许通过 80 和 443，不放通其他端口。NAT 网关在转换网络地址时重写传输层的头部，有可能导致双方无法使用新的传输格式。因为通信协议栈都是固化到 *** 作系统中的，只能通过内核参数进行调整，但是这样的调整极其有限，如果想要新加协议，只能重新编译内核。而现实是，可能还有一些Centos5 还作为某些古董公司的线上服务器。另外，windows xp 可能还是某些事业单位的办公电脑上装的 *** 作系统，尽管xp的时代已经过去20年了。另外TCP Fast Open 也在2013年就提出了，但是windows *** 作系统也有些不支持。

知道一个首次https网站的访问都要有哪些步骤吗？dns解析需要1个RTT，TCP三次握手，HTTP 302 跳转 HTTPS又需要RTT，TCP重新握手。TLS握手再消耗2个。解析CA的DNS（因为浏览器获取到证书后，有可能需要发起 OCSP 或者 CRL 请求，查询证书状态）再对CA进行TCP握手，OCSP响应。密钥协商又是RTT。当然这种情况是最极端的，大部分情况下不是所有流程都需要走一遍的。（参考 大型网站的 HTTPS 实践（二）-- HTTPS 对性能的影响 ）

基于以上的原因，QUIC选择了UDP。没有了三次握手，在应用层面完成了传输的可靠性，拥塞控制还有TLS的安全性。只要应用软件的客户端和服务端支持就行，绕开了 *** 作系统内核版本这个硬骨头。

在HTTPS over TCP+TLS的时代。HTTPS需要3个RTT，在session 复用的情况下是2个RTT。而QUIC做到了1RTT和会话复用的0RTT。

QUIC的TLS只能使用TLS1.3，这就可以做到PSK的0RTT。

TCP 的拥塞控制实际上包含了四个算法：慢启动，拥塞避免，快速重传，快速恢复。其中TCP中拥塞控制是被编译进内核中的，如果想要更改就需要改变内核参数，但是想要对已有的拥塞控制算法进行更改就需要重新编译内核，Linux 4.9 中引入了基于时延的拥塞控制算法 BBR，这打破了以往是靠丢包驱动的拥塞控制算法，但是想要在TCP中使用，就必须升级内核至4.9以上。

QUIC 协议当前默认使用了 TCP 协议的 Cubic 拥塞控制算法 [6]，同时也支持 CubicBytes, Reno, RenoBytes, BBR, PCC 等拥塞控制算法。

QUIC和TCP的对比

其中α 从 0到 1（RFC 推荐 0.9），越大越平滑

如 UBOUND为1分钟，LBOUND为 1 秒钟， β从 1.3 到 2 之间

对于QUIC

参考： 科普：QUIC协议原理分析 罗成

---