ecc的过程与rsa相比有很大的不同，ecc涉及到了很多额外的概念，比如group等等，另外ecc包含两套截然不同的机制，这就是ecdsa和ecdh，这两套机制统一于ecc，在非ecc算法中，这两套机制是由两个独立的算法实现的，比如对于加密/解密以及签名/验证这一类需求来说使用的是rsa，dsa，对于密钥协商这一类需求来说使用的是dh，如何把这两类算法统一到一个结构中是类似openssl等框架需要

突然发现一场战争刚刚过去，自己没有来得及参战，战利品当然就没有机会了，不过观战也是不错的选择。这篇帖子讨论的非常不错，大家都阐述了自己的观点，值得一看前面写过一些文章来讨论人工智能，我的观点就是以当前纯算法的努力实现真正的人工智能几乎不可能，突然发现一个帖子，里面阐述的更加具体了一些，大家都发表了自己的意见，很激烈。本贴子主要的观点有随机和进化，我也比较认同这二者，因此我更有必要收藏它了。

最近一直在分析数据包。同时也一直想学python。凑一块儿了...于是，便开工了。座椅爆炸！正文首先要说的是，我知道python有很多解析pcap文件的库，这里不使用它们的原因是为了理解pcap文件的格式细节。使用tcpdump你可以很容易抓取到一系列的数据包，然而tcpdump并没有分析数据包的功能，如果想从这个抓包文件中分析出一些端倪，比如重传情况，你必须使用wireshark之类的软件，用w

最近看大模型相关的论文和书籍，发现了宝藏，这里面全都是我感兴趣的单点，概率统计学，非线性，GPU 并行的切割方向，负反馈，矩阵，函数图像…当模型对某个类别的预测概率高于真实概率时，梯度为正，提示应该降低相应的 logit，当预测不足时，梯度为负，提示应该增加 logit。影响更大，两者偏离越大，损失越大，直观上看，交叉熵更重视出类拔萃者，而忽略了卑微者，这就是一种有意义的 “拔优”，涌现正基于这种

最近看大模型相关的论文和书籍，发现了宝藏，这里面全都是我感兴趣的单点，概率统计学，非线性，GPU 并行的切割方向，负反馈，矩阵，函数图像…当模型对某个类别的预测概率高于真实概率时，梯度为正，提示应该降低相应的 logit，当预测不足时，梯度为负，提示应该增加 logit。影响更大，两者偏离越大，损失越大，直观上看，交叉熵更重视出类拔萃者，而忽略了卑微者，这就是一种有意义的 “拔优”，涌现正基于这种

在做法上，我可能会用实际流量样本训练 DCN 本身，在它能为拥塞控制给出建议之前，实际的流量或人为注入的流量(例如 incast)最为输入，人工的，传统算法的或 SDN 的决策作为目标，都是该 AI DCN 的学习样本，该 AI DCN 就像一个神经网络本身一样收敛，涌现出应对任何流量模式的即时应对措施，在我看来这就算一种即时的 “在线推理”。不管怎样，信息守恒，只是难以暴露，依赖大模型的涌现能力

在做法上，我可能会用实际流量样本训练 DCN 本身，在它能为拥塞控制给出建议之前，实际的流量或人为注入的流量(例如 incast)最为输入，人工的，传统算法的或 SDN 的决策作为目标，都是该 AI DCN 的学习样本，该 AI DCN 就像一个神经网络本身一样收敛，涌现出应对任何流量模式的即时应对措施，在我看来这就算一种即时的 “在线推理”。不管怎样，信息守恒，只是难以暴露，依赖大模型的涌现能力

遇到一个迟来的case，用scp在长链路上传输文件竟然慢到无法忍受！100～200毫秒往返时延的链路，wget下载文件吞吐可达40MBps，scp却只有9MBps。我开始以为这是加密带宽损耗所致，然而用HTTPS测试却正常。为了避免pacing平滑掉边沿事件，设置CC为CUIBIC，抓包抓到如下trace波形：这要么是一个rwnd limited的场景，要么是app limited的场景，肯定不是

是时候将把戏揭穿了。请先阅读下文：https://blog.csdn.net/dog250/article/details/108113329依照文章中所描述的把戏，我们hack一下两个进程的tcp连接的归属，首先给出hack之前的情景：[root@localhost ~]# netstat -ntpActive Internet connections (w/o servers)Proto Re

Unix/Linux内核协议栈的衰微，以及每年大量的行业工人输入，造成了网络数据面技术的内卷。我经常和人一起讨论网络技术，各式各样的，也不仅限于技术，偶尔也吐槽下内卷，周末了总结下我的观点。早在2013年，有一篇关于C10M的文章：http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connec