从输入URL(www.google.com)到页面加载发生了什么?
1.DNS解析(网址 -> IP地址):DNS缓存:浏览器和操作系统。分级查询:本地DNF服务器,根域名服务器,com顶级域名服务器,google.com域名服务器
2.TCP连接(三次握手)-> 为什么两次不可以?
3.发送HTTP请求
4.服务器处理请求,并且返回HTTP报文
5.浏览器解析和渲染页面
6.连接结束(四次挥手)-> 为什么三次不可以?
DNS解析流程:
DNS 解析安全问题
1、DNS 劫持
一种可能的域名劫持方式即黑客侵入了宽带路由器并对终端用户的本地 DNS 服务器进行篡改,指向黑客自 己伪造的本地 DNS 服务器,进而通过控制本地 DNS 服务器的逻辑返回错误的 IP 信息进行域名劫持。 另一方面,由于 DNS 解析主要是基于 UDP 协议,除了上述攻击行为外,攻击者还可以监听终端用户的域名 解析请求,并在本地 DNS 服务器返回正确结果之前将伪造的 DNS 解析响应传递给终端用户,进而控制终端 用户的域名访问行为。
2、缓存污染(DNS 污染)。
我们知道在接收到域名解析请求时,本地 DNS 服务器首先会查找缓存,如果缓存命中就会直接返回缓存结 果,不再进行递归 DNS 查询。这时候如果本地 DNS 服务器针对部分域名的缓存进行更改,比如将缓存结果 指向第三方的广告页,就会导致用户的访问请求被引导到这些广告页地址上。
3、如何解决 DNS 劫持?
DNS 解析发生在 HTTP 协议之前,DNS 解析和 DNS 劫持和 HTTP 没有关系,DNS 协议使用的是 UDP 协议向服 务器的 53 端口进行请求。 要想解决 DNS 劫持:
可以使用 HttpDNS 的方案:使用 HTTP 协议向 DNS 服务器的 80 端口进行请求,来规避 DNS 劫持 比如:http://119.29.29.29/d?dn=domain&ip=clientIp
在终端上,可以更换 DNS 服务器,不管手机还是电脑,都能手动配置 DNS
三次握手:
第一次握手:客户端 -> 服务端:发送SYN=1(请求建立连接),seq=n(序列号)
第二次握手:服务端 -> 客户端:SYN=1(同意建立连接),服务器收到客户端的seq序列号,它会给它发送ack字段=n+1(序列号加1,确认收到信息)和seq=x(服务端序列号)
第三次握手:客户端 -> 服务端:SYN=0(开始发送信息),发送ack字段=x+1(序列号加1,确认收到信息)和seq=n+1
第一次握手表示:客户端具有发送信息的能力
第二次握手表示:服务端具有接收信息的能力和发送信息的能力
第三次握手表示:客户端具有接收信息的能力
三次握手原因
避免资源被浪费掉。如果在第二步握手时,由于网络延迟导致确认包不能及时到达客户端,那么客户端会认为第一次握手失败,再次发送连接请求,服务端收到后再次发送确认包。在这种情况下,服务端已经创建了两次连接,等待两个客户端发送数据,而实际却只有一个客户端发送数据。
四次挥手:
第一次挥手:客户端 -> 服务端:发完了
第二次挥手:服务端 -> 客户端:知道发完了
第三次挥手:服务端 -> 客户端:收完了
第四次挥手:客户端 -> 服务端:知道收完了
第一次:发完了,第二次:知道发完了,第三次:收完了,第四次:知道收完了
四次挥手原因
由于TCP的连接是全双工,双方都可以主动传输数据,一方的断开需要告知对方,让对方可以相关操作,负责任的表现。
使用TCP协议有:FTP(文件传输协议)、Telnet(远程登录协议)、SMTP(简单邮件传输协议)、POP3(和SMTP相对,用于接收邮件)、HTTP协议等
浏览器解析和渲染页面:
自上而下 下载||渲染 css并行 图片异步请求下载 js挂起
html -> dom + css -> cssom = render渲染树(不渲染:head,display:none)4.布局 5.绘制
影响一个HTTP网络请求的因素
1.网络波动或者网络延迟;这种情况最常见,导致的原因是由服务器之间网络的连通情况和心跳包的容纳情况决定的
2.跨域请求;这种情况一般出现在做外贸或者金融类的公司,比如,美国的服务器,访问上海的服务器,异地处理,请求需要跨越VPN和国际传输,在加上三次握手协议,再加上国际信息传输的特殊渠道供给和波动,会大大延迟数据的响应时间
3.服务器转发次数过多;比如A服务器给B服务请发起请求,B服务器在转发给C由C处理结果之后在依次返回,最后又A收到结果,请求时效加倍,响应时效加倍,服务的可用率就降低了
4.服务器本身的原因:网卡不够完善(多网卡划分,网卡部分缺失),内存供给不足等等都会导致各种各样的响应慢
5.网段划分不一致:如A服务器10M带宽,B服务器10K带宽(分流),1秒一次的心跳,最终决定响应时间的一定是最慢的那个B,因为B的慢,会拖累整个服务集群交互;再比如阿里云华南地区和华北地区两台服务器之间的交互也没有两台华北地区服务器交互来得快
…
简单说,要想服务器交互的尽可能的快,尽量保证服务器的部署网段尽可能一致,带宽没有短板,尽量减少多次转发和跨域的可能性…
更多原因:HTTP慢的原因和解决方式
HTTP和HTTPS的区别
HTTPS:HTTP -> SSL(加密)/TLS(解密)包括对称加密和非对称加密,公钥和私钥代表非对称加密,只有密钥就是对称加密
1.HTTPS需要CA请求证书(付费的)
2.HTTP传输都是明文传送的可以截获,HTTPS传输都是客户端通过SSL加密,服务端通过TLS解密
3.连接方式,端口不同,HTTP端口80,HTTPS端口443
4.HTTPS防止运营商劫持
证书机制
1.作为服务端的小红,首先把自己的公钥发给证书颁发机构,向证书颁发机构申请证书。
2.证书颁发机构自己也有一对公钥私钥。机构利用自己的私钥来加密Key1,并且通过服务端网址等信息生成一个证书签名,证书签名同样经过机构的私钥加密。证书制作完成后,机构把证书发送给了服务端小红。
3.当小灰向小红请求通信的时候,小红不再直接返回自己的公钥,而是把自己申请的证书返回给小灰。
4.小灰收到证书以后,要做的第一件事情是验证证书的真伪。需要说明的是,各大浏览器和操作系统已经维护了所有权威证书机构的名称和公钥。所以小灰只需要知道是哪个机构颁布的证书,就可以从本地找到对应的机构公钥,解密出证书签名。
参考链接:
https://blog.csdn.net/jiangshangchunjiezi/article/details/88545263
Https单向认证和双向认证
app客户端不需要处理证书就属于单向认证,双向认证app客户端是属要处理证书的。
Get、Post区别
(1). 从功能上讲
GET一般用来从服务器上获取资源,POST一般用来更新服务器上的资源;
(2). 从REST服务(REST软件架构)角度上说,GET是幂等的,即读取同一个资源,总是得到相同的数据,而POST不是幂等的,因为每次请求对资源的改变并不是相同的;进一步地,GET不会改变服务器上的资源,而POST会对服务器资源进行改变;
(3). 从请求参数形式上看
GET请求的数据会附在URL之后,即将请求数据放置在HTTP报文的 请求头 中,以?分割URL和传输数据,参数之间以&相连。特别地,如果数据是英文字母/数字,原样发送;否则,会将其编码为 application/x-www-form-urlencoded MIME 字符串(如果是空格,转换为+,如果是中文/其他字符,则直接把字符串用BASE64加密,得出如:%E4%BD%A0%E5%A5%BD,其中%XX中的XX为该符号以16进制表示的ASCII);
而POST请求会把提交的数据则放置在是HTTP请求报文的 请求体 中。
(4). 就安全性而言
POST的安全性要比GET的安全性高,因为GET请求提交的数据将明文出现在URL上,而且POST请求参数则被包装到请求体中,相对更安全。
(5). 从请求的大小看
GET请求的长度受限于浏览器或服务器对URL长度的限制,允许发送的数据量比较小,而POST请求则是没有大小限制的。
参考链接:
https://blog.csdn.net/jiangshangchunjiezi/java/article/details/88546010
Cookie、Session区别
cookie 和session 的区别:
1、存放位置:cookie数据存放在客户的浏览器上,session数据放在服务器上。
2、安全性:cookie不是很安全,别人可以分析存放在本地的COOKIE并进行COOKIE欺骗
考虑到安全应当使用session。
3、性能:session会在一定时间内保存在服务器上。当访问增多,会比较占用你服务器的性能
考虑到减轻服务器性能方面,应当使用COOKIE。
4、大小限制:单个cookie保存的数据不能超过4K,很多浏览器都限制一个站点最多保存20个cookie。Session没有大小限制,理论上只与服务器的内存大小有关;
5、所以个人建议:
将登陆信息等重要信息存放为SESSION
其他信息如果需要保留,可以放在COOKIE中
TCP、UDP报文段
参考链接:https://blog.csdn.net/jiangshangchunjiezi/article/details/88546874
HTTP 的请求方式
根据 HTTP 标准,HTTP 请求可以使用多种请求方法。
HTTP1.0 定义了三种请求方法: GET, POST 和 HEAD方法。
HTTP1.1 新增了六种请求方法:OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。
1、GET
向特定的资源发出请求。注意:GET方法不应当被用于产生“副作用”的操作中,例如在Web Application中,其中一个原因是GET可能会被网络蜘蛛等随意访问。Loadrunner中对应get请求函数:web_link和web_url
2、HEAD
向服务器索与GET请求相一致的响应,只不过响应体将不会被返回。这一方法可以再不必传输整个响应内容的情况下,就可以获取包含在响应小消息头中的元信息。
3、POST
向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。 Loadrunner中对应POST请求函数:web_submit_data,web_submit_form
4、PUT
向指定资源位置上传其最新内容
5、DELETE
请求服务器删除Request-URL所标识的资源
6、CONNECT
HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
7、OPTIONS
返回服务器针对特定资源所支持的HTTP请求方法,也可以利用向web服务器发送‘*’的请求来测试服务器的功能性
8、TRACE
回显服务器收到的请求,主要用于测试或诊断
9、PATCH
是对PUT方法的补充,用来对已知资源进行局部更新。