附一份干货!一份700多页的后端面试笔记,涵盖了后端开发常考知识点。
链接:https://pan.baidu.com/s/1dsDm...
提取码:0das
计算机网络面试题第二期来了,话不多说,先珍藏再看吧~
看下本期的目录:
1. HTTP常见的状态码有哪些?
常见状态码:
- 200:服务器已胜利解决了申请。 通常,这示意服务器提供了申请的网页。
- 301 : (永恒挪动) 申请的网页已永恒挪动到新地位。 服务器返回此响应(对 GET 或 HEAD 申请的响应)时,会主动将请求者转到新地位。
- 302:(长期挪动) 服务器目前从不同地位的网页响应申请,但请求者应持续应用原有地位来进行当前的申请。
- 400 :客户端申请有语法错误,不能被服务器所了解。
- 403 :服务器收到申请,然而回绝提供服务。
- 404 :(未找到) 服务器找不到申请的网页。
- 500: (服务器外部谬误) 服务器遇到谬误,无奈实现申请。
状态码结尾代表类型:
2. 状态码301和302的区别是什么?
共同点:301和302状态码都示意重定向,就是说浏览器在拿到服务器返回的这个状态码后会主动跳转到一个新的URL地址,这个地址能够从响应的Location首部中获取(用户看到的成果就是他输出的地址A霎时变成了另一个地址B)。
不同点:301示意旧地址A的资源曾经被永恒地移除了(这个资源不可拜访了),搜索引擎在抓取新内容的同时也将旧的网址替换为重定向之后的网址;302示意旧地址A的资源还在(依然能够拜访),这个重定向只是长期地从旧地址A跳转到地址B,搜索引擎会抓取新的内容而保留旧的网址。 SEO中302好于301。
补充,重定向起因:
- 网站调整(如扭转网页目录构造);
- 网页被移到一个新地址;
- 网页扩展名扭转(如利用须要把.php改成.Html或.shtml)。
3. HTTP 罕用的申请形式?
办法 | 作用 |
---|---|
GET | 获取资源 |
POST | 传输实体主体 |
PUT | 上传文件 |
DELETE | 删除文件 |
HEAD | 和GET办法相似,但只返回报文首部,不返回报文实体主体局部 |
PATCH | 对资源进行局部批改 |
OPTIONS | 查问指定的URL反对的办法 |
CONNECT | 要求用隧道协定连贯代理 |
TRACE | 服务器会将通信门路返回给客户端 |
为了不便记忆,能够将PUT、DELETE、POST、GET了解为客户端对服务端的增删改查。
- PUT:上传文件,向服务器增加数据,能够看作增
- DELETE:删除文件
- POST:传输数据,向服务器提交数据,对服务器数据进行更新。
- GET:获取资源,查问服务器资源
4. GET申请和POST申请的区别?
应用上的区别:
- GET应用URL或Cookie传参,而POST将数据放在BODY中”,这个是因为HTTP协定用法的约定。
- GET形式提交的数据有长度限度,则POST的数据则能够十分大”,这个是因为它们应用的操作系统和浏览器设置的不同引起的区别。
- POST比GET平安,因为数据在地址栏上不可见”,这个说法没故障,但仍然不是GET和POST自身的区别。
本质区别
GET和POST最大的区别次要是GET申请是幂等性的,POST申请不是。这个是它们本质区别。
幂等性是指一次和屡次申请某一个资源应该具备同样的副作用。简略来说意味着对同一URL的多个申请应该返回同样的后果。
5. 解释一下HTTP长连贯和短连贯?
在HTTP/1.0中,默认应用的是短连贯。也就是说,浏览器和服务器每进行一次HTTP操作,就建设一次连贯,但工作完结就中断连贯。如果客户端浏览器拜访的某个HTML或其余类型的 Web页中蕴含有其余的Web资源,如JavaScript文件、图像文件、CSS文件等;当浏览器每遇到这样一个Web资源,就会建设一个HTTP会话。
但从 HTTP/1.1起,默认应用长连贯,用以放弃连贯个性。应用长连贯的HTTP协定,会在响应头有退出这行代码:Connection:keep-alive
在应用长连贯的状况下,当一个网页关上实现后,客户端和服务器之间用于传输HTTP数据的 TCP连贯不会敞开,如果客户端再次拜访这个服务器上的网页,会持续应用这一条曾经建设的连贯。Keep-Alive不会永恒放弃连贯,它有一个放弃工夫,能够在不同的服务器软件(如Apache)中设定这个工夫。实现长连贯要客户端和服务端都反对长连贯。
HTTP协定的长连贯和短连贯,本质上是TCP协定的长连贯和短连贯。
6. HTTP申请报文和响应报文的格局?
申请报文格式:
- 申请行(申请办法+URI协定+版本)
- 申请头部
- 空行
- 申请主体
GET/sample.jspHTTP/1.1 申请行Accept:image/gif.image/jpeg, 申请头部Accept-Language:zh-cnConnection:Keep-AliveHost:localhostUser-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)Accept-Encoding:gzip,deflateusername=jinqiao&password=1234 申请主体
响应报文:
- 状态行(版本+状态码+起因短语)
- 响应首部
- 空行
- 响应主体
HTTP/1.1 200 OKServer:Apache Tomcat/5.0.12Date:Mon,6Oct2003 13:23:42 GMTContent-Length:112<html> <head> <title>HTTP响应示例<title> </head> <body> Hello HTTP! </body></html>
7. HTTP1.0和HTTP1.1的区别?
- 长连贯:HTTP 1.1反对长连贯(Persistent Connection)和申请的流水线(Pipelining)解决,在一个TCP连贯上能够传送多个HTTP申请和响应,缩小了建设和敞开连贯的耗费和提早,在HTTP1.1中默认开启
Connection: keep-alive
,肯定水平上补救了HTTP1.0每次申请都要创立连贯的毛病。 - 缓存解决:在HTTP1.0中次要应用header里的If-Modified-Since,Expires来做为缓存判断的规范,HTTP1.1则引入了更多的缓存控制策略,可供选择的缓存头来管制缓存策略。
- 带宽优化及网络连接的应用:HTTP1.0中,存在一些节约带宽的景象,例如客户端只是须要某个对象的一部分,而服务器却将整个对象送过来了,并且不反对断点续传性能,HTTP1.1则在申请头引入了range头域,它容许只申请资源的某个局部,即返回码是206(Partial Content),这样就不便了开发者自在的抉择以便于充分利用带宽和连贯。
- 谬误告诉的治理:在HTTP1.1中新增了24个谬误状态响应码,如409(Conflict)示意申请的资源与资源的以后状态发生冲突;410(Gone)示意服务器上的某个资源被永久性的删除。
- Host头解决:在HTTP1.0中认为每台服务器都绑定一个惟一的IP地址,因而,申请音讯中的URL并没有传递主机名(hostname)。但随着虚拟主机技术的倒退,在一台物理服务器上能够存在多个虚拟主机(Multi-homed Web Servers),并且它们共享一个IP地址。HTTP1.1的申请音讯和响应音讯都应反对Host头域,且申请音讯中如果没有Host头域会报告一个谬误(400 Bad Request)。
8. HTTP1.1和 HTTP2.0的区别?
HTTP2.0相比HTTP1.1反对的个性:
- 新的二进制格局:HTTP1.1的解析是基于文本。基于文本协定的格局解析存在人造缺点,文本的表现形式有多样性,要做到健壮性思考的场景必然很多,二进制则不同,只认0和1的组合。基于这种思考HTTP2.0的协定解析决定采纳二进制格局,实现不便且强壮。
- 多路复用,即连贯共享,即每一个request都是用作连贯共享机制的。一个request对应一个id,这样一个连贯上能够有多个request,每个连贯的request能够随机的混淆在一起,接管方能够依据request的 id将request再归属到各自不同的服务端申请外面。
- 头部压缩,HTTP1.1的头部(header)带有大量信息,而且每次都要反复发送;HTTP2.0应用encoder来缩小须要传输的header大小,通信单方各自cache一份header fields表,既防止了反复header的传输,又减小了须要传输的大小。
- 服务端推送:服务器除了对最后申请的响应外,服务器还能够额定的向客户端推送资源,而无需客户端明确的申请。
9. HTTP 与 HTTPS 的区别?
HTTP | HTTPS | |
---|---|---|
端口 | 80 | 443 |
安全性 | 无加密,安全性较差 | 有加密机制,安全性较高 |
资源耗费 | 较少 | 因为加密解决,资源耗费更多 |
是否须要证书 | 不须要 | 须要 |
协定 | 运行在TCP协定之上 | 运行在SSL协定之上,SSL运行在TCP协定之上 |
10. HTTPS 的优缺点?
长处:
安全性:
- 应用HTTPS协定可认证用户和服务器,确保数据发送到正确的客户机和服务器;
- HTTPS协定是由SSL+HTTP协定构建的可进行加密传输、身份认证的网络协议,要比http协定平安,可避免数据在传输过程中不被窃取、扭转,确保数据的完整性。
- HTTPS是现行架构下最平安的解决方案,尽管不是相对平安,但它大幅减少了中间人攻打的老本。
- SEO方面:谷歌曾在2014年8月份调整搜索引擎算法,并称“比起等同HTTP网站,采纳HTTPS加密的网站在搜寻后果中的排名将会更高”。
毛病:
- 在雷同网络环境中,HTTPS 相比 HTTP 无论是响应工夫还是耗电量都有大幅度回升。
- HTTPS 的平安是有范畴的,在黑客攻击、服务器劫持等状况下简直起不到作用。
- 在现有的证书机制下,中间人攻打仍然有可能产生。
- HTTPS 须要更多的服务器资源,也会导致老本的升高。
11. 讲一讲HTTPS 的原理?
图片起源:https://segmentfault.com/a/11...
加密流程按图中的序号分为:
- 客户端申请 HTTPS 网址,而后连贯到 server 的 443 端口 (HTTPS 默认端口,相似于 HTTP 的80端口)。
- 采纳 HTTPS 协定的服务器必须要有一套数字 CA (Certification Authority)证书。颁发证书的同时会产生一个私钥和公钥。私钥由服务端本人保留,不可透露。公钥则是附带在证书的信息中,能够公开的。证书自身也附带一个证书电子签名,这个签名用来验证证书的完整性和真实性,能够避免证书被篡改。
- 服务器响应客户端申请,将证书传递给客户端,证书蕴含公钥和大量其余信息,比方证书颁发机构信息,公司信息和证书有效期等。
客户端解析证书并对其进行验证。如果证书不是可信机构颁布,或者证书中的域名与理论域名不统一,或者证书曾经过期,就会向访问者显示一个正告,由其抉择是否还要持续通信。
如果证书没有问题,客户端就会从服务器证书中取出服务器的公钥A。而后客户端还会生成一个随机码 KEY,并应用公钥A将其加密。
- 客户端把加密后的随机码 KEY 发送给服务器,作为前面对称加密的密钥。
- 服务器在收到随机码 KEY 之后会应用私钥B将其解密。通过以上这些步骤,客户端和服务器终于建设了平安连贯,完满解决了对称加密的密钥泄露问题,接下来就能够用对称加密欢快地进行通信了。
- 服务器应用密钥 (随机码 KEY)对数据进行对称加密并发送给客户端,客户端应用雷同的密钥 (随机码 KEY)解密数据。
- 单方应用对称加密欢快地传输所有数据。
12. 在浏览器中输出www.baidu.com后执行的全副过程?
域名解析(域名 www.baidu.com 变为 ip 地址)。
浏览器搜寻本人的DNS缓存(保护一张域名与IP的对应表);若没有,则搜寻操作系统的DNS缓存(保护一张域名与IP的对应表);若没有,则搜寻操作系统的hosts文件(保护一张域名与IP的对应表)。
若都没有,则找 tcp/ip 参数中设置的首选 dns 服务器,即本地 dns 服务器(递归查问),本地域名服务器查问本人的dns缓存,如果没有,则进行迭代查问。将本地dns服务器将IP返回给操作系统,同时缓存IP。
- 发动 tcp 的三次握手,建设 tcp 连贯。浏览器会以一个随机端口(1024-65535)向服务端的 web 程序 80 端口发动 tcp 的连贯。
- 建设 tcp 连贯后发动 http 申请。
- 服务器响应 http 申请,客户端失去 html 代码。服务器 web 应用程序收到 http 申请后,就开始解决申请,解决之后就返回给浏览器 html 文件。
- 浏览器解析 html 代码,并申请 html 中的资源。
- 浏览器对页面进行渲染,并出现给用户。
附一张形象的图片:
13. 什么是 Cookie 和 Session ?
什么是 Cookie
HTTP Cookie(也叫 Web Cookie或浏览器 Cookie)是服务器发送到用户浏览器并保留在本地的一小块数据,它会在浏览器下次向同一服务器再发动申请时被携带并发送到服务器上。通常,它用于告知服务端两个申请是否来自同一浏览器,如放弃用户的登录状态。Cookie 使基于无状态的 HTTP 协定记录稳固的状态信息成为了可能。
Cookie 次要用于以下三个方面:
- 会话状态治理(如用户登录状态、购物车、游戏分数或其它须要记录的信息)
- 个性化设置(如用户自定义设置、主题等)
- 浏览器行为跟踪(如跟踪剖析用户行为等)
什么是 Session
Session 代表着服务器和客户端一次会话的过程。Session 对象存储特定用户会话所需的属性及配置信息。这样,当用户在应用程序的 Web 页之间跳转时,存储在 Session 对象中的变量将不会失落,而是在整个用户会话中始终存在上来。当客户端敞开会话,或者 Session 超时生效时会话完结。
14. Cookie 和 Session 是如何配合的呢?
用户第一次申请服务器的时候,服务器依据用户提交的相干信息,创立对应的 Session ,申请返回时将此 Session 的惟一标识信息 SessionID 返回给浏览器,浏览器接管到服务器返回的 SessionID 信息后,会将此信息存入到 Cookie 中,同时 Cookie 记录此 SessionID 属于哪个域名。
当用户第二次拜访服务器的时候,申请会主动判断此域名下是否存在 Cookie 信息,如果存在主动将 Cookie 信息也发送给服务端,服务端会从 Cookie 中获取 SessionID,再依据 SessionID 查找对应的 Session 信息,如果没有找到阐明用户没有登录或者登录生效,如果找到 Session 证实用户曾经登录可执行前面操作。
依据以上流程可知,SessionID 是连贯 Cookie 和 Session 的一道桥梁,大部分零碎也是依据此原理来验证用户登录状态。
15. Cookie和Session的区别?
- 作用范畴不同,Cookie 保留在客户端(浏览器),Session 保留在服务器端。
- 存取形式的不同,Cookie 只能保留 ASCII,Session 能够存任意数据类型,个别状况下咱们能够在 Session 中放弃一些罕用变量信息,比如说 UserId 等。
- 有效期不同,Cookie 可设置为长时间放弃,比方咱们常常应用的默认登录性能,Session 个别生效工夫较短,客户端敞开或者 Session 超时都会生效。
- 隐衷策略不同,Cookie 存储在客户端,比拟容易受到不法获取,晚期有人将用户的登录名和明码存储在 Cookie 中导致信息被窃取;Session 存储在服务端,安全性绝对 Cookie 要好一些。
- 存储大小不同, 单个 Cookie 保留的数据不能超过 4K,Session 可存储数据远高于 Cookie。
16. 如何思考分布式 Session 问题?
在互联网公司为了能够撑持更大的流量,后端往往须要多台服务器独特来撑持前端用户申请,那如果用户在 A 服务器登录了,第二次申请跑到服务 B 就会呈现登录生效问题。
分布式 Session 个别会有以下几种解决方案:
- 客户端存储:间接将信息存储在cookie中,cookie是存储在客户端上的一小段数据,客户端通过http协定和服务器进行cookie交互,通常用来存储一些不敏感信息
- Nginx ip_hash 策略:服务端应用 Nginx 代理,每个申请按拜访 IP 的 hash 调配,这样来自同一 IP 固定拜访一个后盾服务器,防止了在服务器 A 创立 Session,第二次散发到服务器 B 的景象。
- Session 复制:任何一个服务器上的 Session 产生扭转(增删改),该节点会把这个 Session 的所有内容序列化,而后播送给所有其它节点。
- 共享 Session:服务端无状态话,将用户的 Session 等信息应用缓存中间件(如Redis)来对立治理,保障散发到每一个服务器的响应后果都统一。
倡议采纳共享 Session的计划。
17. 什么是DDos攻打?
DDos全称Distributed Denial of Service,分布式拒绝服务攻打。最根本的DOS攻打过程如下:
- 客户端向服务端发送申请链接数据包。
- 服务端向客户端发送确认数据包。
- 客户端不向服务端发送确认数据包,服务器始终期待来自客户端的确认
DDoS则是采纳分布式的办法,通过在网络上霸占多台“肉鸡”,用多台计算机发动攻打。
DOS攻打当初根本没啥作用了,因为服务器的性能都很好,而且是多台服务器独特作用,1V1的模式黑客无奈占上风。对于DDOS攻打,预防办法有:
- 缩小SYN timeout工夫。在握手的第三步,服务器会期待30秒-120秒的工夫,缩小这个等待时间就能开释更多的资源。
- 限度同时关上的SYN半连贯数目。
18. 什么是XSS攻打?
XSS也称 cross-site scripting,跨站脚本。这种攻打是因为服务器将攻击者存储的数据原原本本地显示给其余用户所致的。比方一个存在XSS破绽的论坛,用户发帖时就能够引入带有<script>标签的代码,导致恶意代码的执行。
预防措施有:
- 前端:过滤。
- 后端:本义,比方go自带的处理器就具备本义性能。
19. SQL注入是什么,如何防止SQL注入?
SQL 注入就是在用户输出的字符串中退出 SQL 语句,如果在设计不良的程序中疏忽了查看,那么这些注入进去的 SQL 语句就会被数据库服务器误认为是失常的 SQL 语句而运行,攻击者就能够执行计划外的命令或拜访未被受权的数据。
SQL注入的原理次要有以下 4 点
- 歹意拼接查问
- 利用正文执行非法命令
- 传入非法参数
- 增加额定条件
防止SQL注入的一些办法:
- 限度数据库权限,给用户提供仅仅可能满足其工作的最低权限。
- 对进入数据库的特殊字符(’”\尖括号&*;等)本义解决。
- 提供参数化查问接口,不要间接应用原生SQL。
20. 负载平衡算法有哪些?
多台服务器以对称的形式组成一个服务器汇合,每台服务器都具备等价的位置,能相互分担负载。
- 轮询法:将申请依照程序轮流的调配到服务器上。大锅饭,不能施展某些高性能服务器的劣势。
- 随机法:随机获取一台,和轮询相似。
- 哈希法:通过ip地址哈希化来确定要抉择的服务器编号。益处是,每次客户端拜访的服务器都是同一个服务器,能很好地利用session或者cookie。
- 加权轮询:依据服务器性能不同加权。
End
更文不易,点赞激励下呗~我将继续输入干货,与你独特成长~
还有,秋招求职交换群继续凋谢,扫码加我,备注秋招,拉你进群。
伟人的肩膀
https://juejin.cn/post/684490...
https://www.justdojava.com/20...
https://juejin.cn/post/684490...
https://segmentfault.com/a/11...
https://jiangren.work/2020/02...
https://www.cnblogs.com/ityou...
https://juejin.cn/post/684490...
这里也举荐一个我收集的计算机书籍仓库,仓库目前有上百本经典cs电子书,看经典的书籍会更悟得深~
点此链接即可中转书单,计算机必看经典书籍(含pdf下载)
Github也有相应仓库,https://github.com/cosen1024/...
欢送star。