【八股学习笔记】计算机网络

最新推荐文章于 2025-05-03 10:31:57 发布

速效救薪丸

最新推荐文章于 2025-05-03 10:31:57 发布

阅读量640

点赞数 30

文章标签：学习笔记计算机网络

本文链接：https://blog.csdn.net/weixin_46836669/article/details/147665326

版权

#王者杯·14天创作挑战营·第1期#

一、网络基础

1、OSI七层模型与TCP/IP四层模型
2、网页解析
- 在浏览器输入url按下回车键之后会发生什么？？
  - 1、浏览器解析URL：解析URL的协议、端口、路径信息后，构建一个http请求报文，（可能会加载http缓存）
  - 2、DNS域名解析，将域名解析为IP地址：首先读取浏览器自身缓存是否有域名对应的IP地址，有👉直接返回IP地址；没有则查操作系统的缓存（hosts文件），本地DNS服务器分别取根域名服务器→顶级域名服务器→权威域名服务器询问，最后拿着返回的ip交给浏览器
  - 3、建立TCP连接，三次握手：客户端发送第一次握手时，TCP头部会填上SYN标记位，同时填上目标端口和源端口的信息。源端口是浏览器随机生成的，目标端口要看是HTTPorHTTPS，HTTP默认目标端口为80，HTTPS默认是443
    - 请求层层封装，传输层到网络层会加上IP头，填上源目IP地址。👉数据链路层会通过ARP协议，获取路由器的MAC地址，加上MAC头，填上源目MAC地址。👉物理层直接把数据包转发给路由器，路由器再通过下一跳，最终找到目标服务器。目标服务器收到客服端的SYN报文后，会响应第二次握手。
  - 4、浏览器发送HTTP/HTTPS请求到web服务器：完成三次握手建立TCP连接后，客户端发送HTTP请求给服务器；如果是HTTPS协议，还需要进行TLS四次握手之后再发送HTTP报文。
  - 5、服务器处理HTTP请求并返回HTTP报文：响应报文包括：请求的网页、状态码、压缩类型，如何缓存的页面，设置的cookie等
  - 6、浏览器渲染页面
  - 7、断开连接、TCP四次挥手

二、传输层

1、TCP
- TCP的头部有哪些字段？？
  - 【源目端口号、序列号、确认应答号、控制位、窗口大小、校验和、首部长度/数据偏移】
  - 1、【16位的源目端口号】⽤于多路复⽤/分解来⾃或送到上层应⽤的数据。告诉主机报⽂段来⾃哪⾥，传给哪个上层协议或应⽤程序。标识双方的应用程序/通信进程
  - 2、【32位的序列号和确认应答号】解决网络包乱序和可靠性，都是用于实现可靠数据传输
  - 3、【控制位】比如SYN用于发起连接的请求、ACK用于确认、FIN用于断开连接、RST用于重置连接
  - 4、【首部长度、窗口大小】标识TCP头部有多少字节、告诉对方本段TCP缓存还有多少空间可以接受数据，用于实现流量控制
  - 5、【校验和】UDP也有，用于数据完整性校验
- 请详细描述TCP三次握手的具体过程？？
  - 【请求、确认请求、确认服务器的确认】三次握手是建立可靠连接的关键步骤
  - 【第一次握手SYN报⽂】客户端随机初始化序列号seq=x，放进TCP首部序列号字段，然后把SYN=1。把SYN报⽂（SYN=1）发送给服务端，表示发起连接，之后客户端处于 SYN-SENT 状态。
  - 【第二次握手SYN+ACK报⽂】服务端收到客户端的SYN报⽂之后，会把⾃⼰随机初始化的序列号 server_isn 放进TCP⾸部序列号段seq=y，「确认应答号」填⼊ client_isn + 1ack=x+1。把SYN+ACK报⽂（SYN=1 ACK=1)发送给客户端，然后进⼊ SYN-RCVD 状态,表示服务器接受了客户端的请求，并希望建⽴连接。
  - 【第三次握手ACK报文】该应答报⽂ TCP ⾸部 ACK 标志位置为 1 ，其次「确认应答号」字段填⼊ server_isn + 1 ack=y+1，序列号是seq=x+1最后把报⽂(ACK=1)发送给服务端，这次报⽂可以携带客户到服务器的数据，之后客户端处于 ESTABLISHED 状态, 表示客户端已经准备好与服务器进⾏数据传输。服务器收到客户端的应答报⽂后，也进ESTABLISHED 状态。
    
    只有第三次握手可以携带数据，原因是：如果在第三次握手时携带数据，即使数据丢失，客户端和服务器都可以通过 TCP 的重传机制来确保数据的可靠传输。前两次握手不携带数据，是为了确保连接的可靠建立，避免因数据丢失或报文丢失导致连接建立失败。
- 为什么不TCP建立是三次握手，不是两次握手？？
  - 【防止历史连接建立、减少双方不必要资源开销、防止资源浪费、同步双方初始序列号并确认双方的发送接收消息的能力】
  - 1、【防止历史连接建立（主因）】
  - 如果只是两次握⼿，服务端在收到SYN报⽂之后，就进⼊到 ESTABLISHED 状态, 服务器端并不知道这次是历史连接，直接与客户端建⽴连接并向客户端发送数据（资源浪费），但是客户端会判定这次连接是历史连接，从⽽发送RST报⽂来断开连接。而三次握手，可以通过收到的SYN-ACK确认应答号来判断是否为期望的新响应，不是就RST包断开
  - 2、【同步双⽅的初始序列号】序列号是可靠传输的⼀个关键因素，包括去除重复元素、按顺序接受、标识已接受的数据包。三次握手才能保证双方都确认自己有收发能力。
  - 3、【避免资源浪费】两次握手，服务端一收到SYN报文就建立连接建⽴多个冗余的⽆效链接，造成不必要的资源浪费。
- 如果TCP第一次握手发生丢包，会有什么现象？？
  - 【TCP超时重传机制-重传次数和时间-连接放弃】
  - 第一握手发送SYN报文，进入SYN-SENT状态后，会设定⼀个计时器，当超过指定的时间后，没有收到对⽅的确认SYN-ACK应答报⽂，就会重发该数据，并且超时时间逐渐增加（策略是加倍，指数退避）
  - 这个重传的过程会持续进行，直到收到SYN-ACK报文，或者达到预设的最大重传次数。
  - 一直没有相应，则连接放弃
- 如果TCP第二次握手发生丢包，会有什么现象？？
  - 双方均认为自己刚才发送的包丢失了，同时触发重传
- 如果TCP第三次握手发生丢包，会发生什么？？
  - 客户端发送ACK报文后，就认为连接已经确立，进入ESTABLISHED状态，不会进行重传。
  - 服务端会认为自己的SYN-ACK报文丢失了，触发重传
- 了解什么是TCP半连接队列吗？？
  - 半连接队列（SYN队列）⽤于存放已经发送了 SYN（同步）包，但还未完成三次握⼿的连接：服务器第⼀次收到客户端的 SYN 之后，就会处于 SYN_RCVD 状态，此时双⽅还没有完全建⽴其连接，服务器会把此种状态下请求连接放在⼀个队列⾥，我们把这种队列称之为半连接队列。
  - 全连接队列（Accept队列）⽤于存放已经完成三次握⼿，处于完全建⽴连接状态的连接。等待应用程序的accept()来获取队列中的连接
  - 你可以把半连接队列想象成一个等待区，而全连接队列是准备就绪可以被应用程序使用的连接的缓冲区。这两个队列对于服务器处理并发连接请求至关重要。
- 什么是SYN攻击？？如何应对这种攻击？？
  - 在 SYN 攻击中，攻击者发送⼤量伪造的 SYN 请求到⽬标服务器，但不完成后续的握⼿过程，从⽽让服务器⼀直等待确认，消耗服务器的资源（如半连接队列和系统资源），当半连接队列满了之后，后续再收到SYN报⽂就会丢弃，导致⽆法与客户端之间建⽴连接。
  - 【适用SYN-Cookies】当半连接队列满时，服务器可以启用 SYN Cookies。启用 SYN Cookies 后，服务器不会为每个 SYN 请求分配资源，而是通过一个特殊的算法计算出一个 cookie 值，将其作为 SYN-ACK 报文的序列号发送给客户端。当客户端发送 ACK 报文时，服务器验证 ACK 报文中的序列号是否与之前计算的 cookie 值一致。如果一致，说明这是一个合法的连接请求，服务器才会为其分配资源并建立连接
  - 【调整系统参数、优化服务器性能、调整应用程序逻辑】
  - 增加半连接队列的大小、缩短SYN-REVC状态的持续时间等；
  - 服务器硬件配置升级、增加服务器数量/代理服务器来三次握手建立连接、应用程序逻辑调整，尽快调用accept()函数来处理新的连接请求，以确保服务器的正常运行。
- 能否详细描述一次TCP四次挥手的过程？请具体说明每个阶段TCP连接的状态变化？？
  - 【步骤、状态变化、主动断开和被动断开】挥手前均处于ESTABLISHED状态
  - 1、【第一次挥手】客户端发送FIN报文给服务端，进入FIN_WAIT_1状态，seq=u
  - 2、【第二次挥手】
  - 服务端收到以后，向客户端发送ACK应答报⽂seq=v，且把客户端的序列号值+1作为ACK报⽂的序列号值ack=u+1，表明已经收到客户端的报⽂了，此时服务端处于CLOSE_WAIT 状态;客户端收到ACK包后，进入FIN_WAIT_2状态
    
    服务器的应用程序收到通知，可以开始清理资源。
  - 3、【第三次挥手】等待服务端处理完数据后，向客户端发送FIN报⽂。此时服务端处于 LAST_ACK 的状态seq=w且ack=u+1
    
    服务器的应用程序调用 close() 函数，请求操作系统关闭 TCP 连接。
  - 4、【第四次挥手】客户端接收到FIN报⽂后回⼀个ACK应答报⽂seq=u+1且ack=w+1，之后客户端处于 TIME_WAIT 状态;服务端收到ACK报⽂后，进⼊ CLOSE 状态，服务器完成连接关闭
  - 客户端在经过 2MSL ⼀段时间后，⾃动进⼊ CLOSE 状态，客户端也完成连接的关闭。目的是确保最后一个ACK报文能够到达服务端，并且防止网络中残留的旧报文干扰新的连接。
- 为什么TCP断开连接是四次挥手而不是三次呢？？
  - 【TCP全双工通信特性、关闭的独立性、服务端CLOSE_WAIT状态】
  - TCP 需要四次挥手主要是因为 TCP 连接是全双工的，这意味着连接的两端可以同时进行数据的发送和接收。
  - 当一方（比如客户端）完成数据发送想要关闭连接时，客户端发送FIN报⽂，表示其不再发送数据，但还可以接收数据。服务端收到这个 FIN 报文后，会先回复一个 ACK 报文，表示已经知道了客户端不再发送数据了。但是，服务端可能还有一些数据没有发送完，因此它不能立即发送 FIN 报文来关闭连接，而是需要等待自己的应用程序处理完所有数据后再发送 FIN 报文。
  - 这就导致了服务端发送 ACK 和 FIN 报文这两个动作可能是分开进行的，从而形成了四次挥手。
  - 如果只有三次挥手，当服务端收到客户端的 FIN 并回复 ACK 后就立即发送 FIN，那么如果服务端还有数据没发完，就会导致数据丢失。
- 为什么需要TIME_WAIT状态？如何产生？？
  - 主动发起关闭连接的⼀⽅，才会有 TIME-WAIT 状态。该状态是发送完最后一个ACK报文（第四次挥手）后进入的。
  - 目的【确保可靠终止】保证最后的 ACK 能让被动关闭⽅接收，从⽽帮助其正常关闭
  - 如果最后的⼀次ACK报⽂丢失（第四次挥⼿），客户端没有 TIME_WAIT 状态，直接进⼊ClOSE，服务端⼀直在等待ACK状态，⼀直没有等到，就会重发FIN报⽂，⽽客户端已经进⼊到关闭状态，在收到服务端重传的 FIN 报⽂后，就会回 RST 报⽂,服务端收到这个 RST 并将其解释为⼀个错误, 为了防⽌这种情况出现，客户端必须等待⾜够⻓的时间，确保服务端能够收到 ACK，如果服务端没有收到 ACK，那么就会触发 TCP 重传机制，服务端会重新发送⼀个FIN，这样⼀去⼀来刚好两个 MSL 的时间。
  - 避免【延迟报文干扰新连接】：防止历史连接中的数据，被后⾯相同四元组的连接错误的接收；
  - 如果⽹络出现拥塞或延迟，数据包可能会在⽹络中滞留⼀段时间，甚⾄超过了原始连接关闭的时间。如果没有TIME_WAIT 状态，客户端直接进⼊到CLOSE状态，这些滞留的数据包可能会被传递给新连接，导致新连接的数据被旧连接的数据⼲扰。
- 为什么 TIME_WAIT 等待的时间是 2MSL？
  - 【MSL定义、保证ACK可靠到达、防止延迟报文干扰、权衡】
  - MSL是 Maximum Segment Lifetime ，报⽂最⼤⽣存时间，它是任何报⽂在⽹络上存在的最⻓时间，超过这个时间报⽂将被丢弃。
  - 【计时起点】2MSL 的时间是从客户端接收到 FIN 后发送 ACK 开始计时的。如果在 TIME-WAIT 时间内，因为客户端的 ACK没有传输到服务端，客户端⼜接收到了服务端重发的 FIN 报⽂，那么 2MSL 时间将重新计时。
  - 【一来一回需要2MSL】⽹络中可能存在发送⽅的数据包，当这些发送⽅的数据包被接收⽅处理后⼜会向对⽅发送响应，所以⼀来⼀回需要等待 2 倍的时间。
  - 【可靠性与资源性能的权衡】过多的TIME-WAIT 状态内存资源占⽤，占满了所有端⼝资源，则会导致⽆法创建新连接。
  - 【旧连接的残留报文段自然消失而不会干扰】可以保证这两个方向上所有可能延迟到达的报文都被丢弃，这样新的连接就不会收到来自上一次连接的延迟报文了。
- TIME_WAIT 过多有什么危害？有什么解决办法吗？？
  - 内存资源占⽤，占满了所有端⼝资源，则会导致⽆法创建新连接。
  - 【客户端主动关闭】可以开启tcp_tw_reuse参数，起到连接复用的作用
  - 【服务端主动关闭】调整应用程序的连接管理策略，例如尽量适用长连接而非短连接，或者在应用层设计一些机制，使得在无需连接时由客户端主动发起关闭连接请求，以减少服务端进入TIME_WAIT状态的概率
  - 【操作系统TCP参数】缩短MSL时间，但也需要谨慎评估对网络稳定性的影响。
- TCP内核缓冲区？？
  - 【发送缓冲区】是内核为每个 TCP 连接维护的一个内存区域，用于存储待发送的数据。
2、TCP可靠性传输
- TCP重传机制只有超时重传吗？？
  - 【超时重传、快速重传】
  - 1、【超时重传】设定⼀个计时器，当超过指定的时间后，没有收到对⽅的确认ACK应答报⽂，就会重发该数据。
  - 2、【快速重传】快速重传（Fast Retransmit）机制，它不以时间为驱动，⽽是以数据驱动重传。
  - 当收到三个相同的ACK报⽂时，会在定时器过期之前，重传丢失的报⽂段。
  - 2-1、【SACK选择性确认-快速重传】
  - 这种⽅式需要在 TCP 头部「选项」字段⾥加⼀个 SACK 的东⻄，可以将已收到的数据的信息发送给「发送⽅」，这样发送⽅就可以知道哪些数据收到了，哪些数据没收到，知道了这些信息，就可以只重传丢失的数据。
  - 2-2、【D-SACK】主要使⽤了SACK来告诉【发送⽅】有哪些数据被重复接收了。是发出去的包丢了，还是接收⽅回应的ACK包丢了；
- 什么是TCP滑动窗口？是怎么设计的？解决了什么问题？？
  - 【发送窗口、接收窗口、吞吐量与效率】
  - 【TCP缺点】TCP每发送⼀个数据，都需要⼀次应答，数据往返时间越⻓，⽹络吞吐量越低。
  - 【窗口概念】即使在往返时间较⻓的情况下，它也不会降低⽹络通信的效率。⽽窗⼝的⼤⼩呢，就是⽆需等待确认应答，可以继续发送数据的最⼤值。
  - 【内核缓冲区】双方的内核中都维护一个缓冲区，缓冲区上定义了一个窗口。
  - 窗⼝的实现就是操作系统开辟的⼀个缓存空间，发送⽅主机在等到确认应答返回之前，必须在缓冲区中保留已发送的数据。如果按期收到确认应答，此时数据就可以从缓存区清除。
  - 对于发送方来说，窗口大小为未收到ACK报文前可以连续发送的最大数据量。对于接收方来说，接受窗口大小表示接收缓冲区内当前可用的空间大小。
  - 【ACK报文通知】接收方会将自己的接收窗口大小通过ACK报文（TCP报文首部）告知发送方。发送方得知后，灵活调整自己的发送频率，避免发送过多数据导致接收方处理不当而丢包，实现了流量控制
  - 总体而言，滑动窗口机制主要解决了串行发送-确认方式效率低下的问题，并实现了流量控制，保证了数据传输的可靠性。
- 接收窗⼝和发送窗⼝的⼤⼩是相等的吗？
  - 并不是完全相等，接收窗⼝的⼤⼩是约等于发送窗⼝的⼤⼩的。
  - 因为滑动窗⼝并不是⼀成不变的。⽐如，当接收⽅的应⽤进程读取数据的速度⾮常快的话，这样的话接收窗⼝可以很快的就空缺出来。那么新的接收窗⼝⼤⼩，是通过 TCP 报⽂中的 Windows 字段来告诉发送⽅。那么这个传输过程是存在时延的，所以接收窗⼝和发送窗⼝是约等于的关系。
- TCP流量控制机制的实现？？
  - 基本原理是使⽤滑动窗⼝机制，其中接收⽅可以通过调整窗⼝⼤⼩来告诉发送⽅其当前处理数据的能⼒。
  - 【接收窗口与通告】接收⽅维护⼀个接收窗⼝，表示可以接收的数据段的范围。窗⼝⼤⼩可以根据接收⽅的处理能⼒进⾏调整。接收⽅通过 TCP 报⽂中的确认信息，通告当前的接收窗⼝⼤⼩给发送⽅。发送⽅会根据这个窗⼝⼤⼩来控制发送数据的速率。
  - 【窗口滑动】随着接收⽅处理数据的能⼒，窗⼝可以向前滑动。接收⽅可以通告更⼤的窗⼝，表示它可以接收更多的数据。
  - 【发送速率控制】发送⽅会根据接收⽅通告的窗⼝⼤⼩来控制发送数据的速率。如果接收窗⼝变⼩，表示接收⽅的处理能⼒减弱，发送⽅会减慢发送速率，避免数据拥塞。
  - 【动态调整】TCP 流量控制是动态的，适应⽹络和接收⽅的变化。如果⽹络拥塞或接收⽅的处理速度变慢，流量控制可以适时地减少发送速率。
- TCP协议的拥塞控制是如何实现的？你能详细描述它的过程吗？？
  - 【慢启动、拥塞避免、网络拥塞监测（快速重传、超时重传）、两种调整方案】
  - 【解决问题】避免网络拥堵导致「发送⽅」的数据填满整个⽹络。
  - 拥塞窗⼝ cwnd 是发送⽅维护的⼀个状态变量，根据⽹络拥塞程度⽽变化。⽹络中没有出现拥塞，cwnd增⼤，出现拥塞，cwnd减⼩。
  - 【慢启动】是⼀点⼀点的提⾼发送数据包的数量。慢启动算法，发包的个数是指数性的增⻓。
  - 【拥塞避免】超过初始的ssthresh就会进入拥塞避免算法，它的规则是：每当收到⼀个 ACK 时，cwnd 增加1/cwnd。将原本慢启动算法的指数增⻓变成了线性增⻓，还是增⻓阶段，但是增⻓速度缓慢了⼀些。不过⽹络就会慢慢进⼊了拥塞的状况了，就会出现丢包现象，这时就需要对丢失的数据包进⾏重传。
  - 【拥塞发⽣】当⽹络出现拥塞，也就是会发⽣数据包重传，TCP检测丢包的两种重传机制主要有两种：超时重传、快速重传。优先触发快速重传和快速恢复。
  - 1【超时重传触发拥塞发生算法】阈值ssthresh更新为拥塞时的窗口大小的一半cwnd/2 ，cwnd 重置为 1。接着，就重新开始慢启动，慢启动是会突然减少数据流的。--→反应强烈，网络卡顿感明显
  - 2【**快速重传-快速恢复】**当发送方连续收到三个重复的 ACK 时，会认为发生了丢包，会立即重传丢失的报文，并进入快速恢复阶段。
  - 拥塞窗⼝减半后+3 cwnd = ssthresh + 3 （ 3 的意思是确认有 3 个数据包被收到了）；然后进入拥塞避免阶段，拥塞窗口继续现象增长
- TCP的流量控制和拥塞控制机制有什么不同？？
  - 【流量控制：端到端、拥塞控制：网络层面】
  - TCP 的流量控制和拥塞控制都是为了保证可靠传输，但它们解决的问题和控制的层面是不同的。流量控制是一个端到端的机制，它的目的是防止发送方发送数据的速度超过接收方的处理能力，避免接收方因缓冲区溢出而丢包。这是通过接收方在 ACK 报文中告知发送方自己的接收窗口大小来实现的。
  - 而拥塞控制是网络层面的机制，它的目的是防止过多的数据包同时在网络中传输，导致网络出现拥塞。当网络拥塞时，数据包可能会丢失或延迟，这会影响所有使用该网络的连接。TCP 通过慢启动、拥塞避免、拥塞发生以及快速重传、快速恢复等算法来感知网络的拥塞情况，并动态调整发送速率，以减轻网络的负担。
- TCP的延迟应答和累计应答是什么？？
  - 这两种方式都是TCP传输为了提高效率而提出的机制
  - 【延迟应答】是指接收方在收到数据报文后，不会立即发送ACK确认，而是会等待一段时间，看看该时间段是否有数据需要发送给对方（应用程序响应），如果有，就可以将ACK和要发送的数据一起发送出去，以减少ACK报文数量，提高网络利用率。注意适当延时，避免发送方误以为超时而重传
  - 【累计应答】接收方可以一次性确认收到的多个连续的数据包，再返回一个ACK报文，减少报文数量，提高网络效率。
- TCP粘包和拆包问题你了解吗？？为什么会出现这两种现象？如何解决呢？？
  - 【TCP字节流】TCP是⼀个面向字节“流”协议，所谓流，就是没有界限的⼀⻓串⼆进制数据。不像UDP那样有明确的边界。没有消息的边界保护机制。
    
    UDP则是⾯向消息传输的，是有保护消息边界的，接收⽅⼀次只接受⼀条独⽴的信息，所以不存在粘包问题。
  - 【含义】TCP作为传输层协议并不了解上层业务数据的具体含义，它会根据TCP缓冲区的实际情况进⾏数据包的划分，所以在业务上认为是⼀个完整的包，可能会被TCP拆分成多个段进⾏发送，也有可能把多个⼩的包封装成⼀个⼤的数据包发送，这就是所谓的TCP粘包和拆包问题。
    
    TCP为提⾼性能，发送端会将需要发送的数据发送到缓冲区，等待缓冲区满了以后，再将缓冲中的数据发送到接收⽅。同理，接收⽅也有缓冲区这样的机制来接受数据。
  - 【出现拆包原因】发送的数据超过TCP的MSS(最大报文段长度)或者接收端的接收窗口大小时，TCP会将数据分割成多个TCP段进行传输。从应用层看，一个完整的数据包被分成多次接收。应用程序写入数据大于socket缓冲区大小，会发生拆包
  - 【出现粘包的原因】应用层发送数据包较小时，TCP为了提高传输效率，可能会用Nagle算法将多个小的 TCP 段合并成一个较大的 TCP 段发送。接收端可能会一次性接收到多个逻辑上独立的数据包。应用程序写入数据小于socket缓冲区大小，网卡将应⽤多次写⼊的数据发送到⽹络上，这将会发送粘包。
  - 解决思路：由于是TCP流式特性造成，因此需要在应用层处理，明确数据包的边界。
  - 方法1【特定分隔符】：在每个消息的末尾添加一个特殊的、不会在消息内容中出现的分隔符，接收方通过分隔符来识别消息的边界。
  - 方法2【自定义消息结构-发送长度】：定义包含消息长度字段的消息头，接收方首先读取长度字段，然后读取相应长度的消息内容。
3、UDP
- UDP和TCP的区别？？
  - TCP面向连接的、可靠的、有状态的字节流式传输控制协议
  - UDP不可靠的、无状态的数据报文段传输控制协议
  - 【连接性】TCP面向连接，在正式传输数据之前需要通过三次握手建立连接。UDP可以直接发送数据，不需要建立连接的过程
  - 【可靠性】TCP提供了很多机制来保证数据的传输可靠性，如重试机制、流量控制和拥塞控制。UDP属于尽自己最大努力交付级别的可靠性，不保证顺序和完整性
  - 【传输方式-消息边界】TCP传输的数据是基于字节流的，没有明确的消息边界，可能会导致粘包拆包问题，而UDP是基于数据报传输，每次发送一个完整的数据包，有明确的消息边界
  - 总体而言，TCP的优势在于可靠性，适用于对数据完整性要求高的场景，但可能会牺牲一些实时性，如文件传输、网页浏览；UDP的优势在于高效简洁、实时性好，适用于对于实时性要求高容忍少量丢包的场景，如直播、在线游戏、DNS查询等；
- UDP怎么保证可靠性？？
  - HTTP3基于UDP协议在应用层实现了QUIC协议，有类似TCP的连接管理、拥塞窗口、流量控制的网络特性，相当于将UDP协议变成可靠的了，无需担心数据包丢失问题

三、应用层

1、DNS
- DNS是什么？怎么实现的？？
  - DNS(DomainNameSystem)属于应用层，将域名转换为IP地址的分布式系统.
  - 首先读取浏览器自身缓存是否有域名对应的IP地址，有👉直接返回IP地址；没有则查操作系统的缓存（hosts文件），没有则👉向本地DNS服务器发送查询请求，分别取根域名服务器→顶级域名服务器→权威域名服务器询问，最后拿着返回的ip交给浏览器
  - 迭代查询和递归查询两种解析方法
  - 通常采用递归查询的方式：一个查询请求--->层层递归查询，等待最终结果，适合普通⽤户和客户端
  - 迭代查询：一个查询请求-->不要求直接提供完整的解析结果，适⽤于DNS服务器之间的通信
2、HTTP
- 一条HTTP协议是通过什么来确定TCP连接的？？QUIC协议呢？
  - 四元组：源目IP、源目端口，有一个改变了TCP连接就不同了
  - 如果移动设备的网络从4G切换未WIFI，IP地址变换了则必须切断连接，重建连接，而建立连接的过程包括TCP三次握手和TLS四次握手，以及TCP慢启动的减速过程，给用户带来网络卡顿的不好体验。因此连接迁移的成本很高
  - QUIC协议没有用四元组的方式绑定连接，而是通过连接ID标记通信的两个端点。当网络设备变换时，即使IP地址变了，只要仍保有上下文信息（如连接id、TLS密钥等），就可以”无缝“复用原来的连接，消除连接的成本，达到连接迁移的功能
- HTTP是什么一款什么协议？？有哪些特点？？
  【超文本、hypertext、flexibility、NOsiuation、askforans、openNOsafe】
  - 超文本传输协议，应用层协议，基于TCP协议，用于在浏览器与服务器之间传输数据
  - 简单、基于文本：HTTP消息是基于文本形式传输，易于阅读与传输
  - 灵活、易于扩展：HTTP支持不同的数据格式，各种请求方法、URI/URL、状态码等组成不是固定死的，允许开发人员自定义和扩充，适用于多种应用场景
  - ⚠️无状态：HTTP每个请求之间是相互独立的，服务器不会保留之前请求的状态信息，减轻服务器的负担，需要通过其他手段，比如Cookies、Session来维护状态
  - 请求-应答模式：使用请求-应答通信模式，请求方先发起连接和请求，是主动的，而应答方只有在收到请求后才能答复，是被动的。
  - 明文传输、不安全：调试工作遍历，信息透明容易被窃取
- HTTP状态码有哪些？？
  - 1开头：目前是协议处理的中间状态，仍需后续处理。如客户端请求服务端从HTTP切换为WebSocket通信时，服务端如果同意切换，会返回101状态码
  - 2开头：成功收到并处理，200=成功响应请求
  - 3开头：服务端的资源发生了变动，需要重定向，如301时代表永久重定向，302临时重定向
  - 4开头：客户端错误，请求报文有误导致服务器无法处理。401Unauthorized请求未授权需要身份验证；404表示请求的资源在服务器不存在或未找到，所以无法提供给客户端
  - 5开头：服务端错误，服务端在处理时内部发生了错误。
    - 502 Bad GateWay：服务器作为网关或代理时返回的错误，表示服务器自身工作征程，访问后端服务器发生了错误
    - 503 Service Unavailable：服务器很忙，暂时无法响应客户端
    - 504 GateWay Timeout：作为网关或代理的服务器未能及时从上游服务器获得响应
- HTTP长连接和短链接的区别？？
  - HTTP的长短连接实际上是指TCP协议的长短连接
  - 短连接：HTTP1.0每次请求都需要建立新的TCP连接，完成请求响应后立即断开连接。这样每次请求都需要建立连接和释放连接，会增加通信开销和延迟
  - 长连接：HTTP1.1提出了长连接。在通信过程中，只要客户端和服务端任一一端没有明确提出断开连接，则多次请求响应可以保持在一个TCP连接状态中，减少连接和释放的开销，提高通信的效率
- HTTP1.0和1.1的区别？？
  - 长连接：HTTTP1.1默认为长连接，1.0为短连接
  - 请求管道化pipeline：HTTP1.0的请求和响应必须是串行的，当一个请求和响应完成后才能发送下一个请求，容易出现请求的队头阻塞；HTTP1.1支持管道传输，支持HTTP请求并发发送，提高HTTP请求的效率。但是响应还是得按顺序响应。
  - HTTP1.1 解决了HTTP1.0的短连接问题、请求的队头阻塞问题。未解决响应的队头阻塞问题
- HTTP1.1和HTTP2.0？？
  - 请求和响应多路复用并发传输：HTTP1.1请求可以并发，但是响应还得是顺序响应；HTTP2.0引入stream的概念，不同的HTTP请求和响应用不同的stream id来区分，stream帧可以乱序发送，多个stream复用一条TCP连接，只要一条连接就可以达到并发传输和响应的效果，提高HTTP传输吞吐量
    - 还可以根据资源的渲染顺序来设置Stream的优先级，提高用户体验
  - 头部压缩+二进制：HAPACK算法压缩HTTP头部，避免多次发送冗余消息造成带宽浪费，将HTTP.1.1纯文本格式改成二进制，提高数据传输的效率
  - 基于HTTPS具有安全性：比1.1还多了TLS四次握手
  - 服务器主动推送资源：客户端的一个请求，服务端可以发送多个响应，不再被动
- 那HTTP2.0解决了队头阻塞问题吗？？
  - 并没有。问题是在TCP传输层出现的。
  - HTTP/2 是基于 TCP 协议来传输数据的，TCP 是字节流协议，TCP 层必须保证收到的字节数据是完整且连续的，这样内核才会将缓冲区⾥的数据返回给 HTTP 应⽤，
  - 那么当「前 1 个字节数据」没有到达时，后收到的字节数据只能存放在内核缓冲区⾥，只有等到这 1 个字节数据到达时，HTTP/2 应⽤层才能从内核中拿到数据，这就是 HTTP/2队头阻塞问题。
  - 怎么办？HTTP3直接把TCP放弃转而用UDP作为传输层协议来解决队头阻塞问题了
- HTTP3.0了解吗？做了哪些升级？？
  - HTTP3基于QUIC协议+UDP
  - 1、无队头阻塞：QUIC用UDP协议来传输数据。一个连接上的多个stream之间没有依赖，如果一个stream丢了一个UDP包，不影响后续的stream，不存在TCP队头阻塞
  - 2、丝滑连接迁移：QUIC协议没有用四元组的方式绑定连接，而是通过连接ID标记通信的两个端点。当网络设备变换时，即使IP地址变了，只要仍保有上下文信息（如连接id、TLS密钥等），就可以”无缝“复用原来的连接，消除连接的成本，达到连接迁移的功能
  - 3、QPACK：有QPACK Encoder/Decoder Stream单向流，用来同步双方的动态表
- HTTP报文格式具体是什么样的？？
  - HTTP请求报文：请求行、请求头、请求体
    - 请求行：请求方法POST/GET、URL、协议版本号
    - 请求头：key-value形式告知服务端详细的请求信息，常见的HTTP请求头部字段有Host、User-Agent、Content-Type、Authorization
    - 请求体：实际传输的数据，如文本、图片，在POST、PUT等请求时包含请求的实际数据
  - HTTP响应报文：状态行、响应头、响应体
    - 状态行 HTTP/1.1 200 OK 版本协议、状态码、状态信息简单描述
    - 响应头部：key-value形式，Content-typeContent-length、Cookie、Server
    - 响应体：返回给客户端的实际数据。如HTML内容
- HTTP其中请求体和响应体中有常见字段有哪些？？
  - 信息类：Host指定服务器主机和端口号、User-Agent标识客户端的用户代理
  - 内容协商类：描述客户端期望的响应Content-Type字段标识数据格式、Content-Length字段服务器返回的数据长度、Content-Encoding返回数据的压缩形式
  - 鉴权类：携带认证信息的字段Authorization用于身份验证的凭证、Set-Cookie客户端的信息
  - 连接类：Connection字段keep-alive用于客户端要求服务器使用HTTP长连接，避免多次握手的开销
- 输入域名如何知道端口号？？
  - 如果URL中没有显式指定端口号，浏览器会根据URL的协议类型，使用默认端口进行连接。HTTP：// -80 HTTPS-443
  - 如果显式指定端口号，则用该端口号连接，如8080
  - DNS只负责解析域名对应IP地址，端口号从URL协议或显式指定来决定
- GET和POST请求的区别什么？？
  - GET和POST都是HTTP请求方法，本质无区别GET/POST实际上都是TCP链接
  - 由于HTTP的规定以及浏览器/服务器的限制，导致它们在应⽤过程中可能会有所不同
  - 资源请求：GET是获取资源，不对服务器产⽣影响；POST客户端向服务器提交数据，会影响服务器
  - 参数传递：GET请求的参数⼀般写在URL中；POST请求参数⼀般放在请求体中
  - 幂等性：GET为安全幂等的，因为它为只读操作；POST 因为是「新增或提交数据」的操作
  - 缓存机制：GET 请求会被浏览器主动cache；POST 不会，除⾮⼿动设置
  - 时间消耗：GET 产⽣⼀个 TCP 数据包服务器响应 200（返回数据）；POST 产⽣两个 TCP 数据包。先响应100再响应200。
3、HTTPS
- HTTPS和HTTP有什么区别？？
  - 1、安全性：
  - HTTP 是超⽂本传输协议，信息是明⽂传输，存在安全⻛险的问题。
  - HTTPS 则解决 HTTP 不安全的缺陷，在TCP 和 HTTP ⽹络层之间加⼊了 SSL/TLS 安全协议，使得报⽂能够加密传输。
  - 2、连接建立：
  - TCP 三次握⼿之后便可进⾏ HTTP 的报⽂传输；
  - HTTPS 在 TCP 三次握⼿之后，还需进⾏ SSL/TLS 的握⼿过程，才可进⼊加密报⽂传输
  - 3、端口号：
  - HTTP 默认端⼝号是 80，HTTPS 默认端⼝号是 443。
  - 4、数字证书：
  - HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。
  - 总结来说：HTTPS通过信息加密-（混合加密）、身份检验（数字证书）、消息完整性来源可靠性（摘要算法+数字签名）校验的实现来解决HTTP存在的消息窃听、篡改、劫持的风险
- 你了解哪些加密算法？？
  - 【对称加密-非对称加密-哈希算法】
  - 1、对称加密：
  - 对称加密也称为私钥加密，使⽤相同的密钥来进⾏加密和解密。速度通常较快，适合加密大量数据，但是一旦密钥泄漏，攻击者可以轻易地解密数据。
  - 2、非对称加密：
  - ⾮对称加密也称为公钥加密私钥解密（反之也可以），使⽤⼀对不同但相关的密钥：公钥和私钥。
  - 除了加密和解密【密钥交换】，⾮对称加密还⽤于【数字签名】，可以验证消息的来源和完整性。
  - 3、哈希算法
  - 单向算法，通过算法加密，如MD5，加密过程是不可逆的
  - 从密钥的角度来看，对称加密的关键在于密钥的保密，一旦泄露，加密的数据就不安全了。而非对称加密则是公钥公开，私钥保密，通过这种方式实现了更安全的通信。
- 详细描述一些HTTPS建立连接的过程？？TLS/SSL握手？？加密机制？？
  - 阶段一：建立TCP连接，客户端和服务端三次握手，略
  - 阶段二：TCP连接后，TLS/SSL四次握手（HTTP3.0的TLS1.3优化为三次握手）
  - 1、第一次握手：客户端发送ClientHello，包括支持的TLS版本、密码套件列表和客户端随机数
  - 此间：服务端产⽣⼀对公私钥，然后将⾃⼰的公钥发送给CA机构，CA机构也有⼀对公私钥，然后CA机构使⽤⾃⼰的私钥将服务端发送过来的公钥进⾏加密，产⽣⼀个CA数字证书。（CA数字证书=服务端公钥+CA数字签名）
  - 2、第二次握手：服务端响应Server Hello消息，确认TLS版本，选择一个密码套件，并发送一个服务器随机数。紧接着Server Certificate：发送CA机构颁发的数字证书，Server Hello Done。
  - 此间：客户端检验CA数字证书的合法性，若合法，取出服务器的公钥
  - 3、第三次握手：客户端验证合法性后，随机生成对话密钥（就是对称密钥，用于后续加密传输），用公钥加密，通过Client Key Exchange消息发送给服务器
  - 4、第四次握手：实际包含两个步骤，是客户端和服务端分别通知对方用协商好的加密方式进行通信，并且通过摘要算法+数字签名来验证消息的完整性和可靠性
  - 数字签名=私钥加密的消息哈希值，消息哈希值=摘要算法（哈希算法）对消息计算的值
- Cookie、Session、Token三种技术的区别你知道嘛？讲讲它们分别适用于什么场景？？
  - 这些都是用于用户身份验证和状态管理的技术
  - Cookie 通过在客户端记录信息确定⽤户身份，简单状态管理，不支持跨域（传输时放在Set-Cookie请求头）【存不敏感的用户偏好信息】
    
    服务器可以通过 HTTP 响应的头部信息中的 "Set-Cookie" 标头来创建⼀个 Cookie。
  - Session 通过在服务器端记录信息确定⽤户身份，依赖Cookie或URL重写传递SessionID会话标识符，跨域支持有限（用于维护⽤户登录状态、存储⽤户的临时数据和上下⽂信息）【适用传统的web应用】
    
    SessionID通常以Cookie的形式存储在用户的浏览器中，在服务器中有对应的存储空间
  - Token也存在客户端，通常会进行加密存储，支持跨域请求【常用于需要支持跨域或实现无状态服务的场景】
- 了解跨域问题吗？什么情况下会发生跨域请求？？
  - 【同源策略限制、源的定义；响应头信息，Nginx反向代理】
  - 同源策略：同源策略是一种安全机制，它要求协议、域名和端口号都必须一致，才能进行资源共享。限制一个网页中的脚本只能访问与该网页同源的资源，不能直接访问其他域下的资源
  - 跨域问题是指浏览器出于安全考虑，阻止网页/脚本向不同源的服务器发起请求。当一个请求的协议、域名或端口与当前页面不一致时，就会发生跨域问题。
  - 后果：数据隔离、安全风险、用户体验不佳
  - 解决方案：CORS跨域资源共享——通用设置响应头中的字段Access-Control-Allow-Origin告知浏览器允许特定源的请求。CORS 支持多种请求方法和请求头，是一种较为灵活和强大的跨域解决方案

四、其他协议

1、CDN
- 了解CDN吗？？它的工作流程是怎么样的？？
  - 内容分发⽹络（Content Delivery Network） ,将内容存储在分布式的服务器上，使⽤户可以从距离较近的服务器获取所需的内容，从⽽减少数据传输的时间和距离，提⾼内容的传输速度、减少延迟和提升⽤户体验。
  - 浏览器若启用了CDN，DNS 解析会返回距离⽤户最近的 CDN 节点的 IP 地址，⽽不是原始源服务器的 IP 地址。
  - 节点选择机制：【用户IP地址、网络状况、节点负载】⽤户的请求会被路由到距离最近的 CDN 节点，并且CDN 节点可以根据服务器的负载和可⽤性，动态地将请求分发到最适合的服务器节点上。
  - 静态资源缓存：CDN 节点会缓存静态资源，如图⽚、样式表、脚本等。当⽤户请求访问这些资源时，CDN 可以直接从缓存中返回，避免了从源服务器获取资源的延迟。
2、WebSocket
- 讲讲什么是websocket？？和http的区别是什么？？
  - WebSocket是一种基于TCP连接的全双工通信协议，客户端和服务器可以同时发送和接受数据。属于应用层的协议，用于弥补HTTP协议在持久通信能力上的不足。两端只需要一次握手，就可以创建持久化的连接，进行双向通信，适用于对于实时性要求高的场景
3、IP与MAC
- 解释一下什么是IP地址？？
  - 【网络层】
  - IP 地址是互联网协议（IP）中用来唯一标识和定位网络中设备的一种地址。它就像我们现实生活中的门牌号码，确保数据包能够准确地送到目的地。目前主要有两种类型的 IP 地址：IPv4 和 IPv6。
  - IPv4 地址是 32 位二进制的，通常用点分十进制表示，例如 10.100.122.1。而为了解决 IPv4 地址不够用的问题，出现了 128 位的 IPv6 地址，它采用冒号分隔的十六进制数表示。在 TCP/IP 协议中，IP 地址通常会和MAC 地址结合使用，共同完成设备之间的通信和数据传输。
- 什么是子网掩码？子网掩码与IP地址是什么关系？？
  - 通过子网掩码，我们可以将 IP 地址划分为网络号和主机号两部分。网络号用于标识网络，主机号用于标识网络中的主机。这种划分使得 IP 地址可以被有效地组织和管理。
  - IP地址10.100.122.2/24中/24 表示子网掩码的前 24 位是 1，后 8 位是 0。在点分十进制格式中，这相当于得到子网掩码为 255.255.255.0。
  - 将IP 地址和子网掩码转换为二进制后进行与&运算，得到网络号。
  - 将 IP 地址和子网掩码的反码进行按位与（AND）操作，结果是主机号。
- 什么是MAC地址？？
  - 【数据链路层】
  - MAC地址也称为物理地址或硬件地址，是在数据链路层中使用的，用于唯一标识网络设备。
  - 每个网络接口卡（网卡）在出厂时都会被分配一个全球唯一的 MAC 地址，它通常是一个 48 位的二进制数，为了方便阅读和表示，通常会写成用冒号或短横线分隔的六组十六进制数，例如 00:1A:2B:3C:4D:5E。MAC 地址是固化在硬件中的，不会因为设备连接到不同的网络而改变。它的主要作用是在局域网内部进行数据传输时，帮助网络设备识别和寻址目标设备。
- 4、NAT协议