https://blog.csdn.net/weixin_45912307/article/details/109229702
1. 三次握手，四次揮手過程

• 三次握手：
  • 第一次握手：客戶端傳送syn包(syn=1，seq=x)到伺服器，並進入SYN_SENT狀態，等待伺服器確認；
  • 第二次握手：伺服器收到syn包，必須確認客戶的SYN（ack=x+1），同時自己也傳送一個SYN包（syn=y），即SYN+ACK包，此時伺服器進入SYN_RECV狀態；
  • 第三次握手：客戶端收到伺服器的SYN＋ACK包，向伺服器傳送確認包ACK(ack=y+1)，此包傳送完畢，客戶端和伺服器進入ESTABLISHED狀態，完成三次握手。
    握手過程中傳送的包裡不包含資料，三次握手完畢後，客戶端與伺服器才正式開始傳送資料。理想狀態下，TCP連線一旦建立，在通訊雙方中的任何一方主動關閉連線之前，TCP 連線都將被一直保持下去。

• 四次揮手:斷開一個TCP連線則需要“四次揮手”。
  • 第一次揮手：主動關閉方傳送一個FIN，用來關閉主動方到被動關閉方的資料傳送，也就是主動關閉方告訴被動關閉方：我已經不 會再給你發資料了(當然，在fin包之前傳送出去的資料，如果沒有收到對應的ack確認報文，主動關閉方依然會重發這些資料)，但是，此時主動關閉方還可 以接受資料。
  • 第二次揮手：被動關閉方收到FIN包後，傳送一個ACK給對方，確認序號為收到序號+1（與SYN相同，一個FIN佔用一個序號）。
    -第三次揮手：被動關閉方傳送一個FIN，用來關閉被動關閉方到主動關閉方的資料傳送，也就是告訴主動關閉方，我的資料也傳送完了，不會再給你發資料了。
  • 第四次揮手：主動關閉方收到FIN後，傳送一個ACK給被動關閉方，確認序號為收到序號+1，至此，完成四次揮手。

2. OSI，TCP/IP，五層協議的體系結構，以及各層協議

• OSI分層 （7層）：物理層、資料鏈路層、網路層、傳輸層、會話層、表示層、應用層。
• TCP/IP分層（4層）：網路介面層、 網際層、運輸層、 應用層。
• 五層協議 （5層）：物理層、資料鏈路層、網路層、運輸層、 應用層。
• 每層作用
  • 物理層：傳輸二進位制位元流
  • 資料鏈路層：負責將上層資料封裝成幀
  • 網路層：負責路由定址和廣播 ；廣播：傳送訊息和接收訊息
    *傳輸層：負責建立一個可靠的端到端的連線；端到端：傳送到接收 ；過程：建立、維護、撤銷(拆除)
  • 會話層：負責建立維護拆除會話，為端應用之間提供控制功能(可靠性)
  • 表示層：完成對傳輸資料格式轉換：格式化；發：加密；接：解密；發：壓縮，接：解壓縮
  • 應用層：對應用軟體提供網路支援
    

3. cookie、session、token

• cookie:在客戶端用於儲存會話資訊的
• session：在伺服器端，記錄使用者的請求狀態，一般預設時間30min
  • session_id會存在cookie中，每次請求cookie中所有資訊都會傳遞給伺服器，伺服器通過session_id來識別是否是同一個使用者請求，不是同一個使用者的話，就會要求重新登入
• token：訪問許可權和身份認證
  • 鑑權：訪問的介面是否正常，是否非法訪問繞過前端。 防止跳過頁面直接訪問介面**token**
  • 授權：是否具有訪問介面的許可權。 唯一全域性動態的 。

4. 常用狀態碼

• 100系列：請求已收到繼續處理；

• 200系列:表示成功

  • 200：正常，伺服器正確響應了請求

• 300系列：資源重定向；

  • 301: 永久重定向；請求的網頁已永久移動到新位置
  • 302：臨時重定向；被請求文件已經臨時移至別處，此文件新的url在location響應頭中給出
  • 303：瀏覽器對於POST的響應進行重定向至新的url
  • 304 ： 服務端已經執行了GET，但檔案未變化
  • 307：瀏覽器對於GET的響應重定向至新的url

• 400系列：客戶端錯誤：

  • 400：錯誤請求；伺服器不理解請求的語法。
  • 401：未授權；如請求引數、方法、格式等
  • 403：拒絕訪問；伺服器理解客戶的請求，但拒絕處理它（沒有許可權）
  • 404：請求資源不存在

• 500系列：伺服器端出錯

  • 500：伺服器內部錯誤
  • 501：尚未實施；伺服器不具備完成請求的功能
  • 502:伺服器閘道器錯誤
  • 503：伺服器由於維護或者負載過重未能應答
  • 504請求超時

5. http請求頭和響應頭

• http請求及其結構：
  請求資訊包含：請求行(request) 請求頭部header 、空行和請求資料組成
• 響應及其結構
  響應組成：狀態行、響應頭報頭、空行和響應正文

6. IP地址的分類

• A類地址：以0開頭， 第一個位元組範圍：1~126（1.0.0.0 - 126.255.255.255）；

• B類地址：以10開頭， 第一個位元組範圍：128~191（128.0.0.0 - 191.255.255.255）；

• C類地址：以110開頭， 第一個位元組範圍：192~223（192.0.0.0 - 223.255.255.255）；

• D類地址：以1110開頭，第一個位元組範圍：224~239（224.0.0.0 - 239.255.255.255）；（作為多播使用）

• E類地址：保留

• 以下是留用的內部私有地址：

  • A類 10.0.0.0–10.255.255.255

  • B類 172.16.0.0–172.31.255.255

  • C類 192.168.0.0–192.168.255.255

7. 常見一些詞彙

• ARP:地址解析協議（Address Resolution Protocol）
• RARP:反地址解析協議(Reverse Address Resolution Protocol）將ip地址轉換為實體地址
• FTP:檔案傳輸協議（File Transfer Protocol）
• HTTP：超文字傳輸協議（Hyper Text Transfer Protocol）
• TCP:傳輸控制協議(Transmission Control Protocol)
• UDP:使用者資料報協議（User Datagram Protocol）

8. TCP的三次握手過程？為什麼會採用三次握手，若採用二次握手可以嗎？
建立連線的過程是利用客戶伺服器模式，假設主機A為客戶端，主機B為伺服器端。
（1）TCP的三次握手過程：主機A向B傳送連線請求；主機B對收到的主機A的報文段進行確認；主機A再次對主機B的確認進行確認。
（2）採用三次握手是為了防止失效的連線請求報文段突然又傳送到主機B，因而產生錯誤。失效的連線請求報文段是指：主機A發出的連線請求沒有收到主機B的確認，於是經過一段時間後，主機A又重新向主機B傳送連線請求，且建立成功，順序完成資料傳輸。考慮這樣一種特殊情況，主機A第一次傳送的連線請求並沒有丟失，而是因為網路節點導致延遲達到主機B，主機B以為是主機A又發起的新連線，於是主機B同意連線，並向主機A發回確認，但是此時主機A根本不會理會，主機B就一直在等待主機A傳送資料，導致主機B的資源浪費。
（3）採用兩次握手不行，原因就是上面說的失效的連線請求的特殊情況。

9. 常用四種請求方法

• get：
• post
• put
• delete

. get和post區別

• GET - 從指定的資源請求資料。請求的資料會附加在URL之後，以?分割URL和傳輸資料，多個引數用&連線
• POST - 向指定的資源提交要被處理的資料。POST請求會把請求的資料放置在HTTP請求包的包體中

10. http和https區別

• HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路協議，要比http協議安全。
• HTTPS和HTTP的區別主要如下：
  • https需要到cat申請證書，需要交費
  • http是超文字傳輸協議，資訊明文傳輸，https具有安全性的ssl加密傳輸協議
  • http和https使用完全不同的連線方式和埠號，前者80，後者443
  • http連線簡單、無狀態；https可進行加密傳輸、身份驗證網路協議

11. 請你說一下分散式和叢集的概念。
分散式：是指將不同的業務分佈在不同的地方，
叢集：是指將幾臺伺服器集中在一起，實現同一業務。

分散式中的每一個節點，都可以做叢集，而叢集並不一定就是分散式的。叢集有組織性，一臺伺服器垮了，其它的伺服器可以頂上來，而分散式的每一個節點，都完成不同的業務，一個節點垮了，哪這個業務就不可訪問了。

12. 路由定址(路由)：
在路由器中，從一個介面接收到資料包，根據資料包所攜帶的目的地址進行定向轉發到另一個介面的過程。

13. HTTP協議工作原理
瀏覽器作為HTTP客戶端通過URL向http服務端即web伺服器傳送所有請求
web伺服器根據接收到的請求後，向客戶端傳送響應資訊