获得徽章 1
- #青训营笔记创作活动#
# 1月20日 Day8
今日学习了：
- Kafka基础概念
- 整体架构
- 版本变迁
- 实战
展开评论1 - #青训营笔记创作活动#
# 1月27日 Day9
今日学习了：
- TCP为了实现可靠性，引入了重传机制、流量控制、滑动窗口、拥塞控制、分段以及乱序重排机制。而UDP则没有实现，因此一般来说TCP比UDP快。
- TCP是面向连接的协议，而UDP是无连接的协议。这里的"**连接**"其实是，操作系统内核在两端代码里维护的一套复杂状态机。
- 大部分项目，会在基于UDP的基础上，模仿TCP，实现不同程度的可靠性机制。比如王者农药用的KCP其实就在基于UDP在应用层里实现了一套**重传**机制。
- 对于UDP+重传的场景，如果要传**超大数据包**，并且没有实现**分段机制**的话，那数据就会在IP层分片，一旦丢包，那就需要重传整个超大数据包。而TCP则不需要考虑这个，内部会自动分段，丢包重传分段就行了。这种场景下，其实TCP更快。展开评论1 - #青训营笔记创作活动#
1月19日 Day7
今日学习了：
- TCP协议本身是全双工的，但我们最常用的HTTP1.1，虽然是基于TCP的协议，但它是半双工的，对于大部分需要服务器主动推送数据到客户端的场景，都不太友好，因此我们需要使用支持全双工的websocket协议。
- 在HTTP1.1里。只要客户端不问，服务端就不答。基于这样的特点，对于登录页面这样的简单场景，可以使用定时轮询或者长轮询的方式实现服务器推送(comet)的效果。
- 对于客户端和服务端之间需要频繁交互的复杂场景，比如网页游戏，都可以考虑使用websocket协议。
- websocket和socket几乎没有任何关系，只是叫法相似。
- 正因为各个浏览器都支持HTTP协议，所以websocket会先利用HTTP协议加上一些特殊的header头进行握手升级操作，升级成功后就跟HTTP没有任何关系了，之后就用websocket的数据格式进行收发数据。展开评论1 - #青训营笔记创作活动# 1月15日 Day3
今日学习了几种常用的限流算法：
计数器：
- 优点：固定时间段计数，实现简单，适用不太精准的场景；
- 缺点：对边界没有很好处理，导致限流不能精准控制。
滑动窗口：
- 优点：将固定时间段分块，时间比“计数器”复杂，适用于稍微精准的场景；
- 缺点：实现稍微复杂，还是不能彻底解决“计数器”存在的边界问题。
漏桶：
- 优点：可以很好的控制消费频率；
- 缺点：实现稍微复杂，单位时间内，不能多消费，感觉不太灵活。
令牌桶：
- 优点：可以解决“漏桶”不能灵活消费的问题，又能避免过渡消费，强烈推荐；
- 缺点：实现稍微复杂，其它缺点没有想到。
Redis + Lua 分布式限流：
- 优点：支持分布式限流，有效保护下游依赖的服务资源；
- 缺点：依赖 Redis，对边界没有很好处理，导致限流不能精准控制。展开评论1 - #第五届青训营阅读打卡# 1月13日 打卡day1
非对称加密：
- 非对称加密中，公钥负责加密，私钥负责解密，和数字签名正好相反
- 不过它们都是公开公钥，保护私钥
- 一个公钥加密的内容，可以由多个不同的私钥解密
- 只有私钥可以解密公钥加密过的内容
Https加密原理：
HTTPS的握手过程:
首先，建立TCP连接，因为HTTP是基于TCP的
在TCP建立完协议后，就开始加密流程
分为两个阶段：
1. TLS四次握手
2. 加密通信
第一阶段是利用非对称加密的特性交换信息，最后得到一个会话密钥
第二阶段则是在会话密钥的基础上，进行对称加密通信
- 可以看到，四次握手的目的就是为了生成"会话密钥"，后续用对称加密的方式进行通信，因为对称加密更快一点
- 前两个随机数是明文传输，第三个则是经过服务器公钥加密的
- 用三个随机数是为了增加"会话密钥"的随机性
原文链接:
juejin.cn 展开评论1
juejin.cn