Android 面試必備 - 計算機網絡基本知識（TCP，UDP，Http，https）

簡介

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次揮手

1. 當主機A完成數據傳輸後,將控制位FIN置1,提出中止TCP鏈接的請求

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

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

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

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

進入last-wait狀態

1. 主機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加密技術

主要的區別

1. 在osi模型中，http工做於應用層，https工做與傳輸層
2. http傳輸的時候採用明文傳輸，https採用加密傳輸
3. http不須要證書，https須要響應額證書
4. http以http開頭，默認端口是80，https 以https開頭，默認的端口是243

上傳視頻的時候爲何不用 Http 協議？

由於上傳視頻的時候文件通常比較長，若是咱們採用 post 請求的話，寫到輸出流中，它並不會直接寫到服務器中，而是會緩存在內存中，會影響咱們的執行效率

---

擴展補充

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

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

在連續ARQ協議中，爲提升信道利用率，一般採起的作法是發送方維持一個發送窗口，凡是位於該窗口內的分組均可以發送出去，無需等待確認，在接收方是採用累積確認，即對按需到達的分組後一個分組發送確認，代表在這個分組之前的全部分組都已正確接收到

擁塞控制與流量控制

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

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

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

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

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

洪水攻擊

向服務器端發送大量的僞TCP鏈接請求，這時候服務器端會進入syn_receive半鏈接狀態，服務器端會嘗試發送屢次包來確認，由於這些鏈接時假冒的，因此並不會完成第三次握手，致使服務器端保持大量的半鏈接狀態，耗費資源，是TCP鏈接隊列被塞滿。

解決方法：

1. 作一些應急處理，對這些IP地址的特徵來禁止響應的IP地址字段的訪問。
2. 應急處理畢竟太被動，由於本機房的F5比較空閒，運維利用F5來擋攻擊，採用方式：讓客戶端先和F5三次握手，鏈接創建以後F5才轉發到後端業務服務器。

掃一掃，歡迎關注個人公衆號 stormjun94。若是你有好的文章，也歡迎你的投稿。