TCP/IP協(xié)議族
計(jì)算機(jī)與網(wǎng)絡(luò)設(shè)備要相互通信，雙方就必須基于相同的方法。如何探測(cè)到通信目標(biāo)、由那一邊現(xiàn)發(fā)起通信、使用哪種語(yǔ)言、使用那種操作系統(tǒng)、怎樣結(jié)束通信等都需要事先確定。不同的硬件、操作系統(tǒng)之間的相互通信，所有的這一切都需要一種規(guī)則。而我們就把這種規(guī)則稱(chēng)為協(xié)議。而與互聯(lián)網(wǎng)相關(guān)聯(lián)的協(xié)議集合起來(lái)總稱(chēng)為T(mén)CP/IP協(xié)議族。
TCP/IP的分層管理
TCP/IP協(xié)議族里最重要的一點(diǎn)就是分層。TCP/IP協(xié)議族暗層次可以氛圍以下五層：應(yīng)用層、傳輸層、網(wǎng)絡(luò)層、數(shù)據(jù)鏈路層、實(shí)體層。
把TCP/IP層次化的好處有很多。比如，如果互聯(lián)網(wǎng)只由一個(gè)協(xié)議統(tǒng)籌，某個(gè)地方需要改變?cè)O(shè)計(jì)時(shí)，就必須把所有部分整體替換掉。而分成之后只需把改變的曾替換掉即可。八個(gè)層之間的接口部分規(guī)劃好之后，每個(gè)層次內(nèi)部的設(shè)計(jì)就能夠自由改動(dòng)了。
實(shí)體層
實(shí)體層就是把電腦連接起來(lái)的物理手段，它主要規(guī)定了網(wǎng)絡(luò)的一些電氣特性。
鏈接層
用來(lái)處理連接網(wǎng)絡(luò)的硬件部分。包括控制操作系統(tǒng)、硬件的設(shè)備驅(qū)動(dòng)、NIC（Network Interface Card，網(wǎng)絡(luò)適配器，即網(wǎng)卡），及光纖等物理可見(jiàn)部分。硬件上的范疇均在鏈路層的作用范圍之內(nèi)。
1.以太網(wǎng)協(xié)議
早起的時(shí)候，每家公司都有自己的電信號(hào)分組方式。逐漸的，一種叫做以太網(wǎng)的協(xié)議，占據(jù)了主導(dǎo)地位。
以太網(wǎng)協(xié)議規(guī)定，一組電信號(hào)構(gòu)成一個(gè)數(shù)據(jù)包，叫做楨（frame）。每一幀分成兩個(gè)部分：標(biāo)頭（Head）和數(shù)據(jù)（Data）?！皹?biāo)頭”包含數(shù)據(jù)的一些說(shuō)明項(xiàng)，比如發(fā)送者、接受者、數(shù)據(jù)類(lèi)型等；“數(shù)據(jù)”則是發(fā)送的具體內(nèi)容。
2.MAC地址
以太網(wǎng)規(guī)定，如網(wǎng)設(shè)備，必須有網(wǎng)卡接口。數(shù)據(jù)包必須是從一塊網(wǎng)卡，傳送到另一塊網(wǎng)卡。網(wǎng)卡的地址就是數(shù)據(jù)包的發(fā)送地址和接收地址，被稱(chēng)為MAC地址。
3.廣播
如何從一塊網(wǎng)卡獲知另一塊網(wǎng)卡地址，首先采用的是一種ARP協(xié)議（Address Resolution Protocol）獲取對(duì)應(yīng)的MAC地址，然后以太網(wǎng)采用了一種很原始的方式，向所有的本網(wǎng)內(nèi)所有計(jì)算機(jī)發(fā)送，讓每臺(tái)計(jì)算機(jī)自己判斷對(duì)應(yīng)的MAC地址是否與自己一樣，如果一樣，就接受這個(gè)包，做進(jìn)一步處理，負(fù)責(zé)就丟棄這個(gè)包。這種發(fā)送方式就叫做廣播（Broadcasting）。
在同一局域網(wǎng)內(nèi)，PC1發(fā)送的數(shù)據(jù)包以廣播的形式進(jìn)行發(fā)送，當(dāng)匹配對(duì)象PC2接收到請(qǐng)求之后，就可以將PC1的IP和MAC映射信息存儲(chǔ)在本地的【ARP緩存表】，既然知道PC1在哪里，就可以返回ARP單播回應(yīng)包。
網(wǎng)絡(luò)層
互聯(lián)網(wǎng)是無(wú)數(shù)個(gè)子網(wǎng)絡(luò)共同組成的一個(gè)巨型網(wǎng)絡(luò)，如果在同一個(gè)子網(wǎng)絡(luò)，就采用廣播的方式發(fā)送，否則就采用路由方式發(fā)送。這就導(dǎo)致了網(wǎng)絡(luò)層的誕生。他的作用是引進(jìn)一套新的地址，使得我們能夠區(qū)分不同的計(jì)算機(jī)是否屬于同一個(gè)子網(wǎng)絡(luò)。這套地址就叫做"網(wǎng)絡(luò)地址"，簡(jiǎn)稱(chēng)"網(wǎng)址"。
網(wǎng)絡(luò)層用來(lái)處理在網(wǎng)絡(luò)上流動(dòng)的數(shù)據(jù)包。數(shù)據(jù)包是網(wǎng)絡(luò)層傳輸?shù)淖钚?shù)據(jù)單位。該層規(guī)定了通過(guò)怎樣的路徑到達(dá)對(duì)方計(jì)算機(jī)，并把數(shù)據(jù)傳送給對(duì)方。
1.IP協(xié)議
IP協(xié)議的作用是把各種數(shù)據(jù)包傳送給對(duì)方。而要確保數(shù)據(jù)確實(shí)發(fā)送到對(duì)方哪里，則需要滿(mǎn)足各類(lèi)條件。其中最主要的條件是IP地址和MAC地址。IP地址指明了節(jié)點(diǎn)被分配到的地址，MAC是網(wǎng)卡所屬的固定地址。 IP地址可更換，但MAC地址基本上不會(huì)更改。
互聯(lián)網(wǎng)上的每一臺(tái)計(jì)算機(jī)，都會(huì)分配一個(gè)IP地址。這個(gè)地址分為兩部分，前一部分代表網(wǎng)絡(luò)，后一部分代表主機(jī)。判斷兩臺(tái)計(jì)算機(jī)是否屬于同一個(gè)子網(wǎng)絡(luò)，需要用到另一個(gè)參數(shù)子網(wǎng)掩碼，它是一個(gè)32位地址，它只有一個(gè)作用，就是將某個(gè)IP地址劃分成網(wǎng)絡(luò)地址和主機(jī)地址兩部分，如果兩臺(tái)電腦的網(wǎng)絡(luò)地址部分相同，則可以判定他們?cè)谕粋€(gè)子網(wǎng)絡(luò)。
2.ARP協(xié)議
IP間的通信依賴(lài)MAC地址。在網(wǎng)絡(luò)上，通信雙方不在同一局域網(wǎng)內(nèi)，事實(shí)上沒(méi)有辦法得到對(duì)方的MAC地址，只能把數(shù)據(jù)包傳送到兩個(gè)子網(wǎng)絡(luò)連接處的"網(wǎng)關(guān)"（gateway），讓網(wǎng)關(guān)去處理。而在同一局域網(wǎng)內(nèi)，我們可以使用ARP協(xié)議（Address Resolution Protocol），獲取對(duì)方的MAC地址。ARP是一種用以解析地址的協(xié)議，根據(jù)通信方的IP地址就可以反查處對(duì)應(yīng)的MAC地址。
3.IMCP協(xié)議
IP協(xié)議并不是一個(gè)可靠的協(xié)議，它不保證數(shù)據(jù)被送達(dá)，那么，自然的，保證數(shù)據(jù)送達(dá)的工作應(yīng)該由其他的模塊來(lái)完成。其中一個(gè)重要的模塊就是ICMP(網(wǎng)絡(luò)控制報(bào)文)協(xié)議。當(dāng)傳送IP數(shù)據(jù)包發(fā)生錯(cuò)誤——比如主機(jī)不可達(dá)，路由不可達(dá)等等，ICMP協(xié)議將會(huì)把錯(cuò)誤信息封包，然后傳送回給主機(jī)。給主機(jī)一個(gè)處理錯(cuò)誤的機(jī)會(huì)，這也就是為什么說(shuō)建立在IP層以上的協(xié)議是可能做到安全的原因。
傳輸層
傳輸層對(duì)上層應(yīng)用層，提供處于網(wǎng)絡(luò)連接中的兩臺(tái)計(jì)算機(jī)之間的數(shù)據(jù)傳輸。在同一個(gè)電腦中接收到發(fā)送給不同軟件的數(shù)據(jù)包，則需要依靠端口（port）來(lái)區(qū)分是發(fā)給具體某個(gè)軟件，它其實(shí)是一個(gè)網(wǎng)卡的程序編號(hào)。傳輸層的功能就是建立在“端口到端口”的通信。在傳輸層有兩個(gè)性質(zhì)不同的協(xié)議：TCP（Transmission Protocol，傳輸控制協(xié)議）和UDP（User Data Protocol，用戶(hù)數(shù)據(jù)報(bào)協(xié)議）。
TCP協(xié)議
tcp是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。是專(zhuān)門(mén)為了在不可靠的互聯(lián)網(wǎng)絡(luò)上提供一個(gè)可靠的端到端字節(jié)流而設(shè)計(jì)的，面向字節(jié)流。TCP協(xié)議將大快數(shù)據(jù)分割成報(bào)文段（segment）為單位的數(shù)據(jù)包進(jìn)行管理，為了確保無(wú)誤的將數(shù)據(jù)發(fā)送到目標(biāo)處，TCP協(xié)議采用了三次握手（three-way handshaking）策略。握手中使用了TCP的標(biāo)志（flag）-SYN（synchronize）、ACK（acknowledgement）和seq（sequence）。
TCP三次握手過(guò)程
第一次握手：客戶(hù)端發(fā)送一個(gè)含有同步序列號(hào)的標(biāo)志位給服務(wù)器請(qǐng)求建立連接，同時(shí)客戶(hù)端進(jìn)入SYN_SENT狀態(tài)。發(fā)送報(bào)文的同時(shí)也啟動(dòng)一個(gè)定時(shí)器，等待服務(wù)器確認(rèn)收到這個(gè)報(bào)文段，如果不能及時(shí)收到一個(gè)確認(rèn)，將重新發(fā)送這個(gè)報(bào)文段。這次握手總共做了兩件事：我要和你通信、你可以用seq=x作為起始數(shù)據(jù)段來(lái)回應(yīng)我。
第二次握手：服務(wù)端收到這個(gè)報(bào)文段，需要對(duì)報(bào)文段進(jìn)行確認(rèn)，設(shè)置ACK=x+1，seq=y，讓客戶(hù)端以這個(gè)序列號(hào)作為起始數(shù)據(jù)段來(lái)進(jìn)行回應(yīng)，這時(shí)服務(wù)器進(jìn)入SYN_RECV狀態(tài)。這次握手總共做了兩件事：你可以和我通信、你可以用seq=y作為起始數(shù)據(jù)段來(lái)回應(yīng)我。
第三次握手：客戶(hù)端收到服務(wù)器的確認(rèn)報(bào)文段，會(huì)先進(jìn)性確認(rèn)，如果收到的報(bào)文檢驗(yàn)有差錯(cuò)，那么就會(huì)丟棄這個(gè)報(bào)文段，如果檢驗(yàn)無(wú)誤，則會(huì)對(duì)服務(wù)器進(jìn)行回復(fù)，設(shè)置ACK=Y+1。這時(shí)客戶(hù)端與服務(wù)端都進(jìn)入ESTABLISHED狀態(tài)，完成TCP三次握手。
若握手過(guò)程中某個(gè)階段莫名中斷，TCP協(xié)議會(huì)再次以相同順序發(fā)送相同的數(shù)據(jù)包。
TCP四次分手
第一次分手：當(dāng)客戶(hù)端完成數(shù)據(jù)傳輸后，會(huì)對(duì)服務(wù)器發(fā)送一個(gè)FIN報(bào)文段，客戶(hù)端進(jìn)入FIN_WAIT_1狀態(tài)。表明數(shù)據(jù)發(fā)送結(jié)束。
第二次分手：服務(wù)器收到客戶(hù)端發(fā)送來(lái)的FIN報(bào)文段，會(huì)返回一個(gè)ACK報(bào)文段，ACK加一，客戶(hù)端進(jìn)入FIN_WAIT_2狀態(tài)，意思就是我同意你的關(guān)閉請(qǐng)求。
第三次分手：服務(wù)器向客戶(hù)端發(fā)送FIN報(bào)文段，請(qǐng)求關(guān)閉連接， 服務(wù)器進(jìn)入LAST_ACK狀態(tài)。
第四次分手：客戶(hù)端收到服務(wù)器發(fā)送的FIN狀態(tài)，會(huì)向服務(wù)器發(fā)送ACK報(bào)文段，ACK加一，客戶(hù)端進(jìn)入TIME_WAIT狀態(tài)，服務(wù)器收到ACK報(bào)文段后，就關(guān)閉連接；此時(shí)，客戶(hù)端等待2MSL后依然沒(méi)有收到回復(fù)，則證明服務(wù)器已正常關(guān)閉，那好，客戶(hù)端也可以關(guān)閉連接了。
客戶(hù)端應(yīng)用程序的狀態(tài)遷移圖
CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED
服務(wù)器的狀態(tài)遷移圖
CLOSED->LISTEN->SYN_RECE->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED
UDP協(xié)議
UDP 是一種面向無(wú)連接，且不可靠的協(xié)議，在通信過(guò)程中，它并不像 TCP 那樣需要先建立一個(gè)連接，只要（目的地址，端口號(hào)，源地址，端口號(hào)）確定了，就可以直接發(fā)送信息報(bào)文，并且不需要確保服務(wù)端一定能收到或收到完整的數(shù)據(jù)。它僅僅提供了校驗(yàn)和機(jī)制來(lái)保障一個(gè)報(bào)文是否完整，若校驗(yàn)失敗，則直接丟棄報(bào)文，不做任何處理。
TCP與UD片間的區(qū)別
1、tcp是面向連接的，可靠性高；udp是無(wú)連接的，可靠性較低；
2、由于tcp是連接的通信，需要有三次握手、重新確認(rèn)等連接過(guò)程，會(huì)有延時(shí)，實(shí)時(shí)性差；同時(shí)過(guò)程復(fù)雜，也使其易于被攻擊；而udp無(wú)連接，無(wú)建立連接的過(guò)程，因而實(shí)時(shí)性較強(qiáng)，也稍安全；
3、在傳輸相同大小的數(shù)據(jù)時(shí)，tcp首部開(kāi)銷(xiāo)20字節(jié)；udp首部開(kāi)銷(xiāo)只有8個(gè)字節(jié)，tcp報(bào)頭比udp復(fù)雜，故實(shí)際包含的用戶(hù)數(shù)據(jù)較少。tcp無(wú)丟包，而udp有丟包（注：網(wǎng)速的提升導(dǎo)致現(xiàn)在丟包率很低），故tcp開(kāi)銷(xiāo)大，udp開(kāi)銷(xiāo)較??；
4、每條tcp連接只能是點(diǎn)到點(diǎn)的；udp支持一對(duì)一、一對(duì)多、多對(duì)一、多對(duì)多的交互通信。
5、TCP對(duì)系統(tǒng)資源要求較多，UDP對(duì)系統(tǒng)資源要求較少
采用TCP，一旦發(fā)生丟包，TCP會(huì)將后續(xù)的包緩存起來(lái)，等前面的包重傳并接收到后再繼續(xù)發(fā)送，延時(shí)會(huì)越來(lái)越大，基于UDP對(duì)實(shí)時(shí)性要求較為嚴(yán)格的情況下，采用自定義重傳機(jī)制（注：UDP本身并不具有重傳機(jī)制），能夠把丟包產(chǎn)生的延遲降到最低，盡量減少網(wǎng)絡(luò)問(wèn)題對(duì)游戲性造成影響。如果對(duì)實(shí)時(shí)性要求高和高速傳輸?shù)膱?chǎng)合下需要使用udp；如果需要傳輸大量數(shù)據(jù)且對(duì)可靠性要求高的情況下應(yīng)該使用tcp；在可靠性要求較低，追求效率的情況下應(yīng)該使用udp。
應(yīng)用層
應(yīng)用層決定了向用戶(hù)提供應(yīng)用服務(wù)時(shí)通信的活動(dòng)。TCP/IP協(xié)議族內(nèi)預(yù)存了各類(lèi)通用的應(yīng)用服務(wù)。比如，F(xiàn)TP（File Transfer Protocol，文件傳輸協(xié)議）和DNS服務(wù)（Domain Name System，域名系統(tǒng)）服務(wù)就是其中兩類(lèi)。而HTTP協(xié)議也處于該層。
DNS
DNS（Domain Name System）服務(wù)提供了域名到IP地址之間的解析服務(wù)。計(jì)算機(jī)可以被賦予IP地址，也可以被賦予主機(jī)名和域名。比如www.18yk.com。我們通常使用主機(jī)名或者域名來(lái)訪問(wèn)對(duì)方的計(jì)算機(jī)，而不是直接通過(guò)IP地址訪問(wèn)。這就需要DNS服務(wù)來(lái)為我們將它們轉(zhuǎn)換成IP地址，DNS協(xié)議通過(guò)域名的查找IP地址，會(huì)逆向從IP地址反差域名服務(wù)。
HTTP協(xié)議
HTTP（Hyper Text Transfer Protocol）超文本傳輸協(xié)議，是一種建立在TCP上的無(wú)狀態(tài)連接，也是我們?nèi)粘Ｓ玫淖疃嗟囊环N協(xié)議。
URI
URI（Uniform Resource Identifier）統(tǒng)一資源標(biāo)識(shí)符，RFC2396分別對(duì)這 3 個(gè)單詞進(jìn)行了如下定義：
Uniform ：規(guī)定統(tǒng)一的格式可方便處理多種不同類(lèi)型的資源， 而不用根據(jù)上下文環(huán)境來(lái)識(shí)別資源指定的訪問(wèn)方式。另外， 加入新增的協(xié)議方案（如http:或ftp:） 也更容易。
Resource ：資源的定義是可標(biāo)識(shí)的任何東西。 除了文檔文件、 圖像或服務(wù)（例如當(dāng)天的天氣預(yù)報(bào)） 等能夠區(qū)別于其他類(lèi)型的， 全都可作為資源。 另外， 資源不僅可以是單一的， 也可以是多數(shù)的集合體。
Identifier ：表示可標(biāo)識(shí)的對(duì)象。 也稱(chēng)為標(biāo)識(shí)符。
RFC3986列舉了幾種URI的常用語(yǔ)法格式：
1.tp://ftp.is.co.za/rfc/rfc1808.txt
2.http://www.ietf.org/rfc/rfc2396.txt
3.ldap://[2001:db8::7]/c=GB?objectClass?one
5.news:comp.infosystems.www.servers.unix
6.tel:+1-816-555-1212
7.telnet://192.0.2.16:80/
8.urn:oasis:names:specification:docbook:dtd:xml:4.1.2
TCP/IP通信傳輸流
利用TCP/IP協(xié)議族進(jìn)行網(wǎng)絡(luò)通信時(shí)，會(huì)通過(guò)分層順序與對(duì)方進(jìn)行通信。發(fā)送端從應(yīng)用層往下走，接收段則往應(yīng)用層上走。以HTTP舉例說(shuō)明：
發(fā)送端
首先作為發(fā)送端的客戶(hù)端在應(yīng)用層（HTTP協(xié)議）發(fā)出一個(gè)想看某個(gè)Web頁(yè)面的HTTP請(qǐng)求。為了傳輸方便，在傳輸層（TCP協(xié)議）把從應(yīng)用層收到的數(shù)據(jù)（THTTP請(qǐng)求報(bào)文）進(jìn)行分割，并根據(jù)各個(gè)報(bào)文上打上標(biāo)記序號(hào)及端口號(hào)后轉(zhuǎn)發(fā)給網(wǎng)絡(luò)層。在網(wǎng)絡(luò)層（IP協(xié)議），增加作為通信目的地的MAC地址后轉(zhuǎn)送給鏈路層。這樣一個(gè)網(wǎng)絡(luò)通信請(qǐng)求就準(zhǔn)備齊全了。
接收端
接受端的服務(wù)器在鏈路層接收到數(shù)據(jù)，按順序往上層發(fā)送，一直到應(yīng)用層。當(dāng)傳輸?shù)綉?yīng)用層才算真正接收到由客戶(hù)端發(fā)送過(guò)來(lái)的HTTP請(qǐng)求。
發(fā)送端在層與層之間傳輸數(shù)據(jù)時(shí)，每經(jīng)過(guò)一層時(shí)必定會(huì)被打上一個(gè)該層所屬的首部信息。反之。接收段在層與層傳輸數(shù)據(jù)時(shí)，每經(jīng)過(guò)一層會(huì)把對(duì)應(yīng)的首部消去。而這種把數(shù)據(jù)信息包裝起來(lái)的做法被稱(chēng)為封裝（encapsulate）。
感言：到這里TCP/IP協(xié)議族就暫時(shí)告一亂落。寫(xiě)作的目的主要是最近在閱讀《圖解HTTP》這本書(shū)籍時(shí)產(chǎn)生了一些心的，并通過(guò)在網(wǎng)上查找相關(guān)資料進(jìn)行整理總結(jié)，將之記錄下來(lái)，與大家共享，也方便以后自己查閱。若其中有何錯(cuò)誤漏洞，請(qǐng)大家不吝賜教。
參考資料1:https://blog.csdn.net/u011957758/article/details/72353485
參考資料2:http://www.itdecent.cn/p/0cf648510bce
參考資料3:http://www.ruanyifeng.com/blog/2012/05/internet_protocol_suite_part_i.html
--------------------- 作者：蝸牛非牛 來(lái)源：CSDN 原文：https://blog.csdn.net/qq_34003239/article/details/82992495?utm_source=copy 版權(quán)聲明：本文為博主原創(chuàng)文章，轉(zhuǎn)載請(qǐng)附上博文鏈接！
