1.GET和POST的不同
- get參數通過url傳遞，post放在request body中。
- get請求在url中傳遞的參數是有長度限制的，而post沒有。
- get比post更不安全，因爲參數直接暴露在url中，所以不能用來傳遞敏感信息。
- get請求只能進行url編碼，而post支持多種編碼方式
- get請求會瀏覽器主動cache，而post支持多種編碼方式。
- get請求參數會被完整保留在瀏覽歷史記錄裏，而post中的參數不會被保留。
- 本質都是tcp連接，但是GET一個數據包，POST兩個數據包，會先發header再發data。
2.一次完整的web頁面請求
- 打開網頁
- 建立tcp連接（http是應用層協議，需要先建立tcp連接）
- 瀏覽器向服務器發送請求。
- 瀏覽器發送header信息。
- web服務器應答。
- web服務器發送應答頭信息。
- web服務器發送數據。
- 發送完畢後web服務器關閉tcp連接，如果header裏有keep-alive則保持連接。
3.DNS域名解析
- 客戶端向dns服務器發送解析請求，dns服務器再自身緩存裏查找，找不到就往上一層找。
- localdns：本地運營商的dns。
- httpdns：使用http協議向dns服務器53端口請求，代替dns協議。
4.TCP和UDP
- 確認和重傳機制
- 建立連接時三次握手同步雙方的“序列號 + 確認號 + 窗口大小信息”，是確認重傳、流控的基礎
- 傳輸過程中，如果Checksum校驗失敗、丟包或延時，發送端重傳
- 數據排序：TCP有專門的序列號SN字段，可提供數據re-order
- 流量控制：窗口和計時器的使用。TCP窗口中會指明雙方能夠發送接收的最大數據量
- 擁塞控制
TCP的擁塞控制由4個核心算法組成。
- “慢啓動”（Slow Start）
- “擁塞避免”（Congestion avoidance）
- “快速重傳 ”（Fast Retransmit）
- “快速恢復”（Fast Recovery）
https：把數據進行非對稱加密，然後客戶端從第三方服務器獲取證書（加密後的公鑰）
http完整請求：建立tcp連接，發送http命令請求頭，web服務器應答，關閉tcp連接
tcp：
三次握手：
- 客戶端syn包
- 服務器syn+ack
- 客戶端ack
缺陷：洪泛攻擊
- 僞造客戶端發送大量連接請求，服務器確認，真正的客戶端不回覆，造成浪費服務器資源。
解決辦法：
- 監控無效鏈接
- 延緩tcb分配
- 防火牆
- 調短超時時間
四次揮手：
- 一方發起斷開請求，並停止數據傳輸。
- 對方確認。
- 對方傳輸完剩餘數據，並再次確認。
- 一方確認，斷開連接。
5.短鏈接和長鏈接的特點以及應用在什麼場合
長連接：
- 長連接多用於操作頻繁，點對點的通訊，而且連接數不能太多的情況。
- 每個TCP連接的建立都需要三次握手，每個TCP連接的斷開要四次揮手。
- 如果每次操作都要建立連接然後再操作的話處理速度會降低，所以每次操作後，下次操作時直接發送數據就可以了，不用再建立TCP連接。例如：數據庫的連接用長連接，如果用短連接頻繁的通信會造成socket錯誤，頻繁的socket創建也是對資源的浪費。
短連接：
- web網站的http服務一般都用短連接。因爲長連接對於服務器來說要耗費一定的資源。像web網站這麼頻繁的成千上萬甚至上億客戶端的連接用短連接更省一些資源。試想如果都用長連接，而且同時用成千上萬的用戶，每個用戶都佔有一個連接的話，可想而知服務器的壓力有多大。所以併發量大，但是每個用戶又不需頻繁操作的情況下需要短連接。總之：長連接和短連接的選擇要根據需求而定。
6.進程和線程
進程：
- 一個程序至少有一個進程，一個進程至少有一個線程。
- 系統進行資源分配和調度的一個獨立單位，有獨立的內存單元。地址空間，全局變量，文件描述符，各種硬件等等資源
- 進程有獨立的地址空間，所以崩潰後不會對其他進程造成影響。
- 進程切換需要保存上下文並切換，所以效率較低。使用中斷完成。
線程：
- 線程是進程的一個實體,是CPU調度和分派的基本單位。
- 相同進程內的線程資源共享，獨立的只有程序計數器、棧和一組寄存器。
- 一個線程可以創建和撤銷另一個線程，同一個進程中的多個線程之間可以併發執行。
- 線程崩潰會導致進程崩潰，崩潰一般伴隨棧溢出、讀取或者訪問了非法地址。
- 線程切換需要保存程序計數器和寄存器狀態，切換效率比進程高。
併發和並行：
- 並行：多個線程或者進程同時運行。
- 併發：多個線程按時間來分配處理器資源，宏觀上看是同時運行。
進程通信：
- 互斥量，同一時間只能由一個擁有互斥對象的線程訪問資源。
- 信號量，實現進程互斥，可以設置最大同時訪問的數量。互斥量就等於信號量設置爲1。
- 管道，ipc機制，表現爲一個只存在於內存中的文件，半雙工通信。匿名管道，只能相關進程間通信，如父子兄弟進程。命名管道，無關進程間通信。
- 共享內存，進程資源獨立，但是可以共享內存。
- 消息隊列，rpc
線程同步：
- 臨界區，串行訪問公共資源，由於是公共資源，所以只能同步同一進程內的線程。
- 互斥量，同一時間只能由一個擁有互斥對象的線程訪問資源。
- 信號量，實現進程互斥，可以設置最大同時訪問的數量。互斥量就等於信號量設置爲1。
- 事件，通過event來通知線程。
線程鎖：
讀寫鎖，可以多個線程共同讀，只有一個線程可以寫。
自旋鎖，獲取不到鎖就循環查看鎖是否釋放。互斥鎖獲取不到會睡眠。
樂觀鎖悲觀鎖。
死鎖：
- 互斥
- 佔有且等待
- 不可搶佔
- 循環等待
預防死鎖
破壞上述條件
搶佔資源，停止死鎖進程。
銀行家算法，實時統計進程和資源，只有資源夠才分配。
7.消息隊列和rpc
消息隊列：
- 消息從某一端發出，在某個隊列裏存儲，之後再由容器發到另一端。
- 作用，異步處理，應用解耦，流量削峯，進程通信。
- 模式，點對點，接受完應答後再從消息隊列中刪除消息。發佈訂閱模式，消息發到topic，然後由topic發給訂閱者。
- AMQP，應用層高級消息隊列協議。發佈者發到exchange，exchange再將消息發送到queue。topic
- rabbitmq隊列持久化，啓動兩個進程，一個存內存裏，另一個內存不足時存到磁盤上。隊列持久化。
- 消息確認機制，未確定會發給其他消費者，確認後再刪除消息。
- zeromq，性能最好，消息只保存在內存裏，但是請求應答一對一，不在乎消息丟失。不像一個消息隊列服務器，更像一個底層網絡通訊庫。不是單獨的服務或者程序，僅僅是一套組件，其封裝了網絡通信、消息隊列、線程調度等功能，向上層提供簡潔的API，應用程序通過加載庫文件，調用API函數來實現高性能網絡通信。
rpc：
- 遠程過程調用，一臺機器上的程序可以調用另一臺機器上的程序。跨越了傳輸層和應用層，用於分佈式服務的通信。
- rpc基於tcp/ip協議
- 內部子系統較多，接口非常多的情況下。rpc框架的好處，長鏈接，不需要跟HTTP一樣每次三次握手，減少網絡開銷。rpc框架有註冊中心，有豐富的監控管理；發佈、下線接口、動態擴展等，對調用方來說是無感知、統一化的操作。
rpc架構：
- 客戶端（Client），服務的調用方。
- 服務端（Server），真正的服務提供者。
- 客戶端存根，存放服務端的地址消息，再將客戶端的請求參數打包成網絡消息，然後通過網絡遠程發送給服務方。
- 服務端存根，接收客戶端發送過來的消息，將消息解包，並調用本地的方法。
rpc過程：
- 通訊問題，建立TCP連接傳輸數據
- 尋址問題
- 根據網絡協議序列化成二進制數據
- 接收到數據後反序列化成內存中的傳遞方式
- 返回值返回的時候也經過序列化反序列化。
- 序列化：應用層對象轉爲二進制串。 反序列化：二進制串轉換爲應用層對象。
8.分佈式系統
分佈式系統保證操作的時序性、原子性，操作互斥。
分佈式鎖實現對共享資源的搶佔。借鑑了多線程和多進程的互斥鎖。
分佈式鎖實現：
- redis根據判斷redis中是否有某個鎖id，判斷是否上鎖。
- 設置超時時間防止死鎖。
- redis去拿鎖，不存在就設置鎖並獲得鎖，存在的話判斷是否超時，超時了才能拿到。各種實現方式大同小異。
9.SOA和微服務
- 微服務相比於SOA更加精細，微服務更多的以獨立的進程的方式存在，互相之間並無影響；
- 微服務提供的接口方式更加通用化，例如HTTP RESTful方式，各種終端都可以調用，無關語言、平臺限制；
- 微服務更傾向於分佈式去中心化的部署方式，在互聯網業務場景下更適合；
微服務需求：
- 能支持當前業務需求，當然這只是最最基本的條件；
- 每個微服務都要去中心化，不存在單點故障；
- 每個微服務都要實現高可用、高負載，不會因爲一個服務不可用而影響了整套業務流；
- 每個微服務都要高度通用化，即多種終端都可調用，不分語言和平臺；
- 服務部署或升級簡單，不會消耗大量人力並且部署過程不易出現人爲錯誤；
- 微服務具有快速註冊與自動發現功能（例如dubbo框架）
10.websocket
- 基於tcp的全雙工協議，持久化協議，用於服務端主動向客戶端推送消息。輪詢，心跳檢測等。
- 一次握手即可建立永久連接。
- http協議可以通過keep-alive將多個http請求合成一個。
- websocket基於http協議，將http協議升級。
11.中斷和系統調用
- 中斷是指在CPU正常運行期間，由於內外部事件或由程序預先安排的事件引起的CPU暫時停止正在運行的程序，轉而爲該內部或外部事件或預先安排的事件服務的程序中去，服務完畢後再返回去繼續運行被暫時中斷的程序。Linux中通常分爲外部中斷（又叫硬件中斷）和內部中斷（又叫異常）。
- 系統調用通過中斷實現，中斷號爲0x80，應用程序通過系統調用訪問系統資源。
- 在用戶態和內核態切換，棧切換和寄存器保存與恢復，比較耗時。
- 中斷號——中斷向量表——查找中斷處理函數——處理。