http状态码有那些?分别代表是什么意思?
100 Continue 继续,一般在发送post请求时,已发送了http header之后服务端将返回此信息,表示确认,之后发送具体参数信息
200 OK 正常返回信息
201 Created 请求成功并且服务器创建了新的资源
202 Accepted 服务器已接受请求,但尚未处理
301 Moved Permanently 请求的网页已永久移动到新位置。
302 Found 临时性重定向。
303 See Other 临时性重定向,且总是使用 GET 请求新的 URI。
304 Not Modified 自从上次请求后,请求的网页未修改过。
400 Bad Request 服务器无法理解请求的格式,客户端不应当尝试再次使用相同的内容发起请求。
401 Unauthorized 请求未授权。
403 Forbidden 禁止访问。
404 Not Found 找不到如何与 URI 相匹配的资源。
500 Internal Server Error 最常见的服务器端错误。
503 Service Unavailable 服务器端暂时无法处理请求(可能是过载或维护)。
]
一个页面从输入 URL 到页面加载显示完成,这个过程中都发生了什么?(流程说的越详细越好)
注:这题胜在区分度高,知识点覆盖广,再不懂的人,也能答出几句,
而高手可以根据自己擅长的领域自由发挥,从URL规范、HTTP协议、DNS、CDN、数据库查询、
到浏览器流式解析、CSS规则构建、layout、paint、onload/domready、JS执行、JS API绑定等等;
-
详细版:
浏览器会开启一个线程来处理这个请求,对 URL 分析判断如果是 http 协议就按照 Web 方式来处理;
调用浏览器内核中的对应方法,比如 WebView 中的 loadUrl 方法;
通过DNS解析获取网址的IP地址,设置 UA 等信息发出第二个GET请求;
进行HTTP协议会话,客户端发送报头(请求报头);
进入到web服务器上的 Web Server,如 Apache、Tomcat、Node.JS 等服务器;
进入部署好的后端应用,如 PHP、Java、JavaScript、Python 等,找到对应的请求处理;
处理结束回馈报头,此处如果浏览器访问过,缓存上有对应资源,会与服务器最后修改时间对比,一致则返回304;
浏览器开始下载html文档(响应报头,状态码200),同时使用缓存;
文档树建立,根据标记请求所需指定MIME类型的文件(比如css、js),同时设置了cookie;
页面开始渲染DOM,JS根据DOM API操作DOM,执行事件绑定等,页面显示完成。
-
简洁版:
浏览器根据请求的URL交给DNS域名解析,找到真实IP,向服务器发起请求;
服务器交给后台处理完成后返回数据,浏览器接收文件(HTML、JS、CSS、图象等);
浏览器对加载到的资源(HTML、JS、CSS等)进行语法解析,建立相应的内部数据结构(如HTML的DOM);
载入解析到的资源文件,渲染页面,完成。
说说TCP传输的三次握手四次挥手策略
为了准确无误地把数据送达目标处,TCP协议采用了三次握手策略。用TCP协议把数据包送出去后,TCP不会对传送 后的情况置之不理,它一定会向对方确认是否成功送达。握手过程中使用了TCP的标志:SYN和ACK
发送端首先发送一个带SYN标志的数据包给对方。接收端收到后,回传一个带有SYN/ACK标志的数据包以示传达确认信息。 最后,发送端再回传一个带ACK标志的数据包,代表“握手”结束。 若在握手过程中某个阶段莫名中断,TCP协议会再次以相同的顺序发送相同的数据包
断开一个TCP连接则需要“四次握手”:
第一次挥手:主动关闭方发送一个FIN,用来关闭主动方到被动关闭方的数据传送,也就是主动关闭方告诉被动关闭方:我已经不 会再给你发数据了(当然,在fin包之前发送出去的数据,如果没有收到对应的ack确认报文,主动关闭方依然会重发这些数据),但是,此时主动关闭方还可 以接受数据
第二次挥手:被动关闭方收到FIN包后,发送一个ACK给对方,确认序号为收到序号+1(与SYN相同,一个FIN占用一个序号)
第三次挥手:被动关闭方发送一个FIN,用来关闭被动关闭方到主动关闭方的数据传送,也就是告诉主动关闭方,我的数据也发送完了,不会再给你发数据了
第四次挥手:主动关闭方收到FIN后,发送一个ACK给被动关闭方,确认序号为收到序号+1,至此,完成四次挥手
TCP和UDP的区别
TCP(Transmission Control Protocol,传输控制协议)是基于连接的协议,也就是说,在正式收发数据前,必须和对方建立可靠的连接。一个TCP连接必须要经过三次“对话”才能建立起来
UDP(User Data Protocol,用户数据报协议)是与TCP相对应的协议。它是面向非连接的协议,它不与对方建立连接,而是直接就把数据包发送过去! UDP适用于一次只传送少量数据、对可靠性要求不高的应用环境
HTTP和HTTPS
HTTP协议通常承载于TCP协议之上,在HTTP和TCP之间添加一个安全协议层(SSL或TSL),这个时候,就成了我们常说的HTTPS
默认HTTP的端口号为80,HTTPS的端口号为443
为什么HTTPS安全
- 因为网络请求需要中间有很多的服务器路由器的转发。中间的节点都可能篡改信息,而如果使用HTTPS,密钥在你和终点站才有。https之所以比http安全,是因为他利用ssl/tls协议传输。它包含证书,卸载,流量转发,负载均衡,页面适配,浏览器适配,refer传递等。保障了传输过程的安全性
关于Http 2.0 你知道多少?
HTTP/2引入了“服务端推(server push)”的概念,它允许服务端在客户端需要数据之前就主动地将数据发送到客户端缓存中,从而提高性能。
HTTP/2提供更多的加密支持
HTTP/2使用多路技术,允许多个消息在一个连接上同时交差。
它增加了头压缩(header compression),因此即使非常小的请求,其请求和响应的header都只会占用很小比例的带宽
GET和POST的区别,何时使用POST?
GET:一般用于信息获取,使用URL传递参数,对所发送信息的数量也有限制,一般在2000个字符
POST:一般用于修改服务器上的资源,对所发送的信息没有限制。
GET方式需要使用Request.QueryString来取得变量的值,而POST方式通过Request.Form来获取变量的值,也就是说Get是通过地址栏来传值,而Post是通过提交表单来传值。
-
然而,在以下情况中,请使用 POST 请求:
无法使用缓存文件(更新服务器上的文件或数据库)
向服务器发送大量数据(POST 没有数据量限制)
发送包含未知字符的用户输入时,POST 比 GET 更稳定也更可靠
说说网络分层里七层模型是哪七层
应用层:应用层、表示层、会话层(从上往下)(HTTP、FTP、SMTP、DNS)
传输层(TCP和UDP)
网络层(IP)
物理和数据链路层(以太网)
-
每一层的作用如下:
物理层:通过媒介传输比特,确定机械及电气规范(比特Bit) 数据链路层:将比特组装成帧和点到点的传递(帧Frame)
网络层:负责数据包从源到宿的传递和网际互连(包PackeT)
传输层:提供端到端的可靠报文传递和错误恢复(段Segment)
会话层:建立、管理和终止会话(会话协议数据单元SPDU)
表示层:对数据进行翻译、加密和压缩(表示协议数据单元PPDU)
应用层:允许访问OSI环境的手段(应用协议数据单元APDU)
讲讲304缓存的原理
服务器首先产生ETag,服务器可在稍后使用它来判断页面是否已经被修改。本质上,客户端通过将该记号传回服务器要求服务器验证其(客户端)缓存
304是HTTP状态码,服务器用来标识这个文件没修改,不返回内容,浏览器在接收到个状态码后,会使用浏览器已缓存的文件
客户端请求一个页面(A)。 服务器返回页面A,并在给A加上一个ETag。 客户端展现该页面,并将页面连同ETag一起缓存。 客户再次请求页面A,并将上次请求时服务器返回的ETag一起传递给服务器。 服务器检查该ETag,并判断出该页面自上次客户端请求之后还未被修改,直接返回响应304(未修改——Not Modified)和一个空的响应体
HTTP/2 与 HTTP/1.x 的关键区别
二进制协议代替文本协议,更加简洁高效
针对每个域只使用一个多路复用的连接
压缩头部信息减小开销
允许服务器主动推送应答到客户端的缓存中
一个页面从输入 URL 到页面加载显示完成,这个过程中都发生了什么?
01.浏览器查找域名对应的IP地址(DNS 查询:浏览器缓存->系统缓存->路由器缓存->ISP DNS 缓存->根域名服务器)
02.浏览器向 Web 服务器发送一个 HTTP 请求(TCP三次握手)
03.服务器 301 重定向(从 http://example.com 重定向到 http://www.example.com)
04.浏览器跟踪重定向地址,请求另一个带 www 的网址
05.服务器处理请求(通过路由读取资源)
06.服务器返回一个 HTTP 响应(报头中把 Content-type 设置为 'text/html')
07.浏览器进 DOM 树构建
08.浏览器发送请求获取嵌在 HTML 中的资源(如图片、音频、视频、CSS、JS等)
09.浏览器显示完成页面
10.浏览器发送异步请求
http默认端口为80,https默认端口443
不同层的协议
在网络层有IP协议、ICMP协议、ARP协议、RARP协议和BOOTP协议。在传输层中有TCP协议与UDP协议。在应用层有FTP、HTTP、TELNET、SMTP、DNS等协议。
HTTP缓存
HTTP缓存分为强制缓存和协商缓存。
强制缓存相关头部参数为Cache-Control和Expires,Cache-Control优先级高于Expires。
Expires返回的内容为绝对时间,格式形如:Wed, 05 Aug 2020 09:51:58 GMT,存在客户端时间与服务端时间不同步问题。
Cache-Control有五个取值:
- public:所有内容都将被缓存(客户端和代理服务器都可缓存)
- private:所有内容只有客户端可以缓存,Cache-Control的默认取值
- no-cache:客户端缓存内容,但是是否使用缓存则需要经过协商缓存来验证决定
- no-store:所有内容都不会被缓存,即不使用强制缓存,也不使用协商缓存
- max-age=xxx (xxx is numeric):缓存内容将在xxx秒后失效
当Cache-Control被设置为max-age=×××时,会优先使用max-age的值加上当前时间作为缓存过期时间。
浏览器发送请求,会首先检查是否有缓存,若没有,则直接向服务端发送请求,得到资源;
若有则检查缓存是否过期,若没有过期,则直接读取缓存返回客户端;
缓存存储位置:对于js和图片等动态资源存储在memory-cache内存缓存中,对于css等静态文件,存储在disk-cache硬盘缓存中,硬盘缓存需要I/O文件读取,比内存缓存慢
若缓存过期则进入协商缓存阶段;
与协商缓存相关的有两个参数,Etag / If-None-Match和Last-Modified / If-Modified-Since,其中Last-Modified / If-Modified-Since只能精确到秒级别,Etag / If-None-Match的优先级比Last-Modified / If-Modified-Since高;
其中Etag是服务端生成的文件资源唯一标识,Last-Modified为上次修改时间;
判断Etag是否发生变化,未发生变化说明文件未修改,返回304,客户端读取缓存,发生变化返回200,则服务端重新返回资源并进行缓存;
将请求头中的Last-Modified(上次请求服务端返回的值)与服务端资源最后修改时间进行对比,若最后修改时间大于Last-Modified,则说明资源在上次请求后发生了变化,返回200,服务端重新返回资源并缓存,否则返回304,客户端直接读取缓存。
https如何实现安全通信,为什么慢,如何解决慢
非对称加密(公开加密):一对公钥私钥,公钥加密的内容只有私钥可以解密,而私钥加密的内容可以使用公钥解密。
对称加密(共享加密):加密和解密使用同一个秘钥。
公开加密可以实现通信安全,比如服务端将公钥发给客户端,客户端通过公钥对内容加密,然后再向服务端发送加密后的内容,服务端接收后再利用私钥解密。由于只有服务端才有私钥,且公钥加密的内容只有私钥才能解密,因此只有服务端才能获取到真正内容,实现安全传输。
但是,使用公开加密处理起来会比共享加密要复杂很多,因此仅使用公开加密的话,会导致通信效率很低,因此我们可以使用混合加密:
利用公开加密能够达到的安全通信,传输共享加密需要的秘钥,然后双方使用共享加密进行通信。由于公开加密的安全性,因此可以保证只有客户端和服务端得到共享加密需要的秘钥,因而后续通信就可以使用共享加密,提升通信效率。
服务端身份认证:服务端人工向第三方机构申请CA证书,CA机构开出证书,证书包括内容和CA机构签名两部分。
证书内容:机构名称,证书用途,申请者公开密钥,到期时间等等。
CA机构签名:通过机构自身的HASH算法对证书内容进行求值,得到一个HASH值,将该HASH算法和HASH值利用机构自身秘钥进行加密,得到签名。
认证过程:
客户端内置了各个知名CA机构的CA证书,当接收到服务端发过来的证书时,通过机构名称在本地找到该CA机构的CA证书;
然后利用其公钥对服务端发过来的证书的证书签名进行解密,如果确实是该机构颁发的证书,则该公钥能够成功解密其签名;
解密签名完成后得到该机构的HASH算法及证书内容的HASH值,接下来去验证证书内容是否被修改;
利用解密得到的HASH算法对证书内容求值,如果得到的值和解密得到的HASH值相同,则说明内容未被修改;
证明了证书确实由该CA机构颁发,又证明了内容未被修改,则证明该证书确实是由正确服务端发送的,验证了服务端。
完整性保护
SSL建立开始时,客户端会向服务端发送一些信息,包括支持的SSL版本,加密组件列表,以及一个随机数A。
服务端收到后,对客户端进行应答,应答内容包含SSL版本以及加密组件,加密组件内容是从客户端加密组件中筛选出来的,同时也会返回一个随机数B。
服务端给客户端发送自己的CA证书,客户端验证成功后,取出公钥,对随机生成的Pre-master secrete进行加密,传递给服务端。
服务端利用配对私钥解密,得到Pre-master secret。
客户端和服务端利用开始筛选出来的加密组件(包括加密算法及密钥长度等)和Pre-master secret,随机数A,随机数B计算出一个master secret,然后利用这个master secret推导出一个session secret和一个hash secret。
session secret即共享密钥。
双方通过hash secret对报文求值,得到一个MAC值,将这个值附到报文后面,然后利用session secret对整个报文进行加密。
接收到报文的一方先利用session secret对报文进行解密,然后利用相同的hash secret对报文内容进行哈希求值得到自己的MAC',与接收到的MAC值进行对比,如果相同说明报文未被修改过,保证报文的完整性。
HTTP 1.0 1.1 2.0各版本区别
1.0与1.1区别:
- 1.1支持长连接,1.0版本每一个请求需要新建一个tcp连接(三次握手,四次挥手),影响性能。1.1默认长连接,通过设置头部Connection关键字为Keep-Alive或Close打开或关闭长连接。
- 1.1支持请求部分文件,通过指定请求范围,只返回请求的部分资源,这是文件断点续传的基础。1.0每次请求都返回整个资源,不能请求部分。可以通过设置头部Range关键字,指定从哪里开始返回资源,此时成功状态码为206(成功返回请求的部分资源)。
- 1.1支持Head请求,只发送header信息来判断请求是否合法,若不合法则无需发送body信息,节约带宽。
- 1.1新增缓存关键字,ETag和Cache-Control,Cache-Control使得强缓存存在时间可以设置为相对时间(相对客户端),解决了客户端与服务端时间不同步的问题。ETag使得每次返回一个文件标识,通过对比该标识可以直接判断文件是否更新,改善了Last-Modified只能精确到秒级,重复相同更改操作,而文件内容并未发生变化不需要再重新请求。
2.0和1.X区别:
- 2.0支持多路复用,同一个域名请求只建立一个连接,一个连接内可以并发多个请求。
1.1长连接也可以发送多个请求,但是它是串行的,虽然客户端可以并行发送请求,但服务端为了确定这些请求的顺序,只能按顺序去处理返回。虽然也可以通过建立多个tcp连接实现服务端并行处理,但是建立tcp连接需要时间,而且各浏览器对同一域名tcp连接个数是有限制的。
2.0通过添加一个二进制分帧层,将所有信息拆分为独立的互不干扰的帧并进行顺序标识,这样服务端也可以不用管顺序去并行处理,处理完后按照标识返回即可。 - 2.0通过HPACK算法压缩头部
- 2.0新增服务端推送,比如要请求example.css和example.js两个文件,1.X通过两次http请求分别得到两个文件,而2.0在请求example.css文件时,服务端判断出后续可能也需要example.js问价,就会自动将example.js文件推送给客户端,客户端保存到“本地”,等客户端需要该文件时,直接从“本地”读取即可,不需要再向服务端请求,效率提高很多。
- 可以通过对请求设置优先级(31bit)来优先响应重要的请求。