计算机网络面试内容

目录

• 第一部分、TCP和UDP
  • 一、三次握手
  • 二、四次挥手
  • 三、TCP和UDP
  • 四、TCP的重传机制
    • 1. 超时重传
    • 2.快速重传
    • 3.带选择确认的重传（SACK）
    • 4.重复SACK（D-SACK）
  • 五、TCP的流量控制
    • 1.基础概念
    • 2.存在的问题
  • 六、TCP的拥塞控制：慢启动算法、拥塞避免、拥塞发生、快恢复。
    • 1.慢启动算法
    • 2..拥塞避免算法
    • 3.拥塞发生
    • 4.快速恢复
  • 七、TCP 半连接队列和全连接队列
    • 1.基础概念
• 第二部分、HTTP和HTTPS
• 第三部分、协议
  • 一、IP协议
• 第四部分、CDN
• 第五部分、网络模型
  • 一、TCP/IP ⽹络模型
  • 二、OSI七层网络模型
• 第六部分 面试题

---

第一部分、TCP和UDP

一、三次握手

1. 为什么TCP连接的时候是3次？2次不可以吗？（丢包问题、序列号确认、避免资源浪费、防止历史连接初始化）

• 丢包问题:第二次服务端的确认丢失，则c和s都会等待，第三次握手中，若丢失，则s收不到确认，会重发。
• 保证序列号双方确认:通信双方都必须维持序列号，两次握手只有发起方序列号可以被确
• 三次握⼿才可以阻⽌重复历史连接的初始化（主要原因）
• 三次握⼿才可以同步双⽅的初始序列号：两次握⼿只保证了⼀⽅的初始序列号能被对⽅成功接收，没办法保证双⽅的初始序列号都能被确认接收。
• 三次握⼿才可以避免资源浪费：如果客户端的 SYN 阻塞了，重复发送多次 SYN 报⽂，那么服务器在收到请求后就会建⽴多个冗余的⽆效链接，造成不必要的资源浪费。（两次握手）
• 「两次握⼿」：⽆法防⽌历史连接的建⽴，会造成双⽅资源的浪费，也⽆法可靠的同步双⽅序列号
• 「四次握⼿」：三次握⼿就已经理论上最少可靠连接建⽴，所以不需要使⽤更多的通信次数。

2. 三次握手：交换三个TCP报文

   • (SYN=1,seq=x)
   • (SYN=1,ACK=1,seq=y,ack=x+1)
   • (ACK=1,seq=x+1,ack=y+1)
   • 第三次握⼿是可以携带数据的，前两次握⼿是不可以携带数据的

3. 如果已经建立了连接，但是客户端突然出现故障了怎么办？

   • TCP设有一个保活计时器，服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时。
   • 若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。
   • 若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

4. 什么是 SYN 攻击？如何避免 SYN 攻击？（未理解）

   • SYN 攻击：假设攻击者短时间伪造不同 IP 地址的 SYN 报⽂，服务端每接收到⼀个 SYN 报⽂，就进⼊ SYN_RCVD 状态，但服务端发送出去的 ACK + SYN 报⽂，⽆法得到未知 IP 主机的 ACK 应答，久⽽久之就会占满服务端的 SYN 接收队列（未连接队列），使得服务器不能为正常⽤户服务。
   • 避免 SYN 攻击⽅式⼀：通过修改 Linux 内核参数，控制队列⼤⼩和当队列满时应做什么处理。
   • 避免 SYN 攻击⽅式⼆：（?）

5. TCP报文首部有哪些字段，其作用又分别是什么？

   • 32位序号：在建⽴连接时由计算机⽣成的随机数作为其初始值，通过 SYN 包传给接收端主机，每发送⼀次数据，就「累加」⼀次该「数据字节数」的⼤⼩。⽤来解决⽹络包乱序问题。

   • 32位确认号：指下⼀次「期望」收到的数据的序列号，发送端收到这个确认应答以后可以认为在这个序号以前的数据都已经被正常接收。⽤来解决不丢包的问题。

   • 控制位：

     1. ACK：该位为 1 时，「确认应答」的字段变为有效，TCP 规定除了最初建⽴连接时的 SYN 包之外该位必须设置为 1 。
     2. RST：该位为 1 时，表示 TCP 连接中出现异常必须强制断开连接。
     3. SYN：该位为 1 时，表示希望建⽴连接，并在其「序列号」的字段进⾏序列号初始值的设定。
     4. FIN：该位为 1 时，表示不会再有数据发送，希望断开连接。当通信结束希望断开连接时，通信双⽅的主机之间可以相互交换 FIN 位为 1 的 TCP 段。

   • 16位端口号：源端口号，主机该报文段是来自哪里；目标端口号，要传给哪个上层协议或应用程序

   • 4位头部长度：表示tcp头部有多少个32bit字（4字节）。因为4位最大能标识15，所以TCP头部最长是60字节。

   • 6位标志位：URG(紧急指针是否有效)，ACk（表示确认号是否有效），PSH（缓冲区尚未填满），RST（表示要求对方重新建立连接），SYN（建立连接消息标志接），FIN（表示告知对方本端要关闭连接了）

   • 16位窗口大小：是TCP流量控制的一个手段。这里说的窗口，指的是接收通告窗口。它告诉对方本端的TCP接收缓冲区还能容纳多少字节的数据，这样对方就可以控制发送数据的速度。

   • 16位校验和：由发送端填充，接收端对TCP报文段执行CRC算法以检验TCP报文段在传输过程中是否损坏。注意，这个校验不仅包括TCP头部，也包括数据部分。这也是TCP可靠传输的一个重要保障。

   • 16位紧急指针：一个正的偏移量。它和序号字段的值相加表示最后一个紧急数据的下一字节的序号。因此，确切地说，这个字段是紧急指针相对当前序号的偏移，不妨称之为紧急偏移。TCP的紧急指针是发送端向接收端发送紧急数据的方法。

6. TCP是如何确保可靠性——滑动窗口和超时重传

   • 连接和断开的可靠性（三次握手，四次挥手）、有状态（哪些数据发送了，哪些没发）、可控制（超时重传、流量控制、拥塞控制等）。
   • TCP的可靠性，体现连接和断开：TCP的连接是基于三次握手，而断开则是基于四次挥手。确保连接和断开的可靠性。
   • TCP的可靠性，体现在状态：TCP会记录哪些数据发送了，哪些数据被接收了，哪些没有被接受，并且保证数据包按序到达，保证数据传输不出差错。
   • TCP的可靠性，体现可控制：它有数据包校验、ACK应答、超时重传(发送方)、失序数据重传（接收方）、丢弃重复数据、流量控制（滑动窗口）和拥塞控制等机制。

7. TCP 三次握⼿的性能提升：

   • 客户端优化
   • 服务端优化

8. TCP 四次挥⼿的性能提升：

   • 主动⽅的优化
   • 被动⽅的优化

9. TCP 传输数据的性能提升：

二、四次挥手

1. 为什么TCP连接的时候是3次，关闭的时候却是4次？

   • 客户端和服务端都没有数据要发送的时候才能断开TCP。
   • 客户端发出FIN报文时只能保证客户端没有数据发了。
   • 服务端收到客户端的FIN报文后只能先回复客户端一个确认报文来告诉客户端我服务端已经收到你的FIN报文了，但我服务端还有一些数据没发完，等这些数据发完了服务端才能给客户端发FIN报文。

2. 为什么客户端发出第四次挥手的确认报文后要等2MSL的时间才能释放TCP连接？

   • 防止丢包，如果第四次挥手的报文丢失，服务端没收到确认ack报文就会重发第三次挥手的报文，这样报文一去一回最长时间就是2MSL

3. CLOSE_WAIT 过多会出现什么问题？

   • 导致服务器资源占用，CLOSE_WAIT 积压可能造成服务器无法分配出资源给新的连接。一般这种情况都是由于服务器没有调用 close

4. 为什么需要 TIME_WAIT 状态？

   • 防⽌具有相同「四元组」的「旧」数据包被收到：经过 2MSL 这个时间，⾜以让两个⽅向上的数据包都被丢弃，使得原来连接的数据包在⽹络中都⾃然消失，再出现的数据包⼀定都是新建⽴连接所产⽣的。
   • 保证「被动关闭连接」的⼀⽅能被正确的关闭，即保证最后的 ACK 能让被动关闭⽅接收，从⽽帮助其正常关闭；
   • 注：主动关闭连接的，才有 TIME_WAIT 状态。

5. TIME_WAIT 过多有什么危害？

   • 第⼀是内存资源占⽤；
   • 第⼆是对端⼝资源的占⽤，⼀个 TCP 连接⾄少消耗⼀个本地端⼝；

三、TCP和UDP

1. 区别

   • 连接： TCP 是⾯向连接的传输层协议，传输数据前先要建⽴连接。UDP 是不需要连接，即刻传输数据。
   • 服务对象：TCP 是⼀对⼀的两点服务，即⼀条连接只有两个端点。UDP ⽀持⼀对⼀、⼀对多、多对多的交互通信
   • 可靠性：TCP 是可靠交付数据的，数据可以⽆差错、不丢失、不重复、按需到达。UDP 是尽最⼤努⼒交付，不保证可靠交付数据。
   • 拥塞控制、流量控制：TCP 有拥塞控制和流量控制机制，保证数据传输的安全性。UDP 则没有，即使⽹络⾮常拥堵了，也不会影响 UDP 的发送速率。
   • ⾸部开销：TCP ⾸部⻓度较⻓，会有⼀定的开销，⾸部在没有使⽤「选项」字段时是 20 个字节，如果使⽤了「选项」字段则会变⻓的。UDP ⾸部只有 8 个字节，并且是固定不变的，开销较⼩。
   • 传输⽅式：TCP 是流式传输，没有边界，但保证顺序和可靠。UDP 是⼀个包⼀个包的发送，是有边界的，但可能会丢包和乱序。
   • 分⽚不同：
     • TCP 的数据⼤⼩如果⼤于 MSS ⼤⼩，则会在传输层进⾏分⽚，⽬标主机收到后，也同样在传输层组装 TCP数据包，如果中途丢失了⼀个分⽚，只需要传输丢失的这个分⽚。
     • UDP 的数据⼤⼩如果⼤于 MTU ⼤⼩，则会在 IP 层进⾏分⽚，⽬标主机收到后，在 IP 层组装完数据，接着再传给传输层，但是如果中途丢了⼀个分⽚，在实现可靠传输的 UDP 时则就需要重传所有的数据包，这样传输效率⾮常差，所以通常 UDP 的报⽂应该⼩于 MTU。

2. 应⽤场景

   • TCP（⾯向连接，能保证数据的可靠性交付）：FTP⽂件传输；HTTP/HTTPS
   • UDP（⾯向⽆连接，它可以随时发送数据，再加上UDP本身的处理既简单⼜⾼效）：包总量少的通信，如 DNS 、 SNMP 等；视频、⾳频等多媒体通信；⼴播通信

四、TCP的重传机制

1. 超时重传

• 在发送数据时，设定⼀个定时器，当超过指定的时间后，没有收到对⽅的 ACK 确认应答报⽂，就会重发该数据，直到发送成功为止
• 发生情况：数据包丢失；确认应答丢失
• RTT （Round-Trip Time 往返时延）：数据从⽹络⼀端传送到另⼀端所需的时间，也就是包的往返时间。
• 超时重传时间是以 RTO （Retransmission Timeout 超时重传时间）表示。
  1. 当超时时间 RTO 较⼤时，重发就慢，丢了⽼半天才重发，没有效率，性能差；
  2. 当超时时间 RTO 较⼩时，会导致可能并没有丢就重发，于是重发的就快，会增加⽹络拥塞，导致更多的超时，更多的超时导致更多的重发。
  3. 超时重传时间 RTO 的值应该略⼤于报⽂往返 RTT 的值。
  4. 实际上「报⽂往返 RTT 的值」是经常变化的，因为我们的⽹络也是时常变化的。也就因为「报⽂往返 RTT 的值」是经常波动变化的，所以「超时重传时间 RTO 的值」应该是⼀个动态变化的值
• 计算 RTO ：Jacobson / Karels 算法
• 超时重传缺点：
  1. 当一个报文丢失时，会等待一定的超时周期，才重传分组，增加了端到端的时延。
  2. 当一个报文丢失时，在其等待超时的过程中，可能会出现这种情况：其后的报文段已经被接收端接收但却迟迟得不到确认，发送端会认为也丢失了，从而引起不必要的重传，既浪费资源也浪费时间。

2.快速重传

• ⼯作⽅式：当收到三个相同的 ACK 报⽂时，会在定时器过期之前，重传丢失的报⽂段。
• 问题：就是重传的时候，是重传之前的⼀个，还是重传所有的问题。

3.带选择确认的重传（SACK）

• 在快速重传的基础上，接收方返回最近收到报文段的序列号范围，这样发送方就知道接收方哪些数据包是没收到的。这样就很清楚应该重传哪些数据包啦。
• 在 TCP 头部「选项」字段⾥加⼀个 SACK 的东⻄，它可以将缓存的地图发送给发送⽅，这样发送⽅就可以知道哪些数据收到了，哪些数据没收到，知道了这些信息，就可以只重传丢失的数据。

4.重复SACK（D-SACK）

• 使⽤了 SACK 来告诉「发送⽅」有哪些数据被重复接收了。
• DSACK的目的是帮助发送方判断，是否发生了包失序、ACK丢失、包重复或伪重传。让TCP可以更好的做网络流控
• 解决问题：ACK 丢包、⽹络延时
• 优点：
  1. 可以让「发送⽅」知道，是发出去的包丢了，还是接收⽅回应的 ACK 包丢了;
  2. 可以知道是不是「发送⽅」的数据包被⽹络延迟了;
  3. 可以知道⽹络中是不是把「发送⽅」的数据包给复制了;

五、TCP的流量控制

1.基础概念

• TCP 提供一种机制可以让发送端根据接收端的实际接收能力控制发送的数据量，这就是流量控制。
• 滑动窗口：发送窗口和接收窗口（两者并不是完全相等，接收窗⼝的⼤⼩是约等于发送窗⼝的⼤⼩的）
• TCP报文首部字段Window控制窗口大小：这个字段是接收端告诉发送端⾃⼰还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能⼒来发送数据，⽽不会导致接收端处理不过来。

2.存在的问题

• 操作系统缓冲区与滑动窗⼝的关系（?）
  1. 发送窗⼝和接收窗⼝中所存放的字节数，都是放在操作系统内存缓冲区中的，⽽操作系统的缓冲区，会被操作系统调整。
• 窗⼝关闭
  1. 如果窗⼝⼤⼩为 0 时，就会阻⽌发送⽅给接收⽅传递数据，直到窗⼝变为⾮ 0 为⽌，这就是窗⼝关闭。
  2. 危险：当发⽣窗⼝关闭时，接收⽅处理完数据后，会向发送⽅通告⼀个窗⼝⾮ 0 的 ACK 报⽂，如果这个通告窗⼝的 ACK 报⽂在⽹络中丢失,会导致发送⽅⼀直等待接收⽅的⾮ 0 窗⼝通知，接收⽅也⼀直等待发送⽅的数据，如不采取措施，这种相互等待的过程，会造成了死锁的现象。
  3. 解决—持续计时器：只要 TCP 连接⼀⽅收到对⽅的零窗⼝通知，就启动持续计时器。如果持续计时器超时，就会发送窗⼝探测 ( Windowprobe ) 报⽂，⽽对⽅在确认这个探测报⽂时，给出⾃⼰现在的接收窗⼝⼤⼩。
• 糊涂窗⼝综合症：
  1. 如果接收⽅太忙了，来不及取⾛接收窗⼝⾥的数据，那么就会导致发送⽅的发送窗⼝越来越⼩。
  2. 到最后，如果接收⽅腾出⼏个字节并告诉发送⽅现在有⼏个字节的窗⼝，⽽发送⽅会义⽆反顾地发送这⼏个字节，这就是糊涂窗⼝综合症。
  3. 原因：接收⽅可以通告⼀个⼩的窗⼝⽽发送⽅可以发送⼩数据
  4. 解决：
     • 接收⽅不通告⼩窗⼝：当「窗⼝⼤⼩」⼩于 min( MSS，缓存空间/2 ) ，也就是⼩于 MSS 与 1/2 缓存⼤⼩中的最⼩值时，就会向发送⽅通告窗⼝为 0 ，也就阻⽌了发送⽅再发数据过来。
     • 发送⽅避免发送⼩数据：使⽤ Nagle 算法，该算法的思路是延时处理，它满⾜以下两个条件中的⼀条才可以发送数据：要等到窗⼝⼤⼩ >= MSS 或是 数据⼤⼩ >= MSS；收到之前发送数据的 ack 回包

六、TCP的拥塞控制：慢启动算法、拥塞避免、拥塞发生、快恢复。

• 功能：作用于网络，防止过多的数据包注入到网络中，避免出现网络负载过大的情况
• 原理：发送方维持一个拥塞窗口，只要网络中没有出现拥塞，拥塞窗口的值就可以再增大一些，以便把更多的数据包发送出去，但只要网络出现拥塞，拥塞窗口的值就应该减小一些，以减少注入到网络中的数据包数。
• 拥塞窗⼝ cwnd是发送⽅维护的⼀个的状态变量，它会根据⽹络的拥塞程度动态变化的。
• 只要⽹络中没有出现拥塞， cwnd 就会增⼤；但⽹络中出现了拥塞， cwnd 就减少；
• 只要「发送⽅」没有在规定时间内接收到 ACK 应答报⽂，发⽣了超时重传，就会认为⽹络出现了拥塞。

1.慢启动算法

• 由小到大逐渐增加拥塞窗口的大小，如果没有出现丢包，每收到一个ACK，就将拥塞窗口cwnd大小就加1。每轮次发送窗口增加一倍，呈指数增长，如果出现丢包，拥塞窗口就减半，进入拥塞避免阶段。
• 慢启动阀值ssthresh：当cwnd >ssthresh时，进入了拥塞避免算法。

2..拥塞避免算法

• cwnd到达慢启动阀值后：每收到一个ACK时，cwnd = cwnd + 1/cwnd，当每过一个RTT时，cwnd = cwnd + 1
• 拥塞发生时： 慢启动阀值sshthresh = cwnd /2，cwnd 重置为 1，进入新的慢启动过程

3.拥塞发生

• 发⽣超时重传的拥塞发⽣算法
  1. 当发⽣了「超时重传」，则就会使⽤拥塞发⽣算法：ssthresh 设为 cwnd/2 ；cwnd 重置为 1
  2. 慢启动是会突然减少数据流的。这真是⼀旦「超时重传」，⻢上回到解放前。但是这种⽅式太激进了，反应也很强烈，会造成⽹络卡顿。
• 发⽣快速重传的拥塞发⽣算法
  1. cwnd = cwnd/2 ，也就是设置为原来的⼀半；ssthresh = cwnd
  2. 进⼊快速恢复算法

​

4.快速恢复

• 拥塞窗⼝ cwnd = ssthresh + 3 （ 3 的意思是确认有 3 个数据包被收到了）；
• 重传丢失的数据包；
• 如果再收到重复的 ACK，那么 cwnd 增加 1；
• 如果收到新数据的 ACK 后，把 cwnd 设置为第⼀步中的 ssthresh 的值，原因是该 ACK 确认了新的数据，说明从 duplicated ACK 时的数据都已收到，该恢复过程已经结束，可以回到恢复之前的状态了，也即再次进⼊拥塞避免状态；

七、TCP 半连接队列和全连接队列

1.基础概念

• TCP 三次握⼿的时候，Linux 内核会维护两个队列：半连接队列，也称 SYN 队列；全连接队列，也称 accepet 队列；
• 服务端收到客户端发起的 SYN 请求后，内核会把该连接存储到半连接队列，并向客户端响应 SYN+ACK
• 客户端会返回 ACK，服务端收到第三次握⼿的 ACK 后，内核会把连接从半连接队列移除，然后创建新的完全的连接，并将其添加到 accept 队列，等待进程调⽤ accept 函数时把连接取出来。

7. 地址栏输入 URL 发生了什么

   • 浏览器会根据你输入的 URL 地址，去查找域名是否被本地 DNS 缓存，不同浏览器对 DNS 的设置不同，如果浏览器缓存了你想访问的 URL 地址，那就直接返回 ip。

   • 如果没有缓存你的 URL 地址，浏览器就会发起系统调用来查询本机 hosts 文件是否有配置 ip 地址，如果找到，直接返回。

   • 如果找不到，就向网络中发起一个 DNS 查询。在由根域名服务器 -> 顶级域名服务器 -> 权威 DNS 服务器后，由权威服务器告诉本地服务器目标 IP 地址，再有本地 DNS 服务器告诉用户需要访问的 IP 地址。

   • 浏览器需要和目标服务器建立 TCP 连接

   • 向服务器发送HTTP请求

   • 服务器处理请求，返回网页内容

   • 浏览器解析并渲染页面

   • TCP四次挥手，连接结束

     DNS是域名系统(DomainNameSystem)的缩写，该系统用于命名组织到域层次结构中的计算机和网络服务，可以简单地理解为将URL转换为IP地址。

8. TCP粘包是什么？

   • TCP是面向流，没有界限的一串数据。TCP底层并不了解上层业务数据的具体含义，它会根据TCP缓冲区的实际情况进行包的划分
   • 所以在业务上认为，一个完整的包可能会被TCP拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这就是所谓的TCP粘包和拆包问题。
   
   • TCP粘包是指发送方发送的若干包数据到接收方接收时粘成一包，从接收缓冲区看，后一包数据的头紧接着前一包数据的尾。
     1. 原因
        发送端需要等缓冲区满才发送出去，造成粘包
        接收方不及时接收缓冲区的包，造成多个包接收
        接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生粘包；
     2. 粘包情况有两种，一种是粘在一起的包都是完整的数据包，另一种情况是粘在一起的包有不完整的包。
     3. 若传输的数据为不带结构的连续流数据（如文件传输），则不必把粘连的包分开
   • 避免

     1. 发送:TCP提供了强制数据立即传送的操作指令push，但它关闭了优化算法，降低了网络发送效率，影响应用程序的性能，

     2. 接受:可通过优化程序设计、精简接收进程工作量、提高接收进程优先级等措施，使其及时接收数据，只能减少出现粘包的可能性，但并不能完全避免，当发送频率较高时，或由于网络突发可能使某个时间段数据包到达接收方较快，接收方还是有可能来不及接收，从而导致粘包。

     3. 由接收方控制，将一包数据按结构字段，人为控制分多次接收，然后合并，通过这种手段来避免粘包。应用程序的效率较低

     4. 发送端将每个数据包封装为固定长度
        在数据尾部增加特殊字符进行分割
        将数据分为两部分，一部分是头部，一部分是内容体；其中头部结构大小固定，且有一个字段声明内容体的大小。

     5. 一种比较周全的对策是：接收方创建一预处理线程，对接收到的数据包进行预处理，将粘连的包分开。

     6. 讲一讲拆包

        • 要发送的数据大于TCP发送缓冲区剩余空间大小，将会发生拆包；
        • 待发送数据大于MSS（最大报文长度），TCP在传输前将进行拆包。即TCP报文长度-TCP头部长度>MSS。
          1. 动态缓冲区暂存方式。
          2. 利用底层的缓冲区来进行拆包

第二部分、HTTP和HTTPS

1. 什么是HTTP、HTTPS？
   • HTTP 是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范（超⽂本传输协议）
   • HTTPS中的S表示SSL或者TLS，就是在原HTTP的基础上加上一层用于数据加密、解密、身份认证的安全层。
   • HTTP 安全性没有 HTTPS高，但是 HTTPS 比HTTP耗费更多服务器资源。

//两者区别
1.费用:https协议需要到ca申请证书，一般免费证书很少，需要交费。
2.加密:http是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议。
3.连接:http和https使用的是完全不同的连接方式用的端口也不一样,前者是80,后者是443。
4.状态:http的连接很简单,是无状态的 。
5.安全性:HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议， 要比http协议安全。
       
//HTTP（1.1） 的优点有哪些，怎么体现的？
1. 简单：HTTP 基本的报⽂格式就是 header + body ，头部信息也是 key-value 简单⽂本的形式，易于理解，降低了学习和使⽤的⻔槛。
2. 灵活和易于扩展：HTTP协议⾥的各类请求⽅法、URI/URL、状态码、头字段等每个组成要求都没有被固定死，都允许开发⼈员⾃定义和扩充。同时 HTTP 由于是⼯作在应⽤层（OSI 第七层），则它下层可以随意变化。HTTPS 也就是在 HTTP 与 TCP 层之间增加了 SSL/TLS 安全传输层，HTTP/3 甚⾄把 TCP 层换成了基于 UDP 的QUIC。
3. 应⽤⼴泛和跨平台：互联⽹发展⾄今，HTTP 的应⽤范围⾮常的⼴泛，从台式机的浏览器到⼿机上的各种 APP，从看新闻、刷贴吧到购物、理财、吃鸡，HTTP 的应⽤⽚地开花，同时天然具有跨平台的优越性。
       
//HTTP（1.1） 的缺点——（无状态、不安全、性能低）
1.⽆状态双刃剑
   -好处：服务器不会去记忆 HTTP 的状态，不需要额外的资源记录状态信息，减轻服务器负担，能够把更多的 CPU 和内存⽤来对外提供服务。
   -坏处：既然服务器没有记忆能⼒，它在完成有关联性的操作时会⾮常麻烦。
   -解法⽅案：Cookie 技术，通过在请求和响应报⽂中写⼊ Cookie 信息来控制客户端的状态
2. 明⽂传输双刃剑
   -好处：⽅便阅读，为调试⼯作带了极⼤的便利性
   -坏处：信息的内容很容易就能被窃取
3.不安全：
   -通信使⽤明⽂（不加密），内容可能会被窃听；不验证通信⽅的身份，因此有可能遭遇伪装；⽆法证明报⽂的完整性，所以有可能已遭篡改
   -解决方案：⽤ HTTPS，引⼊ SSL/TLS 层
       -混合加密的⽅式实现信息的机密性，解决了窃听的⻛险。
       -摘要算法的⽅式来实现完整性，它能够为数据⽣成独⼀⽆⼆的「指纹」，指纹⽤于校验数据的完整性，解决了篡改的⻛险。
       -将服务器公钥放⼊到数字证书中，解决了冒充的⻛险。
4.性能瓶颈：
    -请求 / 响应头部（Header）未经压缩就发送，⾸部信息越多延迟越⼤。只能压缩 Body 的部分；
    -发送冗⻓的⾸部。每次互相发送相同的⾸部造成的浪费较多；
    -服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端⼀直请求不到数据，也就是队头阻塞；
    -没有请求优先级控制；
    -请求只能从客户端开始，服务器只能被动响应。
       
//HTTP/1.1 的性能如何？
1.⻓连接（持久连接）：这种⽅式的好处在于减少了TCP 连接的重复建⽴和断开所造成的额外开销，减轻了服务器端的负载。
2.管道⽹络传输：可在同⼀个 TCP 连接⾥⾯，客户端可以发起多个请求，只要第⼀个请求发出去了，不必等其回来，就可以发第⼆个请求出去，可以减少整体的响应时间。
3. 队头阻塞：服务器还是按照顺序回应请求，要是前⾯的回应特别慢，后⾯就会有许多请求排队等着。这称为「队头堵塞」。
总之：HTTP/1.1 的性能⼀般般，后续的 HTTP/2 和 HTTP/3 就是在优化 HTTP 的性能。
    
//HTTP/1.1如何优化？
1.使⽤ KeepAlive 将 HTTP/1.1 从短连接改成⻓链接。
2.尽量避免发送 HTTP 请求：
    通过缓存技术，对于⼀些具有重复性的 HTTP 请求，⽐如每次请求得到的数据都⼀样的，我们可以把这对「请求-响应」的数据都缓存在本地，那么下次就直接读取本地的数据，不必在通过⽹络获取服务器的响应了
    服务器在发送 HTTP 响应时，会估算⼀个过期的时间，并把这个信息放到响应头部中，这样客户端在查看响应头部的信息时，⼀旦发现缓存的响应是过期的，则就会重新发送⽹络请求。
    如果客户端从第⼀次请求得到的响应头部中发现该响应过期，重新发送请求，假设服务器上的资源并没有变更，服务器的响应不需要带上这个资源（只需要客户端在重新发送请求时，在请求的 Etag 头部带上第⼀次请求的响应头部中的摘要）
3.在需要发送 HTTP 请求时，考虑如何减少请求次数：
    减少重定向请求次数：重定向的⼯作交由代理服务器完成，就能减少 HTTP 请求次数
    合并请求：把多个访问⼩⽂件的请求合并成⼀个⼤的请求，虽然传输的总资源还是⼀样，但是减少请求，也就意味着减少了重复发送的 HTTP 头部。
    延迟发送请求：请求⽹⻚的时候，不用把全部资源都获取到，⽽只获取当前⽤户所看到的⻚⾯资源，当⽤户滑动⻚⾯的时候，再向服务器获取接下来的资源
4.减少服务器的 HTTP 响应的数据⼤⼩（压缩）：⽆损压缩、有损压缩 

//http 常⻅字段有哪些？
- Host 字段：客户端发送请求时，⽤来指定服务器的域名。有了 Host 字段，就可以将请求发往「同⼀台」服务器上的不同⽹站。
- Content-Length 字段：服务器在返回数据时，会有 Content-Length 字段，表明本次回应的数据⻓度。
- Connection 字段：最常⽤于客户端要求服务器使⽤ TCP 持久连接，以便其他请求复⽤。指定值为Keep-Alive 
- Content-Type 字段：⽤于服务器回应时，告诉客户端，本次数据是什么格式。
- Accept 字段：声明⾃⼰可以接受哪些数据格式。
- Content-Encoding 字段：说明数据的压缩⽅法。表示服务器返回的数据使⽤了什么压缩格式
- Accept-Encoding 字段：说明⾃⼰可以接受哪些压缩⽅法。
    
//HTTP/2 做了什么优化？
1. 头部压缩
    HTTP/2 会压缩头（Header）如果你同时发出多个请求，他们的头是⼀样的或是相似的，那么，协议会帮你消除重复的部分。
2. ⼆进制格式
    HTTP/2 不再像 HTTP/1.1 ⾥的纯⽂本形式的报⽂，⽽是全⾯采⽤了⼆进制格式，头信息和数据体都是⼆进制，并且统称为帧（frame）：头信息帧和数据帧。
    对计算机⾮常友好，直接解析⼆进制报⽂，增加数据传输的效率。
3. 数据流
    HTTP/2 的数据包不是按顺序发送的，同⼀个连接⾥⾯连续的数据包，可能属于不同的回应。因此，必须要对数据包做标记，指出它属于哪个回应。
    每个请求或回应的所有数据包，称为⼀个数据流（ Stream ）。每个数据流都标记着⼀个独⼀⽆⼆的编号，其中规定客户端发出的数据流编号为奇数， 服务器发出的数据流编号为偶数
    客户端还可以指定数据流的优先级。优先级⾼的请求，服务器就先响应该请求。
4. 多路复⽤
    HTTP/2 是可以在⼀个连接中并发多个请求或回应，⽽不⽤按照顺序⼀⼀对应。
    移除了 HTTP/1.1 中的串⾏请求，不需要排队等待，也就不会再出现「队头阻塞」问题，降低了延迟，⼤幅度提⾼了连接的利⽤率。
    举例来说，在⼀个 TCP 连接⾥，服务器收到了客户端 A 和 B 的两个请求，如果发现 A 处理过程⾮常耗时，于是就回应 A 请求已经处理好的部分，接着回应 B 请求，完成后，再回应 A 请求剩下的部分。
5. 服务器推送
    HTTP/2 还在⼀定程度上改善了传统的「请求 - 应答」⼯作模式，服务不再是被动地响应，也可以主动向客户端发送消息。
    举例来说，在浏览器刚请求 HTML 的时候，就提前把可能会⽤到的 JS、CSS ⽂件等静态资源主动发给客户端，减少延时的等待，也就是服务器推送（Server Push，也叫 Cache Push）。
    
//HTTP/2 有哪些缺陷？
    多个 HTTP 请求在复⽤⼀个 TCP 连接，下层的 TCP 协议是不知道有多少个 HTTP 请求的。所以⼀旦发⽣了丢包现象，就会触发 TCP 的重传机制，这样在⼀个 TCP 连接中的所有的 HTTP 请求都必须等待这个丢了的包被重传回来。
    
//HTTP/3 做了哪些优化？
    HTTP/1.1、HTTP/2 的问题都是基于 TCP 传输层的问题，所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP！
    UDP 发⽣是不管顺序，也不管丢包的，所以不会出现 HTTP/1.1 的队头阻塞 和 HTTP/2 的⼀个丢包全部重传问题。
    基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输（？）
    
//HTTPS优化
1.性能消耗：第⼀个环节， TLS 协议握⼿过程；第⼆个环节，握⼿后的对称加密报⽂传输（主要针对第一环节优化）
    -硬件优化，选择可以⽀持 AES-NI 特性的 CPU
    -软件优化：⼀个是软件升级，⼀个是协议优化（对「密钥交换过程」进⾏优化）
        -密钥交换算法优化：
    -证书优化
    -会话复用
    -

2. https工作流程：关键字（公私钥、数字证书、对称加密+ 非对称加密）

   • 客户端发起Https请求，连接到服务器的443端口。

   • 服务器必须要有一套数字证书（证书内容有公钥、证书颁发机构、失效日期等）。服务器将自己的数字证书发送给客户端（公钥在证书里面，私钥由服务器持有）。

   • 客户端收到数字证书之后，会验证证书的合法性。如果证书验证通过，就会生成一个随机的对称密钥，用证书的公钥加密。

   1.ssl证书如果验证失败会有哪些原因呢？
       -申请的SSL证书与域名不匹配
       -SSL证书已过期
       -发行SSL证书的数字证书颁发机构不受信任
   

   • 客户端将公钥加密后的密钥发送到服务器。
   • 服务器接收到客户端发来的密文密钥之后，用自己之前保留的私钥对其进行非对称解密，解密之后就得到客户端的密钥，然后用客户端密钥对返回数据进行对称加密，酱紫传输的数据都是密文啦。
   • 服务器将加密后的密文返回到客户端。
   • 客户端收到后，用自己的密钥对其进行对称解密，得到服务器返回的数据。

   1.中间人有可能篡改该证书吗？
      浏览器收到该证书后会发现原文和签名解密后的值不一致，则说明证书已被篡改，证书不可信
   2.中间人有可能把证书掉包吗？
      因为证书里包含了网站A的信息，包括域名，浏览器把证书里的域名与自己请求的域名比对一下就知道有没有被掉包了
   3.为什么制作数字签名时需要hash一次？
      性能:非对称加密效率较差，证书信息一般较长，比较耗时。而hash后得到的是固定长度的信息，加密解密就会快很多。
   4.为什么使用非对称加密和对称加密？
       -对称加密的问题在于这个密钥怎么让传输的双方知晓，同时不被别人知道，依赖于非对称加密将秘钥进行传输，非对称加密耗时所以采用非对称加密和对称加密组合的方式
   5.对称加密与非对称加密有什么区别
       -对称加密：指加密和解密使用同一密钥，优点是运算速度较快，缺点是如何安全将密钥传输给另一方。常见的对称加密算法有：DES、AES等。
       -非对称加密：指的是加密和解密使用不同的密钥（即公钥和私钥）。公钥与私钥是成对存在的，如果用公钥对数据进行加密，只有对应的私钥才能解密。常见的非对称加密算法有RSA。
   

3. cookie和session

1.浏览器关闭后,session还可以用吗?
    -同一浏览器，同一session，不同浏览器，不同session。
    -不可以用，sessionid不存在了
2.如果客户端禁止 cookie 能实现 session 还能用吗?
    -Session采用的是在服务器端保持状态的方案，而Cookie采用的是在客户端保持状态的方案。不能用，sessionid通过cookie传递
    -关闭Cookie的情况下使用Session利用 URL 重写把 Session ID 直接附加在URL路径的后面用文件、数据库等形式保存Session ID，在跨页过程中手动调用
3.概念：
    -Cookie是保存在客户端的一小块文本串的数据
    -Session指的是服务器和客户端一次会话的过程　　
4.cookie传递过程：
    当在浏览器地址栏中键入了一个Web站点的URL，浏览器会向该Web站点发送一个读取网页的请求，并将结果在显示器上显示。这时该网页在你的电脑上寻找Amazon网站设置的Cookie文件，如果找到，浏览器会把Cookie文件中的数据连同前面输入的URL一同发送到Amazon服务器。服务器收到Cookie数据，就会在他的数据库中检索你的ID，你的购物记录、个人喜好等信息，并记录下新的内容，增加到数据库和Cookie文件中去。如果没有检测到Cookie或者你的Cookie信息与数据库中的信息不符合，则说明你是第一次浏览该网站，服务器的CGI程序将为你创建新的ID信息，并保存到数据库中。
　　Cookie是利用了网页代码中的HTTP头信息进行传递的，浏览器的每一次网页请求，都可以伴随Cookie传递，例如，浏览器的打开或刷新网页操作。服务器将Cookie添加到网页的HTTP头信息中，伴随网页数据传回到你的浏览器，浏览器会根据你电脑中的Cookie设置选择是否保存这些数据。如果浏览器不允许Cookie保存，则关掉浏览器后，这些数据就消失。Cookie在电脑上保存的时间是不一样的，这些都是由服务器的设置不同决定得。Cookie有一个Expires（有效期）属性，这个属性决定了Cookie的保存时间，服务器可以通过设定Expires字段的数值，来改变Cookie的保存时间。如果不设置该属性，那么Cookie只在浏览网页期间有效，关闭浏览器，这些Cookie自动消失，绝大多数网站属于这种情况。通常情况下，Cookie包含Server、Expires、Name、Value这几个字段，其中对服务器有用的只是Name和Value字段，Expires等字段的内容仅仅是为了告诉浏览器如何处理这些Cookies。

4. HTTP常用的状态码及其含义？
   • 1：信息性状态码；2：成功响应；3：重定向；4：客户端错误；5：服务器端错误

//2xx
- 「200 OK」是最常⻅的成功状态码，表示⼀切正常。如果是⾮ HEAD 请求，服务器返回的响应头都会有 body 数据。
- 「204 No Content」也是常⻅的成功状态码，与 200 OK 基本相同，但响应头没有 body 数据。
- 「206 Partial Content」是应⽤于 HTTP 分块下载或断点续传，表示响应返回的 body 数据不是资源的全部，⽽是其中⼀部分，也是服务器处理成功的状态。
//3xx
- 3xx 类状态码表示客户端请求的资源发送了变动，需要客户端⽤新的 URL 重新发送请求获取资源，也就是重定向。
- 「301 Moved Permanently」表示永久重定向，说明请求的资源已经不存在了，需改⽤新的 URL 再次访问。（永久性转移）请求的网页已被永久移动到新位置。服务器返回此响应时，会自动将请求者转到新位置。
- 「302 Found」表示临时重定向，说明请求的资源还在，但暂时需要⽤另⼀个 URL 来访问。（暂时性转移）服务器目前正从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。此代码与响应GET和HEAD请求的301代码类似，会自动将请求者转到不同的位置。
- 301 和 302 都会在响应头⾥使⽤字段 Location ，指明后续要跳转的 URL，浏览器会⾃动重定向新的 URL。（类比：换房子和走亲戚）
- 「304 Not Modified」不具有跳转的含义，表示资源未修改，重定向已存在的缓冲⽂件，也称缓存重定向，⽤于缓存控制。
//4xx
- 4xx 类状态码表示客户端发送的报⽂有误，服务器⽆法处理，也就是错误码的含义。
- 「400 Bad Request」表示客户端请求的报⽂有错误，但只是个笼统的错误。
- 「403 Forbidden」表示服务器禁⽌访问资源，并不是客户端的请求出错。
- 「404 Not Found」表示请求的资源在服务器上不存在或未找到，所以⽆法提供给客户端。
//5xx
- 5xx 类状态码表示客户端请求报⽂正确，但是服务器处理时内部发⽣了错误，属于服务器端的错误码。
- 「500 Internal Server Error」与 400 类型，是个笼统通⽤的错误码，服务器发⽣了什么错误，我们并不知道。
- 「501 Not Implemented」表示客户端请求的功能还不⽀持，类似“即将开业，敬请期待”的意思。
- 「502 Bad Gateway」通常是服务器作为⽹关或代理时返回的错误码，表示服务器⾃身⼯作正常，访问后端服务器发⽣了错误。
- 「503 Service Unavailable」表示服务器当前很忙，暂时⽆法响应服务器，类似“⽹络服务正忙，请稍后重试”的意思。

5. HTTP 常用的请求方式，区别和用途？

//说⼀下 GET 和 POST 的区别？
1.Get ⽅法的含义是请求从服务器获取资源，这个资源可以是静态的⽂本、⻚⾯、图⽚视频等。
2.POST ⽅法则是相反操作，它向 URI 指定的资源提交数据，数据就放在报⽂的 body ⾥。
    -get请求，post提交
    -get不安全（请求参数在url后），post参数在请求体中，用户不可见
    -get的url有长度限制， post没有
    -get 请求会被浏览器主动 cache，而 post 不会，除非手动设置。
    -get 请求在发送过程中会产生一个 TCP 数据包；post 在发送过程中会产生两个 TCP 数据包（header和data）
    
//GET 和 POST ⽅法都是安全和幂等的吗？
1.安全和幂等:
    -在 HTTP 协议⾥，所谓的「安全」是指请求⽅法不会「破坏」服务器上的资源。
    -所谓的「幂等」，意思是多次执⾏相同的操作，结果都是「相同」的
2.GET ⽅法就是安全且幂等的，因为它是「只读」操作，⽆论操作多少次，服务器上的数据都是安全的，且每次的结果都是相同的。
3.POST 因为是「新增或提交数据」的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以不是幂等的。

7. 了解的端口及对应的服务？

8. HTTP/1.0，1.1，2.0的区别

   • HTTP/1.0默认是短连接，可以强制开启，HTTP/1.1默认长连接，HTTP/2.0采用多路复
   • http1.0:每次请求都需要建立一个TCP连接。设置Connection: keep-alive 强制开启长连接。（设置超链接超时keep-alive timeout）
   • http1.1:持久连接、分块传输编码、管道机制。
   • http2.0:二进制协议、完全多路复用、报头压缩、服务器推送。

9. 域名解析过程

   • 第一步：客户机提出域名解析请求,并将该请求发送给本地的域名服务器。

   • 第二步：当本地的域名服务器收到请求后,就先查询本地的缓存,如果有该纪录项,则本地的域名服务器就直接把查询的结果返回。

   • 第三步：如果本地的缓存中没有该纪录,则本地域名服务器就直接把请求发给根域名服务器,然后根域名服务器再返回给本地域名服务器一个所查询域(根的子域)的主域名服务器的地址。

   • 第四步：本地服务器再向上一步返回的域名服务器发送请求,接受请求的服务器查询自己的缓存,如果没有该纪录,则返回相关的下级的域名服务器的地址

   • 第五步：重复第四步,直到找到正确的纪录。

   • 第六步：本地域名服务器把返回的结果保存到缓存,以备下一次使用,同时还将结果返回给客户机。

10. 有哪些方面的因素会导致网站访问慢？

    • 服务器出口带宽不够用:加大出口带宽
    • 服务器负载过大，导致响应不过来
    • 数据库瓶颈
    • 网站开发代码没有优化好
    • 排查：服务端还是客户端数据加载慢；数据库缓存/搭建MySQL主从服务器；负载情况SQL语句查询慢；SQL语句优化

11. HTTP的结构：

    • HTTP请求报文：由请求行、请求头、空行和请求数据4个部分组成。
      1. 请求行：由三部分组成，请求方法、请求URL（不包括域名）、HTTP协议版本
         • 请求方法：GET、POST、HEAD、DELETE、OPTIONS、PUT、TRACE、CONNECT
         • HTTP协议版本：HTTP 1.0、HTTP1.1
      2. 请求头部：请求头部由关键字/值对组成，每行一对
         • User-Agent : 产生请求的浏览器类型
         • Accept : 客户端希望接受的数据类型，比如 Accept：text/xml（application/json）表示希望接受到的是xml（json）类型
         • Content-Type：发送端发送的实体数据的数据类型。比如，Content-Type：text/html（application/json）表示发送的是html类型。
         • Host : 请求的主机名，允许多个域名同处一个IP地址，即虚拟主机
      3. 空行：请求头之后是一个空行，通知服务器以下不再有请求头
      4. 请求体：GET没有请求数据，POST有。

    

    • 响应报文：由 状态行、消息报头、空行、响应正文组成
      1. 状态行：包括三个字段——协议版本、状态码与原因短语

    

第三部分、协议

1. 通信协议
   FTP 文件传输协议（File Transfer Protocol）
   SMTP：邮件传送协议，
   ARP 协议是正向地址解析协议（Address Resolution Protocol），通过已知的 IP，寻找对应主机的 MAC 地址
   RARP 协议是方向地址解析协议，通过 MAC 地址确定 IP地址

2. ARP 协议的工作过程？
   用于实现IP地址到MAC地址的映射。

   • 首先，每台主机都会在自己的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查询失败。

3. ICMP协议——控制消息协议
   ICMP协议是一种面向无连接的协议，用于传输出错报告控制信息。
   它是一个非常重要的协议，它对于网络安全具有极其重要的意义。它属于网络层协议，主要用于在主机与路由器之间传递控制信息，包括报告错误、交换受限控制和状态信息等。
   当遇到IP数据无法访问目标、IP路由器无法按当前的传输速率转发数据包等情况时，会自动发送ICMP消息。

   （1）ping的原理
   ping通知系统，新建一个固定格式的ICMP请求数据包

   ICMP协议，将该数据包和目标机器B的IP地址打包，一起转交给IP协议层

   IP层协议将本机IP地址为源地址，机器B的IP地址为目标地址，加上一些其他的控制信息，构建一个IP数据包

   先获取目标机器B的MAC地址。

   数据链路层构建一个数据帧，目的地址是IP层传过来的MAC地址，源地址是本机的MAC地址

   机器B收到后，对比目标地址，和自己本机的MAC地址是否一致，符合就处理返回，不符合就丢弃。

   根据目的主机返回的ICMP回送回答报文中的时间戳，从而计算出往返时间

   最终显示结果有这几项：发送到目的主机的IP地址、发送 & 收到 & 丢失的分组数、往返时间的最小、最大& 平均值

11.WebSocket与socket的区别
WebSocket是一个持久化的协议，它是伴随H5而出的协议，用来解决http不支持持久化连接的问题。

Socket一个是网编编程的标准接口，而WebSocket则是应用层通信协议。

12.forward和redirect的区别？
直接转发方式（Forward） ，客户端和浏览器只发出一次请求，Servlet、HTML、JSP或其它信息资源，由第二个信息资源响应该请求，在请求对象request中，保存的对象对于每个信息资源是共享的。
间接转发方式（Redirect） 实际是两次HTTP请求，服务器端在响应第一次请求的时候，让浏览器再向另外一个URL发出请求，从而达到转发的目的。

16.SQL注入攻击

18.有了IP地址，为什么还要用MAC地址？
计算机的IP地址可由用户自行更改，管理起来就相对困难，而MAC地址不可更改，所以一般会把IP地址和MAC地址组合起来使用。IP是得路由不会过于复杂，出现子网。

19.保活计时器的作用
若客户端故障，不必一直等待

20.URI和URL的区别
资源标识与资源地址

23.说说半连接队列和 SYN Flood攻击的关系
TCP进入三次握手前，服务端会从CLOSED状态变为LISTEN状态,同时在内部创建了两个队列：半连接队列（SYN队列）和全连接队列（ACCEPT队列）。
服务器ack:连接加入半连接队列
客户端ack:连接加入全连接队列

SYN Flood是一种典型的DDos攻击，它在短时间内，伪造不存在的IP地址,向服务器大量发起SYN报文。当服务器回复SYN+ACK报文后，不会收到ACK回应报文，导致服务器上建立大量的半连接半连接队列满了，这就无法处理正常的TCP请求啦。

方案应对
syn cookie：在收到SYN包后，服务器根据一定的方法，以数据包的源地址、端口等信息为参数计算出一个cookie值作为自己的SYNACK包的序列号，回复SYN+ACK后，服务器并不立即分配资源进行处理，等收到发送方的ACK包后，重新根据数据包的源地址、端口计算该包中的确认序列号是否正确，如果正确则建立连接，否则丢弃该包。

SYN Proxy防火墙：服务器防火墙会对收到的每一个SYN报文进行代理和回应，并保持半连接。等发送方将ACK包返回后，再重新构造SYN包发到服务器，建立真正的TCP连接。

26.Nagle 算法与延迟确认
TCP/IP协议中，无论发送多少数据，总是需要在数据前面加上协议头，同时，对方接收到数据，也需要发送ACK表示确认。为了尽可能的利用网络带宽，TCP总是希望尽可能的发送足够大的数据。Nagle算法就是为了尽可能发送大块数据，避免网络中充斥着许多小数据块。

Nagle算法：任意时刻，最多只能有一个未被确认的小段。 所谓“小段”，指的是小于MSS尺寸的数据块，所谓“未被确认”，是指一个数据块发送出去后，没有收到对方发送的ACK确认该数据已收到。
实现规则:
如果包长度达到MSS，则允许发送；
如果该包含有FIN，则允许发送；
设置了TCP_NODELAY选项，则允许发送；
未设置TCP_CORK选项时，若所有发出去的小数据包（包长度小于MSS）均被确认，则允许发送；
上述条件都未满足，但发生了超时（一般为200ms），则立即发送。

延迟确认
接收方收到数据包后，如果暂时没有数据要发给对端，它可以等一小段时间，再确认（Linux上默认是40ms）。如果这段时间刚好有数据要传给对端，ACK就随着数据传输，而不需要单独发送一次ACK。如果超过时间还没有数据要发送，也发送ACK，避免对端以为丢包。

不能用延迟确认:发现了乱序包、接收到了大于一个 frame 的报文，且需要调整窗口大小

一般情况下，Nagle算法和延迟确认不能一起使用，Nagle算法意味着延迟发，延迟确认意味着延迟接收，酱紫就会造成更大的延迟，会产生性能问题。

一、IP协议

1. IP地址分类：
   • 优点：简单明了、选路（基于⽹络地址）简单。
   • 缺点：同⼀⽹络下没有地址层次；不能很好的与现实⽹络匹配（数量问题）。

2. ⽆分类地址 CIDR
   • 32 ⽐特的 IP 地址被划分为两部分，前⾯是⽹络号，后⾯是主机号。
   • a.b.c.d/x ，其中 /x 表示前 x 位属于⽹络号， x 的范围是 0 ~ 32
3. ⼦⽹掩码
   • 掩盖掉主机号，剩余的就是⽹络号
   • 将⼦⽹掩码和 IP 地址按位计算 AND，就可得到⽹络号
   • 划分⼦⽹：⼦⽹划分实际上是将主机地址分为两个部分——⼦⽹⽹络地址和⼦⽹主机地址

4. 环回地址是不会流向⽹络：环回地址是在同⼀台计算机上的程序之间进⾏⽹络通信时所使⽤的⼀个默认地址。（127.0.0.1/localhost）
5. IP 分⽚与重组：
   • 当 IP 数据包⼤⼩⼤于 MTU 时， IP 数据包就会被分⽚。经过分⽚之后的 IP 数据报在被重组的时候，只能由⽬标主机进⾏，路由器是不会进⾏重组的。
   • 在分⽚传输中，⼀旦某个分⽚丢失，则会造成整个 IP 数据报作废，所以 TCP 引⼊了 MSS 也就是在 TCP 层进⾏分⽚不由 IP 层分⽚，那么对于 UDP 我们尽量不要发送⼀个⼤于 MTU 的数据报⽂。
6. IPv6 相⽐ IPv4 的⾸部改进：
   • 取消了⾸部校验和字段。 因为在数据链路层和传输层都会校验。
   • 取消了分⽚/重新组装相关字段。 分⽚与重组是耗时的过程，IPv6 不允许在中间路由器进⾏分⽚与重组，这种操作只能在源与⽬标主机，这将⼤⼤提⾼了路由器转发的速度。
   • 取消选项字段。 选项字段不再是标准 IP ⾸部的⼀部分了，但它并没有消失，⽽是可能出现在 IPv6 ⾸部中的「下⼀个⾸部」指出的位置上。删除该选项字段使的 IPv6 的⾸部成为固定⻓度的 40 字节。

7. IP 协议相关技术

   • DNS 域名解析：可以将域名⽹址⾃动转换为具体的 IP 地址
   • ARP 与 RARP 协议：将IP地址和MAC地址相互转换——借助 ARP 请求与 ARP 响应两种类型的包确定 MAC 地址
     1. 主机会通过⼴播发送 ARP 请求，这个包中包含了想要知道的 MAC 地址的主机 IP 地址。
     2. 当同个链路中的所有设备收到 ARP 请求时，会去拆开 ARP 请求包⾥的内容，如果 ARP 请求包中的⽬标 IP 地址与⾃⼰的 IP 地址⼀致，那么这个设备就将⾃⼰的 MAC 地址塞⼊ ARP 响应包返回给主机。
   • DHCP 动态获取 IP 地址：通过 DHCP 动态获取 IP 地址
     1. 客户端⾸先发起 DHCP 发现报⽂（DHCP DISCOVER） 的 IP 数据报，由于客户端没有 IP 地址，也不知道DHCP 服务器的地址，所以使⽤的是 UDP ⼴播通信，其使⽤的⼴播⽬的地址是 255.255.255.255（端⼝ 67）并且使⽤ 0.0.0.0（端⼝ 68） 作为源 IP 地址。DHCP 客户端将该 IP 数据报传递给链路层，链路层然后将帧⼴播到所有的⽹络中设备。
     2. DHCP 服务器收到 DHCP 发现报⽂时，⽤ DHCP 提供报⽂（DHCP OFFER） 向客户端做出响应。该报⽂仍然使⽤ IP ⼴播地址 255.255.255.255，该报⽂信息携带服务器提供可租约的 IP 地址、⼦⽹掩码、默认⽹关、DNS 服务器以及 IP 地址租⽤期。
     3. 客户端收到⼀个或多个服务器的 DHCP 提供报⽂后，从中选择⼀个服务器，并向选中的服务器发送 DHCP 请求报⽂（DHCP REQUEST进⾏响应，回显配置的参数。
     4. 最后，服务端⽤ DHCP ACK 报⽂对 DHCP 请求报⽂进⾏响应，应答所要求的参数。
   • NAT ⽹络地址转换：同个公司、家庭、教室内的主机对外部通信时，把私有 IP 地址转换成公有 IP 地址。
     1. NAT 穿透技术：客户端主动从 NAT 设备获取公有 IP 地址，然后⾃⼰建⽴端⼝映射条⽬，⽤这个条⽬对外通信，就不需要 NAT 设备来进⾏转换了。
   • ICMP 互联⽹控制报⽂协议
     1. ICMP 主要的功能包括：确认 IP 包是否成功送达⽬标地址、报告发送过程中 IP 包被废弃的原因和改善⽹络设置等。
     2. ICMP 类型：
   
   • IGMP 因特⽹组管理协议：管理一组内的主机
   • ping —— 查询报⽂类型的使⽤
     1. 源主机⾸先会构建⼀个 ICMP 回送请求消息数据包(类型+序号)。
     2. 协议字段设置为 1 表示是 ICMP 协议，再加上⼀些其他控制信息，构建⼀个 IP 数据包。
     3. 接下来，需要加⼊ MAC 头（本地 ARP 映射表/ARP 协议查询）
     4. 主机 B 收到这个数据帧后，先检查它的⽬的 MAC 地址，并和本机的 MAC 地址对⽐，如符合，则接收，否则就丢弃。
     5. 接收后检查该数据帧，将 IP 数据包从帧中提取出来，交给本机的 IP 层。同样，IP 层检查后，将有⽤的信息提取后交给 ICMP 协议。
     6. 主机 B 会构建⼀个 ICMP 回送响应消息数据包，回送响应数据包的类型字段为 0 ，序号为接收到的请求数据包中的序号，然后再发送出去给主机 A。
     7. 在规定的时候间内，源主机如果没有接到 ICMP 的应答包，则说明⽬标主机不可达；如果接收到了 ICMP 回送响应消息，则说明⽬标主机可达。
   • traceroute —— 差错报⽂类型的使⽤
     1. 作⽤⼀：故意设置特殊的 TTL，来追踪去往⽬的地时沿途经过的路由器。原理就是利⽤ IP 包的⽣存期限 从 1 开始按照顺序递增的同时发送 UDP 包，强制接收 ICMP 超时消息
     2. 作⽤⼆：故意设置不分⽚，从⽽确定路径的 MTU。主要是为了知道 MTU 的⼤⼩，从⽽控制发送的包⼤⼩

第四部分、CDN

第五部分、网络模型

一、TCP/IP ⽹络模型

1. 应⽤层：为⽤户提供应⽤功能，不⽤去关⼼数据是如何传输的,应⽤层是⼯作在操作系统中的⽤户态，传输层及以下则⼯作在内核态
2. 传输层：应⽤层的数据包会传给传输层，传输层（Transport Layer）是为应⽤层提供⽹络⽀持的。
   • 传输层会有两个传输协议，分别是 TCP 和 UDP
   • 传输层的报⽂中会携带端⼝号，因此接收⽅可以识别出该报⽂是发送给哪个应⽤
3. ⽹络层：提供实际的传输功能，⽹络层负责将数据从⼀个设备传输到另⼀个设备，最常使⽤的是 IP 协议
4. 数据链路层：标识⽹络中的设备，让数据在⼀个链路中传输，MAC 地址
5. 物理层：数据准备要从设备发送到⽹络时，需要把数据包转换成电信号，让其可以在物理介质中传输

二、OSI七层网络模型

1. 应用层：
2. 表示层：
3. 会话层：
4. 传输层：
5. 网络层：
6. 数据链路层：
7. 物理层：

第六部分 面试题

1. Https和Http的区别？HTTP的状态码有哪些？HTTP常用的方法？HTTPS通过SSL加密，加密的过程是怎么样的呢？HTTPS检查公钥是通过什么方式检查的？CA证书起什么样的作用，证书是什么时候出现的？

   • 费用:https协议需要到ca申请证书，一般免费证书很少，需要交费。
   • 加密:http是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议。
   • 连接:http和https使用的是完全不同的连接方式用的端口也不一样,前者是80,后者是443。
   • 状态:http的连接很简单,是无状态的 。
   • 安全性:HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议， 要比http协议安全。

2. ssl证书如果验证失败会有哪些原因呢？

   • 申请的SSL证书与网站域名不匹配
   • SSL证书无效已经过期
   • 颁发SSL证书的数字证书颁发机构不受信任
   • 页面包含HTTP不安全内容

3. 访问一个网址时域名解析成ip的过程？DNS解析发生在什么阶段？通过什么方式解决DNS劫持问题？

   • 第一步：客户机提出域名解析请求,并将该请求发送给本地的域名服务器。
   • 第二步：当本地的域名服务器收到请求后,就先查询本地的缓存,如果有该纪录项,则本地的域名服务器就直接把查询的结果返回。
   • 第三步：如果本地的缓存中没有该纪录,则本地域名服务器就直接把请求发给根域名服务器,然后根域名服务器再返回给本地域名服务器一个所查询域(根的子域)的主域名服务器的地址。
   • 第四步：本地服务器再向上一步返回的域名服务器发送请求,然后接受请求的服务器查询自己的缓存,如果没有该纪录,则返回相关的下级的域名服务器的地址
   • 第五步：重复第四步,直到找到正确的纪录。
   • 第六步：本地域名服务器把返回的结果保存到缓存,以备下一次使用,同时还将结果返回给客户机。

4. 浏览器地址栏输入url，有哪些协议？

   • 浏览器会根据你输入的 URL 地址，去查找域名是否被本地 DNS 缓存，不同浏览器对 DNS 的设置不同，如果浏览器缓存了你想访问的 URL 地址，那就直接返回 ip。
   • 如果没有缓存你的 URL 地址，浏览器就会发起系统调用来查询本机 hosts 文件是否有配置 ip 地址，如果找到，直接返回。
   • 如果找不到，就向网络中发起一个 DNS 查询。在由根域名服务器 -> 顶级域名服务器 -> 权威 DNS 服务器后，由权威服务器告诉本地服务器目标 IP 地址，再有本地 DNS 服务器告诉用户需要访问的 IP 地址//对应ip地址解析
   • 浏览器需要和目标服务器建立 TCP 连接
   • 向服务器发送HTTP请求
   • 服务器处理请求，返回网页内容
   • 浏览器解析并渲染页面
   • TCP四次挥手，连接结束
   • DNS是域名系统(DomainNameSystem)的缩写，该系统用于命名组织到域层次结构中的计算机和网络服务，可以简单地理解为将URL转换为IP地址。

5. 怎么处理跨域问题？

   跨域，指的是浏览器不能执行其他网站的脚本。它是由浏览器的同源策略造成的，是浏览器对javascript施加的安全限制。
   1.JSONP：
   2.代理
   3.PHP端修改header
   

6. TCP3次握手，4次挥手？为什么要3次握手？不是4次，5次？为什么要4次挥手？

   • 1.3次握手的原因：防止丢包问题，第二次服务端的确认丢失，则c和s都会等待，若使用第三次握手，若丢失，则s收不到确认，会重发。
     2.对于三次没必要，少于三次会有意外
     3.4次挥手的原因：不能某一方想断开就断开
   • 客户端和服务端都没有数据要发送的时候才能断开TCP。
   • 客户端发出FIN报文时只能保证客户端没有数据发了。
   • 服务端收到客户端的FIN报文后只能先回复客户端一个确认报文来告诉客户端我服务端已经收到你的FIN报文了，但我服务端还有一些数据没发完，等这些数据发完了服务端才能给客户端发FIN报文。

7. 有了解中间人攻击吗？假设去攻击一个HTTPS的请求该怎么去攻击？

8. TCP怎么判断发生拥塞？

   • TCP连接方一般是基于丢包来判断当前网络是否发生拥塞，丢包可以由重传超时RTO和重复确认来做判断。

9. TCP如何保证可靠性

   • 校验和：通过检验和的方式，接收端可以检测出来数据是否有差错和异常，假如有差错就会直接丢弃TCP段，重新发送。
   • 序列号+确认应答：序列号：TCP传输时将每个字节的数据都进行了编号，这就是序列号。确认应答：TCP传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答。
   • 超时重传：发送方发送数据后的一段时候内，如果没有接收到接收方的ACK响应，那么刚刚发送的数据需要重新发送。
   • 连接管理：三次握手，四次挥手
   • 流量控制：滑动窗口机制
   • 拥塞控制：慢启动+拥塞避免+拥塞发生+快恢复

10. DNS选择TCP还是UDP协议？

    • 域名解析：实现这种功能一般来说是认为使用的UDP协议，当客户端向DNS查询域名，一般不会超过512字节，而且无连接的过程更安全也更快，所以使用UDP协议进行通信有其独特的好处，体现在效率高，相对来说更加安全，不过也是不可靠的
    • 区域传输：
      1. 辅域名服务器会定时（一般3小时）向主域名服务器进行查询以便了解数据是否有变动。如有变动，会执行一次区域传送，进行数据同步。
      2. 区域传送使用TCP而不是UDP，因为数据同步传送的数据量比一个请求应答的数据量要多得多。实现这种功能时则有时需要TCP协议，即进行与主域名服务器进行查询以确认数据是否有效，用TCP则是依赖了其可靠性

11. 设计一个可靠的udp？

12. TCP建立连接交换了什么信息？

13. session和token的区别：

    • token的生成方式：浏览器第一次访问服务器，根据传过来的唯一标识userId，服务端会通过一些算法，如常用的HMAC-SHA256算法，然后加一个密钥，生成一个token，然后通过BASE64编码一下之后将这个token发送给客户端；客户端将token保存起来，下次请求时，带着token，服务器收到请求后，然后会用相同的算法和密钥去验证token，如果通过，执行业务操作，不通过，返回不通过信息；
    • session生成方式：浏览器第一次访问服务器，服务器会创建一个session，然后同时为该session生成一个唯一的会话的key,也就是sessionid，然后，将sessionid及对应的session分别作为key和value保存到缓存中，也可以持久化到数据库中，然后服务器再把sessionid，以cookie的形式发送给客户端。这样浏览器下次再访问时，会直接带着cookie中的sessionid。然后服务器根据sessionid找到对应的session进行匹配；还有一种是浏览器禁用了cookie或不支持cookie，这种可以通过URL重写的方式发到服务器；
    • cookie机制：只要你带通行证不管你是谁都可以进来,只认通信证，cookie在这里是通行证。
    • session机制：要报你的门牌号户主姓名电话号码，大楼门卫在信息表里找到对应的就会放行。session在这里是信息表里的门牌号户主姓名电话号码。
    • token机制：检验通行证，同时需要对暗号“天王盖地虎”---“宝塔镇河妖”，暗号错一个字都不行。token在这里就是通行证和暗号。
    • 参考链接：https://www.likecs.com/show-96455.html

14. 数字证书包含什么信息：

    • 申请者的组织信息和个人信息、证书持有者的公钥、证书颁发机构信息、证书有效期、证书序列号、证书电子签名、签名计算方法。
    • 最简单的证书包含一个公开密钥、名称以及证书授权中心的数字签名。

15. 服务器端的TCP如果长时间没有通讯,可以自动断开吗

    • 用TCP通讯时，TCP一旦建立不会自动断开，但是可以通过设置超时断开。

16. Http 协议和TCP协议的关系是什么

    • http的任务是与服务器交换信息，它不管怎么连到服务器和保证数据正确的事情。而tcp的任务是保证连接的可靠，它只管连接，它不管连接后要传什么数据。http协议不一定要建在TCP的连接上的。

17. HTTP 与TCP中Keep-Alive机制的区别

    • TCP连接往往就是广义理解上的长连接，因为它具备双端连续收发报文的能力；开启了keep-alive的HTTP连接，也是一种长连接，但是它由于协议本身的限制，服务端无法主动发起应用报文。
    • TCP中的keepalive是用来保鲜、保活的；HTTP中的keep-alive机制主要为了让支撑它的TCP连接活的的更久，所以通常又叫做：HTTP persistent connection（持久连接） 和 HTTP connection reuse（连接重用）。
    • 参考链接：https://blog.csdn.net/tianshouzhi/article/details/103922842

18. 访问一个网址，返回一个错误，怎么排查问题？我说ping看网络通不通，又被问到ping目标主机，返回127.0.0.1是怎么回事？