[计网] TCP/UDP对比
一、UDP协议
1.1 UDP定义及报文格式
udp:user datagram protocol 用户数据协议
- 16位UDP长度表示整个数据报
(UDP首部+UDP数据)
的长度 - 如果校验和出错,就会直接丢弃(UDP校验首部和数据部分)
UDP是一种全双工
通信协议。 UDP协议首部中有一个16位的大长度. 也就是说一个UDP能传输的报文长度是64K
(包含UDP首部)。
如果我们需要传输的数据超过64K, 就需要在应用层手动的分包, 多次发送, 并在接收端手动拼装。
1.2 提供的服务
1)无连接服务:发送和接受之间无捂手协议
2)尽力而为服务:UDP报文段可能丢失,可能乱序
1.3 功能以及特点
功能:多路复用/分用 ;校验和差错检检测
特点:1)无连接:无须建立连接,只知道对端的IP和端口号就可以发送,不需要实现建立连接;可支持更多活跃用户
2)不可靠:没有确认机制,也没有重传机制,如果因为网络故障无法发到对方,UDP报文段可能丢失,可能乱序,UDP协议也不会给应用层返回任何错误信息
3)面向数据报:只要应用进程将数据传递给UDP, UDP会将数据立即打包并原样发送给网络层,既不会拆分,也不会合并。如果发送端调用一次sendto
, 发送100个字节, 那么接收端也必须调用对应的一次recvfrom, 接收100个 字节,而不能循环调用10次recvfrom,每次接受10字节。所以UDP不能够灵活的控制读写数据的次数和数量。
4)UDP存在接收缓冲区,但不存在发送缓冲区。
- UDP没有发送缓冲区,在调用sendto时会直接将数据交给内核,由内核将数据传给网络层协议进行后续的传输动作。为什么UDP不需要发送缓冲区? 因为UDP不保证可靠性,它没有重传机制,当报文丢失时,UDP不需要重新发送,而TCP不同,他必须具备发送缓冲区,当报文丢失时,TCP必须保证重新发送,用户不会管,所以必须要具备发送缓冲区。
- UDP具有接收缓冲区,但是这个接收缓冲区不能保证收到的UDP报文的顺序和发送UDP报的顺序一致,如果缓冲区满了再到达的UDP数据报就会被丢弃。
UDP接收缓冲区和丢包问题:https://blog.csdn.net/ljh0302/article/details/49738191
1.4 UDP应用场景
1.需要资源少,网络情况比较好的内网,或对丢包不敏感的应用,如:DHCP协议
2.不需要一对一沟通建立连接,可以广播的应用.如:DHCP协议(基于广播协议);IGMP协议(互联网管理协议,组播),VXLAN协议(虚拟扩展局域网,组播)
3.要求处理速度快.低时延,可容忍少量丢包,即便自己网络拥塞,也毫不退缩一往无前的应用。如果要可靠,通常应用程序自己实现。如:
- QUIC(Quick Udp Internet Connection)-google的一种基于UDP改进的通信协议。降低网络通信延迟,提供更好的互动体验。
- 流媒体RTMP (Real Time Messaging Protocol);实时游戏
- 物联网-物联网通信协议Thread
- 移动通信-GTP(GPRS Tunnelling Protocol GPRS隧道协议)协议本身包含复杂的手机上线下线的通信协议,传输层协议简化了,基于UDP
4.常见的基于UDP的应用层协议
- NFS:网络文件系统
- TFTP:简单文件传输协议
- DHCP:动态主机
配置
协议 - BOOTP:启动协议(用于无盘设备启动)
- DNS:域名
解析
协议 - 程序员在写UDP程序时自己定义的协议
二、TCP协议
2.1 TCP协议报文
- TCP全称为传输控制协议,必须对数据的传输进行控制
- TCP是面向字节流的协议,序号为TCP携带数据的第一个字节的编号
- 源端口号:本次
TCP
连接中,发起连接的主机使用的端口号; - 目的端口号:本次
TCP
连接主,接受连接的主机使用的端口号; - 序号:通过TCP传输的每一个数据段,都有一个序号,作用是为了确认此数据段的顺序。网络中允许传输的数据长度是有限制的,所以当我们要通过
TCP
传输一个较大的数据时,TCP
会将数据切割成很多小的数据段进行传输。而将这些小的数据段发送到目的主机时(发送方会同时发送多个数据),并不能保证它们是按顺序到达目的地,所以对于每一个数据段,都要有一个序号,来标识它们是属于总数据的哪一部分,以保证在目的主机中能将他们重新拼接。比如:一个报文段的序号为300,此报文段数据部分共有100字节,则下一个报文段的序号为401。 - 32位确认序号:接收方若接收到一个数据段,会发送一个确认报文给发送方,告诉发送方已经接收到这个数据段,而确认序号的作用就是告诉发送方接收到了哪条数据段。确认号只有当
ACK
标志为1时才有效。若接收方接收到了序号为n
的报文段,则确认序号将是n+1
,表示它已经接收了n
,下一条想要接收n+1
; - 4位首部长度(偏移长度):
TCP
报文的首部+选项的字节数;表示该TCP头部有多少个32位bit
(有多少个4字节),所以TCP头部大长度是15 * 4 = 60
。根据该部分可以将TCP报头和有效载荷分离。TCP报文默认大小为20个字节。 - URG:它为了标志紧急指针是否有效
- PSH:提示接收端应用程序立即将接收缓冲区的数据拿走。
- ACK:只有
1 bit
的标志位,若为1
,表示这个数据段中的确认序号是有效的,即这个数据报是对之前接收到的某个报文的确认(一个TCP
报文可以同时作为确认报文和传递数据报文)。 - RST:只有
1 bit
的标志位,若客户端向服务器的一个端口请求建立TCP
连接,但是服务器的那个端口并不允许建立连接(比如没开启此端口),则服务器会回送一个TCP
报文,将RST
位置为1,告诉客户端不要再向这个端口发起连接; - SYN:只有
1 bit
的标志位,若为1
,表示这是一条建立连接的TCP
报文段; - FIN:只有
1 bit
的标志位,若为1
,表示这是一条断开连接的TCP
报文段; - 16位的
紧急
指针:按序到达是TCP协议
保证可靠性的一种机制,但是也存在一些报文想优先被处理,这时就可以设置紧急指针
,指向该报文即可,同时将紧急指针有效位置位1
。 -
16位窗口大小:如果发送方发送大量数据,接收方接收不过来,会导致大量数据丢失。然后接收方可以发送给发送发消息让发送方发慢一点,这是流量控制。接收方将自己接收缓冲器剩余空间的大小告诉发送方叫做16位窗口大小。发送发可以根据窗口大小来适配发送的速度和大小,窗口大小最大是2的16次方,及64KB,但也可以根据选项中的某些位置扩展,最大扩展1G
- 16位校验和:发送端填充,
CRC
校验。如果接收端校验不通过, 则认为数据有问题(此处的检验和不光包含TCP首部
也包含TCP数据部分
)。
2.2 TCP 可靠传输
2.2.1 TCP的可靠传输
所谓的可靠,就是能保证数据的正确性,无差错、不丢失、不重复、并且按序达到。
TCP首先采用三次握手来建立连接、四次挥手来释放连接。其次TCP采用了连续ARQ协议,即自动重传请求(Automatic Repeat-reQuest)来保证数据传输的正确性,使用滑动窗口协议来保证接收方能够及时处理接收到的数据,进行流量控制。最后TCP使用慢开始、拥塞避免、快重传、快恢复来进行拥塞控制,避免网络拥堵
2.2.2 TCP可靠传输的实现方式
-
检验和
计算方式:在数据传输的过程中,将发送的数据段都当做一个16位的整数。将这些整数加起来。并且前面的进位不能丢弃,补在后面,最后取反,得到校验和。
发送方:在发送数据之前计算检验和,并进行校验和的填充。
接收方:收到数据后,对数据以同样的方式进行计算,求出校验和,与发送方的进行比对。
注意:如果接收方比对校验和与发送方不一致,那么数据一定传输有误。但是如果接收方比对校验和与发送方一致,数据不一定传输成功
-
确认应答与序列号
序列号:TCP传输时将每个字节的数据都进行了编号,这就是序列号。
确认应答:TCP传输的过程中,每次接收方收到数据后,都会对传输方进行确认应答。也就是发送ACK报文。这个ACK报文当中带有对应的确认序列号,告诉发送方,接收到了哪些数据,下一次的数据从哪里发。
-
超时重传
在进行TCP传输时,由于确认应答与序列号机制,也就是说发送方发送一部分数据后,都会等待接收方发送的ACK报文,并解析ACK报文,判断数据是否传输成功。如果发送方发送完数据后,迟迟没有等到接收方的ACK报文,这该怎么办呢?而没有收到ACK报文的原因可能是什么呢?
首先,发送方没有介绍到响应的ACK报文原因可能有两点:
- 数据在传输过程中由于网络原因等直接全体丢包,接收方根本没有接收到。
- 接收方接收到了响应的数据,但是发送的ACK报文响应却由于网络原因丢包了。
TCP在解决这个问题的时候引入了一个新的机制,叫做超时重传机制。简单理解就是发送方在发送完数据后等待一个时间,时间到达没有接收到ACK报文,那么对刚才发送的数据进行重新发送。如果是刚才第一个原因,接收方收到二次重发的数据后,便进行ACK应答。如果是第二个原因,接收方发现接收的数据已存在(判断存在的根据就是序列号,所以上面说序列号还有去除重复数据的作用),那么直接丢弃,仍旧发送ACK应答。
如果主机A发送给主机B的报文,主机B在规定的时间内没有及时收到主机A发送的报文,我们可以认为是ACK丢了,这时就需要触发超时重传机制。
如果主机A未收到B发来的确认应答,也可能是因为ACK丢了。因此主机B会收到很多重复的数据,那么,TCP协议需要能够识别出那些包是重复的包,并且把重复的包丢弃,这时候我们可以用前面提到的序列号,很容易做到去重的效果
那么发送方发送完毕后等待的时间是多少呢?如果这个等待的时间过长,那么会影响TCP传输的整体效率,如果等待时间过短,又会导致频繁的发送重复的包。如何权衡?
由于TCP传输时保证能够在任何环境下都有一个高性能的通信,因此这个最大超时时间(也就是等待的时间)是动态计算的。超时重传的时间设置的太短,会引起很多报文的不必要重传;
时间设置的过长,又会使网络的空闲时间增大,降低传输效率;
TCP采用了一种自适应算法,它记录一个报文发出的时间,以及收到相应确认的时间,者两个时间之差就是报文的往返时间RTT;
最理想的情况下,找到一个最小的时间,保证确认应答一定能在这个时间内返回
Linux中,超时以500s为一个单位进行控制,每次判定超时重发的超时时间都是500ms的整数倍;如果重发一次仍然得不到应答,等待2*500ms后再进行重传;如果仍然得不到应答,等待4*500ms进行重传,依次类推,以指数形式递增;累积到一定的重传次数,TCP认为网络或者对端主机出现异常,强制关闭连接。
快速重传:
-
连接管理
[计网]TCP/IP 三次握手四次挥手 - S1mmons - 博客园 (cnblogs.com)
-
流量控制
所谓流量控制,就是让发送方的发送速率不要太快,要让对方来得及接受,流量控制的实现方法:接收端将自己可接受的缓冲区大小放入TCP首部中的”窗口大小字段”,通过ACK通知发送端;窗口大小字段越大,说明网络的吞吐量越高;接收端一旦发现自己的缓冲区快满了,就会将窗口大小设置成一个更小的值给发送端;发送端接受到这个窗口之后,就会减慢自己的发送速率;如果接受缓冲区满了,就会将窗口设置为0,这时发送方不在发送数据,但是需要定期发送一个窗口探测数据段,使接收端把窗口大小告诉发送端。
利用滑动窗口来实现流量控制。
发送方的发送窗口,不能超过接收方给出的接受窗口的数值。
当发送一次数据,等到确认应答时才可以发送下一个数据段,这样的效率会很低,我们利用滑动窗口,无需等待确认应答而可以继续发送数据的最大值;收到第一个ACK后,滑动窗口向后移;*操作系统为了维护这个滑动窗口,需要开辟发送缓冲区来记录当前还有那些数据没有应答,只有确认应答过的数据,才能从缓冲区删除掉;窗口越大,网络的吞吐率越高***TCP为每一个连接设有一个持续计时器,只要TCP连接的一方收到对方的零窗口通知,就启动持续计时器,若持续计时器设置的时间到期,就发送一个零窗口探测报文段(仅携带一个字节的数据),对方就在确认这个探测报文段时给出了现在的窗口值,如果仍然是0,那么收到这个报文段的一方就重新设置持续计时器;如果窗口不是0,那么死锁的僵局就可以打破。
TCP缓存空间
TCP是面向连接的协议,一旦建立一条TCP连接,两个应用程序可以互相发送数据 TCP连接的两端都有各自发送缓存和接收缓存 客户进程通过socket传递数据流,数据一旦进入传输层,由TCP控制,TCP将数据引导到发送缓存中。TCP会从发送缓存中取出一块数据,并将数据传递到网络层中。 1)TCP规范中未指明何时发送 2)TCP从缓存中取出并放入报文段的数据量不能超过最大报文长度MSS TCP另一端接收另一个报文段,将报文段的数据放入TCP连接的接收缓存,应用程序从接收缓存中读取数据流
MSS
MSS(max segment size)——选项字段 TCP 从缓冲区中取出放在报文段中的数据数量受限于MSS 最大报文段MSS的选择 1)连接两端位于同一物理网络:选择的MSS应使IP数据报的大小与网络MTU相适应 MSS<=MTU(直连LAN)-TCP头-IP 以太网MSS=1500-20-20=1460B(不包含选项字段) 2)连接两端可以协商MSS,每个连接方通常在握手的第一步中指明这个选项。它指明本段所能接受的最大长度的报文段 TCP发送大文件时,会将文件划分成长度为MSS的若干块
流量控制
流量控制:控制发送端的发送速率
建立连接时,各端分配一个缓冲区用来存储接收的数据,并将缓冲区的尺寸发送给另一端。接收方发送的确认消息中包含了自己剩余的缓冲区尺寸。剩余缓冲区空间的数量叫做窗口。其实就是建立连接的双虎互相知道彼此剩余的缓冲区大小。
通告窗口(大小可变):1)rcvbuffer:接收端为接收数据分配的缓冲区(默认4096B)
2)发送方和接收方都有接收窗口(rwnd)来提供流量控制,此缓冲空间的大小是随时间变化的。发送窗口在连接建立时由双方商定。但在通信的过程中,接收端可根据自己的资源情况,随时动态地调整对方的发送窗口上限值(可增大或减小)
3)在TCP报文段首部的窗口字段写入的数值就是当前给对方设置的发送窗口数值的上限。
利用滑动窗口机制可以很方便地在TCP连接上实现流量控制
TCP的滑动窗口都是以字节为单位的。凡是已发送过的数据,在未收到确认之前,都必须暂时保留,以便在超时重传时使用。发送窗口里面的序号表示允许发送的序号,发送窗口后沿的后面部分表示已经发送并且已经得到确认。
-
拥塞控制
在某段时间,若对网络中某一资源的需求超过了该资源所能提供的可用部分,网络性能就要变坏,这种情况就叫做网络拥塞。
在计算机网络中数位链路容量(即带宽)、交换结点中的缓存和处理机等,都是网络的资源。若出现拥塞而不进行控制,整个网络的吞吐量将随输入负荷的增大而下降。
当输入的负载到达一定程度 吞吐量不会增加,即一部分网络资源会丢失掉,网络的吞吐量维持在其所能控制的最大值,转发节点的缓存不够大这造成分组的丢失是拥塞的征兆。
TCP的四种拥塞控制算法
1.慢开始
2.拥塞控制
3.快重传
4.快恢复
假定:
1.数据是单方向传送,而另一个方向只传送确认
2.接收方总是有足够大的缓存空间,因而发送发发送窗口的大小由网络的拥塞程度来决定
3.以TCP报文段的个数为讨论问题的单位,而不是以字节为单位
示例如下:
传输轮次:发送方给接收方发送数据报文段后,接收方给发送方发回相应的确认报文段,一个传输轮次所经历的时间就是往返时间RTT(RTT并非是恒定的数值),使用传输轮次是为了强调,把拥塞窗口cwnd所允许发送的报文段都连续发送出去,并收到了对已发送的最后一个报文段的确认,拥塞窗口cwnd会随着网络拥塞程度以及所使用的拥塞控制算法动态变化。
在tcp双方建立逻辑链接关系时, 拥塞窗口cwnd的值被设置为1,还需设置慢开始门限ssthresh,在执行慢开始算法时,发送方每收到一个对新报文段的确认时,就把拥塞窗口cwnd的值加一,然后开始下一轮的传输,当拥塞窗口cwnd增长到慢开始门限值时,就使用拥塞避免算法。
示例如下:
传输轮次:发送方给接收方发送数据报文段后,接收方给发送方发回相应的确认报文段,一个传输轮次所经历的时间就是往返时间RTT(RTT并非是恒定的数值),使用传输轮次是为了强调,把拥塞窗口cwnd所允许发送的报文段都连续发送出去,并收到了对已发送的最后一个报文段的确认,拥塞窗口cwnd会随着网络拥塞程度以及所使用的拥塞控制算法动态变化。
在tcp双方建立逻辑链接关系时, 拥塞窗口cwnd的值被设置为1,还需设置慢开始门限ssthresh,在执行慢开始算法时,发送方每收到一个对新报文段的确认时,就把拥塞窗口cwnd的值加一,然后开始下一轮的传输,当拥塞窗口cwnd增长到慢开始门限值时,就使用拥塞避免算法。
慢开始:
假设当前发送方拥塞窗口cwnd的值为1,而发送窗口swnd等于拥塞窗口cwnd,因此发送方当前只能发送一个数据报文段(拥塞窗口cwnd的值是几,就能发送几个数据报文段),接收方收到该数据报文段后,给发送方回复一个确认报文段,发送方收到该确认报文后,将拥塞窗口的值变为2,
发送方此时可以连续发送两个数据报文段,接收方收到该数据报文段后,给发送方一次发回2个确认报文段,发送方收到这两个确认报文后,将拥塞窗口的值加2变为4,发送方此时可连续发送4个报文段,接收方收到4个报文段后,给发送方依次回复4个确认报文,发送方收到确认报文后,将拥塞窗口加4,置为8,发送方此时可以连续发送8个数据报文段,接收方收到该8个数据报文段后,给发送方一次发回8个确认报文段,发送方收到这8个确认报文后,将拥塞窗口的值加8变为16,
当前的拥塞窗口cwnd的值已经等于慢开始门限值,之后改用拥塞避免算法。
拥塞避免:
也就是每个传输轮次,拥塞窗口cwnd只能线性加一,而不是像慢开始算法时,每个传输轮次,拥塞窗口cwnd按指数增长。同理,16+1……直至到达24,假设24个报文段在传输过程中丢失4个,接收方只收到20个报文段,给发送方依次回复20个确认报文段,一段时间后,丢失的4个报文段的重传计时器超时了,发送发判断可能出现拥塞,更改cwnd和ssthresh.并重新开始慢开始算法,如图所示:
快速重传:
发送方发送1号数据报文段,接收方收到1号报文段后给发送方发回对1号报文段的确认,在1号报文段到达发送方之前,发送方还可以将发送窗口内的2号数据报文段发送出去,接收方收到2号报文段后给发送方发回对2号报文段的确认,在2号报文段到达发送方之前,发送方还可以将发送窗口内的3号数据报文段发送出去,
假设该报文丢失,发送方便不会发送针对该报文的确认报文给发送方,发送方还可以将发送窗口内的4号数据报文段发送出去,接收方收到后,发现这不是按序到达的报文段,因此给发送方发送针对2号报文段的重复确认,表明我现在希望收到的是3号报文段,但是我没有收到3号报文段,而收到了未按序到达的报文段,发送方还可以将发送窗口中的5号报文段发送出去,接收方收到后,发现这不是按序到达的报文段,因此给发送方发送针对2号报文段的重复确认,表明我现在希望收到的是3号报文段,但是我没有收到3号报文段,而收到了未按序到达的报文段,,发送方还可以将发送窗口内的最后一个数据段即6号数据报文段发送出去,接收方收到后,发现这不是按序到达的报文段,因此给发送方发送针对2号报文段的重复确认,表明我现在希望收到的是3号报文段,但是我没有收到3号报文段,而收到了未按序到达的报文段,
此时,发送方收到了累计3个连续的针对2号报文段的重复确认,立即重传3号报文段,接收方收到后,给发送方发回针对6号报文的确认,表明,序号到6为至的报文都收到了,这样就不会造成发送方对3号报文的超时重传,而是提早收到了重传。
三、TCP与UDP的区别
区别一、是否基于连接
TCP是面向连接的协议,而UDP是无连接的协议。即TCP面向连接;UDP是无连接的,即发送数据之前不需要建立连接。
区别二、可靠性 和 有序性 区别
TCP 提供交付保证(Tcp通过校验和,重传控制,序号标识,滑动窗口、确认应答实现可靠传输),无差错,不丢失,不重复,且按序到达,也保证了消息的有序性。该消息将以从服务器端发出的同样的顺序发送到客户端,尽管这些消息到网络的另一端时可能是无序的。TCP协议将会为你排好序。
UDP不提供任何有序性或序列性的保证。UDP尽最大努力交付,数据包将以任何可能的顺序到达。
TCP的逻辑通信信道是全双工的可靠信道,UDP则是不可靠信道
区别三、实时性
UDP具有较好的实时性,工作效率比TCP高,适用于对高速传输和实时性有较高的通信或广播通信。
区别四、协议首部大小
TCP首部开销20字节; UDP的首部开销小,只有8个字节 。
区别五、运行速度
TCP速度比较慢,而UDP速度比较快,因为TCP必须创建连接,以保证消息的可靠交付和有序性,毕竟TCP协议比UDP复杂。
区别六、拥塞机制
UDP没有拥塞控制,因此网络出现拥塞不会使源主机的发送速率降低(对实时应用很有用,如IP电话,实时视频会议等)
区别七、流模式(TCP)与数据报模式(UDP);
TCP面向字节流,实际上是TCP把数据看成一连串无结构的字节流;
UDP是面向报文的 。
区别八、资源占用
TCP对系统资源要求较多,UDP对系统资源要求较少。
TCP被认为是重量级的协议,而与之相比,UDP协议则是一个轻量级的协议。因为UDP传输的信息中不承担任何间接创造连接,保证交货或秩序的的信息。这也反映在用于承载元数据的头的大小。
区别九、应用
每一条TCP连接只能是点到点的;UDP支持一对一,一对多,多对一和多对多的交互通信 。基于UDP不需要建立连接,所以且适合多播的环境,UDP是大量使用在游戏和娱乐场所。
基于上面的区别;TCP和UDP的优缺点也很明显了。
UDP 优点:简单、传输快。
(1)网速的提升给UDP的稳定性提供可靠网络保障,丢包率很低,如果使用应用层重传,能够确保传输的可靠性。
(2)TCP为了实现网络通信的可靠性,使用了复杂的拥塞控制算法,建立了繁琐的握手过程,由于TCP内置的系统协议栈中,极难对其进行改进。采用TCP,一旦发生丢包,TCP会将后续的包缓存起来,等前面的包重传并接收到后再继续发送,延时会越来越大,基于UDP对实时性要求较为严格的情况下,采用自定义重传机制,能够把丢包产生的延迟降到最低,尽量减少网络问题对游戏性造成影响。
缺点:不可靠,不稳定;
UDP应用场景:
1.面向数据报方式
2.网络数据大多为短消息
3.拥有大量Client
4.对数据安全性无特殊要求
5.网络负担非常重,但对响应速度要求高
TCP:
优点:可靠 稳定
TCP的可靠体现在TCP在传输数据之前,会有三次握手来建立连接,而且在数据传递时,有确认. 窗口. 重传. 拥塞控制机制,在数据传完之后,还会断开来连接用来节约系统资源。
缺点:慢,效率低,占用系统资源高,易被攻击
TCP应用场景:
当对网络质量有要求时,比如HTTP,HTTPS,FTP等传输文件的协议;POP,SMTP等邮件传输的协议。
四、参考
1、 深入理解TCP、UDP协议及两者的区别_striveb的博客-CSDN博客_udp协议和tcp协议
2、TCP和UDP详解(非常详细)_HanSion.Z-CSDN博客_tcp和udp
3、 网络基础:TCP协议-如何保证传输可靠性_Chenxi13-CSDN博客_tcp如何保证数据传输的可靠性
4、TCP和UDP的区别及各自优缺点_随、心所遇 的博客-CSDN博客_tcp和udp的区别
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 全程不用写代码,我用AI程序员写了一个飞机大战
· DeepSeek 开源周回顾「GitHub 热点速览」
· MongoDB 8.0这个新功能碉堡了,比商业数据库还牛
· 记一次.NET内存居高不下排查解决与启示
· 白话解读 Dapr 1.15:你的「微服务管家」又秀新绝活了