計算機網路常見面試題總結

HTTP

概述

HTTP協議是基于TCP/IP協議之上的應用層協議，HTTP是一個無狀態協議，在Web瀏覽器（客戶端）和服務器之間不需要建立持久的連接，客戶端發送請求，服務端回傳回應后，一次通信結束，HTTP連接關閉，服務器不保留連接相關資訊，
HTTP協議采用了請求/回應模型，客戶端向服務器發送一個請求報文，請求報文包含請求的方法、URL、協議版本、請求頭部和請求資料，服務器以一個狀態行作為回應，回應的內容包括協議的版本、成功或者錯誤代碼、服務器資訊、回應頭部和回應資料，
HTTP的傳輸流程包括地址決議，封裝HTTP資料包、封裝TCP包、建立TCP連接、客戶端發送請求、服務端回應、服務端關閉TCP連接，

HTTP特點

• 支持客戶/服務器模式，
• 簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑，請求方法常用的有GET、HEAD、POST，每種方法規定了客戶與服務器聯系的型別不同，由于HTTP協議簡單，使得HTTP服務器的程式規模小，因而通信速度很快，
• 靈活：HTTP允許傳輸任意型別的資料物件，正在傳輸的型別由Content-Type（Content-Type是HTTP包中用來表示內容型別的標識）加以標記，
• 無連接：無連接的含義是限制每次連接只處理一個請求，服務器處理完客戶的請求，并收到客戶的應答后，即斷開連接，采用這種方式可以節省傳輸時間，
• 無狀態：HTTP協議是無狀態協議，無狀態是指協議對于事務處理沒有記憶能力，缺少狀態意味著如果后續處理需要前面的資訊，則它必須重傳，這樣可能導致每次連接傳送的資料量增大，另一方面，在服務器不需要先前資訊時它的應答就較快，

HTTP 頭部包含哪些資訊？

HTTP 頭部本質上是一個傳遞額外重要資訊的鍵值對，主要分為：通用頭部，請求頭部，回應頭部和物體頭部，

通用頭部

請求頭部

回應頭部

物體頭部

如何知道 HTTP 的報文長度？

當回應訊息中存在 Content-Length 欄位時，我們可以直接根據這個值來判斷資料是否接收完成，例如客戶端向服務器請求一個靜態頁面或者一張圖片時，服務器能夠很清楚的知道請求內容的大小，因此可以通過訊息首部欄位 Content- Length 來告訴客戶端需要接收多少資料，但是如果服務器預先不知道請求內容的大小，例如加載動態頁面的時候，就需要使用 Transfer-Encoding: chunked 的方式來代替 Content-Length，

分塊傳輸編碼（Chunked transfer encoding）是 HTTP/1.1 中引入的一種資料傳輸機制，其允許 HTTP 由服務器發送給客戶端的資料可以分成多個部分，當資料分解成一系列資料塊發送時，服務器就可以發送資料而不需要預先知道發送內容的總大小，每一個分塊包含十六進制的長度值和資料，最后一個分塊長度值為0，表示物體結束，客戶機可以以此為標志確認資料已經接收完畢，

HTTP請求報文

請求行：請求方式（post、get）、請求的資源（URL欄位）、協議版本（HTTP/1.0：創建一次鏈接獲得一個web資源，鏈接斷開；HTTP/1.1：創建一個鏈接，獲得多個web資源，保持連接），

請求頭：客戶端發送給服務器端的一些資訊，用鍵值對表示，包含：User-Agent：產生請求的瀏覽器型別，Accept：客戶端可識別的內容型別串列，Host：主機地址，接受的編碼方式和壓縮方式，

常見的請求頭欄位含義：

• If-Modified-Since：當客戶端訪問頁面時，服務器會將頁面最后修改時間通過 Last-Modified 標識由服務器發往客戶端，客戶端記錄修改時間，再次請求本地存在的cache頁面時，客戶端會通過 If-Modified-Since 頭將先前服務器端發過來的最后修改時間戳發送回去，服務器端通過這個時間戳判斷客戶端的頁面是否是最新的，如果不是最新的，則回傳新的內容，如果是最新的，則 回傳 304 告訴客戶端其本地 cache 的頁面是最新的，于是客戶端就可以直接從本地加載頁面了，這樣在網路上傳輸的資料就會大大減少，同時也減輕了服務器的負擔，
• If-None-Match：和回應頭的 Etag 一起作業，當用戶再次請求同個資源時，將上一次請求回傳回應中的 Etag 值填入，如果服務器驗證 Etag 沒有改變，將回傳304告訴客戶端使用快取，
• Pragma：防止頁面被快取，
• Cache-Control ：設定請求回應鏈上所有的快取機制必須遵守的指令，
• Accept：客戶端可以接受服務端發回的媒體型別，
• Accept-Charset：瀏覽器可接受的字符集，
• Accept-Encoding：瀏覽器能夠進行解碼的資料編碼方式
• Accept-Language：瀏覽器所希望的語言種類，當服務器能夠提供一種以上的語言版本時要用到，
• User-Agent：客戶端使用的作業系統和瀏覽器版本，
• Content-Length：表示請求訊息正文的長度，
• Referer：背景關系資訊，例如，如果在網頁 1，點擊一個鏈接到網頁 2，當瀏覽器請求網頁 2 時，網頁 1 的 URL 就會包含在 Referer 頭資訊中，
• Cookie：客戶機通過這個頭可以向服務器帶資料，這是最重要的請求頭資訊之一，
• Connection：處理完這次請求后是否斷開連接還是繼續保持連接，取值keep-alive代表建立長連接，如果Servlet看到這里的值為“Keep- Alive”，或者看到請求使用的是HTTP 1.1(HTTP 1.1默認進行持久連接)，它就可以利用持久連接的優點，當頁面包含多個元素時(例如Applet，圖片)，顯著地減少下載所需要的時間，要實作這一點，Servlet需要在應答中發送一個Content-Length頭，最簡單的實作方法是：先把內容寫入 ByteArrayOutputStream，然后在正式寫出內容之前計算它的大小，
• Host：指定被請求資源的服務器IP和埠號，
• Range：用于請求頭中，指定第一個位元組的位置和最后一個位元組的位置

訊息主體：前臺向后臺發送的資料，當請求方式是post時，請求體會有請求引數，格式如下：username=zhangsan&password=123，
當請求方式是get時，請求引數不會出現在請求體中，會拼接在url地址后面： http://localhost:8080…？username=zhangsan&password=123，

HTTP回應報文

回應行：HTTP版本 + 狀態碼 + 狀態代碼的文本描述（狀態描述），常用狀態碼（200：請求成功；301：資源（網頁等）被永久轉移到其它URL；302：請求重定向；304：請求資源沒有變，訪問本地快取；404：請求資源不存在；500：服務器內部錯誤），

回應頭：服務器端將資訊以鍵值對的形式回傳給客戶端，包含服務器型別，日期，長度，內容型別等，

常見的回應頭欄位含義：

• Date：當前的GMT時間，例如：Date:Mon,31Dec200104:25:57GMT，
• Expires：瀏覽器會在指定過期時間內使用快取，
• Content- Type：回應物件的型別和字符集，
• Content-Length：回應體長度，根據這個值來判斷資料是否接收完成，
• Content-Encoding：回應體的編碼方式以及是否壓縮，
• Transfer-Encoding: WEB 服務器表明自己對本回應訊息體（不是訊息體里面的物件）作了怎樣的編碼，比如是否分塊（chunked），例如：Transfer-Encoding: chunked
• ETag ：和請求頭中的If-None-Match配合使用，
• Last-Modified：檔案的最后改動時間，客戶可以通過If-Modified-Since請求頭提供一個日期，該請求將被視為一個條件GET，只有改動時間遲于指定時間的檔案才會回傳，否則回傳一個304(Not Modified)狀態，
• Location：這個頭配合302狀態碼使用，用于重定向接收者到一個新URI地址，表示客戶應當到哪里去提取檔案，Location通常不是直接設定的，而是通過 HttpServletResponse 的 sendRedirect 方法，該方法同時設定狀態代碼為302，
• Refresh：告訴瀏覽器隔多久重繪一次，以秒計，
• Content-Range：用于回應頭中，在發出帶 Range 的請求后，服務器會在 Content-Range 頭部回傳當前接受的范圍和檔案總大小，

回應體：是服務器回寫給客戶端的頁面正文，瀏覽器將正文加載到記憶體，然后決議渲染，顯示在頁面內容，

回應狀態碼

狀態代碼由服務器發出，以回應客戶端對服務器的請求，
1xx（資訊）：收到請求，繼續處理
2xx（成功）：請求已成功接收，理解和接受
3xx（重定向）：需要采取進一步措施才能完成請求
4xx（客戶端錯誤）：請求包含錯誤的語法或無法滿足
5xx（服務器錯誤）：服務器無法滿足明顯有效的請求

• 200 OK：表示從客戶端發送給服務器的請求被正常處理并回傳；
• 204 No Content：表示客戶端發送給客戶端的請求得到了成功處理，但在回傳的回應報文中不含物體的主體部分（沒有資源可以回傳）；
• 206 Patial Content：表示客戶端進行了范圍請求，并且服務器成功執行了這部分的GET請求，回應報文中包含由Content-Range指定范圍的物體內容，
• 301 Moved Permanently：永久性重定向，表示請求的資源被分配了新的URL，之后應使用更改的URL；
• 302 Found：臨時性重定向，表示請求的資源被分配了新的URL，希望本次訪問使用新的URL；
• 303 See Other：表示請求的資源被分配了新的URL，應使用GET方法定向獲取請求的資源；
• 304 Not Modified：表示客戶端發送附帶條件（是指采用GET方法的請求報文中包含if-Match、If-Modified-Since、If-None-Match、If-Range、If-Unmodified-Since中任一首部）的請求時，服務器端允許訪問資源，但是請求為滿足條件的情況下回傳改狀態碼；
• 307 Temporary Redirect：臨時重定向，與303有著相同的含義，307會遵照瀏覽器標準不會從POST變成GET；（不同瀏覽器可能會出現不同的情況）；
• 400 Bad Request：表示請求報文中存在語法錯誤；
• 401 Unauthorized：未經許可，需要通過HTTP認證；
• 403 Forbidden：服務器拒絕該次訪問
• 404 Not Found：表示服務器上無法找到請求的資源，也可以在服務器拒絕請求但不想給拒絕原因時使用；
• 500 Inter Server Error：表示服務器在執行請求時發生了錯誤；
• 503 Server Unavailable：表示服務器暫時處于超負載或正在進行停機維護，無法處理請求；

HTTP請求的方法

HTTP/1.0 定義了三種請求方法：GET, POST 和 HEAD 方法，
HTTP/1.1 增加了六種請求方法：OPTIONS, PUT, PATCH, DELETE, TRACE 和 CONNECT 方法，

請求方法的應用場景

GET：基于“URL”地址問號傳參；一般用于向服務器獲取資源，例如查詢資料庫的資料等；成功回傳200，
POST：基于“請求”主體把訊息發送給服務器；一般用于請求新增或修改資源，例如提交表單，新增用戶等；先發送header，服務器回應100；再發送data，成功回應201，
PUT：修改資源，
DELETE：洗掉某個資源，
OPTIONS：一般是客戶端向服務端判斷對某個資源是否有訪問權限，
HEAD：一般用于獲取某個資源的metadata資訊，比如說某份報告的關鍵描述資訊等，

GET 和 POST 的區別

• get 提交的資料會放在 URL 之后，并且請求引數會被完整的保留在瀏覽器的記錄里，由于引數直接暴露在 URL 中，可能會存在安全問題，因此往往用于獲取資源資訊，而 post 引數放在請求主體中，并且引數不會被保留，相比 get 方法，post 方法更安全，主要用于修改服務器上的資源，
• get 請求只支持 URL 編碼，post 請求支持多種編碼格式，
• get 只支持 ASCII 字符格式的引數，而 post 方法沒有限制，
• get 提交的資料大小有限制（這里所說的限制是針對瀏覽器而言的），而 post 方法提交的資料沒限制
• get 方式需要使用 Request.QueryString 來取得變數的值，而 post 方式通過 Request.Form 來獲取，
• get 方法產生一個 TCP 資料包，post 方法產生兩個（并不是所有的瀏覽器中都產生兩個），
  

GET 的長度限制是多少

HTTP 中的 GET 方法是通過 URL 傳遞資料的，而 URL 本身并沒有對資料的長度進行限制，真正限制 GET 長度的是瀏覽器，例如 IE 瀏覽器對 URL 的最大限制為 2000多個字符，大概 2KB左右，像 Chrome, FireFox 等瀏覽器能支持的 URL 字符數更多，其中 FireFox 中 URL 最大長度限制為 65536 個字符，Chrome 瀏覽器中 URL 最大長度限制為 8182 個字符，并且這個長度不是只針對資料部分，而是針對整個 URL 而言，在這之中，不同的服務器同樣影響 URL 的最大長度限制，因此對于特定的瀏覽器，GET的長度限制不同，

由于 POST 方法請求引數在請求主體中，理論上講，post 方法是沒有大小限制的，而真正起限制作用的是服務器處理程式的處理能力，

PUT和PATCH區別

PUT和PATCH都是用來修改服務端某個資源的，但是PUT和PATCH修改時提交的資料不同：PUT是將整個資源的資訊都提交到服務端，包括修改的，未修改的都提交到服務端；而PATCH只提交已修改的欄位到服務端，而服務端對PUT請求應該是整體替換，PATCH請求只修改提交的欄位，所以PUT請求應該是冪等的，即多次提交同一個請求，結果是相同的，

Cookie && Session && Token

HTTP是無狀態的，每次的請求都是獨立的，它的執行情況與前后請求沒有直接關系，它不會受前面的請求應答情況直接影響，也不會直接影響后面的請求應答情況，

缺少狀態意味著如果后續處理需要前面的資訊，則它必須重傳，這樣可能導致每次連接傳送的資料量增大，

客戶端與服務器進行動態互動的Web應用程式出現之后，HTTP無狀態的特性嚴重阻礙了這些應用程式的實作，畢竟互動是需要承前啟后的，簡單的購物車程式也要知道用戶到底在之前選擇了什么商品，于是，兩種用于保持HTTP連接狀態的技術就應運而生了，一個是Cookie，而另一個則是Session，HTTP本身是一個無狀態的連接協議，為了支持客戶端與服務器之間的互動，我們就需要通過不同的技術為互動存盤狀態，而這些不同的技術就是Cookie和Session了，

Cookie

Cookie實際上是一小段的文本資訊，客戶端請求服務器，如果服務器需要記錄該用戶狀態，就使用response向客戶端瀏覽器頒發一個Cookie，客戶端瀏覽器會把Cookie保存起來，當瀏覽器再請求該網站時，瀏覽器把請求的網址連同該Cookie一同提交給服務器，服務器檢查該Cookie，以此來辨認用戶狀態，服務器還可以根據需要修改Cookie的內容，
很多網站都會使用Cookie，Cookie具有不可跨域名性（所以不能實作單點登錄），

Session

Session是另一種記錄客戶狀態的機制，不同的是Cookie保存在客戶端瀏覽器中，而Session保存在服務器上，客戶端瀏覽器訪問服務器的時候，服務器把客戶端資訊以某種形式記錄在服務器上，這就是Session，cookie中存放著session ID，請求時會發送這個ID，客戶端再次訪問時服務器只需要從Session中查找該客戶的狀態就可以了，

如果說Cookie機制是通過檢查客戶身上的“通行證”來確定客戶身份的話，那么Session機制就是通過檢查服務器上的“客戶明細表”來確認客戶身份，Session相當于程式在服務器上建立的一份客戶檔案，客戶來訪的時候只需要查詢客戶檔案表就可以了，

注意

• cookie資料存放在客戶的瀏覽器上，session資料放在服務器上，
• 單個cookie保存的資料不能超過4K，很多瀏覽器都限制一個站點最多保存20個cookie，
• cookie只是實作session的其中一種方案，雖然是最常用的，但并不是唯一的方法，禁用cookie后還有其他方法存盤，比如放在URL中
• 現在大多都是Session + Cookie，但是只用session不用cookie，或是只用cookie，不用session在理論上都可以保持會話狀態，
• 用session只需要在客戶端保存一個id，實際上大量資料都是保存在服務端，
• 如果只用cookie不用session，那么賬戶資訊全部保存在客戶端，一旦被劫持，全部資訊都會泄露，并且客戶端資料量變大，網路傳輸的資料量也會變大，
• Cookie只能存盤字串；
• 子域名可以獲取頂級域名的Cookie

Token

互聯網服務離不開用戶認證，一般流程是下面這樣：
1、用戶向服務器發送用戶名和密碼，
2、服務器驗證通過后，在當前對話（session）里面保存相關資料，比如用戶角色、登錄時間等等，
3、服務器向用戶回傳一個 session_id，寫入用戶的 Cookie，
4、用戶隨后的每一次請求，都會通過 Cookie，將 session_id 傳回服務器，
5、服務器收到 session_id，找到前期保存的資料，由此得知用戶的身份，

存在的問題：
1、每次用戶發起請求時，服務器需要創建一個記錄來存盤資訊，當越來越多的用戶發請求時，記憶體的開銷不斷增大，
2、可擴展性不好，如果是服務器集群，或者是跨域的服務導向架構，就要求 session 資料共享，每臺服務器都能夠讀取 session，
舉例來說，A 網站和 B 網站是同一家公司的關聯服務，現在要求，用戶只要在其中一個網站登錄，再訪問另一個網站就會自動登錄，請問怎么實作？

一種解決方案是 session 資料持久化，寫入資料庫或別的持久層，各種服務收到請求后，都向持久層請求資料，這種方案的優點是架構清晰，缺點是工程量比較大，另外，持久層萬一掛了，就會單點失敗，

另一種方案是服務器索性不保存 session 資料了，所有資料都保存在客戶端，每次請求都發回服務器，
（1）客戶端第一次請求時，發送用戶資訊到服務器，服務器對用戶資訊使用演算法及密鑰進行簽名，再將這個簽名和資料一起生成token回傳給客戶戶端，
（2）服務端不再保存token，客戶端保存token，
（3）當客戶端再次發送請求時，在請求資訊中將token一起發送給服務器，
（4）服務器用同樣的演算法和密鑰，對資料再計算一次簽名，和token的簽名做比較，
（5）如果相同，服務器就知道客戶端登錄過，則反之，

Token就是一個令牌，無狀態，用戶資訊都被加密到token中，服務器收到token后解密就可知道是哪個用戶，需要開發者手動添加，

JWT(JSON Web Token)：跨域認證解決方案

JWT 的原理是，服務器認證以后，生成一個 JSON 物件，發回給用戶，就像下面這樣，

{
"姓名": "張三",
"角色": "管理員",
"到期時間": "2018年7月1日0點0分"
}

以后，用戶與服務端通信的時候，都要發回這個 JSON 物件，服務器完全只靠這個物件認定用戶身份，為了防止用戶篡改資料，服務器在生成這個物件的時候，會加上簽名，
服務器就不保存任何 session 資料了，也就是說，服務器變成無狀態了，從而比較容易實作擴展，
一個JWT實際上就是一個字串，它由三部分組成：頭部、載荷與簽名，

1、頭部（Header）
頭部用于描述關于該JWT的最基本的資訊，例如其型別以及簽名所用的演算法等，這也可以被表示成一個JSON物件，

{
"typ":"JWT",
"alg":"HS256"
}

alg 屬性表示簽名的演算法（algorithm），默認是 HMAC SHA256； typ 屬性表示這個令牌（token）的型別（type），JWT 令牌統一寫為 JWT ，
最后，將上面的 JSON 物件使用 Base64URL 演算法轉成字串，

2、載荷（playload）
Payload 部分也是一個 JSON 物件，用來存放實際需要傳遞的資料，JWT 規定了7個官方欄位，供選用，

iss: jwt簽發者
sub: jwt所面向的用戶
aud: 接收jwt的一方
exp: jwt的過期時間，這個過期時間必須要大于簽發時間
nbf: 定義在什么時間之前，該jwt都是不可用的.
iat: jwt的簽發時間
jti: jwt的唯一身份標識，主要用來作為一次性token，

除了官方欄位，你還可以在這個部分定義私有欄位，下面就是一個例子，

{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}

注意，JWT 默認是不加密的，任何人都可以讀到，所以不要把秘密資訊放在這個部分，
這個 JSON 物件也要使用 Base64URL 演算法轉成字串，

3、簽名（signature）
Signature 部分是對前兩部分的簽名，防止資料篡改，
首先，需要指定一個密鑰（secret），這個密鑰只有服務器才知道，不能泄露給用戶，然后，使用Header 里面指定的簽名演算法，產生簽名，算出簽名以后，把 Header、Payload、Signature 三個部分拼成一個字串，每個部分之間用.分隔，就可以回傳給用戶，

注意：secret是保存在服務器端的，Jwt的簽發生成也是在服務器端的，secret就是用來進行Jwt的簽發和Jwt的驗證，所以，它就是你服務端的私鑰，在任何場景都不應該流露出去，一旦客戶端得知這個secret, 那就意味著客戶端就可以自我簽發Jwt了，

JWT特點：
（1）JWT 默認是不加密，但也是可以加密的，生成原始 Token 以后，可以用密鑰再加密一次，
（2）JWT 不加密的情況下，不能將秘密資料寫入 JWT，
（3）JWT 不僅可以用于認證，也可以用于交換資訊，有效使用 JWT，可以降低服務器查詢資料庫的次數，
（4）JWT 的最大缺點是，由于服務器不保存 session 狀態，因此無法在使用程序中廢止某個 token，或者更改 token 的權限，也就是說，一旦 JWT 簽發了，在到期之前就會始終有效，除非服務器部署額外的邏輯，
（5）JWT 本身包含了認證資訊，一旦泄露，任何人都可以獲得該令牌的所有權限，為了減少盜用，JWT 的有效期應該設定得比較短，對于一些比較重要的權限，使用時應該再次對用戶進行認證，
（6）為了減少盜用，JWT 不應該使用 HTTP 協議明碼傳輸，要使用 HTTPS 協議傳輸，

為什么要使用JWT：
分布式系統解決Session問題，
假設現在有一個APP，后臺是分布式系統，APP的首頁模塊部署在杭州機房的服務器上，子頁面模塊部署在深圳機房的服務器上，此時你從首頁登錄了該APP，然后跳轉到子頁面模塊，session在兩個機房之間不能同步，用戶是否需要重新登錄？傳統的方式（cookie+session）需要重新登錄，用戶體驗不好，session共享（在多臺物理機之間傳輸和復制session）方式對網路IO的壓力大，延遲太長，用戶體驗也不好，JWT相當于將session保存在了客戶端，解決了后臺session復制的問題，

分布式session解決方案

1、session復制
session復制是早期的企業級的使用比較多的一種服務器集群session管理機制，應用服務器開啟web容器的session復制功能，在集群中的幾臺服務器之間同步session物件，使得每臺服務器上都保存所有的session資訊，這樣任何一臺宕機都不會導致session的資料丟失，服務器使用session時，直接從本地獲取，

這種方式在應用集群達到數千臺的時候，就會出現瓶頸，每臺都需要備份session，出現記憶體不夠用的情況，

2、session系結
利用hash演算法，比如nginx的ip_hash,使得同一個IP的請求分發到同一臺服務器上，

這種方式不符合對系統的高可用要求，因為一旦某臺服務器宕機，那么該機器上的session也就不復存在了，用戶請求切換到其他機器后沒有session，無法完成業務處理，

3、利用cookie記錄session
session記錄在客戶端，每次請求服務器的時候，將session放在請求中發送給服務器，服務器處理完請求后再將修改后的session回應給客戶端，這里的客戶端就是cookie，

利用cookie記錄session的也有缺點，比如受cookie大小的限制，能記錄的資訊有限；每次請求回應都需要傳遞cookie，影響性能，如果用戶關閉cookie，訪問就不正常，

4、Session集中式存盤
將原先存盤在單機服務器記憶體中的Session資料集中存盤起來，比如說存盤在分布式快取 Redis 集群中，

其原理是以SessionId作為Key，序列化后的HttpSession物件作為Value存盤在Redis中，然后將SessionId回傳給客戶端，當下一次客戶端發送HTTP請求到服務器的時候，會帶上這個SessionId，服務器再根據SessionId從Redis拿到相應的Session資料并反序列化成HttpSession物件，由于對HttpSession物件進行了集中存盤，而不是存盤在服務器本地記憶體，所以即使同個用戶的多次HTTP請求落到不同的服務器上，也能將SessionId與相應的HttpSession物件關聯起來，從而實作分布式環境下的Session共享，

HTTP 是不保存狀態的協議,如何保存用戶狀態？

假如某個特定的客戶機在短時間內兩次請求同一個物件，服務器并不會因為剛剛為該用戶提供了該物件就不再做出反應，而是重新發送該物件，就像該服務器已經完全忘記不久之前所做過的是一樣，因為一個 HTTP 服務器并不保存關于客戶機的任何資訊，所以我們說 HTTP 是一個無狀態協議，

通常有兩種解決方案：
（1）基于 Session 實作的會話保持
在客戶端第一次向服務器發送 HTTP 請求后，服務器會創建一個 Session 物件并將客戶端的身份資訊以鍵值對的形式存盤下來，然后分配一個會話標識（SessionId）給客戶端，這個會話標識一般保存在客戶端 Cookie 中，之后每次該瀏覽器發送 HTTP 請求都會帶上 Cookie 中的 SessionId 到服務器，服務器根據會話標識就可以將之前的狀態資訊與會話聯系起來，從而實作會話保持，

優點：安全性高，因為狀態資訊保存在服務器端，
缺點：由于大型網站往往采用的是分布式服務器，瀏覽器發送的 HTTP 請求一般要先通過負載均衡器才能到達具體的后臺服務器，倘若同一個瀏覽器兩次 HTTP 請求分別落在不同的服務器上時，基于 Session 的方法就不能實作會話保持了，

【解決方法：采用中間件，例如 Redis，我們通過將 Session 的資訊存盤在 Redis 中，使得每個服務器都可以訪問到之前的狀態資訊】

（2）基于 Cookie 實作的會話保持
當服務器發送回應訊息時，在 HTTP 回應頭中設定 Set-Cookie 欄位，用來存盤客戶端的狀態資訊，客戶端決議出 HTTP 回應頭中的欄位資訊，并根據其生命周期創建不同的 Cookie，這樣一來每次瀏覽器發送 HTTP 請求的時候都會帶上 Cookie 欄位，從而實作狀態保持，基于 Cookie 的會話保持與基于 Session 實作的會話保持最主要的區別是前者完全將會話狀態資訊存盤在瀏覽器 Cookie 中，

優點：服務器不用保存狀態資訊， 減輕服務器存盤壓力，同時便于服務端做水平拓展，
缺點：該方式不夠安全，因為狀態資訊存盤在客戶端，這意味著不能在會話中保存機密資料，除此之外，瀏覽器每次發起 HTTP 請求時都需要發送額外的 Cookie 到服務器端，會占用更多帶寬，

拓展：Cookie被禁用了怎么辦？
若遇到 Cookie 被禁用的情況，則可以通過重寫 URL 的方式將會話標識放在 URL 的引數里，也可以實作會話保持，

HTTP/1.1 和 HTTP/1.0 的區別

• 快取處理：在 HTTP/1.0 中主要使用 header 里的 if-modified-Since, Expries 來做快取判斷的標準，而 HTTP/1.1 請求頭中添加了更多與快取相關的欄位，從而支持更為靈活的快取策略，例如 Entity-tag, If-Unmodified-Since, If-Match, If-None-Match 等可供選擇的快取頭來控制快取策略，
• 節約帶寬： 當客戶端請求某個資源時，HTTP/1.0 默認將該資源相關的整個物件傳送給請求方，但很多時候可能客戶端并不需要物件的所有資訊，而在 HTTP/1.1 的請求頭中引入了 range 頭域，它允許只請求部分資源，其使得開發者可以多執行緒請求某一資源，從而充分的利用帶寬資源，實作高效并發，
• 錯誤通知的管理：HTTP/1.1 在 1.0 的基礎上新增了 24 個錯誤狀態回應碼，例如 414 表示客戶端請求中所包含的 URL 地址太長，以至于服務器無法處理；410 表示所請求的資源已經被永久洗掉，
• Host 請求頭：早期 HTTP/1.0 中認為每臺服務器都系結一個唯一的 IP 地址并提供單一的服務，請求訊息中的 URL 并沒有傳遞主機名，而隨著虛擬主機的出現，一臺物理服務器上可以存在多個虛擬主機，并且它們共享同一個 IP 地址，為了支持虛擬主機，HTTP/1.1 中添加了 host 請求頭，請求訊息和回應訊息中應宣告這個欄位，若請求訊息中缺少該欄位時服務端會回應一個 404 錯誤狀態碼，
• 長連接：HTTP/1.0 默認瀏覽器和服務器之間保持短暫連接，瀏覽器的每次請求都需要與服務器建立一個 TCP 連接，服務器完成后立即斷開 TCP 連接，HTTP/1.1 默認使用的是持久連接，其支持在同一個 TCP 請求中傳送多個 HTTP 請求和回應，此之前的 HTTP 版本的默認連接都是使用非持久連接，如果想要在舊版本的 HTTP 協議上維持持久連接，則需要指定 Connection 的首部欄位的值為 Keep-Alive，

HTTP 1.1如何斷點續傳？

HTTP 1.1協議中定義了斷點續傳相關的HTTP頭 Range和Content-Range欄位，一個最簡單的斷點續傳實作大概如下：

1. 客戶端下載一個1024K的檔案，已經下載了其中512K
2. 網路中斷，客戶端請求續傳，因此需要在HTTP頭中申明本次需要續傳的片段：
   Range:bytes=512000-
   這個頭通知服務端從檔案的512K位置開始傳輸檔案
3. 服務端收到斷點續傳請求，從檔案的512K位置開始傳輸，并且在HTTP頭中增加：
   Content-Range:bytes 512000-/1024000
   并且此時服務端回傳的HTTP狀態碼應該是206，而不是200，

但是在實際場景中，會出現一種情況，即在終端發起續傳請求時，URL對應的檔案內容在服務端已經發生變化，此時續傳的資料肯定是錯誤的，如何解決這個問題？顯然此時我們需要有一個標識檔案唯一性的方法，
在 RFC2616 中也有相應的定義，比如實作 Last-Modified 來標識檔案的最后修改時間，這樣即可判斷出續傳檔案時是否已經發生過改動，同時 FC2616 中還定義有一個 ETag 的頭，可以使用 ETag 頭來放置檔案的唯一標識，

If-Modified-Since，和 Last-Modified 一樣都是用于記錄頁面最后修改時間的 HTTP 頭資訊，只是 Last-Modified 是由服務器往客戶端發送的 HTTP 頭，而 If-Modified-Since 則是由客戶端往服務器發送的頭，可以看到，再次請求本地存在的 cache 頁面時，客戶端會通過 If-Modified-Since 頭將先前服務器端發過來的 Last-Modified 最后修改時間戳發送回去，這是為了讓服務器端進行驗證，通過這個時間戳判斷客戶端的頁面是否是最新的，如果不是最新的，則回傳新的內容，如果是最新的，則回傳 304 告訴客戶端其本地 cache 的頁面是最新的，于是客戶端就可以直接從本地加載頁面了，這樣在網路上傳輸的資料就會大大減少，同時也減輕了服務器的負擔，

Etag（Entity Tags）主要為了解決 Last-Modified 無法解決的一些問題，

1. 一些檔案也許會周期性的更改，但是內容并不改變（僅改變修改時間），這時候我們并不希望客戶端認為這個檔案被修改了，而重新 GET，
2. 某些檔案修改非常頻繁，例如：在秒以下的時間內進行修改（1s 內修改了 N 次），If-Modified-Since 能檢查到的粒度是 s 級的，這種修改無法判斷（或者說 UNIX 記錄 MTIME 只能精確到秒），
3. 某些服務器不能精確的得到檔案的最后修改時間，

為此，HTTP/1.1 引入了 Etag，Etag 僅僅是一個和檔案相關的標記，

另外RFC2616中同時定義有一個If-Range頭，終端如果在續傳是使用If-Range，If-Range中的內容可以為最初收到的ETag頭或者是Last-Modfied中的最后修改時候，服務端在收到續傳請求時，通過If-Range中的內容進行校驗，校驗一致時回傳206的續傳回應，不一致時服務端則回傳200回應，回應的內容為新的檔案的全部資料，

第一次請求：

1. 客戶端發起 HTTP GET 請求一個檔案，
2. 服務器處理請求，回傳檔案內容以及相應的 Header，其中包括 Etag（例如：627-4d648041f6b80）（假設服務器支持 Etag 生成并已開啟了 Etag）狀態碼為 200，

第二次請求（斷點續傳）：

1. 客戶端發起 HTTP GET 請求一個檔案，同時發送 If-Range（該頭的內容就是第一次請求時服務器回傳的 Etag：627-4d648041f6b80），
2. 服務器判斷接收到的 Etag 和計算出來的 Etag 是否匹配，如果匹配，那么回應的狀態碼為 206；否則，狀態碼為 200，

HTTP 1.x的缺陷

• 客戶端需要使用多個連接才能實作并發和縮短延遲；
• 不會壓縮請求和回應首部，從而導致不必要的網路流量；
• 不支持有效的資源優先級，致使底層 TCP 連接的利用率低下，

SPDY

HTTP1.x的優化：優化了HTTP1.X的請求延遲，解決了HTTP1.X的安全性問題，

• 降低延遲，針對HTTP高延遲的問題，SPDY優雅的采取了多路復用（multiplexing），降低了延遲同時提高了帶寬的利用率，多路復用通過多個請求stream共享一個TCP連接的方式，解決了HOL blocking的問題，
• 請求優先級（request prioritization），多路復用帶來一個新的問題是，在連接共享的基礎上可能會導致關鍵請求被阻塞，SPDY允許給每個request設定優先級，這樣重要的請求就會優先得到回應，比如瀏覽器加載首頁，首頁的html內容應該優先展示，之后才是各種靜態資源檔案，腳本檔案等加載，這樣可以保證用戶能第一時間看到網頁內容，
• header壓縮，前面提到HTTP1.x的header很多時候都是重復多余的，選擇合適的壓縮演算法可以減小包的大小和數量，
• 基于HTTPS的加密協議傳輸，大大提高了傳輸資料的可靠性，
• 服務端推送（server push），采用了SPDY的網頁，例如我的網頁有一個sytle.css的請求，在客戶端收到sytle.css資料的同時，服務端會將sytle.js的檔案推送給客戶端，當客戶端再次嘗試獲取sytle.js時就可以直接從快取中獲取到，不用再發請求了，
  SPDY在HTTP之下，TCP和SSL之上，可以輕松兼容老版本HTTP協議(將HTTP1.x內容封裝成一種新的frame格式)，同時可以使用已有的SSL功能，

HTTP2.0：SPDY的升級版，區別如下：

• HTTP2.0 支持明文 HTTP 傳輸，而 SPDY 強制使用 HTTPS；
• HTTP2.0 訊息頭的壓縮演算法采用HPACK，而SPDY 采用DEFLATE，

HTTP/1.X 和 HTTP/2.0 的區別

• 相比于 HTTP/1.X 的文本（字串）傳送， HTTP/2.0 采用二進制傳送，客戶端和服務器傳輸資料時把資料分成幀，幀組成了資料流，流具有流 ID 標識和優先級，通過優先級以及流依賴能夠一定程度上解決關鍵請求被阻塞的問題，
• HTTP/2.0 支持多路復用，因為流 ID 的存在， 通過同一個 HTTP 請求可以實作多個 HTTP 請求傳輸，客戶端和服務器可以通過流 ID 來標識究竟是哪個流從而定位到是哪個 HTTP 請求，
• HTTP/2.0 頭部壓縮，HTTP/2.0 通過 gzip 和 compress 壓縮頭部然后再發送，同時通信雙方會維護一張頭資訊表，所有欄位都記錄在這張表中，在每次 HTTP 傳輸時只需要傳頭欄位在表中的索引即可，大大減小了重傳次數和資料量，
• HTTP/2.0 支持服務器推送， 服務器在客戶端未經請求許可的情況下，可預先向客戶端推送需要的內容，客戶端在退出服務時可通過發送復位相關的請求來取消服務端的推送，

HTTP2.0的多路復用和HTTP1.X中的長連接復用有什么區別？

HTTP/1.0 一次請求-回應，建立一個連接，用完關閉；每一個請求都要建立一個連接；
HTTP/1.1 所有的資料通信是按次序進行的，服務器只有處理完一個請求，才會接著處理下一個請求，一旦有某請求超時等，后續請求只能被阻塞，也就是人們常說的線頭/端/程阻塞；
HTTP/2.0多個請求可同時在一個連接上并行執行，某個請求任務耗時嚴重，不會影響到其它連接的正常執行，

HTTP/3

HTTP/2 存在的問題

我們知道，傳統 Web 平臺的資料傳輸都基于 TCP 協議，而 TCP 協議在創建連接之前不可避免的需要三次握手，如果需要提高資料互動的安全性，即增加傳輸層安全協議（TLS），還會增加更多的握手次數，HTTP 從 1.0 到 2.0，其傳輸層都是基于 TCP 協議的，即使是帶來巨大性能提升的 HTTP/2，也無法完全解決 TCP 協議存在的固有問題（慢啟動，擁塞視窗尺寸的設定等），此外，HTTP/2 多路復用只是減少了連接數，其隊頭的擁塞問題并沒有完全解決，倘若 TCP 丟包率過大，則 HTTP/2 的表現將不如 HTTP/1.1，

QUIC 協議

QUIC（Quick UDP Internet Connections），直譯為快速 UDP 網路連接，是谷歌制定的一種基于 UDP 的低延遲傳輸協議，其主要目的是解決采用傳輸層 TCP 協議存在的問題，同時滿足傳輸層和應用層對多連接、低延遲等的需求，該協議融合了 TCP, TLS, HTTP/2 等協議的特性，并基于 UDP傳輸，該協議帶來的主要提升有：

• 低延遲連接，當客戶端第一次連接服務器時，QUIC 只需要 1 RTT（Round-Trid Time）延遲就可以建立安全可靠的連接（采用 TLS 1.3 版本），相比于 TCP + TLS 的 3 次 RTT 要更加快捷，之后，客戶端可以在本地快取加密的認證資訊，當再次與服務器建立連接時可以實作 0 RTT 的連接建立延遲，
• QUIC 復用了 HTTP/2 協議的多路復用功能，由于 QUIC 基于 UDP，所以也避免了 HTTP/2存在的隊頭阻塞問題，
• 基于 UDP 協議的 QUIC 運行在用戶域而不是系統內核，這使得 QUIC 協議可以快速的更新和部署，從而很好地解決了 TPC 協議部署及更新的困難，
• QUIC 的報文是經過加密和認證的，除了少量的報文，其它所有的 QUIC 報文頭部都經過了認證，報文主體經過了加密，只要有攻擊者篡改 QUIC 報文，接收端都能及時發現，
• 具有向前糾錯機制，每個資料包攜帶了除了本身內容外的部分其他資料包的內容，使得在出現少量丟包的情況下，盡量地減少其它包的重傳次數，其通過犧牲單個包所攜帶的有效資料大小換來更少的重傳次數，這在丟包數量較小的場景下能夠帶來一定程度的性能提升，

HTTP/3

HTTP/3 是在 QUIC 基礎上發展起來的，其底層使用 UDP 進行資料傳輸，上層仍然使用 HTTP/2，在 UDP 與 HTTP/2 之間存在一個 QUIC 層，其中 TLS 加密程序在該層進行處理，HTTP/3 主要有以下幾個特點：

• 使用 UDP 作為傳輸層進行通信；
• 在 UDP 之上的 QUIC 協議保證了 HTTP/3 的安全性，QUIC 在建立連接的程序中就完成了 TLS 加密握手；
• 建立連接快，正常只需要 1 RTT 即可建立連接，如果有快取之前的會話資訊，則直接驗證和建立連接，此程序 0 RTT，建立連接時，也可以帶有少量業務資料；
• 不和具體底層連接系結，QUIC 為每個連接的兩端分別分配了一個唯一 ID，上層連接只認這對邏輯 ID，網路切換或者斷連時，只需要繼續發送資料包即可完成連接的建立；
• 使用 QPACK 進行頭部壓縮，因為 在 HTTP/2 中的 HPACK 要求傳輸程序有序，這會導致隊頭阻塞，而 QPACK 不存在這個問題，
  最后我們使用一張圖來清晰的表示出 HTTP 協議的發展變化：
  

短鏈接和長鏈接的區別

所謂長連接，指在一個TCP連接上可以連續發送多個資料包，在TCP連接保持期間，如果沒有資料包發送，需要雙方發檢測包以維持此連接，一般需要自己做在線維持，

短連接是指通信雙方有資料互動時，就建立一個TCP連接，資料發送完成后，則斷開此TCP連接，一般銀行都使用短連接，HTTP是無狀態的的短鏈接，

HTTP 長連接短連接使用場景是什么

長連接：多用于操作頻繁，點對點的通訊，而且客戶端連接數目較少的情況，例如即時通訊、網路游戲等，

短連接：用戶數目較多的Web網站的 HTTP 服務一般用短連接，例如京東，淘寶這樣的大型網站一般客戶端數量達到千萬級甚至上億，若采用長連接勢必會使得服務端大量的資源被無效占用，所以一般使用的是短連接，

Keep-Alive 和非 Keep-Alive 區別，對服務器性能有影響嗎？

在早期的 HTTP/1.0 中，瀏覽器每次 發起 HTTP 請求都要與服務器創建一個新的 TCP 連接，服務器完成請求處理后立即斷開 TCP 連接，服務器不跟蹤每個客戶也不記錄過去的請求，然而創建和關閉連接的程序需要消耗資源和時間，為了減少資源消耗，縮短回應時間，就需要重用連接，在 HTTP/1.1 版本中默認使用持久連接，在此之前的 HTTP 版本的默認連接都是使用非持久連接，如果想要在舊版本的 HTTP 協議上維持持久連接，則需要指定 connection 的首部欄位的值為 Keep-Alive 來告訴對方這個請求回應完成后不要關閉，下一次咱們還用這個請求繼續交流，我們用一個示意圖來更加生動的表示兩者的區別：

對于非 Keep-Alive 來說，必須為每一個請求的物件建立和維護一個全新的連接，對于每一個這樣的連接，客戶機和服務器都要分配 TCP 的緩沖區和變數，這給服務器帶來的嚴重的負擔，因為一臺 Web 服務器可能同時服務于數以百計的客戶機請求，在 Keep-Alive 方式下，服務器在回應后保持該 TCP 連接打開，在同一個客戶機與服務器之間的后續請求和回應報文可通過相同的連接進行傳送，甚至位于同一臺服務器的多個 Web 頁面在從該服務器發送給同一個客戶機時，可以在單個持久 TCP 連接上進行，

然而，Keep-Alive 并不是沒有缺點的，當長時間的保持 TCP 連接時容易導致系統資源被無效占用，若對 Keep-Alive 模式配置不當，將有可能比非 Keep-Alive 模式帶來的損失更大，因此，我們需要正確地設定 keep-alive timeout 引數，當 TCP 連接在傳送完最后一個 HTTP 回應，該連接會保持 keepalive_timeout 秒，之后就開始關閉這個鏈接，

HTTP與TCP的區別？

TCP/IP是一個分層的協議，計算機里面很多東西都是這樣分層來設計的，這樣設計的好處是每一層只需要考慮自己需要處理的資料，
在TCP/IP協議的四層模型里，HTTP屬于應用層，之所以叫應用層是因為這些是我們直接接觸到的具體應用，比如用于網頁瀏覽的HTTP，用于傳輸檔案的FTP，或者遠程登錄的Telnet和SSH，HTTP是無狀態的短連接，
TCP是傳輸層，它通過流量控制、重傳等機制來在主機間建立一個可靠的連接，TCP使用不同的埠來標記不同的應用發起的連接，為了避免在網路層產生分片，TCP會通過協商MSS，Path MTU Discovery的方式來對資料包進行分段交給網路層，TCP是有狀態的長連接，
IP是網路層，負責處理不同的網路之間發送的資料包，它不需要考慮具體應用或者埠的資訊，它的主要作業是分片（fragmentation）和重組（reassembly）資料包以及根據IP地址做路由（route），TCP需要通過重傳來保證可靠性，所以不依賴網路層的分片，主要是UDP使用，
總結：

• IP是網路層，負責把包從發送端送到接收端，但是，不保證服務（丟、多、改、按序）；
• TCP是傳輸層，是底層通訊協議，定義的是資料傳輸和連接方式的規范，負責可靠傳輸，保證HTTP層能拿到正確格式的包；
• HTTP是應用層協議，定義的是傳輸資料的內容的規范，負責內容決議、內容呈現、用戶互動；
• HTTP一般基于TCP，TCP一般基于IP，三者之間是服務關系，HTTP:發什么；TCP:怎么發；IP:發資料給誰，

URI && URL

• URI(Uniform Resource Identifier) 是統一資源標志符，可以唯一標識一個資源，不是定位資源
• URL(Uniform Resource Location) 是統一資源定位符，可以提供該資源的路徑，它是一種具體的URI，即 URL 可以用來標識一個資源，而且還指明了如何 locate 這個資源，其實就是我們平時上網時輸入的網址，它標識一個互聯網資源，并指定對其進行操作或獲取該資源的方法，例如 https://leetcode-cn.com/problemset/all/ 這個 URL，標識一個特定資源并表示該資源的某種形式是可以通過 HTTP 協議從相應位置獲得，
• URN(Uniform Resource Name)統一資源名，

URI的作用像身份證號一樣，URN如同一個人的名稱，URL的作用更像家庭住址一樣，URL是一種具體的URI，它不僅唯一標識資源，而且還提供了定位該資源的資訊，

URL 是 URI 的一個子集，兩者都定義了資源是什么，而 URL 還定義了如何能訪問到該資源，URI 是一種語意上的抽象概念，可以是絕對的，也可以是相對的，而URL則必須提供足夠的資訊來定位，是絕對的，簡單地說，只要能唯一標識資源的就是 URI，在 URI 的基礎上給出其資源的訪問方式的就是 URL，

HTTPS

什么是 HTTPS？

HTTPS，是以安全為目標的HTTP通信，簡單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL， 現在它被廣泛用于萬維網上安全敏感的通訊，例如交易支付方面，經常會在Web的登錄頁面和購物結算界面等使用HTTPS通信（當瀏覽器訪問HTTPS通信有效的Web網站時，瀏覽器的地址欄內會出現一個帶鎖的標記），

HTTPS 并不是新協議，而是讓 HTTP 先和 SSL （Secure Sockets Layer）通信，再由 SSL 和 TCP 通信，也就是說 HTTPS 使用了隧道進行通信，通過使用 SSL，HTTPS 具有了加密（防竊聽）、認證（防偽裝）和完整性保護（防篡改），

HTTPS作業原理

• 發起請求

客戶端通過TCP和服務器建立連接后（443埠），發出請求證書的訊息，此訊息里包含自己可實作的演算法串列，

• 證書回傳

采用 HTTPS 協議的服務器必須要有一套數字證書，可以自己制作，也可以向組織申請，區別就是自己頒發的證書需要客戶端驗證通過，才可以繼續訪問，而使用受信任的公司申請的證書則不會彈出提示頁面，這套證書其實就是一對公鑰和私鑰，是用來進行非對稱加密使用的，服務器端保存著私鑰，不能將其泄露，公鑰可以發送給任何人；

服務器端收到訊息后，回傳公鑰，公鑰包含了很多資訊，如證書的頒發機構，過期時間、資料等等，

• 證書驗證

客戶端收到服務器端的公鑰之后，檢查其合法性，比如頒發機構，過期時間等等，如果發現發現公鑰有問題，那么HTTPS傳輸就無法繼續，

如果公鑰合格，則客戶端會生成一個客戶端密鑰，然后用服務器的公鑰對客戶端密鑰進行非對稱加密成密文，至此，HTTPS中的第一次HTTP請求結束；

• 秘鑰交換

客戶端發起HTTPS中的第二個HTTP請求，將加密之后的客戶端密鑰發送給服務器；

服務器接收到客戶端發來的密文之后，會用自己的私鑰對其進行非對稱解密，解密之后的明文就是客戶端密鑰，然后用客戶端密鑰對資料進行對稱加密，這樣資料就變成了密文；然后服務器將加密后的密文發送給客戶端；

• 資料傳輸

客戶端收到服務器發送來的密文，用客戶端密鑰對其進行對稱解密，得到服務器發送的資料，這樣HTTPS中的第二個HTTP請求結束，整個HTTPS傳輸完成，

HTTP 與 HTTPS 的區別

• HTTP 運行在TCP之上，是明文傳輸；連接很簡單，是無狀態的，HTTPS運行在SSL/TLS之上，SSL/TLS運行在TCP之上，可進行加密傳輸、身份認證，比 HTTP 協議安全；
• HTTP和 HTTPS 使用的是完全不同的連接方式，用的埠也不一樣，HTTP 的埠號是 80，HTTPS 是 443；
• HTTPS 需要到 CA 申請證書，一般免費證書很少，需要交費，
• HTTP 頁面回應速度比 HTTPS 快，主要是因為 HTTP 使用 TCP 三次握手建立連接，客戶端和服務器需要交換 3 個包，而 HTTPS除了 TCP 的三個包，還要加上 ssl 握手需要的 9 個包，所以一共是12 個包，
• HTTPS 其實就是建構在 SSL/TLS 之上的 HTTP 協議，所以，要比較 HTTPS 比 HTTP 要更耗費服務器資源，

HTTP通信存在什么問題?

• 通信使用明文（不加密），內容可能被竊聽

HTTP本身不具備加密的功能，所以也無法做到對通信整體（使用HTTP協議通信的請求和回應的內容）進行加密，即，HTTP報文使用明文（指未經過加密的報文）方式發送，

• 不驗證通信方的身份，因此有可能遭遇偽裝

HTTP協議中的請求和回應不會對通信方進行確認（會存在各種隱患，比如目標的Web服務器有可能是已偽裝的Web服務器），在HTTP協議通信時，由于不存在確認通信方的處理步驟，任何人都可以發起請求，另外，服務器只要接收到請求，不管對方是誰都會回傳一個回應（但也僅限于發送端的IP地址和埠號沒有被Web服務器設定限制訪問的前提下），

• 無法證明報文的完整性，所以可能遭篡改

所謂完整性是指資訊的準確度，若無法證明其完整性，通常也就意味著無法判斷資訊是否準確，由于HTTP協議無法證明通信的報文完整性，因此，在請求或回應送出之后直到對方接收之前的這段時間內，即使請求或回應的內容遭到篡改，也沒有辦法獲悉，

HTTPS如何解決上述三個問題？

HTTPS并非是應用層的一種新協議，只是HTTP通信介面部分用SSL（Secure Socket Layer）和TLS（Transport Layer Security）協議代替而已，

通常，HTTP直接和TCP通信，當使用SSL時，則演變成先和SSL通信，再由SSL和TCP通信了，所謂HTTPS，其實就是身披SSL協議外殼的HTTP，

在采用SSL后，HTTP就擁有了HTTPS的加密、身份驗證和完整性保護這些功能，也就是說HTTP加上加密處理、認證以及完整性保護后即是HTTPS，

加密演算法

HTTPS 協議的主要功能基本都依賴于 TLS/SSL 協議，TLS/SSL 的功能實作主要依賴于三類基本演算法：散列演算法、對稱加密和非對稱加密，其利用非對稱加密實作身份認證和密鑰協商，對稱加密演算法采用協商的密鑰對資料加密，基于散列演算法驗證資訊的完整性，

非對稱加密演算法：RSA，DSA/DSS，ECC

對稱加密演算法：AES，RC4，3DES，DES

散列演算法（HASH演算法）：MD5，SHA1，SHA256

加密——解決內容可能被竊聽的問題

對稱加密：
這種方式加密和解密同用一個密鑰，沒有密鑰就無法進行解密，反過來說，任何人只要持有密鑰就能解密了，

非對稱加密：
非對稱加密/公開密鑰加密 使用一對非對稱的密鑰，一把叫做私有密鑰，另一把叫做公開密鑰，顧名思義，私有密鑰不能讓其他任何人知道，而公開密鑰則可以隨意發布，任何人都可以獲得，
非對稱加密的特點是資訊傳輸一對多，服務器只需要維持一個私鑰就能夠和多個客戶端進行加密通信，但服務器發出的資訊能夠被所有的客戶端解密，且該演算法的計算復雜，加密速度慢，

對稱加密+非對稱加密：
將對稱加密與非對稱加密結合起來,充分利用兩者各自的優勢，將多種方法組合起來用于通信，在交換密鑰環節使用非對稱加密方式，之后的建立通信交換報文階段則使用對稱加密方式，具體做法是：發送密文的一方使用對方的公鑰對“對稱的密鑰”進行加密，然后對方用自己的私鑰解密拿到“對稱的密鑰”，這樣可以確保交換的密鑰是安全的前提下，使用對稱加密方式進行通信，所以，HTTPS采用對稱加密和非對稱加密兩者并用的混合加密機制，

數字簽名——解決報文可能遭篡改問題

數字簽名有兩種功效：

• 能確定訊息確實是由發送方簽名并發出來的，因為發送方簽名無法偽造，
• 數字簽名能驗證訊息的完整性，證明資料是否未被篡改過，

數字簽名技術就是對“非對稱密鑰加解密”和“數字摘要“兩項技術的應用，它將摘要資訊用發送者的私鑰加密，與原文一起傳送給接收者，接收者只有用發送者的公鑰才能解密被加密的摘要資訊，然后用HASH函式對收到的原文產生一個摘要資訊，與解密的摘要資訊對比，如果相同，則說明收到的資訊是完整的，在傳輸程序中沒有被修改；否則說明資訊被修改過，

認證——解決通信方身份可能被偽裝的問題

非對稱加密方式還是存在一些問題的，那就是無法證明公開密鑰本身就是貨真價實的公開密鑰，為了解決上述問題，可以使用由數字證書認證機構（CA，Certificate Authority）和其相關機關頒發的公開密鑰證書，也可叫做數字證書或直接稱為證書，

接到證書的客戶端可使用數字證書認證機構的公開密鑰，對那張證書上的數字簽名進行驗證，一旦驗證通過，客戶端便可明確兩件事：一，認證服務器的公開密鑰的是真實有效的數字證書認證機構，二，服務器的公開密鑰是值得信賴的，

為什么不一直使用HTTPS

與純文本通信相比，加密通信會消耗更多的CPU及記憶體資源，如果每次通信都加密，會消耗相當多的資源，平攤到一臺計算機上時，能夠處理的請求數量必定也會隨之減少，如果是非敏感資訊則使用HTTP通信，只有在包含個人資訊等敏感資料時，才利用HTTPS加密通信，

想要節約購買證書的開銷也是原因之一，

DNS

DNS 的作用和原理

DNS：（Domain Name System）是域名系統的英文縮寫，是一種組織成域層次結構的計算機和網路服務命名系統，用于 TCP/IP 網路，

DNS 的作用：通常我們有兩種方式識別主機：通過主機名或者 IP 地址，人們喜歡便于記憶的主機名表示，而路由器則喜歡定長的、有著層次結構的 IP 地址，為了滿足這些不同的偏好，我們就需要一種能夠進行主機名到 IP 地址轉換的目錄服務，域名系統作為將域名和 IP 地址相互映射的一個分布式資料庫，能夠使人更方便地訪問互聯網，

DNS 域名決議原理：DNS 采用了分布式的設計方案，其域名空間采用一種樹形的層次結構：

上圖展示了 DNS 服務器的部分層次結構，從上到下依次為根域名服務器、頂級域名服務器和權威域名服務器，其實根域名服務器在因特網上有13個，大部分位于北美洲，第二層為頂級域服務器，這些服務器負責頂級域名（如 com、org、net、edu）和所有國家的頂級域名（如uk、fr、ca 和 jp），在第三層為權威 DNS 服務器，因特網上具有公共可訪問主機（例如 Web 服務器和郵件服務器）的每個組織機構必須提供公共可訪問的 DNS 記錄，這些記錄由組織機構的權威 DNS 服務器負責保存，這些記錄將這些主機的名稱映射為 IP 地址，

除此之外，還有一類重要的 DNS 服務器，叫做本地 DNS 服務器，本地 DNS 服務器嚴格來說不在 DNS 服務器的層次結構中，但它對 DNS 層次結構是很重要的，一般來說，每個網路服務提供商（ISP） 都有一臺本地 DNS 服務器，當主機與某個 ISP 相連時，該 ISP 提供一臺主機的 IP 地址，該主機具有一臺或多臺其本地 DNS 服務器的 IP 地址，主機的本地 DNS 服務器通常和主機距離較近，當主機發起 DNS 請求時，該請求被發送到本地 DNS 服務器，它起著代理的作用，并將該請求轉發到 DNS 服務器層次結構中，

我們以一個例子來了解 DNS 的作業原理，假設主機 A（IP 地址為 abc.xyz.edu） 想知道主機 B 的 IP 地址 （def.mn.edu），如下圖所示，主機 A 首先向它的本地 DNS 服務器發送一個 DNS 查詢報文，該查詢報文含有被轉換的主機名 def.mn.edu，本地 DNS 服務器將該報文轉發到根 DNS 服務器，根 DNS 服務器注意到查詢的 IP 地址前綴為 edu 后向本地 DNS 服務器回傳負責 edu 的頂級域名服務器的 IP 地址串列，該本地 DNS 服務器則再次向這些 頂級域名服務器發送查詢報文，該頂級域名服務器注意到 mn.edu 的前綴，并用權威域名服務器的 IP 地址進行回應，通常情況下，頂級域名服務器并不總是知道每臺主機的權威 DNS 服務器的 IP 地址，而只知道中間的某個服務器，該中間 DNS 服務器依次能找到用于相應主機的 IP 地址，我們假設中間經歷了權威服務器 ① 和 ②，最后找到了負責 def.mn.edu 的權威 DNS 服務器 ③，之后，本地 DNS 服務器直接向該服務器發送查詢報文從而獲得主機 B 的IP 地址，

在上圖中，IP 地址的查詢其實經歷了兩種查詢方式，分別是遞回查詢和迭代查詢，

域名決議查詢的兩種方式：

遞回查詢：如果主機所詢問的本地域名服務器不知道被查詢域名的 IP 地址，那么本地域名服務器就以 DNS 客戶端的身份，向其他根域名服務器繼續發出查詢請求報文，即替主機繼續查詢，而不是讓主機自己進行下一步查詢，如上圖步驟（1）和（10），

迭代查詢：當根域名服務器收到本地域名服務器發出的迭代查詢請求報文時，要么給出所要查詢的 IP 地址，要么告訴本地服務器下一步應該找哪個域名服務器進行查詢，然后讓本地服務器進行后續的查詢，如上圖步驟（2）~（9），

DNS 為什么既使用 TCP 又使用 UDP？

當進行區域傳送（主域名服務器向輔助域名服務器傳送變化的那部分資料）時會使用 TCP，因為資料同步傳送的資料量比一個請求和應答的資料量要多，而 TCP 允許的報文長度更長，因此為了保證資料的正確性，會使用基于可靠連接的 TCP，
當客戶端向 DNS 服務器查詢域名 ( 域名決議) 的時候，一般回傳的內容不會超過 UDP 報文的最大長度，即 512 位元組，用 UDP 傳輸時，不需要經過 TCP 三次握手的程序，從而大大提高了回應速度，但這要求域名決議器和域名服務器都必須自己處理超時和重傳從而保證可靠性，

怎么實作 DNS 劫持？

DNS 劫持即域名劫持，是通過將原域名對應的 IP 地址進行替換從而使得用戶訪問到錯誤的網站或者使得用戶無法正常訪問網站的一種攻擊方式，域名劫持往往只能在特定的網路范圍內進行，范圍外的 DNS 服務器能夠回傳正常的 IP 地址，攻擊者可以冒充原域名所屬機構，通過電子郵件的方式修改組織機構的域名注冊資訊，或者將域名轉讓給其它組織，并將新的域名資訊保存在所指定的 DNS 服務器中，從而使得用戶無法通過對原域名進行決議來訪問目的網址，

具體實施步驟如下：

• 獲取要劫持的域名資訊：攻擊者首先會訪問域名查詢站點查詢要劫持的域名資訊，
• 控制域名相應的 E-MAIL 賬號：在獲取到域名資訊后，攻擊者通過暴力破解或者專門的方法破解公司注冊域名時使用的 E-mail 賬號所對應的密碼，更高級的攻擊者甚至能夠直接對 E-mail 進行資訊竊取，
• 修改注冊資訊：當攻擊者破解了 E-MAIL 后，會利用相關的更改功能修改該域名的注冊資訊，包括域名擁有者資訊，DNS 服務器資訊等，
• 使用 E-MAIL 收發確認函：在修改完注冊資訊后，攻擊者在 E-mail 真正擁有者之前收到修改域名注冊資訊的相關確認資訊，并回復確認修改檔案，待網路公司恢復已成功修改信件后，攻擊者便成功完成 DNS 劫持，

用戶端的一些預防手段：

• 直接通過 IP 地址訪問網站，避開 DNS 劫持，
• 由于域名劫持往往只能在特定的網路范圍內進行，因此一些高級用戶可以通過網路設定讓 DNS 指向正常的域名服務器以實作對目的網址的正常訪問，例如將計算機首選 DNS 服務器的地址固定為 8.8.8.8，

網路編程

通常網路編程默認是指TCP編程，即用socket（是ip地址與埠的結合協議，是行程間通信的一種方式）函式創建一個socket用于TCP通訊，函式引數通常填為SOCK_STREAM，即socket(PF_INET, SOCK_STREAM, 0)，這表示建立一個socket用于流式網路通訊，SOCK_STREAM這種的特點是面向連接的，即每次收發資料之前必須通過connect建立連接，也是雙向的，即任何一方都可以收發資料，協議本身提供了一些保障機制保證它是可靠的、有序的，即每個包按照發送的順序到達接收方，

而SOCK_DGRAM這種是UDP協議的網路通訊，它是無連接的，不可靠的，因為通訊雙方發送資料后不知道對方是否可以正常收到資料，任何一方建立一個socket以后就可以用sendto發送資料，也可以用recvfrom接收資料，根本不關心對方是否存在，是否發送了資料，它的特點是通訊速度比較快，

socket的組成與作用：在網路傳輸中用于唯一標識兩個端點（包括（ip+port））的鏈接，4個要素：客戶端地址、客戶端埠、服務器地址、服務器埠，

TCP服務器端編程的一般步驟是：
　　1、創建一個socket，用函式socket()；
　　2、設定socket屬性，用函式setsockopt(); * 可選
　　3、系結IP地址、埠等資訊到socket上，用函式bind();
　　4、開啟監聽，用函式listen()；
　　5、接收客戶端上的連接，用函式accept()；
　　6、收發資料，用函式send()和recv()，或者read()和write();
　　7、關閉網路連接；
　　8、關閉監聽；
TCP客戶端編程的一般步驟是：
　　1、創建一個socket，用函式socket()；
　　2、設定socket屬性，用函式setsockopt();* 可選
　　3、系結IP地址、埠等資訊到socket上，用函式bind();* 可選
　　4、設定要連接的服務器的IP地址和埠等屬性；
　　5、連接服務器，用函式connect()；
　　6、收發資料，用函式send()和recv()，或者read()和write();
　　7、關閉網路連接；
UDP編程步驟要簡單許多，UDP服務器端編程的一般步驟是：
　　1、創建一個socket，用函式socket()；
　　2、設定socket屬性，用函式setsockopt();* 可選
　　3、系結IP地址、埠等資訊到socket上，用函式bind();
　　4、回圈接收資料，用函式recvfrom();
　　5、關閉網路連接；
UDP客戶端編程的一般步驟是：
　　1、創建一個socket，用函式socket()；
　　2、設定socket屬性，用函式setsockopt();* 可選
　　3、系結IP地址、埠等資訊到socket上，用函式bind();* 可選
　　4、設定對方的IP地址和埠等屬性;
　　5、發送資料，用函式sendto();
　　6、關閉網路連接；

socket() 套接字

套接字（Socket）是對網路中不同主機上的應用行程之間進行雙向通信的端點的抽象，網路行程通信的一端就是一個套接字，不同主機上的行程便是通過套接字發送報文來進行通信，例如 TCP 用主機的 IP 地址 + 埠號作為 TCP 連接的端點，這個端點就叫做套接字，

套接字主要有以下三種型別：

• 流套接字（SOCK_STREAM）：流套接字基于 TCP 傳輸協議，主要用于提供面向連接、可靠的資料傳輸服務，由于 TCP 協議的特點，使用流套接字進行通信時能夠保證資料無差錯、無重復傳送，并按順序接收，通信雙方不需要在程式中進行相應的處理，
• 資料報套接字（SOCK_DGRAM）：和流套接字不同，資料報套接字基于 UDP 傳輸協議，對應于無連接的 UDP 服務應用，該服務并不能保證資料傳輸的可靠性，也無法保證對端能夠順序接收到資料，此外，通信兩端不需建立長時間的連接關系，當 UDP 客戶端發送一個資料給服務器后，其可以通過同一個套接字給另一個服務器發送資料，當用 UDP 套接字時，丟包等問題需要在程式中進行處理，
• 原始套接字（SOCK_RAW）：由于流套接字和資料報套接字只能讀取 TCP 和 UDP 協議的資料，當需要傳送非傳輸層資料包（例如 Ping 命令時用的 ICMP 協議資料包）或者遇到作業系統無法處理的資料包時，此時就需要建立原始套接字來發送，

socket原理

套接字（socket）是通信的基石，是支持TCP/IP協議的網路通信的基本操作單元，它是網路通信程序中端點的抽象表示，包含進行網路通信必須的五種資訊：使用的通信協議；本地主機的IP地址；本地行程的協議埠；遠地主機的IP地址；遠地行程的協議埠，

應用層可以和傳輸層通過Socket介面，區分來自不同應用程式行程或網路連接的通信，實作資料傳輸的并發服務，

建立Socket連接：
建立Socket連接至少需要一對套接字，其中一個運行于客戶端，稱為ClientSocket；另一個運行于服務器端，稱為ServerSocket ，套接字之間的連接程序分為三個步驟：服務器監聽，客戶端請求，連接確認，

• 服務器監聽：服務器端套接字并不定位具體的客戶端套接字，而是處于等待連接的狀態，實時監控網路狀態，等待客戶端的連接請求，
• 客戶端請求：指客戶端的套接字發起連接請求，要連接的目標是服務器端的套接字，為此，客戶端的套接字必須首先描述它要連接的服務器的套接字，指出服務器端套接字的地址和埠號，然后就向服務器端套接字發起連接請求，
• 連接確認：當服務器端套接字監聽或接收到客戶端套接字的連接請求時，就回應該請求，建立一個新的執行緒，把服務器端套接字的描述發給客戶端，一旦客戶端確認了此描述，雙方就正式建立連接，而服務器端套接字繼續處于監聽狀態，繼續接收其他客戶端套接字的連接請求，

Socket連接與TCP連接：
創建Socket連接時，可以指定使用的傳輸層協議（支持TCP或UDP），當使用TCP協議進行連接時，該Socket連接就是一個TCP連接，

Socket連接與HTTP連接：
很多情況需要服務器主動向客戶端推送資料，保證客戶端與服務器資料的實時與同步，此時若雙方建立的是Socket連接，服務器可以直接將資料傳給客戶端；若雙方建立的是HTTP連接，則服務器需要等到客戶端發送一次請求后才能將資料傳回給客戶端，因此，客戶端定時向服務器端發送連接請求，不僅可以保持在線，還可以“詢問”服務器是否有新的資料，如果有就將資料傳給客戶端，

為什么 fidder，charles 能抓到你的包？【抓取資料包的程序】

假如我們需要抓取客戶端的資料包，需要監控客戶端與服務器互動之間的網路節點，監控其中任意一個網路節點（網卡），獲取所有經過網卡中的資料，對這些資料按照網路協議進行決議，這就是抓包的基本原理，而中間的網路節點不受我們控制，是基本無法實作抓包的，因此只能在客戶端與服務器之間進行抓包，

（1）當采用抓包工具抓取 HTTP 資料包時，程序較為簡單：

• 首先抓包工具會提出代理服務，客戶端需要連接該代理；
• 客戶端發出 HTTP 請求時，會經過抓包工具的代理，抓包工具將請求的原文進行展示；
• 抓包工具使用該原文將請求發送給服務器；
• 服務器回傳結果給抓包工具，抓包工具將回傳結果進行展示；
• 抓包工具將服務器回傳的結果原樣回傳給客戶端，
• 這里抓包工具相當于透明人，資料經過的時候它一只手接到資料，然后另一只手把資料傳出去，

（2）當抓取 HTTPS 資料包時：

• 客戶端連接抓包工具提供的代理服務，并安裝抓包工具的根證書；
• 客戶端發出 HTTPS 請求，抓包工具模擬服務器與客戶端進行 TLS 握手交換密鑰等流程；
• 抓包工具發送一個 HTTPS 請求給客戶端請求的目標服務器，并與目標服務器進行 TLS 握手交換密鑰等流程；
• 客戶端使用與抓包工具協定好的密鑰加密資料后發送給抓包工具；
• 抓包工具使用與客戶端協定好的密鑰解密資料，并將結果進行展示；
• 抓包工具將解密后的客戶端資料，使用與服務器協定好的密鑰進行加密后發送給目標服務器；
• 服務器解密資料后，做對應的邏輯處理，然后將回傳結果使用與抓包工具協定好的密鑰進行加密發送給抓包工具；
• 抓包工具將服務器回傳的結果，用與服務器協定好的密鑰解密，并將結果進行展示；
• 抓包工具將解密后的服務器回傳資料，使用與客戶端協定好的密鑰進行加密后發送給客戶端；
• 客戶端解密資料，

這個時候抓包工具對客戶端來說相當于服務器，對服務器來說相當于客戶端，在這個傳輸程序中，客戶端會以為它就是目標服務器，服務器也會以為它就是請求發起的客戶端，

如果你訪問一個網站很慢，怎么排查和解決？

網頁打開速度慢的原因有很多，這里列舉出一些較常出現的問題：

• 首先最直接的方法是查看本地網路是否正常，可以通過網路測速軟體例如電腦管家等對電腦進行測速，若網速正常，我們查看網路帶寬是否被占用，例如當你正在下載電影時并且沒有限速，是會影響你打開網頁的速度的，這種情況往往是處理器記憶體小導致的；
• 當網速測驗正常時，我們對網站服務器速度進行排查，通過 ping 命令查看鏈接到服務器的時間和丟包等情況，一個速度好的機房，首先丟包率不能超過 1%，其次 ping 值要小，最后是 ping 值要穩定，如最大和最小差值過大說明路由不穩定，或者我們也可以查看同臺服務器上其他網站的打開速度，看是否其他網站打開也慢，
• 如果網頁打開的速度時快時慢，甚至有時候打不開，有可能是空間不穩定的原因，當確定是該問題時，就要找你的空間商解決或換空間商了，如果購買空間的話，可選擇購買購買雙線空間或多線空間；如果是在有的地方打開速度快，有的地方打開速度慢，那應該是網路線路的問題，電信線路用戶訪問放在聯通服務器的網站，聯通線路用戶訪問放在電信服務器上的網站，相對來說打開速度肯定是比較慢，
• 從網站本身找原因，

網站的問題主要包括網站程式設計、網頁設計結構和網頁內容三個部分，

• 網站程式設計：當訪問網頁中有拖慢網站打開速度的代碼，會影響網頁的打開速度，例如網頁中的統計代碼，我們最好將其放在網站的末尾，因此我們需要查看網頁程式的設計結構是否合理；
• 網頁設計結構：如果是 table 布局的網站，查看是否嵌套次數太多，或是一個大表格分成多個表格這樣的網頁布局，此時我們可以采用 div 布局并配合 css 進行優化，
• 網頁內容：查看網頁中是否有許多尺寸大的圖片或者尺寸大的 flash 存在，我們可以通過降低圖片質量，減小圖片尺寸，少用大型 flash 加以解決，此外，有的網頁可能過多地參考了其他網站的內容，若某些被參考的網站訪問速度慢，或者一些頁面已經不存在了，打開的速度也會變慢，一種直接的解決方法是去除不必要的加載項，

其他協議

（1）FTP，FTP（File Transfer Protocol，檔案傳輸協議）是用于在網路上進行檔案傳輸的一套標準協議，使用客戶/服務器模式，使用 TCP 資料報，提供互動式訪問，雙向傳輸，
TFTP（Trivial File Transfer Protocol，簡單檔案傳輸協議）一個小且易實作的檔案傳輸協議，也使用客戶/服務器方式，使用 UDP 資料報，只支持檔案傳輸而不支持互動，沒有列目錄，不能對用戶進行身份鑒定，

（2）SMTP，SMTP（Simple Mail Transfer Protocol，簡單郵件傳輸協議）是在 Internet 傳輸 Email 的標準，是一個相對簡單的基于文本的協議，在其之上指定了一條訊息的一個或多個接收者（在大多數情況下被確認是存在的），然后訊息文本會被傳輸，可以很簡單地通過 Telnet 程式來測驗一個 SMTP 服務器，SMTP 使用 TCP 埠 25，

（3）DHCP，DHCP ( Dynamic Host Configuration Protocol，動態主機設定協議 ) 是一個局域網的網路協議，使用 UDP 協議作業，主要有兩個用途：
用于內部網路或網路服務供應商自動分配 IP 地址給用戶
用于內部網路管理員作為對所有電腦作中央管理的手段

（4）SNMP，SNMP（Simple Network Management Protocol，簡單網路管理協議）構成了互聯網工程作業小組（IETF，Internet Engineering Task Force）定義的 Internet 協議族的一部分，該協議能夠支持網路管理系統，用以監測連接到網路上的設備是否有任何引起管理上關注的情況，

FTP的主動模式和被動模式？連接程序？

檔案傳輸協議（FTP）是網路共享檔案的傳輸協議，在網路應用軟體中具有廣泛的應用，FTP的目標是提高檔案的共享性和可靠高效地傳送資料，FTP只通過TCP連接，沒有用于FTP的UDP組件，

一般的 客戶端/服務器（C/S）結構 應用程式只會建立一個 Socket 連接，這個連接同時處理服務器端和客戶端的連接命令和資料傳輸，而FTP協議將命令與資料分開傳送，提高了效率，FTP使用了兩個埠, 一個資料埠和一個命令埠(或控制埠)，通常21埠是命令埠，20埠是資料埠，當混入主動/被動模式的概念時，資料埠就有可能不是20了，

FTP協議要用到兩個TCP連接，一個是命令連接，用來在FTP客戶端與服務器之間傳遞命令；另一個是資料連接，用來上傳或下載資料，無論是主動模式還是被動模式，要進行檔案傳輸都必須依次建立兩個連接，

主動模式FTP

服務端通過指定的資料傳輸埠（默認20），主動連接客戶端提交的埠，向客戶端發送資料，
主動模式下，FTP客戶端隨機開啟一個非特殊的埠N（N > 1023）連入到FTP服務器的命令埠–21埠，然后客戶端在N+1埠監聽，并且通過N+1埠發送命令給FTP服務器，服務器接收到命令后，會用其本地的FTP資料埠（通常是20）來連接客戶端指定的埠N+1，進行資料傳輸，

優點：服務端配置簡單，利于服務器安全管理，服務器只需要開放21埠，
缺點：如果客戶端開啟了防火墻，或客戶端處于內網（NAT網關之后），那么服務器對客戶端埠發起的連接可能會失敗，

被動模式FTP

在被動方式FTP中，命令連接和資料連接都由客戶端，這樣就可以解決從服務器到客戶端的資料埠方向的連接被防火墻過濾掉的問題，服務端開啟資料傳輸埠的監聽，被動等待客戶端的連接，然后向客戶端發送資料，
在被動模式下，FTP客戶端隨機開啟一個大于1024的埠N向服務器的21埠發起連接，同時會開啟N+1埠，然后向服務器發送PASV命令，通知服務器自己處于被動模式，服務器收到命令后，會開放一個大于1024的埠P進行監聽，然后用PORT P命令通知客戶端，資料埠是P，客戶端收到命令后，會通過N+1號埠連接服務器的埠P，然后在兩個埠之間進行資料傳輸，

優點：對客戶端網路環境沒有要求，
缺點：服務器配置管理復雜，不利于安全，服務器需要開放隨機高位埠以便客戶端可以連接，因此大多數FTP服務軟體都可以手動配置被動埠的范圍，

兩種模式的比較

主動模式傳送資料是“服務器”連接到“客戶端”的埠，對FTP服務器的管理有利，但對客戶端的管理不利，被動模式傳送資料是“客戶端”連接到“服務器”的埠，對FTP客戶端的管理有利，但對服務器端的管理不利，
主動模式需要客戶端開放埠給服務器，很多客戶端都是在防火墻內，開放埠給FTP服務器訪問比較困難，被動模式只需要服務器開放埠給客戶端連接就行，

FTP的作業流程

FTP 與大多數 Internet 服務一樣，使用的也是“客戶端/服務器”模式，用戶通過一個支持 FTP 協議的客戶機程式，連接在遠程主機上的 FTP 服務器程式，通過客戶端向服務器端發送 FTP 命令，服務器執行該命令，并將執行結果回傳給客戶端，由于“控制連接”的因素，客戶端發送的 FTP 命令，服務器都會有對應的應答，
FTP 進行檔案傳輸的基本作業流程主要分為 4 個階段，即建立連接階段、身份認證階段、命令互動階段和斷開連接階段，

• 建立連接階段：該階段是FTP客戶端通過TCP三次握手與FTP服務器端建立連接，客戶端向FTP服務器發出建立連接請求，FTP服務器對請求進行應答，如果 FTP 服務器上的 21 埠是啟用的，可以接受來自其他主機的請求，給出應答220，表示服務就緒，即告訴客戶端需要的FTP服務已經準備好了，回傳應答以后，FTP服務器需要客戶端進行身份認證，向客戶端發送身份認證請求，
• 身份認證階段：指客戶端需要向FTP服務器提供登錄所需的用戶名和密碼，FTP服務器對客戶端輸入的用戶名和密碼都會給出相應的應答，如果客戶端輸入的用戶名和密碼正確，將成功登錄FTP服務器，此時進入FTP會話，
• 命令互動階段：在FTP會話中，用戶可以執行FTP命令進行檔案傳輸，如查看目錄資訊、上傳或下載檔案等，客戶端輸入要執行的FTP命令后，服務器同樣會給出應答，如果輸入的執行命令正確，服務器會將命令的執行結果回傳給客戶端，執行結果回傳完成后，服務器繼續給出應答，
• 斷開連接階段：當客戶端不再與FTP服務器進行檔案傳輸時需要斷開連接，客戶端向FTP服務器發送斷開連接請求，服務器收到請求后給出相應的應答，

網頁決議全程序【用戶輸入網址到顯示對應頁面的全程序】

• DNS 決議：當用戶輸入一個網址并按下回車鍵的時候，瀏覽器獲得一個域名，而在實際通信程序中，我們需要的是一個 IP 地址，因此我們需要先把域名轉換成相應 IP 地址，【具體細節參看問題 16，17】
• TCP 連接：瀏覽器通過 DNS 獲取到 Web 服務器真正的 IP 地址后，便向 Web 服務器發起 TCP 連接請求，通過 TCP 三次握手建立好連接后，瀏覽器便可以將 HTTP 請求資料發送給服務器了，【三次握手放在傳輸層詳細講解】
• 發送 HTTP 請求：瀏覽器向 Web 服務器發起一個 HTTP 請求，HTTP 協議是建立在 TCP 協議之上的應用層協議，其本質是在建立起的TCP連接中，按照HTTP協議標準發送一個索要網頁的請求，在這一程序中，會涉及到負載均衡等操作，
• 處理請求并回傳：服務器獲取到客戶端的 HTTP 請求后，會根據 HTTP 請求中的內容來決定如何獲取相應的檔案，并將檔案發送給瀏覽器，
• 瀏覽器渲染：瀏覽器根據回應開始顯示頁面，首先決議 HTML 檔案構建 DOM 樹，然后決議 CSS 檔案構建渲染樹，等到渲染樹構建完成后，瀏覽器開始布局渲染樹并將其繪制到螢屏上，
• 斷開連接：客戶端和服務器通過四次揮手終止 TCP 連接，

負載均衡

負載均衡，英文名為 Load Balance，其含義是指將負載（作業任務）進行平衡、分攤到多個操作單元上進行運行，例如 FTP 服務器、Web 服務器、企業核心服務器和其他主要任務服務器等，從而協同完成作業任務，負載均衡建立在現有的網路之上，它提供了一種透明且廉價有效的方法擴展服務器和網路設備的帶寬、增加吞吐量、加強網路處理能力并提高網路的靈活性和可用性，

負載均衡是分布式系統架構設計中必須考慮的因素之一，例如天貓、京東等大型用戶網站中為了處理海量用戶發起的請求，其往往采用分布式服務器，并通過引入反向代理等方式將用戶請求均勻分發到每個服務器上，而這一程序所實作的就是負載均衡，