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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如果你訪問一個網站，比如www.flydean.com，我們看一下數據是怎么從服務器到達你的電腦的。

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

ISP是啥呢？ISP就是互聯網服務提供商（Internet Service Provider），通過ISP你才能夠把服務器接入互聯網。

互聯網就是通過主干網的互聯網服務提供商（ISP）之間的相互連接構成的。

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

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

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

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

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

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

最后，我們對于分組數據進行排隊處理也需要時間。

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

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

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

200ms夠快了，但是為什么我們仍然會感覺到網速慢呢？

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

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

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

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

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

數據包(data packet)是什么？

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

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

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

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

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

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

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

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

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

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

一般來說，使用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 (User Datagram Protocol)，用戶數據報協議。

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

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

大家都知道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。