1/30每日一题

从输入 URL 到页面展示到底发生了什么？

1. 输入 URL 与浏览器解析

• 当你在浏览器地址栏输入 URL 并按下回车，浏览器首先会解析这个 URL（统一资源定位符），比如 https://www.example.com。
• 浏览器会解析这个 URL 中的不同部分：
  • 协议（如：http 或 https）：决定了数据传输的方式和安全性。
  • 域名（如：www.example.com）：确定请求的目标服务器。
  • 路径（如：/index.html）：指定了服务器上的资源位置。
  • 查询参数（如果有）：如：?id=123&sort=desc，用于传递额外的信息。

2. DNS 解析

• 浏览器将 URL 中的域名（如 www.example.com）转换成服务器的 IP 地址。这个过程叫做DNS（域名系统）解析。

3. 建立 TCP 连接

• 一旦得到 IP 地址，浏览器就会与目标服务器建立一个 TCP 连接，通常通过 3 次握手的过程。
  1. 客户端（浏览器）发送 SYN 请求（同步标志位）。
  2. 服务器返回 SYN-ACK（确认响应）。
  3. 客户端再次发送 ACK（确认标志）。
• 如果使用的是 HTTPS，还会进行 TLS/SSL 握手，保证数据传输的加密性。

4. 发送 HTTP 请求

5.服务器响应​

三次握手的过程，以及为什么是三次，而不是四次，两次？

三次握手的过程

1. 第一次握手（客户端 → 服务器）

   • 客户端向服务器发送一个 SYN（同步）标志位的 TCP 数据包，表示客户端请求建立连接。
   • 同时，客户端会选择一个初始序列号（ISN，Initial Sequence Number），这个序列号是一个随机生成的数字，用于后续的数据传输中的数据包排序和确认。

2. 第二次握手（服务器 → 客户端）

   • 服务器收到客户端的 SYN 包后，响应一个 SYN-ACK（同步-确认）标志位的 TCP 数据包，表示服务器同意建立连接。
   • 服务器会选择自己的初始序列号，并将客户端的序列号加 1，作为 ACK（确认）号返回给客户端。此时，服务器也等待客户端的确认。

3. 第三次握手（客户端 → 服务器）

   • 客户端收到服务器的 SYN-ACK 包后，发送一个 ACK（确认）标志位的 TCP 数据包，表示客户端已经收到了服务器的响应。
   • 客户端将服务器的序列号加 1，作为确认号发送给服务器。
   • 至此，客户端和服务器都确认了对方的存在和初始序列号，连接建立完成。

为什么是三次握手，而不是两次或四次？

1. 为什么不是两次握手？

如果只有两次握手，就无法保证服务器是否准备好接收数据。假设只有两次握手的过程：

• 第一次握手：客户端发送 SYN 请求。
• 第二次握手：服务器收到 SYN 包后直接返回 SYN-ACK 包。

这种情况下，客户端无法确认服务器是否成功接收了请求，也无法确认服务器是否准备好接收数据。如果只有两次握手，可能会出现服务器无法接收数据的情况，或者服务器错误地认为客户端已经收到了响应。

三次握手通过客户端和服务器的互相确认，确保了双方的准备状态，避免了这种情况的发生。

2. 为什么不是四次握手？

四次握手实际上是不必要的，因为在三次握手中，双方已经充分确认了对方的状态。四次握手会增加额外的网络延迟和开销，而且在大多数情况下并不需要。

1. 四次挥手的过程，以及为什么是四次？

**四次挥手（Four-Way Handshake）**是 TCP 协议中断开连接的过程。它用于确保通信双方都能正确地关闭连接，并且所有未发送的数据能够顺利传输。四次挥手的过程涉及到双方发送和确认的多个信号，确保连接断开是安全和完整的。

四次挥手的过程

1. 第一次挥手（客户端 → 服务器）

   • 客户端向服务器发送一个 FIN（结束）标志位的 TCP 数据包，表示客户端已经没有数据要发送了，准备关闭连接。
   • 这个 FIN 数据包的序列号是客户端发送的最后一个字节的序列号。

2. 第二次挥手（服务器 → 客户端）

   • 服务器收到客户端的 FIN 包后，表示同意关闭连接，返回一个 ACK（确认）标志位的 TCP 数据包，确认客户端的请求。
   • 这个 ACK 数据包的确认号是客户端 FIN 包的序列号 + 1，表示服务器收到了客户端的关闭连接请求。
   • 此时，连接的一个方向（客户端 → 服务器）已经关闭，服务器还可以继续向客户端发送数据。

3. 第三次挥手（服务器 → 客户端）

   • 服务器发送完自己的数据后，准备关闭连接，会向客户端发送一个 FIN 包，表示服务器也没有数据要发送了，准备关闭连接。
   • 这个 FIN 包的序列号是服务器发送的最后一个字节的序列号。

4. 第四次挥手（客户端 → 服务器）

   • 客户端收到服务器的 FIN 包后，确认服务器已经没有数据要发送了，发送一个 ACK（确认）标志位的 TCP 数据包，表示客户端同意关闭连接。
   • 这个 ACK 数据包的确认号是服务器 FIN 包的序列号 + 1，表示客户端已经收到了服务器的关闭请求。
   • 至此，客户端和服务器都确认连接已经完全关闭，连接进入 TIME_WAIT 状态，最终关闭。

1. TCP与UDP的概念，特点，区别和对应的使用场景？

TCP（传输控制协议）和UDP（用户数据报协议）是互联网上两种常见的传输层协议

TCP（Transmission Control Protocol）是一种面向连接的、可靠的传输层协议。它提供了数据传输的完整性，确保数据包按顺序、无误地传输。

特点

1. 面向连接：在数据传输开始前，必须先通过“三次握手”建立连接，通信双方确认连接的存在后才能开始数据传输。
2. 可靠性：通过数据确认、重传、流量控制、拥塞控制等机制确保数据传输的可靠性。
3. 数据顺序：确保数据按发送顺序到达接收方，避免数据乱序。
4. 流量控制：TCP 使用滑动窗口机制进行流量控制，避免发送方过快地发送数据导致接收方缓冲区溢出。
5. 拥塞控制：TCP 具有拥塞控制机制（如慢启动、拥塞避免、快速重传等），防止网络拥塞。
6. 数据完整性：TCP 为每个数据段提供校验和，确保数据传输的完整性。

优点

• 提供可靠的数据传输，确保数据无误并按顺序到达。
• 可以自动重传丢失的包。

缺点

• 相对较慢，因需要连接建立、确认、重传等过程。
• 占用较多的网络资源，因为每个连接都需要维护连接状态。

使用场景

• 网页浏览：HTTP、HTTPS协议基于TCP，确保网页内容的完整性和顺序加载。
• 文件传输：FTP、SFTP等协议用于文件上传/下载，需要保证数据传输的可靠性。
• 电子邮件：如SMTP、POP3和IMAP等协议，保证电子邮件内容传输的完整性。
• 视频会议：如Zoom、Skype等，保证视频数据按顺序到达，减少中断和错误。

二、UDP（用户数据报协议）

概念

UDP（User Datagram Protocol）是一个无连接、尽力而为的传输层协议。它不保证数据的可靠传输，发送方将数据发送到网络中，并不关心接收方是否收到。

特点

1. 无连接：UDP 不需要建立连接，数据传输前不进行连接的建立与确认，发送方和接收方不需要同步。
2. 不可靠性：UDP 不提供错误检测和修复机制。如果数据包丢失、乱序或损坏，UDP 不会重新发送。
3. 无流量控制：UDP 不会控制数据的发送速度，不关心接收方的接收能力。
4. 无拥塞控制：UDP 不会处理网络拥塞问题，可能导致网络过载。
5. 低开销：没有建立连接、确认等过程，减少了协议的开销。

优点

• 协议开销小，传输速度快。
• 延迟低，适合对实时性要求高的应用。

缺点

• 不保证数据传输的可靠性，数据包丢失、重复或乱序无法保证。
• 不提供流量控制和拥塞控制，可能会造成丢包和网络过载。

使用场景

• 实时通信：如VoIP（语音通话）、视频直播、视频会议等，要求低延迟，但可以容忍少量的数据丢失。
• DNS查询：域名解析时使用UDP，响应快速，且请求和响应数据小，丢失一个数据包可以重新发起请求。
• 在线游戏：多人游戏常用UDP，因为要求低延迟，玩家位置等数据的实时性远比数据的可靠性更重要。
• 流媒体传输：如实时视频、音频流等，UDP 可以提供低延迟的传输，部分丢包也能接受。

HTTP常见状态码

HTTP状态码是Web服务器响应请求时，服务器向客户端发送的数字代码，用于表示请求的处理结果。状态码分为五类，分别对应不同的意义。

1. 1xx（信息性状态码）

这些状态码表示请求已被接收，正在处理。

• 100 Continue：表示客户端应继续发送请求数据。
• 101 Switching Protocols：表示服务器已经理解了客户端的请求，并且正在切换协议。

2. 2xx（成功状态码）

这些状态码表示请求已成功被服务器接收、理解和处理。

• 200 OK：请求成功，通常用于 GET 和 POST 请求。
• 201 Created：请求成功并且服务器已创建了新的资源。
• 202 Accepted：请求已接受，但尚未处理完成。
• 204 No Content：请求成功，但没有返回任何内容（如删除操作）。
• 205 Reset Content：请求成功，要求客户端重置视图。
• 206 Partial Content：部分内容响应，通常用于断点续传或部分请求的情况。

3. 3xx（重定向状态码）

这些状态码表示客户端需要进一步操作才能完成请求。

• 301 Moved Permanently：请求的资源已被永久移动到新的 URL。
• 302 Found：请求的资源临时性地被移动到新的 URL。
• 303 See Other：客户端应访问其他位置的 URL 进行获取资源。
• 304 Not Modified：请求的资源未修改，客户端可以使用缓存的版本。
• 307 Temporary Redirect：请求的资源临时转移，客户端应继续使用原始 URL。
• 308 Permanent Redirect：请求的资源永久转移，客户端应使用新的 URL。

4. 4xx（客户端错误状态码）

这些状态码表示客户端发出的请求存在错误。

• 400 Bad Request：请求无效或无法理解，通常是客户端发送的数据格式不对。
• 401 Unauthorized：请求要求用户的身份验证，未提供或提供的认证信息无效。
• 403 Forbidden：服务器理解请求，但拒绝执行请求。
• 404 Not Found：请求的资源不存在，URL 错误或者服务器上没有该文件。
• 405 Method Not Allowed：请求方法不被允许，客户端请求了一个不支持的 HTTP 方法。
• 408 Request Timeout：请求超时，服务器等待客户端发送请求时超时。
• 409 Conflict：请求与服务器的当前状态发生冲突。
• 410 Gone：请求的资源不再可用，且服务器不会再提供。
• 411 Length Required：需要 Content-Length 头部，缺失时无法处理请求。
• 413 Payload Too Large：请求实体过大，无法处理。
• 414 URI Too Long：请求的 URI 太长，服务器无法处理。
• 415 Unsupported Media Type：请求的媒体类型不被支持。
• 429 Too Many Requests：客户端发送的请求次数过多，服务器认为超出了限制。

5. 5xx（服务器错误状态码）

这些状态码表示服务器遇到错误，无法完成请求。

• 500 Internal Server Error：服务器内部错误，无法完成请求。
• 501 Not Implemented：服务器不支持请求的方法。
• 502 Bad Gateway：服务器作为网关或代理时，收到无效响应。
• 503 Service Unavailable：服务器当前无法处理请求，通常是由于过载或维护。
• 504 Gateway Timeout：网关或代理未能及时从上游服务器获取响应。
• 505 HTTP Version Not Supported：服务器不支持请求中所使用的 HTTP 版本。

1. == 和 equals() 的区别

== 和 equals() 都是用于比较对象的，但是它们的比较方式有所不同，适用于不同的场景。

==：

• 比较的是引用地址：== 用于比较两个对象的内存地址，即它比较的是两个对象是否指向同一个内存位置（是否是同一个对象）。

• 对于基本数据类型，== 比较的是值。

equals()：

• 比较的是对象的内容：equals() 用于比较两个对象的内容是否相等。在 Java 中，String 类重写了 equals() 方法，比较的是字符串的内容。

• 如果类没有重写 equals() 方法，默认使用 Object 类的 equals() 方法，实际上和 == 一样，比较的是内存地址。

总结：

• == 比较对象的内存地址（引用是否相同）。
• equals() 比较对象的内容（值是否相同）。

String, StringBuilder, StringBuffer 的区别

在 Java 中，String、StringBuilder 和 StringBuffer 都是用于处理字符串的类，但它们的特点和使用场景有所不同。以下是它们的主要区别：

1. String

• 不可变性（Immutable）：

  • String 是不可变的，一旦创建后，字符串内容不能更改。如果对一个 String 对象进行修改（如拼接、替换），会创建一个新的 String 对象。
  • 由于不可变性，String 对象在多线程环境下是线程安全的，因为它的内容不会被改变。

2. StringBuilder

• 可变性（Mutable）：

  • StringBuilder 是可变的，它允许在原有字符串的基础上进行修改，而不创建新的对象。它的内容可以被改变（如拼接、替换等），但不会生成新的对象。

• 线程安全性：

  • StringBuilder 不是线程安全的。如果多个线程同时操作同一个 StringBuilder 对象，可能会引发线程安全问题

3. StringBuffer

• 可变性（Mutable）：

  • StringBuffer 和 StringBuilder 类似，都是可变的，可以对字符串进行修改而不创建新的对象。

• 线程安全性：

  • StringBuffer 是线程安全的，内部方法通过加锁来保证线程安全。这使得 StringBuffer 在多线程环境下可以安全使用。

• 性能：

  • 因为线程安全的原因，StringBuffer 的性能相对较差（比 StringBuilder 要低）。如果不涉及多线程，StringBuilder 通常是更优选择。

什么时候使用抽象类？什么时候使用接口？

在 Java 中，抽象类和接口都可以用于定义类的抽象行为，二者有一些相似性，但使用场景和设计意图有所不同。理解它们的区别有助于在不同的情况下做出更合适的选择。

使用抽象类的场景

1. 需要共享代码实现时

• 抽象类可以包含具体的方法实现，因此它适用于一些子类之间需要共享代码实现的情况。抽象类可以提供一些公共的方法实现，子类可以继承这些实现，或者重写这些方法。

2. 有共同的父类

• 如果多个类之间存在“是一个”的关系，且它们有一些共同的属性和行为，那么可以使用抽象类。在抽象类中定义这些公共属性和方法，子类只需要继承并实现那些特有的行为。

3. 想要限制类的实例化

• 抽象类不能直接实例化，只能通过子类实例化。这种限制用于将某些类定义为模板，强制要求子类提供实现。

使用接口的场景

1. 多重继承（实现多个接口）

• Java 不支持类的多重继承，但可以实现多个接口。如果你希望一个类能够有多个不相关的行为，接口是非常合适的选择。

Java 异常体系

Java 的异常体系采用类继承的方式组织，其中 Throwable 是异常体系的根类，所有异常类型都继承自它。Java 中的异常分为两大类：Error 和 Exception，其中 Exception 又可以分为 RuntimeException 和 非运行时异常。

• Error：表示 JVM 无法恢复的错误，通常由系统问题引发，不建议捕获。
  • OutOfMemoryError：内存不足错误
  • StackOverflowError：栈溢出错误
  • VirtualMachineError：虚拟机错误
• Exception：表示程序可以处理的异常。它分为两类：
  • RuntimeException：运行时异常，是程序中无法预知的异常，通常不需要强制捕获或声明。
  • 非 RuntimeException（受检异常）：这类异常是编译时异常，通常需要显式捕获或者通过 throws 声明。

常见的运行时异常（RuntimeException）

运行时异常是 Java 异常体系中的一个重要分支，它通常在程序运行过程中发生，不需要显式声明或捕获。这些异常通常是由于程序中的逻辑错误或预料外的情况引发的。

常见的运行时异常包括 NullPointerException、ArrayIndexOutOfBoundsException、ArithmeticException、ClassCastException 等。