从 DataReportal 2021 年 1 月的统计数据来看，全球 78 亿人口中，有 52 亿手机用户，46 亿互联网用户。 能够接入网络的设备越来越多，体量越来越大，不知道你有没有好奇过，这样一个庞大的世界是如何被构造出来的？思科（Cisco，世界 500 强通信设备提供商）在一篇报告中曾指出，2016 年年底全球 IP 流量超过 1 个 Zettabyte，也就是 1021 个字节，相当于一万亿 GB。那么如此庞大的流量体系，又需要何种结构去承接？ 接下来我们会学习网络协议，比如 TCP/IP 协议、HTTP 协议，还会学习算法，比如时间窗口算法、校验和算法。这些协议和算法，只是整个互联网的一角，而整个互联网的全貌，我将借这次机会带你做一次漫游。 网络的组成我们习惯称今天的时代为云时代，整个世界可以看作一张巨大的、立体的网。在这个时代里产生的各种服务，就好像水和电一样，打开即用。透过这张巨大的网去观察，里面还会有一个个小型的网络。你可以想象，用无数个节点构成一个个小型网络，再用小型网络组成中型网络，再组成大型网络，以此类推，最后组成完整的一个如星河般的世界。 公司内 ...

在讲解之前，我简短地与身边同僚、朋友交流了内容的大纲。当时，大家都表示出了浓厚的兴趣，并且不约而同地问了我这样一个问题：啥是分布式数据库？更有“爱好学习”的朋友希望借此展现出“勤学好问”的品德，进而补充道：“这是哪个大厂出的产品？” 好吧，我的朋友，你们真的戳中了我的笑点。但笑一笑后，我不禁陷入了思考：为什么分布式数据库在大众，甚至专业领域内认知如此之低呢？ 原因我大概可以总结为两点：数据库产品特点与商业氛围。 首先，数据库产品的特点是抽象度高。用户一般仅仅从使用层面接触数据库，知道数据库能实现哪些功能，而不关心或者很难关心其内部原理。而一些类型的分布式数据库的卖点正是这种抽象能力，从而使用户觉得应用这种分布式化的数据库与传统单机数据库没有明显的差别，甚至更加简单。 其次，数据库的商业氛围一直很浓厚。数据库产品高度抽象且位置关键，这就天然成为资本追逐的领地。而商业化产品和服务的卖点就是其包含支撑服务，而且许多商业数据库最赚钱的部分就是提供该服务。因此这些产品有意无意地对终端用户掩盖了数据库的技术细节，而用户有了这层商业保障，也很难有动力去主动了解内部原理。 这就造成即使你工作中接触了分 ...

在mysql中设计表的时候,mysql官方推荐不要使用uuid或者不连续不重复的雪花id(long形且唯一),而是推荐连续自增的主键id,官方的推荐是auto_increment,那么为什么不建议采用uuid,使用uuid究竟有什么坏处？我们就来分析这个问题,探讨一下内部的原因。 MySQL 和程序实例要说明这个问题,我们首先来建立三张表,分别是user_auto_key,user_uuid,user_random_key,分别表示自动增长的主键,uuid作为主键,随机 key 作为主键,其它我们完全保持不变.根据控制变量法,我们只把每个表的主键使用不同的策略生成,而其他的字段完全一样，然后测试一下表的插入速度和查询速度： 注：这里的随机key其实是指用雪花算法算出来的前后不连续不重复无规律的id:一串 18 位长度的long值 id 自动生成表：```CREATE TABLE user_key_auto ( user_id int unsigned NOT NULL AUTO_INCREMENT, user_name varchar(64) CH ...

他们本质都是TCP连接，并无区别，但是由于http的规定以及浏览器和服务器的限制，导致他们在应用过程中可能有所不同 get方法的特点 请求数据会附在URL之后（放在请求行中，以 ？分割URL和传输数据，多个参数用 & 连接） get是会被浏览器主动缓存的，如果下一次传输的数据相同，那么就会返回缓存中的内容，可以更快的展示数据 get方法的UR一般都有长度限制，但是需要注意的是http协议中并未规定get请求的长度。这个长度限制主要是由浏览器和web服务器决定的，并且各个浏览器对长度限制各不相同 get方法只产生一个TCP数据包，浏览器会把请求头和请求数据一并发送出去，服务器响应200 ok（返回数据） post方法的特点 根据http规范，post可能改变服务器上的资源的请求（点赞就是post请求），因为有可能修改服务器上的资源，所以不符合安全性和幂等性 因为post方法是放在请求数据的，所以它的请求信息是没有长度限制的 post方法会产生两个TCP数据包，浏览器会先将请求头发送给服务器，待服务器返回100 continue，浏览器再发送请求数据，服务器响应 200 ...

首先，在浏览器地址栏中输入url，先解析url，检测url地址是否合法 浏览器先查看浏览器缓存——系统缓存——路由器缓存，如果缓存中有，直接在屏幕上显示内容，如果没有，到第三步 在发送http请求前，需要域名解析（DNS解析），获取相应的IP地址 浏览器向服务器发起TCP连接，与浏览器建立三次握手 握手成功后，浏览器向服务器发送http请求，请求数据包 服务器处理收到的请求，将数据返回至浏览器 四次挥手释放TCP连接 浏览器收到http响应 浏览器解析响应，如果响应可以缓存，则存入缓存 浏览器发送请求获取嵌入在HTML的资源（对于未知类型，会弹出对话框） 浏览器发送异步请求 页面渲染全部结束 **浏览器缓存：**浏览器会记录DNS一段时间，因此只有第一个地方解析DNS请求 操作系统缓存：如果在浏览器中不包含这个记录，则会使用系统调用操作系统，获取操作系统记录（保存最近的DNS查询缓存） **路由器缓存：**如果上述两个步骤均不能获取DNS记录，继续搜索路由器缓存

客户端向服务端发送断开连接请求FIN 服务端响应客户端的断开连接请求，发送ACK响应包给客户端 服务端向客户端发送断开连接请求FIN 客户端响应服务端的断开连接请求，发送ACK响应给客户端 客户端主动调用close时，向服务端发送结束报文段FIN报，同时进入FIN_WAIT1状态；服务器会收到结束报文段FIN报，服务器返回确认报文段ACK并进入CLOSE_WAIT状态，此时如果服务端有数据要发送的话，客户端依然需要接收。客户端收到服务器对结束报文段的确认，就会进入到FIN_WAIT2状态，开始等待服务器的结束报文段；服务器端数据发送完毕后，当服务器真正调用close关闭连接时，会向客户端发送结束报文段FIN包，此时服务器进入LAST_ACK状态，等待最后一个ACK的带来；客户端收到服务器发来的结束报文段, 进入TIME_WAIT, 并发出送确认报文段ACK；服务器收到了对结束报文段确认的ACK，进入CLOSED状态，断开连接。而客户端要等待2MSL的时间，才会进入到CLOSED状态 为什么握手是三次，而挥手需要四次呢 ？第二步属于系统自动响应数据包 第三步是程序手动调用close ...

建立客户端向服务端的连接：发送客户端的请求连接数据包SYN到服务端 响应客户端的连接并建立服务端的连接：服务端发送响应客户端连接的数据包ACK和服务端的请求连接数据包SYN到客户端 响应服务端的连接：客户端发送响应服务端连接的数据包ACK到服务端 服务端新建套接字，绑定地址信息后开始监听，进入LISTEN状态。客户端新建套接字绑定地址信息后调用connect，发送连接请求SYN，并进入SYN_SENT状态，等待服务器的确认。服务端一旦监听到连接请求，就会将连接放入内核等待队列中，并向客户端发送SYN和确认报文段ACK，进入SYN_RECD状态。客户端收到SYN+ACK报文后向服务端发送确认报文段ACK，并进入ESTABLISHED状态，开始读写数据。服务端一旦收到客户端的确认报文，就进入ESTABLISHED状态，就可以进行读写数据了

请求报文格式：请求行、请求头、空一行、请求体 请求行包括：请求方法、统一资源定位符（URL）、http协议及版本 响应报文格式：状态行、响应头、空一行、响应体 状态行包括：协议及版本、状态码、状态码解释

Rancher为采用容器的团队提供了完整的软件堆栈，解决了跨任何基础设施架构管理多个Kubernetes集群的运维和安全挑战，同时为DevOps团队提供了用于运行容器化工作负载的集成工具。 统一的多集群应用程序管理平台第一个真正的多云计算解决方案 对于用户而言，他们希望的是平台可以提供稳定且持续的服务。而确保满足这一需求的最佳方法是在多个基础设施提供商的多个区域部署服务。因此，您需要一个高效可靠的平台，用以管理生产环境中的多个Kubernetes集群。 Rancher不仅可以集中管理部署在任何基础设施上的Kubernetes集群，还可以实行统一的集中式身份验证和访问控制。由于无法确定资源运行的位置，您可以轻松地在不同的基础设施之间调用集群，并在它们之间进行资源迁移。相较而言，与其管理多个独立部署的Kubernetes，不如通过Rancher将它们统一为一个托管的Kubernetes云。 为初学者和高级用户设计工作在您关心的事情上 在Kubernetes中，用户一般用YAML文件来编写资源清单，从而创建容器化应用。通过Rancher，您无需担心YAML，便可立即从Kubernetes中 ...