java学习——网络

上一篇传送门：点我

一些java知识体系中常见的计算机网络问题整理。

说说http和https的区别

HTTP和HTTPS的主要区别在于安全性、传输协议和端口不同，其中最主要的区别是在安全性上。

从安全性方面来看，HTTP协议传输的内容都是明文，客户端和服务器端都无法验证对方的身份，因此存在安全风险，不适合传输敏感信息。而HTTPS协议通过SSL/TLS加密技术，对传输的数据进行加密，确保数据在传输过程中的安全性。同时，HTTPS还通过证书认证机制，验证服务器的身份，防止中间人攻击。

从传输协议方面来看，HTTP是运行在TCP之上的明文传输协议，而HTTPS则是基于HTTP协议构建的，但增加了SSL/TLS握手过程，用于建立加密通道。因此，HTTPS协议在传输数据之前，需要先进行SSL/TLS握手，协商加密参数和生成会话密钥等。

从端口方面来看，HTTP默认使用80端口进行通信，而HTTPS则默认使用443端口。这是因为HTTPS需要在传输层之上增加一层加密层，因此需要使用不同的端口来区分HTTP和HTTPS流量。

get和post请求有什么区别？

我理解的get和post请求区别有以下几点：

从数据传输方式来看，get请求将请求参数附加在url之后，通过查询字符串的方式进行传输。这意味着请求的数据会暴露在url中，可能会被保存在浏览器的历史记录、日志或网络抓包工具中，因此存在安全风险。而post请求会将请求参数放在请求体中传输，不会在url中显示。

从安全性角度来看，由于get请求的参数暴露在url中，容易被恶意用户篡改或利用，从而引发安全问题。而post请求通过请求体传输数据，可以在一定程度上防止参数被篡改。然而，需要注意的是，post请求本身并不提供数据加密功能，如果需要确保数据的安全性，还需要结合https等加密协议来使用。

从数据大小限制方面来看，get请求的数据大小受到url长度的限制，因为浏览器和服务器对url的长度有一定的限制。这意味着get请求不适合传输大量数据。而post请求的数据大小限制相对较大，可以传输更多的数据。

总的来说，get请求适用于获取数据或查询信息的场景，而post请求适用于提交数据或更新资源的场景。

osi七层模型是什么？

408常考的基础知识。记住口诀：“物联网淑慧试用”。

OSI七层模型是一种网络通信框架，它将网络通信过程划分为七个层次，分别是物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。

物理层负责在物理媒体上实现比特流的透明传输，涉及电子及物理设备的规范，如网线的接口类型、光纤的接口类型等。

数据链路层则负责将网络层传下来的数据报组装成帧，以及运行数据的调试、重传或修正等工作。

网络层负责将数据传送的目的地寻址，并选择出传送数据的最佳路线。网络层的主要任务是将分组从源端传到目的端，为分组交换网上的不同主机提供通信服务。

传输层负责主机中两个进程的通信，即端到端的通信。传输层定义了传输数据的协议和端口号，如TCP和UDP协议。TCP协议提供可靠的、面向连接的通信服务，而UDP协议则提供不可靠的、无连接的通信服务。

会话层负责建立、管理和终止会话，为通信双方制定通信方式。表示层则负责数据的编码和转换，以确保数据能够被应用层识别。

应用层是与用户直接交互的层次，它提供了各种网络服务，如FTP、Web浏览、电子邮件等。（HTTP和HTTPS是应用层协议）

UDP和TCP的区别

TCP（传输控制协议）和UDP（用户数据报协议）是传输层中的两个主要的协议，它们之间的区别如下：
1.TCP是一种面向连接的协议，而UDP是无连接的。在使用TCP进行通信之前，必须先建立连接，即进行三次握手的过程。而UDP则不需要这样的连接过程，它可以直接发送数据。
2.TCP提供可靠 的数据传输服务，UDP不提供可靠 的数据传输服务。TCP在数据传输过程中会通过确认应答、连接管理、重发控制等机制去确保传输的数据是可靠的，而对于UDP而言，UDP会尽最大努力交付数据，但不保证数据能够成功到达目的地，因此UDP的数据传输不可靠。
3.TCP是面向字节流传输的，而UDP则是基于数据报的传输方式。在TCP中，发送方和接收方之间的数据可以像水流一样连续不断地传输。对于UDP，每个数据报都是独立传输的，与前后的数据报没有关联。
4.TCP连接只能是点到点、一对一的通信，而UDP支持一对一、一对多、多对一和多对多的交互通信。这使得UDP在某些场景下更具灵活性，例如广播、多播等应用。
4.UDP的数据传输速度相比TCP会更快。这是因为UDP不需要建立和维护连接状态，仅仅是尽最大努力交付数据，这使得UDP更适用于如视频通话这样需要更低的时延、更高的实时性的场景。

TCP连接的三次握手和四次挥手（重点！！！）

TCP连接的三次握手和四次挥手是TCP协议中建立连接和终止连接的关键过程。

三次握手用于建立TCP连接。在这个过程中，客户端首先发送一个SYN报文给服务器，请求建立连接。然后，服务器接收到SYN报文后，会发送一个ACK和SYN报文作为回应，表示已经收到请求并准备好建立连接。最后，客户端再次发送一个ACK报文给服务器，以确认服务器的回应，此时连接建立完成。这个过程之所以需要三次握手，是为了确保双方都有发送和接收数据的能力，从而建立一个可靠的连接。

四次挥手用于终止TCP连接。当一方完成数据传输后，会发送一个FIN报文给另一方，表示希望关闭连接。对方收到FIN报文后，会发送一个ACK报文进行确认。然后，对方也发送一个FIN报文给原始发送方，表示同意关闭连接。最后，原始发送方发送一个ACK报文确认对方的FIN报文，然后再等待2MSL（Maximum Segment Lifetime，报文最长存活时间），此时连接关闭完成。四次挥手的过程是为了确保双方都能够正确地关闭连接，避免出现数据丢失或重复传输的情况。

图片来源：https://baijiahao.baidu.com/s?id=1618114723935605183&wfr=spider&for=pc

为什么四次挥手之后还需要等待2MSL？

在TCP的四次挥手过程中，最后一步是客户端在发送最后一个ACK报文给服务器后，需要等待2MSL才能正式关闭连接。四次挥手后需要等待2MSL的原因有以下几点：
1.MSL是TCP报文段在网络中的最长存活时间，等待2MSL可以确保在网络中迷失的报文段都已经消失，从而避免已失效的报文段对后续新连接造成干扰。换句话说，这个等待时间是为了保证在关闭连接后，所有关于这个连接的报文都已经从网络中消失。
2.等待2MSL还可以确保服务器能够正常接收到客户端发送的最后一个ACK报文。如果客户端在发送ACK后立即关闭连接，而该ACK报文由于网络延迟等原因未能及时到达服务器，那么服务器可能会因为未收到ACK而重新发送FIN报文，导致不必要的混乱。
3.等待2MSL也是为了避免“已失效的连接请求报文段”对新的连接造成干扰。当客户端发送最后一个ACK之后，如果立即释放关闭，然后再次发起一个新的连接请求，这个新的连接请求可能会与网络中残留的FIN报文或FIN的ACK报文发生混淆，从而导致新的连接建立失败或者出现其他问题。

之所以是2MSL而不是1MSL是因为需要考虑网络的波动问题，等待2MSL可以给报文足够的时间缓冲，从而确保因各方面原因滞留在网络中的失效报文有足够的时间超时并丢弃，以确保网络的稳定性和可靠性。

TCP建立连接为什么是三次握手？

如果TCP连接只有两次握手，当第二次握手结束后，客户端知道服务器能够正常接受到自己发送的数据，但服务器此时还并不知道客户端是否能够收到自己发送的数据。
建立第三次握手可以防止第一次握手时的网络拥塞，避免重传信号建立连接后，被阻塞的信号又传到服务端，服务端会误以为客户端想重新建立连接；同时也可以防止第二次握手的信号丢失，也避免了服务端已建立与客户端的连接，但是客户端没有建立与服务端的连接从而占用服务端资源的问题。

不设置更多的握手是因为，三次握手是能够保证通信可靠的最小握手次数，为了尽可能提高通信效率，没有必要设置更多的握手。

TCP关闭连接为什么需要四次挥手？

TCP关闭连接需要四次挥手，这是因为TCP连接是全双工的，即双方都可以同时发送和接收数据。当一方完成数据传输并发送FIN报文请求关闭连接时，它只能保证自己不再发送数据，但仍然可以接收对方的数据。因此，对方需要发送ACK报文进行确认，表示已经收到了关闭请求。然后，对方可能还有数据需要发送，所以在发送完所有数据后，再发送自己的FIN报文表示同意关闭连接。最后，主动关闭方发送ACK报文确认对方的FIN报文，确保双方都知道了关闭请求的确认。

HTTP1.0、HTTP1.1、HTTP2.0、HTTP3.0之间的区别

HTTP 1.0、1.1、2.0和3.0是HTTP协议的不同版本，它们之间存在一些关键的区别和改进。
HTTP 1.0：每次请求都需要新建TCP连接，请求完成后断开，不支持持久连接和管道化请求，效率较低。
HTTP 1.1：引入了持久连接和管道化请求，允许多个请求在同一个TCP连接上同时连续发送，提高了并发性能和效率。
HTTP 2.0：在1.1基础上，通过二进制分帧层和多路复用技术进一步优化了并发性能，同时使用了头部压缩减少传输开销。
HTTP 3.0：改用UDP协议替换原本的TCP协议，降低了延迟，提升了并发性能；同时通过QUIC协议和TLS加密增强了安全性，但需要通过其他机制保证数据的可靠性。

HTTP既然无状态为什么还有状态码？

HTTP协议是无状态协议，这里的HTTP无状态是指它的每个请求都是独立的，服务器不会保留之前请求或响应的信息。
而状态码是HTTP响应的一部分，它表示的是请求的处理结果。它们提供了关于请求是否成功、出现错误或需要进一步操作的信息。状态码不是用来跟踪客户端的状态，而是用来传达请求处理的结果。

HTTP常见状态码有哪些？

HTTP状态码可以分为五大类：

1XX： 消息状态码，服务器收到请求，需要请求者继续执行操作。(相对不常见)

2XX： 成功状态码，操作被成功接收并处理。
200： 表示服务器响应成功，也就是服务器找到了客户端请求的内容，并且将内容返回给客户端。

3XX： 重定向状态码，需要进一步的操作以完成请求。
301： 永久性重定向（跳转）。值得注意的是，这种重定向跳转，从严格意义来讲不是服务器跳转，而是客户端跳转的。这个“跳”的动作是服务器是通过回传状态码301来下达给客户端的，让客户端完成跳转。
302： 临时跳转。例如：URL地址A可以向URL地址B上跳转，但这并不是永久性的，在经过一段时间后，URL地址A还可能向URL地址C上跳转。

4XX： 客户端错误状态码，请求包含语法错误或无法完成请求。
400： 错误请求。客户端请求的语法错误，服务器无法理解请求。
403： 服务器理解但拒绝执行客户端的请求，可能是请求的服务器资源不够。
404： 服务器上找不到该资源，或者说服务器找不到客户端请求的资源，是最常见的请求错误码，url路径有误经常会报此错误。

5XX： 服务端错误状态码，服务器在处理请求的过程中发生了错误，一般是后端代码逻辑的问题。
500： 服务器内部错误。也就是说请求的网页程序本身报错了，一般是由于后端代码逻辑的问题导致服务器端出现错误。由于现在的浏览器都会对状态码500做一定的处理，所以在一般情况下会返回一个定制的错误页面。
502： 网关错误。作为网关或者代理工作的服务器尝试执行一个请求时，从远程服务器接收到了一个无效的相应。

输入URL网址到前端页面显示的过程（常问的重点！！！）

1.URL解析： 浏览器首先解析用户输入的URL，确定所使用的协议（如http://或https://），域名（或IP地址），端口号（如果有的话，且不是默认端口），以及路径（页面或资源的具体位置）。
2.DNS查询： 浏览器首先检查本地缓存是否有该域名的IP地址记录。如果没有，浏览器会向DNS服务器发出查询请求，以获取域名对应的IP地址。
3.建立TCP连接： 一旦获取到IP地址，浏览器会尝试与该IP地址的服务器建立TCP连接。这通常涉及“三次握手”过程，以确保连接的稳定性和可靠性。
4.发送HTTP请求： 在TCP连接建立后，浏览器会构建一个HTTP请求报文，并通过连接发送给服务器。这个请求报文包括请求行（指定HTTP方法、请求资源的路径和HTTP协议版本）、请求头部（包含各种元信息和浏览器设置）以及可能的请求体（如POST请求中的数据）。
5.服务器处理请求： 服务器接收到HTTP请求后，会根据请求行中的信息定位到相应的资源（如HTML文件、图片、脚本等）。服务器会读取资源的元数据，并根据需要执行相应的逻辑处理。服务器构建HTTP响应报文，包括状态行（指示请求的处理结果）、响应头部（包含资源的元信息和服务器设置）以及响应体（包含实际的资源内容）。
6.发送HTTP响应： 服务器将构建好的HTTP响应报文发送回浏览器。这通常是通过之前建立的TCP连接进行的。
7.浏览器解析渲染页面： 浏览器接收到HTTP响应后，会首先检查状态码以确定请求的处理结果（如200 OK表示成功）。浏览器解析响应头部，获取资源的元信息和编码方式等。之后浏览器会解析响应体中的资源内容，当所有资源都加载完成后，浏览器会进行渲染操作，最终在页面上显示出完整的网页内容。
8.连接关闭： 在数据传输完成后，浏览器和服务器会通过“四次挥手”过程关闭TCP连接，释放资源。如果服务器支持持久连接，则连接可能会保持一段时间以供后续请求复用。

说说什么是Cookie？什么是Session？

Cookie是客户端浏览器用来保存服务端数据的一种机制，当我们通过浏览器去进行网页访问的时候，服务器可以把某一些状态数据以key-value的形式写入到Cookie里面从而存储到客户端浏览器，然后客户端下一次再访问服务器的时候，可以携带这一些状态数据发送到服务器端，服务器端可以根据Cookie里面携带的内容去识别使用者。
Session则表示一个会话，它是属于服务器端的一个容器对象，默认情况下，针对每一个浏览器的请求，Servlet容器都会分配一个Session对象，Session本质上可以认为是一个ConcurrentHashMap，它可以用来存储当前会话产生的一些状态数据。Http协议本身是一个无状态协议，也就是说服务器端其实并不知道客户端发送过来的多次请求是属于同一用户，所以Session是用来弥补Http无状态的不足，简单来说，服务器端可以利用Session来存储客户端在同一个会话里面产生的多次请求的记录。
结合服务端的Session存储机制与客户端的Cookie机制，就可以去实现一个有状态的Http协议。客户端第一次访问服务器端的时候，服务端会针对这次请求创建一个会话，并且生成一个唯一的SessionId来标注这个对话，然后服务器端把这个SessionId写入到客户端浏览器的Cookie里面，用来去实现客户端状态的保存，在后续的请求中，每一次都会携带SessionId，服务器端就可以根据SessionId来识别当前会话的状态。

使用Token进行用户身份验证的流程

1.用户登录：首先，用户在客户端（如Web应用、移动应用等）输入用户名和密码进行登录。
2.密码验证：客户端将用户名和密码发送到服务器进行验证。服务器会检查用户名和密码是否匹配存储在数据库中的信息。
3.生成Token：如果用户名和密码验证成功，服务器会生成一个Token。这个Token通常是一个包含用户信息和过期时间的加密字符串，用于在后续请求中标识用户身份。
4.返回Token：服务器将生成的Token返回给客户端。
5.客户端存储Token：客户端接收到Token后，通常会将其存储在某个安全的地方，如浏览器的localStorage、sessionStorage或者Cookie中，以便后续请求使用。
6.后续请求携带Token：当客户端需要向服务器发送请求以获取受保护资源时，它会在请求头中携带之前获得的Token。
7.服务器验证Token：服务器接收到请求后，会提取请求头中的Token，并验证其有效性。验证过程可能包括检查Token的签名、过期时间以及是否已被撤销等。
8.授权访问：如果Token验证成功，服务器会根据Token中包含的用户信息来授权访问请求的资源。如果验证失败，服务器可能会返回一个错误响应，要求客户端重新进行身份验证。

什么是JWT？为什么要选择JWT？

JWT（Json Web Token）是一种开放标准的令牌格式，它定义了一种在网络之间安全地传输信息的方式。JWT由三部分组成：
1.Header，它由token的类型（“JWT”）和签名算法（如“HS256”）组成；
2.Payload，它包含了需要传输的数据；
3.Signature，它是对前两部分数据的签名，用于验证数据的完整性和来源。
JWT的主要优势在于其无状态性，服务器端不需要保存任何会话数据，只需要验证令牌的有效性即可，这使得JWT非常适合用于分布式架构。同时，JWT也支持自定义声明，可以灵活地传输各种类型的数据。
选择JWT的原因主要有几点原因：
1.JWT是无状态的，这使得系统具有更好的可扩展性和可靠性；
2.JWT通过签名机制保证了令牌的安全性和完整性；
3.JWT 基于JSON格式，具有很高的灵活性，可以根据业务需求自定义有效载荷中的属性；
4.JWT还适用于跨域身份验证的场景。这些特点使得JWT成为了一个高效、安全且灵活的身份验证和授权解决方案。

对称加密和非对称加密有什么区别？

对称加密是指加密和解密过程使用同一个密钥，优点是运算速度比较快，常见的算法有DES和AES，而非对称加密使用的是不同的密钥，也成为公钥和私钥，公钥和私钥是成对存在的，如果是公钥对数据进行加密，那只有对应的私钥才能解密，反之如果采用私钥加密，那么只有对应的公钥才能解密，常见的非对称算法有RSA，由于非对称算法会带来一定的性能开销，所以对于非对称加密的场景来说，一般是与外部系统对接时，为了保证数据传输的安全性而使用的加密算法。

过滤器和拦截器的区别

1.执行的顺序不同：过滤器是Servlet容器接收到请求之后，但是在Servlet被调用之前运行的，而拦截器则是在Servlet被调用之后，但是在响应被发送到客户端之前运行的；
2.配置方式不同：过滤器是在web.xml里面进行配置，而拦截器是在Spring的配置文件中进行配置抑或是使用注解的方式进行配置的；
3.Filter依赖于Servlet容器，而Interceptor不依赖于Servlet容器；
4.Filter在过滤器中只能对request和response进行操作 ，而Interceptor可以对request、response、handler、modeAndView、exception进行操作，相当于Interceptor多了对于SpringMVC组件的操作能力。

下一篇传送门：点我