UDP报文长度限制,在IPv4下是65507字节(65535-8字节UDP header-20字节 IPheader) 长度限制内的包都可以发 fragmentation发生在IP层,一个长UDP报文,会被分为若干个fragment,封成IP包发送接收端收到所有的fragment之后,会在IP层组装成一个完整的UDP datagram交给你的UDP recv函数 只要有一个fragment丢了,整个UDP报文就丢了 所以作为没有ACK的UDP协议,一般我们不希望出现分包发送的情形,以避免累积丢包率,导致实际报文的丢包率很高 根据IEEE的要求,IPv4的网络,至少要保证MTU不低于576,于是扣除一些IP、UDP header的长度,548长度的UDP包可以认为是不会发生fragmentation的 但是人们喜欢冗余,喜欢留余地,所以很多人实践中,把这个限制写成了512 https://stackoverflow.com/questions/20314308/understanding-how-to-send-larger-data-chunks-over-udp-reliably/20317315#20317315
IP地址有统一综合bai规划管理的du 比如某个省 划分100个IP段归这个范围使zhi用 省级部门接下来把20个一组 划分给某市dao使用 市区呢又把5个段分给某运营商去使用 其余的还有计划的投放企业应用,民用,公共事业范围等等… 所以每个IP都有其固定的 可查的 使用范围 运营商处可以查询任何时间 任何场所 使用的某IP详细日志记录档案
热 key 指的是那些在一段时间内访问频次比较高的键值,具体到业务上,商品的限时抢购、瞬时的新闻热点或某个全局性的资源,都极有可能产生热点 key。
设计定位方案的话,我们可以从 Redis 请求路径上的节点来着手,比如在客户端、中间层和服务端,具体来说如下: