http和https协议面试题
1、http协议
-
1)是一个基于请求与响应的应用层协议,底层协议是TCP保证其可靠传输
-
2)通过url来进行客户端与服务器之间的交互(url的解释:统一资源定位符,用于定位互联网上的资源的位置;格式, 协议://主机名.域名:端口号/路径…?参数1=值1&参数2=值2&…#锚点)
-
3)是一种C/S(或者b/s,b/s是一种特殊的c/s)模式的协议,客户端发起请求,服务器接收请求并且处理然后做出响应
-
4)是一种无状态协议
2、什么是无状态,如何取弥补http无状态的缺陷
http协议有一个特性就是无状态,何为无状态。就是上一次的请求对这次的请求没有任何影响,服务端也不会对客户端上一次的请求进行任何记录处理。
http协议的无状态性带来的问题:用户登录后,切换到其他界面,进行操作,服务器端是无法判断是哪个用户登录的。 每次进行页面跳转的时候,得重新登录。
解决方案:token
3、https协议
HTTPS(Secure Hypertext Transfer Protocol)安全超文本传输协议
-
HTTPS是一个安全通信通道,基于HTTP开发,用于在客户计算机和服务器之间交换信息
-
HTTPS使用安全套接字层(SSL)进行信息交换,简单来说它是HTTP的安全办
-
HTTPS是有Netscape开发并内置于其浏览器中,用于对数据进行压缩和解压操作,并返回网络上传送的结果
-
HTTPS世界上应用了Netscape的安全套接字层SSL作为HTTP应用层的子层
-
HTTPS使用端口是443,而不是像HTTP那样使用端口80来和TCP/IP进行通信
SSL使用40位关键字作为RC4流加密算法,这对于商业信息的加密是合适的 -
HTTPS和SSL支持使用X.509数字认证
4、http和https协议有什么区别,各自有什么优势
相同点
- 都是采用同一个基础协议作为HTPP或HTTPS客户端—浏览器
- 设立一个连接到Web服务器指定的端口
- 服务器接收到请求,会返回一个状态码以及消息
- 系统使用统一资源定位器URI模式,因此资源可以被唯一指定
不同点
- HTTP的URL是以http://开头。HTTPS的URL是以https://开头
- HTTP是不安全的,HTTPS是安全的
- HTTP是80端口,HTTPS是443端口
- 在OSI网络模型中,HTTP处于应用层,HTTPS工作在传输层
- HTTP无需加密,HTTPS需要加密
- HTTP无需证书,HTTPS需要安装证书
总体来说,关键的区别在于https协议多了一层安全套接字
如何选择
加入为了安全保密,将一个网站所有的Web应用都启用SSL技术来加密,并使用HTTPS协议进行传输,那么该网站的性能和效率将会大大降低,而且没有这个必要,因为一般来说并不是所有数据都要求那么搞的安全保密级别,所以,我们只需对哪些设计机密数据的交互处理使用HTTPS协议
5、get请求和post请求的区别
-
1)GET的参数拼接在url后面,post的参数不在url中体现而是放在表单中提交
-
2)get请求的有最大提交限制(因为浏览器对url的长度有限制 1k),post没有
-
3)服务器接收请求,并且处理请求,然后将处理的结果响应给前端
-
4)判断数据是否还有传输,如果没有则通过四次挥手断开TCP链接
6、http常见的状态码及其含义
常见的http状态码
-
100:继续 客户端应当继续发送请求。客户端应当继续发送请求的剩余部分,或者如果请求已经完成,忽略这个响应。
-
101: 转换协议 在发送完这个响应最后的空行后,服务器将会切换到在Upgrade 消息头中定义的那些协议。只有在切换新的协议更有好处的时候才应该采取类似措施。
-
102:继续处理 由WebDAV(RFC 2518)扩展的状态码,代表处理将被继续执行。
-
200:请求成功 处理方式:获得响应的内容,进行处理
-
201:请求完成,结果是创建了新资源。新创建资源的URI可在响应的实体中得到 处理方式:爬虫中不会遇到
-
202:请求被接受,但处理尚未完成 处理方式:阻塞等待
-
204:服务器端已经实现了请求,但是没有返回新的信 息。如果客户是用户代理,则无须为此更新自身的文档视图。 处理方式:丢弃
-
300:该状态码不被HTTP/1.0的应用程序直接使用, 只是作为3XX类型回应的默认解释。存在多个可用的被请求资源。 处理方式:若程序中能够处理,则进行进一步处理,如果程序中不能处理,则丢弃
-
301:请求到的资源都会分配一个永久的URL,这样就可以在将来通过该URL来访问此资源 处理方式:重定向到分配的URL
-
302:请求到的资源在一个不同的URL处临时保存 处理方式:重定向到临时的URL
-
304:请求的资源未更新 处理方式:丢弃,使用本地缓存文件
-
400:非法请求 处理方式:丢弃
-
401:未授权 处理方式:丢弃
-
403:禁止 处理方式:丢弃
-
404:没有找到 处理方式:丢弃
-
500:服务器内部错误 服务器遇到了一个未曾预料的状况,导致了它无法完成对请求的处理。一般来说,这个问题都会在服务器端的源代码出现错误时出现。
-
501:服务器无法识别 服务器不支持当前请求所需要的某个功能。当服务器无法识别请求的方法,并且无法支持其对任何资源的请求。
-
502:错误网关 作为网关或者代理工作的服务器尝试执行请求时,从上游服务器接收到无效的响应。
-
503:服务出错 由于临时的服务器维护或者过载,服务器当前无法处理请求。这个状况是临时的,并且将在一段时间以后恢复。
7、cookie、session和jwt
了解这三者之间的区别于联系,首先要了解HTTP协议。
HTTP是无状态的协议,每个请求都是完全独立的,每次客户端和服务端会话完成时,服务端不会保存任何会话信息,服务端无法确认当前访问者的身份信息,因此也无法知道上一次的请求发送者和这一次的发送者是否为同一操作者。
所以服务器与浏览器为了进行会话跟踪(知道是谁在访问),就必须主动的去维护一个状态,这个状态用于告知服务端前后两个请求是否来自同一浏览器。而这个状态需要通过 cookie 或者 session 去实现。
假设用浏览器去登录一个网站,登陆完后服务器就会开启一个session,返回一个session ID给浏览器,,浏览器下次访问该网站的任何一个网页的时候,就会吧这个session ID放在cookie里发给服务器,服务器收到后就会识别是否有这么个session ID,如果有就可以浏览网站的其他页面,如果没有就需要重新登录
由于大型网站都有很多服务器,假设浏览器每次访问的都是不同的服务器,那么这个session就没法识别了,当然,可以做一个统一的专门存储session的服务器,来给所有服务器提供筛选session查询服务,但这样会存在session服务器单点失效的问题;如果把session服务器做成一个集群,成本和效率的开销就会很大。
而token很好的解决了这些问题,假设浏览器进行登录操作后,服务器提供一个token给浏览器,下次浏览器访问任何一个服务器,只需要提供这个token就可以了,这个token是经过服务器签名认证的,任何一个服务器都能识别这个签名,这也是token被翻译为令牌的原因
cookie
Cookie是将数据持久化存储到浏览器(客户端)的一种技术,它通常包含有关用户的信息,例如用户ID和过期时间。
- cookie 存储在客户端: cookie 是服务器发送到用户浏览器并保存在本地的一小块数据,它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。cookie中的信息是以键值对的形式储存在浏览器中,而且在浏览器中可以直接看到数据
- cookie 是不可跨域的: 每个 cookie 都会绑定单一的域名,无法在别的域名下获取使用,一级域名和二级域名之间是允许共享使用的(靠的是 domain)
session
session则是一种记录服务器和客户端会话状态的机制,是基于cookie实现的,在创建的一个会话对象存储在服务器中,用于存储用户的信息,例如用户ID和权限等
-
用户第一次请求服务器的时候,服务器根据用户提交的相关信息,创建对应的 Session,请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器
浏览器接收到服务器返回的 SessionID 信息后,会将此信息存入到 Cookie 中,同时 Cookie 记录此 SessionID 属于哪个域名 -
当用户第二次访问服务器的时候,请求会自动判断此域名下是否存在 Cookie 信息,如果存在自动将 Cookie 信息也发送给服务端,服务端会从 Cookie 中获取 SessionID,再根据 SessionID 查找对应的 Session 信息,如果没有找到说明用户没有登录或者登录失效,如果找到 Session 证明用户已经登录可执行后面操作。
jwt
JWT(JSON Web Token)是一种开放标准(RFC 7519),用于在不同应用程序之间安全地传输信息。与Cookie和Session相比,JWT具有状态无关性和可扩展性的优点,也可以通过简单的验证来保护数据的安全
jwt是目前比较流行的跨域认证解决方案,包含三个部分:
- 头部header:Header包含两个部分,token类型和加密算法,头部使用base64编码
- 负载payload:这一部分一般是存储自己定义的字段,常有过期时间,签发时间、用户信息, 这一部分也是使用base64编码
- 签名signature:对前两部分用header中指定算法进行加密,再进行base64加密
用户的状态不再存储在服务端的内存中,JWT是一种无状态的认证机制,JWT内部包含了一些会话信息,因此减少了需要查询数据库的需要。 JWT并不使用Cookie,所以你可以使用任何域名提供你的 API 服务而不需要担心跨域资源共享问题(CORS)
- 用户进行登录操作,服务端认证成功后,使用秘钥创建JWT,并返回给客户端
- 客户端将 JWT 保存到本地(通常存储到localstorage或sessionStorage)
- 当用户访问一个受保护的路由或者资源的时候,需要请求头的 Authorization 字段中使用Bearer 模式添加 JWT,服务端的保护路由将会检查请求头 Authorization 中的 JWT 信息,如果校验通过,则允许用户的行为
cookie、session和jwt的相同点
三者都是应用在web中对http无状态协议的补充,达到状态保持的目的
cookie、session和jwt的区别
Cookie存储在客户端,Session存储在服务器端,JWT是一种在客户端和服务器之间传输信息的机制。Cookie和Session都是由服务器来管理的,而JWT则是由客户端来管理的。
cookie、session和jwt的优缺点
Cookie的优点是灵活,易于使用和实现。缺点是在跨域请求和跨站点请求时可能会存在安全漏洞。
Session的优点是相对安全,数据存储在服务器端,但会占用服务器资源。缺点是在分布式系统中使用不方便,难以扩展。
JWT的优点是可扩展性和安全性高,缺点是没有状态,需要在客户端中存储信息。