一次完整的HTTP請求是怎樣的一個過程？
當我們在瀏覽器的地址欄輸入jianshu.com屎暇，然后回車蹋盆，這一瞬間到底發(fā)生了什么？
- 域名解析
- 發(fā)起TCP三次握手
- 建立TCP連接后發(fā)起http請求（GET, POST）
- 服務器響應http請求那先，瀏覽器得到HTML代碼
- 瀏覽器解析HTML代碼并請求html代碼中的資源（js,css,圖片等）
- 瀏覽器對頁面進行渲染展現(xiàn)給用戶
TCP為什么需要三次握手？
2臺計算機通信是靠協(xié)議來實現(xiàn)的赡艰，目前流行的是TPC/IP協(xié)議售淡，如果兩臺計算機使用的協(xié)議不一樣，那是不能進行通信的，所以這個三次握手就相當于試探一下對方是否遵循TCP/IP協(xié)議揖闸，協(xié)商完成后就可以進行通信了揍堕，這只是簡單理解下，其實過程中要復雜些汤纸。
HTTP和HTTPS的區(qū)別：
HTTP的URL是以http開頭衩茸，而HTTPS是https開頭；
HTTP是不安全的贮泞，HTTPS是安全的(相對)楞慈；
HTTP標準端口是80，HTTPS是443啃擦；
在OSI網(wǎng)絡模型中囊蓝，HTTP工作于應用層，HTTPS的安全傳輸機制工作在傳輸層议惰；
HTTP無法加密，HTTPS對傳輸?shù)臄?shù)據(jù)進行加密乡恕；
HTTP無需證書言询，而HTTPS 需要CA機構(gòu)wosign的頒發(fā)的SSL證書；
什么是Http協(xié)議無狀態(tài)協(xié)議?怎么解決Http協(xié)議無狀態(tài)協(xié)議?
無狀態(tài)協(xié)議對于事務處理沒有記憶能力傲宜。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息
也就是說运杭，當客戶端一次HTTP請求完成以后，客戶端再發(fā)送一次HTTP請求函卒，HTTP并不知道當前客戶端是一個”老用戶“辆憔。
可以使用Cookie來解決無狀態(tài)的問題，Cookie就相當于一個通行證报嵌，第一次訪問的時候給客戶端發(fā)送一個Cookie虱咧，當客戶端再次來的時候，拿著Cookie(通行證)锚国，那么服務器就知道這個是”老用戶“腕巡。
常用的會話跟蹤技術(shù)Cookie和Session
HTTP本身是一個無狀態(tài)的連接協(xié)議，為了支持客戶端與服務器之間的交互血筑，我們就需要通過不同的技術(shù)為交互存儲狀態(tài)绘沉，而這些不同的技術(shù)就是Cookie和Session了.
- Cookie實際上是一小段的文本信息〔蜃埽客戶端請求服務器车伞，如果服務器需要記錄該用戶狀態(tài)，就使用response向客戶端瀏覽器頒發(fā)一個Cookie喻喳×砭粒客戶端瀏覽器會把Cookie保存起來。當瀏覽器再請求該網(wǎng)站時，瀏覽器把請求的網(wǎng)址連同該Cookie一同提交給服務 器日矫。服務器檢查該Cookie赂弓，以此來辨認用戶狀態(tài)。服務器還可以根據(jù)需要修改Cookie的內(nèi)容哪轿。
查看某個網(wǎng)站頒發(fā)的Cookie很簡單盈魁。在瀏覽器地址欄輸入javascript:alert (document. cookie)就可以了（需要有網(wǎng)才能查看）。JavaScript腳本會彈出一個對話框顯示本網(wǎng)站頒發(fā)的所有Cookie的內(nèi)容
所以窃诉，總結(jié)一下：
Session是在服務端保存的一個數(shù)據(jù)結(jié)構(gòu)杨耙，用來跟蹤用戶的狀態(tài)，這個數(shù)據(jù)可以保存在集群飘痛、數(shù)據(jù)庫珊膜、文件中；
Cookie是客戶端保存用戶信息的一種機制宣脉，用來記錄用戶的一些信息车柠，也是實現(xiàn)Session的一種方式。
常見的HTTP相應狀態(tài)碼
- 200：請求被正常處理
- 204：請求被受理但沒有資源可以返回
- 206：客戶端只是請求資源的一部分塑猖，服務器只對請求的部分資源執(zhí)行GET方法竹祷，相應報文中通過Content-Range指定范圍的資源。
- 301：永久性重定向
- 302：臨時重定向
- 303：與302狀態(tài)碼有相似功能羊苟，只是它希望客戶端在請求一個URI的時候塑陵，能通過GET方法重定向到另一個URI上
- 304：發(fā)送附帶條件的請求時，條件不滿足時返回蜡励，與重定向無關
- 307：臨時重定向令花，與302類似，只是強制要求使用POST方法
- 400：請求報文語法有誤凉倚，服務器無法識別
- 401：請求需要認證
- 403：請求的對應資源禁止被訪問
- 404：服務器無法找到對應資源
- 500：服務器內(nèi)部錯誤
- 503：服務器正忙
HTTP優(yōu)化方案
我下面就簡要概括一下：
- TCP復用：TCP連接復用是將多個客戶端的HTTP請求復用到一個服務器端TCP連接上兼都，而HTTP復用則是一個客戶端的多個HTTP請求通過一個TCP連接進行處理。前者是負載均衡設備的獨特功能稽寒；而后者是HTTP 1.1協(xié)議所支持的新功能俯抖，目前被大多數(shù)瀏覽器所支持。
- 內(nèi)容緩存：將經(jīng)常用到的內(nèi)容進行緩存起來瓦胎，那么客戶端就可以直接在內(nèi)存中獲取相應的數(shù)據(jù)了芬萍。
- 壓縮：將文本數(shù)據(jù)進行壓縮，減少帶寬
- SSL加速（SSL Acceleration）：使用SSL協(xié)議對HTTP協(xié)議進行加密搔啊，在通道內(nèi)加密并加速
- TCP緩沖：通過采用TCP緩沖技術(shù)柬祠，可以提高服務器端響應時間和處理效率，減少由于通信鏈路問題給服務器造成的連接負擔负芋。
HTTP三次握手四次揮手
三次握手與四次揮手分別對應TCP連接建立過程與斷開過程
問題1： 為什么要三次握手漫蛔？
答：三次握手的目的是建立可靠的通信信道嗜愈，說到通訊，簡單來說就是數(shù)據(jù)的發(fā)送與接收莽龟，而三次握手最主要的目的就是雙方確認自己與對方的發(fā)送與接收機能正常蠕嫁。
第一次握手：Client什么都不能確認；Server確認了對方發(fā)送正常
第二次握手：Client確認了：自己發(fā)送毯盈、接收正常剃毒，對方發(fā)送、接收正常搂赋；Server確認了：自己接收正常赘阀，對方發(fā)送正常
第三次握手：Client確認了：自己發(fā)送、接收正常脑奠，對方發(fā)送基公、接收正常；Server確認了：自己發(fā)送宋欺、接收正常轰豆，對方發(fā)送接收正常
所以三次握手就能確認雙發(fā)收發(fā)功能都正常，缺一不可齿诞。
問題2：為什么要發(fā)送特定的數(shù)據(jù)包酸休，隨便發(fā)不行嗎？
答：三次握手的另外一個目的就是確認雙方都支持TCP掌挚，告知對方用TCP傳輸雨席。
第一次握手：Server 猜測Client可能要建立TCP請求菩咨，但不確定吠式，因為也可能是Client亂發(fā)了一個數(shù)據(jù)包給自己
第二次握手：通過ack=J+1，Client知道Server是支持TCP的抽米，且理解了自己要建立TCP連接的意圖
第三次握手：通過ack=K+1特占，Server知道Client是支持TCP的，且確實是要建立TCP連接
問題3：上圖中的SYN和ACK是什么云茸？
答：SYN是標志位是目，SYN=1表示請求連接；
ACK其實就是ack后面加上的那個數(shù)标捺，真正發(fā)送的時候不單獨發(fā)ACK懊纳，只發(fā)ack，下面四次揮手的圖同理
問題1： 為什么要四次揮手亡容？
答：根本原因是嗤疯，一方發(fā)送FIN只表示自己發(fā)完了所有要發(fā)的數(shù)據(jù)，但還允許對方繼續(xù)把沒發(fā)完的數(shù)據(jù)發(fā)過來闺兢。
舉個例子：A和B打電話茂缚，通話即將結(jié)束后，A說“我沒啥要說的了”，B回答“我知道了”脚囊，但是B可能還會有要說的話龟糕，A不能要求B跟著自己的節(jié)奏結(jié)束通話，于是B可能又巴拉巴拉說了一通悔耘，最后B說“我說完了”讲岁，A回答“知道了”，這樣通話才算結(jié)束淮逊。
問題2：為什么雙方要發(fā)送這樣的數(shù)據(jù)包催首？
答：和握手的情況類似，只是為了讓對方知曉自己理解了對方的意圖泄鹏。
