在浏览器输入 URL 回车之后发生了什么(超详细版)
前言这个问题已经是老生常谈了,更是经常被作为面试的压轴题出现,网上也有很多文章,但最近闲的无聊,然后就自己做了一篇笔记,感觉比之前理解更透彻了。
这篇笔记是我这两天看了数十篇文章总结出来的,所以相对全面一点,但由于我是做前端的,所以会比较重点分析浏览器渲染页面那一部分,至于其他部分我会罗列出关键词,感兴趣的可以自行查阅,
注意:本文的步骤是建立在,请求的是一个简单的 HTTP 请求,没有 HTTPS、HTTP2、最简单的 DNS、没有代理、并且服务器没有任何问题的基础上,尽管这是不切实际的。
大致流程
URL 解析
DNS 查询
TCP 连接
处理请求
接受响应
渲染页面
一、URL 解析地址解析:
首先判断你输入的是一个合法的 URL 还是一个待搜索的关键词,并且根据你输入的内容进行自动完成、字符编码等操作。
HSTS
由于安全隐患,会使用 HSTS 强制客户端使用 HTTPS 访问页面。详见:你所不知道的 HSTS。
其他操作
浏览器还会进行一些额外的操作,比如安全检查、访问限制(之前国产浏览器限制 996.icu)。
检查缓存
二、DNS 查询基本步骤
1. 浏览器缓存
浏 ...
Geohash算法
用户附近位置计算经纬度与物理距离介绍经纬度是经度与纬度的合称组成一个坐标系统,称为地理坐标系统,它是一种利用三度空间的球面来定义地球上的空间的球面坐标系统,能够标示地球上的任何一个位置。
在一定误差范围内,通常情况下,经纬线和米的换算为:经度或者纬度0.00001度,约等于1米。以下表格列出更细致的换算关系:
在纬度相等的情况下
在经度相等的情况下
经度每隔0.00001度,距离相差约1米;每隔0.0001度,距离相差约10米;每隔0.001度,距离相差约100米;每隔0.01度,距离相差约1000米;每隔0.1度,距离相差约10000米。
纬度每隔0.00001度,距离相差约1.1米;每隔0.0001度,距离相差约11米;每隔0.001度,距离相差约111米;每隔0.01度,距离相差约1113米;每隔0.1度,距离相差约11132米。
地图坐标系
WGS84坐标系
地球坐标系,国际通用坐标系
GCJ02坐标系
火星坐标系,WGS84坐标系加密后的坐标系;Google国内地图、高德、QQ地图 使用
BD09坐标系
百度坐标系,GCJ02坐标系加密后的坐标 ...
Zookeeper面试题总结
1、请简述Zookeeper的选举机制 假设有五台服务器组成的zookeeper集群,它们的id从1-5,同时它们都是最新启动的,也就是没有历史数据,在存放数据量这一点上,都是一样的。 假设这些服务器依序启动,来看看会发生什么。[ (1)服务器1启动,此时只有它一台服务器启动了,它发出去的报没有任何响应,所以它的选举状态一直是LOOKING状态。 (2)服务器2启动,它与最开始启动的服务器1进行通信,互相交换自己的选举结果,由于两者都没有历史数据,所以id值较大的服务器2胜出, 但是由于没有达到超过半数以上的服务器都同意选举它(这个例子中的半数以上是3),所以服务器1、2还是继续保持LOOKING状态。 (3)服务器3启动,根据前面的理论分析,服务器3成为服务器1、2、3中的Leader,而与上面不同的是,此时有三台服务器选举了它, 所以它成为了这次选举的Leader。 (4)服务器4启动,根据前面的分析,理论上服务器4应该是服务器1、2、3、4中最大的,但是由于前面已经有半数以上的服务器选举了服务器3, 所以它成为Follower。 (5)服务器5启动,同4一样成为Fol ...
HBase优化笔记
HBase 优化JVM调优内存调优一般安装好的HBase集群,默认配置是给Master和RegionServer 1G的内存,而Memstore默认占0.4,也就是400MB。显然RegionServer给的1G真的太少了。
12export HBASE_MASTER_OPTS="$HBASE_MASTER_OPTS -Xms2g -Xmx2g"export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS -Xms8g -Xmx8g"
这里只是举例,并不是所有的集群都是这么配置。==要牢记至少留10%的内存给操作系统来进行必要的操作==
如何给出一个合理的JVM 内存大小设置,举一个ambari官方提供的例子吧。
比如你现在有一台16GB的机器,上面有MapReduce服务、 RegionServer和DataNode(这三位一般都是装在一起的),那么建议按 照如下配置设置内存:
2GB:留给系统进程。
8GB:MapReduce服务。平均每1GB分配6个Map slots + 2个Redu ...
HBase RowKey设计
在HBase中,定位一条数据(即一个Cell)需要4个维度的限定:行键(RowKey)、列族(Column Family)、列限定符(Column Qualifier)、时间戳(Timestamp)。其中,RowKey是最容易出现问题的。除了根据业务和查询需求来设计之外,还需要注意以下三点。
1. 打散RowKeyHBase中的行是按照RowKey字典序排序的。
这对Scan操作非常友好,因为RowKey相近的行总是存储在相近的位置,顺序读的效率比随机读要高。
但是,如果大量的读写操作总是集中在某个RowKey范围,那么就会造成Region热点,拖累RegionServer的性能。
因此,要适当地将RowKey打散。
加盐(salting)+哈希(hashing)这里的“加盐”与密码学中的“加盐”不是一回事。
它是指在RowKey的前面增加一些前缀。
加盐的前缀种类越多,RowKey就被打得越散。
前缀不可以是随机的,因为必须要让客户端能够完整地重构RowKey。
我们一般会拿原RowKey或其一部分计算hash值,然后再对hash值做运算作为前缀。
反转固定格式的数值以手机号为例,手 ...
HBase性能优化指南
HBase简介HBase是一个分布式的、面向列的开源数据库存储系统,是对Google论文BigTable的实现,具有高可靠性、高性能和可伸缩性,它可以处理分布在数千台通用服务器上的PB级的海量数据。BigTable的底层是通过GFS(Google文件系统)来存储数据,而HBase对应的则是通过HDFS(Hadoop分布式文件系统)来存储数据的。
HBase不同于一般的关系型数据库,它是一个适合于非结构化数据存储的数据库。HBase不限制存储的数据的种类,允许动态的、灵活的数据模型。HBase可以在一个服务器集群上运行,并且能够根据业务进行横向扩展。
Hbase有以下优点:
海量存储:HBase适合存储PB级别的海量数据,在PB级别的数据以及采用廉价PC存储的情况下,能在几十到百毫秒内返回数据。这与HBase的记忆扩展性息息相关。正是因为HBase的良好扩展性,才为海量数据的存储提供了便利。
列式存储:列式存储,HBase是根据列族来存储数据的。列族下面可以有非常多的列,列族在创建表的时候就必须指定,而不用指定列。
极易扩展:HBase的扩展性主要体现在两个方面,一个是基于上层处理能力 ...
超详细梳理HBase核心知识点
1、 HBase的特点是什么? 1)大:一个表可以有数十亿行,上百万列; 2)无模式:每行都有一个可排序的主键和任意多的列,列可以根据需要动态的增加,同一张表中不同的行可以有截然不同的列; 3)面向列:面向列(族)的存储和权限控制,列(族)独立检索; 4)稀疏:空(null)列并不占用存储空间,表可以设计的非常稀疏; 5)数据多版本:每个单元中的数据可以有多个版本,默认情况下版本号自动分配,是单元格插入时的时间戳; 6)数据类型单一:Hbase中的数据都是字符串,没有类型。
2、HBase和Hive的区别?
Hive和Hbase是两种基于Hadoop的不同技术–Hive是一种类SQL的引擎,并且运行MapReduce任务,Hbase是一种在Hadoop之上的NoSQL 的Key/vale数据库。 当然,这两种工具是可以同时使用的。就像用Google来搜索,用FaceBook进行社交一样,Hive可以用来进行统计查询,HBase可以用来进行实时查询, 数据也可以从Hive写到Hbase,设置再从H ...
Elasticsearch性能优化实战指南
0、背景在当今世界,各行各业每天都有海量数据产生,为了从这些海量数据中获取想要的分析结果,需要对数据进行提取、转换,存储,维护,管理和分析。 这已然远远超出了普通处理工具、数据库等的实现能力,只有基于的分布式架构和并行处理机制的大数据工具所才能实现这些功能。 Elasticsearch是响应如前所述大多数用例的最热门的开源数据存储引擎之一。
Elasticsearch是一种分布式数据存储和搜索引擎,具有容错和高可用性特点。为了充分利用其搜索功能,需要正确配置Elasticsearch。
简单的默认配置不适合每个实际业务场景。实战开发运维中,个性化实现贴合自己业务场景的集群配置是优化集群性能的必经之路。本文集合实战业务场景,重点介绍搜索密集型Elasticsearch集群的提升性能的干货配置。
1、索引层面优化配置默认情况下,6.x及之前的版本中Elasticsearch索引有5个主分片和1个副本,7.X及之后版本1主1副。 这种配置并不适用于所有业务场景。 需要正确设置分片配置,以便维持索引的稳定性和有效性。
1.1、分片大小分片大小对于搜索查询非常重要。
一方面, 如果分配给索引的 ...
ElasticSearch 索引设置总结
在使用ES时,我们常见的就是需要生成一个template来定义索引的设置,分词器,Mapping.本文将基于项目经验来总结一些常用的配置。
Index设置
index.refresh_interval
配置一个刷新时间,将index buffer刷新到os cache的时间间隔,刷新到os cache的数据才可以被索引到,默认是1s.如果对实时性搜索要求不高的地方,可设置时间为30s,提高性能。
number_of_replicas
对于集群数据节点 >=2 的场景,建议副本至少设置为 1(一主一从,共两个副本), 可以提高集群容错和搜索吞吐量(副本分片可用于查询)。
index.number_of_shards
主副本的分片数,默认是5个,最大值限制为1024个,这个值是分片数可适当的增加,提高索引的并发性能,但是分片越多,也会导致资源耗费越高,索引要根据访问并发数和ES集群的资源来设置。经验公式:分片数 = 索引大小/分片大小经验值 30GB,官方推荐Shard值在 20-40GB性能最好,日志类:单分片<50GB;搜索类:单分片<20G ...
Kafka史上最详细原理总结
Kafka
Kafka是最初由Linkedin公司开发,是一个分布式、支持分区的(partition)、多副本的(replica),基于zookeeper协调的分布式消息系统,它的最大的特性就是可以实时的处理大量数据以满足各种需求场景:比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎,web/nginx日志、访问日志,消息服务等等,用scala语言编写,Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。
1.前言
消息队列的性能好坏,其文件存储机制设计是衡量一个消息队列服务技术水平和最关键指标之一。下面将从Kafka文件存储机制和物理结构角度,分析Kafka是如何实现高效文件存储,及实际应用效果。
1.1 Kafka的特性:
- 高吞吐量、低延迟:kafka每秒可以处理几十万条消息,它的延迟最低只有几毫秒,每个topic可以分多个partition, consumer group 对partition进行consume操作。
- 可扩展性:kafka集群支持热扩展
- 持久性、可靠性:消息被持久化到本地磁盘,并且支持数据 ...