OSI 七层模型：
- 应用层：网络进程访问应用层，提供接口服务
HTTP：超文本传输协议
FTP：文件传输协议
DNS：域名解析协议
Telnet：远程终端协议
SMTP：简单邮件传输协议
POP3：邮件读取协议
- 表示层：将数据以特定形式表现，如：加密
- 会话层：将应用的会话同步
- 传输层：实现端与端之间的传输
TCP：传输控制协议
UDP：用户数据包协议
- 网络层：负责将源和终点建立连接
IP：网际协议
ICMP、IGMP 协议
- 数据链路层：为同一链路的主机提供数据传输服务
RIP：路由信息协议
OSPF：内部网关协议
- 物理层：数据以比特流形式传输
PPP：点对点协议
HDLC：高级数据链路控制协议
TCP/IP 四层模型：
- 应用层：
- 传输层：
- 网络层：
- 网络接口层
五层模型：
- 应用层：
- 传输层：
- 网络层
- 数据链路层：
- 物理层
HTTP请求结构：请求方式+请求URL+协议及其版本
HTTP响应结构：状态码+原因短语+协议及其版本
三次握手：
- 第一次握手：客户端将标志位SYN置为1，随机产生一个值sep=x，并将该数据包发送给服务端，客户端进入SYN_SENT状态，等待服务端确认；
- 第二次握手：服务端收到数据报后由标志位SYN=1知道客户端请求建立连接，服务端将标志位SYN和ACK都置为1，ack=x+1，随机产生一个值seq=y，并将该数据包发送给客户端以确认连接请求，服务器进入SYN_RCVD状态；
- 第三次握手：客户端收到确认后，检查ack是否为x+1,ACK是否为1，如果正确则将标志位ACK置为1，ack=y+1，并将该数据包发送给服务端，服务端检查ack是否为k+1，ACK是否为1，如果正确则连接建立成功。此时客户端和服务端进入ESTABLISHED状态，完成三次握手，之后客户端与服务端之间就可以传输数据了。
四次挥手：
- 第一次挥手：客户端发送一个FIN，用来关闭客户端到服务端的数据发送，客户端进入FIN_WAIT_1状态；
- 第二次挥手：服务端收到FIN后，发送一个ACK给客户端，确认序号为收到序号加1，服务端进入CLOSE_WAIT状态。此时TCP处于半关闭状态，即客户端已经没有要发送的数据了，但服务端若是发送数据，客户端仍要接收；
- 第三次挥手：服务端发送一个FIN，用来关闭服务端到客户端的数据发送，服务端进入LAST_ACK状态；
- 第四次挥手：客户端收到FIN后，客户端进入TIME_WAIT状态，接着发送一个ACK给服务端，确认序号为接收到序号加1，服务端进入CLOSED状态，完成四次挥手。
Expires要求客户端和服务端的时钟严格同步。HTTP1.1引入Cache-Control来克服Expires头的限制。如果max-age和Expires同时出现，则max-age有更高的优先级。
Cache-Control:no-cache, private, max-age=0 ETag: abcde
Expires: Thu, 15 Apr 201420:00:00 GMT
Pragma: private
Last-Modified:$now //RFC1123 format
参考回答：
cache-control 是一个通用消息头字段被用于HTTP 请求和响应中，通过指定指令来实现缓存机制，这个缓存指令是单向的，常见的取值有 private、no-cache、max-age、
must-revalidate 等，默认为private。
参考回答：
XSS, 即为（Cross Site Scripting）, 中文名为跨站脚本, 是发生在目标用户的浏览器层面上的，当渲染 DOM 树的过程成发生了不在预期内执行的 JS 代码时，就发生了 XSS 攻击。大多数XSS 攻击的主要方式是嵌入一段远程或者第三方域上的 JS 代码。实际上是在目标网站的作用域下执行了这段 JS 代码。
CSRF（Cross Site Request Forgery，跨站请求伪造），字面理解意思就是在别的站点伪造了一个请求。专业术语来说就是在受害者访问一个网站时，其 Cookie 还没有过期的情况下，攻击者伪造一个链接地址发送受害者并欺骗让其点击，从而形成 CSRF 攻击。XSS 防御的总体思路是：对输入(和URL 参数)进行过滤，对输出进行编码。也就是对提交的所有内容进行过滤，对 url 中的参数进行过滤，过滤掉会导致脚本执行的相关内容； 然后对动态输出到页面的内容进行 html 编码，使脚本无法在浏览器中执行。虽然对输入过滤可以被绕过，但是也还是会拦截很大一部分的XSS 攻击。
防御CSRF 攻击主要有三种策略：验证 HTTP Referer 字段；在请求地址中添加 token 并验证；在 HTTP 头中自定义属性并验证。
1）我们在网页中的某个操作（有的操作对应多个事件）。例如：当我们点击一个按钮就会产生一个事 件。是可以被 JavaScript 侦测到的行为。
2）事件处理机制：IE是事件冒泡、firefox同时支持两种事件模型，也就是：捕获型事件和冒泡型事件。；
3）ev.stopPropagation() ;注意旧ie的方法ev.cancelBubble = true ;
调用localstorge、cookies等本地存储方式
IE支持currentStyle，FIrefox使用getComputStyle IE 使用innerText，Firefox使用textContent
滤镜方面：IE:filter:alpha(opacity= num)；Firefox：-moz-opacity:num
事件方面：IE：attachEvent：火狐是addEventListener 鼠标位置：IE是event.clientX；火狐是event.pageX
IE使用event.srcElement；Firefox使用event.target
IE中消除list的原点仅需margin:0即可达到最终效果；FIrefox需要设置margin:0;padding:0以及list-
style:none
CSS圆角：ie7以下不支持圆角
Javascript数据推送
Commet：基于HTTP长连接的服务器推送技术基于WebSocket的推送方案
SSE（Server-Send Event）：服务器推送数据新方式
当发送一个服务器请求时，浏览器首先会进行缓存过期判断。浏览器根据缓存过期时间判断缓存文件是 否过期。
情景一：若没有过期，则不向服务器发送请求，直接使用缓存中的结果，此时我们在浏览器控制台中可 以看到 200 OK(from cache) ，此时的情况就是完全使用缓存，浏览器和服务器没有任何交互的。
情景二：若已过期，则向服务器发送请求，此时请求中会带上①中设置的文件修改时间，和Etag
然后，进行资源更新判断。服务器根据浏览器传过来的文件修改时间，判断自浏览器上一次请求之后， 文件是不是没有被修改过；根据Etag，判断文件内容自上一次请求之后，有没有发生变化
情形一：若两种判断的结论都是文件没有被修改过，则服务器就不给浏览器发index.html的内容了，直接告诉它，文件没有被修改过，你用你那边的缓存吧—— 304 Not Modified，此时浏览器就会从本地缓存中获取index.html的内容。此时的情况叫协议缓存，浏览器和服务器之间有一次请求交互。
情形二：若修改时间和文件内容判断有任意一个没有通过，则服务器会受理此次请求，之后的操作同①
① 只有get请求会被缓存，post请求不会
Etag由服务器端生成，客户端通过If-Match或者说If-None-Match这个条件判断请求来验证资源是否修 改。常见的是使用If-None-Match。请求一个文件的流程可能如下：
====第一次请求===
1.客户端发起 HTTP GET 请求一个文件；
2.服务器处理请求，返回文件内容和一堆Header，当然包括Etag(例如”2e681a-6-5d044840”)(假设服务器支持Etag生成和已经开启了Etag).状态码200
====第二次请求===
客户端发起 HTTP GET 请求一个文件，注意这个时候客户端同时发送一个If-None-Match头，这个头的内容就是第一次请求时服务器返回的Etag：2e681a-6-5d0448402.服务器判断发送过来的Etag和计算出 来的Etag匹配，因此If-None-Match为False，不返回200，返回304，客户端继续使用本地缓存；流程很 简单，问题是，如果服务器又设置了Cache-Control:max-age和Expires呢，怎么办
答案是同时使用，也就是说在完全匹配If-Modified-Since和If-None-Match即检查完修改时间和Etag之后，
服务器才能返回304.(不要陷入到底使用谁的问题怪圈)
Etag 主要为了解决 Last-Modified 无法解决的一些问题。
渐进增强 ：针对低版本浏览器进行构建页面，保证最基本的功能，然后再针对高级浏览器进行效果、交互等改进和追加功能达到更好的用户体验。
优雅降级 ：一开始就构建完整的功能，然后再针对低版本浏览器进行兼容。
sql注入原理
就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。
总的来说有以下几点：
1）永远不要信任用户的输入，要对用户的输入进行校验，可以通过正则表达式，或限制长度，对单引 号和双”-“进行转换等。
2）永远不要使用动态拼装SQL，可以使用参数化的SQL或者直接使用存储过程进行数据查询存取。
3）永远不要使用管理员权限的数据库连接，为每个应用使用单独的权限有限的数据库连接。
4）不要把机密信息明文存放，请加密或者hash掉密码和敏感的信息。
Xss(cross-site scripting)攻击指的是攻击者往Web页面里插入恶意 html标签或者javascript代码。比如：攻击者在论坛中放一个
看似安全的链接，骗取用户点击后，窃取cookie中的用户私密信息；或者攻击者在论坛中加一个恶意表单，
当用户提交表单的时候，却把信息传送到攻击者的服务器中，而不是用户原本以为的信任站点。
XSS防范方法
首先代码里对用户输入的地方和变量都需要仔细检查长度和对”<”,”>”,”;”,”’”等字符做过滤；其次任何内容 写到页面之前都必须加以encode，避免不小心把html tag 弄出来。这一个层面做好，至少可以堵住超过一半的XSS 攻击。
首先，避免直接在cookie 中泄露用户隐私，例如email、密码等等。
其次，通过使cookie 和系统ip 绑定来降低cookie 泄露后的危险。这样攻击者得到的cookie 没有实际价值，不可能拿来重放。
如果网站不需要再浏览器端对cookie 进行操作，可以在Set-Cookie 末尾加上HttpOnly 来防止javascript 代码直接获取cookie 。
尽量采用POST 而非GET 提交表单
XSS是获取信息，不需要提前知道其他用户页面的代码和数据包。CSRF是代替用户完成指定的动作，需要知道其他用户页面的代码和数据包。
要完成一次CSRF攻击，受害者必须依次完成两个步骤： 登录受信任网站A，并在本地生成Cookie。
在不登出A的情况下，访问危险网站B。
CSRF的防御
服务端的CSRF方式方法很多样，但总的思想都是一致的，就是在客户端页面增加伪随机数。通过验证码的方法
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的连接是持久的，他通过在客户端和服务器之间保持双工连接，服务器的更新可以被及时推送给客户端，而不需要客户端以一定时间间隔去轮询。
CSRF攻击
CSRF即Cross-site request forgery(跨站请求伪造)，是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。
假如黑客在自己的站点上放置了其他网站的外链，例如”www.weibo.com/api，默认情况下，浏览器会带着weibo.com的cookie访问这个网址，如果用户已登录过该网站且网站没有对CSRF攻击进行防御，那么服务器就会认为是用户本人在调用此接口并执行相关操作，致使账号被劫持。
如何防御CSRF攻击
验证Token：浏览器请求服务器时，服务器返回一个token，每个请求都需要同时带上token和cookie才会被认为是合法请求
验证Referer：通过验证请求头的Referer来验证来源站点，但请求头很容易伪造
设置SameSite：设置cookie的SameSite，可以让cookie不随跨域请求发出，但浏览器兼容不一
xss攻击
XSS即Cross Site Scripting（跨站脚本攻击），指的是通过利用网页开发时留下的漏洞，注入恶意指令代码到网页，使用户加载并执行攻击者恶意制造的网页程序。常见的例如在评论区植入JS代码，用户进入评论页时代码被执行，造成页面被植入广告、账号信息被窃取
XSS攻击有哪些类型
存储型：即攻击被存储在服务端，常见的是在评论区插入攻击脚本，如果脚本被储存到服务端，那么所有看见对应评论的用户都会受到攻击。
反射型：攻击者将脚本混在URL里，服务端接收到URL将恶意代码当做参数取出并拼接在HTML里返回，浏览器解析此HTML后即执行恶意代码
DOM型：将攻击脚本写在URL中，诱导用户点击该URL，如果URL被解析，那么攻击脚本就会被运行。和前两者的差别主要在于DOM型攻击不经过服务端
如何防御XSS攻击
输入检查：对输入内容中的
// 向服务器test.com发出请求，该请求的查询字符串有一个callback参数，用来指定回调函数的名字
// 处理服务器返回回调函数的数据
jQuery ajax
$.ajax({
url: ‘http://www.test.com:8080/login’,
type: ‘get’,
dataType: ‘jsonp’, // 请求方式为jsonp
jsonpCallback: “handleCallback”, // 自定义回调函数名
data: {}
});
vue-resource
this.$http.jsonp(‘http://www.domain2.com:8080/login’, {
params: {},
jsonp: ‘handleCallback’
}).then((res) => {
console.log(res);
})
4.cors
CORS 是跨域资源分享（Cross-Origin Resource Sharing）的缩写。它是 W3C 标准，属于跨源 AJAX 请求的根本解决方法。
1、普通跨域请求：只需服务器端设置Access-Control-Allow-Origin
2、带cookie跨域请求：前后端都需要进行设置,前端设置根据xhr.withCredentials字段判断是否带有cookie
原生ajax
var xhr = new XMLHttpRequest(); // IE8/9需用window.XDomainRequest兼容
// 前端设置是否带cookie
xhr.withCredentials = true;
xhr.open(‘post’, ‘http://www.domain2.com:8080/login’, true);
xhr.setRequestHeader(‘Content-Type’, ‘application/x-www-form-urlencoded’);
xhr.send(‘user=admin’);
xhr.onreadystatechange = function() {
if (xhr.readyState == 4 && xhr.status == 200) {
alert(xhr.responseText);
}
};
jQuery ajax
$.ajax({
url: ‘http://www.test.com:8080/login’,
type: ‘get’,
data: {},
xhrFields: {
withCredentials: true // 前端设置是否带cookie
},
crossDomain: true, // 会让请求头中包含跨域的额外信息，但不会含cookie
});
vue-resource
Vue.http.options.credentials = true
axios
axios.defaults.withCredentials = true
原因是浏览器会自动带上cookie，而token需要设置header才可
xss: 用户通过各种方式将恶意代码注入到其他用户的页面中。就可以通过脚本劫持cookie或者localStorage等信息，发起请求，之类的操作。从而伪造用户身份相关信息。前端层面token会存在哪儿？不外乎cookie localStorage sessionStorage,这些东西都是通过js代码获取到的。解决方案：过滤标签<>,不信任用户输入， 对用户身份等cookie层面的信息进行http-only处理。
csxf：跨站请求攻击，简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去运行。这利用了web中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。csrf并不能够拿到用户的任何信息，它只是欺骗用户浏览器，让其以用户的名义进行操作。。解决方案也很简单，对于cookie不信任，对每次请求都进行身份验证，比如token的处理。
被xss攻击了，不管是token还是cookie，都能被拿到，所以对于xss攻击来说，cookie和token没有什么区别。但是对于csrf来说就有区别了。
cookie：用户点击了链接，cookie未失效，导致发起请求后后端以为是用户正常操作，于是进行扣款操作。
token：用户点击链接，由于浏览器不会自动带上token，所以即使发了请求，后端的token验证不会通过，所以不会进行扣款操作。
两者的区别：
- （1）MAC地址是物理地址，IP地址是逻辑地址；MAC地址是固定不可改变的，IP地址可以改变；
- （2）MAC地址具有唯一性，每一个硬件出厂的时候MAC地址就固定了；而IP地址的应用后才分配的，不具备唯一性；
- （3）工作层次不同：数据链路层基于MAC地址转发数据帧，网络层基于IP地址转发报文；
- （4）MAC地址是EtherNet网卡上带的地址，长度为48位；IP地址目前主流是32位长。
出现粘包的原因：
- （1）发送方的原因：发送端需要等缓冲区满了才发出去，造成粘包；
- （2）接收方的原因：接收方不及时接收缓冲区的数据包，然后多个包同时接收造成粘包。
粘包问题的解决：
- （1）格式化数据：每条数据有固定的格式（开始符，结束符），根据开始符和结束符进行拆包，但选择开始符合结束符的时候一定要注意每条数据的内部一定不能出现开始符或结束符；
- （2）发送长度：发送每条数据的时候，将数据的长度一并发送，处理时可以根据长度来判断每条数据的开始和结束。