作者：Vamei 出處：http://www.cnblogs.com/vamei

1. OSI模型

• 物理層(physical layer)：光纖、電纜或者電磁波等真實存在的物理媒介。0/1信號
• 連接層(link layer)：在連接層，信息以幀(frame)為單位傳輸。一串0/1序列，包括了收信地址(Source, SRC)和送信地址(Destination, DST)，還有能夠探測錯誤的校驗序列(Frame Check Sequence)及符合更高層協議的數據信息。以太網(Ethernet)和WiFi是現在最常見的連接層協議。類似于郵差，收到信封。
• 網絡層(network layer)：不同的社區之間通信需要用到路由器。路由器能夠：1. 能從物理層上在兩個網絡的接收和發送0/1序列，2. 能同時理解兩種網絡的幀格式。IP協議。路由器和計算機都懂得IP協議。類似于郵局。
• 傳輸層(transport layer)：找到了某一臺計算機，靠傳輸層判斷是交給哪個進程。TCP/UDP協議。TCP協議還有控制網絡交通等功能。
• 應用層(application layer)：應用層協議是對信件內容進一步的用語規范。應用層的協議包括用于Web瀏覽的HTTP協議，用于傳輸文件的FTP協議，用于Email的IMAP等等。

2. 連接層

以太網和WiFi是連接層的兩種協議。在連接層，信息以幀(frame)為單位傳輸。幀像信封一樣將數據(payload)包裹起來，并注明收信地址和送信地址。連接層實現了“本地社區”的通信。
幀本身是一段有限的0/1序列。它可以分為頭部、數據(Payload)和尾部三部分:

幀按照上面的順序從頭到尾依次被發送/接收。

• 幀的最初7個byte被稱為序言(preamble)。它的每個byte都是0xAA(這里是十六進制，也就是二進制的10101010)。為了與發送設備的頻率一致，這個過程就叫做時鐘復原(recover the clock)。
• 幀的起始信號(SFD, start frame delimiter)。SFD是固定的值0xAB。
• 緊隨SFD之后的是6 byte的目的地(DST, destination)和6 byte的發出地(SRC, source)。對地址的“本地描述”，也就是MAC地址。MAC地址是物理設備自帶的序號，只能在同一個以太網中被識別 。
• 頭部的最后一個區域是Type，用以說明數據部分的類型。(比如0x0800為IPv4，0x0806為ARP)。
• 數據一般包含有符合更高層協議的數據，比如IP包。連接層協議本身并不在乎數據是什么，它只負責傳輸。注意，數據尾部可能填充有一串0(PAD區域)。原因是數據需要超過一定的最小長度。
• 跟隨在數據之后的是校驗序列(FCS, Frame Check Sequence)。校驗序列是為了檢驗數據的傳輸是否發生錯誤。FCS采用了CRC(Cyclic Redundancy Check)算法。

2.1 集線器(Hub) vs. 交換器(Switch)

以太網使用集線器或者交換器將幀從發出地傳送到目的地。一臺集線器或交換器上有多個端口，每個端口都可以連接一臺計算機(或其他設備)。
一臺電腦將幀發送到集線器，集線器會將幀轉發到所有其他的端口。每臺計算機檢查自己的MAC地址是不是符合DST。如果不是，則保持沉默。缺點在于：1. 相當于廣播，不安全。 2. 多個客戶端向集線器同時發送消息時，會產生沖突。
交換器克服集線器的缺陷。交換器記錄有各個設備的MAC地址。當幀發送到交換器時，交換器會檢查DST，然后將幀只發送到對應端口。交換器允許多路同時通信。由于交換器的優越性，交換器基本上取代了集線器。但比較老的以太網還有可能在使用集線器。

交換機對MAC地址的記錄表也是逐漸生成的。收到一個有frame的時候，記錄下發出地的端口和MAC地址，如果MAC表為空，則像每個端口轉播這個frame，等到正確的機器接收到frame并回復時就知道了接受地的端口和MAC地址對應。

2.2 WiFi

WiFi的工作方式與集線器連接下的以太網類似。一個WiFi設備會向所有的WiFi設備發送幀，其它的WiFi設備檢查自己是否符合DST。由于WiFi采取無線電信號，所以很難像交換器一樣定向發送，所以WiFi的安全性很值得關注。WiFi采用加密的方法來實現信息的安全性。

3. 網絡層

網絡層(network layer)是實現互聯網的最重要的一層。正是在網絡層面上，各個局域網根據IP協議相互連接，最終構成覆蓋全球的Internet。
IP數據包是符合IP協議的信息(也就是0/1序列)，IP包分為頭部(header)和數據(Data)兩部分。數據部分是要傳送的信息，頭部是為了能夠實現傳輸而附加的信息。

3.1 IP包

IPv4

3.2 網卡與路由器

IP地址實際上識別的是網卡(NIC, Network Interface Card)。網卡是計算機的一個硬件，它在接收到網路信息之后，將信息交給計算機(處理器/內存)。當計算機需要發送信息的時候，也要通過網卡發送。
路由器(router)實際上就是一臺配備有多個網卡的專用電腦。它讓網卡接入到不同的網絡中。

3.3 IP包傳輸

IP包的傳輸要通過路由器的接力。每一個主機和路由中都存有一個路由表(routing table)。路由表根據目的地的IP地址，規定了等待發送的IP包所應該走的路線。
IP包可以進一步接力，到達更遠的主機。IP包從主機出發，根據沿途路由器的routing table指導，在router間接力。IP包最終到達某個router，這個router與目標主機位于一個局域網中，可以直接建立連接層的通信。最后，IP包被送到目標主機。這樣一個過程叫做routing。
整個過程中，IP包不斷被主機和路由封裝入幀(信封)并拆開，然后借助連接層，在局域網的各個NIC之間傳送幀。整個過程中，我們的IP包的內容保持完整，沒有發生變化。最終的效果是一個IP包從一個主機傳送到另一個主機。利用IP包，我們不需要去操心底層(比如連接層)發生了什么。

3.4 ARP協議

每一臺主機和路由都能了解局域網內的IP地址和MAC地址的對應關系，這是實現IP包封裝(encapsulation)到幀的基本條件。IP地址與MAC地址的對應是通過ARP協議傳播到局域網的每個主機和路由。每一臺主機或路由中都有一個ARP cache，用以存儲局域網內IP地址和MAC地址如何對應。
ARP協議(ARP介于連接層和網絡層之間，ARP包需要包裹在一個幀中)的工作方式如下：主機會發出一個ARP包，該ARP包中包含有自己的IP地址和MAC地址。通過ARP包，主機以廣播的形式詢問局域網上所有的主機和路由：我是IP地址xxxx，我的MAC地址是xxxx，有人知道199.165.146.4的MAC地址嗎？擁有該IP地址的主機會回復發出請求的主機：哦，我知道，這個IP地址屬于我的一個NIC，它的MAC地址是xxxxxx。由于發送ARP請求的主機采取的是廣播形式，并附帶有自己的IP地址和MAC地址，其他的主機和路由會同時檢查自己的ARP cache，如果不符合，則更新自己的ARP cache。
這樣，經過幾次ARP請求之后，ARP cache會達到穩定。如果局域網上設備發生變動，ARP重復上面過程。

3.5 Routing table

Routing table描述了網絡的拓撲(topology)結構。
一種用來生成routing table的協議是RIP(Routing Information Protocol)。它通過距離來決定routing table，所以屬于distance-vector protocol。對于RIP來說，所謂的距離是從出發地到目的地途徑的路由器數目(hop number)。

一個路由向其他路由廣播它的table，其他路由根據收到的包更新自己的table

RIP出于技術上的原因(looping hops)，認為距離超過15的IP不可到達。所以RIP更多用于互聯網的一部分(比如整個中國電信的網絡)。這樣一個互聯網的部分往往屬于同一個ISP或者有同一個管理機構，所以叫做自治系統(AS,autonomous system)。自治系統內部的主機和路由根據通向外部的邊界路由器來和其它的自治系統通信。各個邊界路由器之間通過BGP(Border Gateway Protocol)來生成自己前往其它AS的routing table，而自治系統內部則參照邊界路由器，使用RIP來決定routing table。BGP的基本工作過程與RIP類似，但在考慮距離的同時，也權衡比如政策、連接性能等其他因素，再決定交通的走向(routing table)。

3.6 IP協議

IP協議是"Best Effort"式的，IP傳輸是不可靠的。但這樣的設計成就了IP協議的效率。

3.7 ICMP協議

ICMP(Internet Control Message Protocol)是介于網絡層和傳輸層的協議。它的主要功能是傳輸網絡診斷信息。

常見的ICMP包類型

回音
回音(Echo)屬于咨詢信息。ping命令就是利用了該類型的ICMP包。當使用ping命令的時候，將向目標主機發送Echo-詢問類型的ICMP包，而目標主機在接收到該ICMP包之后，會回復Echo-回答類型的ICMP包，并將詢問ICMP包包含在數據部分。ping命令是我們進行網絡排查的一個重要工具。如果一個IP地址可以通過ping命令收到回復，那么其他的網絡協議通信方式也很有可能成功。

源頭冷卻
源頭冷卻(source quench)屬于錯誤信息。如果某個主機快速的向目的地傳送數據，而目的地主機沒有匹配的處理能力，目的地主機可以向出發主機發出該類型的ICMP包，提醒出發主機放慢發送速度(請溫柔一點吧)。

目的地無法到達
目的地無法到達(Destination Unreachable)屬于錯誤信息。如果一個路由器接收到一個沒辦法進一步接力的IP包，它會向出發主機發送該類型的ICMP包。比如當IP包到達最后一個路由器，路由器發現目的地主機down機，就會向出發主機發送目的地無法到達(Destination Unreachable)類型的ICMP包。目的地無法到達還可能有其他的原因，比如不存在接力路徑，比如不被接收的端口號等等。

超時
超時(Time Exceeded)屬于錯誤信息。IPv4中的Time to Live(TTL)和IPv6中的Hop Limit會隨著經過的路由器而遞減，當這個區域值減為0時，就認為該IP包超時(Time Exceeded)。Time Exceeded就是TTL減為0時的路由器發給出發主機的ICMP包，通知它發生了超時錯誤。
traceroute就利用了這種類型的ICMP包。traceroute命令用來發現IP接力路徑(route)上的各個路由器。它向目的地發送IP包，第一次的時候，將TTL設置為1，引發第一個路由器的Time Exceeded錯誤。這樣，第一個路由器回復ICMP包，從而讓出發主機知道途徑的第一個路由器的信息。隨后TTL被設置為2、3、4，...，直到到達目的主機。這樣，沿途的每個路由器都會向出發主機發送ICMP包來匯報錯誤。traceroute將ICMP包的信息打印在屏幕上，就是接力路徑的信息了。

重新定向
重新定向(redirect)屬于錯誤信息。當一個路由器收到一個IP包，對照其routing table，發現自己不應該收到該IP包，它會向出發主機發送重新定向類型的ICMP，提醒出發主機修改自己的routing table。

4. 傳輸層

4.1 UDP

UDP(User Datagram Protocol)傳輸與IP傳輸非常類似。你可以將UDP協議看作IP協議暴露在傳輸層的一個接口。UDP協議同樣以數據包(datagram)的方式傳輸，它的傳輸方式也是"Best Effort"的，所以UDP協議也是不可靠的(unreliable)。
UDP的數據包同樣分為頭部(header)和數據(payload)兩部分。UDP是傳輸層(transport layer)協議，這意味著UDP的數據包需要經過IP協議的封裝(encapsulation)，然后通過IP協議傳輸到目的電腦。隨后UDP包在目的電腦拆封，并將信息送到相應端口的緩存中。

4.2 TCP

TCP

TCP協議是傳輸層協議，實現的是端口到端口(port)的通信。更進一步，TCP協議虛擬了文本流(byte stream)的通信。
TCP協議確保了數據到達的順序與文本流順序相符。
是TCP協議所規定的片段(segment)。與之前的一個IP或者UDP數據包類似，一個TCP片段同樣分為頭部(header)和數據(payload)兩部分
(給文本流分段是在發送主機完成的，而碎片化是在網絡中的路由器完成的。路由器要處理許多路的通信，所以相當繁忙。文本流提前在發送主機分好段，可以避免在路由器上執行碎片化，可大大減小網絡負擔)

TCP的補救方法是，在每收到一個正確的、符合次序的片段之后，就向發送方(也就是連接的另一段)發送一個特殊的TCP片段，用來知會(ACK，acknowledge)發送方：我已經收到那個片段了。這個特殊的TCP片段叫做ACK回復。如果一個片段序號為L，對應ACK回復有回復號L+1，也就是接收方期待接收的下一個發送片段的序號。如果發送方在一定時間等待之后，還是沒有收到ACK回復，那么它推斷之前發送的片段一定發生了異常。發送方會重復發送(retransmit)那個出現異常的片段，等待ACK回復，如果還沒有收到，那么再重復發送原片段... 直到收到該片段對應的ACK回復(回復號為L+1的ACK)。
當發送方收到ACK回復時，它看到里面的回復號為L+1，也就是發送方下一個應該發送的TCP片段序號。發送方推斷出之前的片段已經被正確的接收，隨后發出L+1號片段。ACK回復也有可能丟失。對于發送方來說，這和接收方拒絕發送ACK回復是一樣的。發送方會重復發送，而接收方接收到已知會過的片段，推斷出ACK回復丟失，會重新發送ACK回復。

通過ACK回復和重新發送機制，TCP協議將片段傳輸變得可靠。

滑窗(sliding window)被同時應用于接收方和發送方，以解決以上問題。發送方和接收方各有一個滑窗。當片段位于滑窗中時，表示TCP正在處理該片段。滑窗中可以有多個片段，也就是可以同時處理多個片段。滑窗越大，越大的滑窗同時處理的片段數目越多(當然，計算機也必須分配出更多的緩存供滑窗使用)。

網絡層在邏輯上提供了端口的概念。一個IP地址可以有多個端口。一個具體的端口需要IP地址和端口號共同確定(我們記為IP:port的形式)。一個連接為兩個IP:port之間建立TCP通信。
參與連接的如果是兩臺電腦，那么兩臺電腦操作系統的TCP模塊負責建立連接。每個連接有四個參數(兩個IP，兩個端口)，來表明“誰在和誰通話”。每臺電腦都會記錄有這四個參數，以確定是哪一個連接。如果這四個參數完全相同，則為同一連接；如果這四個參數有一個不同，即為不同的連接。這意味著，同一個端口上可以有多個連接。

ACK（一位）回復“附著”在發送的數據片段中。TCP協議是雙向的。比如A和B兩個電腦。ACK回復是接收方回復給發送方 (比如A發送給B， B回復A)。但同時，B也可以是發送方，B有可能有數據發送給A，所以B就把ACK回復附著在它要發送給A的數據片段的頭部。這樣可以減少ACK所占用的交通流量。一個片段可以只包含ACK回復。一個純粹的ACK回復片段不傳送文本流，所以不消耗序列號。如果有下一個正常的數據片段，它的序號將與純粹ACK回復片段的序號相同。(ACK回復還可以“附著”在SYN片段和FIN片段)

TCP連接建立

TCP連接從無到有需要一個建立連接的過程。建立連接的最重要目是讓連接的雙方交換初始序號(ISN, Initial Sequence Number)。根據TCP協議的規定，文本流的第一個片段的序號不能是確定的數字(比如說1)。連接的雙方各自隨機生成自己的ISN，然后再利用的一定方式讓對方了解。這樣的規定是出于TCP連接安全考慮：如果以一個確定的數字作為初始的TCP序號，那么其他人很容易猜出接下來的序列號，并按照正確的序號發送“偽裝”的TCP片段，以插入到文本流中。

ISN交換是通過SYN片段實現的。SYN片段由頭部的SYN位表明，它的序號為發送方的ISN。該片段由連接的一方首先發給給另一方，我們將發送SYN的一方稱為客戶(client)，而接收SYN的一方稱為服務器(server)。我們使用ISN(c)表示client一方的ISN，使用ISN(s)表示server一方的ISN。隨后，接收到SYN的server需要回復ACK，并發送出包含有server的ISN的SYN片段。經典的TCP三次握手(three-way handshaking)。

一個連接建立之后，連接兩端的進程可以利用該連接進行通信。當連接的一方覺得“我講完了”，它可以終結連接中發送到對方方向的通信。連接最終通過四次握手(four-way handshaking)的方式終結，連接終結使用的是特殊片段FIN(FIN位為1的片段)。

end

累計ACK減少了TCP傳輸過程中所需的ACK流量。通過流量管理，TCP連接兩端的工作能力可以匹配，從而減少不不要的傳輸浪費。累計ACK和流量控制都是TCP協議的重要特征。

快速重新發送機制利用重復的ACK來提示空洞的存在。當重復次數達到閾值時，認為空洞對應的片段在網絡中丟失。快速重新發送機制提高了檢測丟失片段的效率，往往可以在超時之前探測到丟失片段，并重復發送丟失的片段。

在TCP協議中，我們使用連接記錄TCP兩端的狀態，使用編號和分段實現了TCP傳輸的有序，使用advertised window來實現了發送方和接收方處理能力的匹配，并使用重復發送來實現TCP傳輸的可靠性。我們只需要將TCP片段包裝成IP包，扔到網絡中就可以了。TCP協議的相關模塊會幫我們處理各種可能出現的問題(比如排序，比如TCP片段丟失等等)。最初的TCP協議就是由上述的幾大塊構成的。

4. 應用層

4.1DNS

域名(domain name)是IP地址的代號。域名通常是由字符構成的。對于人類來說，字符構成的域名，比如www.yahoo.com，要比純粹數字構成的IP地址(106.10.170.118)容易記憶。域名解析系統(DNS, domain name system)就負責將域名翻譯為對應的IP地址。
域名和IP地址的對應關系存儲在DNS服務器(DNS server)中。所謂的DNS服務器，是指在網絡中進行域名解析的一些服務器(計算機)。這些服務器都有自己的IP地址，并使用DNS協議(DNS protocol)進行通信。DNS協議主要基于UDP，是應用層協議。
在整個DNS查詢過程中，無論是重新定向還是最終取得對應關系，都是用戶計算機和DNS服務器使用DNS協議通信。用戶計算機根據DNS服務器的反饋，依次與下一層的DNS服務器建立通信。用戶計算機經過遞歸查詢，最終和末端節點通信，并獲得IP地址。
DNS Resolver（域名解析模塊）通常有DNS緩存(cache)，用來記錄最近使用和查詢的域名/IP關系。在進行DNS查詢之前，計算機會先查詢cache中是否有相關記錄。這樣，重復使用的域名就不用總要經過整個遞歸查詢過程。

4.2 HTTP

HTTP協議解決文件傳輸的問題。HTTP是應用層協議，主要建立在TCP協議之上(偶爾也可以UDP為底層)。它隨著萬維網的發展而流行。HTTP協議目的是，如何在萬維網的網絡環境下，更好的利用TCP協議，以實現文件，特別是超文本文件的傳輸。

早期的HTTP協議主要傳輸靜態文件，即真實存儲在服務器上的文件。隨著萬維網的發展，HTTP協議被用于傳輸“動態文件”，服務器上的程序根據HTTP請求即時生成的動態文件。我們將HTTP的傳輸對象統稱為資源(resource)。

兩個過程： 請求（request）回復（response）

格式：

起始行 (start line)
頭信息 (headers)

主體(entity body)

起始行只有一行。它包含了請求/回復最重要的信息。請求的起始行表示(顧客)“想要什么”。回復的起始行表示(后廚)“發生什么”。
頭信息可以有多行。每一行是一對鍵值對(key-value pair)

早期的HTTP協議只有GET方法。遵從HTTP協議，服務器接收到GET請求后，會將特定資源傳送給客戶。
GET方法也可以用于傳輸一些不重要的數據。它是通過改寫URL的方式實現的。GET的數據利用URL?變量名＝變量值的方法傳輸。比如向http://127.0.0.1發送一個變量“q”，它的值為“a”。那么，實際的URL為http://127.0.0.1?q=a。服務器收到請求后，就可以知道"q"的值為"a"。

POST方法用于從客戶端向服務器提交數據。使用POST方法時，URL不再被改寫。數據位于http請求的主體。POST方法最用于提交HTML的form數據。服務器往往會對POST方法提交的數據進行一定的處理，比如存入服務器數據庫。

HTTP協議的默認端口是80

狀態碼：200, OK; 302，重新定向(redirect); 404，無法找到(not found)

4.3 DHCP協議用于動態的配置電腦的網絡相關參數，如主機的IP地址，路由器出口地址、DNS域名服務器地址等。一臺電腦只要接上網，就可以通過DHCP協議獲得相關配置，從而順利的暢游網絡。

DHCP協議全稱為“動態主機設置協議”（Dynamic Host Configuration Protocol）。通常來說，普通電腦中都內置有DHCP客戶端模塊。電腦接上網絡后，DHCP客戶端發現新連通的網絡，會在該網絡上找DHCP服務器。DHCP服務器將給電腦提供合理的網絡配置，并把設置信息傳回本機。所謂的DHCP服務器，其實就是一些運行有DHCP服務器端軟件的特殊電腦。他們像等候在網絡上的服務員，為新來的顧客排憂解難。本機和DHCP服務器之間的通信，都是通過DHCP協議進行的。
DHCP協議的底層是UDP協議。

DHCP通信分為四步：

1. Discovery：客戶機發廣播，搜尋DHCP服務器。
2. Offer：DHCP服務器發出邀請，提供一個可用的IP地址。
3. Request：客戶機正式請求使用該IP地址。
4. Acknowledge：DHCP服務器確認，并提供其他配置參數。