11、HTTP的不同版本的優(yōu)點：

• 1.1相對于1.0：

• 1. 支持長連接：HTTP 1.0需要使用keep-alive參數(shù)來告知服務器端要建立一個長連接，而HTTP1.1默認支持長連接。
• 2. 增加了host域：在HTTP1.0中認為每臺服務器都綁定一個唯一的IP地址，因此，請求消息中的URL并沒有傳遞主機名（hostname）。但隨著虛擬主機技術的發(fā)展，在一臺物理服務器上可以存在多個虛擬主機（Multi-homed Web Servers），并且它們共享一個IP地址。 HTTP1.1的請求消息和響應消息都應支持Host頭域，且請求消息中如果沒有Host頭域會報告一個錯誤（400 Bad Request）。此外，服務器應該接受以絕對路徑標記的資源請求。
• 3. 帶寬優(yōu)化（range：支持斷點重傳、請求數(shù)據(jù)的一部分）：HTTP/1.0中，存在一些浪費帶寬的現(xiàn)象，例如客戶端只是需要某個對象的一部分，而服務器卻將整個對象送過來了。例如，客戶端只需要顯示一個文檔的部分內容，又比如下載大文件時需要支持斷點續(xù)傳功能，而不是在發(fā)生斷連后不得不重新下載完整的包。HTTP/1.1中在請求消息中引入了range頭域，它允許只請求資源的某個部分。在響應消息中Content-Range頭域聲明了返回的這部分對象的偏移值和長度。如果服務器相應地返回了對象所請求范圍的內容，則響應碼為206（Partial Content），它可以防止Cache將響應誤以為是完整的一個對象。
     另外一種情況是請求消息中如果包含比較大的實體內容，但不確定服務器是否能夠接收該請求（如是否有權限），此時若貿然發(fā)出帶實體的請求，如果被拒絕也會浪費帶寬。HTTP/1.1加入了一個新的狀態(tài)碼100（Continue）?？蛻舳耸孪劝l(fā)送一個只帶頭域的請求，如果服務器因為權限拒絕了請求，就回送響應碼401（Unauthorized）；如果服務器接收此請求就回送響應碼100，客戶端就可以繼續(xù)發(fā)送帶實體的完整請求了。注意，HTTP/1.0的客戶端不支持100響應碼。但可以讓客戶端在請求消息中加入Expect頭域，并將它的值設置為100-continue。

• HTTP2.0的核心優(yōu)點有哪些呢?

• 1、采用二進制格式傳輸數(shù)據(jù)，而非文本格式，二進制格式在協(xié)議的解析和優(yōu)化擴展上帶來更多的優(yōu)勢和可能
• 2、對消息頭進行壓縮傳輸，能夠節(jié)省消息頭占用的網絡的流量，而 http1.1每次請求，都會攜帶大量冗余頭信息，浪費了很多帶寬資源，頭壓縮能夠很好的解決該問題
• 3、多路復用，就是多個請求都是通過一個TCP連接并發(fā)完成，http1.1雖然通過pipeline也能并發(fā)請求，但是多個請求之間的響應會被阻塞的，所以pipeline 至今也沒有被普及應用，而 http2.0做到了真正的并發(fā)請求，同時，流還支持優(yōu)先級和流量控制
• 4、服務器推送，服務端能夠更快的把資源推送給客戶端，例如服務端可以主動把.JS和CSS文件推送給客戶端，而不需要客戶端解析HTML再發(fā)送這些請求，當客戶端需要的時候，它已經在客戶端了

• HTTP 2.0的缺點：

• HTTP/2 使用了多路復用，一般來說同一域名下只需要使用一個 TCP 連接。但當這個連接中出現(xiàn)了丟包的情況，那就會導致 HTTP/2 的表現(xiàn)情況反倒不如 HTTP/1 了。因為在出現(xiàn)丟包的情況下，整個 TCP 都要開始等待重傳，也就導致了后面的所有數(shù)據(jù)都被阻塞了。但是對于 HTTP/1.1 來說，可以開啟多個 TCP 連接，出現(xiàn)這種情況反到只會影響其中一個連接，剩余的 TCP 連接還可以正常傳輸數(shù)據(jù)。

• HTTP1.0與HTTP1.1的區(qū)別

關于HTTP加密和HTTP3.0：

• HTTP加上加密處理、認證、完整性保護后即是HTTPS
• HTTPS 協(xié)議的主要功能基本依賴于 TLS/SSL 協(xié)議，TLS/SSL 的功能實現(xiàn)主要依賴于三類基本算法：散列函數(shù) 、對稱加密和非對稱加密，其利用非對稱加密實現(xiàn)身份認證和密鑰協(xié)商，對稱加密算法采用協(xié)商的密鑰對數(shù)據(jù)加密，基于散列函數(shù)驗證信息的完整性。
• 非對稱加密的特點是信息傳輸一對多，服務器只需要維持一個私鑰就能夠和多個客戶端進行加密通信，但服務器發(fā)出的信息能夠被所有的客戶端解密，且該算法的計算復雜，加密速度慢。
• 瀏覽器如何通過域名去查詢 URL 對應的 IP 呢

• 瀏覽器緩存：瀏覽器會按照一定的頻率緩存 DNS 記錄。
• 操作系統(tǒng)緩存：如果瀏覽器緩存中找不到需要的 DNS 記錄，那就去操作系統(tǒng)中找。
• 路由緩存：路由器也有 DNS 緩存。
• ISP 的 DNS 服務器：ISP 是互聯(lián)網服務提供商(Internet Service Provider)的簡稱，ISP 有專門的 DNS 服務器應對 DNS 查詢請求。
• 根服務器：ISP 的 DNS 服務器還找不到的話，它就會向根服務器發(fā)出請求，進行遞歸查詢（DNS 服務器先問根域名服務器.com 域名服務器的 IP 地址，然后再問.baidu 域名服務器，依次類推）

• 請求頭部通知服務器有關于客戶端請求的信息。它包含許多有關的客戶端環(huán)境和請求正文的有用信息。其中比如：Host，表示主機名，虛擬主機；Connection,HTTP/1.1 增加的，使用 keepalive，即持久連接，一個連接可以發(fā)多個請求；User-Agent，請求發(fā)出者，兼容性以及定制化需求。
• 網際協(xié)議（Internet Protocol，IP）： 一個無連接的協(xié)議， 負責將數(shù)據(jù)報從源結點轉發(fā)到目的結點。 IP協(xié)議通過對每個數(shù)據(jù)報中都有的源地址和目的地址進行分析，然后進行路由選擇（即選擇一條到達目標的最佳路徑），最后再轉發(fā)到目的地。需要注意的是：IP協(xié)議只是負責對數(shù)據(jù)進行轉發(fā)，并不對數(shù)據(jù)進行檢查。也就是說，它不負責數(shù)據(jù)的可靠性，這樣設計的主要目的是提高IP協(xié)議傳送和轉發(fā)數(shù)據(jù)的效率；

• Http的特點

1.簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、PUT、DELETE、POST。每種方法規(guī)定了客戶與服務器聯(lián)系的類型不同。由于HTTP協(xié)議簡單，使得HTTP服務器的程序規(guī)模小，因而通信速度很快。
2.靈活：HTTP允許傳輸任意類型的數(shù)據(jù)對象。
3.無連接：無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，并收到客戶的應答后，即斷開連接。采用這種方式可以節(jié)省傳輸時間。
4.無狀態(tài)：HTTP協(xié)議是無狀態(tài)的，HTTP 協(xié)議自身不對請求和響應之間的通信狀態(tài)進行保存。任何兩次請求之間都沒有依賴關系。直觀地說，就是每個請求都是獨立的，與前面的請求和后面的請求都是沒有直接聯(lián)系的。協(xié)議本身并不保留之前一切的請求或 響應報文的信息。這是為了更快地處理大量事務，確保協(xié)議的可伸縮性，而特意把 HTTP 協(xié)議設計成如此簡單的。

• HTTP/1.x的缺陷

• 連接無法復用：連接無法復用會導致每次請求都經歷三次握手和慢啟動。三次握手在高延遲的場景下影響較明顯，慢啟動則對大量小文件請求影響較大（沒有達到最大窗口請求就被終止）。
• HTTP/1.0傳輸數(shù)據(jù)時，每次都需要重新建立連接，增加延遲。
• HTTP/1.1雖然加入keep-alive可以復用一部分連接，但域名分片等情況下仍然需要建立多個connection，耗費資源，給服務器帶來性能壓力。
• Head-Of-Line Blocking（HOLB）：導致帶寬無法被充分利用，以及后續(xù)健康請求被阻塞。 是指一系列包（package）因為第一個包被阻塞；當頁面中需要請求很多資源的時候，HOLB（隊頭阻塞）會導致在達到最大請求數(shù)量時，剩余的資源需要等待其他資源請求完成后才能發(fā)起請求。
• HTTP 1.0：下個請求必須在前一個請求返回后才能發(fā)出，request-response對按序發(fā)生。顯然，如果某個請求長時間沒有返回，那么接下來的請求就全部阻塞了。
• HTTP 1.1：嘗試使用 pipeling 來解決，即瀏覽器可以一次性發(fā)出多個請求（同個域名，同一條 TCP 鏈接）。但 pipeling 要求返回是按序的，那么前一個請求如果很耗時（比如處理大圖片），那么后面的請求即使服務器已經處理完，仍會等待前面的請求處理完才開始按序返回。所以，pipeling 只部分解決了 HOLB。
• 協(xié)議開銷大： HTTP1.x在使用時，header里攜帶的內容過大，在一定程度上增加了傳輸?shù)某杀?，并且每次請求header基本不怎么變化，尤其在移動端增加用戶流量。
• 安全因素：HTTP1.x在傳輸數(shù)據(jù)時，所有傳輸?shù)膬热荻际敲魑?，客戶端和服務器端都無法驗證對方的身份，這在一定程度上無法保證數(shù)據(jù)的安全性

• HTTP3基于udp進行實現(xiàn):

  
  

• QUIC新功能:

• 機制一：自定義連接機制
  一條tcp連接是由四元組標識的，分別是源ip、源端口、目的端口，一旦一個元素發(fā)生變化時，就會斷開重連，重新連接。在次進行三次握手，導致一定的延時
  在TCP是沒有辦法的，但是基于UDP，就可以在QUIC自己的邏輯里面維護連接的機制，不再以四元組標識，而是以一個64
  位的隨機數(shù)作為ID來標識，而且UDP是無連接的，所以當ip或者端口變化的時候，只要ID不變，就不需要重新建立連接
• 機制二：自定義重傳機制
  tcp為了保證可靠性，通過使用序號和應答機制，來解決順序問題和丟包問題
  任何一個序號的包發(fā)過去，都要在一定的時間內得到應答，否則一旦超時，就會重發(fā)這個序號的包，通過自適應重傳算法（通過采樣往返時間RTT不斷調整）。但是，在TCP里面超時的采樣存在不準確的問題。例如發(fā)送一個包，序號100，發(fā)現(xiàn)沒有返回，于是在發(fā)送一個100，過一陣返回ACK101.客戶端收到了，但是往返的時間是多少，沒法計算。是ACK到達的時候減去第一還是第二。
  QUIC也有個序列號，是遞增的，任何宇哥序列號的包只發(fā)送一次，下次就要加1，那樣就計算可以準確了但是有一個問題，就是怎么知道包100和包101發(fā)送的是同樣的內容呢？quic定義了一個offset概念。QUIC既然是面向連接的，也就像TCP一樣，是一個數(shù)據(jù)流，發(fā)送的數(shù)據(jù)在這個數(shù)據(jù)流里面有個偏移量offset，可以通過offset查看數(shù)據(jù)發(fā)送到了那里，這樣只有這個offset的包沒有來，就要重發(fā)。如果來了，按照offset拼接，還是能夠拼成一個流。
• 機制三： 無阻塞的多路復用
  有了自定義的連接和重傳機制，就可以解決上面HTTP2.0的多路復用問題
  同HTTP2.0一樣，同一條 QUIC連接上可以創(chuàng)建多個stream，來發(fā)送多個HTTP請求，但是，QUIC是基于UDP的，一個連接上的多個stream之間沒有依賴。這樣，假如stream2丟了一個UDP包，后面跟著stream3的一個UDP包，雖然stream2的那個包需要重新傳，但是stream3的包無需等待，就可以發(fā)給用戶。
• 機制四：自定義流量控制
  TCP的流量控制是通過滑動窗口協(xié)議。QUIC的流量控制也是通過window_update，來告訴對端它可以接受的字節(jié)數(shù)。但是QUIC的窗口是適應自己的多路復用機制的，不但在一個連接上控制窗口，還在一個連接中的每個steam控制窗口。
  在TCP協(xié)議中，接收端的窗口的起始點是下一個要接收并且ACK的包，即便后來的包都到了，放在緩存里面，窗口也不能右移，因為TCP的ACK機制是基于序列號的累計應答，一旦ACK了一個序列號，就說明前面的都到了，所以是要前面的沒到，后面的到了也不能ACK,就會導致后面的到了，也有可能超時重傳，浪費帶寬
  QUIC的ACK是基于offset的，每個offset的包來了，進了緩存，就可以應答，應答后就不會重發(fā)，中間的空檔會等待到來或者重發(fā)，而窗口的起始位置為當前收到的最大offset，從這個offset到當前的stream所能容納的最大緩存，是真正的窗口的大小，顯然，那樣更加準確。

• HTTP2.0雖然性能已經不錯了，還有什么不足嗎?

建立連接時間長(本質上是TCP的問題)
隊頭阻塞問題
移動互聯(lián)網領域表現(xiàn)不佳(弱網環(huán)境)

• 圖解|為什么HTTP3.0使用UDP協(xié)議
• HTTP3.0(QUIC的實現(xiàn)機制)
• udp怎么實現(xiàn)tcp：

• 添加seq/ack機制，確保數(shù)據(jù)發(fā)送到對端
• 添加發(fā)送和接收緩沖區(qū)，主要是用戶超時重傳
• 添加超時重傳機制 ：發(fā)送端發(fā)送數(shù)據(jù)時，生成一個隨機seq=x，然后每一片按照數(shù)據(jù)大小分配seq。數(shù)據(jù)到達接收端后接收端放入緩存，并發(fā)送一個ack=x的包，表示對方已經收到了數(shù)據(jù)。發(fā)送端收到了ack包后，刪除緩沖區(qū)對應的數(shù)據(jù)。時間到后，定時任務檢查是否需要重傳數(shù)據(jù)。