用了 TCP 协议,就一定不会丢包吗?

表面上我是个技术博主。


但没想到今天成了个情感博主。


我是没想到有一天,我会通过技术知识,来挽救粉丝即将破碎的感情。


掏心窝子的说。这件事情多少是沾点功德无量了。


事情是这样的。


最近就有个读者加了我的绿皮聊天软件,女生,头像挺好看的,就在我以为她要我拉她进群发成人专升本广告的时候。


画风突然不对劲。


她说她男朋友也是个程序员,异地恋,也关注了我,天天研究什么 TCP、UDP 网络。一研究就是一晚上,一晚上都不回她消息的那种。


话里有话,懂。


不出意外的出了意外,她发出了灵魂拷问


"你们程序员真的有那么忙吗?忙到连消息都不知道回。"


没想到上来就是一记直拳。


但是,这一拳,我接住了。


2d04cb2c291324fbde69eb67742b2234.jpeg


我很想告诉她 "分了吧,下一题"。


但我不能。因为这样我就伤害了我的读者兄弟。


沉默了一下。


84261e1201c0877eee3ca14717b83e26.jpeg


单核 CPU 都快转冒烟了,才颤颤巍巍在九宫格键盘上发出消息。


再回慢一点,我就感觉,我要对不起我这全日制本科学历了。


"其实,他已经回了你消息了,但你知道吗?网络是会丢包的。"


"我来帮他解释下,这个话题就要从数据包的发送流程聊起"


数据包的发送流程


首先,我们两个手机的绿皮聊天软件客户端,要通信,中间会通过它们家服务器。大概长这样。


11931562100fc84fecf348bb09f663aa.jpeg

聊天软件三端通信


但为了简化模型,我们把中间的服务器给省略掉,假设这是个端到端的通信。且为了保证消息的可靠性,我们盲猜它们之间用的是 TCP 协议进行通信。


7feb284541962b5e51089f9ac4a73d89.jpeg

聊天软件两端通信


为了发送数据包,两端首先会通过三次握手,建立 TCP 连接。


一个数据包,从聊天框里发出,消息会从聊天软件所在的用户空间拷贝到内核空间的发送缓冲区(send buffer),数据包就这样顺着传输层、网络层,进入到数据链路层,在这里数据包会经过流控(qdisc),再通过 RingBuffer 发到物理层的网卡。数据就这样顺着网卡发到了纷繁复杂的网络世界里。这里头数据会经过 n 多个路由器和交换机之间的跳转,最后到达目的机器的网卡处。


此时目的机器的网卡会通知 DMA 将数据包信息放到 RingBuffer 中,再触发一个硬中断给 CPU,CPU 触发软中断让 ksoftirqd 去 RingBuffer 收包,于是一个数据包就这样顺着物理层,数据链路层,网络层,传输层,最后从内核空间拷贝到用户空间里的聊天软件里。


ea5f7d391d52d8167387e4d14677c155.jpeg

网络发包收包全景图


画了那么大一张图,只水了 200 字做解释,我多少是有些心痛的。


到这里,抛开一些细节,大家大概知道了一个数据包从发送到接收的宏观过程。

可以看到,这上面全是密密麻麻的名词。


整条链路下来,有不少地方可能会发生丢包。


但为了不让大家保持蹲姿太久影响身体健康,我这边只重点讲下几个常见容易发生丢包的场景。


建立连接时丢包


TCP 协议会通过三次握手建立连接。大概长下面这样。


274fe4483a588a821baf8957f923037f.jpeg

TCP 三次握手


在服务端,第一次握手之后,会先建立个半连接,然后再发出第二次握手。这时候需要有个地方可以暂存这些半连接。这个地方就叫半连接队列。


如果之后第三次握手来了,半连接就会升级为全连接,然后暂存到另外一个叫全连接队列的地方,坐等程序执行 accept () 方法将其取走使用。


6e07dee380ee70f77a7effd568e6e65c.jpeg

半连接队列和全连接队列


是队列就有长度,有长度就有可能会满,如果它们满了,那新来的包就会被丢弃。


可以通过下面的方式查看是否存在这种丢包行为。



# 全连接队列溢出次数 # netstat -s | grep overflowed 4343 times the listen queue of a socket overflowed
# 半连接队列溢出次数 # netstat -s | grep -i "SYNs to LISTEN sockets dropped" 109 times the listen queue of a socket overflowed


从现象来看就是连接建立失败。


49a0e77058ce376855964523d652567c.jpeg


流量控制丢包


应用层能发网络数据包的软件有那么多,如果所有数据不加控制一股脑冲入到网卡,网卡会吃不消,那怎么办?让数据按一定的规则排个队依次处理,也就是所谓的 qdisc (Queueing Disciplines,排队规则),这也是我们常说的流量控制机制。


排队,得先有个队列,而队列有个长度。


我们可以通过下面的 ifconfig 命令查看到,里面涉及到的 txqueuelen 后面的数字 1000,其实就是流控队列的长度。


当发送数据过快,流控队列长度 txqueuelen 又不够大时,就容易出现丢包现象。


8643a85cd9ced0b85bcef00e889298c6.jpeg

qdisc 丢包


可以通过下面的 ifconfig 命令,查看 TX 下的 dropped 字段,当它大于 0 时,则有可能是发生了流控丢包。




# ifconfig eth0 eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 172.21.66.69 netmask 255.255.240.0 broadcast 172.21.79.255 inet6 fe80::216:3eff:fe25:269f prefixlen 64 scopeid 0x20<link> ether 00:16:3e:25:26:9f txqueuelen 1000 (Ethernet) RX packets 6962682 bytes 1119047079 (1.0 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 9688919 bytes 2072511384 (1.9 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0


当遇到这种情况时,我们可以尝试修改下流控队列的长度。比如像下面这样将 eth0 网卡的流控队列长度从 1000 提升为 1500。


网卡丢包


网卡和它的驱动导致丢包的场景也比较常见,原因很多,比如网线质量差,接触不良。除此之外,我们来聊几个常见的场景。


RingBuffer 过小导致丢包


上面提到,在接收数据时,会将数据暂存到 RingBuffer 接收缓冲区中,然后等着内核触发软中断慢慢收走。如果这个缓冲区过小,而这时候发送的数据又过快,就有可能发生溢出,此时也会产生丢包。


a6a20e346dfd504ff46d6c0d6f9ba751.jpeg

RingBuffer 满了导致丢包


我们可以通过下面的命令去查看是否发生过这样的事情。


# ifconfig eth0: RX errors 0 dropped 0 overruns 0 frame 0


查看上面的 overruns 指标,它记录了由于 RingBuffer 长度不足导致的溢出次数。


当然,用 ethtool 命令也能查看。


# ethtool -S eth0|grep rx_queue_0_drops


但这里需要注意的是,因为一个网卡里是可以有多个 RingBuffer 的,所以上面的 rx_queue_0_drops 里的 0 代表的是第 0 个 RingBuffer 的丢包数,对于多队列的网卡,这个 0 还可以改成其他数字。但我的家庭条件不允许我看其他队列的丢包数,所以上面的命令对我来说是够用了。


当发现有这类型丢包的时候,可以通过下面的命令查看当前网卡的配置。



#ethtool -g eth0 Ring parameters for eth0: Pre-set maximums: RX: 4096 RX Mini: 0 RX Jumbo: 0 TX: 4096 Current hardware settings: RX: 1024 RX Mini: 0 RX Jumbo: 0 TX: 1024


上面的输出内容,含义是 RingBuffer 最大支持 4096 的长度,但现在实际只用了 1024。


想要修改这个长度可以执行 ethtool -G eth1 rx 4096 tx 4096 将发送和接收 RingBuffer 的长度都改为 4096。


RingBuffer 增大之后,可以减少因为容量小而导致的丢包情况。


网卡性能不足


网卡作为硬件,传输速度是有上限的。当网络传输速度过大,达到网卡上限时,就会发生丢包。这种情况一般常见于压测场景。


我们可以通过 ethtool 加网卡名,获得当前网卡支持的最大速度。



# ethtool eth0 Settings for eth0: Speed: 10000Mb/s


可以看到,我这边用的网卡能支持的最大传输速度 speed=1000Mb/s。


也就是俗称的千兆网卡,但注意这里的单位是 Mb,这里的 b 是指 bit,而不是 Byte。1Byte=8bit。所以 10000Mb/s 还要除以 8,也就是理论上网卡最大传输速度是 1000/8 = 125MB/s。


我们可以通过 sar 命令从网络接口层面来分析数据包的收发情况。



# sar -n DEV 1 Linux 3.10.0-1127.19.1.el7.x86_64 2022年07月27日 _x86_64_ (1 CPU)
08时35分39秒 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s 08时35分40秒 eth0 6.06 4.04 0.35 121682.33 0.00 0.00 0.00


其中 txkB/s 是指当前每秒发送的字节(byte)总数,rxkB/s 是指每秒接收的字节(byte)总数。


当两者加起来的值约等于 12~13w 字节的时候,也就对应大概 125MB/s 的传输速度。此时达到网卡性能极限,就会开始丢包。


遇到这个问题,优先看下你的服务是不是真有这么大的真实流量,如果是的话可以考虑下拆分服务,或者就忍痛充钱升级下配置吧。


接收缓冲区丢包


我们一般使用 TCP socket 进行网络编程的时候,内核都会分配一个发送缓冲区和一个接收缓冲区。


当我们想要发一个数据包,会在代码里执行 send (msg),这时候数据包并不是一把梭直接就走网卡飞出去的。而是将数据拷贝到内核发送缓冲区就完事返回了,至于什么时候发数据,发多少数据,这个后续由内核自己做决定。


b83cf367be1b432c5d4ddae745d38a1e.jpeg

tcp_sendmsg 逻辑


而接收缓冲区作用也类似,从外部网络收到的数据包就暂存在这个地方,然后坐等用户空间的应用程序将数据包取走。


这两个缓冲区是有大小限制的,可以通过下面的命令去查看。



# 查看接收缓冲区 # sysctl net.ipv4.tcp_rmem net.ipv4.tcp_rmem = 4096 87380 6291456
# 查看发送缓冲区 # sysctl net.ipv4.tcp_wmem net.ipv4.tcp_wmem = 4096 16384 4194304


不管是接收缓冲区还是发送缓冲区,都能看到三个数值,分别对应缓冲区的最小值,默认值和最大值 (min、default、max)。缓冲区会在 min 和 max 之间动态调整。


那么问题来了,如果缓冲区设置过小会怎么样?


对于发送缓冲区,执行 send 的时候,如果是阻塞调用,那就会等,等到缓冲区有空位可以发数据。


c0be49c4ee5a2f13914d0097268d2569.jpeg

send 阻塞


如果是非阻塞调用,就会立刻返回一个 EAGAIN 错误信息,意思是 Try again 。让应用程序下次再重试。这种情况下一般不会发生丢包。


ecaa754fa83a2c8e40dbb70b04a2977a.jpeg

send 非阻塞


当接受缓冲区满了,事情就不一样了,它的 TCP 接收窗口会变为 0,也就是所谓的零窗口,并且会通过数据包里的 win=0,告诉发送端,"球球了,顶不住了,别发了"。一般这种情况下,发送端就该停止发消息了,但如果这时候确实还有数据发来,就会发生丢包。


8313881f772cd3d89a4e5167075b6b95.jpeg

recv_buffer 丢包


我们可以通过下面的命令里的 TCPRcvQDrop 查看到有没有发生过这种丢包现象。



cat /proc/net/netstat TcpExt: SyncookiesSent TCPRcvQDrop SyncookiesFailed TcpExt: 0 157 60116



但是说个伤心的事情,我们一般也看不到这个 TCPRcvQDrop,因为这个是 5.9 版本里引入的打点,而我们的服务器用的一般是 2。x~3。x 左右版本。你可以通过下面的命令查看下你用的是什么版本的 Linux 内核。


# cat /proc/version Linux version 3.10.0-1127.19.1.el7.x86_64


两端之间的网络丢包


前面提到的是两端机器内部的网络丢包,除此之外,两端之间那么长的一条链路都属于外部网络,这中间有各种路由器和交换机还有光缆啥的,丢包也是很经常发生的。

这些丢包行为发生在中间链路的某些个机器上,我们当然是没权限去登录这些机器。但我们可以通过一些命令观察整个链路的连通情况。


ping 命令查看丢包


比如我们知道目的地的域名是 baidu.com。想知道你的机器到 baidu 服务器之间,有没有产生丢包行为。可以使用 ping 命令。


762237be3eb95dfe2f664d3e0325d842.jpeg

ping 查看丢包


倒数第二行里有个 100% packet loss,意思是丢包率 100%。


但这样其实你只能知道你的机器和目的机器之间有没有丢包。


那如果你想知道你和目的机器之间的这条链路,哪个节点丢包了,有没有办法呢?有。


mtr 命令


mtr 命令可以查看到你的机器和目的机器之间的每个节点的丢包情况。


像下面这样执行命令。


b67e24c59dbab7a6ea36af48f595d56d.jpeg

mtr_icmp


其中 -r 是指 report,以报告的形式打印结果。


可以看到 Host 那一列,出现的都是链路中间每一跳的机器,Loss 的那一列就是指这一跳对应的丢包率。


需要注意的是,中间有一些是 host 是?,那个是因为 mtr 默认用的是 ICMP 包,有些节点限制了 ICMP 包,导致不能正常展示。


我们可以在 mtr 命令里加个 -u,也就是使用 UDP 包,就能看到部分?对应的 IP。


1f29d893624a8f4885da73e1a14fd3e2.jpeg

mtr-udp


把 ICMP 包和 UDP 包的结果拼在一起看,就是比较完整的链路图了。


还有个小细节,Loss 那一列,我们在 icmp 的场景下,关注最后一行,如果是 0%,那不管前面 loss 是 100% 还是 80% 都无所谓,那些都是节点限制导致的虚报。


但如果最后一行是 20%,再往前几行都是 20% 左右,那说明丢包就是从最接近的那一行开始产生的,长时间是这样,那很可能这一跳出了点问题。如果是公司内网的话,你可以带着这条线索去找对应的网络同事。如果是外网的话,那耐心点等等吧,别人家的开发会比你更着急。


9427616458a80743c1d4ad7dc483ccdc.jpeg


发生丢包了怎么办


说了这么多。只是想告诉大家,丢包是很常见的,几乎不可避免的一件事情。


但问题来了,发生丢包了怎么办?


这个好办,用 TCP 协议去做传输。


d9ab14def028df7c8de46fa0034e8353.jpeg

TCP 是什么


建立了 TCP 连接的两端,发送端在发出数据后会等待接收端回复 ack 包,ack 包的目的是为了告诉对方自己确实收到了数据,但如果中间链路发生了丢包,那发送端会迟迟收不到确认 ack,于是就会进行重传。以此来保证每个数据包都确确实实到达了接收端。


假设现在网断了,我们还用聊天软件发消息,聊天软件会使用 TCP 不断尝试重传数据,如果重传期间网络恢复了,那数据就能正常发过去。但如果多次重试直到超时都还是失败,这时候你将收获一个红色感叹号。


558cacaa461757da49aefe048c9307dd.jpeg


这时候问题又来了。


假设某绿皮聊天软件用的就是 TCP 协议。


那文章开头提到的女生,她男朋友回她的消息时为什么还会丢包?毕竟丢包了会重试,重试失败了还会出现红色感叹号。


于是乎,问题就变成了,用了 TCP 协议,就一定不会丢包吗?


用了 TCP 协议就一定不会丢包吗


我们知道 TCP 位于传输层,在它的上面还有各种应用层协议,比如常见的 HTTP 或者各类 RPC 协议。


097e6b5fa3d6ec225414860484ff95d5.jpeg

四层网络协议


TCP 保证的可靠性,是传输层的可靠性。也就是说,TCP 只保证数据从 A 机器的传输层可靠地发到 B 机器的传输层。


至于数据到了接收端的传输层之后,能不能保证到应用层,TCP 并不管。


假设现在,我们输入一条消息,从聊天框发出,走到传输层 TCP 协议的发送缓冲区,不管中间有没有丢包,最后通过重传都保证发到了对方的传输层 TCP 接收缓冲区,此时接收端回复了一个 ack,发送端收到这个 ack 后就会将自己发送缓冲区里的消息给扔掉。到这里 TCP 的任务就结束了。


TCP 任务是结束了,但聊天软件的任务没结束。


聊天软件还需要将数据从 TCP 的接收缓冲区里读出来,如果在读出来这一刻,手机由于内存不足或其他各种原因,导致软件崩溃闪退了。


发送端以为自己发的消息已经发给对方了,但接收端却并没有收到这条消息。


于是乎,消息就丢了。


4a54fabb0a53910cebf15e2b4a34a44c.jpeg

使用 TCP 协议却发生丢包


虽然概率很小,但它就是发生了。


合情合理,逻辑自洽。


所以从这里,我铿锵有力的得出结论,我的读者已经回了这位女生消息了,只是因为发生了丢包所以女生才没能收到,而丢包的原因是女生的手机聊天软件在接收消息的那一刻发生了闪退。


到这里。女生知道自己错怪她男朋友了,哭着表示,一定要让她男朋友给她买一台不闪退的最新款 iPhone。


额……


这类丢包问题怎么解决?


故事到这里也到尾声了,感动之余,我们来聊点掏心窝子的话。


其实前面说的都对,没有一句是假话。


但某绿皮聊天软件这么成熟,怎么可能没考虑过这一点呢。


大家应该还记得我们文章开头提到过,为了简单,就将服务器那一方给省略了,从三端通信变成了两端通信,所以才有了这个丢包问题。


现在我们重新将服务器加回来。


18f9be389274b35f60db6f66c2e2a682.jpeg

聊天软件三端通信


大家有没有发现,有时候我们在手机里聊了一大堆内容,然后登录电脑版,它能将最近的聊天记录都同步到电脑版上。也就是说服务器可能记录了我们最近发过什么数据,假设每条消息都有个 id,服务器和聊天软件每次都拿最新消息的 id 进行对比,就能知道两端消息是否一致,就像对账一样。


对于发送方,只要定时跟服务端的内容对账一下,就知道哪条消息没发送成功,直接重发就好了。


如果接收方的聊天软件崩溃了,重启后跟服务器稍微通信一下就知道少了哪条数据,同步上来就是了,所以也不存在上面提到的丢包情况。


可以看出,TCP 只保证传输层的消息可靠性,并不保证应用层的消息可靠性。如果我们还想保证应用层的消息可靠性,就需要应用层自己去实现逻辑做保证。


那么问题叒来了,两端通信的时候也能对账,为什么还要引入第三端服务器?


主要有三个原因。


  • 第一,如果是两端通信,你聊天软件里有 1000 个好友,你就得建立 1000 个连接。但如果引入服务端,你只需要跟服务器建立 1 个连接就够了,聊天软件消耗的资源越少,手机就越省电。

  • 第二,就是安全问题,如果还是两端通信,随便一个人找你对账一下,你就把聊天记录给同步过去了,这并不合适吧。如果对方别有用心,信息就泄露了。引入第三方服务端就可以很方便的做各种鉴权校验。

  • 第三,是软件版本问题。软件装到用户手机之后,软件更不更新就是由用户说了算了。如果还是两端通信,且两端的软件版本跨度太大,很容易产生各种兼容性问题,但引入第三端服务器,就可以强制部分过低版本升级,否则不能使用软件。但对于大部分兼容性问题,给服务端加兼容逻辑就好了,不需要强制用户更新软件。


所以看到这里大家应该明白了,我把服务端去掉,并不单纯是为了简单。


总结


数据从发送端到接收端,链路很长,任何一个地方都可能发生丢包,几乎可以说丢包不可避免。


平时没事也不用关注丢包,大部分时候 TCP 的重传机制保证了消息可靠性。


当你发现服务异常的时候,比如接口延时很高,总是失败的时候,可以用 ping 或者 mtr 命令看下是不是中间链路发生了丢包。


TCP 只保证传输层的消息可靠性,并不保证应用层的消息可靠性。如果我们还想保证应用层的消息可靠性,就需要应用层自己去实现逻辑做保证。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/83305.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

01强化学习的数学原理:大纲

01强化学习学习路线大纲 前言强化学习脉络图章节介绍Chapter 1&#xff1a;Basic ConceptsChapter 2&#xff1a;Bellman EquationChapter 3&#xff1a;Bellman Optimality EquationChapter 4&#xff1a;Value Iteration / Policy IterationChapter 5&#xff1a;Monte Carlo…

华为OD机试 - 靠谱的车 - 逻辑分析(Java 2023 B卷 100分)

目录 专栏导读一、题目描述二、输入描述三、输出描述四、解题思路五、Java算法源码六、效果展示1、输入2、输出3、说明 华为OD机试 2023B卷题库疯狂收录中&#xff0c;刷题点这里 专栏导读 本专栏收录于《华为OD机试&#xff08;JAVA&#xff09;真题&#xff08;A卷B卷&#…

JOSEF约瑟 智能电流继电器KWJL-20/L KWLD26 零序孔径45mm 柜内导轨式安装

KWJL-20智能电流继电器 零序互感器&#xff1a; KWLD80 KWLD45 KWLD26 KWJL-20 一、产品概述 KWJL-20系列智能剩余电流继电器&#xff08;以下简称继电器&#xff09;适用于交流电压至660V或更高的TN、TT、和IT系统&#xff0c;频率为50Hz。通过零序电流互感器检测出超过…

IOTE 2023国际物联网展直击:芯与物发布全新定位芯片,助力多领域智能化发展

IOTE 2023国际物联网展&#xff0c;作为全球物联网领域的盛会&#xff0c;于9月20日在中国深圳拉开帷幕。北斗星通集团应邀参展&#xff0c;旗下专业从事物联网、消费类GNSS芯片研发设计的芯与物公司也随其亮相本届盛会。 展会上&#xff0c;芯与物展示了一系列创新的GNSS定位…

消费盲返模式:一种让消费者和商家都受益的新型消费返利模式

消费盲返是一种新型的消费返利模式&#xff0c;它的核心思想是&#xff1a;消费者在平台购买商品后&#xff0c;可以获得后续一定数量的订单的部分利润作为奖励。这样&#xff0c;消费者不仅可以享受商品的优惠&#xff0c;还有可能赚取更多的钱。 这种模式对于平台和消费者都有…

iOS蓝牙 Connection Parameters 关键参数说明

1. 先贴苹果文档 《 Accessory Design Guidelines for Apple Devices 》 2. 几个关键词 connection Event Interval 事件间隔&#xff0c;为1.25ms的倍数。可以简单理解为,是两个连接着的蓝牙设备发送“心跳包”的时间间隔&#xff1b; 范围是 6 ~ 3200&#xff0c;即 7.5…

Jmeter性能测试吞吐量控制器使用小结

吞吐量控制器(Throughput Controller)场景: 在同一个线程组里, 有10个并发, 7个做A业务, 3个做B业务,要模拟这种场景,可以通过吞吐量模拟器来实现.。 jmeter性能测试&#xff1a;2023最新的大厂jmeter性能测试全过程项目实战详解&#xff0c;悄悄收藏&#xff0c;后面就看不到…

Pytorch史上最全torch全版本离线文件下载地址大全(9月最新)

以下为pytorch官网的全版本torch文件离线下载地址 torch全版本whl文件离线下载大全https://download.pytorch.org/whl/torch/其中的文件版本信息如下所示&#xff08;部分版本信息&#xff0c;根据需要仔细寻找进行下载&#xff09;&#xff1a;

Web(1) 搭建漏洞环境(metasploitable2靶场/DVWA靶场)

简述渗透测试的步骤&#xff1b; 前期交互阶段→情报搜集阶段→威胁建模阶段→漏洞分析阶段→渗透攻击阶段→后渗透攻击阶段→报告阶段 (2)配置好metasploitable2靶场&#xff0c;截图 下载metasploitable2&#xff0c;VMware打开.vmx文件&#xff0c;登录&#xff0c;登陆用…

React 全栈体系(五)

第三章&#xff1a;React 应用(基于 React 脚手架) 一、使用 create-react-app 创建 react 应用 1. react 脚手架 xxx 脚手架: 用来帮助程序员快速创建一个基于 xxx 库的模板项目 包含了所有需要的配置&#xff08;语法检查、jsx 编译、devServer…&#xff09;下载好了所有…

一、8086

1、三大总线&#xff1a; &#xff08;1&#xff09;基础&#xff1a; 地址总线、数据总线、控制总线 &#xff08;2&#xff09;例题&#xff1a; 2、8086CPU &#xff08;1&#xff09;通用寄存器&#xff1a; 数据寄存器&#xff1a; 指针寄存器和变址寄存器&#xff1a…

国内首个潮玩行业沉浸式IP主题乐园,泡泡玛特城市乐园即将开园

近年来&#xff0c;泡泡玛特以潮玩IP为核心&#xff0c;不断拓展业务版图&#xff0c;推进国际化布局同时实现集团化运营&#xff0c;而泡泡玛特首个城市乐园将于9月下旬开业。据了解&#xff0c;泡泡玛特城市乐园是由泡泡玛特精心打造的沉浸式IP主题乐园&#xff0c;占地约4万…

linux新版本io框架 io_uring

从别的博主那copy过来&#xff1a; 1 io_uring是Linux内核的一个新型I/O事件通知机制&#xff0c;具有以下特点&#xff1a; 高性能&#xff1a;相比传统的select/poll/epoll等I/O多路复用机制&#xff0c;io_uring采用了更高效的ring buffer实现方式&#xff0c;可以在处理大量…

html form表单高级用法

场景&#xff1a;想单纯使用表单内置的api完成提交&#xff0c;不使用js代码 代码如下&#xff1a; <form name"myForm" action"http://localhost:13734/form" method"post"><label>用户名<input type"text" name&qu…

卓越领先!安全狗入选2023年福建省互联网综合实力50强

近日&#xff0c;福建省互联网协会在2023年东南科技论坛——智能算力助力数字经济产业融合发展论坛上正式发布2023年福建省互联网综合实力前50家企业最终评定结果。 作为国内云原生安全领导厂商&#xff0c;安全狗凭借突出的竞争力和市场表现入选。 据悉&#xff0c;福建省互…

【面试题】forEach能跳出循环吗?

前端面试题库 &#xff08;面试必备&#xff09; 推荐&#xff1a;★★★★★ 地址&#xff1a;前端面试题库 【国庆头像】- 国庆爱国 程序员头像&#xff01;总有一款适合你&#xff01; 如果面试官&#xff0c;或者有人问你foreach怎么跳出循环&#xff0c;请你…

开源媒体浏览器Kyoo

什么是 Kyoo &#xff1f; Kyoo 是一款开源媒体浏览器&#xff0c;可让您流式传输电影、电视节目或动漫。它是 Plex、Emby 或 Jellyfin 的替代品。Kyoo 是从头开始创建的&#xff0c;它不是一个分叉。一切都将永远是免费和开源的。 软件特性&#xff1a; 管理您的电影、电视剧…

QT : 仿照QQ 完成弹出登录窗口,并实例化组件

1. 运行效果图 2. Headers #ifndef MAINWINDOW_H #define MAINWINDOW_H#include <QMainWindow>class MainWindow : public QMainWindow {Q_OBJECTpublic:MainWindow(QWidget *parent nullptr);~MainWindow(); }; #endif // MAINWINDOW_H 3. mainWindow.cpp &#xff1a…

SpringMVC之JSON返回及异常处理机制

目录 一、JSON处理 1.1 导入依赖 1.2 配置Spring-mvc.xml 1.3 ResponseBody注解使用 ​编辑 1.4 Jackson 1.4.1 定义 1.4.2 用途 1.4.3 用法 1.4.4 常用注解 1.5 作用 二、统一异常处理 2.1 为什么要全局异常处理&#xff1f; 2.2 异常处理思路 2.3 SpringMVC异…