「观感度:🌟🌟🌟🌟🌟」
前端
「口味:剁椒鱼头」
git
「烹饪时间:20min」
github
本文已收录在Github
github.com/Geekhyt,感谢Star。web
从淡黄的长裙和蓬松的头发我察觉到,面前坐着的这位女面试官属实是有点东西。个人自我介绍也变得声情并茂起来。Skr~~~ 在此期间,小姐姐面无改色的看着个人简历。不过无所谓,这些都不重要。面试
仍是我们的原定计划,把面试官引到了我们最擅长的领域。算法
你以为本身最擅长的是什么?浏览器
HTTP 协议吧,我还算比较了解。缓存
应用层、表示层、会话层、传输层、网络层、数据链路层、物理层安全
application layer、presentation layer、session layer、transport layer、network layer、data link layer、physical layer
服务器
应用层、传输层、网际层、连接层
application layer、transport layer、internet layer、link layer
TCP 和 UDP 都是传输层的协议,但两者有着大相径庭的基因。
TCP:
UDP:
1.客户端主动发起 SYN
2.服务端收到并返回 SYN 以及 ACK 客户端的 SYN
3.客户端收到服务端的 SYN 和 ACK 后,发送 ACK 的 ACK 给服务端,服务端收到后链接创建
Client -> SYN -> Server
Server -> SYN/ACK -> Client
Client -> ACK -> Server
1.客户端发送 FIN 给服务端
2.服务端收到后发送 ACK 给客户端
3.服务端发送 FIN 给客户端
4.客户端收到后,发送 ACK 的 ACK 给服务端,服务端关闭,客户端等待 2MSL 后关闭
Client -> FIN -> Server
Server -> ACK -> Client
Server -> FIN -> Client
Client -> ACK -> Server -> CLOSED
Client -> 2MSL 的时间 -> CLOSED
(小白回答版)
HTTP 就是超文本传输协议
呀,它的英文是 HyperText Transfer Protocol。
敲黑板!
(罗剑锋老师的完美回答版)
HTTP 是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范。
(面试官:理解的不错)
(幂等)
(幂等)
(带条件时幂等)
(幂等)
(幂等)
(有安全风险)
HTTPS 就是在 HTTP 和 TCP 协议中间加入了 SSL/TLS 安全套接层。
结合非对称加密和对称加密的各自优势,配合证书。既保证了安全性,也保证了传输效率。
目前应用最普遍的是TLS1.2
,实现原理以下:
random1+对称加密套件列表+非对称加密套件列表
对称加密套件+非对称加密套件 并和 random2+证书(公钥在证书中)
一块儿返回
random1+random2 生成 pre-master 经过服务器公钥加密+浏览器确认
发送给 Server
pre-master
,根据约定的加密算法对
random1+random2+pre-master(解密)生成 master-secret
,而后发送服务器确认
master-secert
,对称加密秘钥传输完毕
TLS1.3
则简化了握手过程,彻底握手只须要一个消息往返,提高了性能。不只如此,还对部分不安全的加密算法进行了删减。
ECDHE 算法利用了椭圆曲线和离散对数
等思想,按照当下的计算机算力,很难在短期进行破解。且每次握手时生成的都是一对临时的公钥和私钥,这样就保证每次的密钥对也不一样。
即便大费力气破解了一次的密钥,以前的历史消息也不会受到影响,保证了前向安全。
固然,TLS 协议的安全性受限于当下最快的计算机运行速度,理论上绝对安全的是量子通信传递密钥
。
(面试官:小伙子有点东西)
(基操,勿6)
DNS (Domain Name System)
是互联网中的重要基础设施,负责对域名的解析工做,为了保证高可用、高并发和分布式,它设计成了树状的层次结构。
由根DNS服务器、顶级域 DNS 服务器和权威 DNS 服务器组成。
解析顺序是首先从浏览器缓存
、操做系统缓存
以及本地 DNS 缓存 (/etc/hosts)
逐级查找,而后从本地 DNS 服务器
、根 DNS
、顶级 DNS
以及权威 DNS
层层递归查询。
还能够基于域名在内网、外网进行负载均衡。
不过传统的 DNS 有不少问题(解析慢、更新不及时),HTTPDNS
经过客户端 SDK 和服务端配合,直接经过 HTTP 调用解析 DNS 的方式,能够绕过传统 DNS 这些缺点,实现智能调度。
(面试官:小伙子理解的挺细啊)
CDN(Content Delivery Network)
就是内容分发网络。
为了突破现实生活中的光速、传输距离等物理限制,CDN 投入了大量资金,在全球范围内各大枢纽城市创建机房,部署大量高存储高带宽的节点,构建跨运营商、跨地域的专用高速传输网络。
其中分为中心节点、区域节点、边缘节点等,在用户接入网络后,首先经过全局负载均衡 (Global Sever Load Balance)
,简称 GSLB 算法负责调度,找到离用户最合适的节点。而后经过 HTTP 缓存代理技术进行缓存,缓存命中就返回给用户,不然就回源站去取。CDN 擅长缓存静态资源(图片、音频等),固然也支持动态内容的缓存。
WebSocket
是一种基于 TCP 的轻量级网络通讯协议。和 HTTP/2 同样,都是为了解决 HTTP 某些方面的缺陷而诞生的。不过解决方式略有不一样,HTTP/2 针对的是“队头阻塞 ”,WebSocket 针对的是“请求-应答”的通讯模式。
咱们知道“请求-应答”是半双工的通讯模式,不具有服务器推送能力。这就限制了 HTTP 在实时通讯领域的发展。虽然可使用轮询来不停的向服务器发送 HTTP 请求,可是缺点也很大,反复的无效请求占用了大量的带宽和 CPU 资源。因此,WebSocket 应运而生。
WebSocket 是一个全双工通讯协议,具有服务端主动推送的能力。本质上是对 TCP 作了一层包装,让它能够运行在浏览器环境里。
看过我这篇专栏的同窗们必定知道,Webpack 的热更新中就利用了这种协议。固然,在即时通信、游戏以及可视化大屏展现等领域中也都有着 WebSocket 的身影。
(关于 WebSocket 的过多细节这里再也不展开,后续有机会在专栏中详细介绍,感兴趣的同窗们能够先自行学习)
服务器使用 Cache-Control
来设置缓存策略,经常使用 max-age
来表示资源的有效期。
(这里的 max-age 的时间计算起点是响应报文的建立时刻,而不是客户端收到报文的时刻。)
(浏览器也能够发送 Cache-Control 字段,使用 max-age=0 或 no-cache 来刷新数据)
若是想更精确的控制缓存策略,还可使用 Cache-Control 的其余属性:
验证资源是否失效就须要使用条件请求
。经常使用的是 If-Modified-Since
和 If-None-Match
,收到 304
状态码就能够复用缓存里的资源。
(If-None-Match 比 If-Modified-Since 优先级更高)
验证资源是否被修改的条件有两个 Last-modified
和 ETag
(ETag 比 Last-modified 的精确度更高),须要预先在服务端的响应报文里设置,配合条件请求使用。
内容协商就是每一个 URI 指向的资源能够是任何事物,能够有不少不一样的表述。对于文档来讲,能够有不一样的语言、不一样的媒体格式,并针对不一样的浏览器提供不一样的压缩编码。
重定向是服务器发起的跳转,要求客户端使用新的 URI 从新发送请求。在响应头字段 Location
中指示了要跳转的 URI。使用 Refresh
字段,还能够实现延时重定向。
301 / 302
是经常使用的重定向状态码。分别表明永久性重定向
和临时性重定向
。
除此以外还有:
GET
方法
(上文中提到过一些,这里只列举一些经常使用的)
(开始报菜名)
Cache-Control
控制缓存
Connection
链接管理
Transfor-Encoding
报文主体的传输编码格式
Date
建立报文的时间
Upgrade
升级为其余协议
Host
请求资源所在的服务器 (惟一一个HTTP/1.1规范里要求必须出现的字段)
Accept
客户端或者代理可以处理的媒体类型
If-Match
比较实体标记 (ETag)
If-None-Match
比较实体标记 (ETag),与 If-Match 相反
If-Modified-Since
比较资源更新时间 (Last-Modified)
If-Unmodified-Since
比较资源更新时间 (Last-Modified), 与 If-Modified-Since 相反
Range
实体的字节范围请求
User-Agent
客户端信息
Accept-Ranges
能接受的字节范围
Location
命令客户端重定向的 URI
ETag
可以表示资源惟一资源的字符串
Server
服务器的信息
Allow
资源可支持 HTTP 请求方法
Last-Modified
资源最后修改时间
Expires
实体主体过时时间
Content-Language
实体资源语言
Content-Encoding
实体编码格式
Content-Length
实体大小
Content-Type
实体媒体类型
(上文中提到过一些,这里只列举一些经常使用的)
(开始报菜名)
1xx:请求已经接收到,须要进一步处理才能完成,HTTP/1.0 不支持
100 Continue
:上传大文件前使用
101 Switch Protocols
:协议升级使用
102 Processing
:服务器已经收到并正在处理请求,但无响应可用
2xx:成功处理请求
200 OK
:成功返回响应
201 Created
:有新资源在服务器端被成功建立
202 Accepted
:服务器接受并开始处理请求,但请求未处理完成
206 Partial Content
:使用range协议时返回部分响应内容时的响应码
请查阅上文重定向部分,这里再也不赘述。
4xx:客户端出现错误
400 Bad Request
:服务器认为客户端出现了错误,但不明确,通常是 HTTP 请求格式错误
401 Unauthorized
:用户认证信息确实或者不正确
403 Forbidden
:服务器理解请求的含义,但没有权限执行
407 Proxy Authentication Required
:对须要经由代理的请求,认证信息未经过代理服务器的验证
404 Not Found
:服务器没有找到对应的资源
408 Request Timeout
:服务器接收请求超时
5xx:服务器端出现错误
500 Internal Server Error
:服务器内部错误,且不属于如下错误类型
502 Bad Gateway
:代理服务器没法获取到合法响应
503 Service Unavailable
:服务器资源还没有准备好处理当前请求
505 HTTP Version Not Supported
:请求使用的 HTTP 协议版本不支持
小姐姐拿起桌旁已经凉透的芋泥波波奶茶,喝了一口。
(精神小伙啊)
1.看到这里了就点个赞支持下吧,你的「赞」是我创做的动力。
2.关注公众号前端食堂,「你的前端食堂,记得按时吃饭」!
3.本文已收录在前端食堂Github github.com/Geekhyt,求个小星星,感谢Star。