一、網絡的五層模型
如何分層有不同的模型，有的模型分七層，有的分四層。我覺得，把互聯網分成五層，比較容易解釋。
如上圖所示，最底下的一層叫做"實體層"（Physical Layer），最上面的一層叫做"應用層"（Application Layer），中間的三層（自下而上）分別是"鏈接層"（Link Layer）、"網絡層"（Network Layer）和"傳輸層"（Transport Layer）。越下面的層，越靠近硬件；越上面的層，越靠近用戶。
一、層與協議
互聯網的每一層，都定義了很多協議。這些協議的總稱，就叫做"互聯網協議"（Internet Protocol Suite）。它們是互聯網的核心，下面介紹每一層的功能，主要就是介紹每一層的主要協議。
二、實體層：
內容小結：電腦連接起來的物理手段
實體層，它就是把電腦連接起來的物理手段。它主要規定了網絡的一些電氣特性，作用是負責傳送0和1的電信號。
三、鏈接層：
內容小結：在同一個子網絡里發送數據包。
3.1 定義
鏈接層，它在"實體層"的上方，通過以太網協議在同一個子網絡里發送數據包。
3.2 以太網協議（不是http協議）
以太網規定，一組電信號構成一個數據包，叫做"幀"（Frame）。每一幀分成兩個部分：標頭（Head）和數據（Data）。
"標頭"包含數據包的一些說明項，比如發送者、接受者、數據類型等等；"數據"則是數據包的具體內容。
"標頭"的長度，固定為18字節。"數據"的長度，最短為46字節，最長為1500字節。因此，整個"幀"最短為64字節，最長為1518字節。如果數據很長，就必須分割成多個包進行發送。
3.3 MAC地址
"標頭"中發送者和接受者的信息：以太網規定，連入網絡的所有設備，都必須具有"網卡"接口。數據包是從一塊網卡，傳送到另一塊網卡。網卡的地址，就是數據包的發送地址和接收地址，這叫做MAC地址。
每塊網卡出廠的時候，都有一個全世界獨一無二的MAC地址，長度是48個二進制位，通常用12個十六進制數表示。
前6個十六進制數是廠商編號，后6個是該廠商的網卡流水號。有了MAC地址，就可以定位網卡和數據包的路徑了。
3.4 廣播
以太網數據包必須知道接收方的MAC地址，然后才能發送。
以太網向本網絡內所有計算機發送，讓每台計算機自己判斷，是否為接收方。
上圖中，1號計算機向2號計算機發送一個數據包，同一個子網絡的3號、4號、5號計算機都會收到這個包。它們讀取這個包的"標頭"，找到接收方的MAC地址，然后與自身的MAC地址相比較，如果兩者相同，就接受這個包，做進一步處理，否則就丟棄這個包。這種發送方式就叫做"廣播"（broadcasting）。
有了數據包的定義、網卡的MAC地址、廣播的發送方式，"鏈接層"就可以在多台計算機之間傳送數據了。
四、網絡層（互聯網）：
內容小結：ip到ip的數據傳送，是否是在同一子網絡，不在統一子網絡的話，先把包發送給本網絡網關，本網關再找另一個ip所在的網關
4.1 網絡層的由來
以太網采用廣播方式發送數據包，局限在發送者所在的子網絡。
互聯網是無數子網絡共同組成的一個巨型網絡
如果是同一個子網絡，就采用廣播方式發送，否則就采用"路由"方式發送。（"路由"的意思，就是指如何向不同的子網絡分發數據包，這是一個很大的主題，本文不涉及。）
網絡層使用ip地址，使得我們能夠區分不同的計算機是否屬於同一個子網絡。
於是，每台計算機有了兩種地址，一種是MAC地址，另一種是網絡地址。兩種地址之間沒有任何聯系，MAC地址是綁定在網卡上的，網絡地址則是管理員分配的。
ip地址確定計算機所在的子網絡，MAC地址則將數據包送到該子網絡中的目標網卡。先處理網絡地址，然后再處理MAC地址。
4.2 IP協議
規定網絡地址的協議，叫做IP協議。它所定義的地址，就被稱為IP地址，互聯網上的每一台計算機，都會分配到一個IP地址。
目前，廣泛采用的是IP協議第四版，簡稱IPv4。這個版本規定，ip地址由32個二進制位（每段8位，一共4段）組成，四段，分成兩個部分，前一部分代表網絡，后一部分代表主機。
"子網掩碼"（subnet mask）：用於判斷兩台計算機是否屬於同一個子網絡，是一個32位二進制數字，它的網絡部分全部為1，主機部分全部為0。比如，IP地址172.16.254.1，子網絡掩碼是11111111.11111111.11111111.00000000，寫成十進制就是255.255.255.0，那么網絡部分是前3段，主機部分是最后一段，處於同一個子網絡的電腦，它們IP地址的網絡部分必定是相同的。
比如，已知IP地址172.16.254.1和172.16.254.233的子網掩碼都是255.255.255.0，可知他們的網絡部分是相同的都是172.16.254，因此它們在同一個子網絡。
IP地址分類：
IP地址 = {<網絡號>, <主機號>}
A類地址 : 0.0.0.0 ~ 127.0.0.0
B類地址 : 128.0.0.0 ~ 191.255.0.0
C類地址 : 192.0.0.0 ~ 223.255.255.0
大部分網絡使用B類或C類地址。
A類地址的默認子網掩碼為255.0.0.0
B類地址的默認子網掩碼為255.255.0.0
C類地址的默認子網掩碼為255.255.255.0
內網（局域網）：
內網的計算機通過一個公共的網關訪問Internet。內網的計算機可向Internet上的其他計算機發送連接請求，但Internet上其他的計算機無法向內網的計算機發送連接請求。
Class A 10.0.0.0-10.255.255.255，默認子網掩碼:255.0.0.0
Class B 172.16.0.0-172.31.255.255，默認子網掩碼:255.240.0.0
Class C 192.168.0.0-192.168.255.255，默認子網掩碼:255.255.0.0
內網是可以上網的.內網需要一台服務器或路由器做網關,通過它來上網。
假設公司A在廣州和上海有辦事處, 而他們在當地都有自己的專用網. 那么怎么將這兩個專用網連接起來呢?利用公用的因特網當做通信載體, 這就是虛擬專用網VPN
總結一下，IP協議的作用主要有兩個，一個是為每一台計算機分配IP地址，另一個是確定哪些地址在同一個子網絡。
4.3 IP數據包
根據IP協議發送的數據，就叫做IP數據包。不難想象，其中必定包括IP地址信息。
但是前面說過，以太網數據包只包含MAC地址，並沒有IP地址的欄位。那么是否需要修改數據定義，再添加一個欄位呢？
回答是不需要，我們可以把IP數據包直接放進以太網數據包的"數據"部分，因此完全不用修改以太網的規格。這就是互聯網分層結構的好處：上層的變動完全不涉及下層的結構。
具體來說，IP數據包也分為"標頭"和"數據"兩個部分。
"標頭"部分主要包括版本、長度、IP地址等信息，"數據"部分則是IP數據包的具體內容。它放進以太網數據包后，以太網數據包就變成了下面這樣。
4.4 ARP協議
我們需要一種機制，能夠從IP地址得到MAC地址。
這里又可以分成兩種情況。第一種情況，如果兩台主機不在同一個子網絡，那么事實上沒有辦法得到對方的MAC地址，只能把數據包傳送到兩個子網絡連接處的"網關"（gateway），讓網關去處理。
第二種情況，如果兩台主機在同一個子網絡，那么我們可以用ARP協議，得到對方的MAC地址。ARP協議也是發出一個數據包（包含在以太網數據包中），其中包含它所要查詢主機的IP地址，在對方的MAC地址這一欄，填的是FF:FF:FF:FF:FF:FF，表示這是一個"廣播"地址。它所在子網絡的每一台主機，都會收到這個數據包，從中取出IP地址，與自身的IP地址進行比較。如果兩者相同，都做出回復，向對方報告自己的MAC地址，否則就丟棄這個包。
總之，有了ARP協議之后，我們就可以得到同一個子網絡內的主機MAC地址，可以把數據包發送到任意一台主機之上了。
五、傳輸層
5.1 傳輸層的由來
有了MAC地址和IP地址，我們已經可以在互聯網上任意兩台主機上建立通信。
接下來需要一個參數，表示這個數據包到底供哪個程序（進程）使用。這個參數就叫做"端口"（port），它其實是每一個使用網卡的程序的編號。每個數據包都發到主機的特定端口，所以不同的程序就能取到自己所需要的數據。
"端口"是0到65535之間的一個整數，正好16個二進制位。0到1023的端口被系統占用，用戶只能選用大於1023的端口。不管是瀏覽網頁還是在線聊天，應用程序會隨機選用一個端口，然后與服務器的相應端口聯系。
"傳輸層"的功能，就是建立"端口到端口"的通信。相比之下，"網絡層"的功能是建立"主機到主機"的通信。只要確定主機和端口，我們就能實現程序之間的交流。因此，Unix系統就把主機+端口，叫做"套接字"（socket）。有了它，就可以進行網絡應用程序開發了。
5.2 UDP協議
現在，我們必須在數據包中加入端口信息，這就需要新的協議。最簡單的實現叫做UDP協議，它的格式幾乎就是在數據前面，加上端口號。
UDP數據包，也是由"標頭"和"數據"兩部分組成。
"標頭"部分主要定義了發出端口和接收端口，"數據"部分就是具體的內容。然后，把整個UDP數據包放入IP數據包的"數據"部分，而前面說過，IP數據包又是放在以太網數據包之中的，所以整個以太網數據包現在變成了下面這樣：
UDP數據包非常簡單，"標頭"部分一共只有8個字節，總長度不超過65,535字節，正好放進一個IP數據包。
5.3 TCP協議
主要特點 :
面向連接的運輸層協議
每一條TCP連接只能有2個端點, TCP是點對點的，端點叫套接字(socket)
提供可靠交互
全雙工通信
面向字節流
每發出一個數據包都要求確認。如果有一個數據包遺失，就收不到確認，發出方就知道有必要重發這個數據包了。因此，TCP協議能夠確保數據不會遺失。它的缺點是過程復雜、實現困難、消耗較多的資源。
TCP數據包和UDP數據包一樣，都是內嵌在IP數據包的"數據"部分。TCP數據包沒有長度限制，理論上可以無限長，但是為了保證網絡的效率，通常TCP數據包的長度不會超過IP數據包的長度，以確保單個TCP數據包不必再分割。
六、應用層
應用程序收到"傳輸層"的數據，接下來就要進行解讀。由於互聯網是開放架構，數據來源五花八門，必須事先規定好格式，否則根本無法解讀。
"應用層"的作用，就是規定應用程序的數據格式。
應用層協議最著名的就是HTTP, FTP了, 還有一個重要的DNS。
舉例來說，TCP協議可以為各種各樣的程序傳遞數據，比如Email、WWW、FTP等等。那么，必須有不同協議規定電子郵件、網頁、FTP數據的格式，這些應用程序協議就構成了"應用層"。
這是最高的一層，直接面對用戶。它的數據就放在TCP數據包的"數據"部分。因此，現在的以太網的數據包就變成下面這樣。
二、網關
先對前面的內容，做一個小結。
我們已經知道，網絡通信就是交換數據包。電腦A向電腦B發送一個數據包，后者收到了，回復一個數據包，從而實現兩台電腦之間的通信。數據包的結構，基本上是下面這樣：
發送這個包，需要知道兩個地址：
* 對方的MAC地址 * 對方的IP地址
有了這兩個地址，數據包才能准確送到接收者手中。但是，前面說過，MAC地址有局限性，如果兩台電腦不在同一個子網絡，就無法知道對方的MAC地址，必須通過網關（gateway）轉發。
上圖中，1號電腦要向4號電腦發送一個數據包。它先判斷4號電腦是否在同一個子網絡，結果發現不是（后文介紹判斷方法），於是就把這個數據包發到網關A。網關A通過路由協議，發現4號電腦位於子網絡B，又把數據包發給網關B，網關B再轉發到4號電腦。
1號電腦把數據包發到網關A，必須知道網關A的MAC地址。所以，數據包的目標地址，實際上分成兩種情況：
| 場景 |
數據包地址 |
| 同一個子網絡 |
對方的MAC地址，對方的IP地址 |
| 非同一個子網絡 |
網關的MAC地址，對方的IP地址 |
發送數據包之前，電腦必須判斷對方是否在同一個子網絡，然后選擇相應的MAC地址。接下來，我們就來看，實際使用中，這個過程是怎么完成的。
三、用戶的上網設置
3.1 靜態IP地址
你買了一台新電腦，插上網線，開機，這時電腦能夠上網嗎？
通常你必須做一些設置。有時，管理員（或者ISP）會告訴你下面四個參數，你把它們填入操作系統，計算機就能連上網了：
* 本機的IP地址 * 子網掩碼 * 網關的IP地址 * DNS的IP地址
下圖是Windows系統的設置窗口。
這四個參數缺一不可，后文會解釋為什么需要知道它們才能上網。由於它們是給定的，計算機每次開機，都會分到同樣的IP地址，所以這種情況被稱作"靜態IP地址上網"。
但是，這樣的設置很專業，普通用戶望而生畏，而且如果一台電腦的IP地址保持不變，其他電腦就不能使用這個地址，不夠靈活。出於這兩個原因，大多數用戶使用"動態IP地址上網"。
3.2 動態IP地址
所謂"動態IP地址"，指計算機開機后，會自動分配到一個IP地址，不用人為設定。它使用的協議叫做DHCP協議。
這個協議規定，每一個子網絡中，有一台計算機負責管理本網絡的所有IP地址，它叫做"DHCP服務器"。新的計算機加入網絡，必須向"DHCP服務器"發送一個"DHCP請求"數據包，申請IP地址和相關的網絡參數。
前面說過，如果兩台計算機在同一個子網絡，必須知道對方的MAC地址和IP地址，才能發送數據包。但是，新加入的計算機不知道這兩個地址，怎么發送數據包呢？
DHCP協議做了一些巧妙的規定。
3.3 DHCP協議
首先，它是一種應用層協議，建立在UDP協議之上，所以整個數據包是這樣的：
（1）最前面的"以太網標頭"，設置發出方（本機）的MAC地址和接收方（DHCP服務器）的MAC地址。前者就是本機網卡的MAC地址，后者這時不知道，就填入一個廣播地址：FF-FF-FF-FF-FF-FF。
（2）后面的"IP標頭"，設置發出方的IP地址和接收方的IP地址。這時，對於這兩者，本機都不知道。於是，發出方的IP地址就設為0.0.0.0，接收方的IP地址設為255.255.255.255。
（3）最后的"UDP標頭"，設置發出方的端口和接收方的端口。這一部分是DHCP協議規定好的，發出方是68端口，接收方是67端口。
這個數據包構造完成后，就可以發出了。以太網是廣播發送，同一個子網絡的每台計算機都收到了這個包。因為接收方的MAC地址是FF-FF-FF-FF-FF-FF，看不出是發給誰的，所以每台收到這個包的計算機，還必須分析這個包的IP地址，才能確定是不是發給自己的。當看到發出方IP地址是0.0.0.0，接收方是255.255.255.255，於是DHCP服務器知道"這個包是發給我的"，而其他計算機就可以丟棄這個包。
接下來，DHCP服務器讀出這個包的數據內容，分配好IP地址，發送回去一個"DHCP響應"數據包。這個響應包的結構也是類似的，以太網標頭的MAC地址是雙方的網卡地址，IP標頭的IP地址是DHCP服務器的IP地址（發出方）和255.255.255.255（接收方），UDP標頭的端口是67（發出方）和68（接收方），分配給請求端的IP地址和本網絡的具體參數則包含在Data部分。
新加入的計算機收到這個響應包，於是就知道了自己的IP地址、子網掩碼、網關地址、DNS服務器等等參數。
3.4 上網設置：小結
這個部分，需要記住的就是一點：不管是"靜態IP地址"還是"動態IP地址"，電腦上網的首要步驟，是確定四個參數。這四個值很重要，值得重復一遍：
* 本機的IP地址 * 子網掩碼 * 網關的IP地址 * DNS的IP地址
有了這幾個數值，電腦就可以上網"沖浪"了。接下來，我們來看一個實例，當用戶訪問網頁的時候，互聯網協議是怎么運作的。
四、訪問網頁
過程解析
4.1 本機參數
我們假定，經過上一節的步驟，用戶設置好了自己的網絡參數：
* 本機的IP地址：192.168.1.100 * 子網掩碼：255.255.255.0 * 網關的IP地址：192.168.1.1 * DNS的IP地址：8.8.8.8
輸入網址：
然后他打開瀏覽器，想要訪問Google，在地址欄輸入了網址：www.google.com。
這意味着，瀏覽器要向Google發送一個網頁請求的數據包。
4.2 DNS協議（域名解析）
域名服務器分類
根域名服務器 : 最高層次的域名服務器
頂級域名服務器 : 如其名
權限域名服務器 : 負責一個區的應服務器
本地域名服務器 : 主機發送DNS查詢請求就是發給它
URL的格式 : <協議>://<主機>:<端口>/<路徑>, 端口和路徑有時可省略.
使用HTTP協議的URL : http://<主機>:<端口>/<路徑>, HTTP默認端口號是80
我們知道，發送數據包，必須要知道對方的IP地址。但是，現在，我們只知道網址www.google.com，不知道它的IP地址。
DNS協議可以幫助我們，將這個網址轉換成IP地址。已知DNS服務器為8.8.8.8，於是我們向這個地址發送一個DNS數據包（53端口）。
然后，DNS服務器做出響應，告訴我們Google的IP地址是172.194.72.105。於是，我們知道了對方的IP地址。
4.3 子網掩碼
接下來，我們要判斷，這個IP地址是不是在同一個子網絡，這就要用到子網掩碼。
已知子網掩碼是255.255.255.0，本機用它對自己的IP地址192.168.1.100，做一個二進制的AND運算（兩個數位都為1，結果為1，否則為0），計算結果為192.168.1.0；然后對Google的IP地址172.194.72.105也做一個AND運算，計算結果為172.194.72.0。這兩個結果不相等，所以結論是，Google與本機不在同一個子網絡。
因此，我們要向Google發送數據包，必須通過網關192.168.1.1轉發，也就是說，接收方的MAC地址將是網關的MAC地址。
4.4 應用層協議（http協議）
每一次HTTP請求就需要建立一次TCP連接和釋放TCP連接.
HTTP是無連接, 無狀態的. 每一次請求都是作為一次新請求.
HTTP的GET和POST
GET 請求通常用於查詢、獲取數據，而 POST 請求則用於發送數據
GET 請求的參數在URL中, 因此絕不能用GET請求傳輸敏感數據, 而POST 請求的參數在請求頭中, 安全性略高於GET請求
ps : POST請求的數據也是以明文的形式存放在請求頭中, 因此也不安全
Cookie
萬維網使用Cookie來跟蹤用戶, 表示HTTP服務器和用戶之間傳遞的狀態信息.
Cookie工作原理 :
1. 用戶瀏覽某網站, 該網站的服務器為用戶產生一個唯一的識別碼, 並以此為索引在服務器后端數據庫中產生一個項目2. 返回給用戶的HTTP響應報文中添加一條 "Set-cookie", 值為該識別碼, 如1233. 用戶的瀏覽器將該cookie保存起來, 在用於繼續瀏覽該網站時發送的每一個HTTP請求都會有一行 Cookie: 123於是, 這個網站就知道Cookie為123的這個用戶做了什么, 為這個用戶維護一個獨立的列表(如購物車)
當然, Cookie是把雙刃劍, 方便的同時也帶有危險性, 例如隱私泄露等, 用戶可以自行決定是否使用Cookie
Session
Cookie是保存在客戶端上的, 而Session是保存在服務器中. 當服務器收到用戶發出的Cookie時, 會根據Cookie中的SessionID來查找對應的Session, 如沒有則會生成一個新的SessionID返回給用戶。
總而言之, Cookie和Session就是同一樣東西存放地方不同而已.
HTTPS協議在HTTP協議的基礎上, 在HTTP和TCP中間加入了一層SSL/TLS加密層, 解決了HTTP不安全的問題: 冒充, 篡改, 竊聽三大風險.
瀏覽網頁用的是HTTP協議，它的整個數據包構造是這樣的：
HTTP部分的內容，類似於下面這樣：
GET / HTTP/1.1 Host: www.google.com Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 6.1) ...... Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: gzip,deflate,sdch Accept-Language: zh-CN,zh;q=0.8 Accept-Charset: GBK,utf-8;q=0.7,*;q=0.3 Cookie: ... ...
我們假定這個部分的長度為4960字節，它會被嵌在TCP數據包之中。
4.5 TCP協議
TCP數據包需要設置端口，接收方（Google）的HTTP端口默認是80，發送方（本機）的端口是一個隨機生成的1024-65535之間的整數，假定為51775。
TCP數據包的標頭長度為20字節，加上嵌入HTTP的數據包，總長度變為4980字節。
4.6 IP協議
然后，TCP數據包再嵌入IP數據包。IP數據包需要設置雙方的IP地址，這是已知的，發送方是192.168.1.100（本機），接收方是172.194.72.105（Google）。
IP數據包的標頭長度為20字節，加上嵌入的TCP數據包，總長度變為5000字節。
4.7 以太網協議
最后，IP數據包嵌入以太網數據包。以太網數據包需要設置雙方的MAC地址，發送方為本機的網卡MAC地址，接收方為網關192.168.1.1的MAC地址（通過ARP協議得到）。
以太網數據包的數據部分，最大長度為1500字節，而現在的IP數據包長度為5000字節。因此，IP數據包必須分割成四個包。因為每個包都有自己的IP標頭（20字節），所以四個包的IP數據包的長度分別為1500、1500、1500、560。
4.8 服務器端響應
經過多個網關的轉發，Google的服務器172.194.72.105，收到了這四個以太網數據包。
根據IP標頭的序號，Google將四個包拼起來，取出完整的TCP數據包，然后讀出里面的"HTTP請求"，接着做出"HTTP響應"，再用TCP協議發回來。
本機收到HTTP響應以后，就可以將網頁顯示出來，完成一次網絡通信。
這個例子就到此為止，雖然經過了簡化，但它大致上反映了互聯網協議的整個通信過程。