面試季-網絡安全常見面試題整理1

一、請描述常見 Web 攻擊？Owasp TOP10有哪些？

常見 Web 攻擊

XSS攻擊

XSS（Cross Site Scripting）跨站腳本攻擊，爲了避免與層疊樣式表（CSS）混淆，故將跨站腳本攻擊縮寫爲XSS。原理即在網頁中嵌入惡意腳本，當用戶打開網頁時，惡意腳本便開始在用戶瀏覽器上執行，以盜取客戶端cookie、用戶名、密碼，甚至下載木馬程式。

解決方法：XSS之因此會發生,是由於用戶輸入的數據變成了代碼。所以,咱們須要對用戶輸入的數據進行HTML轉義處理,將其中的「尖括號」、「單引號」、「引號」 之類的特殊字符進行轉義編碼。

SQL注入攻擊

經過把SQL命令假裝成正常的HTTP請求參數,傳遞到服務端,欺騙服務器最終執行惡意的SQL命令,達到入侵目的。攻擊者能夠利用SQL注入漏洞,查詢非受權信息, 修改數據庫服務器的數據,改變表結構,甚至是獲取服務器root權限。總而言之,SQL注入漏洞的危害極大,攻擊者採用的SQL指令,決定攻擊的威力。當前涉及到大批量數據泄露的攻擊事件,大部分都是經過利用SQL注入來實施的目的。

如何防範SQL注入攻擊

Web端

1）有效性檢驗。

2）限制字符串輸入的長度。

服務端

1）不用拼接SQL字符串。

2）使用預編譯的PrepareStatement。

3）有效性檢驗。(爲何服務端還要作有效性檢驗？第一準則，外部都是不可信的，防止攻擊者繞過Web端請求)

4）過濾SQL須要的參數中的特殊字符。好比單引號、雙引號。
 

DDos 攻擊

客戶端向服務端發送請求連接數據包，服務端向客戶端發送確認數據包，客戶端不向服務端發送確認數據包，服務器一直等待來自客戶端的確認

DDos 預防：

1）限制同時打開SYN半連接的數目

2）縮短SYN半連接的Time out 時間

3）關閉沒必要要的服務

文件上傳漏洞

文件上傳漏洞，指的是用戶上傳一個可執行的腳本文件，並經過此腳本文件得到了執行服務端命令的能力。
許多第三方框架、服務，都曾經被爆出文件上傳漏洞，好比很早以前的Struts2，以及富文本編輯器等等，可被攻擊者上傳惡意代碼，有可能服務端就被人黑了。

如何防範文件上傳漏洞，文件上傳的目錄設置爲不可執行。

1）判斷文件類型。在判斷文件類型的時候，能夠結合使用MIME Type，後綴檢查等方式。由於對於上傳文件，不能簡單地經過後綴名稱來判斷文件的類型，由於攻擊者能夠將可執行文件的後綴名稱改成圖片或其餘後綴類型，誘導用戶執行。

2）對上傳的文件類型進行白名單校驗，只容許上傳可靠類型。

3）上傳的文件須要進行從新命名，使攻擊者沒法猜測上傳文件的訪問路徑，將極大地增長攻擊成本，同時向shell.php.rar.ara這種文件，由於重命名而沒法成功實施攻擊。

4）限制上傳文件的大小。

5）單獨設置文件服務器的域名。

CSRF攻擊

跨站點請求僞造，指攻擊者經過跨站請求，以合法的用戶的身份進行非法操做。能夠這麼理解CSRF攻擊：攻擊者盜用你的身份，以你的名義向第三方網站發送惡意請求。CRSF能作的事情包括利用你的身份發郵件，發短信，進行交易轉帳，甚至盜取帳號信息。

如何防範CSRF攻擊

安全框架，例如Spring Security。

token機制。在HTTP請求中進行token驗證，若是請求中沒有token或者token內容不正確，則認爲CSRF攻擊而拒絕該請求。
驗證碼。一般狀況下，驗證碼可以很好的遏制CSRF攻擊，可是不少狀況下，出於用戶體驗考慮，驗證碼只能做爲一種輔助手段，而不是最主要的解決方案。

referer識別。在HTTP Header中有一個字段Referer，它記錄了HTTP請求的來源地址。若是Referer是其餘網站，就有多是

CSRF攻擊，則拒絕該請求。可是，服務器並不是都能取到Referer。不少用戶出於隱私保護的考慮，限制了Referer的發送。在某些狀況下，瀏覽器也不會發送Referer，例如HTTPS跳轉到HTTP。

1）驗證請求來源地址；

2）關鍵操做添加驗證碼；

3）在請求地址添加 token 並驗證。

XSS攻擊

跨站點腳本攻擊，指攻擊者經過篡改網頁，嵌入惡意腳本程序，在用戶瀏覽網頁時，控制用戶瀏覽器進行惡意操做的一種攻擊方式。如何防範XSS攻擊

1）前端，服務端，同時須要字符串輸入的長度限制。

2）前端，服務端，同時須要對HTML轉義處理。將其中的」<」,」>」等特殊字符進行轉義編碼。

防 XSS 的核心是必須對輸入的數據作過濾處理。

Owasp TOP10

（1） 注入

將不受信任的數據做爲命令或查詢的一部分發送到解析器時，會產生諸如SQL注入、NoSQL注入、OS注入和LDAP注入的注入缺陷。攻擊者的惡意數據能夠誘使解析器在沒有適當受權的狀況下執行非預期命令或訪問數據。

如何防止：

• 防止注入漏洞須要將數據與命令語句、查詢語句分隔開來。

• 最佳選擇是使用安全的API，徹底避免使用解釋器，或提供參數化界面的接口，或遷移到ORM或實體框架。

• 使用正確的或「白名單」的具備恰當規範化的輸入驗證方法一樣會有助於防止注入攻擊，但這不是一個完整的防護，由於許多應用程序在輸入中須要特殊字符，例如文本區域或移動應用程序的API。

• 對於任何剩餘的動態查詢，可使用該解釋器的特定轉義語法轉義特殊字符。OWASP的JavaEncoder和相似的庫提供了這樣的轉義例程。

• 在查詢中使用LIMIT和其餘SQL控件，以防止在SQL注入時大量地泄露記錄。

（2） 失效的身份認證

一般，經過錯誤使用應用程序的身份認證和會話管理功能，攻擊者可以破譯密碼、密鑰或會話令牌，或者利用其它開發缺陷來暫時性或永久性冒充其餘用戶的身份。

如何防止：

• 在可能的狀況下，實現多因素身份驗證，以防止自動、憑證填充、暴力破解和被盜憑據再利用攻擊。

• 不要使用發送或部署默認的憑證，特別是管理員用戶。

• 執行弱密碼檢查，例如測試新或變動的密碼，以糾正「排名前10000個弱密碼」列表。

• 修改密碼複雜度策略，密碼由大/小寫字母+特殊字符+數字組成，長度大於8位，按期90天修改密碼。

• 確認註冊、憑據恢復和API路徑，經過對全部輸出結果使用相同的消息，用以抵禦帳戶枚舉攻擊。

• 限制或逐漸延遲失敗的登陸嘗試。記錄全部失敗信息並在憑據填充、暴力破解或其餘攻擊被檢測時提醒管理員。

• 使用服務器端安全的內置會話管理器，在登陸後生成高度複雜的新隨機會話ID。會話ID不能在URL中，能夠安全地存儲和當登出、閒置、絕對超時後使其失效。

（3） 敏感數據泄露

許多Web應用程序和API都沒法正確保護敏感數據，例如：財務數據、醫療數據和PII數據。攻擊者能夠經過竊取或修改未加密的數據來實施信用卡詐騙、身份盜竊或其餘犯罪行爲。未加密的敏感數據容易受到破壞，所以，咱們須要對敏感數據加密，這些數據包括：傳輸過程當中的數據、存儲的數據以及瀏覽器的交互數據。

如何防止：

• 對系統處理、存儲或傳輸的數據分類，並根據分類進行訪問控制。

• 熟悉與敏感數據保護相關的法律和條例，並根據每項法規要求保護敏感數據。

• 對於不必存放的、重要的敏感數據，應當儘快清除，或者經過PCIDSS標記或攔截。未存儲的數據不能被竊取。

• 確保存儲的全部敏感數據被加密。

• 確保使用了最新的、強大的標準算法或密碼、參數、協議和密匙，而且密鑰管理到位。

• 確保傳輸過程當中的數據被加密，如：使用TLS。確保數據加密被強制執行，如：使用HTTP嚴格安全傳輸協議(HSTS)。

• 禁止緩存對包含敏感數據的響應。

• 確保使用密碼專用算法存儲密碼，如：Argon二、scrypt、bcrypt或者PBKDF2。將工做因素(延遲因素)設置在可接受範圍。

• 單獨驗證每一個安全配置項的有效性。

（4） XML外部實體(XXE)

當開發人員暴露一個對內部實現對象的引用時，例如，一個文件、目錄或者數據庫密匙，就會產生一個不安全的直接對象引用。在沒有訪問控制檢測或其餘保護時，攻擊者會操控這些引用去訪問未受權數據。許多較早的或配置錯誤的XML處理器評估了XML文件中的外部實體引用。攻擊者能夠利用外部實體竊取使用URI文件處理器的內部文件和共享文件、監聽內部掃描端口、執行遠程代碼和實施拒絕服務攻擊。

如何防止：

• 儘量使用簡單的數據格式(如：JSON)，避免對敏感數據進行序列化。

• 及時修復或更新應用程序或底層操做系統使用的全部XML處理器和庫。同時，經過依賴項檢測，將SOAP更新到1.2版本或更高版本。

• 在應用程序的全部XML解析器中禁用XML外部實體和DTD進程。

• 在服務器端實施積極的(「白名單」)輸入驗證、過濾和清理，以防止在XML文檔、標題或節點中出現惡意數據。

• 驗證XML或XSL文件上傳功能是否使用XSD驗證或其餘相似驗證方法來驗證上傳的XML文件。

• 儘管在許多集成環境中，手動代碼審查是大型、複雜應用程序的最佳選擇，可是SAST工具能夠檢測源代碼中的XXE漏洞。

（5） 失效的訪問控制

未對經過身份驗證的用戶實施恰當的訪問控制。攻擊者能夠利用這些缺陷訪問未經受權的功能或數據，例如：訪問其餘用戶的賬戶、查看敏感文件、修改其餘用戶的數據、更改訪問權限等。

如何防止：

• 除公有資源外，默認狀況下拒絕訪問。

• 使用一次性的訪問控制機制，並在整個應用程序中不斷重用它們，包括最小化CORS使用。

• 創建訪問控制模型以強制執行全部權記錄，而不是接受用戶建立、讀取、更新或刪除的任何記錄。

• 域訪問控制對每一個應用程序都是惟一的，但業務限制要求應由域模型強制執行。

• 禁用Web服務器目錄列表，並確保文件元數據(如：git)不存在於Web的根目錄中。

• 記錄失敗的訪問控制，並在適當時向管理員告警(如：重複故障)。

• 對API和控制器的訪問進行速率限制，以最大限度地下降自動化攻擊工具的危害。

• 當用戶註銷後，服務器上的JWT令牌應失效。

（6） 安全配置錯誤

安全配置錯誤是最多見的安全問題，這一般是因爲不安全的默認配置、不完整的臨時配置、開源雲存儲、錯誤的HTTP標頭配置以及包含敏感信息的詳細錯誤信息所形成的。所以，咱們不只須要對全部的操做系統、框架、庫和應用程序進行安全配置，並且必須及時修補和升級它們。

如何防止：

• 一個能夠快速且易於部署在另外一個鎖定環境的可重複的加固過程。開發、質量保證和生產環境都應該進行相同配置，而且，在每一個環境中使用不一樣的密碼。這個過程應該是自動化的，以儘可能減小安裝一個新安全環境的耗費。

• 搭建最小化平臺，該平臺不包含任何沒必要要的功能、組件、文檔和示例。移除或不安裝不適用的功能和框架。

• 檢查和修復安全配置項來適應最新的安全說明、更新和補丁，並將其做爲更新管理過程的一部分。

• 一個能在組件和用戶間提供有效的分離和安全性的分段應用程序架構，包括：分段、容器化和雲安全組。

• 向客戶端發送安全指令，如：安全標頭。

• 在全部環境中可以進行正確安全配置和設置的自動化過程。

（7）跨站腳本(XSS)

當應用程序的新網頁中包含不受信任的、未經恰當驗證或轉義的數據時，或者使用能夠建立HTML或JavaScript的瀏覽器API更新現有的網頁時，就會出現XSS缺陷。XSS讓攻擊者可以在受害者的瀏覽器中執行腳本，並劫持用戶會話、破壞網站或將用戶重定向到惡意站點。

如何防止：

• 使用設計上就會自動編碼來解決XSS問題的框架，如：Ruby3.0或ReactJS。瞭解每一個框架的XSS保護的侷限性，並適當地處理未覆蓋的用例。

• 爲了不反射式或存儲式的XSS漏洞，最好的辦法是根據HTML輸出的上下文(包括：主體、屬性、JavaScript、CSS或URL)對全部不可信的HTTP請求數據進行恰當的轉義。

• 在客戶端修改瀏覽器文檔時，爲了不DOMXSS攻擊，最好的選擇是實施上下文敏感數據編碼。

• 使用內容安全策略(CSP)是對抗XSS的深度防護策略。若是不存在能夠經過本地文件放置惡意代碼的其餘漏洞(例如：路徑遍歷覆蓋和容許在網絡中傳輸的易受攻擊的庫)，則該策略是有效的。

（8） 不安全的反序列化

不安全的反序列化會致使遠程代碼執行。即便反序列化缺陷不會致使遠程代碼執行，攻擊者也能夠利用它們來執行攻擊，包括：重播攻擊、注入攻擊和特權升級攻擊。

如何防止：

• 執行完整性檢查，如：任何序列化對象的數字簽名，以防止惡意對象建立或數據篡改。

• 在建立對象以前強制執行嚴格的類型約束，由於代碼一般被指望成一組可定義的類。繞過這種技術的方法已經被證實，因此徹底依賴於它是不可取的。

• 若是可能，隔離運行那些在低特權環境中反序列化的代碼。

• 記錄反序列化的例外狀況和失敗信息，如：傳入的類型不是預期的類型，或者反序列處理引起的例外狀況。

• 限制或監視來自於容器或服務器傳入和傳出的反序列化網絡鏈接。

• 監控反序列化，當用戶持續進行反序列化時，對用戶進行警告。

（9） 使用含已知漏洞的組件

組件(例如：庫、框架和其餘軟件模塊)擁有和應用程序相同的權限。若是應用程序中含有已知漏洞的組件被攻擊者利用，可能會形成嚴重的數據丟失或服務器接管。同時，使用含有已知漏洞的組件的應用程序和API可能會破壞應用程序防護、形成各類攻擊併產生嚴重影響。

如何防止：

• 移除不使用的依賴、不須要的功能、組件、文件和文檔。

• 利用如versions、DependencyCheck、retire.js等工具來持續的記錄客戶端和服務器端以及它們的依賴庫的版本信息。持續監控如CVE和NVD等是否發佈已使用組件的漏洞信息，可使用軟件分析工具來自動完成此功能。訂閱關於使用組件安全漏洞的警告郵件。

• 僅從官方渠道安全的獲取組件，並使用簽名機制來下降組件被篡改或加入惡意漏洞的風險。

• 監控那些再也不維護或者不發佈安全補丁的庫和組件。若是不能打補丁，能夠考慮部署虛擬補丁來監控、檢測或保護。

（10） 不足的日誌記錄和監控

不足的日誌記錄和監控，以及事件響應缺失或無效的集成，使攻擊者可以進一步攻擊系統、保持持續性或轉向更多系統，以及篡改、提取或銷燬數據。大多數缺陷研究顯示，缺陷被檢測出的時間超過200天，且一般經過外部檢測方檢測，而不是經過內部流程或監控檢測。

如何防止：

• 確保全部登陸、訪問控制失敗、輸入驗證失敗可以被記錄到日誌中去，並保留足夠的用戶上下文信息，以識別可疑或惡意賬戶，併爲後期取證預留足夠時間。

• 確保日誌以一種能被集中日誌管理解決方案使用的形式生成。

• 確保高額交易有完整性控制的審計信息，以防止篡改或刪除，例如審計信息保存在只能進行記錄增長的數據庫表中。

• 創建有效的監控和告警機制，使可疑活動在可接受的時間內被發現和應對。

二、重要協議分佈層

三、請描述arp協議的工做原理

ARP（Address Resolution Protocol），地址解析協議。ARP爲IP地址到對應的硬件地址之間提供動態映射。咱們之因此用動態這個詞是由於這個過程是自動完成的，通常應用程序用戶或系統管理員沒必要關心。

• 每臺主機都會在本身的ARP緩衝區中創建一個 ARP列表，以表示IP地址和MAC地址的對應關係。
• 當源主機須要將一個數據包要發送到目的主機時，會首先檢查本身 ARP列表中是否存在該 IP地址對應的MAC地址。若是有，就直接將數據包發送到這個MAC地址；若是沒有，就向本地網段發起一個ARP請求的廣播包，查詢此目的主機對應的MAC地址。此ARP請求數據包裏包括源主機的IP地址、硬件地址、以及目的主機的IP地址。
• 網絡中全部的主機收到這個ARP請求後，會檢查數據包中的目的IP是否和本身的IP地址一致。若是不相同就忽略此數據包；若是相同，該主機首先將發送端的MAC地址和IP地址添加到本身的ARP列表中。若是ARP表中已經存在該IP的信息，則將其覆蓋，而後給源主機發送一個 ARP響應數據包，告訴對方本身是它須要查找的MAC地址。
• 源主機收到這個ARP響應數據包後，將獲得的目的主機的IP地址和MAC地址添加到本身的ARP列表中，並利用此信息開始數據的傳輸。若是源主機一直沒有收到ARP響應數據包，表示ARP查詢失敗。

四、rip協議是什麼？rip的工做原理

RIP ：（Routing Information Protocol，路由信息協議），是內部網關協議IGP（Interior Gateway Protocol），採用距離矢量（也就是用距離做爲路由變量）路由算法，使用跳數即（HOP） 來衡量到達目標地址的路由距離，且最大跳數僅爲15）

原理：

• 初始化——RIP初始化時，會從每一個參與工做的接口上發送請求數據包。該請求數據包會向全部的RIP路由器請求一份完整的路由表。該請求經過LAN上的廣播形式發送LAN或者在點到點鏈路發送到下一跳地址來完成。這是一個特殊的請求，向相鄰設備請求完整的路由更新。
• 接收請求——RIP有兩種類型的消息，響應和接收消息。請求數據包中的每一個路由條目都會被處理，從而爲路由創建度量以及路徑。RIP採用跳數度量，值爲1的意爲着一個直連的網絡，16，爲網絡不可達。路由器會把整個路由表做爲接收消息的應答返回。
• 接收到響應——路由器接收並處理響應，它會經過對路由表項進行添加，刪除或者修改做出更新。
• 常規路由更新和定時——路由器以30秒一次地將整個路由表以應答消息地形式發送到鄰居路由器。路由器收到新路由或者現有路由地更新信息時，會設置一個180秒地超時時間。若是180秒沒有任何更新信息，路由的跳數設爲16。路由器以度量值16宣告該路由，直到刷新計時器從路由表中刪除該路由。刷新計時器的時間設爲240秒，或者比過時計時器時間多60秒。Cisco還用了第三個計時器，稱爲抑制計時器。接收到一個度量更高的路由以後的180秒時間就是抑制計時器的時間，在此期間，路由器不會用它接收到的新信息對路由表進行更新，這樣可以爲網路的收斂提供一段額外的時間。
•  觸發路由更新——當某個路由度量發生改變時，路由器只發送與改變有關的路由，並不發送完整的路由表。

五、什麼是RARP？工做原理

歸納： 反向地址轉換協議，網絡層協議，RARP與ARP工做方式相反。 RARP使只知道本身硬件地址的主機可以知道其IP地址。RARP發出要反向解釋的物理地址並但願返回其IP地址，應答包括可以提供所需信息的RARP服務器發出的IP地址。

原理：

(1)網絡上的每臺設備都會有一個獨一無二的硬件地址，一般是由設備廠商分配的MAC地址。主機從網卡上讀取MAC地址，而後在網絡上發送一個RARP請求的廣播數據包，請求RARP服務器回覆該主機的IP地址。

(2)RARP服務器收到了RARP請求數據包，爲其分配IP地址，並將RARP迴應發送給主機。

(3)主機收到RARP迴應後，就使用獲得的IP地址進行通信。
 

六、OSPF協議是什麼？並描述OSPF的工做原理。

OSPF(Open Shortest Path First開放式最短路徑優先)是一個內部網關協議(Interior Gateway Protocol,簡稱IGP)，用於在單一自治系統(autonomous system,AS)內決策路由。OSPF經過路由器之間通告網絡接口的狀態來創建鏈路狀態數據庫，生成最短路徑樹，每一個OSPF路由器使用這些最短路徑構造路由表。

原理：

首先，當路由器開啓OSPF後，路由器之間就會相互發送HELLO報文，HELLO報文中包含一些路由器和鏈路的相關信息，發送HELLO報文的目的是爲了造成鄰居表

而後，路由器之間就會發送LSA（LINK STATE ADVERTISEMENT，鏈路狀態通告），LSA告訴本身的鄰居路由器和本身相連的鏈路的狀態，最後，造成網絡的拓撲表，其實這個過程是很複雜的，他們通過發LSA，記錄LSA，裝發LSA，最後造成LSDB（鏈路狀態數據庫，即拓撲表），

造成拓撲表以後，在通過SPF算法，經過計算LSDB，最後造成路由表。造成路由表後，路由器就能夠根據路由表來轉發數據包，

可是，這只是理想狀況，若是以後，網絡拓撲發生了變化，或是網絡鏈路出現了問題，OSPF協議仍是會通過這三張表來從新計算新的路由，只不過不會這麼複雜了，路由器在默認狀況下，10S就會發送一次HELLO報文，以檢測鏈路狀態，保證鏈路始終是正常的。

七、TCP與UDP區別是什麼？

原文：https://blog.csdn.net/gao1440156051/article/details/52207032

•  基於鏈接vs無鏈接        

他們之間的第一點而且最重要的區別是：TCP是面向鏈接的協議，而UDP是無鏈接的協議。這意味着當一個客戶端和一個服務器經過TCP發送數據以前，必須先創建鏈接，他們能夠經過TCP發送數據。創建鏈接的過程也被稱爲TCP握手，他經過控制消息在客戶端和服務器之間互換來實現。下面的圖形象描述了TCP握手過程。客戶端，它也是TCP鏈接的發起者，發送一個SYN消息給服務器，該服務器端正在監聽某個TCP端口。服務器接收該消息併發送一個SYN-ACK消息，客戶端接受到該消息以後會再回一個ACK消息。一旦服務器收到ACK消息，TCP鏈接就創建成功，準備數據傳輸了。另外一方面，UDP是無鏈接的協議，和點對點鏈接以前不須要發送消息。這就是爲何，UDP更加適合消息的多播發布，從單個點向多個點傳輸消息。

• 可靠性不一樣

TCP提供交付保證,這意味着一個使用TCP協議發送的消息是保證交付給客戶端的。若是消息在傳輸過程當中丟失,那麼它將重發,這是由TCP協議自己控制的。另外一方面,UDP是不可靠的,它不提供任何交付的保證。一個數據報包在運輸途中可能會丟失。這就是爲何UDP是不適合保證交付的項目。

• 有序性

除了提供交付保證，爲TCP也保證了消息的有序性。該消息將以從服務器端發出的一樣的順序發送到客戶端，儘管這些消息到網絡的另外一端時多是無序的。TCP協議將會爲你排好序。UDP不提供任何有序性或序列性的保證。數據包將以任何可能的順序到達。這就是爲何TCP是適合須要順序交付方式的應用，儘管有基於UDP的協議經過使用序列號和重傳來提供有序和可靠性的應用，如TIBCO Rendezvous，他實際上就是一個基於UDP的應用。

• 數據邊界

TCP不保存數據的邊界，而UDP保證。在傳輸控制協議，數據以字節流的形式發送，並無明顯的標誌代表傳輸信號消息（段）的邊界。在UDP中，數據包單獨發送的，只有當他們到達時，纔會再次集成。包有明確的界限來哪些包已經收到，這意味着在消息發送後，在接收器接口將會有一個讀操做，來生成一個完整的消息。雖然TCP也將在收集全部字節以後生成一個完整的消息，可是這些信息在傳給傳輸給接受端以前將儲存在TCP緩衝區，以確保更好的使用網絡帶寬

• 速度

總而言之，TCP速度比較慢，而UDP速度比較快，由於TCP必須建立鏈接，以保證消息的可靠交付和有序性，他須要作比UDP多的多的事。這就是爲何UDP更適用於對速度比較敏感的應用，例如：在線視頻媒體，電視廣播和多人在線遊戲。

• 重量級vs輕量級

因爲上述的開銷，TCP被認爲是重量級的協議，而與之相比，UDP協議則是一個輕量級的協議。由於UDP傳輸的信息中不承擔任何間接創造鏈接，保證交貨或秩序的的信息。這也反映在用於承載元數據的頭的大小。

• 頭大小

TCP具備比UDP更大的頭。一個TCP數據包報頭的大小是20字節，UDP數據報報頭是8個字節。TCP報頭中包含序列號，ACK號，數據偏移量，保留，控制位，窗口，緊急指針，可選項，填充項，校驗位，源端口和目的端口。而UDP報頭只包含長度，源端口號，目的端口，和校驗和。

• 擁塞或流控制

TCP有流量控制。在任何用戶數據能夠被髮送以前，TCP須要三數據包來設置一個套接字鏈接。TCP處理的可靠性和擁塞控制。另外一方面，UDP不能進行流量控制。

• 用法和應用

在互聯網中，TCP和UDP都運行在哪些環境中了？在瞭解了TCP和UDP之間的關鍵差別以後，咱們能夠很容易地得出結論，哪一種狀況適合他們。因爲TCP提供可靠交付和有序性的保證，它是最適合須要高可靠而且對傳輸時間要求不高的應用。UDP是更適合的應用程序須要快速，高效的傳輸的應用，如遊戲。UDP是無狀態的性質，在服務器端須要對大量客戶端產生的少許請求進行應答的應用中是很是有用的。在實踐中，TCP被用於金融領域，如FIX協議是一種基於TCP的協議，而UDP是大量使用在遊戲和娛樂場所。

八、什麼是三次握手四次揮手？

原文：https://blog.csdn.net/qq_38950316/article/details/81087809

• 三次握手

第一次握手：創建鏈接時，客戶端發送syn包（syn=j）到服務器，並進入SYN_SENT狀態，等待服務器確認；SYN：同步序列編號（Synchronize Sequence Numbers）。

第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時本身也發送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態；

第三次握手：客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK(ack=k+1），此包發送完畢，客戶端和服務器進入ESTABLISHED（TCP鏈接成功）狀態，完成三次握手。

• 四次揮手

1）客戶端進程發出鏈接釋放報文，而且中止發送數據。釋放數據報文首部，FIN=1，其序列號爲seq=u（等於前面已經傳送過來的數據的最後一個字節的序號加1），此時，客戶端進入FIN-WAIT-1（終止等待1）狀態。 TCP規定，FIN報文段即便不攜帶數據，也要消耗一個序號。

2）服務器收到鏈接釋放報文，發出確認報文，ACK=1，ack=u+1，而且帶上本身的序列號seq=v，此時，服務端就進入了CLOSE-WAIT（關閉等待）狀態。TCP服務器通知高層的應用進程，客戶端向服務器的方向就釋放了，這時候處於半關閉狀態，即客戶端已經沒有數據要發送了，可是服務器若發送數據，客戶端依然要接受。這個狀態還要持續一段時間，也就是整個CLOSE-WAIT狀態持續的時間。

3）客戶端收到服務器的確認請求後，此時，客戶端就進入FIN-WAIT-2（終止等待2）狀態，等待服務器發送鏈接釋放報文（在這以前還須要接受服務器發送的最後的數據）。

4）服務器將最後的數據發送完畢後，就向客戶端發送鏈接釋放報文，FIN=1，ack=u+1，因爲在半關閉狀態，服務器極可能又發送了一些數據，假定此時的序列號爲seq=w，此時，服務器就進入了LAST-ACK（最後確認）狀態，等待客戶端的確認。

5）客戶端收到服務器的鏈接釋放報文後，必須發出確認，ACK=1，ack=w+1，而本身的序列號是seq=u+1，此時，客戶端就進入了TIME-WAIT（時間等待）狀態。注意此時TCP鏈接尚未釋放，必須通過2∗∗MSL（最長報文段壽命）的時間後，當客戶端撤銷相應的TCB後，才進入CLOSED狀態。

6）服務器只要收到了客戶端發出的確認，當即進入CLOSED狀態。一樣，撤銷TCB後，就結束了此次的TCP鏈接。能夠看到，服務器結束TCP鏈接的時間要比客戶端早一些。

【問題1】爲何鏈接的時候是三次握手，關閉的時候倒是四次握手？

答：由於當Server端收到Client端的SYN鏈接請求報文後，能夠直接發送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。可是關閉鏈接時，當Server端收到FIN報文時，極可能並不會當即關閉SOCKET，因此只能先回復一個ACK報文，告訴Client端，"你發的FIN報文我收到了"。只有等到我Server端全部的報文都發送完了，我才能發送FIN報文，所以不能一塊兒發送。故須要四步握手。

【問題2】爲何TIME_WAIT狀態須要通過2MSL(最大報文段生存時間)才能返回到CLOSE狀態？

答：雖然按道理，四個報文都發送完畢，咱們能夠直接進入CLOSE狀態了，可是咱們必須假象網絡是不可靠的，有能夠最後一個ACK丟失。因此TIME_WAIT狀態就是用來重發可能丟失的ACK報文。在Client發送出最後的ACK回覆，但該ACK可能丟失。Server若是沒有收到ACK，將不斷重複發送FIN片斷。因此Client不能當即關閉，它必須確認Server接收到了該ACK。Client會在發送出ACK以後進入到TIME_WAIT狀態。Client會設置一個計時器，等待2MSL的時間。若是在該時間內再次收到FIN，那麼Client會重發ACK並再次等待2MSL。所謂的2MSL是兩倍的MSL(Maximum Segment Lifetime)。MSL指一個片斷在網絡中最大的存活時間，2MSL就是一個發送和一個回覆所需的最大時間。若是直到2MSL，Client都沒有再次收到FIN，那麼Client推斷ACK已經被成功接收，則結束TCP鏈接。

【問題3】爲何不能用兩次握手進行鏈接？

答：3次握手完成兩個重要的功能，既要雙方作好發送數據的準備工做(雙方都知道彼此已準備好)，也要容許雙方就初始序列號進行協商，這個序列號在握手過程當中被髮送和確認。

       如今把三次握手改爲僅須要兩次握手，死鎖是可能發生的。做爲例子，考慮計算機S和C之間的通訊，假定C給S發送一個鏈接請求分組，S收到了這個分組，併發 送了確認應答分組。按照兩次握手的協定，S認爲鏈接已經成功地創建了，能夠開始發送數據分組。但是，C在S的應答分組在傳輸中被丟失的狀況下，將不知道S 是否已準備好，不知道S創建什麼樣的序列號，C甚至懷疑S是否收到本身的鏈接請求分組。在這種狀況下，C認爲鏈接還未創建成功，將忽略S發來的任何數據分 組，只等待鏈接確認應答分組。而S在發出的分組超時後，重複發送一樣的分組。這樣就造成了死鎖。

【問題4】若是已經創建了鏈接，可是客戶端忽然出現故障了怎麼辦？

TCP還設有一個保活計時器，顯然，客戶端若是出現故障，服務器不能一直等下去，白白浪費資源。服務器每收到一次客戶端的請求後都會從新復位這個計時器，時間一般是設置爲2小時，若兩小時尚未收到客戶端的任何數據，服務器就會發送一個探測報文段，之後每隔75秒鐘發送一次。若一連發送10個探測報文仍然沒反應，服務器就認爲客戶端出了故障，接着就關閉鏈接。

九、請描述OSI 的七層模型都有哪些？

原文連接：https://blog.csdn.net/meism5/article/details/90414270

OSI模型分爲七層，自下而上爲 物理層（Physical Layer）、數據鏈路層（Data Link Layer）、網絡層（Network Layer）、傳輸層（Transport Layer）、會話層（Session Layer）、表達層（Presentation Layer）、應用層（Application Layer）。

 

十、dns是什麼？請描述dns的工做原理

DNS（Domain Name Server，域名服務器）是進行域名(domain name)和與之相對應的IP地址 (IP address)轉換的服務器。DNS中保存了一張域名(domain name)和與之相對應的IP地址 (IP address)的表，以解析消息的域名。

原理：

• 客戶機提出域名解析請求，並將該請求發送給本地的域名服務器。
• 當本地的域名服務器收到請求後，就先查詢本地的緩存，若是有該紀錄項，則本地的域名服務器就直接把查詢的結果返回；若是本地的緩存中沒有該紀錄，則本地域名服務器就直接把請求發給根域名服務器，而後根域名服務器再返回給本地域名服務器一個所查詢域(根的子域) 的主域名服務器的地址。
• 本地服務器再向上一步返回的域名服務器發送請求，而後接受請求的服務器查詢本身的緩存，若是沒有該紀錄，則返回相關的下級的域名服務器的地址。
• 重複第四步，直到找到正確的紀錄。
• 本地域名服務器把返回的結果保存到緩存，以備下一次使用，同時還將結果返回給客戶機。

十一、請描述一次完整的HTTP請求過程

• TCP創建鏈接

HTTP協議是基於TCP協議來實現的，所以首先就是要經過TCP三次握手與服務器端創建鏈接，通常HTTP默認的端口號爲80；

• 瀏覽器發送請求命令

一旦創建了 TCP 鏈接，Web 瀏覽器就會向 Web 服務器發送請求命令。例如：GET/hello/index.jsp HTTP/1.1。瀏覽器發送其請求命令以後，還要以頭信息的形式向Web服務器發送一些別的信息(例：Accept ,User-Agent 等?)，以後瀏覽器發送了一空白行來通知服務器，它已經結束了該頭信息的發送。

• 服務器應答

客戶機向服務器發出請求後，服務器會客戶機進行應答，應答內容包括：協議的版本號和應答狀態碼 ：HTTP/1.1 200 OK，響應頭信息來記錄服務器本身的數據，被請求的文檔內容。最後發送一個空白行來表示頭信息的發送到此爲結束，接着以Content-Type響應頭信息所描述的格式發送用戶所請求的實際數據。

• 服務器斷開TCP鏈接

通常狀況下，一旦 服務器向瀏覽器發送了請求的數據，它就要關閉 TCP 鏈接，可是若是瀏覽器或者服務器在其頭信息加入了這行代碼：Connection:keep-alive，就會保持此鏈接狀態，瀏覽器能夠繼續經過相同的鏈接發送請求。保持鏈接節省了爲每一個請求創建新鏈接所需的時間，還節約了網絡帶寬。

• 瀏覽器接受到服務器響應的數據

瀏覽器解析服務器應答回來的 html 代碼和css，和js代碼；進行頁面的渲染呈現給用戶。

十二、請描述Cookies和session區別是什麼？

• session存放在服務器端，cookie存放在客戶端。
• session會隨着會話的結束而關閉，cookie則存放在客戶端瀏覽器上長期有效。
• session保存的是對象，cookie保存的是字符串
• 存放在cookie裏的信息容易泄露，一般只保存不重要的信息，重要的信息放在session中

1三、請描述GET 和 POST 的區別是什麼？

• GET在瀏覽器回退時是無害的，而POST會再次提交請求。

• GET產生的URL地址能夠被Bookmark，而POST不能夠。

• GET請求會被瀏覽器主動cache，而POST不會，除非手動設置。

• GET請求只能進行url編碼，而POST支持多種編碼方式。

• GET請求參數會被完整保留在瀏覽器歷史記錄裏，而POST中的參數不會被保留。

• GET請求在URL中傳送的參數是有長度限制的，而POST麼有。

• 對參數的數據類型，GET只接受ASCII字符，而POST沒有限制。

• GET比POST更不安全，由於參數直接暴露在URL上，因此不能用來傳遞敏感信息。

• GET參數經過URL傳遞，POST放在Request body中。

建議：

get方式的安全性較Post方式要差些，包含機密信息的話，建議用Post數據提交方式；

在作數據查詢時，建議用Get方式；而在作數據添加、修改或刪除時，建議用Post方式；

1四、請描述HTTPS和HTTP的區別是什麼？

數據加密傳輸，是HTTP和HTTPS之間的本質性區別。HTTPS基於HTTP協議，經過SSL或TLS提供加密處理數據、驗證對方身份以及數據完整性保護

https協議須要到ca申請證書，通常免費證書較少，於是須要必定費用。功能越強大的證書費用越高。

• http是超文本傳輸協議，信息是明文傳輸，https則是具備安全性的ssl加密傳輸協議。
• SEO方面：在2015年以前百度是沒法收錄HTTPS頁面的，不過自從2015年5月份百度搜索全站HTTPS加密後，就已經能夠收錄HTTPS了。谷歌則是從2014年起便開始收錄HTTPS頁面，而且HTTPS頁面權重比HTTP頁面更高。從SEO的角度來講，HTTPS和HTTP區別不大，甚至HTTPS效果更好。
• 性能問題：https作了加密就意味着客戶端服務端也須要附帶解密步驟，相比來講，在通信快捷上，性能有所不如http。
• 經濟方面
  （1）、SSL證書須要錢，功能越強大的證書費用越高，我的網站、小網站沒有必要通常不會用。
  （2）、SSL證書一般須要綁定IP，不能在同一IP上綁定多個域名，IPv4資源不可能支撐這個消耗（SSL有擴展能夠部分解決這個問題，可是比較麻煩，並且要求瀏覽器、操做系統支持，Windows XP就不支持這個擴展，考慮到XP的裝機量，這個特性幾乎沒用）。
  （3）、HTTPS鏈接緩存不如HTTP高效，大流量網站如非必要也不會採用，流量成本過高。
  （4）、HTTPS鏈接服務器端資源佔用高不少，支持訪客稍多的網站須要投入更大的成本，若是所有采用HTTPS，基於大部分計算資源閒置的假設的VPS的平均成本會上去。
  （5）、HTTPS協議握手階段比較費時，對網站的相應速度有負面影響，如非必要，沒有理由犧牲用戶體驗。
  
  
  
  
  

1五、請描述session 的工做原理？

Session又稱爲會話控制。因爲HTTP是無狀態協議，爲了保持瀏覽器與服務器之間的聯繫，纔有了Session。Session就是用於在服務器端保存用戶狀態的協議。一般用來保存用戶的登陸狀態。

當用戶訪問到一個服務器，服務器首先檢查這個用戶發來的請求裏是否包含了一個SESSION ID，若是包含了一個SESSION ID，則說明以前該用戶已經登錄過併爲此用戶建立過SESSION，那服務器就按照這個SESSION ID把這個SESSION在服務器的內存中查找出來，若是客戶端請求裏不包含有SESSION ID，則爲該客戶端建立一個SESSION並生成一個與此SESSION相關的SESSION ID。這個SESSION ID是惟一的、不重複的、不容易找到規律的字符串，這個SESSION ID將被在本次響應中返回到客戶端保存，而保存這個SESSION ID的正是COOKIE，這樣在交互過程當中瀏覽器能夠自動的按照規則把這個標識發送給服務器。