簡述http，主要特點舶吗，1.0, 1.1, 2.0 和 3.0區(qū)別
HTTP（HyperText Transfer Protocol）超文本傳輸協(xié)議，是TCP/IP協(xié)議集中的一個應用層協(xié)議腹侣，用于定義瀏覽器和Web服務器之間交換數(shù)據(jù)的過程以及數(shù)據(jù)本身的格式傲隶。
HTTP工作模式
HTTP1.0,1.1, 2.0 區(qū)別（發(fā)展）
HTTP 1.0與1.1
緩存處理：在HTTP1.0中主要使用header里的If-Modified-Since,Expires來做為緩存判斷的標準脖卖，HTTP1.1則引入了更多的緩存控制策略例如Entity tag畦木，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略十籍。
帶寬優(yōu)化以及網(wǎng)絡連接的使用：HTTP1.0中娶吞，存在一些浪費帶寬的現(xiàn)象妒蛇，例如客戶端只是需要某個對象的一部分绣夺，而服務器卻將整個對象送過來了奋蔚，并且不支持斷點續(xù)傳功能泊碑，HTTP1.1則在請求頭引入了range頭域馒过，它允許只請求資源的某個部分腹忽，即返回碼是206（Partial Content），這樣就方便了開發(fā)者自由的選擇以便于充分利用帶寬和連接着裹。
錯誤通知管理：在HTTP1.1中新增了24個錯誤狀態(tài)響應碼，如409（Conflict）表示請求的資源與資源的當前狀態(tài)發(fā)生沖突匠题；410（Gone）表示服務器上的某個資源被永久性的刪除但金。
Host頭處理：在HTTP1.0中認為每臺服務器都綁定一個唯一的IP地址韭山，因此，請求消息中的URL并沒有傳遞主機名（hostname）冷溃。但隨著虛擬主機技術(shù)的發(fā)展钱磅，在一臺物理服務器上可以存在多個虛擬主機（Multi-homed Web Servers），并且它們共享一個IP地址似枕。HTTP1.1的請求消息和響應消息都應支持Host頭域，且請求消息中如果沒有Host頭域會報告一個錯誤（400 Bad Request）凿歼。
連接方式轉(zhuǎn)變：HTTP 1.1支持長（持續(xù)）連接（PersistentConnection）和請求的流水線（Pipelining）處理褪迟，在一個TCP連接上可以傳送多個HTTP請求和響應冗恨，減少了建立和關閉連接的消耗和延遲，在HTTP1.1中默認開啟Connection： keep-alive味赃，一定程度上彌補了HTTP1.0每次請求都要創(chuàng)建連接的缺點掀抹。-
HTTP 2.0
- 頭部壓縮，雙方各自維護一個header的索引表心俗，使得不需要直接發(fā)送值傲武，通過發(fā)送key縮減頭部大小
- 多路復用，使用多個stream城榛，每個stream又分幀傳輸揪利，使得一個tcp連接能夠處理多個http請求
- 可以使用服務端推送
HTTP/1.x 缺陷：HTTP/1.x 實現(xiàn)簡單、以犧牲性能為代價的
- 客戶端需要使用多個連接才能實現(xiàn)并發(fā)和縮短延遲狠持；
- 不會壓縮請求和響應首部土童，從而導致不必要的網(wǎng)絡流量；
- 不支持有效的資源優(yōu)先級工坊，致使底層 TCP 連接的利用率低下。
二者區(qū)別：http1.1 -> http2.0
- HTTP2使用的是二進制傳送敢订，HTTP1.X是文本（字符串）傳送王污。二進制傳送的單位是幀和流。幀組成了流楚午，同時流還有流ID標識昭齐。
- HTTP2支持多路復用。因為有流ID矾柜，所以通過同一個http請求實現(xiàn)多個http請求傳輸變成了可能阱驾，可以通過流ID來標識究竟是哪個流從而定位到是哪個http請求。
- HTTP2頭部壓縮怪蔑。HTTP2通過gzip和compress壓縮頭部然后再發(fā)送里覆，同時客戶端和服務器端同時維護一張頭信息表，所有字段都記錄在這張表中缆瓣，這樣后面每次傳輸只需要傳輸表里面的索引ID就行喧枷，通過索引ID查詢表頭的值。
- HTTP2支持服務器推送弓坞。HTTP2支持在未經(jīng)客戶端許可的情況下隧甚，主動向客戶端推送內(nèi)容。
拓展： HTTP長連接/短連接?
在HTTP/1.0中默認使用短連接渡冻。也就是說戚扳，客戶端和服務器每進行一次HTTP操作，就建立一次連接族吻，任務結(jié)束就中斷連接帽借。當客戶端瀏覽器訪問的某個HTML或其他類型的Web頁中包含有其他的Web資源（如JavaScript文件珠增、圖像文件、CSS文件等）宜雀，每遇到這樣一個Web資源切平，瀏覽器就會重新建立一個HTTP會話。
從HTTP/1.1起辐董，默認使用長連接悴品，用以保持連接特性。使用長連接的HTTP協(xié)議简烘，會在響應頭加入這行代碼：Connection:keep-alive苔严。在使用長連接的情況下，當一個網(wǎng)頁打開完成后孤澎，客戶端和服務器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會關閉届氢，客戶端再次訪問這個服務器時，會繼續(xù)使用這一條已經(jīng)建立的連接覆旭。Keep-Alive不會永久保持連接退子，它有一個保持時間，可以在不同的服務器軟件（如Apache）中設定這個時間型将。實現(xiàn)長連接需要客戶端和服務端都支持長連接寂祥。
HTTP協(xié)議的長連接和短連接，實質(zhì)上是TCP協(xié)議的長連接和短連接七兜。
拓展：Host 是 HTTP 1.1 協(xié)議中新增的一個請求頭丸凭，主要用來實現(xiàn)虛擬主機技術(shù)。
虛擬主機（virtual hosting）即共享主機（shared web hosting）腕铸，可以利用虛擬技術(shù)（網(wǎng)絡空間技術(shù)惜犀，空分復用）把一臺完整的服務器分成若干網(wǎng)絡空間，每一臺網(wǎng)絡空間都擁有獨立域名和IP地址狠裹，具備完整的Internet服務器的功能虽界。因此可以在單一主機上運行多個網(wǎng)站或服務。
舉個栗子涛菠，有一臺 ip 地址為 61.135.169.125 的服務器浓恳，在這臺服務器上部署著谷歌、百度碗暗、淘寶的網(wǎng)站颈将。為什么我們訪問 https://www.google.com 時，看到的是 Google 的首頁而不是百度或者淘寶的首頁言疗？原因就是Host 請求頭決定著訪問哪個虛擬主機晴圾。
補充與總結(jié)：
HTTP 1.0
無狀態(tài)，無連接噪奄；
短連接：每次發(fā)送請求都要重新建立tcp請求死姚，即三次握手人乓，非常浪費性能；
無host頭域都毒，也就是http請求頭里的host色罚；
不允許斷點續(xù)傳，而且不能只傳輸對象的一部分账劲，要求傳輸整個對象戳护。
HTTP 1.1
長連接，流水線瀑焦，使用connection:keep-alive使用長連接腌且；
請求管道化；
增加緩存處理(新的字段如cache-control)榛瓮；
增加Host字段铺董，支持斷點傳輸?shù)龋?br> 由于長連接會給服務器造成壓力。
HTTP 2.0
二進制分幀禀晓；
多路復用(或連接共享)精续，使用多個stream，每個stream又分幀傳輸粹懒，使得一個tcp連接能夠處理多個http請求重付；
頭部壓縮，雙方各自維護一個header的索引表崎淳，使得不需要直接發(fā)送值，通過發(fā)送key縮減頭部大秀蛋选拣凹；
服務器推送(Sever push)。
HTTP 3.0
基于google的QUIC協(xié)議恨豁，而quic協(xié)議是使用udp實現(xiàn)的嚣镜；
減少了tcp三次握手時間，以及tls握手時間橘蜜；
解決了http 2.0中前一個stream丟包導致后一個stream被阻塞的問題菊匿；
優(yōu)化了重傳策略，重傳包和原包的編號不同计福，降低后續(xù)重傳計算的消耗跌捆；
連接遷移，不再用tcp四元組確定一個連接象颖，而是用一個64位隨機數(shù)來確定這個連接米苹；
更合適的流量控制酥泞。
HTTP和TCP是有狀態(tài)還是無狀態(tài)？兩者之間的聯(lián)系與區(qū)別？
-
HTTP無狀態(tài)協(xié)議赞庶，是指協(xié)議對于事務處理沒有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息宦焦，則它必須重傳须妻。這樣缺點是導致每次連接傳送的數(shù)據(jù)量增大（每次請求會傳輸大量重復信息）。優(yōu)點是煞额，在服務器不需要先前信息時它的應答就較快（點到為止思恐，解放了服務器）。
客戶端與服務器進行動態(tài)交互的 Web 應用程序出現(xiàn)之后立镶，HTTP 無狀態(tài)的特性嚴重阻礙了這些應用程序的實現(xiàn)壁袄，畢竟交互是需要承前啟后的，簡單的購物車程序也要知道用戶到底在之前選擇了什么商品媚媒。于是保持HTTP連接狀態(tài)的技術(shù)應運而生：
-
通過cookie：cookie可以保持登錄信息到用戶下次與服務器的會話嗜逻，即下次訪問同一網(wǎng)站時，用戶會發(fā)現(xiàn)不必輸入用戶名和密碼就已經(jīng)登錄了（當然缭召，不排除用戶手工刪除Cookie）栈顷。而還有一些Cookie在用戶退出會話的時候就被刪除了，這樣可以有效保護個人隱私嵌巷。
Cookies 最典型的應用是判定注冊用戶是否已經(jīng)登錄網(wǎng)站萄凤，用戶可能會得到提示，是否在下一次進入此網(wǎng)站時保留用戶信息以便簡化登錄手續(xù)搪哪，這些都是 Cookies 的功用靡努。另一個重要應用場合是“購物車”之類處理。用戶可能會在一段時間內(nèi)在同一家網(wǎng)站的不同頁面中選擇不同的商品晓折，這些信息都會寫入 Cookies惑朦，以便在最后付款時提取信息。
-
通過session會話保存：與cookie相對的解決方案漓概，session是通過服務器來保持狀態(tài)的漾月。當客戶端訪問服務器時，服務器根據(jù)需求設置 Session胃珍，將會話信息保存在服務器上梁肿，同時將標示 Session 的 SessionId 傳遞給客戶端瀏覽器，瀏覽器將這個 SessionId 保存在內(nèi)存中觅彰，我們稱之為無過期時間的 Cookie吩蔑。瀏覽器關閉后，這個 Cookie 就會被清掉填抬，它不會存在于用戶的 Cookie 臨時文件哥纫。
以后瀏覽器每次請求都會額外加上這個參數(shù)值，服務器會根據(jù)這個 SessionId，就能取得客戶端的數(shù)據(jù)信息蛀骇。
如果客戶端瀏覽器意外關閉厌秒，服務器保存的 Session 數(shù)據(jù)不是立即釋放，此時數(shù)據(jù)還會存在擅憔，只要我們知道那個 SessionId鸵闪，就可以繼續(xù)通過請求獲得此 Session 的信息，因為此時后臺的 Session 還存在暑诸，當然我們可以設置一個 Session 超時時間蚌讼，一旦超過規(guī)定時間沒有客戶端請求時，服務器就會清除對應 SessionId 的 Session 信息个榕。
-
TCP協(xié)議是一種有狀態(tài)協(xié)議篡石。具體見tcp/ip詳解。
聯(lián)系與區(qū)別：
Http協(xié)議是建立在TCP協(xié)議基礎之上的西采，當瀏覽器需要從服務器獲取網(wǎng)頁數(shù)據(jù)的時候凰萨，會發(fā)出一次Http請求。Http會通過TCP建立起一個到服務器的連接通道械馆，當本次請求需要的數(shù)據(jù)完畢后胖眷，Http會立即將TCP連接斷開，這個過程是很短的霹崎。所以Http連接是一種短連接珊搀，是一種無狀態(tài)的連接。
- TCP是傳輸層協(xié)議：負責數(shù)據(jù)的傳輸（定義傳輸數(shù)據(jù)內(nèi)容的規(guī)范）尾菇，包括定義端口境析、流量控制與數(shù)據(jù)校驗等。
- HTTP是應用層協(xié)議：負責請求和響應數(shù)據(jù)的封裝（定義的是數(shù)據(jù)傳輸與連接方式的規(guī)范）派诬，請求報文包括請求行（請求方法劳淆、url與http版本信息）、請求頭與請求體千埃；響應報文包括狀態(tài)行（http版本憔儿、狀態(tài)碼與對應的狀態(tài)信息）忆植、響應頭與響應體放可。
常用的HTTP方法有哪些？
一共有八種朝刊，HTTP1.0三種：
- GET： 用于請求訪問已經(jīng)被URI（統(tǒng)一資源標識符）識別的資源耀里，可以通過URL傳參給服務器
- POST：用于傳輸信息給服務器，主要功能與GET方法類似拾氓，但一般推薦使用POST方式冯挎。
- HEAD： 獲得報文首部，與GET方法類似咙鞍，只是不返回報文主體房官，一般用于驗證URI是否有效趾徽。
HTTP1.1增加了5種：
- PUT： 傳輸文件，報文主體中包含文件內(nèi)容翰守，保存到對應URI位置孵奶。
- DELETE：刪除文件，與PUT方法相反蜡峰，刪除對應URI位置的文件了袁。
- OPTIONS：查詢相應URI支持的HTTP方法。
- TRACE 和 CONNECT方法
ps: GET方法與POST方法的區(qū)別湿颅？
- GET和POST在本質(zhì)上沒有區(qū)別载绿，都是HTTP協(xié)議中的兩種發(fā)送請求的方法。而HTTP呢油航，是基于TCP/IP的關于數(shù)據(jù)如何在萬維網(wǎng)中如何通信的協(xié)議崭庸。GET/POST都是TCP鏈接。
- 功能上（應用場景）：get重點在從服務器上獲取資源劝堪，post重點在向服務器發(fā)送數(shù)據(jù)（更新服務器資源）冀自；
- REST服務角度上：GET是冪等的，即讀取同一個資源秒啦，總是得到相同的數(shù)據(jù)熬粗，而POST不是冪等的，因為每次請求對資源的改變并不是相同的余境；進一步地驻呐，GET不會改變服務器上的資源，而POST會對服務器資源進行改變芳来；
- http傳參類型：GET 請求由 url 觸發(fā)含末，想攜帶參數(shù)就只能在 url 后附加（GET只接受ASCII字符，POST沒有限制）即舌。POST 請求來自表單提交佣盒，表單數(shù)據(jù)被瀏覽器編碼到 HTTP 請求報文的請求體中。
- 大小限制：GET 長度受限于 url顽聂，而 url 的長度由瀏覽器和服務器決定肥惭。POST 沒有大小限制，起限制作用的是服務器的處理能力紊搪。
- 安全的角度：POST的安全性要比GET的安全性高蜜葱，因為GET請求提交的數(shù)據(jù)將明文出現(xiàn)在URL上，而且POST請求參數(shù)則被包裝到請求體中耀石，相對更安全牵囤。但無論 GET 還是 POST 都不安全，因為 HTTP 是明文協(xié)議。
- GET請求會被瀏覽器主動緩存揭鳞，而POST不會炕贵，除非手動設置。
- GET在瀏覽器回退時是無害的野崇，而POST會再次提交請求鲁驶。
HTTP請求報文與響應報文格式
請求報文包含三部分：請求行、請求頭部舞骆、空行和請求數(shù)據(jù)钥弯。
-
請求行：包含請求方法、URL督禽、HTTP版本信息
ps：空格不能缺省脆霎。- 請求方法（見上）：當然并不是所有的服務器都實現(xiàn)了所有的方法，部分方法即便支持狈惫，處于安全性的考慮也是不可用的
- 請求路徑：主機域名睛蛛、資源路徑
- 版本號格式：HTTP/主版本號.次版本號，如HTTP/1.0和HTTP/1.1
請求頭部：為請求報文添加了一些附加信息胧谈，由“名/值”對組成忆肾，每行一對，名和值之間使用冒號分隔菱肖，常見請求頭如下：
| 請求頭（名） | 說明 |
|---|---|
| Host | 接受請求的服務器地址客冈，可以是IP:端口號，也可以是域名 |
| User-Agent | 發(fā)送請求的應用程序名稱 |
| Connection | 指定與連接相關的屬性稳强，如Connection:Keep-Alive（使用長連接） |
| Accept-Charset | 通知服務端可以發(fā)送的編碼格式 |
| Accept-Encoding | 通知服務端可以發(fā)送的數(shù)據(jù)壓縮格式场仲，如gzip，deflate |
| Accept-Language | 通知服務端可以發(fā)送的語言退疫，如zh-CN（簡體中文） |
- 請求正文（可選）：比如GET請求就沒有請求正文
請求報文總結(jié)：
示例：
響應報文包含三部分：響應行（狀態(tài)行）渠缕，響應頭，和響應體
狀態(tài)行：包含HTTP版本褒繁、狀態(tài)碼亦鳞、對應的狀態(tài)信息，空格不能缺省棒坏。
-
響應頭部：
與請求頭部類似燕差，為響應報文添加了一些附加信息
| 響應頭（名） | |
|---|---|
| Server | 服務器應用程序軟件的名稱和版本 |
| Content-Type | 響應正文的類型（是圖片image還是二進制字符串） |
| Content-Length | 響應正文長度 |
| Content-Charset | 響應正文使用的編碼 |
| Content-Encoding | 響應正文使用的數(shù)據(jù)壓縮格式 |
| Content-Language | 響應正文使用的語言 |
- 響應正文（存放返回客戶端的信息），作用方式類似請求體俊抵。
響應報文總結(jié)
ps: URI谁不、URN和URL的區(qū)別
- URI全名為Uniform Resource Indentifier（統(tǒng)一資源標識）坐梯，用來唯一的標識一個資源徽诲，是一個通用的概念，URI由兩個主要的子集URL和URN組成
- URL全名為Uniform Resource Locator（統(tǒng)一資源定位），通過描述資源的位置來標識資源
- URN全名為Uniform Resource Name（統(tǒng)一資源命名）谎替，通過資源的名字來標識資源偷溺，與其所處的位置無關，這樣即使資源的位置發(fā)生變動钱贯，其URN也不會變化
HTTP規(guī)范將更通用的概念URI作為其資源標識符挫掏，但是實際上，HTTP應用程序處理的只是URI的URL子集
在Java的URI中秩命，一個URI實例可以代表絕對的尉共，也可以是相對的，只要它符合URI的語法規(guī)則弃锐。而URL類則不僅符合語義袄友，還包含了定位該資源的信息，因此它不能是相對的霹菊。
- 在Java類庫中剧蚣，URI類不包含任何訪問資源的方法，URI唯一的作用就是解析旋廷。
- 相反的是鸠按，URL類可以打開一個到達資源的流。
HTTP常見的狀態(tài)碼饶碘？
（1）1XX 提示信息目尖，表示目前是協(xié)議處理的中間狀態(tài)，還需要后續(xù)的操作扎运。
- 100 Continue ：表明到目前為止都很正常卑雁，客戶端可以繼續(xù)發(fā)送請求或者忽略這個響應。
（2）#2XX 成功绪囱，報文已被收到并正確處理
- 200 OK测蹲，響應成功
- 201 Created 該請求已成功，并因此創(chuàng)建了一個新的資源鬼吵。這通常是在POST請求扣甲，或是某些PUT請求之后返回的響應。
- 204 No Content ：請求已經(jīng)成功處理齿椅，但是返回的響應報文不包含實體的主體部分琉挖。一般在只需要從客戶端往服務器發(fā)送信息，而不需要返回數(shù)據(jù)時使用涣脚。
- 206 Partial Content ：表示客戶端進行了范圍請求示辈，響應報文包含由 Content-Range 指定范圍的實體內(nèi)容。
（3）#3XX 重定向遣蚀，資源位置發(fā)生變動矾麻，需要客戶端重新發(fā)送請求纱耻。
- 301 Moved Permanently ：永久性重定向
- 302 Found ：臨時性重定向，服務器返回的頭部信息中會包含一個 Location 字段险耀，內(nèi)容是重定向到的url弄喘。
- 303 See Other ：和 302 有著相同的功能，但是 303 明確要求客戶端應該采用 GET 方法獲取資源甩牺。
- 注：雖然 HTTP 協(xié)議規(guī)定 301蘑志、302 狀態(tài)下重定向時不允許把 POST 方法改成 GET 方法，但是大多數(shù)瀏覽器都會在 301贬派、302 和 303 狀態(tài)下的重定向把 POST 方法改成 GET 方法急但。
- 304 Not Modified ：如果請求報文首部包含一些條件，例如：If-Match搞乏，If-Modified-Since羊始，If-None-Match，If-Range查描，If-Unmodified-Since突委，如果不滿足條件，則服務器會返回 304 狀態(tài)碼冬三。
- 307 Temporary Redirect ：臨時重定向匀油，與 302 的含義類似，但是 307 要求瀏覽器不會把重定向請求的 POST 方法改成 GET 方法勾笆。
（4）#4XX 客戶端錯誤敌蚜，請求報文有誤，服務器無法處理窝爪。
- 400 Bad Request ：請求報文中存在語法錯誤弛车。
- 401 Unauthorized ：表示發(fā)送的請求需要有認證信息（BASIC 認證、DIGEST 認證）蒲每。如果之前已進行過一次請求纷跛，則表示用戶認證失敗。
- 403 Forbidden ：請求被拒絕邀杏。與401響應不同的是贫奠，身份驗證并不能提供任何幫助，而且這個請求也不應該被重復提交
- 404 Not Found： 請求失敗望蜡，請求所希望得到的資源未被在服務器上發(fā)現(xiàn)
（5）#5XX 服務器錯誤唤崭，服務器在處理請求時內(nèi)部發(fā)生錯誤。
- 500 Internal Server Error ：服務器正在執(zhí)行請求時發(fā)生錯誤脖律。
- 501 服務器不支持當前請求所需要的某個功能谢肾。當服務器無法識別請求的方法，并且無法支持其對任何資源的請求小泉。
- 503 Service Unavailable ：服務器暫時處于超負載或正在進行停機維護芦疏，現(xiàn)在無法處理請求冕杠。
HTTP長連接
數(shù)字簽名與報文鑒別
數(shù)字簽名：證明數(shù)據(jù)或身份的真實性，為什么進行數(shù)字簽名（的功能）眯分？
- 報文鑒別：接受者可以確認報文發(fā)送方的身份，即證明來源柒桑。
- 報文完整性：接受者可以確定報文沒有被篡改過弊决，防止偽造或篡改。
- 不可否認：發(fā)送者事后不能抵賴對報文的簽名魁淳，防止發(fā)送者否認簽名飘诗。
ps：報文鑒別：鑒別收到的報文確實是期望的發(fā)送方發(fā)送的，而不是別人偽造的界逛。數(shù)字簽名可以實現(xiàn)昆稿，但缺點是對較長報文進行簽名時需要長時間的運算。有一種相對簡單的報文鑒別方式息拜，即密碼散列函數(shù)溉潭，要找到兩個不同的報文，它們具有相同的密碼散列函數(shù)輸出少欺，在計算上是不可行的喳瓣。
使用散列函數(shù)進行報文鑒別：通信雙方共享一個密鑰 k ，發(fā)送方生成報文 m赞别，用 k 級聯(lián) m 生成 m+k畏陕，并使用 SHA-1 或 MD5 這樣的散列函數(shù)計算 m+k 的散列值 h，這個散列值就被稱為報文鑒別碼 MAC仿滔。發(fā)送方會利用 MAC 生成擴展報文并發(fā)送給接收方惠毁。接收方收到后，由于知道共享密鑰 k崎页，因此可以計算出 MAC鞠绰，如果和 h 相等就可以得出一切正常的結(jié)論。
數(shù)字簽名實現(xiàn)方式 : 數(shù)字簽名算法很多 , 公鑰算法 是最簡單的算法 , 即 發(fā)送者 使用 私鑰加密數(shù)據(jù) , 接收者 使用 對應的公鑰 解密數(shù)據(jù) ;
HTTP優(yōu)化方案飒焦？
-
TCP復用：TCP連接復用是將多個客戶端的HTTP請求復用到一個服務器端TCP連接上洞豁，而HTTP復用則是一個客戶端的多個HTTP請求通過一個TCP連接進行處理。前者是負載均衡設備的獨特功能荒给；而后者是HTTP 1.1協(xié)議所支持的新功能丈挟，目前被大多數(shù)瀏覽器所支持。 -
內(nèi)容緩存：將經(jīng)常用到的內(nèi)容進行緩存起來志电，那么客戶端就可以直接在內(nèi)存中獲取相應的數(shù)據(jù)了曙咽。 -
壓縮：將文本數(shù)據(jù)進行壓縮，減少帶寬 -
SSL加速（SSL Acceleration）：使用SSL協(xié)議對HTTP協(xié)議進行加密挑辆，在通道內(nèi)加密并加速 -
TCP緩沖：通過采用TCP緩沖技術(shù)例朱，可以提高服務器端響應時間和處理效率孝情，減少由于通信鏈路問題給服務器造成的連接負擔。
HTTPS基本知識洒嗤？
HTTPS是一種應用層協(xié)議箫荡，本質(zhì)上來說它是HTTP協(xié)議的一種變種。HTTPS比HTTP協(xié)議安全渔隶，因為HTTP是明文傳輸羔挡，而HTTPS是加密傳輸，加密過程中使用了三種加密手段间唉，分別是證書绞灼，對稱加密和非對稱加密。HTTPS相比于HTTP多了一層SSL/TSL呈野，其構(gòu)造如下：
- 證書加密：服務器在使用證書加密之前需要去證書頒發(fā)機構(gòu)申請該服務器的證書低矮，在HTTPS的請求過程服務器端將會把本服務器的證書發(fā)送給客戶端，客戶端進行證書驗證被冒，以此來驗證服務器的身份（驗證交互雙方的正確性）军掂。
- 對稱加密：HTTPS的請求中，客戶端和服務器之間的通信的數(shù)據(jù)是通過對稱加密算法進行加密的昨悼。對稱加密良姆，即在加密和解密的過程使用同一個私鑰進行加密以及解密，而且對稱加密算法是公開的幔戏，所以該私鑰是不能夠泄漏的玛追，一旦泄漏，對稱加密形同虛設闲延。例如：A第一次加密傳輸給B是安全的痊剖，后邊A使用相同的私鑰進行加密，就可能存在私鑰泄露垒玲。適用于大量數(shù)據(jù)傳輸陆馁，速度快。
- 非對稱加密：HTTPS的請求中也使用了非對稱加密算法合愈。非對稱加密叮贩，加密和解密過程使用不同的密鑰，一個公鑰佛析，對外公開益老，一個私鑰，僅是解密端擁有寸莫。由于公鑰和私鑰是分開的捺萌，非對稱加密算法安全級別高，加密密文長度有限制膘茎，適用于對少量數(shù)據(jù)進行加密桃纯，速度較慢酷誓。
HTTPS請求執(zhí)行的流程
- HTTPS作為一種安全的應用層協(xié)議，它使用了以上三種加密手段态坦，我們現(xiàn)在嘗試分析其加密的思想盐数。
- 首先，數(shù)據(jù)正文一般數(shù)據(jù)量較大伞梯，適用于對稱加密玫氢，因為對稱加密速度快，適應于大量數(shù)據(jù)加密壮锻，但是安全級別低琐旁，其中對稱加密的私鑰需要在網(wǎng)絡中傳輸涮阔，容易被盜炔滦濉；
- 其次敬特，正因為非對稱機密私鑰易被盜取掰邢，所以我們需要對這個私鑰進行加密，而且安全級別要求高伟阔，所以這個可以用非對稱加密進行加密辣之，原因是對稱加密的私鑰數(shù)據(jù)量小，非對稱加密可以提供高安全級別和高響應速度皱炉。
- 最后怀估，由于非對稱加密的公鑰可以在網(wǎng)絡中傳輸，如何保證公鑰傳送到給正確的一方合搅，這個時候使用了證書來驗證多搀。證書不是保證公鑰的安全性，而是驗證正確的交互方灾部。可以使用下圖進行說明：
上述過程就是兩次HTTP請求康铭，其詳細過程如下：
- 客戶端想服務器發(fā)起HTTPS的請求，連接到服務器的443端口（在此之前赌髓，服務器要去證書頒發(fā)機構(gòu)申請證書）从藤；
- 服務器將非對稱加密的公鑰傳遞給客戶端，以證書的形式回傳到客戶端锁蠕；
- 客戶端接受到該公鑰進行驗證夷野，就是驗證2中證書，如果有問題荣倾，則HTTPS請求無法繼續(xù)扫责；如果沒有問題，則上述公鑰是合格的逃呼。（第一次HTTP請求）客戶端隨機生成client key（客戶端私鑰）鳖孤，使用前面的公鑰對client key進行非對稱加密者娱；
- 進行二次HTTP請求，將加密之后的client key傳遞給服務器苏揣；
- 服務器使用私鑰進行解密（注意私鑰是存儲在服務器）黄鳍，得到client key，使用client key對數(shù)據(jù)進行對稱加密平匈；
- 將對稱加密的數(shù)據(jù)傳遞給客戶端框沟，客戶端使用對稱解密得到服務器發(fā)送的數(shù)據(jù)，完成第二次HTTP請求增炭。
拓展：SSL加密過程（大致分三步）
- 客戶端向服務器端索要并驗證證書合法性忍燥；
- 雙方協(xié)商生成“會話密鑰”；對稱密鑰
- 雙方采用“會話密鑰”進行加密通信隙姿；
瀏覽器（客戶端）如何驗證證書的合法性梅垄？
- 驗證域名、有效期等信息是否正確：證書上都有包含這些信息输玷，比較容易完成驗證队丝；
- 判斷證書來源是否合法：每份簽發(fā)證書都可以根據(jù)驗證鏈查找到對應的根證書，操作系統(tǒng)欲鹏、瀏覽器會在本地存儲權(quán)威機構(gòu)的根證書机久，利用本地根證書可以對對應機構(gòu)簽發(fā)證書完成來源驗證
- 判斷證書是否被篡改：需要與 CA 服務器進行校驗；
- 判斷證書是否已吊銷：通過CRL（Certificate Revocation List 證書注銷列表）和 OCSP（Online Certificate Status Protocol 在線證書狀態(tài)協(xié)議）實現(xiàn)赔嚎，其中 OCSP 可用于第3步中以減少與 CA 服務器的交互膘盖，提高驗證效率。
ps: HTTP缺點尤误，與HTTPS的區(qū)別侠畔？
HTTP的缺點：
- 被竊聽：通信使用明文不加密，內(nèi)容可能被竊聽
- 被偽裝：不驗證通信方身份袄膏，可能遭到偽裝
- 被篡改：無法驗證報文完整性践图，可能被篡改
兩者之間的區(qū)別：
- 傳輸信息的安全性不同：HTTP協(xié)議運行在TCP之上，所有傳輸?shù)膬?nèi)容都是明文沉馆；HTTPS運行在SSL/TLS之上的加密傳輸協(xié)議码党，所有傳輸?shù)膬?nèi)容都經(jīng)過加密的。
- 使用端口不同：HTTP默認使用80端口斥黑，HTTPS默認使用443端口揖盘。
- CA證書：HTTPS請求的過程需要CA證書要驗證身份以保證客戶端請求到服務器端之后，傳回的響應是來自于服務器端锌奴，而HTTP則不需要CA證書兽狭；
- HTTPS = HTTP + 加密 + 認證 + 完整性保護
Tomcat底層原理（了解）
Tomcat通過監(jiān)聽端口，獲取數(shù)據(jù)，然后解析數(shù)據(jù)箕慧，根據(jù)請求url找到對應的Servlet實現(xiàn)類服球，然后通過反射執(zhí)行Servlet實現(xiàn)類中的方法。
參考鳴謝：
https://blog.csdn.net/a19881029/article/details/14002273
https://blog.51cto.com/linpeisong/1746151
http://www.reibang.com/p/a6d086a3997d
https://blog.csdn.net/seujava_er/article/details/90018326
