太棒了！TCP/IP协议 （图解+秒懂+史上最全）
TCP/IP協(xié)議的分層模型
在展開介紹TCP/IP協(xié)議之前，首先介紹一下七層ISO模型。國際標(biāo)準(zhǔn)化組織ISO為了使網(wǎng)絡(luò)應(yīng)用更為普及，推出了OSI參考模型，即開放式系統(tǒng)互聯(lián)（Open
System Interconnect）模型，
一般都叫OSI參考模型。OSI參考模型是ISO組織在1985年發(fā)布的網(wǎng)絡(luò)互連模型，其含義就是為所有公司使用一個統(tǒng)一的規(guī)范來控制網(wǎng)絡(luò)，這樣所有公司遵循相同的通信規(guī)范，網(wǎng)絡(luò)就能互聯(lián)互通了。
OSI模型的七層框架
OSI模型定義了網(wǎng)絡(luò)互連的七層框架（物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層、會話層、表示層、應(yīng)用層），每一層實(shí)現(xiàn)各自的功能和協(xié)議，并完成與相鄰層的接口通信。OSI模型各層的通信協(xié)議，大致舉例如下表所示：
表：OSI模型各層的通信協(xié)議舉例
| 應(yīng)用層 | HTTP、SMTP、SNMP、FTP、Telnet、SIP、SSH、NFS、RTSP、XMPP、Whois、ENRP、等等 |
| 表示層 | XDR、ASN.1、SMB、AFP、NCP、等等 |
| 會話層 | ASAP、SSH、RPC、NetBIOS、ASP、Winsock、BSD Sockets、等等 |
| 傳輸層 | TCP、UDP、TLS、RTP、SCTP、SPX、ATP、IL、等等 |
| 網(wǎng)絡(luò)層 | IP、ICMP、IGMP、IPX、BGP、OSPF、RIP、IGRP、EIGRP、ARP、RARP、X.25、等等 |
| 數(shù)據(jù)鏈路層 | 以太網(wǎng)、令牌環(huán)、HDLC、幀中繼、ISDN、ATM、IEEE 802.11、FDDI、PPP、等等 |
| 物理層 | 例如銅纜、網(wǎng)線、光纜、無線電等等 |
TCP/IP協(xié)議是Internet互聯(lián)網(wǎng)最基本的協(xié)議，其在一定程度上參考了七層ISO模型。OSI模型共有七層，從下到上分別是物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、運(yùn)輸層、會話層、表示層和應(yīng)用層。但是這顯然是有些復(fù)雜的，所以在TCP/IP協(xié)議中，七層被簡化為了四個層次。TCP/IP模型中的各種協(xié)議，依其功能不同，被分別歸屬到這四層之中，常被視為是簡化過后的七層OSI模型。
TCP/IP協(xié)議與七層ISO模型的對應(yīng)關(guān)系
TCP/IP協(xié)議與七層ISO模型的對應(yīng)關(guān)系，大致如下圖所示：
圖：TCP/IP協(xié)議與七層ISO模型的對應(yīng)關(guān)系
TCP/IP協(xié)議的應(yīng)用層的主要協(xié)議有HTTP、Telnet、FTP、SMTP等，是用來讀取來自傳輸層的數(shù)據(jù)或者將數(shù)據(jù)傳輸寫入傳輸層；傳輸層的主要協(xié)議有UDP、TCP，實(shí)現(xiàn)端對端的數(shù)據(jù)傳輸；網(wǎng)絡(luò)層的主要協(xié)議有ICMP、IP、IGMP，主要負(fù)責(zé)網(wǎng)絡(luò)中數(shù)據(jù)包的傳送等；鏈路層有時也稱作數(shù)據(jù)鏈路層或網(wǎng)絡(luò)接口層，主要協(xié)議有ARP、RARP，
通常包括操作系統(tǒng)中的設(shè)備驅(qū)動程序和計(jì)算機(jī)中對應(yīng)的網(wǎng)絡(luò)接口卡，它們一起處理與傳輸媒介（如電纜或其他物理設(shè)備）的物理接口細(xì)節(jié)。
（一）TCP/IP協(xié)議的應(yīng)用層
應(yīng)用層包括所有和應(yīng)用程序協(xié)同工作，并利用基礎(chǔ)網(wǎng)絡(luò)交換應(yīng)用程序的業(yè)務(wù)數(shù)據(jù)的協(xié)議。一些特定的程序被認(rèn)為運(yùn)行在這個層上，該層協(xié)議所提供的服務(wù)能直接支持用戶應(yīng)用。應(yīng)用層協(xié)議包括HTTP（萬維網(wǎng)服務(wù)）、FTP（文件傳輸）、SMTP（電子郵件）、SSH（安全遠(yuǎn)程登陸）、DNS（域名解析）以及許多其他協(xié)議。
（二）TCP/IP協(xié)議的傳輸層
傳輸層的協(xié)議，解決了諸如端到端可靠性問題，能確保數(shù)據(jù)可靠的到達(dá)目的地，甚至能保證數(shù)據(jù)按照正確的順序到達(dá)目的地。傳輸層的主要功能大致如下：
（1）為端到端連接提供傳輸服務(wù)；
（2）這種傳輸服務(wù)分為可靠和不可靠的，其中TCP是典型的可靠傳輸，而UDP則是不可靠傳輸；
（3）為端到端連接提供流量控制、差錯控制、QoS(Quality of
Service)服務(wù)質(zhì)量等管理服務(wù)。
傳輸層主要有兩個性質(zhì)不同的協(xié)議：TCP傳輸控制協(xié)議和UDP用戶數(shù)據(jù)報協(xié)議。
TCP協(xié)議是一個面向連接的、可靠的傳輸協(xié)議，它提供一種可靠的字節(jié)流，能保證數(shù)據(jù)完整、無損并且按順序到達(dá)。TCP盡量連續(xù)不斷地測試網(wǎng)絡(luò)的負(fù)載并且控制發(fā)送數(shù)據(jù)的速度以避免網(wǎng)絡(luò)過載。另外，TCP試圖將數(shù)據(jù)按照規(guī)定的順序發(fā)送。
UDP協(xié)議是一個無連接的數(shù)據(jù)報協(xié)議，是一個“盡力傳遞”和“不可靠”協(xié)議，不會對數(shù)據(jù)包是否已經(jīng)到達(dá)目的地進(jìn)行檢查，并且不保證數(shù)據(jù)包按順序到達(dá)。
總體來說，TCP協(xié)議傳輸效率低，但可靠性強(qiáng)；UDP協(xié)議傳輸效率高，但可靠性略低，適用于傳輸可靠性要求不高、體量小的數(shù)據(jù)（比如QQ聊天數(shù)據(jù)）。
（三）TCP/IP協(xié)議的網(wǎng)絡(luò)層
TCP/IP協(xié)議網(wǎng)絡(luò)層的作用是在復(fù)雜的網(wǎng)絡(luò)環(huán)境中為要發(fā)送的數(shù)據(jù)報找到一個合適的路徑進(jìn)行傳輸。簡單來說，網(wǎng)絡(luò)層負(fù)責(zé)將數(shù)據(jù)傳輸?shù)侥繕?biāo)地址，目標(biāo)地址可以是多個網(wǎng)絡(luò)通過路由器連接而成的某一個地址。另外，網(wǎng)絡(luò)層負(fù)責(zé)尋找合適的路徑到達(dá)對方計(jì)算機(jī)，并把數(shù)據(jù)幀傳送給對方，網(wǎng)絡(luò)層還可以實(shí)現(xiàn)擁塞控制、網(wǎng)際互連等功能。網(wǎng)絡(luò)層協(xié)議的代表包括：ICMP、IP、IGMP等。
（四）TCP/IP協(xié)議的鏈路層
鏈路層有時也稱作數(shù)據(jù)鏈路層或網(wǎng)絡(luò)接口層，用來處理連接網(wǎng)絡(luò)的硬件部分。該層既包括操作系統(tǒng)硬件的設(shè)備驅(qū)動、NIC（網(wǎng)卡）、光纖等物理可見部分，還包括連接器等一切傳輸媒介。在這一層，數(shù)據(jù)的傳輸單位為比特。其主要協(xié)議有ARP、RARP等。
圖解 物理層：使用MAC解決設(shè)備的身份證問題
通信的原始時代
很久很久之前，你不與任何其他電腦相連接，孤苦伶仃。
直到有一天，你希望與另一臺電腦 B 建立通信，于是你們各開了一個網(wǎng)口，用一根網(wǎng)線連接了起來。
用一根網(wǎng)線連接起來怎么就能"通信"了呢？我可以給你講 IO、講中斷、講緩沖區(qū)，但這不是研究網(wǎng)絡(luò)時該關(guān)心的問題。
如果你糾結(jié)，要么去研究一下操作系統(tǒng)是如何處理網(wǎng)絡(luò) IO 的，要么去研究一下包是如何被網(wǎng)卡轉(zhuǎn)換成電信號發(fā)送出去的，要么就僅僅把它當(dāng)做電腦里有個小人在開槍吧~
反正，你們就是連起來了，并且可以通信。
有一天，一個新伙伴 C 加入了，但聰明的你們很快發(fā)現(xiàn)，可以每個人開兩個網(wǎng)口，用一共三根網(wǎng)線，彼此相連。
隨著越來越多的人加入，你發(fā)現(xiàn)身上開的網(wǎng)口實(shí)在太多了，而且網(wǎng)線密密麻麻，混亂不堪。（而實(shí)際上一臺電腦根本開不了這么多網(wǎng)口，所以這種連線只在理論上可行，所以連不上的我就用紅色虛線表示了，就是這么嚴(yán)謹(jǐn)哈哈~）
集線器的誕生
于是你們發(fā)明了一個中間設(shè)備，你們將網(wǎng)線都插到這個設(shè)備上，由這個設(shè)備做轉(zhuǎn)發(fā)，就可以彼此之間通信了，本質(zhì)上和原來一樣，只不過網(wǎng)口的數(shù)量和網(wǎng)線的數(shù)量減少了，不再那么混亂。
你給它取名叫集線器，它僅僅是無腦將電信號轉(zhuǎn)發(fā)到所有出口（廣播），不做任何處理，你覺得它是沒有智商的，因此把人家定性在了物理層。
由于轉(zhuǎn)發(fā)到了所有出口，那 BCDE 四臺機(jī)器怎么知道數(shù)據(jù)包是不是發(fā)給自己的呢？
首先，你要給所有的連接到交換機(jī)的設(shè)備，都起個名字。原來你們叫 ABCD，但現(xiàn)在需要一個更專業(yè)的，全局唯一的名字作為標(biāo)識，你把這個更高端的名字稱為?MAC 地址。
你的 MAC 地址是 aa-aa-aa-aa-aa-aa，你的伙伴 b 的 MAC 地址是 bb-bb-bb-bb-bb-bb，以此類推，不重復(fù)就好。
這樣，A 在發(fā)送數(shù)據(jù)包給 B 時，只要在頭部拼接一個這樣結(jié)構(gòu)的數(shù)據(jù)，就可以了。
B 在收到數(shù)據(jù)包后，根據(jù)頭部的目標(biāo) MAC 地址信息，判斷這個數(shù)據(jù)包的確是發(fā)給自己的，于是便收下。
其他的 CDE 收到數(shù)據(jù)包后，根據(jù)頭部的目標(biāo) MAC 地址信息，判斷這個數(shù)據(jù)包并不是發(fā)給自己的，于是便丟棄。
雖然集線器使整個布局干凈不少，但原來我只要發(fā)給電腦 B 的消息，現(xiàn)在卻要發(fā)給連接到集線器中的所有電腦，這樣既不安全，又不節(jié)省網(wǎng)絡(luò)資源。
圖解 數(shù)據(jù)鏈路：使用交換機(jī)解決MAC 地址映射問題
集線器的問題
如果把這個集線器弄得更智能一些，只發(fā)給目標(biāo) MAC 地址指向的那臺電腦，就好了。
交換機(jī)的誕生
雖然只比集線器多了這一點(diǎn)點(diǎn)區(qū)別，但看起來似乎有智能了，你把這東西叫做交換機(jī)。也正因?yàn)檫@一點(diǎn)點(diǎn)智能，你把它放在了另一個層級，數(shù)據(jù)鏈路層。
如上圖所示，你是這樣設(shè)計(jì)的。
交換機(jī)內(nèi)部維護(hù)一張?MAC 地址表，記錄著每一個 MAC 地址的設(shè)備，連接在其哪一個端口上。
| MAC 地址 | 端口 |
| bb-bb-bb-bb-bb-bb | 1 |
| cc-cc-cc-cc-cc-cc | 3 |
| aa-aa-aa-aa-aa-aa | 4 |
| dd-dd-dd-dd-dd-dd | 5 |
假如你仍然要發(fā)給 B 一個數(shù)據(jù)包，構(gòu)造了如下的數(shù)據(jù)結(jié)構(gòu)從網(wǎng)口出去。
到達(dá)交換機(jī)時，交換機(jī)內(nèi)部通過自己維護(hù)的 MAC 地址表，發(fā)現(xiàn)目標(biāo)機(jī)器 B 的 MAC 地址 bb-bb-bb-bb-bb-bb 映射到了端口 1 上，于是把數(shù)據(jù)從 1 號端口發(fā)給了 B，完事~
你給這個通過這樣傳輸方式而組成的小范圍的網(wǎng)絡(luò)，叫做以太網(wǎng)。
當(dāng)然最開始的時候，MAC 地址表是空的，是怎么逐步建立起來的呢？
假如在 MAC 地址表為空是，你給 B 發(fā)送了如下數(shù)據(jù)
由于這個包從端口 4 進(jìn)入的交換機(jī)，所以此時交換機(jī)就可以在 MAC地址表記錄第一條數(shù)據(jù)：
MAC：aa-aa-aa-aa-aa-aa-aa
端口：4
交換機(jī)看目標(biāo) MAC 地址（bb-bb-bb-bb-bb-bb）在地址表中并沒有映射關(guān)系，于是將此包發(fā)給了所有端口，也即發(fā)給了所有機(jī)器。
之后，只有機(jī)器 B 收到了確實(shí)是發(fā)給自己的包，于是做出了響應(yīng)，響應(yīng)數(shù)據(jù)從端口 1 進(jìn)入交換機(jī)，于是交換機(jī)此時在地址表中更新了第二條數(shù)據(jù)：
MAC：bb-bb-bb-bb-bb-bb
端口：1
過程如下
經(jīng)過該網(wǎng)絡(luò)中的機(jī)器不斷地通信，交換機(jī)最終將 MAC 地址表建立完畢~
隨著機(jī)器數(shù)量越多，交換機(jī)的端口也不夠了，但聰明的你發(fā)現(xiàn)，只要將多個交換機(jī)連接起來，這個問題就輕而易舉搞定~
你完全不需要設(shè)計(jì)額外的東西，只需要按照之前的設(shè)計(jì)和規(guī)矩來，按照上述的接線方式即可完成所有電腦的互聯(lián)，所以交換機(jī)設(shè)計(jì)的這種規(guī)則，真的很巧妙。你想想看為什么（比如 A 要發(fā)數(shù)據(jù)給 F）。
但是你要注意，上面那根紅色的線，最終在 MAC 地址表中可不是一條記錄呀，而是要把 EFGH 這四臺機(jī)器與該端口（端口6）的映射全部記錄在表中。
MAC 地址和端口的映射記錄
最終，兩個交換機(jī)將分別記錄 A ~ H 所有機(jī)器的映射記錄。
左邊的交換機(jī)
| MAC 地址 | 端口 |
| bb-bb-bb-bb-bb-bb | 1 |
| cc-cc-cc-cc-cc-cc | 3 |
| aa-aa-aa-aa-aa-aa | 4 |
| dd-dd-dd-dd-dd-dd | 5 |
| ee-ee-ee-ee-ee-ee | 6 |
| ff-ff-ff-ff-ff-ff | 6 |
| gg-gg-gg-gg-gg-gg | 6 |
| hh-hh-hh-hh-hh-hh | 6 |
右邊的交換機(jī)
| MAC 地址 | 端口 |
| bb-bb-bb-bb-bb-bb | 1 |
| cc-cc-cc-cc-cc-cc | 1 |
| aa-aa-aa-aa-aa-aa | 1 |
| dd-dd-dd-dd-dd-dd | 1 |
| ee-ee-ee-ee-ee-ee | 2 |
| ff-ff-ff-ff-ff-ff | 3 |
| gg-gg-gg-gg-gg-gg | 4 |
| hh-hh-hh-hh-hh-hh | 6 |
這在只有 8 臺電腦的時候還好，甚至在只有幾百臺電腦的時候，都還好，所以這種交換機(jī)的設(shè)計(jì)方式，已經(jīng)足足支撐一陣子了。
但很遺憾，人是貪婪的動物，很快，電腦的數(shù)量就發(fā)展到幾千、幾萬、幾十萬。
圖解 傳輸層：IP地址和路由器
二層交換機(jī)的問題
交換機(jī)已經(jīng)無法記錄如此龐大的映射關(guān)系了。
此時你動了歪腦筋，你發(fā)現(xiàn)了問題的根本在于，連出去的那根紅色的網(wǎng)線，后面不知道有多少個設(shè)備不斷地連接進(jìn)來，從而使得地址表越來越大。
那我可不可以讓那根紅色的網(wǎng)線，接入一個新的設(shè)備，這個設(shè)備就跟電腦一樣有自己獨(dú)立的 MAC 地址，而且同時還能幫我把數(shù)據(jù)包做一次轉(zhuǎn)發(fā)呢？
這個設(shè)備就是路由器，它的功能就是，作為一臺獨(dú)立的擁有 MAC 地址的設(shè)備，并且可以幫我把數(shù)據(jù)包做一次轉(zhuǎn)發(fā)，你把它定在了網(wǎng)絡(luò)層。
注意，路由器的每一個端口，都有獨(dú)立的 MAC 地址
好了，現(xiàn)在交換機(jī)的 MAC 地址表中，只需要多出一條 MAC 地址 ABAB 與其端口的映射關(guān)系，就可以成功把數(shù)據(jù)包轉(zhuǎn)交給路由器了，這條搞定。
那如何做到，把發(fā)送給 C 和 D，甚至是把發(fā)送給 DEFGH.... 的數(shù)據(jù)包，統(tǒng)統(tǒng)先發(fā)送給路由器呢？
不難想到這樣一個點(diǎn)子，假如電腦 C 和 D 的 MAC 地址擁有共同的前綴，比如分別是
C 的 MAC 地址：FFFF-FFFF-CCCC?D 的 MAC 地址：FFFF-FFFF-DDDD
那我們就可以說，將目標(biāo) MAC 地址為?FFFF-FFFF-？開頭的，統(tǒng)統(tǒng)先發(fā)送給路由器。
這樣是否可行呢？答案是否定的。
IP地址的誕生
我們先從現(xiàn)實(shí)中 MAC 地址的結(jié)構(gòu)入手，MAC地址也叫物理地址、硬件地址，長度為 48 位，一般這樣來表示
00-16-EA-AE-3C-40
它是由網(wǎng)絡(luò)設(shè)備制造商生產(chǎn)時燒錄在網(wǎng)卡的EPROM（一種閃存芯片，通?？梢酝ㄟ^程序擦寫）。
其中前 24 位（00-16-EA）代表網(wǎng)絡(luò)硬件制造商的編號，后 24 位（AE-3C-40）是該廠家自己分配的，一般表示系列號。
只要不更改自己的 MAC 地址，MAC 地址在世界是唯一的。形象地說，MAC地址就如同身份證上的身份證號碼，具有唯一性。
那如果你希望向上面那樣表示將目標(biāo) MAC 地址為?FFFF-FFFF-？開頭的，統(tǒng)一從路由器出去發(fā)給某一群設(shè)備（后面會提到這其實(shí)是子網(wǎng)的概念），那你就需要要求某一子網(wǎng)下統(tǒng)統(tǒng)買一個廠商制造的設(shè)備，要么你就需要要求廠商在生產(chǎn)網(wǎng)絡(luò)設(shè)備燒錄 MAC 地址時，提前按照你規(guī)劃好的子網(wǎng)結(jié)構(gòu)來定 MAC 地址，并且日后這個網(wǎng)絡(luò)的結(jié)構(gòu)都不能輕易改變。
這顯然是不現(xiàn)實(shí)的。
于是你發(fā)明了一個新的地址，給每一臺機(jī)器一個 32 位的編號，如：
11000000101010000000000000000001
你覺得有些不清晰，于是把它分成四個部分，中間用點(diǎn)相連。
11000000.10101000.00000000.00000001
你還覺得不清晰，于是把它轉(zhuǎn)換成 10 進(jìn)制。
192.168.0.1
最后你給了這個地址一個響亮的名字，IP 地址。現(xiàn)在每一臺電腦，同時有自己的 MAC 地址，又有自己的 IP 地址，只不過 IP 地址是軟件層面上的，可以隨時修改，MAC 地址一般是無法修改的。
這樣一個可以隨時修改的 IP 地址，就可以根據(jù)你規(guī)劃的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，來調(diào)整了。
如上圖所示，假如我想要發(fā)送數(shù)據(jù)包給 ABCD 其中一臺設(shè)備，不論哪一臺，我都可以這樣描述，"將 IP 地址為 192.168.0 開頭的全部發(fā)送給到路由器，之后再怎么轉(zhuǎn)發(fā)，交給它！"，巧妙吧。
路由器的誕生
路由器誕生了，專門負(fù)責(zé)IP地址的尋找。那報文交給路由器之后，路由器又是怎么把數(shù)據(jù)包準(zhǔn)確轉(zhuǎn)發(fā)給指定設(shè)備的呢？
別急我們慢慢來。
我們先給上面的組網(wǎng)方式中的每一臺設(shè)備，加上自己的 IP 地址
現(xiàn)在兩個設(shè)備之間傳輸，除了加上數(shù)據(jù)鏈路層的頭部之外，還要再增加一個網(wǎng)絡(luò)層的頭部。
假如 A 給 B 發(fā)送數(shù)據(jù)，由于它們直接連著交換機(jī)，所以 A 直接發(fā)出如下數(shù)據(jù)包即可，其實(shí)網(wǎng)絡(luò)層沒有體現(xiàn)出作用。
但假如 A 給 C 發(fā)送數(shù)據(jù)，A 就需要先轉(zhuǎn)交給路由器，然后再由路由器轉(zhuǎn)交給 C。由于最底層的傳輸仍然需要依賴以太網(wǎng)，所以數(shù)據(jù)包是分成兩段的。
A ~ 路由器這段的包如下：
路由器到 C 這段的包如下：
好了，上面說的兩種情況（A->B，A->C），相信細(xì)心的讀者應(yīng)該會有不少疑問，下面我們一個個來展開。
子網(wǎng)的由來
A 給 C 發(fā)數(shù)據(jù)包，怎么知道是否要通過路由器轉(zhuǎn)發(fā)呢？
答案：子網(wǎng)
如果源 IP 與目的 IP 處于一個子網(wǎng)，直接將包通過交換機(jī)發(fā)出去。
如果源 IP 與目的 IP 不處于一個子網(wǎng)，就交給路由器去處理。
好，那現(xiàn)在只需要解決，什么叫處于一個子網(wǎng)就好了。
- 192.168.0.1 和 192.168.0.2 處于同一個子網(wǎng)
- 192.168.0.1 和 192.168.1.1 處于不同子網(wǎng)
這兩個是我們?nèi)藶橐?guī)定的，即我們想表示，對于 192.168.0.1 來說：
192.168.0.xxx 開頭的，就算是在一個子網(wǎng)，否則就是在不同的子網(wǎng)。
那對于計(jì)算機(jī)來說，怎么表達(dá)這個意思呢？于是人們發(fā)明了子網(wǎng)掩碼的概念
假如某臺機(jī)器的子網(wǎng)掩碼定為 255.255.255.0
這表示，將源 IP 與目的 IP 分別同這個子網(wǎng)掩碼進(jìn)行與運(yùn)算****，相等則是在一個子網(wǎng)，不相等就是在不同子網(wǎng)，就這么簡單。
比如
- A電腦：192.168.0.1 & 255.255.255.0 = 192.168.0.0
- B電腦：192.168.0.2 & 255.255.255.0 = 192.168.0.0
- C電腦：192.168.1.1 & 255.255.255.0 = 192.168.1.0
- D電腦：192.168.1.2 & 255.255.255.0 = 192.168.1.0
那么 A 與 B 在同一個子網(wǎng)，C 與 D 在同一個子網(wǎng)，但是 A 與 C 就不在同一個子網(wǎng)，與 D 也不在同一個子網(wǎng)，以此類推。
所以如果 A 給 C 發(fā)消息，A 和 C 的 IP 地址分別 & A 機(jī)器配置的子網(wǎng)掩碼，發(fā)現(xiàn)不相等，則 A 認(rèn)為 C 和自己不在同一個子網(wǎng)，于是把包發(fā)給路由器，就不管了，之后怎么轉(zhuǎn)發(fā)，A 不關(guān)心。
A 如何知道，哪個設(shè)備是路由器？
答案：在 A 上要設(shè)置默認(rèn)網(wǎng)關(guān)
上一步 A 通過是否與 C 在同一個子網(wǎng)內(nèi)，判斷出自己應(yīng)該把包發(fā)給路由器，那路由器的 IP 是多少呢？
其實(shí)說發(fā)給路由器不準(zhǔn)確，應(yīng)該說 A 會把包發(fā)給默認(rèn)網(wǎng)關(guān)。
對 A 來說，A 只能直接把包發(fā)給同處于一個子網(wǎng)下的某個 IP 上，所以發(fā)給路由器還是發(fā)給某個電腦，對 A 來說也不關(guān)心，只要這個設(shè)備有個 IP 地址就行。
所以默認(rèn)網(wǎng)關(guān)，就是 A 在自己電腦里配置的一個 IP 地址，以便在發(fā)給不同子網(wǎng)的機(jī)器時，發(fā)給這個 IP 地址。
僅此而已！
路由表的由來（和Mac表的由來好像，都是逼出來的）
路由器如何知道C在哪里？
答案：路由表
現(xiàn)在 A 要給 C 發(fā)數(shù)據(jù)包，已經(jīng)可以成功發(fā)到路由器這里了，最后一個問題就是，路由器怎么知道，收到的這個數(shù)據(jù)包，該從自己的哪個端口出去，才能直接（或間接）地最終到達(dá)目的地 C 呢。
路由器收到的數(shù)據(jù)包有目的 IP 也就是 C 的 IP 地址，需要轉(zhuǎn)化成從自己的哪個端口出去，很容易想到，應(yīng)該有個表，就像 MAC 地址表一樣。
這個表就叫路由表。
至于這個路由表是怎么出來的，有很多路由算法，本文不展開，因?yàn)槲乙膊粫
不同于 MAC 地址表的是，路由表并不是一對一這種明確關(guān)系，我們下面看一個路由表的結(jié)構(gòu)。
| 目的地址 | 子網(wǎng)掩碼 | 下一跳 | 端口 |
| 192.168.0.0 | 255.255.255.0 | 0 | |
| 192.168.0.254 | 255.255.255.255 | 0 | |
| 192.168.1.0 | 255.255.255.0 | 1 | |
| 192.168.1.254 | 255.255.255.255 | 1 |
我們學(xué)習(xí)一種新的表示方法，由于子網(wǎng)掩碼其實(shí)就表示前多少位表示子網(wǎng)的網(wǎng)段，所以如 192.168.0.0（255.255.255.0） 也可以簡寫為 192.168.0.0/24
| 目的地址 | 下一跳 | 端口 |
| 192.168.0.0/24 | 0 | |
| 192.168.0.254/32 | 0 | |
| 192.168.1.0/24 | 1 | |
| 192.168.1.254/32 | 1 |
這就很好理解了，路由表就表示，192.168.0.xxx 這個子網(wǎng)下的，都轉(zhuǎn)發(fā)到 0 號端口，192.168.1.xxx 這個子網(wǎng)下的，都轉(zhuǎn)發(fā)到 1 號端口。下一跳列還沒有值，我們先不管
配合著結(jié)構(gòu)圖來看（這里把子網(wǎng)掩碼和默認(rèn)網(wǎng)關(guān)都補(bǔ)齊了）
剛才說的都是 IP 層，但發(fā)送數(shù)據(jù)包的數(shù)據(jù)鏈路層需要知道 MAC 地址，可是我只知道 IP 地址該怎么辦呢？
答案：arp
假如你（A）此時不知道你同伴 B 的 MAC 地址（現(xiàn)實(shí)中就是不知道的，剛剛我們只是假設(shè)已知），你只知道它的 IP 地址，你該怎么把數(shù)據(jù)包準(zhǔn)確傳給 B 呢？
答案很簡單，在網(wǎng)絡(luò)層，我需要把 IP 地址對應(yīng)的 MAC 地址找到，也就是通過某種方式，找到?192.168.0.2?對應(yīng)的 MAC 地址?BBBB。
這種方式就是?arp 協(xié)議，同時電腦 A 和 B 里面也會有一張?arp 緩存表，表中記錄著?IP 與 MAC 地址的對應(yīng)關(guān)系。
| IP 地址 | MAC 地址 |
| 192.168.0.2 | BBBB |
一開始的時候這個表是空的，電腦 A 為了知道電腦 B（192.168.0.2）的 MAC 地址，將會廣播一條 arp 請求，B 收到請求后，帶上自己的 MAC 地址給 A 一個響應(yīng)。此時 A 便更新了自己的 arp 表。
這樣通過大家不斷廣播 arp 請求，最終所有電腦里面都將 arp 緩存表更新完整。
圖解：整個傳輸過程
從各個節(jié)點(diǎn)的視角來看
電腦視角：
- 首先我要知道我的 IP 以及對方的 IP
- 通過子網(wǎng)掩碼判斷我們是否在同一個子網(wǎng)
- 在同一個子網(wǎng)就通過 arp 獲取對方 mac 地址直接扔出去
- 不在同一個子網(wǎng)就通過 arp 獲取默認(rèn)網(wǎng)關(guān)的 mac 地址直接扔出去
交換機(jī)視角：
- 我收到的數(shù)據(jù)包必須有目標(biāo) MAC 地址
- 通過 MAC 地址表查映射關(guān)系
- 查到了就按照映射關(guān)系從我的指定端口發(fā)出去
- 查不到就所有端口都發(fā)出去
路由器視角：
- 我收到的數(shù)據(jù)包必須有目標(biāo) IP 地址
- 通過路由表查映射關(guān)系
- 查到了就按照映射關(guān)系從我的指定端口發(fā)出去（不在任何一個子網(wǎng)范圍，走其路由器的默認(rèn)網(wǎng)關(guān)也是查到了）
- 查不到則返回一個路由不可達(dá)的數(shù)據(jù)包
如果你嗅覺足夠敏銳，你應(yīng)該可以感受到下面這句話：
網(wǎng)絡(luò)層（IP協(xié)議）本身沒有傳輸包的功能，包的實(shí)際傳輸是委托給數(shù)據(jù)鏈路層（以太網(wǎng)中的交換機(jī)）來實(shí)現(xiàn)的。
涉及到的三張表分別是
- 交換機(jī)中有?MAC 地址表用于映射 MAC 地址和它的端口
- 路由器中有路由表用于映射 IP 地址(段)和它的端口
- 電腦和路由器中都有** arp 緩存表**用于緩存 IP 和 MAC 地址的映射關(guān)系
這三張表是怎么來的
- MAC 地址表是通過以太網(wǎng)內(nèi)各節(jié)點(diǎn)之間不斷通過交換機(jī)通信，不斷完善起來的。
- 路由表是各種路由算法 + 人工配置逐步完善起來的。
- arp 緩存表是不斷通過 arp 協(xié)議的請求逐步完善起來的。
知道了以上這些，目前網(wǎng)絡(luò)上兩個節(jié)點(diǎn)是如何發(fā)送數(shù)據(jù)包的這個過程，就完全可以解釋通了！
參考的網(wǎng)絡(luò)拓?fù)鋱D
那接下來我們就放上參考的?最后一個網(wǎng)絡(luò)拓?fù)鋱D吧，請做好?戰(zhàn)斗?準(zhǔn)備！
這時路由器 1 連接了路由器 2，所以其路由表有了下一條地址這一個概念，所以它的路由表就變成了這個樣子。如果匹配到了有下一跳地址的一項(xiàng)，則需要再次匹配，找到其端口，并找到下一跳 IP 的 MAC 地址。
也就是說找來找去，最終必須能映射到一個端口號，然后從這個端口號把數(shù)據(jù)包發(fā)出去。
| 目的地址 | 下一跳 | 端口 |
| 192.168.0.0/24 | 0 | |
| 192.168.0.254/32 | 0 | |
| 192.168.1.0/24 | 1 | |
| 192.168.1.254/32 | 1 | |
| 192.168.2.0/24 | 192.168.100.5 | |
| 192.168.100.0/24 | 2 | |
| 192.168.100.4/32 | 2 |
這時如果 A 給 F 發(fā)送一個數(shù)據(jù)包，能不能通呢？如果通的話整個過程是怎樣的呢？
思考一分鐘...
詳細(xì)過程動畫描述：
詳細(xì)過程文字描述：
1.?首先 A（192.168.0.1）通過子網(wǎng)掩碼（255.255.255.0）計(jì)算出自己與 F（192.168.2.2）并不在同一個子網(wǎng)內(nèi)，于是決定發(fā)送給默認(rèn)網(wǎng)關(guān)（192.168.0.254）
2.?A 通過 ARP 找到 默認(rèn)網(wǎng)關(guān) 192.168.0.254 的 MAC 地址。
3.?A 將源 MAC 地址（AAAA）與網(wǎng)關(guān) MAC 地址（ABAB）封裝在數(shù)據(jù)鏈路層頭部，又將源 IP 地址（192.168.0.1）和目的 IP 地址（192.168.2.2）（注意這里千萬不要以為填寫的是默認(rèn)網(wǎng)關(guān)的 IP 地址，從始至終這個數(shù)據(jù)包的兩個 IP 地址都是不變的，只有 MAC 地址在不斷變化）封裝在網(wǎng)絡(luò)層頭部，然后發(fā)包
4.?交換機(jī) 1 收到數(shù)據(jù)包后，發(fā)現(xiàn)目標(biāo) MAC 地址是 ABAB，轉(zhuǎn)發(fā)給路由器1
5.?數(shù)據(jù)包來到了路由器 1，發(fā)現(xiàn)其目標(biāo) IP 地址是 192.168.2.2，查看其路由表，發(fā)現(xiàn)了下一跳的地址是 192.168.100.5*
6.?所以此時路由器 1 需要做兩件事，第一件是再次匹配路由表，發(fā)現(xiàn)匹配到了端口為 2，于是將其封裝到數(shù)據(jù)鏈路層，最后把包從 2 號口發(fā)出去。
7.?此時路由器 2 收到了數(shù)據(jù)包，看到其目的地址是 192.168.2.2，查詢其路由表，匹配到端口號為 1，準(zhǔn)備從 1 號口把數(shù)據(jù)包送出去。
8.?但此時路由器 2 需要知道 192.168.2.2 的 MAC 地址了，于是查看其 arp 緩存，找到其 MAC 地址為 FFFF，將其封裝在數(shù)據(jù)鏈路層頭部，并從 1 號端口把包發(fā)出去。
9.?交換機(jī) 3 收到了數(shù)據(jù)包，發(fā)現(xiàn)目的 MAC 地址為 FFFF，查詢其 MAC 地址表，發(fā)現(xiàn)應(yīng)該從其 6 號端口出去，于是從 6 號端口把數(shù)據(jù)包發(fā)出去。
10.F 最終收到了數(shù)據(jù)包！**并且發(fā)現(xiàn)目的 MAC 地址就是自己，于是收下了這個包
HTTP報文傳輸原理
利用TCP/IP進(jìn)行網(wǎng)絡(luò)通信時，數(shù)據(jù)包會按照分層順序與對方進(jìn)行通信。發(fā)送端從應(yīng)用層往下走，接收端從鏈路層往上走。從客戶端到服務(wù)器的數(shù)據(jù)，每一幀數(shù)據(jù)的傳輸?shù)捻樞蚨紴?#xff1a;應(yīng)用層->運(yùn)輸層->網(wǎng)絡(luò)層->鏈路層->鏈路層->網(wǎng)絡(luò)層->運(yùn)輸層->應(yīng)用層。
HTTP報文傳輸過程
以一個HTTP請求的傳輸為例，請求從HTTP客戶端（如瀏覽器）和HTTP服務(wù)端應(yīng)用的傳輸過程，大致如下圖所示：
圖：HTTP請求報文的分層傳輸過程
數(shù)據(jù)封裝和分用
接下來，為大家介紹一下數(shù)據(jù)封裝和分用。
數(shù)據(jù)通過互聯(lián)網(wǎng)傳輸?shù)臅r候不可能是光禿禿的不加標(biāo)識，如果這樣數(shù)據(jù)就會亂。所以數(shù)據(jù)在發(fā)送的時候，需要加上特定標(biāo)識，加上特定標(biāo)識的過程叫做數(shù)據(jù)的封裝，在數(shù)據(jù)使用的時候再去掉特定標(biāo)識，去掉特定標(biāo)識的過程就叫做分用。TCP/IP協(xié)議的數(shù)據(jù)封裝和分用過程，大致如下圖所示：
圖：TCP/IP協(xié)議的數(shù)據(jù)封裝和分用過程
在數(shù)據(jù)封裝時，數(shù)據(jù)經(jīng)過每個層都會打上該層特定標(biāo)識，添加上頭部。
在傳輸層封裝時，添加的報文首部時要存入一個應(yīng)用程序的標(biāo)識符，無論TCP和UDP都用一個16位的端口號來表示不同的應(yīng)用程序，并且都會將源端口和目的端口存入報文首部中。
在網(wǎng)絡(luò)層封裝時，IP首部會標(biāo)識處理數(shù)據(jù)的協(xié)議類型，或者說標(biāo)識出網(wǎng)絡(luò)層數(shù)據(jù)幀所攜帶的上層數(shù)據(jù)類型，如TCP、UDP、ICMP、IP、IGMP等等。
具體來說，會在IP首部中存入一個長度為8位的數(shù)值，稱作協(xié)議域：
1表示為ICMP協(xié)議、2表示為IGMP協(xié)議、6表示為TCP協(xié)議、17表示為UDP協(xié)議、等等。IP首部還會標(biāo)識發(fā)送方地址（源IP）和接收方地址（目標(biāo)IP）。
在鏈路層封裝時，網(wǎng)絡(luò)接口分別要發(fā)送和接收IP、ARP和RARP等多種不同協(xié)議的報文，因此也必須在以太網(wǎng)的幀首部中加入某種形式的標(biāo)識，以指明所處理的協(xié)議類型，為此，以太網(wǎng)的報文幀的首部也有一個16位的類型域，標(biāo)識出以太網(wǎng)數(shù)據(jù)幀所攜帶的上層數(shù)據(jù)類型，如IPv4、ARP、IPV6、PPPoE等等。
數(shù)據(jù)封裝和分用的過程大致為：發(fā)送端每通過一層會增加該層的首部，接收端每通過一層則刪除該層的首部。
總體來說，TCP/IP分層管理、數(shù)據(jù)封裝和分用的好處：分層之后若需改變相關(guān)設(shè)計(jì)，只需替換變動的層。各層之間的接口部分規(guī)劃好之后，每個層次內(nèi)部的設(shè)計(jì)就可以自由改動。層次化之后，設(shè)計(jì)也變得相對簡單：各個層只需考慮分派給自己的傳輸任務(wù)。
TCP/IP與OSI的區(qū)別主要有哪些呢？除了TCP/IP與OSI在分層模塊上稍有區(qū)別，更重要的區(qū)別為：OSI參考模型注重“通信協(xié)議必要的功能是什么”，而TCP/IP則更強(qiáng)調(diào)“在計(jì)算機(jī)上實(shí)現(xiàn)協(xié)議應(yīng)該開發(fā)哪種程序”。
實(shí)際上，在傳輸過程中，數(shù)據(jù)報文會在不同的物理網(wǎng)絡(luò)之間傳遞，還是以一個HTTP請求的傳輸為例，請求在不同物理網(wǎng)絡(luò)之間的傳輸過程，大致如下圖所示：
圖：HTTP請求在不同物理網(wǎng)絡(luò)之間的傳輸過程
數(shù)據(jù)包在不同物理網(wǎng)絡(luò)之間的傳輸過程中，網(wǎng)絡(luò)層會通過路由器去對不同的網(wǎng)絡(luò)之間的數(shù)據(jù)包進(jìn)行存儲、分組轉(zhuǎn)發(fā)處理。構(gòu)造互連網(wǎng)最簡單的方法是把兩個或多個網(wǎng)絡(luò)通過路由器進(jìn)行連接。路由器可以簡單理解為一種特殊的用于網(wǎng)絡(luò)互連的硬件盒，其作用是為不同類型的物理網(wǎng)絡(luò)提供連接：以太網(wǎng)、令牌環(huán)網(wǎng)、點(diǎn)對點(diǎn)的鏈接和FDDI（光纖分布式數(shù)據(jù)接口）等等。
物理網(wǎng)絡(luò)之間通過路由器進(jìn)行互連，隨著增加不同類型的物理網(wǎng)絡(luò)，可能會有很多個路由器，但是對于應(yīng)用層來說仍然是一樣的，TCP協(xié)議棧為大家屏蔽了物理層的復(fù)雜性?？傊?#xff0c;物理細(xì)節(jié)和差異性的隱藏，使得互聯(lián)網(wǎng)TCP/IP傳輸?shù)墓δ茏兊梅浅?qiáng)大。
接下來，開始為大家介紹與傳輸性能有密切關(guān)系的內(nèi)容：TCP傳輸層的三次握手建立連接，四次揮手釋放連接。不過在此之前，還得先介紹一下TCP報文協(xié)議。
TCP協(xié)議的報文格式
在TCP/IP協(xié)議棧中，IP協(xié)議層只關(guān)心如何使數(shù)據(jù)能夠跨越本地網(wǎng)絡(luò)邊界的問題，而不關(guān)心數(shù)據(jù)如何傳輸。整體TCP/IP協(xié)議棧，共同配合一起解決數(shù)據(jù)如何通過許許多多個點(diǎn)對點(diǎn)通路，順利傳輸?shù)竭_(dá)目的地。一個點(diǎn)對點(diǎn)通路被稱為一“跳”（hop），通過TCP/IP協(xié)議棧，網(wǎng)絡(luò)成員能夠在許多“跳”的基礎(chǔ)上建立相互的數(shù)據(jù)通路。
傳輸層TCP協(xié)議提供了一種面向連接的、可靠的字節(jié)流服務(wù)，其數(shù)據(jù)幀格式，大致如下圖所示：
圖：傳輸層TCP協(xié)議的數(shù)據(jù)幀格式
一個傳輸層TCP協(xié)議的數(shù)據(jù)幀，大致包含以下字段：
（一）源端口號
源端口號表示報文的發(fā)送端口，占16位。源端口和源IP地址組合起來，可以標(biāo)識報文的發(fā)送地址。
（二）目的端口號
目的端口號表示報文的接收端口，占16位。目的端口和目的IP地址相結(jié)合，可以標(biāo)識報文的接收地址。
TCP協(xié)議是基于IP協(xié)議的基礎(chǔ)上傳輸?shù)?#xff0c;TCP報文中的源端口號+源IP，與TCP報文中的目的端口號+目的IP一起，組合起來唯一性的確定一條TCP連接。
（三）序號（Sequence Number）
TCP傳輸過程中，在發(fā)送端出的字節(jié)流中，傳輸報文中的數(shù)據(jù)部分的每一個字節(jié)都有它的編號。序號（Sequence
Number）占32位，發(fā)起方發(fā)送數(shù)據(jù)時，都需要標(biāo)記序號。
序號（Sequence Number）的語義與SYN控制標(biāo)志（Control
Bits）的值有關(guān)。根據(jù)控制標(biāo)志（Control Bits）中的SYN是否為1，序號（Sequence
Number）表達(dá)不同的含義：
（1）當(dāng)SYN = 1時，當(dāng)前為連接建立階段，此時的序號為初始序號ISN((Initial Sequence
Number)，通過算法來隨機(jī)生成序號；
（2）當(dāng)SYN = 0時在數(shù)據(jù)傳輸正式開始時，第一個報文的序號為 ISN +
1，后面的報文的序號，為前一個報文的SN值+TCP報文的凈荷字節(jié)數(shù)(不包含TCP頭)。比如，如果發(fā)送端發(fā)送的一個TCP幀的凈荷為12byte，序號為5，則發(fā)送端接著發(fā)送的下一個數(shù)據(jù)包的時候，序號的值應(yīng)該設(shè)置為5+12=17。
在數(shù)據(jù)傳輸過程中，TCP協(xié)議通過序號（Sequence
Number）對上層提供有序的數(shù)據(jù)流。發(fā)送端可以用序號來跟蹤發(fā)送的數(shù)據(jù)量；接收端可以用序號識別出重復(fù)接收到的TCP包，從而丟棄重復(fù)包；對于亂序的數(shù)據(jù)包，接收端也可以依靠序號對其進(jìn)行排序。
（四）確認(rèn)序號（Acknowledgment Number）
確認(rèn)序號（Acknowledgment
Number）標(biāo)識了報文接收端期望接收的字節(jié)序列。如果設(shè)置了ACK控制位，確認(rèn)序號的值表示一個準(zhǔn)備接收的包的序列碼，注意，它所指向的是準(zhǔn)備接收的包，也就是下一個期望接收的包的序列碼。
舉個例子，假設(shè)發(fā)送端（如Client）發(fā)送3個凈荷為1000byte、起始SN序號為1的數(shù)據(jù)包給Server服務(wù)端，Server每收到一個包之后，需要回復(fù)一個ACK響應(yīng)確認(rèn)數(shù)據(jù)包給Client。ACK響應(yīng)數(shù)據(jù)包的ACK
Number值，為每個Client包的為SN+包凈荷，既表示Server已經(jīng)確認(rèn)收到的字節(jié)數(shù)，還表示期望接收到的下一個Client發(fā)送包的SN序號，具體的ACK值如下圖左邊的正常傳輸部分所示。
圖：傳輸過程的確認(rèn)序號（Acknowledgment Number）值示例圖
在上圖的左邊部分，Server第1個ACK包的ACK
Number值為1001，是通過Client第1個包的SN+包凈荷=1+1000計(jì)算得到，表示期望第2個Client包的SN序號為1001；Server第2個ACK包的ACK
Number值為2001，為Client第2個包的SN+包凈荷=2001，表示期望第3個Server包的SN為2001，以此類推。
如果發(fā)生錯誤，假設(shè)Server在處理Client的第二個發(fā)送包異常，Server仍然回復(fù)一個ACK
Number值為1001的確認(rèn)包，則Client的第二個數(shù)據(jù)包需要重復(fù)發(fā)送，具體的ACK值如上圖右邊的正常傳輸部分所示。
只有控制標(biāo)志的ACK標(biāo)志為1時，數(shù)據(jù)幀中的確認(rèn)序號ACK
Number才有效。TCP協(xié)議規(guī)定，連接建立后，所有發(fā)送的報文的ACK必須為1，也就是建立連接后，所有報文的確認(rèn)序號有效。如果是SYN類型的報文，其ACK標(biāo)志為0，故沒有確認(rèn)序號。
（五）頭部長度
該字段占用4位，用來表示TCP報文首部的長度，單位是4bit位。其值所表示的并不是字節(jié)數(shù)，而是頭部的所含有的32bit的數(shù)目（或者倍數(shù)），或者4個字節(jié)的倍數(shù)，所以TCP頭部最多可以有60字節(jié)（4*15=60）。沒有任何選項(xiàng)字段的TCP頭部長度為20字節(jié)，所以其頭部長度為5，可以通過20/4=5計(jì)算得到。
（六）預(yù)留6位
頭部長度后面預(yù)留的字段長度為6位，作為保留字段，暫時沒有什么用處。
（七）控制標(biāo)志
控制標(biāo)志（Control
Bits）共6個bit位，具體的標(biāo)志位為：URG、ACK、PSH、RST、SYN、FIN。6個標(biāo)志位的說明，如下表所示。
表：TCP報文控制標(biāo)志（Control Bits）說明
| 標(biāo)志位 | 說明 |
| URG | 占1位，表示緊急指針字段有效。URG位指示報文段里的上層實(shí)體（數(shù)據(jù)）標(biāo)記為“緊急”數(shù)據(jù)。當(dāng)URG=1時，其后的緊急指針指示緊急數(shù)據(jù)在當(dāng)前數(shù)據(jù)段中的位置(相對于當(dāng)前序列號的字節(jié)偏移量)，TCP接收方必須通知上層實(shí)體。 |
| ACK | 占1位，置位ACK=1表示確認(rèn)號字段有效；TCP協(xié)議規(guī)定，接建立后所有發(fā)送的報文的ACK必須為1；當(dāng)ACK=0時，表示該數(shù)據(jù)段不包含確認(rèn)信息。當(dāng)ACK=1時，表示該報文段包括一個對已被成功接收報文段的確認(rèn)序號Acknowledgment Number，該序號同時也是下一個報文的預(yù)期序號。 |
| PSH | 占1位，表示當(dāng)前報文需要請求推（push）操作；當(dāng)PSH=1時，接收方在收到數(shù)據(jù)后立即將數(shù)據(jù)交給上層，而不是直到整個緩沖區(qū)滿。 |
| RST | 占1位，置位RST=1表示復(fù)位TCP連接；用于重置一個已經(jīng)混亂的連接，也可用于拒絕一個無效的數(shù)據(jù)段或者拒絕一個連接請求。如果數(shù)據(jù)段被設(shè)置了RST位，說明報文發(fā)送方有問題發(fā)生。 |
| SYN | 占1位，在連接建立時用來同步序號。當(dāng)SYN=1而ACK=0時，表明這是一個連接請求報文。對方若同意建立連接，則應(yīng)在響應(yīng)報文中使SYN=1和ACK=1。 綜合一下，SYN置1就表示這是一個連接請求或連接接受報文。 |
| FIN | 占1位，用于在釋放TCP連接時，標(biāo)識發(fā)送方比特流結(jié)束，用來釋放一個連接。當(dāng) FIN = 1時，表明此報文的發(fā)送方的數(shù)據(jù)已經(jīng)發(fā)送完畢，并要求釋放連接。 |
在連接建立的三次握手過程中，若只是單個SYN置位，表示的只是建立連接請求。如果SYN和ACK同時置位為1，表示的建立連接之后的響應(yīng)。
（八）窗口大小：
長度為16位，共2個字節(jié)。此字段用來進(jìn)行流量控制。流量控制的單位為字節(jié)數(shù)，這個值是本端期望一次接收的字節(jié)數(shù)。
（九）校驗(yàn)和：
長度為16位，共2個字節(jié)。對整個TCP報文段，即TCP頭部和TCP數(shù)據(jù)進(jìn)行校驗(yàn)和計(jì)算，接收端用于對收到的數(shù)據(jù)包進(jìn)行驗(yàn)證。
（十）緊急指針：
長度為16米，2個字節(jié)。它是一個偏移量，和SN序號值相加表示緊急數(shù)據(jù)最后一個字節(jié)的序號。
以上十項(xiàng)內(nèi)容是TCP報文首部必須的字段，也稱固有字段，長度為20個字節(jié)。接下來是TCP報文的可選項(xiàng)和填充部分。
（十一）可選項(xiàng)和填充部分
可選項(xiàng)和填充部分的長度為4n字節(jié)（n是整數(shù)），該部分是根據(jù)需要而增加的選項(xiàng)。如果不足4n字節(jié)，要加填充位，使得選項(xiàng)長度為32位（4字節(jié)）的整數(shù)倍，具體的做法是在這個字段中加入額外的零，以確保TCP頭是32位（4字節(jié)）的整數(shù)倍。
最常見的選項(xiàng)字段是MSS（Maximum Segment
Size最長報文大小），每個連接方通常都在通信的第一個報文段（SYN標(biāo)志為1的那個段）中指明這個選項(xiàng)字段，表示當(dāng)前連接方所能接受的最大報文段的長度。
由于可選項(xiàng)和填充部分不是必須的，所以TCP報文首部最小長度為20個字節(jié)。
至此，TCP報文首部的字段，就全部介紹完了。TCP報文首部的后面，接著的是數(shù)據(jù)部分，不過數(shù)據(jù)部分是可選的。在一個連接建立和一個連接終止時，雙方交換的報文段僅有TCP首部。如果一方?jīng)]有數(shù)據(jù)要發(fā)送，也使用沒有任何數(shù)據(jù)的首部來確認(rèn)收到的數(shù)據(jù)，比如在處理超時的過程中，也會發(fā)送不帶任何數(shù)據(jù)的報文段。
總體來說，TCP協(xié)議的可靠性，主要通過以下幾點(diǎn)來保障：
（1）應(yīng)用數(shù)據(jù)分割成TCP認(rèn)為最適合發(fā)送的數(shù)據(jù)塊。這部分是通過MSS（最大數(shù)據(jù)包長度）選項(xiàng)來控制的，通常這種機(jī)制也被稱為一種協(xié)商機(jī)制，MSS規(guī)定了TCP傳往另一端的最大數(shù)據(jù)塊的長度。值得注意的是，MSS只能出現(xiàn)在SYN報文段中，若一方不接收來自另一方的MSS值，則MSS就定為536字節(jié)。一般來講，MSS值還是越大越好，這樣可以提高網(wǎng)絡(luò)的利用率。
（2）重傳機(jī)制。設(shè)置定時器，等待確認(rèn)包，如果定時器超時還沒有收到確認(rèn)包，則報文重傳。
（3）對首部和數(shù)據(jù)進(jìn)行校驗(yàn)。
（4）接收端對收到的數(shù)據(jù)進(jìn)行排序，然后交給應(yīng)用層。
（5）接收端丟棄重復(fù)的數(shù)據(jù)。
（6）TCP還提供流量控制，主要是通過滑動窗口來實(shí)現(xiàn)流量控制。
至此TCP協(xié)議的數(shù)據(jù)幀格式介紹完了。接下來開始為大家重點(diǎn)介紹：TCP傳輸層的三次握手建立連接，四次揮手釋放連接。
TCP的三次握手
TCP連接的建立時，雙方需要經(jīng)過三次握手，而斷開連接時，雙方需要經(jīng)過四次分手，那么，其三次握手和四次分手分別做了什么呢？又是如何進(jìn)行的呢？
通常情況下，建立連接的雙方，由一端打開一個監(jiān)聽套接字（ServerSocket）來監(jiān)聽來自請求方的TCP（Socket）連接，當(dāng)服務(wù)器端監(jiān)聽開始時，必須做好準(zhǔn)備接受外來的連接，在Java中該操作通過創(chuàng)建一個ServerSocket服務(wù)監(jiān)聽套接字實(shí)例來完成，此操作會調(diào)用底層操作系統(tǒng)（如Linux）的C代碼中三個函數(shù)socket()、bind()、listen()
來完成。開始監(jiān)聽之后，服務(wù)器端就做好接受外來連接的準(zhǔn)備，如果監(jiān)聽到建立新連接的請求，會開啟一個傳輸套接字，稱之為被動打開（Passive
Open）。
一段簡單的服務(wù)端監(jiān)聽新連接請求，并且被動打開（Passive
Open）傳輸套接字的Java示例代碼，具體如下：
客戶端在發(fā)起連接建立時，Java代碼通過創(chuàng)建Socket實(shí)例，調(diào)用底層的connect(…)方法，主動打開(Active
Open)Socket連接。套接字監(jiān)聽方在收到請求之后，監(jiān)聽方和發(fā)起方（客戶端）之間就會建立一條的連接通道，該通道由雙方IP和雙方端口所唯一確定。
一段簡單的客戶端連接主動打開(Active Open)的Java示例代碼，具體如下：
public class SocketClient {public static void main(String[] args) throws InterruptedException {try {// 和服務(wù)器創(chuàng)建連接Socket socket = new Socket("localhost",8080);// 寫入給監(jiān)聽方的輸出流OutputStream os = socket.getOutputStream();…..// 讀取監(jiān)聽方的輸入流InputStream is = socket.getInputStream();…..} catch (Exception e) {e.printStackTrace();}}}三次握手過程
TCP連接的建立時，雙方需要經(jīng)過三次握手，具體過程如下：
（1）第一次握手：Client進(jìn)入SYN_SENT狀態(tài)，發(fā)送一個SYN幀來主動打開傳輸通道，該幀的SYN標(biāo)志位被設(shè)置為1，同時會帶上Client分配好的SN序列號，該SN是根據(jù)時間產(chǎn)生的一個隨機(jī)值，通常情況下每間隔4ms會加1。除此之外，SYN幀還會帶一個MSS（最大報文段長度）可選項(xiàng)的值，表示客戶端發(fā)送出去的最大數(shù)據(jù)塊的長度。
（2）第二次握手：Server端在收到SYN幀之后，會進(jìn)入SYN_RCVD狀態(tài)，同時返回SYN+ACK幀給Client，主要目的在于通知Client，Server端已經(jīng)收到SYN消息，現(xiàn)在需要進(jìn)行確認(rèn)。Server端發(fā)出的SYN+ACK幀的ACK標(biāo)志位被設(shè)置為1，其確認(rèn)序號AN（Acknowledgment
Number）值被設(shè)置為Client的SN+1；SYN+ACK幀的SYN標(biāo)志位被設(shè)置為1，SN值為Server端生成的SN序號；SYN+ACK幀的MSS（最大報文段長度）表示的是Server端的最大數(shù)據(jù)塊長度。
（3）第三次握手：Client在收到Server的第二次握手SYN+ACK確認(rèn)幀之后，首先將自己的狀態(tài)會從SYN_SENT變成ESTABLISHED，表示自己方向的連接通道已經(jīng)建立成功，Client可以發(fā)送數(shù)據(jù)給Server端了。然后，Client發(fā)ACK幀給Server端，該ACK幀的ACK標(biāo)志位被設(shè)置為1，其確認(rèn)序號AN（Acknowledgment
Number）值被設(shè)置為Server端的SN序列號+1。還有一種情況，Client可能會將ACK幀和第一幀要發(fā)送的數(shù)據(jù)，合并到一起發(fā)送給Server端。
（4）Server端在收到Client的ACK幀之后，會從SYN_RCVD狀態(tài)會進(jìn)入ESTABLISHED狀態(tài)，至此，Server方向的通道連接建立成功，Server可以發(fā)送數(shù)據(jù)給Client，TCP的全雙工連接建立完成。
三次握手的圖解
三次握手的交互過程，具體如下圖所示：
圖：TCP建立的連接時三次握手示意圖
Client和Server完成了三次握手后，雙方就進(jìn)入了數(shù)據(jù)傳輸?shù)碾A段。數(shù)據(jù)傳輸完成后，連接將斷開，連接斷開的過程需要經(jīng)歷四次揮手。
TCP的四次揮手
業(yè)務(wù)數(shù)據(jù)通信完成之后，TCP連接開始斷開（或者拆接）的過程，在這個過程中連接的每個端的都能獨(dú)立地、主動的發(fā)起，斷開的過程TCP協(xié)議使用了四路揮手操作。
四次揮手具體過程
四次揮手具體過程，具體如下：
（1）第一次揮手：主動斷開方（可以是客戶端，也可以是服務(wù)器端），向?qū)Ψ桨l(fā)送一個FIN結(jié)束請求報文，此報文的FIN位被設(shè)置為1，并且正確設(shè)置Sequence
Number（序列號）和Acknowledgment
Number（確認(rèn)號）。發(fā)送完成后，主動斷開方進(jìn)入FIN_WAIT_1狀態(tài)，這表示主動斷開方?jīng)]有業(yè)務(wù)數(shù)據(jù)要發(fā)送給對方，準(zhǔn)備關(guān)閉SOCKET連接了。
（2）第二次揮手：正常情況下，在收到了主動斷開方發(fā)送的FIN斷開請求報文后，被動斷開方會發(fā)送一個ACK響應(yīng)報文，報文的Acknowledgment
Number（確認(rèn)號）值為斷開請求報文的Sequence Number
（序列號）加1，該ACK確認(rèn)報文的含義是：“我同意你的連接斷開請求”。之后，被動斷開方就進(jìn)入了CLOSE-WAIT（關(guān)閉等待）狀態(tài)，TCP協(xié)議服務(wù)會通知高層的應(yīng)用進(jìn)程，對方向本地方向的連接已經(jīng)關(guān)閉，對方已經(jīng)沒有數(shù)據(jù)要發(fā)送了，若本地還要發(fā)送數(shù)據(jù)給對方，對方依然會接受。被動斷開方的CLOSE-WAIT（關(guān)閉等待）還要持續(xù)一段時間，也就是整個CLOSE-WAIT狀態(tài)持續(xù)的時間。
主動斷開方在收到了ACK報文后，由FIN_WAIT_1轉(zhuǎn)換成FIN_WAIT_2狀態(tài)。
（3）第三次揮手：在發(fā)送完成ACK報文后，被動斷開方還可以繼續(xù)完成業(yè)務(wù)數(shù)據(jù)的發(fā)送，待剩余數(shù)據(jù)發(fā)送完成后，或者CLOSE-WAIT（關(guān)閉等待）截止后，被動斷開方會向主動斷開方發(fā)送一個FIN+ACK結(jié)束響應(yīng)報文，表示被動斷開方的數(shù)據(jù)都發(fā)送完了，然后，被動斷開方進(jìn)入LAST_ACK狀態(tài)。
（4）第四次揮手：主動斷開方收在到FIN+ACK斷開響應(yīng)報文后，還需要進(jìn)行最后的確認(rèn)，向被動斷開方發(fā)送一個ACK確認(rèn)報文，然后，自己就進(jìn)入TIME_WAIT狀態(tài)，等待超時后最終關(guān)閉連接。處于TIME_WAIT狀態(tài)的主動斷開方，在等待完成2MSL的時間后，如果期間沒有收到其他報文，則證明對方已正常關(guān)閉，主動斷開方的連接最終關(guān)閉。
被動斷開方在收到主動斷開方的最后的ACK報文以后，最終關(guān)閉了連接，自己啥也不管了。
四次揮手圖解
四次揮手的全部交互過程，具體如下圖所示：
圖：TCP建立的連接時四次揮手的示意圖
處于TIME_WAIT狀態(tài)的主動斷開方，在等待完成2MSL的時間后，才真正關(guān)閉連接通道，其等待的時間為什么是2MSL呢？
2MSL翻譯過來就是兩倍的MSL。MSL全稱為Maximum Segment
Lifetime，指的是一個TCP報文片段在網(wǎng)絡(luò)中最大的存活時間，具體來說，2MSL對應(yīng)于一次消息的來回（一個發(fā)送和一個回復(fù)）所需的最大時間。如果直到2MSL，主動斷開方都沒有再一次收到對方的報文（如FIN報文），則可以推斷ACK已經(jīng)被對方成功接收，此時，主動斷開方將最終結(jié)束自己的TCP連接。所以，TCP的TIME_WAIT狀態(tài)也稱為2MSL等待狀態(tài)。
有關(guān)MSL的具體的時間長度，在RFC1122協(xié)議中推薦為2分鐘。在SICS（瑞典計(jì)算機(jī)科學(xué)院）開發(fā)的一個小型開源的TCP/IP協(xié)議棧——LwIP開源協(xié)議棧中MSL默認(rèn)為1分鐘。在源自Berkeley的TCP協(xié)議棧實(shí)現(xiàn)中MSL默認(rèn)長度為30秒?？傮w來說，TIME_WAIT（2MSL）等待狀態(tài)的時間長度，一般維持在1-4分鐘之間。
通過三次握手建立連接和四次揮手拆除連接，一次TCP的連接建立及拆除，至少進(jìn)行7次通信，可見其成本是很高的。
三次握手、四次揮手的常見面試題
有關(guān)TCP的連接建立的三次握手及拆除過程的四次揮手的面試問題，是技術(shù)面試過程中的出現(xiàn)頻率很高的重點(diǎn)和難點(diǎn)問題，常見問題大致如下：
問題（1）：為什么關(guān)閉連接的需要四次揮手，而建立連接卻只要三次握手呢？
關(guān)閉連接時，被動斷開方在收到對方的FIN結(jié)束請求報文時，很可能業(yè)務(wù)數(shù)據(jù)沒有發(fā)送完成，并不能立即關(guān)閉連接，被動方只能先回復(fù)一個ACK響應(yīng)報文，告訴主動斷開方：“你發(fā)的FIN報文我收到了，只有等到我所有的業(yè)務(wù)報文都發(fā)送完了，我才能真正的結(jié)束，在結(jié)束之前，我會發(fā)你FIN+ACK報文的，你先等著”。所以，被動斷開方的確認(rèn)報文，需要拆開成為兩步，故總體就需要四步揮手。
而在建立連接場景中，Server端的應(yīng)答可以稍微簡單一些。當(dāng)Server端收到Client端的SYN連接請求報文后，其中ACK報文表示對請求報文的應(yīng)答，SYN報文用來表示服務(wù)端的連接也已經(jīng)同步開啟了，而ACK報文和SYN報文之間，不會有其他報文需要發(fā)送，故而可以合二為一，可以直接發(fā)送一個SYN+ACK報文。所以，在建立連接時，只需要三次握手即可。
問題（2）：為什么連接建立的時候是三次握手，可以改成兩次握手嗎？
三次握手完成兩個重要的功能：一是雙方都做好發(fā)送數(shù)據(jù)的準(zhǔn)備工作，而且雙方都知道對方已準(zhǔn)備好；二是雙方完成初始SN序列號的協(xié)商，雙方的SN序列號在握手過程中被發(fā)送和確認(rèn)。
如果把三次握手改成兩次握手，可能發(fā)生死鎖。兩次握手的話，缺失了Client的二次確認(rèn)ACK幀，假想的TCP建立的連接時二次揮手，可以如下圖所示：
圖：假想的TCP建立的連接時二次握手的示意圖
在假想的TCP建立的連接時二次握手過程中，Client發(fā)送Server發(fā)送一個SYN請求幀，Server收到后發(fā)送了確認(rèn)應(yīng)答SYN+ACK幀。按照兩次握手的協(xié)定，Server認(rèn)為連接已經(jīng)成功地建立了，可以開始發(fā)送數(shù)據(jù)幀。這個過程中，如果確認(rèn)應(yīng)答SYN+ACK幀在傳輸中被丟失，Client沒有收到，Client將不知道Server是否已準(zhǔn)備好，也不知道Server的SN序列號，Client認(rèn)為連接還未建立成功，將忽略Server發(fā)來的任何數(shù)據(jù)分組，會一直等待Server的SYN+ACK確認(rèn)應(yīng)答幀。而Server在發(fā)出的數(shù)據(jù)幀后，一直沒有收到對應(yīng)的ACK確認(rèn)后就會產(chǎn)生超時，重復(fù)發(fā)送同樣的數(shù)據(jù)幀。這樣就形成了死鎖。
問題（3）：為什么主動斷開方在TIME-WAIT狀態(tài)必須等待2MSL的時間？
原因之一：主動斷開方等待2MSL的時間，是為了確保兩端都能最終關(guān)閉。假設(shè)網(wǎng)絡(luò)是不可靠的，被動斷開方發(fā)送FIN+ACK報文后，其主動方的ACK響應(yīng)報文有可能丟失，這時候的被動斷開方處于LAST-ACK狀態(tài)的，由于收不到ACK確認(rèn)被動方一直不能正常的進(jìn)入CLOSED狀態(tài)。在這種場景下，被動斷開方會超時重傳FIN+ACK斷開響應(yīng)報文，如果主動斷開方在2MSL時間內(nèi)，收到這個重傳的FIN+ACK報文，會重傳一次ACK報文，后再一次重新啟動2MSL計(jì)時等待，這樣，就能確保被動斷開方能收到ACK報文，從而能確保被動方順利進(jìn)入到CLOSED狀態(tài)。只有這樣，雙方都能夠確保關(guān)閉。反過來說，如果主動斷開方在發(fā)送完ACK響應(yīng)報文后，不是進(jìn)入TIME_WAIT狀態(tài)去等待2MSL時間，而是立即釋放連接，則將無法收到被動方重傳的FIN+ACK報文，所以不會再發(fā)送一次ACK確認(rèn)報文，此時處于LAST-ACK狀態(tài)的被動斷開方，無法正常進(jìn)入到CLOSED狀態(tài)。
原因之二：防止“舊連接的已失效的數(shù)據(jù)報文”出現(xiàn)在新連接中。主動斷開方在發(fā)送完最后一個ACK報文后，再經(jīng)過2MSL，才能最終關(guān)閉和釋放端口，這就意味著，相同端口的新TCP新連接，需要在2MSL的時間之后，才能夠正常的建立。2MSL這段時間內(nèi)，舊連接所產(chǎn)生的所有數(shù)據(jù)報文，都已經(jīng)從網(wǎng)絡(luò)中消失了，從而，確保了下一個新的連接中不會出現(xiàn)這種舊連接請求報文。
問題（4）：如果已經(jīng)建立了連接，但是Client端突然出現(xiàn)故障了怎么辦？
TCP還設(shè)有一個保活計(jì)時器，Client端如果出現(xiàn)故障，Server端不能一直等下去，這樣會浪費(fèi)系統(tǒng)資源。每收到一次Client客戶端的數(shù)據(jù)幀后，Server端都的?；钣?jì)時器會復(fù)位。計(jì)時器的超時時間通常是設(shè)置為2小時，若2小時還沒有收到Client端的任何數(shù)據(jù)幀，Server端就會發(fā)送一個探測報文段，以后每隔75秒鐘發(fā)送一次。若一連發(fā)送10個探測報文仍然沒反應(yīng)，Server端就認(rèn)為Client端出了故障，接著就關(guān)閉連接。如果覺得保活計(jì)時器的兩個多小時的間隔太長，可以自行調(diào)整TCP連接的?；顓?shù)。
總結(jié)
以上是生活随笔為你收集整理的太棒了！TCP/IP协议 （图解+秒懂+史上最全）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： nginx修改upstream不重启的方
- 下一篇： 开始学习jQuery和准备工作