自动跳转手机网站代码企业网站的推广形式有
一.10万个正整数，取值范围0到100w，互不重复，给定一个数字判断是否在这些数中出现过?
1.哈希表法怎么做到的？
我可以用哈希表（比如
unordered_set或HashSet）来存储这1.1万个数字。这样查找一个数字是否存在时，时间复杂度是O(1)。空间上，存储1.1万个int类型数字，大约需要44KB，加上哈希表本身的结构开销，整体空间消耗也不大。哈希表的优点是查询速度快，并且不会有误判，结果是100%准确的。
2.布隆过滤器法怎么做到的？
如果对空间要求特别苛刻，也可以考虑用布隆过滤器。布隆过滤器用位数组和多个哈希函数来判断元素是否存在，空间效率很高。比如1.1万个元素，误判率设为0.01%，大概需要143KB空间。布隆过滤器的优点是空间消耗更低，但缺点是有一定的误判率（可能把不在集合中的数误判为存在），但不会漏判。
3.总结
如果需要绝对准确的判断，我会优先选择哈希表。如果数据量更大或者内存非常有限，可以考虑布隆过滤器，前提是能接受极低的误判率。对于1.1万个数来说，哈希表已经非常高效且简单。
二.两个有序数组取交集?代码层面优化?n个数组取交集?
1.用哈希表法解决
两个数组：
我可以先把第一个数组的所有元素放进哈希表，然后遍历第二个数组，判断每个元素是否在哈希表中。这样时间复杂度是O(m+n)，空间复杂度是O(min(m, n))。n个数组：
可以先把第一个数组放进哈希表，然后依次用哈希表和下一个数组取交集，每次都更新哈希表。这样适合数组数量较多但每个数组不太大的情况。
2.用二路查找法（二分查找）解决
两个数组：
如果两个数组长度差异较大，可以遍历较短的数组，对较长的数组用二分查找。时间复杂度是O(m*log n)（m为较短数组长度）。n个数组：
可以先对最短的数组中的每个元素，依次在其他数组中二分查找是否存在。适合数组都已排序且长度差异大时。
3.用二路归并法（双指针） 解决
两个数组：
由于数组有序，可以用双指针分别遍历两个数组，遇到相等的元素就加入结果，否则移动较小的指针。时间复杂度O(m+n)，空间复杂度O(1)（不算输出）。n个数组：
可以两两归并，先取前两个数组的交集，再与第三个数组归并，依次类推。每次归并都用双指针法。这样适合数组数量不多且每个数组都较大的情况。
三.TCP的三次握手和四次挥手
1.三次握手
第一次握手：客户端向服务器发送SYN报文（同步序列号），表示请求建立连接，并发送一个初始序列号seq=x。
第二次握手：服务器收到SYN后，回复SYN+ACK报文。SYN表示同意建立连接，ACK表示确认收到客户端的SYN，同时服务器也发送自己的初始序列号seq=y，并对客户端的SYN进行确认ack=x+1。
第三次握手：客户端收到SYN+ACK后，发送ACK报文，确认收到服务器的SYN，ack=y+1。此时，双方都确认了连接，TCP连接正式建立。
2.四次挥手
第一次挥手：主动关闭方（通常是客户端）发送FIN报文，表示没有数据要发送了，但仍可以接收数据。
第二次挥手：被动关闭方（通常是服务器）收到FIN后，发送ACK报文，确认收到了对方的关闭请求。
第三次挥手：被动关闭方处理完自己的数据后，也发送FIN报文，表示自己也没有数据要发送了。
第四次挥手：主动关闭方收到FIN后，发送ACK报文，确认连接可以关闭。此时，TCP连接彻底断开
四.TCP的重传机制
超时重传（Timeout Retransmission）
发送方为每个未确认的数据包设置一个重传定时器。如果在超时时间内没有收到ACK，就会重传该数据包。超时时间（RTO）会根据网络的往返时延（RTT）动态调整。快速重传（Fast Retransmit）
当发送方连续收到三个相同的ACK（即三次重复ACK），说明有一个数据包丢失，发送方会立即重传该丢失的数据包，而不必等到超时。SACK（选择性确认）
如果接收方支持SACK，可以告诉发送方哪些数据已经收到，哪些还没收到，发送方只需重传丢失的部分，提高效率。拥塞控制与重传配合
每次重传通常会触发拥塞控制机制，比如慢启动、拥塞避免等，防止网络进一步拥塞。
五.TCP和UDP HTTP和HTTPS ARP和RARP
1.tcp和udp
连接方式：
TCP是面向连接的协议，通信前需要三次握手建立连接；UDP是无连接的，发送数据前不需要建立连接。可靠性：
TCP提供可靠的数据传输，具有重传、校验、流量控制和拥塞控制等机制，保证数据不丢失、不重复、按顺序到达；UDP不保证可靠性，数据可能丢失、乱序或重复。传输效率：
UDP头部开销小，传输效率高，适合实时性要求高的场景，比如视频、语音等；TCP由于需要保证可靠性，开销较大，效率略低。数据传输方式：
TCP是面向字节流的，数据以流的形式传输；UDP是面向报文的，数据以独立的报文发送。应用场景：
TCP适合对可靠性要求高的应用，如网页浏览、文件传输、邮件等；UDP适合对实时性要求高、能容忍部分丢包的应用，如视频会议、在线游戏、DNS等。
2.http和https 协议
安全性：
HTTP是明文传输，数据容易被窃听和篡改；HTTPS在HTTP的基础上加入了SSL/TLS加密，数据传输是加密的，能防止窃听和篡改，安全性更高。端口号：
HTTP默认使用80端口，HTTPS默认使用443端口。证书机制：
HTTPS需要申请数字证书，由权威CA机构颁发，用于身份认证和加密通信；HTTP不需要证书。性能：
HTTPS由于有加解密过程，性能开销比HTTP略大，但随着硬件和算法优化，影响已经较小。应用场景：
HTTPS适用于对安全性要求高的场景，比如登录、支付、敏感信息传输等；HTTP适用于对安全性要求不高的普通场景。
3.arp和rarp
ARP和RARP都是工作在数据链路层的协议，主要用于IP地址和MAC地址之间的转换：
ARP（地址解析协议）：
用于已知IP地址，查询对应的MAC地址。比如主机要发送数据时，先通过ARP广播请求目标IP的MAC地址，收到响应后进行通信。ARP常用于局域网内的主机通信。RARP（逆地址解析协议）：
用于已知MAC地址，反查对应的IP地址。常用于无盘工作站等设备刚启动时，只知道自己的MAC地址，通过RARP向网络请求分配IP地址。
六.json和protobuf
1. JSON 和 Protobuf 有什么区别？
格式：JSON 是文本格式，易读易写；Protobuf 是二进制格式，体积更小，效率更高。
可读性：JSON 可直接阅读和编辑；Protobuf 不易直接阅读。
扩展性：Protobuf 支持强类型和向后兼容，字段有编号，易于演进；JSON 灵活但缺乏类型约束。
序列化/反序列化速度：Protobuf 通常比 JSON 更快。
跨语言支持：两者都支持多语言，但 Protobuf 需要生成代码，JSON 直接解析即可。
2. 什么时候选择 JSON，什么时候选择 Protobuf？
JSON：适合前后端交互、配置文件、调试和日志等对可读性有要求的场景。
Protobuf：适合高性能、带宽敏感、数据量大、服务间通信（如微服务、RPC）等场景。
3. Protobuf 如何保证向后兼容和向前兼容？
字段有唯一编号，新增字段时不影响老版本。
删除字段时，编号不能复用，避免冲突。
未知字段会被忽略，保证兼容性。
4. Protobuf 和 JSON 的序列化和反序列化流程分别是什么？
JSON：对象转为字符串（序列化），字符串转为对象（反序列化）。
Protobuf：对象转为二进制流（序列化），二进制流转为对象（反序列化），需要 .proto 文件生成的类。
5. Protobuf 支持哪些数据类型？和 JSON 有什么不同？
Protobuf 支持强类型（int32、int64、float、double、bool、enum、message等），类型更丰富。
JSON 只支持字符串、数字、布尔、数组、对象等基础类型。