1. Http 状态码，Http2 是什么
答案：
200 欢迎回来，主人 （正常；请求已完成。）
301 人家搬家了 （已移动 — 请求的数据具有新的位置且更改是永久的。）
307 不是这里，换个地方啦 （重新请求的 URL，客户端自动重新请求新的地址）
400 不要把奇怪的东西给人家嘛 （错误请求 — 请求中有语法问题，或不能满足请求。）
403 这里不可以啦！（禁止 — 即使有授权也不需要访问。）
404 这里什么都没有 --- 人家是平的啦。 （找不到 — 服务器找不到给定的资源；文档不存在。）
405 打开方式不对 （资源被禁止）
414 这... 太长了啦 （请求 - URI 太长）
500 服务姬坏掉了啦 （内部错误 — 因为意外情况，服务器不能完成请求。）
503 不要...人家还没准备好啦 （无法获得服务 — 由于临时过载或维护，服务器无法处理请求。）
101 服务姬傲娇中 （服务器将遵从客户的请求转换到另外一种协议）
100 人家... 还要... （初始的请求已经接受，客户应当继续发送请求的其余部分。）
HTTP/2（超文本传输协议第 2 版，最初命名为 HTTP 2.0），是 HTTP 协议的的第二个主要版本，使用于万维网。HTTP/2 是 HTTP 协议自 1999 年 HTTP 1.1 发布后的首个更新，主要基于 SPDY 协议（是 Google 开发的基于 TCP 的应用层协议，用以最小化网络延迟，提升网络速度，优化用户的网络使用体验）。
与 HTTP 1.1 相比，主要区别包括
- HTTP/2 采用二进制格式而非文本格式
- HTTP/2 是完全多路复用的，而非有序并阻塞的——只需一个连接即可实现并行
- 使用报头压缩，HTTP/2 降低了开销
- HTTP/2 让服务器可以将响应主动“推送”到客户端缓存中
解析：
| 状态码 | 类别 | 描述 |
|---|---|---|
| 1xx | Informational（信息状态码） | 接受请求正在处理 |
| 2xx | Success（成功状态码） | 请求正常处理完毕 |
| 3xx | Redirection（重定向状态码） | 需要附加操作已完成请求 |
| 4xx | Client Error（客户端错误状态码） | 服务器无法处理请求 |
| 5xx | Server Error（服务器错误状态码） | 服务器处理请求出错 |
3. Http 请求的整个过程
答案：
简洁版： 1.域名解析 --> 2.发起 TCP 的 3 次握手 --> 3.建立 TCP 连接后发起 http 请求 --> 4.服务器响应 http 请求，浏览器得到 html 代码 --> 5.浏览器解析 html 代码，并请求 html 代码中的资源（如 js、css、图片等） --> 6.浏览器对页面进行渲染呈现给用户
4. http 缓存配置怎么设置
答案：
前端设置 http 缓存,前端设置 html 页面缓存方法：静态的 html 页面想要设置使用缓存需要通过 HTTP 的 META 设置 expires 和 cache-control
设置如下网页元信息:
<meta http-equiv="Cache-Control" content="max-age=7200" />
<meta http-equiv="Expires" content="Mon, 20 Jul 2013 23:00:00 GMT" />解答: cache-control：||no-cache||no-store||max-age
1.no-cache：
表面意为“数据内容不被缓存”，而实际数据是被缓存到本地的，只是每次请求时候直接绕过缓存这一环节直接向服务器请求最新资源，由于浏览器解释不一样，
例如 ie 中我们设置了 no-cache 之后，请求虽然不会直接使用缓存，但是还会用缓存数据与服务器数据进行一致性检测(也就是说还是有几率会用到缓存的),
firefox 中则完全无视 no-cache 存在，详细解释见 no-store;
2.no-store：
指示缓存不存储此次请求的响应部分。与 no-cache 比较来说，一个是不用缓存，一个是不存储缓存;按理来说这个设置更加粗暴直接禁用缓存，
但是具体实现起来 浏览器之间差异却特别大，一般不会直接用该字段进行设置，不过 no-store 是为了防止缓存被恶意修改存储路径导致信息被泄露而设置的，
毕竟有它的用处，在 firefox 中实现缓存是通过文件另存为将缓存副本保存到本地，直接利用 no-cache 对其是无效的，如果加上 no-store 设置的话 则可以起到与 no-cache 一样的效果;
即：cache-control:no-cache,no-store;可以确保在支持 http1.1 版本中各大浏览器回车后退刷新无缓存；
再加上 Pragma: no-cache 设置兼容版本 1.0 即可(不过为了防止一致性检测时候的万一我们还是最好加上一致性检测的内容，如下所示几种方式)；
3.max-age：
例如 Cache-control: max-age=3；表示此次请求成功后 3 秒之内发送同样请求不会去服务器重新请求，而是使用本地缓存；同样我们如果设置 max-age=0 表示立即抛弃缓存直接发送请求到服务器
以下内容来自:http://www.runoob.com/tags/att-meta-http-equiv.html
HTML http-equiv 属性 HTML meta 标签参考手册 HTML 标签
实例 每隔 30 秒刷新一次文档：
<head>
<meta http-equiv="refresh" content="30" />
</head>扩展：
与缓存有关的 header 我们来看看每个 header 的具体含义。
- Request
Cache-Control: max-age=0 以秒为单位 If-Modified-Since: Mon, 19 Nov 2012 08:38:01 GMT 缓存文件的最后修改时间。 If-None-Match: "0693f67a67cc1:0" 缓存文件的 Etag 值 Cache-Control: no-cache 不使用缓存 Pragma: no-cache 不使用缓存
- Response
Cache-Control: public 响应被缓存，并且在多用户间共享， （公有缓存和私有缓存的区别，请看另一节） Cache-Control: private 响应只能作为私有缓存，不能在用户之间共享 Cache-Control:no-cache 提醒浏览器要从服务器提取文档进行验证 Cache-Control:no-store 绝对禁止缓存（用于机密，敏感文件） Cache-Control: max-age=60 60 秒之后缓存过期（相对时间） Date: Mon, 19 Nov 2012 08:39:00 GMT 当前 response 发送的时间 Expires: Mon, 19 Nov 2012 08:40:01 GMT 缓存过期的时间（绝对时间） Last-Modified: Mon, 19 Nov 2012 08:38:01 GMT 服务器端文件的最后修改时间 ETag: "20b1add7ec1cd1:0" 服务器端文件的 Etag 值
5. 常见的浏览器端的存储技术有哪些， 以及它们的优缺点和使用场景？
答案：
h5 之前，存储主要用 cookies，缺点是在请求头上带着数据，导致流量增加。大小限制 4k
操作方式：
document.cookie = "username=John Doe; expires=Thu, 18 Dec 2013 12:00:00
GMT;path=/" // 设置 cookie document.cookie = "username=; expires=Thu, 01 Jan
1970 00:00:00 GMT" // 删除 cookie设置 cookie 的方法比较简单，其中有几个参数可以添加
expires 过期时间，当过了到期日期时，浏览器会自动删除该 cookie，如果想删除一个 cookie，只需要把它过期时间设置成过去的时间即可 比如希望设置过期时间一年：new Date().getTime() + 365 _ 24 _ 60 _ 60 _ 1000
如果不设置过期时间，则表示这个 cookie 生命周期为浏览器会话期间，只要关闭浏览器窗口，cookie 就消失了。
path 路径，值可以是一个目录，或者是一个路径。
如果 cc.com/test/index.html 建立了一个 cookie，那么在 cc.com/test/目录里的所有页面，以及该目录下面任何子目录里的页面都可以访问这个 cookie。因此在 cc.com/test/test2/test3 里的任何页面都可以访问 cc.com/test/index.html 建立的 cookie。若 cc.com/test/ 若想访问 cc.com/test/index.html 设置的 cookes，需要把 cookies 的 path 属性设置成“/”。 在指定路径的时候，凡是来自同一服务器，URL 里有相同路径的所有 WEB 页面都可以共享 cookies。
domain 主机名，是指同一个域下的不同主机，例如：www.baidu.com 和 map.baidu.com 就是两个不同的主机名。默认情况下，一个主机中创建的 cookie 在另一个主机下是不能被访问的，但可以通过 domain 参数来实现对其的控制：document.cookie = "name=value;domain=.baidu.com" 这样，所有*.baidu.com 的主机都可以访问该 cookie。
以键值对(Key-Value)的方式存储，永久存储，永不失效，除非手动删除。IE8+支持，每个域名限制 5M
打开同域的新页面也能访问得到
操作方式：
window.localStorage.username = 'hehe' // 设置 window.localStorage.setItem('username', 'hehe') // 设置 window.localStorage.getItem('username') // 读取 window.localStorage.removeItem('username') // 删除 window.localStorage.key(1) // 读取索引为 1 的值 window.localStorage.clear() // 清除所有 可以存储数组、数字、对象等可以被序列化为字符串的内容
sessionStorage 操作的方法与 localStroage 是一样的，区别在于 sessionStorage 在关闭页面后即被清空，而 localStorage 则会一直保存。很多时候数据只需要在用户浏览一组页面期间使用，关闭窗口后数据就可以丢弃了，这种情况使用 sessionStorage 就比较方便。
注意，刷新页面 sessionStorage 不会清除，但是打开同域新页面访问不到
他们都是保存在浏览器端的存储方式，他们之间的区别：
cookie 数据始终在同源的 http 请求中携带（即使不需要），即 cookie 在浏览器和服务器间来回传递。而 sessionStorage 和 localStorage 不会自动把数据发给服务器，仅在本地保存。cookie 数据还有路径（path）的概念，可以限制 cookie 只属于某个路径下。 存储大小限制不同，cookie 数据不能超过 4k，同时因为每次 http 请求都会携带 cookie，所以 cookie 只适合保存很小的数据，如会话标识。sessionStorage 和 localStorage 虽然也有存储大小的限制，但比 cookie 大得多，可以达到 5M 或更大。 数据有效期不同，sessionStorage：仅在当前浏览器窗口关闭前有效，自然也就不可能持久保持；localStorage：始终有效，窗口或浏览器关闭也一直保存，因此用作持久数据；cookie 只在设置的 cookie 过期时间之前一直有效，即使窗口或浏览器关闭。 作用域不同，sessionStorage 不在不同的浏览器页面中共享，即使是同一个页面；localStorage 在所有同源窗口中都是共享的；cookie 也是在所有同源窗口中都是共享的。 Web Storage 支持事件通知机制，可以将数据更新的通知发送给监听者。 Web Storage 的 api 接口使用更方便，cookie 的原生接口不友好，需要自己封装。
需要注意的是，不是什么数据都适合放在 Cookie、localStorage 和 sessionStorage 中的，因为它们保存在本地容易被篡改，使用它们的时候，需要时刻注意是否有代码存在 XSS 注入的风险。所以千万不要用它们存储你系统中的敏感数据。
6. 在 HTTP 响应 Header 中，set-cookie 选项有哪些，分别代表什么含义？
答案：
Set-Cookie: <cookie-name>=<cookie-value>
- Expires=
<date> - Max-Age=
<non-zero-digit> - Domain=
<domain-value> - Path=
<path-value> - Secure
- HttpOnly
- SameSite=Strict
- SameSite=Lax
name = name; // 需要设置cookie的值(name不能使用";"和","号),有多个name值时用";"分隔例如：name1=name1;name2=name2;name3=name3
expires; //cookie的有效期限,格式为:expires="Wdy,DD-Mon-YYYY HH:MM:SS"
path; //设置cookie支持的路径,如果path是一个路径，则cookie对这个目录下的所有文件及子目录生效，例如：path="/cgi-bin/"，如果path是一个文件，则cookie指对这个文件生效，例如：path="/cgi-bin/cookie.cgi"
domain; //对cookie生效的域名，例如：domain="gzdzw.51.net"
secure; //如果给出此标志，表示cookie只能通过SSL协议的https服务器来传递,cookie的接收是通过设置环境变量HTTP_COOKIE来实现的，CGI程序可以通过检索该变量获取cookie信息解析：Cookie 相关的 Http 头
有两个 Http 头部和 Cookie 有关：Set-Cookie 和 Cookie
- Set-Cookie 由服务器发送，它包含在响应请求的头部中。它用于在客户端创建一个 Cookie
- Cookie 头由客户端发送，包含在 HTTP 请求的头部中。注意，只有 cookie 的 domain 和 path 与请求的 URL 匹配才会发送这个 cookie。
7. 何为跨域？ 跨域请求数据有几种方式？图片/脚本 等资源有什么跨域问题。如何解决？跨域请求时如何携带 cookie
答案：
- 由于浏览器同源策略，凡是发送请求 url 的协议、域名、端口三者之间任意一与当前页面地址不同即为跨域。
- 同源策略限制了一个源(origin)中加载文本或脚本与来自其它源(origin)中资源的交互方式。同源指的是协议、域名、端口相同，同源策略是一种安全协议。
（1）JSONP 动态创建 script 标签
但缺点是只支持 get 请求，并且很难判断请求是否失败（一般通过判断请求是否超时）。
（2）Proxy 代理
这种方式首先将请求发送给后台服务器，通过服务器来发送请求，然后将请求的结果传递给前端。
（3）CORS 跨域
是现代浏览器提供的一种跨域请求资源的方法，需要客户端和服务器端的同时支持。整个 CORS 通信过程，都是浏览器自动完成，不需要用户参与。对于开发者来说，CORS 通信与同源的 AJAX 通信没有差别，代码完全一样。浏览器一旦发现 AJAX 请求跨源，就会自动添加一些附加的头信息，有时还会多出一次附加的请求，但用户不会有感觉。因此，实现 CORS 通信的关键是服务器。只要服务器实现了 CORS 接口，就可以跨源通信。
8. 简要描述 HTTPS 的安全机制，以及在 web 服务工程实践中需要注意的问题。描述 http2 和 https 的关系
答案：
- HTTP 协议通常承载于 TCP 协议之上，在 HTTP 和 TCP 之间添加一个安全协议层（SSL 或 TSL），这个时候，就成了我们常说的 HTTPS。
- 默认 HTTP 的端口号为 80，HTTPS 的端口号为 443。
9. 什么是点击劫持？如何防范？
答案：
什么点击劫持？最常见的是恶意网站使用 <iframe> 标签把我方的一些含有重要信息类如交易的网页嵌入进去，然后把 iframe 设置透明，用定位的手段的把一些引诱用户在恶意网页上点击。这样用户不知不觉中就进行了某些不安全的操作。
有两种方式可以防范：
-
使用 JS 防范： if (top.location.hostname !== self.location.hostname) { alert("您正在访问不安全的页面，即将跳转到安全页面！"); top.location.href = self.location.href; }
-
使用 HTTP 头防范： 通过配置 nginx 发送 X-Frame-Options 响应头，这样浏览器就会阻止嵌入网页的渲染。更详细的可以查阅 MDN 上关于 X-Frame-Options 响应头的内容。 add_header X-Frame-Options SAMEORIGIN;
10. 什么是 CSRF, 怎么造成的，有什么防御方法？
答案：
CSRF 概念：CSRF 跨站点请求伪造(Cross—Site Request Forgery)，跟 XSS 攻击一样，存在巨大的危害性，你可以这样来理解： 攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以你的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等。 如下：其中 Web A 为存在 CSRF 漏洞的网站，Web B 为攻击者构建的恶意网站，User C 为 Web A 网站的合法用户。
CSRF 攻击攻击原理及过程如下：
1. 用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A；
2.在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A；
3. 用户未退出网站A之前，在同一浏览器中，打开一个TAB页访问网站B；
4. 网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A；
5. 浏览器在接收到这些攻击性代码后，根据网站B的请求，在用户不知情的情况下携带Cookie信息，向网站A发出请求。网站A并不知道该请求其实是由B发起的，所以会根据用户C的Cookie信息以C的权限处理该请求，导致来自网站B的恶意代码被执行。
防御 CSRF 攻击：
目前防御 CSRF 攻击主要有三种策略：验证 HTTP Referer 字段；在请求地址中添加 token 并验证；在 HTTP 头中自定义属性并验证。
解析：
CSRF（Cross-site request forgery）跨站请求伪造，也被称为“One Click Attack”或者 Session Riding，通常缩写为 CSRF 或者 XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与 XSS 非常不同，XSS 利用站点内的信任用户，而 CSRF 则通过伪装来自受信任用户的请求来利用受信任的网站。与 XSS 攻击相比，CSRF 攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比 XSS 更具危险性。
- 依靠用户标识危害网站
- 利用网站对用户标识的信任
- 欺骗用户的浏览器发送 HTTP 请求给目标站点
- 另外可以通过 IMG 标签会触发一个 GET 请求，可以利用它来实现 CSRF 攻击。
- 通过 referer、token 或者验证码来检测用户提交。
- 尽量不要在页面的链接中暴露用户隐私信息。
- 对于用户修改删除等操作最好都使用 post 操作 。
- 避免全站通用的 cookie，严格设置 cookie 的域。
11. 请简述如何在 HTML 中开启和关闭 DNS 预读取?
答案：
浏览器主动去执行域名解析功能。
当浏览网页时，浏览器会对网页中的域名进行解析缓存，这样当单击当前网页中的连接时就无需进行 DNS 解析，减少用户等待时间，提高用户体验。
图片、CSS、JS 或 html 上的 link 等 URL。
<meta http-equiv="x-dns-prefetch-control" content="off" />
<link rel="dns-prefetch" href="//www.spreadfirefox.com" />减少 DNS 请求次数；
进行 DNS 预获取；
12. 什么是回源？域名回源的含义是什么？
答案：在搜索引擎中所谓的域名回源就是搜索引擎的蜘蛛在爬行的过程中直接抓取源地址上的内容而不是存在各个节点（CDN）上的缓存内容。
解析：
CDN 回源率计算方法
回源比分为回源请求数比例及回源流量比例两种
回源请求数比：统计数据来自所有边缘节点上的请求记录，其中，对于没有缓存或缓存过期（可缓存）的请求以及不可缓存的请求，均计入回源请求中，其他直接命中缓存的，则为命中请求。
回源流量比：回源流量是回源请求文件大小产生的流量和请求本身产生的流量 回源流量比=回源流量/回源流量+用户请求访问的流量
源站内容有更新的时候，源站主动把内容推送到 CDN 节点。 常规的 CDN 都是回源的。即：当有用户访问某一个 URL 的时候，如果被解析到的那个 CDN 节点没有缓存响应的内容，或者是缓存已经到期，就会回源站去获取。如果没有人访问，那么 CDN 节点不会主动去源站拿的。
回源域名一般是 cdn 领域的专业术语，通常情况下，是直接用 ip 进行回源的，但是如果客户源站有多个 ip，并且 ip 地址会经常变化，对于 cdn 厂商来说，为了避免经常更改配置（回源 ip），会采用回源域名方式进行回源，这样即使源站的 ip 变化了，也不影响原有的配置。
CDN 本来是给我们的网站加速的，但是有时会因为不合适的回源策略给服务器带来负担，只有选择正确的策略才能给自己的网站带来更高的访问效率。
13. https 实现原理
答案：
HTTPS 在通讯过程中的原理，总共分为 8 步 STEP 1: 客户端发起 HTTPS 请求 STEP 2: 服务端的配置 STEP 3: 传送证书 STEP 4: 客户端解析证书 STEP 5: 传送加密信息 STEP 6: 服务端解密信息 STEP 7: 传输加密后的信息 STEP 8: 客户端解密信息
14. HTML5 的离线储存怎么使用，工作原理能不能解释一下
答案：
如何使用：只要在在页面头部加入 mainfest 的属性就行了。
<!DOCTYPE html>
<html manifest="cache.manifest"></html>工作原理：HTML5 的离线存储是基于一个新建的.appcache 文件的缓存机制（不是存储技术），通过这个文件上的解析清单离线存储资源，这些资源就像 cookie 一样被存储下来。当无网时，浏览器会通过被离线存储的数据进行展示
15. XSS
答案：
XSS 是一种经常出现在 web 应用中的计算机安全漏洞，它允许恶意 web 用户将代码植入到提供给其它用户使用的页面中。
比如这些代码包括 HTML 代码和客户端脚本。攻击者利用 XSS 漏洞旁路掉访问控制——例如同源策略(same origin policy)。
这种类型的漏洞由于被黑客用来编写危害性更大的网络钓鱼(Phishing)攻击而变得广为人知。
对于跨站脚本攻击，黑客界共识是：跨站脚本攻击是新型的“缓冲区溢出攻击“，而 JavaScript 是新型的“ShellCode”。
示例：
<script>alert(document.cookie)</script>
能注入恶意的 HTML/JavaScript 代码到用户浏览的网页上，从而达到 Cookie 资料窃取、会话劫持、钓鱼欺骗等攻击。 <攻击代码不一定（非要）在 <script></script> 中>
- Web 浏览器本身的设计不安全。浏览器能解析和执行 JS 等代码，但是不会判断该数据和程序代码是否恶意。
- 输入和输出是 Web 应用程序最基本的交互，而且网站的交互功能越来越丰富。如果在这过程中没有做好安全防护，很容易会出现 XSS 漏洞。
- 程序员水平参差不齐，而且大都没有过正规的安全培训，没有相关的安全意识。
- XSS 攻击手段灵活多变。
- 盗取各类用户帐号，如机器登录帐号、用户网银帐号、各类管理员帐号
- 控制企业数据，包括读取、篡改、添加、删除企业敏感数据的能力
- 盗窃企业重要的具有商业价值的资料
- 非法转账
- 强制发送电子邮件
- 网站挂马
- 控制受害者机器向其它网站发起攻击
- 将重要的 cookie 标记为 http only, 这样的话 Javascript 中的 document.cookie 语句就不能获取到 cookie 了.
- 表单数据规定值的类型，例如：年龄应为只能为 int、name 只能为字母数字组合。。。。
- 对数据进行 Html Encode 处理
- 过滤或移除特殊的 Html 标签， 例如: <script>, <iframe> , < for <, > for >, " for
- 过滤 JavaScript 事件的标签。例如 "onclick=", "onfocus" 等等。
解析：参考资料：
https://www.cnblogs.com/phpstudy2015-6/p/6767032.html
https://www.cnblogs.com/443855539-wind/p/6055816.html
https://baike.baidu.com/item/XSS%E6%94%BB%E5%87%BB/954065?fr=aladdin
20.三次握手
答案：
TCP 协议是面向连接的通信协议，即在传输数据前先在发送端和接收端建立逻辑连接，然后再传输数据，它提供了两台计算机之间可靠无差错的数据传输。
在 TCP 连接中必须要明确客户端与服务器端，由客户端向服务端发出连接请求，每次连接的创建都需要经过“三次握手”
第一次握手，客户端向服务器端发送一个带 SYN 标志的数据包，等待服务器确认
第二次握手，服务器端向客户端回传一个带有 SYN/ACK 标志的数据包，通知客户端收到了连接请求
第三次握手，客户端再次向服务器端回传一个带 ACK 标志的数据包，确认连接，“握手”结束。
21.四次挥手
答案：
1、客户端向服务器发送一个断开连接的请求（不早了，我该走了）；
2、服务器接到请求后发送确认收到请求的信号（知道了）；
3、服务器向客户端发送断开通知（我也该走了）；
4、客户端接到断开通知后断开连接并反馈一个确认信号（嗯，好的），服务器收到确认信号后断开连接；
解析：
第一次挥手：主动关闭方发送一个 FIN，用来关闭主动方到被动关闭方的数据传送，也就是主动关闭方告诉被动关闭方：我已经不会再给你发数据了(当然，在 fin 包之前发送出去的数据，如果没有收到对应的 ack 确认报文，主动关闭方依然会重发这些数据)，但是，此时主动关闭方还可 以接受数据。
第二次挥手：被动关闭方收到 FIN 包后，发送一个 ACK 给对方，确认序号为收到序号+1（与 SYN 相同，一个 FIN 占用一个序号）。
第三次挥手：被动关闭方发送一个 FIN，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，我的数据也发送完了，不会再给你发数据了。
第四次挥手：主动关闭方收到 FIN 后，发送一个 ACK 给被动关闭方，确认序号为收到序号+1，至此，完成四次挥手。
22.线程与进程的区别
答案：
a. 一个程序至少有一个进程，一个进程至少有一个线程
b. 线程的划分尺度小于进程，使得多线程程序的并发性高
c. 进程在执行过程中拥有独立的内存单元，而多个线程共享内存，从而极大地提高了程序的运行效率
d. 每个独立的线程有一个程序运行的入口、顺序执行序列和程序的出口。但是线程不能够独立执行，必须依存在应用程序中，由应用程序提供多个线程执行控制
e. 多线程的意义在于一个应用程序中，有多个执行部分可以同时执行。但操作系统并没有将多个线程看做多个独立的应用，来实现进程的调度和管理以及资源分配
23. WEB 应用从服务器主动推送 Data 到客户端有那些方式？
答案：
a. html5 websoket
b. WebSocket 通过 Flash
c. XHR 长时间连接
d. XHR Multipart Streaming
e. 不可见的 Iframe
f. 标签的长时间连接(可跨域)
27.域名发散和域名收敛是什么？
答案：
PC 时代为了突破浏览器的域名并发限制。有了域名发散。 浏览器有并发限制，是为了防止DDOS攻击。
- 域名收敛：就是将静态资源放在一个域名下。减少DNS解析的开销。
- 域名发散：是将静态资源放在多个子域名下，就可以多线程下载，提高并行度，使客户端加载静态资源更加迅速。
域名发散是pc端为了利用浏览器的多线程并行下载能力。而域名收敛多用与移动端，提高性能，因为dns解析是是从后向前迭代解析，如果域名过多性能会下降，增加DNS的解析开销。
29.TCP 和 UDP 的区别
答案：
TCP（Transmission Control Protocol，传输控制协议）是基于连接的协议，也就是说，在正式收发数据前，必须和对方建立可靠的连接。一个 TCP 连接必须要经过三次“对话”才能建立起来
UDP（User Data Protocol，用户数据报协议）是与 TCP 相对应的协议。它是面向非连接的协议，它不与对方建立连接，而是直接就把数据包发送过去！ UDP 适用于一次只传送少量数据、对可靠性要求不高的应用环境。
30. Web Worker 和 webSocket
答案：
worker 主线程:
1.通过 worker = new Worker( url ) 加载一个JS文件来创建一个worker，同时返回一个worker实例。
2.通过worker.postMessage( data ) 方法来向worker发送数据。
3.绑定worker.onmessage方法来接收worker发送过来的数据。
4.可以使用 worker.terminate() 来终止一个worker的执行。
WebSocket 是 Web 应用程序的传输协议，它提供了双向的，按序到达的数据流。他是一个 Html5 协议，WebSocket 的连接是持久的，他通过在客户端和服务器之间保持双工连接，服务器的更新可以被及时推送给客户端，而不需要客户端以一定时间间隔去轮询。
31.为什么 HTTPS 安全
答案：因为网络请求需要中间有很多的服务器路由器的转发。中间的节点都可能篡改信息，而如果使用 HTTPS，密钥在你和终点站才有。https 之所以比 http 安全，是因为他利用 ssl/tls 协议传输。它包含证书，卸载，流量转发，负载均衡，页面适配，浏览器适配，refer 传递等。保障了传输过程的安全性
32.sql 注入原理
答案：就是通过把 SQL 命令插入到 Web 表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的 SQL 命令。
总的来说有以下几点：
-
永远不要信任用户的输入，要对用户的输入进行校验，可以通过正则表达式，或限制长度，对单引号和双"-"进行转换等。
-
永远不要使用动态拼装 SQL，可以使用参数化的 SQL 或者直接使用存储过程进行数据查询存取。
-
永远不要使用管理员权限的数据库连接，为每个应用使用单独的权限有限的数据库连接。
-
不要把机密信息明文存放，请加密或者 hash 掉密码和敏感的信息。
33.XSS 原理及防范
答案：
Xss(cross-site scripting)攻击指的是攻击者往 Web 页面里插入恶意 html 标签或者 javascript 代码。比如：攻击者在论坛中放一个看似安全的链接，骗取用户点击后，窃取 cookie 中的用户私密信息；或者攻击者在论坛中加一个恶意表单，当用户提交表单的时候，却把信息传送到攻击者的服务器中，而不是用户原本以为的信任站点。
34.XSS 防范方法
答案：
首先代码里对用户输入的地方和变量都需要仔细检查长度和对”<”,”>”,”;”,”’”等字符做过滤；其次任何内容写到页面之前都必须加以 encode，避免不小心把 html tag 弄出来。这一个层面做好，至少可以堵住超过一半的 XSS 攻击。
首先，避免直接在 cookie 中泄露用户隐私，例如 email、密码等等。
其次，通过使 cookie 和系统 ip 绑定来降低 cookie 泄露后的危险。这样攻击者得到的 cookie 没有实际价值，不可能拿来重放。
如果网站不需要再浏览器端对 cookie 进行操作，可以在 Set-Cookie 末尾加上 HttpOnly 来防止 javascript 代码直接获取 cookie 。
尽量采用 POST 而非 GET 提交表单
35.XSS 与 CSRF 有什么区别吗？
答案：
XSS 是获取信息，不需要提前知道其他用户页面的代码和数据包。CSRF 是代替用户完成指定的动作，需要知道其他用户页面的代码和数据包。
要完成一次 CSRF 攻击，受害者必须依次完成两个步骤：
- 登录受信任网站 A，并在本地生成 Cookie。
- 在不登出 A 的情况下，访问危险网站 B。
37.请你谈谈 Cookie 的弊端？
答案：
Cookie数量和长度的限制。每个 domain 最多只能有 20 条 cookie，每个 cookie 长度不能超过 4KB，否则会被截掉。- 安全性问题。如果 cookie 被人拦截了，那人就可以取得所有的 session 信息。即使加密也与事无补，因为拦截者并不需要知道 cookie 的意义，他只要原样转发 cookie 就可以达到目的了。
- 有些状态不可能保存在客户端。例如，为了防止重复提交表单，我们需要在服务器端保存一个计数器。如果我们把这个计数器保存在客户端，那么它起不到任何作用。
39.本地存储（Local Storage ）和 cookies（储存在用户本地终端上的数据）之间的区别是什么？
答案：
Cookies:服务器和客户端都可以访问；大小只有 4KB 左右；有有效期，过期后将会删除；
本地存储：只有本地浏览器端可访问数据，服务器不能访问本地存储直到故意通过 POST 或者 GET 的通道发送到服务器；每个域 5MB；没有过期数据，它将保留知道用户从浏览器清除或者使用 Javascript 代码移除
40.Accept 和 Content-Type
答案：
Accept 请求头用来告知客户端可以处理的内容类型，这种内容类型用 MIME 类型来表示。 服务器使用 Content-Type 应答头通知客户端它的选择。
Accept: text/html
Accept: image/*
Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8
1.Accept 属于请求头， Content-Type 属于实体头。
Http 报头分为通用报头，请求报头，响应报头和实体报头。
请求方的 http 报头结构：通用报头|请求报头|实体报头
响应方的 http 报头结构：通用报头|响应报头|实体报头
2.Accept 代表发送端（客户端）希望接受的数据类型。
比如：Accept：text/xml;
代表客户端希望接受的数据类型是 xml 类型
Content-Type 代表发送端（客户端|服务器）发送的实体数据的数据类型。
比如：Content-Type：text/html;
代表发送端发送的数据格式是 html。
二者合起来，
Accept:text/xml；
Content-Type:text/html
即代表希望接受的数据类型是 xml 格式，本次请求发送的数据的数据格式是 html。
42.如何处理不让别人盗用你的图片，访问你的服务器资源
答案：
- http header, 对 refer 做判断看来源是不是自己的网站，如果不是就拒绝
- 通过 session 校验，如果不通过特定服务生成 cookie 和 session 就不能请求得到资源
43.Http 与 Https 的区别
答案：
- HTTP 的 URL 以 http:// 开头，而 HTTPS 的 URL 以 https:// 开头
- HTTP 是不安全的，而 HTTPS 是安全的
- HTTP 标准端口是 80 ，而 HTTPS 的标准端口是 443
- 在 OSI 网络模型中，HTTP 工作于应用层，而 HTTPS 的安全传输机制工作在传输层
- HTTP 无法加密，而 HTTPS 对传输的数据进行加密
- HTTP 无需证书，而 HTTPS 需要 CA 机构 wosign 的颁发的 SSL 证书
解析：参考
44.什么是 Http 协议无状态协议?怎么解决 Http 协议无状态协议?
答案：
无状态协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息也就是说，
当客户端一次 HTTP 请求完成以后，客户端再发送一次 HTTP 请求，HTTP 并不知道当前客户端是一个”老用户“。
可以使用 Cookie 来解决无状态的问题，Cookie 就相当于一个通行证，第一次访问的时候给客户端发送一个 Cookie，
当客户端再次来的时候，拿着 Cookie(通行证)，那么服务器就知道这个是”老用户“。
解析：参考
45.常用的 HTTP 方法有哪些
答案：
- GET：用于请求访问已经被 URL（统一资源标识符）识别的资源，可以通过 URL 传参给服务器。
- POST：用于传输信息给服务器，主要功能与 Get 方法类似，但一般推荐 POST 方式。
- PUT：传输文件，报文主体包含文件内容，保存到对应 URL 位置。
- HEAD：获取报文首部，与 GET 方法类似，只是不返回报文主体，一般用于验证 URL 是否有效。
- DELET：删除文件，与 PUT 方法相反，删除对应 URL 位置的文件。OPTIONS：查询相应 URL 支持的 HTTP 方法。
46.一次完整的 HTTP 请求所经历的 7 个步骤
答案：
HTTP 通信机制是在一次完整的 HTTP 通信过程中，Web 浏览器与 Web 服务器之间将完成下列 7 个步骤：
- 建立 TCP 连接
在 HTTP 工作开始之前，Web 浏览器首先要通过网络与 Web 服务器建立连接，该连接是通过 TCP 来完成的，该协议与 IP 协议共同构建 Internet，即著名的 TCP/IP 协议族，因此 Internet 又被称作是 TCP/IP 网络。HTTP 是比 TCP 更高层次的应用层协议，根据规则， 只有低层协议建立之后才能，才能进行更层协议的连接，因此，首先要建立 TCP 连接，一般 TCP 连接的端口号是 80。
- Web 浏览器向 Web 服务器发送请求行
一旦建立了 TCP 连接，Web 浏览器就会向 Web 服务器发送请求命令。例如：GET /sample/hello.jsp HTTP/1.1。
- Web 浏览器发送请求头
浏览器发送其请求命令之后，还要以头信息的形式向 Web 服务器发送一些别的信息，之后浏览器发送了一空白行来通知服务器，它已经结束了该头信息的发送。
- Web 服务器应答
客户机向服务器发出请求后，服务器会客户机回送应答， HTTP/1.1 200 OK ，应答的第一部分是协议的版本号和应答状态码。
- Web 服务器发送应答头
正如客户端会随同请求发送关于自身的信息一样，服务器也会随同应答向用户发送关于它自己的数据及被请求的文档。
- Web 服务器向浏览器发送数据
Web 服务器向浏览器发送头信息后，它会发送一个空白行来表示头信息的发送到此为结束，接着，它就以 Content-Type 应答头信息所描述的格式发送用户所请求的实际数据。
- Web 服务器关闭 TCP 连接
一般情况下，一旦 Web 服务器向浏览器发送了请求数据，它就要关闭 TCP 连接，然后如果浏览器或者服务器在其头信息加入了这行代码：
Connection:keep-alive
TCP 连接在发送后将仍然保持打开状态，于是，浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间，还节约了网络带宽。
建立 TCP 连接->发送请求行->发送请求头->（到达服务器）发送状态行->发送响应头->发送响应数据->断 TCP 连接
解析：参考
47. webSocket 如何兼容低版本浏览器？
答案：对于低端不支持 websocket 的浏览器，一般有几个解决方案
-
使用轮询或长连接的方式实现伪 websocket 的通信
-
使用 flash 或其他方法实现一个 websocket 客户端 ：