計算機揭祕之:網絡分類和性能分析

簡介

程序員天天都在寫代碼,關注的都是更高層次的封裝,今天我們換個思路,讓程序那些事來帶你看一看隱藏在表象之下的網絡和他們的性能分析。

本文主要涉及5個模塊,分別是網絡七層協議,延遲與帶寬,IP,TCP,UDP。

OSI網絡七層協議

在講網絡之前,一定要提到OSI網絡七層協議。

OSI是Open System Interconnect的縮寫,意爲開放式系統互聯。

 

 

上圖是大家非常非常熟悉的OSI七層網絡模型,和對應的TCP/IP模型。

應用層的功能是文件傳輸,電子郵件和文件服務等。使用的協議主要是HTTP,SMTP和FTP。

表示層的功能是數據格式化,代碼轉換和數據加密。

會話層的功能是解除或者建立與其他節點的聯繫。

傳輸層的功能是提供端對端的接口,使用的協議主要是TCP和UDP。

網絡層的功能是爲數據包選擇路由,使用的協議是IP。

數據鏈路層的功能是傳輸有地址的幀,和檢查數據錯誤。

物理層的功能是以二進制數據在物理媒介上傳輸數據。

延遲與帶寬

最近電信業務員老是給我打電話,說是要把家裏的電信寬帶從100M升級到500M,每天只需要一塊錢。一塊錢雖然少,但也是血汗錢。那麼辦還是不辦呢?升級到500M對性能和延時提升有多大幫助呢?

2020年可以稱爲中國5G的元年。先不管華爲,中信在5G基站和協議制定方面的能力。直觀的感覺5G手機開始多了,手機營業廳也在賣力的讓你升級到5G套餐,那麼辦還是不辦?

在回答這兩個問題之前,我們學習兩個名詞:

延遲: 分組從信息源發送到目的地所需的時間。

帶寬: 邏輯或物理通信路徑最大的吞吐量。

 

 

如果你訪問一個網站,比如,我們看一下數據是怎麼從服務器到達你的電腦的。

首先數據從服務器通過以太網(以太網是一種計算機局域網技術)傳輸到ISP。

ISP是啥呢?ISP就是互聯網服務提供商(Internet Service Provider),通過ISP你才能夠把服務器接入互聯網。

互聯網就是通過主幹網的互聯網服務提供商(ISP)之間的相互連接構成的。

所以ISP就是一個……大代理。

好了,數據傳到爲我家提供服務的ISP了,然後通過光纖或者電纜線傳到了我家的WiFi,然後通過WiFi的無線信號,被我的電腦接收。

延時的構成

討論分析了數據的傳輸線路,接下來我們看一下,延時會跟哪些原因有關呢?

首先肯定是信號傳輸的距離,距離越長,傳輸速率越慢,需要的時間就越長。

接下來就是消息的長度,我們把消息中的所有比特轉移到鏈路中需要時間,消息長度越長,需要的時間越多。

數據上了鏈路之後,處理分組首部、檢查位錯誤及確定分組目標也需要時間。

最後,我們對於分組數據進行排隊處理也需要時間。

現在主網絡的傳輸介質基本上都是光纖了,光在光纖中傳播,並不是直線進行的,並且也有折射率的影響,所以速度比光在真空中傳播要慢一點。

比如說信號圍繞赤道轉一圈,只需要大概200ms。已經很快了。

200ms確實很快了,但是對於某些實時性要求特別高的應用場景,我們可以使用CDN技術(Content Delivery Network,內容分發網絡),把內容部署在全球網絡中,然後從最近的地方去取數據。從而大大減少傳輸延時。

200ms夠快了,但是爲什麼我們仍然會感覺到網速慢呢?

大家都聽過木桶原理吧,木桶能夠裝的水,決定於最短的那塊木板。同樣的對於網絡延時來說,提升速度不在於你在主幹網上採用了多麼先進的技術,因爲提升的再多或者再差也是毫米級的。

真正決定網速的在於最後一公里,也就是你電纜線的傳輸速率,你的wifi的傳輸速率,還有你電腦的處理速率等。

能接入更高帶寬固然好,特別是傳輸大塊數據時更是如此,比如在線聽音樂、看視頻,或者下載大文件。可是,日常上網瀏覽需要的是從數十臺主機獲取較小的資源,這時候往返時間就成了瓶頸。

IP協議

IP,即 Internet Protocol(因特網協議),負責聯網主機之間的路由選擇和尋址。

各種物理網絡在鏈路層所傳輸的基本單元爲幀(MAC幀),其幀格式隨物理網絡而異,各物理網絡的物理地址(MAC地址)也隨物理網絡而異。Ip協議的作用就是向傳輸層(TCP層)提供統一的IP包,即將各種不同類型的MAC幀轉換爲統一的IP包,並將MAC幀的物理地址變換爲全網統一的邏輯地址(IP地址)。

IP數據包

數據包(data packet)是什麼?

數據包也是分組交換的一種形式,就是把所傳送的數據分段打成包,再傳送出去.

每個數據包都有報頭和報文這兩個部分,報頭中有目的地址等必要內容,使每個數據包不經過同樣的路徑都能準確地到達目的地。在目的地重新組合還原成原來發送的數據.

 

 

我們看下IP數據包的構成。

注意上面的Total Length部分佔用了2個字節,所以IP數據包的最大長度就是2^16-1=65535字節。

分片和重組

鏈路層具有最大傳輸單元MTU這個特性,它限制了數據幀的最大長度,不同的網絡類型都有一個上限值.如果IP層有數據包要傳,而且數據包的長度超過了MTU,那麼IP層就要對數據包進行分片操作,使每一片的長度都小於或等於MTU。

分片後的IP數據包,只有到達目的地才能重新組裝。重新組裝由目的地的IP層來完成,其目的是使分片和重新組裝過程對傳輸層(TCP和UDP)是透明的。

MSS與MTU

MSS最大傳輸大小的縮寫,是TCP協議裏面的一個概念。

MSS就是TCP數據包每次能夠傳輸的最大數據分段。爲了達到最佳的傳輸效能TCP協議在建立連接的時候通常要協商雙方的MSS值,這個值TCP協議在實現的時候往往用MTU值代替(需要減去IP數據包包頭的大小20Bytes和TCP數據段的包頭20Bytes), 通訊雙方會根據雙方提供的MSS值得最小值確定爲這次連接的最大MSS值。

而一般以太網MTU都爲1500, 所以在以太網中, 往往TCP MSS爲1460。

TCP

TCP,即 Transmission Control Protocol(傳輸控制協議),負責在不可靠的傳輸信道之上提供可靠的抽象層, 嚮應用層隱藏了大多數網絡通信的複雜細節,比如丟包重發、按序發送、擁塞控制及避免、數據完整,等等。

TCP三次握手

 

 

一般來說,使用TCP協議,如果client和server要達成一致建立連接的話,需要三次交互。

  • SYN
    客戶端選擇一個隨機序列號x,併發送一個SYN 分組,其中可能還包括其他TCP標誌和選項。
  • SYN ACK
    服務器給x 加1,並選擇自己的一個隨機序列號y,追加自己的標誌和選項,然後返回響應。
  • ACK
    客戶端給x 和y 加1 併發送握手期間的最後一個ACK 分組。

擁塞崩潰

如果幾個IP分組同時到達路由器,並期望經同一個輸出端口轉發.

顯然,不是所有分組可以同時接受處理,必須有一個服務順序,中間節點上的緩存爲等候服務的分組提供一定保護。

然而,如果此狀況具有一定的持續性,當緩存空間被耗盡時,路由器只有丟棄分組。

在這種持續過載的狀態下,網絡性能會急劇下降.

流量控制

流量控制是一種預防發送端過多向接收端發送數據的機制。否則,接收端可能因爲忙碌、負載重或緩衝區既定而無法處理。

爲實現流量控制,TCP連接的每一方都要通告自己的接收窗口receive window(rwnd),其中包含能夠保存數據的緩衝區空間大小信息。

 

 

最初的TCP規範分配給通告窗口大小的字段是16位的,這相當於設定了發送端和接收端窗口的最大值(65535字節)。結果,在這個限制內經常無法獲得最優性能。

爲解決這個問題,RFC1323提供了TCP窗口縮放(TCP Window Scaling)選項,可以把接收窗口大小由65535字節提高到1G字節。

那麼現在問題來了,rwnd只是一個接收端的初始窗口大小,如果有多個sender都在向receiver發送數據包的話,怎麼才能保證receiver端的接收性能呢?

爲了解決這個問題,TCP引入了慢啓動的概念。

當sender和receiver已經建立好了TCP三次握手之後。就可以開始發送數據包了。

這裏引入了一個擁堵窗口Congestion window(cwnd)的概念。

cwnd是server端目前可以接受的最大的窗口大小。

建立連接之後第一次發送的cwnd是一個初始值,這個初始值最開始是1個network segment,在1999年 RFC 2581將其更新爲4個network segments。在2013年, RFC 6928 將這個值擴大到了10個network segments。

我們以10個network segments爲例,看下cwnd的膨脹過程:

 

 

 

  

一般來說cwnd是倍數增加的,收到ack之後,cwnd會從10,20,40這樣往上增加。一直到server端拒絕ack爲止。

那麼回到我們之前講到的一個結論,帶寬其實不是那麼重要。

爲什麼呢?考慮在HTTP1.1中,client需要等待server的返回才能夠進行下一次請求。如果你的請求的文件比較小,那麼cwnd還沒有漲到足夠大的時候,請求就已經結束了。這個時候最主要的時間花費是請求的來回時間,而不在於帶寬大小。

當然,如果在HTTP2中,因爲建立的是長連接,慢啓動可能就不存在了(不確定,大家有不同的意見可以提出)。

UDP

UDP( User Datagram Protocol,用戶數據報協議。

UDP 的主要功能和亮點並不在於它引入了什麼特性,而在於它忽略的那些特性:不保證消息交付,不保證交付順序,不跟蹤連接狀態,不需要擁塞控制。

我們先來看一下UDP的數據包:

 

 

NAT

大家都知道IPV4地址是有限的,很快IPV4地址就快用完了,那怎麼解決這個問題呢?

當然,一個永久解決的辦法是IPV6,不過IPV6推出這麼多年了,好像還沒有真正的普及。

不使用IPV6的話還有什麼解決辦法呢?

這個辦法就是NAT(Network Address Translators)。

 

 

NAT的原理是將局域網的IP和端口和NAT設備的IP和端口做個映射。

NAT內部維護着一張轉換表。這樣就可以通過一個NAT的IP地址和不同的端口來連接衆多的局域網服務器。

那麼NAT有什麼問題呢?

NAT的問題在於,內部客戶端不知道自己外網IP地址,只知道內網IP地址。

如果是在UDP協議中,因爲UDP是無狀態的,所以需要NAT來重寫每個UDP分組中的源端口、地址,以及IP分組中的源IP地址。

如果客戶端是在應用程序內部將自己的IP地址告訴服務器,並想跟服務器建立連接,那麼肯定是建立不了的。因爲找不到客戶端的公網IP。

即使找到了公網IP,任何到達NAT設備外網IP的分組還必須有一個目標端口,而且NAT轉換表中也要有一個條目可以將其轉換爲內部主機的IP地址和端口號。否則就可能出現下圖的連接失敗的問題。

 

 

怎麼解決呢?

第一種方式是使用STUN服務器。

 

 

STUN服務器是IP地址已知的服務器,客戶端要通信之前,先去STUN服務器上面查詢一下自己的外網IP和端口,然後再使用這個外網IP和端口進行通信。

但有時UDP包會被防火牆或者其他的應用程序所阻擋。這個時候就可以使用中繼器技術Traversal Using Relays around NAT (TURN) 。

 

 

雙方都將數據發送到中繼器server,由中繼器server來負責轉發數據。注意,這裏已經不是P2P了。

最後,我們有一個集大成者的協議叫做ICE(Interactive Connectivity Establishment ):

 

 

 

  

 它實際上就是直連,STUN和TURN的綜合體,能直連的時候就直連,不能直連就用STUN,不能用STUN就用TURN。

總結

本文介紹了IP,TCP和UDP等協議和需要注意的一些事項,希望大家能夠喜歡。

 

本文鏈接:

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章