HTTP
超文本傳輸協(xié)議 Hyper Text
Transfer Protocol络断，是符合TCP標(biāo)準(zhǔn)的應(yīng)用層射亏，以明文方式發(fā)送內(nèi)容谜嫉，不提供任何方式的數(shù)據(jù)加密湘纵。
請求方法
GET POST PUT HEAD OPTIONS DELETE TRACE CONNECT
請求頭
通用頭 請求頭 響應(yīng)頭 實(shí)體頭
連接
- 短連接： 1.0默認(rèn)使用短連接，即每次請求都要重新發(fā)起連接分瘦，數(shù)據(jù)交換結(jié)束即關(guān)閉連接
- 長連接：1.1起默認(rèn)使用長連接蘸泻，連接建立后不斷開琉苇。
各版本
1.0
- 默認(rèn)使用短連接
- 使用if-modified-since expires來做緩存判斷標(biāo)準(zhǔn)
- 存在帶寬浪費(fèi)現(xiàn)象嘲玫，比如客戶端僅需要對象的一部分，服務(wù)端將整個對象送來
1.1
- 默認(rèn)使用長連接
- 引入更多緩存判斷標(biāo)準(zhǔn)Etag if-None-Match
- 允許請求資源的某個部分
- 新增了24個狀態(tài)碼
2.0
- 允許多路復(fù)用并扇，做到同一個連接并發(fā)處理多個請求
- 支持二進(jìn)制編碼
- 將相同的首部進(jìn)行壓縮去团，不重復(fù)傳輸
- 流量控制
- 支持服務(wù)器推送（CSS和JS一起發(fā)送），不僅只是客戶端發(fā)起請求穷蛹，服務(wù)端可以自己發(fā)送一些數(shù)據(jù)土陪。
3.0
1、QUIC (Quick UDP Internet Connections)是基于UDP協(xié)議的肴熏。
2鬼雀、解決了 TCP 的隊(duì)頭阻塞問題（某一個流的數(shù)據(jù)有丟包，則同樣會阻塞在它之后傳輸?shù)牧鲾?shù)據(jù)傳輸）蛙吏。而 http3.0 中不同的流之間真正的實(shí)現(xiàn)相互獨(dú)立傳輸源哩，互不干擾。
3鸦做、在切換網(wǎng)絡(luò)時的依舊保持連接励烦。
狀態(tài)碼
| 狀態(tài)碼 | 解釋 |
|---|---|
| 100 | 服務(wù)器收到了請求，請客戶端繼續(xù)發(fā)送 1XX是1.1版本新定義的泼诱，可以優(yōu)化某些場景坛掠，比如：客戶端有一個較大的文件需要上傳并保存，但是客戶端并不知道服務(wù)端是否愿意接受這個文件治筒，所以希望在消耗網(wǎng)絡(luò)資源進(jìn)行傳輸之前屉栓，先詢問服務(wù)器的意愿，實(shí)際操作為耸袜，請求頭加上Expect: 100-coninue友多， 若服務(wù)器接受，返回100句灌，否則417 |
| 200 | 請求成功 |
| 201 | 成功請求并創(chuàng)建了新資源 |
| 202 | 已接受請求夷陋，但未處理完成 |
| 203 | 非授權(quán)信息 |
| 204 | 服務(wù)器成功處理欠拾，但未返回內(nèi)容 |
| 301 | 請求的資源已被永久的移動到新URL，返回信息會包括新的URL |
| 302 | 資源臨時被移動骗绕，客戶端應(yīng)繼續(xù)使用原有URL |
| 303 | 使用GET和POST請求查看其他地址 |
| 304 | 請求已被允許藐窄，但文檔的內(nèi)容并沒有改變（緩存） |
| 305 | 所請求的資源必須通過代理訪問 |
| 307 | 使用GET請求重定向 |
| 400 | 請求無效，前端數(shù)據(jù)與后端數(shù)據(jù)不一致酬土，請求格式不對 |
| 401 | 當(dāng)前請求需要用戶驗(yàn)證 |
| 403 | 服務(wù)器已經(jīng)得到請求荆忍，但是拒絕執(zhí)行，比如身份驗(yàn)證不通過 |
| 404 | 服務(wù)器無法根據(jù)客戶端的請求找到資源 |
| 405 | 客戶端請求中的方法被禁止 |
| 408 | 服務(wù)器等待客戶端發(fā)送的請求時間過長撤缴，請求超時 |
| 410 | 客戶端請求的資源已經(jīng)不存在 |
| 413 | 由于請求的實(shí)體過大刹枉，服務(wù)器無法處理，因此拒絕 |
| 414 | 請求的URL過長 |
| 415 | 服務(wù)器無法處理請求附帶的媒體格式 |
| 416 | 客戶端請求的范圍無效 |
| 500 | 服務(wù)器內(nèi)部錯誤屈呕，無法完成請求 |
| 501 | 這個狀態(tài)碼不常見微宝，意思是未實(shí)現(xiàn)，這個解釋會給人誤導(dǎo)虎眨，并不是意味著我們訪問了一個未實(shí)現(xiàn)的api蟋软，而是服務(wù)器目前不具備滿足您對該內(nèi)容請求的功能， 比如服務(wù)器脫機(jī)了 |
| 503 | 由于超載或系統(tǒng)維護(hù)嗽桩，服務(wù)器暫時無法處理客戶端的請求 |
| 505 | 服務(wù)器不支持請求的http協(xié)議的版本 |
HTTPS
HTTPS在HTTP的基礎(chǔ)上加入了SSL協(xié)議岳守，SSL依靠證書來驗(yàn)證服務(wù)器的身份，并未瀏覽器和服務(wù)器之間的通信加密碌冶。簡單來說是HTTP的安全版湿痢。
SSL(Secure Sockets Layer)最初由網(wǎng)景公司設(shè)計（1994），用來加密HTTP協(xié)議傳輸?shù)臄?shù)據(jù).
主要區(qū)別
- HTTPS需要到CA申請證書扑庞，一般需要一定費(fèi)用
- HTTPS安全性更高
- HTTP的默認(rèn)端口是80譬重，HTTPS是443
- HTTP本身是無狀態(tài)的，非常簡單的協(xié)議嫩挤；HTTPS是由SSL+HTTP構(gòu)建的可進(jìn)行加密傳輸害幅、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，它是有狀態(tài)的岂昭。
- https更消耗時間和資源（ssl部分需額外花費(fèi)三倍時間）
- https在SEO方面以现，谷歌搜索引擎算法中給了https加密的網(wǎng)站更高的排名。
HTTPS的工作原理
- 用戶在瀏覽器輸入一個https網(wǎng)址约啊，連接到對應(yīng)server的443端口
- 采用HTTPS協(xié)議的服務(wù)器必須要有一套數(shù)字證書邑遏，可以自己制作，也可以向組織申請恰矩，自己制作的證書需要客戶端驗(yàn)證通過才可以繼續(xù)訪問记盒。
這個證書就是一對公鑰和私鑰。私鑰相當(dāng)于鑰匙外傅，公鑰相當(dāng)于鎖纪吮， - 服務(wù)端傳送證書給客戶端（公鑰俩檬，相當(dāng)于把鎖給別人，別人可以用這把鎖把重要的東西鎖起來碾盟，然后發(fā)給你棚辽，因?yàn)橹挥心阋粋€人有鑰匙，所以只有你才能看到）
- 客戶端解析證書冰肴，由客戶端的TLS來完成屈藐。
TLS/SSL 安全傳輸層協(xié)議，用于在兩個通信應(yīng)用程序之間提供保密性和數(shù)據(jù)完整性熙尉。TLS是SSL的升級版联逻，二者經(jīng)常混用检痰，小編也說不清楚包归，總之是先有了SSL1.0 2.0，但各種bug攀细，后來直接推出了TLS1.0箫踩，又有了SSL3.0。
那么TLS確認(rèn)保證公鑰不是被篡改的谭贪。TLS會確認(rèn)證書中的頒發(fā)機(jī)構(gòu)和過期時間，只要證書是可信的锦担，那么公鑰就是可信的俭识。
如果證書沒有問題，就會生成一個隨機(jī)值洞渔，然后用公鑰對該隨機(jī)值進(jìn)行加密套媚。 - 客戶端傳送隨機(jī)值給服務(wù)端
- 客戶端用私鑰解密公鑰（鎖）之后，得到隨機(jī)值磁椒，然后之后的傳輸都用該隨機(jī)值所謂私鑰進(jìn)行對稱加密傳遞信息堤瘤。
對稱加密和非對稱加密方法列舉
- 非對稱加密： RSA DSA
- 對稱加密： AES RC4
- HASH加密： MD5 SHA1
HTTPS的優(yōu)缺點(diǎn)
優(yōu)點(diǎn)
- 安全
缺點(diǎn)
- 握手階段費(fèi)時
- https 緩存不如 http 高效，增加數(shù)據(jù)開銷浆熔。
- SSL 證書消耗成本本辐，功能越強(qiáng)大的證書費(fèi)用越高。
