基礎(chǔ)概念
網(wǎng)絡(luò)七層模型
應(yīng)用層
提供網(wǎng)絡(luò)管理纯陨、文件傳輸、事務(wù)處理,Telnet、FTP翼抠、HTTP咙轩、SNMP、DNS,HTTPS.在這里稍微解釋下.
HTTP
http0.9 是http協(xié)議的第一個版本,只有普通的get請求.
http1.0,引入post請求,讓HTML的表單可以提交表單.引入加入請求頭Header ,讓
既一次TCP連接后阴颖，可以多次通信活喊，雖然HTTP1.0 默認是傳輸一次數(shù)據(jù)后就關(guān)閉。http1.1,加入keep alive等.
HTTPS:加密數(shù)據(jù)傳輸
發(fā)起請求:通過443端口發(fā)起https請求
關(guān)于HTTPS,這里有一篇不錯的文章[傳送門]
宿主host:
(主機名) 加快域名解析,當進行DNS請求時,系統(tǒng)會自動檢查host文件是否有這個網(wǎng)絡(luò)域名映射關(guān)系量愧。如果有則钾菊，調(diào)用這個IP地址映射，如果沒有偎肃，再向已知的DNS服務(wù)器提出域名解析结缚。也就是說Hosts的請求級別比DNS高。
**DNS(Domain Name System) **
域名解析器,將域名和ip綁定
表示層
不同數(shù)據(jù)編碼格式的轉(zhuǎn)換软棺，提供數(shù)據(jù)壓縮红竭、解壓縮服務(wù)，對數(shù)據(jù)進行加密喘落、解密茵宪。例如圖像格式的顯示
會話層
將數(shù)據(jù)組合成數(shù)據(jù)Data,建立和維持對話.
傳輸層
將數(shù)據(jù)組合成段Segment,用tcp,udp等進行數(shù)據(jù)傳輸.
網(wǎng)絡(luò)層
分割和重新組合數(shù)據(jù)包Packet,基于網(wǎng)絡(luò)層地址IP,進行路徑選擇.例如路由器.
當前TCP/IP協(xié)議族:
IPv4的地址位數(shù)是32位,也就是說最多有2^32臺電腦可以連接到互聯(lián)網(wǎng).
IPv6采用128位地址長度，也就是2^128臺電腦可以連接.幾乎可以不受限制地提供地址.除此之外,還改善了IPv4中解決不好的問題,主要有端到端IP連接瘦棋、服務(wù)質(zhì)量（QoS）稀火、安全性、多播赌朋、移動性凰狞、即插即用等
ARP(Address Resolution Protocol) 地址解析協(xié)議(在IPv4)
數(shù)據(jù)鏈接層
在物理層上建立可靠的傳輸,單位是Frame.功能是:物理地址尋址,數(shù)據(jù)成幀,流量控制,數(shù)據(jù)監(jiān)測等.例如網(wǎng)橋,交換機.
協(xié)議包括:SDLC(sychronous Date Line Control),HDLC,PPP(Point-to-Point),STP等
物理層
是數(shù)據(jù)傳遞的實體,數(shù)據(jù)傳輸單位是bit,例如光纖,電纜等.
在介紹TCP之前,先說一下UDP和TCP的區(qū)別
UDP傳輸就類似于寫信，接收方事先并不知道你要寫信給他沛慢；
即無法判斷在傳輸過程中,會不會發(fā)生丟包,阻塞,等情況.TCP傳輸就像是打電話赡若，必須等對方按了接聽鍵你才能更他通話。
TCP報文有自己的檢測機制,檢驗团甲、序列號逾冬、確認應(yīng)答、重發(fā)控制躺苦、連接管理以及窗口控制等機制實現(xiàn)可靠性傳輸.
TCP協(xié)議的特點
TCP協(xié)議是一種面向連接的,基于字節(jié)流的傳輸層協(xié)議.TCP將用戶數(shù)據(jù)打成報文段(如下報文圖),在發(fā)送的時候啟動一個定時器,在另外一端接受的時候,對數(shù)據(jù)會進行確認,排序,去重復(根據(jù)序列號,確認號比較進行確認)等操作.應(yīng)用層的http,是使用TCP建立連接的.
如果想要充分讀懂TCP是如何收發(fā)包,以及序列號的,請點擊[傳送門]
TCP報文首部:
源端口號：數(shù)據(jù)發(fā)起者的端口號身腻，16bit
目的端口號：數(shù)據(jù)接收者的端口號，16bit
序號：32bit的序列號匹厘，由發(fā)送方使用,根據(jù)發(fā)送的字節(jié)數(shù)據(jù)變化
確認序號：32bit的確認號嘀趟，是接收數(shù)據(jù)方期望收到發(fā)送方的下一個報文段的序號，因此確認序號應(yīng)當是上次已成功收到數(shù)據(jù)字節(jié)序號加1愈诚。
首部長度：首部中32bit字的數(shù)目她按，可表示15*32bit=60字節(jié)的首部坡椒。一般首部長度為20字節(jié)。
保留：6bit, 均為0
緊急URG：當URG=1時尤溜，表示報文段中有緊急數(shù)據(jù)，應(yīng)盡快傳送汗唱。
確認比特ACK：ACK = 1時代表這是一個確認的TCP包宫莱，取值0則不是確認包。
推送比特PSH：當發(fā)送端PSH=1時哩罪，接收端盡快的交付給應(yīng)用進程授霸。
復位比特（RST）：當RST=1時，表明TCP連接中出現(xiàn)嚴重差錯际插，必須釋放連接碘耳，再重新建立連接。
同步比特SYN：在建立連接是用來同步序號框弛。SYN=1辛辨， ACK=0表示一個連接請求報文段。SYN=1瑟枫，ACK=1表示同意建立連接斗搞。
終止比特FIN：FIN=1時，表明此報文段的發(fā)送端的數(shù)據(jù)已經(jīng)發(fā)送完畢慷妙，并要求釋放傳輸連接僻焚。
窗口：用來控制對方發(fā)送的數(shù)據(jù)量，通知發(fā)放已確定的發(fā)送窗口上限膝擂。
檢驗和：該字段檢驗的范圍包括首部和數(shù)據(jù)這兩部分虑啤。由發(fā)端計算和存儲，并由收端進行驗證架馋。
緊急指針：緊急指針在URG=1時才有效狞山，它指出本報文段中的緊急數(shù)據(jù)的字節(jié)數(shù)。
選項：長度可變叉寂，最長可達40字節(jié)
HTTP請求流程
時間線流程
網(wǎng)絡(luò)層級關(guān)系
請求流程分析
解析域名(HOST/DNS)
- 一個域名 會首先訪問本地的Host文件,查看有沒有域名對應(yīng)的訪問ip的映射
- 如果有,就直接得到IP,如果沒有,就通過DNS根服務(wù)器,
- DNS根服務(wù)器會詢問.net域名服務(wù)器,有沒有此域名
- net域名服務(wù)器會查找blog.csdn.net是否存在
- 如果存在,就返回相應(yīng)的IP地址
- ARP協(xié)議解析ip對應(yīng)的物理地址,并加入到ARP緩存
- 進行TCP握手
三次握手
相互請求,相互確認的過程.
就像長途運貨車
你和總部說,我想運貨,
然后總部收到你的短信,給你回信說:恩,收到,去吧
你說,收到,馬上去.
在此先設(shè)定
SYN1表示客戶端的同步信號,ACK1表示客戶端的確認信號,FIN1表示客戶端對服務(wù)器信道停止信號
SYN2表示服務(wù)器的同步信號,ACK2表示服務(wù)器的確認信號,FIN2表示服務(wù)器對客戶端信道停止信號
SYN根據(jù)ACK的相應(yīng)而變化.使用確認號1響應(yīng)服務(wù)端的序列號0
序列號代表發(fā)送的數(shù)據(jù)編號,確認序列代表收到的數(shù)據(jù)編號.
序列號和確認序列在握手的時候發(fā)送的時候都會自動+1(說的不太恰當);
序列號為當前端成功發(fā)送的數(shù)據(jù)位數(shù)铣墨，確認號為當前端成功接收的數(shù)據(jù)位數(shù)，SYN標志位和FIN標志位也要占1位
第一次:
客戶端發(fā)起請求(發(fā)送SYN1=1,ACK1=0)到服務(wù)器,此時,服務(wù)器進入'SYN_SENT'(客戶端已經(jīng)提交SYN報文)狀態(tài),等待服務(wù)器響應(yīng).
第二次:
服務(wù)器收到SYN包,確認客戶端的SYN包而生成ACK(ACK=j+1)包,還有自己的一個請求編號SYN
(SYN=k), 即發(fā)送SYN+ACK包(發(fā)送SYN2=0,ACK2=1)到客戶端.此時,服務(wù)器進入'SYN_RECV'狀態(tài).
第三次:
客戶端收到服務(wù)器的SYN+ACK包,然后,自己向服務(wù)器發(fā)送確認包ACK(發(fā)送SYN1=0+1,ACK1=0+1=1),此時,服務(wù)器進入'ESTABLISHED'(鏈接成功)狀態(tài),完成三次握手
(連接完成狀態(tài)表示為SYN1=1,ACK1=1,SYN2=1,ACK2=1).
數(shù)據(jù)傳輸過程
第四次(客戶端請求服務(wù)器發(fā)出的有效數(shù)據(jù)包)
這是流中第一個攜帶有效數(shù)據(jù)的包（確切的說办绝，是客戶端發(fā)送的HTTP請求）伊约，序列號依然為1，因為到上個包為止孕蝉，還沒有發(fā)送任何數(shù)據(jù)屡律，確認號也保持1不變，因為客戶端沒有從服務(wù)端接收到任何數(shù)據(jù)
需要注意的是降淮，包中有效數(shù)據(jù)的長度為125字節(jié),但是一共有125+1個數(shù)據(jù),因為序列號也占用字節(jié).
服務(wù)端的序列號為1.確認號為1,TCP客戶端的序列號為126.確認號為1
第五次(服務(wù)器得到包,并處理得到的數(shù)據(jù))
當上層處理HTTP請求時超埋，服務(wù)端發(fā)送該包來確認客戶端在包4中發(fā)來的數(shù)據(jù)搏讶，需要注意的是，確認號的值增加了125（125是包4中有效數(shù)據(jù)長度）霍殴，變?yōu)?26媒惕，
服務(wù)端以此來告知客戶端端，目前為止来庭，我總共收到了126字節(jié)的數(shù)據(jù)妒蔚，服務(wù)端的序列號保持為1不變
服務(wù)端的序列號為1.確認號為126,TCP客戶端的序列號仍為126.確認號為1
第六次(服務(wù)器發(fā)出數(shù)據(jù)包)
這個包標志著服務(wù)端返回HTTP響應(yīng)的開始，序列號依然為1月弛，因為服務(wù)端在該包之前返回的包中都不帶有有效數(shù)據(jù)肴盏，該包帶有512字節(jié)的有效數(shù)據(jù).
服務(wù)端的序列號為513.確認號為126,TCP客戶端的序列號仍為126.確認號為1
第七次(客戶端接受數(shù)據(jù)包)
客戶端接收到數(shù)據(jù).到此為止,一次tcp的短連接,一次網(wǎng)絡(luò)請求完成().
當tcp進行長鏈接的時候,會不斷地相互增長.
服務(wù)端的序列號為513.確認號為126,TCP客戶端的序列號仍為126.確認號為1+513=514
連接終止協(xié)議(四次揮手)
第一次:
TCP的客戶端發(fā)送一個FIN(FIN=1),用來關(guān)閉客戶到服務(wù)器的數(shù)據(jù)傳輸.
此時,將標志位FIN1=1.
服務(wù)端的序列號為513.確認號為126,TCP客戶端的序列號仍為126+1.確認號為514
第二次:
服務(wù)器收到這個FIN，它發(fā)出一個ACK2=1帽衙，確認序號為收到的序號加1菜皂。和SYN一樣，一個FIN將占用一個序號厉萝。
此時,FIN1=1,ACK2=1,通道1關(guān)閉,服務(wù)器確定
服務(wù)端的序列號為513.確認號為126+1=127,TCP客戶端的序列號仍為126.確認號為514
第三次:
服務(wù)器關(guān)閉客戶端連接,發(fā)一個FIN2=1的標志位給客戶端,
此時,將標志位FIN1=1,FIN2=1.ACK2=1,通道1,2關(guān)閉,服務(wù)器確定
服務(wù)端的序列號為513.確認號為126+1=127,TCP客戶端的序列號仍為126.確認號為514
第四次:
客戶端發(fā)回ACK1=1報文確認恍飘，并將確認序號設(shè)置為收到序號加1。
此時,FIN1=1,ACK2=1,ACK1=1,ACK2=1,通道1,2關(guān)閉,客戶端確認,服務(wù)端確認.連接關(guān)閉
服務(wù)端的序列號為513.確認號為126+1+1=128,TCP客戶端的序列號為126+1=127(最終序列號).確認號為514
附軟件截圖
總結(jié)
1.正常網(wǎng)絡(luò)連接的實質(zhì)都是TCP連接下的bit流的傳輸(沒有考慮UDP等).
2.一個網(wǎng)絡(luò)請求,過程復雜,需要跨過網(wǎng)關(guān),解析域名,TCP握手,各種緩存策略,協(xié)議和報文等機制復雜.
3.HTTP協(xié)議,所有信息都是公開的,容易被第三方獲取.HTTPS運用了SSL加密,對稱,非對稱,hash加密等.
4.三次握手的意義在于,雙方都進行了確認后再代開連接,防止已經(jīng)鏈接失效,或者因為網(wǎng)絡(luò)延時造成的重復分組.造成建立新的tcp鏈接,造成service一直等待,浪費資源.
5.四次揮手的原因是,TCP是全雙工,因此每個方向都必須單獨關(guān)閉.收到一個FIN,代表這個信道,在此之后不會傳輸數(shù)據(jù).但是一個TCP連接在發(fā)出FIN之前,收到一個FIN后仍能發(fā)送數(shù)據(jù).
6.協(xié)議在不斷地更新?lián)Q代,效率越來越高!
