李晶洋
获得徽章 1
赞了这篇文章
#青训营笔记创作活动#
2.9 day10
消息发送有 3 种模式，即发后即忘、同步和异步。对于发后即忘 的模式，不管消息有没有被成功写入，生产者都不会收到通知，那么即使消息写入失败也无从 得知，因此发后即忘的模式不适合高可靠性要求的场景。如果要提升可靠性，那么生产者可以 采用同步或异步的模式，在出现异常情况时可以及时获得通知，以便可以做相应的补救措施， 比如选择重试发送(可能会引起消息重复)。
2.9 day10
消息发送有 3 种模式，即发后即忘、同步和异步。对于发后即忘 的模式，不管消息有没有被成功写入，生产者都不会收到通知，那么即使消息写入失败也无从 得知，因此发后即忘的模式不适合高可靠性要求的场景。如果要提升可靠性，那么生产者可以 采用同步或异步的模式，在出现异常情况时可以及时获得通知，以便可以做相应的补救措施， 比如选择重试发送(可能会引起消息重复)。
展开
评论
点赞
赞了这篇文章
#青训营笔记创作活动#
1.24 day9
HTTPS握手的过程中会先通过非对称机密去交换各种信息，其中就包括3个随机数，再通过这三个随机数去生成对称机密的会话秘钥，后续使用这个会话秘钥去进行对称加密通信。如果能获得这三个随机数就能解密HTTPS的加密数据包。
三个随机数，分别是客户端随机数（client random），服务端随机数（server random）以及pre_master_key。前两个，是明文，第三个是被服务器公钥加密过的，在客户端侧需要通过SSLKEYLOGFILE去导出。
1.24 day9
HTTPS握手的过程中会先通过非对称机密去交换各种信息，其中就包括3个随机数，再通过这三个随机数去生成对称机密的会话秘钥，后续使用这个会话秘钥去进行对称加密通信。如果能获得这三个随机数就能解密HTTPS的加密数据包。
三个随机数，分别是客户端随机数（client random），服务端随机数（server random）以及pre_master_key。前两个，是明文，第三个是被服务器公钥加密过的，在客户端侧需要通过SSLKEYLOGFILE去导出。
展开
评论
点赞
#青训营笔记创作活动#
1.23 day8
很多时候，大家虽然号称自己用了UDP，但实际上都很忌惮它的丢包问题，所以大部分情况下都会在UDP的基础上做各种不同程度的应用层可靠性保证。比如王者农药用的KCP，以及最近很火的QUIC（HTTP3.0），其实都在UDP的基础上做了重传逻辑，实现了一套类似TCP那样的可靠性机制。
但对于UDP，其本身并不会分段，如果数据过大，到了IP层，就会进行分片。此时发生丢包的话，再次重传，就会重传整个大数据包。
对于UDP+重传的场景，如果要传超大数据包，并且没有实现分段机制的话，那数据就会在IP层分片，一旦丢包，那就需要重传整个超大数据包。而TCP则不需要考虑这个，内部会自动分段，丢包重传分段就行了。这种场景下，其实TCP更快。
1.23 day8
很多时候，大家虽然号称自己用了UDP，但实际上都很忌惮它的丢包问题，所以大部分情况下都会在UDP的基础上做各种不同程度的应用层可靠性保证。比如王者农药用的KCP，以及最近很火的QUIC（HTTP3.0），其实都在UDP的基础上做了重传逻辑，实现了一套类似TCP那样的可靠性机制。
但对于UDP，其本身并不会分段，如果数据过大，到了IP层，就会进行分片。此时发生丢包的话，再次重传，就会重传整个大数据包。
对于UDP+重传的场景，如果要传超大数据包，并且没有实现分段机制的话，那数据就会在IP层分片，一旦丢包，那就需要重传整个超大数据包。而TCP则不需要考虑这个，内部会自动分段，丢包重传分段就行了。这种场景下，其实TCP更快。
展开
评论
点赞