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

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

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

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

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

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

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

缺點：

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

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

而且，因為TCP有確認機制、三次握手機制，這些也導致TCP容易被人利用，實現(xiàn)DOS、DDOS、CC等攻擊。

優(yōu)點：

快，比TCP稍安全

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

缺點：

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

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

三次握手

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

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

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

發(fā)送                  確認


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

4次揮手

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

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

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

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

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

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

主機A對主機B的請求進行確認,將ACK置1,雙方向的關(guān)閉結(jié)束.

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

三次握手的原因

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

四次揮手的原因

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

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

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

Http 是在應用層上的傳輸協(xié)議，底層是 TCP 協(xié)議實現(xiàn)的，
它一種面向無狀態(tài)的連接，短連接，
之所以說他無狀態(tài)，是因為在每一次請求完成之后，都會把連接關(guān)了，不會記住是哪一個客戶端連接。

四種請求方式
get，post，pull，delete

請求信息有請求行，請求頭，請求正文

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

響應信息有相應行，響應頭，響應正文

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

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

Http1.0一次只能處理一個請求和響應，Http1.1一次能處理多個請求和響應

多個請求和響應過程可以重疊

增加了更多的請求頭和響應頭，比如Host、If-Unmodified-Since請求頭等

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

主要的區(qū)別

在osi模型中，http工作于應用層，https工作與傳輸層

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

http不需要證書，https需要響應額證書

http以http開頭，默認端口是80，https 以https開頭，默認的端口是243

上傳視頻的時候為什么不用 Http 協(xié)議？

因為上傳視頻的時候文件一般比較長，如果我們采用 post 請求的話，寫到輸出流中，它并不會直接寫到服務器中，而是會緩存在內(nèi)存中，會影響我們的執(zhí)行效率

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

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

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

擁塞控制與流量控制

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

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

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

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

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

洪水攻擊

向服務器端發(fā)送大量的偽TCP連接請求，這時候服務器端會進入syn_receive半連接狀態(tài)，服務器端會嘗試發(fā)送多次包來確認，因為這些連接時假冒的，所以并不會完成第三次握手，導致服務器端保持大量的半連接狀態(tài)，耗費資源，是TCP連接隊列被塞滿。

解決方法：

做一些應急處理，對這些IP地址的特征來禁止響應的IP地址字段的訪問。

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

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