相關(guān)文章: http://www.reibang.com/p/dc5b91f826f0
HTTP的發(fā)展
HTTP誕生：1990年纽帖，www全球信息剛起步時(shí)就得到了應(yīng)用
HTTP0.9版本：1991年，只有一個(gè)命令GET
HTTP1.0版本：1996年，不僅可以傳輸文字，還可以傳輸圖像昧捷，視頻秉馏，二進(jìn)制文件
HTTP1.1版本：1999年，進(jìn)一步完善了HTTP協(xié)議朋蔫，直到現(xiàn)在一直是很流行的版本
HTTPS: 2000年，是以安全為目標(biāo)的HTTP通道
什么是HTTP,HTTP協(xié)議具體包含哪些內(nèi)容,HTTP連接是怎么建立的
超文本傳輸協(xié)議
HTTP報(bào)文格式
HTTP的請(qǐng)求方式有
GET
POST
HEAD
PUT
DELETE
OPTIONS
GET和POST的區(qū)別
初級(jí)回答
- 請(qǐng)求參數(shù)位置: GET以問好拼接放在URL中,POST放在Body中
- 請(qǐng)求參數(shù)長度限制: GET限制2048個(gè)字符,POST無限制
- 安全性: GET不安全,POST相對(duì)安全
高級(jí)回答
- GET: 用來獲取資源的,需要遵從得是:安全性,冪等性,可緩存性
- POST: 是用來處理資源的,需要遵從的是非安全,非冪等,不可緩存
安全性:
指的是不應(yīng)該引起Server端相關(guān)數(shù)據(jù)的任何狀態(tài)變化
GET HEAD OPTIONS遵從安全性
冪等性:
同一個(gè)請(qǐng)求方法執(zhí)行多次和執(zhí)行一次的效果完全相同
PUT DELETE遵從
可緩存性:
請(qǐng)求是否可以被緩存
GET HEAD遵從
常見狀態(tài)碼及含義
1xx
2xx: 200響應(yīng)成功
3xx: 301和302可能是網(wǎng)絡(luò)重定向
4xx: 401和404可能是客戶端發(fā)起的請(qǐng)求本身存在問題
5xx: 501和502可能代表server端本身異常
HTTP的連接建立流程,涉及到TCP的三次握手和四次揮手
- 第一步先發(fā)起一個(gè)HTTP請(qǐng)求前,需要通過TCP的三次握手來建立連接,其實(shí)是客戶端和server端的三次交互
- 第二步是,在這條TCP通道上進(jìn)行HTTP的請(qǐng)求與相應(yīng)的數(shù)據(jù)傳遞
- 第三次是TCP的四次揮手,也就是客戶端和Server的四次交互
1.客戶端發(fā)送SYN同步報(bào)文給服務(wù)端
2.服務(wù)端收到后梭域，會(huì)給客戶端回復(fù)報(bào)文SYN,ACK
3.客戶端收到后會(huì)給服務(wù)端回復(fù)報(bào)文信息ACK報(bào)文
三次握手成功后證明TCP的通道建立成功了斑举，下面就可以發(fā)送數(shù)據(jù)了
4.當(dāng)我們點(diǎn)擊登錄按鈕，客戶端會(huì)發(fā)送HTTP的請(qǐng)求報(bào)文到服務(wù)端
5.當(dāng)服務(wù)端收到4時(shí)病涨，處理后返回給客戶端信息富玷，就是相應(yīng)報(bào)文
結(jié)束后通道需要關(guān)閉,假設(shè)這次關(guān)閉是由客戶端發(fā)起的
6，客戶端發(fā)送FIN報(bào)文既穆，即終止報(bào)文
7. 服務(wù)端收到終止報(bào)文后赎懦，會(huì)返回給客戶端一個(gè)ACK確認(rèn)終止
此時(shí)客戶端向服務(wù)端方向的連接已經(jīng)斷開了
8。過一段時(shí)間幻工，服務(wù)端又會(huì)發(fā)送給客戶端第8條FIN ACK終止報(bào)文
9励两。當(dāng)客戶端收到終止報(bào)文之后，回復(fù)給服務(wù)端一條ACK確認(rèn)報(bào)文
此時(shí)由服務(wù)端向客戶端方向的TCP連接通道已經(jīng)斷開了
TCP連接通道是雙向的一條通道囊颅，客戶端可以通過這條通道向服務(wù)器端發(fā)送數(shù)據(jù)当悔，服務(wù)器端也可以通過這個(gè)通道向客戶端發(fā)送數(shù)據(jù)傅瞻？？盲憎？
疑問:
??為什么TCP是三次握手,而不是兩次?
??四次揮手為什么要進(jìn)行兩方面的斷開?
HTTP的特點(diǎn)
無連接: 它的連接是有一個(gè)建立連接和釋放連接的過程
解決方案是:HTTP的持久連接無狀態(tài): 在多次發(fā)送HTTP請(qǐng)求的時(shí)候,如果是同一個(gè)用戶的話,對(duì)于server端,它是不知道這是同一個(gè)用戶的
當(dāng)我們打開一個(gè)網(wǎng)頁去購買商品的時(shí)候,會(huì)添加到購物車中,會(huì)發(fā)送多次請(qǐng)求,那么server端應(yīng)該如何去規(guī)避這種無狀態(tài)的弊端呢
解決方案是HTTP的Cookie和Session相關(guān)技術(shù)
持久連接
非持久連接是指,當(dāng)客戶端和server端進(jìn)行交互時(shí),會(huì)打開一個(gè)TCP連接,然后關(guān)閉,再請(qǐng)求時(shí),又打開一個(gè)TCP連接,再關(guān)閉,也就是每次網(wǎng)絡(luò)請(qǐng)求,都要新創(chuàng)建TCP連接
,每次都要經(jīng)歷三次握手和四次揮手
持久連接是指,當(dāng)我們打開一條TCP通道,在一定時(shí)間內(nèi),多個(gè)HTTP請(qǐng)求,是在同一條TCP通道中進(jìn)行數(shù)據(jù)傳遞,過一段時(shí)間后才會(huì)關(guān)閉這條通道
HTTP為了提升請(qǐng)求響應(yīng)的效率,所以才有了持久連接這個(gè)方案
????持久連接的頭部字段有:
- Connection : keep-alive 客戶端期許采用持久連接
- time: 20 持久連接需要持續(xù)多長時(shí)間,20S內(nèi)如果再次發(fā)起同一個(gè)域名或者IP的請(qǐng)求,可以 復(fù)用TCP通道
- max: 10 最多可以支持多少個(gè)HTTP請(qǐng)求和響應(yīng)對(duì)
??同一條TCP通道上,產(chǎn)生了多次HTTP請(qǐng)求,那么怎樣判斷一個(gè)請(qǐng)求是否結(jié)束和后一個(gè)請(qǐng)求的開始呢?
請(qǐng)求和響應(yīng)報(bào)文都有頭部字段,在響應(yīng)報(bào)文的頭部字段中會(huì)涉及到
Content-length: 1024
在我們發(fā)送請(qǐng)求,server回復(fù)時(shí),會(huì)攜帶響應(yīng)數(shù)據(jù)的大小,就是Content-length,當(dāng)客戶端所接收的字節(jié)數(shù)到達(dá)這個(gè)值時(shí),說明這個(gè)HTTP請(qǐng)求響應(yīng)已經(jīng)全部接收了,意味著結(jié)束POST請(qǐng)求時(shí),Server端返回往往是多次響應(yīng)返回給這些數(shù)據(jù)的,可以通過頭部字段
chuked: 最后一個(gè)塊是空chuked
來判斷一個(gè)請(qǐng)求是否結(jié)束
當(dāng)有多個(gè)塊通過HTTP的TCP連接傳輸給客戶端時(shí),每個(gè)報(bào)文都會(huì)帶有一個(gè)chuked字段,而最后一個(gè)塊,它是一個(gè)空的chuked,可以根據(jù)chuked是否為空來判斷上一個(gè)請(qǐng)求是否結(jié)束
HTTPS與網(wǎng)絡(luò)安全
2016年年底嗅骄，蘋果公司向開發(fā)者提出要求：全面適配https網(wǎng)絡(luò)請(qǐng)求，此要求是為了提高iOS客戶端的安全性
HTTP和HTTPS的區(qū)別:HTTPS = HTTP + SSL/TLS,多出的 SSL/TLS,就是安全模塊
總結(jié): HTTPS是安全的HTTP,他的安全,是由SSL/TLS協(xié)議來保障的
IP層: 網(wǎng)絡(luò)層
TCP層:傳輸層
HTTP:應(yīng)用層
SSL/TLS: 協(xié)議中間層
HTTPS的連接建立流程(有安全保證)
- 客戶端發(fā)報(bào)文,包含客戶端支持的TLS版本,客戶端支持的加密算法,還有一個(gè)隨機(jī)C
- Server返回給客戶端一個(gè)握手消息,也包括最終決定的加密算法(客戶端提供N中,Server選擇一個(gè)),隨機(jī)數(shù)S和Server的證書
- 客戶端進(jìn)行證書的公鑰驗(yàn)證,來判定當(dāng)前server是否合法
- 客戶端組裝會(huì)話秘鑰(用隨機(jī)數(shù)C+S+客戶端產(chǎn)生的預(yù)主秘鑰三個(gè)組裝合 )
- 客戶端會(huì)發(fā)送報(bào)文,通過Server的公鑰對(duì)預(yù)主秘鑰進(jìn)行加密傳輸
- server端通過私鑰解密得到預(yù)主秘鑰
- server端組裝會(huì)話秘鑰(用隨機(jī)數(shù)C+S+私鑰解密得到的預(yù)主秘鑰三個(gè)組裝合成)
- 客戶端向Server端發(fā)送加密的握手消息
- Server端返回給客戶端一個(gè)加密的握手消息,來驗(yàn)證安全通道是否已經(jīng)驗(yàn)證完成
備注:
會(huì)話秘鑰 = 隨機(jī)數(shù)S + 隨機(jī)數(shù)C + 預(yù)主秘鑰
會(huì)話秘鑰是對(duì)稱加密的秘鑰
公鑰和私鑰是非對(duì)稱加密
HTTPS中使用了哪些加密手段,為什么使用這些?
主要使用了對(duì)稱加密和非對(duì)稱加密
- 連接建立過程使用非對(duì)稱加密,保證安全
非對(duì)稱加密很耗時(shí)!!!,因?yàn)榧用芎徒饷苁褂玫氖侄尾灰粯?/li> - 數(shù)據(jù)傳輸過程是使用的對(duì)稱加密,減少耗時(shí)所帶來的性能損耗
非對(duì)稱加密??
假設(shè)發(fā)送方要發(fā)送hello出去,那么發(fā)送方會(huì)先用一個(gè)公鑰對(duì)hello進(jìn)行加密,之后經(jīng)過TCP的連接,將加密之后的內(nèi)容發(fā)給接收方
當(dāng)接收方拿到數(shù)據(jù)后,用私鑰進(jìn)行解密,然后拿到hello
加密用公鑰,解密就要用私鑰,如果加密用私鑰,那么解密就要用公鑰
????加密和解密必須使用不同的鑰
好處是非常安全,只有公鑰是在TCP中傳輸,私鑰永遠(yuǎn)保留在Server端,不涉及被中間人盜取的情況
對(duì)稱加密??
發(fā)送方使用一個(gè)對(duì)稱秘鑰進(jìn)行加密,然后將結(jié)果通過TCP連接傳過去
接收方通過同一個(gè)對(duì)稱秘鑰進(jìn)行解密,拿到結(jié)果
加密和解密是同一把鑰匙
自身缺點(diǎn)是:秘鑰需要通過TCP通道進(jìn)行傳遞,這樣server才能使用這個(gè)秘鑰,一旦在傳遞過程中被中間人攻擊,那么就不能保證安全了
工具
Charles查爾斯小瓶子(網(wǎng)絡(luò)調(diào)試代理)
當(dāng)你開著charles去刷新某個(gè)網(wǎng)頁時(shí)饼疙，charles會(huì)抓到你請(qǐng)求的數(shù)據(jù)
?? 查爾斯抓包原理是什么?
利用了HTTP的中間人攻擊漏洞來進(jìn)行實(shí)現(xiàn)的
??關(guān)于HTTP的中間人攻擊是什么?
當(dāng)客戶端發(fā)送請(qǐng)求時(shí),中間人會(huì)攔截住,然后假冒客戶端的身份,去向server請(qǐng)求, server會(huì)返回結(jié)果給中間人,然后中間人再把結(jié)果返回給客戶端
中間人可以篡改我們請(qǐng)求的參數(shù),包括server返回的數(shù)據(jù)也可以篡改
- Wireshark(網(wǎng)絡(luò)分析器)
打開Wireshark的wifi連接溺森，然后隨便打開一個(gè)網(wǎng)頁，就可以在Wireshark看到網(wǎng)絡(luò)數(shù)據(jù)
80是HTTP的端口號(hào)
5985是客戶端的臨時(shí)端口號(hào)
下面這條59854 - 80的數(shù)據(jù)窑眯，是客戶端向服務(wù)器端方向發(fā)送的一個(gè)報(bào)文屏积，還可以看到是TCP報(bào)文，并且是SYN,證明是第一次握手
傳輸層中的TCP和UDP
TCP: 傳輸控制協(xié)議
UDP: 用戶數(shù)據(jù)報(bào)協(xié)議
UDP
UDP協(xié)議是什么,特點(diǎn)和功能是什么?
????特點(diǎn):
- 無連接: 發(fā)送UDP數(shù)據(jù)報(bào)時(shí),不需要事先建立好連接,也不需要釋放連接
- 盡最大努力交付: 不保證可靠傳輸
- 面向報(bào)文: 既不合并,也不拆分,它會(huì)將應(yīng)用層報(bào)直接拼接UDP首部,組成UDP數(shù)報(bào),然后再在IP層拼接上IP首部,直接向外傳送
!](https://upload-images.jianshu.io/upload_images/1602974-fc3012d6f898f61f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
備注:
IP層: 網(wǎng)絡(luò)層
TCP層:傳輸層
HTTP:應(yīng)用層
SSL/TLS: 協(xié)議中間層
????功能:復(fù)用分用,差錯(cuò)檢測(cè)
復(fù)用分用
建立傳輸過程中需要IP地址和端口號(hào)的組成,也就是常說的套接字
TCP
特點(diǎn)
- 面向連接 : 數(shù)據(jù)傳輸開始前需要建立連接,結(jié)束后要釋放連接
- 可靠傳輸: 保證報(bào)文無差錯(cuò),不丟失,不重復(fù),按序到達(dá)
- 面向字節(jié)流
- 流量控制
- 擁塞控制
??為什么是三次握手?
三次握手能解決請(qǐng)求的超時(shí)場(chǎng)景
三次握手可以解決客戶端第一次SYN報(bào)文的超時(shí)問題
假如第一次SYN超時(shí),客戶端會(huì)在一定時(shí)間后發(fā)起SYN重連,當(dāng)Server回復(fù)連接報(bào)文后,如果客戶端的第一個(gè)超時(shí)SYN此時(shí)發(fā)出來了,如果是兩次握手的話,那么Server端會(huì)認(rèn)為客戶端發(fā)來兩次連接報(bào)文,如果是三次連接,當(dāng)Server回復(fù)后,會(huì)等待客戶端的ACK確認(rèn)報(bào)文,客戶端只會(huì)確認(rèn)一次,那么Server就會(huì)認(rèn)為客戶端第二次發(fā)送的SYN報(bào)文是無效的
??為什么是四次揮手?
6和7之后,客戶端向server端的通道就關(guān)閉了
8和9之后,server端向客戶端的通道就關(guān)閉了
之所以關(guān)閉兩次,是因?yàn)門CP通道是雙向的,一條通道,兩方都可以發(fā)送和接收,所以必須兩次斷開
DNS解析
域名到IP地址的映射
Session / Cookie
是為了解決HTTP的無狀態(tài)特點(diǎn)的
無狀態(tài): 在多次發(fā)送HTTP請(qǐng)求的時(shí)候,如果是同一個(gè)用戶的話,對(duì)于server端,它是不知道這是同一個(gè)用戶的
當(dāng)我們打開一個(gè)網(wǎng)頁去購買商品的時(shí)候,會(huì)添加到購物車中,會(huì)發(fā)送多次請(qǐng)求,那么server端應(yīng)該如何去規(guī)避這種無狀態(tài)的弊端呢
Cookie是用來區(qū)分用戶的,他會(huì)記錄用戶狀態(tài),保存在客戶端
Session也是用來區(qū)分用戶的,他會(huì)記錄用戶狀態(tài),保存在Server端
