八股总结----计算机网络

devtools/2024/9/24 20:01:00/

0.OSI七层模型

自己的理解:应用层:生成HTTP请求报文-----表示层:将请求报文转换成适合网络传输的数据格式,加密压缩编码等-----会话层:管理两个应用程序之间的会话,包括连接中断等------传输层:实现端到端通信(主机到主机),但它的职责不仅仅是主机到主机之间的通信,还需要确保数据能够被正确的应用程序接收。所以将数据分成更小的数据段(

  • 适应MTU限制:分段可以确保数据能够在网络中传输,而不会因为过大而被拒绝传输。
  • 提高可靠性:分段减少了重传的开销,提高了错误处理的效率。
  • 流量与拥塞控制:分段有助于动态调整传输速度,避免网络拥塞。
  • 网络兼容性:分段提高了数据在不同类型网络中的传输兼容性。)

,并分别加上端口号,以使其到达正确的应用程序------网络层:给数据段加上网络IP地址,并且选择最佳路由------数据链路层:可靠传输、差错检测、封装成帧-----物理层:将数据转换成适合在网线中传输的电信号。

另外,数据链路层也会和传输层一样进行校验、流量控制,但是针对的对象、作用是不一样的。传输层实现的是端到端的通信,数据链路层实现的则是点对点的通信。点对点一般指设备相连,是局部的,而端到端则可能是跨越了全局网络,中间会经历多次路由器和交换机。

另外,物理层是用什么传输介质、什么物理接口、什么信号表示0和1,解决了两台计算机可以通过信号来传输比特0或1。数据链路层是如何标识MAC地址,如何从比特流中区分地址、数据,如何协调主机争用主线,实现了分组在一个网络上传输。网络层如何标识IP地址,如何路由选择,解决了在多个网络上传输的问题。传输层确定哪个进程通信,解决传输错误问题。应用层制定网络协议,编写网络应用,来实现特定的网络功能。

通过IP地址确定目标主机所在的局域网,然后通过ARP协议把IP地址对应的MAC地址找到,然后在同一片网络中找到目标主机。IP地址的前三个数标识网络,后一个数标识主机。

OSI七层模型的功能概述

  1. 物理层:负责物理设备之间的原始比特流的传输,包括电缆、网卡等硬件。它定义了接口类型、电压、电流等物理特性。

  2. 数据链路层:负责节点之间的可靠传输,包括错误检测与纠正、帧的创建与识别、流量控制等。数据链路层将数据封装成帧并通过物理层传输。

  3. 网络层:负责数据包的路由与转发,决定数据如何从源节点到达目标节点。典型的协议如IP(Internet Protocol)。

  4. 传输层:提供端到端的通信服务,确保数据的完整性和可靠性。主要协议包括TCP(传输控制协议)和UDP(用户数据报协议)。

  5. 会话层:管理会话,建立、维持和终止通信会话,确保数据交换的有序性。

  6. 表示层:处理数据格式的转换,确保发送端和接收端能够理解数据的格式。它涉及数据的加密解密、压缩解压等。

  7. 应用层:直接为用户或应用程序提供网络服务,如电子邮件、文件传输等。应用层是用户与网络的接口。

通过例子说明七层模型的作用

假设你在计算机上使用浏览器访问一个网站(比如打开一个网页),从输入网址到网页显示在屏幕上的过程,可以说明OSI模型各层的作用:

  1. 应用层:你在浏览器中输入网址并点击“回车”,浏览器(作为应用层)生成一个HTTP请求,这个请求包含你想要访问的网页地址。

  2. 表示层:在发送HTTP请求之前,表示层负责将请求数据转换为可以被网络传输的格式,可能还会进行数据的压缩和加密。

  3. 会话层:表示层之后,会话层建立一个通信会话,这个会话保证请求和响应之间的数据交换有序且同步。

  4. 传输层:会话层之后,传输层将数据分成更小的数据段(如TCP段),并为每个数据段加上端口号,以确保数据能够传输到正确的应用程序。

  5. 网络层:传输层之后,网络层根据目标网址的IP地址(通过DNS解析获取)为每个数据段加上源和目标IP地址,并选择最优路径将数据段发送到目标服务器。

  6. 数据链路层:网络层之后,数据链路层将数据段封装成帧,并通过物理介质(如网线)传输。数据链路层还负责检测和纠正物理层传输中可能出现的错误。

  7. 物理层:最终,物理层将数据帧转化为电信号,通过网络电缆或无线信号发送到目标服务器的物理设备。

目标服务器接收到这些信号后,会逆向处理这些层,从物理层到应用层,将最终的HTTP响应发送回你的浏览器,浏览器再将网页显示在屏幕上。

1.UDP头部格式

UDP的头部比较简单,只有8个字节,这也是为什么UDP不能像TCP那样实现可靠传输的原因。源端口和目标端口表示数据传输的来源和去向,包长度表示数据报文的总长度(包含了头部和数据部分),方便接收方正确地处理数据。检验和则是用于验证UDP数据报在传输过程中是否发生了错误。它帮助确保数据的完整性。

2.TCP头部格式

TCP的头部一般是20个字节,复杂的头部决定了它的可靠传输。校验和保证了数据的完整性和错误检测;序列号进行了数据的顺序控制;ACK实现了重传机制,确认和重传;滑动窗口进行流量控制;拥塞控制;三次挥手和四次握手进行连接管理。

序列号解决网络乱序问题,确认应答号解决丢包问题,窗口大小用来进行流量控制,控制位(ACK确认和重传、FIN断开连接、SYN请求连接)。

3.IP地址

IPV4地址,四位,主机号全为0的是网络地址,全为1的是广播地址。A类,第一位范围1-126,127是本地环回测试地址。后三位范围是1-2^24-1,全1表示广播地址。

网络号是IP地址中的一部分,用于标识某个特定的网络。相同网络号的设备处于同一网络中。主机号是IP地址中的另一部分,用于标识网络内的具体设备(主机)。网络地址是指IP地址中主机号部分全为0的地址,它标识的是整个网络,而不是网络中的具体设备。广播地址是指IP地址中主机号部分全为1的地址,用于向网络中的所有设备发送信息。

4.流量控制

滑动窗口机制中的流量控制主要依赖接收方的接收窗口大小来调节数据传输速率。

  1. 接收窗口大小的动态调整

    • 接收方在接收到数据包后,会根据当前缓冲区的可用空间和处理能力来决定是否调整接收窗口的大小。如果接收方的缓冲区空间充足且处理能力良好,它可能会增大接收窗口的大小,允许发送方发送更多的数据包。反之,如果接收方的缓冲区接近满载,它会缩小接收窗口,以减缓发送方的数据传输速度。
  2. 通过ACK通知窗口大小的变化

    • 每当接收方收到数据包并处理完毕后,它会发送一个ACK(Acknowledgment,确认)消息回给发送方。这个ACK消息不仅确认了已成功接收的数据包,还携带了一个重要的字段:接收窗口大小(Receive Window Size)
    • 这个字段明确告知发送方,接收方当前还能接收的数据量是多少。比如,如果接收窗口大小是500字节,发送方就知道它最多还能发送500字节的数据而不必等待进一步的ACK。
    • 如果接收方的缓冲区快要满了,它会在ACK消息中报告一个较小的接收窗口大小,通知发送方降低数据传输速率,避免缓冲区溢出。

5.拥塞控制

慢开始、拥塞避免、快重传、快恢复。

TCP发送方一开始使用慢开始算法,让拥塞窗口值从1开始按指数规律增大,当拥塞窗口值增大到慢开始门限值时,执行拥塞避免算法,让拥塞窗口值按线性加1的规律增大,当发生超时重传时,就判断网络很可能出现了拥塞,这时将慢开始门限值更新为发生拥塞时拥塞窗口值的一半,并将拥塞窗口值减少为1,并重新执行慢开始算法,拥塞窗口值又从1开始按指数规律增大,当增大到了新的慢开始门限值时,停止使用慢开始算法,执行拥塞避免算法。

后来又加入了快重传和快恢复,快重传是指收到三个重复确认。快恢复是指快重传之后门限值更新发生拥塞时拥塞窗口值的一半,并将拥塞窗口值也更新为发生拥塞时拥塞窗口值的一半,而不是更新为1。

6.三次握手

第一次握手发送端向接收端发送请求连接SYN,接收端收到,并且得知发送端具有发送能力。第二次握手接收端向发送端发送确认连接ACK,发送端得知接收端具有接受能力,并且向发送端发送请求连接,发送端收到,得知接收端具有发送能力。第三次握手,发送端向接收端发送确认连接,接收端得知发送端具有接收能力。这样一来,两端都知道对方具有发送和接收能力,两端建立连接可以正常的传送数据。三次握手才能确认双方的接收和发送能力是否正常。

如果是两次握手,如果某次发送的报文因为网络延误了,又重新发送了一次连接,延误的发送在重新的连接释放之后才到达服务端,这时候服务端会认为发送端又发送了一次连接请求,于是向发送端发送确认请求,同意建立连接,但客户端实际并未发送,所以忽略请求,于是服务端一直等待,浪费资源。

不采用两次或者四次:避免历史连接、避免资源浪费、确认对方收发能力。

7.四次挥手

通过四次挥手的过程,TCP协议确保了双方都能够正常地关闭连接,并且所有未完成的数据传输都能顺利结束。第一次挥手:客户端发送FIN,表示没有数据要发送了。第二次挥手:服务器发送ACK,确认收到FIN请求。第三次挥手:服务器发送FIN,表示没有数据要发送了。第四次挥手:客户端发送ACK,确认收到服务器的FIN请求,连接关闭。

8.HTTP请求方法

应用层产生的请求报文里面会含有请求行、请求头、请求体(post会有,get没有),

  • 请求行:包括请求方法、请求 URI 和 HTTP 版本。
  • 请求头:提供关于请求的附加信息,例如主机名、用户代理、接受的内容类型等。
  • 请求体:包含要发送给服务器的数据,适用于需要提交数据的请求方法如 POSTPUT

GET  POST  PUT  PATCH  TRACE  OPTIONS  CONNECT  HEAD  DELETE 

9.HTTP状态码

1XX  信息性状态码  接收的请求正在处理,正常,继续;

2XX  成功状态码  请求正常处理完毕; 200   204   206

3XX  重定向状态码   资源位置发生变化,需要新的URL; 301   302  304

4XX  客户端错误状态码  服务端无法处理客户端的请求;400   403   404 

5XX  服务端错误状态码  服务端在处理请求时自身错误; 500  501  502  503

10.HTTP协议的几个版本

HTTP1.0  短连接,请求响应模型,多媒体 (支持文本、音视频等),简单易用,扩展性,但是短连接导致效率低、延迟高、浪费资源,无持久连接导致没法在同一个连接中处理多个请求;

HTTP1.1  持久连接,请求管道化,缓存控制,性能提升,带宽利用率高,更灵活的请求处理,但是管道化局限,队头阻塞;

HTTP2  二进制格式,头部压缩,多路复用(流),服务器推送,但复杂性增加,基于TCP(仍受到握手、丢包重传等限制);

HTTP3  基于QUIC协议,更快的连接建立,改进的流量控制,内建的加密,性能卓越,但是依赖基础设施,实现复杂。QUIC允许对每个流单独进行流量控制,而不仅仅是针对整个连接进行流量控制。这样可以更好地适应不同流的数据传输需求,提高传输效率。

11.GET和POST的区别

1. 用途:GET用来请求数据,POST修改/提交数据;

2. 数据传输方式:URL传递,请求体传递;

3. 安全性:URL上数据可见,请求体内稍微安全一些,但是都不安全,HTTP明文;

4. 幂等性:GET每次请求都会得到相同的数据,POST每次创建则会产生不同的资源;

5. 数据大小限制:URL长度限制,请求体可以大数据;

6. 缓存:GET每次请求可以缓存下来,方便下次请求,POST每次创建不同,不缓存;

7. 语义安全:GET修改服务器数据,POST不修改。

12.HTTP缓存方式

1. 强制缓存(HTTP1.0  Expires 头部字段,绝对时间,HTTP1.1 Cache-Control 头部字段,更灵活)

优点是在缓存有效期内,浏览器无需与服务器通信,直接使用本地缓存资源,提升加载速度。缺点是如果资源在缓存期间发生了变化,用户可能无法及时获取到最新的内容。

2. 协商缓存是指浏览器每次请求资源时,都会先向服务器询问资源是否已经更新,如果没有更新,则继续使用缓存。如果更新了,则下载新的资源。

优点是既能减少不必要的数据传输,又能保证获取最新的资源。缺点是相比强制缓存,每次请求都需要与服务器进行验证,带来了一定的延迟。

13.HTTP和HTTPS

区别:安全、连接、端口、证书

1. HTTP超文本传输协议,明文,不安全。HTTPS在TCP和HTTP之间加入了SSL/TLS安全协议,使得报文能够加密安全传输。

2. HTTP只需要三次握手就能建立连接,HTTPS则还需要SSL/TLS握手。

3. 端口号80与443。

4. HTTPS需要向CA申请身份证书,来保证服务器是安全可靠的。

14.HTTPS能解决什么问题

信息加密解决安全机密,校验机制解决篡改信息,身份证书解决不可信服务器。

15.为什么每次建立 TCP 连接,初始化的序列号要求不一样呢?

主要原因有两个方面:

  • 为了防止历史报文被下一个相同四元组的连接接收(主要方面);
  • 为了安全性,防止黑客伪造的相同序列号的 TCP 报文被对方接收;

客户端和服务端建立一个 TCP 连接,在客户端发送数据包被网络阻塞了,然后超时重传了这个数据包,而此时服务端设备断电重启了,之前与客户端建立的连接就消失了,于是在收到客户端的数据包的时候就会发送 RST 报文。紧接着,客户端又与服务端建立了与上一个连接相同四元组的连接;在新连接建立完成后,上一个连接中被网络阻塞的数据包正好抵达了服务端,刚好该数据包的序列号正好是在服务端的接收窗口内,所以该数据包会被服务端正常接收,就会造成数据错乱。可以看到,如果每次建立连接,客户端和服务端的初始化序列号都是一样的话,很容易出现历史报文被下一个相同四元组的连接接收的问题

16.第一次、第二次、第三次握手丢失了分别会发生什么?

第一次握手丢失:超时重传,而且重传的 SYN 报文的序列号都是一样的。每次等待几秒,下一次重传的等待时间是这次的两倍,直至重传上限次数,断开连接。

第二次握手丢失:客户端和服务端都会重传,客户端会重传 SYN 报文,也就是第一次握手,最大重传次数由 tcp_syn_retries内核参数决定;服务端会重传 SYN-ACK 报文,也就是第二次握手,最大重传次数由 tcp_synack_retries 内核参数决定。

第三次握手丢失:ACK 报文是不会有重传的,当 ACK 丢失了,就由对方重传对应的报文。因为这个第三次握手的 ACK 是对第二次握手的 SYN 的确认报文,所以当第三次握手丢失了,如果服务端那一方迟迟收不到这个确认报文,就会触发超时重传机制,重传 SYN-ACK 报文,直到收到第三次握手,或者达到最大重传次数。

17.什么是 SYN 攻击?如何避免 SYN 攻击?

半连接队列:服务器第一次收到客户端的SYN之后,就会处于SYN_RCVD状态,此时双方还没有完全建立连接,服务器会把这种状态下的请求连接放在一个队列里,称为半连接队列。完成三次握手建立起连接的就会放入全连接队列中。

SYN攻击是客户端短时间内伪造大量不存在的IP地址,并向服务器不断发送SYN包,服务器回复确认包,并且等待客户端确认,由于源地址不存在,因此服务器不断重发直至超时,这些伪造的SYN包将长时间占用半连接队列,导致正常的SYN请求因队列满而丢弃,从而引起网络拥塞甚至瘫痪。

防御方法:缩短超时时间,增大半连接队列,防火墙过滤,SYN Cookies(是一种在服务器接收到 SYN 请求时,不立即为其分配资源,而是将请求信息编码到 TCP 序列号中的技术。只有当客户端发送 ACK 确认时,服务器才会验证这个序列号并为连接分配资源。),SYN 速率限制。

18.四次挥手丢失分别会发生什么?

第一次挥手丢失:客户端迟迟收不到被动方的 ACK 的话,触发超时重传机制,重传 FIN 报文,重发次数由 tcp_orphan_retries 参数控制。如果还是没能收到服务端的第二次挥手(ACK报文),那么客户端就会断开连接。

第二次挥手丢失:ACK 报文是不会重传的,所以如果服务端的第二次挥手丢失了,客户端就会触发超时重传机制,重传 FIN 报文,直到收到服务端的第二次挥手,或者达到最大的重传次数。

第三次挥手丢失:如果迟迟收不到这个 ACK,服务端就会重发 FIN 报文,重发次数仍然由 tcp_orphan_retries 参数控制,这与客户端重发 FIN 报文的重传次数控制方式是一样的。

第四次挥手丢失:如果第四次挥手的 ACK 报文没有到达服务端,服务端就会重发 FIN 报文,重发次数仍然由前面介绍过的 tcp_orphan_retries 参数控制。

也就是说,四次丢失导致的结果都是FIN重传。

19.为什么 TIME_WAIT 等待的时间是 2MSL?

四次挥手开始时,客户端和服务器都是连接已建立状态,客户端向服务器发送一个终止信号FIN,进入终止等待1,服务器收到后发送一个确认信号ACK,进入关闭等待状态,客户端收到后进入终止等待2,整个系统进入半连接状态,服务器向客户端发送FIN和ACK,ACK是对第一次挥手的重复确认,进入最后确认状态,客户端收到后发送ACK,进入时间等待状态(2MSL),服务器收到后进入关闭状态,2MSL之后客户端也进入关闭状态。至于为什么是2MSL,2倍的最大报文生存时间,是为了确保ACK能够到达服务器 ,以使其进入关闭状态,如果丢失能够重传,时间重新计时。

需要 TIME-WAIT 状态,主要是两个原因:

  • 防止历史连接中的数据,被后面相同四元组的连接错误的接收;(这个时间足以让两个方向上的数据包都被丢弃,使得原来连接的数据包在网络中都自然消失,再出现的数据包一定都是新建立连接所产生的。)
  • 保证「被动关闭连接」的一方,能被正确的关闭。

20.一些连接问题

服务器出现大量 TIME_WAIT 状态的原因有哪些?说明服务器主动断开了很多 TCP 连接,什么场景下服务端会主动断开连接呢?第一个场景:HTTP 没有使用长连接;第二个场景:HTTP 长连接超时;第三个场景:HTTP 长连接的请求数量达到上限。

服务器出现大量 CLOSE_WAIT 状态的原因有哪些?

如果已经建立了连接,但是客户端突然出现故障了怎么办?保活机制:定义一个时间段,在这个时间段内,如果没有任何连接相关的活动,TCP 保活机制会开始作用,每隔一个时间间隔,发送一个探测报文,该探测报文包含的数据非常少,如果连续几个探测报文都没有得到响应,则认为当前的 TCP 连接已经死亡,系统内核将错误信息通知给上层应用程序。

如果已经建立了连接,但是服务端的进程崩溃会发生什么?TCP 的连接信息是由内核维护的,所以当服务端的进程崩溃后,内核需要回收该进程的所有 TCP 连接资源,于是内核会发送第一次挥手 FIN 报文,后续的挥手过程也都是在内核完成,并不需要进程的参与,所以即使服务端的进程退出了,还是能与客户端完成 TCP 四次挥手的过程。

保活机制根本上是断开空闲的TCP连接的。如果两端的 TCP 连接一直没有数据交互,达到了触发 TCP 保活机制的条件,那么内核里的 TCP 协议栈就会发送探测报文。

TCP 连接,一端断电和进程崩溃有什么区别?一端断电触发保活机制,进程崩溃不同。TCP 的连接信息是由内核维护的,所以当服务端的进程崩溃后,内核需要回收该进程的所有 TCP 连接资源,于是内核会发送第一次挥手 FIN 报文,后续的挥手过程也都是在内核完成,并不需要进程的参与,所以即使服务端的进程退出了,还是能与客户端完成 TCP四次挥手的过程。

拔掉网线几秒,再插回去,原本的 TCP 连接还存在吗?如果有数据传输,只要及时就会赶上超时重传。如果没有就触发保活机制,没有及时的话会断开连接。

HTTPS 中 TLS 和 TCP 能同时握手吗?不管 TLS 握手次数如何,都得先经过 TCP 三次握手后才能进行,因为 HTTPS 都是基于 TCP 传输协议实现的,得先建立完可靠的 TCP 连接才能做 TLS 握手的事情。前两次握手并不能携带数据,第三次可以。

TCP Keepalive 和 HTTP Keep-Alive 是一个东西吗?

  • HTTP 的 Keep-Alive,是由应用层(用户态) 实现的,称为 HTTP 长连接;
  • TCP 的 Keepalive,是由 TCP 层(内核态) 实现的,称为 TCP 保活机制;

TCP 协议有哪些缺陷?主要有四个方面:升级 TCP 的工作很困难;TCP 建立连接的延迟;TCP 存在队头阻塞问题;网络迁移需要重新建立 TCP 连接。

服务端没有 listen,客户端发起连接建立,会发生什么?服务端如果只 bind 了 IP 地址和端口,而没有调用 listen 的话,然后客户端对服务端发起了连接建立,服务端会返回 RST 报文。

不使用 listen ,可以建立 TCP 连接吗?可以的,客户端是可以自己连自己的形成连接(TCP自连接),也可以两个客户端同时向对方发出请求建立连接(TCP同时打开),这两个情况都有个共同点,就是没有服务端参与,也就是没有listen,就能建立连接。

没有 accept,能建立 TCP 连接吗?就算不执行accept()方法,三次握手照常进行,并顺利建立连接。半连接队列(SYN队列),服务端收到第一次握手后,会将sock加入到这个队列中,队列内的sock都处于SYN_RECV 状态。全连接队列(ACCEPT队列),在服务端收到第三次握手后,会将半连接队列的sock取出,放到全连接队列中。队列里的sock都处于 ESTABLISHED状态。这里面的连接,就等着服务端执行accept()后被取出了。建立连接的过程中根本不需要accept()参与,执行accept()只是为了从全连接队列里取出一条连接。全连接队列(icsk_accept_queue)是个链表,而半连接队列(syn_table)是个哈希表。出于效率考虑设计的,复杂度尽量低。全连接队列:服务端取走连接的过程中,并不关心具体是哪个连接,只要是个连接就行,所以直接从队列头取就行了。这个过程算法复杂度为O(1)。半连接队列:有一个第三次握手来了,则需要从队列里把相应IP端口的连接取出,哈希表,那么查找半连接的算法复杂度就回到O(1)了。

总结:

  • 每一个socket执行listen时,内核都会自动创建一个半连接队列和全连接队列。
  • 第三次握手前,TCP连接会放在半连接队列中,直到第三次握手到来,才会被放到全连接队列中。
  • accept方法只是为了从全连接队列中拿出一条连接,本身跟三次握手几乎毫无关系
  • 出于效率考虑,虽然都叫队列,但半连接队列其实被设计成了哈希表,而全连接队列本质是链表。
  • 全连接队列满了,再来第三次握手也会丢弃,此时如果tcp_abort_on_overflow=1,还会直接发RST给客户端。
  • 半连接队列满了,可能是因为受到了SYN Flood攻击,可以设置tcp_syncookies,绕开半连接队列。
  • 客户端没有半连接队列和全连接队列,但有一个全局hash,可以通过它实现自连接或TCP同时打开。

TCP 是一个可靠的传输协议,那它一定能保证数据不丢失吗?数据从发送端到接收端,链路很长,任何一个地方都可能发生丢包,几乎可以说丢包不可避免。TCP只保证传输层的消息可靠性,并不保证应用层的消息可靠性。

21.针对 TCP 应该如何 Socket 编程?

没有 accept,能建立 TCP 连接吗?accpet 系统调用并不参与 TCP 三次握手过程,它只是负责从 TCP 全连接队列取出一个已经建立连接的 socket,用户层通过 accpet 系统调用拿到了已经建立连接的socket,就可以对该 socket 进行读写操作了。

22.TCP的一些点

超时重传时间RTO要略微大于报文往返时间RTT.

三次同样的ACK就会触发快速重传。

窗口大小就是指无需等待确认应答,而可以继续发送数据的最大值

SYN 报文什么时候情况下会被丢弃?1. 如果发现收到的数据包中时间戳不是递增的,则表示该数据包是过期的,就会直接丢弃这个数据包。2. 当服务器造成syn攻击,就有可能导致 TCP 半连接队列满了,这时后面来的 syn 包都会被丢弃。但是,如果开启了syncookies 功能,即使半连接队列满了,也不会丢弃syn 包。3. 在服务端并发处理大量请求时,如果 TCP accpet 队列过小,或者应用程序调用 accept() 不及时,就会造成 accpet 队列满了 ,这时后续的连接就会被丢弃,这样就会出现服务端请求数量上不去的现象。

在 TCP 正常挥手过程中,处于 TIME_WAIT 状态的连接,收到相同四元组的 SYN 后会发生什么?如果处于 TIME_WAIT 状态的连接收到「合法的 SYN 」后,就会重用此四元组连接,跳过 2MSL 而转变为 SYN_RECV 状态,接着就能进行建立连接过程。如果处于 TIME_WAIT 状态的连接收到「非法的 SYN 」后,就会再回复一个第四次挥手的 ACK 报文,客户端收到后,发现并不是自己期望收到确认号,就回 RST 报文给服务端RST标志用于强制关闭一个TCP连接。

23.TCP面向字节流,粘包和拆包

TCP 是面向字节流的协议,UDP 是面向报文的协议。是因为操作系统对 TCP 和 UDP 协议的发送方的机制不同。当用户消息通过 UDP 协议传输时,操作系统不会对消息进行拆分每个 UDP 报文就是一个用户消息的边界。当用户消息通过 TCP 协议传输时,消息可能会被操作系统分组成多个的 TCP 报文。因此,我们不能认为一个用户消息对应一个 TCP 报文,正因为这样,所以 TCP 是面向字节流的协议。当两个消息的某个部分内容被分到同一个 TCP 报文时,就是我们常说的 TCP 粘包问题,这时接收方不知道消息的边界的话,是无法读出有效的消息。粘包的问题出现是因为不知道一个用户消息的边界在哪,所以解决办法是:固定长度的消息、特殊字符作为边界、长度前缀、自定义协议来明确数据包的结构和边界。

24. 如何基于 UDP 协议实现可靠传输?

 TCP 可靠传输的特性(序列号、确认应答、超时重传、流量控制、拥塞控制)

QUIC 是如何实现可靠传输的?

QUIC 通过单向递增的 Packet Number,配合 Stream ID 与 Offset字段信息,可以支持乱序确认而不影响数据包的正确组装,摆脱了TCP 必须按顺序确认应答 ACK 的限制,解决了 TCP 因某个数据包重传而阻塞后续所有待发送数据包的问题。

QUIC 是如何解决 TCP 队头阻塞问题的?

QUIC 给每一个 Stream 都分配了一个独立的滑动窗口,这样使得一个连接上的多个 Stream 之间没有依赖关系,都是相互独立的,各自控制的滑动窗口

QUIC 是如何做流量控制的?

Stream 级别的流量控制:Stream 可以认为就是一条 HTTP 请求,每个 Stream 都有独立的滑动窗口,所以每个 Stream 都可以做流量控制,防止单个 Stream 消耗连接(Connection)的全部接收缓冲。Connection 流量控制:限制连接中所有 Stream 相加起来的总字节数,防止发送方超过连接的缓冲容量。

QUIC 对拥塞控制改进

QUIC 是处于应用层的,应用程序层面就能实现不同的拥塞控制算法,不需要操作系统,不需要内核支持。这是一个飞跃,因为传统的 TCP 拥塞控制,必须要端到端的网络协议栈支持,才能实现控制效果。而内核和操作系统的部署成本非常高,升级周期很长,所以 TCP 拥塞控制算法迭代速度是很慢的。而 QUIC 可以随浏览器更新,QUIC 的拥塞控制算法就可以有较快的迭代速度。TCP 更改拥塞控制算法是对系统中所有应用都生效,无法根据不同应用设定不同的拥塞控制策略。但是因为 QUIC 处于应用层,所以就可以针对不同的应用设置不同的拥塞控制算法,这样灵活性就很高了。

QUIC 更快的连接建立

 HTTP/3 的 QUIC 协议并不是与 TLS 分层,而是QUIC 内部包含了 TLS,它在自己的帧会携带 TLS 里的“记录”,再加上 QUIC 使用的是 TLS1.3,因此仅需 1 个 RTT 就可以「同时」完成建立连接与密钥协商,甚至在第二次连接的时候,应用数据包可以和 QUIC 握手信息(连接信息 + TLS 信息)一起发送,达到 0-RTT 的效果

QUIC 是如何迁移连接的?

基于 TCP 传输协议的 HTTP 协议,由于是通过四元组(源 IP、源端口、目的 IP、目的端口)确定一条 TCP 连接。那么当移动设备的网络从 4G 切换到 WIFI 时,意味着 IP 地址变化了,那么就必须要断开连接,然后重新建立 TCP 连接。QUIC 协议没有用四元组的方式来“绑定”连接,而是通过连接 ID来标记通信的两个端点,客户端和服务器可以各自选择一组 ID 来标记自己,因此即使移动设备的网络变化后,导致 IP 地址变化了,只要仍保有上下文信息(比如连接 ID、TLS 密钥等),就可以“无缝”地复用原连接,消除重连的成本,没有丝毫卡顿感,达到了连接迁移的功能。


http://www.ppmy.cn/devtools/94548.html

相关文章

uni-app发布安卓app打包时必须在APP模块配置中选中需要的模块

最近尝试开发一个语音对话的app,在调试阶段没有选中“record录音”模块,安卓基座运行在雷电模拟器上是没有问题的,但是直接云打包在手机上运行就不行了,语音输入没有反应。 经过试验发现是manifest.json没有勾选APP模块配置中的“…

HarmonyOS.FA开发流程

开发环境配置 1、DevEco Studio的安装 2、DevEcoStudio模拟运行工程:运行Tools->Device Manager,使用已认证的HW开发者联盟帐号Login(在DP平台申请测试者权限),点击"允许"授权,选择一个设备运…

【深度学习】【语音】TTS,MeloTTS代码讲解

文章目录 推理split_sentences_zh 函数短句子转为音素和bert特征get_text_for_tts_infer 函数text_normalize函数_g2p_v2函数def _g2p(segments)cleaned_text_to_sequencehps.data什么是滤波长度短时傅里叶变换(STFT)滤波长度(filter_length)影响分析get_bert_featureinfer…

java快速导出word文档

点关注不迷路,欢迎再访! 精简博客内容,尽量已行业术语来分享。 努力做到对每一位认可自己的读者负责。 帮助别人的同时更是丰富自己的良机。 文章目录 前言一.添加 Apache POI 依赖二.填充文档内容三.导出文档效果测试 前言 在 Java 应用程序…

uniapp接口请求this.$request

代码示例: createPhoto(url) {this.$request({url: /emp/gallery-photo/create,method: post,header: {tenant-id: 1,},data: {galleryId: this.albumId,empUserId: this.empUserId,"url": url,}}).then((res) > {console.log(res,"返回值"…

PCB工艺

表面处理 提高焊接质量:提高焊接点的质量,确保电路板的可靠性和寿命。防止氧化:保护裸露的铜箔不受氧化,延长电路板的使用寿命。提高导电性:某些表面处理方法可以提高电路板的导电性,适用于高频和高速电路…

基于spring boot的校园商铺管理系统

TOC springboot188基于spring boot的校园商铺管理系统 第1章 绪论 1.1 研究背景 互联网概念的产生到如今的蓬勃发展,用了短短的几十年时间就风靡全球,使得全球各个行业都进行了互联网的改造升级,标志着互联网浪潮的来临。在这个新的时代&…

面试题精选汇总(实时更新)(评论区欢迎补充)

1. 数组扁平化去重 已知如下数组,编写一个程序将数组扁平化并且去除其中重复部分数据,最终得 到一个升序且不重复的数组 var arr = [ [1, 2, 2], [3, 4, 5, 5], [6, 7, 8, 9, [11, 12, [12, 13, [14] ] ] ], 10] (使用 Set 方法去重,flat(Infinity)扁平化) Array.from(new S…