http協議是瀏覽器與伺服器之間的資料傳送協議。作為應用層協議，http是基於tcp/ip協議來傳遞資料的（html檔案、、查詢結果等），http協議不涉及資料報（packet）傳輸，主要規定了客戶端和伺服器之間的通訊格式。
下面我通過乙個例子來告訴你http的本質是什麼。
假如瀏覽器需要從遠端http伺服器獲取乙個html文字，在這個過程中，瀏覽器實際上要做兩件事情。
第一步比較容易理解，瀏覽器從位址列獲取使用者輸入的**和埠，去連線遠端的伺服器，這樣就能通訊了。
我們重點來看第二步，這個請求資料到底長什麼樣呢？都請求些什麼內容呢？或者換句話說，瀏覽器需要告訴服務端什麼資訊呢？
首先最基本的是，你要讓服務端知道你的意圖，你是想獲取內容還是提交內容；其次你需要告訴服務端你想要哪個內容。那麼要把這些資訊以一種什麼樣的格式放到請求裡去呢？這就是http協議要解決的問題。也就是說，http協議的本質就是一種瀏覽器與伺服器之間約定好的通訊格式。
使用者通過瀏覽器進行了乙個操作，比如輸入**並回車，或者是點選鏈結，接著瀏覽器獲取了這個事件。
瀏覽器向服務端發出tcp連線請求。
服務程式接受瀏覽器的連線請求，並經過tcp三次握手建立連線。
瀏覽器將請求資料打包成乙個http協議格式的資料報。
瀏覽器將該資料報推入網路，資料報經過網路傳輸，最終達到端服務程式。
服務端程式拿到這個資料報後，同樣以http協議格式解包，獲取到客戶端的意圖。
得知客戶端意圖後進行處理，比如提供靜態檔案或者呼叫服務端程式獲得動態結果。
伺服器將響應結果（可能是html或者等）按照http協議格式打包。
伺服器將響應資料報推入網路，資料報經過網路傳輸最終達到到瀏覽器。
瀏覽器拿到資料報後，以http協議的格式解包，然後解析資料，假設這裡的資料是html。
瀏覽器將html檔案展示在頁面上。
如上，tomcat和jetty作為乙個http伺服器，主要承擔了接受連線、解析請求資料、處理請求和傳送響應這幾個步驟。這裡請你注意，可能有成千上萬的瀏覽器同時請求同乙個http伺服器，因此tomcat和jetty為了提高服務的能力和併發度，往往會將自己要做的幾個事情並行化，具體來說就是使用多執行緒的技術。
在http/1.0時期，每次http請求都會建立乙個新的tcp連線，請求完成後之後這個tcp連線就會被關閉。這種通訊模式的效率不高，所以在http/1.1中，引入了http長連線的概念，使用長連線的http協議，會在響應頭加入connection:keep-alive。這樣當瀏覽器完成一次請求後，瀏覽器和伺服器之間的tcp連線不會關閉，再次訪問這個伺服器上的網頁時，瀏覽器會繼續使用這一條已經建立的連線，也就是說兩個請求可能共用乙個tcp連線。省去了下一次的tcp三次握手。
假設有乙個網頁，裡面包含好多，還包含好多【外部的】 css 檔案和 js 檔案。在「短連線」的模式下，瀏覽器會先發起乙個 tcp 連線，拿到該網頁的 html 源**（拿到 html 之後，這個 tcp 連線就關閉了）。然後，瀏覽器開始分析這個網頁的原始碼，知道這個頁面包含很多外部資源（、css、js）。然後針對【每乙個】外部資源，再分別發起乙個個 tcp 連線，把這些檔案獲取到本地（同樣的，每抓取乙個外部資源後，相應的 tcp 就斷開）
如果是「長連線」的方式，瀏覽器也會先發起乙個 tcp 連線去抓取頁面。但是抓取頁面之後，該 tcp 連線並不會立即關閉，而是暫時先保持著（所謂的「keep-alive」）。然後瀏覽器分析 html 原始碼之後，發現有很多外部資源，就用剛才那個 tcp 連線去抓取此頁面的外部資源。
http/1.1中的長連線依然沒有解決 head of line blocking 的問題，後面的連線必須等待前面的返回了才能夠傳送，這個問題直到http/2.0採取二進位制分幀編碼方式才徹底解決。
http協議有個特點是無狀態
cookie是http報文的乙個請求頭，web應用可以將使用者的標識資訊或者其他一些資訊（使用者名稱等）儲存在cookie中。使用者經過驗證之後，每次http請求報文中都包含cookie，這樣伺服器讀取這個cookie請求頭就知道使用者是誰了。cookie本質上就是乙份儲存在使用者本地的檔案，裡面包含了每次請求中都需要傳遞的資訊。
由於cookie以明文的方式儲存在本地，而cookie中往往帶有使用者資訊，這樣就造成了非常大的安全隱患。瀏覽器在cookie中填充了乙個session id之類的字段用來標識請求。
session可以理解為伺服器端開闢的儲存空間，裡面儲存了使用者的狀態，使用者資訊以session的形式儲存在服務端。當使用者請求到來時，服務端可以把使用者的請求和使用者的session對應起來。
具體工作過程是這樣的：伺服器在建立session的同時，會為該session生成唯一的session id，當瀏覽器再次傳送請求的時候，會將這個session id帶上，伺服器接受到請求之後就會依據session id找到相應session，找到session後，就可以在session中獲取或者新增內容了。而這些內容只會儲存在伺服器中，發到客戶端的只有session id，這樣相對安全，也節省了網路流量，因為不需要在cookie中儲存大量使用者資訊。
sessionid的生成過程和過期時間
sessionid是乙個會話的key，瀏覽器第一次訪問伺服器會在伺服器端生成乙個session，有乙個sessionid和它對應。tomcat生成的sessionid叫做jsessionid。jetty為sessionid。
在j**a中，是web應用程式在呼叫httpservletrequest的getsession方法時，由web容器（比如tomcat）建立的。
tomcat的session管理器提供了多種持久化方案來儲存session，通常會採用高效能的儲存方式，比如redis，並且通過集群部署的方式，防止單點故障，從而提公升高可用。同時，session有過期時間，因此tomcat會開啟後台執行緒定期的輪詢，如果session過期了就將session失效。
在日常網際網路瀏覽網頁時，我們接觸到的大多都是 http 協議，這種協議是未加密，即明文的。這使得 http 協議在傳輸隱私資料時非常不安全。因此，瀏覽器鼻祖 netscape 公司設計了ssl（secure sockets layer） 協議，用於對 http 協議傳輸進行資料加密，即 https。
https 和http 協議相比提供了：
如上圖，使用https協議，即http+ssl層，它在網路間通訊是加密的，所以需要加密證書（即便被抓包，會有加密資訊）注意：https的get請求，能夠抓到網域名稱字元部分，不能抓到請求的資料。
一篇文章看明白 http，https，ssl/tsl 之間的關係
web開發學習筆記二 http協議
http協議 當使用瀏覽器上網時，每個操作都是瀏覽器向伺服器傳送請求資訊，伺服器也會對每個請求發出相應的響應資訊，就是返回的頁面等.一 請求 請求包含 請求行 和 多個請求頭 請求行 一般是顯示所使用的請求方式 和 http協議版本 請求方式常用的倆鐘 get 和 post 倆鐘請求的區別 以下 g...
Web前端 HTTP協議
目錄2 post請求 三 http響應報文 http hypertext transport protocol 即超文字傳輸協議。這個協議詳細規定了瀏覽器和全球資訊網伺服器之間互相通訊的規則。http就是乙個通訊規則，通訊規則規定了客戶端傳送給伺服器的內容格式，也規定了伺服器傳送給客戶端的內容格式。...
web開發 Http協議基礎
一 http0.9版 http 是基於 tcp ip 協議的應用層協議 它不涉及資料報 packet 傳輸，主要規定了客戶端和伺服器之間的通訊格式，預設使用80埠。最早版本是1991年發布的0.9版。該版本極其簡單，只有乙個命令get。get index.html 上面命令表示，tcp 連線 con...