- 博客(6)
- 收藏
- 关注
RSS订阅原创 HTTP/1.1、HTTP/2、HTTP/3
队头阻塞依然存在，2只解决了HTTP层面的队头阻塞，但是TCP层面的依旧没有解决：HTTP/2 是基于 TCP 协议来传输数据的，TCP 是字节流协议，TCP 层必须保证收到的字节数据是完整且连续的，这样内核才会将缓冲区里的数据返回给 HTTP 应用，那么当「前 1 个字节数据」没有到达时，后收到的字节数据只能存放在内核缓冲区里，只有等到这 1 个字节数据到达时，HTTP/2 应用层才能从内核中拿到数据，这就是 HTTP/2 队头阻塞问题。大家都知道 UDP 是不可靠传输的，但基于 UDP 的。
2024-11-11 15:16:43
339
原创 【HTTPS的加密过程】
服务器和客户端有了这三个随机数（Client Random、Server Random、pre-master key），接着就用双方协商的加密算法，各自生成本次通信的「会话秘钥」服务器收到客户端的第三个随机数（pre-master key）之后，通过协商的加密算法，计算出本次通信的「会话秘钥」。客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。上面第一项的随机数是整个握手阶段的第三个随机数，会发给服务端，所以这个随机数客户端和服务端都是一样的。
2024-11-10 14:17:48
421
原创 【无标题】
问题1：最快发送数据时间：在三次握手的第三次发送时可以附带数据。因为第二次时客户端已经连接成功，可以发送消息了。问题2：为什么是三次？不是两次也不是四次？【TCP 建立连接时，通过三次握手能防止历史连接的建立，能减少双方不必要的资源开销，能帮助双方同步初始化序列号。序列号能够保证数据包不重复、不丢弃和按序传输。不使用「两次握手」和「四次握手」的原因：• 「两次握手」：无法防止历史连接的建立，会造成双方资源的浪费，也无法可靠的同步双方序列号；
2024-11-09 10:14:51
402
原创 使用FFMPEG把图像从YUV格式转换为RGB格式
使用FFmpeg库将解码后的YUV格式的视频帧转换为RGB32格式的图像，分为五部分，分别是：创建转换上下文，获取RGB32图像的大小，分配内存空间，创建图像，进行转换。第一步：创建转换上下文，使用了函数sws_getcontext，用于创建一个SwsContext结构，这个结构包含了像素格式转换所需的所有信息。参数分别是视频帧的宽度和高度、输入视频帧的像素格式(YUV)，输出的像素格式(RGB32),以及采用的算法(双三次插值算法)。
2024-11-08 13:18:02
838
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人