【推薦】2019 Java 開發者跳槽指南.pdf(吐血整理) >>> 
1. HTTP首部信息格式
1. 簡介：HTTP，即超文本傳輸協議，是TCP/IP協議模型中的一個應用層協議，用於描述瀏覽器與服務器之間進行交流的數據的固定格式。瀏覽器以固定格式將數據打包發送給服務器，服務器以這個固定格式對數據包進行拆包，或者相反進行。HTTP協議中的首部信息爲兩種，一種是HTTP請求，另一種是HTTP響應。
2. HTTP協議的請求：客戶端發送請求對應的數據格式，請求首部信息包括兩部分，主要是請求行、請求頭。請求體是數據部分。
- 請求行：第一個紅框內的內容，包括請求方式（get、post等方式），請求地址以及使用的HTTP協議版本。在Restful標準中，每一種請求方式都有着其特殊含義，比如get表示獲取資源、post表示發送文本數據、put表示發送文件、delete表示刪除文件等等，但開發中我們還是只用到了get以及post
- get：能傳輸的數據大小會受到限制，而且傳輸的參數列表會顯示在地址欄，安全性較低。
- post：能傳輸的數據大小不會受到限制，傳輸的參數列表不會顯示在地址欄，安全性較高。
- 請求頭：第二個紅框內的內容就是請求頭，以鍵值對形式存在，部分請求頭字段如下
- Accept ：表示瀏覽器可以接受的數據形式。
- Accept-Encoding：瀏覽器接受的編碼格式
- Content-Type：表示請求中發送的數據類型
- Accept-Language：瀏覽器接受的語言類型。
- User-Agent：當前瀏覽器版本。通過該請求頭可以獲取瀏覽器的版本。
- Host：接受請求的服務器的ip地址與端口
- Connection：該請求頭表示是否保持TCP連接，默認都會設置爲Keep-Alive，因爲如果每一個HTTP請求都要建立一次TCP連接的話，代價非常巨大。
- Referer：該請求頭的值會記錄這次請求的來源，或者說請求網址，比如說從百度中搜索淘寶後，點擊淘寶會進入淘寶頁面，Referer 請求頭就會記錄這次的請求是由那裏發起的，這個可以用於防盜鏈，通過判斷該請求頭的值，也就是來判斷髮起該請求的網址來判斷是否允許該請求的通過。如果是直接通過瀏覽器地址欄輸入地址，那麼該請求頭的值就是請求的地址。
- If-Modified-Since：與304狀態碼、響應頭一起使用，用來控制本地緩存的使用。
- Keep-Alive：表示TCP連接保持時間
- Cache-control：控制緩存行爲
- 請求空行：第三個紅框，這是必須存在的一個空行
- 請求正文：提交的請求中包含需要發送給服務端的數據（文本或者文件）。
3. HTTP協議的響應：服務端做出響應對應的數據格式。響應首部信息爲響應行和響應頭。
- 響應行：第一個藍框就是響應行，包括了HTTP協議版本和響應狀態碼，常見狀態碼所代表信息如下
- 100-199：表示請求接收成功，客戶端必須繼續提交下一次請求才能完成整個處理過程。
- 200-299：表示成功接受請求並完成一次處理過程。常用200，表示一個請求對應一個響應成功。
- 300-399：爲完成請求，客戶端需要進一步細化請求，例如請求重定向用302表示，返回302狀態碼，同時返回重定向的地址，瀏覽器自動向該地址發起請求，然後接受重定向地址發回的響應；或304表示服務器資源未改動，通知客戶端在本地緩存中查找資源並使用。
- 400-499：客戶端請求出錯，常見404表示請求路徑無效或找不到請求的資源、400表示請求的格式錯誤（請求錯誤）、403表示請求的資源被服務器拒絕訪問。
- 500-599：服務端出錯，常用500表示服務器運行出現錯誤；503表示服務不可用，一般是服務端處於超負載或者停機處理，無法處理請求；
- 響應頭：第二個藍框就是響應頭，包括了一系列的響應頭鍵值對，部分響應頭比如
- Location：該響應頭的值就是重定向的地址，與302狀態碼共同完成重定向。其值的形式如 http://www.baidu.com
- Last-Modified：該響應頭的值表示服務器端被請求資源的最後一次的修改時間，並且保存在瀏覽器中。請求頭中的If-Modified-Since值就是上一次訪問時該資源的最後修改時間值，該響應頭和請求頭If-Modified-Since以及304狀態碼一起使用，通過這三個值的配合使用可以使瀏覽器使用本地緩存的文件資源；其值的形式如
Last-Modified Wed, 11 Jul 2018 14:08:18 GMT - Refresh：設置該響應頭可用於定時頁面刷新，或者定時跳轉，其值的形式如 1;url=http://www.baidu.com
- Content-Disposition：用於文件下載
- 下面三個響應頭是一起使用的，用於禁止瀏覽器的緩存項。
- Expires -1
- Cache-Control no-cache
- Pragma no-cache
- 響應空行：無用，但是必須有
- 響應體：就是服務器直接返回的數據資源，比如js文件、html、圖片等。
2. HTTP與HTTPS
1. HTTP存在的問題：通信安全問題，HTTP中的通信時直接明文傳輸數據，不進行任何加密措施，相當於數據裸奔與網絡之中，所以其對於密碼、個人信息之類的數據絕對不能用HTTP協議進行傳輸。
2. 爲了改善HTTP協議的通信安全問題，就出現了HTTPS協議，該協議就是在HTTP協議的基礎上，添加一種加密協議對HTTP通信線路進行加密。爲了數據傳輸的安全，HTTPS在HTTP的基礎上加入了SSL（安全套接層）或TLS（安全層傳輸協議）協議，SSL/TLS依靠證書來驗證服務器的身份，併爲瀏覽器和服務器之間的通信加密。
即：HTTPS = HTTP + SSL/TLS。SSL或TLS協議主要是建立一條安全的通信線路，還有另一種方式就是僅對傳輸的數據內容加密，雖然可以保證數據內容無法被他人解析，但無法阻止他人對數據內容的攔截以及修改，所以不使用這種方式。
3. 使用HTTP協議主要有以下三種通信不安全的情況：
（1）通信內容被竊聽，對於互聯網中的數據其實全都是可以被監聽的，完全可以實現針對某個網段的數據包（幀）抓取，然後再將抓取的數據包交給抓包軟件進行解析即可，如果內容不加密就可以獲取到數據內容。
（2）無法驗證通信方的身份，通信方可能僞裝身份。接收請求的服務器可能是一個僞裝的服務器，並不是請求的真正目標服務器；無法確定服務端返回的響應是否到達了真正的客戶端，有可能是僞裝的客戶端；無法確定對方是否具有訪問權限，因爲有些特殊的資源是特殊用戶的訪問權限；無法判斷請求來自於誰；即使無意義的請求也會全部接受，無法拒絕海量的DOS攻擊。
（3）無法驗證傳輸數據的完整性，有可能數據已被篡改。
3.長連接和短連接
1. HTTP 對 TCP 連接的使用，分爲兩種方式：俗稱“短連接”和“長連接”（“Keep-Alive”或“Persistent Connection”）
（1）長連接:當一個網頁打開完成後，客戶端和服務器之間用於傳輸HTTP數據的TCP連接不會關閉，客戶端再次訪問這個服務器時，會繼續使用這一條已經建立的連接。Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務器軟件（如Apache）中設定這個時間。實現長連接需要客戶端和服務端都支持長連接。使用長連接的HTTP協議，會在響應頭加入這行代碼：Connection:keep-alive。如果HTTP1.1版本的HTTP請求報文不希望使用長連接，則要在HTTP請求報文首部加上Connection: close。TCP的保活功能主要爲服務器應用提供,試圖在服務端器端檢測到半開放的連接,並根據響應決定是否關閉連接
（2）短連接:客戶端和服務器每進行一次HTTP操作，就建立一次連接，任務結束就中斷連接。雙方任意都可以發起close操作，不過一般都是client先發起close操作。短連接的優點是管理起來比較簡單，存在的連接都是有用的連接，不需要額外的控制手段。
2. 長連接的數據傳輸完成識別：判斷傳輸數據是否達到了Content-Length指示的大小；動態生成的文件沒有Content-Length，它是分塊傳輸（chunked），這時候就要根據chunked編碼來判斷，chunked編碼的數據在最後有一個空chunked塊，表明本次傳輸數據結束。
3. 長連接的過期時間：
keepalive_timeout 20; --長連接timeout
keepalive_requests 8192; --每個連接最大請求數
4. 什麼時候用長連接，短連接：
長連接多用於操作頻繁，點對點的通訊，而且連接數不能太多情況，。每個TCP連接都需要三步握手，這需要時間，如果每個操作都是先連接，再操作的話那麼處理速度會降低很多，所以每個操作完後都不斷開，次處理時直接發送數據包就OK了，不用建立TCP連接。例如：數據庫的連接用長連接， 如果用短連接頻繁的通信會造成socket錯誤，而且頻繁的socket 創建也是對資源的浪費。而像WEB網站的http服務一般都用短鏈接，因爲長連接對於服務端來說會耗費一定的資源，而像WEB網站這麼頻繁的成千上萬甚至上億客戶端的連接用短連接會更省一些資源，如果用長連接，而且同時有成千上萬的用戶，如果每個用戶都佔用一個連接的話，那可想而知吧。所以併發量大，但每個用戶無需頻繁操作情況下需用短連好。
5. 設置HTTP長連接，有過期時間：
設置請求頭域
在首部字段中設置Connection:keep-alive 和Keep-Alive: timeout=60，表明連接建立之後，空閒時間超過60秒之後，就會失效。如果在空閒第58秒時，再次使用此連接，則連接仍然有效，使用完之後，重新計數，空閒60秒之後過期。
設置HTTP長連接，無過期時間;在首部字段中只設置Connection:keep-alive，表明連接永久有效。connection字段只有服務端設置纔有效。
connection字段只有服務端設置纔有效。
客戶端設置Connection: Keep-Alive和Keep-Alive: timeout=60， 服務端設置Connection: Keep-Alive和Keep-Alive: timeout=5。
6. 如何理解HTTP協議是無狀態的
HTTP 是一種不保存狀態，即無狀態（stateless）協議。HTTP協議自身不對請求和響應之間的通信狀態進行保存。也就是說在 HTTP 這個級別，協議對於發送過的請求或響應都不做持久化處理，因爲如果由服務器來承擔每個客戶端的狀態保存是非常不現實的，對服務器壓力非常大。但是無法保存狀態會造成應用中的一些問題和侷限，所以採用cookie技術來進行保存客戶端狀態，通過在請求和響應中設置cookie就可以實現保存控制客戶端狀態。
4. HTTPS協議原理簡單說明
1. HTTPS通過加密+身份認證+完整性保護的方式來增強HTTP的安全性，客戶端在使用HTTPS方式與Web服務器通信時有以下幾個步驟。
（1）客戶使用https的URL訪問Web服務器，要求與Web服務器建立SSL連接。
（2）Web服務器收到客戶端請求後，會將網站的證書信息（證書中包含公鑰）傳送一份給客戶端。
（3）客戶端的瀏覽器與Web服務器開始協商SSL連接的安全等級，也就是信息加密的等級。
（4）客戶端的瀏覽器根據雙方同意的安全等級，建立會話密鑰，然後利用網站的公鑰將會話密鑰加密，並傳送給網站。
（5）Web服務器利用自己的私鑰解密出會話密鑰。
（6）Web服務器利用會話密鑰加密與客戶端之間的通信。
2. 對於HTTP來說，其直接調用TCP協議提供的服務，而在HTTPS中，HTTP會在部分接口上先和SSL協議進行通信，然後SSL在和TCP進行通信。所以，HTTPS就相當於HTTP協議加上SSL協議，當使用了SSL協議後就具有了加密、認證以及完整性保護的功能。
3. HTTPS中的加密方式：SSL協議採用一種叫做公開密鑰加密（Public-key cryptography）的加密處理方式，即加密算法公開，但密鑰保密，持有密鑰就可以和加密算法共同完成解密。
（1）共享密鑰加密（對稱加密）：即加密與解密使用同一個密鑰，也稱爲對稱加密。這種方式在使用的時候，必須要將密鑰發送給另一方，但是我們無法保證共享密鑰在網絡中傳輸是安全的，一旦密鑰被第三方截獲那麼就會造成數據盜取。
（2）公開密鑰加密（非對稱加密）：即加密與解密使用不同的密鑰，發送密文方使用公開密鑰進行加密，而接收密文方解密使用私有密鑰，私有密鑰必須保證其保存的安全性，不會被盜取。非對稱加密技術源於兩個大質數相乘，就現代的計算機來說，破解非對稱機密是不可能的。
（3）HTTPS將兩種解密算法一起使用，如果能保證密鑰的安全交換就使用第一種發送，否則就用第二種，但是第二種方式的性能較差。
4. 公開密鑰加密方式需要去認證公開密鑰的真實性和準確性：公開密鑰加密方式還是存在一些問題的。那就是無法證明公開密鑰本身就是貨真價實的公開密鑰。比如，正準備和某臺服務器建立公開密鑰加密方式下的通信時，如何證明收到的公開密鑰就是原本預想的那臺服務器發行的公開密鑰？或許在公開密鑰傳輸途中，真正的公開密鑰已經被攻擊者替換掉了。
所以需要使用由數字證書認證機構（CA，Certificate Authority）和其相關機關頒發的公開密鑰證書。數字證書認證機構處於客戶端與服務器雙方都可信賴的第三方機構的立場上。
（1）首先，服務器的運營人員向數字證書認證機構提出公開密鑰的申請。數字證書認證機構在判明提出申請者的身份之後，會對已申請的公開密鑰做數字簽名，然後分配這個已簽名的公開密鑰，並將該公開密鑰放入公鑰證書後綁定在一起。
（2）然後服務器會將這份由數字證書認證機構頒發的公鑰證書發送給客戶端， 以進行公開密鑰加密方式通信。公鑰證書也可叫做數字證書或直接稱爲證書。
（3）接到證書的客戶端可使用數字證書認證機構的公開密鑰，對那張證書上的數字簽名進行驗證，一旦驗證通過，客戶端便可明確兩件事： 一，認證服務器的公開密鑰的是真實有效的數字證書認證機構。二， 服務器的公開密鑰是值得信賴的。 此處認證機關的公開密鑰必須安全地轉交給客戶端。使用通信方式時，如何安全轉交是一件很困難的事，因此，多數瀏覽器開發商發佈版本時，會事先在內部植入常用認證機關的公開密鑰。
5. HTTPS的缺點：HTTPS雖然很安全，但是實際上網站使用的並不多，因爲與HTTP的純文本通信相比，HTTP因爲加密通信會消耗更多的性能資源，尤其是請求數量很多的時候對於服務器的壓力很大；其次是HTTPS的中認證證書是需要購買的，需要額外花銷。所以HTTPS只用於傳輸密碼等關鍵敏感信息，並不能大規模使用。