介绍一下经典网络分层

网络分层的话分成两种,一种是TCP/IP五层协议,一种是OSI七层协议

五层协议自底向上分为物理层, 链路层, 网络层, 传输层, 应用层

而七层协议在五层协议的基础上,将应用层细分为了会话层,表示层和应用层

哪些层有哪些协议

传输层中有TCP协议和UDP协议

应用层中HTTP协议, FTP协议, SMTP协议, GRPC

介绍TCP和UDP

TCP和UDP是两种常见的传输层协议,其中：

TCP是面向连接的, 可靠的, 面向字节流的, 他可以保证数据的可靠传输,所以他可以用于文件的上传和下载,发送HTTP请求等

UDP是无连接的,不可靠的,面向报文的,他传输速度比较快但不能保证数据的完整性,所以可以用于视频音频的传输,实时游戏等

TCP怎么做连接管理

通过三次握手建立连接, 1. 同步请求 (SYN), 2. 同步确认 (SYN-ACK), 3. 确认 (ACK)

通过四次挥手断开连接, 1. 终止请求 (FIN), 2. 确认终止 (ACK), 3. 反向终止请求 (FIN), 4. 反向终止确认 (ACK)

介绍一下三次握手机制

第一步: 客户端发送SYN包给服务器, 这个包包含了客户端的初始序列号以及请求建立连接的标志位(seq码)

第二步: 服务器接收到SYN包后, 会发送一个SYN-ACK包给客户端, 这个包包含了服务器的初始序列号以及对客户端的请求建立连接的确认

第三步: 客户端接收到SYN-ACK包之后, 会发送一个ACK确认包给服务器, 确认服务器的请求建立连接

为什么偏偏要三次(反证法)

因为两次的话，无法防止历史连接的建立,会造成双方资源的浪费，也无法可靠的同步双方序列号

而四次的话又太多余, 第三次握手之后客户端和服务器已经确认了彼此的连接, 无需再重复确认

三次握手中双方的状态

TCP三次握手.webp

第三次可以带数据吗

根据TCP协议规定，第三次不能携带数据，因为不管第三次有没有携带数据得到的结果都是一样的，但在实际应用过程中，可以携带数据，属于是一种优化

介绍一下四次挥手机制

第一步: 客户端想要关闭连接时, 会发送一个FIN包给服务器

第二步: 服务器接收到FIN包后, 发送一个ACK包给客户端, 确认收到了客户端的关闭请求(此时服务器进入close_wait状态，处理未处理完的数据)

第三步: 服务器发送一个FIN包给客户端, 表示服务也准备关闭连接

第四步: 客户端收到FIN包之后,发送一个ACK包给服务器, 确认收到了服务器的关闭请求, 连接关闭

四次挥手后客户端会直接关闭连接吗

（四次挥手后客户端并不会直接断开连接，而是等2MSL的时间，若依然没有回复再关闭连接）

MSL：报文段最大生存时间，它是任何报文段被丢弃前在网络内的最长时间。

为什么要等待2MSL？

  • 第一点：保证TCP协议的全双工连接能够可靠关闭： 由于IP协议的不可靠性或者是其它网络原因，导致了Server端没有收到Client端的ACK报文，那么Server端就会在超时之后重新发送FIN，如果此时Client端的连接已经关闭处于CLOESD状态，那么重发的FIN就找不到对应的连接了，从而导致连接错乱，所以，Client端发送完最后的ACK不能直接进入CLOSED状态，而要保持TIME_WAIT，当再次收到FIN的收，能够保证对方收到ACK，最后正确关闭连接。

  • 第二点：保证这次连接的重复数据段从网络中消失 如果Client端发送最后的ACK直接进入CLOSED状态，然后又再向Server端发起一个新连接，这时不能保证新连接的与刚关闭的连接的端口号是不同的，也就是新连接和老连接的端口号可能一样了，那么就可能出现问题：如果前一次的连接某些数据滞留在网络中，这些延迟数据在建立新连接后到达Client端，由于新老连接的端口号和IP都一样，TCP协议就认为延迟数据是属于新连接的，新连接就会接收到脏数据，这样就会导致数据包混乱。所以TCP连接需要在TIME_WAIT状态等待2倍MSL，才能保证本次连接的所有数据在网络中消失。

四次挥手中双方的状态

TCP四次挥手.webp

TCP怎么保证可靠的

通过使用确认和重传机制保证数据完整且有序的送到目的地

TCP有什么重传机制

  1. 超时重传: 当发送端发送数据后, 会启动一个计时, 如果在计时器到期之前没有收到对应的确认应答, TCP认为数据包可能丢失, 就会重传该数据包
  2. 快速重传: 如果接收端收到乱序的数据包，它会发送重复的ACK，这些ACK都指向同一个未收到的数据包的序列号。当发送端接收到对于同一个数据包的三个或更多的重复ACK时，无需等待超时，TCP将立即重传那个疑似丢失的数据包
  3. SACK: SACK允许接收端告诉发送端哪些数据包已经收到，哪些数据包丢失。
  4. DSACK: DSACK让接收端能够通知发送端它接收到的重复数据段，帮助发送端更好地理解网络状况和优化重传策略。

TCP咋实现快速重传

接收端发送三个或更多的重复ACK。这意味着接收端在没有收到期望的数据段时，会针对同一个未收到的数据段连续发送多个ACK。当发送端接收到三个重复ACK，它就意识到有数据包可能丢失，并在定时器过期之前立即执行快速重传

优点是:解决了超时重传的等待问题

缺点：但是不能确定重传多少

TCP的流量控制机制

TCP（Transmission Control Protocol）的流量控制机制主要是通过滑动窗口（Sliding Window）来实现的，目的是确保发送方的数据发送速率不超过接收方的处理能力，从而避免数据拥塞和丢失，保证数据传输的高效性和可靠性。以下是流量控制机制的具体工作原理：

  1. 滑动窗口概念：
    • 发送方和接收方各自维护一个窗口，发送方的窗口限定它可以连续发送的数据量，而这个窗口的大小是根据接收方的接收能力和当前网络状况动态调整的。
    • 接收方会通过TCP报文段中的窗口大小字段（Window Size）告诉发送方其接收缓冲区当前还能接收多少数据，这个值就是接收窗口的大小。
  2. 过程描述：
    • 初始时，接收方发送一个SYN报文给发送方，其中包含接收窗口的初始大小。
    • 发送方在接收到接收方的窗口大小后，开始按照这个窗口大小发送数据。
    • 随着数据的传输，接收方在缓冲区接收到数据后，会向上游发送确认（ACK）报文，这个ACK报文中会包含最新的窗口大小信息。如果接收方处理数据的速度赶不上接收速度，它会减小窗口大小；反之，则可能增大窗口大小。
    • 发送方根据接收到的ACK报文中的窗口大小调整自己的发送速率，确保不会溢出接收方的缓冲区。
    • 发送方有一个单独的变量记录下一个待发送数据的序列号，这个序列号与接收方的窗口前沿相对应，形成了一个可变动的、允许发送的数据范围，即发送窗口。
  3. 流量控制与拥塞控制的区分：
    • 虽然流量控制和拥塞控制都是为了提高网络传输效率和可靠性，但它们关注的层面不同。流量控制关注点在于端到端的通信，确保数据发送不超过接收方的处理能力；而拥塞控制则关注整个网络，避免过多的数据注入网络导致网络拥塞。

TCP的拥塞控制机制

TCP的拥塞控制机制用于维护网络的稳定性与公平性，以避免网络拥塞的发生，拥塞控制机制主要包括四个算法:慢启动、拥塞避免、快速重传、快速恢复。

  1. 慢启动（Slow Start）：在建立TCP连接或网络拥塞恢复时，发送方将初始拥塞窗口设置为一个较小的值，并随着时间的推移逐渐增加拥塞窗口的大小，以逐渐增加发送的数据量。
  2. 拥塞避免（Congestion Avoidance）：一旦慢启动阶段结束，发送方进入拥塞避免阶段。在拥塞避免阶段，发送方通过线性增加拥塞窗口的大小，但以较慢的速率增加，以避免对网络造成过大的负载。
  3. 快速重传（Fast Retransmit）：当发送方检测到丢失的数据报段时，它不会等待超时重传定时器的触发，而是立即进行重传。这样可以更快地恢复丢失的数据报段，减少等待时间。
  4. 快速恢复（Fast Recovery）：当发送方接收到重复的确认报文时，它会将拥塞窗口减半，并进入快速恢复状态。在快速恢复状态下，发送方会继续线性增加拥塞窗口的大小，而不是回到慢启动阶段。

UDP实现可靠的办法

  1. 应用层确认机制

    • 客户端发送数据后会设置一个超时时间,等待服务端的确认消息。
    • 如果超时还没收到确认,客户端就会重新发送数据。
    • 服务端收到数据后会立即发送确认消息回给客户端。
    • 这种方式可以保证数据能够成功送达,但会增加一些延迟和开销。

  2. 序列号与重复检查

    • 在每个UDP数据报中加入序列号字段。
    • 接收端会检查收到的数据报的序列号,跳过重复的数据报。
    • 这样可以确保数据的完整性和顺序性。
    • 如果数据报丢失,接收端可以根据序列号识别出并请求重传。

  3. 校验和机制

    • UDP本身就有校验和字段,用来检测数据在传输过程中是否发生错误。
    • 接收端计算收到数据的校验和,与数据报中的校验和进行比对。
    • 如果不一致,说明数据在传输过程中出现了错误,接收端可以丢弃该数据报。

  4. 流量控制

    • 实现类似TCP的滑动窗口机制,控制发送方的发送速率,避免网络拥塞。
    • 接收端会根据自身的缓存状况,反馈给发送端当前的窗口大小,让发送端适当调整发送速率。

  5. 多路径传输

    • 同时通过多个UDP连接传输相同的数据。
    • 接收端会等待所有副本数据都到达后,再进行数据合并和校验。
    • 这样即使个别数据报丢失,也能通过其他路径的副本进行补偿。

SYN超时和洪泛攻击是什么?怎么解决

SYN超时: 在三次握手中, 当服务器接收到客户端发送的SYN包后, 会发送SYN-ACK包作为相应, 但是客户端在一定时间内未收到服务器响 应时,就会认为建立连接失败,这个时间就叫SYN超时

解决策略: 增加SYN超时时间 优化网络连接 提高服务器性能

洪泛攻击: 攻击者发送大量的伪造IP地址的SYN请求包给目标服务器, 目的是耗尽服务器的资源. 而服务器接收到这些请求后要为每一个请 求分配资源并等待确认,使得服务器资源被大量占用,无法正常服务其他正常请求

解决策略: 使用防火墙 使用SYN Cookie IP过滤和限制 使用负载均衡 提高服务器性能

​

浏览器输入URL之后,网络世界发生了什么变化

首先浏览器解析URL,用DNS服务确定Web服务器和文件名

接着根据上面的信息生成HTTP请求消息

在发送消息之前,先使用DNS服务器查询服务器域名对应的IP地址(若浏览器缓存有域名的缓存,则不用去问DNS)

经过应用层和传输层(在头部添加TCP/UDP首部)

经过网络层,添加了报文头(包含原地址IP和目的地址IP)

数据链路层添加MAC头部,它包含了接收方和发送方的MAC地址等信息,用于两点之间的传输(使用ARP协议,在以太网以广播的形式找出接收方MAC地址)

网卡:将二进制数字转换成电信号,在网线上传输(开头加报文和起始帧分界符,在末尾加上用于检测错误的帧校验序列)

交换机:交换机里的模块将电信号转换成数字信号,然后通过包末尾的FCS校验错误,如果没问题则放到缓冲区,接下来需要查询一下这个包的接收方MAC地址是否已经在MAC地址表中有记录了,交换机根据MAC地址表查询MAC地址,然后将信号发送到相应的端口(若找不到则将包发送到其他除了源端口的所有端口)

路由器:当转发包时,首先路由器会接收到发送给自己的以太网包,然后查路由表找转发目标,再由相应的端口作为发送方将以太网包发送出去,首先电信号到达网线接口部分,路由器中的模块会将电信号转化为数字信号,然后通过包末尾的FCS进行错误校验. 没问题则MAC头部中的接收方MAC地址, 看看是不是发给自己的包,如果是就放到接收缓冲区中,否则丢弃包.完成包接收操作之后,路由器就会去掉包开头的MAC头部,路由器会根据MAC头部后方的IP头部中的内容进行转发操作

数据抵达服务器,倒着再来一遍

介绍一下DNS服务

当用户在浏览器中输入一个域名并请求访问时，首先会查询本地计算机的DNS缓存，看是否有该域名的IP地址记录。

如果本地缓存没有记录或者记录已过期，则请求会被发送至本地DNS服务器（通常是ISP提供的或网络管理员配置的）。

本地DNS服务器若未缓存相关记录，则会向根域名服务器发起递归查询请求。

根域名服务器会指引本地DNS服务器去询问相应的顶级域服务器（如.com服务器）。

顶级域服务器会指向正确的权威域名服务器，即存储该域名实际IP地址记录的服务器。

权威域名服务器返回域名对应的IP地址给本地DNS服务器。

本地DNS服务器将获取到的IP地址返回给用户的计算机。

用户的计算机最终利用得到的IP地址建立与目标服务器的连接，从而加载网页或其他在线资源

DNS劫持

DNS劫持（DNS Hijacking 或 Domain Name System Hijacking）是一种网络安全攻击，指的是攻击者未经授权非法更改DNS名称服务器上的域名记录，将原本合法的域名解析指向了错误的IP地址。当用户的计算机试图访问被劫持域名下的网站时，实际上会被重定向到攻击者所控制的服务器上。DNS劫持常用于钓鱼诈骗、广告插入、数据窃取等恶意目的，影响用户隐私和网络安全，也会导致用户无法正常访问原网站。

Http1、Http2、Http3的区别

HTTP/1、HTTP/2、和HTTP/3是超文本传输协议（HTTP）的三个不同版本，每个版本都在前一代的基础上进行了改进，以提升网页加载速度、降低延迟并增强安全性。下面是它们之间的一些关键区别：

HTTP/1.x (主要指HTTP/1.1)

  • 文本协议：HTTP/1.x使用文本格式传输数据。
  • 串行处理：请求和响应必须按照顺序处理，这意味着如果一个请求阻塞（如大文件下载），后续请求必须等待。
  • 连接管理：为了解决每次请求都要建立连接的问题，HTTP/1.1引入了Keep-Alive头部，允许复用TCP连接，但仍然存在队头阻塞问题。
  • 无状态性：服务器不会在不同请求间保留状态信息，除非使用Cookie。
  • 安全性：默认情况下不加密，但可以通过与TLS/SSL结合形成HTTPS来提供安全性。

HTTP/2

  • 二进制协议：HTTP/2使用二进制格式，更高效地解析和传输数据。
  • 多路复用：在一个TCP连接上同时处理多个请求和响应，减少了延迟和带宽消耗，有效缓解了队头阻塞问题。
  • 头部压缩：通过HPACK算法压缩请求和响应头，降低了不必要的网络流量。
  • 服务器推送：服务器可以在客户端请求之前主动推送资源。
  • 优先级分配：允许客户端指定资源请求的优先级，优化资源加载顺序。

HTTP/3

  • 基于QUIC：HTTP/3建立在QUIC传输协议之上，而不是TCP，QUIC本身是基于UDP的。
  • 解决队头阻塞：由于QUIC是多路复用的，且每个请求都有独立的流，所以完全消除了队头阻塞问题。
  • 0-RTT连接：QUIC支持0往返时间（0-RTT）连接重用，可以更快地恢复之前的连接状态，提高页面加载速度。
  • 加密：QUIC强制使用TLS进行加密，确保了安全性，且加密握手过程更为高效。
  • 更好的拥塞控制和错误恢复：QUIC内置了更好的拥塞控制和丢包恢复机制，更适合于移动和不可靠网络环境。

总的来说，从HTTP/1.x到HTTP/2再到HTTP/3，协议的进化主要是为了提升网络效率、减少延迟并增强安全性，特别是在现代互联网的高要求下，这些改进对于提供流畅的用户体验至关重要。

TCP是如何解决粘包问题的？

TCP的粘包问题是由于TCP协议的特性导致的，它可能会将连续发送的数据包合并成一个大的数据块，或者将一个大的数据块拆分成多个小的数据包进行传输，接收方收到这些数据包时有可能无法区分数据包的边界，从而导致解析错误。

解决方法：一般通过固定消息的长度、用特殊字符作为边界、使用自定义消息结构三种方式来进行分包。

  1. 固定长度消息：发送方在每个消息的前面添加固定长度的消息头，用于表示该消息的长度。接收方在接收数据时，先读取消息头的长度信息，然后根据长度信息读取相应长度的数据，以确保每个消息被正确解析。
  2. 特殊字符分隔：发送方在消息的末尾添加一个特殊的分隔符，例如换行符或特定字符，作为消息的结束标志。接收方根据分隔符来切分接收到的数据，将其分解为单独的消息进行处理。
  3. 使用自定义消息结构：在应用层上设计自定义的协议，利用应用层协议中的消息分割规则来解决粘包问题，例如使用XML、JSON等结构化数据格式，通过标签或特定字段来分割消息。