1 引言
學分分析抓到的數據包是創作本文最初的目的，從而形成了以數據的視角看待數通網絡的思考維度。以數據的視角來看待我們的計算機網絡，這可能是理解它最好的思考方式和思想主線。
本文不僅詳細介紹了數據在網絡中的傳輸過程及表現形式，並通過相應抓包實例展示這些實現，試圖使抽象的概念變得觸手可及，這也是創作本書努力想要達到的目的，理論和實際緊密結合，從而讓理論變得易於理解。這種敘述方式貫穿全書，通過各點擊破從而掌控整個數據通信網絡系統全局。
如果你對抓包協議分析工具的使用有疑問，請出門右轉往前走，移步到《Wireshark抓包實戰》。
2 數據在網絡中的傳輸
所有的數據對於網絡來說都是業務，不同的業務數據對傳輸的要求不一樣，就需要有不同的信令協議來滿足它，不同的信令協議對數據的封裝和標識提出了不同的要求，從而又產生了各種封裝協議和標識協議。現在就讓我們從業務數據的角度來對數據通信網絡做一個全面的、宏觀的、高屋建瓴認識。
在數通網絡模型中，每一個上層對於下層來說都是業務、是應用、是數據；每一個下層對於上層來說都是服務。下層協議通過SAP（Service Access Point 服務訪問點）爲上層協議提供服務，每一層對SAP的實現方式（或表現形式）都不一樣。以TCP/IP模型爲例，傳輸層使用TCP、UDP或SCTP協議，應用層的程序通過調用TCP、UDP或SCTP端口號(Port Number)獲得傳輸層服務；網絡層使用IPv4或IPv6協議，通過IP協議號(IP Protocol Number)或Next Header區分使用網絡層服務的協議；網絡接入層基本上是以太網的天下，以太網通過以太網類型(Ethernet Type)來區分使用網絡接入層的協議。我們把端口號、IP協議號和以太網類型統稱之爲服務標誌。
在發送端，數據從上層到下層逐層封裝，並打上它在下層註冊的服務標誌；在接收端，數據再從下層到上層逐層拆解，根據標記的服務標誌，送給對應的上層協議去處理，這就是所謂的對等層通信。數據最終會送到應用層相應的應用程序，經應用程序解析並處理後提供給用戶或做進一步處理。
數據在網絡模型中的封裝與拆解，如下圖02-01：
圖 02-01 數據在網絡各層次中的表現形式
在TCP/IP網絡模型中，可以簡單地理解各層的功能如下：應用層是用戶接口，負責用戶數據數字化；傳輸層是數據進入網絡的接口，負責將數據封裝成網絡Socket；互聯網層提供組網與網際互聯，負責數據在網絡中的轉發；網絡接入層負責爲用戶的聯網設備提供接入網絡的接口。其實在網絡接入層中還應分出一個物理層，它負責將數字數據信號化，即將數字數據轉換成電、光、或載波等物理信號。
我們無法將目前壟斷局域網的以太網單獨歸入OSI模型的數據鏈路層或物理層，因爲它同時實現了數據鏈路層和物理層的功能，將其歸入TCP/IP的網絡接入層才更合適。
用戶通過調用應用程序，產生計算能夠識別和處理的數據。
數據通過傳輸層Socket封裝，進入網絡進行傳輸。
互聯網層在轉發數據時需要先做三件事：1）計算本節點到目的節點的出口，即路由；2）對業務數據進行本層的標記封裝；3）最後纔是轉發數據到對應的路由出口。計算路由和封裝數據並沒有先後順序，但一般的情況是先計算好路由，數據來的時候直接封裝並轉發。
在還沒有發展出IP網絡的時候，即在網絡發展的較早期階段或簡單組網場景中，數據轉發沒有或不需要網絡層封裝與轉發，使用的是數據鏈路層的封裝與轉發。爲了解決二層設備的兼容性和線路複用等問題，才發展出了網關和IP網絡。
傳說桑迪.勒納（Sandy Lerner）和丈夫雷納爾德.博薩科（Leonard Bosack）在斯坦福大學讀研和任教時相識，兩人爲了解決使用不同電腦及聯網協議傳遞信息的需要，開發出了協議網關產品，後來拿到風投創立了思科系統（CISCO System）公司。這很顯然只是一個浪漫的創業故事（Story），真實性並不足以爲信。
雖然說故事歸故事，但我們還是從CISCO的成功中看到了聯結和連接的重要性。華爲公司後來居上，在聯結和連接的成本和便利性等方面更勝一籌，實現了更大規模連接，創造了更大的價值，最終也成就了更好的自己。
ICT行業天然具有壟斷性。網絡的規模越大，其價值越大；節點的連接數越多，其價值越大。無論個人或組織，都應當千方百計地想辦法加入到更大的價值網絡當中，並儘可能地增加自己的連接數。千萬不要把自己孤立在價值網絡之外。
3 面向網絡的應用程序
我們把使用到網絡的應用程序叫做面向網絡的應用程序，或簡稱爲網絡應用程序。藉助網絡應用程序，我們的數據纔可以在網絡上進行傳輸。面向網絡的的應用程序一方面爲用戶提供人機界面，將用戶數據數字化，另外一方面網絡應用程序通過調用Socket相關操作，進入網絡進行轉發。
4 TCP、UDP與SCTP
從傳輸層開始，數據才真正進入網絡。傳輸層通過提供Socket相關操作接口，爲應用程序數據提供數據進入網絡的入口，並通過不同端口號區分不同的上層應用。
4.1 端口號
傳輸層通過TCP、UDP或SCTP端口號爲上層應用提供服務，不同的端口與對應不同的應用或服務。所有端口號都是由IANA（Internet Assigned Numbers Authority，互聯網號碼分配權威）管理，該組織維護一個在線的數據庫並隨時更新，所有已註冊端口號都會在網站上公佈，鏈接地址如下：https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml。
常見的應用協議及對應端口號如表02-01：
表02-01 常用協議及端口表
Service Name | Port Number | Transport Protocol |
ftp-data | 20 | tcp |
ftp-data | 20 | udp |
ftp-data | 20 | sctp |
ftp | 21 | tcp |
ftp | 21 | udp |
ftp | 21 | sctp |
ssh | 22 | tcp |
ssh | 22 | udp |
ssh | 22 | sctp |
telnet | 23 | tcp |
telnet | 23 | udp |
smtp | 25 | tcp |
smtp | 25 | udp |
dns | 53 | tcp |
dns | 53 | udp |
bootps | 67 | tcp |
bootps | 67 | udp |
bootpc | 68 | tcp |
bootpc | 68 | udp |
tftp | 69 | tcp |
tftp | 69 | udp |
http | 80 | tcp |
http | 80 | udp |
http | 80 | sctp |
pop2 | 110 | tcp |
pop2 | 110 | udp |
pop3 | 110 | tcp |
pop3 | 110 | udp |
sftp | 115 | tcp |
sftp | 115 | udp |
ntp | 123 | tcp |
ntp | 123 | udp |
epmap | 135 | tcp |
epmap | 135 | udp |
profile | 136 | tcp |
profile | 136 | udp |
netbios-ns | 137 | tcp |
netbios-ns | 137 | udp |
netbios-dgm | 138 | tcp |
netbios-dgm | 138 | udp |
netbios-ssn | 139 | tcp |
netbios-ssn | 139 | udp |
imap | 143 | tcp |
imap | 143 | udp |
snmp | 161 | tcp |
snmp | 161 | udp |
snmpstrap | 162 | tcp |
snmpstrap | 162 | udp |
bgp | 179 | tcp |
bgp | 179 | udp |
bgp | 179 | sctp |
imap3 | 220 | tcp |
imap3 | 220 | udp |
efs | 520 | tcp |
router | 520 | udp |
ripng | 521 | tcp |
ripng | 521 | udp |
ibm-db2 | 523 | tcp |
ibm-db2 | 523 | udp |
ldp | 646 | tcp |
ldp | 646 | udp |
mysql | 3306 | tcp |
mysql | 3306 | udp |
bfd-control | 3784 | tcp |
bfd-control | 3784 | udp |
bfd-echo | 3786 | tcp |
bfd-echo | 3786 | udp |
postgre | 5432 | tcp |
postgre | 5432 | udp |
TCP是面向連接的協議，在通信的雙方在交互數據之前先建立起TCP連接，數據傳輸的可靠性比較高，因此也需要更多的標識字段，協議開銷也比較大，通信效率相對UDP較低，缺省的TCP報文頭長度是20Bytes。應用在需要高可靠傳輸場景，廣域網大部應用多采用TCP傳輸。
UDP是無連接的協議，數據交互之前不需要建立連接，數據傳輸的可靠性相對TCP較差，需要的標識字段也比較少，協議開銷小，通信效率高，UDP報文頭長度是8Bytes。應用在需要高效傳輸和網絡質量較好的場景，很多局域網應用都採用UDP傳輸。
4.2 TCP
TCP（Transport Control Protocol，傳輸控制協議），IP協議號是6，是傳輸層一個面向連接的、可靠的傳輸協議。TCP最早在RFC761中描述，後來被RFC793被重新描述並廢棄。對原著有明顯偏好的同學可以移步到IETF官方網站，RFC793鏈接地址是：https://datatracker.ietf.org/doc/rfc793/?include_text=1。
4.2.1 TCP報頭格式
圖02-02 TCP報頭格式 RFC793
TCP報頭說明：
1）TCP報頭寬度是32位；
2）Source Port源端口，長度16位；
3）Destination Port目的端口，長度16位；
4）Sequence Number順序號，長度32位；
5）Acknowledgment Number確認號，長度32位；
6）HLEN，TCP頭部長度，4位長，表示TCP中包含多少個32位字；
7）Reserved，保留，未使用，長度4位；
8）標誌，可以是ACK，PSH，RST，SYN，FIN，用來建立和維護TCP連接等；
9）Window Size窗口大小，表示在確認了字節之後還可以發送多少字節，長度16位；
10）Checksum校驗和，長度16位；
11）Urgent Pointer緊急指針；
12）Options and Padding可選項，0~32字節。
TCP報頭在沒有添加任何選項的情況下是20Bytes，也是TCP報頭的最小長度，實現中通常都是這個長度。
4.2.2 TCP報文實例
在Wireshark網絡協議分析工具顯示的TCP報頭如下圖02-03。
圖02-03 Wireshark網絡協議分析工具顯示的TCP報頭
4.2.3 滑動窗口
TCP協議的流量控制是用窗口機制實現的。在接收端，窗口大小是指本地接收緩衝區的大小；在發送端，窗口大小是指發送緩衝區的大小。窗口的大小通過滑動窗口算法在發送端和接收端進行協商。在報頭字段中用16位表示，最大可表示65535，也是常見的首次協商發起大小。
4.2.4 TCP三次握手
TCP連接建立過程也叫做TCP三次握手(TCP Three Way Handshake)，如下圖02-04。
圖02-04 TCP三次握手
4.2.5 TCP三次握手實驗
圖02-05 TCP SYN
這是一個TCP SYN分節，從上圖02-05我們可以看出如下信息：
1）TCP協議的IP協議號是6；
2）數據是由源地址192.168.1.2發往目的地址104.20.0.85；
3）源端口是本地隨機分配的一個未被佔用的端口1280，目的端口是源端請求的知名端口80；
4）TCP的流索引號是27；
5）SYN序列號是0，即seq = 0；
6）SYN位被設置，即0x02，表示這是一個SYN；
7）窗口大小爲65535。
圖02-06 TCP SYN+ACK
這是一個TCP SYN + ACK分節，從上圖02-06我們可以看出如下信息：
1）TCP協議的IP協議號是6；
2）數據是由源地址104.20.0.85發往目的地址192.168.1.2；
3）源端口是一個知名端口80，目的端口是一個隨機端口1280；
4）TCP的流索引是27，此字段可用來標識一個TCP連接；
5）SYN序列號是0，seq=0；
6）ACK序列號是1，即ack = seq + 1；
7）SYN位和ACK位都被設置，即0x12，表示這是一個SYN+ACK；
8）窗口大小爲29200。
圖02-07 TCP ACK
這是一個TCP ACK分節，從上圖02-07我們可以看出如下信息：
1）TCP協議的協議號是6；
2）數據是由源地址192.168.1.2發往目的地址104.20.0.85；
3）源端口是一個隨機端口1280，目的端口是一個知名端口80；
4）TCP的流索引是27；
5）ACK序列號是1，即ack = seq + 1；
7）ACK位被設置，0x10，表示這是一個ACK；
8）窗口大小爲65536。
至此，流索引爲27 的TCP連接建立成功!
4.3 UDP
UDP （User Datagram Protocol，用戶數據報協議），IP協議號是17，是一個無連接的，盡力而爲的傳輸協議，在數據封裝和傳輸機制上都更加精簡，相對於TCP來說傳輸效率更高。UDP協議在RFC768中描述，對原著有明顯偏好的讀者可以移步到IETF官方網站，鏈接地址是：https://datatracker.ietf.org/doc/rfc768/?include_text=1。
4.3.1 UDP報頭格式
圖02-08 TCP報頭格式 RFC 768
UDP報頭說明：
1）UDP報頭寬度是32位；
2）Source Port，源端口，長度16位；
3）Destination Port，目的端口，長度16位；
4）Length，UDP分段長度，長度16位；
5）Checksum，校驗和，長度16位，可選字段，當不使用檢驗和時，此字段全部置爲0；
UDP報頭的長度是8Bytes。因爲沒有什麼選項，長度相對TCP比較固定。
4.3.2 UDP報文實例
在Wireshark網絡協議分析工具上顯示的UDP報頭，如圖02-09所示。
圖02-09 Wireshark網絡協議分析工具顯示的UDP報頭
從上圖02-09中我們可以看出如下信息：
1）UDP協議的協議號是17；
2）數據是由源地址192.168.1.2發往目的地址163.177.69.40；
3）源端口是一個隨機端口1028，目的端口是一個“知名”端口8000（連企鵝都知道）；
4）報文的長度是178；
5）報文校驗和是0x627f，沒有使能確認；
6）數據內容有170字節。
4.4 SCTP
SCTP（Stream Control Transmission Protocol，流控制傳輸協議）,IP協議號132。它支持多宿主和多流，處理和傳輸數據的效率高；在建立關聯時，服務端不保存狀態，不佔用服務端系統資源，天然具有抗DoS（Denial of Service，拒絕服務）***能力；它唯一不好的地方就是提供亂序消息服務的同時沒有處理好數據亂序的問題。SCTP目前應用相對較少，隨着將來網絡傳輸數據量的增加和安全性的需要，有望得到廣泛應用。SCTP在RFC4960中描述，鏈接地址如下：https://datatracker.ietf.org/doc/rfc4960/?include_text=1
5 IP
IP（Internet Protocol，互聯網協議）是互聯網層最重要的一個協議，根據發展階段不同，有兩個版，分別是IPv4（Internet Protocol Version 4）和IPv6（Internet Protocol Version 4）。IPv4提供32位地址空間，IPv6提供128地址空間。聯網設備數的增加是大概率事件，IPv6的普及也是大概率事件，現在正處在轉折點上。
IP是一個標識協議，提供了兩項非常重要的功能：尋址和破碎。尋址包括編址和把互聯網數據報從源地址轉發到目的地址；破碎就是把大塊的上層應用數據分割並打包成能在網絡上傳輸的小塊，並在接收端把他們重組。IP被設計用在包交換計算機網絡互聯通訊系統中。
5.1 IPv4
IPv4 （Internet Protocol Version 4，互聯網協議版本4），以太網類型是0x0800。互聯網協議爲在不同的互聯繫統中的主機提供主機到主機的數據報服務。Internet Protocol最早在RFC760中定義，後來被RFC791重新描述並廢棄，對原著有明顯偏好的同學可以移步到IETF官方網站，RFC791鏈接地址是：https://datatracker.ietf.org/doc/rfc791/?include_text=1。
5.1.1 IP協議號
IPv4通過協議號爲上層應用提供服務，不同的應用對應不同的IP協議號，號碼也是由IANA管理，在線數據庫地址是：https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml#protocol-numbers-1。
常見的應用協議及對應協議號如表02-02：
表02-02 常用IP協議號及對應協議表
號碼 | 協議縮寫 | 協議名 |
１ | ICMP | Internet Control Message |
2 | IGMP | Internet Group Management |
4 | IPv4 | IPv4 encapsulation Stream |
6 | TCP | Transmission Control Protocol |
17 | UDP | User Datagram Protocol |
88 | EIGRP | Enhanced Interior Gateway Routing Protocol |
89 | OSPF | Open Shortest Path First |
103 | PIM | Protocol Independent Multicast |
112 | VRRP | Virtual Router Redundancy Protocol |
115 | L2TP | Layer Two Tunneling Protocol |
124 | ISIS over IPv4 | ISIS over IPv4 |
132 | SCTP | Stream Control Transmission Protocol |
134 | RSVP-E2E-IGNORE | RSVP-E2E-IGNORE |
137 | MPLS-in-IP | MPLS-in-IP |
5.1.2 IPv4報頭格式
圖02-10 IP報頭格式，rfc791
IPv4報頭結構解釋如下 ：
1）Version 版本，4位，0x0100表示是IPv4；
2）IHL 頭長度，4位，表示32位字長的報文長度，缺省長度20Bytes，也是IP報頭的最小長度；
3）Type of Service 服務類型，8位，用於實現QoS；
4）Total Length 總長度，16位，包括數據和報頭在內的總長，以字節計；
5）Identification 標示，16位，標識一個數據包，與分片偏移字段一起使用，用來標識被分段的數據包。例如，當一個數據包的大小超網絡傳輸的MTU時，被分片的數據包會打上同一標識；
6）Flags 標記，3位，表示是否可以對數據包分段，如果設置爲對大包不分段，可以用來測試網絡中MTU的大小；
7）Fragment Offset 片偏移/分段偏移，13位，以8位組爲單位，用來標示分段起始點相對於報頭起始點的偏移量；
8）Time to Live 生存時間，8位，在UNIX系和新的Windows操作系統上，缺省是64，在多數Windows操作系統上缺省值是128，目前在絕大多數網絡設備上，缺省值都是255，數據包在網絡中傳輸時，每經過1跳就會減1，當此值爲0是包丟棄；
9）Protocol 協議，8位，用來標示封裝的上層應用，用IP協議號來表示，每一個上層協議都會對應一個協議號，如本節開頭所描述；
10）Header Checksum 報頭檢驗和，16位，報頭檢驗和，不包含數據，發送者計算產生，接收者重新計算以校驗對錯，因爲TTL值的變化，每一個轉發者需要重新計算；
11）Source Address 源地址，32位，發送者地址，由4個八位組構成的IP地址；
12）Destination Address 目的地址，32位，接收者地址，由4個八位組構成的IP地址；
13）Options 選項，可變長度，在IP報頭中是可選的，通常都沒有用到；
14）Padding 填充，填充選項，如果選項的長度不夠32位，填充字段用0補足。
有關IP地址更多詳細內容請查閱本書第15章《IP與IP編址》。
5.1.3 IPv4報文實例
IP報頭在WireShark網絡協議分析工具上的顯示如下圖：
圖02-11 IPv4報頭實例，訪問www.ietf.org抓包
從上圖我們可以看出如下信息：
1）這是一個IPv4數據包，源地址是104.20.0.85，目的地址是192.168.6.57；
2）報頭長度是20Byte；
3）沒有提供DSCP QoS（一種服務質量類型）；
4）包總長度是40，單位是Bytes，是指上層數據的長度；
5）包ID是0x2c25(11301)；
6）數據包沒有被分片；
7）當前包的TTL是50；
8）上層協議是TCP，IP協議號是6；
9）頭部校驗和是0xed60，頭部檢驗和禁用；
10）因爲Wireshark頭部檢驗沒有啓用；
11）源地址是104.20.0.85；
12）目的地址是192.168.6.57；
13）源IP地理位置信息，未知；
14）目的IP地理位置信息，未知；
5.2 ARP
ARP，Address Resolution Protocol，地址解析協議。用來查詢出單播目的IP地址對應的下一跳IP地址的MAC地址，然後把查詢出來的這一地址封裝在以太網幀的目的MAC地址。ARP協議在RFC826中描述，對原著有特別偏好的同學可以移步到IETF官方網站，鏈接地址是： https://datatracker.ietf.org/doc/rfc826/?include_text=1。
傳輸層的數據段到達網絡層後要封裝上網絡層的報頭，並添加源和目的IP地址，形成數據包。數據包到達網絡接入層後要封裝以太網報頭並添加源和目的MAC地址。源MAC地址直接封裝出接口地址，目的MAC地址要如何封裝呢？其實目的MAC地址封裝的是目的IP地址對應的下一跳IP地址的MAC地址，有時目的IP地址可能就是下一跳地址，但如果涉及到向外網路由數據那就不是了。具體的實現有三種情況，分別是：
1）對於目的IP是廣播地址，目的地址就是下一跳地址，廣播IP地址（32個1）直接映射爲廣播MAC地址（48個1）；
2）對於目的IP是組播地址，是通過將IP地址的後23位映射到組播MAC地址的後23位來實現的；
3）對於目的IP是單播IP地址，IP地址到MAC地址的映射是通過ARP來完成的。
單播IP地址纔是常態，組播IP地址只有在組播協議或組播應用的網絡中才有，數量也比較小，產生廣播IP地址的場景主要是ARP和DHCP，並以ARP爲主。其實ARP產生的廣播IP也是由單播地址而來。ARP表中沒有MAC地址對應關係的單播地址，其與MAC的對應關係是通過ARP協議查詢得到，ARP查詢的目的地址是廣播地址。
IP地址與MAC地址的對應關係存放在ARP表中，單播IP地址的ARP表的構建需要兩個步驟，如下圖：
圖02-12 ARP請求廣播發送，單播回覆，收到回覆，表項建立成功
1）請求者以廣播形式發送ARP請求，詢問目的IP地址對應的下一跳IP地址的MAC地址，同一個廣播域內的設備都會接收，正常情況下只有實際的IP地址擁有者纔會響應；
2）實際被請求者以單播的形式進行回覆，請求者收到回覆，表項建立成功，交互結束。
ARP Request報文在Wireshark協議分析工具上的顯示：
圖 02-13 ARP請求以廣播形式發送
從圖02-13中我們可以看出：
1）這是一個ARP報文，其以太網類型是0x0806；
2）硬件類型是以太網，Ethernet；
3）協議類型是IP協議；
4）硬件大小是6；
5）協議大小是4；
6）ARP協議的類型是請求，request(0x0001)；
7）不是無故ARP（無償ARP/免費ARP）；
8）發送者的MAC地址是00:1e:65:28:2f:46；
9）發送者的IP地址是192.168.6.30；
10）目標MAC地址是00:00:00:00:00:00；
11）目標IP地址是192.168.6.1。
ARP Reply報文在Wireshark協議分析工具上的顯示：
圖 02-14 ARP回覆以單播形式發送
從圖02-14中我們可以看出：
1）這是一個ARP報文，其以太網類型是0x0806；
2）硬件類型是以太網，Ethernet；
3）協議類型是IP協議；
4）硬件大小是6；
5）協議大小是4；
6）ARP協議的類型是回覆，reply(0x0002)；
7）不是無故ARP（在有些文獻中也被叫做無償ARP或免費ARP）；
8）發送者的MAC地址是；20:a6:80:64:a3:5d；
9）發送者的IP地址是192.168.6.1；
10）目標MAC地址是00:1e:65:28:2f:46；
11）目標IP地址是192.168.6.30。
更多有關ARP的詳細內容請查閱本書本書第16章《ARP及其在生產中的應用》。
5.3 IPv6
基於計算機網絡本身的魅力，再加上5G（Fifth Generation）和IoT（Internet of Things）技術的普及，預期未來聯網設備數將大幅度增加，原來提供32位地址空間的IPv4已經不能滿足現實需要，迫切需要更大的可標識地址空間。中關村在線2019年11月27消息，2019年11月26日全球43億個IPv4地址正式耗盡！
關於下一代互聯網曾提出過很多個方案，最終IPv6勝出。IPv6可提供128位地址空間，是在IPv4經驗教訓的基礎上提出的下一代互聯網協議標準，各國政府都在全力推行，中國也不例外。
在2017年11月26日，中共中央辦公廳、國務院辦公廳印發了《推進互聯網協議第六版（IPv6）規模部署行動計劃》，併發出通知，要求各地區各部門結合實際認真貫徹落實。中國政府網可查全文內容，網頁鏈接地址如下：http://www.gov.cn/zhengce/2017-11/26/content_5242389.htm
2018年05月03日，中國政府網又發佈了工業和信息化部關於貫徹落實《推進互聯網協議第六版（IPv6）規模部署行動計劃的通知》， 中國政府網可查全文內容，網頁鏈接地址如下：http://www.gov.cn/xinwen/2018-05/03/content_5287654.htm
2018年08月03日，工信部通信司召開IPv6規模部署及專項督查工作全國電視電話會議，新聞內容可在中共中央網絡安全和信息化委員全辦公室及中華人民共和國國家互聯網信息辦公室網站可查，網頁鏈接地址如下：http://www.cac.gov.cn/2018-08/04/c_1123220958.htm
中國人民銀行，中國銀行保險監督管理委員會，中國證券監督管理委員會聯合發文（《銀髮【2018】343號》），《關於金融行業貫徹《推進互聯網協議第六版（IPv6）規模部署行動計劃的實施意見》，《意見》對金融行業規模部署IPv6給出指導。
與IPv6相關的RFC文檔有：
RFC1883，RFC2460，RFC5095，RFC5722，RFC5871，RFC6437，RFC6564，RFC6935，RFC6946，RFC7045，RFC7112，RFC8200。
RFC1883，Internet Protocol, Version 6 (IPv6) Specification，是IPv6的最早描述，鏈接地址：https://datatracker.ietf.org/doc/rfc1883/?include_text=1。
RFC2460是目前對IPv6的通用描述，它廢棄了RFC1883，鏈接地址：https://datatracker.ietf.org/doc/rfc2460/?include_text=1。
IPv6的最新內容由RFC8200描述，發佈於2017年10月30日，它廢棄了RFC2460 [4]，鏈接地址：https://datatracker.ietf.org/doc/rfc8200/?include_text=1。
IPv6通過Next Header來區分上層應用，在IPv4協議號的基礎上增加一些IPv6特有的應用。
據IPv6 Forum網站消息，在全球IPv6採用和部署情況方面，中國還是比較落後的，目前排在前面的是比利時63%，德國61%，瑞士57%，美國51%，英國50%。
5.3.1 IPv6特點
IPv6不僅僅是提供了更大的地址空間，同時也優化了IPv4的一些不足，其特點總結如下：
1）將地址空間從32位擴展到128位；
2）簡化報頭格式；
3）改進爲支持擴展選項，更強的擴展能力；
4）報頭中添加流標記域，方便實現服務質量；
5）擴展的安全選項，支持端到端安全；
6）分層地址結構；
7）去掉廣播，添加任播；
8）移動性支持；
9）無狀態自動配置。
5.3.2 IPv6報頭格式
圖 02-15 IPv6報頭格式
IPv6報頭結構解釋如下 ：
Version 版本號，4位，0x0110，就是十進制的6，表示IPv6。
Traffic Class 流分類，8位，用於服務質量。
Flow Label流標籤，20位，標識一個流。
Payload Length 載荷長度，16位，標識負載的長度。
Next Header 下一報頭，8位，標識擴展中的報文類型比如類型，可實現更多擴展功能，比如：值爲43的路由頭，可實現移動IPv6，類型值爲51的認證頭，可用於IPSec，實現端到端加密。IPv6通過可選擴展報頭還可實現目前沒有的功能，其值的定義與IPv4報頭中的Protocol字段定義的值相同，詳情請參閱RFC1700以及與之相關IANA在線文檔[18]。
Hop Limit 跳數限制，8位，可用於限制傳播範圍或防環。
Source Address 源地址，128位。
Destination Address 目的地址，128位。
5.3.3 IPv6報文實例
圖 02-16 IPv6報頭實例
從抓包實例我們可以看出如下信息：
1）這是一個IPv6數據包，Ethernet Type是0x86dd;
2）版本號是0110，即十進制的6，表示IPv6協議；
3）流分類是0x00,未分類或缺省分類；
4）流標籤是0x0000,未標記或缺省標記；
5）數據載荷長度是40，這裏的單位是字節Byte；
6）下一頭類型（Next Header）是58，即ICMPv6；
7）跳數限制是128，即超過128個節點後數據包丟棄；
8）源地址是fe80::1001:9c37:37b3:4990；
9）目的地址是fe80::b0b0:8229:80fd:757b。
後面的內容就是ICMPv6相關的內容。
5.3.4 廣播替代
IPv4網絡最受垢病的就是廣播，在IPv4中有兩個用到廣播的非常重要的協議分別是ARP和DHCP。針對ARP的替代，IPv6中通過ICMPv6的擴展協議NDP實現的；針對DHCP，IPv6中是通過DHCPv6實現的，DHCPv6繼承了DHCP的基本實現思想，但是數據交互通過組播地址實現，消息的數量也由8個變成了13個。
更多有關IPv6的內容請查閱《IPv6》一節。
5.4 IP地址空間分配
IP既可以標識聯網設備，也可以標識破碎後的數據。其中對聯網設備的標示是通過IP地址實現的。IANA維護在其網站維護一個IP地址的分配狀態庫。
IPv4地址空間分配：
https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml。
組播IPv4地址分配：
https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml。
特殊用途IPv4地址：
https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml。
IPv6地址空間分配：
https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml。
IPv6全球單播地址分配：
在地址空間分配上，中國一直處於劣勢。
關於IP地址等更多內容，請參閱《IP地址》一節。
6 MPLS
MPLS,Multiprotocol Label Switching，多協議標籤交換。介於數據鏈路層與網絡層之間的協議，是一個2.5層的協議，有些文獻乾脆就把這一層叫做MPLS層。MPLS上層可以支持IPv4、IPv6、IPX、CLNP等，所以稱之爲多協議。下層可支持Frame Relay，ATM，Ethernet等多種網絡類型。MPLS將上層的數據包添加4Bytes的MPLS報頭，在MPLS域內都進行標籤轉發，轉發效率高，出MPLS域之前會將標籤彈出，從而形成了一個由MPLS構成的***（Virtual Private Network，虛擬專用網）隧道。MPLS層不是必須的存在，園區網基本用不到，但是在運營商環境卻非常普遍。
有關MPLS比較重要的RFC有：
RFC3031，Multiprotocol Label Switching Architecture，推薦標準，定義了MPLS的體系結構，鏈接地址：https://datatracker.ietf.org/doc/rfc3031/?include_text=1。
RFRFC032，MPLS Label Stack Encoding，推薦標準，定義了MPLS標籤格式，鏈接地址：https://datatracker.ietf.org/doc/rfc3032/?include_text=1。
6.1 MPLS報頭格式
02-17 RFC 3032中定義的MPLS標籤結構
各字段定義如下：
Label：定義標籤值，長度20位；
Exp：文檔中說是做實驗用，但我們通常說是擴展位，用來做QoS，長度3位；
S：棧底標識，也叫棧底位，用來標識是否是標籤棧底，長度1位；
TTL：Time to Live，與IPv4中的TTL功能相同，過一跳減1，到0丟棄，可用來防環，長度8位。
6.2 MPLS報文實例
通過Wireshark協議分析工具抓包並顯示的MPLS報文頭，如圖02-18所示：
圖 02-18 MPLS報頭實例
從圖02-18中我們可以看出如下信息：
1）以太網中的Type值是0x8847，表示這是一個MPLS單跳報文；
2）MPLS標籤號是1024，是由BGP分配的動態標籤；
3）MPLS Exp位是6，缺省對應的QoS服務類型是CS6；
4）棧底標記是1，表示是標籤棧底，裏面沒有更多標籤；
5）MPLS TTL值是255，表示這是第一跳MPLS路由器。
6.3 MPLS轉發過程
02-19 RFC 3032中定義的MPLS標籤結構
路由器的存在是依據路由選擇協議（Routing Protocol）規則計算形成路由表（Routing Table），也即路由信息表（RIB，Routing Information Base），路由器對路由信息表中的下一跳地址進行迭代，最終得到一個出接口。這個接口可能是路由器上真實存在的物理接口，也有可能是虛擬的隧道接口（Tunnel Interface），迭代後形成的表就是轉發信息表（FIB，Forwarding Information Base）。路由器轉發數據的依據實際上是FIB。在FIB中，如果目標網段對應的Tunnel ID是0，通過物理接口轉發數據，反之則根據Tunnel ID的值進入相應隧道轉發。
在MPLS路由器上，路由器還可以根據MPLS標籤值，查詢入標籤映射表（ILM，Incoming Label Map），得到Tunnel ID。
路由器拿目標網段對應的Tunnel ID，到下一跳標籤轉發表（NHLFE，Next Hop Label Forward Entry）中查詢得到出接口。NHLFE中除了記錄Tunnel ID對應的出接口，還記錄了Tunnel ID對應的標籤操作類型，如：壓入（Push）、交換（Swap）、彈出（Pop）等。
MPLS路由器除了轉發數據，還需要根據NHLFE中的記錄對標籤進行相應的操作。在入站MPLS路由器（Ingress節點），上層數據（如IP Packet）添加（Push操作）MPLS標籤並進行標籤轉發；在MPLS轉發路由器（Transit節點），路由器轉發帶標籤的數據並更新（Swap操作）出入接口標籤值；在出站MPLS路由器（Egress節點），路由器去掉（Pop操作）標籤，數據交由上層協議（如IP）處理。
更多詳細內容，請查閱本書第25章《MPLS及其應用》。
7 以太網
以太網是最爲典型的網絡接入層LAN實現，至今經歷過兩個版本，分別是Ethernet和Ethernet II，目前的LAN網絡中應用的都是以太網。
以太網是由DEC，Intel，Xerox三家公司在1982年聯合發佈的一個標準，後來轉到由IEEE 802.3委員會維護和更新，目前已經發展到100G以太網。以太網是一個包含了OSI/RM中數據鏈路層和網絡層的內容。我們的個人計算機和服務器等機集成的網卡（NIC，Network Interface Card）一般都是以太網網卡。
以太網是局域網實事上的標準，它通過Type號爲上層應用提供服務，不同的Type號對應不同的應用協議，Type號也是由IANA管理，在線數據庫地址是：https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml。
常見的應用協議及對應Type號如表02-03：
表02-03 常見Ethernet Type號及對應協議
Ethernet Type(hex) | Description |
0x0000~0x05DC | IEEE802.3 Length Field |
0x0100~0x01FF | Experimental |
0x0800 | Internet Protocol version 4 |
0x0805 | X.25 Level 3 |
0x0806 | Address Resolution Protocol |
0x0808 | Frame Relay ARP |
0x0806 | Address Resolution Protocol |
0x22F3 | TRILL |
0x22F4 | L2-IS-IS |
0x8100 | Customer VLAN Tag Type (C-Tag, formerly called the Q-Tag) |
0x8181 | STP, HIPPI-ST |
0x86DD | Internet Protocol version 6 |
0x8808 | IEEE Std 802.3 – Ethernet Passive Optical Network (EPON) |
0x880B | Point-to-Point Protocol (PPP) |
0x8847 | MPLS |
0x8848 | MPLS with upstream-assigned label |
0x8863 | PPP over Ethernet (PPPoE) Discovery Stage |
0x8864 | PPP over Ethernet (PPPoE) Session Stage |
0x888E | IEEE Std 802.1X – Port-based network access control |
0x88A8 | IEEE Std 802.1Q - Service VLAN tag identifier (S-Tag) |
7.1 報文格式
圖02-20 以太網II幀結構
1）Destination Address，目的地址，6字節，接收者的物理地址，通常說的MAC地址，48位二進制位；
2）Source Address，源地址，6字節，發送者的物理地址，48位二進制位；
3）Type/Length，類型/長度，2字節，可以表示幀數據的長度或上層應用的類型，值0~1500表示長度，1536~65535表示上層應用協議的類型，比如0x0800表示是IP，0x0806表示是ARP；
4）Data，數據，可變長度，46~1500字節；
5）FCS，幀校驗序列，一般是循環冗餘校驗，4字節，對事個數據封裝的校驗。
以太網II幀頭長度是18 Bytes，幀數據的最小長度是46 Bytes，最大長度（MTU，Maximum Transmission Unite，最大傳輸單元）是1500 Bytes，整個幀的長度是64~1518 Bytes。如果小於最小長度，則通過填充內容爲0的八位組的方式補齊，填充內容不作爲IP數據包的一部分，也不包含在包頭字段的總長度當中（rfc894）。MAC子層檢測到小於64bytes的幀會當作殘幀丟棄。我們通常設置典型的以太網數據幀數據長度是1500 Bytes，再加上報頭長度18Bytes，因此以太網幀的總長度就是1518bytes，如果超過最大長度，接收端系統會阻止其它系統發送給自己，解決這個問題的辦法是在發送端設置TCP的最大分片大小選項（rfc894），即大塊數據在發送一開始就會被分片。
一個典型的以太網幀在WireShark協議分析工具上的顯示如下圖02-17：
圖02-21 典型以太網幀
從上圖02-21中我們可以看到，以太網II數據幀信息：
1）源MAC地址是00:1e:65:28:2f:26；
2）目的MAC地址是20:a6:80:64:a3:5d；
3）封裝的協議是IP（0x0800）；
以太網II數據幀信息已經是網絡接入層LLC子層的信息了，內容已經開始包含數據層面的信息。
7.2 關於數據鏈路層封裝的一個不成熟思考
以太網是二層局域網實事上的標準，有一統天下之能勢，但是局域網本身也存在一些問題。比如：1）沒有老化機制，當環路發生時，一個數據幀可以在二層網絡中無限傳輸，直到環路消失；2）二層網絡中缺少像ICMP這樣的跟蹤定位工具協議，幀結構相對簡單，網絡問題很難定位；3）48位的MAC地址在未來是否依然夠用？
數據鏈路層封裝當初是怎麼被設計出來的？如果沒有這一層封裝，又會帶來什麼問題？
二層網絡的最大優勢是VLAN，有它，二層組網可以更加簡單方便，成本低廉。如果IPv6發展出合適的擴展報頭及處理機制，二層網絡被取代也不是沒有可能，IPv6交換機也不是沒有可能，如果二層封裝可有可無，以太網的根基也就受到了動搖。
MPLS及其它其它依賴以太網的技術也無法存在了，將會產生什麼樣的影響？有什麼替代的方案？
數據鏈路層封裝到直網絡路層封裝如何過渡？兩種封裝如何共存？
7.3 MAC地址
TCP/IP將網絡接入層（Network Access Layer）又劃分爲LLC（Logical Link Control，邏輯鏈路控制）子層和MAC（Media Access Control，介質訪問控制）子層。介質訪問控制地址是最受我們關注的一個存在，它由48位構成，經常用12個十六進制位表示。
1）這是一個燒錄（Burn In）地址，一次性寫入，不再更改。
2）MAC地址的前24位代表一個組織，叫OUI（Organizationally Unique Identifier 組織唯一標識符），可以通過下面的連接查詢：
3）後24位是流水號，所以設備的MAC地址在正常情況下是不會重複的。
MAC地址的唯一性，可以幫助我們鎖定某一臺設備。
MAC地址的分配也是由IANA來管理，在線數據庫地址是：https://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml。
8 物理信號
物理層最爲基礎和底層，其主要功能是將數字數據信號化，另外還提供接口形式，引腳定義，電壓和光強等。所有的數字都會被轉換成由0和1組成的編碼，這些編碼在以電爲信號的網絡中由電壓高低或電壓變化來表示，在以光爲信號的網絡中由有無光或有無光變化來表示，在以電磁波爲信號的網絡中由載波有無和載波有無變化來表示，我們把將數字數據信號化爲物理信號的過程叫做數字數據的信號化。
8.1 幀物理
很多文檔或教材中也會把二層以太剛幀之前的幀起始定界符，前導（也叫前同步碼是二進制10101010 10101010 10101010 10101010 10101010 10101010 10101010），甚至包括幀間隙，三者都視之爲以太網幀的組成部分。這種理解也許說不上錯，甚至也有其合理之處，但是更合理的理解是把它當作幀的物理信息來看待。
從上圖02-21中我們可以看到，物理幀相關信息：
1）幀序號19，是指在本次抓包中的排序，僅在本次抓包中有意義；
2）接收時間是中國標準時間2016年6月16日10時03分45秒303545000；
3）新紀元時間1466042625.303545000秒；
4）距離上一幀捕獲時間0.002398000秒；
5）距離上一幀顯示時間0.002398000秒；
6）距離第一幀時間10.290923000秒；
7）幀序號19；
8）幀長度106字節（848位）；
9）捕獲長度106字節（848位）；
10）幀沒有被標記；
11）幀沒有被忽略；
12）着色規則名稱ICMP；
13）着色規則字串ICMP或ICMPv6；
14）幀長度是106字節。
幀信基本息其實是物理層的信息，從物理世界直接得到的信息。物理層判斷幀的起止是通過一串特殊的字符，其實也可以把這一串特殊的字符都看作是數據鏈路層幀的前導字段。
8.2 幀間隙與幀時隙
計算機設備在發送數據幀時並不是連續的，即每發送完一個幀需要等待一個時間纔可以發送下一個幀，其目的是爲了讓接收者能夠處理得過來而不至於擁塞。這個等待的時間間隔我們把它叫做幀間隔或幀間隙（Inter Frame Gap，IFG），它表示一個站點連續發送數據時，幀與幀之間的空閒時間或間隔時間，但是其量綱卻不是時間（time），而是比特（bit），比如10/100Mbps以太網的幀時隙就是96Bits，它指的是96位的數據通過線路的時間。Gbps以太網幀間隙是4096Bits。
幀時隙(IFS，Inter Frame Slot)也叫幀時槽，用來表示每一個數據幀佔用的最小時間長度，比如10/100Mbps以太網的幀時隙就是512Bits，它是由最小幀數據長度46Bytes + 18Bytes的幀頭信息計算得來。在10/100Mbps鏈路上，如果512位Bits時間仍然沒有收到，則認爲線路是空閒的，而小於512Bytes的幀則認爲是殘幀。
定義幀時隙是爲了共享線路從而提高其利用率，此檢查機制通過CSMA/CD（Carrier Sense Multiple Access/Collision Detection，帶衝突檢測的載波偵聽多路訪問）實現。在10Mbps以太網中，512Bits數據傳輸的時間是51.2us，5-4-3原則最大傳輸距離是2500m，而根據電磁波的傳輸角度來看，512Bits在10Mbps以太網最大可傳輸2800m。在100Mbps中，512Bits的數據傳輸完需要5.12us，電磁波在這個時間可傳輸約200m。以太網傳輸距離的限制最主要的原因其實是基於幀間隔與幀時隙基礎上的CSMA/CD，其次纔是信號強度的問題。在一些通訊距離較遠，而又無法添加中繼設備的場景中，我們需要還到另外一個技術，叫長距離以太網（Long Reach Ethernet，LRE），它除了將物理信號增強和提高信號檢測的能力外，很重要的一點就是修改了幀間隙。因爲幀間隙的修改，LRE設備都需要成對使用，否則時隙不一致就會導致衝突的產生。
9 數據傳遞實例
當我在瀏覽器的地址欄裏填入http://www.ietf.org/並回車，到我看到IETF的網頁，這中間發生了什麼？
瀏覽器首先調socket()函數在本地創建一個大於1024的未被佔用的隨機端口，再用connect()函數與遠端主機www.ietf.org的80端口連接，待TCP連接建立成功後，再使用write()函數將HTTP GET進行封裝，發送給www.ietf.org這臺主機。
www.ietf.org這臺主機如果我剛剛已經訪問過，那麼主機對應的IP地址就會在我的電腦上進行緩存（Windows主機可能通過ipconfig /displaydns查看），如果在緩存中沒有查到，再去查詢etc/hosts文件，文件中也沒有查到時，就會向DNS Server發起遞歸查詢，直到找到主機www.ietf.org的IP地址，並把它封裝到IP頭的目的地址字段，源地址封裝我電腦的對應出口的IP地址，Protocol字段標記爲6。
數據在數據鏈路層又封裝上以太網標記，其中源MAC地址封裝我電腦對應出接口的MAC地址，目的地址封裝目的IP地址對應的下一跳的MAC地址，這個地址如果ARP表中有，就直接查得並封裝，如果沒有，則通過發送ARP Request進行查詢，收到對應的ARP Reply，則可以完成ARP表項，從而完成數據鏈路層封裝。封裝後的數據到達物理層，經過編碼轉化後形成二進制比特流（Bit Flowing）。
如果中間轉發設備是以太網交換機，交換機會根據會根據數據幀目的MAC地址和源MAC地址，查MAC地址表（MAC Address Table）和相關的策略進行轉發，且保持原數據幀不變。關於MAC地址表構建過程及數據幀轉發的更多詳細內容請參閱《STP及其在生產中的應用》一節。
如果中間轉發設備是路由器設備，路由器收到數據幀查看其報頭，發現其Ethernet Type字段的值是0x0800，把它交給IPv4進程處理。路由器的功能是依據網絡層地址轉發數據包，轉發的依據是轉發信息表（FIB，Forwarding Information Base），轉發表來自於路由信息表（RIB，Routing Information Base），路由表來自於路由選擇協議（Routing Protocol）。路由器轉發數據出去之前需要像主機一樣從上到下重新封裝，不過它封裝是從網絡層及以下開始，重新添加以太網幀頭信息，我們把這個過程叫做重新成幀。在重新成幀時因爲封裝目的MAC地址字段的需要，需要查詢ARP表，這裏的目的MAC字段同樣填充的是目的IP地址對應的下一跳IP地址的MAC地址。有關路由器轉發數據的過程的更多詳細內容請查閱本書《路由選擇》一節。
轉發設備是路由器設備，但Ethernet Type字段的值是0x8847或0x8848，路由器會將數據送給MPLS進程處理，並根據MPLS標籤進行轉發。
中間可能還經過了傳送網設備或其它轉發設備，但是它們基本上都是把IP當作業務來處理的，做的是打包、封裝、轉發、拆解，還原爲IP包過程。
數據經過多次查錶轉發（MAC地址表和路由轉發表等），終於來到接收端，即IETF的Web服務器上。在TCP連接請求到達www.ietf.org主機之前，Web服務程序使用socket()函數創建一個端口，端口號是80，並用bind()函數使之與網絡層地址相關聯，並使用listen()函數監聽這個端口，等待用戶的TCP連接請求。當我發送的TCP連接請求被傳送到www.ietf.org這臺主機上時，依次從以太網封裝開始向上層拆解。以太網層的封裝Ethernet Type字段的值是0x0800，送給網絡層，由IP來處理；網絡層發現IP Protocol字段的值是6，送給傳輸層，由TCP來處理；傳輸層發現TCP端口號是80，www.ietf.org主機上HTTP應用服務使用accept()函數接受我電腦發送過來的TCP連接請求。
TCP連接建立之後，就收到了我從電腦上發過來的HTTP GET請求，HTTP服務進程根據GET請求的內容，回覆我相應的HTML文檔。回送過來的數據同樣要經過從上層到下層的封裝，經過網絡設備的轉發，當到達我的電腦後，再經過由下層到上層的逐層拆解，最終送到我電腦上發出請求的應用程序—瀏覽器，瀏覽器收到HTML文檔，解析並呈現出來。於是就出現了圖02-22的畫面。
圖02-22 在瀏覽器的地址欄填下網站的地址並回車，
中間發生了很多奇妙的事情
不管是在服務端和客戶端，數據都是由應用層產生並逐層向下傳遞，在接收方，數據先由物理層接收並逐層向上傳遞，最終送給應用層的應用程序。中繼設備只關心物理層；交換機關心數據鏈路層和物理層，重點在數據鏈路層；路由器關心下面三層，重點在網絡層；個人電腦或服務器等端計算設備或主機設備擁有相對完備的協議棧，但端計算設備和主機設備重點關注的是應用層。
10 飯後思考題
1）爲什麼TCP首部長度的字段，而UDP沒有？
2）有什麼辦法可以取代低效的TCP，並保留它的可靠性？
3）數據在網絡上傳遞的過程中，要經過不同類型的網絡設備，源IP、目的IP、源MAC、目的MAC經過這些設備後是否會重新封裝？如何封裝？
4）長距離以太網設備爲什麼要成對使用？
5）全棧升級到IPv6需要怎麼做？需要用到哪些技術？有哪些注意事項？