No45.精选前端面试题，享受每天的挑战和学习

TCP 和 UDP的区别是什么？

TCP（传输控制协议）和 UDP（用户数据报协议）是两种常用的互联网传输层协议，它们有以下几个主要区别：

1. 连接性： TCP 是面向连接的协议，通过建立可靠的连接来进行数据传输。在通信之前，必须建立连接，然后进行数据传输，最后关闭连接。而 UDP 是无连接的协议，发送数据之前不需要建立连接，每个数据包都是独立的，相互之间没有依赖关系。
   
2. 可靠性： TCP 提供可靠的数据传输。它使用重传、流量控制、拥塞控制等机制确保数据的可靠传输。如果数据包丢失或损坏，TCP 会自动重传，并保证数据按照发送顺序正确接收。UDP 不提供可靠性保证，数据包可能会丢失、重复或乱序传递，不进行重传。
   
3. 速度： UDP 比 TCP 快，因为它没有建立连接和维护状态的开销。UDP 的头部较小，没有拥塞控制等机制，因此能够更快地传输数据。而 TCP 的头部较大，需要进行连接的建立和维护，有更多的控制信息，因此会有一定的开销。
   
4. 带宽利用率： UDP 具有较好的带宽利用率，适合实时应用和对数据准确性要求不高的场景。TCP 会根据网络状况自动调整传输速度，拥塞控制等机制可能会导致带宽利用率降低。
   
5. 应用场景： TCP 适用于需要可靠传输和数据完整性的应用，例如网页浏览、文件下载、电子邮件等。UDP 适用于实时性要求高、数据丢失可接受的应用，例如音视频流媒体、在线游戏、DNS 解析等。
   

总之，TCP 和 UDP 在连接性、可靠性、速度、带宽利用率及应用场景等方面存在明显差异。选择使用哪种协议主要取决于具体的应用需求和性能要求。

下面是使用表格总结 TCP 和 UDP 的区别：

这张表格总结了 TCP 和 UDP 在连接性、可靠性、速度、带宽利用率以及应用场景等方面的不同之处。根据具体的需求和应用场景，选择适合的传输协议能够更好地满足通信需求。

说下 websocket 的连接原理

WebSocket 是一种在单个 TCP 连接上进行全双工通信的协议，它是为了解决 HTTP 协议的请求-响应模式无法满足实时通信需求而设计的。

WebSocket 的连接原理如下：

1. 握手阶段： WebSocket 的连接以 HTTP 请求作为握手过程的开始。客户端发送一个特殊的 HTTP 请求给服务器，请求中包含 Upgrade 头部字段，指定要升级到 WebSocket。如果服务器支持 WebSocket，将返回一个 101 Switching Protocols 的响应，表示握手成功，此时连接升级为 WebSocket 连接。
   
2. 数据传输阶段： 握手成功后，WebSocket 连接变为全双工模式，客户端和服务器可以直接发送数据而不需要等待请求和响应。双方可以通过发送帧（Frame）来传输数据，每个帧都有一定的格式规范，包括控制帧和数据帧。
   
3. 保持连接： WebSocket 连接在建立后将一直保持打开状态，并且允许客户端和服务器之间双向传输数据。由于 WebSocket 是基于 TCP 的，它利用 TCP 的保持连接能力，避免了每次通信都需要重新建立连接的开销。
   

WebSocket 的连接原理使得实时通信变得更加高效和灵活，避免了频繁的连接和断开操作，同时也减少了网络传输的开销和延迟。它广泛应用于实时聊天、多人在线游戏、股票行情等需要快速实时通信的场景。

跨域时怎么处理 cookie？

在跨域请求中，默认情况下浏览器是不会携带跨域请求的 cookie。但是可以通过一些方法来处理跨域请求时的 cookie：

1. 服务器设置响应头： 在服务器端设置响应头，允许跨域请求携带 cookie。例如，在响应中添加 Access-Control-Allow-Credentials: true，表示允许跨域请求携带凭证（包括 cookie）。
   
2. 前端请求设置： 在前端发起跨域请求时，需设置 withCredentials 属性为 true，以允许请求携带 cookie。例如，使用 Fetch API 发起请求时，可以添加 credentials: 'include' 参数。
   

需要注意的是，由于安全原因，跨域请求携带 cookie 需要同时满足以下两个条件：

• 响应头中设置了 Access-Control-Allow-Credentials: true。
• 请求的源（Origin）和目标服务器的域名、协议、端口都一致。

还需要注意的是，在设置跨域请求携带 cookie 时，要确保目标服务器是可信任的，以防止信息泄露和安全风险。

总之，通过在服务器端设置响应头和在前端设置请求参数，可以在跨域请求中处理 cookie，实现跨域通信时的身份验证和数据传输。

cookie 怎么设置只在 https 时携带？

要设置 cookie 只在 HTTPS 连接中携带，可以在设置 cookie 的时候使用 Secure 属性。具体操作如下：

1. 在服务器端设置响应头时，通过设置 Set-Cookie 头部字段的属性来指定 cookie 的选项。例如：

Set-Cookie: cookieName=value; Secure

1. 在这个例子中，通过添加 Secure 属性来表示该 cookie 只能在 HTTPS 安全连接中使用。
2. 在前端设置 cookie 时，通过 JavaScript 的 document.cookie 属性或者使用第三方库（如 js-cookie）来进行设置。例如：

document.cookie = 'cookieName=value; Secure';

1. 同样，通过添加 Secure 属性来确保该 cookie 只会在 HTTPS 连接中发送。

需要注意的是，设置了 Secure 属性的 cookie 只有在使用 HTTPS 加密连接时才会被浏览器发送，如果在普通的 HTTP 连接中进行请求，浏览器将不会发送这些 cookie。

此外，为了提高安全性，还可以结合其他安全措施，如设置 HttpOnly 属性来限制 cookie 的 JavaScript 访问，以防止跨站点脚本攻击（XSS）等安全问题。

总结起来，通过在设置 cookie 时添加 Secure 属性，可以确保该 cookie 只在 HTTPS 连接中携带，增加数据传输的安全性。

POST请求的 Content-Type 有哪几种？

POST 请求的 Content-Type 根据发送的数据类型不同，可以有多种不同的值。以下是一些常见的 POST 请求 Content-Type 类型：

1. application/x-www-form-urlencoded： 这是最常见的 Content-Type 类型，用于表单提交。数据会被编码成 key-value 的形式，例如 key1=value1&key2=value2。
   
2. multipart/form-data： 通常用于上传文件时的表单提交。数据会被分割成多个部分（multipart），每个部分都有自己的 Content-Type 和内容。
   
3. application/json： 当请求的数据为 JSON 格式时，使用该 Content-Type。请求体中的数据会以 JSON 格式进行传输。
   
4. text/plain： 表示请求体中的数据是纯文本，没有特定的格式或结构。
   
5. application/xml： 当请求的数据为 XML 格式时，使用该 Content-Type。请求体中的数据会以 XML 格式进行传输。
   

除了上述常见的 Content-Type 类型外，还有一些其他的 Content-Type 可以根据需要使用，例如：

• application/octet-stream： 用于传输二进制数据，如文件下载。
• application/graphql： 用于 GraphQL 查询语言的请求。
• application/x-msgpack： 使用 MessagePack 格式进行数据传输。
• application/protobuf： 使用 Protocol Buffers 格式进行数据传输。

根据实际需求以及后端服务器的要求，选择合适的 Content-Type 类型来发送 POST 请求，确保数据的正确传输和解析。

以上是一些常见的 POST 请求 Content-Type 类型及其描述。根据实际需求选择合适的 Content-Type 类型，以确保数据的正确传输和解析。

附录：「简历必备」前后端实战项目（推荐：⭐️⭐️⭐️⭐️⭐️）

Vue.js 和 Egg.js 开发企业级健康管理项目

带你从入门到实战全面掌握 uni-app