1、網絡協議通俗地講就是網絡上兩臺計算機之間通訊所要遵照的共同標準。
html
二:協議的實現
協議自己並非一種軟件,它只是一種通信標準,但協議最終要由軟件來實現。網絡協議的實現就是在不一樣的軟件和硬件環境下,執行可運行於該種環境的「協議」翻譯程序。這些程序可能在WINDOWS下,也可能在UNIX下,也可能運行於一臺我的電腦,也可能運行於一臺服務器,也可能在你的手機中,這些程序可能都不同,但卻都會翻譯同一種網絡協議,好比(TCP/IP)協議。瀏覽器
實現網絡協議,聽起來就象是給全部接入網絡的設備配備了一個「通用語言翻譯器」,這些翻譯都懂通用語言「英語」,同時也懂得本國語言,這樣就能實現不一樣國家不一樣環境的人接入同一個網絡並進行交流了。
服務器
3、協議的分層網絡
那麼人們爲何要把這個協議分層呢?計算機網絡:有以IP協議爲基礎的TCP協議,以TCP協議爲基礎的HTTP協議,以TCP協議爲基礎的FTP協議等。這裏HTTP和FTP是同一層次的兩種不一樣協議。架構
以下圖:app
高層3:HTTP協議、FTP協議 (應用層)框架
中層2:TCP協議、UDP協議 (傳輸層)socket
底層1:IP協議 (網絡層)學習
咱們一般把上圖中的底層1和中層2合在一塊兒稱爲TCP/IP協議。因此,協議並不必定非要分層,有時候一種協議是幾層協議的一個結合,事實上,協議分層並非必須的。ui
一樣道理,上圖中「底層1:IP協議」如下還有更底層的協議。「高層3:HTTP」協議以上還能夠有更高層的應用協議。咱們能夠任意一層協議爲基礎制訂本身的更高一層的協議。
不一樣的設備能夠安裝不一樣的協議,識別不一樣層次的協議。
說到底:協議是人規定的一套通訊規範,因此任何人均可以規定本身的協議,只要通訊的雙方可以共同遵照,你就實現了你的協議。
事實上協議自己是能夠無所謂分層的概念,分層只是爲了方便人們處理複雜的協議而人爲作出的劃分。
咳咳,上面這些東西都不是我寫的,我只是把他們複製過來,方便本身之後看到。參考:blog.csdn.net/fyl_077/art…
接下來,纔是重頭戲
首先通信是一件很複雜也是很麻煩的事情,有句古話說得好,遇到麻煩的事就應該大事化小,小事化了。那麼怎麼才能把通信這件事大事化小呢?若是一整塊蛋糕吃不下,咱們就把他切成小塊吃。分層的理念就這樣誕生了。
首先網絡協議就是一個規定,你們都按照這個規定去作事,這樣才能提升效率,若是你有你的作事方法,我有個人作事方法,最終誰也作不成這件事。網絡協議就是這樣的一個規矩,你們都依照這個規矩來通信,彼此才能正常交流。
OSI分層有分五層有分七層的,七層是在五層的基礎上進行了細分。咱們先來講這五層,這五層從下往上依次是:物理層(實體層)、鏈路層、網絡層、傳輸層、應用層。
每一層都只依賴於其上一層,越下面的層就越接近硬件,越上面就越接近用戶。
接下來講一點官方的,網絡協議分層的好處
各層次之間是獨立的。某一層並不須要知道它的下一層是如何實現的,而僅僅須要知道該層經過層間的接口所提供的服務。這樣,整個問題的複雜程度就降低了。也就是說上一層的工做如何進行並不影響下一層的工做,這樣咱們在進行每一層的工做設計時只要保證接口不變能夠隨意調整層內的工做方式。
靈活性好。當任何一層發生變化時,只要層間接口關係保持不變,則在這層以上或如下層均不受影響。當某一層出現技術革新或者某一層在工做中出現問題時不會連累到其它層的工做,排除問題時也只須要考慮這一層單獨的問題便可。
結構上可分割開。各層均可以採用最合適的技術來實現。技術的發展每每不對稱的,層次化的劃分有效避免了木桶效應,不會由於某一方面技術的不完善而影響總體的工做效率。
易於實現和維護。這種結構使得實現和調試一個龐大又複雜的系統變得易於處理,由於整個的系統已經被分解爲若干個相對獨立的子系統。進行調試和維護時,能夠對每一層進行單獨的調試,避免了出現找不到、解決錯問題的狀況。
能促進標準化工做。由於每一層的功能及其所提供的服務都已有了精確的說明。標準化的好處就是能夠隨意替換其中的某一層,對於使用和科研來講十分方便。
不得不說網絡通訊真的太龐大,太複雜了。咱們要作的就是用最簡單的語言去描述這項巨大的工程
接下來給你們分享一個博客,這篇博客寫的很是好,若是做爲計算機網絡入門博客來看,我認爲他是優秀的
全世界幾十億臺電腦,鏈接在一塊兒,兩兩通訊。上海的某一塊網卡送出信號,洛杉磯的另外一塊網卡竟然就收到了,二者實際上根本不知道對方的物理位置,你不以爲這是很神奇的事情嗎?
互聯網的核心是一系列協議,總稱爲」互聯網協議」(Internet Protocol Suite)。它們對電腦如何鏈接和組網,作出了詳盡的規定。理解了這些協議,就理解了互聯網的原理。
下面就是個人學習筆記。由於這些協議實在太複雜、太龐大,我想整理一個簡潔的框架,幫助本身從整體上把握它們。爲了保證簡單易懂,我作了大量的簡化,有些地方並不全面和精確,可是應該可以說清楚互聯網的原理。
互聯網的實現,分紅好幾層。每一層都有本身的功能,就像建築物同樣,每一層都靠下一層支持。
用戶接觸到的,只是最上面的一層,根本沒有感受到下面的層。要理解互聯網,必須從最下層開始,自下而上理解每一層的功能。
如何分層有不一樣的模型,有的模型分七層,有的分四層。我以爲,把互聯網分紅五層,比較容易解釋。
如上圖所示,最底下的一層叫作」實體層」(Physical Layer),最上面的一層叫作」應用層」(Application Layer),中間的三層(自下而上)分別是」連接層」(Link Layer)、」網絡層」(Network Layer)和」傳輸層」(Transport Layer)。越下面的層,越靠近硬件;越上面的層,越靠近用戶。
它們叫什麼名字,其實並不重要。只須要知道,互聯網分紅若干層就能夠了。
每一層都是爲了完成一種功能。爲了實現這些功能,就須要你們都遵照共同的規則。
你們都遵照的規則,就叫作」協議」(protocol)。
互聯網的每一層,都定義了不少協議。這些協議的總稱,就叫作」互聯網協議」(Internet Protocol Suite)。它們是互聯網的核心,下面介紹每一層的功能,主要就是介紹每一層的主要協議。
咱們從最底下的一層開始。
電腦要組網,第一件事要幹什麼?固然是先把電腦連起來,能夠用光纜、電纜、雙絞線、無線電波等方式。
這就叫作」實體層」,它就是把電腦鏈接起來的物理手段。它主要規定了網絡的一些電氣特性,做用是負責傳送0和1的電信號。
單純的0和1沒有任何意義,必須規定解讀方式:多少個電信號算一組?每一個信號位有何意義?
這就是」連接層」的功能,它在」實體層」的上方,肯定了0和1的分組方式。
早期的時候,每家公司都有本身的電信號分組方式。逐漸地,一種叫作「以太網」(Ethernet)的協議,佔據了主導地位。
以太網規定,一組電信號構成一個數據包,叫作」幀」(Frame)。每一幀分紅兩個部分:標頭(Head)和數據(Data)。
下圖是一個數據包頭部的解析:
「標頭」的長度,固定爲18字節。」數據」的長度,最短爲46字節,最長爲1500字節。所以,整個」幀」最短爲64字節,最長爲1518字節。若是數據很長,就必須分割成多個幀進行發送。
上面提到,以太網數據包的」標頭」,包含了發送者和接受者的信息。那麼,發送者和接受者是如何標識呢?
以太網規定,連入網絡的全部設備,都必須具備」網卡」接口。數據包必須是從一塊網卡,傳送到另外一塊網卡。網卡的地址,就是數據包的發送地址和接收地址,這叫作MAC地址。
每塊網卡出廠的時候,都有一個全世界獨一無二的MAC地址,長度是48個二進制位,一般用12個十六進制數表示。
前6個十六進制數是廠商編號,後6個是該廠商的網卡流水號。有了MAC地址,就能夠定位網卡和數據包的路徑了。
定義地址只是第一步,後面還有更多的步驟。
首先,一塊網卡怎麼會知道另外一塊網卡的MAC地址?
回答是有一種ARP協議,能夠解決這個問題。這個留到後面介紹,這裏只須要知道,以太網數據包必須知道接收方的MAC地址,而後才能發送。
其次,就算有了MAC地址,系統怎樣才能把數據包準確送到接收方?
回答是以太網採用了一種很」原始」的方式,它不是把數據包準確送到接收方,而是向本網絡內全部計算機發送,讓每臺計算機本身判斷,是否爲接收方。
上圖中,1號計算機向2號計算機發送一個數據包,同一個子網絡的3號、4號、5號計算機都會收到這個包。它們讀取這個包的」標頭」,找到接收方的MAC地址,而後與自身的MAC地址相比較,若是二者相同,就接受這個包,作進一步處理,不然就丟棄這個包。這種發送方式就叫作」廣播」(broadcasting)。
有了數據包的定義、網卡的MAC地址、廣播的發送方式,」連接層」就能夠在多臺計算機之間傳送數據了。
以太網協議,依靠MAC地址發送數據。理論上,單單依靠MAC地址,上海的網卡就能夠找到洛杉磯的網卡了,技術上是能夠實現的。
可是,這樣作有一個重大的缺點。以太網採用廣播方式發送數據包,全部成員人手一」包」,不只效率低,並且侷限在發送者所在的子網絡。也就是說,若是兩臺計算機不在同一個子網絡,廣播是傳不過去的。這種設計是合理的,不然互聯網上每一臺計算機都會收到全部包,那會引發災難。
互聯網是無數子網絡共同組成的一個巨型網絡,很難想象上海和洛杉磯的電腦會在同一個子網絡,這幾乎是不可能的。
所以,必須找到一種方法,可以區分哪些MAC地址屬於同一個子網絡,哪些不是。若是是同一個子網絡,就採用廣播方式發送,不然就採用」路由」方式發送。(」路由」的意思,就是指如何向不一樣的子網絡分發數據包,這是一個很大的主題,本文不涉及。)遺憾的是,MAC地址自己沒法作到這一點。它只與廠商有關,與所處網絡無關。
這就致使了」網絡層」的誕生。它的做用是引進一套新的地址,使得咱們可以區分不一樣的計算機是否屬於同一個子網絡。這套地址就叫作」網絡地址」,簡稱」網址」。
因而,」網絡層」出現之後,每臺計算機有了兩種地址,一種是MAC地址,另外一種是網絡地址。兩種地址之間沒有任何聯繫,MAC地址是綁定在網卡上的,網絡地址則是管理員分配的,它們只是隨機組合在一塊兒。
網絡地址幫助咱們肯定計算機所在的子網絡,MAC地址則將數據包送到該子網絡中的目標網卡。所以,從邏輯上能夠推斷,一定是先處理網絡地址,而後再處理MAC地址。
規定網絡地址的協議,叫作IP協議。它所定義的地址,就被稱爲IP地址。
目前,普遍採用的是IP協議第四版,簡稱IPv4。這個版本規定,網絡地址由32個二進制位組成。
習慣上,咱們用分紅四段的十進制數表示IP地址,從0.0.0.0一直到255.255.255.255。
互聯網上的每一臺計算機,都會分配到一個IP地址。這個地址分紅兩個部分,前一部分表明網絡,後一部分表明主機。好比,IP地址172.16.254.1,這是一個32位的地址,假定它的網絡部分是前24位(172.16.254),那麼主機部分就是後8位(最後的那個1)。處於同一個子網絡的電腦,它們IP地址的網絡部分一定是相同的,也就是說172.16.254.2應該與172.16.254.1處在同一個子網絡。
可是,問題在於單單從IP地址,咱們沒法判斷網絡部分。仍是以172.16.254.1爲例,它的網絡部分,究竟是前24位,仍是前16位,甚至前28位,從IP地址上是看不出來的。
那麼,怎樣才能從IP地址,判斷兩臺計算機是否屬於同一個子網絡呢?這就要用到另外一個參數」子網掩碼」(subnet mask)。
所謂」子網掩碼」,就是表示子網絡特徵的一個參數。它在形式上等同於IP地址,也是一個32位二進制數字,它的網絡部分所有爲1,主機部分所有爲0。好比,IP地址172.16.254.1,若是已知網絡部分是前24位,主機部分是後8位,那麼子網絡掩碼就是11111111.11111111.11111111.00000000,寫成十進制就是255.255.255.0。
知道」子網掩碼」,咱們就能判斷,任意兩個IP地址是否處在同一個子網絡。方法是將兩個IP地址與子網掩碼分別進行AND運算(兩個數位都爲1,運算結果爲1,不然爲0),而後比較結果是否相同,若是是的話,就代表它們在同一個子網絡中,不然就不是。
好比,已知IP地址172.16.254.1和172.16.254.233的子網掩碼都是255.255.255.0,請問它們是否在同一個子網絡?二者與子網掩碼分別進行AND運算,結果都是172.16.254.0,所以它們在同一個子網絡。
總結一下,IP協議的做用主要有兩個,一個是爲每一臺計算機分配IP地址,另外一個是肯定哪些地址在同一個子網絡。
根據IP協議發送的數據,就叫作IP數據包。不難想象,其中一定包括IP地址信息。
可是前面說過,以太網數據包只包含MAC地址,並無IP地址的欄位。那麼是否須要修改數據定義,再添加一個欄位呢?
回答是不須要,咱們能夠把IP數據包直接放進以太網數據包的」數據」部分,所以徹底不用修改以太網的規格。這就是互聯網分層結構的好處:上層的變更徹底不涉及下層的結構。
具體來講,IP數據包也分爲」標頭」和」數據」兩個部分。
「標頭」部分主要包括版本、長度、IP地址等信息,」數據」部分則是IP數據包的具體內容。它放進以太網數據包後,以太網數據包就變成了下面這樣。
IP數據包的」標頭」部分的長度爲20到60字節,整個數據包的總長度最大爲65,535字節。所以,理論上,一個IP數據包的」數據」部分,最長爲65,515字節。前面說過,以太網數據包的」數據」部分,最長只有1500字節。所以,若是IP數據包超過了1500字節,它就須要分割成幾個以太網數據包,分開發送了。
關於」網絡層」,還有最後一點須要說明。
由於IP數據包是放在以太網數據包裏發送的,因此咱們必須同時知道兩個地址,一個是對方的MAC地址,另外一個是對方的IP地址。一般狀況下,對方的IP地址是已知的(後文會解釋),可是咱們不知道它的MAC地址。
因此,咱們須要一種機制,可以從IP地址獲得MAC地址。
這裏又能夠分紅兩種狀況。第一種狀況,若是兩臺主機不在同一個子網絡,那麼事實上沒有辦法獲得對方的MAC地址,只能把數據包傳送到兩個子網絡鏈接處的」網關」(gateway),讓網關去處理。
第二種狀況,若是兩臺主機在同一個子網絡,那麼咱們能夠用ARP協議,獲得對方的MAC地址。ARP協議也是發出一個數據包(包含在以太網數據包中),其中包含它所要查詢主機的IP地址,在對方的MAC地址這一欄,填的是FF:FF:FF:FF:FF:FF,表示這是一個」廣播」地址。它所在子網絡的每一臺主機,都會收到這個數據包,從中取出IP地址,與自身的IP地址進行比較。若是二者相同,都作出回覆,向對方報告本身的MAC地址,不然就丟棄這個包。
總之,有了ARP協議以後,咱們就能夠獲得同一個子網絡內的主機MAC地址,能夠把數據包發送到任意一臺主機之上了。
有了MAC地址和IP地址,咱們已經能夠在互聯網上任意兩臺主機上創建通訊。
接下來的問題是,同一臺主機上有許多程序都須要用到網絡,好比,你一邊瀏覽網頁,一邊與朋友在線聊天。當一個數據包從互聯網上發來的時候,你怎麼知道,它是表示網頁的內容,仍是表示在線聊天的內容?
也就是說,咱們還須要一個參數,表示這個數據包到底供哪一個程序(進程)使用。這個參數就叫作」端口」(port),它實際上是每個使用網卡的程序的編號。每一個數據包都發到主機的特定端口,因此不一樣的程序就能取到本身所須要的數據。
「端口」是0到65535之間的一個整數,正好16個二進制位。0到1023的端口被系統佔用,用戶只能選用大於1023的端口。無論是瀏覽網頁仍是在線聊天,應用程序會隨機選用一個端口,而後與服務器的相應端口聯繫。
「傳輸層」的功能,就是創建」端口到端口」的通訊。相比之下,」網絡層」的功能是創建」主機到主機」的通訊。只要肯定主機和端口,咱們就能實現程序之間的交流。所以,Unix系統就把主機+端口,叫作」套接字」(socket)。有了它,就能夠進行網絡應用程序開發了。
如今,咱們必須在數據包中加入端口信息,這就須要新的協議。最簡單的實現叫作UDP協議,它的格式幾乎就是在數據前面,加上端口號。
UDP數據包,也是由」標頭」和」數據」兩部分組成。
「標頭」部分主要定義了發出端口和接收端口,」數據」部分就是具體的內容。而後,把整個UDP數據包放入IP數據包的」數據」部分,而前面說過,IP數據包又是放在以太網數據包之中的,因此整個以太網數據包如今變成了下面這樣:
UDP數據包很是簡單,」標頭」部分一共只有8個字節,總長度不超過65,535字節,正好放進一個IP數據包。
UDP協議的優勢是比較簡單,容易實現,可是缺點是可靠性較差,一旦數據包發出,沒法知道對方是否收到。
爲了解決這個問題,提升網絡可靠性,TCP協議就誕生了。這個協議很是複雜,但能夠近似認爲,它就是有確認機制的UDP協議,每發出一個數據包都要求確認。若是有一個數據包遺失,就收不到確認,發出方就知道有必要重發這個數據包了。
所以,TCP協議可以確保數據不會遺失。它的缺點是過程複雜、實現困難、消耗較多的資源。
TCP數據包和UDP數據包同樣,都是內嵌在IP數據包的」數據」部分。TCP數據包沒有長度限制,理論上能夠無限長,可是爲了保證網絡的效率,一般TCP數據包的長度不會超過IP數據包的長度,以確保單個TCP數據包沒必要再分割。
應用程序收到」傳輸層」的數據,接下來就要進行解讀。因爲互聯網是開放架構,數據來源五花八門,必須事先規定好格式,不然根本沒法解讀。
「應用層」的做用,就是規定應用程序的數據格式。
舉例來講,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地址。接下來,咱們就來看,實際使用中,這個過程是怎麼完成的。
你買了一臺新電腦,插上網線,開機,這時電腦可以上網嗎?
一般你必須作一些設置。有時,管理員(或者ISP)會告訴你下面四個參數,你把它們填入操做系統,計算機就能連上網了:
下圖是Windows系統的設置窗口。
這四個參數缺一不可,後文會解釋爲何須要知道它們才能上網。因爲它們是給定的,計算機每次開機,都會分到一樣的IP地址,因此這種狀況被稱做」靜態IP地址上網」。
可是,這樣的設置很專業,普通用戶望而生畏,並且若是一臺電腦的IP地址保持不變,其餘電腦就不能使用這個地址,不夠靈活。出於這兩個緣由,大多數用戶使用」動態IP地址上網」。
所謂」動態IP地址」,指計算機開機後,會自動分配到一個IP地址,不用人爲設定。它使用的協議叫作DHCP協議。
這個協議規定,每個子網絡中,有一臺計算機負責管理本網絡的全部IP地址,它叫作」DHCP服務器」。新的計算機加入網絡,必須向」DHCP服務器」發送一個」DHCP請求」數據包,申請IP地址和相關的網絡參數。
前面說過,若是兩臺計算機在同一個子網絡,必須知道對方的MAC地址和IP地址,才能發送數據包。可是,新加入的計算機不知道這兩個地址,怎麼發送數據包呢?
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服務器等等參數。
這個部分,須要記住的就是一點:無論是」靜態IP地址」仍是」動態IP地址」,電腦上網的首要步驟,是肯定四個參數。這四個值很重要,值得重複一遍:
有了這幾個數值,電腦就能夠上網」衝浪」了。接下來,咱們來看一個實例,當用戶訪問網頁的時候,互聯網協議是怎麼運做的。
咱們假定,通過上一節的步驟,用戶設置好了本身的網絡參數:
而後他打開瀏覽器,想要訪問Google,在地址欄輸入了網址:www.google.com。
這意味着,瀏覽器要向Google發送一個網頁請求的數據包。
咱們知道,發送數據包,必需要知道對方的IP地址。可是,如今,咱們只知道網址www.google.com,不知道它的IP地址。
DNS協議能夠幫助咱們,將這個網址轉換成IP地址。已知DNS服務器爲8.8.8.8,因而咱們向這個地址發送一個DNS數據包(53端口)。
而後,DNS服務器作出響應,告訴咱們Google的IP地址是172.194.72.105。因而,咱們知道了對方的IP地址。
接下來,咱們要判斷,這個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地址。
瀏覽網頁用的是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數據包之中。
TCP數據包須要設置端口,接收方(Google)的HTTP端口默認是80,發送方(本機)的端口是一個隨機生成的1024-65535之間的整數,假定爲51775。
TCP數據包的標頭長度爲20字節,加上嵌入HTTP的數據包,總長度變爲4980字節。
而後,TCP數據包再嵌入IP數據包。IP數據包須要設置雙方的IP地址,這是已知的,發送方是192.168.1.100(本機),接收方是172.194.72.105(Google)。
IP數據包的標頭長度爲20字節,加上嵌入的TCP數據包,總長度變爲5000字節。
最後,IP數據包嵌入以太網數據包。以太網數據包須要設置雙方的MAC地址,發送方爲本機的網卡MAC地址,接收方爲網關192.168.1.1的MAC地址(經過ARP協議獲得)。
以太網數據包的數據部分,最大長度爲1500字節,而如今的IP數據包長度爲5000字節。所以,IP數據包必須分割成四個包。由於每一個包都有本身的IP標頭(20字節),因此四個包的IP數據包的長度分別爲1500、1500、1500、560。
通過多個網關的轉發,Google的服務器172.194.72.105,收到了這四個以太網數據包。
根據IP標頭的序號,Google將四個包拼起來,取出完整的TCP數據包,而後讀出裏面的」HTTP請求」,接着作出」HTTP響應」,再用TCP協議發回來。
本機收到HTTP響應之後,就能夠將網頁顯示出來,完成一次網絡通訊。
這個例子就到此爲止,雖然通過了簡化,但它大體上反映了互聯網協議的整個通訊過程