本文參照：極客時間-《深入拆解 Tomcat & Jetty》-02 | HTTP協議必知必會
HTTP協議
HTTP本質
HTTP協議是瀏覽器與服務器之間的數據傳送協議。作爲應用層協議，HTTP是基於TCP/IP協議來傳遞數據的（HTML文件、圖片、查詢結果等），HTTP協議不涉及數據包（Packet）傳輸，主要規定了客戶端和服務器之間的通信格式。
下面我通過一個例子來告訴你HTTP的本質是什麼。
假如瀏覽器需要從遠程HTTP服務器獲取一個HTML文本，在這個過程中，瀏覽器實際上要做兩件事情。
- 與服務器建立Socket連接。
- 生成請求數據並通過Socket發送出去。
第一步比較容易理解，瀏覽器從地址欄獲取用戶輸入的網址和端口，去連接遠端的服務器，這樣就能通信了。
我們重點來看第二步，這個請求數據到底長什麼樣呢？都請求些什麼內容呢？或者換句話說，瀏覽器需要告訴服務端什麼信息呢？
首先最基本的是，你要讓服務端知道你的意圖，你是想獲取內容還是提交內容；其次你需要告訴服務端你想要哪個內容。那麼要把這些信息以一種什麼樣的格式放到請求裏去呢？這就是HTTP協議要解決的問題。也就是說，HTTP協議的本質就是一種瀏覽器與服務器之間約定好的通信格式。
HTTP工作原理
- 用戶通過瀏覽器進行了一個操作，比如輸入網址並回車，或者是點擊鏈接，接着瀏覽器獲取了這個事件。
- 瀏覽器向服務端發出TCP連接請求。
- 服務程序接受瀏覽器的連接請求，並經過TCP三次握手建立連接。
- 瀏覽器將請求數據打包成一個HTTP協議格式的數據包。
- 瀏覽器將該數據包推入網絡，數據包經過網絡傳輸，最終達到端服務程序。
- 服務端程序拿到這個數據包後，同樣以HTTP協議格式解包，獲取到客戶端的意圖。
- 得知客戶端意圖後進行處理，比如提供靜態文件或者調用服務端程序獲得動態結果。
- 服務器將響應結果（可能是HTML或者圖片等）按照HTTP協議格式打包。
- 服務器將響應數據包推入網絡，數據包經過網絡傳輸最終達到到瀏覽器。
- 瀏覽器拿到數據包後，以HTTP協議的格式解包，然後解析數據，假設這裏的數據是HTML。
- 瀏覽器將HTML文件展示在頁面上。
如上，Tomcat和Jetty作爲一個HTTP服務器，主要承擔了接受連接、解析請求數據、處理請求和發送響應這幾個步驟。這裏請你注意，可能有成千上萬的瀏覽器同時請求同一個HTTP服務器，因此Tomcat和Jetty爲了提高服務的能力和併發度，往往會將自己要做的幾個事情並行化，具體來說就是使用多線程的技術。
HTTP請求響應實例
在瀏覽器和HTTP服務器之間通信的過程中，首先要將數據打包成HTTP協議的格式：
如上，HTTP請求數據由三部分組成，分別是請求行、請求報頭、請求正文。當這個HTTP請求數據到達Tomcat後，Tomcat會把HTTP請求數據字節流解析成一個Request對象，這個Request對象封裝了HTTP所有的請求信息。接着Tomcat把這個Request對象交給Web應用去處理，處理完後得到一個Response對象，Tomcat會把這個Response對象轉成HTTP格式的響應數據併發送給瀏覽器。
HTTP響應的格式，HTTP的響應也是由三部分組成，分別是狀態行、響應報頭、報文主體。
HTTP長連接
在HTTP/1.0時期，每次HTTP請求都會創建一個新的TCP連接，請求完成後之後這個TCP連接就會被關閉。這種通信模式的效率不高，所以在HTTP/1.1中，引入了HTTP長連接的概念，使用長連接的HTTP協議，會在響應頭加入Connection:keep-alive。這樣當瀏覽器完成一次請求後，瀏覽器和服務器之間的TCP連接不會關閉，再次訪問這個服務器上的網頁時，瀏覽器會繼續使用這一條已經建立的連接，也就是說兩個請求可能共用一個TCP連接。省去了下一次的TCP三次握手。
HTTP/1.1中的長連接依然沒有解決 head of line blocking 的問題，後面的連接必須等待前面的返回了才能夠發送，這個問題直到HTTP/2.0採取二進制分幀編碼方式才徹底解決。
Cookie和Session
HTTP協議有個特點是無狀態，請求與請求之間是沒有關係的。因此HTTP協議需要一種技術讓請求與請求之間建立起聯繫，並且服務器需要知道這個請求來自哪個用戶，於是Cookie技術出現了。
cookie
Cookie是HTTP報文的一個請求頭，Web應用可以將用戶的標識信息或者其他一些信息（用戶名等）存儲在Cookie中。用戶經過驗證之後，每次HTTP請求報文中都包含Cookie，這樣服務器讀取這個Cookie請求頭就知道用戶是誰了。Cookie本質上就是一份存儲在用戶本地的文件，裏面包含了每次請求中都需要傳遞的信息。
由於Cookie以明文的方式存儲在本地，而Cookie中往往帶有用戶信息，這樣就造成了非常大的安全隱患。瀏覽器在Cookie中填充了一個Session ID之類的字段用來標識請求。
session
**Session可以理解爲服務器端開闢的存儲空間，裏面保存了用戶的狀態，用戶信息以Session的形式存儲在服務端。**當用戶請求到來時，服務端可以把用戶的請求和用戶的Session對應起來。
具體工作過程是這樣的：服務器在創建Session的同時，會爲該Session生成唯一的Session ID，當瀏覽器再次發送請求的時候，會將這個Session ID帶上，服務器接受到請求之後就會依據Session ID找到相應Session，找到Session後，就可以在Session中獲取或者添加內容了。而這些內容只會保存在服務器中，發到客戶端的只有Session ID，這樣相對安全，也節省了網絡流量，因爲不需要在Cookie中存儲大量用戶信息。
sessionid是一個會話的key，瀏覽器第一次訪問服務器會在服務器端生成一個session，有一個sessionid和它對應。tomcat生成的sessionid叫做jsessionid。jetty爲sessionId。
在Java中，是Web應用程序在調用HttpServletRequest的getSession方法時，由Web容器（比如Tomcat）創建的。
Tomcat的Session管理器提供了多種持久化方案來存儲Session，通常會採用高性能的存儲方式，比如Redis，並且通過集羣部署的方式，防止單點故障，從而提升高可用。同時，Session有過期時間，因此Tomcat會開啓後臺線程定期的輪詢，如果Session過期了就將Session失效。
HTTP與HTTPS
在日常互聯網瀏覽網頁時，我們接觸到的大多都是 HTTP 協議，這種協議是未加密，即明文的。這使得 HTTP 協議在傳輸隱私數據時非常不安全。因此，瀏覽器鼻祖 Netscape 公司設計了 SSL（Secure Sockets Layer） 協議，用於對 HTTP 協議傳輸進行數據加密，即 HTTPS 。
HTTPS 和HTTP 協議相比提供了：
- 數據完整性：內容傳輸經過完整性校驗
- 數據隱私性：內容經過對稱加密，每個連接生成一個唯一的加密密鑰
- 身份認證：第三方無法僞造服務端（客戶端）身份
如上圖，使用https協議，即http+ssl層，它在網絡間通信是加密的，所以需要加密證書（即便被抓包，會有加密信息）
注意：https的get請求，能夠抓到域名字符部分，不能抓到請求的數據。
一篇文章看明白 HTTP，HTTPS，SSL/TSL 之間的關係
HTTP與HTML
HTTP是通信的方式，HTML纔是通信的目的，就好比HTTP是信封，信封裏面的信（HTML）纔是內容；但是沒有信封，信也沒辦法寄出去。HTTP協議就是瀏覽器與服務器之間的溝通語言，具體交互過程是請求、處理和響應。