一.新模塊'subprocess'

復(fù)習(xí): 在os模塊中調(diào)用系統(tǒng)命令 import os f = os.popen('dir') print(f.read())上面的結(jié)果和下面的寫法是一樣的 import subprocess r = subprocess.Popen('ls',shell=True,stdout=subprocess.PIPE,stderr=subprocess.PIPE)# subprocess.Popen(cmd,shell=True,subprocess.stdout,subprocess.stderr) # cmd : 代表系統(tǒng)命令 # shell = True 代表這條命令是 系統(tǒng)命令,告訴操作系統(tǒng),將cmd當(dāng)成系統(tǒng)命令去執(zhí)行 # stdout 是執(zhí)行完系統(tǒng)命令之后,用于保存結(jié)果的一個(gè)管道 # stderr 是執(zhí)行完系統(tǒng)命令之后,用于保存錯(cuò)誤結(jié)果的一個(gè)管道 stdout = r.stdout.read().decode('gbk') stderr = r.stderr.read().decode('gbk') print('正確的返回結(jié)果:',stdout) print('錯(cuò)誤的返回結(jié)果:',stderr) print('錯(cuò)誤的返回結(jié)果:',stderr)

?

二.粘包問題? (只有tcp協(xié)議才會(huì)發(fā)送粘包,udp不會(huì)發(fā)生)

?

EX:?發(fā)送端發(fā)送數(shù)據(jù),接收端不知道應(yīng)該如何去接收,造成的一種數(shù)據(jù)混亂的現(xiàn)象

1.合包機(jī)制(nagle算法):?將多次連續(xù)發(fā)送且間隔較小的數(shù)據(jù),進(jìn)行打包成一塊數(shù)據(jù)傳送.?

?

?

?

2.拆包機(jī)制:?還有一個(gè)機(jī)制是拆包機(jī)制,在發(fā)送端,因?yàn)槭艿骄W(wǎng)卡的MTU限制,會(huì)將大的超過MTU限制的數(shù)據(jù),進(jìn)行拆分,拆分成多個(gè)小的數(shù)據(jù),進(jìn)行傳輸. ?當(dāng)傳輸?shù)侥繕?biāo)主機(jī)的操作系統(tǒng)層時(shí),會(huì)重新將多個(gè)小的數(shù)據(jù)合并成原本的數(shù)據(jù)

針對 使用udp協(xié)議發(fā)送數(shù)據(jù),一次收發(fā)大小究竟多少合適?udp不會(huì)發(fā)生粘包,udp協(xié)議本層對一次收發(fā)數(shù)據(jù)大小的限制是:65535 - ip包頭(20) - udp包頭(8) = 65507站在數(shù)據(jù)鏈路層,因?yàn)榫W(wǎng)卡的MTU一般被限制在了1500,所以對于數(shù)據(jù)鏈路層來說,
一次收發(fā)數(shù)據(jù)的大小被限制在 1500 - ip包頭(20) - udp包頭(8) = 1472得到結(jié)論:如果sendto(num)num > 65507 報(bào)錯(cuò)1472 < num < 65507 會(huì)在數(shù)據(jù)鏈路層拆包,而udp本身就是不可靠協(xié)議,所以一旦拆包之后,造成的多個(gè)小數(shù)據(jù)包在網(wǎng)絡(luò)傳輸中,如果丟任何一個(gè),那么此次數(shù)據(jù)傳輸失敗num < 1472 是比較理想的狀態(tài)

?

轉(zhuǎn)載于:https://www.cnblogs.com/shuai1993/p/9477472.html

總結(jié)

以上是生活随笔為你收集整理的粘包问题,以及在python中如何调用操作系统命令的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。