摘要：在網(wǎng)絡(luò)層有協(xié)議協(xié)議協(xié)議協(xié)議和協(xié)議。而且，因?yàn)橛写_認(rèn)機(jī)制三次握手機(jī)制，這些也導(dǎo)致容易被人利用，實(shí)現(xiàn)等攻擊。沒有的這些機(jī)制，較被攻擊者利用的漏洞就要少一些。但也是無法避免攻擊的，比如攻擊缺點(diǎn)不可靠，不穩(wěn)定。

HTTP協(xié)議（超文本傳輸協(xié)議）和 UDP（用戶數(shù)據(jù)包協(xié)議），TCP 協(xié)議（傳輸控制協(xié)議）

TCP/IP是個(gè)協(xié)議組，可分為四個(gè)層次：網(wǎng)絡(luò)接口層、網(wǎng)絡(luò)層、傳輸層和應(yīng)用層。
在網(wǎng)絡(luò)層有IP協(xié)議、ICMP協(xié)議、ARP協(xié)議、RARP協(xié)議和BOOTP協(xié)議。
在傳輸層中有TCP協(xié)議與UDP協(xié)議，arq協(xié)議。
在應(yīng)用層有FTP、HTTP、TELNET、SMTP、DNS等協(xié)議。

UDP與TCP的區(qū)別與聯(lián)系

一：UDP是面向無連接的協(xié)議，TCP 是面向連接的協(xié)議
UDP發(fā)出請(qǐng)求后，即發(fā)送數(shù)據(jù)之前不需要先連接，TCP 發(fā)送數(shù)據(jù)之前需要先連接
二：UDP 相對(duì)TCP來說是不可靠的
因?yàn)?UDP 在發(fā)送數(shù)據(jù)以后，沒有采用超時(shí)重發(fā)，停止等待機(jī)制，擁塞控制
三：TCP 面向流，UDP 面向報(bào)文

優(yōu)點(diǎn)：可靠，穩(wěn)定

TCP的可靠體現(xiàn)在TCP在傳遞數(shù)據(jù)之前，會(huì)有三次握手來建立連接，而且在數(shù)據(jù)傳遞時(shí)，有確認(rèn)、窗口、重傳、擁塞控制機(jī)制，在數(shù)據(jù)傳完后，還會(huì)斷開連接用來節(jié)約系統(tǒng)資源。

缺點(diǎn)：

慢，效率低，占用系統(tǒng)資源高，易被攻擊

TCP在傳遞數(shù)據(jù)之前，要先建連接，這會(huì)消耗時(shí)間，而且在數(shù)據(jù)傳遞時(shí)，確認(rèn)機(jī)制、重傳機(jī)制、擁塞控制機(jī)制等都會(huì)消耗大量的時(shí)間，而且要在每臺(tái)設(shè)備上維護(hù)所有的傳輸連接，事實(shí)上，每個(gè)連接都會(huì)占用系統(tǒng)的CPU、內(nèi)存等硬件資源。

而且，因?yàn)門CP有確認(rèn)機(jī)制、三次握手機(jī)制，這些也導(dǎo)致TCP容易被人利用，實(shí)現(xiàn)DOS、DDOS、CC等攻擊。

優(yōu)點(diǎn)：

快，比TCP稍安全

UDP沒有TCP的握手、確認(rèn)、窗口、重傳、擁塞控制等機(jī)制，UDP是一個(gè)無狀態(tài)的傳輸協(xié)議，所以它在傳遞數(shù)據(jù)時(shí)非?？臁]有TCP的這些機(jī)制，UDP較TCP被攻擊者利用的漏洞就要少一些。但UDP也是無法避免攻擊的，比如：UDP Flood攻擊……

缺點(diǎn)：

不可靠，不穩(wěn)定 。因?yàn)閁DP沒有TCP那些可靠的機(jī)制，在數(shù)據(jù)傳遞時(shí)，如果網(wǎng)絡(luò)質(zhì)量不好，就會(huì)很容易丟包。

### 三次握手與四次揮手

三次握手

第一次握手:第一次連接時(shí)，客戶端向服務(wù)器端發(fā)送SYN（syn=j），等待服務(wù)器端的確認(rèn)，此時(shí)客戶端進(jìn)入SYN_SEND狀態(tài)，SYN：同步序列號(hào)

第二次握手：服務(wù)器端收到客戶端發(fā)來的SYN，必須向客戶端發(fā)送ACK包（ack=j+1=k），同時(shí)自己必須發(fā)送一個(gè)SYN包，即syn+ack，此時(shí)進(jìn)入SYN_REC狀態(tài)

第三次握手：客戶端收到服務(wù)器端發(fā)來的syn+ack包，向服務(wù)器發(fā)送ack包（ack=k+1),發(fā)送完畢，此時(shí)進(jìn)入ESTABLISH狀態(tài)，連接成功，完成第三次連接。

發(fā)送                  確認(rèn)


第一次：SYN=1       SEQ=X               ACK=0（客）
第二次：SYN=1       SEQ=Y               ACK=X+1（服）
第三次：            SEQ=X+1             ACK=Y+1（客）

4次揮手

當(dāng)主機(jī)A完成數(shù)據(jù)傳輸后,將控制位FIN置1,提出停止TCP連接的請(qǐng)求

A進(jìn)入終止等待1（FIN-WAIT-1）狀態(tài)

主機(jī)B收到FIN后對(duì)其作出響應(yīng),確認(rèn)這一方向上的TCP連接將關(guān)閉,將ACK置1

tcp處于半關(guān)閉狀態(tài)（half-close）
a收到b端的確認(rèn)后，就進(jìn)入終止等待2狀態(tài)

由B 端再提出反方向的關(guān)閉請(qǐng)求,將FIN置1

進(jìn)入last-wait狀態(tài)

主機(jī)A對(duì)主機(jī)B的請(qǐng)求進(jìn)行確認(rèn),將ACK置1,雙方向的關(guān)閉結(jié)束.

進(jìn)入時(shí)間等待狀態(tài)（time-wait）
時(shí)間等待計(jì)數(shù)器設(shè)置的時(shí)間過了2msl以后，進(jìn)入closed狀態(tài)

三次握手的原因

如果只有兩次握手的話，比如說失效的報(bào)文段，突然發(fā)送到服務(wù)端，服務(wù)端收到失效報(bào)文段的請(qǐng)求后，會(huì)發(fā)送確認(rèn)報(bào)文，新的連接就建立起來了。但現(xiàn)在由于客戶端并沒有發(fā)出請(qǐng)求，所以并不會(huì)理睬服務(wù)端的確認(rèn)，也不會(huì)像服務(wù)端發(fā)送數(shù)據(jù)。而服務(wù)端以為已經(jīng)連接起來了，一直在等待，浪費(fèi)資源。

四次揮手的原因

TCP建立連接要進(jìn)行3次握手,而斷開連接要進(jìn)行4次,這是由于TCP的半關(guān)閉造成的,因?yàn)門CP連接是全雙工的(
即數(shù)據(jù)可在兩個(gè)方向上同時(shí)傳遞)所以進(jìn)行關(guān)閉時(shí)每個(gè)方向上都要多帶帶進(jìn)行關(guān)閉,這個(gè)單方向的關(guān)閉就叫半關(guān)閉.

關(guān)閉的方法是一方完成它的數(shù)據(jù)傳輸后,就發(fā)送一個(gè)FIN來向另一方通告將要終止這個(gè)方向的連接.當(dāng)一端收到一個(gè)FIN,它必須
通知應(yīng)用層TCP連接已終止了這個(gè)方向的數(shù)據(jù)傳送,發(fā)送FIN通常是應(yīng)用層進(jìn)行關(guān)閉的結(jié)果.

ACK TCP報(bào)頭的控制位之一,對(duì)數(shù)據(jù)進(jìn)行確認(rèn).確認(rèn)由目的端發(fā)出,用它來告訴發(fā)送端這個(gè)序列號(hào)之前的數(shù)據(jù)段
都收到了.比如,確認(rèn)號(hào)為X,則表示前X-1個(gè)數(shù)據(jù)段都收到了,只有當(dāng)ACK=1時(shí),確認(rèn)號(hào)才有效,當(dāng)ACK=0時(shí),確認(rèn)號(hào)無效,這時(shí)會(huì)要求重傳數(shù)據(jù),保證數(shù)據(jù)的完整性.
SYN 同步序列號(hào),TCP建立連接時(shí)將這個(gè)位置1
FIN 發(fā)送端完成發(fā)送任務(wù)位,當(dāng)TCP完成數(shù)據(jù)傳輸需要斷開時(shí),提出斷開連接的一方將這位置1

Http 是在應(yīng)用層上的傳輸協(xié)議，底層是 TCP 協(xié)議實(shí)現(xiàn)的，
它一種面向無狀態(tài)的連接，短連接，
之所以說他無狀態(tài)，是因?yàn)樵诿恳淮握?qǐng)求完成之后，都會(huì)把連接關(guān)了，不會(huì)記住是哪一個(gè)客戶端連接。

四種請(qǐng)求方式
get，post，pull，delete

請(qǐng)求信息有請(qǐng)求行，請(qǐng)求頭，請(qǐng)求正文

請(qǐng)求行：請(qǐng)求方式，請(qǐng)求地址，請(qǐng)求協(xié)議
請(qǐng)求頭：頭名稱，頭值
請(qǐng)求正文：（只有post請(qǐng)求才會(huì)有）

響應(yīng)信息有相應(yīng)行，響應(yīng)頭，響應(yīng)正文

響應(yīng)行：響應(yīng)協(xié)議，狀態(tài)碼，狀態(tài)信息
響應(yīng) 頭：頭名稱和頭值
響應(yīng)正文

http 2.0采用二進(jìn)制的格式傳送數(shù)據(jù)，不再使用文本格式傳送數(shù)據(jù)
http2.0對(duì)消息頭采用hpack壓縮算法，http1.x的版本消息頭帶有大量的冗余消息
http2.0 采用多路復(fù)用，即用一個(gè)tcp連接處理所有的請(qǐng)求，真正意義上做到了并發(fā)請(qǐng)求，流還支持優(yōu)先級(jí)和流量控制
http2.0支持server push，服務(wù)端可以主動(dòng)把css，jsp文件主動(dòng)推送到客戶端，不需要客戶端解析HTML，再發(fā)送請(qǐng)求，當(dāng)客戶端需要的時(shí)候，它已經(jīng)在客戶端了。

Http1.0一次只能處理一個(gè)請(qǐng)求和響應(yīng)，Http1.1一次能處理多個(gè)請(qǐng)求和響應(yīng)

多個(gè)請(qǐng)求和響應(yīng)過程可以重疊

增加了更多的請(qǐng)求頭和響應(yīng)頭，比如Host、If-Unmodified-Since請(qǐng)求頭等

https相當(dāng)于http加上安全套接字，采用ssl加密技術(shù)

主要的區(qū)別

在osi模型中，http工作于應(yīng)用層，https工作與傳輸層

http傳輸?shù)臅r(shí)候采用明文傳輸，https采用加密傳輸

http不需要證書，https需要響應(yīng)額證書

http以http開頭，默認(rèn)端口是80，https 以https開頭，默認(rèn)的端口是243

上傳視頻的時(shí)候?yàn)槭裁床挥?Http 協(xié)議？

因?yàn)樯蟼饕曨l的時(shí)候文件一般比較長，如果我們采用 post 請(qǐng)求的話，寫到輸出流中，它并不會(huì)直接寫到服務(wù)器中，而是會(huì)緩存在內(nèi)存中，會(huì)影響我們的執(zhí)行效率

停止等待機(jī)制：是指每發(fā)送完一個(gè)分組，就會(huì)停止發(fā)送，必須受到對(duì)這個(gè)分組的確認(rèn)才會(huì)繼續(xù)發(fā)送下一個(gè)分組

超時(shí)重傳：是指每發(fā)送一個(gè)分組，就會(huì)為這個(gè)分組啟動(dòng)一個(gè)超時(shí)計(jì)數(shù)器，在規(guī)定的時(shí)間內(nèi)沒有受到確認(rèn)，就會(huì)再次發(fā)送這個(gè)分組。

在連續(xù)ARQ協(xié)議中，為提高信道利用率，通常采取的做法是發(fā)送方維持一個(gè)發(fā)送窗口，凡是位于該窗口內(nèi)的分組都可以發(fā)送出去，無需等待確認(rèn)，在接收方是采用累積確認(rèn)，即對(duì)按需到達(dá)的分組后一個(gè)分組發(fā)送確認(rèn)，表明在這個(gè)分組以前的所有分組都已正確接收到

擁塞控制與流量控制

流量控制是一個(gè)端到端的過程，是值接收方限制發(fā)送方的速率不要太快，使接收方來得及接收；擁塞控制是一個(gè)全局的過程，是只不要向網(wǎng)絡(luò)注入太多的數(shù)據(jù)，導(dǎo)致鏈路或者路由器損壞；

擁塞控制采用四種算法：慢開始和擁塞控制，快重傳和快恢復(fù)

慢開始是cwnd（擁塞窗口）每次回從1開始，每經(jīng)過一個(gè)往返時(shí)間，cwnd的值就會(huì)加倍；
擁塞避免是指每經(jīng)過一個(gè)往返時(shí)間，cwnd的值會(huì)加一，是一個(gè)線性的過程。
慢開始和擁塞避免:會(huì)設(shè)置一個(gè)慢開始門限，當(dāng)cwnd《sshreh的時(shí)候，會(huì)采用滿開始算法，當(dāng)超過這個(gè)值的時(shí)候，會(huì)采用擁塞避免的算法，當(dāng)出現(xiàn)擁塞的時(shí)候，會(huì)把sshreh的值取為發(fā)送方窗口值當(dāng)前的一半，再把cwnd取為1，從1開始使用滿開始算法。

快重傳和快恢復(fù)收到三個(gè)重復(fù)確認(rèn)的時(shí)候，會(huì)把sshreh的值置為當(dāng)前值的一半，與慢開始不同的是，它會(huì)把擁塞窗口的值取為當(dāng)前慢開始門限的一半，執(zhí)行擁塞避免算法

快重傳要求接收方?jīng)]收到一段失序的報(bào)文段，就要向發(fā)送方發(fā)送一個(gè)確認(rèn)

洪水攻擊

向服務(wù)器端發(fā)送大量的偽TCP連接請(qǐng)求，這時(shí)候服務(wù)器端會(huì)進(jìn)入syn_receive半連接狀態(tài)，服務(wù)器端會(huì)嘗試發(fā)送多次包來確認(rèn)，因?yàn)檫@些連接時(shí)假冒的，所以并不會(huì)完成第三次握手，導(dǎo)致服務(wù)器端保持大量的半連接狀態(tài)，耗費(fèi)資源，是TCP連接隊(duì)列被塞滿。

解決方法：

做一些應(yīng)急處理，對(duì)這些IP地址的特征來禁止響應(yīng)的IP地址字段的訪問。

應(yīng)急處理畢竟太被動(dòng)，因?yàn)楸緳C(jī)房的F5比較空閑，運(yùn)維利用F5來擋攻擊，采用方式：讓客戶端先和F5三次握手，連接建立之后F5才轉(zhuǎn)發(fā)到后端業(yè)務(wù)服務(wù)器。

掃一掃，歡迎關(guān)注我的公眾號(hào) stormjun94。如果你有好的文章，也歡迎你的投稿。