网络：OSI 的七层模型分别是？各自的功能是什么？

OSI 的七层模型分别是？各自的功能是什么？

  • 物理层：底层数据传输，比如网线、网卡标准
  • 数据链路层：定义数据的基本格式，如何传输，如何标识。比如网卡MAC地址
  • 网络层：定义IP编码，定义路由功能，比如不同设备的数据转发
  • 传输层：端到端传输数据的基本功能，比如TCP、UDP
  • 会话层：控制应用程序之间会话能力，比如不同软件数据分发给不停软件
  • 表示层：数据格式标识，基本压缩加密功能。
  • 应用层：各种应用软件，包括 Web 应用。

注意：

  • 网络七层模型是一个标准，而非实现。
  • 网络四层模型是一个实现的应用模型。
  • 网络四层模型由七层模型简化合并而来。

网络的五层模型

  • 应用层：负责向用户提供一组应用程序，比如 HTTP、DNS、FTP 等;
  • 传输层：负责端到端的通信，比如 TCP、UDP 等；
  • 网络层：主要是IP协议，负责寻址和路由
  • 数据链路层：负责网络包的封装、分片、路由、转发，比如 IP、ICMP 等；
  • 物理层：负责网络包在物理网络中的传输，比如网络包的封帧、 MAC 寻址、差错检测，以及通过网卡传输网络帧等；

每一层对应的网络协议

  • 应用层：
    • 超文本传输协议：HTTP
    • 文件传输协议：FTP
    • 简单邮件协议：SMTP
    • 域名协议：DNS
    • 安全外壳协议：SSH
    • 动态主机配置协议：DHCP
    • 远程登录协议：TELNET
  • 传输层：
    • 传输控制协议：TCP
    • 用户数据报文协议：UDP
  • 网络层：
    • 网际协议：IP
    • 地址转换协议：ARP
    • 反向地址转换协议：RARP
    • Internet控制报文协议：ICMP
    • Internet组管理协议：IGMP
    • 路由信息协议：RIP
    • 分布式链路状态协议：OSPF
    • 边界网关协议：BGP
  • 数据链路层：
    • 自动重传协议：ARQ
    • 停止等待协议：CSMA/CD
    • 点对点协议：PPP
  • 物理层：
    • 中继器
    • 集线器
    • 网线
    • HUB

在这里插入图片描述

IP地址有哪些分类？

  • A类地址(1~126)：网络号占前8位，以0开头，主机号占后24位。
  • B类地址(128~191)：网络号占前16位，以10开头，主机号占后16位。
  • C类地址(192~223)：网络号占前24位，以110开头，主机号占后8位。
  • D类地址(224~239)：以1110开头，保留位多播地址。
  • E类地址(240~255)：以1111开头，保留位今后使用

ARP协议的工作原理

网络层的ARP协议完成了IP地址到物理地址的映射。

  • 首先，每台主机都会在自己的ARP缓冲区中建立一个ARP列表，以表示IP地址和MAC地址的对应关系。当源主机需要将一个数据包发送到目的主机时，会先检查自己的ARP列表中是否存在该IP地址对应的MAC地址，如果有，就直接将数据包发送到这个MAC地址；如果没有，就向本地网段发起一个ARP请求的广播包，查询此目的主机对应的MAC地址
  • 此ARP请求数据包里包括源主机IP地址、硬件地址、以及目的IP地址。网络中所有主机收到这个ARP请求后，会检查数据包中的目的地址IP是否和自己的IP地址一致，如果不相同则忽略此数据包；如果相同，该主机首先将发送端的MAC地址和IP地址添加到自己的ARP列表中，如果ARP表中已经存在该IP的信息，则覆盖，然后给源主机发送一个ARP响应数据包，告诉对方自己是它需要查找的MAC地址；源主机收到这个ARP响应数据包后，将得到的目的主机的IP地址和MAC地址添加到自己的ARP列表中，并利用此信息开始数据的传输。如果源主机一直没有收到 ARP 响应数据包，表示 ARP 查询失败

为什么需要四次挥手？三次不行？

  • 第一次挥手： 主动关闭方调用close函数，这是会发生一个FIN包，表示需要关闭连接，此时主动方进入FIN_WAIT1状态
  • 第二次挥手：被动关闭方的TCP协议栈收到FIN之后，先给主动关闭方发送一个ACK ，然后放一个EOF到接收缓冲区中，此时被动关闭方进入CLOSE_WAIT状态。主动方接收到这个ACK之后，就会进入FIN-WAIT-2状态
  • 第三次挥手：被动关闭方应用程序读到EOF之后，就应该调用close，这会导致它的TCP也发送一个FIN包，此时被动方进入LAST_ACK状态，
  • 第三次挥手：主动方接收到到FIN之后，就会进入TIME-WAIT状态，然后ACK被动方发来的这个FIN。
    • 注意，客户端必须现在TIME_WAIT状态2MSL才进入CLOSED状态，以确保服务端收到自己的ACK报文
    • 服务端接收到最后的ACK之后，就会结束LAST_ACK，进入CLOSE状态

关于MSS、MTU、MSL

  • MTU：一个网络包的数据长度，一以太网中是1500字节
  • MSS：除去IP和TCP头部之后，一个网络包所能容纳的TCP数据的最大长度 。 如果HTTP请求消息比较长，超过了MSS的长度，TCP就会把数据进行拆包，而不是一次性发送所有数据
  • MSL：Maximum Segment Lifetime的英文缩写，可译为“最长报文段寿命”，它是任何报文在网络上存在的最长的最长时间，超过这个时间报文将被丢弃。我们都知道IP头部中有个TTL字段，TTL是time to live的缩写，可译为“生存时间”，这个生存时间是由源主机设置设置初始值但不是但不是存在的具体时间，而是一个IP数据报可以经过的最大路由数，每经过一个路由器，它的值就减1，当此值为0则数据报被丢弃，同时发送ICMP报文通知源主机。

在这里插入图片描述

为什么 TIME-WAIT 状态必须等待 2MSL 的时间呢？

（1）为了保证A发送的最后一个ACK报文段能够到达B。这个ACK报文段有可能丢失，因而使处于LAST-ACK状态的B对已发送的 FIN + ACK 报文段的确认。B会超时重传这个FIN-ACK报文段，而A就能在2MSL 时间内（超时 + 1MSL 传输）收到这个重传的 FIN+ACK 报文段。接着 A 重传一次确认，重新启动 2MSL 计时器。最后，A 和 B 都正常进入到 CLOSED 状态。如果 A 在 TIME-WAIT 状态不等待一段时间，而是在发送完 ACK 报文段后立即释放连接，那么就无法收到 B 重传的 FIN + ACK 报文段，因而也不会再发送一次确认报文段，这样，B 就无法按照正常步骤进入 CLOSED 状态。

（2）防止已失效的连接请求报文段出现在本连接中。A在发送完最后一个ACK报文段之后，再经过时间2MSL，就可以使得本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使得下一个连接中不会出现这种旧的连接请求报文段

保活记时器

除了时间等待计时器之外，TCP还有一个保活计时器。设想这样的场景：客户已主动与服务器建立了TCP连接，但是后来客户端的主机突然发生故障。显然，服务器之后就不能再接收到客户端发来的数据，因此，应该有措施使得服务器不要在白白等待下去。这就需要使用保活定时器了。

服务器每收到一次客户的数据，就重新设置保活计时器，时间的设置通常是两个小时。如果两个小时都没有收到客户端的数据，服务端就发送一个探测报文段，以后每隔75s就发送一次。如果连续发送10个探测报文段之后仍然无客户端响应，服务端就认为客户端出了故障，接着就关闭这个连接

TCP是如何保证可靠的？

  • 首先，采用三次握手来建立TCP连接，四次挥手来释放TCP连接，从而保证建立的传输信道是可靠的
  • 其次，TCP采用了超时自动重传来保证数据传输的可靠性，使用滑动窗口来保证接收方能够及时处理所接收到的数据，进行流量控制
  • 最后，TCP使用慢开始、拥塞避免、快速重传、快速恢复来进行拥塞控制，避免网络拥塞

其他回答：

  • 建立连接（标志位）：通信前确认通信实体存在
  • 数据校验（检验和）：如果校验包出错，则丢弃报文段并且不给出响应，这时TCP会发生数据端超时后会重发数据
  • 序号机制（序号、确认号）：
    • 对失序数据重新排序：因为TCP报文段底层是IP段，而IP是无序，TCP会对失序的数据进行重新排序、然后才交给应用层
    • 丢弃重复数据：对于重复数据，能够丢弃重复数据；
  • 应答机制：当TCP收到自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒
  • 超时重传（定时器）：当TCP发出一个段之后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段
  • 流量控制：TCP 连接的每一方都有固定大小的缓冲空间。TCP 的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP 使用的流量控制协议是可变大小的滑动窗口协议。

什么是ARQ协议？

（0）刚开始的时候是使用停止等待协议（注意，这不是ARQ协议）

  • 停止等待协议是为了可靠传输，它的基本原理是每发送完一个分组就停止发送，等待对方确认。在收到确认后在发下一个分组。
  • 在停止等待协议中，如果接收方收到重复分组，就丢弃该分组，但是同时还要发送确认。
  • 主要包括如下几种情况：无差错情况、出现差错情况（超时重传）、确认丢失和确认迟到

（1）自动重传请求ARQ协议

  • 停止等待协议中超时重传是指只要超过一段时间仍然没有收到确认，就认为刚刚的分组丢失了，救护重传前面发送过的分组。
  • 因此每发送完一个分组就需要设置一个超时计时器，其重传时间应该比数据在分组传输的平均往返时间更长一些。

（2）连续ARQ协议

  • 连续ARQ协议可以提高信道利用率
  • 发送方维持一个发送窗口，凡是位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认
  • 接收方一般采用累计确认，对按序到达的最后一个分组发送确认，表明这个分组为止的剩余分组都已经正确收到了

什么是滑动窗口

TCP利用滑动窗口实现流量控制的机制。

（1）TCP是双工协议，双方可以同时通信，所以发送方接收方各自维护一个发送窗口和接收窗口

  • 发送窗口：用来控制发送方可以发送的数据大小，其中发送窗口的大小由接收端返回的TCP报文段中窗口字段来控制，接收方通过此字段告知发送方自己的缓冲（受系统、硬件等限制）大小
  • 接收窗口：用来标记可以接收的数据大小

（2）TCP是流数据，发送出去的数据流可以被分为以下四部分：已发送且被确认部分 | 已发送未被确认部分 |未发送但可发送部分 | 不可发送部分，其中发送窗 = 已发送未确认部分 + 未发但可发送部分。接收到的数据流可分为：已接收 | 未接收但准备接收 | 未接收不准备接收。接收窗 = 未接收但准备接收部分

（3）TCP报文的头部中有两个字段，一个是ACK确认号，一个是windows窗口值，在每次数据传递过程中，收发双方都会传递这两个字段，ACK表示对方已经对小于ACK-1的报文进行确认，发送方能够以此为动态调整窗口的左边界，windows窗口表示接收方能够接收的数据大小，发送方能够根据此动态调整窗口的右边界，这就形成了窗口的向前滑动，所以就叫做滑动窗口

发送窗内数据只有当接收到接收端某段发送数据的ACK响应时才移动发送窗，左边缘紧贴刚被确认的数据。接收窗也只有接收到数据且最左侧连续时才移动接收窗⼝。

谈下你对流量控制的理解？

早期的网络通信中，通信双方不会考虑网络的拥挤情况。由于大家不知道网络拥塞情况，同时发送数据，导致中间节点阻塞掉包，谁也发不了数据，所以就有了滑动窗口机制来解决这个问题。

  • TCP利用滑动窗口来实现流量控制，流量控制是为了控制发送方发送速率，保证接收方来得及接收。只有窗口内的部分数据才能发送
  • 当滑动窗口为0时，发送方一般不能再发送数据报，但是有两种情况例外，一种是可以发送紧急数据另一种是发送方可以发送一个1字节的数据报来通知接收方重新声明它希望接收的下一字节以及发送方的滑动窗口大小

谈下你对TCP拥塞控制的理解？使用了哪些算法

  • 拥塞控制和流量控制不同，拥塞控制是一个全局性的过程，而流量控制指的是点对点通信量的控制。在某段时间，如果对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况叫做拥塞。
  • 拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使得网络中的路由器或链路不至于过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。
  • 拥塞控制是一个全局性的过程，涉及到所有主机，所有路由器，以及与降低网络传输性能相关的所有因素。而流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做的是抑制发送端发送数据的速率，以便使接收端来得及接收。

TCP拥塞控制采用了四种算法：慢开始、拥塞避免、快重传、快恢复。在网络层也可以使路由器采用适当的分组丢弃策略（如：主动队列管理 AQM），以减少网络拥塞的发生。

对于拥塞控制来说，TCP 主要维护两个核心状态：

  • 拥塞窗口cwnd：
    • 拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。
    • 发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。
  • 慢启动阈值ssthresh：用来选择
    • 当 cwnd < ssthresh 时，使用慢开始算法
    • 当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。
    • 当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞控制避免算法。

慢开始&&拥塞避免

当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的拥塞情况。所以先探测一下，即：

  • 在开始传输的一段时间，发送端和接收端会首先通过三次握手建立连接，确定各自接收窗口大小，然后初始化双方的拥塞窗口（cwnd初始值为1），接着每经过一轮 RTT（收发时延，也叫做传播轮次），cwnd加倍，直到达到慢启动阈值。
  • 达到阀值后让拥塞窗口cwnd缓慢增大，即每经过一个往返时间 RTT 就把发送方的cwnd 加 1，当发⽣拥塞（超时未收到确认），将阀值减为原先⼀半，继续执⾏线性增加，这个过程为拥塞避免。

无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到确认），就要把慢开始门限ssthresh设置为出现拥塞时的发送方窗口值的一半（但不能小于2）。然后把拥塞窗口cwnd重新设置为1，执行慢开始算法。这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。

拥塞控制的具体过程如下：
（1）TCP连接初始化，将拥塞窗口设置为1
（2）执行慢开始算法，cwnd按指数规律增长，直到cwnd=ssthresh时，开始执行拥塞避免算法，cwnd按线性规律增长
（3）当网络发生拥塞，把ssthresh值更新为拥塞前ssthresh值的一半，cwnd重新设置为1，按照步骤（2）执行

乘法减小和加法增大:

  • 乘法减小：是指不论在慢开始阶段还是拥塞避免阶段，只要出现超时，就把慢开始门限减半，即设置为当前的拥塞窗口的一半（于此同时，执行慢开始算法）。当网络出现频繁拥塞时，ssthresh值就下降的很快，以大大将小注入到网络中的分组数。
  • 加法增大：是指执行拥塞避免算法后是拥塞窗口缓慢增大，以防止网络过早出现拥塞。

快重传与快恢复

在 TCP/IP 中，快速重传和快恢复（fast retransmit and recovery，FRR）是一种拥塞控制算法，它能快速恢复丢失的数据包。

对于快重传（可以在在网络恢复时及时给予响应）：

  • 快速重传(Fast retransmit)要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方），而不要等到自己发送数据时捎带确认。
  • 快重传算法规定，发送方只要一连收到3个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计数器时间到期。
    • 快速重传ACK：在TCP传输过程中，如果发生了丢包，接收端就会发送之前重复ACK，比如第5个包丢了，6、7到了，然后接收端就会为5、6、7都发送第四个包的ACK，这个时候发送到收到了3个重复的ACK，意识到丢包了，就会马上进行重传，而不用等待RTO（超时重传时间）
      - 快速重传机制只解决了一个问题，就是超时时间的问题，但是它依然面临着另一个问题，就是重传的时候，是重传之前的一个，还是重传所有的问题
      - 为此，引入了选择性重传。
    • 选择性重传SACK：
      • 报文首部可选性中加入SACK属性，通过 left edge 和 right edge 标志哪些包到了
      • 这样发送方就可以知道哪些数据送到了，哪些数据没有收到，知道了这些信息，就可以只重传丢失的数据
    • SACK：使用SACK来告诉[发送方]有哪些数据被重复接收了。

与快重传配合使用的还有快恢复算法

如果发送端收到了 3 个重复的 ACK，发现了丢包，觉得现在的网络状况已经进入拥塞状态了，那么就会进入快速恢复阶段：

  • 会将慢开始门限ssthresh降低为 拥塞窗口的一半。请注意：接下去不执行慢开始算法。
  • 然后拥塞窗口cwnd大小变为设置为慢开始门限ssthresh减半后的数值，然后开始执行拥塞避免算法（“加法增大”），使拥塞窗口缓慢地线性增大。

TCP和UDP有哪些区别？各自应用场景？

TCP协议的主要特点

  • TCP是面向连接的（就好像打电话一样，通话前需要先拨号建立连接，通话结束后要挂机释放连接）；
  • 每一条 TCP 连接只能有两个端点，每一条 TCP 连接只能是点对点的（一对一）；
  • TCP提供可靠的传输服务，传输的数据无差错，不丢失、不重复、按序到达
  • TCP 提供全双工通信。TCP 允许通信双方的应用进程在任何时候都能发送数据。TCP 连接的两端都设有发送缓存和接收缓存，用来临时存放双方通信的数据；
  • 面向字节流：虽然应用程序与TCP交互是一次一个大小不等的数据块，但是TCP把这些数据看成一连串无结构的字节流，它不保证接收方收到的数据块和发送方发送的数据块具有对应大小关系，比如，发送方应用程序交给发送方的TCP10个数据块，但就受访的TCP可能只用了4个数据块久保收到的字节流交付给上层的应用程序，但字节流完全一样。

UDP协议特点

  • UDP是无连接的传输层协议
  • UDP 使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的链接状态（这里面有许多参数）；
  • UDP是面向报文的，对应用层交下来的报文，不合并，不拆分，保留原报文的边界；
  • UDP 没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如 直播，实时视频会议等）；
  • UDO支持一对多、一对一、多对多的交互通信
  • UDP 的首部开销小，只有 8 个字节，比 TCP 的 20 个字节的首部要短。

TCP和UDP的区别

  • TCP是面向连接；UDP无连接
  • TCP是可靠传输（数据有序、不重复、保证到达）；UDP是不可靠传输
  • TCP是数据流，不保存数据边界；UDP是数据包，保留数据边界
  • TCP有流量控制而UDP没有

TCP和UDP的应用场景

（1）TCP应用场景

  • 效率相对较低，但是对准确性要求比较高的场景。
  • 举几个例子：文件传输（准确高要求高、但是速度可以相对慢）、接受邮件、远程登录。
  • 实际例子：HTTP、HTTPS、FTP、TELNET、SMTP(简单邮件传输协议)

（2）UDP应用场景

  • 效率比较高，但是准确度比较大的场景。
  • 比如：QQ聊天、在线视频、广播通信（广播、多播）
  • 实际例子：TFTP、DNS、DHCP、TFTP、SNMP(简单网络管理协议)、RIP

HTTP1.0，1.1，2.0 的版本区别

HTTP1.0：

  • HTTP1.0规定浏览器和服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理之后立即端口连接。
  • 每次请求都需要三位握手和四次挥手，因此效率比较低
  • HTTP1.0 其实也可以强制开启长链接，例如接受Connection: keep-alive 这个字段，但是，这不是标准字段，不同实现的行为可能不一致，因此不是根本的解决办法。

HTTP/1.1：

  • HTTP1.1引入了持久连接，默认TCP连接不关闭可复用。客户端和服务端发现对方一段时间没有活动，就可以主动关闭连接，或者在客户端最后一个请求时，主动高速服务端要关闭连接
  • HTTP/1.1还引入了管道机制，即在同一个TCP连接里面，客户端可以同时发送多个请求。进一步改进了HTTP协议的效率
  • 有了持久连接和管道，大大的提升了HTTP的效率。但是服务端还是顺序执行的，效率还有提升的空间。

HTTP/2：

  • HTTP/2引入了多路复用，即在一个连接里，客户端和浏览器都可以同时发送多个请求和响应，而且不用按照顺序一一对应。能这样做有一个前提，就是HTTP/2进行了二进制分帧，即 HTTP/2 会将所有传输的信息分割为更小的消息和帧（frame）,并对它们采用二进制格式的编码。
  • 也就是说，老板可以同时下达多个命令，员工也可以收到了A请求和B请求，于是先回应A请求，结果发现处理过程非常耗时，于是就发送A请求已经处理好的部分， 接着回应B请求，完成后，再发送A请求剩下的部分。A请求的两部分响应在组合到一起发给老板。而这个负责拆分、组装请求和二进制帧的一层就叫做二进制分帧层。
  • 除此之外，还有一些其他的优化，比如做Header压缩、服务端推送等。

HTTPS和HTTP的区别

HTTP协议运行在TCP上，明文传输，客户端和服务端都无法验证对方的省份，HTTPS运行在SSL上，SSL运行在TCP上，它是添加了加密和认证机制的HTTP。两者区别：

  • 端口不同：HTTP默认80，HTTPS默认443
  • 开销：HTTPS通信需要证书
  • 资源消耗：HTTPS需要加密解密资源消耗更多

对称加密与非对称加密的区别

  • 对称加密是指加密和解密都使用同一个密钥的方式，这种方式最大问题是密钥发送问题，即如何安全的将密钥发送给对方。
  • 非对称加密是指使用一对非对称密钥，即公钥和私钥，公钥可以随意发布，但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理，对方接收到加密信息后，使用自己的私钥进行解密。

由于非对称加密的方式不需要发送用来解密的私钥，所以可以保证安全性；但是和对称加密比起来，它非常的慢，所以我们还是要用对称加密来传送消息，但对称加密所使用的密钥我们可以通过非对称加密的方式发送出去。

POST和GET有哪些区别？各自应用场景？

没有区别

http 协议的请求可以分成三部分

  • request line
  • headers
  • body

其中，headers 和 body 是可选的，request line 和 headers 都是以\r\n分䣓，headers 与 body 之前有一个空行（两个 \r\n），而 request line 则又可细分成三部分：

  • method
  • uri
  • version

method 有好多，常见的就是 GET 和 POST。http 1.1 为了表达不同的语义，引入了诸如 DELETE、PATCH 等方法，这种语义不是强制性的。

从字面上看 GET 是查询信息，POST 是提新信息。但你用 POST 方法查询信息也是可以的。例如 gRPC 中所有的请求都是 POST；你用 GET 请求理新信息也是没问题的，君不见多少业务系统的 GET 请求都不幂等。

而且，协议并没有规定 GET 请求不能带 body 的。理论上，任何请求都可以带 body 的。ElasticSearch 查询的时候使用的方法是 GET，但查询 DSL 却是用 body 传输的。

另外，uri 中的查询参数也不是 GET 所独有的。POST 请求的 uri 中也可以有参数呀。

所以说，GET 和 POST 除了字面语义不同之外，就没有什么区别了。

还有一点需要注意，代理一般不会缓存 post 请求的响应内容。

GET请求中URL编码的意义

避免特殊字符比如=或者&等，产生歧义

HTTP 哪些常用的状态码及使用场景？

（1）状态码分类

  • 1xx：表示目前是协议的中间状态，还需要后续请求
  • 2xx：表示请求成功
  • 3xx：表示重定向状态，需要重新请求
  • 4xx：表示请求报文错误
  • 5xx：服务器端错误

（2）常用状态码

  • 101 切换请求协议，从 HTTP 切换到 WebSocket
  • 200 请求成功，有响应体
  • 301 永久重定向：会缓存
  • 302 临时重定向：不会缓存
  • 304 协商缓存命中
  • 403 服务器禁止访问
  • 404 资源未找到
  • 400 请求错误
  • 500 服务器端错误
  • 503 服务器繁忙

HTTP状态码301和302的区别，都有哪些用途？

  • 301重定向（301 Move Permanently），指页面永久性转移
  • 302重定向（302 Move Temporarily），指页面暂时性转移，表示资源或页面暂时转移到另一个位置，常被用作网址劫持，容易导致网站降权，严重时网站会被封掉，不推荐使用。

302重定向是页面暂时性转移，搜索引擎会抓取新的内容而保存旧的网址并认为新的网址只是暂时的。

在交互过程中如果数据传送完了，还不想断开连接怎么办，怎么维持？

在 HTTP 中响应体的 Connection 字段指定为 keep-alive

connetion:keep-alive;

HTTP 如何实现长连接？在什么时候会超时？

  • 通过在头部（请求和响应头）设置 Connection: keep-alive，HTTP1.0协议支持，但是默认关闭，从HTTP1.1协议以后，连接默认都是长连接
  • 实际上 HTTP 没有长短链接，只有 TCP 有，TCP 长连接可以复用一个 TCP 链接来发起多次 HTTP 请求，这样可以减少资源消耗，比如一次请求 HTML，可能还需要请求后续的 JS/CSS/图片等