2.3.1http及https问题解析

一、http和https的区别

1、https需要到ca申请证书,一般免费的证书较少,故需要一定的费用
2、http是超文本传输协议,信息是明文传输;HTTPS则是具有安全性的ssl加密传输协议
3、http和HTTPS使用不同的连接方式,使用的端口也不一样,http使用的是80端口,HTTPS使用的则是443
4、http的连接很简单,是无状态的;HTTPS协议是由SSL和HTTP构建的可进行加密传输、身份认证的网络协议,比http要安全的多。

二、简单说说https是如何保证安全传输的

https 在三次握手,对服务端返回的证书,进行验签(比如证书是否ca机构颁发,有效期,是否吊销,根据ca公钥进行解密,
得到ca的对证书内容进行摘要的签名算法,同样使用该算法进行摘要,比较两个结果是否一致),然后基于会话中的三个随机数生成对称密钥,
用服务端公钥发送给服务端
数据的传输基于这个对称密钥进行加解密。

三、https是不是绝对安全的?有没有办法被破解?

不是,人为的安装不受信任的证书或者获取到服务器的证书进行重签

四、http无状态协议,怎么理解无状态协议。如何实现有状态的请求

1、无状态协议是指,服务端不保存客户端请求的任何数据
2、保证状态可以采用cookie+session的方式:首次客户端请求时,创建一个session,并保存用户信息,在响应头信息带有set-cookie报纸客户端保存cookie信息,客户端之后的请求带上cookie的session id,服务端获取存储session id保存的数据

五、说说http协议中的302状态码的作用

Found(已找到) 与状态码301类似。但这里的移除是临时的。 客户端会使用Location中给出的URL,重新发送新的HTTP request

六、304缓存原理

304 状态码 表示 客户端有缓冲的文档并发出一个条件性请求,服务器告诉客户端,原来缓冲文档还可以继续使用
服务端返回304状态码 主要包含 几个http头信息,请求头 if-none-match 响应头Etag 和响应头Cache-control
第一次请求服务器获取资源子厚把该资源缓存在本地,同时返回一个响应Etag,用来标识一个资源(内部资源不变,Etag不变),
客户端第二次请求,请求头if-none-match 告诉服务器自己已经有个Etag为xxx的资源,如果没有变化,服务器不用在返回该资源内容,直接返回304响应
告诉浏览器资源没有变化,缓存有效率,浏览器直接调用本地缓存(可以用来对图片做缓存)

七、http协议1.0和http协议1.1的区别

1、HTTP 1.1支持长连接(PersistentConnection)和请求的流水线(Pipelining)处理

HTTP 1.0规定浏览器与服务器只保持短暂的连接,浏览器的每次请求都需要与服务器建立一个TCP连接,服务器完成请求处理后立即断开TCP连接,服务器不跟踪每个客户也不记录过去的请求。

HTTP 1.1则支持持久连接Persistent Connection, 并且默认使用persistent connection. 在同一个tcp的连接中可以传送多个HTTP请求和响应. 多个请求和响应可以重叠,多个请求和响应可以同时进行. 更加多的请求头和响应头(比如HTTP1.0没有host的字段).

在1.0时的会话方式:

  1. 建立连接
  2. 发出请求信息
  3. 回送响应信息
  4. 关掉连接

HTTP 1.1的持续连接,也需要增加新的请求头来帮助实现,例如,Connection请求头的值为Keep-Alive时,客户端通知服务器返回本次请求结果后保持连接;Connection请求头的值为close时,客户端通知服务器返回本次请求结果后关闭连接。HTTP 1.1还提供了与身份认证、状态管理和Cache缓存等机制相关的请求头和响应头。

请求的流水线(Pipelining)处理,在一个TCP连接上可以传送多个HTTP请求和响应,减少了建立和关闭连接的消耗和延迟。例如:一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输,但每个单独的网页文件的请求和应答仍然需要使用各自的连接。 HTTP 1.1还允许客户端不用等待上一次请求结果返回,就可以发出下一次请求,但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果,以保证客户端能够区分出每次请求的响应内容。

2.HTTP 1.1增加host字段

在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址,因此,请求消息中的URL并没有传递主机名(hostname)。但随着虚拟主机技术的发展,在一台物理服务器上可以存在多个虚拟主机(Multi-homed Web Servers),并且它们共享一个IP地址。

HTTP1.1的请求消息和响应消息都应支持Host头域,且请求消息中如果没有Host头域会报告一个错误(400 Bad Request)。此外,服务器应该接受以绝对路径标记的资源请求。

3、100(Continue) Status(节约带宽)

HTTP/1.1加入了一个新的状态码100(Continue)。客户端事先发送一个只带头域的请求,如果服务器因为权限拒绝了请求,就回送响应码401(Unauthorized);如果服务器接收此请求就回送响应码100,客户端就可以继续发送带实体的完整请求了。100 (Continue) 状态代码的使用,允许客户端在发request消息body之前先用request header试探一下server,看server要不要接收request body,再决定要不要发request body。

4、HTTP/1.1中引入了Chunked transfer-coding来解决上面这个问题,发送方将消息分割成若干个任意大小的数据块,每个数据块在发送时都会附上块的长度,最后用一个零长度的块作为消息结束的标志。这种方法允许发送方只缓冲消息的一个片段,避免缓冲整个消息带来的过载。

5、HTTP/1.1在1.0的基础上加入了一些cache的新特性,当缓存对象的Age超过Expire时变为stale对象,cache不需要直接抛弃stale对象,而是与源服务器进行重新激活(revalidation)。

八、如何保证基于http协议的接口的安全性

1、选择拦截过滤器。
在请求的时候对请求方法进行一次拦截处理。比如非正常访问的方法已经注入插入可执行语句参数验证等在拦截中进行一次安全校验保证
请求不是非法请求。
2、数据加密。我们知道目前大部分APP接口都是通过Http协议进行调用的容易被抓包拦截。
我们可以对客户端和服务端都对数据传输的时候进行一个加密处理。常用的MD5 AES等。
3、签名
根据用户名或者用户id,结合用户的ip或者设备号,生成一个token。在请求后台,后台获取http的head中的token,校验是否合法(和数据库或者Redis中记录的是否一致,在登录或者初始化的时候,存入数据库/redis)
在使用Base64方式的编码后,Token字符串还是有20多位,有的时候还是嫌它长了。由于GUID本身就有128bit,在要求有良好的可读性的前提下,很难进一步改进了。那我们如何产生更短的字符串呢?还有一种方式就是较少Token的长度,不用GUID,而采用一定长度的随机数,例如64bit,再用Base64编码表示:

由于这里只用了64bit,此时得到的字符串为Onh0h95n7nw的形式,长度要短一半。这样就方便携带多了。但是这种方式是没有唯一性保证的。不过用来作为身份认证的方式还是可以的(如网盘的提取码)。

4、使用第三方框架与技术整合支持比如spring的框架中的oauth模块。

九、http协议上传文件,数据如何传输?

1、常见的手段是,对文件进行压缩,减少文件大小。那压缩和解压缩的流程怎么实现呢?
首先服务端需要能支持文件的压缩功能,其次浏览器能够针对被压缩的文件进行解压缩。浏览器可以指定 Accept-Encoding 来告诉服务器我当前支持的编码类型Accept-Encoding:gzip,deflate
那服务端会根据支持的编码类型,选择合适的类型进行压缩。常见的编码方式有:gzip/deflate/2、分割传输
在传输大容量数据时,通过把数据分割成多块,能够让浏览器逐步显示页面。这种把实体主体分块的功能称为分块传输编码(Chunked Transfer Coding)。

十、说说http协议的优缺点

简单 客户端请求服务端只需要知道服务器资源地址,请求的方法有get post put delete head(获取请求头信息)options(询问支持的请求方法)
灵活 : 允许传输任意类型的数据对象,可以通过accpet或者content-type 标记
无连接 :节约传输时间(每次处理一个请求,1.1 版本有持久化连接,解决请求过多时握手和挥手的性能开销)
无状态 : 减少不必要的数据传输。
缺点 : 超文本传输协议,基于明文传输。

十一、一次http请求的完整交互流程

用户在浏览器输入域名, 经过dns 解析成ip,返回对应的服务器进程,首先经过我们应用层加入http头, -> 传输层(tcp头 ),网路层 (ip头)- > 数据链路层(mac地址)-> 转换为0101在网卡上传输->目标服务器 层层把头取掉,拿到对应数据。处理完成返回客户端也经过一样的流程

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值