當(dāng)前位置：首頁(yè) > 公眾號(hào)精選 > 小林coding

粗暴的關(guān)閉?vs?優(yōu)雅的關(guān)閉

時(shí)間：2021-08-20 16:37:53
關(guān)鍵字： 5G    AC   
手機(jī)看文章

掃描二維碼
隨時(shí)隨地手機(jī)看文章

[導(dǎo)讀]大家好，我是小林。前段時(shí)間，我在群里看到個(gè)小伙伴面字節(jié)時(shí)遇到的問(wèn)題：關(guān)于close和shudown我在圖解網(wǎng)絡(luò)里也介紹了一下，但是還不是太詳細(xì)。今天具體給大家分享下?close和?shudown的區(qū)別，大家掌握好來(lái)，下次就不怕被問(wèn)啦！我們都知道，TCP是個(gè)面向連接的、可靠的、基于...

大家好，我是小林。

前段時(shí)間，我在群里看到個(gè)小伙伴面字節(jié)時(shí)遇到的問(wèn)題：

關(guān)于 close 和 shudown 我在圖解網(wǎng)絡(luò)里也介紹了一下，但是還不是太詳細(xì)。

今天具體給大家分享下?close 和?shudown 的區(qū)別，大家掌握好來(lái)，下次就不怕被問(wèn)啦！

我們都知道，TCP是個(gè)面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。

TCP是什么
那這里面提到的"面向連接"，意味著需要 建立連接，使用連接，釋放連接。

建立連接是指我們熟知的TCP三次握手。

而使用連接，則是通過(guò)一發(fā)送、一確認(rèn)的形式，進(jìn)行數(shù)據(jù)傳輸。

還有就是釋放連接，也就是我們常見(jiàn)的TCP四次揮手。

TCP四次揮手大家應(yīng)該比較了解了，但大家見(jiàn)過(guò)三次揮手嗎？還有兩次揮手呢？

都見(jiàn)過(guò)？那四次握手呢？

今天這個(gè)話題，不想只是獵奇，也不想搞冷知識(shí)。

我們從四次揮手開(kāi)始說(shuō)起，搞點(diǎn)實(shí)用的知識(shí)點(diǎn)。


TCP四次揮手

簡(jiǎn)單回顧下TCP四次揮手。

TCP四次揮手
正常情況下。只要數(shù)據(jù)傳輸完了，不管是客戶端還是服務(wù)端，都可以主動(dòng)發(fā)起四次揮手，釋放連接。

就跟上圖畫的一樣，假設(shè)，這次四次揮手是由客戶端主動(dòng)發(fā)起的，那它就是主動(dòng)方。服務(wù)器是被動(dòng)接收客戶端的揮手請(qǐng)求的，叫被動(dòng)方。

客戶端和服務(wù)器，一開(kāi)始，都是處于ESTABLISHED狀態(tài)。

第一次揮手：一般情況下，主動(dòng)方執(zhí)行close()或 shutdown()方法，會(huì)發(fā)個(gè)FIN報(bào)文出來(lái)，表示"我不再發(fā)送數(shù)據(jù)了"。

第二次揮手：在收到主動(dòng)方的FIN報(bào)文后，被動(dòng)方立馬回應(yīng)一個(gè)ACK，意思是"我收到你的FIN了，也知道你不再發(fā)數(shù)據(jù)了"。

上面提到的是主動(dòng)方不再發(fā)送數(shù)據(jù)了。但如果這時(shí)候，被動(dòng)方還有數(shù)據(jù)要發(fā)，那就繼續(xù)發(fā)。注意，雖然第二次和第三次揮手之間，被動(dòng)方是能發(fā)數(shù)據(jù)到主動(dòng)方的，但主動(dòng)方能不能正常收就不一定了，這個(gè)待會(huì)說(shuō)。

第三次揮手：在被動(dòng)方在感知到第二次揮手之后，會(huì)做了一系列的收尾工作，最后也調(diào)用一個(gè) close(), 這時(shí)候就會(huì)發(fā)出第三次揮手的 FIN-ACK。

第四次揮手：主動(dòng)方回一個(gè)ACK，意思是收到了。

其中第一次揮手和第三次揮手，都是我們?cè)趹?yīng)用程序中主動(dòng)觸發(fā)的（比如調(diào)用close()方法），也就是我們平時(shí)寫代碼需要關(guān)注的地方。

第二和第四次揮手，都是內(nèi)核協(xié)議棧自動(dòng)幫我們完成的，我們寫代碼的時(shí)候碰不到這地方，因此也不需要太關(guān)心。

另外不管是主動(dòng)還是被動(dòng)，每方發(fā)出了一個(gè) FIN 和一個(gè)ACK 。也收到了一個(gè) FIN 和一個(gè)ACK 。這一點(diǎn)大家關(guān)注下，待會(huì)還會(huì)提到。

FIN一定要程序執(zhí)行close()或shutdown()才能發(fā)出嗎？

不一定。一般情況下，通過(guò)對(duì)socket執(zhí)行 close() 或 shutdown() 方法會(huì)發(fā)出FIN。但實(shí)際上，只要應(yīng)用程序退出，不管是主動(dòng)退出，還是被動(dòng)退出（因?yàn)橐恍┠涿畹脑虮?code style="font-size: inherit;line-height: inherit;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left: 2px;color: rgb(255, 82, 82);background: rgb(248, 248, 248);">kill了）, 都會(huì)發(fā)出 FIN。

FIN 是指"我不再發(fā)送數(shù)據(jù)"，因此shutdown() 關(guān)閉讀不會(huì)給對(duì)方發(fā)FIN, 關(guān)閉寫才會(huì)發(fā)FIN。


如果機(jī)器上FIN-WAIT-2狀態(tài)特別多，是為什么

根據(jù)上面的四次揮手圖，可以看出，FIN-WAIT-2是主動(dòng)方那邊的狀態(tài)。

處于這個(gè)狀態(tài)的程序，一直在等第三次揮手的FIN。而第三次揮手需要由被動(dòng)方在代碼里執(zhí)行close() 發(fā)出。

因此當(dāng)機(jī)器上FIN-WAIT-2狀態(tài)特別多，那一般來(lái)說(shuō)，另外一臺(tái)機(jī)器上會(huì)有大量的 CLOSE_WAIT。需要檢查有大量的 CLOSE_WAIT的那臺(tái)機(jī)器，為什么遲遲不愿調(diào)用close()關(guān)閉連接。

所以，如果機(jī)器上FIN-WAIT-2狀態(tài)特別多，一般是因?yàn)閷?duì)端一直不執(zhí)行close()方法發(fā)出第三次揮手。

FIN-WAIT-2特別多的原因

主動(dòng)方在close之后收到的數(shù)據(jù)，會(huì)怎么處理

之前寫的一篇文章《代碼執(zhí)行send成功后，數(shù)據(jù)就發(fā)出去了嗎？》中，從源碼的角度提到了，一般情況下，程序主動(dòng)執(zhí)行close()的時(shí)候；

  • 如果當(dāng)前連接對(duì)應(yīng)的socket的接收緩沖區(qū)有數(shù)據(jù)，會(huì)發(fā)RST。

  • 如果發(fā)送緩沖區(qū)有數(shù)據(jù)，那會(huì)等待發(fā)送完，再發(fā)第一次揮手的FIN。

大家知道，TCP是全雙工通信，意思是發(fā)送數(shù)據(jù)的同時(shí)，還可以接收數(shù)據(jù)。

Close()的含義是，此時(shí)要同時(shí)關(guān)閉發(fā)送和接收消息的功能。

也就是說(shuō)，雖然理論上，第二次和第三次揮手之間，被動(dòng)方是可以傳數(shù)據(jù)給主動(dòng)方的。

但如果 主動(dòng)方的四次揮手是通過(guò) close() 觸發(fā)的，那主動(dòng)方是不會(huì)去收這個(gè)消息的。而且還會(huì)回一個(gè) RST。直接結(jié)束掉這次連接。

close()觸發(fā)TCP四次揮手

第二第三次揮手之間，不能傳輸數(shù)據(jù)嗎？

也不是。前面提到Close()的含義是，要同時(shí)關(guān)閉發(fā)送和接收消息的功能。

那如果能做到只關(guān)閉發(fā)送消息，不關(guān)閉接收消息的功能，那就能繼續(xù)收消息了。這種 half-close 的功能，通過(guò)調(diào)用shutdown() 方法就能做到。

int?shutdown(int?sock,?int?howto);
其中 howto 為斷開(kāi)方式。有以下取值：

  • SHUT_RD：關(guān)閉讀。這時(shí)應(yīng)用層不應(yīng)該再嘗試接收數(shù)據(jù)，內(nèi)核協(xié)議棧中就算接收緩沖區(qū)收到數(shù)據(jù)也會(huì)被丟棄。

  • SHUT_WR：關(guān)閉寫。如果發(fā)送緩沖區(qū)中還有數(shù)據(jù)沒(méi)發(fā)，會(huì)將將數(shù)據(jù)傳遞到目標(biāo)主機(jī)。

  • SHUT_RDWR：關(guān)閉讀和寫。相當(dāng)于close()了。

shutdown觸發(fā)的TCP四次揮手

怎么知道對(duì)端socket執(zhí)行了close還是shutdown

不管主動(dòng)關(guān)閉方調(diào)用的是close()還是shutdown()，對(duì)于被動(dòng)方來(lái)說(shuō)，收到的就只有一個(gè)FIN。

被動(dòng)關(guān)閉方就懵了，"我怎么知道對(duì)方讓不讓我繼續(xù)發(fā)數(shù)據(jù)？"

其實(shí)，大可不必糾結(jié)，該發(fā)就發(fā)。

第二次揮手和第三次揮手之間，如果被動(dòng)關(guān)閉方想發(fā)數(shù)據(jù)，那么在代碼層面上，就是執(zhí)行了 send() 方法。

int?send(?SOCKET?s,const?char*?buf,int?len,int?flags);
send() 會(huì)把數(shù)據(jù)拷貝到本機(jī)的發(fā)送緩沖區(qū)。如果發(fā)送緩沖區(qū)沒(méi)出問(wèn)題，都能拷貝進(jìn)去，所以正常情況下，send()一般都會(huì)返回成功。

![tcp_sendmsg 邏輯](https://cdn.jsdelivr.net/gh/xiaobaiTech/image/tcp_sendmsg 邏輯.png)

然后被動(dòng)方內(nèi)核協(xié)議棧會(huì)把數(shù)據(jù)發(fā)給主動(dòng)關(guān)閉方。

  • 如果上一次主動(dòng)關(guān)閉方調(diào)用的是shutdown(socket_fd, SHUT_WR)。那此時(shí)，主動(dòng)關(guān)閉方不再發(fā)送消息，但能接收被動(dòng)方的消息，一切如常，皆大歡喜。

  • 如果上一次主動(dòng)關(guān)閉方調(diào)用的是close()。那主動(dòng)方在收到被動(dòng)方的數(shù)據(jù)后會(huì)直接丟棄，然后回一個(gè)RST。

針對(duì)第二種情況。

被動(dòng)方內(nèi)核協(xié)議棧收到了RST，會(huì)把連接關(guān)閉。但內(nèi)核連接關(guān)閉了，應(yīng)用層也不知道（除非被通知）。

此時(shí)被動(dòng)方應(yīng)用層接下來(lái)的操作，無(wú)非就是讀或?qū)?/strong>。

  • 如果是讀，則會(huì)返回RST的報(bào)錯(cuò)，也就是我們常見(jiàn)的Connection reset by peer。

  • 如果是寫，那么程序會(huì)產(chǎn)生SIGPIPE信號(hào)，應(yīng)用層代碼可以捕獲并處理信號(hào)，如果不處理，則默認(rèn)情況下進(jìn)程會(huì)終止，異常退出。


總結(jié)一下，當(dāng)被動(dòng)關(guān)閉方 recv() 返回EOF時(shí)，說(shuō)明主動(dòng)方通過(guò) close()或 shutdown(fd, SHUT_WR) 發(fā)起了第一次揮手。

如果此時(shí)被動(dòng)方執(zhí)行兩次 send()。

  • 第一次send(), 一般會(huì)成功返回。

  • 第二次send()時(shí)。如果主動(dòng)方是通過(guò) shutdown(fd, SHUT_WR) 發(fā)起的第一次揮手，那此時(shí)send()還是會(huì)成功。如果主動(dòng)方通過(guò) close()發(fā)起的第一次揮手，那此時(shí)會(huì)產(chǎn)生SIGPIPE信號(hào)，進(jìn)程默認(rèn)會(huì)終止，異常退出。不想異常退出的話，記得捕獲處理這個(gè)信號(hào)。


如果被動(dòng)方一直不發(fā)第三次揮手，會(huì)怎么樣

第三次揮手，是由被動(dòng)方主動(dòng)觸發(fā)的，比如調(diào)用close()。

如果由于代碼錯(cuò)誤或者其他一些原因，被動(dòng)方就是不執(zhí)行第三次揮手。

這時(shí)候，主動(dòng)方會(huì)根據(jù)自身第一次揮手的時(shí)候用的是 close() 還是 shutdown(fd, SHUT_WR) ，有不同的行為表現(xiàn)。

  • 如果是 shutdown(fd, SHUT_WR) ，說(shuō)明主動(dòng)方其實(shí)只關(guān)閉了寫，但還可以讀，此時(shí)會(huì)一直處于 FIN-WAIT-2， 死等被動(dòng)方的第三次揮手。

  • 如果是 close()， 說(shuō)明主動(dòng)方讀寫都關(guān)閉了，這時(shí)候會(huì)處于 FIN-WAIT-2一段時(shí)間，這個(gè)時(shí)間由 net.ipv4.tcp_fin_timeout 控制，一般是 60s，這個(gè)值正好跟2MSL一樣 。超過(guò)這段時(shí)間之后，狀態(tài)不會(huì)變成 `TIME-WAIT`，而是直接變成`CLOSED`。

#?cat?/proc/sys/net/ipv4/tcp_fin_timeout
60

一直不發(fā)第三次揮手的情況

TCP三次揮手

四次揮手聊完了，那有沒(méi)有可能出現(xiàn)三次揮手？

是可能的。

我們知道，TCP四次揮手里，第二次和第三次揮手之間，是有可能有數(shù)據(jù)傳輸?shù)?。第三次揮手的目的是為了告訴主動(dòng)方，"被動(dòng)方?jīng)]有數(shù)據(jù)要發(fā)了"。

所以，在第一次揮手之后，如果被動(dòng)方?jīng)]有數(shù)據(jù)要發(fā)給主動(dòng)方。第二和第三次揮手是有可能合并傳輸?shù)?。這樣就出現(xiàn)了三次揮手。

TCP三次揮手

如果有數(shù)據(jù)要發(fā)，就不能是三次揮手了嗎

上面提到的是沒(méi)有數(shù)據(jù)要發(fā)的情況，如果第二、第三次揮手之間有數(shù)據(jù)要發(fā)，就不可能變成三次揮手了嗎？

并不是。TCP中還有個(gè)特性叫延遲確認(rèn)。可以簡(jiǎn)單理解為：接收方收到數(shù)據(jù)以后不需要立刻馬上回復(fù)ACK確認(rèn)包。

在此基礎(chǔ)上，不是每一次發(fā)送數(shù)據(jù)包都能對(duì)應(yīng)收到一個(gè) ACK 確認(rèn)包，因?yàn)榻邮辗娇梢院喜⒋_認(rèn)。

而這個(gè)合并確認(rèn)，放在四次揮手里，可以把第二次揮手、第三次揮手，以及他們之間的數(shù)據(jù)傳輸都合并在一起發(fā)送。因此也就出現(xiàn)了三次揮手。

TCP三次揮手延遲確認(rèn)

TCP兩次揮手

前面在四次揮手中提到，關(guān)閉的時(shí)候雙方都發(fā)出了一個(gè)FIN和收到了一個(gè)ACK。

正常情況下TCP連接的兩端，是不同IP 端口的進(jìn)程。

但如果TCP連接的兩端，IP 端口是一樣的情況下，那么在關(guān)閉連接的時(shí)候，也同樣做到了一端發(fā)出了一個(gè)FIN，也收到了一個(gè) ACK，只不過(guò)正好這兩端其實(shí)是同一個(gè)socket 。

TCP兩次揮手
而這種兩端IP 端口都一樣的連接，叫TCP自連接。

是的，你沒(méi)看錯(cuò)，我也沒(méi)打錯(cuò)別字。同一個(gè)socket確實(shí)可以自己連自己，形成一個(gè)連接。


一個(gè)socket能建立連接？

上面提到了，同一個(gè)客戶端socket，自己對(duì)自己發(fā)起連接請(qǐng)求。是可以成功建立連接的。這樣的連接，叫TCP自連接。

下面我們嘗試下復(fù)現(xiàn)。

注意我是在以下系統(tǒng)進(jìn)行的實(shí)驗(yàn)。在mac上多半無(wú)法復(fù)現(xiàn)。

#??cat?/etc/os-release
NAME="CentOS?Linux"
VERSION="7?(Core)"
ID="centos"
ID_LIKE="rhel?fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS?Linux?7?(Core)"
通過(guò)nc命令可以很簡(jiǎn)單的創(chuàng)建一個(gè)TCP自連接

#?nc?-p?6666?127.0.0.1?6666
上面的 -p 可以指定源端口號(hào)。也就是指定了一個(gè)端口號(hào)為6666的客戶端去連接 127.0.0.1:6666 。

#?netstat?-nt?|?grep?6666
tcp????????0??????0?127.0.0.1:6666??????????127.0.0.1:6666??????????ESTABLISHED
整個(gè)過(guò)程中，都沒(méi)有服務(wù)端參與。可以抓個(gè)包看下。

image-20210810093309117
可以看到，相同的socket，自己連自己的時(shí)候，握手是三次的。揮手是兩次的。

TCP自連接
上面這張圖里，左右都是同一個(gè)客戶端，把它畫成兩個(gè)是為了方便大家理解狀態(tài)的遷移。

我們可以拿自連接的握手狀態(tài)對(duì)比下正常情況下的TCP三次握手。

正常情況下的TCP三次握手
看了自連接的狀態(tài)圖，再看看下面幾個(gè)問(wèn)題。


一端發(fā)出第一次握手后，如果又收到了第一次握手的SYN包，TCP連接狀態(tài)會(huì)怎么變化？

第一次握手過(guò)后，連接狀態(tài)就變成了SYN_SENT狀態(tài)。如果此時(shí)又收到了第一次握手的SYN包，那么連接狀態(tài)就會(huì)從SYN_SENT狀態(tài)變成SYN_RCVD。

//?net/ipv4/tcp_input.c
static?int?tcp_rcv_synsent_state_process()
{
????//?SYN_SENT狀態(tài)下，收到SYN包
????if?(th->syn)?{
????????//?狀態(tài)置為?SYN_RCVD
????????tcp_set_state(sk,?TCP_SYN_RECV);
????}
}

一端發(fā)出第二次握手后，如果又收到第二次握手的SYN ACK包，TCP連接狀態(tài)會(huì)怎么變化？

第二握手過(guò)后，連接狀態(tài)就變?yōu)?code style="font-size: inherit;line-height: inherit;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left: 2px;color: rgb(255, 82, 82);background: rgb(248, 248, 248);">SYN_RCVD了，此時(shí)如果再收到第二次握手的SYN ACK包。連接狀態(tài)會(huì)變?yōu)?code style="font-size: inherit;line-height: inherit;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left: 2px;color: rgb(255, 82, 82);background: rgb(248, 248, 248);">ESTABLISHED。

//?net/ipv4/tcp_input.c
int?tcp_rcv_state_process()
{
????//?前面省略很多邏輯，能走到這就認(rèn)為肯定有ACK
????if?(true)?{
????????//?判斷下這個(gè)ack是否合法
????????int?acceptable?=?tcp_ack(sk,?skb,?FLAG_SLOWPATH?|?FLAG_UPDATE_TS_RECENT)?>?0;
????????switch?(sk->sk_state)?{
????????case?TCP_SYN_RECV:
????????????if?(acceptable)?{
????????//?狀態(tài)從?SYN_RCVD?轉(zhuǎn)為?ESTABLISHED
????????????????tcp_set_state(sk,?TCP_ESTABLISHED);
????????????}?
????????}
????}
}

一端第一次揮手后，又收到第一次揮手的包，TCP連接狀態(tài)會(huì)怎么變化？

第一次揮手過(guò)后，一端狀態(tài)就會(huì)變成 FIN-WAIT-1。正常情況下，是要等待第二次揮手的ACK。但實(shí)際上卻等來(lái)了 一個(gè)第一次揮手的 FIN包， 這時(shí)候連接狀態(tài)就會(huì)變?yōu)?code style="font-size: inherit;line-height: inherit;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left: 2px;color: rgb(255, 82, 82);background: rgb(248, 248, 248);">CLOSING。

//?net/
static?void?tcp_fin(struct?sock?*sk)
{
????switch?(sk->sk_state)?{
????case?TCP_FIN_WAIT1:
????????tcp_send_ack(sk);
????//?FIN-WAIT-1狀態(tài)下，收到了FIN，轉(zhuǎn)為?CLOSING
????????tcp_set_state(sk,?TCP_CLOSING);
????????break;
????}
}
這可以說(shuō)是隱藏劇情了。

CLOSING 很少見(jiàn)，除了出現(xiàn)在自連接關(guān)閉外，一般還會(huì)出現(xiàn)在TCP兩端同時(shí)關(guān)閉連接的情況下。

處于CLOSING狀態(tài)下時(shí)，只要再收到一個(gè)ACK，就能進(jìn)入 TIME-WAIT 狀態(tài)，然后等個(gè)2MSL，連接就徹底斷開(kāi)了。這跟正常的四次揮手還是有些差別的。大家可以滑到文章開(kāi)頭的TCP四次揮手再對(duì)比下。


代碼復(fù)現(xiàn)自連接

可能大家會(huì)產(chǎn)生懷疑，這是不是nc這個(gè)軟件本身的bug。

那我們可以嘗試下用strace看看它內(nèi)部都做了啥。

#?strace?nc?-p?6666?127.0.0.1?6666
//?...
socket(AF_INET,?SOCK_STREAM,?IPPROTO_TCP)?=?3
fcntl(3,?F_GETFL)???????????????????????=?0x2?(flags?O_RDWR)
fcntl(3,?F_SETFL,?O_RDWR|O_NONBLOCK)????=?0
setsockopt(3,?SOL_SOCKET,?SO_REUSEADDR,?[1],?4)?=?0
bind(3,?{sa_family=AF_INET,?sin_port=htons(6666),?sin_addr=inet_addr("0.0.0.0")},?16)?=?0
connect(3,?{sa_family=AF_INET,?sin_port=htons(6666),?sin_addr=inet_addr("127.0.0.1")},?16)?=?-1?EINPROGRESS?(Operation?now?in?progress)
//?...
無(wú)非就是以創(chuàng)建了一個(gè)客戶端socket句柄，然后對(duì)這個(gè)句柄執(zhí)行 bind, 綁定它的端口號(hào)是6666，然后再向 127.0.0.1:6666發(fā)起connect方法。

我們可以嘗試用C語(yǔ)言去復(fù)現(xiàn)一遍。

下面的代碼，只用于復(fù)現(xiàn)問(wèn)題。直接跳過(guò)也完全不影響閱讀。

#include?
#include?
#include?
#include?
#include?
#include?
#include?
#include?


int?main()
{
????int?lfd,?cfd;
????struct?sockaddr_in?serv_addr,?clie_addr;
????socklen_t?clie_addr_len;
????char?buf[BUFSIZ];
????int?n?=?0,?i?=?0,?ret?=?0?;
????printf("This?is?a?client?\n");

????/*Step?1:?創(chuàng)建客戶端端socket描述符cfd*/????
????cfd?=?socket(AF_INET,?SOCK_STREAM,?0);
????if(cfd?==?-1)
????{
????????perror("socket?error");
????????exit(1);
????}

????int?flag=1,len=sizeof(int);
????if(?setsockopt(cfd,?SOL_SOCKET,?SO_REUSEADDR,?
本站聲明： 本文章由作者或相關(guān)機(jī)構(gòu)授權(quán)發(fā)布，目的在于傳遞更多信息，并不代表本站贊同其觀點(diǎn)，本站亦不保證或承諾內(nèi)容真實(shí)性等。需要轉(zhuǎn)載請(qǐng)聯(lián)系該專欄作者，如若文章內(nèi)容侵犯您的權(quán)益，請(qǐng)及時(shí)聯(lián)系本站刪除。
換一批
延伸閱讀

9月2日消息，不造車的華為或?qū)⒋呱龈蟮莫?dú)角獸公司，隨著阿維塔和賽力斯的入局，華為引望愈發(fā)顯得引人矚目。

關(guān)鍵字： 阿維塔 塞力斯 華為

倫敦2024年8月29日 /美通社/ -- 英國(guó)汽車技術(shù)公司SODA.Auto推出其旗艦產(chǎn)品SODA V，這是全球首款涵蓋汽車工程師從創(chuàng)意到認(rèn)證的所有需求的工具，可用于創(chuàng)建軟件定義汽車。 SODA V工具的開(kāi)發(fā)耗時(shí)1.5...

關(guān)鍵字： 汽車 人工智能 智能驅(qū)動(dòng) BSP

北京2024年8月28日 /美通社/ -- 越來(lái)越多用戶希望企業(yè)業(yè)務(wù)能7×24不間斷運(yùn)行，同時(shí)企業(yè)卻面臨越來(lái)越多業(yè)務(wù)中斷的風(fēng)險(xiǎn)，如企業(yè)系統(tǒng)復(fù)雜性的增加，頻繁的功能更新和發(fā)布等。如何確保業(yè)務(wù)連續(xù)性，提升韌性，成...

關(guān)鍵字： 亞馬遜 解密 控制平面 BSP

8月30日消息，據(jù)媒體報(bào)道，騰訊和網(wǎng)易近期正在縮減他們對(duì)日本游戲市場(chǎng)的投資。

關(guān)鍵字： 騰訊 編碼器 CPU

8月28日消息，今天上午，2024中國(guó)國(guó)際大數(shù)據(jù)產(chǎn)業(yè)博覽會(huì)開(kāi)幕式在貴陽(yáng)舉行，華為董事、質(zhì)量流程IT總裁陶景文發(fā)表了演講。

關(guān)鍵字： 華為 12nm EDA 半導(dǎo)體

8月28日消息，在2024中國(guó)國(guó)際大數(shù)據(jù)產(chǎn)業(yè)博覽會(huì)上，華為常務(wù)董事、華為云CEO張平安發(fā)表演講稱，數(shù)字世界的話語(yǔ)權(quán)最終是由生態(tài)的繁榮決定的。

關(guān)鍵字： 華為 12nm 手機(jī) 衛(wèi)星通信

要點(diǎn)： 有效應(yīng)對(duì)環(huán)境變化，經(jīng)營(yíng)業(yè)績(jī)穩(wěn)中有升 落實(shí)提質(zhì)增效舉措，毛利潤(rùn)率延續(xù)升勢(shì) 戰(zhàn)略布局成效顯著，戰(zhàn)新業(yè)務(wù)引領(lǐng)增長(zhǎng) 以科技創(chuàng)新為引領(lǐng)，提升企業(yè)核心競(jìng)爭(zhēng)力 堅(jiān)持高質(zhì)量發(fā)展策略，塑強(qiáng)核心競(jìng)爭(zhēng)優(yōu)勢(shì)...

關(guān)鍵字： 通信 BSP 電信運(yùn)營(yíng)商 數(shù)字經(jīng)濟(jì)

北京2024年8月27日 /美通社/ -- 8月21日，由中央廣播電視總臺(tái)與中國(guó)電影電視技術(shù)學(xué)會(huì)聯(lián)合牽頭組建的NVI技術(shù)創(chuàng)新聯(lián)盟在BIRTV2024超高清全產(chǎn)業(yè)鏈發(fā)展研討會(huì)上宣布正式成立。 活動(dòng)現(xiàn)場(chǎng) NVI技術(shù)創(chuàng)新聯(lián)...

關(guān)鍵字： VI 傳輸協(xié)議 音頻 BSP

北京2024年8月27日 /美通社/ -- 在8月23日舉辦的2024年長(zhǎng)三角生態(tài)綠色一體化發(fā)展示范區(qū)聯(lián)合招商會(huì)上，軟通動(dòng)力信息技術(shù)（集團(tuán)）股份有限公司（以下簡(jiǎn)稱"軟通動(dòng)力"）與長(zhǎng)三角投資（上海）有限...

關(guān)鍵字： BSP 信息技術(shù)
關(guān)閉
關(guān)閉