計算機網絡方面

1.TCP與UDP的區別

（1）TCP是面向鏈接的；UDP是無鏈接的，即發送數據前不須要創建鏈接

（2）TCP提供可靠的服務，經過TCP傳輸的數據無差錯、不丟失、不重複且按順序到達；UDP盡最大努力交付，且不保證可靠交付

（3）TCP面向字節流；UDP面向報文

　　TCP有一個發送緩衝區，當應用程序傳送的數據塊過長時，TCP就能夠把它劃分短一些再傳送，若是應用程序一次只發送一個字節，TCP也能夠等到積累足夠多的字節後再構成報文段發送出去；

　　對於UDP，應用層交給UDP多長的報文，UDP原樣發送，既不會拆分，也不會合並。

 

TCP的優勢：可靠，穩定，在數據傳輸前創建三次握手，而且在數據傳遞時，有確認、窗口、重傳、擁塞控制機制。

TCP的缺點：傳輸慢、效率低，佔用系統資源高，易攻擊。

                     傳數據之間創建鏈接，這樣會消耗時間，並且在消息傳遞時，確認機制、重傳機制和擁塞控制機制都會消耗大量的時間，並且要在每臺設備上維護全部的傳輸鏈接。而每一個鏈接都會佔用系統的CPU、內存等資源。

UDP的優勢：不可靠、不穩定

                      由於UDP沒有TCP那些可靠的機制，在網絡質量很差時很容易丟包。

UDP的優勢：快、比TCP安全

UDP沒有TCP的握手、確認、窗口、重傳、擁塞控制等機制，udp是一個無狀態的傳輸協議，因此他在傳輸數據時很是快。M沒有TCP的這些機制，UDP較TCP被攻擊者利用的漏洞就要少一些。UDP也是沒法避免攻擊的，好比：UDP flood攻擊。。。

 

基於TCP、UDP的協議以及應用場景有哪些？

TCP：HTTP、FTP、SMTP（發送郵件）、POP3（接收郵件）

UDP：DNS（主域名稱系統）、TFTP（通用文件傳輸協議等）、SNMP（簡單網絡管理協議）、實時遊戲、qq聊天。

TCP應用場景：

　　效率要求相對低，但對準確性要求相對高。由於在傳輸中須要對數據確認、重發、排序等操做。好比：文件傳輸、接收郵件、遠程登錄。

UDP應用場景：

　　效率要求相對高，對準確性要求相對低的場景。好比：qq聊天、在線視頻、網絡語音通話。

 

TCP如何保證可靠傳輸？

（1）確認應答+序號。

　　 TCP給發送的每一個包都進行編號，接受方對數據包進行排序，把有序的數據傳送給應用層。

（2）校驗和

　　TCP將保持它首部和數據的校驗和。這是一個端到端的校驗和，目的是監測數據在傳輸過程當中的任何變化。若是收到段的校驗和有差錯，TCP將丟棄這個報文段和不確認收到此報文段。

（3）超時重傳協議

　　當TCP發送一個段後，他啓動一個定時器，等待目的端確認收到這個報文段。若是不能及時收到這個確認，將重發這個報文段。

（4）擁塞控制     和網絡相關

　　擁塞控制是爲了解決過多數據注入到網絡，致使網絡崩潰，超過負荷。TCP傳輸的過程當中，發送端開始發送數據的時候，若是剛開始就發送大量的數據，那麼就可能形成一些問題。網絡可能在剛開始的時候就很擁擠，擁堵加重就會產生大量的丟包。因此TCP引入了慢啓動的機制，在開始發送數據前，先發送少許的數據探路。探清當前的網絡情況如何，再決定多大的速度進行傳輸。

（5）流量控制

　　若是發送者發送數據過快，接收者來不及接收，就會出現分組丟失的現象，爲避免分組丟失，控制發送者的發送速度，使得接收者來得及接收，這就是流量控制。

　　流量控制的實現是經過滑動窗口實現的，滑動窗口協議既保證了分組無差錯、有序接收，也實現了流量控制。主要的方式就是接收方返回的ACK中會包含本身的接收窗口的大小，而且利用大小來控制發送方的數據發送。

TCP首部：

TCP首部佔20個字節，包括：源端口、目的端口、序列號、確認號、校驗和、窗口大小

 

二、請簡單說一下你瞭解的端口及對應的服務

三、TCP三次握手

四、OSI七層模型與ICP/IP五層模型

OSI(Open System Interconnect)開放式系統互聯

物理層：經常使用設備有集線器、中繼器、網線等都是物理層的傳輸介質

鏈路層：交換機

網絡層：IP、路由器

傳輸層：TCP、UDP

應用層：HTTP、HTTPS、FTP、POP三、SMTP

五、HTTP與HTTPS

HTTPS是加密的HTTP，HTTPS並非一個新協議，而是HTTP+SSL，本來http與tcp直接通訊，加上ssl後，就變成http先和ssl通訊，再由ssl與TCP通訊，至關於ssl嵌在了http與tcp之間

HTTP協議一般承載於TCP之上，在HTTP和TCP之間添加一個安全協議層（SSL或TSL），這個時候就成了HTTPS。

HTTP默認端口是80，HTTPS默認端口是443。

HTTP的鏈接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比HTTP協議安全。

 

爲何HTTPS安全？

由於網絡請求須要中間不少的服務器路由的轉發，而http協議是明文發送，在傳輸的過程當中信息可能會被劫持或篡改，而若是使用HTTPS，密鑰只有本身和終點站纔有。HTTPS之因此安全，是由於它利用SSL/TSL協議傳輸。它包含證書，卸載，流量轉發，負載均衡，頁面適配，refer傳遞等，保障了傳輸過程當中的安全性。

HTTPS使用的主要目的是提供對網站服務器的身份認證，同時保護交換數據的隱私與完整性。

 

HTTPS的特色：

（1）內容加密：採用混合加密技術，中間者沒法直接查看明文內容；

（2）驗證身份：經過證書認證客戶端訪問的是本身的服務器；

（3）保護數據完整性：防止傳輸的內容被中間者冒充或篡改。

 

HTTPS是如何進行加密的？

什麼是對稱加密？

就是有一個密鑰，它能夠對一段內容進行加密，加密後只能用他才能解密看到原來的內容，和生活中的鑰匙差很少。

 

用對稱加密可行嗎？

　　若是通訊雙方各自持有同一個密鑰，且沒有別人知曉，這種方式固然能夠，可是最大的問題是這個密鑰怎麼傳輸讓雙方知曉？若是由服務器生成一個密鑰並傳輸給瀏覽器，在傳輸的過程當中密鑰可能會被別人劫持，因此這種方法不可取。

 

什麼是非對稱加密？

　　有兩把密鑰，一把公鑰、一把私鑰，用公鑰加密的內容必須用私鑰才能解開，一樣，私鑰加密的內容只能公鑰解開。

 

用非對稱加密可行嗎？

　　假如服務器先把公鑰直接明文傳輸給瀏覽器，以後瀏覽器向服務器傳輸數據前先用公鑰加密好再傳輸，這樣只有服務器有相應的私鑰進行解密。可是這樣仍不能保證從服務器到瀏覽器的這條路是安全的，公鑰一樣也會被劫持而後用該公鑰解密服務器端傳來的信息。

　　使用一組公鑰私鑰已經能夠保證一個方向的數據傳輸是安全的，若是使用兩對公鑰私鑰是否是能保證雙向傳輸都安全了？的確能夠。可是https加密方式沒有采用這種，由於非對稱加密算法很是耗時，而對稱加密很快。因此須要對稱加密與非對稱加密結合。

 

非對稱加密+對稱加密

　　可是這樣還存在必定漏洞，當服務器將公鑰A傳送到瀏覽器的過程當中，中間人把數據包中的公鑰A換成了本身僞造的公鑰B，以後瀏覽器會用公鑰B（瀏覽器不知道公鑰被替換）加密對稱加密的密鑰X並傳輸到服務器端，而後中間人截獲數據並用私鑰B‘解密獲得密鑰X。

 

產生這個漏洞的根本緣由是瀏覽器沒法確認本身收到的公鑰是否是服務器端的，因此須要用到CA證書。

CA數字證書：網站在使用https以前，須要向CA機構申請頒發一個數字證書，證書中有證書持有者、持有者公鑰等信息。服務器把證書傳輸給瀏覽器，瀏覽器直接從證書裏獲取公鑰就能夠了。

如何防止數字證書被篡改？

數字簽名：咱們把證書內容生成一份「簽名」，對比證書內容與簽名是否一致就能察覺是否被篡改，這種技術叫數字簽名。

 

HTTPS創建鏈接的過程：

（1）客戶端發起加密請求，客戶端主要提供的信息有可使用的SSL版本、支持的加密方式。

（2）服務器返回相應，相應中包含CA證書（包含網站域名、公鑰、數字簽名等）

（3）客戶端驗證服務端的證書，用於客戶端配置了CA機構的證書，裏面包含CA公鑰，因此能夠匹配服務器端發送的公鑰是否正確。

（4）客戶端經過公鑰對一對私鑰進行加密發送給服務器，

（5）服務器收到後，用本身的私鑰進行解密，得到一對私鑰。

（6）最後客戶端與服務器之間經過一對私鑰對數據進行加密傳輸。

 

 

六、進程、線程、協程

進程：是系統分配資源和調度的基本單位，進程是一個正在運行程序的實例。

進程與程序：

• 程序是一段靜態的代碼；進程是一個動態運行的過程；
• 程序是產生進程的基礎；進程是程序功能的體現；

進程的幾種狀態：

就緒狀態：進程已經準備好了，已經分配到所需的資源，只要分配到CPU就能當即執行；

執行狀態：進行處於就緒狀態被調度後，進程進入執行狀態；

阻塞狀態：正在執行的進程因爲某些事件（I/O請求，申請緩存區失敗）而暫時沒法運行，進程受到阻塞。在知足請求時進入就緒狀態等待系統調度。

 

線程：是CPU調度和分派的基本單位。線程是進程中的一個執行流程。

 

區別：

（1）一個進程是一個獨立的運行環境，單獨佔據必定的內存地址空間，它能夠被看做一個程序或者一個應用。而線程是在進程中執行的一個任務。

（2）一個線程只能屬於一個進程，可是一個進程能夠擁有多個線程，不一樣的線程能夠共享進程所擁有的所有資源。

（3）一個線程能夠建立和撤銷另外一個線程；同一進程中的多個線程能夠併發執行。

不管是進程仍是線程，都是由操做系統所管理的。

 

協程：是比線程更加輕量級的存在。一個線程能夠擁有多個協程。協程不是被操做系統內核所管理，而是由程序所控制（也就是在用戶態執行）這樣帶來的好處就是性能獲得了很大的提高，不會像線程切換那樣消耗資源。

 爲何要用到協程呢？

　　由於在線程中存在問題，好比在生產者/消費者模式中線程之間的運行過程：

　　若干個生產者線程向隊列中寫入數據，若干個消費者線程從隊列中讀取數據。

 

 

 

 假如隊列有長度限制，生產者向隊列中插入數據，當隊列滿了時，生產者阻塞，當隊列空了，消費者阻塞。因此這並非一個高性能的實現。

爲何性能不高呢？

（1）涉及到同步鎖

（2）涉及到線程阻塞狀態和可運行狀態之間的切換。

（3）涉及到線程上下文的切換。

以上都是很是消耗性能的。

 

若是改用協程，生產者生產消息後，直接經過yield跳轉到消費者開始執行。待消費者執行完畢以後，切換回生產者繼續生產，效率極高。 

 

七、HTTP與TCP的區別

創建一個TCP鏈接須要通過「三次握手」

HTTP協議即超文本傳輸協議，是創建在TCP協議之上的一種應用。

HTTP鏈接顯著的特色是客戶端發送的每次請求都須要服務端回送響應，每次請求結束以後會主動釋放鏈接。從創建鏈接到關閉鏈接的過程稱爲「一次鏈接」。

　　在http1.0中，客戶端的每次請求都要求創建一次單獨的鏈接，在處理完本次請求以後，會自動釋放鏈接。

　　在http1.1中，在一次鏈接中能夠處理多個請求，而且多個請求能夠重疊進行，不須要等待一個請求結束後再進行下一個請求。

因爲http在每次請求結束後都會主動釋放鏈接，所以http鏈接是一種「短鏈接」，無狀態的鏈接。

區別：

TCP就是單純創建鏈接，不涉及咱們須要請求的實際數據，簡單的傳輸，而http是用來收發數據的。TCP是傳輸層協議，定義數據傳輸和鏈接方式的規範。

HTTP是應用層協議，定義的是傳輸數據的內容的規範。由請求和相應構成，是一個無狀態的協議。HTTP永遠都是由客戶端發起請求，服務器返回請求，這樣就限制了使用HTTP協議，沒法實如今客戶端沒有發起請求的時候，服務器將消息推送給客戶端。

八、死鎖

死鎖是指兩個或兩個以上的進程在執行過程當中，因爲競爭資源或者因爲彼此通訊形成的一種阻塞現象，若無外力做用，它們都將沒法推動下去。此時稱系統處於死鎖狀態。

產生死鎖的四個必要條件：（只要一個不知足就不會死鎖）

（1）互斥條件。即某個資源在一段時間內只能由一個進程全部，不能同時被兩個或兩個以上的進程全部。

（2）請求和保持條件。進程得到必定資源後，又對其餘資源發出請求，可是該資源可能被其餘進程佔用，此時請求阻塞，可是又對本身佔有的資源保持不放。

（3）不可剝奪條件。是指進程以得到的資源，在未完成使用以前，不可被剝奪，只能使用完本身釋放。

（4）環路等待條件。若干進程之間造成一種首尾相接的循環等待資源關係。

解決死鎖的方法：

（1）死鎖預防：破壞致使死鎖必要條件中的任意一個就能夠預防死鎖。例如，要求用戶申請資源時一次性申請所須要的所有資源，這就破壞了保持和等待的條件；將資源進行分層，獲得上一資源後，纔可以申請下一層的資源。

（2）死鎖避免：避免是指進程每次申請資源時判斷這些操做是否安全，例如，使用銀行家算法，死鎖避免算法的執行會增長系統的開銷。

（3）死鎖檢測：死鎖預防和死鎖避免都是事前措施，而死鎖檢測是判斷系統是否處於死鎖狀態，若是是，則執行死鎖解除策略。

（4）死鎖解除：這是與死鎖檢測結合使用的，它使用的方式就是剝奪。即將進程所擁有的資源強行進行回收，分配給其餘的進程。

 

九、get和post的區別

（1）安全性。get請求的數據顯示在url上，而post把數據放在http的包體內（request body），因此post比get更加安全。

（2）長度限制。get提交的數據最大是2k個字節（由於瀏覽器對url的長度有限制），而post沒有限制，post發送的數據更大。

（3）get在回退按鈕或刷新時是無害的，而post會從新提交數據。

（4）get產生的url地址能夠收藏爲書籤，而post不能

（5）get請求會被瀏覽器主動生成緩存，而post不會，除非手動設置

（6）編碼類型。get請求只能進行url編碼，而post支持多種編碼方式。

　　get:application/x-www-form-urlencoded

　　post:application/x-www-form-urlencoded 或 multipart/form-data。爲二進制數據使用多重編碼。

（7）get請求參數會被完整保留在瀏覽器歷史紀錄中，而post中的參數不會被保留。

（8）get只接受ASCLL字符的參數的數據類型，而post沒有限制。

（9）get產生一個TCP數據包，post產生兩個TCP數據包。

　　get請求，瀏覽器會把請求頭和請求body一塊兒發送出去，服務器響應200；而post請求，瀏覽器先發送請求頭，當服務器響應100 continue時，瀏覽器纔會發送request body。

　　由於post須要兩步，時間上消耗的要多一些，可是在網絡環境好的狀況下，發一次包的時間和發兩次包的時間差異基本上能夠無視。

（10）post用於修改和寫入數據，get通常用於搜索排序和篩選，目的是資源的獲取。

 

十、HTTP1.0、HTTP1.一、HTTP2.0的關係和區別

HTTP1.0與HTTP1.1的區別

（1）長鏈接。

　　HTTP1.0每次請求都須要與服務器創建一個TCP鏈接，服務器處理完成以後當即斷開鏈接，服務器不跟蹤每一個客戶端的請求（無狀態）。

　　HTTP1.0默認使用Connection:close，須要使用keep-alive參數來告知服務器端要創建一個長鏈接；在HTTP1.1中默認使用Connection：keep-alive，支持長鏈接，避免了鏈接創建和釋放的開銷。

（2）緩存處理。

　　HTTP1.0中主要使用header裏的if-Modified-Since,Expires來作爲緩存判斷的標準。 1.0中採用的是絕對時間。

　　HTTP1.1則引入了更多的緩存控制策略，如Entity tag,If-None-Match等更多可供選擇的緩存頭來控制緩存策略。eTag是資源的惟一標識

（3）節約帶寬    100狀態碼

　　HTTP1.1加入了新的狀態碼100（continue）：容許客戶端在發送請求消息body以前先用request header來試探一下服務器，看服務器要不要接收request body,再決定要不要發送request body。

　　HTTP1.1客戶端事先發送一個只帶頭域的請求，若是服務器由於權限拒絕了請求，就返回響應碼401（Unauthorized），這樣客戶端就能夠不用發送請求body了，節約帶寬；若是服務器接收此請求就返回響應碼100，客戶端就能夠繼續發送帶實體的完整請求了。

（4）host字段

　　在HTTP1.0中認爲每臺服務器都綁定一個惟一的IP地址，所以請求消息中的URL並無傳遞主機名，但隨着虛擬主機技術的發展，一臺物理服務器上能夠存在多個虛擬主機，而且它們共享一個IP。

　　HTTP1.1的請求消息和相應消息都應支持Host頭域，且請求消息中若是沒有host頭域會報告一個錯誤（400 Bad Request）。

 

目前http1.1存在的問題：

（1）線頭阻塞，http1.1雖然採用keep-alive來解決複用TCP的問題，可是仍是沒法解決請求阻塞的問題。所謂請求阻塞是一條TCP鏈接在同一時間只容許一個請求，後面的請求須要等待前面的請求返回相應以後再請求。

　　之因此會有這個問題就是由於http1.x須要每條請求都是可識別的，按順序發送，不然服務器端就沒法判斷該響應哪一個具體的請求了。

（2）多個TCP鏈接

　　雖然http1.1管道化能夠支持請求併發，可是瀏覽器很難實現，chrome、firefox等都禁用了管道化。因此1.1版本請求併發依賴於多個TCP鏈接，創建TCP鏈接的成本很高，還會存在慢啓動的問題。

（3）頭部冗餘，採用文本格式

　　http1.1版本採用的是文本格式，首部未壓縮，每個請求都會帶上cookie、user-agent等徹底相同的首部。

（4）客戶端須要主動請求

 

HTTP1.1與HTTP2.0的區別

（1）二進制分幀 

　　 http1.x採用的是文本格式傳輸數據，而http2.0採用的是二進制格式傳輸。http2.0是二進制協議。　　

　　在應用層和傳輸層之間增長了一個二進制分幀層。在分幀層，會將傳輸的信息分割成更小的消息和幀，並採用二進制格式進行編碼。將頭部信息封裝到header frame，將request body封裝到data frame中。

　　http1.x是基於文本格式的，因爲文本的表現形式有不少種，要作到健壯性考慮的場景必然不少，而二進制分幀只認0和1的組合。

（2）多路複用

　　上面提到的http1.1的線頭阻塞和多個TCP鏈接的問題，http2.0的多路複用完美解決。http2.0讓全部的通訊都在一個TCP鏈接上完成，真正實現了請求的併發。

　　每一個請求以stream的方式傳輸，每一個stream都有惟一表示，connection鏈接一旦創建，後續的請求均可以複用這個connection而且能夠同時發送，服務端根據stream的惟一標識來響應對應的請求。

　　在http2.0中有兩個很是重要的概念：幀和流。幀是最小的數據單位。HTTP2.0的傳輸是基於二進制幀的，每個TCP鏈接中承載了多個雙向流通的流，每一個流都有惟一的標識，而流就是由二進制幀組成的。二進制幀的頭部信息會標識本身屬於哪一個流，因此這些幀是能夠交錯傳輸的，而後在接收端經過幀頭的信息組裝成完整的數據。

     

 

（3）頭部壓縮

　　http1.1不支持header數據的壓縮，每次請求的header都會帶有大量的信息，並且每次都要重複發送。http2.0使用HPACK算法對header的數據進行壓縮，這樣數據體積小了，傳輸就會更快。

　　頭部壓縮須要在瀏覽器和服務器之間：

• 維護一份相同的靜態字典，包括常見的頭部名稱以及常見的頭部名稱和值的組合；
• 維護一份相同的動態字典，能夠動態的添加內容；
• 經過靜態Huffman編碼對傳輸的首部字段進行編碼。

 

 

 靜態字典：

    

 

　　假如咱們要傳輸method:GET,那麼咱們只須要傳輸字典裏面method:GET對應的索引值就能夠了，一個字節搞定。可是像cookie、user-agent這種靜態字典中只有首部而沒有值的首部，第一次傳輸須要user-agent在靜態字典中的索引以及它的實際值，值會用靜態Huffman編碼來減少體積。

　　第一次傳輸過user-agent以後，瀏覽器和服務器就會把它添加到本身的動態字典中，後續傳輸就能夠傳輸索引了，一個字節搞定。

 

（4）服務器推送

　　服務端根據客戶端的請求，提早返回多個相應，推送額外的資源給客戶端。

 例如：客戶端請求index.html，服務器端可以額外推送script.js和style.css。實現原理就是客戶端發送請求時，服務器端可以分析這個頁面所依賴的其餘資源，主動推送到客戶端的緩存。當客戶端收到原始網頁的請求時，他須要的資源已經位於緩存中了。

　　針對每個但願發送的資源，服務器會發送一個PUSH_PROMISE幀，客戶端能夠經過發送RST_STREAM幀來拒絕推送（當資源已經位於緩存）。這一步操做要先於父響應。客戶端了解到服務端打算推送哪些資源，就不會再爲這些資源建立重複請求。

 

HTTP2.0的弊端：

主要是底層支撐的TCP協議的問題。

由於http2.0使用了多路複用，通常來講同一域名下只須要使用一個TCP鏈接。當這個鏈接中出現了丟包的狀況，會致使http2.0的表現狀況不如http1.1了。

　　由於在出現丟包的狀況下，整個TCP都要開始等待重傳，也就致使了後面的全部數據都被阻塞了。可是對於http1.1來講，能夠開啓多個TCP鏈接，出現這種狀況反倒會隻影響其中一個鏈接，剩餘的TCP鏈接還能夠正常傳輸數據。

 

 

操做系統

（1）爲何要份內核態和用戶態？

內核態：CPU能夠訪問內存全部數據，包括外圍設備，例如硬盤，網卡。CPU也能夠將本身從一個程序切換到另外一個程序。

用戶態：只能受限的訪問內存，且不容許訪問外圍設備。佔用CPU的能力被剝奪，CPU資源能夠被其餘程序獲取。

 

緣由：

因爲須要限制不一樣程序之間的訪問能力，防止他們獲取別的程序的內存數據，或者獲取外圍設備的數據，併發送到網絡。

　　爲了安全性。在cpu的一些指令中，有的指令若是用錯，將會致使整個系統崩潰。分了內核態和用戶態以後，當用戶須要操做這些指令時候，內核爲其提供了API，能夠經過系統調用陷入內核，讓內核去執行這些操做。

　　假如沒有這種內核態和用戶態之分，程序隨隨便便就能訪問硬件資源，好比分配內存，程序能隨意讀取全部的內存空間，若是程序員一不當心將不適當的內容寫到了不應寫的地方，就極可能致使系統崩潰。用戶程序是不可信的，很容易形成系統崩潰。

 

（2）進程之間通訊的方式

進程間通訊的主要方式有：管道、FIFO、消息隊列、信號量等。

管道：（無名管道）

管道只能在具備公共祖先的兩個進程之間使用，一般，一個管道由一個進程建立，在進程調用fork以後，這個管道就能在父進程和子進程之間使用了。

FIFO：（命名管道）

與無名管道不一樣的是，其能夠在不相關的程序之間交換數據。

 信號量：

信號量是一個計數器，主要用於實現進程間的互斥與同步，而不是用於存儲進程間通訊數據。