在進(jìn)行UDP編程的時(shí)候,一次發(fā)送多少bytes好?
服務(wù)器:
fd:accept返回的連接描述字,每個(gè)連接有一個(gè),生命周期為連接周期。
注:sockfd是監(jiān)聽(tīng)描述字,一個(gè)服務(wù)器只有一個(gè),用于監(jiān)聽(tīng)是否有連接;fd是連接描述字,用于每個(gè)連接的操作。
fd:連接描述字。
buf:緩沖區(qū)buf。
count:緩沖區(qū)長(zhǎng)度。
注:大于0表示讀取的字節(jié)數(shù),返回0表示文件讀取結(jié)束,小于0表示發(fā)生錯(cuò)誤。
sockfd:服務(wù)器socket描述字。
addr:指向地址結(jié)構(gòu)指針。
addrlen:協(xié)議地址長(zhǎng)度。
注:一旦accept某個(gè)客戶(hù)機(jī)請(qǐng)求成功將返回一個(gè)全新的描述符用于標(biāo)識(shí)具體客戶(hù)的TCP連接。
sockfd:要監(jiān)聽(tīng)的sock描述字。
backlog:socket可以排隊(duì)的最大連接數(shù)。
sockfd:socket返回的套接字描述符,類(lèi)似于文件描述符fd。
addr:有個(gè)sockaddr類(lèi)型數(shù)據(jù)的指針,指向的是被綁定結(jié)構(gòu)變量。
addrlen:地址長(zhǎng)度。
domain:協(xié)議域,決定了socket的地址類(lèi)型,IPv4為AF_INET。
type:指定socket類(lèi)型,SOCK_STREAM為T(mén)CP連接。
protocol:指定協(xié)議。IPPROTO_TCP表示TCP協(xié)議,為0時(shí)自動(dòng)選擇type默認(rèn)協(xié)議。
創(chuàng)建socket -> int socket(int domain, int type, int protocol);
綁定socket和端口號(hào) -> int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen);
// IPv4的sockaddr地址結(jié)構(gòu)
struct sockaddr_in {
sa_family_t sin_family; // 協(xié)議類(lèi)型,AF_INET
in_port_t sin_port; // 端口號(hào)
struct in_addr sin_addr; // IP地址
};
struct in_addr {
uint32_t s_addr;
}
監(jiān)聽(tīng)端口號(hào) -> int listen(int sockfd, int backlog);
接收用戶(hù)請(qǐng)求 -> int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);
從socket中讀取字符 -> ssize_t read(int fd, void *buf, size_t count);
關(guān)閉socket -> int close(int fd);
客戶(hù)機(jī):
fd:同服務(wù)器端fd。
fd、buf、count:同read中意義。
大于0表示寫(xiě)了部分或全部數(shù)據(jù),小于0表示出錯(cuò)。
sockfd客戶(hù)端的sock描述字。
addr:服務(wù)器的地址。
addrlen:socket地址長(zhǎng)度。
創(chuàng)建socket -> int socket(int domain, int type, int protocol);
連接指定計(jì)算機(jī) -> int connect(int sockfd, struct sockaddr* addr, socklen_t addrlen);
向socket寫(xiě)入信息 -> ssize_t write(int fd, const void *buf, size_t count);
關(guān)閉oscket -> int close(int fd);
84、TCP 協(xié)議如何保證可靠傳輸?
第一種回答確認(rèn)和重傳:接收方收到報(bào)文就會(huì)確認(rèn),發(fā)送方發(fā)送一段時(shí)間后沒(méi)有收到確認(rèn)就會(huì)重傳。數(shù)據(jù)校驗(yàn):TCP報(bào)文頭有校驗(yàn)和,用于校驗(yàn)報(bào)文是否損壞。數(shù)據(jù)合理分片和排序:tcp會(huì)按最大傳輸單元(MTU)合理分片,接收方會(huì)緩存未按序到達(dá)的數(shù)據(jù),重新排序后交給應(yīng)用層。而UDP:IP數(shù)據(jù)報(bào)大于1500字節(jié),大于MTU。這個(gè)時(shí)候發(fā)送方的IP層就需要分片,把數(shù)據(jù)報(bào)分成若干片,是的每一片都小于MTU。而接收方IP層則需要進(jìn)行數(shù)據(jù)報(bào)的重組。由于UDP的特性,某一片數(shù)據(jù)丟失時(shí),接收方便無(wú)法重組數(shù)據(jù)報(bào),導(dǎo)致丟棄整個(gè)UDP數(shù)據(jù)報(bào)。流量控制:當(dāng)接收方來(lái)不及處理發(fā)送方的數(shù)據(jù),能通過(guò)滑動(dòng)窗口,提示發(fā)送方降低發(fā)送的速率,防止包丟失。擁塞控制:當(dāng)網(wǎng)絡(luò)擁塞時(shí),通過(guò)擁塞窗口,減少數(shù)據(jù)的發(fā)送,防止包丟失。第二種回答
建立連接(標(biāo)志位):通信前確認(rèn)通信實(shí)體存在。
序號(hào)機(jī)制(序號(hào)、確認(rèn)號(hào)):確保了數(shù)據(jù)是按序、完整到達(dá)。
數(shù)據(jù)校驗(yàn)(校驗(yàn)和):CRC校驗(yàn)全部數(shù)據(jù)。
超時(shí)重傳(定時(shí)器):保證因鏈路故障未能到達(dá)數(shù)據(jù)能夠被多次重發(fā)。
窗口機(jī)制(窗口):提供流量控制,避免過(guò)量發(fā)送。
擁塞控制:同上。
第三種回答
首部校驗(yàn)這個(gè)校驗(yàn)機(jī)制能夠確保數(shù)據(jù)傳輸不會(huì)出錯(cuò)嗎?答案是不能。
原因
TCP協(xié)議中規(guī)定,TCP的首部字段中有一個(gè)字段是校驗(yàn)和,發(fā)送方將偽首部、TCP首部、TCP數(shù)據(jù)使用累加和校驗(yàn)的方式計(jì)算出一個(gè)數(shù)字,然后存放在首部的校驗(yàn)和字段里,接收者收到TCP包后重復(fù)這個(gè)過(guò)程,然后將計(jì)算出的校驗(yàn)和和接收到的首部中的校驗(yàn)和比較,如果不一致則說(shuō)明數(shù)據(jù)在傳輸過(guò)程中出錯(cuò)。
這就是TCP的數(shù)據(jù)校驗(yàn)機(jī)制。但是這個(gè)機(jī)制能夠保證檢查出一切錯(cuò)誤嗎?顯然不能。
因?yàn)檫@種校驗(yàn)方式是累加和,也就是將一系列的數(shù)字(TCP協(xié)議規(guī)定的是數(shù)據(jù)中的每16個(gè)比特位數(shù)據(jù)作為一個(gè)數(shù)字)求和后取末位。但是小學(xué)生都知道A+B=B+A,假如在傳輸?shù)倪^(guò)程中有前后兩個(gè)16比特位的數(shù)據(jù)前后顛倒了(至于為什么這么巧合?我不知道,也許路由器有bug?也許是宇宙中的高能粒子擊中了電纜?反正這個(gè)事情的概率不為零,就有可能會(huì)發(fā)生),那么校驗(yàn)和的計(jì)算結(jié)果和顛倒之前是一樣的,那么接收端肯定無(wú)法檢查出這是錯(cuò)誤的數(shù)據(jù)。
解決方案
傳輸之前先使用MD5加密數(shù)據(jù)獲得摘要,跟數(shù)據(jù)一起發(fā)送到服務(wù)端,服務(wù)端接收之后對(duì)數(shù)據(jù)也進(jìn)行MD5加密,如果加密結(jié)果和摘要一致,則認(rèn)為沒(méi)有問(wèn)題
85、UDP是什么
提供無(wú)連接的,盡最大努力的數(shù)據(jù)傳輸服務(wù)(不保證數(shù)據(jù)傳輸?shù)目煽啃裕?/p>
86、TCP和UDP的區(qū)別
1、TCP面向連接(如打電話要先撥號(hào)建立連接);UDP是無(wú)連接的,即發(fā)送數(shù)據(jù)之前不需要建立連接
2、TCP提供可靠的服務(wù)。也就是說(shuō),通過(guò)TCP連接傳送的數(shù)據(jù),無(wú)差錯(cuò),不丟失,不重復(fù),且按序到達(dá);UDP盡最大努力交付,即不保證可靠交付
3、TCP面向字節(jié)流,實(shí)際上是TCP把數(shù)據(jù)看成一連串無(wú)結(jié)構(gòu)的字節(jié)流;UDP是面向報(bào)文的
UDP沒(méi)有擁塞控制,因此網(wǎng)絡(luò)出現(xiàn)擁塞不會(huì)使源主機(jī)的發(fā)送速率降低(對(duì)實(shí)時(shí)應(yīng)用很有用,如IP電話,實(shí)時(shí)視頻會(huì)議等)
4、每一條TCP連接只能是點(diǎn)到點(diǎn)的;UDP支持一對(duì)一,一對(duì)多,多對(duì)一和多對(duì)多的交互通信
5、TCP首部開(kāi)銷(xiāo)20字節(jié);UDP的首部開(kāi)銷(xiāo)小,只有8個(gè)字節(jié)
6、TCP的邏輯通信信道是全雙工的可靠信道,UDP則是不可靠信道
7、UDP是面向報(bào)文的,發(fā)送方的UDP對(duì)應(yīng)用層交下來(lái)的報(bào)文,不合并,不拆分,只是在其上面加上首部后就交給了下面的網(wǎng)絡(luò)層,論應(yīng)用層交給UDP多長(zhǎng)的報(bào)文,它統(tǒng)統(tǒng)發(fā)送,一次發(fā)送一個(gè)。而對(duì)接收方,接到后直接去除首部,交給上面的應(yīng)用層就完成任務(wù)了。因此,它需要應(yīng)用層控制報(bào)文的大小
TCP是面向字節(jié)流的,它把上面應(yīng)用層交下來(lái)的數(shù)據(jù)看成無(wú)結(jié)構(gòu)的字節(jié)流會(huì)發(fā)送,可以想象成流水形式的,發(fā)送方TCP會(huì)將數(shù)據(jù)放入“蓄水池”(緩存區(qū)),等到可以發(fā)送的時(shí)候就發(fā)送,不能發(fā)送就等著TCP會(huì)根據(jù)當(dāng)前網(wǎng)絡(luò)的擁塞狀態(tài)來(lái)確定每個(gè)報(bào)文段的大小。
87、UDP的特點(diǎn)有哪些(附贈(zèng)TCP的特點(diǎn))?
UDP是無(wú)連接的;UDP使用盡最大努力交付,即不保證可靠交付,因此主機(jī)不需要維持復(fù)雜的鏈接狀態(tài)(這里面有許多參數(shù));UDP是面向報(bào)文的;UDP沒(méi)有擁塞控制,因此網(wǎng)絡(luò)出現(xiàn)擁塞不會(huì)使源主機(jī)的發(fā)送速率降低(對(duì)實(shí)時(shí)應(yīng)用很有用,如IP電話,實(shí)時(shí)視頻會(huì)議等);UDP支持一對(duì)一、一對(duì)多、多對(duì)一和多對(duì)多的交互通信;UDP的首部開(kāi)銷(xiāo)小,只有8個(gè)字節(jié),比TCP的20個(gè)字節(jié)的首部要短。
那么,再說(shuō)一次TCP的特點(diǎn):
TCP是面向連接的。(就好像打電話一樣,通話前需要先撥號(hào)建立連接,通話結(jié)束后要掛機(jī)釋放連接);每一條TCP連接只能有兩個(gè)端點(diǎn),每一條TCP連接只能是點(diǎn)對(duì)點(diǎn)的(一對(duì)一);TCP提供可靠交付的服務(wù)。通過(guò)TCP連接傳送的數(shù)據(jù),無(wú)差錯(cuò)、不丟失、不重復(fù)、并且按序到達(dá);TCP提供全雙工通信。TCP允許通信雙方的應(yīng)用進(jìn)程在任何時(shí)候都能發(fā)送數(shù)據(jù)。TCP連接的兩端都設(shè)有發(fā)送緩存和接收緩存,用來(lái)臨時(shí)存放雙方通信的數(shù)據(jù);面向字節(jié)流。TCP中的“流”(stream)指的是流入進(jìn)程或從進(jìn)程流出的字節(jié)序列!懊嫦蜃止(jié)流”的含義是:雖然應(yīng)用程序和TCP的交互是一次一個(gè)數(shù)據(jù)塊(大小不等),但TCP把應(yīng)用程序交下來(lái)的數(shù)據(jù)僅僅看成是一連串的無(wú)結(jié)構(gòu)的字節(jié)流。
88、TCP對(duì)應(yīng)的應(yīng)用層協(xié)議
FTP:定義了文件傳輸協(xié)議,使用21端口.Telnet:它是一種用于遠(yuǎn)程登陸的端口,23端口SMTP:定義了簡(jiǎn)單郵件傳送協(xié)議,服務(wù)器開(kāi)放的是25號(hào)端口。POP3:它是和SMTP對(duì)應(yīng),POP3用于接收郵件。
89、UDP對(duì)應(yīng)的應(yīng)用層協(xié)議
DNS:用于域名解析服務(wù),用的是53號(hào)端口SNMP:簡(jiǎn)單網(wǎng)絡(luò)管理協(xié)議,使用161號(hào)端口TFTP(Trival File Transfer Protocal):簡(jiǎn)單文件傳輸協(xié)議,69
90、數(shù)據(jù)鏈路層常見(jiàn)協(xié)議?可以說(shuō)一下嗎?
協(xié)議名稱(chēng)作用ARP地址解析協(xié)議根據(jù)IP地址獲取物理地址RARP反向地址轉(zhuǎn)換協(xié)議根據(jù)物理地址獲取IP地址PPP點(diǎn)對(duì)點(diǎn)協(xié)議主要是用來(lái)通過(guò)撥號(hào)或?qū)>方式建立點(diǎn)對(duì)點(diǎn)連接發(fā)送數(shù)據(jù),使其成為各種主機(jī)、網(wǎng)橋和路由器之間簡(jiǎn)單連接的一種共通的解決方案“
91、Ping命令基于哪一層協(xié)議的原理是什么?
ping命令基于網(wǎng)絡(luò)層的命令,是基于ICMP協(xié)議工作的。
92、在進(jìn)行UDP編程的時(shí)候,一次發(fā)送多少bytes好?
當(dāng)然,這個(gè)沒(méi)有唯一答案,相對(duì)于不同的系統(tǒng),不同的要求,其得到的答案是不一樣的。
我這里僅對(duì)像ICQ一類(lèi)的發(fā)送聊天消息的情況作分析,對(duì)于其他情況,你或許也能得到一點(diǎn)幫助:首先,我們知道,TCP/IP通常被認(rèn)為是一個(gè)四層協(xié)議系統(tǒng),包括鏈路層,網(wǎng)絡(luò)層,運(yùn)輸層,應(yīng)用層.UDP屬于運(yùn)輸層,
下面我們由下至上一步一步來(lái)看:以太網(wǎng)(Ethernet)數(shù)據(jù)幀的長(zhǎng)度必須在46-1500字節(jié)之間,這是由以太網(wǎng)的物理特性決定的.這個(gè)1500字節(jié)被稱(chēng)為鏈路層的MTU(最大傳輸單元).但這并不是指鏈路層的長(zhǎng)度被限制在1500字節(jié),其實(shí)這這個(gè)MTU指的是鏈路層的數(shù)據(jù)區(qū).并不包括鏈路層的首部和尾部的18個(gè)字節(jié).
所以,事實(shí)上,這個(gè)1500字節(jié)就是網(wǎng)絡(luò)層IP數(shù)據(jù)報(bào)的長(zhǎng)度限制。因?yàn)镮P數(shù)據(jù)報(bào)的首部為20字節(jié),所以IP數(shù)據(jù)報(bào)的數(shù)據(jù)區(qū)長(zhǎng)度最大為1480字節(jié).而這個(gè)1480字節(jié)就是用來(lái)放TCP傳來(lái)的TCP報(bào)文段或UDP傳來(lái)的UDP數(shù)據(jù)報(bào)的.又因?yàn)閁DP數(shù)據(jù)報(bào)的首部8字節(jié),所以UDP數(shù)據(jù)報(bào)的數(shù)據(jù)區(qū)最大長(zhǎng)度為1472字節(jié).這個(gè)1472字節(jié)就是我們可以使用的字節(jié)數(shù)。
當(dāng)我們發(fā)送的UDP數(shù)據(jù)大于1472的時(shí)候會(huì)怎樣呢?這也就是說(shuō)IP數(shù)據(jù)報(bào)大于1500字節(jié),大于MTU.這個(gè)時(shí)候發(fā)送方IP層就需要分片(fragmentation).把數(shù)據(jù)報(bào)分成若干片,使每一片都小于MTU.而接收方IP層則需要進(jìn)行數(shù)據(jù)報(bào)的重組.這樣就會(huì)多做許多事情,而更嚴(yán)重的是,由于UDP的特性,當(dāng)某一片數(shù)據(jù)傳送中丟失時(shí),接收方便無(wú)法重組數(shù)據(jù)報(bào).將導(dǎo)致丟棄整個(gè)UDP數(shù)據(jù)報(bào)。
因此,在普通的局域網(wǎng)環(huán)境下,我建議將UDP的數(shù)據(jù)控制在1472字節(jié)以下為好.
進(jìn)行Internet編程時(shí)則不同,因?yàn)镮nternet上的路由器可能會(huì)將MTU設(shè)為不同的值.如果我們假定MTU為1500來(lái)發(fā)送數(shù)據(jù)的,而途經(jīng)的某個(gè)網(wǎng)絡(luò)的MTU值小于1500字節(jié),那么系統(tǒng)將會(huì)使用一系列的機(jī)制來(lái)調(diào)整MTU值,使數(shù)據(jù)報(bào)能夠順利到達(dá)目的地,這樣就會(huì)做許多不必要的操作.
鑒于Internet上的標(biāo)準(zhǔn)MTU值為576字節(jié),所以我建議在進(jìn)行Internet的UDP編程時(shí).最好將UDP的數(shù)據(jù)長(zhǎng)度控件在548字節(jié)(576-8-20)以?xún)?nèi)
93、TCP 利用滑動(dòng)窗口實(shí)現(xiàn)流量控制的機(jī)制?
流量控制是為了控制發(fā)送方發(fā)送速率,保證接收方來(lái)得及接收。TCP 利用滑動(dòng)窗口實(shí)現(xiàn)流量控制。
TCP 中采用滑動(dòng)窗口來(lái)進(jìn)行傳輸控制,滑動(dòng)窗口的大小意味著接收方還有多大的緩沖區(qū)可以用于接收數(shù)據(jù)。發(fā)送方可以通過(guò)滑動(dòng)窗口的大小來(lái)確定應(yīng)該發(fā)送多少字節(jié)的數(shù)據(jù)。當(dāng)滑動(dòng)窗口為 0 時(shí),發(fā)送方一般不能再發(fā)送數(shù)據(jù)報(bào),但有兩種情況除外,一種情況是可以發(fā)送緊急數(shù)據(jù)。
例如,允許用戶(hù)終止在遠(yuǎn)端機(jī)上的運(yùn)行進(jìn)程。另一種情況是發(fā)送方可以發(fā)送一個(gè) 1 字節(jié)的數(shù)據(jù)報(bào)來(lái)通知接收方重新聲明它希望接收的下一字節(jié)及發(fā)送方的滑動(dòng)窗口大小。
94、可以解釋一下RTO,RTT和超時(shí)重傳分別是什么嗎?
超時(shí)重傳:發(fā)送端發(fā)送報(bào)文后若長(zhǎng)時(shí)間未收到確認(rèn)的報(bào)文則需要重發(fā)該報(bào)文?赡苡幸韵聨追N情況:
發(fā)送的數(shù)據(jù)沒(méi)能到達(dá)接收端,所以對(duì)方?jīng)]有響應(yīng)。
接收端接收到數(shù)據(jù),但是ACK報(bào)文在返回過(guò)程中丟失。
接收端拒絕或丟棄數(shù)據(jù)。
RTO:從上一次發(fā)送數(shù)據(jù),因?yàn)殚L(zhǎng)期沒(méi)有收到ACK響應(yīng),到下一次重發(fā)之間的時(shí)間。就是重傳間隔。
通常每次重傳RTO是前一次重傳間隔的兩倍,計(jì)量單位通常是RTT。例:1RTT,2RTT,4RTT,8RTT......
重傳次數(shù)到達(dá)上限之后停止重傳。
RTT:數(shù)據(jù)從發(fā)送到接收到對(duì)方響應(yīng)之間的時(shí)間間隔,即數(shù)據(jù)報(bào)在網(wǎng)絡(luò)中一個(gè)往返用時(shí)。大小不穩(wěn)定。
發(fā)表評(píng)論
請(qǐng)輸入評(píng)論內(nèi)容...
請(qǐng)輸入評(píng)論/評(píng)論長(zhǎng)度6~500個(gè)字
最新活動(dòng)更多
-
即日-11.13立即報(bào)名>>> 【在線會(huì)議】多物理場(chǎng)仿真助跑新能源汽車(chē)
-
11月20日火熱報(bào)名中>> 2024 智能家居出海論壇
-
11月28日立即報(bào)名>>> 2024工程師系列—工業(yè)電子技術(shù)在線會(huì)議
-
12月19日立即報(bào)名>> 【線下會(huì)議】OFweek 2024(第九屆)物聯(lián)網(wǎng)產(chǎn)業(yè)大會(huì)
-
即日-12.26火熱報(bào)名中>> OFweek2024中國(guó)智造CIO在線峰會(huì)
-
即日-2025.8.1立即下載>> 《2024智能制造產(chǎn)業(yè)高端化、智能化、綠色化發(fā)展藍(lán)皮書(shū)》
推薦專(zhuān)題
- 1 【一周車(chē)話】沒(méi)有方向盤(pán)和踏板的車(chē),你敢坐嗎?
- 2 特斯拉發(fā)布無(wú)人駕駛車(chē),還未迎來(lái)“Chatgpt時(shí)刻”
- 3 特斯拉股價(jià)大跌15%:Robotaxi離落地還差一個(gè)蘿卜快跑
- 4 馬斯克給的“驚喜”夠嗎?
- 5 打完“價(jià)格戰(zhàn)”,大模型還要比什么?
- 6 馬斯克致敬“國(guó)產(chǎn)蘿卜”?
- 7 神經(jīng)網(wǎng)絡(luò),誰(shuí)是盈利最強(qiáng)企業(yè)?
- 8 比蘋(píng)果偉大100倍!真正改寫(xiě)人類(lèi)歷史的智能產(chǎn)品降臨
- 9 諾獎(jiǎng)進(jìn)入“AI時(shí)代”,人類(lèi)何去何從?
- 10 Open AI融資后成萬(wàn)億獨(dú)角獸,AI人才之爭(zhēng)開(kāi)啟
- 高級(jí)軟件工程師 廣東省/深圳市
- 自動(dòng)化高級(jí)工程師 廣東省/深圳市
- 光器件研發(fā)工程師 福建省/福州市
- 銷(xiāo)售總監(jiān)(光器件) 北京市/海淀區(qū)
- 激光器高級(jí)銷(xiāo)售經(jīng)理 上海市/虹口區(qū)
- 光器件物理工程師 北京市/海淀區(qū)
- 激光研發(fā)工程師 北京市/昌平區(qū)
- 技術(shù)專(zhuān)家 廣東省/江門(mén)市
- 封裝工程師 北京市/海淀區(qū)
- 結(jié)構(gòu)工程師 廣東省/深圳市