这问题看起来也不算无解，因为如果有其它流量，比如 AIMD 流共享瓶颈，则 BBR 的 minrtt 本身就是随行 minrtt(本身就包含了 AIMD 的基础 queuing delay) 而非真正的 rtprop，但魔鬼在细节，BBR 保留 minrtt 有 10s 之久，说的就是 cruise 期中的 AIMD 侵入，此态的 BBR 带宽可能由于 cwnd-limited 而持续吃亏 10s

我个人以为，在一台物理机器上运行虚拟机器，并且虚拟机器还和物理机器公用一套硬件，最复杂的东西只有两个，那就是内存管理和中断管理，对于内存管理，影子叶表已经解决了绝大多数的问题，对于中断问题，还有很多的不同的解决方案有待选择。     以x86系列处理器为例，当中断发生的时候，总是会有intr信号发送到cpu的，如果此时正在运行的是guest os的话既然guest os运行在ring1，那么很显然

推荐一本古老的书，2000年的神书《Telecosm:How Infinite Bandwidth Will Revolutionize Our World》，中文版为《通信革命-无限带宽如何改变我们的世界》。为什么推荐这本书呢？因为这本书在1999年左右的时候，成功预测了：互联网爆发。云计算。智能手机。物联网。搜索引擎。高通芯片。…太厉害了！不过，...

操作系统为应用程序提供了n台虚拟机，有几个进程就有几台虚拟机，实际上计算机在最初发明的时候并没有指望运行多个进程，直到后来分时系统出来后，多道程序设计才成为可能，才有了多个进程分时共享cpu的概念。理解任何问题都要返朴归真地从原始定义理解，这样草能理解到其精髓，所以我们就认为进程实际上就等同于最开始的计算机上运行的计算任务，只不过原始的计算任务运行在硬件计算机上而现在的进程却运行在操作系统上，这个

现在已经不再是二十年前，信息化几乎已经走到了分工很细化的地步，在纵向上有系统软件和应用软件之分，这里的系统软件的意义不是指操作系统和编译器等传统意义上的系统软件，而是指一类服务程序，负责资源的分配，当然操作系统无疑还是系统软件，另外框架也成了系统软件，不管是云计算还是传统意义上的操作系统，它们的职责都是计算资源的合理分配，也就是说它们并不完成某一项特殊的需求，而是为所有的需求提供支撑，如果按照机制

<br />虽然上一篇文章《使用jni接口完成android本地程序的运行》讲述了一些理论上的知识，但是如何具体操作呢？要知道android的java虚拟机与标准的jvm是不一致的，因此肯定会遇到具体操作的问题。实际上，具体操作也不难，只要按照android文档的介绍按部操作即可：<br />1.在apps目录下拷贝一个最简单的例子，比如hello-jni作为模板，命名为你的应用的名称，然后删除其

几个层次问题，首先物理内存和虚拟内存，操作系统管理物理内存，而用户进程使用虚拟内存，操作系统呈现给用户进程的是连续的虚拟内存但是不一定连续的物理内存，物理内存随时在变化，但是对于用户进程来说其虚拟内存地址是不变的；其次是指针和句柄，操作系统为了向用户空间提供若干台虚拟机并且又要管理一些所有进程需要的系统服务，必然不能将内核数据结构呈现给进程，但是进程确实可以使用这种数据，因此句柄就出现了，句柄其实

如果谁有旋转升降座椅爆炸的短视频，麻烦提供给我。按照昨天文章里写的那个思路：https://blog.csdn.net/dog250/article/details/95252740刚刚复现并录制了一个SACK Panic的POC动画，我用两台直连虚拟机测试的结果：复现率超过90%，每次重试次数几乎不超过3次即可使机器panic。然而在实际网络环境中测试，复现率必然会降低。和一位仁...

是否真的将信息存储在云，这是一个问题。正如古代人会把“是否将钱存入钱庄”作为一个棘手的问题一样。可如今，几乎每个人都会把钱存入银行...将来，我们会用买硬盘的钱用于云的存储服务，存储服务按照比特收费...我想，云计算虽然很火爆，不管其应用多么的令人向往，底层的技术仍然是最重要的。显然，对人为因素的监督是必不可少的，比如，我把我个人的一些癖好写成日记存储在了云上，我当然不喜欢一些网管看到这些信息

<br />windows和x系统是相似的，然而它既不以进程为根本，又不以线程为根本，而是以窗口为根本的，由于它的过程的每一个环节都是在本机进行的，所以它必然需要在进程，线程以及窗口之间进行更进一步的细分，毕竟在没有虚拟机硬件的支持下，一台机器的最小元素就是线程(在多处理情况下)。具体过程是，当有鼠标键盘或者触摸屏之类的东西有输入事件时，windows系统会将这个事件排入到当前进程的当前线程的消息