计算机网络

HTTP协议

一 常见的HTTP请求方法

1. GET：请求指定的页面信息，并返回实体主体。
2. POST：向指定资源提交数据进行处理请求（如提交表单或上传文件）。数据被包含在请求体中。POST请求可能会创建新的资源或修改现有资源。
3. PUT：从客户端向服务器传送的数据取代指定的文档的内容。
4. DELETE：请求服务器删除指定的页面。
5. HEAD：类似于GET方法，但没有响应体，只有响应头。用于获取资源的元数据。
6. OPTIONS：允许客户端查看服务器的性能。
7. PATCH：用于对资源进行部分修改。
8. CONNECT：用于代理可以转换成通道的请求。

二 常见的HTTP请求头和响应头

请求头

• Content-Type ：请求体的类型（如 text/html, application/json）。
• Authorization：认证信息，通常用于验证请求的合法性。
• User-Agent：发出请求的用户代理软件信息。
• Accept：客户端能够接收的内容类型。
• Cookie：服务器发送到用户浏览器并保存的小信息片段，随后在同一服务器上被回传。

响应头

• Content-Type：响应体的类型。
• Set-Cookie：服务端设置的cookie。
• Cache-Control：指定请求和响应遵循的缓存机制。
• ETag：资源的特定版本的标识符。
• Expires：响应过期的日期和时间。

三 GET和POST的请求的区别

• GET：用于请求访问已被URL识别的资源，可以通过URL传送参数，对发送的信息数量有限制，通常不用于敏感信息。
• POST：用于发送数据给服务器，比如通过表单提交数据，数据包含在请求体中，没有数据大小限制，适合发送敏感信息。

四 POST和PUT请求的区别

• POST：用于创建或添加新资源，也可以用于非幂等的操作，如提交表单。
• PUT：用于更新现有资源或者创建指定资源，是幂等的，意味着多次执行相同的请求结果相同。

五 HTTP状态码304是多好还是少好

HTTP状态码304（Not Modified）是一个非常有用的状态码，主要用于缓存控制。当浏览器对某个资源发起请求，且该资源自上次请求后未进行修改时，服务器会返回304状态码。这意味着浏览器可以使用本地缓存的版本，不需要重新下载资源。这种机制可以显著提高网页加载速度，减少服务器的负载和带宽使用，从而提升用户体验和系统效率。因此，304状态码通常被视为"好"的，因为它有助于优化Web性能。

六 OPTIONS请求方法及使用场景

OPTIONS方法是HTTP协议的一部分，用于获取目的资源所支持的通信选项。客户端可以通过OPTIONS请求了解服务器的功能，例如服务器支持哪些HTTP方法（如GET、POST等）。

使用场景：

• CORS（跨源资源共享）预检请求 ：在发送实际请求前，浏览器可以发起一个OPTIONS请求到服务器，以确定是否安全发送跨源请求。这个预检请求包括如Access-Control-Request-Method和Access-Control-Request-Headers这样的头部，服务器回应这些请求头，表明哪些HTTP方法和头部是被允许的。
• API探测：开发者可以使用OPTIONS请求探测Web服务看看它支持哪些HTTP方法，这在开发和集成阶段特别有用。

七 HTTP 1.0 和 HTTP 1.1 之间的区别

• 连接持久化 ：
  • HTTP 1.0：默认不支持持久连接。每个HTTP请求/响应对后，连接被关闭，导致每次请求都需要重新建立连接。
  • HTTP 1.1：引入了持久连接（也称为HTTP keep-alive），允许在一个连接上发送多个请求和响应，减少了建立和关闭连接的开销。
• 带宽优化和网络连接的使用 ：
  • HTTP 1.1：支持只发送请求的头部（不带任何body信息）。如果服务器允许请求则发送body；如果不允许，则省去了发送body的带宽。
• 缓存处理 ：
  • HTTP 1.1：添加了更复杂的缓存控制策略，如ETag、If-Unmodified-Since、If-Match、If-None-Match等头部，使得缓存更加高效。

八 HTTP 1.1 和 HTTP 2.0 的区别

• 多路复用 ：
  • HTTP 2.0：通过单一的连接允许多个请求/响应消息在同时进行，这通过帧和流的概念实现，大幅减少了延迟并提高了连接的利用率。
• 服务器推送 ：
  • HTTP 2.0：允许服务器未经请求即向客户端发送资源，提高了页面加载速度。
• 头部压缩 ：
  • HTTP 2.0：引入了HPACK压缩格式，减少了头部大小，减少了带宽的使用。
• 二进制格式 ：
  • HTTP 2.0：HTTP/2是二进制的，而HTTP/1.x是文本的。二进制协议解析更高效且更少出错，更易于网络传输。

九 HTTP和HTTPS协议的区别

什么是HTTPS协议？

HTTPS（全称 HyperText Transfer Protocol Secure）是HTTP的安全版本，它在HTTP的基础上通过使用SSL/TLS协议提供数据加密、数据完整性和认证。这种协议主要用于互联网上的安全通信，确保数据在传输过程中不被拦截或篡改。

TLS/SSL的工作原理

TLS（传输层安全）和SSL（安全套接层）是两种协议，用于在互联网上提供安全的通信。SSL现已被TLS逐步取代，但通常这两个术语仍交替使用。它们的工作原理如下：

1. 密钥交换：客户端和服务器协商生成"会话密钥"，用于此次通信期间的加密和解密。
2. 数据加密：使用会话密钥，数据在发送前被加密，接收后被解密。
3. 服务器认证：服务器向客户端提供其公钥证书，证书由可信任的证书颁发机构（CA）签名，以证明服务器的身份。

数字证书是什么？

数字证书是一个电子证明，表明了证书持有者的身份信息以及公钥，它由证书颁发机构（CA）签发和签名。数字证书用于建立双方的信任关系，确保公钥属于其声称的所有者，从而防止中间人攻击。

HTTPS通信（握手）过程

HTTPS协议的握手过程包括以下几个步骤：

1. 客户端发送ClientHello：包含客户端支持的TLS版本、加密方法和一个随机数。
2. 服务器回复ServerHello：选择一个客户端提出的加密方法，并发送一个随机数和自己的数字证书。
3. 密钥交换和认证：客户端验证服务器的证书是否有效，从证书中提取公钥，并使用公钥加密一个新生成的预主密钥发送给服务器。
4. 预主密钥解密和会话密钥生成：服务器使用自己的私钥解密预主密钥，然后双方根据预主密钥生成会话密钥。
5. 客户端和服务器交换Finished消息：双方通知对方加密通信即将开始，并验证会话密钥的正确性。
6. 加密会话开始：此后的所有通信都使用会话密钥进行加密。

HTTPS的特点

• 加密：保证数据在传输过程中的安全和隐私。
• 数据完整性：防止数据在传输过程中被更改。
• 认证：确保用户与服务器所连接的是真正的服务器，而非伪装的。

HTTPS是如何保证安全的？

HTTPS通过以下机制来保证通信的安全：

• 使用TLS/SSL加密：所有传送的数据都被加密，防止数据被窃听。
• 使用数字证书验证身份：避免了用户访问到假冒的网站。
• 完整性校验：通过消息摘要等技术确保数据在传输过程中未被篡改。

综上所述，HTTPS是一种安全的通信协议，通过结合TLS/SSL的加密、数字证书的认证以及严格的握手过程，它能有效地保护数据传输的安全性和完整性。

HTTP（超文本传输协议）和HTTPS（安全超文本传输协议）是网络通信的两种主要协议。它们在Web开发中的应用非常广泛，尤其是在保证数据传输安全方面。作为全栈Web开发人员，了解这两者的区别对于构建安全的Web应用程序至关重要。

下面是HTTP和HTTPS的主要区别：

1. 安全性

• HTTP：是一个不安全的协议，数据以明文形式传输，没有加密措施。这意味着数据在传输过程中可能被第三方截获或篡改，例如中间人攻击（MITM）。
• HTTPS：在HTTP的基础上，增加了SSL/TLS安全层。这意味着所有传输的数据都经过加密，只有客户端和服务器才能解密通讯内容，极大地增强了安全性。

2. 端口

• HTTP：通常使用80端口。
• HTTPS：通常使用443端口。

3. 性能

• HTTP：由于不进行数据加密，其处理速度比HTTPS快。
• HTTPS：由于加入了数据加密的过程，会稍微影响速度。SSL/TLS握手也需要消耗更多的服务器资源。

4. SSL/TLS证书

• HTTP：不需要使用SSL/TLS证书。
• HTTPS：需要使用SSL/TLS证书来建立安全连接。证书必须由客户端信任的证书颁发机构（CA）签发。

5. 应用场景

• HTTP：适合用于不处理敏感数据的情境，比如一些基本的信息查询或个人博客。
• HTTPS：适合用于需要高安全性的场景，如在线交易、个人信息收集、登录操作等。

6. 搜索引擎优化（SEO）

• HTTPS：被搜索引擎（如Google）优先考虑。自从2014年以来，Google已经开始把HTTPS作为排名因素之一，促使更多网站使用HTTPS。

7. URL前缀

• HTTP ：网址以http://开始。
• HTTPS ：网址以https://开始，其中"s"代表"安全"。

总结

对于任何涉及敏感数据交换的Web应用程序，强烈推荐使用HTTPS。HTTPS不仅保护数据免受中间人攻击，还有助于建立用户对网站的信任。随着网络安全威胁的增加，使用HTTPS已成为现代Web开发的标准实践。

十 GET方法URL长度限制的原因

在HTTP协议中，GET方法常用于请求服务器上的资源，其中请求的参数通常会附加在URL后面。尽管GET方法本身在技术规范上没有明确的URL长度限制，但实际应用中却常常受到各种限制，这主要是由以下几方面的原因导致的：

1. 浏览器限制

不同的浏览器对URL长度有不同的限制。例如，老版本的Internet Explorer限制URL长度为2083字节，其中查询字符串部分（即URL中"?"后面的部分）限制为2048字节。虽然现代浏览器（如Chrome和Firefox）可能支持更长的URL，但依然存在一个实际可用的上限，通常这个上限足以满足日常需求。

2. 服务器限制

服务器软件也可能对URL长度施加限制。例如，Apache服务器默认限制URL长度为8190字节，而Nginx则默认限制为8KB（大约8192字节）。这些限制是可配置的，但超长的URL可能导致服务器处理效率降低或安全风险增加。

3. 中间件和网络设备限制

在复杂的网络架构中，如负载均衡器、防火墙、代理服务器等网络设备或软件可能对URL的长度有自己的限制。这些限制可能是为了提高网络通信的效率或出于安全考虑。

4. 可维护性和可读性

从Web开发的最佳实践角度考虑，过长的URL可能会影响可维护性和可读性。长URL难以阅读和解析，也不便于分享。因此，即使技术上可以支持更长的URL，为了保持良好的用户体验和代码的整洁性，通常也会避免使用过长的URL。

结论

因此，尽管GET方法没有固定的URL长度限制，实际应用中的限制主要是由浏览器、服务器、中间件和网络设备的具体实现和配置决定的。为了避免兼容性问题，一般建议将URL长度保持在可控范围内（经验值通常为2000字节以内），如果需要传递更多数据，考虑使用POST方法，将数据放在请求体内传输。这样做不仅可以避开URL长度的限制，还能增强数据传输的安全性。

十一 当在浏览器中输入 Google.com 并且按下回车之后发生了什么？

当您在浏览器中输入Google.com并按下回车键时，会触发一系列复杂的网络和服务器交互过程，以显示该网站的内容。这个过程涉及多个步骤和技术，以下是该过程的详细说明：

1. URL解析

当您输入"Google.com"并按下回车时，浏览器首先解析这个URL，确定它指向的是一个网站。

2. DNS查找

浏览器需要找到"Google.com"对应的IP地址，这是通过域名系统（DNS）完成的。DNS将域名转换为与之关联的IP地址。如果DNS信息已缓存在您的系统或路由器中，则此步骤会很快完成；如果没有，您的请求会被发送到配置的DNS服务器上进行查找。

3. TCP连接

一旦获取到IP地址，浏览器将通过TCP协议在端口80（HTTP）或443（HTTPS）与服务器建立一个连接。考虑到Google使用HTTPS，浏览器会与服务器建立一个安全连接，这包括SSL/TLS握手过程。

4. 发送HTTP请求

浏览器构建一个HTTP GET请求，用于从服务器请求网页内容。这包括请求行（如GET / HTTP/1.1），还有请求头，其中包括浏览器类型、接受的内容类型等信息。

5. 服务器响应

服务器接收并处理来自浏览器的请求，然后发送一个HTTP响应回浏览器。这个响应包括状态码（如200 OK），响应头（如内容类型、缓存控制等），以及响应体，即请求的网页内容。

6. 内容呈现

浏览器接收到服务器的响应后，将开始解析HTML内容，并根据需要请求额外的资源，如JavaScript文件、CSS样式表、图片等。这些资源可能需要额外的DNS查找和TCP连接。

7. 页面渲染

浏览器将解析的HTML、CSS和JavaScript结合起来，构建DOM（文档对象模型），并渲染页面。JavaScript可能会被执行来修改DOM和页面的行为。

8. 交互

页面加载完成后，用户可以与页面互动，如点击链接、提交表单等。这些互动可能会触发更多的HTTP请求和响应交换。

9. 关闭连接

如果服务器或浏览器决定结束这次会话，TCP连接将被关闭。如果使用的是HTTP/1.1或更高版本的持久连接（keep-alive），连接可能会保持开放，以便后续请求重用。

这个过程展示了现代Web浏览的复杂性，涉及客户端、服务器、网络服务器协议和多个网络层之间的紧密交互。

十二 对keep-alive的理解

Keep-Alive 是一个 HTTP/1.1 协议的特性，它允许客户端和服务器在一个单一的持久连接上发送和接收多个 HTTP 请求和响应，而不需要每次请求都重新建立连接。这个特性可以显著提高网络通信效率，减少延迟，尤其是在需要多个请求的Web应用中非常有用。以下是关于 Keep-Alive 的一些重要点：

1. 连接复用

Keep-Alive 功能使得多个HTTP请求可以在同一个TCP连接上顺序地进行，而不是每一个请求都开启一个新的连接。这减少了因建立新连接而产生的开销和时间延迟，特别是在高延迟的网络环境中。

2. 减少TCP握手次数

在传统的HTTP/1.0协议中，每个HTTP请求响应完成后，TCP连接会立即关闭，之后的每个请求都需要重新进行三次握手来建立新的连接。而在启用了Keep-Alive的HTTP/1.1中，多个请求可以复用同一个连接，从而避免了频繁的连接建立和释放过程。

3. Headers

在HTTP请求和响应中，Connection: keep-alive 这个头部标明了客户端和服务器希望保持连接打开，以便进一步的请求可以使用同一个连接。服务器同样可以在响应中使用这个头部，告诉客户端连接将保持开放。

4. 性能优化

使用 Keep-Alive 可以提升Web应用的性能。特别是在加载一个页面需要多个资源（如图片、CSS、JavaScript 文件等）时，连接复用可以减少总的加载时间。

5. 超时和最大请求限制

尽管连接是保持开放的，但服务器通常会设置超时时间和最大请求处理数。这意味着如果在指定的超时时间内没有新的请求，或者达到了最大请求限制，连接将会被关闭。这些限制帮助服务器管理资源并防止过度的资源占用。

6. 兼容性和配置

虽然现代浏览器和服务器大多默认开启了Keep-Alive，但在某些特定情况下，开发者可能需要在服务器配置或程序代码中显示地设置或调整Keep-Alive的参数，如超时时间和最大请求数，以适应特定的用例或性能需求。

总之，Keep-Alive 是一个提高HTTP通信效率的重要功能，特别适用于现代Web应用，其中资源多、请求频繁。全栈开发者应当了解并合适地利用这一特性来优化应用性能。

十三 页面有多张图片，HTTP是怎样的加载表现？

在一个包含多张图片的网页中，HTTP的加载行为和性能表现依赖于多种因素，包括HTTP的版本（如HTTP/1.1与HTTP/2）、服务器配置、客户端的浏览器支持、网络条件等。我们逐一分析这些情况下的加载表现：

HTTP/1.1

在HTTP/1.1中，默认情况下，每个TCP连接只能同时处理一个请求-响应。对于包含多张图片的页面，浏览器通常会针对同一域名开启多个并行的TCP连接（通常是6个），以便并行下载多个资源，如图片。这种方式可以一定程度上提高加载速度，但存在以下限制：

1. 并发限制：虽然并发连接可以提升速度，但每增加一个连接，都会增加额外的资源消耗和潜在的网络拥堵。
2. 慢启动：新的TCP连接需要经历TCP慢启动，这可能导致初期传输速度较慢。
3. 连接开销：频繁地建立和关闭连接会带来额外的延时和开销。

HTTP/2

HTTP/2的引入主要是为了解决HTTP/1.x的性能限制。HTTP/2引入了以下关键特性来优化包含多资源（如多张图片）的页面的加载性能：

1. 单一连接：HTTP/2通过单一的TCP连接复用，允许多个请求和响应在同一时间并行交换，减少了连接的总数和相应的慢启动影响。
2. 二进制分帧：HTTP/2将所有传输的信息分成更小的消息和帧，并对它们进行优先级设置和管理，使网络更高效地利用。
3. 服务器推送：服务器可以主动发送额外的资源到客户端，而无需客户端明确请求，从而进一步提高加载效率。

性能优化策略

无论是HTTP/1.1还是HTTP/2，你可以采取一些策略来优化图片加载性能：

1. 图片压缩：使用工具减小图片文件大小，而不显著影响质量。
2. 使用CDN：通过内容分发网络（CDN）来分散图片的加载请求，减少主服务器的负载和响应时间。
3. 延迟加载：实现图片的懒加载，即滚动到可视区域时才加载图片，可以显著提高页面的初次加载速度。
4. 缓存策略：合理配置HTTP缓存策略，对于不经常变动的图片资源，可以在用户浏览器上设置较长的缓存时间。
5. 图像格式选择：根据需要选择合适的图片格式，如WebP提供了比PNG和JPEG更优的压缩。

通过这些技术和策略的应用，你可以显著改善一个包含多张图片的网页的加载速度和用户体验。

十四 HTTP2的头部压缩、HTTP请求报文的是什么样的？HTTP响应报文

HTTP/2 引入了许多关键改进来优化网络通信，其中之一就是头部压缩，以及请求和响应报文的结构也有所不同。以下是对这些方面的详细解释：

HTTP/2 头部压缩

HTTP/2 使用一种称为 HPACK 的头部压缩机制来减少传输大小和提高效率。HPACK 针对HTTP头部数据采用了一种专门的压缩格式，可以显著减小头部大小。

1. 静态表和动态表：HPACK 使用两种表来存储和索引头部字段：

   • 静态表：包含常见的头部字段和值的列表，这些是预定义的，并且在所有连接中是相同的。
   • 动态表：在连接过程中逐渐构建起来，存储那些在当前连接中出现的头部字段和值。动态表可以根据通信双方的实际需求适应性地更新。

2. 索引表示方法：如果头部字段可以在静态表或动态表中找到，那么只需发送一个索引号。

3. 字面值表示：对于未在表中的头部字段，将使用字面值发送，但可以选择是否更新动态表以供未来引用。

这种方法有效减少了因重复发送相同的头部信息而产生的冗余数据，从而提升了性能。

HTTP 请求报文

在 HTTP/1.x 中，HTTP请求报文通常包括一个请求行（包括方法、URI和HTTP版本），后跟一系列的头部字段和一个可选的消息体。

HTTP/2 改变了这种格式，使用了二进制的帧（frame）结构来发送数据。每个帧都属于一个流（stream），流是连接中的一个独立的双向数据流。主要帧类型包括：

• HEADERS帧：包含压缩后的HTTP头部字段。
• DATA帧：包含实际的消息体数据。

HTTP 响应报文

在 HTTP/1.x 中，响应报文包括状态行（状态码和状态消息），响应头部字段，以及一个消息体。

在HTTP/2中，响应也是通过帧的形式发送的：

• HEADERS帧：携带响应的头部。
• DATA帧：携带响应的消息体。

通过使用这种帧结构，HTTP/2 不仅可以并行地在同一个连接上发送多个请求和响应（即多路复用），还可以通过优先级和服务器推送（server push）等机制进一步优化性能。

这些改进意味着HTTP/2能够比HTTP/1.x更高效地处理多资源的Web页面，减少延迟，并提升总体性能。

十六 HTTP协议的优点和缺点

HTTP（HyperText Transfer Protocol）是互联网上应用最广泛的协议之一，用于Web数据的传输。作为一个全栈Web开发人员，理解HTTP协议的优点和缺点对于设计和开发高效、安全的Web应用至关重要。以下是HTTP协议的主要优点和缺点的总结：

HTTP协议的优点

1. 简单易用：HTTP协议相对简单，使得开发者容易理解和使用。请求和响应模式直观，易于构建客户端和服务器端应用。

2. 灵活：HTTP允许传输任意类型的数据，只要双方知道如何处理这些数据。这使得它可以用来传输HTML文件、图片、视频等多种媒体类型。

3. 无状态：HTTP是无状态协议，每次请求都是独立的，这简化了事务处理。虽然这也是一个缺点，但它使得每次交互都不依赖于之前的状态，从而简化了服务器设计。

4. 可扩展性：HTTP协议支持可扩展的头部选项，允许新的功能和数据类型能够被集成和支持。

5. 广泛支持：几乎所有的网络应用都支持HTTP，这意味着开发者可以利用现成的库和框架来构建应用，而且兼容性广泛。

HTTP协议的缺点

1. 无状态导致的额外负担：HTTP无状态的特性虽然简化了服务器的设计，但也意味着为了维护状态，服务器和客户端必须实施额外的机制，如Cookies和Session。

2. 安全性问题：基本的HTTP不加密，数据在传输过程中可能被窃听或篡改。虽然HTTPS部分解决了这一问题，但仍需要正确配置和维护。

3. 性能问题：HTTP/1.1虽然支持持久连接，但每次连接只处理一个请求/响应，可能导致延迟。虽然HTTP/2提供了改进，如多路复用，但初始部署和优化需要额外的努力。

4. 头部冗余：在HTTP/1.x中，头部信息每次请求都必须重新发送，即使很多数据如用户代理、接受语言等在多次请求间不会改变，这增加了不必要的网络负载。HTTP/2的头部压缩技术虽然解决了这个问题，但需要新的解析和实现技术。

5. 版本兼容性和迁移问题：尽管HTTP/2和HTTP/3提供了显著的性能优化，但老版本的HTTP协议在某些环境中仍然被广泛使用。迁移到新版本可能涉及兼容性考量和技术挑战。

十七 HTTP 3.0

HTTP/3 是最新的 HTTP 协议版本，它主要目标是解决 HTTP/2 在某些情况下的性能问题，尤其是在网络条件不佳的环境中。HTTP/3 引入了许多重要的改变和优化，其中最显著的是替换了底层的传输协议，从 TCP+TLS 转换到基于 UDP 的 QUIC 协议。以下是有关 HTTP/3 的一些关键点：

1. 使用 QUIC 协议

• 速度：QUIC 支持快速连接建立、流控制、丢包恢复等，比 TCP 更快速。QUIC 减少了连接和传输延迟，特别是在包含多次往返的连接建立过程中。
• 连接迁移：QUIC 支持连接ID，这使得即使底层IP地址改变，连接也能保持活跃，这对移动设备非常有利。

2. 改进的多路复用

• 尽管 HTTP/2 实现了流的多路复用，但它依然受到 TCP 的"队头阻塞"问题的影响。QUIC 通过在更底层实现多路复用，独立处理每个流，从而彻底解决了队头阻塞问题。

3. 加密和安全

• QUIC 包含了从一开始就设计的加密功能，它整合了 TLS 1.3，提供了更强的默认加密支持。这不仅提高了安全性，也简化了协议栈（因为不再需要单独的TLS握手）。

4. 传输和流控制

• QUIC 实现了更细粒度的流控制机制，每个流都可以独立地被控制和优化，而不会影响到其他流。

5. 向前纠错（FEC）

• QUIC 试图实现一定程度的向前纠错，以减少因丢包引起的重新传输需求。

6. 性能优化

• HTTP/3 通过减少延迟、优化重传机制、避免队头阻塞等方式，提供了更好的性能和用户体验，尤其是在丢包率较高的网络环境中。

实际应用和支持

目前，HTTP/3 已经开始在互联网上得到应用，许多主流浏览器如 Chrome、Firefox 和 Safari 已支持 HTTP/3，大型网站如 Google、Facebook 等也开始部署支持 HTTP/3。

十八 URL有哪些组成部分

URL（Uniform Resource Locator，统一资源定位符）是用于定位互联网上资源的地址。一个完整的URL可以包含几个不同的组成部分，每个部分都承载着特定的信息，用于指向网络上的资源。以下是一个URL的主要组成部分及其功能：

1. 协议 （或称为方案）: 指示了客户端和服务器之间应如何通信。常见的协议包括 http、https、ftp、mailto 等。例如，在 https://www.example.com 中，https 是协议。

2. 子域名 : （可选）通常是对主域名的一个补充说明，定义了服务器的一个特定区域。例如，在 subdomain.example.com 中，subdomain 是子域名。

3. 域名 : 网络上服务器的名称，它通常是该服务器所在的组织注册的特定名称。例如，在 https://www.example.com 中，example.com 是域名。

4. 端口 （可选）: 数字形式表示的服务器上的特定门户。如果未指定，Web服务通常使用默认端口，如HTTP的80端口和HTTPS的443端口。例如，在 http://www.example.com:8080 中，8080 是端口号。

5. 路径 : 指向服务器上特定资源的路径。路径通常表示为一系列的斜杠(/)分隔的字符串。例如，在 http://www.example.com/index.html 中，/index.html 是资源路径。

6. 查询字符串 （可选）: 用于提供额外参数以供服务器进一步处理的部分，通常以问号(?)开始，参数间以和号(&)分隔。例如，在 http://www.example.com/search?q=keyword&page=2 中，q=keyword&page=2 是查询字符串。

7. 片段 （可选）: 也称作锚点，通常用于页面内导航，不会被发送到服务器。它通过井号(#)标示，指向资源内部的一个特定部分。例如，在 http://www.example.com/index.html#content 中，#content 是片段标识符。

理解URL的各个组成部分对于Web开发至关重要，它不仅有助于页面的链接设计，也影响到网站的SEO（搜索引擎优化）和资源的组织结构。

十九 与缓存相关的HTTP请求头有哪些

在HTTP中，缓存控制是通过使用一系列请求和响应头来管理的，这些头部字段帮助定义如何缓存资源以及缓存可以存储和重新使用该资源的方式。以下是一些主要的与HTTP缓存相关的请求头：

在HTTP协议中，If-Modified-Since、If-None-Match和Cache-Control 都是与缓存控制相关的重要头部。它们在开发Web应用程序时用于优化性能和管理资源的有效性。下面详细解释这些头部是如何工作的，以及它们在实际中的应用。

1. If-Modified-Since

If-Modified-Since 是一个HTTP请求头，用于向服务器询问自指定的日期之后是否修改了资源。如果资源自那个时间以来未被修改，服务器会返回一个 304 Not Modified 状态码，而不是资源的完整内容。这可以节省带宽并减少不必要的网络流量。

应用场景：

• 在用户的浏览器缓存了某个资源（如图片、CSS文件或JavaScript文件）后，当用户再次访问相同的资源时，浏览器可以发送一个带有If-Modified-Since头的请求。如果资源未更改，服务器响应304，浏览器就会使用缓存的资源。

2. If-None-Match

If-None-Match 是一个HTTP请求头，它使用ETag值（一个可以标识资源版本的标识符）来询问资源是否已更改。如果ETag匹配（即资源没有更改），服务器将返回 304 Not Modified 状态码。

应用场景：

• 类似于If-Modified-Since，但更准确，因为ETag是一个可以确切标识资源状态的标记，即便是资源最后修改时间未变，内容变化也会导致ETag变化。在内容分发网络（CDN）或具有复杂构建过程的应用中尤其有用。

3. Cache-Control

Cache-Control 是一个HTTP头部，用于控制资源在HTTP请求和响应中的缓存行为。它包含多个指令，来精确地控制资源的缓存逻辑。

常见指令：

• no-cache：强制每次请求直接发送到服务器，服务器必须验证资源的状态。
• no-store：完全禁止缓存，适用于敏感数据。
• public：允许资源被缓存在公共缓存中。
• private：资源只能缓存到私有缓存中（如用户的浏览器）。
• max-age=<seconds>：指定资源在客户端缓存中保持新鲜的最长时间。

应用场景：

• 对于需要频繁更新的数据，使用Cache-Control: no-cache来确保数据总是最新的。
• 对于不经常更改且请求高频的资源（如logo图片、CSS框架库等），可以设置较长的max-age以减少服务器负载和改善用户体验。
• 在处理包含敏感信息的响应时，使用Cache-Control: no-store以确保这些信息不会被缓存。

它们之间的关系

1. 配合使用：

   • 当Cache-Control设置为no-cache时，尽管资源可能被存储在缓存中，每个请求仍会前往服务器进行验证（如果提供了If-Modified-Since或If-None-Match，则使用这些头进行条件请求）。这有助于确保内容的新鲜性，同时利用了条件请求的带宽优化。
   • 当Cache-Control设置资源的max-age较长时，浏览器可能不会在资源到期之前发送任何验证请求，从而减少了服务器的请求负担。

2. 优化缓存与验证：

   • If-Modified-Since和If-None-Match可以用来验证缓存中的内容是否仍然有效。这种验证机制可以减少不必要的网络传输，只有在数据实际发生变化时才下载新内容。
   • Cache-Control则控制这些验证的频率和条件，以及是否应该缓存数据和应该在何处缓存。

总之，这三个HTTP头部共同协作，提供了一种灵活而强大的方式来控制Web资源的缓存和有效性验证，从而优化Web应用的性能和用户体验。理解并正确应用这些头部是提升Web开发质量和效率的关键。

二十 HTTP状态码

常见的状态码

在Web开发中，HTTP状态码是服务器用来告知客户端关于请求的处理情况的一种机制。这些状态码分为几个系列，每个系列代表了一类特定的响应。下面是一些常见的HTTP状态码及其含义：

1xx - 信息性响应

• 100 Continue: 客户端应继续其请求
• 101 Switching Protocols: 请求者已要求服务器切换协议，服务器已确认并准备切换

2xx - 成功

• 200 OK: 请求成功。一般用于GET与POST请求的响应
• 201 Created: 请求已被实现，结果是创建了新的资源
• 202 Accepted: 已接受请求，但尚未处理完成
• 204 No Content: 服务器成功处理了请求，但不需要返回任何实体内容

3xx - 重定向

• 301 Moved Permanently: 请求的页面已永久移至新位置
• 302 Found: 临时重定向
• 303 See Other: 对应当前请求的响应可以在另一个URL上被找到，当进行POST请求时尤其有用
• 304 Not Modified: 自从上次请求后，请求的页面未修改过

4xx - 客户端错误

• 400 Bad Request: 服务器无法理解请求的格式，客户端不应该尝试再次使用相同的内容发起请求
• 401 Unauthorized: 请求未经授权。这通常是因为请求的页面需要用户名和密码验证
• 403 Forbidden: 服务器理解请求客户端的请求，但是拒绝执行此请求
• 404 Not Found: 服务器无法找到请求的页面
• 405 Method Not Allowed: 请求行中指定的请求方法不能被用于请求相应的资源
• 429 Too Many Requests: 客户端的请求次数超过限额

5xx - 服务器错误

• 500 Internal Server Error: 服务器遇到错误，无法完成请求
• 501 Not Implemented: 服务器不支持请求的工具
• 502 Bad Gateway: 服务器作为网关或代理，从上游服务器收到无效响应
• 503 Service Unavailable: 服务器目前无法使用（由于超载或停机维护）。通常，这只是暂时状态
• 504 Gateway Timeout: 服务器作为网关或代理，但是没有及时从上游服务器收到请求

了解这些HTTP状态码对于开发和调试Web应用非常重要，它们帮助开发者理解在客户端和服务器交互过程中可能发生的各种情况。

同样是重定向，307，303，302的区别？

HTTP状态码307、303和302都用于在Web开发中处理重定向，但它们之间存在细微的差别，这些差别主要关注于如何处理原始请求的HTTP方法和客户端如何继续该请求。了解这些差别对于确保应用程序的正确行为和数据安全非常重要。

1. HTTP 302 - Found （临时重定向）

HTTP 302是最常用的重定向状态码，用来表示请求的资源临时移动到了一个新的URL上。当响应是302时，大多数客户端（如浏览器）会自动处理重定向，并且将原始的POST请求转换为GET请求，即使这种行为在早期HTTP规范中没有明确规定。这种方法的问题是它可能导致原始的POST请求的意图被改变，如数据可能不会被提交到新的位置。

2. HTTP 303 - See Other

HTTP 303状态码被引入是为了明确302的行为，特别是强调将所有类型的请求方法转换为GET方法。这意味着无论原始请求是POST、PUT还是DELETE，当客户端收到303响应时，都应该使用GET方法去获取在Location头中指定的URL。303主要用于在执行如POST的操作后，将客户端重定向到一个新的URL，该URL可以安全地用GET请求访问，比如重定向到一个操作成功的确认页面。

3. HTTP 307 - Temporary Redirect

HTTP 307状态码是在HTTP/1.1中引入的，用于保持对原始请求方法的完整性。当收到307响应时，客户端必须使用相同的方法（例如POST）向在Location头中指定的新URL发起请求。这样，如果原始请求是POST，客户端会再次使用POST方法到新的URL，而不是转换为GET方法。这对于需要保持请求方法不变时（如表单提交）非常有用，确保数据传输的一致性和安全性。

各自的使用场景

• HTTP 302：虽然在实践中被广泛用于各种临时重定向，但由于它可能导致请求方法从POST转为GET，因此在需要确保请求方法保持不变的情况下不推荐使用。
• HTTP 303：非常适合在POST请求之后进行重定向，确保后续的URL可以安全地使用GET请求访问，适用于提交表单后的重定向。
• HTTP 307：适合在需要保证请求方法不变的情况下进行临时重定向，如在表单重提交的场景中保持POST方法。

正确使用这些HTTP状态码对于维护Web应用的功能性和用户体验至关重要。开发者应当基于具体的应用场景和需求选择适当的重定向状态码。

DNS 协议

一 DNS协议是什么？

DNS（域名系统）是一个分布式的系统，用于将人类可读的域名（如 www.example.com）转换为机器可读的IP地址（如 192.0.2.1），从而使网络用户能够使用简单的域名来访问互联网资源，而不需要记住复杂的数字序列。这种转换过程称为域名解析。

二 DNS同时使用TCP和UDP协议？

DNS主要使用UDP协议进行通信，特别是对于标准的查询，这是因为UDP比TCP快，而且域名解析通常需要快速完成。UDP适用于大多数常规的查询，因为这些查询消息小于512字节，适合UDP的快捷处理方式。

然而，当DNS响应数据超过512字节时（例如包含多个记录的应答），或在进行区域传输（zone transfers）时，DNS会使用TCP协议。TCP协议确保数据的完整性和顺序，适用于更复杂或更大数据量的交换。

三 DNS完整的查询过程

1. 浏览器缓存：浏览器首先检查自己的缓存中是否有请求的域名对应的IP地址。
2. 系统缓存：如果浏览器缓存中没有找到记录，查询会继续到操作系统的DNS缓存。
3. 递归查询：如果前两步未能解析域名，系统会向配置的DNS服务器发送一个递归查询请求。大多数家庭或小型企业网络中，这通常是ISP（互联网服务提供商）的DNS服务器。
4. 根服务器查询：如果ISP的DNS服务器也没有缓存该记录，它会向根DNS服务器查询。
5. 顶级域（TLD）服务器查询：根服务器会返回管理请求域名后缀（如.com、.net）的TLD服务器的信息。ISP的DNS服务器随后查询这个TLD服务器。
6. 权威服务器查询：TLD服务器会提供存储请求域名详细信息的权威名称服务器的地址。ISP的DNS服务器再向这个权威服务器发出查询。
7. 响应：权威服务器回复所请求的域名的IP地址给ISP的DNS服务器，后者再将这个信息传回到用户的计算机。这个IP地址随后被缓存以用于后续查询，以减少解析时间。

四 迭代查询与递归查询

• 迭代查询：在迭代查询中，客户端从一个DNS服务器请求信息，如果这台服务器没有答案，它不会自己去查询其他服务器，而是会返回让客户端查询另一个DNS服务器的建议。客户端接着查询这个新的服务器，这个过程重复进行，直到找到答案。
• 递归查询：在递归查询中，客户端向服务器请求解析域名，如果服务器没有答案，那么这个服务器会代表客户端去查询其他服务器，直到找到答案，然后再将结果返回给客户端。

五 DNS记录和报文

DNS记录用于定义域名服务中的资源信息，常见的类型包括：

• A记录（Address Record）：将域名映射到IPv4地址。
• AAAA记录（IPv6 Address Record）：将域名映射到IPv6地址。
• CNAME记录（Canonical Name Record）：将一个域名映射到另一个域名。
• MX记录（Mail Exchange Record）：定义邮件交换服务器的域名。
• NS记录（Name Server Record）：指定该域名由哪个DNS服务器来控制。
• PTR记录（Pointer Record）：通常用于反向DNS查找，将IP地址映射回域名。

DNS报文包括查询和响应两种类型，包括：

• 报头：包含识别查询类型（如递归、迭代）、状态码以及问题计数和答案计数等。
• 问题部分：包含请求解析的域名和类型（如A，AAAA）。
• 答案部分：包含请求的域名的DNS记录。
• 权限部分：包含哪些DNS服务器有权提供这个域名的记录。
• 附加部分：提供额外的有用信息，如缓存的资源记录。

DNS的设计和操作非常关键，因为它直接影响到网络访问的效率和稳定性。

网络型

网络模型是用于描述计算机网络中通信和网络协议设计的框架。最常见的网络模型是OSI七层模型和TCP/IP模型。这些模型帮助网络管理员和工程师在构建或维护网络系统时理解不同层次的功能和服务。

一 OSI七层模型

OSI（开放系统互连）模型是一个概念模型，由国际标准化组织（ISO）制定，用于促进不同系统间的兼容性和标准化。OSI模型将网络通信分为七个层次：

1. 物理层（Physical Layer）：处理通过物理媒介传输原始比特流的硬件问题，包括电缆、卡、针脚、电压等。
2. 数据链路层（Data Link Layer）：处理介质访问控制，错误检测和修正。确保物理层传出的数据无误。
3. 网络层（Network Layer）：处理数据包从源到宿的传输和路由，包括寻址、流量控制等。
4. 传输层（Transport Layer）：负责提供端到端的通信服务，可以处理流量控制、错误检测、数据传输的完整性等。
5. 会话层（Session Layer）：管理用户的会话，控制建立和断开通信连接。
6. 表示层（Presentation Layer）：确保从一个系统发送的数据被另一个系统正确地读取。可以处理数据格式化、加密解密等。
7. 应用层（Application Layer）：为应用软件提供网络服务，如HTTP、FTP等。

二 TCP/IP模型

TCP/IP模型是一个更实用的模型，广泛用于互联网。它简化了层级，主要包括四层，有时也称为五层模型：

1. 网络接口层（Network Interface Layer）：对应于OSI模型的物理层和数据链路层，处理与物理网络的实际连接。
2. 互联网层（Internet Layer）：对应于OSI的网络层，主要包括IP（Internet Protocol），负责数据包的路由选择和传输。
3. 传输层（Transport Layer）：与OSI模型的传输层相同，主要包括TCP（Transmission Control Protocol）和UDP（User Datagram Protocol），提供端到端的数据传输。
4. 应用层（Application Layer）：包括所有高级协议，如HTTP、SMTP、FTP等，对应于OSI模型的会话层、表示层和应用层。

三 五层TCP/IP模型

有时TCP/IP模型被描述为五层模型，其中第五层是会话层，专门处理会话和连接的管理。这种划分更接近于OSI模型，提供更细致的层级划分。

理解这些模型对于全栈网络开发人员非常关键，可以帮助你设计更安全、高效和可靠的网络应用程序。

TCP和UDP

一 TCP 和 UDP 的概念及特点

TCP (Transmission Control Protocol)

• 是一种面向连接的协议，确保数据包的正确传输。
• 提供高可靠性，数据包到达顺序与发送顺序一致。
• 通过校验和、序列号、确认应答、重传机制等实现可靠传输。
• 适用于要求高可靠性的应用，如网页浏览、文件传输、电子邮件等。

UDP (User Datagram Protocol)

• 是一种无连接的协议，发送数据前不需要建立连接。
• 提供较低的可靠性，不保证数据包的顺序或完整性。
• 传输速度快，开销小，结构简单。
• 适合对实时性要求高的应用，如视频流、VoIP、在线游戏等。

二 TCP 和 UDP 的区别

1. 连接性：TCP 是面向连接的，需建立连接后通信；UDP 是无连接的，发送数据无需建立连接。
2. 可靠性：TCP 提供可靠交付，通过确认和重传机制；UDP 则可能丢包，不保证可靠性。
3. 顺序性：TCP 保证数据顺序正确；UDP 不保证数据顺序。
4. 速度：TCP 由于涉及建立连接和可靠性检查，速度较慢；UDP 由于没有这些开销，通常传输速度更快。
5. 头部大小：TCP 头部至少20字节；UDP 头部较小，只有8字节。

三 TCP 和 UDP 的使用场景

TCP 使用场景：需要可靠数据传输的应用，如网页浏览、文件传输、数据库操作等。

UDP 使用场景：适用于对实时性要求高的应用，如流媒体视频播放、VoIP、在线游戏等。

四 UDP 协议为什么不可靠？

UDP 是非连接状态的，发送数据无需建立连接，也不确认接收方是否收到数据。它不会重新发送丢失的数据包，也不会保证数据包的顺序。因此，如果网络状况不佳，UDP流可能会遇到数据丢失、错误或乱序的问题。

五 TCP 的重传机制

如果TCP预计的确认响应未在预定时间内到达，TCP将重传丢失的数据包。TCP使用自动重传请求（Automatic Repeat reQuest, ARQ）技术，包括错误检测和正向确认。超时重传计时器帮助TCP确定何时觉得数据包可能已丢失并需要重传。

六 TCP 的拥塞控制机制

TCP 使用几种算法来避免网络拥塞，主要包括：

• 慢启动：初始化拥塞窗口大小，逐渐增加网络容量直到发生丢包。
• 拥塞避免：每经过一个往返时间增加一个数据包，避免因增加过快导致网络拥塞。
• 快速重传：在接收到三个重复确认时，立即重传丢失的数据包。
• 快速恢复：调整拥塞窗口大小，快速恢复到拥塞避免阶段。

七 TCP 的流量控制机制

TCP 使用滑动窗口协议来实现流量控制，确保发送方不会发送过多数据压垮接收方。接收方通过TCP头中的窗口大小字段告诉发送方它的缓冲区还能接收多少数据，从而控制发送方的发送速度。

八 TCP 的可靠传输机制

TCP 通过序列号、确认应答、重传机制、校验和等确保数据的可靠传输。每个TCP数据包都被标记一个序列号，并且接收方会发送一个对特定序列号的确认响应，未确认的数据会被重传。

九 TCP 的三次握手和四次挥手

1. 三次握手 ：
   • SYN：客户端发送一个SYN包到服务器，并进入SYN_SEND状态。
   • SYN-ACK：服务器回复一个SYN-ACK包，并进入SYN_RECV状态。
   • ACK：客户端发送ACK包，一旦服务器接收到这个ACK包，连接建立。
2. 四次挥手 ：
   • FIN：当主动方完成数据发送后，发送一个FIN包。
   • ACK：被动方接收到FIN后，发送一个ACK包，确认序号为收到的序号+1。
   • FIN：被动方发送一个FIN，用来关闭另一方的连接。
   • ACK：主动方发送一个ACK表示确认，并进入TIME_WAIT状态。

十 TCP 粘包问题及其处理方法

TCP 粘包问题是指发送方发送的若干包数据到达接收方时被粘合在一起，接收方不容易进行拆分。这通常在发送多个小数据包时发生。处理方法包括：

• 使用固定长度的数据包。
• 使用特殊字符或字符串作为数据包的分隔符。
• 在每个数据包前加上长度字段，指明数据包的长度。

十一 为什么UDP不会粘包？

UDP维护了数据的边界，每个UDP数据包都是独立处理的，因此发送的每个数据包都是独立的数据单元，接收方正是按这种边界来接收和处理每个数据包的。这样就避免了数据粘包的问题。

WebSocket

一 对 WebSocket 的理解

WebSocket 是一种网络通信协议，提供了一种在单个长时间连接上进行全双工、双向交互的方式。它允许客户端和服务器之间的数据在建立连接后可以随时从任一方向传送。WebSocket 协议使得数据交换变得更实时和高效，非常适合需要快速、实时交互的应用，如在线游戏、股票交易平台和即时通讯服务。

WebSocket 连接首先会通过 HTTP 协议发起，使用 "Upgrade" 请求从 HTTP 协议切换到 WebSocket 协议。一旦握手成功，连接就会保持开放状态，直到客户端或服务器决定关闭连接。这种机制使得 WebSocket 能够有效地减少开销和延迟，因为头信息只在连接建立时交换一次，之后的通信都是纯数据。

二 即时通讯的实现方式

即时通讯的实现可以通过几种技术来实现，主要包括短轮询、长轮询、服务器发送事件（SSE）和 WebSocket。

短轮询

短轮询是最基本的一种轮询技术，客户端定期向服务器发送请求，询问是否有新信息。服务器接收到请求后，立即返回当前的数据状态，不管状态是否有变化。这种方法的缺点是它不够实时，并且会在没有数据更新的情况下创建许多无用的网络流量和服务器负载。

长轮询

长轮询是短轮询的改进版。客户端发送请求后，如果没有数据更新，服务器不会立即返回，而是保持请求开放，直到有数据更新发生或达到某个超时限制。这减少了请求的频率，但仍然依赖于客户端发起请求。

服务器发送事件（Server-Sent Events，SSE）

SSE 是一种允许服务器主动向客户端发送信息的技术。它只支持服务器到客户端的单向通信，因此适合那些不需要从客户端到服务器发送数据的场景，例如股票价格更新、新闻滚动等。SSE 在 Web 应用中可以保持连接开放，并允许服务器随时发送新的事件数据。

WebSocket

与 SSE 相比，WebSocket 提供全双工的通信能力。这意味着客户端和服务器都可以在任何时间点发送数据，适用于需要实时双向通信的应用，如聊天应用和在线游戏。WebSocket 更加灵活和强大，支持更复杂的通信需求。

区别总结

• 短轮询：实时性较差，网络及服务器负担较重。
• 长轮询：较短轮询减少了一些不必要的负担，但仍旧依赖客户端请求。
• SSE：单向从服务器到客户端的实时通信，适用于更新频繁的数据。
• WebSocket：最实时，全双工通信，适合实时交互性强的应用。

选择哪种技术取决于应用的具体需求、预期的负载以及开发和运维的复杂性。在实际应用中，开发者需要权衡这些因素，选择最符合需求的实现方式。