前端进阶之网络传输
跨域
同源策略
同源策略是一种约定,它是浏览器最核心也最基本的安全功能,如果缺少了同源策略,浏览器很容易受到XSS、CSRF等攻击。
所谓同源是指"协议+域名+端口"三者相同,即便两个不同的域名指向同一个ip地址,也非同源。
同源策略限制内容有:
- Cookie、LocalStorage、IndexedDB 等存储性内容
- DOM 节点
- AJAX 请求
但是有三个标签是允许跨域加载资源:
<img src='xxx'>
<link href='xxx'>
<script src='xxx'>
跨域并不是请求发不出去,只是结果被浏览器拦截了。
跨域解决方案
解决方案有jsonp
、cors
、postMessage
、websocket
、Node中间件代理(两次跨域)
、nginx反向代理
、window.name + iframe
、location.hash + iframe
、document.domain + iframe
,
CORS
支持所有类型的HTTP请求,是跨域HTTP请求的根本解决方案,JSONP
只支持GET请求,JSONP的优势在于支持老式浏览器,以及可以向不支持CORS的网站请求数据。- 不管是Node中间件代理还是nginx反向代理,主要是通过同源策略对服务器不加限制
日常工作中,用得比较多的跨域方案是cors和nginx反向代理
JSONP
利用 <script>
标签没有跨域限制的漏洞,网页可以得到从其他来源动态产生的 JSON
数据。
JSONP
请求一定需要对方的服务器做支持才可以。
- 优点是简单兼容性好,可用于解决主流浏览器的跨域数据访问的问题。
- 缺点是仅支持get方法具有局限性, 不安全可能会遭受XSS攻击。
实现流程:
// index.html
// 封装函数
function jsonp({ url, params, callback }){
return new Promise((resolve, reject) => {
let script = document.createElement('script')
window[callback] = function(data) {
resolve(data)
document.body.removeChild(script)
}
params = { ...params, callback }
let arrs = []
for (let key in params) {
arrs.push(`${key}=${params[key]}`)
}
script.src = `${url}?${arrs.join('&')}`
document.body.appendChild(script)
})
}
// 调用
jsonp({
url: 'http://localhost:3000/say',
params: { wd: 'go die' },
callback: 'now'
}).then(data => {
console.log(data)
})
这需要浏览器支持:
// server.js
let express = require('express')
let app = express()
app.get('/say', function(req, res){
let { wd, callback } = req.query
console.log(wd) // go die
console.log(callback) // now
res.end(`${callback}("no I dont't")`)
})
app.listen(3000)
CORS
CORS
需要浏览器和后端同时支持。
浏览器会自动进行 CORS
通信,实现 CORS
通信的关键是后端。只要后端实现了 CORS
,就实现了跨域。
服务端设置 Access-Control-Allow-Origin
就可以开启 CORS
。 该属性表示哪些域名可以访问资源,如果设置通配符则表示所有网站都可以访问资源。
postMessage
postMessage
是HTML5 XMLHttpRequest Level 2
中的API
,且是为数不多可以跨域操作的window
属性之一,它可用于解决以下方面的问题:
- 页面和其打开的新窗口的数据传递
- 多窗口之间消息传递
- 页面与嵌套的iframe消息传递
- 上面三个场景的跨域数据传递
postMessage()
方法允许来自不同源的脚本采用异步方式进行有限的通信,可以实现跨文本档、多窗口、跨域消息传递。
Websocket
Websocket
是HTML5
的一个持久化的协议,它实现了浏览器与服务器的全双工通信,同时也是跨域的一种解决方案。
WebSocket
和HTTP
都是应用层协议,都基于 TCP
协议。 但是 WebSocket
是一种双向通信协议,在建立连接之后,WebSocket
的 server
与 client
都能主动向对方发送或接收数据。
同时, WebSocket
在建立连接时需要借助 HTTP
协议,连接建立好了之后 client
与 server
之间的双向通信就与HTTP
无关了。
原生WebSocket API
使用起来不太方便,我们使用Socket.io
,它很好地封装了webSocket
接口,提供了更简单、灵活的接口,也对不支持webSocket
的浏览器提供了向下兼容
Node中间件代理(两次跨域)
实现原理:同源策略是浏览器需要遵循的标准,而如果是服务器向服务器请求就无需遵循同源策略。 代理服务器,需要做以下几个步骤:
- 接受客户端请求
- 将请求转发给服务器。
- 拿到服务器响应数据。
- 将响应转发给客户端。
nginx反向代理
实现原理类似于Node
中间件代理,需要你搭建一个中转nginx
服务器,用于转发请求。
使用nginx
反向代理实现跨域,是最简单的跨域方式。只需要修改nginx
的配置即可解决跨域问题,支持所有浏览器,支持session
,不需要修改任何代码,并且不会影响服务器性能。
实现思路:通过nginx
配置一个代理服务器(域名与domain1相同,端口不同)做跳板机,反向代理访问domain2接口,并且可以顺便修改cookie中domain信息,方便当前域cookie写入,实现跨域登录。
window.name + iframe
window.name
属性的独特之处:name值在不同的页面(甚至不同域名)加载后依旧存在,并且可以支持非常长的 name 值(2MB)。
总结:通过iframe
的src
属性由外域转向本地域,跨域数据即由iframe
的window.name
从外域传递到本地域。这个就巧妙地绕过了浏览器的跨域访问限制,但同时它又是安全操作。
location.hash + iframe
实现原理: a.html欲与c.html跨域相互通信,通过中间页b.html来实现。 三个页面,不同域之间利用iframe的location.hash传值,相同域之间直接js访问来通信。
具体实现步骤:一开始a.html给c.html传一个hash值,然后c.html收到hash值后,再把hash值传递给b.html,最后b.html将结果放到a.html的hash值中。
同样的,a.html和b.html是同域的,都是http://localhost:3000;而c.html是http://localhost:4000
document.domain + iframe
该方式只能用于二级域名相同的情况下,比如 a.test.com 和 b.test.com 适用于该方式。 只需要给页面添加 document.domain ='test.com' 表示二级域名都相同就可以实现跨域。
实现原理:两个页面都通过js强制设置document.domain为基础主域,就实现了同域。
有什么方法可以保持前后端实时通信
- WebSocket
- 优点:WebSocket 是 HTML5 开始提供的一种在单个 TCP 连接上进行全双工通讯的协议,可从HTTP升级而来,浏览器和服务器只需要一次握手,就可以进行持续的,双向的数据传输,因此能显著节约资源和带宽
- 缺点
- 兼容性问题:不支持较低版本的IE浏览器(IE9及以下)
- 不支持断线重连,需要手写心跳连接的逻辑
- 通信机制相对复杂
- server-sent-event(event-source)
- 优点:
- 只需一次请求,便可以stream的方式多次传送数据,节约资源和带宽
- 相对WebSocket来说简单易用
- 内置断线重连功能(retry)
- 缺点是单向的,只支持服务端->客户端的数据传送,客户端到服务端的通信仍然依靠AJAX。且兼容性令人担忧,IE浏览器完全不支持
- 优点:
- AJAX轮询
- 优点:兼容性良好,对标低版本IE
- 缺点:请求中有大半是无用的请求,浪费资源
常见 http status
1XX
系列:指定客户端应相应的某些动作,代表请求已被接受,需要继续处理。- 由于 HTTP/1.0 协议中没有定义任何 1xx 状态码,所以除非在某些试验条件下,服务器禁止向此类客户端发送 1xx 响应。
2XX
系列:代表请求已成功被服务器接收、理解、并接受。这系列中最常见的有200
、201
状态码。- 2开头 (请求成功)表示成功处理了请求的状态代码。
- 200 (成功) 服务器已成功处理了请求。 通常,这表示服务器提供了请求的网页。
- 201 (已创建) 请求成功并且服务器创建了新的资源。
- 202 (已接受) 服务器已接受请求,但尚未处理。
- 203 (非授权信息) 服务器已成功处理了请求,但返回的信息可能来自另一来源。
- 204 (无内容) 服务器成功处理了请求,但没有返回任何内容。
- 205 (重置内容) 服务器成功处理了请求,但没有返回任何内容。
- 206 (部分内容) 服务器成功处理了部分 GET 请求。
3XX
系列:代表需要客户端采取进一步的操作才能完成请求,这些状态码用来重定向,后续的请求地址(重定向目标)在本次响应的 Location 域中指明。这系列中最常见的有301
、302
状态码。- 3开头 (请求被重定向)表示要完成请求,需要进一步操作。 通常,这些状态代码用来重定向。
- 300 (多种选择) 针对请求,服务器可执行多种操作。 服务器可根据请求者 (user agent) 选择一项操作,或提供操作列表供请求者选择。
- 301 (永久移动) 请求的网页已永久移动到新位置。 服务器返回此响应(对 GET 或 HEAD 请求的响应)时,会自动将请求者转到新位置。
- 302 (临时移动) 服务器目前从不同位置的网页响应请求,但请求者应继续使用原有位置来进行以后的请求。
- 303 (查看其他位置) 请求者应当对不同的位置使用单独的 GET 请求来检索响应时,服务器返回此代码。
- 304 (未修改) 自从上次请求后,请求的网页未修改过。 服务器返回此响应时,不会返回网页内容。
- 305 (使用代理) 请求者只能使用代理访问请求的网页。 如果服务器返回此响应,还表示请求者应使用代理。
- 307 (临时重定向) 服务器目前从不同位置的网页响应请求,但请求者应继续使用原有位置来进行以后的请求。
4XX
系列:表示请求错误。代表了客户端看起来可能发生了错误,妨碍了服务器的处理。常见有:401
、404
状态码。- 4开头 (请求错误)这些状态代码表示请求可能出错,妨碍了服务器的处理。
- 400 (错误请求) 服务器不理解请求的语法。
- 401 (未授权) 请求要求身份验证。 对于需要登录的网页,服务器可能返回此响应。
- 403 (禁止) 服务器拒绝请求。
- 404 (未找到) 服务器找不到请求的网页。
- 405 (方法禁用) 禁用请求中指定的方法。
- 406 (不接受) 无法使用请求的内容特性响应请求的网页。
- 407 (需要代理授权) 此状态代码与 401(未授权)类似,但指定请求者应当授权使用代理。
- 408 (请求超时) 服务器等候请求时发生超时。
- 409 (冲突) 服务器在完成请求时发生冲突。 服务器必须在响应中包含有关冲突的信息。
- 410 (已删除) 如果请求的资源已永久删除,服务器就会返回此响应。
- 411 (需要有效长度) 服务器不接受不含有效内容长度标头字段的请求。
- 412 (未满足前提条件) 服务器未满足请求者在请求中设置的其中一个前提条件。
- 413 (请求实体过大) 服务器无法处理请求,因为请求实体过大,超出服务器的处理能力。
- 414 (请求的 URI 过长) 请求的 URI(通常为网址)过长,服务器无法处理。
- 415 (不支持的媒体类型) 请求的格式不受请求页面的支持。
- 416 (请求范围不符合要求) 如果页面无法提供请求的范围,则服务器会返回此状态代码。
- 417 (未满足期望值) 服务器未满足"期望"请求标头字段的要求。
5xx
系列:代表了服务器在处理请求的过程中有错误或者异常状态发生,也有可能是服务器意识到以当前的软硬件资源无法完成对请求的处理。常见有500
、503
状态码。- 5开头(服务器错误)这些状态代码表示服务器在尝试处理请求时发生内部错误。 这些错误可能是服务器本身的错误,而不是请求出错。
- 500 (服务器内部错误) 服务器遇到错误,无法完成请求。
- 501 (尚未实施) 服务器不具备完成请求的功能。 例如,服务器无法识别请求方法时可能会返回此代码。
- 502 (错误网关) 服务器作为网关或代理,从上游服务器收到无效响应。
- 503 (服务不可用) 服务器目前无法使用(由于超载或停机维护)。 通常,这只是暂时状态。
- 504 (网关超时) 服务器作为网关或代理,但是没有及时从上游服务器收到请求。
- 505 (HTTP 版本不受支持) 服务器不支持请求中所用的 HTTP 协议版本。
HTTP
HTTP
是互联网上应用最为广泛的一种网络协议,是一个客户端和服务器端请求和应答的标准(TCP),用于从WWW
服务器传输超文本到本地浏览器的传输协议,它可以使浏览器更加高效,使网络传输减少。
HTTPS
是以安全为目标的HTTP
通道,简单讲是HTTP
的安全版,即HTTP
下加入SSL
层,HTTPS
的安全基础是SSL
,因此加密的详细内容就需要SSL
。
HTTPS
协议的主要作用可以分为两种:一种是建立一个信息安全通道,来保证数据传输的安全;另一种就是确认网站的真实性。
HTTPS和HTTP的区别主要如下:
https
协议需要到ca
申请证书,一般免费证书较少,因而需要一定费用。http
是超文本传输协议,信息是明文传输,https则是具有安全性的ssl加密传输协议。http
和https
使用的是完全不同的连接方式,用的端口也不一样,前者是80
,后者是443
。http
的连接很简单,是无状态的;HTTPS
协议是由SSL+HTTP
协议构建的可进行加密传输、身份认证的网络协议,比http
协议安全。
http1.x 和http2.x主要有以下4个区别:
HTTP2
使用的是二进制传送,HTTP1.X
是文本(字符串)传送。二进制传送的单位是帧和流。帧组成了流,同时流还有流ID标示HTTP2
支持多路复用。因为有流ID,所以通过同一个http请求实现多个http请求传输变成了可能,可以通过流ID来标示究竟是哪个流从而定位到是哪个http请求HTTP2
头部压缩。HTTP2通过gzip和compress压缩头部然后再发送,同时客户端和服务器端同时维护一张头信息表,所有字段都记录在这张表中,这样后面每次传输只需要传输表里面的索引Id就行,通过索引ID查询表头的值HTTP2
支持服务器推送。HTTP2支持在未经客户端许可的情况下,主动向客户端推送内容
http请求方式有以下8种,其中get和post是最常用的:
- OPTIONS
- 返回服务器针对特定资源所支持的HTTP请求方法,也可以利用向web服务器发送‘*’的请求来测试服务器的功能性
- HEAD
- 向服务器索与GET请求相一致的响应,只不过响应体将不会被返回。这一方法可以再不必传输整个响应内容的情况下,就可以获取包含在响应小消息头中的元信息。
- GET
- 向特定的资源发出请求。
- POST
- 向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。数据被包含在请求体中。POST请求可能会导致新的资源的建立或已有资源的修改 。
- PUT
- 向指定资源位置上传其最新内容
- DELETE
- 请求服务器删除Request-URL所标识的资源
- TRACE
- 回显服务器收到的请求,主要用于测试或诊断
- CONNECT
- HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
HTTPS如何保证安全
HTTPS
(全称:Hypertext Transfer Protocol over Secure Socket Layer),是以安全为目标的HTTP通道,简单讲是HTTP的安全版。
HTTPS = HTTP + SSL/TLS
,如今 SSL 已废弃,所以现在只关注 HTTP + TLS。
为了解决 HTTP 协议的问题,HTTPS 引入了数据加密和身份验证机制。在开始传输数据之前,通过安全可靠的 TLS 协议进行加密,从而保证后续加密传输数据的安全性。
TLS
协议:传输层安全性协议(Transport Layer Security,TLS)及其前身安全套接层(Secure Sockets LayerSSL
)是一种安全协议,目的是为了保证网络通信安全和数据完整性。
受 TLS 协议保护的通信过程:先对传输的数据进行了加密(使用对称加密算法)。并且对称加密的密钥是为每一个连接唯一生成的(基于 TLS 握手阶段协商的加密算法和共享密钥),然后发送的每条消息都会通过消息验证码(Message authentication code, MAC),来进行消息完整性检查,最后还可以使用公钥对通信双方进行身份验证
Https的作用:
- 内容加密 建立一个信息安全通道,来保证数据传输的安全;
- 身份认证 确认网站的真实性
- 数据完整性 防止内容被第三方冒充或者篡改
非对称加密和对称加密
- 对称加密 在对称加密算法中,加密使用的密钥和解密使用的密钥是相同的。也就是说,加密和解密都是使用的同一个密钥。
- 非对称加密 指加密和解密使用不同密钥的加密算法。非对称加密算法需要两个密钥:公钥(public key)私钥(private key)。
- 公钥与私钥是一对存在,如果用公钥对数据进行加密,只有用对应的私钥才能解密;
- 如果用密钥对数据进行加密,那么只有用对应的公钥才能解密。因为加密和解密使用的是两个不同的密钥,所以这种算法叫作非对称加密算法。
- 要求提供一条安全的渠道使通讯双方在首次通讯时协商一个共同的密钥。直接的面对面协商可能是不现实而且难于实施的,所以双方可能需要借助于邮件和电话等其它相对不够安全的手段来进行协商;
- 密钥的数目难于管理。因为对于每一个合作者都需要使用不同的密钥,很难适应开放社会中大量的信息交流
- 对称加密算法一般不能提供信息完整性的鉴别。它无法验证发送者和接受者的身份
- 对称密钥的管理和分发工作是一件具有潜在危险的和烦琐的过程。对称加密是基于共同保守秘密来实现的,采用对称加密技术的贸易双方必须保证采用的是相同的密钥,保证彼此密钥的交换是安全可靠的,同时还要设定防止密钥泄密和更改密钥的程序。
数字证书
- 数字证书就是互联网通讯中标志通讯各方身份信息的一串数字,提供了一种在Internet上验证通信实体身份的方式,数字证书不是数字身份证,而是身份认证机构盖在数字身份证上的一个章或印(或者说加在数字身份证上的一个签名)。
- 它是由权威机构——CA机构,又称为证书授权(Certificate Authority)中心发行的,人们可以在网上用它来识别对方的身份。
- 数字证书绑定了公钥及其持有者的真实身份,它类似于现实生活中的居民身份证,所不同的是数字证书不再是纸质的证照,而是一段含有证书持有者身份信息并经过认证中心审核签发的电子数据,广泛用在电子商务和移动互联网中。
数字签名
- 数字签名是将摘要信息用发送者的私钥加密,与原文一起传送给接收者。接收者只有用发送者的公钥才能解密被加密的摘要信息,然后用HASH函数对收到的原文产生一个摘要信息,与解密的摘要信息对比
- 数字签名是个加密的过程,数字签名验证是个解密的过程。
- 数字签名用来,保证信息传输的完整性、发送者的身份认证、防止交易中的抵赖发生。非对称加密算法实现机密信息交换的基本过程是:甲方生成一对密钥并将其中的一把作为公用密钥向其它方公开;得到该公用密钥的乙方使用该密钥对机密信息进行加密后再发送给甲方;甲方再用自己保存的另一把专用密钥对加密后的信息进行解密。
非对称加密和对称加密在HTTPS协议中的应用
- 浏览器向服务器发出请求,询问对方支持的对称加密算法和非对称加密算法;服务器回应自己支持的算法。
- 浏览器选择双方都支持的加密算法,并请求服务器出示自己的证书;服务器回应自己的证书。
- 浏览器随机产生一个用于本次会话的对称加密的钥匙,并使用服务器证书中附带的公钥对该钥匙进行加密后传递给服务器;服务器为本次会话保持该对称加密的钥匙。第三方不知道服务器的私钥,即使截获了数据也无法解密。非对称加密让任何浏览器都可以与服务器进行加密会话。
- 浏览器使用对称加密的钥匙对请求消息加密后传送给服务器,服务器使用该对称加密的钥匙进行解密;服务器使用对称加密的钥匙对响应消息加密后传送给浏览器,浏览器使用该对称加密的钥匙进行解密。第三方不知道对称加密的钥匙,即使截获了数据也无法解密。对称加密提高了加密速度 。
完整的非对称加密过程
假如现在 你向支付宝 转账(术语数据信息),为了保证信息传送的保密性、真实性、完整性和不可否认性,需 要对传送的信息进行数字加密和签名,其传送过程为:
- 首先你要确认是否是支付宝的数字证书,如果确认为支付宝身份后,则对方真实可信。可以向对方传送 信息
- 你准备好要传送的数字信息(明文)计算要转的多少钱,对方支付宝账号等;
- 你对数字信息进行哈希运算,得到一个信息摘要(客户端主要职责);
- 你用自己的私钥对信息摘要进行加密得到 你 的数字签名,并将其附在数字信息上;
- 你随机产生一个加密密钥,并用此密码对要发送的信息进行加密(密文);
- 你用支付宝的公钥对刚才随机产生的加密密钥进行加密,将加密后的 DES 密钥连同密文一起传送给支付 宝
- 支付宝收到 你 传送来的密文和加密过的 DES 密钥,先用自己的私钥对加密的 DES 密钥进行解密,得到 你随机产生的加密密钥;
- 支付宝 然后用随机密钥对收到的密文进行解密,得到明文的数字信息,然后将随机密钥抛弃;
- 支付宝 用你 的公钥对 你的的数字签名进行解密,得到信息摘要;
- 支付宝用相同的哈希算法对收到的明文再进行一次哈希运算,得到一个新的信息摘要;
- 支付宝将收到的信息摘要和新产生的信息摘要进行比较,如果一致,说明收到的信息没有被修改过;
- 确定收到信息,然后进行向对方进行付款交易,一次非对称密过程结束。
TCP vs UDP
TCP
是一种面向连接的、可靠的、基于字节流的传输层通信协议,是专门为了在不可靠的网络中提供一个可靠的端对端字节流而设计的,面向字节流。UDP
(用户数据报协议)是iso
参考模型中一种无连接的传输层协议,提供简单不可靠的非连接传输层服务,面向报文
区别:
- TCP是面向连接的,可靠性高;UDP是基于非连接的,可靠性低
- 由于TCP是连接的通信,需要有三次握手、重新确认等连接过程,会有延时,实时性差,同时过程复杂,也使其易于攻击;UDP没有建立连接的过程,因而实时性较强,也稍安全
- 在传输相同大小的数据时,TCP首部开销20字节;UDP首部开销8字节,TCP报头比UDP复杂,故实际包含的用户数据较少。TCP在IP协议的基础上添加了序号机制、确认机制、超时重传机制等,保证了传输的可靠性,不会出现丢包或乱序,而UDP有丢包,故TCP开销大,UDP开销较小
- 每条TCP连接只能时点到点的;UDP支持一对一、一对多、多对一、多对多的交互通信
应用场景选择:
- 对实时性要求高和高速传输的场合下使用UDP;在可靠性要求低,追求效率的情况下使用UDP;
- 需要传输大量数据且对可靠性要求高的情况下使用TCP
FTP DNS
DNS
(Domain Name Service 域名服务) 协议基于 UDP协议FTP
(File Transfer Protocol 文件传输协议) 基于 TCP协议- DNS和FTP都是应用层协议
URL URI
一个完整的url
分为4部分:
- 协议 Http Https
- 域名 例
www.baidu.com
为网站名字。 baidu.com为一级域名,www是二级服务 - 端口 默认是80端口号
- 路径
- 查询参数
URI
是一个用于标识互联网资源名称的字符串。
该种标识允许用户对网络中(一般指万维网)的资源通过特定的协议进行交互操作。URI的最常见的形式是统一资源定位符(URL),经常指定为非正式的网址。更罕见的用法是统一资源名称(URN),其目的是通过提供一种途径。用于在特定的命名空间资源的标识,以补充网址。
扩展:
URL
和URN
是URI
的子集,URI
属于URL
更高层次的抽象,一种字符串文本标准。
获取地址栏参数
- 正则语句:
new RegExp("(^|&)" + name + "=([^&]*)(&|$)", "i");
function getQueryString(name) {
let reg = new RegExp("(^|&)" + name + "=([^&]*)(&|$)", "i");
let r = window.location.search.substr(1).match(reg);
if (r != null) {
return decodeURIComponent(r[2]); // 解码得到的参数
};
return null;
} - split拆分法
function GetRequest() {
const url = location.search; //获取url中"?"符后的字串
let theRequest = new Object();
if (url.indexOf("?") != -1) {
let str = url.substr(1);
strs = str.split("&")
for(let i = 0; i < strs.length; i ++) {
theRequest[strs[i].split("=")[0]]= unescape(strs[i].split("=")[1]);
}
}
return theRequest;
}
DNS
DNS(Domain Name Server,域名服务器)是进行域名(domain name)和与之相对应的IP地址 (IP address)转换的服务器。
DNS中保存了一张域名(domain name)和与之相对应的IP地址 (IP address)的表,以解析消息的域名。
域名是Internet上某一台计算机或计算机组的名称,用于在数据传输时标识计算机的电子方位(有时也指地理位置)。 域名是由一串用点分隔的名字组成的,通常包含组织名,而且始终包括两到三个字母的后缀,以指明组织的类型或该域所在的国家或地区。
DNS是应用层协议,事实上他是为其他应用层协议工作的,包括不限于HTTP和SMTP以及FTP,用于将用户提供的主机名解析为ip地址。 具体过程如下:
- 客户机提出域名解析请求, 并将该请求发送给本地的域名服务器 ;
- 当本地的域名服务器收到请求后, 就先查询本地的缓存, 如果有该纪录项 , 则本地的域名服务器就直接把查询的结果返回 ;
- 如果本地的缓存中没有该纪录, 则本地域名服务器就直接把请求发给根域名服务器, 然后根域名服务器再返回给本地域名服务器一个所查询域 (根的子域) 的主域名服务器的地址 ;
- 本地服务器再向上一步返回的域名服务器发送请求, 然后接受请求的服务器查询自己的缓存, 如果没有该纪录, 则返回相关的下级的域名服务器的地址 ;
- 重复第四步, 直到找到正确的纪录 ;
- 本地域名服务器把返回的结果保存到缓存, 以备下一次使用, 同时还将结果返回给客户机 ;
http缓存
http缓存的分类:根据是否需要重新向服务器发起请求来分类,可分为(强制缓存,协商缓存) 强制缓存如果生效,不需要再和服务器发生交互,而协商缓存不管是否生效,都需要与服务端发生交互。
根据是否可以被单个或者多个用户使用来分类,可分为(私有缓存,共享缓存)
- 强制缓存
- 强制缓存在缓存数据未失效的情况下(即Cache-Control的max-age没有过期或者Expires的缓存时间没有过期)那么就会直接使用浏览器的缓存数据,不会再向服务器发送任何请求。
- 强制缓存生效时,http状态码为200。这种方式页面的加载速度是最快的,性能也是很好的,但是在这期间,如果服务器端的资源修改了,页面上是拿不到的,因为它不会再向服务器发请求了。这种情况就是我们在开发种经常遇到的,比如你修改了页面上的某个样式,在页面上刷新了但没有生效,因为走的是强缓存,所以Ctrl + F5一顿操作之后就好了。
- 跟强制缓存相关的header头属性有(Pragma/Cache-Control/Expires), Pragma和Cache-control共存时,Pragma的优先级是比Cache-Control高的。
- 协商缓存
- 当第一次请求时服务器返回的响应头中没有Cache-Control和Expires或者Cache-Control和Expires过期还或者它的属性设置为no-cache时(即不走强缓存),
- 那么浏览器第二次请求时就会与服务器进行协商,与服务器端对比判断资源是否进行了修改更新。如果服务器端的资源没有修改,那么就会返回304状态码,告诉浏览器可以使用缓存中的数据,这样就减少了服务器的数据传输压力。
- 如果数据有更新就会返回200状态码,服务器就会返回更新后的资源并且将缓存信息一起返回。
- 跟协商缓存相关的header头属性有(ETag/If-Not-Match 、Last-Modified/If-Modified-Since)请求头和响应头需要成对出现
- 私有缓存(浏览器级缓存) 私有缓存只能用于单独的用户:Cache-Control: Private
- 共享缓存(代理级缓存) 共享缓存可以被多个用户使用: Cache-Control: Public
协商缓存: 向服务器发送请求,服务器会根据这个请求的request header的一些参数来判断是否命中协商缓存, 如果命中,则返回304状态码并带上新的response header通知浏览器从缓存中读取资源;服务器和请求协商,根据请求头携带的参数进行协商
GET和POST区别
- get用来获取数据,post用来提交数据
- get参数有长度限制(受限于url长度,具体的数值取决于浏览器和服务器的限制,最长2048字节),而post无限制
- get请求的数据会附加在url之,以 " ? "分割url和传输数据,多个参数用 "&"连接,而post请求会把请求的数据放在http请求体中。
- get是明文传输,post是放在请求体中,但是开发者可以通过抓包工具看到,也相当于是明文的。
- get请求会保存在浏览器历史记录中,还可能保存在web服务器的日志中
OSI七层协议
OSI(Open System Interconnect),即开放式系统互联。 一般都叫OSI参考模型,是ISO(国际标准化组织)组织在1985年研究的网络互连模型。ISO为了更好的使网络应用更为普及,推出了OSI参考模型。 其含义就是推荐所有公司使用这个规范来控制网络。这样所有公司都有相同的规范,就能互联了。 OSI定义了网络互连的七层框架(物理层、数据链路层、网络层、传输层、会话层、表示层、应用层),即ISO开放互连系统参考模型。
- 应用层
- 作用:它是与其他计算机进行通信的应用,它是对应应用程序的通信服务的。各种应用软件,包括web应用。
- 协议:DNS、FTP、HTTP、SMTP、TELNET、IRC、WHOIS
- 表示层
- 作用:这一层的主要作用是定义数据格式和加密。
- 会话层
- 作用:控制应用程序的会话能力,它定义了一段会话的开始、控制和结束,包括对多个双向消息的控制和管理,以便在只完成一部分消息时可以通知应用。
- 协议
- HTTP(Hyper text Transfer Protocol)协议:超文本传输协议使用TCP的80端口
- FTP(File Transfer Protocol)文本传输协议
- SMTP(Simple Mail Transfer Protocol)简单邮件传输协议,TCP是我25端口用户发邮件。
- POP3(Post Office Protocol version3)邮局协议版本3,TCP的110号端口,用于收邮件的。
- DNS(Domain Name System)域名解析协议。使用TCP和UDP的53号端口,作用是把www的域名解析成IP地址。
- 传输层
- 作用:对差错恢复协议和无差错恢复协议的选择,对同一主机上不同数据流的输入进行复用,对数据包进行重新排序。
- 是最关键的一层,是唯一负责整体的数据传输和数据控制的。对上三层提供可靠的传输服务,对网络层提供可靠的目的地信息。在这一层数据的单位被称为数据段。
- 协议:TCP、UDP等
- 网络层
- 作用:主要负责寻找地址和路由选择,网络层还可以实现阻塞控制、网际互联等。
- 协议:IP、IPX、RIP、OSPF等
- 数据链路层
- 作用:负责物理层面上的互联的、节点间的通信传输;该层的作用包括:物理地址寻址、数据的成帧、流量控制、数据的检错、重发等。在这一层,数据的单位称为帧(frame)
- 协议:ARP、RARP、SDLC、HDLC、PPP、STP、帧中继等
- 物理层
- 作用:负责0、1 比特流(0/1序列)与电压的高低、逛的闪灭之间的转换 规定了激活、维持、关闭通信端点之间的机械特性、电气特性、功能特性以及过程特性;该层为上层协议提供了一个传输数据的物理媒体。在这一层,数据的单位称为比特(bit)。
- 典型规范:EIA/TIA RS-232、EIA/TIA RS-449、V.35、RJ-45、fddi令牌环网等
tcp/ip协议栈、网络模型
TCP/IP 协议栈是一系列网络协议的总和,是构成网络通信的核心骨架,它定义了电子设备如何连入因特网,以及数据如何在它们之间进行传输。 TCP/IP 协议采用4层结构,分别是应用层、传输层、网络层和链路层,
- 链路层:对0和1进行分组,定义数据帧,确认主机的物理地址,传输数据;
- 网络层:定义IP地址,确认主机所在的网络位置,并通过IP进行MAC寻址,对外网数据包进行路由转发;
- 传输层:定义端口,确认主机上应用程序的身份,并将数据包交给对应的应用程序;
- 应用层:定义数据格式,并按照对应的格式解读数据。
xhr 的 readyState
readyState
是XMLHttpRequest
对象的一个属性,用来标识当前XMLHttpRequest
对象处于什么状态。
readyState
总共有5个状态值,分别为0~4,每个值代表了不同的含义
0:初始化,XMLHttpRequest对象还没有完成初始化
1:载入,XMLHttpRequest对象开始发送请求
2:载入完成,XMLHttpRequest对象的请求发送完成
3:解析,XMLHttpRequest对象开始读取服务器的响应
4:完成,XMLHttpRequest对象读取服务器响应结束
hosts 文件是什么?
hosts
文件是个没有扩展名的系统文件,其作用就是将网址域名和其对应的 IP 地址建立一个关联“数据库”,当用户在浏览器中输入一个 url 时,系统会首先自动从 hosts 文件中寻找对应的 IP 地址。
常用的http请求头以及响应头
一、常用的http请求头
- Accept
- Accept: text/html 浏览器可以接受服务器回发的类型为 text/html。
- Accept: / 代表浏览器可以处理所有类型,(一般浏览器发给服务器都是发这个)。
- Accept-Encoding
- Accept-Encoding: gzip, deflate 浏览器申明自己接收的编码方法,通常指定压缩方法,是否支持压缩
- 支持什么压缩方法(gzip,deflate),(注意:这不是只字符编码)。
- Accept-Language
- Accept-Language:zh-CN,zh;q=0.9 浏览器申明自己接收的语言。
- Connection
- Connection: keep-alive 当一个网页打开完成后,客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭,如果客户端再次访问这个服务器上的网页,会继续使用这一条已经建立的连接。
- Connection: close 代表一个Request完成后,客户端和服务器之间用于传输HTTP数据的TCP连接会关闭, 当客户端再次发送Request,需要重新建立TCP连接。
- Host(发送请求时,该报头域是必需的)
- Host: 请求报头域主要用于指定被请求资源的Internet主机和端口号,它通常从HTTP URL中提取出来的。
- Referer
- Referer: 当浏览器向web服务器发送请求的时候,一般会带上Referer,告诉服务器我是从哪个页面链接过来的,服务器籍此可以获得一些信息用于处理。
- User-Agent
- 告诉HTTP服务器,客户端使用的操作系统和浏览器的名称和版本。
- Cache-Control
- Cache-Control:private 默认为private 响应只能够作为私有的缓存,不能再用户间共享
- Cache-Control:public 响应会被缓存,并且在多用户间共享。正常情况, 如果要求HTTP认证,响应会自动设置为 private
- Cache-Control:must-revalidate 响应在特定条件下会被重用,以满足接下来的请求,但是它必须到服务器端去验证它是不是仍然是最新的。
- Cache-Control:no-cache 响应不会被缓存,而是实时向服务器端请求资源。
- Cache-Control:max-age=10 设置缓存最大的有效时间
- Cache-Control:no-store 在任何条件下,响应都不会被缓存,并且不会被写入到客户端的磁盘里,这也是基于安全考虑的某些敏感的响应才会使用这个。
- Cookie
- Range(用于断点续传)
- Range:bytes=0-5 指定第一个字节的位置和最后一个字节的位置。用于告诉服务器自己想取对象的哪部分。
二、常用的http响应头
- Cache-Control(对应请求中的Cache-Control)
- Content-Type
- Content-Type:text/html;charset=UTF-8 告诉客户端,资源文件的类型,还有字符编码,客户端通过utf-8对资源进行解码,然后对资源进行html解析。
- Content-Encoding
- Date
- Date: Tue, 03 Apr 2018 03:52:28 GMT 这个是服务端发送资源时的服务器时间,GMT是格林尼治所在地的标准时间。
- http协议中发送的时间都是GMT的,这主要是解决在互联网上,不同时区在相互请求资源的时候,时间混乱问题。
- Server
- 告诉客户端服务器信息
- Transfer-Encoding
- Transfer-Encoding:chunked 这个响应头告诉客户端,服务器发送的资源的方式是分块发送的。
- Expires
- Expires:Sun, 1 Jan 2000 01:00:00 GMT 这个响应头也是跟缓存有关的,告诉客户端在这个时间前,可以直接访问缓存副本
- Last-Modified
- 所请求的对象的最后修改日期
- Connection
- Connection:keep-alive,告诉客户端服务器的tcp连接也是一个长连接,客户端可以继续使用这个tcp连接发送http请求。
- Etag
- ETag的作用跟Last-Modified的作用差不多,主要供WEB服务器判断一个对象是否改变了
- 比如前一次请求某个html文件时,获得了其ETag,当这次又请求这个文件时,浏览器就会把先前获得ETag值发送给WEB服务器,然后WEB服务器会把这个ETag跟该文件的当前ETag进行对比,然后就知道这个文件有没有改变了。
- Refresh
- 用于重定向,或者当一个新的资源被创建时。默认会在5秒后刷新重定向。
- Access-Control-Allow-Origin
- 指定哪些网站可以跨域资源共享;* 号代表所有网站可以跨域资源共享
- Access-Control-Allow-Methods
- 允许哪些方法来访问
- Access-Control-Allow-Credentials
- 是否允许发送cookie
- Content-Range
- Content-Range: bytes 0-5/7877 指定整个实体中的一部分的插入位置,他也指示了整个实体的长度。
- 在服务器向客户返回一个部分响应,它必须描述响应覆盖的范围和整个实体长度。
no-store 和 no-cache 的区别
no-cache
和 no-store
都是 HTTP
协议头 Cache-Control
的值。
no-store
彻底禁用缓冲,所有内容都不会被缓存到缓存或临时文件中。no-cache
在浏览器使用缓存前,会往返对比 ETag,如果 ETag 没变,返回 304,则使用缓存。
Cache-Control和expires
Cache-Control
设置时间长度Expires
设置时间点
优先级:
强缓存expires和cache-control同时存在时,则cache-control会覆盖expires,expires无论有没有过期,都无效。
即:cache-control优先级 > expires优先级。