和前俩篇一样，有些还是需要你自己整理话述
1.TCP的三次握手
第一次握手：建立连接。客户端发送连接请求报文段，将SYN位置为1，Sequence Number为x；然后，客户端进入SYN_SEND状态，等待服务器的确认
第二次握手：服务器收到SYN报文段。服务器收到客户端的SYN报文段，需要对这个SYN报文段进行确认，设置Acknowledgment Number为x+1(Sequence Number+1)；同时，自己自己还要发送SYN请求信息，将SYN位置为1，Sequence Number为y；服务器端将上述所有信息放到一个报文段（即SYN+ACK报文段）中，一并发送给客户端，此时服务器进入SYN_RECV状态
第三次握手：客户端收到服务器的SYN+ACK报文段。然后将Acknowledgment Number设置为y+1，向服务器发送ACK报文段，这个报文段发送完毕以后，客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手。
完成了三次握手，客户端和服务器端就可以开始传送数据。以上就是TCP简单的三次握手的介绍。
其实在说的当中，完全可以配合着画图。因为在网络协议这块儿，有图的配合是最好的，下边的同理
2.TCP的四次挥手
当客户端和服务器通过三次握手建立了TCP连接以后，当数据传送完毕，肯定是要断开TCP连接
那对于TCP的断开连接，这里就有了“四次挥手”
先由客户端向服务器端发送一个FIN，请求关闭数据传输。
当服务器接收到客户端的FIN时，向客户端发送一个ACK，其中ack的值等于FIN+SEQ
然后服务器向客户端发送一个FIN，告诉客户端应用程序关闭。
当客户端收到服务器端的FIN是，回复一个ACK给服务器端。
其中ack的值等于FIN+SEQ
可以聊聊TCP和UDP的区别。
3.get和post区别
GET在浏览器回退时是无害的，而POST会再次提交请求。
GET产生的URL地址可以被Bookmark，而POST不可以。
GET请求会被浏览器主动cache，而POST不会，除非手动设置。
GET请求只能进行url编码，而POST支持多种编码方式。
GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
GET请求在URL中传送的参数是有长度限制的，而POST没有。
对参数的数据类型，GET只接受ASCII字符，而POST没有限制。
GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
GET参数通过URL传递，POST放在Request body中。
网上还有很多介绍，可以去看看这个地址HTTP 中 GET 与 POST 的区别
4.简述MVC模式和MVT模式
这里谈的是开发模式，还有设计模式之后再说。千万别把 设计模式 和 开发模式 这俩个混为一谈
所谓MVC就是把Web应用分为模型(M)，控制器©和视图(V)三层,他们之间以一种插件式的、松耦合的方式连接在一起，模型负责业务对象与数据库的映射(ORM)，视图负责与用户的交互(页面)，控制器接受用户的输入调用模型和视图完成用户的请求
Django的MTV模式本质上和MVC是一样的，也是为了各组件间保持松耦合关系，只是定义上有些许不同，Django的MTV分别是值：
M 代表模型（Model）： 负责业务对象和数据库的关系映射(ORM)。
T 代表模板 (Template)：负责如何把页面展示给用户(html)。
V 代表视图（View）： 负责业务逻辑，并在适当时候调用Model和Template。
除了以上三层之外，还需要一个URL分发器，它的作用是将一个个URL的页面请求分发给不同的View处理，View再调用相应的Model和Template
这个也可以配合讲解流程图（你自己画）来说。
5.Django 、Flask、Tornado的对比
1.Django走的是大而全的方向,开发效率高。它的MTV框架,自带的ORM,admin后台管理,自带的sqlite数据库和开发测试用的服务器 给开发者提高了超高的开发效率
2.Flask是轻量级的框架,自由,灵活,可扩展性很强,核心基于Werkzeug WSGI工具和jinja2模板引擎
3.Tornado走的是少而精的方向,性能优越。它最出名的是异步非阻塞的设计方式
Tornado的两大核心模块：
1.iostraem：对非阻塞式的socket进行简单的封装
2.ioloop：对I/O多路复用的封装，它实现了一个单例
这三个对比，自己看这说，不用说太多。
6.Django请求的生命周期
1.wsgi,请求封装后交给web框架 （Flask、Django）
2.中间件，对请求进行校验或在请求对象中添加其他相关数据，例如：csrf、request.session
3.路由匹配 根据浏览器发送的不同url去匹配不同的视图函数
4.视图函数，在视图函数中进行业务逻辑的处理，可能涉及到：orm、templates => 渲染
5.中间件，对响应的数据进行处理。
6.wsgi,将响应的内容发送给浏览器
7.说一下Django，MIDDLEWARES中间件的作用和应用场景？
中间件是介于request与response处理之间的一道处理过程,用于在全局范围内改变Django的输入和输出。
简单的来说中间件是帮助我们在视图函数执行之前和执行之后都可以做一些额外的操作
例如：
1.Django项目中默认启用了csrf保护,每次请求时通过CSRF中间件检查请求中是否有正确#token值
2.当用户在页面上发送请求时，通过自定义的认证中间件，判断用户是否已经登陆，未登陆就去登陆。
3.当有用户请求过来时，判断用户是否在白名单或者在黑名单里
其内置的五个方法:
1.process_request : 请求进来时,权限认证
2.process_view : 路由匹配之后,能够得到视图函数
3.process_exception : 异常时执行
4.process_template_responseprocess : 模板渲染时执行
5.process_response : 请求有响应时执行
8.谈谈你对restful规范的认识？
首先restful是一种软件架构风格或者说是一种设计风格，并不是标准，它只是提供了一组设计原则和约束条件，主要用于客户端和服务器交互类的软件。
就像设计模式一样，并不是一定要遵循这些原则，而是基于这个风格设计的软件可以更简洁，更有层次，我们可以根据开发的实际情况，做相应的改变。
它里面提到了一些规范，例如：
1、restful 提倡面向资源编程,在url接口中尽量要使用名词，不要使用动词
2、在url接口中推荐使用Https协议，让网络接口更加安全 https://baidum/v1/mycss？page=3
（Https是Http的安全版，即HTTP下加入SSL层，HTTPS的安全基础是SSL， 因此加密的详细内容就需要SSL（安全套接层协议））
3、在url中可以体现版本号 https://v1.bootcss.com/mycss 不同的版本可以有不同的接口，使其更加简洁，清晰
4、url中可以体现是否是API接口 https://baidum/api/mycss
5、url中可以添加条件去筛选匹配
https://baidum/v1/mycss？page=3
6、可以根据Http不同的method，进行不同的资源操作 （5种方法：GET
/ POST / PUT / DELETE / PATCH）
7、响应式应该设置状态码
8、有返回值，而且格式为统一的json格式
9、返回错误信息
10、返回结果中要提供帮助链接，即API最好做到接口文档
9.HTTP 与 HTTPS 的区别
HTTP（HyperText Transfer Protocol：超文本传输协议）是一种用于分布式、协作式和超媒体信息系统的应用层协议。 简单来说就是一种发布和接收 HTML 页面的方法，被用于在 Web 浏览器和网站服务器之间传递信息。HTTP 默认工作在 TCP 协议 80 端口，用户访问网站 http:// 打头的都是标准 HTTP 服务。HTTP 协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此，HTTP协议不适合传输一些敏感信息，比如：信用卡号、密码等支付信息。
HTTPS（Hypertext Transfer Protocol Secure：超文本传输安全协议）是一种透过计算机网络进行安全通信的传输协议。HTTPS 经由 HTTP 进行通信，但利用 SSL/TLS 来加密数据包。HTTPS 开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。HTTPS 默认工作在 TCP 协议443端口，它的工作流程一般如以下方式：1、TCP 三次同步握手2、客户端验证服务器数字证书3、DH 算法协商对称加密算法的密钥、hash 算法的密钥4、SSL 安全加密隧道协商完成5、网页以加密的方式传输，用协商的对称加密算法和密钥加密，保证数据机密性；用协商的hash算法进行数据完整性保护，保证数据不被篡改。
区别：
HTTP 明文传输，数据都是未加密的，安全性较差，HTTPS（SSL+HTTP） 数据传输过程是加密的，安全性较好。
使用 HTTPS 协议需要到 CA（Certificate Authority，数字证书认证机构） 申请证书，一般免费证书较少，因而需要一定费用。证书颁发机构如：Symantec、Comodo、GoDaddy 和 GlobalSign 等。
HTTP 页面响应速度比 HTTPS 快，主要是因为 HTTP 使用 TCP 三次握手建立连接，客户端和服务器需要交换 3 个包，而 HTTPS除了 TCP 的三个包，还要加上 ssl 握手需要的 9 个包，所以一共是 12 个包。
http 和 https 使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443。
HTTPS 其实就是建构在 SSL/TLS 之上的 HTTP 协议，所以，要比较 HTTPS 比 HTTP 要更耗费服务器资源。
10.websocket
WebSocket是HTML5下一种新的协议。它实现了浏览器与服务器全双工通信，能更好的节省服务器资源和带宽并达到实时通讯的目的。
它与HTTP一样通过已建立的TCP连接来传输数据，但是它和HTTP最大不同是：WebSocket是一种双向通信协议。在建立连接后，WebSocket服务器端和客户端都能主动向对方发送或接收数据，就像Socket一样；WebSocket需要像TCP一样，先建立连接，连接成功后才能相互通信。
相对于传统HTTP每次请求-应答都需要客户端与服务端建立连接的模式，WebSocket是类似Socket的TCP长连接通讯模式。一旦WebSocket连接建立后，后续数据都以帧序列的形式传输。在客户端断开WebSocket连接或Server端中断连接前，不需要客户端和服务端重新发起连接请求。在海量并发及客户端与服务器交互负载流量大的情况下，极大的节省了网络带宽资源的消耗，有明显的性能优势，且客户端发送和接受消息是在同一个持久连接上发起，实时性优势明显。
相比HTTP长连接，WebSocket有以下特点：是真正的全双工方式，建立连接后客户端与服务器端是完全平等的，可以互相主动请求。而HTTP长连接基于HTTP，是传统的客户端对服务器发起请求的模式。HTTP长连接中，每次数据交换除了真正的数据部分外，服务器和客户端还要大量交换HTTP header，信息交换效率很低。Websocket协议通过第一个request建立了TCP连接之后，之后交换的数据都不需要发送 HTTP header就能交换数据，这显然和原有的HTTP协议有区别所以它需要对服务器和客户端都进行升级才能实现（主流浏览器都已支持HTML5）。此外还有 multiplexing、不同的URL可以复用同一个WebSocket连接等功能。这些都是HTTP长连接不能做到的。
维持连接需要监测心跳包
11.JSON Web Token
一、使用JSON Web Token的好处？
1.性能问题。
JWT方式将用户状态分散到了客户端中，相比于session，可以明显减轻服务端的内存压力。
Session方式存储用户id的最大弊病在于Session是存储在服务器端的，所以需要占用大量服务器内存， 对于较大型应用而言可能还要保存许多的状态，一般还需借助nosql和缓存机制来实现session的存储，如果是分布式应用还需session共享。
2.单点登录。
JWT能轻松的实现单点登录，因为用户的状态已经被传送到了客户端。 token 可保存自定义信息，如用户基本信息，web服务器用key去解析token，就获取到请求用户的信息了。 我们也可以配置它以便包含用户拥有的任何权限。这意味着每个服务不需要与授权服务交互才能授权用户。
3.前后端分离。
以前的传统模式下，后台对应的客户端就是浏览器，就可以使用session+cookies的方式实现登录， 但是在前后分离的情况下，后端只负责通过暴露的RestApi提供数据，而页面的渲染、路由都由前端完成。因为rest是无状态的，因此也就不会有session记录到服务器端。
4.兼容性。
支持移动设备，支持跨程序调用，Cookie 是不允许垮域访问的，而 Token 则不存在这个问题。
5.可拓展性。
jwt是无状态的，特别适用于分布式站点的单点登录（SSO）场景。 比如有3台机器（A、B、C）组成服务器集群，若session存在机器A上，session只能保存在其中一台服务器，此时你便不能访问机器B、C，因为B、C上没有存放该Session， 而使用token就能够验证用户请求合法性，并且我再加几台机器也没事，所以可拓展性好。
6.安全性。
因为有签名，所以JWT可以防止被篡改。
JWT是基于token的身份认证的方案。
json web token全称。可以保证安全传输的前提下传送一些基本的信息，以减轻对外部存储的依赖，减少了分布式组件的依赖，减少了硬件的资源。
可实现无状态、分布式的Web应用授权，jwt的安全特性保证了token的不可伪造和不可篡改。
本质上是一个独立的身份验证令牌，可以包含用户标识、用户角色和权限等信息，以及您可以存储任何其他信息（自包含）。任何人都可以轻松读取和解析，并使用密钥来验证真实性。
缺陷：
1）JWT在生成token的时候支持失效时间，但是支持的失效时间是固定的，比如说一天。 但是用户在等出的时候是随机触发的，那么我们jwt token来做这个失效是不可行的，因为jwt在初始化的时候已经定死在什么时候过期了。 采用其他方案，在redis中存储token，设置token的过期时间，每次鉴权的时候都会去延长时间
2）jwt不适合存放大量信息，信息越多token越长
12.支付宝支付流程
支付采用了RSA加密签名的安全通信机制，开发者可以通过支付宝的公钥验证消息的来源，同时使用自己的私钥进行信息加密。RSA算法及数字签名机制是服务窗平台与开发者网关安全通信的基础。
关于数字签名机制无非就是下面这四步，归根结底就是为了提高安全性，毕竟涉及钱了，马虎不得：
第一、发方首先有一个公钥/私钥对，它将要签名的报文作为一个单向散列函数的输入，产生一个定长的散列码，一般称为消息摘要。
第二、使用发放的私钥对散列码进行加密生成签名。将报文和签名一同发出去。
第三、收方用和发放一样的散列函数对报文运算生成一个散列码，同时用发放的公钥对签名进行解密。
第四、如果收方计算得到的散列码和解密的签名一致，那么说明的确是发方对报文进行了签名而且报文在途中没有被篡改。
其实可以照一张流程图，自己试着画画
13.CSRF
一.CSRF是什么？
CSRF（Cross-site request forgery），中文名称：跨站请求伪造，
也被称为：one click attack/session riding，缩写为：CSRF/XSRF。
二.CSRF可以做什么？
你这可以这么理解CSRF攻击：攻击者盗用了你的身份，以你的名义发送恶意请求。CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账…造成的问题包括：个人隐私泄露以及财产安全。
赋上文章防范CSRF跨站请求伪造
14.SQL注入
SQL注入是属于注入式攻击，这种攻击是因为在项目中没有将代码与数据(比如用户敏感数据)隔离，在读取数据的时候，错误的将数据作为代码的一部分执行而导致的。
典型的例子就是当对SQL语句进行字符串拼接的时候，直接使用未转义的用户输入内容作为变量。这时，只要在sql语句的中间做修改，比如加上drop、delete等关键字，执行之后后果不堪设想。
说到这里，那么该怎么处理这种情况呢?三个方面：
1、过滤用户输入参数中的特殊字符，降低风险。
2、禁止通过字符串拼接sql语句，要严格使用参数绑定来传入参数。
3、合理使用数据库框架提供的机制。
就比如Mybatis提供的传入参数的方式 #{}，禁止使用${}，后者相当于是字符串拼接sql，要使用参数化的语句。
总结下，就是要正确使用参数化绑定sql变量
Django中的ORM帮我们做了SQL注入，包括html注入的XSS
15.XSS
XSS：跨站脚本攻击，Cross-Site Scripting，为了和前端的css避免重名，简称为XSS，是指通过技术手段，向正常用户请求的HTML页面中插入恶意脚本，执行。
这种攻击主要是用于信息窃取和破坏等目的。比如2011年的微博XSS攻击事件，攻击者利用了微博发布功能中未对action-data漏洞做有效的过滤，在发布微博信息的时候带上了包含攻击脚本的URL，用户访问就会加载恶意脚本，导致大量用户被攻击。
关于防范XSS上，主要就是通过对用户输入的数据做过滤或者是转义，可以使用框架提供的工具类HtmlUtil。另外前端在浏览器展示数据的时候，要使用安全的API展示数据。比如使用innerText而不是innerHTML。
总结下，过滤html标签
16.celery
首先，明确为啥使用celery
Django的请求处理过程都是同步的无法实现异步任务，若要实现异步任务处理需要通过其他方式（前端的一般解决方案是ajax操作），而后台Celery就是不错的选择。倘若一个用户在执行某些操作需要等待很久才返回，这大大降低了网站的吞吐量。
celery 原理
Celery是由Python开发、简单、灵活、可靠的分布式任务队列，其本质是生产者消费者模型，生产者发送任务到消息队列，消费者负责处理任务。Celery侧重于实时操作，但对调度支持也很好，其每天可以处理数以百万计的任务。
特点：简单：熟悉celery的工作流程后，配置使用简单
高可用：当任务执行失败或执行过程中发生连接中断，celery会自动尝试重新执行任务
快速：一个单进程的celery每分钟可处理上百万个任务
灵活：几乎celery的各个组件都可以被扩展及自定制
工作原理：
任务模块Task包含异步任务和定时任务。其中，异步任务通常在业务逻辑中被触发并发往消息队列，而定时任务由Celery Beat进程周期性地将任务发往消息队列； 任务执行单元Worker实时监视消息队列获取队列中的任务执行；Woker执行完任务后将结果保存在Backend中;
消息中间件Broker
消息中间件Broker官方提供了很多备选方案，支持RabbitMQ、Redis、Amazon SQS、MongoDB、Memcached等，官方推荐RabbitMQ。
任务执行单元Worker
Worker是任务执行单元，负责从消息队列中取出任务执行，它可以启动一个或者多个，也可以启动在不同的机器节点，这就是其实现分布式的核心。
结果存储Backend
Backend结果存储官方也提供了诸多的存储方式支持：RabbitMQ、 Redis，Memcached,SQLAlchemy,
Django ORM、Apache Cassandra、Elasticsearch。
Celery管理和监控功能是通过flower组件实现的，flower组件不仅仅提供监控功能，还提供HTTP API可实现对woker和task的管理。
欢迎采阅！