网络协议

1. Http有哪些版本？如何查看？

http版本分布

1. 0.9
2. 1.0
3. 1.1(最常见)
4. 2.0(最常见，大厂基本都是2.0)
5. 3.0

查看方式：在控制台打印

window.chrome.loadTimes()
在里面的npnNegotiatedProtocol可以看到http版本

或者

在网页的Network查看请求头，根据请求头判断
有GET / HTTP/1.1就是1.1版本；不同版本结构会不一样；

2. http版本的发展

HTTP 0.9

是第一个版本的HTTP协议，已过时。

• 只允许客户端发送GET请求，不支持请求头。
• 无状态（请求没了就没了）

HTTP 1.0

• 新增请求方式POST
• 新增请求头、http状态码等
• 新增Cookie（让HTTP协议有了状态，例：登录）

HTTP 1.1

• 新增keep-alive长连接
• 新增pipeline管道
• 增加了 PUT、DELETE、OPTIONS、PATCH 等新的方法

HTTP 2.0

• 头部支持二进制协议，支持头部压缩（提升性能）
• 新增多路复用：避免了HTTP的队头阻塞问题

HTTP 3.0

革命性大改版

• 将底层TCP协议改成UDP，彻底解决TCP的队头阻塞问题
• 兼容性还不行，不能大规模使用

3. 什么是长连接？Keep-alive

tcp的每次连接建立都需要三次握手，如果开启长连接就可以避免这种情况。 只需一次“三次握手”就可以进行多次请求。

4. pipeline和长连接的区别？

pipeline：可以让请求并发，并且用的是同一条tcp连接

5. HTTP1.1有哪些特点

1. ⭐HTTP1.1默认使用 Connection:keep-alive（长连接）， 避免了连接建立和释放的开销。

2. ⭐支持pipeline管道传输，并发请求。

3. 并发连接(谷歌浏览器最多6个)：对一个域名的请求允许分配多个长连接（缓解了长连接中的【HTTP的队头阻塞】问题）

4. 增加了 PUT、DELETE、OPTIONS、PATCH 等新的方法

5. 允许数据分块（chunked），利于传输大文件

6. 请求头中引入range字段，支持断点续传

6.HTTP2.0有哪些特点

1. ⭐二进制协议：http1.1版本的头部信息是文本，数据部分可以是文本或二进制；http2版本的头部和数据都是二进制，且统称为“帧”
2. ⭐多路复用：废弃了HTTP1.1的pipeline管道机制，在同一个TCP连接中，客户端和服务器可以同时发送多个请求和响应，并且不用按照顺序来。由于服务器不用按顺序处理响应，避免了“HTTP的队头阻塞”的问题。
3. 头部信息压缩：gzip压缩。
4. 服务端主动推送：允许服务端主动向客户端推送数据
5. 数据流：允许服务端以stream(流)的形式向客户端发送数据。（我们现在常见的deepseek 几个字几个字蹦出来，就是这样流式传输）

7.pipeline和多路复用的区别呢？

我们先对比以下几种发送和接收的形式：

1. 长连接-非pipeline：发一条，收一条，没收到就不能发下一条。
2. 长连接-pipeline：发1，发2，收1，收2。可以并发请求 但是，收和发的顺序必须一致，如果有一个卡住，后面全部卡住（HTTP的队头阻塞）。
3. 多路复用：它是基于http的二进制“分帧”。做到让收到数据和发出请求的顺序不需要一致（解决HTTP的队头阻塞）。【人话：原本的请求得到数据需要一次性收到，现在的数据可以一点一点接收 然后组装起来，哪个接口的先收齐就先组装】

8. HTTP3.0有什么特点？

我们都知道http是基于TCP协议实现的。

TCP的主要作用是以正确的顺序将整个字节流从一个端点传输到另一个端点，但是当流中的某些数据包丢失时，TCP需要重新发送这些丢失的数据包，等到丢失的数据包到达对应端点时才能被HTTP处理，这被称为TCP的队头阻塞问题。

HTTP3.0就是主要解决这个问题的

Google做了一个基于UDP协议的QUIC协议。

QUIC的优势：

1. ⭐使用了UDP协议，不需要进行三次握手，也会缩短TLS(HTTPS)建立连接的时间。
2. ⭐彻底解决了TCP队头阻塞问题
3. 报文头和报文体分别进行认证和加密处理，保障安全性
4. 连接能够平滑迁移（设备在流量和wifi等情况间切换，不会断线重连）

9. 网络是怎么分层的

1. 物理层

作用：传输 0 1 0 1 信号。 代表设备：网线、光纤

2. 数据链路层

该层管理网络层与物理层之间的通信。 作用：将 0 1 0 1 数据封装为帧(一帧是64-1518字节)。 代表作用：Mac地址确认，Arp广播 代表设备：交换机

3. 网络层

该层决定如何将数据从发送方路由到接收方。 代表作用：分配IP地址 代表设备：家用路由器

4. 传输层

该层为两台主机上的应用程序提供端到端的通信(微信聊天)。 代表作用：连接端到端，如：TCP UDP 代表设备：操作系统内核

5. 应用层

规定应用程序的数据格式。主要协议有：HTTP、FTP、Telnet、SMTP、POP3等。

10. TCP和UDP的区别

• ⭐TCP面向连接(如打电话要先拨号建立连接)提供可靠的服务，UDP是无连接的，即发送数据之前不需要建立连接，UDP尽最大努力交付，即不保证可靠交付(没有保障一定收到)。
• ⭐UDP具有较好的实时性，工作效率比TCP高。
• TCP连接只能一对一，UDP支持一对一、一对多、多对一和多对多的交互通信。
• UDP占据更小空间。
• ⭐TCP面向字节流，UDP面向报文。字节流可以一点一点发(流式传输)，UDP一次需要交付一个完整的报文。
• UDP适合一次性传输较小数据的网络应用，如DNS、SNMP(专业的网关 服务器、路由器等)等。

应用场景：

• UDP：直播、游戏
• TCP：网页

11. TCP(建立连接)三次握手

首先我们模拟两个对象，客户端(Client)和服务器(Server)。握手的目的，是让这两位都确认能收到对方的消息。

初始状态：Server(Listen) 服务器监听中

第一次握手：

1. Client发送一个syn数据包(seq=x)，之后改变自己的状态为Client(SYN_SENT) 表示已发送SYN数据包。
2. Server收到之后，改变自己的状态为Server(SYN_RCVD) 表示已收到SYN数据包。

第二次握手：

1. Server返回ACK包+SYN(ack=x+1,seq=y)，其中x+1就表示自己收到了，即C->S已经没问题。
2. Client收到之后，改变自己的状态为Client(Established) 表示已确认。

第三次握手：最后，Client再发送ACK包(ack=y+1),Server收到后，改变自己的状态为Server(Established) 表示已确认。

最终状态：Client(Established)、Server(Established)。双方都确定，那么TCP连接成功。

12. TCP(断开连接)四次挥手

1. 为什么握手是三次，挥手是四次？
2. 断开方为什么要等待2MSL(Maximum Segment Life)才能真正断开？

MSL：代表数据包在网络中能够存在的最长时间(常用是30s\60s\120s)。

第一次挥手：

1. Client发送 FIN包(seq=x+2) ACK包(ack=y+1)，改变状态为Client(FIN_WAIT_1)
2. Server收到后，改变状态为Server(CLOSE_WAIT)

第二次挥手：

1. Server发送 ACK包(ack=x+3)
2. Client收到后，改变状态为Client(FIN_WAIT_2)
3. 重点在这里：服务器需要确认一下，有没有数据没传完。因此这里Client需要等待Server确认完后再告诉它是否断开。所以挥手会比握手多一次。

第三次挥手：

1. Server发送 FIN包(seq=y+1)，改变状态为LAST_ACK。
2. Client收到后，改变状态为Client(TIME_WAIT)

第四次挥手：

1. Client发送 ACK包(ack=y+2)

第四次握手之后，Client并不知道Server收到了没有，有两种情况：

1. 如果Server没有收到ACK，会触发超时重传FIN。
2. 如果Server收到了ACK，就不会再发送消息。

前面的解释中说到，MSL代表数据包存储的最长时间。当第三次挥手后，Client收到消息保存FIN的最长时间是一个MSL，如果在这段时间内Server没有重传那么代表可以了。但最保险的是，Client传过去的ACK包存活时间也过去，因此加起来就是2个MSL的时间。Client就可以放心地释放TCP占用的资源、端口号。

13. 常见的http状态码有哪些

1xx：正在处理你的请求 2xx：请求成功，经典状态码200表示成功请求和响应 3xx：302重定向 304触发协商缓存 4xx：401未登录(过期) 403已登录但这个模块你没有权限 404请求没有的资源 5xx：后端发生问题

14. TCP中的滑动窗口有什么作用

滑动窗口(Sliding window)是一种流量控制技术。通信双方不考虑网络的拥挤情况直接发送数据，导致中间节点阻塞掉包，谁也发不了数据。

TCP中采用滑动窗口来进行传输控制，滑动窗口的大小意味着接收方还有多大的缓冲区(内存占用)可以用于接收数据，发送方可以通过滑动窗口的大小来确定应该发送多少字节的数据。

客户端和服务器达成一致，确定要发送多大的数据包。

TCP维持了一个滑动窗口，它解决端到端的问题，并且动态变化。

15. TCP的拥塞控制有什么作用

某段时间内，对网络中某一资源的需求过多，网络性能就会变差，这种情况叫做拥塞。 拥塞控制 就是为了防止过多的数据注入到网络中。有一个前提，是网络其实是能够承受现有的网络负荷，但是想要通过流量控制，抑制发送端发送的速率，以便接收端来得及接收。

TCP发送方要维持一个拥塞窗口的状态变量，窗口大小取决于网络的拥塞成都，且动态变化。

16. 滑动窗口和拥塞控制的区别？

滑动窗口解决双方本身的问题。 拥塞控制解决双方之间传输的拥堵问题。

滑动窗口：

A去B家玩耍，A家人多准备了8台车。B家院子只能停4台，那么A家人 就分成2批过去，1批四台车。

拥塞窗口：

A去B家玩耍，A家人多准备了8台车。B家院子能停8台，但是今天超级堵车，车只能1台1台出发(隔5分钟出发一辆)。

发送方让自己的发送窗口取 滑动窗口 和 拥塞窗口 中较小的一个。

17. https的加密过程

• 对称加密：一把钥匙能解密也能加密
• 非对称加密：有两把钥匙，一把只加密（公钥），一把只解密（私钥）；Client拿公钥，Server拿私钥

过程：

1. Client发起一个http请求，告诉Server自己支持哪些hash算法。

2. ⭐下发公钥和证书信息：Server把自己的信息以数字证书的形式返回给Client（公钥、网站地址、证书颁发机构、失效日期等）。用公钥来加密信息，私钥由Server持有。

3. 浏览器去校验证书的合法性

4. ⭐生成随机密码(RSA签名)：验证通过，浏览器会生成一个随机的对称密钥(session key) 并用公钥加密，让Server用私钥解密拿到密码。以后双方的通信都用这个密码来做对称加密。

5. ⭐Client生成对称加密算法：经过第四步验证了Server身份之后，Client生成一个对称加密算法，把算法和session key一起用公钥加密后发送给Server。Server通过私钥解密后拿到算法和session key，就可以用算法解密了。

18. https是绝对安全的吗？

不是。有一种攻击叫做 “中间人攻击” 。

如何防范：一般只能去引导用户

1. 不要轻易信任证书，不知名的小网站不要随意访问
2. 浏览器给安全提示，就是有风险，谨慎
3. 不要随意连接公共wifi

19. 浏览器的强缓存和协商缓存

强缓存

强缓存是通过Expires与Cache-Control来控制缓存在本地的有效期，在控制台network可查看。

Expires

HTTP1.0提出的一种方案。由服务端给到过期时间。

Expires:Sun, 14 Jun 2020 02：50：57 GMT

Cache-Control

出现于HTTP 1.1，优先级高于Expires。

Cache-Control: max-age=300 我的资源要在浏览器强缓存300s

协商缓存

当浏览器对某个资源的请求没有命中强缓存，就会发一个请求到服务器，验证协商缓存是否命中：

• 如果协商缓存命中，请求响应返回的HTTP状态为304(Not Modified)，该请求不携带实体数据。
• 若未命中，则返回200并携带实体数据。

Last-Modified If-Modified-Since

是HTTP1.0引入的。表示文件的最后修改日期，浏览器会在请求中携带它，询问服务器在该日期之后资源是否更新，更新则发送新资源，没更新就使用缓存。

ETag If-None-Match

ETag就像一个指纹，资源变化就会导致ETag变化。

两者的区别？

Last-Modified精度只能到秒，但是性能更好 ETag更精细，但是性能不如前者，因为文件变化都要重新计算hash值

20. 什么是xss攻击？如何防范

XSS指的是跨站脚本攻击，是一种代码注入攻击。攻击者通过在网站注入恶意脚本，使之在用户的浏览器上运行，从而盗取用户的信息如cookie等。

如何防范？

1. 前端对表单提交，敏感字符进行转义，例如："<","/"等，破坏它的script标签或sql语句
2. 但前端防范不一定是绝对安全的，因为可以抓包篡改
3. 核心是后台进行处理，比如转义

21. 什么是csrf攻击？如何防范

csrf又叫跨站请求伪造，一般需要借助XSS产生的漏洞。

• 比如某网站的评论区有个同域名的链接，你不小心点到了，就把你的cookie也带了过去，然后他就可以用你的账号进行所有事情，例如转账给他。

如何防范？

1. 堵住XSS漏洞
2. 在http header中添加token校验(因为请求时cookie会自动携带，但token需要前端写才会带上，所以可以与后端协商带上token)
3. 校验请求http reffer（可以查到，发起这个请求的网站域名是什么，如果不是我们的域名就不让他访问）

22. 什么是websocket？

是HTML5出的协议。跟HTTP协议基本没有关系（有一丢丢交集），可以说它是HTTP协议上的一种补充。 最大的特点就是：服务器和客户端都可以主动向对方推送消息，双向平等对话，允许服务端和客户端进行全双工(full-duplex)的通信。

全双工通信：就像打电话，双方可以同时说话和同时听到对方说话。

其他特点：

1. 建立在TCP协议上，服务端的实现比较容易
2. 与HTTP协议有着良好的兼容性。默认端口也是80和443。握手阶段采用HTTP协议，因此握手时不容易屏蔽，能通过各种HTTP代理服务器。
3. 数据轻量、性能开销小、通信高效
4. 可发送文本、二进制数据
5. ⭐没有同源限制
6. ⭐协议标识符是ws(如果加密，则为wss)

23. ⭐Socket和WebSocket的关系？

它们的关系就好像Java和JavaScript一样，没有关系。

Socket是对TCP/IP协议的封装和应用：nodejs的内置模块socket，可以去操作TCP。

1. ⭐socket是传输层接口，直接操作TCP/UDP协议
2. ⭐websocket是应用层协议，依赖HTTP握手后升级为Websocket协议。

前言

前阵子在实现应用间链接跳转时碰到了个问题，ios 下实现用户未安装小黑盒跳转 apple store，安装了则跳小黑盒 app，起初使用 scheme 实现，实现的方案是延时 检测 用户页面是否 visible，这种方案在用户切屏速度过快时就会失效，如下

tryOpenChatApp() {
  const chatProtocolUrl = `heyboxchat://***`;
  window.location.href = chatProtocolUrl;

  setTimeout(() => {
    if (document.visibilityState === 'visible') {
      this.redirectToChatDownload();
    }
  }, 2000);
},

后面把协议换成了 Universal Link 就不需要延时检测，Universal link 能够天生支持未安装应用直接跳商店，本期文章就来了解下 Universal link 与 URL Scheme 的关系

URL Scheme

URL Scheme 是一种自定义的 URL 协议，允许应用注册特定的协议头来响应特定格式的链接。当用户点击包含该 scheme 的链接时，系统会尝试打开注册了该 scheme 的应用。

一个典型的 URL Scheme 链接结构如下：

scheme://host/path?query=value

比如 小黑盒 的 scheme 就是 heyboxchat://

URL Scheme 的工作原理如下：

1. 应用在 Info.plist（iOS）或 AndroidManifest.xml（Android）中注册自定义 scheme
2. 当用户点击包含该 scheme 的链接时，操作系统查找注册了该 scheme 的应用
3. 如果找到对应应用，系统启动该应用并传递链接参数
4. 如果应用未安装，通常会显示错误提示或无响应

URL Scheme 的优势

1. 实现简单：只需要在应用配置文件中注册 scheme 即可
2. 跨平台支持：iOS 和 Android 都支持这种方式
3. 历史悠久：是最早的应用间跳转解决方案
4. 灵活性高：可以传递复杂的参数和路径信息

URL Scheme 的局限性

1. 安全性问题：任何应用都可以注册相同的 scheme，存在被恶意应用劫持的风险
2. 用户体验差：如果目标应用未安装，用户会看到错误提示
3. 无法验证应用身份：系统无法确保打开的是预期的应用
4. 协议冲突：多个应用可能注册相同的 scheme，导致不确定性

下面看 Universal Link

Universal Link

Universal Link 是苹果在 iOS 9 中引入的新技术，旨在解决 URL Scheme 存在的安全性和用户体验问题。它通过将应用与特定的网站域名关联，提供了更安全、更可靠的深度链接解决方案。

Universal Link 的工作原理

1. 开发者在应用中配置 Associated Domains，指定关联的域名
2. 在对应的网站服务器上放置 apple-app-site-association 文件
3. 用户安装应用时，iOS 系统验证应用与域名的关联关系
4. 当用户点击该域名下的链接时，系统优先打开关联的应用
5. 如果应用未安装，链接会在浏览器中正常打开网页

现在看下 apple-app-site-association 文件

这是一个 JSON 格式的配置文件，必须放置在网站根目录或 .well-known 目录下：

{
  "applinks": {
    "apps": [],
    "details": [
      {
        "appID": "TEAMID.com.example.app",
        "paths": [
          "/product/*",
          "/user/*",
          "NOT /admin/*"
        ]
      }
    ]
  }
}

Universal Link 的优势

1. 安全性高：通过域名验证确保应用身份的唯一性
2. 用户体验好：应用未安装时自动跳转到网页，无错误提示
3. 无需用户确认：系统直接打开应用，无需用户选择
4. SEO 友好：链接本身就是有效的网页 URL
5. 支持延迟深度链接：可以在应用安装后跳转到指定页面

Universal Link 同样也有限制

1. 仅支持 iOS：Android 有类似的 App Links 技术，但实现方式不同
2. 需要 HTTPS：必须使用安全的 HTTPS 协议
3. 域名要求：需要拥有并控制一个域名
4. 配置复杂：需要同时配置应用和服务器端
5. 调试困难：问题排查相对复杂

Universal Link 与 URL Scheme 的关系

Universal Link 和 URL Scheme 并不是完全对立的技术，而是互补的关系：

1. Universal Link 主要解决从网页到应用的跳转
2. URL Scheme 更适合应用间的直接跳转
3. 在实际项目中，两者经常同时使用

技术层面的区别

特性	Universal Link	URL Scheme
安全性	高（域名验证）	低（可被劫持）
用户体验	好（无错误提示）	差（应用未安装时报错）
实现复杂度	高	低
平台支持	iOS（Android 有 App Links）	跨平台
网络要求	需要 HTTPS	无
域名要求	必须	不需要

使用场景对比

1. 从网页跳转到应用：优先使用 Universal Link
2. 应用间直接跳转：使用 URL Scheme
3. 分享功能：Universal Link 更适合
4. 第三方应用集成：通常使用 URL Scheme
5. 营销推广：Universal Link 提供更好的用户体验

在实际开发中，建议采用混合使用策略：

1. 对外分享和营销推广使用 Universal Link
2. 应用间跳转使用 URL Scheme
3. 提供降级方案：Universal Link 失败时回退到 URL Scheme

实现示例

iOS 应用中同时支持两种方式：

// Universal Link 处理
func application(_ application: UIApplication,
                continue userActivity: NSUserActivity,
                restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void) -> Bool {
    if userActivity.activityType == NSUserActivityTypeBrowsingWeb {
        if let url = userActivity.webpageURL {
            // 处理 Universal Link
            handleUniversalLink(url)
            return true
        }
    }
    return false
}

// URL Scheme 处理
func application(_ app: UIApplication,
                open url: URL,
                options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
    // 处理 URL Scheme
    handleURLScheme(url)
    return true
}

调试和测试

1. Universal Link 调试：

   • 使用苹果的验证工具检查配置
   • 通过 Safari 测试链接跳转
   • 检查 apple-app-site-association 文件的可访问性

2. URL Scheme 调试：

   • 在 Safari 地址栏直接输入 scheme 链接测试
   • 使用模拟器和真机分别测试
   • 检查应用是否正确注册了 scheme

App Links

Android 平台有类似 Universal Link 的技术叫做 App Links：

1. 同样需要域名验证
2. 使用 Digital Asset Links 文件进行验证
3. 提供类似的安全性和用户体验

Intent Filter

Android 的 Intent Filter 类似于 iOS 的 URL Scheme：

1. 在 AndroidManifest.xml 中配置
2. 支持自定义协议和标准 HTTP/HTTPS 链接
3. 可以处理多种类型的链接

最后

Universal Link 和 URL Scheme 都是移动应用生态系统中重要的深度链接技术，它们各有优势和适用场景：

1. URL Scheme 作为传统方案，实现简单但存在安全性和用户体验问题，比如文中开头提到的问题
2. Universal Link 作为 ios 的链接技术，提供了更好的安全性和用户体验，但实现相对复杂
3. 在实际应用中，两者往往结合使用