Link Search Menu Expand Document
iOS 面试八股文

计算机网络

HTTP

HTTP 和 HTTPS 的区别

  • HTTP 是超文本传输协议，HTTPS 是超文本传输安全协议
  • HTTP 默认端口 80，HTTPS 默认端口 443
  • HTTP 使用明文传输，HTTPS 使用加密传输
  • HTTP 页面响应速度比 HTTPS 快
  • HTTPS 是建立在 SSL/TLS 之上的 HTTP 协议
  • HTTPS 需要先通过非对称加密得到在传输过程中使用的对称加密密钥

HTTPS传输过程

  1. 建立 TCP 连接
  2. TLS 握手：
    1. 客户端把自己可以使用的加密算法和其他信息发送给服务器
    2. 服务器把选择的加密算法和自己的数字证书发送给客户端
    3. 客户端验证服务器的证书的有效性
    4. 双方使用服务端的公私玥来进行非对称加密，交换对称加密的密玥
    5. Session 建立，双方可以在这个 Session 中通信
  3. 数据通信：双法可以使用之前协商好的对称加密的密玥进行通信

HTTP 1.0

每个请求都需要一个新的 TCP 链接，收到响应后这条链接就会被断掉。这样就会导致很多资源用在建立和断开 TCP 连接上。

HTTP 1.1

引入了持久链接（Persistence Connection）可以在一个 TCP 链接中进行多个请求和响应。通过复用 TCP 链接减少了资源的消耗，并且降低了响应的延迟。 在一些 HTTP 客户端（如浏览器）引入了连接池，进一步增强优化了连接性能。

HTTP2.0

HTTP/2 是对 HTTP/1 的升级，完全兼容 HTTP/1 并且在性能上有了很大的提升

http/2 升级内容：

  1. 二进制分帧：在二进制分帧层上，http2.0会将所有传输信息分割为更小的消息和帧，并对它们采用二进制格式的编码将其封装，新增的二进制分帧层同时也能够保证http的各种动词，方法，首部都不受影响，兼容上一代http标准。其中，http1.X中的首部信息header封装到Headers帧中，而request body将被封装到Data帧中。
  2. 多路复用（multiplexing）/连接共享：http 2.0 连接都是持久化的，而且客户端与服务器之间也只需要一个连接（每个域名一个连接）即可。http2连接可以承载数十或数百个流的复用，多路复用意味着来自很多流的数据包能够混合在一起通过同样连接传输。当到达终点时，再根据不同帧首部的流标识符重新连接将不同的数据流进行组装。
  3. 头部压缩
  4. 请求优先级
  5. 服务端推送

TCP

握手

  1. 客户端向服务端发送一个不包含应用数据的报文段。SYN=1 和 随机的起始序号（seq=client_isn）
  2. 服务端向客户端发送一个不包含应用数据的允许连接报文段。SYN=1 ACK=client_isn+1 和随机起始序号（seq=server_isn）。服务端分配缓存和变量
  3. 客户端再次确认。ACK=server_isn+1 SYN=0。客户端分配缓存和变量

断开

  1. 客户端向服务端发送报文段，客户端进入 FIN_WAIT_1 状态。FIN=1 和一个序号 seq=x（根据上一个序号）
  2. 服务端回送确认报文段，服务端进入 CLOSED_WAIT 状态，客户端收到后进入 FIN_WAIT_2 状态。ACK=1 ACKnum=x+1
  3. 服务端发送终止报文段，服务端进入 LAST_ACK 状态。FIN=1 seq=y（根据上一个序号）
  4. 客户端确认终止报文段，客户端进入 TIME_WAIT 状态，服务端收到后进入 CLOSED 状态，客户端等待 2MSL 后关闭连接。ACK=1 ACKnum=y+1

握手或者挥手次数为什么需要3次和四次，能少一次吗？

不能，需要这些次数的原因是防止报文在传递过程中出现丢包或者超时的问题。比如说在握手阶段如果没有第三个报文，那么服务端无法确认客户端是否收到了自己发送的确认报文，那就没办法确定后面到来的 TCP 报文的正确和安全性。

TCP 和 UDP 的区别

  是否有连接 是否可靠 性能
TCP 有 可靠 较差
UDP 无 不可靠 较好

流量控制（拥塞控制，Flow Control）和滑动窗口（Sliding Window）

  • 流量控制是一种机制，用来确保发送方发送出去的内容不会超出接收方能够接受和处理的范围。
  • 滑动窗口是一种用来实现流量控制的技术。
  • 滑动窗口：接收方维护一个发送窗口，发送方维护一个接收窗口。
    • 发送方会根据收到的内容来控制自己的窗口大小和是否移动窗口。窗口大小是根据接收方的处理能力和容量来决定的，可以伸缩。窗口的移动是根据接收方发送的 ACK 来决定的。
    • 接收方会根据自己的处理速度来计算自己的窗口大小并通知发送方。

SSL

握手

  1. 客户发送它支持的密码算法列表，连同一个客户的不重数。
  2. 从该列表中，服务器选择一种对称算法（如AES）、一种公钥算法（如RSA）和一种MAC算法。它把它的选择以及证书和一个服务器不重数返回给客户。
  3. 客户验证该证书，提取服务器的公钥，生成一个前主密钥（Pre-Master Secrete, PMS），用服务器的公钥加密该 PMS，并将加密的 PMS 发送给服务器。
  4. 使用相同的密钥导出函数，客户和服务器独立地从 PMS 和不重数中计算出主密钥（Master Secrete，MS）。然后该 MS 被切片以生成两个密码和两个 MAC 密钥。此外，当选择的对称密码应用于 CBC（例如 3DES 或 AES），则两个初始化向量（IV）也从该 MS 获得，这两个 IV 分别用于该连接的两端。自此以后，客户和服务器之间发送的所有报文均被加密和鉴别（使用 MAC）。
  5. 客户发送所有握手报文的一个 MAC。
  6. 服务器发送所有握手报文的一个 MAC。

最后两步使握手免遭篡改。

Mac

Message Authentication Code. 这个消息授权码是一种用来确保信息的完整性和授权的可靠性技术。

当消息从一方发送给另一方时，会使用一种加密算法处理这条消息病得到 Mac，并且在发送时会带上 mac 和原本的消息；当接收方收到消息时，会使用自己的加密算法处理消息生成自己的 Mac，如果接收方自己生成的 Mac 和收到的 Mac 不同就说明消息被篡改了。

断开

通过终止 TCP 连接来结束 SSL 会话。为了防止被截断攻击就在类型字段中指出该记录是用于终止 SSL 会话的。接收方通过使用的 MAC 就可以得知是否是一个正常的关闭。

WebSocket

下面内容主要参考自 WebSocket协议（一）- 简介以及连接建立过程

什么是WebSocket

WebSocket 是 HTML5 中提供的一种在单个 TCP 连接上进行全双工通讯的协议。

WebSocket 经过一次握手就可以建立全双工通讯。

Websocket 和 HTTP 的关系

WebSocket 和 HTTP 都是建立在 TCP 之上的应用层协议，它不是 HTTP 的增强。

在建立连接的过程中，WebSocket 和 HTTP 有相似之处，下面详细说。

WebSocket 建立连接的过程

首先要建立 TCP 连接，之后建立 WebSocket 连接。

  1. 客户端向服务端发送一个握手包，这个握手包的格式必须符合 HTTP 报文格式的规范。其中：
    • 方法必须为 GET 方法
    • HTTP 版本不能低于 1.1
    • 必须包含 Upgrade 头部，值必须为 websocket
    • 必须包含Sec-WebSocket-Key头部，值是一个Base64编码的16字节随机字符串。
    • 必须包含Sec-WebSocket-Version头部，值必须为13
  2. 服务端验证客户端的握手包符合规范之后会向客户端发送一个握手包。其中：
    • 必须包含Connection头部，值必须为Upgrade
    • 须包含一个Upgrade头部，值必须为websocket
    • 必须包含一个Sec-Websocket-Accept头部，值是根据如下规则计算的：
      • 首先将一个固定的字符串258EAFA5-E914-47DA-95CA-C5AB0DC85B11拼接到Sec-WebSocket-Key对应值的后面。
      • 对拼接后的字符串进行一次SHA-1计算
      • 将计算结果进行Base-64编码
  3. 客户端收到服务端的握手包之后，验证报文格式时候符合规范，以2）中同样的方式计算Sec-WebSocket-Accept并与服务端握手包里的值进行比对。

当连接建立完成后，WebSocket 就和 HTTP 没有什么关系了。

DNS

通俗的说法： DNS，或者说域名系统，是互联网中非常重要的一部分。它就像互联网的 ‘电话簿’，帮助我们将易于记忆的域名（比如网站的名字）转换成计算机能够理解的数字 IP 地址，以便我们能够找到并访问网站。就像在城市中找到一座建筑物一样，我们在浏览器中输入域名，DNS 就会帮助我们找到相应的 IP 地址，然后我们就能够连接到那个网站。整个过程是通过一系列的 ‘询问’ 和 ‘指引’ 来实现的，类似于询问导航系统去找到目的地的路线一样。

基本原理

  • 域名层次结构：域名是分层次结构的，从右到左依次为：顶级域（TLD，Top-Level Domain）、二级域、三级域等。例如，www.example.com 中，“com” 是顶级域，“example” 是二级域，“www” 是三级域。
  • 域名解析：当用户在浏览器中输入一个域名并按下回车键时，浏览器会向本地计算机的 DNS 解析器发送查询请求，询问该域名对应的 IP 地址。
  • 递归解析：本地 DNS 解析器首先会查询本地缓存，如果找到了匹配的 IP 地址，则直接返回。如果没有找到，它会向根域名服务器发送查询请求，跟域名服务器会指导解析器转向下一级域名服务器。
  • 迭代解析：TLD 域名服务器会指引解析器前往下一级域名服务器，例如 com 域名服务器。这个过程会继续迭代，直到找到负责该域名的授权域名服务器。
  • 授权解析：当解析器到达负责域名的授权域名服务器时，它会查询该域名的详细记录，，例如 A 记录（IP 地址）或 CNAME 记录（指向另一个域名）。授权域名服务器将查询结果返回给本地解析器。
  • 结果返回：本地解析器收到结果后，将 IP 地址返回给浏览器。浏览器可以使用此 IP 地址与远程服务器建立连接，获取网页内容等。

CDN

CDN（Content Delivery Network，内容分发网络）是一种用于提高网络资源访问速度和性能的技术架构。它通过在全球各地部署服务器节点，将内容（如网页、图像、视频和其他静态资源）存储在距离用户更近的位置，从而加速资源的传输和加载。

CDN 的工作原理如下：

  • 缓存和分发：CDN 将原始服务器上的内容复制到分布在不同地理位置的服务器节点上。这些服务器节点被称为边缘服务器。当用户请求访问某个资源时，CDN 会根据用户的位置选择离用户最近的边缘服务器，从而减少数据传输的延迟。

  • 智能路由：CDN 使用智能路由技术，根据用户的地理位置和网络状况，将用户的请求路由到最佳的边缘服务器。这可以最大限度地降低数据传输的时间和成本。

  • 内容压缩和优化：CDN 可以对内容进行压缩和优化，以减少数据传输量，提高加载速度。这包括对图片、脚本和其他资源进行压缩、缩小和合并，以及使用缓存策略减少重复加载。

  • 负载均衡：CDN 可以将用户的请求分配到多个边缘服务器上，从而分担原始服务器的负载，保证服务器的稳定性和高可用性。

  • 故障转移：如果某个边缘服务器发生故障，CDN 可以将请求重新路由到其他可用的服务器，确保用户能够继续访问资源。

RTMP

RTMP（Real-Time Messaging Protocol，实时消息传送协议）是一种用于实时音视频传输和流媒体播放的协议。它最初由 Adobe 开发，用于将音频、视频和数据流从媒体服务器传输到客户端，适用于直播、视频会议、在线游戏和其他实时多媒体应用。

RTMP 的工作原理如下：

  • 传输协议：RTMP 使用 TCP（Transmission Control Protocol）作为传输层协议，这确保了数据的可靠传输，但也会带来一些延迟。

  • 通道：RTMP 通过多个通道（channels）来传输不同类型的数据，包括音频、视频、控制消息等。每个通道承载特定的数据流，从而实现多媒体的分离传输。

  • 三种模式：

    • 发布者模式（Publishing Mode）：在这个模式下，视频流由发布者发送到流媒体服务器，然后可以被多个观众订阅和观看。
    • 订阅者模式（Subscribing Mode）：观众可以订阅流媒体服务器上的实时流，收听音频或观看视频。
    • 数据模式（Data Mode）：除了音视频流，RTMP 还支持发送元数据、事件消息等其他类型的数据。

  • 帧结构：RTMP 数据被划分为小的数据包，称为帧（frames）。每个帧可以包含音频、视频或其他类型的数据。帧结构允许同时传输多种类型的数据，实现多媒体的同步播放。

  • 流媒体服务器：RTMP 协议需要使用专门的流媒体服务器来处理音视频的分发和处理。一些常见的流媒体服务器包括 Adobe Media Server、NGINX-RTMP 等。

需要注意的是，由于 RTMP 使用了 TCP 协议，它的延迟相对较高，不适合需要低延迟的应用。此外，由于开放的 RTMP 协议的性能和兼容性问题，许多服务正在逐渐转向使用更现代的协议，如 HLS（HTTP Live Streaming）和 DASH（Dynamic Adaptive Streaming over HTTP）来进行流媒体传输。