Java面试那点事——网络200305

1. http1.0 与 http1.1 的区别?什么是 keep-alive 模式?

  • 缓存处理,在 HTTP1.0 中主要使用 header 里的 If-Modified-Since,Expires 来做为缓存判断的标准,HTTP1.1 则引入了更多的缓存控制策略例如 Entity tag,If-Unmodified-Since, If-Match, If-None-Match 等更多可供选择的缓存头来控制缓存策略。

  • 带宽优化及网络连接的使用,HTTP1.0 中,存在一些浪费带宽的现象,例如客户端只是需要某个对象的一部分,而服务器却将整个对象送过来了,并且不支持断点续传功能,HTTP1.1 则在请求头引入了 range 头域,它允许只请求资源的某个部分,即返回码是 206(Partial Content),这样就方便了开发者自由的选择以便于充分利用带宽和连接。

  • 错误通知的管理,在 HTTP1.1 中新增了 24 个错误状态响应码,如 409(Conflict)表示请求的资源与资源的当前状态发生冲突;410(Gone)表示服务器上的某个资源被永久性的删除。

  • Host 头处理,在 HTTP1.0 中认为每台服务器都绑定一个唯一的 IP 地址,因此,请求消息中的 URL 并没有传递主机名(hostname)。但随着虚拟主机技术的发展,在一台物理服务器上可以存在多个虚拟主机(Multi-homed Web Servers),并且它们共享一个 IP 地址。HTTP1.1 的请求消息和响应消息都应支持 Host 头域,且请求消息中如果没有 Host 头域会报告一个错误(400 Bad Request)。

  • 长连接,HTTP 1.1 支持长连接(Persistent-Connection)和请求的流水线(Pipelining)处理,在一个 TCP 连接上可以传送多个 HTTP 请求和响应,减少了建立和关闭连接的消耗和延迟,在 HTTP1.1 中默认开启 Connection: keep-alive,一定程度上弥补了 HTTP1.0 每次请求都要创建连接的缺点。

    【Keep-Alive 模式】

    我们知道 HTTP 协议采用 “请求 - 应答” 模式,当使用普通模式,即非 KeepAlive 模式时,每个请求 / 应答客户和服务器都要新建一个连接,完成 之后立即断开连接(HTTP 协议为无连接的协议);**当使用 Keep-Alive 模式(又称持久连接、连接重用)**时,K eep-Alive 功能使客户端到服务器端的连接持续有效,当出现对服务器的后继请求时,Keep-Alive 功能避免了建立或者重新建立连接。启用 Keep-Alive 模式肯定更高效,性能更高。因为避免了建立 / 释放连接的开销。因此最好能维持一个长连接,可以用一个长连接来发多个请求。


2. 简单说一下 http2.0?

HTTP2.0 使用了多路复用的技术,做到同一个连接并发处理多个请求,而且并发请求的数量比 HTTP1.1 大了好几个数量级。

当然 HTTP1.1 也可以多建立几个 TCP 连接,来支持处理更多并发的请求,但是创建 TCP 连接本身也是有开销的。TCP 连接有一个预热和保护的过程,先检查数据是否传送成功,一旦成功过,则慢慢加大传输速度。因此对应瞬时并发的连接,服务器的响应就会变慢。所以最好能使用一个建立好的连接,并且这个连接可以支持瞬时并发的请求。


3. 什么是幂等性?http 的方法是否都符合幂等性?若不符合,怎么避免?

【幂等性】

HTTP 方法的幂等性是指一次和多次请求某一个资源应该具有同样的副作用。说白了就是,同一个请求,发送一次和发送 N 次效果是一样的!

【HTTP方法】

  • GET 方法用于获取资源,不应有副作用,所以是幂等的。

  • DELETE 方法用于删除资源,有副作用,但它应该满足幂等性。

  • PUT 方法用于创建或更新操作,有副作用,与 DELETE 相同,对同一资源无论调用一次还是多次,其副作用是相同的,因此也满足幂等性。

  • POST 方法与 PUT 方法的区别主要在于幂等性,POST 不具备幂等性,因为 POST 请求每次都会创建一个文件,而 PUT 方法会在服务器验证是否有 ENTITY,若有则更新该 ENTITY 而不是重新创建。

【POST方法避免非幂等性】

HTTP POST 操作既不是安全的,也不是幂等的(至少在 HTTP 规范里没有保证)。当我们因为反复刷新浏览器导致多次提交表单,多次发出同样的 POST 请求,导致远端服务器重复创建出了资源

  • 第一、对应的后端 WebService 一定要做到幂等性,

  • 第二、服务器端收到 POST 请求,在操作成功后必须返回状态码 302 重定向到另外一个页面,这样即使用户刷新页面,url 已经变更,不需要进行 post 请求,也不会重复提交表单。


4. https 与 http 的区别?https 加密的过程?

【区别】

Http 协议运行在 TCP 之上,明文传输,客户端与服务器端都无法验证对方的身份; HTTPS 是运行在 SSL/TLS 之上的 HTTP 协议,SSL/TLS 运行在 TCP 之上。HTTPS 是添加了加密和认证机制的 HTTP。二者之间存在如下不同:

  • 端口不同:Http 与 Https 使用不同的连接方式,用的端口也不一样,前者是 80,后者是 443;

  • 资源消耗:和 HTTP 通信相比,Https 通信会由于加减密处理消耗更多的 CPU 和内存资源;

  • 开销:Https 通信需要证书,而证书一般需要向认证机构购买

【加密过程】

  • 浏览器使用 Https 的 URL 访问服务器,建立 SSL 链接。

  • 服务器接收到 SSL 链接后,发送非对称加密的公钥 A 给浏览器。

  • 浏览器生成随机数,作为对称加密的密钥 B。

  • 浏览器使用服务器返回的公钥 A,对自己生成的对称加密密钥 B 进行加密,得到密钥 C。

  • 浏览器将密钥 C 发送给服务器

  • 服务器使用自己的非对称加密私钥 D 对接受的密钥 C 进行解密,得到对称加密密钥 B。

  • 浏览器和服务器之间使用密钥 B 作为对称加密密钥进行通信。


5. https 是否存在安全问题?如何避免?

【存在问题】

当服务器发送公钥给客户端, 中间人截获公钥 ,将 中间人自己的公钥 冒充服务器的公钥发送给客户端。之后客户端会用 中间人的的公钥 来加密自己生成的 对称密钥 。然后把加密的密钥发送给服务器,这时中间人又把密钥截取,中间人用自己的私钥把加密的密钥进行解密,解密后中间人就能获取 对称加密的密钥 。

注意:非对称加密之所以不安全,因为客户端不知道这把公钥是不是属于服务器的。

【避免】

一个拥有公信力、大家都认可的认证中心,数字证书认证机构。

服务器在给客户端传输公钥的过程中,会把公钥和服务器的个人信 息通过 hash 算法 生成 信息摘要 。

为了 防止信息摘要被调换 ,服务器会采用 CA 提供的私钥 对信息摘要进行加密来形成 数字签名 。最后会把原来没 Hash 算法之前的个人信息、公钥及、数字签名合并在一起,形成 数字证书。

客户端拿到 数字证书 之后,使用 CA 提供的公钥对数字证书里的数字签名进行解密来得到信息摘要,然后对数字证书里服务器的公钥及个人信息进行 Hash 得到 另一份信息摘要 。最后将两份信息摘要对比,如果一样则证明是服务器,否则就是中间人。


6. get方法和post方法的区别​?​

  • GET方法从服务器获取资源,POST是向服务器发送数据

  • GET 浏览器回退是无害的,而 POST 会再次提交请求。

  • GET 产生的 URL 地址可以被书签收藏,并且被浏览器缓存,而 POST 不能书签收藏也不能缓存。

  • GET 只能进行 URL 编码,而 POST 支持多种编码方式。

  • GET 参数通过 URL 传递,并且长度有限制,而 POST 放在 request body 并且长度没有限制。并且,正因为这个原因, GET 比 POST 更不安全,因为参数暴露在 URL 中。

二者还有一个显著区别:GET 产生一个 TCP 数据包;POST 产生两个 TCP 数据包。

  • 对于 GET 方式的请求,浏览器会把 http header 和 data 一并发送出去,服务器响应 200(返回数据);

  • 而对于 POST,浏览器先发送 header,服务器响应 100 continue,浏览器再发送 data,服务器响应 200 ok(返回数据)。


【Java 面试那点事】

这里致力于分享 Java 面试路上的各种知识,无论是技术还是经验,你需要的这里都有!

这里可以让你【快速了解 Java 相关知识】,并且【短时间在面试方面有跨越式提升】

面试路上,你不孤单!
在这里插入图片描述

发布了196 篇原创文章 · 获赞 878 · 访问量 30万+

猜你喜欢

转载自blog.csdn.net/qq_33945246/article/details/104633700