网络面试题整理

TCP通讯原理：三次握手，四次挥手

TCP（Transmission Control Protocol）通信中的"三次握手"和"四次挥手"是建立和终止TCP连接时的标准过程，用于确保数据的可靠传输和连接的正确关闭。

三次握手（Three-Way Handshake）：

第一步 - 客户端发送请求：
- 客户端发送一个SYN（同步）标志位的TCP数据包到服务器，用来请求建立连接。
- 此时，客户端进入"SYN_SENT"状态，等待服务器的响应。
第二步 - 服务器确认请求：
- 服务器收到客户端的SYN数据包后，会发送一个包含SYN和ACK（确认）标志位的数据包作为响应。
- 此时，服务器进入"SYN_RCVD"状态，表示它已经同意建立连接。
第三步 - 客户端确认连接：
- 客户端收到服务器的响应后，发送一个带有ACK标志位的数据包给服务器。
- 此时，客户端和服务器都进入"ESTABLISHED"状态，连接已建立，双方可以开始进行数据传输。

四次挥手（Four-Way Handshake）：

第一步 - 客户端发起关闭：
- 客户端发送一个带有FIN（结束）标志位的数据包给服务器，表示它要关闭连接，但仍然可以接收数据。
- 此时，客户端进入"FIN_WAIT_1"状态，等待服务器的确认。
第二步 - 服务器确认关闭：
- 服务器收到客户端的FIN数据包后，发送一个带有ACK标志位的数据包作为响应，表示它接受了客户端的关闭请求。
- 此时，服务器进入"CLOSE_WAIT"状态，客户端进入"FIN_WAIT_2"状态。
第三步 - 服务器发起关闭：
- 服务器发送一个带有FIN标志位的数据包给客户端，表示服务器也准备关闭连接。
- 此时，服务器进入"LAST_ACK"状态。
第四步 - 客户端确认关闭：
- 客户端收到服务器的FIN数据包后，发送一个带有ACK标志位的数据包作为确认。
- 此时，客户端进入"TIME_WAIT"状态，等待一段时间后才完全关闭连接。
- 服务器收到客户端的确认后，进入"CLOSED"状态，连接完全关闭。

这个四步挥手的过程确保了双方都有机会完成未完成的数据传输，以及关闭连接，同时避免了数据的丢失和不完整的传输。挥手完成后，双方的连接被完全关闭。

服务器设置"CLOSE_WAIT"状态的目的是啥？

服务器在设置"CLOSE_WAIT"状态的目的是等待客户端确认关闭连接。在TCP连接的四次挥手过程中，服务器在发送关闭请求后进入"CLOSE_WAIT"状态，这表示服务器已经发送了一个带有FIN标志位的数据包，告诉客户端它要关闭连接。服务器进入这个状态是为了等待客户端的确认，以确保连接被双方正确地关闭。

"CLOSE_WAIT"状态是暂时的，通常在服务器端只会停留很短的时间，直到收到客户端的确认，然后服务器会进入"CLOSED"状态，连接被完全关闭。这个等待确认的过程允许服务器确保客户端已经成功收到了服务器的关闭请求，以避免数据的丢失或不完整的传输。

总之，服务器设置"CLOSE_WAIT"状态是为了在关闭连接时等待客户端的确认，以确保连接被正确地关闭，从而维护数据的完整性和可靠性。这是TCP连接管理中的一个重要步骤，确保数据可靠传输和连接的正常终止。

UTF-8是怎么进行编码的？

UTF-8（Unicode Transformation Format - 8-bit）是一种可变长度字符编码方式，用于表示Unicode字符集中的字符。UTF-8编码的规则相对简单，它根据字符的Unicode码点值的范围来确定使用多少字节来表示一个字符。以下是UTF-8的编码规则：

ASCII字符（U+0000到U+007F）：
- ASCII字符使用单个字节（8位）进行编码，最高位（最左边的位）为0。
- 例如，字母A的Unicode码点是U+0041，它在UTF-8中编码为01000001。
通用多字节编码：
- 大多数Unicode字符使用多字节进行编码。
- 每个多字节序列以一个字节的起始字节开始，这个字节中的高位位表示此序列的长度。
- 例如，两字节序列以110xxxxx 10xxxxxx开始，三字节序列以1110xxxx 10xxxxxx 10xxxxxx开始，四字节序列以11110xxx 10xxxxxx 10xxxxxx 10xxxxxx开始。
- 剩余的字节都以10xxxxxx开始。
字符值：
- 多字节序列中的x位用于存储字符的值，组成了Unicode码点。
- 字符值的范围根据字节序列的长度不同而变化，不同长度的字节序列可以表示不同范围的Unicode字符。

下面是一些UTF-8编码的示例：

字母A（U+0041）编码为01000001。
欧元符号€（U+20AC）编码为11100010 10000010 10101100。
中文字符“你”（U+4F60）编码为11100100 10111101 10010000。
表情符号😀（U+1F600）编码为11110000 10011111 10011000 10000000。

UTF-8编码的灵活性使其成为一种广泛使用的字符编码方式，因为它可以表示所有Unicode字符，包括ASCII字符，同时保持了向后兼容性。这意味着如果一个UTF-8文本只包含ASCII字符，那么它与ASCII编码是一致的。

http是怎么传递参数的

HTTP请求可以传递参数以向服务器发送数据或请求特定资源。HTTP请求中传递参数的主要方法包括：

查询字符串参数：
- 在URL中使用查询字符串传递参数，通常是在URL的问号后面，多个参数之间使用"&"符号分隔。
- 例如：http://example.com/resource?param1=value1&param2=value2
- 在GET请求中，参数通常以明文形式附加在URL上，因此对于敏感信息来说不安全。
- 用于传递少量参数，如搜索关键字或分页信息。
请求头参数：
- 可以在HTTP请求的头部（Header）中添加自定义参数，这些参数以键值对的形式出现。
- 例如，可以在请求头中添加Authorization头以进行身份验证，或者在Accept头中指定响应的内容类型。
- 用于传递与请求相关的元信息和控制参数。
请求体参数：
- 在POST、PUT等HTTP请求方法中，可以将参数放置在请求体（Request Body）中。
- 参数通常以表单数据、JSON、XML等格式进行编码，并在请求头中指定Content-Type来表示数据类型。
- 用于传递大量参数或包含复杂结构的参数。
URL路径参数：
- 有时，参数可以作为URL路径的一部分来传递。
- 例如：http://example.com/resource/value1/value2，其中"value1"和"value2"可以被服务器解析为参数。
- 用于RESTful风格的API设计中，用于传递资源标识符或参数。
Cookie参数：
- 可以使用Cookie来在HTTP请求之间保持状态信息。
- 服务器可以设置Cookie并在客户端之间传递，客户端会将Cookie自动包含在后续的HTTP请求中。
- 用于跟踪用户会话和存储客户端状态信息。
会话参数：
- 通过使用会话（Session）来存储和管理参数，通常在服务器端。
- 客户端在登录后会获得一个会话标识符（Session ID），该标识符用于关联客户端与服务器端的会话数据。
- 用于保持用户状态和在多个请求之间共享数据。

HTTP请求的参数传递方式取决于应用程序的需求和设计。不同的HTTP框架和库可能提供不同的方式来处理参数。在处理HTTP请求时，服务器通常会解析请求中的参数，并根据参数的内容执行相应的操作或返回响应。

用户名和密码等参数是怎么传递，为什么这么传递？

用户名和密码等敏感信息在网络通信中需要以安全的方式传递，以保护用户的隐私和安全。通常，这些信息是在身份验证过程中传递的，以下是一些常见的传递方法以及为什么要这样传递的原因：

HTTP基本认证：
- 用户名和密码可以通过HTTP基本认证传递，这是HTTP协议的一种内置身份验证机制。
- 客户端将用户名和密码编码为Base64字符串，并将其添加到HTTP请求头的"Authorization"字段中。
- 这种方法简单易用，但不是最安全的方式，因为Base64编码不是加密，容易受到窃听攻击。
- 常用于简单的身份验证，但不建议在非安全环境中使用。
HTTPS：
- 使用HTTPS（HTTP Secure）协议来传递用户名和密码以及其他敏感信息，以加密数据传输。
- HTTPS使用TLS/SSL加密来保护通信，确保传输的数据在传输过程中是安全的。
- 这是一种最安全的传递敏感信息的方式，常用于登录和传输敏感数据，因为它提供了端到端的加密和安全性。
表单认证：
- 用户名和密码可以通过HTML表单输入，并通过POST请求将它们发送到服务器。
- 服务器接收到POST请求后，会验证用户提供的用户名和密码是否正确。
- 这通常用于Web应用程序的登录页面，用户可以安全地输入其凭据。
令牌认证：
- 用户信息可以通过令牌（Token）进行传递，用户在登录后会获得一个令牌，然后将令牌包含在每个后续请求的头部或请求参数中。
- 服务器使用令牌来验证用户的身份，而不需要在每个请求中传递明文的用户名和密码。
- 令牌可以具有一定的生命周期，并且可以存储在安全的方式中，减少了暴露密码的风险。
OAuth认证：
- OAuth是一种开放标准，允许用户授权第三方应用程序访问他们的资源，而不需要将密码传递给第三方应用。
- 用户在OAuth中进行授权，然后服务器生成访问令牌，第三方应用程序使用该令牌来访问受保护的资源。
- OAuth提供了一种安全的方式来授权和传递用户信息，而无需直接传递用户名和密码。

这些方法的选择取决于应用程序的需求和安全性要求。在设计和实施身份验证和数据传输方案时，必须考虑安全性，并选择适当的方法来保护用户信息。HTTPS是一种常用的方式，因为它提供了端到端的数据加密和完整性保护。同时，令牌认证和OAuth等方法也提供了安全且便于管理的方式来处理用户凭据和授权。

如果前端禁用token或者cookies，这样的敏感信息怎么传递

如果前端禁用了使用token或cookies等传递敏感信息的方式，仍然需要传递敏感信息，可以考虑以下替代方法：

在请求头中使用自定义头部：
- 可以在HTTP请求头中添加自定义的头部字段，将敏感信息放入这些头部字段中。但请注意，这仍然不是最安全的方式，因为头部字段仍然可以被窃听或中间人攻击所威胁。
请求参数加密：
- 将敏感信息加密后，作为请求的参数进行传递。前端和后端必须使用相同的加密算法和密钥来加密和解密数据。
- 这可以提供一定程度的保护，但仍然可能受到中间人攻击的威胁。
使用单次令牌（One-Time Token）：
- 生成一次性令牌，令牌只能用一次，并且在使用后立即失效。这样可以降低令牌泄露的风险。
- 服务器和客户端之间必须共享一种机制来生成和验证这些一次性令牌。
IP地址限制：
- 对于一些情况下，可以限制只有特定IP地址或IP地址范围的请求能够访问敏感信息，以增加访问的限制。
使用其他安全传输层：
- 使用其他安全传输层，如VPN（Virtual Private Network）或专用网络连接，以确保数据传输的安全性。

需要强调的是，这些方法仍然可能存在一些安全风险，因此在选择和实施替代方法时，需要根据应用程序的具体需求和安全性要求进行仔细的评估和设计。最佳的安全实践通常包括使用HTTPS、令牌认证、OAuth等安全机制，以确保敏感信息在传输过程中得到保护。

websocket 链接在请求头中是怎么标识的？

WebSocket连接在HTTP请求头中通过特定的头部字段来标识。在建立WebSocket连接时，客户端会发送一个HTTP请求，其中包含一些特殊的头部字段来指示要升级到WebSocket连接。以下是标识WebSocket连接的HTTP请求头部字段：

Upgrade：
- 客户端在HTTP请求头中包含一个"Upgrade"字段，其值设置为"websocket"，表示客户端希望升级到WebSocket连接。
- 示例：Upgrade: websocket
Connection：
- 客户端还包含一个"Connection"字段，其值设置为"Upgrade"，表示客户端希望升级连接。
- 示例：Connection: Upgrade
Sec-WebSocket-Key：
- 客户端生成一个随机的16字节的值，并将其转换为Base64编码后放在"Sec-WebSocket-Key"字段中，以确保服务器可以验证WebSocket握手请求的合法性。
- 示例：Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version：
- 客户端在"Sec-WebSocket-Version"字段中指定所使用的WebSocket协议的版本号。
- 示例：Sec-WebSocket-Version: 13
其他头部字段：
- 除了上述字段外，还可以包含其他自定义的头部字段，以在建立WebSocket连接时传递额外的信息。

当服务器收到包含上述标识字段的HTTP请求后，如果支持WebSocket协议并接受WebSocket连接，它将响应一个HTTP 101 Switching Protocols状态码，表示已成功升级到WebSocket连接。此后，客户端和服务器之间的通信将通过WebSocket协议进行，而不再是HTTP。

下面是一个WebSocket协议升级的示例HTTP请求头：

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

请注意，WebSocket连接的建立过程需要遵循WebSocket协议的标准规范，包括特定的字段和状态码，以确保安全和正确的协议升级。一旦建立WebSocket连接，客户端和服务器之间的数据传输将以全双工的方式进行，允许双方实时地进行双向通信。