HTTP

HTTP：超文本傳輸協(xié)議（HTTP，HyperText Transfer Protocol）是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議。設(shè)計 HTTP 最初的目的是為了提供一種發(fā)布和接收 HTML 頁面的方法。它可以使瀏覽器更加高效。HTTP 協(xié)議是以明文方式發(fā)送信息，如果黑客截取了 Web 瀏覽器和服務(wù)器之間的傳輸報文，就可以直接獲得其中的信息。

隊頭阻塞/多路復(fù)用

HTTP/1.1 和 HTTP/2 都存在隊頭阻塞問題（Head of line blocking），那什么是隊頭阻塞呢？

TCP 是個面向連接的協(xié)議，即發(fā)送請求后需要收到 ACK 消息，以確認(rèn)對方已接收到數(shù)據(jù)。如果每次請求都要在收到上次請求的 ACK 消息后再請求，那么效率無疑很低。后來 HTTP/1.1 提出了 Pipelining 技術(shù)，允許一個 TCP 連接同時發(fā)送多個請求，這樣就大大提升了傳輸效率。

在這個背景下，下面就來談 HTTP/1.1 的隊頭阻塞。下圖中，一個 TCP 連接同時傳輸 10 個請求，其中第 1、2、3 個請求已被客戶端接收，但第 4 個請求丟失，那么后面第 5 - 10 個請求都被阻塞，需要等第 4 個請求處理完畢才能被處理，這樣就浪費了帶寬資源。

因此，HTTP 一般又允許每個主機建立 6 個 TCP 連接，這樣可以更加充分地利用帶寬資源，但每個連接中隊頭阻塞的問題還是存在。

HTTP/2 的多路復(fù)用解決了上述的隊頭阻塞問題。不像 HTTP/1.1 中只有上一個請求的所有數(shù)據(jù)包被傳輸完畢下一個請求的數(shù)據(jù)包才可以被傳輸，HTTP/2 中每個請求都被拆分成多個 Frame 通過一條 TCP 連接同時被傳輸，這樣即使一個請求被阻塞，也不會影響其他的請求。如下圖所示，不同顏色代表不同的請求，相同顏色的色塊代表請求被切分的 Frame。

HTTP/2 雖然可以解決“請求”這個粒度的阻塞，但 HTTP/2 的基礎(chǔ) TCP 協(xié)議本身卻也存在著隊頭阻塞的問題。HTTP/2 的每個請求都會被拆分成多個 Frame，不同請求的 Frame 組合成 Stream，Stream 是 TCP 上的邏輯傳輸單元，這樣 HTTP/2 就達(dá)到了一條連接同時發(fā)送多條請求的目標(biāo)，這就是多路復(fù)用的原理。我們看一個例子，在一條 TCP 連接上同時發(fā)送 4 個 Stream，其中 Stream1 已正確送達(dá)，Stream2 中的第 3 個 Frame 丟失，TCP 處理數(shù)據(jù)時有嚴(yán)格的前后順序，先發(fā)送的 Frame 要先被處理，這樣就會要求發(fā)送方重新發(fā)送第 3 個 Frame，Stream3 和 Stream4 雖然已到達(dá)但卻不能被處理，那么這時整條連接都被阻塞。

參考文章
HTTP/3 來了 ！未來可期

HTTPS

HTTPS是在HTTP上建立SSL加密層，并對傳輸數(shù)據(jù)進(jìn)行加密，是HTTP協(xié)議的安全版。

HTTPS協(xié)議的主要作用：
1）一種是建立一個信息安全通道，來保證數(shù)據(jù)傳輸?shù)陌踩?br> 2）另一種就是確認(rèn)網(wǎng)站的真實性。

HTTPS并非是應(yīng)用層的一種新協(xié)議。只是HTTP通信接口部分用SSL和TLS協(xié)議代替而已。

通常，HTTP直接和TCP通信。當(dāng)使用SSL時，則演變成先和SSL通信，再由SSL和TCP通信了。簡言之，所謂HTTPS，其實就是身披SSL協(xié)議這層外殼的HTTP。

HTTPS優(yōu)缺點

優(yōu)點：

• 使用HTTPS協(xié)議可認(rèn)證用戶和服務(wù)器，確保數(shù)據(jù)發(fā)送到正確的客戶機和服務(wù)器；
• HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，要比http協(xié)議安全，可防止數(shù)據(jù)在傳輸過程中不被竊取、改變，確保數(shù)據(jù)的完整性。
• HTTPS是現(xiàn)行架構(gòu)下最安全的解決方案，雖然不是絕對安全，但它大幅增加了中間人攻擊的成本。

缺點：

• HTTPS協(xié)議握手階段比較費時，會使頁面的加載時間延長近50%，增加10%到20%的耗電；
• HTTPS連接緩存不如HTTP高效，會增加數(shù)據(jù)開銷和功耗，甚至已有的安全措施也會因此而受到影響；
• SSL證書需要錢，功能越強大的證書費用越高，個人網(wǎng)站、小網(wǎng)站沒有必要一般不會用。
• SSL證書通常需要綁定IP，不能在同一IP上綁定多個域名，IPv4資源不可能支撐這個消耗。
• HTTPS協(xié)議的加密范圍也比較有限，在黑客攻擊、拒絕服務(wù)攻擊、服務(wù)器劫持等方面幾乎起不到什么作用。最關(guān)鍵的，SSL證書的信用鏈體系并不安全，特別是在某些國家可以控制CA根證書的情況下，中間人攻擊一樣可行。

HTTP和HTTPS區(qū)別

• HTTP 的連接很簡單，是無狀態(tài)的。HTTPS 協(xié)議是由 SSL+HTTP 協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比 HTTP 協(xié)議安全。
• HTTPS比HTTP更加安全，對搜索引擎更友好，利于SEO,谷歌、百度優(yōu)先索引HTTPS網(wǎng)頁;
• HTTPS需要用到ca的SSL證書，而HTTP不用;
• HTTPS標(biāo)準(zhǔn)端口443，HTTP標(biāo)準(zhǔn)端口80;
• HTTPS基于傳輸層，HTTP基于應(yīng)用層;
• HTTPS在瀏覽器顯示綠色安全鎖，HTTP沒有顯示;

http狀態(tài)碼

客戶端的每一次請求，服務(wù)器都必須給出回應(yīng)?；貞?yīng)包括 HTTP 狀態(tài)碼和數(shù)據(jù)兩部分。

HTTP 狀態(tài)碼就是一個三位數(shù)，分成五個類別。

• 1xx：相關(guān)信息
• 2xx：操作成功
• 3xx：重定向
• 4xx：客戶端錯誤
• 5xx：服務(wù)器錯誤

這五大類總共包含100多種狀態(tài)碼，覆蓋了絕大部分可能遇到的情況。每一種狀態(tài)碼都有標(biāo)準(zhǔn)的（或者約定的）解釋，客戶端只需查看狀態(tài)碼，就可以判斷出發(fā)生了什么情況，所以服務(wù)器應(yīng)該返回盡可能精確的狀態(tài)碼。

API 不需要1xx狀態(tài)碼，下面介紹其他四類狀態(tài)碼的精確含義。

2XX狀態(tài)碼

200狀態(tài)碼表示操作成功，但是不同的方法可以返回更精確的狀態(tài)碼。

• GET: 200 OK
• POST: 201 Created
• PUT: 200 OK
• PATCH: 200 OK
• DELETE: 204 No Content

POST返回201狀態(tài)碼，表示生成了新的資源；DELETE返回204狀態(tài)碼，表示資源已經(jīng)不存在。

此外，202 Accepted狀態(tài)碼表示服務(wù)器已經(jīng)收到請求，但還未進(jìn)行處理，會在未來再處理，通常用于異步操作。下面是一個例子。

HTTP/1.1 202 Accepted

{
  "task": {
    "href": "/api/company/job-management/jobs/2130040",
    "id": "2130040"
  }
}

3xx 狀態(tài)碼

API 用不到301狀態(tài)碼（永久重定向）和302狀態(tài)碼（暫時重定向，307也是這個含義），因為它們可以由應(yīng)用級別返回，瀏覽器會直接跳轉(zhuǎn)，API 級別可以不考慮這兩種情況。

API 用到的3xx狀態(tài)碼，主要是303 See Other，表示參考另一個 URL。它與302和307的含義一樣，也是"暫時重定向"，區(qū)別在于302和307用于GET請求，而303用于POST、PUT和DELETE請求。收到303以后，瀏覽器不會自動跳轉(zhuǎn)，而會讓用戶自己決定下一步怎么辦。

下面是一個例子。

HTTP/1.1 303 See Other
Location: /api/orders/12345

4xx 狀態(tài)碼

4xx狀態(tài)碼表示客戶端錯誤，主要有下面幾種。

• 400 Bad Request： 服務(wù)器不理解客戶端的請求，未做任何處理。
• 401 Unauthorized： 用戶未提供身份驗證憑據(jù)，或者沒有通過身份驗證。
• 403 Forbidden： 用戶通過了身份驗證，但是不具有訪問資源所需的權(quán)限。
• 404 Not Found： 所請求的資源不存在，或不可用。
• 405 Method Not Allowed： 用戶已經(jīng)通過身份驗證，但是所用的 HTTP 方法不在他的權(quán)限之內(nèi)。
• 410 Gone： 所請求的資源已從這個地址轉(zhuǎn)移，不再可用。
• 415 Unsupported Media Type： 客戶端要求的返回格式不支持。比如，API 只能返回 JSON 格式，但是客戶端要求返回 XML 格式。
• 422 Unprocessable Entity ： 客戶端上傳的附件無法處理，導(dǎo)致請求失敗。
• 429 Too Many Requests： 客戶端的請求次數(shù)超過限額。

5xx 狀態(tài)碼

5xx狀態(tài)碼表示服務(wù)端錯誤。一般來說，API 不會向用戶透露服務(wù)器的詳細(xì)信息，所以只要兩個狀態(tài)碼就夠了。

• 500 Internal Server Error： 客戶端請求有效，服務(wù)器處理時發(fā)生了意外。
• 503 Service Unavailable： 服務(wù)器無法處理請求，一般用于網(wǎng)站維護(hù)狀態(tài)。

TCP可靠性保證機制

• 檢驗和
• 序列號
• 確認(rèn)應(yīng)答機制（ACK）
• 超時重傳機制
• 連接管理機制（三次握手四次揮手）
• 流量控制
• 擁塞控制

相關(guān)文章
TCP可靠性的保證機制總結(jié)

瀏覽從輸入網(wǎng)址到回車發(fā)生了什么

當(dāng)用戶訪問頁面時，瀏覽器需要獲取用戶請求內(nèi)容，這個過程主要涉及瀏覽器網(wǎng)絡(luò)模塊：

• 首先會進(jìn)行 url 解析，根據(jù) dns 服務(wù)器根據(jù)輸入的域名查找對應(yīng)IP，然后向該IP地址發(fā)起請求；
• 瀏覽器獲得并解析服務(wù)器的返回內(nèi)容(HTTP response)；
• 瀏覽器加載HTML文件及文件內(nèi)包含的外部引用文件及圖片，多媒體等資源。

通過網(wǎng)絡(luò)模塊加載到HTML文件后渲染引擎渲染流程如下，這也通常被稱作關(guān)鍵渲染路徑（Critical Rendering Path）：

• 構(gòu)建DOM樹(DOM tree)：解析HTML生成DOM樹
• 構(gòu)建CSSOM(CSS Object Model)樹：解析樣式生成CSSOM規(guī)則樹
• 執(zhí)行JavaScript：加載并執(zhí)行JavaScript代碼（包括內(nèi)聯(lián)代碼或外聯(lián)JavaScript文件）
• 構(gòu)建渲染樹(render tree)：將DOM樹和CSSO規(guī)則樹合并生成渲染樹（渲染樹：按順序展示在屏幕上的一系列矩形，這些矩形帶有字體，顏色和尺寸等視覺屬性）
• 布局（layout）：遍歷渲染樹開始布局，計算每個節(jié)點的位置大小等信息
• 繪制（painting）：將渲染樹每個節(jié)點繪制到屏幕

上面的步驟并不是一次性執(zhí)行完成，例如DOM或者CSSOM被修改時，就會有某個過程需要被重復(fù)執(zhí)行，重新計算并重新渲染。實際上，由于JS跟css的操作會多次修改DOM跟CSSOM。

前端安全（CSRF、XSS）

XSS

XSS，即 Cross Site Script，中譯是跨站腳本攻擊；其原本縮寫是 CSS，但為了和層疊樣式表(Cascading Style Sheet)有所區(qū)分，因而在安全領(lǐng)域叫做 XSS。

XSS 攻擊是指攻擊者在網(wǎng)站上注入惡意的客戶端代碼，通過惡意腳本對客戶端網(wǎng)頁進(jìn)行篡改，從而在用戶瀏覽網(wǎng)頁時，對用戶瀏覽器進(jìn)行控制或者獲取用戶隱私數(shù)據(jù)的一種攻擊方式。

攻擊者對客戶端網(wǎng)頁注入的惡意腳本一般包括 JavaScript，有時也會包含 HTML 和 Flash。有很多種方式進(jìn)行 XSS 攻擊，但它們的共同點為：將一些隱私數(shù)據(jù)像 cookie、session 發(fā)送給攻擊者，將受害者重定向到一個由攻擊者控制的網(wǎng)站，在受害者的機器上進(jìn)行一些惡意操作。

XSS攻擊可以分為3類：反射型（非持久型）、存儲型（持久型）、基于DOM。

反射型

反射型 XSS 只是簡單地把用戶輸入的數(shù)據(jù) “反射” 給瀏覽器，這種攻擊方式往往需要攻擊者誘使用戶點擊一個惡意鏈接，或者提交一個表單，或者進(jìn)入一個惡意網(wǎng)站時，注入腳本進(jìn)入被攻擊者的網(wǎng)站。

存儲型

存儲型 XSS 會把用戶輸入的數(shù)據(jù) “存儲” 在服務(wù)器端，當(dāng)瀏覽器請求數(shù)據(jù)時，腳本從服務(wù)器上傳回并執(zhí)行。這種 XSS 攻擊具有很強的穩(wěn)定性。

比較常見的一個場景是攻擊者在社區(qū)或論壇上寫下一篇包含惡意 JavaScript 代碼的文章或評論，文章或評論發(fā)表后，所有訪問該文章或評論的用戶，都會在他們的瀏覽器中執(zhí)行這段惡意的 JavaScript 代碼。

基于DOM

基于 DOM 的 XSS 攻擊是指通過惡意腳本修改頁面的 DOM 結(jié)構(gòu)，是純粹發(fā)生在客戶端的攻擊

CSRF

CSRF，即 Cross Site Request Forgery，中譯是跨站請求偽造，是一種劫持受信任用戶向服務(wù)器發(fā)送非預(yù)期請求的攻擊方式。

通常情況下，CSRF 攻擊是攻擊者借助受害者的 Cookie 騙取服務(wù)器的信任，可以在受害者毫不知情的情況下以受害者名義偽造請求發(fā)送給受攻擊服務(wù)器，從而在并未授權(quán)的情況下執(zhí)行在權(quán)限保護(hù)之下的操作。

防范

• 防御 XSS 攻擊
  • HttpOnly 防止劫取 Cookie
  • 用戶的輸入檢查
  • 服務(wù)端的輸出檢查
• 防御 CSRF 攻擊
  • 驗證碼
  • Referer Check
  • Token 驗證

相關(guān)文章
淺說 XSS 和 CSRF

前端跨域

瀏覽器的同源策略安全機制導(dǎo)致了跨域，容易有CSRF攻擊。

跨域解決方案：

• JSONP，script 標(biāo)簽是不受同源策略的限制的，它可以載入任意地方的 JavaScript 文件，而并不要求同源。
• document.domain，這種方式只適合主域名相同，但子域名不同的iframe跨域。比如主域名是http://crossdomain.com:9099，子域名是http://child.crossdomain.com:9099，這種情況下給兩個頁面指定一下document.domain即document.domain = crossdomain.com就可以訪問各自的window對象了。
• CORS是一個W3C標(biāo)準(zhǔn)，全稱是"跨域資源共享"（Cross-origin resource sharing）跨域資源共享 CORS 詳解。
• Nginx代理配置

cdn加速

簡單的來說就是原服務(wù)器上數(shù)據(jù)復(fù)制到其他服務(wù)器上，用戶訪問時，那臺服務(wù)器近訪問到的就是那臺服務(wù)器上的數(shù)據(jù)。

CDN加速優(yōu)點是成本低，速度快?？梢杂肅DN best的CDN進(jìn)行加速，免費，可部署私有，公有CDN系統(tǒng)。可以實現(xiàn)宕機檢測，自動切換ip，分線路，分組解析。也就是CDN加速的主要作用就是保證網(wǎng)站的正常訪問，及加快網(wǎng)站訪問速度和響應(yīng)速度，防止網(wǎng)站因黑客攻擊，DNS解析劫持故障等導(dǎo)致的網(wǎng)站服務(wù)器的宕機狀況的出現(xiàn)。

負(fù)載均衡

垂直擴展

隨著系統(tǒng)訪問量的增加，在不新增服務(wù)器的情況下，可以通過提升單機硬件配置來做負(fù)載均衡（可從cpu、內(nèi)存、硬盤，網(wǎng)卡等方面提升），但是垂直擴展會帶來成本問題...

在早期時候，價格不變時，每隔一到兩年技術(shù)會革新，性能會翻一倍，即摩爾定律：

當(dāng)價格不變時，集成電路上可容納的元器件數(shù)目，約每隔18-24個月便會增加一倍，性能也將提升一倍。
換言之，每一美元所能買到的電腦性能，將每隔18-24個月翻一倍以上。

當(dāng)技術(shù)已經(jīng)達(dá)到瓶頸，提升電腦性能的消耗的成本將越來越高，所以摩爾定律已經(jīng)放緩。因此單機擴展性能提高是有限的，而且成本會越來越高

水平擴展

目前在高并發(fā)高可用系統(tǒng)架構(gòu)中，最優(yōu)方案還是水平擴展。理論上，在系統(tǒng)能支持水平擴展的前提下，增加服務(wù)器數(shù)量，部署更多機器集群，能帶來無限的性能提升。

Nginx

Nginx 是一個高性能的WEB服務(wù)器和反向代理服務(wù)，最常用的軟件負(fù)載均衡器，屬于第七層應(yīng)用層協(xié)議。

核心概念：用戶請求先到Nginx，再由Ngix轉(zhuǎn)發(fā)請求到后面的應(yīng)用服務(wù)器（如：node）

一般做到10W 并發(fā)，因為http請求的處理包括解析和封裝Http 內(nèi)容，要處理更多請求，需要更多內(nèi)存、CPU等資源。

如果面臨幾十萬并發(fā)量，可以使用Ngix集群，則需要LVS負(fù)責(zé)轉(zhuǎn)發(fā)給 Ngix 集群機器

LVS

LVS（Linux Virtual Server），Linux 虛擬服務(wù)器，中國人開發(fā)，目前絕大部分Linux 發(fā)行版，都集成在內(nèi)核了 。實現(xiàn)基于第四層（傳輸層）的軟件負(fù)載均衡方案。支持10W～50W 并發(fā)量。

為了方便理解，初學(xué)者可認(rèn)為安裝使用了LVS的Linux服務(wù)器，等于快遞中轉(zhuǎn)。

核心理念：原本是請求LVS服務(wù)器的數(shù)據(jù)包，被LVS軟件篡改了數(shù)據(jù)包的目的地，將流量轉(zhuǎn)移到了Ngix所在的機器IP，從而實現(xiàn)負(fù)載均衡。

為什么說LVS比Nigx快？
網(wǎng)絡(luò)層第四層使用的協(xié)議（如TCP）內(nèi)容比Http簡單，解析和組裝所消耗的CPU、內(nèi)存等資源比Nigx要低。

硬件設(shè)備F5

F5是實現(xiàn)第四層（傳輸層）交換的一款產(chǎn)品，屬于硬交換，價格貴性能好

服務(wù)端上限

• Nginx 支撐1W～10W并發(fā)
• LVS 支撐10W～50W并發(fā)
• F5 支撐200W～1000W并發(fā)

DNS-無限水平擴展