[導(dǎo)讀] 客戶端主動(dòng)調(diào)用關(guān)閉連接的函數(shù),于是就會(huì)發(fā)送 FIN 報(bào)文,這個(gè) FIN 報(bào)文代表客戶端不會(huì)再發(fā)送數(shù)據(jù)了,進(jìn)入 FIN_WAIT_1 狀態(tài);
上周有位讀者面美團(tuán)時(shí),被問(wèn)到:TCP 四次揮手中,能不能把第二次的 ACK 報(bào)文, 放到第三次 FIN 報(bào)文一起發(fā)送? 雖然我們?cè)趯W(xué)習(xí) TCP 揮手時(shí),學(xué)到的是需要四次來(lái)完成 TCP 揮手,但是在一些情況下, TCP 四次揮手是可以變成 TCP 三次揮手的 。而且在用 wireshark 工具抓包的時(shí)候,我們也會(huì)??吹?TCP 揮手過(guò)程是三次,而不是四次,如下圖:先來(lái)回答為什么 RFC 文檔里定義 TCP 揮手過(guò)程是要四次?再來(lái)回答什么情況下,什么情況會(huì)出現(xiàn)三次揮手?為什么 TCP 揮手需要四次?
TCP 四次揮手的過(guò)程如下:具體過(guò)程:
客戶端主動(dòng)調(diào)用關(guān)閉連接的函數(shù),于是就會(huì)發(fā)送 FIN 報(bào)文,這個(gè) FIN 報(bào)文代表客戶端不會(huì)再發(fā)送數(shù)據(jù)了,進(jìn)入 FIN_WAIT_1 狀態(tài);
服務(wù)端收到了 FIN 報(bào)文,然后馬上回復(fù)一個(gè) ACK 確認(rèn)報(bào)文,此時(shí)服務(wù)端進(jìn)入 CLOSE_WAIT 狀態(tài)。在收到 FIN 報(bào)文的時(shí)候,TCP 協(xié)議棧會(huì)為 FIN 包插入一個(gè)文件結(jié)束符 EOF 到接收緩沖區(qū)中,服務(wù)端應(yīng)用程序可以通過(guò) read 調(diào)用來(lái)感知這個(gè) FIN 包,這個(gè) EOF 會(huì)被放在已排隊(duì)等候的其他已接收的數(shù)據(jù)之后 ,所以必須要得繼續(xù) read 接收緩沖區(qū)已接收的數(shù)據(jù);
接著,當(dāng)服務(wù)端在 read 數(shù)據(jù)的時(shí)候,最后自然就會(huì)讀到 EOF,接著 read() 就會(huì)返回 0,這時(shí)服務(wù)端應(yīng)用程序如果有數(shù)據(jù)要發(fā)送的話,就發(fā)完數(shù)據(jù)后才調(diào)用關(guān)閉連接的函數(shù),如果服務(wù)端應(yīng)用程序沒(méi)有數(shù)據(jù)要發(fā)送的話,可以直接調(diào)用關(guān)閉連接的函數(shù) ,這時(shí)服務(wù)端就會(huì)發(fā)一個(gè) FIN 包,這個(gè) FIN 報(bào)文代表服務(wù)端不會(huì)再發(fā)送數(shù)據(jù)了,之后處于 LAST_ACK 狀態(tài);
客戶端接收到服務(wù)端的 FIN 包,并發(fā)送 ACK 確認(rèn)包給服務(wù)端,此時(shí)客戶端將進(jìn)入 TIME_WAIT 狀態(tài);
服務(wù)端收到 ACK 確認(rèn)包后,就進(jìn)入了最后的 CLOSE 狀態(tài);
客戶端經(jīng)過(guò) 2MSL 時(shí)間之后,也進(jìn)入 CLOSE 狀態(tài);
你可以看到,每個(gè)方向都需要一個(gè) FIN 和一個(gè) ACK ,因此通常被稱為四次揮手 。為什么 TCP 揮手需要四次呢?
服務(wù)器收到客戶端的 FIN 報(bào)文時(shí),內(nèi)核會(huì)馬上回一個(gè) ACK 應(yīng)答報(bào)文,但是服務(wù)端應(yīng)用程序可能還有數(shù)據(jù)要發(fā)送,所以并不能馬上發(fā)送 FIN 報(bào)文,而是將發(fā)送 FIN 報(bào)文的控制權(quán)交給服務(wù)端應(yīng)用程序 :
如果服務(wù)端應(yīng)用程序有數(shù)據(jù)要發(fā)送的話,就發(fā)完數(shù)據(jù)后,才調(diào)用關(guān)閉連接的函數(shù);
如果服務(wù)端應(yīng)用程序沒(méi)有數(shù)據(jù)要發(fā)送的話,可以直接調(diào)用關(guān)閉連接的函數(shù),
從上面過(guò)程可知,是否要發(fā)送第三次揮手的控制權(quán)不在內(nèi)核,而是在被動(dòng)關(guān)閉方(上圖的服務(wù)端)的應(yīng)用程序,因?yàn)閼?yīng)用程序可能還有數(shù)據(jù)要發(fā)送,由應(yīng)用程序決定什么時(shí)候調(diào)用關(guān)閉連接的函數(shù),當(dāng)調(diào)用了關(guān)閉連接的函數(shù),內(nèi)核就會(huì)發(fā)送 FIN 報(bào)文了, 所以服務(wù)端的 ACK 和 FIN 一般都會(huì)分開(kāi)發(fā)送。FIN 報(bào)文一定得調(diào)用關(guān)閉連接的函數(shù),才會(huì)發(fā)送嗎?
不一定。如果進(jìn)程退出了,不管是不是正常退出,還是異常退出(如進(jìn)程崩潰),內(nèi)核都會(huì)發(fā)送 FIN 報(bào)文,與對(duì)方完成四次揮手。粗暴關(guān)閉 vs 優(yōu)雅關(guān)閉
前面介紹 TCP 四次揮手的時(shí)候,并沒(méi)有詳細(xì)介紹關(guān)閉連接的函數(shù),其實(shí)關(guān)閉的連接的函數(shù)有兩種函數(shù):
close 函數(shù),同時(shí) socket 關(guān)閉發(fā)送方向和讀取方向,也就是 socket 不再有發(fā)送和接收數(shù)據(jù)的能力。如果有多進(jìn)程/多線程共享同一個(gè) socket,如果有一個(gè)進(jìn)程調(diào)用了 close 關(guān)閉只是讓 socket 引用計(jì)數(shù) -1,并不會(huì)導(dǎo)致 socket 不可用,同時(shí)也不會(huì)發(fā)出 FIN 報(bào)文,其他進(jìn)程還是可以正常讀寫(xiě)該 socket,直到引用計(jì)數(shù)變?yōu)?0,才會(huì)發(fā)出 FIN 報(bào)文。
shutdown 函數(shù),可以指定 socket 只關(guān)閉發(fā)送方向而不關(guān)閉讀取方向,也就是 socket 不再有發(fā)送數(shù)據(jù)的能力,但是還是具有接收數(shù)據(jù)的能力。如果有多進(jìn)程/多線程共享同一個(gè) socket,shutdown 則不管引用計(jì)數(shù),直接使得該 socket 不可用,然后發(fā)出 FIN 報(bào)文,如果有別的進(jìn)程企圖使用該 socket,將會(huì)受到影響。
如果客戶端是用 close 函數(shù)來(lái)關(guān)閉連接,那么在 TCP 四次揮手過(guò)程中,如果收到了服務(wù)端發(fā)送的數(shù)據(jù),由于客戶端已經(jīng)不再具有發(fā)送和接收數(shù)據(jù)的能力,所以客戶端的內(nèi)核會(huì)回 RST 報(bào)文給服務(wù)端,然后內(nèi)核會(huì)釋放連接,這時(shí)就不會(huì)經(jīng)歷完成的 TCP 四次揮手,所以我們常說(shuō),調(diào)用 close 是粗暴的關(guān)閉。當(dāng)服務(wù)端收到 RST 后,內(nèi)核就會(huì)釋放連接,當(dāng)服務(wù)端應(yīng)用程序再次發(fā)起讀操作或者寫(xiě)操作時(shí),就能感知到連接已經(jīng)被釋放了:
如果是讀操作,則會(huì)返回 RST 的報(bào)錯(cuò),也就是我們常見(jiàn)的Connection reset by peer。
如果是寫(xiě)操作,那么程序會(huì)產(chǎn)生 SIGPIPE 信號(hào),應(yīng)用層代碼可以捕獲并處理信號(hào),如果不處理,則默認(rèn)情況下進(jìn)程會(huì)終止,異常退出。
相對(duì)的,shutdown 函數(shù)因?yàn)榭梢灾付ㄖ魂P(guān)閉發(fā)送方向而不關(guān)閉讀取方向,所以即使在 TCP 四次揮手過(guò)程中,如果收到了服務(wù)端發(fā)送的數(shù)據(jù),客戶端也是可以正常讀取到該數(shù)據(jù)的,然后就會(huì)經(jīng)歷完整的 TCP 四次揮手,所以我們常說(shuō),調(diào)用 shutdown 是優(yōu)雅的關(guān)閉。但是注意,shutdown 函數(shù)也可以指定「只關(guān)閉讀取方向,而不關(guān)閉發(fā)送方向」,但是這時(shí)候內(nèi)核是不會(huì)發(fā)送 FIN 報(bào)文的,因?yàn)榘l(fā)送 FIN 報(bào)文是意味著我方將不再發(fā)送任何數(shù)據(jù),而 shutdown 如果指定「不關(guān)閉發(fā)送方向」,就意味著 socket 還有發(fā)送數(shù)據(jù)的能力,所以內(nèi)核就不會(huì)發(fā)送 FIN 。什么情況會(huì)出現(xiàn)三次揮手?
當(dāng)被動(dòng)關(guān)閉方(上圖的服務(wù)端)在 TCP 揮手過(guò)程中,「沒(méi)有數(shù)據(jù)要發(fā)送」并且「開(kāi)啟了 TCP 延遲確認(rèn)機(jī)制」,那么第二和第三次揮手就會(huì)合并傳輸,這樣就出現(xiàn)了三次揮手。 然后因?yàn)?TCP 延遲確認(rèn)機(jī)制是默認(rèn)開(kāi)啟的,所以導(dǎo)致我們抓包時(shí),看見(jiàn)三次揮手的次數(shù)比四次揮手還多。什么是 TCP 延遲確認(rèn)機(jī)制?
當(dāng)發(fā)送沒(méi)有攜帶數(shù)據(jù)的 ACK,它的網(wǎng)絡(luò)效率也是很低的,因?yàn)樗灿?40 個(gè)字節(jié)的 IP 頭 和 TCP 頭,但卻沒(méi)有攜帶數(shù)據(jù)報(bào)文。為了解決 ACK 傳輸效率低問(wèn)題,所以就衍生出了 TCP 延遲確認(rèn) 。TCP 延遲確認(rèn)的策略:
當(dāng)有響應(yīng)數(shù)據(jù)要發(fā)送時(shí),ACK 會(huì)隨著響應(yīng)數(shù)據(jù)一起立刻發(fā)送給對(duì)方
當(dāng)沒(méi)有響應(yīng)數(shù)據(jù)要發(fā)送時(shí),ACK 將會(huì)延遲一段時(shí)間,以等待是否有響應(yīng)數(shù)據(jù)可以一起發(fā)送
如果在延遲等待發(fā)送 ACK 期間,對(duì)方的第二個(gè)數(shù)據(jù)報(bào)文又到達(dá)了,這時(shí)就會(huì)立刻發(fā)送 ACK
延遲等待的時(shí)間是在 Linux 內(nèi)核中定義的,如下圖:
關(guān)鍵就需要 HZ 這個(gè)數(shù)值大小,HZ 是跟系統(tǒng)的時(shí)鐘頻率有關(guān),每個(gè)操作系統(tǒng)都不一樣,在我的 Linux 系統(tǒng)中 HZ 大小是 1000,如下圖:知道了 HZ 的大小,那么就可以算出:
最大延遲確認(rèn)時(shí)間是 200 ms (1000/5)
最短延遲確認(rèn)時(shí)間是 40 ms (1000/25)
怎么關(guān)閉 TCP 延遲確認(rèn)機(jī)制?
如果要關(guān)閉 TCP 延遲確認(rèn)機(jī)制,可以在 Socket 設(shè)置里啟用 TCP_QUICKACK,啟用 TCP_QUICKACK,就相當(dāng)于關(guān)閉 TCP 延遲確認(rèn)機(jī)制。
// 1 表示開(kāi)啟 TCP_QUICKACK,即關(guān)閉 TCP 延遲確認(rèn)機(jī)制 int value = 1 ;
setsockopt(socketfd, IPPROTO_TCP, TCP_QUICKACK, (char *)& value, sizeof (int ));
實(shí)驗(yàn)驗(yàn)證
實(shí)驗(yàn)一
接下來(lái),來(lái)給大家做個(gè)實(shí)驗(yàn),驗(yàn)證這個(gè)結(jié)論:當(dāng)被動(dòng)關(guān)閉方(上圖的服務(wù)端)在 TCP 揮手過(guò)程中,「沒(méi)有數(shù)據(jù)要發(fā)送」并且「開(kāi)啟了 TCP 延遲確認(rèn)機(jī)制」,那么第二和第三次揮手就會(huì)合并傳輸,這樣就出現(xiàn)了三次揮手。
服務(wù)端的代碼如下,做的事情很簡(jiǎn)單,就讀取數(shù)據(jù),然后當(dāng) read 返回 0 的時(shí)候,就馬上調(diào)用 close 關(guān)閉連接。因?yàn)?TCP 延遲確認(rèn)機(jī)制是默認(rèn)開(kāi)啟的,所以不需要特殊設(shè)置。
#include #include #include #include #include #include #include #include #include #define MAXLINE 1024 int main (int argc, char *argv[]) { // 1. 創(chuàng)建一個(gè)監(jiān)聽(tīng) socket int listenfd = socket(AF_INET, SOCK_STREAM, 0 ); if (listenfd < 0 )
{ fprintf (stderr , "socket error : %s\n" , strerror(errno)); return -1 ;
} // 2. 初始化服務(wù)器地址和端口 struct sockaddr_in server_addr ; bzero(&server_addr, sizeof (struct sockaddr_in));
server_addr.sin_family = AF_INET;
server_addr.sin_addr.s_addr = htonl(INADDR_ANY);
server_addr.sin_port = htons(8888 ); // 3. 綁定地址+端口 if (bind(listenfd, (struct sockaddr *)(&server_addr), sizeof (struct sockaddr)) < 0 )
{ fprintf (stderr ,"bind error:%s\n" , strerror(errno)); return -1 ;
} printf ("begin listen....\n" ); // 4. 開(kāi)始監(jiān)聽(tīng) if (listen(listenfd, 128 ))
{ fprintf (stderr , "listen error:%s\n\a" , strerror(errno)); exit (1 );
} // 5. 獲取已連接的socket struct sockaddr_in client_addr ; socklen_t client_addrlen = sizeof (client_addr); int clientfd = accept(listenfd, (struct sockaddr *)&client_addr, &client_addrlen); if (clientfd < 0 ) { fprintf (stderr , "accept error:%s\n\a" , strerror(errno)); exit (1 );
} printf ("accept success\n" ); char message[MAXLINE] = {0 }; while (1 ) { //6. 讀取客戶端發(fā)送的數(shù)據(jù) int n = read(clientfd, message, MAXLINE); if (n < 0 ) { // 讀取錯(cuò)誤 fprintf (stderr , "read error:%s\n\a" , strerror(errno)); break ;
} else if (n == 0 ) { // 返回 0 ,代表讀到 FIN 報(bào)文 fprintf (stderr , "client closed \n" );
close(clientfd); // 沒(méi)有數(shù)據(jù)要發(fā)送,立馬關(guān)閉連接 break ;
}
message[n] = 0 ; printf ("received %d bytes: %s\n" , n, message);
}
close(listenfd); return 0 ;
}
客戶端代碼如下,做的事情也很簡(jiǎn)單,與服務(wù)端連接成功后,就發(fā)送數(shù)據(jù)給服務(wù)端,然后睡眠一秒后,就調(diào)用 close 關(guān)閉連接,所以客戶端是主動(dòng)關(guān)閉方:
欲知詳情,請(qǐng)下載word文檔
下載文檔
本站聲明: 本文章由作者或相關(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)系本站刪除。
在工業(yè)自動(dòng)化領(lǐng)域,Modbus協(xié)議憑借其開(kāi)放性和易用性成為設(shè)備通信的"通用語(yǔ)言"。然而,當(dāng)工程師面對(duì)Modbus RTU、ASCII和TCP三種變體時(shí),如何根據(jù)具體場(chǎng)景做出最優(yōu)選擇?本文將從編碼機(jī)制、通信效率、錯(cuò)誤檢測(cè)等...
關(guān)鍵字:
Modbus協(xié)議
TCP
TCP/IP(Transmission Control Protocol/Internet Protocol,傳輸控制協(xié)議/網(wǎng)際協(xié)議)是指能夠在多個(gè)不同網(wǎng)絡(luò)間實(shí)現(xiàn)信息傳輸?shù)膮f(xié)議簇。TCP/IP協(xié)議不僅僅指的是TCP 和I...
關(guān)鍵字:
TCP
IP
把TCP首部想象成一封信的信封,每個(gè)字段對(duì)應(yīng)信封上的不同信息。源端口和目的端口就像寄信人和收信人的門(mén)牌號(hào),序列號(hào)和確認(rèn)號(hào)相當(dāng)于書(shū)信的頁(yè)碼編號(hào)和回執(zhí)編號(hào)。數(shù)據(jù)偏移量可以比作信封上留出的貼郵票位置,保留字段就像信封上預(yù)留的空...
關(guān)鍵字:
TCP
首部信息
三次握手的目的,確保雙方都能正常通信,確認(rèn)雙方的發(fā)送和接收能力正常。可能舉一個(gè)生活中的例子,比如打電話時(shí)的確認(rèn)過(guò)程。
關(guān)鍵字:
TCP
通信
服務(wù)器接收請(qǐng)求是一個(gè)涉及網(wǎng)絡(luò)層(IP/端口綁定)、傳輸層(UDP/TCP/TLS 適配)、應(yīng)用層(SIP 協(xié)議解析)
關(guān)鍵字:
服務(wù)器
TCP
UDP
RPC 是遠(yuǎn)程過(guò)程調(diào)用協(xié)議,實(shí)現(xiàn)跨進(jìn)程透明通信,通過(guò)注冊(cè)中心動(dòng)態(tài)管理服務(wù),支持高效二進(jìn)制傳輸(如 Protobuf)、負(fù)載均衡和故障容錯(cuò),解耦服務(wù)間依賴,提升分布式系統(tǒng)擴(kuò)展性與可靠性。
關(guān)鍵字:
PRC
服務(wù)端
客戶端
在TCP(傳輸控制協(xié)議)網(wǎng)絡(luò)通信中,粘包問(wèn)題一直是開(kāi)發(fā)者需要面對(duì)和解決的難題。TCP粘包,即發(fā)送方多次寫(xiě)入的數(shù)據(jù)在接收方被讀取時(shí),多個(gè)數(shù)據(jù)包粘合在一起,導(dǎo)致接收方難以正確解析和處理數(shù)據(jù)。這種問(wèn)題的出現(xiàn),主要源于TCP的傳...
關(guān)鍵字:
TCP
粘包
TCP(Transmission Control Protocol,傳輸控制協(xié)議)是互聯(lián)網(wǎng)中廣泛使用的可靠傳輸協(xié)議,它通過(guò)三次握手過(guò)程來(lái)確保通信雙方能夠建立一個(gè)可靠的連接。然而,在復(fù)雜的網(wǎng)絡(luò)環(huán)境中,TCP三次握手過(guò)程可能...
關(guān)鍵字:
TCP
傳輸控制協(xié)議
舊金山2024年7月22日 /美通社/ -- 百度國(guó)際旗下基于深度學(xué)習(xí)技術(shù)的智能廣告平臺(tái)MediaGo今天宣布,對(duì)平臺(tái)的SmartBid智能出價(jià)產(chǎn)品進(jìn)行全面升級(jí),推出了最大轉(zhuǎn)化出價(jià)模式,旨在保證成本可控的同時(shí),最大限度提...
關(guān)鍵字:
MEDIA
GO
TCP
PERFORMANCE
本次直播活動(dòng)旨在紀(jì)念那些為現(xiàn)代互聯(lián)網(wǎng) 奠定基礎(chǔ)的發(fā)展 新澤西州皮斯卡特維2024年5月13日 /美通社/ -- 旨在通過(guò)推動(dòng)技術(shù)進(jìn)步以造福人類的全球最大技術(shù)專業(yè)組...
關(guān)鍵字:
IEEE
互聯(lián)網(wǎng)
TCP
GOOGLE
據(jù)業(yè)內(nèi)信息,近日Tweetbot、Twitterific等推特第三方客戶端大規(guī)模失效,導(dǎo)致用戶無(wú)法正常使用,開(kāi)發(fā)人員表示是推特提供給第三方的公共API出現(xiàn)驗(yàn)證失敗問(wèn)題,但是目前推特方面并未做出任何正式通知。
關(guān)鍵字:
推特
客戶端
API
TCP 是基于連接的數(shù)據(jù)流的協(xié)議,先建立連接再進(jìn)行通信,而且在通信過(guò)程中會(huì)檢查數(shù)據(jù)是否發(fā)送成功。優(yōu)點(diǎn)就是保證數(shù)據(jù)的完整性和準(zhǔn)確性,缺點(diǎn)就是效率較低。
關(guān)鍵字:
TCP
數(shù)據(jù)流
協(xié)議
近來(lái)總有人唱衰客戶端開(kāi)發(fā)的前景,一位干脆取名叫“iOS勸退帶頭人”的網(wǎng)友講了這樣一個(gè)案例:朋友的初創(chuàng)公司一共15人左右,招一個(gè)iOS開(kāi)發(fā),預(yù)算15k以內(nèi)。周一開(kāi)放職位,周二就收到了900多份簡(jiǎn)歷。根據(jù)985學(xué)歷、大廠背景...
關(guān)鍵字:
客戶端
iOS開(kāi)發(fā)
簡(jiǎn)歷
在進(jìn)行socket通信開(kāi)發(fā)時(shí),一般會(huì)用到TCP或UDP這兩種傳輸層協(xié)議,UDP(User Datagram Protocol)是一種面向無(wú)連接的協(xié)議,在數(shù)據(jù)發(fā)送前,不需要提前建立連接,它可以更高效地傳輸數(shù)據(jù),但可靠性無(wú)法...
關(guān)鍵字:
socket
TCP
UDP
之前寫(xiě)過(guò) TCP 三次握手和四次揮手過(guò)程中,途中某一步的報(bào)文丟失會(huì)發(fā)生什么的文章。
關(guān)鍵字:
TCP
服務(wù)端
事情從一個(gè)健身教練說(shuō)起吧。李東,自稱亞健康終結(jié)者,嘗試使用互聯(lián)網(wǎng)的模式拓展自己的業(yè)務(wù)。在某款新開(kāi)發(fā)的聊天軟件琛琛上發(fā)布廣告。鍵盤(pán)說(shuō)來(lái)就來(lái)。瘋狂發(fā)送"李東",回車發(fā)送!,"亞健康終結(jié)者",再回車發(fā)送!還記得四層網(wǎng)絡(luò)協(xié)議長(zhǎng)什...
關(guān)鍵字:
TCP
UDP
數(shù)據(jù)包
應(yīng)用層
傳輸控制協(xié)議(TCP,Transmission Control Protocol)是為了在不可靠的互聯(lián)網(wǎng)絡(luò)上提供可靠的端到端字節(jié)流而專門(mén)設(shè)計(jì)的一個(gè)傳輸協(xié)議。
關(guān)鍵字:
TCP
IP是Internet Protocol(網(wǎng)際互連協(xié)議)的縮寫(xiě),是TCP/IP體系中的網(wǎng)絡(luò)層協(xié)議。設(shè)計(jì)IP的目的是提高網(wǎng)絡(luò)的可擴(kuò)展性:一是解決互聯(lián)網(wǎng)問(wèn)題,實(shí)現(xiàn)大規(guī)模、異構(gòu)網(wǎng)絡(luò)的互聯(lián)互通;二是分割頂層網(wǎng)絡(luò)應(yīng)用和底層網(wǎng)絡(luò)技術(shù)...
關(guān)鍵字:
IP
TCP
主機(jī)
Internet 協(xié)議集支持一個(gè)無(wú)連接的傳輸協(xié)議,該協(xié)議稱為用戶數(shù)據(jù)包協(xié)議(UDP,User Datagram Protocol)。UDP 為應(yīng)用程序提供了一種無(wú)需建立連接就可以發(fā)送封裝的 IP 數(shù)據(jù)包的方法。RFC 7...
關(guān)鍵字:
UDP
TCP
IP
客戶端(Client)或稱為用戶端,是指與服務(wù)器相對(duì)應(yīng),為客戶提供本地服務(wù)的程序。除了一些只在本地運(yùn)行的應(yīng)用程序之外,一般安裝在普通的客戶機(jī)上,需要與服務(wù)端互相配合運(yùn)行 [1] 。因特網(wǎng)發(fā)展以后,較常用的用戶端包括了如萬(wàn)...
關(guān)鍵字:
客戶端
數(shù)據(jù)庫(kù)
即時(shí)通訊