OSI (Open System Interconnection 开放式系统互联)
OSI 是国际标准化组织ISO提出的概念模型,把网络通信的工作分为7层
OSI 定义了开放系统的层次结构,和各层应该负责的任务 ,以及各层之间的关系
OSI 没有具体指出怎样制定标准,只是提出制定标准的概念
OSI 并不是一个标准,而是一个在制定标准时,所使用的概念框架
巧计:物理数学—网络传输——会话表示应用
物理层
物理层,定义物理设备(电缆、光纤、无线信道等)的传输标准
比如 规定网线的类型,规定光纤的接口类型(SC、ST、FC、等等…)
网卡 属于物理层
数据链路层
物理媒体上传输的数据难免受到各种不可靠因素的影响而产生差错,数据链路层不仅要检错,而且还要纠错,数据链路层在传输数据的过程中,保证数据的完整性,正确性
交换机 属于数据链路层
协议
网络层
在 计算机网络中进行通信的两个计算机之间可能会经过很多个数据链路,也可能还要经过很多通信子网。网络层的任务就是选择合适的网间路由和交换结点, 确保数据及时传送。 在发送数据时,网络层把传输层产生的报文段或用户数据报封装成分组和包进行传送。
路由器 属于网络层
传输层
传输层,主要任务就是负责向两台主机进程之间的通信提供通用的数据传输服务。应用进程利用该服务传送应用层报文。“通用的”是指并不针对某一个特定的网络应用,而是多种应用可以使用同一个运输层服务。由于一台主机可同时运行多个线程,因此运输层有复用和分用的功能。所谓复用就是指多个应用层进程可同时使用下面运输层的服务,分用和复用相反,是运输层把收到的信息分别交付上面应用层中的相应进程。
比如 TCP/IP协议族 中的 1.TCP协议 2.UDP协议
会话层
会话层,管理应用程序之间的通信连接
表示层
表示层,保证通信语法一致
否则无法解析传递过来的数据
比如 传递加密数据时,如果对方不知道解密规则,则无法解析数据,即为通信语法的不一致
协议
应用层
应用层的任务是通过应用进程间的交互来完成特定网络应用。应用层协议定义的是应用进程间的通信和交互的规则。对于不同的网络应用需要不同的应用层协议。
应用层协议有:域名系统DNS,支持万维网应用的 HTTP协议,支持电子邮件的 SMTP协议等等。我们把应用层交互的数据单元称为报文。
从应用层开始,每层都会对数据头进行处理,最终通过物理层将数据发出
对方接收后,反方向解析头部,将数据分离出来
ISO制定的OSI参考模型的过于庞大、复杂招致了许多批评。与此对照,由技术人员自己开发的TCP/IP协议栈获得了更为广泛的应用。
数据链路层
物理媒体上传输的数据难免受到各种不可靠因素的影响而产生差错,数据链路层不仅要检错,而且还要纠错,数据链路层在传输数据的过程中,保证数据的完整性,正确性
交换机 属于数据链路层
网络层
在 计算机网络中进行通信的两个计算机之间可能会经过很多个数据链路,也可能还要经过很多通信子网。网络层的任务就是选择合适的网间路由和交换结点, 确保数据及时传送。 在发送数据时,网络层把传输层产生的报文段或用户数据报封装成分组和包进行传送。
路由器 属于网络层
传输层
传输层,主要任务就是负责向两台主机进程之间的通信提供通用的数据传输服务。应用进程利用该服务传送应用层报文。“通用的”是指并不针对某一个特定的网络应用,而是多种应用可以使用同一个运输层服务。由于一台主机可同时运行多个线程,因此运输层有复用和分用的功能。所谓复用就是指多个应用层进程可同时使用下面运输层的服务,分用和复用相反,是运输层把收到的信息分别交付上面应用层中的相应进程。
比如 TCP/IP协议族 中的 1.TCP协议 2.UDP协议
应用层
应用层的任务是通过应用进程间的交互来完成特定网络应用。应用层协议定义的是应用进程间的通信和交互的规则。对于不同的网络应用需要不同的应用层协议。
应用层协议有:域名系统DNS,支持万维网应用的 HTTP协议,支持电子邮件的 SMTP协议等等。我们把应用层交互的数据单元称为报文。
“TCP面向字节流,UDP面向报文”解释如下:
你通过TCP连接给另一端发送数据,你只调用了一次write,发送了100个字节,但是对方可以分10次收完,每次10个字节;你也可以调用10次write,每次10个字节,但是对方可以一次就收完。
UDP和TCP不同,发送端调用了几次write,接收端必须用相同次数的read读完。UPD是基于报文的,在接收的时候,每次最多只能读取一个报文。
TCP是面向连接的,所以收到的数据都是由同一台主机发出的,因此,知道保证数据是有序的到达就行了,至于每次读取多少数据自己看着办。
而UDP是无连接的协议,如果一次能读取超过一个报文的数据,则会乱套。比如,主机A向发送了报文P1,主机B发送了报文P2,如果能够读取超过一个报文的数据,那么就会将P1和P2的数据合并在了一起,这样的数据是没有意义的。
TCP对应的协议:
UDP对应的协议:
学习博客:第五章 链路层
首先, 每个主机会在自己的ARP缓冲区建立一个ARP列表,以表示IP地址和MAC地址之间的对应关系。
当源主机要发送数据时,首先检查自己的ARP列表中是否有对应的目的主机的MAC地址,如果有就直接发送数据,如果没有,就向本网段的所有的主机发送ARP数据包, 该数据包括的内容由:源主机IP地址,源主机的MAC地址,目的主机的IP地址
当本网络的所有主机收到ARP数据包时,首先检查数据包中的IP地址是否是自己的IP地址,如果不是,则忽略该数据包,如果是,则首先从数据包中取出源主机的IP和MAC地址写入到ARP列表中,如果已经存在,则覆盖,然后将自己的MAC地址中放入到ARP响应包中,告诉源主机自己是它想找的MAC地址。
源主机接收到ARP响应包后,将目的主机的IP和MAC地址写入到ARP列表,并利用此消息发送数据。如果源主机一直没有收到ARP响应数据包,表示ARP查询失败。
广播发送ARP请求,单播发送ARP响应。
ARQ协议即 自动重传请求(Automatic Repeat-reQuest,ARQ)是OSI模型中数据链路层和传输层的错误纠正协议之一。它通过使用确认
和超时
这两个机制,在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认帧,它通常会重新发送。ARQ包括停止等待ARQ协议
和连续ARQ协议
。
优点: 简单
缺点: 信道利用率低,等待时间长
连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口,凡位于发送窗口内的分组可以连续发送出去,而不需要等待对方确认。接收方一般采用累计确认,对按序到达的最后一个分组发送确认,表明到这个分组为止的所有分组都已经正确收到了。
优点: 信道利用率高,容易实现,即使确认丢失,也不必重传。
缺点: 不能向发送方反映出接收方已经正确收到的所有分组的信息。 比如:发送方发送了 5条 消息,中间第三条丢失(3号),这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落,而只好把后三个全部重传一次。这也叫 Go-Back-N(回退 N),表示需要退回来重传已经发送过的 N 个消息。
ICMP : 因特网控制报文协议。它是TCP/IP协议族的一个子协议,用于在IP主机、路由器之间传递控制消息(别忘了路由器属于网络层)。控制消息是指网络通不通、主机是否可达、路由器是否可用等网络本身的消息。这些控制消息虽然并不传输用户数据,但是对于用户数据的传递起着重要的作用。
TFTP:是TCP/IP协议族中的一个用来在客户机和服务器之间进行简单的文件传输的协议,提供不复杂、开销不大的文件传输服务
HTTP:超文本传输协议,是一个简单的请求-响应协议,它通常运行在TCP之上。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。
NAT协议:网络地址转换接入广域网(WAN)技术,是一种将私有地址转换为合法IP地址的转换技术。
DHCP协议:动态主机配置协议,使用UDP协议工作。给内部的网络和网络服务供应商自动的分配IP地址,主要作用是集中的管理、分配IP地址,使网络环境中的主机动态的获得IP地址、Gateway地址、DNS服务器地址等信息,并能够提升地址的使用率。
RARP是逆地址解析协议,作用是完成从硬件地址到IP地址的映射,RARP只能用于具有广播能力的网络。封装一个RARP的数据包里面有MAC地址, 然后广播到网络上,当服务器收到请求包后,就查找对应的MAC地址的IP地址装入到响应报文中发送给请求者。
【计算机网络】巧记IP地址分类
A,B,C是基本类,D、E类作为多播和保留使用。
IP地址分为网络号和主机号, A类地址的前8位是网络地址,B类地址的前16位是网络地址,C类地址的前24位是网络地址。
主机号,全0的是网络号,主机号全1的是广播地址。
A类地址:1.0.0.0~126.0.0.0
B类地址:128.0.0.0 ~ 191.255.255.255(B像8,B就是8,所以B是128)
C类地址:192.0.0.0 ~ 223.255.255.255(128+64)
D类地址:224.0.0.0 ~ 239.255.255.255(128+64+32)
E类地址:保留
(应该很好记吧?10开头的,172开头的,192.168开头的,平时中很常见的)
A类:10.0.0.0 - 10.255.255.255
B类:172.16.0.0 - 172.31.255.255
C类:192.168.0.0 - 192.168.255.255
3306:Mysql端口号
TCP 80端口:HTTP超文本传输服务
TCP 25端口:SMTP简单邮件传输服务。(想找邮局寄一份邮包,但被告知无法保证邮包里的二胡(25)不被损坏,不然得加一笔钱作为保险
)
TCP 109端口:POP2邮局协议2
TCP 110端口 : POP3邮局协议版本3使用的端口
TCP 21端口 : FTP 文件传输服务
UDP 69 端口:TFTP 简单文件传输协议
TCP 23 端口:TELNET 远程登录协议
UDP 53端口:DNS域名解析服务
传输连接有三个阶段,即:连接建立,数据传送,连接释放。
握手是为了建立连接,避免传输的数据包乱序问题,握手成功会建立一个全双工通信通道。
第一次握手:客户端主动打开请求服务端,服务端被动打开监听LISTEN,客户端进入SYN_SEND状态,等待服务器确认。
第二次握手:服务端收到SYN包,回应客户端,如果同意连接就发送 SYN/ACK 确认信息,服务器进入SYN_RECV状态。
第三次握手:客户端收到确认信息,向服务器发送ACK确认信息,客户端进入可接受数据状态,服务器收到确认信息后也进入可接受数据状态。
三次握手的目的是建立可靠的通信信道,说到通讯,简单来说就是数据的发送与接收,而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。
第一次握手:Client 什么都不能确认;Server 确认了对方发送正常,自己接收正常
第二次握手:Client 确认了:自己发送、接收正常,对方发送、接收正常;Server 确认了:对方发送正常,自己接收正常
第三次握手:Client 确认了:自己发送、接收正常,对方发送、接收正常;Server 确认了:自己发送、接收正常,对方发送、接收正常
所以三次握手就能确认双发收发功能都正常,缺一不可。
接收端传回发送端所发送的 SYN 是为了告诉发送端,我接收到的信息确实就是你所发送的信号了。
SYN 是 TCP/IP 建立连接时使用的握手信号。在客户机和服务器之间建立正常的 TCP 网 络连接时,客户机首先发出一个 SYN 消息,服务器使用 SYN-ACK 应答表示接收到了这 个消息,最后客户机再以 ACK消息响应。这样在客户机和服务器之间才能建立起可靠的TCP连接,数据才可以在客户机 和服务器之间传递。
A端向B端发送SYN(你在吗?)包确定B端状态, 若B端可通信则回复A端SYN+ACK (在,你在吗?) 当A端收到SYN+ACK包后 回复ACK(我在。)包 此时链接成功建立。
双方通信无误必须是两者互相发送信息都无误。传了 SYN,证明发送方到接收方的通道没有问题,但是接收方到发送方的通道还需要 ACK 信号来进行验证。
在三次握手过程中,服务器发送 SYN-ACK 之后,收到客户端的 ACK 之前的 TCP 连接称为半连接(half-open connect)。此时服务器处于 SYN_RCVD 状态。当收到 ACK 后,服务器才能转入 ESTABLISHED 状态.
SYN攻击指的是,攻击客户端在短时间内伪造大量不存在的IP地址,向服务器不断地发送SYN包,服务器回复确认包,并等待客户的确认。由于源地址是不存在的,服务器需要不断的重发直至超时,这些伪造的SYN包将长时间占用未连接队列,正常的SYN请求被丢弃,导致目标系统运行缓慢,严重者会引起网络堵塞甚至系统瘫痪。
检测 SYN 攻击非常的方便,当你在服务器上看到大量的半连接状态时,特别是源IP地址是随机的,基本上可以断定这是一次SYN攻击。在Linux/Unix 上可以使用系统自带的 netstats 命令来检测 SYN 攻击。
SYN攻击不能完全被阻止,除非将TCP协议重新设计。常见的防御 SYN 攻击的方法有如下几种:
任何一方都可以在数据传送结束后发出连接释放的通知,待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候,则发出连接释放通知,对方确认后就完全关闭了TCP连接。
举个例子:A 和 B 打电话,通话即将结束后,A 说“我没啥要说的了”,B回答“我知道了”,但是 B 可能还会有要说的话,A 不能要求 B 跟着自己的节奏结束通话,于是 B 可能又巴拉巴拉说了一通,最后 B 说“我说完了”,A 回答“知道了”,这样通话才算结束。
2 *MSL(最长报文段寿命)
的时间后,当客户端撤销相应的TCB后,才进入CLOSED状态。MSL(Maximum Segment Lifetime),TCP允许不同的实现可以设置不同的MSL值。
第一,保证客户端发送的最后一个ACK报文能够到达服务器,因为这个ACK报文可能丢失,站在服务器的角度看来,我已经发送了FIN+ACK报文请求断开了,客户端还没有给我回应,应该是我发送的请求断开报文它没有收到,于是服务器又会重新发送一次,而客户端就能在这个2MSL时间段内收到这个重传的报文,接着给出回应报文,并且会重启2MSL计时器。
第二,防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后,在这个2MSL时间中,就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。
建立连接的时候, 服务器在LISTEN状态下,收到建立连接请求的SYN报文后,把ACK和SYN放在一个报文里发送给客户端。
而关闭连接时,服务器收到对方的FIN报文时,仅仅表示对方不再发送数据了但是还能接收数据,而自己也未必全部数据都发送给对方了,所以己方可以立即关闭,也可以发送一些数据给对方后,再发送FIN报文给对方来表示同意现在关闭连接,因此,己方ACK和FIN一般都会分开发送,从而导致多了一次。
学习视频:流量控制 与 滑动窗口协议 ,很清楚
TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率,保证接收方来得及接收。 接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小,从而影响发送方的发送速率。将窗口字段设置为 0,则发送方不能发送数据。
TCP为每一个连接设有一个持续计时器(persistence timer)。只要TCP连接的一方收到对方的零窗口通知,就启动持续计时器。若持续计时器设置的时间到期,就发送一个零窗口控测报文段(携1字节的数据),那么收到这个报文段的一方就重新设置持续计时器。
学习视频:拥塞控制,讲的太清楚了
在某段时间,若对网络中某一资源的需求超过了该资源所能提供的可用部分,网络的性能就要变坏。这种情况就叫拥塞。
拥塞控制就是为了防止过多的数据注入到网络中,这样就可以使网络中的路由器或链路不致过载。
拥塞控制所要做的都有一个前提,就是网络能够承受现有的网络负荷。
TCP的拥塞控制采用了四种算法,即 慢开始 、 拥塞避免 、快重传 和 快恢复。在网络层也可以使路由器采用适当的分组丢弃策略(如主动队列管理 AQM),以减少网络拥塞的发生。
1、满开始
慢开始:当主机开始发送数据时,如果立即所大量数据字节注入到网络,那么就有可能引起网络拥塞,因为现在并不清楚网络的负荷情况。因此,较好的方法是 先探测一下,即由小到大逐渐增大发送窗口。
具体做法就是:拥塞窗口cwnd初始值为1(1是指一个最大报文段MSS的数值),每经过一个传播轮次,cwnd加倍。为了防止拥塞窗口cwnd增长过大引起网络拥塞,还需要设置一个慢开始门限ssthresh状态变量(如何设置ssthresh)。慢开始门限ssthresh的用法如下:
当 cwnd < ssthresh 时,使用慢开始算法。
当 cwnd > ssthresh 时,停止使用慢开始算法而改用拥塞避免算法。
当 cwnd = ssthresh 时,既可使用慢开始算法,也可使用拥塞控制避免算法。
2、拥塞避免:
让拥塞窗口cwnd缓慢地增大,即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1,而不是加倍。这样拥塞窗口cwnd按线性规律缓慢增长,比慢开始算法的拥塞窗口增长速率缓慢得多。
3.快重传与快恢复:
在 TCP/IP 中,快速重传和恢复(fast retransmit and recovery,FRR)是一种拥塞控制算法,它能快速恢复丢失的数据包。没有 FRR,如果数据包丢失了,TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内,没有新的或复制的数据包被发送。有了 FRR,如果接收机接收到一个不按顺序的数据段,它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认,它会假定确认件指出的数据段丢失了,并立即重传这些丢失的数据段。有了 FRR,就不会因为重传时要求的暂停被耽误。 当有单独的数据包丢失时,快速重传和恢复(FRR)能最有效地工作。当有多个数据信息包在某一段很短的时间内丢失时,它则不能很有效地工作。
拥塞控制是一个全局性的过程,涉及到所有的主机,所有的路由器,以及与降低网络传输性能有关的所有因素。
相反,流量控制往往是点对点通信量的控制,是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率,以便使接收端来得及接收。
A通过网络给B发数据,A发送的太快导致B没法接收(B缓冲窗口过小或者处理过慢),这时候的控制就是流量控制
拥塞控制是害怕A发送的太快导致整个网络出现拥塞,拥塞控制也是针对整个网络进行控制,不单单是对A控制
总体来说分为以下几个过程:
1.DNS解析
2.TCP连接
3.发送HTTP请求
4.服务器处理请求并返回HTTP报文
5.浏览器解析渲染页面
6.连接结束
GET:对服务器资源的简单请求
POST:用于发送包含用户提交数据的请求
HEAD:类似于GET请求,不过返回的响应中没有具体内容,用于获取报头
PUT:传说中请求文档的一个版本
DELETE:发出一个删除指定文档的请求
TRACE:发送一个请求副本,以跟踪其处理进程
OPTIONS:返回所有可用的方法,检查服务器支持哪些方法
CONNECT:用于ssl隧道的基于代理的请求
在HTTP/1.0中默认使用短连接。也就是说,客户端和服务器每进行一次HTTP操作,就建立一次连接,任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源(如JavaScript文件、图像文件、CSS文件等),每遇到这样一个Web资源,浏览器就会重新建立一个HTTP会话。
而从HTTP/1.1起,默认使用长连接,用以保持连接特性。
在使用长连接的情况下,当一个网页打开完成后,客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭,客户端再次访问这个服务器时,会继续使用这一条已经建立的连接。实现长连接需要客户端和服务端都支持长连接。
HTTP协议的长连接和短连接,实质上是TCP协议的长连接和短连接。
①工作所处的OSI层次不一样,交换机工作在OSI第二层数据链路层,路由器工作在OSI第三层网络层
②寻址方式不同:交换机根据MAC地址寻址,路由器根据IP地址寻址
③转发速不同:交换机的转发速度快,路由器转发速度相对较慢。
网桥是一个局域网与另一个局域网之间建立连接的桥梁
静态路由是由管理员手工配置的,适合比较简单的网络或需要做路由特殊控制。而动态路由则是由动态路由协议自动维护的,不需人工干预,适合比较复杂大型的网络。
1xx:服务器就收客户端消息,但没有接受完成,等待一段时间后,发送1xx多状态码
2xx:成功。代表:200
3xx:重定向。代表:302(重定向),304(访问缓存)
302:浏览器访问A资源,A资源发了个302(重定向)说我办不了你找C去吧。
304:浏览器访问了一张图片并把它缓存下来,当它再次访问这张图片时该图片就会发出304表示你本地有缓冲,你从缓冲里面找吧
4xx:客户端错误。
* 代表:
* 404(请求路径没有对应的资源)
* 405:请求方式没有对应的doXxx方法(你代码里面删掉了doGet方法,你启动servlet,浏览器访问该页面就会报错为405)
5xx:服务器端错误。代表:500(服务器内部出现异常)
200 OK //客户端请求成功
400 Bad Request // 客户端有语法错误,不能被服务器所理解
402 Forbidden //服务器收到请求,但是拒绝提供服务
404 not find //请求资源不存在
* 重定向的特点:redirect
1. 地址栏发生变化
2. 重定向可以访问其他站点(服务器)的资源
3. 重定向是两次请求。不能使用request对象来共享数据
* 转发的特点:forward
1. 转发地址栏路径不变
2. 转发只能访问当前服务器下的资源
3. 转发是一次请求,可以使用request对象来共享数据
HTTP 是一种不保存状态,即无状态(stateless)协议。也就是说 HTTP 协议自身不对请求和响应之间的通信状态进行保存。那么我们保存用户状态呢?Session 机制的存在就是为了解决这个问题,Session 的主要作用就是通过服务端记录用户的状态。典型的场景是购物车,当你要添加商品到购物车的时候,系统不知道是哪个用户操作的,因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了(一般情况下,服务器会在一定时间内保存这个 Session,过了时间限制,就会销毁这个Session)。
在服务端保存 Session 的方法很多,最常用的就是内存和数据库(比如是使用内存数据库redis保存)。既然 Session 存放在服务器端,那么我们如何实现 Session 跟踪呢?大部分情况下,我们都是通过在 Cookie 中附加一个 Session ID 来方式来跟踪。
Cookie 被禁用怎么办?
最常用的就是利用 URL 重写把 Session ID 直接附加在URL路径的后面。
* session与Cookie的区别:
1. session存储数据在服务器端,Cookie在客户端
2. session没有数据大小限制,Cookie有
3. session数据安全,Cookie相对于不安全
Cookie 和 Session都是用来跟踪浏览器用户身份的会话方式,但是两者的应用场景不太一样。
Cookie的作用:
①在 Cookie 中保存已经登录过的用户信息,下次访问网站的时候页面可以自动帮你登录的一些基本信息给填了。除此之外,Cookie 还能保存用户首选项,主题和其他设置信息。
②使用Cookie 保存 session 或者 token ,向后端发送请求的时候带上 Cookie,这样后端就能取到session或者token了。这样就能记录用户当前的状态了,因为 HTTP 协议是无状态的。
③Cookie 还可以用来记录和分析用户行为。举个简单的例子你在网上购物的时候,因为HTTP协议是没有状态的,如果服务器想要获取你在某个页面的停留状态或者看了哪些商品,一种常用的实现方式就是将这些信息存放在Cookie
session的作用
Session 的主要作用就是通过服务端记录用户的状态。 典型的场景是购物车,当你要添加商品到购物车的时候,系统不知道是哪个用户操作的,因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。
很多时候我们都是通过 SessionID 来实现特定的用户,SessionID 一般会选择存放在 Redis 中。举个例子:用户成功登陆系统,然后返回给客户端具有 SessionID 的 Cookie,当用户向后端发起请求的时候会把 SessionID 带上,服务器可以将存储在 Cookie 上的 Session ID 与存储在内存中或者数据库中的 Session 信息进行比较,以验证用户的身份,返回给用户客户。
一般是通过 Cookie 来保存 SessionID ,假如你使用了 Cookie 保存 SessionID的方案的话, 如果客户端禁用了Cookie,那么Seesion就无法正常工作。
但是,并不是没有 Cookie 之后就不能用 Session 了,比如你可以将SessionID放在请求的 url 里面https://javaguide.cn/?session_id=xxx 。这种方案的话可行,但是安全性和用户体验感降低。当然,为了你也可以对 SessionID 进行一次加密之后再传入后端。
1.什么是CSRF?
CSRF(Cross Site Request Forgery)一般被翻译为 跨站请求伪造 。攻击者盗用你的身份,以你的名义发送恶意请求。目前的验证用户登录方式只是用户的sessionId存在,就认为用户是已经登录状态,但是没有办法保证某一次请求一定是用户触发的。
那么什么是 跨站请求伪造 呢?说简单用你的身份去发送一些对你不友好的请求。举个简单的例子:
小壮登录了某网上银行,他来到了网上银行的帖子区,看到一个帖子下面有一个链接写着“科学理财,年盈利率过万”,小壮好奇的点开了这个链接,结果发现自己的账户少了10000元。这是这么回事呢?原来黑客在链接中藏了一个请求,这个请求直接利用小壮的身份给银行发送了一个转账请求,也就是通过你的 Cookie 向银行发出请求。
<a src=http://www.mybank.com/Transfer?bankId=11&money=10000>科学理财,年盈利率过万</>
cookie中保存着SessionId,客户端登录以后每次请求都会带上这个SessionId,如果别人通过 cookie拿到了 SessionId 后就可以代替你的身份访问系统了。借助这个特性,攻击者就可以在链接中藏了一个请求,这个请求直接利用你的身份给银行发送了一个转账请求,达到攻击效果。
Session 认证中 Cookie 中的 SessionId是由浏览器发送到服务端的,借助这个特性,攻击者就可以通过让用户误点攻击链接,达到攻击效果。
2.如何防御?
1.尽量使用POST请求,GET请求很容易被利用
2.加入验证码功能,确保这一次请求是用户的行为
3.使用token
我们使用 token 的话就不会存在这个问题,在我们登录成功获得 token 之后,在每一次http的请求中或头信息中加上这个 token,然后服务端通过拦截器验证这个token,如果没有token或者token不是正确的就怀疑它是CSRF攻击,然后拒绝这次请求。
关于token:
1.非法请求是不会携带 token 的,所以能被识别出来
2.我们刷新网页就发现每次token都是不一样的,而且每一次请求带着token过去的时候服务端一验证完就立刻销毁这个token,所以token不会被重复利用
需要注意的是不论是 Cookie 还是 token 都无法避免跨站脚本攻击
(Cross Site Scripting)XSS
。
3.什么是XSS
由于我们对URL中的参数或者用户提交输入的地方没有做一个充分的过滤,导致一些不合法的参数或者输入内容能够到了web服务器,就可能将这段被植入恶意脚本的代码拉执行了一遍。
4.如何防御?
1.对输入做一个过滤(做一个黑名单过滤策略,对url的参数做一个过滤,过滤掉会导致脚本执行的相关内容)
2.对输出做一个编码(对动态输出的那些语句做一个编码让它没有办法在浏览器中执行)
3.将cookie设置为http-only(这样js脚本就没有办法读取到cookie)
JWT (JSON Web Token) JWT 本质上就一段签名的 JSON 格式的数据。由于它是带有签名的,因此接收者便可以验证它的真实性。
在我们登录成功获得 token 之后,在每一次http的请求中或头信息中加上这个 token,然后服务端通过拦截器验证这个token,如果没有token或者token不是正确的就怀疑它是CSRF攻击,然后拒绝这次请求。
关于token:
1.非法请求是不会携带 token 的,所以能被识别出来
2.我们刷新网页就发现每次token都是不一样的,而且每一次请求带着token过去的时候服务端一验证完就立刻销毁这个token,所以token不会被重复利用
实际上它就是一种授权机制,它的最终目的是为第三方应用颁发一个有时效性的令牌 token,使得第三方应用能够通过该令牌获取相关的资源。
OAuth 2.0 比较常用的场景就是第三方登录,当你的网站接入了第三方登录的时候一般就是使用的 OAuth 2.0 协议。
SSO(Single Sign On)即单点登录说的是用户登陆多个子系统的其中一个就有权访问与其相关的其他系统。举个例子我们在登陆了京东金融之后,我们同时也成功登陆京东的京东超市、京东家电等子系统。
OAuth 是一个行业的标准授权协议,主要用来授权第三方应用获取有限的权限。
SSO解决的是一个公司的多个相关的自系统的之间的登陆问题比如京东旗下相关子系统京东金融、京东超市、京东家电等等。
* URI:统一资源标识符 : /day14/demo1
* URL:统一资源定位符 : http://localhost/day14/demo1
* URI相当于“共和国”,URL相当于“中华人民共和国”,URI的范围要大于URL的范围
URI(Uniform Resource Identifier) 是统一资源标志符,可以唯一标识一个资源。
URL(Uniform Resource Location) 是统一资源定位符,可以提供该资源的路径。它是一种具体的 URI。
URI的作用像身份证号一样,URL的作用更像家庭住址一样。URL是一种具体的URI,它不仅唯一标识资源,而且还提供了定位该资源的信息。
认证 (Authentication): 你是谁。
授权 (Authorization): 你有权限干什么。
Authentication(认证) 是验证您的身份的凭据(例如用户名/用户ID和密码),通过这个凭据,系统得以知道你就是你,也就是说系统存在你这个用户。所以,Authentication 被称为身份/用户验证。
Authorization(授权) 发生在 Authentication(认证) 之后。授权它主要掌管我们访问系统的权限。比如有些特定资源只能具有特定权限的人才能访问比如admin,有些对系统资源操作比如删除、添加、更新只能特定人才具有。
这两个一般在我们的系统中被结合在一起使用,目的就是为了保护我们系统的安全性。