1. HTTP
超文本傳輸協(xié)議; 是基于TCP
的;
常見方式有GET, POST, HEAD, PUT, DELETE, OPTIONS
;
特點:
- 1.無鏈接, 有建立鏈接和釋放鏈接的過程;
- 2.無狀態(tài); 如果沒有
session
或者cookie
即使是多次請求服務(wù)端也沒法確認客戶端的身份;
知識點:GET和POST的區(qū)別有哪些?
GET
POST
GET
請求參數(shù)以?
分隔拼接到URL
后面;POST
放在Body
中;GET
參數(shù)長度限制2048字節(jié);POST
無限制;GET
是獲取資源;POST
是處理資源;安全性, 冪等, 可緩存; 非安全性, 非冪等, 不可緩存; 安全性: 不引起服務(wù)端的任何狀態(tài)變化;
冪等性: 同一個請求執(zhí)行多次效果是否一樣;
緩存性: 一個請求是否可以被緩存;
日常開發(fā)中常見的狀態(tài)碼:
200:正常相應(yīng);
404:請求錯誤;
500:服務(wù)器內(nèi)部錯誤;
持久連接
持久連接有點:提升網(wǎng)絡(luò)請求銷量, 在一段時間內(nèi)即使多次請求也只執(zhí)行一次鏈接和斷開操作;
持久連接頭部字段設(shè)置
#允許客戶端持久連接
Connection:keep-alive
#100s內(nèi)有效, 不設(shè)置表示永久有效
Keep-Alive: timeout=100
知識點: 持久連接如何判斷數(shù)據(jù)是否已經(jīng)已經(jīng)傳輸完畢?
1: 判斷數(shù)據(jù)是否已經(jīng)達到Content-Length
所設(shè)置的大小;
2: 如果分塊傳輸數(shù)據(jù), 根據(jù)chunked
編碼數(shù)據(jù)判斷, 如果chunked
編碼的數(shù)據(jù)最后有chunked
的塊, 則表示完成;
2.HTTPS
簡單理解為安全的HTTP
; HTTPS
= HTTP
+ SSL/TLS
;
HTTPS使用了哪些加密方式?
建立鏈接的過程使用非對稱加密(耗時);(非對稱加密:公鑰加密, 私鑰解密)
后續(xù)通信采用對稱加密;(對稱加密: 只有一個密鑰)
加密方式
3. TCP/UDP
TCP
:傳輸控制協(xié)議, 提供面向鏈接可靠的字流服務(wù), 提供超時重發(fā), 丟棄重復(fù)數(shù)據(jù), 檢測數(shù)據(jù)控制流量等功能, 正式收發(fā)數(shù)據(jù)之前需要建立三次握手;
建立鏈接三次握手:
- 1.客戶端發(fā)送
syn
包,并進入syn_send
(請求鏈接)狀態(tài), 并等待服務(wù)器確認; - 2.服務(wù)器收到客戶端的
syn
(序列編號)包后,也發(fā)送一個syn
(syn=k
, 即syn+ack
)包,并進入syn_reveive
狀態(tài); - 3.客戶端收到服務(wù)器的
syn+ack
包,向服務(wù)器發(fā)送確認包ack(ack = k+1)
,此包發(fā)送完畢則和服務(wù)器進入建立鏈接(ESTABLISHED
)狀態(tài),完成三次握手;
為什么要三次握手?
假設(shè)只有兩次握手, 那么加入客戶端發(fā)發(fā)送的syn
包超時了, 客戶端會啟用重試策略再次發(fā)送syn
包, 后邊的的syn
包先被接受, 然后鏈接成功, 接著最先發(fā)送的syn
被接受到了, 就會再次鏈接; 然而初衷只是建立一次鏈接; 三次握手有效解決這個問題;
斷開連接的四次握手:
- 1.客戶端發(fā)送
fin
包到服務(wù)器, 請求是否可以斷開; - 2.服務(wù)器收到收發(fā)送
fin
包,確認可以斷開; - 3.服務(wù)器發(fā)送
ack
包,并斷開連接; - 4.客戶端收到服務(wù)器的包并斷開鏈接,同時發(fā)送
ack
包確認斷開;
UDP
:用戶數(shù)據(jù)報協(xié)議, 面向非鏈接, 不保證可靠性的數(shù)據(jù)傳輸服務(wù), 沒有超時重發(fā)等一系列等機制, 故而傳輸速度很快;
不與對方建立鏈接, 而是直接把數(shù)據(jù)包發(fā)送過去, UDP適用于一次只傳送少量數(shù)據(jù)對可靠性要求不高的應(yīng)用環(huán)境;
4. Socket
socket
是針對TCP/IP
協(xié)議的封裝, socket
本身并不是協(xié)議, 而是一個API
,通過socket
我們才能使用TCP/IP
協(xié)議;
基于TCP
的socket
如何保證數(shù)據(jù)的完整性, 讀到包頭開始,直到讀到相應(yīng)的包尾,取出中間的buffr,認為是一個完整的數(shù)據(jù)包;
客戶端的使用流程:
- 1.引入頭文件;
- 2.創(chuàng)建socket;
- 3.建立鏈接(基于TCP, 三次握手流程);
- 4.發(fā)送數(shù)據(jù)到服務(wù)器;
- 5.從服務(wù)器接受數(shù)據(jù);
- 6.關(guān)閉鏈接;
5. DNS
域名到IP地址的映射,DNS
解析請求采用UDP
明文數(shù)據(jù)報;
常見的查詢方式有遞歸查詢和迭代查詢
DNS劫持
問題:由于采用UDP明文數(shù)據(jù)報, 這樣就容易被釣魚DNS
劫持
返回錯誤的IP
地址; 注意:DNS劫持
和HTTP
是沒有關(guān)系的, 因為劫持是發(fā)生在HTTP
建立之前的;
可以通過HTTPDNS
和長連接
方案解決DNS
劫持問題;
6. Session&Cookies
Cookies
是保存在客戶端用來記錄區(qū)分用戶狀態(tài)的數(shù)據(jù);
Session
是保存在服務(wù)器端用來記錄區(qū)分用戶狀態(tài)的數(shù)據(jù);
Session
依賴于Cookies
的機制;
名詞解釋及鏈接
ack 即確認字符, 在TCP/IP協(xié)議中如果接收方成功收到數(shù)據(jù)那么會回復(fù)一個ack數(shù)據(jù)(通常ack有自己固定的格式和長度大小, 由接收方回復(fù)給發(fā)送方);
syn即同步序列編號, TCP/IP建立鏈接使用的握手信號,TCP鏈接的第一個包; (syn攻擊, 大量發(fā)送此類的包, 服務(wù)器);
fin帶有標志位的數(shù)據(jù)包用來結(jié)束一個TCP回話,但對應(yīng)的端口仍處于開放狀態(tài), 準備接收后續(xù)的數(shù)據(jù);
參考文章
iOS HTTP chunked
HTTP的長連接和短連接
HTTP Keep-Alive模式
HttpDNS功能說明及實現(xiàn)