1 状态码
2xx 没问题
200 OK 正常处理并返回对应资源
204 No Content 请求收到了，但是没给响应内容，只给响应头，那么浏览器显示的页面不发生更新
206 Partial Content 返回一部分资源
3xx 进一步操作
301 Moved Permanently 永久性重定向 第一次访问就记录在浏览器缓存中
302 Found：临时性重定向 每次重定向都要发送请求接收响应
304 Not Modified 缓存 用于返回是否更新数据，未更新就从缓存中获取
4xx 客户端出错
400 Bad Request：该状态码表示***请求报文中**存在语法错误
403 Forbidden：该状态码表明对请求资源的访问被服务器拒绝了 权限错误
404 Not Found：一般是网址URL错误，服务器找不到地址
414 请求的URL 太长
5xx 服务器出错
500 Internal Server Error：表明服务器端在执行请求时发生了错误
503 Service Unavailable：表明服务器**暂时处于超负载**或**正在进行停机维护**，现在无法处理请求
2 HTTP 缓存
Expire 过期时间 GMT 日期格式
在某个时间点过期
用户本地时间更改后，这个Expire就失效了
Cache-Control：max-age：600
延迟600s过期
特点：延迟时间内无请求
Etag 一般存放MD5散列函数处理的数据
- MD5处理文件，得到一个MD5值
- 只要文件更改，这个MD5值就必定改变
- 每次请求与响应只需比对这个MD5值就可控制是否需要更新
- 不需要更新就返回状态码304 告诉浏览器从浏览器自己的缓存中获取
特点：每次都需请求
Last-Modified
和md5方法较为类似，通过记录文件的最后依次修改时间来判定是否需要更新文件
拓展：PWA技术
4 GET和POST的区别
可回答的答案，先说：表层次的区别
- post 比get 安全 get参数直接暴露在URL上，所以不能用来传递敏感信息
- 一般 GET 放在URL 里 有长度限制，POST放在请求体中，没有长度限制
- 从发送的报文格式来说，Get 请求的报文中实体部分为空，Post 请求的报文中实体部分一般为向服务器发送的数据。
- GET幂等的，post不幂等的，发送多次GET不会改变数据库里的内容，如果发送POST会改变数据库
标准的答案，其实post和get没有本质区别，都是HTTP的请求方式，有区别的是人为规定用法
- 语义化区别，get是获取数据，post是提交数据，不能随便混用
5 Cookie / LocalStorage /SessionStorage /Session
Cookie 与session的区别
- cookie是服务器发给浏览器的一段内容，浏览器每次访问对应域名（服务器）的时候需要带上这个cookie
- session是会话，表示一次浏览器与服务器之间一段时间的会话
- session是在服务器上，cookie在浏览器上，session一般是基于cookie来实现的，把sessionID放入cookie里
Cookie与LocalStorage的区别
- cookie大小限制比较小（4k）localstorage限制大小较大（5MB）
- cookie是来存储用户信息，localstorage存储不重要的数据
- cookie是会被发送到浏览器中（相当于通行证）另一个不发送
LocalStorage与SessionStorage
localstorage不会过期，sessionstorage会在session结束的时候过期
6 HTTP2 和 HTTP1的区别是什么
HTTP 1.1
优点
- 复用链接（持久连接），一次连接，有多个请求响应（keep-alive）
- 管线化，并行处理，一个请求之后可以不等待响应，继续下一个请求
- 格外的缓存机制，状态码，提交方法以及内容协商机制等
缺点
- 请求头复杂冗余且重复，浪费资源和性能
- 数据未强制压缩
- 只能客户端发送请求，不能服务端主动发起，比如聊天时，客户端需要不断发送请求
- 请求没有优先级，无法首先加载重要资源
- 每个域名下的请求并行数量有限制
HTTP 2.0
HTTP 2.0 其实是SPDY演化而来的
改进了
- 采用二进制格式传输，取代了 HTTP1 的文本格式，二进制格式解析更高效
- 多路复用，一个tcp连接可以无限制处理多个请求
- 强制压缩HTTP首部
- 服务器推送（server push）允许服务器未经请求，主动向客户端发送资源，减少延迟时间
- 设置请求的优先级
7 HTTPS 协议
HTTPS 是基于 HTTP 协议的，HTTP的对称非对称算法混用仍然不安全，因为无法确定服务端给浏览器端的公匙是真的，可能会是别人伪造的，
所以HTTPS会使用 TLS/SSL握手流程来验证公匙
TLS握手过程
- 浏览器将自己支持的一套加密算法发给服务器，同时发一个浏览器随机数。
- 服务器向浏览器发送选择的加密算法、服务器生成的随机数、服务器数字证书。
- 浏览器收到证书后对证书的CA签名进行验证，如果验证通过，会从证书中拿到服务器的公钥。
- 浏览器对浏览器随机数+服务器随机数进行处理，生成预备主密码。
- 浏览器用服务器的公钥对预备主密码进行加密，发给服务器。
- 服务器收到后使用自己的私钥解密出预备主密钥。
- 浏览器和服务器分别使用预备主密钥和两个随机数，生成共享主密钥
- 二者使用共享主密钥，使用对称加密算法加密数据。
对称加密算法与非对称加密算法
- 对称加密算法的特点是 速度快，不安全，加密解密使用同一个共享密匙
- 非对称加密特点是 速度慢，安全，公密匙加密，私密匙解密
- 所以一般都是两者混用：
- 使用对称加密的共享密钥加密数据
- 浏览器通过非对称加密的公密匙加密这个共享密钥，传输给服务器
- 服务器通过私密匙解密出对称加密的共享密钥，再使用这个共享密钥解密数据
- 而加密共享密匙用的公密匙一般是服务器提供
但是这种组合的方法同样不安全
因为无法确定得到的公密匙就是服务器发送的，可能会有坏人截取，发送坏人自己的公密匙，浏览器发送加密数据后，坏人通过自己的私密匙解密
因此就产生了TLS的握手方式
8 TCP 的三步握手，四步挥手
三步握手
SYN 同步序列编号
ACK 确认字符
其中ACK报文是用来应答的，SYN报文是用来同步的
使用SYN+ACK应答表示接收到了这个消息
- 客户端向服务器发送一个 SYN 连接请求报文段，首部的同步位SYN=1，初始序号seq=x，此时客户端处于SYN_SEND 状态
- 服务器端收到 SYN 报文，使用SYN+ACK应答，一个在确认报文段中SYN=1，ACK=1，确认号ack=x+1，初始序号seq=y，此时服务器处于 SYN_REVD 的状态
- 客户端收到服务器端的 SYN 报文，确认报文段ACK=1，确认号ack=y+1，序号seq=x+1，双方处于 ESTABLISHED 状态，此时，双方已建立起了连接
客户端发送 syn(同步序列编号) 请求，进入 syn_send 状态，等待确认
服务端接收并确认 syn 包后发送 syn+ack 包，进入 syn_recv 状态
客户端接收 syn+ack 包后，发送 ack 包，双方进入 established 状态
为什么需要三次握手
首先得知道握手的目的是为了什么，是为了确认双方的接收和发送功能是正常的
-
第一次握手：客户端发送报文给服务端。说明，客户端的发送能力正常
-
第二次握手：服务端接收到了并发出报文，说明：服务端的接收、发送能力，是正常的
-
第三次握手：客户端接收到服务端的确认报文，再次发送给服务端确认报文，说明客户端的接收功能也是正常的
因此，至少需要三次握手才能确认双方的接收与发送能力是否正常。
四步挥手
客户端 – FIN --> 服务端， FIN—WAIT
服务端 – ACK --> 客户端， CLOSE-WAIT
服务端 – ACK,FIN --> 客户端， LAST-ACK
客户端 – ACK --> 服务端，CLOSED
- 客户端发送一个 FIN = 1报文 ，告诉服务器想关闭连接。seq = p（随机数代表A）
- 服务器收到这个 FIN ，发回一个 ACK，表示知道了，正在关闭（关闭服务器需要时间） ack = p + 1(代表确认了的是A seq = p 的询问)
- 服务器通知应用程序关闭了网络连接，应用程序关闭后通知服务器。服务发送一个 FIN 给客户端 sep = q （代表B的询问）ack = p + 1（代表确认A的询问）
- 客户端发回 ACK = q+1 报文确认B的询问
为什么需要四次挥手
- 只要知道一点，服务端关闭连接是需要时间的，而不是瞬间关闭
- 服务器收到关闭消息后需要发送一次ACK确认报文说正在关闭，然后关闭成功后再发送一次FIN+ACK表示关闭成功请浏览器再确认一次
- 当服务端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文
9 UDP
UDP 是一种无连接的，不可靠的传输层协议。它只提供了传输层需要实现的最低限度的功能
通俗的来讲，UDP传输协议没有tcp复杂的功能，类似于广播，只管发送不管对方是否接收到
10 XSS和CSRF 的攻击和预防
跨站脚本 XSS Cross-Site Scripting
-
正常情况下 用户A提交正常内容，显示在用户B的网页上
-
但是有恶意用户 C提交恶意内容，对B的网页进行篡改
-
具体的篡改方式就是拿到B用户的cookie，伪装成B进行登录篡改内容
<script>console.log(document.cookie)</script> // 拿到cookie document.querySelector('h2').remove() // 篡改页面
成因以及解决
成因就是form表单提交的内容直接变成了js中的有效代码
-
后台模板问题
<p> 评论内容：<?php echo $content; ?> </p>$content 的内容，没有经过任何过滤，原样输出。
要解决这个原因，只需要后台输出的时候，将可疑的符号 < 符号变成
<（HTML实体）就行。 -
前端代码问题
$p.html(content) 或者 $p = $('<p>'+ content +'</p>')content 内容又被原样输出了。
解决办法就是不要自己拼 HTML，尽量使用 text 方法。如果一定要使用 HTML，就把可疑符号变成 HTML 实体。 -
cookie 设置 httpOnly
跨站请求伪造 Cross Site Request Forgery
通俗的讲
- 问题出在form表单中，表单无法确定是否是页面的表单，可以伪造
- 比如视频网站bilibili中，A用户可以给UP主B送礼物，页面中有个提交按钮，下面有评论区
- 但是恶意用户C在评论区写了一个链接，伪造了一个礼物赠送的表单，如果用户A不小心点击了这个链接，就会给这个恶意用户C送出礼物
- 总结就是恶意用户伪造请求
解决办法
客户端防范：对于数据库的修改请求，全部使用POST提交，禁止使用GET请求。
服务器端防范：一般的做法是在表单里面添加一段隐藏的唯一的token(请求令牌)。
- 服务端在收到路由请求时，生成一个随机数，在渲染请求页面时把随机数埋入页面（一般埋入 form 表单内，
<input type="hidden" name="_csrf_token" value="xxxx">）类似于身份证 - 服务端设置setCookie，把该随机数作为cookie或者session存入用户浏览器
- 当用户发送 GET 或者 POST 请求时带上_csrf_token参数（对于 Form 表单直接提交即可，因为会自动把当前表单内所有的 input 提交给后台，包括_csrf_token）
- 后台在接受到请求后解析请求的cookie获取_csrf_token的值，然后和用户请求提交的_csrf_token做个比较，如果相等表示请求是合法的。
注意：
- Token 最好保存在 Session 中，如果保存在cookie中可能会造成用户开启多个页面后，新打开页面改变cookie造成无法提交老的页面
- 尽量少用 GET，因为会直接将信息提交到url中
11 DNS
- DNS 的全称是 Domain Name System 或者 Domain Name Service
- 它主要的作用就是将人们所熟悉的网址 (域名) “翻译”成电脑可以理解的 IP 地址，这个过程叫做 DNS 域名解析。
- 打个比方，我们登百度的地址的时候，都是敲www.baidu.com，进行登陆，难道你会去敲IP地址登百度？明显，域名容易记忆。
浏览器中输入URL到页面返回的全过程
- 根据域名，进行DNS域名解析；
- 拿到解析的IP地址，建立TCP连接；
- 向IP地址，发送HTTP请求；
- 服务器处理请求,返回响应结果；
- 关闭TCP连接；
- 浏览器解析HTML并渲染；
12 CDN
CDN（Content Delivery Network，内容分发网络）是构建在现有互联网基础之上的一层智能虚拟网络，通过在网络各处部署节点服务器，实现将源站内容分发至所有 CDN 节点，使用户可以就近获得所需的内容。CDN 服务缩短了用户查看内容的访问延迟，提高了用户访问网站的响应速度与网站的可用性，解决了网络带宽小、用户访问量大、网点分布不均等问题。
加速原理
当用户访问使用 CDN 服务的网站时，本地 DNS 服务器通过 CNAME 方式将最终域名请求重定向到 CDN 服务。CDN 通过一组预先定义好的策略(如内容类型、地理区域、网络负载状况等)，将当时能够最快响应用户的 CDN 节点 IP 地址提供给用户，使用户可以以最快的速度获得网站内容。使用 CDN 后的 HTTP 请求处理流程如下：
CDN 节点有缓存场景
- 用户在浏览器输入要访问的网站域名，向本地 DNS 发起域名解析请求。
- 域名解析的请求被发往网站授权 DNS 服务器。
- 网站 DNS 服务器解析发现域名已经 CNAME 到了 www.example.com.c.cdnhwc1.com。
- 请求被指向 CDN 服务。
- CDN 对域名进行智能解析，将响应速度最快的 CDN 节点 IP 地址返回给本地 DNS。
- 用户获取响应速度最快的 CDN 节点 IP 地址。
- 浏览器在得到速度最快节点的 IP 地址以后，向 CDN 节点发出访问请求。
- CDN 节点将用户所需资源返回给用户。
CDN 节点无缓存场景
- 用户在浏览器输入要访问的网站域名，向本地 DNS 发起域名解析请求。
- 域名解析的请求被发往网站授权 DNS 服务器。
- 网站 DNS 服务器解析发现域名已经 CNAME 到了 www.example.com.c.cdnhwc1.com。
- 请求被指向 CDN 服务。
- CDN 对域名进行智能解析，将响应速度最快的 CDN 节点 IP 地址返回给本地 DNS。
- 用户获取响应速度最快的 CDN 节点 IP 地址。
- 浏览器在得到速度最快节点的 IP 地址以后，向 CDN 节点发出访问请求。
- CDN 节点回源站拉取用户所需资源。
- 将回源拉取的资源缓存至节点。
- 将用户所需资源返回给用户。
PS：CNAME 别名解析是将域名指向一个网址（域名）
200
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
