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

HTTP協議（超文本傳輸協議）和 UDP（用戶數據包協議），TCP 協議（傳輸控制協議）

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

UDP與TCP的區別與聯系

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

優點：可靠，穩定

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

缺點：

慢，效率低，占用系統資源高，易被攻擊

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

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

優點：

快，比TCP稍安全

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

缺點：

不可靠，不穩定 。因為UDP沒有TCP那些可靠的機制，在數據傳遞時，如果網絡質量不好，就會很容易丟包。

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

三次握手

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

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

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

發送                  確認


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

4次揮手

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

A進入終止等待1（FIN-WAIT-1）狀態

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

tcp處于半關閉狀態（half-close）
a收到b端的確認后，就進入終止等待2狀態

由B 端再提出反方向的關閉請求,將FIN置1

進入last-wait狀態

主機A對主機B的請求進行確認,將ACK置1,雙方向的關閉結束.

進入時間等待狀態（time-wait）
時間等待計數器設置的時間過了2msl以后，進入closed狀態

三次握手的原因

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

四次揮手的原因

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

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

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

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

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

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

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

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

響應行：響應協議，狀態碼，狀態信息
響應 頭：頭名稱和頭值
響應正文

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

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

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

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

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

主要的區別

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

http傳輸的時候采用明文傳輸，https采用加密傳輸

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

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

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

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

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

超時重傳：是指每發送一個分組，就會為這個分組啟動一個超時計數器，在規定的時間內沒有受到確認，就會再次發送這個分組。

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

擁塞控制與流量控制

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

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

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

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

快重傳要求接收方沒收到一段失序的報文段，就要向發送方發送一個確認

洪水攻擊

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

解決方法：

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

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

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