簡介
HTTP協議（超文本傳輸協議）和 UDP（用戶數據包協議），TCP 協議（傳輸控制協議）
TCP/IP是個協議組，可分爲四個層次：網絡接口層、網絡層、傳輸層和應用層。
在網絡層有IP協議、ICMP協議、ARP協議、RARP協議和BOOTP協議。
在傳輸層中有TCP協議與UDP協議，arq協議。
在應用層有FTP、HTTP、TELNET、SMTP、DNS等協議。
TCP 與 UDP
TCP與UDP基本區別
UDP與TCP的區別與聯繫
一：UDP是面向無連接的協議，TCP 是面向連接的協議
UDP發出請求後，即發送數據之前不需要先連接，TCP 發送數據之前需要先連接
二：UDP 相對TCP來說是不可靠的
因爲 UDP 在發送數據以後，沒有采用超時重發，停止等待機制，擁塞控制
三：TCP 面向流，UDP 面向報文
TCP優缺點：
優點：可靠，穩定
TCP的可靠體現在TCP在傳遞數據之前，會有三次握手來建立連接，而且在數據傳遞時，有確認、窗口、重傳、擁塞控制機制，在數據傳完後，還會斷開連接用來節約系統資源。
缺點：
- 慢，效率低，佔用系統資源高，易被攻擊
TCP在傳遞數據之前，要先建連接，這會消耗時間，而且在數據傳遞時，確認機制、重傳機制、擁塞控制機制等都會消耗大量的時間，而且要在每臺設備上維護所有的傳輸連接，事實上，每個連接都會佔用系統的CPU、內存等硬件資源。 - 而且，因爲TCP有確認機制、三次握手機制，這些也導致TCP容易被人利用，實現DOS、DDOS、CC等攻擊。
UDP優缺點：
優點：
- 快，比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 與 https
Http 是在應用層上的傳輸協議，底層是 TCP 協議實現的，
它一種面向無狀態的連接，短連接，
之所以說他無狀態，是因爲在每一次請求完成之後，都會把連接關了，不會記住是哪一個客戶端連接。
四種請求方式
get，post，pull，delete
請求信息有請求行，請求頭，請求正文
請求行：請求方式，請求地址，請求協議
請求頭：頭名稱，頭值
請求正文：（只有post請求纔會有）
響應信息有相應行，響應頭，響應正文
響應行：響應協議，狀態碼，狀態信息
響應 頭：頭名稱和頭值
響應正文
Http1.0與Http1.1，Http2.0的區別
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請求頭等
http和https的區別
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。如果你有好的文章，也歡迎你的投稿。