1.http狀態碼有那些？分別代表是什麼意思？
1**信息，服務器收到請求，需要請求者繼續執行操作
2**成功，操作被成功接收並處理
3**重定向，需要進一步的操作以完成請求
4**客戶端錯誤，請求包含語法錯誤或無法完成請求
5**服務器錯誤，服務器在處理請求的過程中發生了錯誤
100 Continue繼續。客戶端應繼續其請求
101 Switching Protocols切換協議。服務器根據客戶端的請求切換協議。只能切換到更高級的協議，例如，切換到HTTP的新版本協議
200 K請求成功。一般用於GET與POST請求
201 Created已創建。成功請求並創建了新的資源
202 Accepted已接受。已經接受請求，但未處理完成
203 Non-Authoritative Information非授權信息。請求成功。但返回的meta信息不在原始的服務器，而是一個副本
204 No Content無內容。服務器成功處理，但未返回內容。在未更新網頁的情況下，可確保瀏覽器繼續顯示當前文檔
205 Reset Content重置內容。服務器處理成功，用戶終端(例如：瀏覽器)應重置文檔視圖。可通過此返回碼清除瀏覽器的表單域
206 Partial Content部分內容。服務器成功處理了部分GET請求
300 Multiple Choices多種選擇。請求的資源可包括多個位置，相應可返回一個資源特徵與地址的列表用於用戶終端(例如：瀏覽器)選擇
301 Moved Permanently永久移動。請求的資源已被永久的移動到新URI，返回信息會包括新的URI，瀏覽器會自動定向到新URI。今後任何新的請求都應使用新的URI代替
302 Found臨時移動。與301類似。但資源只是臨時被移動。客戶端應繼續使用原有URI
303 See Other查看其它地址。與301類似。使用GET和POST請求查看
304 Not Modified未修改。所請求的資源未修改，服務器返回此狀態碼時，不會返回任何資源。客戶端通常會緩存訪問過的資源，通過提供一個頭信息指出客戶端希望只返回在指定日期之後修改的資源
305 Use Proxy使用代理。所請求的資源必須通過代理訪問
306 Unused已經被廢棄的HTTP狀態碼
307 Temporary Redirect臨時重定向。與302類似。使用GET請求重定向
400 Bad Request客戶端請求的語法錯誤，服務器無法理解
401 Unauthorized請求要求用戶的身份認證
402 Payment Required保留，將來使用
403 Forbidden服務器理解請求客戶端的請求，但是拒絕執行此請求
404 Not Found服務器無法根據客戶端的請求找到資源(網頁)。通過此代碼，網站設計人員可設置”您所請求的資源無法找到”的個性頁面
405 Method Not Allowed客戶端請求中的方法被禁止
406 Not Acceptable服務器無法根據客戶端請求的內容特性完成請求
407 Proxy Authentication Required請求要求代理的身份認證，與401類似，但請求者應當使用代理進行授權
408 Request Time-out服務器等待客戶端發送的請求時間過長，超時
409 Conflict服務器完成客戶端的PUT請求是可能返回此代碼，服務器處理請求時發生了衝突
410 Gone客戶端請求的資源已經不存在。410不同於404，如果資源以前有現在被永久刪除了可使用410代碼，網站設計人員可通過301代碼指定資源的新位置
411 Length Required服務器無法處理客戶端發送的不帶Content-Length的請求信息
412 Precondition Failed客戶端請求信息的先決條件錯誤
413 Request Entity Too Large由於請求的實體過大，服務器無法處理，因此拒絕請求。爲防止客戶端的連續請求，服務器可能會關閉連接。如果只是服務器暫時無法處理，則會包含一個Retry-After的響應信息
414 Request-URI Too Large請求的URI過長(URI通常爲網址)，服務器無法處理
415 Unsupported Media Type服務器無法處理請求附帶的媒體格式
416 Requested range not satisfiable客戶端請求的範圍無效
417 Expectation Failed服務器無法滿足Expect的請求頭信息
500 Internal Server Error服務器內部錯誤，無法完成請求
501 Not Implemented服務器不支持請求的功能，無法完成請求
502 Bad Gateway充當網關或代理的服務器，從遠端服務器接收到了一個無效的請求
503 Service Unavailable由於超載或系統維護，服務器暫時的無法處理客戶端的請求。延時的長度可包含在服務器的Retry-After頭信息中
504 Gateway Time-out充當網關或代理的服務器，未及時從遠端服務器獲取請求
505 HTTP Version not supported服務器不支持請求的HTTP協議的版本，無法完成處理
2.http請求頭有哪些?
Accept-Charset：瀏覽器可接受的字符集。
Accept-Encoding：瀏覽器能夠進行解碼的數據編碼方式，比如gzip。Servlet能夠向支持gzip的瀏覽器返回經gzip編碼的HTML頁面。許多情形下這可以減少5到10倍的下載時間。
Accept-Language：瀏覽器所希望的語言種類，當服務器能夠提供一種以上的語言版本時要用到。
Authorization：授權信息，通常出現在對服務器發送的WWW-Authenticate頭的應答中。
Connection：表示是否需要持久連接。如果Servlet看到這裏的值爲“Keep-Alive”，或者看到請求使用的是HTTP 1.1（HTTP 1.1默認進行持久連接），它就可以利用持久連接的優點，當頁面包含多個元素時（例如Applet，圖片），顯著地減少下載所需要的時間。要實現這一點，Servlet需要在應答中發送一個Content-Length頭，最簡單的實現方法是：先把內容寫入ByteArrayOutputStream，然後在正式寫出內容之前計算它的大小。
Content-Length：表示請求消息正文的長度。
Cookie：這是最重要的請求頭信息之一
From：請求發送者的email地址，由一些特殊的Web客戶程序使用，瀏覽器不會用到它。
Host：初始URL中的主機和端口。
If-Modified-Since：只有當所請求的內容在指定的日期之後又經過修改才返回它，否則返回304“Not Modified”應答。
Pragma：指定“no-cache”值表示服務器必須返回一個刷新後的文檔，即使它是代理服務器而且已經有了頁面的本地拷貝。
Referer：包含一個URL，用戶從該URL代表的頁面出發訪問當前請求的頁面。
User-Agent：瀏覽器類型，如果Servlet返回的內容與瀏覽器類型有關則該值非常有用。
UA-Pixels，UA-Color，UA-OS，UA-CPU：由某些版本的IE瀏覽器所發送的非標準的請求頭，表示屏幕大小、顏色深度、操作系統和CPU類型。
3.HTTP1.0和HTTP1.1和HTTP2.0的區別
1 HTTP1.0和HTTP1.1的區別
1.1 長連接(Persistent Connection)
HTTP1.1支持長連接和請求的流水線處理，在一個TCP連接上可以傳送多個HTTP請求和響應，減少了建立和關閉連接的消耗和延遲，在HTTP1.1中默認開啓長連接keep-alive，一定程度上彌補了HTTP1.0每次請求都要創建連接的缺點。HTTP1.0需要使用keep-alive參數來告知服務器端要建立一個長連接。
1.2 節約帶寬
HTTP1.0中存在一些浪費帶寬的現象，例如客戶端只是需要某個對象的一部分，而服務器卻將整個對象送過來了，並且不支持斷點續傳功能。HTTP1.1支持只發送header信息（不帶任何body信息），如果服務器認爲客戶端有權限請求服務器，則返回100，客戶端接收到100纔開始把請求body發送到服務器；如果返回401，客戶端就可以不用發送請求body了節約了帶寬。
1.3 HOST域
在HTTP1.0中認爲每臺服務器都綁定一個唯一的IP地址，因此，請求消息中的URL並沒有傳遞主機名（hostname），HTTP1.0沒有host域。隨着虛擬主機技術的發展，在一臺物理服務器上可以存在多個虛擬主機（Multi-homed Web Servers），並且它們共享一個IP地址。HTTP1.1的請求消息和響應消息都支持host域，且請求消息中如果沒有host域會報告一個錯誤（400 Bad Request）。
1.4緩存處理
在HTTP1.0中主要使用header裏的If-Modified-Since,Expires來做爲緩存判斷的標準，HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。
1.5錯誤通知的管理
在HTTP1.1中新增了24個錯誤狀態響應碼，如409（Conflict）表示請求的資源與資源的當前狀態發生衝突；410（Gone）表示服務器上的某個資源被永久性的刪除。
2 HTTP1.1和HTTP2.0的區別
2.1 多路複用
HTTP2.0使用了多路複用的技術，做到同一個連接併發處理多個請求，而且併發請求的數量比HTTP1.1大了好幾個數量級。HTTP1.1也可以多建立幾個TCP連接，來支持處理更多併發的請求，但是創建TCP連接本身也是有開銷的。
2.2 頭部數據壓縮
在HTTP1.1中，HTTP請求和響應都是由狀態行、請求/響應頭部、消息主體三部分組成。一般而言，消息主體都會經過gzip壓縮，或者本身傳輸的就是壓縮過後的二進制文件，但狀態行和頭部卻沒有經過任何壓縮，直接以純文本傳輸。隨着Web功能越來越複雜，每個頁面產生的請求數也越來越多，導致消耗在頭部的流量越來越多，尤其是每次都要傳輸UserAgent、Cookie這類不會頻繁變動的內容，完全是一種浪費。
HTTP1.1不支持header數據的壓縮，HTTP2.0使用HPACK算法對header的數據進行壓縮，這樣數據體積小了，在網絡上傳輸就會更快。
2.3 服務器推送
服務端推送是一種在客戶端請求之前發送數據的機制。網頁使用了許多資源：HTML、樣式表、腳本、圖片等等。在HTTP1.1中這些資源每一個都必須明確地請求。這是一個很慢的過程。瀏覽器從獲取HTML開始，然後在它解析和評估頁面的時候，增量地獲取更多的資源。因爲服務器必須等待瀏覽器做每一個請求，網絡經常是空閒的和未充分使用的。
爲了改善延遲，HTTP2.0引入了server push，它允許服務端推送資源給瀏覽器，在瀏覽器明確地請求之前，免得客戶端再次創建連接發送請求到服務器端獲取。這樣客戶端可以直接從本地加載這些資源，不用再通過網絡。
4. 從輸入URL到瀏覽器顯示頁面發生了什麼
1.在瀏覽器中輸入url（解析IP地址）
2.應用層DNS解析域名
3.應用層客戶端發送HTTP請求
4.傳輸層TCP傳輸報文(3次握手)
5.網絡層IP協議查詢MAC地址
6.數據到達數據鏈路層
7.服務器接收數據
8.服務器響應請求
9.服務器返回相應文件
5. 線程與進程的區別
a. 一個程序至少有一個進程，一個進程至少有一個線程
b. 線程的劃分尺度小於進程，使得多線程程序的併發性高
c. 進程在執行過程中擁有獨立的內存單元，而多個線程共享內存，從而極大地提高了程序的運行效率
d. 每個獨立的線程有一個程序運行的入口、順序執行序列和程序的出口。但是線程不能夠獨立執行，必須依存在應用程序中，由應用程序提供多個線程執行控制
e. 多線程的意義在於一個應用程序中，有多個執行部分可以同時執行。但操作系統並沒有將多個線程看做多個獨立的應用，來實現進程的調度和管理以及資源分配
6. 列舉IE與其他瀏覽器不一樣的特性？
a. IE的排版引擎是Trident （又稱爲MSHTML）
b. Trident內核曾經幾乎與W3C標準脫節（2005年）
c. Trident內核的大量 Bug等安全性問題沒有得到及時解決
d. JS方面，有很多獨立的方法，例如綁定事件的attachEvent、創建事件的createEventObject等
e. CSS方面，也有自己獨有的處理方式，例如設置透明，低版本IE中使用濾鏡的方式
7.簡述同步和異步的區別
同步是阻塞模式，異步是非阻塞模式。
同步就是指一個進程在執行某個請求的時候，若該請求需要一段時間才能返回信息，那麼這個進程將會一直等待下去，直到收到返回信息才繼續執行下去；
異步是指進程不需要一直等下去，而是繼續執行下面的操作，不管其他進程的狀態。當有消息返回時系統會通知進程進行處理，這樣可以提高執行的效率
8.http 和 https 有何區別？如何靈活使用？
http是HTTP協議運行在TCP之上。所有傳輸的內容都是明文，客戶端和服務器端都無法驗證對方的身份。
https是HTTP運行在SSL/TLS之上，SSL/TLS運行在TCP之上。所有傳輸的內容都經過加密，加密採用對稱加密，但對稱加密的密鑰用服務器方的證書進行了非對稱加密。此外客戶端可以驗證服務器端的身份，如果配置了客戶端驗證，服務器方也可以驗證客戶端的身份
9. 一次js請求一般情況下有哪些地方會有緩存處理？
a. 瀏覽器端存儲
b. 瀏覽器端文件緩存
c. HTTP緩存304
d. 服務器端文件類型緩存
e. 表現層&DOM緩存
10. TCP與UDP的區別：
1.基於連接與無連接；
2.對系統資源的要求（TCP較多，UDP少）；
3.UDP程序結構較簡單；
4.流模式與數據報模式 ；
5.TCP保證數據正確性，UDP可能丟包，TCP保證數據順序，UDP不保證。
11安全問題
sql注入：利用引號截斷sql語句
防禦：用戶輸入進行過濾，sql語句預處理。
xss：理論上，所有可輸入的地方沒有對輸入數據進行處理的話，都會存在XSS漏洞，漏洞的危害取決於攻擊代碼的威力，攻擊代碼也不侷限於script（改變樣式什麼的）。（可以盜取用戶cookie)
XSS攻擊及防禦
開發者對用戶輸入進行處理，個人不要隨便點擊連接。
vue、react等框架已經很好的預防了xss攻擊，除非使用v-html將用戶輸入直接放到頁面中。
csrf：僞造請求，冒充用戶在站內的正常操作。
要完成一次CSRF攻擊，受害者必須依次完成兩個步驟：
1.登錄受信任網站A，並在本地生成Cookie。
2.在不登出A的情況下，訪問危險網站B。
12.TCP協議的三次握手與四次揮手
（1）TCP連接建立過程中採用“三次握手機制”
第一次握手：客戶端發出連接請求報文段，其中將SYN標誌位置爲1表示要建立連接，選擇一個初始序列號seq=x，不攜帶數據但消耗一個序號。之後TCP客戶進程進入SYN-SENT（同步已發送）狀態。
第二次握手：服務器收到連接請求報文段後，如同意建立連接，向客戶端發送確認。在確認報文段中將SYN位和ACK位都置1，確認號是ack=x+1，選擇一個初始序號seq=y，不攜帶數據但消耗一個序號。TCP服務器進程進入SYN-RCVD（同步收到）狀態。
第三次握手：TCP客戶進程收到服務器的確認後，檢查ack是否是x+1，ACK是否是1。如果正確，向服務器發送確認報文段，其中ACK置1，確認號ack=y+1，序號seq=x+1，可以攜帶數據，但如果不攜帶數據則不消耗序號。服務器檢查ack是否爲y+1，ACK是否爲1，如果正確則連接建立成功，客戶端和服務器進入ESTABLISHED（已建立連接）狀態。
（2）TCP連接釋放過程中採用“四次揮手機制”
第一次揮手：客戶端的應用進程發出連接釋放報文段，停止發送數據。FIN置1，序號seq=u，是前面已經傳送過的數據的最後一個字節的序號加1，不攜帶數據但消耗一個序號。客戶端進入FIN-WAIT-1（終止等待1）狀態，等待服務器的確認。
第二次揮手： 服務器收到連接釋放報文段後發出確認。ACK置1，確認號ack=u+1，序號seq=v，是服務器前面已經傳送過的數據的最後一個字節的序號加1。服務器進入CLOSE-WAIT（關閉等待）狀態。從客戶端到服務器的連接釋放了。
客戶端收到來自服務器端的確認後，進入FIN-WAIT-2（終止等待）狀態，等待服務器發出連接釋放報文段。
第三次揮手：若服務器已經沒有要向客戶端發送的數據，發出連接釋放報文段。FIN置1，序號seq=w，確認號ack=u+1。服務器進入LAST-ACK（最後確認）狀態，等待客戶端的確認。
第四次揮手：客戶端收到服務器的連接釋放報文段後，發出確認。ACK置1，確認號ack=w+1，序號seq=u+1。進入TIME-WAIT（時間等待）狀態，經過2MSL後，進入CLOSED狀態。
服務器只要收到客戶端發出的確認，就進入CLOSED狀態。
13.TCP連接爲什麼需要三次握手？
客戶端最後還要發送一次確認，主要是爲了防止已失效的連接請求報文段突然又送到了服務器，產生錯誤。
假定客戶端發出連接請求報文段，在某個網絡結點長時間滯留，延誤到連接釋放以後的某個時間纔到達服務器。這是一個早已失效的報文段，但服務器收到後會誤以爲客戶端又發出一次新的連接請求，於是向客戶端發出確認報文段，同意建立連接。假定不採用第三次握手，新的連接就建立了。
由於現在客戶端並沒有發出建立連接的請求，因此不會理睬服務器的確認，但服務器卻誤以爲新的連接已經建立，一直等待客戶端發數據，服務器的資源被浪費。但如果採用三次握手的方法，客戶端不會向服務器發出確認，就不會建立連接。
