dns

页面加载及优化

偶尔善良 提交于 2020-03-07 19:18:52
页面加载过程 一、 DNS解析(域名解析) DNS 查询的基本过程如下: 1. 查找浏览器缓存 浏览器会缓存 DNS 查询结果,不同的浏览器缓存时间会有所不同。如果浏览器存在缓存,那么 DNS 查询就到此为止。 2. 查找系统缓存 浏览器缓存中没有需要的数据时,就会往上找到操作系统缓存。我们也可以手动配置 host 文件,这样浏览器会优先使用我们的配置。 3. 查找路由器缓存 系统缓存中也没有需要的数据时,就会找到路由器。 4. 查找运营商 DNS 缓存 之后会向运营的服务器(网络配置中的 DNS 服务器地址)请求 DNS 数据。 5. 递归搜索 如果运营商服务器内也没有需要的数据时,就会开始消耗最大的递归搜索。 二、建立连接( TCP连接) http 协议是经过 TCP 来传输的,所以产生一个 http 请求就会有 TCP connect ,但是依赖于长连接,不会产生这个过程。 三、发送请求 从发送请求到开始响应的过程 。 request header :请求头信息, request body :请求体信息 四、接收数据 从响应开始到数据传输完成的过程。 response header :响应头信息。 response body :响应体信息。 五、解析 DOM 树 解析 HTML 结构 ,加载外部脚本和样式表文件,解析并执行脚本代码 ,构建与解析 HTML DOM 树

攻防视角下的信息收集

我的梦境 提交于 2020-03-07 10:24:38
信息收集是指通过各种方式获取所需的信息。信息收集是信息得以利用的第一步,也是关键的一步。—百度百科 信息收集是指黑客为了更加有效地实施渗透攻击而在攻击前或攻击过程中对目标的所有探测活动。 背景: 不论曾经作为白帽子、安全服务工程师还是现在作为甲方安全工程师,都明白信息收集这项工作的重要性。目前网络上关于信息收集的文章数不胜数,那么为什么还要老生常谈?主要是目前网络上的文章更多是站在白帽子或者攻击者的视角下进行展开讨论,但甲方做信息收集的话题没有被提及,本文抛砖引玉,希望更多大佬提出意见。其实是对自己曾经做过的信息收集内容进行一个总结。 本文通过两个角度来讨论信息收集:攻击方、防守方,它们二者之间在信息收集方向的关系如下图: 不论是攻击方还是防守方做信息收集工作主要是四种方法: 社会工程: Google Hacking(不一定是Google); 社交软件(微信、QQ、朋友圈等等); site:example.com site:example.com 登录 site:example.com login 花式工具:各种扫描器与漏洞利用工具、爬虫; 奇葩技巧:这个主意是靠经验的积累与多看看大佬的文章; 手工:坚持+耐心 攻击方视角下的信息收集 网络上关于攻击方做信息收集的工具、方法都有了很不错的文章,大家搜索"信息收集"关键字就可以获取。攻击方做信息收集讨论两个问题:为什么做信息收集

HTTP协议 处理流程

本秂侑毒 提交于 2020-03-07 04:30:23
我们平时在浏览网页的时候都是使用浏览器,输入你要的网址后回车,就会显示出我们所想要的内容,看似这个简单的用户操作行为的背后,Web的工作原理是怎样的呢?到底隐藏了些什么呢? 对于传统的上网流程,系统它是这么做的:浏览器本身它是一个客户端,当输入URL地址的时候,浏览器首先会去请求DNS服务器,通过DNS查询获取相应的域名所对应的IP地址,然后通过这个映射的IP地址找到IP对应的服务器,并建立连接,等浏览器发送完HTTP Request(请求)包后,服务器接收到请求包之后才开始处理,返回HTTP Response(响应)包,客户端浏览器收到来自服务器的响应后就开始渲染这个Response包里的主体(body)部分,等收到全部的内容后断开与该服务器之间的连接。 一个Web服务器也被称为HTTP服务器,它通过HTTP协议与客户端通信。这个客户端通常指的是Web浏览器(其实手机端客户端内部也是浏览器实现的)。 Web服务器的工作原理可以简单地定义为: 1 客户机通过TCP/IP协议建立到服务器的TCP连接 2 客户端向服务器发送HTTP协议请求包,请求服务器里的资源文档 3 服务器向客户机发送HTTP协议应答包,如果请求的资源包含有动态语言的内容,那么服务器会调用动态语言的解释引擎负责处理“动态内容”,并将处理得到的数据返回给客户端 4 客户机与服务器断开。由客户端解释HTML文档

访问一个网页的全过程

半腔热情 提交于 2020-03-07 02:59:55
访问一个网页的全过程 原创toumingren527 最后发布于2017-12-08 18:03:35 阅读数 33418 收藏 展开 引言 打开浏览器,在地址栏输入URL,回车,出现网页内容。整个过程发生了什么?其中的原理是什么?以下进行整理和总结。 整个过程可以概括为几下几个部分: 域名解析成IP地址; 与目的主机进行TCP连接(三次握手); 发送与收取数据(浏览器与目的主机开始HTTP访问过程); 与目的主机断开TCP连接(四次挥手); 正文 下面详细介绍其中的原理: 域名解析成IP地址 访问目标地址有两种方式: ①使用目标IP地址访问。由于IP地址是一堆数字不方便记忆,于是有了域名这种字符型标识。 ②使用域名访问。域名解析就是域名到IP地址的转换过程,域名的解析工作由DNS服务器完成。 DNS域名解析时用的是UDP协议。整个域名解析的过程如下: 浏览器向本机DNS模块发出DNS请求,DNS模块生成相关的DNS报文; DNS模块将生成的DNS报文传递给传输层的UDP协议单元; UDP协议单元将该数据封装成UDP数据报,传递给网络层的IP协议单元; IP协议单元将该数据封装成IP数据包,其目的IP地址为DNS服务器的IP地址; 封装好的IP数据包将传递给数据链路层的协议单元进行发送; 发送时在ARP缓存中查询相关数据,如果没有,就发送ARP广播(包含待查询的IP地址

linux 加入到WINDOWS ad域

帅比萌擦擦* 提交于 2020-03-06 15:40:11
以下是从网上搜集到的内容 概念: 1、 DC AND AD   DC是Domain Controller的缩写,即域控制器,AD是active directory的缩写,即活动目录.   Domain Controller是一台计算机,实现用户,计算机,目录的统一管理.   AD(活动目录)是一种存储协议,基于LDAP.   两者完全是两种概念,DC也可以不基于AD实现,比如基于数据库或文件,当然目前微软还没有这样的实现. 在对等网模式下,任何一台电脑只要接入网络,其他机器就都可以访问共享资源,如共享上网等。尽管 对等网络 上的共享文件可以加访问密码,但是非常容易被破解。在由Windows 9x构成的对等网中,数据的传输是非常不安全的。   不过在“域”模式下,至少有一台服务器负责每一台联入网络的电脑和用户的验证工作,相当于一个单位的门卫一样,称为“域控制器(Domain Controller,简写为DC)”。 域控制器中包含了由这个域的账户、密码、属于这个域的计算机等信息构成的数据库。当电脑联入网络时,域控制器首先要鉴别这台电脑是否是属于这个域的,用户使用的登录账号是否存在、密码是否正确。如果以上信息有一样不正确,那么域控制器就会拒绝这个用户从这台电脑登录。不能登录,用户就不能访问服务器上有权限保护的资源,他只能以对等网用户的方式访问Windows共享出来的资源

Remove CNAME after Azure has verified the domain

醉酒当歌 提交于 2020-03-06 09:54:08
问题 Once I have verified my domain in Azure with the CNAME record, can I remove the CNAME record safely from my DNS server without breaking anything? 回答1: You can safely delete the awverify records. Those are used only when validating the custom domain (while associating a new domain in the portal) and post that, they are not used so feel free to remove them. 来源: https://stackoverflow.com/questions/37715005/remove-cname-after-azure-has-verified-the-domain

浏览器输入url按回车背后经历了哪些?

守給你的承諾、 提交于 2020-03-06 05:47:56
在PC浏览器的地址栏输入一串URL,然后按Enter键这个页面渲染出来,这个过程中都发生了什么事? 1、首先,在浏览器地址栏中输入url,先解析url,检测url地址是否合法 2、浏览器先查看浏览器缓存-系统缓存-路由器缓存,如果缓存中有,会直接在屏幕中显示页面内容。若没有,则跳到第三步操作。 浏览器缓存:浏览器会记录DNS一段时间,因此,只是第一个地方解析DNS请求; 操作系统缓存:如果在浏览器缓存中不包含这个记录,则会使系统调用操作系统,获取操作系统的记录(保存最近的DNS查询缓存); 路由器缓存:如果上述两个步骤均不能成功获取DNS记录,继续搜索路由器缓存; ISP缓存:若上述均失败,继续向ISP搜索。 3、在发送http请求前,需要域名解析(DNS解析),解析获取相应的IP地址。 4、浏览器向服务器发起tcp连接,与浏览器建立tcp三次握手。 5、握手成功后,浏览器向服务器发送http请求,请求数据包。 6、服务器处理收到的请求,将数据返回至浏览器 7、浏览器收到HTTP响应 8、浏览器解码响应,如果响应可以缓存,则存入缓存。 9、 浏览器发送请求获取嵌入在HTML中的资源(html,css,javascript,图片,音乐······),对于未知类型,会弹出对话框。 10、 浏览器发送异步请求。 11、页面全部渲染结束。 来源: https://www.cnblogs

MySQL未能加载文件或程序集“Ubiety.Dns.Core”或它的某一个依赖项 问题的解决

为君一笑 提交于 2020-03-06 01:20:25
在VS2019中使用Nuget的方式添加了最新的MySQL包 MySql.Data 8.0.19 ,默认添加了个Ubiety.Dns.Core,不知道有什么用,但是启动程序后就报错。 “/”应用程序中的服务器错误。 未能加载文件或程序集“Ubiety.Dns.Core”或它的某一个依赖项。未能验证强名称签名。此程序集可能已被篡改,或者已被延迟签名,但没有用正确的私钥进行完全签名。 (异常来自 HRESULT:0x80131045) 原因好像是因为 MySql.Data 8.0.19 中自带的Ubiety.Dns.Core.dll竟然是没有签名的版本…… 于是单独找到Ubiety.Dns.Core的Nuget包进行单独下载,但是报错: 无法安装程序包“Ubiety.Dns.Core 2.5.0”。你正在尝试将此程序包安装到目标为“.NETFramework,Version=v4.6”的项目中,但该程序包不包含任何与该框架兼容的程序集引用或内容文件。有关详细信息,请联系程序包作者。 竟然Nuget安装不上……我也是醉了 最后在 https://www.nuget.org/packages/Ubiety.Dns.Core/2.5.0 网址中,把这个Nuget包单独下载下来。然后把这个文件 ubiety.dns.core.2.5.0.nuget的扩展名修改为.zip。 用解压软件解压

k8s

孤人 提交于 2020-03-05 00:51:28
1:k8s集群的安装 1.1 k8s的架构 Master: API-Server 核心服务 Controller Manager 监控容器的状态实现自愈功能 Scheduler 调度器:挑选合适的节点创建容器 etcd 数据库 node: kubelet 通过docker创建容器 cadvisor 普罗米修斯监控容器 pod 每个容器都被封装到pod资源里 Kube-Proxy 负载均衡 网络插件:flannel容器之间跨宿主机通讯,将ip地址分配信息自动写入etcd中 除了核心组件,还有一些推荐的Add-ons: 组件名称 说明 kube-dns 负责为整个集群提供DNS服务 Ingress Controller 为服务提供外网入口 Heapster 提供资源监控 Dashboard 提供GUI Federation 提供跨可用区的集群 Fluentd-elasticsearch 提供集群日志采集、存储与查询 1.2 修改IP地址、主机名和host解析 10.0.0.11 k8s-master 10.0.0.12 k8s-node-1 10.0.0.13 k8s-node-2 所有节点需要做hosts解析 1.3 master节点安装etcd(数据库服务) 第一步:安装数据库服务 [root@k8s-master ~]# yum install etcd -y 第二步

MongoDB: DNS issue of resolv.conf connecting to MongoDB

痴心易碎 提交于 2020-03-04 20:05:09
问题 I want to export some data from MongoDB Atlas. If I execute the command below, It tries connect localhost and export the data. mongoexport --uri="mongodb+srv://<username>:<password>@name-of-project-x2lpw.mongodb.net/test" --collection users --out /tmp/testusers.json Note: If you run this command from Windows CMD, it works fine After researching the problem and with the help of a user, everything seems to point to a DNS problem and to the related resolv.conf file. Below the original /etc