标签:浏览器 请求 基础 网络 发送 DNS 服务器 客户端
文章目录
- 1.硬件地址
- 2.域名
- 3.私有IP地址
- 4.判断是否属于同一个子网
- 5.URL构成
- 6.cookie和session的区别
- 7.OSI,TCP/IP,五层协议的体系结构,以及各层协议
- 8.HTTP常用动词
- 9.ARP和RARP
- 10.DNS域名解析失败
- 11.URL从输入到渲染全过程
- 12.socket通讯
- 13.对称加密非对称加密
- 14.HTTP
- 15.传输层中的TCP
- 16.unix网络模型
- 17.反向代理
- 18.http2多路复用
- 19.XSS,CSRF,DDOS
- 20.DHCP
- 21.CIDR 无类型域间选路
- 22.Hub 集线器
- 23.交换机
- 24.VLAN
- 25.DNS/HTTPDNS
- 26.P2P
- 27.VPN
1.硬件地址
MAC地址是网卡决定的,是固定的。MAC地址就如同我们身份证上的身份证号码
2.域名
一个域名对应一个IP地址,一个IP地址可以对应多个域名;所以多个域名可以同时被解析到一个IP地址。域名解析需要由专门的域名解析服务器(DNS)来完成。
3.私有IP地址
私有IP就是在本地局域网上的IP 与之对应的是公有IP(在互联网上的IP)。
- 10.0.0.0~10.255.255.255 即10.0.0.0/8
- 172.16.0.0~172.31.255.255即172.16.0.0/12
- 192.168.0.0~192.168.255.255 即192.168.0.0/16
4.判断是否属于同一个子网
若子网掩码为255.255.255.192
换算成2进制:
11111111.11111111.11111111.11000000
第一组:
156.26.101.88和156.26.101.132
二级制分别是:
10011100.00011010.01100101.01011000
10011100.00011010.01100101.10000100
和子网掩码AND运算,前面肯定一样,第四段不同
第二组:
156.26.27.71和156.26.27.110
二级制分别是:
10011100.00011010.00011011.01000111
10011100.00011010.00011011.01101110
和子网掩码AND运算,只看第四段:
01000000
01000000 完全相同,所以是一个子网
5.URL构成
http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name
- 1
- ⑴协议部分 http
- ⑵域名部分 www.aspxfans.com
- ⑶端口(非必须,没有则使用默认) 8080
- ⑷虚拟目录部分(非必须) 从第一个/到最后一个/ 这里是/news/
- ⑸文件名部分(非必须) 从最后一个/到? 这里是index.asp
- ⑹锚部分(非必须) :从“#”开始到最后,都是锚部分。这里是name
- ⑺参数部分:从“?”开始到“#”为止之间的部分为参数部分,这里是boardID=5&ID=24618&page=1**
6.cookie和session的区别
- ①cookie数据存放在客户的浏览器上,session数据放在服务器上,cookie中存有sessionid
- ②cookie不是很安全,别人可以分析存放在本地的COOKIE并进行COOKIE欺骗
考虑到安全应当使用session。 - ③session会在一定时间内保存在服务器上。当访问增多,会比较占用你服务器的性能
考虑到减轻服务器性能方面,应当使用COOKIE。 - ④单个cookie保存的数据不能超过4K,很多浏览器都限制一个站点最多保存20个cookie。
- ⑤所以个人建议:将登陆信息等重要信息存放为SESSION
7.OSI,TCP/IP,五层协议的体系结构,以及各层协议
⑴应用层
应用层是我们经常接触使用的部分
⑵传输层
传输层的作用就是将应用层的数据进行传输转运
⑶网络层
网络层用来处理网络中流动的数据包,数据包为最小的传递单位
⑷数据链路层
数据链路层一般用来处理连接硬件的部分
⑸物理层
物理层一般为负责数据传输的硬件,比如我们了解的双绞线电缆、无线、光纤等。比特流光电等信号发送接收数据。
8.HTTP常用动词
- GET (选择):从服务器上获取一个具体的资源或者一个资源列表。幂等
- POST (创建): 在服务器上创建一个新的资源。非幂等
- PUT (更新):以整体的方式更新服务器上的一个资源。幂等
- PATCH (更新):只更新服务器上一个资源的一个属性。和PUT非常类似。非幂等
- DELETE (删除):删除服务器上的一个资源。幂等
9.ARP和RARP
ARP协议就是将IP地址转换为MAC物理地址
RARP协议就是将MAC物理地址转换为IP地址
10.DNS域名解析失败
原因
- 网络不可用(少见)
- 域名劫持(少见)
- 域名解析被禁止,用whois工具检查域名状态。
- 各项记录及缓存更新是否生效
解决方法
- 1、HTTPDNS解决法
HTTPDNS解决法即使用HTTP协议进行域名解析,域名解析请求直接发送到HTTPDNS服务器而不经过运营商,这种方法不仅能解决dns域名解析失败的问题,并且还能提高解析效率。 - 2、公共DNS解决法
虽然有部分厂商提供dns解决法,但是这种方法通用型很低,对于开发者来言实施难度也很大。 - 3、通过客户端自身解决(重点)
如果是客户自身由于缓存不能更新的,可以通过dos命令来执行强制刷新解析结果。例如windows系统可以执行ipconfig/flushdns命令清空DNS缓存。
11.URL从输入到渲染全过程
⑴ 概述
- DNS解析
- 与服务器建立连接
- 服务器处理并返回http报文
- 浏览器解析渲染页面
⑵ DNS解析
实现了网址到IP地址的转换。
DNS解析通常会经过以下几个过程:
- 浏览器缓存
- 系统缓存
- 路由器缓存
- ISP DNS缓存
- 都没有找到,则向根域名服务器查找域名对应IP,根域名服务器吧请求转发到下一级查找IP。比如www.baidu.com的查找顺序是:
根域名服务器(.)-> .com -> .baidu.com -> www.baidu.com
⑶ 建立连接
俗称三次握手
⑷ 服务端处理并返回http报文
- 浏览器根据 URL 内容生成 HTTP 请求,请求中包含请求文件的位置、请求文件的方式等等
- 服务器接到请求后,会根据 HTTP 请求中的内容来决定如何获取相应的 HTML 文件
- 服务器将处理结果HTML 文件发送给浏览器
⑸ 浏览器解析渲染页面
- 浏览器拿到HTML文件后,根据渲染规则进行渲染:
- 解析HTML,构建DOM树
- 解析CSS,生成CSS规则树
- 合并DOM树和CSS规则树,生成render树
- 布局render树
- 绘制render数、树,即绘制页面像素信息
- GPU将各层合成,结果呈现在浏览器窗口中。
12.socket通讯
⑴基本步骤
- 创建sockethe和ServiceSocket
- 打开socket输入输出流
- 按照协议对socket进行读写操作
- 关闭输入输出流,关闭socket
⑵基于TCP的socket编程
- service端
- 创建ServiceSocket对象,绑定端口 ServerSocket(int port)
- 通过accept()方法监听客户请求
- 通过输入流读取客户端发送的信息
- 通过输出流向客户端发送响应信息
- client端
- 创建socket对象,需要指明连接的服务器地址和端口号 Socket(InetAddress address , int port)
- 建立连接后,通过输出流向服务器端发送请求信息
- 通过输入流获取服务器端响应的信息
- 关闭资源
⑶基于UDP的socket编程
- service端
- 创建DatagramSocket 同时指定端口号
- 建DatagramPacket 用来接收客户端发送来的数据
- 接受客户端发送的数据信息
- 读取数据
- client端
- 定义发送信息
- 创建DatagramPacket,包含将要发送的信息
- 创建DatagramSocket
- 发送数据
13.对称加密非对称加密
⑴对称加密
对称加密的基本思想是: 通信双方使用同一个密钥(或者是两个可以简单地互相推算的密钥)来对明文进行加密与解密
常见的对称加密算法有DES、3DES、AES、Blowfish、IDEA、RC5、RC6
对称加密看起来很美好,但是密钥要怎么发送过去呢?如果直接发送过去,被中间人截获了密钥岂不是白费工夫
⑵非对称加密
使用了两个密钥,一个为公钥,一个为私钥,公开其中一个密钥(也就是公钥),不公开的密钥为私钥
常见的非对称加密算法有RSA、DSA、ECDSA、 DH、ECDHE
它的效率有点低
⑶对称加密+非对称加密
将对称加密与非对称加密结合起来,其中一方先自己生成一个对称加密密钥,然后通过非对称加密的方式来发送这个密钥,这样双方之后的通信就可以用对称加密这种高效率的算法进行加解密了.
14.HTTP
⑴概述
HTTP协议(HyperText Transfer Protocol,超文本传输协议)是因特网上应用最为广泛的一种网络传输协议
⑵HTTP工作过程
⑶HTTP特点
- 无状态,但是很多业务都需要对通信状态进行保存,于是我们引入了 Cookie 技术
- 使用 Cookie 的状态管理,Cookie 会根据从服务器端发送的响应报文内的一个叫做 Set-Cookie 的首部字段信息,通知客户端保存Cookie。
- 长连接 HTTP/1.1 和部分 HTTP/1.0 想出了持久连接的方法,只要任意一端没有明确提出断开连接,则保持 TCP 连接状态。在 HTTP/1.1 中,所有的连接默认都是持久连接
- 管线化 能做到同时并行发送多个请求
⑷发展过程
- HTTP0.9
- 仅支持GET
- 相应仅支持超文本,响应后马上结束的连接
- 没有 HTTP headers (无法传输其他内容类型的文件), 没有 status/error 代码, 没有 URLs, 没有版本控制
- HTTP1.0的改进
- 支持的方法:GET HESD POST
- 响应:不再只限于超文本 (Content-Type 头部提供了传输 HTML 之外文件的能力 — 如脚本、样式或媒体文件)
- 提供了对请求和响应都包含丰富元数据的 header 域 (HTTP 版本号、status code 和 content type)
- HTTP1.0默认是短连接
- HTTP1.1的改进(当前普遍使用的版本)
- 支持的方法: GET , HEAD , POST , PUT , DELETE , TRACE , OPTIONS
- 默认值长连接
- 进行了重大的性能优化和特性增强,分块传输、压缩/解压等
- 引入更多缓存机制
- 增加了错误状态码
- 在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址,因此,请求消息中的URL并没有传递主机名(hostname)。但随着虚拟主机技术的发展,在一台物理服务器上可以存在多个虚拟主机(Multi-homed Web Servers),并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域,且请求消息中如果没有Host头域会报告一个错误(400 Bad Request)。
- SPDY
2012年由google提出,主要解决:- 降低延迟,针对HTTP高延迟的问题,SPDY优雅的采取了多路复用(multiplexing)
- 请求优先级(request prioritization)。多路复用带来一个新的问题是,在连接共享的基础之上有可能会导 致关键请求被阻塞。SPDY允许给每个request设置优先级,这样重要的请求就会优先得到响应。比如浏览器加载首页,首页的html内容应该优先展示,之后才是各种静态资源文件,脚本文件等加载,这样可以保证用户能第一时间看到网页内容。
- header压缩。前面提到HTTP1.x的header很多时候都是重复多余的。选择合适的压缩算法可以减小包的大小和数量。
- 基于HTTPS的加密协议传输,大大提高了传输数据的可靠性。
- 服务端推送(server push),采用了SPDY的网页,例如我的网页有一个style.css的请求,在客户端收到style.css数据的同时,服务端会将style.js的文件推送给客户端,当客户端再次尝试获取style.js时就可以直接从缓存中获取到,不用再发请求了。
- HTTP2.0
- HTTP2.0 支持明文 HTTP 传输,而 SPDY 强制使用 HTTPS
- HTTP2.0 消息头的压缩算法采用 HPACK,而非 SPDY 采用的 DEFLATE
- 说了HTTP2.0其实可以支持非HTTPS的,但是现在主流的浏览器像chrome,firefox表示还是只支持基于 TLS 部署的HTTP2.0协议,所以要想升级成HTTP2.0还是先升级HTTPS为好
- HTTP2.0完全兼容HTTP1.x的语义,对于不支持HTTP2.0的浏览器,NGINX会自动向下兼容的
- HTTP2.0的三大特性(SPDY已经支持)
- 头部压缩
- 服务端推送
- 多路复用
⑸HTTPS
①概述
HTTP是明文传输的,HTTPS在HTTP的基础上添加了SSL(安全套接字层)层来保证传输数据的安全问题
②CA证书
CA证书是由一个权威的CA证书中心颁发的,我们首先来看一个简化的加密流程,对于每个访问XX的用户,生成的对称密钥B理论上来说都是不一样的。比如小明、小王、小光,可能生成的就是B1、B2、B3.
- 小明访问XX,XX将自己的证书给到小明(其实是给到浏览器,小明不会有感知)
- 浏览器从证书中拿到XX的公钥A
- 浏览器生成一个只有自己自己的对称密钥B,用公钥A加密,并传给XX(其实是有协商的过程,这里为了便于理解先简化)
- XX通过私钥解密,拿到对称密钥B
- 浏览器、XX 之后的数据通信,都用密钥B进行加密
注:这里的Bill是服务器端
如何保证证书不被篡改呢?
数字签名是用来验证数据完整性的,首先将公钥与个人信息用一个Hash算法生成一个消息摘要,Hash算法是不可逆的,且只要内容发生变化,那生成的消息摘要将会截然不同.然后CA再用它的私钥对消息摘要加密,最终形成数字签名.这还不算, 还把原始信息和数据签名合并, 形成一个全新的东西,叫做“数字证书”
当客户端接收到证书时:
- 用同样的Hash算法再次生成一个消息摘要
- 然后用CA的公钥对证书进行解密
- 对比两个消息摘要就能知道数据有没有被篡改过了.
那么CA的公钥又要从哪里来呢?这似乎陷入了一个鸡生蛋,蛋生鸡的悖论,其实CA也有证书来证明自己,而且CA证书的信用体系就像一棵树的结构,上层节点是信用高的CA同时它也会对底层的CA做信用背书,操作系统中已经内置了一些根证书,所以相当于你已经自动信任了它们(需要注意误安装一些非法或不安全的证书).
⑹HTTP报文信息
①报文结构
②请求报文
这里只关注几个重要的:
- Cookie: 客户机通过这个头可以向服务器带数据
- Accept: 用于高速服务器,客户机支持的数据类型
③响应报文
这里只关注几个重要的:
- content-type:服务器通过这个头告诉浏览器回送数据的类型。
- set-cookie: 设置HTTP cookie
⑺状态码
常用的状态码:
- 200 表示从客户端发来的请求在服务器端被正常处理了
- 400 表示请求报文中存在语法错误
- 404 服务器上无法找到请求的资源
- 500 表明服务器端在执行请求时发生了错误。也可能是 Web 应用存在的 bug 或某些临时的故障
15.传输层中的TCP
⑴概述
TCP/IP 原本就是为使用互联网而开发制定的协议族。因此,互联网的协议就是 TCP/IP,TCP/IP 就是互联网的协议。我们这里讲的是位于传输层中的TCP
⑵三次握手和四次挥手
①三次握手
- 客户端将标志位SYN置为1,随机产生一个值seq=J,并将该数据包发送给服务器端,客户端进入SYN_SENT状态,等待服务器端确认
- 服务器端收到数据包后由标志位SYN=1知道客户端请求建立连接,服务器端将标志位SYN和ACK都置为1,ack=J+1,随机产生一个值seq=K,并将该数据包发送给客户端以确认连接请求,服务器端进入SYN_RCVD状态
- 客户端收到确认后,检查ack是否为J+1,ACK是否为1,如果正确则将标志位ACK置为1,ack=K+1,并将该数据包发送给服务器端,服务器端检查ack是否为K+1,ACK是否为1,如果正确则连接建立成功,客户端和服务器端进入ESTABLISHED状态,完成三次握手,随后客户端与服务器端之间可以开始传输数据了
为什么要三次握手?
为了保证服务端能收接受到客户端的信息并能做出正确的应答而进行前两次(第一次和第二次)握手,为了保证客户端能够接收到服务端的信息并能做出正确的应答而进行后两次(第二次和第三次)握手。
②四次挥手
中断连接端可以是客户端,也可以是服务器端。
第一次挥手:客户端发送一个FIN=M,用来关闭客户端到服务器端的数据传送,客户端进入FIN_WAIT_1状态。意思是说"我客户端没有数据要发给你了",但是如果你服务器端还有数据没有发送完成,则不必急着关闭连接,可以继续发送数据。
第二次挥手:服务器端收到FIN后,先发送ack=M+1,告诉客户端,你的请求我收到了,但是我还没准备好,请继续你等我的消息。这个时候客户端就进入FIN_WAIT_2 状态,继续等待服务器端的FIN报文。
第三次挥手:当服务器端确定数据已发送完成,则向客户端发送FIN=N报文,告诉客户端,好了,我这边数据发完了,准备好关闭连接了。服务器端进入LAST_ACK状态。
第四次挥手:客户端收到FIN=N报文后,就知道可以关闭连接了,但是他还是不相信网络,怕服务器端不知道要关闭,所以发送ack=N+1后进入TIME_WAIT状态,如果Server端没有收到ACK则可以重传。服务器端收到ACK后,就知道可以断开连接了。客户端等待了2MSL后依然没有收到回复,则证明服务器端已正常关闭,那好,我客户端也可以关闭连接了。最终完成了四次握手。
上面是一方主动关闭,另一方被动关闭的情况,实际中还会出现同时发起主动关闭的情况,
⑶TCP粘包,拆包及解决方法
①概述
首先知道一点:UDP是不会发生粘包或拆包现象的,UDP是基于报文发送的,从UDP的帧结构可以看出,在UDP首部采用了16bit来指示UDP数据报文的长度,因此在应用层能很好的将不同的数据报文区分开,从而避免粘包和拆包的问题。
而TCP是基于字节流的,虽然应用层和TCP传输层之间的数据交互是大小不等的数据块,但是TCP把这些数据块仅仅看成一连串无结构的字节流,没有边界;在TCP的首部也没有表示数据长度的字段,基于上面两点,在使用TCP传输数据时,才有粘包或者拆包现象发生的可能。
②粘包,拆包表现形式
现在假设客户端向服务端连续发送了两个数据包,用packet1和packet2来表示,那么服务端收到的数据可以分为三种:
- 正常接收两个包,没发生粘包或者拆包
- 只接收了一个包,由于TCP不会丢包,这个包含了两个包的信息,即发生了粘包,由于接收端不知道两个包界限所以不好解析
- 两个包不完整或多出一块,即发生了粘包和拆包
③原因
- 要发送的数据大于TCP发送缓冲区剩余空间大小,将会发生拆包。
- 待发送数据大于MSS(最大报文长度),TCP在传输前将进行拆包。
- 要发送的数据小于TCP发送缓冲区的大小,TCP将多次写入缓冲区的数据一次发送出去,将会发生粘包。
- 接收数据端的应用层没有及时读取接收缓冲区中的数据,将发生粘包。
等等。
④解决方法
关键在于添加边界信息,常用办法如下:
- 发送端给每个数据包添加包含数据包长度的包首部。效率高,实现复杂
- 将数据包封装为固定长度(不够的用0填充),接收端每次从缓冲区读取固定长度。效率低,实现简单
- 数据包之间添加特殊字符
⑷通过序列号和确认应答提高可靠性
- 接收端收到消息会返回一个已收到消息的通知
- 在一定时间没有确认应答,则发送端重发
- 为了防止接收端接受重复,有了序列号,确认应答会返回下一个应当接收的序列号
⑸重发时间
- 如果超过这个时间仍未收到确认应答,发送端将进行数据重发。最理想的是,找到一个最小时间,它能保证“确认应答一定能在这个时间内返回”
- 数据被重发之后若还是收不到确认应答,则进行再次发送。此时,等待确认应答的时间将会以2倍、4倍的指数函数延长
- 达到一定重发次数之后,如果仍没有任何确认应答返回,就会判断为网络或对端主机发生了异常,强制关闭连接。并且通知应用通信异常强行终止
⑹以段为单位发送数据
在建立 TCP 连接的同时,也可以确定发送数据包的单位,我们也可以称其为“最大消息长度”(MSS)。最理想的情况是,最大消息长度正好是 IP 中不会被分片处理的最大数据长度。
TCP 在传送大量数据时,是以 MSS 的大小将数据进行分割发送。进行重发时也是以 MSS 为单位。
MSS 在三次握手的时候,在两端主机之间被计算得出。两端的主机在发出建立连接的请求时,会在 TCP 首部中写入 MSS 选项,告诉对方自己的接口能够适应的 MSS 的大小。然后会在两者之间选择一个较小的值投入使用。
⑺利用窗口提高速度
CP 以1个段为单位,每发送一个段进行一次确认应答的处理。这样的传输方式有一个缺点,就是包的往返时间越长通信性能就越低。
为解决这个问题,TCP 引入了窗口这个概念。确认应答不再是以每个分段,而是以更大的单位进行确认,转发时间将会被大幅地缩短。也就是说,发送端主机,在发送了一个段以后不必要一直等待确认应答,而是继续发送。如下图所示:
窗口大小就是指无需等待确认应答而可以继续发送数据的最大值。上图中窗口大小为4个段。这个机制实现了使用大量的缓冲区,通过对多个段同时进行确认应答的功能。
⑻滑动窗口控制
①概述
上图中的窗口内的数据即便没有收到确认应答也可以被发送出去。不过,在整个窗口的确认应答没有到达之前,如果其中部分数据出现丢包,那么发送端仍然要负责重传。为此,发送端主机需要设置缓存保留这些待被重传的数据,直到收到他们的确认应答。
在滑动窗口以外的部分包括未发送的数据以及已经确认对端已收到的数据。当数据发出后若如期收到确认应答就可以不用再进行重发,此时数据就可以从缓存区清除。
收到确认应答的情况下,将窗口滑动到确认应答中的序列号的位置。这样可以顺序地将多个段同时发送提高通信性能。这种机制也别称为滑动窗口控制。
②窗口控制的重发控制
在使用窗口控制中, 出现丢包一般分为两种情况:
① 确认应答未能返回的情况。在这种情况下,数据已经到达对端,是不需要再进行重发的,如下图:
② 某个报文段丢失的情况。接收主机如果收到一个自己应该接收的序列号以外的数据时,会针对当前为止收到数据返回确认应答。如下图所示,当某一报文段丢失后,发送端会一直收到序号为1001的确认应答,因此,在窗口比较大,又出现报文段丢失的情况下,同一个序列号的确认应答将会被重复不断地返回。而发送端主机如果连续3次收到同一个确认应答,就会将其对应的数据进行重发。这种机制比之前提到的超时管理更加高效,因此也被称为高速重发控制。
16.unix网络模型
⑴同步,异步,阻塞,非阻塞
- 同步 需要不断打电话给渔夫
- 异步 鱼好了渔夫通知你,不需要你去问
- 阻塞 买鱼要在码头等着
- 非阻塞 买鱼不用在码头等着
⑵5种不同的io模型
- 同步阻塞I/O
- 同步非阻塞 I/O
- I/O复用模型
- 信号驱动式I/O模型
- 异步非阻塞 I/O
⑶同步阻塞I/O
当我们去买码头买鱼,鱼还没上来,我们一直在码头等着鱼钓上来,这就是同步阻塞I/O
⑷同步非阻塞 I/O
我们不断的问码头的鱼上来没有,上来我们就去拿,这就是同步非阻塞I/O
⑸I/O复用模型
通过一种机制,一个进程可以监视多个文件描述符(套接字描述符)一旦某个文件描述符就绪(一般是读就绪或者写就绪),能够通知程序进行相应的读写操作(这样就不需要每个用户进程不断的询问内核数据准备好了没)。
IO复用的实现方式目前主要有select、poll和epoll
select和poll就是当去询问时,渔民会把所有点的鱼都轮询一遍再回复,当大量鱼很长时间都不能准备好的情况下是很低效的。于是,渔民有些不耐烦了,然后就每准备好一种鱼就记下来他。这样每次再去问的时候,他会直接把已经准备好的鱼回复,你再去拿。这就是事件驱动IO就绪通知的方式epoll。
⑹信号驱动式I/O模型
我们打个电话给渔夫,鱼准备好了通知我们去拿,这就是信号驱动式I/O模型
⑺异步非阻塞 I/O
我们打个电话给渔夫,鱼准备好了渔夫给你送过来,这就是异步非阻塞I/O
⑻五种I/O模型的比较
17.反向代理
服务器根据客户端的请求,从其关联的一组或多组后端服务器(如Web服务器)上获取资源,然后再将这些资源返回给客户端,反向代理是服务端的代理。客户端不需要知道实际后端服务器的存在,而以为所有资源都来自于这个反向代理服务器。
18.http2多路复用
⑴长连接存在的问题
HTTP1.1已经默认采用长连接。但是长连接只减少了建立连接的时间,HTTP 1.1是基于串行文件传输数据,因此这些请求必须是有序的,所以没有办法并行传输。
⑵http2的改进
HTTP1.1是基于文本的,只能串行顺序传输,HTTP2引入二进制数据帧和流的概念,其中帧对数据进行顺序标识。这样接收端就可以按照顺序对数据进行合并,从而可以并行的传输数据。
19.XSS,CSRF,DDOS
⑴XSS
①什么是XSS
Cross-Site Scripting(跨站脚本攻击)简称 XSS,是一种代码注入攻击。攻击者通过在目标网站上注入恶意脚本,使之在用户的浏览器上运行。利用这些恶意脚本,攻击者可获取用户的敏感信息如 Cookie、SessionID 等,进而危害数据安全。
为了和 CSS 区分,这里把攻击的第一个字母改成了 X,于是叫做 XSS。
②XSS攻击分类
- 存储型
恶意代码被当做正常数据插入到数据库中,当用户正常访问页面的时候,恶意代码从数据库中被取出,在当前页面被触发。用户不会发现自己被攻击。这种XSS可以无差别攻击,影响很大。比如留言板的XSS,在留言板里加个alert的script,等读的时候弹死他们。 - 反射型
恶意代码被当做正常数据提交到后台后,由后台进行处理,并立刻返回到前端被触发。这种XSS的攻击方式一般是骗人点链接,恶意代码在url中,有一些安全常识的人可能会发现一些端倪。比如前几年在QQ空间留言区很火的“你这张照片好好看啊:恶意连接”。 - DOM型
和反射型一样,单独提出来是因为它不过后端,由JS直接在前台处理。所以在后端是无法防御的,这个必须要前台过滤。比如当你在一个购物网站搜索“上衣”,返回页面中显示“上衣的搜索结果如下:”,这里的上衣可能就是直接由js获取你提交的值插入的,而不是从后端而来。
③XSS可以干的坏事举例
- 盗取cookie
- 可以偷你当前页面的重要数据,偷偷回传到攻击者服务器
- 恶意跳转,比如网页中插入一个window.location.href的脚本。
还有很多自行脑补。。。
④如何防止XSS攻击
需要对用户的输入进行处理,只允许输入合法的值,其它值一概过滤掉。不要让不可预期的脚本被在浏览器上执行,所以在前端和后端代码上都加上过滤方法。过滤掉所有不可预期的脚本。但是用户有插入混合图文的需求,有的场景可能还支持自定义样式,这决定了不能完全阻止html注入,自然也就会带来js注入,引发XSS。
⑵CSRF
①什么是CSRF攻击
CSRF(Cross Site Request Forgery),中文是跨站点请求伪造。CSRF攻击者在用户已经登录目标网站之后,诱使用户访问一个攻击页面,利用目标网站对用户的信任,以用户身份在攻击页面对目标网站发起伪造用户操作的请求,达到攻击目的。
②CSRF攻击的原因
CSRF攻击是源于Web的隐式身份验证机制!Web的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器,但却无法保证该请求是用户批准发送的。具体过程如下
- ⑴用户C打开浏览器,访问受信任网站A,输入用户名和密码请求登录网站A
- ⑵在用户信息通过验证后,网站A产生Cookie信息并返回给浏览器,此时用户登录网站A成功
- ⑶用户未退出网站A之前,在同一浏览器中,打开一个TAB页访问网站B
- ⑷网站B接收到用户请求后,返回一些攻击性代码,并发出一个请求要求访问第三方站点A
- ⑸浏览器在接收到这些攻击性代码后,根据网站B的请求,在用户不知情的情况下携带Cookie信息,向网站A发出请求
③CSRF攻击的例子
受害者 Bob 在银行有一笔存款,通过对银行的网站发送请求http://bank.example/withdrawaccount=bob&amount=1000000&for=bob2 可以使 Bob 把 1000000 的存款转到 bob2 的账号下。通常情况下,该请求发送到网站后,服务器会先验证该请求是否来自一个合法的 session,并且该 session 的用户 Bob 已经成功登陆。
黑客 Mallory 自己在该银行也有账户,他知道上文中的 URL 可以把钱进行转帐操作。Mallory 可以自己发送一个请求给银行:http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory。但是这个请求来自 Mallory 而非 Bob,他不能通过安全认证,因此该请求不会起作用。
这时,Mallory 想到使用 CSRF 的攻击方式,他先自己做一个网站,在网站中放入如下代码: src=”http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory ”,并且通过广告等诱使 Bob 来访问他的网站。当 Bob 访问该网站时,上述 url 就会从 Bob 的浏览器发向银行,而这个请求会附带 Bob 浏览器中的 cookie 一起发向银行服务器。大多数情况下,该请求会失败,因为他要求 Bob 的认证信息。但是,如果 Bob 当时恰巧刚访问他的银行后不久,他的浏览器与银行网站之间的 session 尚未过期,浏览器的 cookie 之中含有 Bob 的认证信息。这时,悲剧发生了,这个 url 请求就会得到响应,钱将从 Bob 的账号转移到 Mallory 的账号。
④CSRF漏洞检测
以CSRFTester工具为例,CSRF漏洞检测工具的测试原理如下:使用CSRFTester进行测试时,首先需要抓取我们在浏览器中访问过的所有链接以及所有的表单等信息,然后通过在CSRFTester中修改相应的表单等信息,重新提交,这相当于一次伪造客户端请求。如果修改后的测试请求成功被网站服务器接受,则说明存在CSRF漏洞,当然此款工具也可以被用来进行CSRF攻击。
⑤CSRF攻击的解决方案
使用一个Token(Anti CSRF Token),比如:
- 用户访问某个表单页面。
- 服务端生成一个Token,放在用户的Session中,或者浏览器的Cookie中。
- 在页面表单附带上Token参数。
- 用户提交请求后, 服务端验证表单中的Token是否与用户Session(或Cookies)中的Token一致,一致为合法请求,不是则非法请求。
这个Token的值必须是随机的,不可预测的。由于Token的存在,攻击者无法再构造一个带有合法Token的请求实施CSRF攻击。另外使用Token时应注意Token的保密性,尽量把敏感操作由GET改为POST,以form或AJAX形式提交,避免Token泄露。
⑶DDOS
DDoS攻击通过大量合法的请求占用大量网络资源,以达到瘫痪网络的目的。
20.DHCP
动态主机配置协议,主要是用来动态配置IP地址
当一台机器加入一个网络的时候,只有MAC地址而没有IP地址,如果这个网络里配有DHCP Server的话,就会租给它一个IP地址,DHCP服务器可以有多个,新加入的机器一般会选择先收到的IP
客户机当租期过了5成时,会继续给分配它的DHCP服务器发消息续租
BOOTP(Bootstrap Protocol,引导程序协议)是一种引导协议,基于UDP,是DHCP的前身
21.CIDR 无类型域间选路
由于C类地址包含的主机数太少,B类又太多了,所以有了CIDR
将32位IP地址一份为二:
10.100.122.2/24 前面24位是网络号,后面8位是主机号
22.Hub 集线器
集线器完全工作在物理层,它将自己收到的每一个字节都复制到其他所有端口上去
在一个局域网,知道IP找MAC地址靠吼,吼出结果缓存一段时间
23.交换机
二层设备,因为集线器是广播的,机器一多久不行了,所以有了交换机
交换机也会的缓存,当A机器请求到达交换机时,它就会记录下来,以后有包目的地址是A就直接发了,缓存也是过期时间的
多个交换机就形成了一个拓扑结构,当一个交换机下面的局域网发过来一个信息,除了包来的方向外它就会转发给其它所有网口,当转发到其它交换机时,其它交换机会广播自己的局网,找到对应的地址,交换机也可以学习,缓存地址
同时,为了解决环路问题,A-B-A的问题,交换机采用了STP协议
24.VLAN
虚拟局域网,也就是一个交换机下面有多个局域网
25.DNS/HTTPDNS
⑴DNS
DNS服务器是通过域名去查询对应的IP的设备,要设计成分布式高可用的
DNS服务器
- 根 DNS 服务器 :返回顶级域 DNS 服务器的 IP 地址
- 顶级域 DNS 服务器:返回权威 DNS 服务器的 IP 地址
- 权威 DNS 服务器 :返回相应主机的 IP 地址
根DNS服务器和顶级域DNS服务器,不会告诉本地DNS具体IP。而是指向它下级的服务器地址。权威DNS服务器会告诉本地DNS具体的IP地址。什么叫本地DNS呢?一般就是网络服务商的某个机房
DNS解析流程:
客户端先去本地DNS查询
- 本地DNS查询不到就去根域名服务器
- 根域名服务器指向对应的顶级域名服务器
- 顶级域名服务器指向权威DNS服务器
- 权威DNS服务器给本地DNS对应的IP
- 本地DNS将IP返回给客户端,客户端和目标建立连接
负载均衡:
- 内部负载均衡
通过域名查询IP地址,IP地址可以配置多个做简单的轮询。 - 全局负载均衡
轮询访问不同地域的多个数据中心,也可以配置就近或者分运营商访问
工具
- 可以查询DNS解析过程dig。
⑵HTTPDNS
DNS存在的问题:
- 给A运营商发请求,A外包给了B,DNS服务器以为我们是B的用户,给我的IP是B的,跨运营商访问很慢
- 本地DNS缓存并非最新的,也可能不再是最合适的
- NAT网关会修改IP地址,DNS服务器无法判断运营商
- DNS解析要根DNS到权威DNS,比较慢
什么是HTTP DNS:
自己搭建基于HTTP协议的DNS服务,分布多个地点和运营商,使用HTTPDNS的一般是手机用户。
在客户端的缓存是手机应用自己做的,可以在配置如何更新,合适更新,可以直接请求HTTPDNS服务器。不需要本地DNS缓存(本地DNS缓存一般是运营商统一做的)。
HTTPDNS缓存设计
- 同步进行
发现过期直接调用 HTTPDNS 的接口,返回最新的记录,更新缓存,实时性好,但是当多个请求同时发现,浪费资源 - 异步进行
可以将多个请求都发现过期的情况,合并为一个对于 HTTPDNS 的请求任务,只执行一次,减少 HTTPDNS 的压力。同时可以在即将过期的时候,就创建一个任务进行预加载,防止过期之后再刷新,称为预加载。缺点是客户可能请求到过期的数据
26.P2P
HTTP协议和FTP协议都无法克服服务器的带宽问题,所有有个P2P协议。
在P2P协议中,我们即使服务下载者,也是提供者。常见的P2P软件例如BitTorrent,往往我们看到既有下载流量,又有上传流量。
P2P 也是有两种,一种是依赖于 tracker 的,也即元数据集中,文件数据分散;另一种是 基于分布式的哈希算法,元数据和文件数据全部分散。
⑴依赖tracker的协议
.torrent 文件(又叫做种子),里面包括announce(tracker URL)和文件信息。
下载的时候可以根据tracker URL去tracker 服务器拿到其它下载者(包括发布者)的IP,下载者根据种子的文件信息和对方交换没有的数据。而且通过下载块的hash验证码来验证准确性,不准确则重新下载。
一旦 tracker 服务器出现故障或者线路遭到屏蔽,BT 工具就无法正常工作了。
⑵DHT
Distributed Hash Table,有一种著名的 DHT 协议,叫Kademlia 协议:
它相当于一个朋友圈,假如我想买点吃的,我可以在我的朋友圈询问好友,好友然后通过他的朋友圈然后再询问,最终知道哪里有卖。
在一个DHT网络中每个节点都保存了一定的联系方式,但是肯定没有所有的联系方式。
任何一个BitTorrent 启动之后,在.torrent 文件可以找到一个node的列表,这些节点列表里肯定有我们可以联系上的,然后我们通过这个节点接入了一个DHT网络,然后我们计算这个文件的hash值来找到我们下载节点(这个下载节点不是唯一的,因而任意节点加入和离开都不影响整体网络),然后通过可以联系上的不断寻找,找到可以下载的节点。下载完之后我们这里也有了那个文件,最后告诉下载节点我们也有了,以后可以从我们这下载。
27.VPN
概述
全名Virtual Private Network,虚拟专用网,就是利用开放的公众网络,建立专用数据传输通道,将远程的分支机构、移动办公人员等连接起来
VPN原理
VPN 通过隧道技术在公众网络上仿真一条点到点的专线,是通过利用一种协议来传输另外一种协议的技术,
IPsec VPN 这是基于 IP 协议的安全隧道协议,为了保证在公网上面信息的安全,因而采取了一定的机制保证安全性
奇跡の山 发布了238 篇原创文章 · 获赞 13 · 访问量 1万+ 私信 关注标签:浏览器,请求,基础,网络,发送,DNS,服务器,客户端 来源: https://blog.csdn.net/qq_35812205/article/details/104409524
本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享; 2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关; 3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关; 4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除; 5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。