go的net/http有哪些值得关注的细节?

原创 小白debug 2023-08-14 08:33

golang的net/http库是我们平时写代码中,非常常用的标准库。由于go语言拥有goroutine,goroutine的上下文切换成本比普通线程低很多,net/http库充分利用了这个优势,因此,它的内部实现跟其他语言会有一些区别。

其中最大的区别在于,其他语言中,一般是多个网络句柄共用一个或多个线程,以此来减少线程之间的切换成本。而golang则会为每个网络句柄创建两个goroutine,一个用于读数据,一个用于写数据。

读写协程

下图是net/http源码中创建这两个goroutine的地方。

源码中创建两个协程的地方

了解它的内部实现原理,可以帮助我们写出更高性能的代码,以及避免协程泄露造成的内存泄漏问题。

这篇文章是希望通过几个例子让大家对net/http的内部实现有更直观的理解。


连接与协程数量的关系

首先我们来看一个例子。

func main() {
    tr := &http.Transport{
        MaxIdleConns:    100,
        IdleConnTimeout: 3 * time.Second,
    }

    n := 5
    for i := 0; i < n; i++ {
        req, _ := http.NewRequest("POST""https://www.baidu.com"nil)
        req.Header.Add("content-type""application/json")
        client := &http.Client{
            Transport: tr,
            Timeout:   3 * time.Second,
        }
        resp, _ := client.Do(req)
        _, _ = ioutil.ReadAll(resp.Body)
        _ = resp.Body.Close()
    }
    time.Sleep(time.Second * 5)
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

上面的代码做的事情很简单,执行5次循环http请求,最终通过runtime.NumGoroutine()方法打印当前的goroutine数量。

代码里只有三个地方需要注意:

  1. 1. Transport设置了一个3s的空闲连接超时

  2. 2. for循环执行了5次http请求

  3. 3. 程序退出前执行了5s sleep

答案输出1。也就是说当程序退出的时候,当前的goroutine数量为1,毫无疑问它指的是正在运行main方法的goroutine,后面我们都叫它main goroutine

再来看个例子。

func main() {
    tr := &http.Transport{
        MaxIdleConns:    100,
        IdleConnTimeout: 3 * time.Second,
    }

    n := 5
    for i := 0; i < n; i++ {
        req, _ := http.NewRequest("POST""https://www.baidu.com"nil)
        req.Header.Add("content-type""application/json")
        client := &http.Client{
            Transport: tr,
            Timeout:   3 * time.Second,
        }
        resp, _ := client.Do(req)
        _, _ = ioutil.ReadAll(resp.Body)
        _ = resp.Body.Close()
    }
    time.Sleep(time.Second * 1)
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

在原来的基础上,我们程序退出前的睡眠时间,从5s改成1s,此时输出3。也就是说除了main方法所在的goroutine,还多了两个goroutine,我们大概也能猜到,这就是文章开头提到的读goroutine和写goroutine。也就是说程序在退出时,还有一个网络连接没有断开。

这是一个TCP长连接。

HTTP1.1底层依赖TCP

网络五层模型中,HTTP处于应用层,它的底层依赖了传输层的TCP协议。

当我们发起http请求时,如果每次都要建立新的TCP协议,那就需要每次都经历三次握手,这会影响性能,因此更好的方式就是在http请求结束后,不立马断开TCP连接,将它放到一个空闲连接池中,后续有新的http请求时就复用该连接。

像这种长时间存活,被多个http请求复用的TCP连接,就是所谓的长连接。反过来,如果每次HTTP请求结束就将TCP连接进行四次挥手断开,下次有需要执行HTTP调用时就再建立,这样的TCP连接就是所谓的短连接

HTTP1.1之后默认使用长连接。

连接池复用连接

那为什么这跟5s和1s有关系?

这是因为长连接在空闲连接池也不能一直存放着,如果一直没被使用放着也是浪费资源,因此会有个空闲回收时间,也就是上面代码中的IdleConnTimeout,我们设置的是3s,当代码在结束前sleep了5s后,长连接就已经被释放了,因此输出结果是只剩一个main goroutine。当sleep 1s时,长连接还在空闲连接池里,因此程序结束时,就还剩3个goroutine(main goroutine+网络读goroutine+网络写goroutine)。

我们可以改下代码下验证这个说法。我们知道,HTTP可以通过connectionheader头来控制这次的HTTP请求是用的长连接还是短连接。connection:keep-alive 表示http请求结束后,tcp连接保持存活,也就是长连接, connection:close则是短连接。

req.Header.Add("connection""close")

就像下面这样。

func main() {
    tr := &http.Transport{
        MaxIdleConns:    100,
        IdleConnTimeout: 3 * time.Second,
    }

    n := 5
    for i := 0; i < n; i++ {
        req, _ := http.NewRequest("POST""https://www.baidu.com"nil)
        req.Header.Add("content-type""application/json")
        req.Header.Add("connection""close")
        client := &http.Client{
            Transport: tr,
            Timeout:   3 * time.Second,
        }
        resp, _ := client.Do(req)
        _, _ = ioutil.ReadAll(resp.Body)
        _ = resp.Body.Close()
    }
    time.Sleep(time.Second * 1)
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

此时,会发现,程序重新输出1。完全符合我们预期。


resp.body是否读取对连接复用的影响

func main() {
   n := 5
   for i := 0; i < n; i++ {
      resp, _ := http.Get("https://www.baidu.com")
      _ = resp.Body.Close()
   }
   fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

注意这里没有执行 ioutil.ReadAll(resp.Body)。也就是说http请求响应的结果并没有被读取的情况下,net/http库会怎么处理。

上面的代码最终输出3,分别是main goroutine,read goroutine 以及write goroutine。也就是说长连接没有断开,那长连接是会在下一次http请求中被复用吗?先说答案,不会复用

我们可以看代码。resp.Body.Close() 会执行到 func (es * bodyEOFSignal) Close() error 中,并执行到es.earlyCloseFn()中。

earlyCloseFn的逻辑也非常简单,就是将一个false传入到waitForBodyRead的channel中。那写入通道后的数据会在另外一个地方被读取,我们来看下读取的地方。

bodyEOF为false, 也就不需要执行 tryPutIdleConn()方法。

tryPutIdleConn会将连接放到长连接池中备用)。

最终就是alive=bodyEOF ,也就是false,字面意思就是该连接不再存活。因此该长连接并不会复用,而是会释放。

那为什么output输出为3?这是因为长连接释放需要时间。

我们可以在结束前加一个休眠,比如再执行休眠1毫秒

func main() {
    n := 5
    for i := 0; i < n; i++ {
        resp, _ := http.Get("https://www.baidu.com")
        _ = resp.Body.Close()
    }
    time.Sleep(time.Millisecond * 1)
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

此时就会输出1。说明协程是退出中的,只是没来得及完全退出,休眠1ms后彻底退出了。

如果我们,将在代码中重新加入 ioutil.ReadAll(resp.Body),就像下面这样。

func main() {
    n := 5
    for i := 0; i < n; i++ {
        resp, _ := http.Get("https://www.baidu.com")
        _, _ = ioutil.ReadAll(resp.Body)
        _ = resp.Body.Close()
    }
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

此时,output还是输出3,但这个3跟上面的3不太一样,休眠5s后还是输出3。这是因为长连接被推入到连接池了,连接会重新复用。

下面是源码的解释。


body.close()不执行会怎么样

网上都说不执行body.close()会协程泄漏(导致内存泄露),真的会出现协程泄漏吗,如果泄漏,会泄漏多少?

func main() {
    tr := &http.Transport{
        MaxIdleConns:    100,
        IdleConnTimeout: 3 * time.Second,
    }

    n := 5
    for i := 0; i < n; i++ {
        req, _ := http.NewRequest("POST""https://www.baidu.com"nil)
        req.Header.Add("content-type""application/json")
        client := &http.Client{
            Transport: tr,
        }
        resp, _ := client.Do(req)
        _, _ = ioutil.ReadAll(resp.Body)
        //_ = resp.Body.Close()
    }
    time.Sleep(time.Second * 1)
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

我们可以运行这段代码,代码中将resp.body.close()注释掉,结果输出3。debug源码,会发现连接其实复用了。代码执行到tryPutIdleConn函数中,会将连接归还到空闲连接池中。

休眠5s,结果输出1,这说明达到idleConnTimeout,空闲连接断开。看起来一切正常。

resp.Body.Close()那一行代码重新加回来,也就是下面这样,会发现代码结果依然输出3我们是否删除这行代码,对结果没有任何影响。

func main() {
    tr := &http.Transport{
        MaxIdleConns:    100,
        IdleConnTimeout: 3 * time.Second,
    }

    n := 5
    for i := 0; i < n; i++ {
        req, _ := http.NewRequest("POST""https://www.baidu.com"nil)
        req.Header.Add("content-type""application/json")
        client := &http.Client{
            Transport: tr,
        }
        resp, _ := client.Do(req)
        _, _ = ioutil.ReadAll(resp.Body)
        _ = resp.Body.Close()
    }
    time.Sleep(time.Second * 1)
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

既然执不执行body.close()都没啥区别,那body.close()的作用是什么呢?

它是为了标记当前连接请求中,response.body是否使用完毕,如果不执行body.close(),则resp.Body中的数据是可以不断重复读且不报错的(但不一定能读到数据),执行了body.close(),再次去读取resp.Body则会报错,如果resp.body数据读一半,处理代码逻辑就报错了,此时你不希望其他地方继续去读,那就需要使用body.close()去关闭它。这更像是一种规范约束,它可以更好的保证数据正确。

也就是说不执行body.close(),并不一定会内存泄露。那么什么情况下会协程泄露呢?

直接说答案,既不执行 ioutil.ReadAll(resp.Body) 也不执行resp.Body.Close(),并且不设置http.Clienttimeout的时候,就会导致协程泄露

比如下面这样。

func main() {
    tr := &http.Transport{
        MaxIdleConns:    100,
        IdleConnTimeout: 3 * time.Second,
    }

    n := 5
    for i := 0; i < n; i++ {
        req, _ := http.NewRequest("POST""https://www.baidu.com"nil)
        req.Header.Add("content-type""application/json")
        client := &http.Client{
            Transport: tr,
        }
        resp, _ := client.Do(req)
        _ = resp
    }
    time.Sleep(time.Second * 5)
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

最终结果会输出11,也就是1个main goroutine + (1个read goroutine + 1个read goroutine)* 5次http请求。

前面提到,不执行ioutil.ReadAll(resp.Body),网络连接无法归还到连接池不执行resp.Body.Close(),网络连接就无法为标记为关闭,也就无法正常断开。因此能导致协程泄露,非常好理解。

但http.Client内timeout有什么关系?这是因为timeout是指,从发起请求到从resp.body中读完响应数据的总时间,如果超过了,网络库会自动断开网络连接,并释放read+write goroutine。因此如果设置了timeout,则不会出现协程泄露的问题。

另外值得一提的是,我看到有不少代码都是直接用下面的方式去做网络请求的。

resp, _ := http.Get("https://www.baidu.com")

这种方式用的是DefaultClient,是没有设置超时的,生产环境中使用不当,很容易出现问题。

func Get(url string) (resp *Response, err error) {
    return DefaultClient.Get(url)
}

var DefaultClient = &Client{}


连接池的结构

我们了解到连接池可以复用网络连接,接下来我们通过一个例子来看看网络连接池的结构。


func main() {
    tr := &http.Transport{
        MaxIdleConns:    100,
        IdleConnTimeout: 3 * time.Second,
    }

    n := 5
    for i := 0; i < n; i++ {
        req, _ := http.NewRequest("POST""http://www.baidu.com"nil)
        req.Header.Add("content-type""application/json")
        client := &http.Client{
            Transport: tr,
            Timeout:   3 * time.Second,
        }
        resp, _ := client.Do(req)
        _, _ = ioutil.ReadAll(resp.Body)
        _ = resp.Body.Close()
    }
    time.Sleep(time.Second * 1)
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

注意这里请求的不是https,而是http。最终结果输出5,为什么?

这是因为,http://www.baidu.com会返回307,重定向到https://www.baidu.com

http重定向为https

在网络中,我们可以通过一个五元组来唯一确定一个TCP连接。

五元组

它们分别是源ip,源端口,协议,目的ip,目的端口。只有当多次请求的五元组一样的情况下,才有可能复用连接。

放在我们这个场景下,源ip、源端口、协议都是确定的,也就是两次http请求的目的ip或目的端口有区别的时候,就需要使用不同的TCP长连接。

而http用的是80端口,https用的是443端口。于是连接池就为不同的网络目的地建立不同的长连接。

因此最终结果5个goroutine,其实2个goroutine来自http,2个goroutine来自https,1个main goroutine。

我们来看下源码的具体实现。net/http底层通过一个叫idleConnmap去存空闲连接,也就是空闲连接池。

idleConn这个map的key是协议和地址,其实本质上就是ip和端口。map的value是长连接的数组([]*persistConn),说明net/http支持为同一个地址建立多个TCP连接,这样可以提升传输的吞吐。

连接池的结构和逻辑


Transport是什么?

Transport本质上是一个用来控制http调用行为的一个组件,里面包含超时控制,连接池等,其中最重要的是连接池相关的配置。

我们通过下面的例子感受下。

func main() {
    n := 5
    for i := 0; i < n; i++ {
        httpClient := &http.Client{}
        resp, _ := httpClient.Get("https://www.baidu.com")
        _, _ = ioutil.ReadAll(resp.Body)
        _ = resp.Body.Close()
    }
    time.Sleep(time.Second * 1)
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}
func main() {
    n := 5
    for i := 0; i < n; i++ {
        httpClient := &http.Client{
            Transport:  &http.Transport{},
        }
        resp, _ := httpClient.Get("https://www.baidu.com")
        _, _ = ioutil.ReadAll(resp.Body)
        _ = resp.Body.Close()
    }
    time.Sleep(time.Second * 1)
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

上面的代码第一个例子的代码会输出3。分别是main goroutine + read goroutine + write goroutine,也就是有一个被不断复用的TCP连接。

在第二例子中,当我们在每次client中都创建一个新的http.Transport,此时就会输出11

说明TCP连接没有复用,每次请求都会产生新的连接。这是因为每个http.Transport内都会维护一个自己的空闲连接池,如果每个client都创建一个新的http.Transport,就会导致底层的TCP连接无法复用。如果网络请求过大,上面这种情况会导致协程数量变得非常多,导致服务不稳定。

因此,最佳实践是所有client都共用一个transport

func main() {
    tr := &http.Transport{
        MaxIdleConns:    100,
        IdleConnTimeout: 3 * time.Second,
    }

    n := 5
    for i := 0; i < n; i++ {
        req, _ := http.NewRequest("POST""https://www.baidu.com"nil)
        req.Header.Add("content-type""application/json")
        client := &http.Client{
            Transport: tr,
            Timeout:   3 * time.Second,
        }
        resp, _ := client.Do(req)
        _, _ = ioutil.ReadAll(resp.Body)
        _ = resp.Body.Close()
    }
    time.Sleep(time.Second * 1)
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

如果创建客户端的时候不指定http.Client,会默认所有http.Client都共用同一个DefaultTransport。这一点可以从源码里看出。

默认使用DefaultTransport
DefaultTransport

因此当第二段代码中,每次都重新创建一个Transport的时候,每个Transport内都会各自维护一个空闲连接池。因此每次建立长连接后都会多两个协程(读+写),对应1个main goroutine+(read goroutine + write goroutine)* 5 =11。


别设置 Transport.Dail里的SetDeadline

http.Transport.Dial的配置里有个SetDeadline,它表示连接建立后发送接收数据的超时时间。听起来跟client.Timeout很像。

那么他们有什么区别呢?我们通过一个例子去看下。

package main

import (
    "bytes"
    "encoding/json"
    "fmt"
    "io/ioutil"
    "net"
    "net/http"
    "time"
)

var tr *http.Transport

func init() {
    tr = &http.Transport{
        MaxIdleConns: 100,
        Dial: func(netw, addr string) (net.Conn, error) {
            conn, err := net.DialTimeout(netw, addr, time.Second*2//设置建立连接超时
            if err != nil {
                return nil, err
            }
            err = conn.SetDeadline(time.Now().Add(time.Second * 3)) //设置发送接受数据超时
            if err != nil {
                return nil, err
            }
            return conn, nil
        },
    }
}

func main() {
    for {
        _, err := Get("http://www.baidu.com/")
        if err != nil {
            fmt.Println(err)
            break
        }
    }
}


func Get(url string) ([]byteerror) {
    m := make(map[string]interface{})
    data, err := json.Marshal(m)
    if err != nil {
        return nil, err
    }
    body := bytes.NewReader(data)
    req, _ := http.NewRequest("Get", url, body)
    req.Header.Add("content-type""application/json")

    client := &http.Client{
        Transport: tr,
    }
    res, err := client.Do(req)
    if res != nil {
        defer res.Body.Close()
    }
    if err != nil {
        return nil, err
    }
    resBody, err := ioutil.ReadAll(res.Body)
    if err != nil {
        return nil, err
    }
    return resBody, nil
}

上面这段代码,我们设置了SetDeadline为3s,当你执行一段时间,会发现请求baidu会超时,但其实baidu的接口很快,不可能超过3s。

在生产环境中,假如是你的服务调用下游服务,你看到的现象就是,你的服务显示3s超时了,但下游服务可能只花了200ms就已经响应你的请求了,并且这是随机发生的问题。遇到这种情况,我们一般会认为是“网络波动”。

但如果我们去对网络抓包,就很容易发现问题的原因 。

抓包结果

可以看到,在tcp三次握手之后,就会开始多次网络请求。直到3s的时候,就会触发RST包,断开连接。也就是说,我们设置的SetDeadline,并不是指单次http请求的超时是3s,而是指整个tcp连接的存活时间是3s,计算长连接被连接池回收,这个时间也不会重置。

SetDeadline的解释

我实在想不到什么样的场景会需要这个功能,因此我的建议是,不要使用它。

下面是修改后的代码。这个问题其实在我另外一篇文章有过详细的解释,如果你对源码解析感兴趣的话,可以去看看。

package main

import (
    "bytes"
    "encoding/json"
    "fmt"
    "io/ioutil"
    "net/http"
    "time"
)

var tr *http.Transport

func init() {
    tr = &http.Transport{
        MaxIdleConns: 100,
        // 下面的代码被干掉了
        //Dial: func(netw, addr string) (net.Conn, error) {
        // conn, err := net.DialTimeout(netw, addr, time.Second*2) //设置建立连接超时
        // if err != nil {
        //  return nil, err
        // }
        // err = conn.SetDeadline(time.Now().Add(time.Second * 3)) //设置发送接受数据超时
        // if err != nil {
        //  return nil, err
        // }
        // return conn, nil
        //},
    }
}


func Get(url string) ([]byteerror) {
    m := make(map[string]interface{})
    data, err := json.Marshal(m)
    if err != nil {
        return nil, err
    }
    body := bytes.NewReader(data)
    req, _ := http.NewRequest("Get", url, body)
    req.Header.Add("content-type""application/json")

    client := &http.Client{
        Transport: tr,
        Timeout: 3*time.Second,  // 超时加在这里,是每次调用的超时
    }
    res, err := client.Do(req) 
    if res != nil {
        defer res.Body.Close()
    }
    if err != nil {
        return nil, err
    }
    resBody, err := ioutil.ReadAll(res.Body)
    if err != nil {
        return nil, err
    }
    return resBody, nil
}

func main() {
    for {
        _, err := Get("http://www.baidu.com/")
        if err != nil {
            fmt.Println(err)
            break
        }
    }
}

总结

golang的net/http部分有不少细节点,直接上源码分析怕劝退不少人,所以希望以几个例子作为引子展开话题然后深入了解它的内部实现。总体内容比较碎片化,但这个库的重点知识点基本都在这里面了。希望对大家后续排查问题有帮助。

最后

离开广东好长时间了,好久没人叫我靓仔了。

大家可以在评论区里,叫我一靓仔吗?

我这么善良质朴的愿望,能被满足吗?

如果实在叫不出口的话,能帮我点下右下角的点赞和在看吗?


别说了,一起在知识的海洋里呛水吧

点击下方名片,关注公众号:【小白debug】

不满足于在留言区说骚话?

加我,我们建了个划水吹牛皮群,在群里,你可以跟你下次跳槽可能遇到的同事或面试官聊点有意思的话题。就超!开!心!

文章推荐:

  • • 程序员防猝死指南

  • • TCP粘包 数据包:我只是犯了每个数据包都会犯的错 |硬核图解

  • • 动图图解!既然IP层会分片,为什么TCP层也还要分段?


评论
  • 在追求更快、更稳的无线通信路上,传统射频架构深陷带宽-功耗-成本的“不可能三角”:带宽每翻倍,系统复杂度与功耗增幅远超线性增长。传统方案通过“分立式功放+多级变频链路+JESD204B 接口”的组合试图平衡性能与成本,却难以满足实时性严苛的超大规模 MIMO 通信等场景需求。在此背景下,AXW49 射频开发板以“直采+异构”重构射频范式:基于 AMD Zynq UltraScale+™ RFSoC Gen3XCZU49DR 芯片的 16 通道 14 位 2.5GSPS ADC 与 16
    ALINX 2025-03-13 09:27 32浏览
  • 在海洋监测领域,基于无人艇能够实现高效、实时、自动化的海洋数据采集,从而为海洋环境保护、资源开发等提供有力支持。其中,无人艇的控制算法训练往往需要大量高质量的数据支持。然而,海洋数据采集也面临数据噪声和误差、数据融合与协同和复杂海洋环境适应等诸多挑战,制约着无人艇技术的发展。针对这些挑战,我们探索并推出一套基于多传感器融合的海洋数据采集系统,能够高效地采集和处理海洋环境中的多维度数据,为无人艇的自主航行和控制算法训练提供高质量的数据支持。一、方案架构无人艇要在复杂海上环境中实现自主导航,尤其是完
    康谋 2025-03-13 09:53 44浏览
  • 一、行业背景与用户需求随着健康消费升级,智能眼部按摩仪逐渐成为缓解眼疲劳、改善睡眠的热门产品。用户对这类设备的需求不再局限于基础按摩功能,而是追求更智能化、人性化的体验,例如:语音交互:实时反馈按摩模式、操作提示、安全提醒。环境感知:通过传感器检测佩戴状态、温度、压力等,提升安全性与舒适度。低功耗长续航:适应便携场景,延长设备使用时间。高性价比方案:在控制成本的同时实现功能多样化。针对这些需求,WTV380-8S语音芯片凭借其高性能、多传感器扩展能力及超高性价比,成为眼部按摩仪智能化升级的理想选
    广州唯创电子 2025-03-13 09:26 33浏览
  • 文/杜杰编辑/cc孙聪颖‍主打影像功能的小米15 Ultra手机,成为2025开年的第一款旗舰机型。从发布节奏上来看,小米历代Ultra机型,几乎都选择在开年发布,远远早于其他厂商秋季主力机型的发布时间。这毫无疑问会掀起“Ultra旗舰大战”,今年影像手机将再次被卷上新高度。无意臆断小米是否有意“领跑”一场“军备竞赛”,但各种复杂的情绪难以掩盖。岁岁年年机不同,但将2-3年内记忆中那些关于旗舰机的发布会拼凑起来,会发现,包括小米在内,旗舰机的革新点,除了摄影参数的不同,似乎没什么明显变化。贵为旗
    华尔街科技眼 2025-03-13 12:30 60浏览
  • 前言在快速迭代的科技浪潮中,汽车电子技术的飞速发展不仅重塑了行业的面貌,也对测试工具提出了更高的挑战与要求。作为汽车电子测试领域的先锋,TPT软件始终致力于为用户提供高效、精准、可靠的测试解决方案。新思科技出品的TPT软件迎来了又一次重大更新,最新版本TPT 2024.12将进一步满足汽车行业日益增长的测试需求,推动汽车电子技术的持续革新。基于当前汽车客户的实际需求与痛点,结合最新的技术趋势,对TPT软件进行了全面的优化与升级。从模型故障注入测试到服务器函数替代C代码函数,从更准确的需求链接到P
    北汇信息 2025-03-13 14:43 37浏览
  • 一、行业背景与需求痛点智能电子指纹锁作为智能家居的核心入口,近年来市场规模持续增长,用户对产品的功能性、安全性和设计紧凑性提出更高要求:极致空间利用率:锁体内部PCB空间有限,需高度集成化设计。语音交互需求:操作引导(如指纹识别状态、低电量提醒)、安全告警(防撬、试错报警)等语音反馈。智能化扩展能力:集成传感器以增强安全性(如温度监测、防撬检测)和用户体验。成本与可靠性平衡:在复杂环境下确保低功耗、高稳定性,同时控制硬件成本。WTV380-P(QFN32)语音芯片凭借4mm×4mm超小封装、多传
    广州唯创电子 2025-03-13 09:24 41浏览
  • 本文介绍Android系统主板应用配置默认获取管理所有文件权限方法,基于触觉智能SBC3588行业主板演示,搭载了瑞芯微RK3588芯片,八核处理器,6T高算力NPU;音视频接口、通信接口等各类接口一应俱全,支持安卓Android、Linux、开源鸿蒙OpenHarmony、银河麒麟Kylin等操作系统。配置前提在配置前,建议先将应用配置成系统应用,不然配置后系统每次重启后都会弹窗提示是否获取权限。应用配置成系统应用,可参考以下链接方法:瑞芯微开发板/主板Android系统APK签名文件使用方法
    Industio_触觉智能 2025-03-12 14:34 54浏览
  • DeepSeek自成立之初就散发着大胆创新的气息。明明核心开发团队只有一百多人,却能以惊人的效率实现许多大厂望尘莫及的技术成果,原因不仅在于资金或硬件,而是在于扁平架构携手塑造的蜂窝创新生态。创办人梁文锋多次强调,与其与大厂竞争一时的人才风潮,不如全力培养自家的优质员工,形成不可替代的内部生态。正因这样,他对DeepSeek内部人才体系有着一套别具一格的见解。他十分重视中式教育价值,因而DeepSeek团队几乎清一色都是中国式学霸。许多人来自北大清华,或者在各种数据比赛中多次获奖,可谓百里挑一。
    优思学院 2025-03-13 12:15 47浏览
  • 引言汽车行业正经历一场巨变。随着电动汽车、高级驾驶辅助系统(ADAS)和自动驾驶技术的普及,电子元件面临的要求从未如此严格。在这些复杂系统的核心,存在着一个看似简单却至关重要的元件——精密电阻。贞光科技代理品牌光颉科技的电阻选型过程,特别是在精度要求高达 0.01% 的薄膜和厚膜技术之间的选择,已成为全球汽车工程师的关键决策点。当几毫欧姆的差异可能影响传感器的灵敏度或控制系统的精确性时,选择正确的电阻不仅仅是满足规格的问题——它关系到车辆在极端条件下的安全性、可靠性和性能。在这份全面指南中,我们
    贞光科技 2025-03-12 17:25 92浏览
  •        随着人工智能算力集群的爆发式增长,以及5.5G/6G通信技术的演进,网络数据传输速率的需求正以每年30%的速度递增。万兆以太网(10G Base-T)作为支撑下一代数据中心、高端交换机的核心组件,其性能直接决定了网络设备的稳定性与效率。然而,万兆网络变压器的技术门槛极高:回波损耗需低于-20dB(比千兆产品严格30%),耐压值需突破1500V(传统产品仅为1000V),且需在高频信号下抑制电磁干扰。全球仅有6家企业具备规模化量产能力,而美信科
    中科领创 2025-03-13 11:24 40浏览
  • 曾经听过一个“隐形经理”的故事:有家公司,新人进来后,会惊讶地发现老板几乎从不在办公室。可大家依旧各司其职,还能在关键时刻自发协作,把项目完成得滴水不漏。新员工起初以为老板是“放羊式”管理,结果去茶水间和老员工聊过才发现,这位看似“隐形”的管理者其实“无处不在”,他提前铺好了企业文化、制度和激励机制,让一切运行自如。我的观点很简单:管理者的最高境界就是——“无为而治”。也就是说,你的存在感不需要每天都凸显,但你的思路、愿景、机制早已渗透到组织血液里。为什么呢?因为真正高明的管理,不在于事必躬亲,
    优思学院 2025-03-12 18:24 81浏览
  • 北京时间3月11日,国内领先的二手消费电子产品交易和服务平台万物新生(爱回收)集团(纽交所股票代码:RERE)发布2024财年第四季度和全年业绩报告。财报显示,2024年第四季度万物新生集团总收入48.5亿元,超出业绩指引,同比增长25.2%。单季non-GAAP经营利润1.3亿元(non-GAAP口径,即经调整口径,均不含员工股权激励费用、无形资产摊销及因收购产生的递延成本,下同),并汇报创历史新高的GAAP净利润7742万元,同比增长近27倍。总览全年,万物新生总收入同比增长25.9%达到1
    华尔街科技眼 2025-03-13 12:23 47浏览
  • 2025年,科技浪潮汹涌澎湃的当下,智能数字化变革正进行得如火如荼,从去年二季度开始,触觉智能RK3562核心板上市以来,受到了火爆的关注,上百家客户选用了此方案,也获得了众多的好评与认可,为客户的降本增效提供了广阔的空间。随着原厂的更新,功能也迎来了一波重大的更新,无论是商业级(RK3562)还是工业级(RK3562J),都可支持NPU和2×CAN,不再二选一。我们触觉智能做了一个艰难又大胆的决定,为大家带来两大重磅福利,请继续往下看~福利一:RK3562核心板149元特惠再续,支持2×CAN
    Industio_触觉智能 2025-03-12 14:45 26浏览
  • 文/Leon编辑/cc孙聪颖作为全球AI领域的黑马,DeepSeek成功搅乱了中国AI大模型市场的格局。科技大厂们选择合作,接入其模型疯抢用户;而AI独角兽们则陷入两难境地,上演了“Do Or Die”的抉择。其中,有着“大模型六小虎”之称的六家AI独角兽公司(智谱AI、百川智能、月之暗面、MiniMax、阶跃星辰及零一万物),纷纷开始转型:2025年伊始,李开复的零一万物宣布转型,不再追逐超大模型,而是聚焦AI商业化应用;紧接着,消息称百川智能放弃B端金融市场,聚焦AI医疗;月之暗面开始削减K
    华尔街科技眼 2025-03-12 17:37 145浏览
我要评论
0
点击右上角,分享到朋友圈 我知道啦
请使用浏览器分享功能 我知道啦