TCP/IP四层协议,http请求方式get和post对比,Python中的Django框架,Flask框架和Tornado框架对比介绍

1. TCP/IP四层协议模型

1、数据链路层

   功能:实现了网卡接口的网络驱动程序,以处理数据在物理媒介(如以太网、令牌环等)上的传输。

   对应设备:网线、网桥、集线器、交换机

   常用协议:

(1)ARP(地址解析协议):它实现IP地址到物理地址(通常是MAC地址,通俗的理解就是网卡地址)的转换。

(2)RARP(逆地址解析协议):顾名思义,它和ARP是相反的,它是实现从物理地址到IP地址的转换。

ARP用途:网络层使用IP地址寻找一台机器,而数据链路层则是使用物理地址寻找一台机器,因此网络层必须先将目标机器的IP地址转化成物理地址,才能使用数据链路层提供的服务。

RARP用途:RARP协议仅用于网络上的某些无盘工作站,因为缺少储存设备,无盘工作站无法记录自己的IP地址,然而通过RARP就可以看到从物理地址到IP地址的映射。

2、网络层

  功能:实现数据包的选路和转发。

  对应设备:路由器

  常用协议:

(1)IP协议(英特网协议)根据数据包的目的IP地址来决定如何将它发送给目标主机。如果数据包不能直接发送给目标主机,那么IP协议为它寻找一个合适的下一跳路由器,将数据包交给路由器来转发,多次之后数据包将到达目标主机,或者因发送失败而被丢弃。

 (2)ICMP协议是网络层的另一个重要协议,它是IP协议的重要补充,主要用于检测网络连接。

3、传输层

  功能:为两台主机上的应用程序提供端到端的通信。与网络层使用的逐跳通信方式不同,传输层只关心通信的起始端和目的端,而不在乎数据包的中转过程。

主要协议:

(1)TCP协议(传输控制协议):为应用层提供可靠的、面向连接的和流式服务。

(2)UDP协议(用户数据报协议):为应用层提供不可靠的、无连接的和数据报服务。(TCP和UDP协议的详解见https://blog.csdn.net/weixin_43215948/article/details/106966135

(3)SCTP协议(流控制传输协议)它是为在英特网上传输电话信号而设计的,这里不再细说。

4、应用层

 功能:负责处理应用程序的逻辑,比如文件传输,名称查询和网络管理等。

注意:数据链路层、网络层、传输层复制处理网络通信 细节,所以这些部分必须稳定且高效,因此它们都在内核空间实现,而应用层在用户空间中实现,因为它负责众多逻辑,在内核中实现的话,则会使内核变得非常庞大。也有少数服务器程序是在内核中实现,这样代码就不用在用户空间和内核空间中来回切换(主要是数据的复制)提高了工作效率。

常用协议:

(1)OSPF(开放最短路径优先)协议:是一种动态路由更新协议,用于路由器之间的通信,以告知对方各自的路由信息。

(2)DNS(域名服务)协议:提供机器域名到IP地址的转换。(如将www.baidu.com转化成百度的IP,输入域名就直接可以进入。因为IP地址记的时候太麻烦,就像每个人都是由身份证唯一标识的,但为了好记就起了名字。DNS就是一个将姓名与身份证对应的过程)

(3)telnet协议是一种远程登陆协议,使我们能在本地完成远程任务。

(4)HTTP协议(超文本传输协议)是一个基于请求与响应模式的、无状态的、应用层的协议,常基于TCP的连接方式。

2. TCP三次握手,四次分手,以及为什么?

具体过程如下:

第一次握手:建立连接。客户端发送连接请求报文段,并将syn(标记位)设置为1,Squence Number(数据包序号)(seq)为x,接下来等待服务端确认,客户端进入SYN_SENT状态(请求连接);

第二次握手:服务端收到客户端的 SYN 报文段,对 SYN 报文段进行确认,设置 ack(确认号)为 x+1(即seq+1 ; 同时自己还要发送 SYN 请求信息,将 SYN 设置为1, seq为 y。服务端将上述所有信息放到 SYN+ACK 报文段中,一并发送给客户端,此时服务器进入 SYN_RECV状态。(SYN_RECV是指,服务端被动打开后,接收到了客户端的SYN并且发送了ACK时的状态。再进一步接收到客户端的ACK就进入ESTABLISHED状态。)

第三次握手:客户端收到服务端的 SYN+ACK(确认符) 报文段;然后将 ACK 设置为 y+1,向服务端发送ACK报文段,这个报文段发送完毕后,客户端和服务端都进入ESTABLISHED(连接成功)状态,完成TCP 的三次握手。

第一次挥手:客户端设置seq和 ACK ,向服务器发送一个 FIN(终结)报文段。此时,客户端进入 FIN_WAIT_1 状态,表示客户端没有数据要发送给服务端了。

第二次挥手:服务端收到了客户端发送的 FIN 报文段,向客户端回了一个 ACK 报文段。

第三次挥手:服务端向客户端发送FIN 报文段,请求关闭连接,同时服务端进入 LAST_ACK 状态。

第四次挥手:客户端收到服务端发送的 FIN 报文段后,向服务端发送 ACK 报文段,然后客户端进入 TIME_WAIT 状态。服务端收到客户端的 ACK 报文段以后,就关闭连接。此时,客户端等待 2MSL(指一个片段在网络中最大的存活时间)后依然没有收到回复,则说明服务端已经正常关闭,这样客户端就可以关闭连接了。

注意:如果有大量的连接,每次在连接,关闭都要经历三次握手,四次挥手,这显然会造成性能低下。因此。Http 有一种叫做 长连接(keepalive connections) 的机制。它可以在传输数据后仍保持连接,当客户端需要再次获取数据时,直接使用刚刚空闲下来的连接而无需再次握手。

常见的一些关于3次握手4次挥手的问题

问题1:为什么要3次握手?

为了防止已失效的连接请求报文突然又传送到了服务端,因为产生错误。

具体解释: “已失效的连接请求报文段”产生情况:

client 发出的第一个连接请求报文段并没有丢失,而是在某个网络节点长时间滞留,因此导致延误到连接释放以后的某个时间才到达 service。如果没有三次握手,那么此时server收到此失效的连接请求报文段,就误认为是 client再次发出的一个新的连接请求,于是向 client 发出确认报文段,同意建立连接,而此时 client 并没有发出建立连接的情况,因此并不会理会服务端的响应,而service将会一直等待client发送数据,因此就会导致这条连接线路白白浪费。

如果此时变成两次挥手行不行?

这个时候需要明白全双工与半双工,再进行回答。比如:

第一次握手: A给B打电话说,你可以听到我说话吗?
第二次握手: B收到了A的信息,然后对A说: 我可以听得到你说话啊,你能听得到我说话吗?
第三次握手: A收到了B的信息,然后说可以的,我要给你发信息啦!
在三次握手之后,A和B都能确定这么一件事: 我说的话,你能听到; 你说的话,我也能听到。 这样,就可以开始正常通信了,如果是两次,那将无法确定。
问题2:为什么要四次挥手?

TCP 协议是一种面向连接,可靠,基于字节流的传输层通信协议。TCP 是全双工模式(同一时刻可以同时发送和接收),这就意味着,当主机1发出 FIN 报文段时,只是表示主机1已结没有数据要发送了,主机1告诉主机2,它的数据已经全部发送完毕;但是,这个时候主机1还是可以接受来自主机2的数据;当主机2返回 ACK报文段时,这个时候就表示主机2也没有数据要发送了,就会告诉主机1,我也没有数据要发送了,之后彼此就会中断这次TCP连接。
问题3:为什么要等待 2MSL?

MSL:报文段最大生存时间,它是任何报文段被丢弃前在网络内的最长时间

原因如下:

保证TCP协议的全双工连接能够可靠关闭
保证这次连接的重复数据从网络中消息

3. HTTP的请求方式GET和POST有什么区别?


4. Django框架,Flask框架和Tornado框架各有什么优缺点?为什么你的项目会选择使用Django框架?

  • Django:Python 界最全能的 web 开发框架,battery-include 各种功能完备,可维护性和开发速度一级棒。常有人说 Django 慢,其实主要慢在 Django ORM 与数据库的交互上,所以是否选用 Django,取决于项目对数据库交互的要求以及各种优化。而对于 Django 的同步特性导致吞吐量小的问题,其实可以通过 Celery 等解决,倒不是一个根本问题。Django 的项目代表:Instagram,Guardian。

  • Tornado:天生异步,性能强悍是 Tornado 的名片,然而 Tornado 相比 Django 是较为原始的框架,诸多内容需要自己去处理。当然,随着项目越来越大,框架能够提供的功能占比越来越小,更多的内容需要团队自己去实现,而大项目往往需要性能的保证,这时候 Tornado 就是比较好的选择。Tornado项目代表:知乎。

  • Flask:微框架的典范,号称 Python 代码写得最好的项目之一。Flask 的灵活性,也是双刃剑:能用好 Flask 的,可以做成 Pinterest,用不好就是灾难(显然对任何框架都是这样)。Flask 虽然是微框架,但是也可以做成规模化的 Flask。加上 Flask 可以自由选择自己的数据库交互组件(通常是 Flask-SQLAlchemy),而且加上 celery +redis 等异步特性以后,Flask 的性能相对 Tornado 也不逞多让,也许Flask 的灵活性可能是某些团队更需要的。

一、Django

主要特点是大而全,集成了很多组件,例如: Models Admin Form 等等, 不管你用得到用不到,反正它全都有,属于全能型框架

优点:

  • 大和全(重量级框架)
  • 自带orm,template,view
  • 需要的功能也可以去找第三方的app
  • 注重高效开发
  • 全自动化的管理后台(只需要使用起ORM,做简单的定义,就能自动生成数据库结构,全功能的管理后台)
  • session功能

缺点:

  • template不怎么好用(来自自身的缺点)
  • 数据库用nosql不方便(来自自身的缺点)
  • 如果功能不多,容易臃肿

二、Torando

主要特点是原生异步非阻塞,在IO密集型应用和多任务处理上占据绝对性的优势,属于专注型框架

优点:

  • 少而精(轻量级框架)
  • 注重性能优越,速度快
  • 解决高并发(请求处理是基于回调的非阻塞调用)
  • 异步非阻塞
  • websockets 长连接
  • 内嵌了HTTP服务器
  • 单线程的异步网络程序,默认启动时根据CPU数量运行多个实例;利用CPU多核的优势
  • 自定义模块

缺点:

  • 模板和数据库部分有很多第三方的模块可供选择,这样不利于封装为一个功能模块

三、Flask

主要特点小而轻,原生组件几乎为0, 三方提供的组件请参考Django 非常全面,属于短小精悍型框架

优点:

  • 简单,Flask的路由以及路由函数由修饰器设定,开发人员不需要借助其他文件匹配;
  • 配置灵活,有多种方法配置,不同环境的配置也非常方便;环境部署简单,Flask运行不需要借助其他任何软件,只需要安装了Python的IDE,在命令行运行即可。只需要在Python中导入相应包即可满足所有需求;
  • 入门简单,通过官方指南便可以清楚的了解Flask的运行流程;
  • 低耦合,Flask可以兼容多种数据库、模板。

缺点:

  • 对于大型网站开发,需要设计路由映射的规则,否则导致代码混乱

5. 什么是ORM?有什么优势?

 对象关系映射(Object Relational Mapping,简称ORM)模式是一种为了解决面向对象与关系数据库存在的互不匹配的现象的技术。简单的说,ORM是通过使用描述对象和数据库之间映射的元数据,将程序中的对象自动持久化到关系数据库中。

 ORM技术特点: 
        1.提高了开发效率。由于ORM可以自动对Entity对象与数据库中的Table进行字段与属性的映射,所以我们实际可能已经不需要一个专用的、庞大的数据访问层。 
        2.ORM提供了对数据库的映射,不用sql直接编码,能够像操作对象一样从数据库获取数据。 

 ORM的方法论基于三个核心原则: 
  · 简单:以最基本的形式建模数据。 
  · 传达性:数据库结构被任何人都能理解的语言文档化。 
  · 精确性:基于数据模型创建正确标准化了的结构。 
6. migrations和migrate有什么区别?

迁移机制有两个指令,感觉像是模型和服务器之间的中转站

(1)makemigrations

生成迁移代码的makemigrations指令是用模型里面的模型和当前的迁移代码里面的模型做对比,如果有新的修改,就生成新的迁移代码,

(2)migrate

migrate指令是用于迁移目录中间代码文件和Django的数据库django_migrations表中的代码文件做对比如果表中没有那就对这些没有文件按顺序和依赖关系做迁移应用然后再把代码文件名加进迁移表中。

也就是说,在改动models.py的内容之后执行:   python manger.py makemigrations 

会在该应用下会建立migrations目录,并记录modes.py的改动,但是这个改动还没有作用到数据库文件

直到你执行:python manager.py migrate才会改动数据库


7. Django的请求生命周期是什么?

Django的请求生命周期是指:当用户在浏览器上输入url到用户看到网页的这个时间段内,Django后台所发生的事情。

过程:第一步:浏览器发起请求
第二步:WSGI创建socket服务端,接收请求(Httprequest)
第三步:中间件处理请求
第四步:url路由,根据当前请求的URL找到视图函数
第五步:view视图,进行业务处理(ORM处理数据,从数据库取到数据返回给view视图;view视图将数据渲染到template模板;将数据返回)
第六步:中间件处理响应
第七步:WSGI返回响应(HttpResponse)
第八步:浏览器渲染

8. csrf跨站请求伪造是什么?如何防止?

CSRF,全称为Cross-Site Request Forgery,跨站请求伪造,是一种网络攻击方式,它可以在用户毫不知情的情况下,以用户的名义伪造请求发送给被攻击站点,从而在未授权的情况下进行权限保护内的操作。具体来讲,可以这样理解CSRF。攻击者借用用户的名义,向某一服务器发送恶意请求,对服务器来讲,这一请求是完全合法的,但攻击者确完成了一个恶意操作,比如以用户的名义发送邮件,盗取账号,购买商品等等。

解决方法:

服务器端表单hash认证;验证http Referer字段;在HTTP头中自定义属性并验证;

猜你喜欢

转载自blog.csdn.net/weixin_43215948/article/details/107558220