輸入URL返回頁面的過程：首先，DNS解析域名得到IP，然後利用IP發起TCP三次握手（瀏覽器會隨機生成一個埠去連線伺服器的web80埠），然後客戶端發起HTTP請求，然後伺服器響應請求，返回響應資料。瀏覽器解析資料，渲染呈現。

HTTP常見欄位。客戶端傳送請求的時候，用Host欄位來指定伺服器的域名。伺服器返回資料的時候，通過Content-Length欄位表明本次迴應的資料長度。Connection欄位最常用於客戶端要求伺服器使用TCP持久連線，以便其他請求複用。

HTTP協議特點。允許傳輸任何型別的資料，由content-type決定。是無狀態的，每次客戶端發的資料都會被伺服器認為是新的請求，上一次和這一次無關。支援cs模式。

HTTP請求報文格式，行頭體。請求行，請求頭，請求體。請求行包括請求方法，請求URL，使用的HTTP版本。請求頭是屬性名和屬性值。
HTTP響應報文格式，狀態行，響應頭，響應體。狀態行包含協議版本，狀態碼和狀態描述。
HTTP狀態碼：1表示成功接收到客戶端請求，需要客戶端繼續傳送請求。2表示成功處理了客戶端請求。3表示重定向，就是成功接收了請求，但是還需要進一步操作才能完成請求。4表示無法處理請求。5表示處理請求失敗。

HTTP1.1相比於1.0。長連線，斷電續傳，新增一些以4開頭的錯誤狀態響應碼，Host頭處理（因為多個虛擬主機可以共享一個IP地址了）
HTTP2.0相比於1.1。二進位制的檔案傳輸格式，多路複用，頭部壓縮技術（把頭和資料分離，封裝成頭幀和資料幀。記錄已傳送的鍵值對防止重複傳送，防止資料冗餘，降低開銷），服務端推送功能（不需要客戶端發起請求）

HTTP風險：竊聽（密碼被盜）、篡改（垃圾廣告彈出）、冒充（冒充淘寶騙錢）、

HTTPS和HTTP的區別。HTTP是基於TCP協議的超文字傳輸協議，HTTPS是具有安全性的SSL加密傳輸協議。埠不一樣，一個是80，一個是443。HTTPS需要到CA機構申請證書，花銷大。要注意ssl協議也是基於TCP協議的。

HTTPS的基本原理。首先是TCP三次握手。然後客戶端傳送一個client hello包，告訴伺服器自己可以支援的加密演算法（協商加密演算法）、SSL協議支援的版本、隨機產生的數num1。伺服器迴應sever hello包，告訴客戶端加密演算法、確認協議版本、隨機產生的數num2。然後伺服器向數字證書頒發機構CA獲取數字證書（自己設了公鑰）傳給客戶端。客戶端收到證書後，首先確認證書真實性，然後拿出伺服器公鑰，使用它加密報文，並向服務端傳送隨機數num3、加密通訊演算法改變通知（以後都用新的會話金鑰）加密通訊、握手結束通知和給服務端校驗的摘要。接著就用三個隨機數和之前協商的加密演算法，算出本次通訊的會話金鑰（對稱加密）。

（1）混合加密：非對稱加密和對稱加密的結合。通訊之前使用非對稱加密交換會話金鑰，後續通訊過程中全部使用對稱加密的會話金鑰的方式加密明文資料。
（2）摘要演算法：瀏覽器發資料之前會先通過摘要演算法算出明文對應的md5碼之類的特定指紋，然後指紋和明文一起傳送過去伺服器。伺服器用相同的摘要演算法算出明文，通過對比指紋判斷資料的完整性。
（3）數字證書：伺服器把公鑰給CA機構，CA用自己的私鑰和伺服器的公鑰做成數字簽名頒發數字證書。數字證書從伺服器傳到客戶端。客戶端通過CA公鑰（事先就在瀏覽器或作業系統）確認證書真實性，從數字證書獲取伺服器公鑰，使用該公鑰對報文加密傳送。伺服器使用加密演算法計算的私鑰對報文解密。

考慮到效能的問題，雙方在加密應用資訊的時候使用的是對稱加密金鑰。但是這個金鑰不能被洩漏，所以使用非對稱加密的方式保護對稱加密金鑰的協商（三個隨機數和加密演算法）。
對稱加密演算法有AES和ADS。
非對稱加密演算法有RSA和DSA和ECDHE。（公鑰，金鑰，比如HTTPS）

get和post請求的不同。
功能，引數傳遞的方式，傳輸大小，安全性性。此外，從瀏覽器端來看，get產生一個TCP資料包，post產生兩個（傳送過去收到100，然後接收到之後，再次傳送）。（1）get是從伺服器獲取資料，引數在url請求行傳送，因此不太安全，url的傳輸大小比較小。（2）post是向伺服器傳送資料。引數在響應體裡面傳送，因此比較安全，傳輸大小比較大。

HTPS的優化如下。
cookie和session的區別。cookie在瀏覽器，很容易被竊取。session在服務端，安全員比較高。cookie長時間保持，session短時間失效。cookie儲存容量小（小於4k），session儲存容量大（但是不能太大，要有刪除機制）

web開發中，webserver會自動的為那個使用者建立一個session，提供資料儲存功能（儲存登入資訊自動登入，和資料庫就不一樣，才會有session刪除機制）
在HTTP通訊中，客戶端傳送請求，伺服器接受請求並建立session會話，使用響應頭返回sessionid給客戶端。瀏覽器收到sessionid以後會儲存在本地cookie。當客戶端要發起第二次請求的時候，就會訪問本地cookie獲取sessionid放到請求頭，伺服器解析請求頭和session配對。
分散式系統會帶來session共享的問題。同一個使用者的多次請求被分發到叢集的不同伺服器上，就會出現取不到session使用者需要重新登入驗證的情況。
解決方案：
第一種，session複製和同步，tomat自帶該功能。需要資料傳輸，有延遲，且受記憶體限制。
第二種，客戶端cookie儲存法，不安全，儲存大小受限。
第三種，反向代理hash一致性。反向代理層讓同一個使用者的請求落在同一個伺服器上。失去了nginx負載均衡的意義。
第四種，後端統一集中儲存，比如資料庫或快取，需要增加一次網路呼叫。可以使用spring session框架，將session快取到redis裡面。使用redis和EhCache實現一級和危機快取。
第五種，使用token的方式代替session功能，移動端沒有session概念，使用token實現。token最終會存到redis，Redis-cluster分片叢集中預設支援分散式共享。（最靠譜的分散式session資料一致性解決方案）