傳輸層協議延遲時間組成延遲指的就是從傳送源到接收源經歷的時間頻寬指的就是邏輯或物理路徑最大的吞吐量
從傳送源開始到接收源，中間可能經過很多的基站或者運營商等，那麼延遲到底由哪些部分組成呢？從客戶端到服務端之間歷經的過程會涉及到以下的延遲：
之前我們介紹過CDN的原理，就是讓使用者從最近的伺服器載入內容，大幅度降低傳播分組的時間，在距離與時間的選擇當中，我們選擇縮短距離的方式來減少載入時間。
其實我們應該明白，造成使用者載入時間過慢的原因不是頻寬的問題，而是延遲的問題。比如從中國請求美國的網站，中間花的時間不是橫跨大洋或者大陸產生的，而是你當前接收的地址（一般是家或者辦公室）與最近的服務運營商之間的連線，中間可能會經過多個路由器，路由器進行網路資料的分發，最終才會與運營商連線起來。
在linux平臺上可以使用traceroute 命令最終資訊的傳輸過程，計算每一跳所需要的時間，window就透過tracert命令。
由於人們對影片的需求增長迅速，所以我們提高傳輸的頻寬是非常有必要的，比如部署更多的光纖、擁塞路由之間改善鏈路、或者使用光纖波分複用（WDN）等技術來讓現有的硬體裝置傳輸更多的資料。
WDN:波分複用(WDM)是將兩種或多種不同波長的光載波訊號(攜帶各種資訊)在傳送端經複用器(亦稱合波器)匯合在一起，並耦合到光線路的同一根光纖中進行傳輸的技術；在接收端，經解複用器(亦稱分波器或稱去複用器)將各種波長的光載波分離，然後由光接收機作進一步處理以恢復原訊號。這種在同一根光纖中同時傳輸兩個或眾多不同波長光訊號的技術,稱為波分複用
除了提高頻寬，我們也可以利用減少延遲的方式改善，可以讓光訊號傳輸的速率更接近光速，如採用折射率更低的材料、速度更快的路由器或者中繼器。上面我們就提到過其實資訊分組的傳輸中，延遲是最難以解決的。
「TCP/IP協議」
我們這兩種協議並不陌生，IP協議（因特網協議），負責聯網主機之間的路由選擇與定址；TCP協議（傳輸控制協議），負責不可靠的傳輸通道之上提供可靠的抽象層。對於資訊傳輸的過程中發生的事情，如丟包、擁塞控制等隱藏，所以在最佳化的時候我們可能會有一些挑戰。
「三次握手」
在客戶端與伺服器進行應用資料交換之前進行操作。
三次握手
在三次握手階段其實是比較耗費效能的，因此我們想要最佳化網路也可以從這一方面下手，任何兩段資料想要透過TCP傳輸，那麼握手就是必不可少的階段。谷歌的開發人員研究出一種TCP Fast Open的技術，透過客戶端連線時附加一個Cookie（一個TCP選項，此Cookie通常採用一種分組密碼，私鑰由伺服器根據客戶端的IP地址儲存）來驗證是否之前就連線過，如果成功則可以在伺服器收到第三個包之前就傳送資料。
「擁塞控制及預防」
流量控制是一種預防傳送端向服務端傳送過多資料的一種機制。如果超過了接收端的接收量，可能會造成負載重而處理不過來的情況。每一方都要向對方告知自己的接收視窗，確保能夠開闢一個數據緩衝區接收對方的資訊。
慢啟動出現的原因其實就是連線剛建立的雙發都不知道網路中可用的頻寬是多少，必須要有一個估算的機制，而且這個機制還要隨著網路傳輸的頻寬而進行動態變化。我們不可能一上來就完全利用連線的最大頻寬，都需要慢慢地傳輸資料資訊以防止網路擁堵。
當出現丟包的時候，就會認為網路已經出現了擁塞，此時就會採取刪包的措施來緩解網路中的某個連線或者路由器的擁塞。然後透過重置擁塞視窗，預防機制按照自己的演算法逐步增大視窗，避免丟包。
「隊首阻塞」
我們都知道TCP有順序交付的特點，從一開始的確認應答機制到滑動視窗的機制，前者是隻有確認前一個包才可以進行下一個包的傳送，後者是允許你傳送一定數量的包到接收端，但假如有一個包接收端一直收不到，那就必須停止後面包的傳送，重發丟失的包。
所以這裡我們就會出現假如一個包要處理很久，那麼豈不是後面的都一直等待？這就是隊首阻塞問題。
http2中無論在客戶端還是在伺服器端都不需要排隊，在同一個tcp連線上，有多個stream，由各個stream傳送和接收http請求，各個steam相互獨立，互不阻塞。這就解決了這個問題。
「TCP最佳化建議」
要對TCP進行最佳化，必須要最大限度地利用底層協議的原理，其原理性的東西無非就是以下的幾點：
伺服器調優
透過進行伺服器的最優調整，把主機的作業系統升級到最新版本，可以確保每個TCP連線都具有較低的延遲和較高的吞吐量。
應用程式行為調優
請求的影響因素就是減少請求與壓縮體積，透過減少一些不必要的資料傳輸和減少傳輸距離，能夠使應用程式的行為最優。
小結
由於UDP是一種簡單的協議，它的高效性正是因為它忽略了很多TCP的特性，但是由於這樣的高效性，可能也會造成麻煩。舉個例子來說，當你看影片的時候假如沒有經過擁塞處理，可能會佔用大量的頻寬，導致一些正常的TCP連線無法傳送正常的資料，如網頁也可能無法開啟。另一種情況也有可能造成影片一直卡頓，無法載入。
所以我們針對這種情況必須進行有效的處理，根據RFC的文件，主要有幾種最佳化方案。
以上的最佳化必須是應用程式做出的最佳化。
前端與網路的關係大家都知道，理解TCP的核心機制已經是web最佳化的必修課，我們在專案中一般不會深入到鏈路物理層面進行最佳化，但是應用層的最佳化我們還是可以做的。
傳輸層協議延遲時間組成延遲指的就是從傳送源到接收源經歷的時間頻寬指的就是邏輯或物理路徑最大的吞吐量
從傳送源開始到接收源，中間可能經過很多的基站或者運營商等，那麼延遲到底由哪些部分組成呢？從客戶端到服務端之間歷經的過程會涉及到以下的延遲：
傳播延遲：從傳送端到接收端的時間，是傳播距離與速度的關係傳輸延遲：傳輸的資訊轉移到鏈路中需要的時間，是訊息長度與鏈路速率的關係處理延遲：處理分組首部、檢查位錯誤以及確定分組目標所需的時間排隊延遲：到來的分組排隊等待的時間之前我們介紹過CDN的原理，就是讓使用者從最近的伺服器載入內容，大幅度降低傳播分組的時間，在距離與時間的選擇當中，我們選擇縮短距離的方式來減少載入時間。
其實我們應該明白，造成使用者載入時間過慢的原因不是頻寬的問題，而是延遲的問題。比如從中國請求美國的網站，中間花的時間不是橫跨大洋或者大陸產生的，而是你當前接收的地址（一般是家或者辦公室）與最近的服務運營商之間的連線，中間可能會經過多個路由器，路由器進行網路資料的分發，最終才會與運營商連線起來。
在linux平臺上可以使用traceroute 命令最終資訊的傳輸過程，計算每一跳所需要的時間，window就透過tracert命令。
高頻寬與低延遲由於人們對影片的需求增長迅速，所以我們提高傳輸的頻寬是非常有必要的，比如部署更多的光纖、擁塞路由之間改善鏈路、或者使用光纖波分複用（WDN）等技術來讓現有的硬體裝置傳輸更多的資料。
WDN:波分複用(WDM)是將兩種或多種不同波長的光載波訊號(攜帶各種資訊)在傳送端經複用器(亦稱合波器)匯合在一起，並耦合到光線路的同一根光纖中進行傳輸的技術；在接收端，經解複用器(亦稱分波器或稱去複用器)將各種波長的光載波分離，然後由光接收機作進一步處理以恢復原訊號。這種在同一根光纖中同時傳輸兩個或眾多不同波長光訊號的技術,稱為波分複用
除了提高頻寬，我們也可以利用減少延遲的方式改善，可以讓光訊號傳輸的速率更接近光速，如採用折射率更低的材料、速度更快的路由器或者中繼器。上面我們就提到過其實資訊分組的傳輸中，延遲是最難以解決的。
TCP的具體構成「TCP/IP協議」
我們這兩種協議並不陌生，IP協議（因特網協議），負責聯網主機之間的路由選擇與定址；TCP協議（傳輸控制協議），負責不可靠的傳輸通道之上提供可靠的抽象層。對於資訊傳輸的過程中發生的事情，如丟包、擁塞控制等隱藏，所以在最佳化的時候我們可能會有一些挑戰。
「三次握手」
在客戶端與伺服器進行應用資料交換之前進行操作。
三次握手
在三次握手階段其實是比較耗費效能的，因此我們想要最佳化網路也可以從這一方面下手，任何兩段資料想要透過TCP傳輸，那麼握手就是必不可少的階段。谷歌的開發人員研究出一種TCP Fast Open的技術，透過客戶端連線時附加一個Cookie（一個TCP選項，此Cookie通常採用一種分組密碼，私鑰由伺服器根據客戶端的IP地址儲存）來驗證是否之前就連線過，如果成功則可以在伺服器收到第三個包之前就傳送資料。
「擁塞控制及預防」
流量控制流量控制是一種預防傳送端向服務端傳送過多資料的一種機制。如果超過了接收端的接收量，可能會造成負載重而處理不過來的情況。每一方都要向對方告知自己的接收視窗，確保能夠開闢一個數據緩衝區接收對方的資訊。
慢啟動慢啟動出現的原因其實就是連線剛建立的雙發都不知道網路中可用的頻寬是多少，必須要有一個估算的機制，而且這個機制還要隨著網路傳輸的頻寬而進行動態變化。我們不可能一上來就完全利用連線的最大頻寬，都需要慢慢地傳輸資料資訊以防止網路擁堵。
擁塞預防當出現丟包的時候，就會認為網路已經出現了擁塞，此時就會採取刪包的措施來緩解網路中的某個連線或者路由器的擁塞。然後透過重置擁塞視窗，預防機制按照自己的演算法逐步增大視窗，避免丟包。
「隊首阻塞」
我們都知道TCP有順序交付的特點，從一開始的確認應答機制到滑動視窗的機制，前者是隻有確認前一個包才可以進行下一個包的傳送，後者是允許你傳送一定數量的包到接收端，但假如有一個包接收端一直收不到，那就必須停止後面包的傳送，重發丟失的包。
所以這裡我們就會出現假如一個包要處理很久，那麼豈不是後面的都一直等待？這就是隊首阻塞問題。
http2中無論在客戶端還是在伺服器端都不需要排隊，在同一個tcp連線上，有多個stream，由各個stream傳送和接收http請求，各個steam相互獨立，互不阻塞。這就解決了這個問題。
「TCP最佳化建議」
要對TCP進行最佳化，必須要最大限度地利用底層協議的原理，其原理性的東西無非就是以下的幾點：
三次握手就是一次往返時間慢啟動在每個連線中都應用流量控制和擁塞控制會影響到所有連線的吞吐量吞吐量由當前擁塞視窗大小控制伺服器調優
增大TCP的初始化擁塞視窗慢啟動重啟視窗縮放TCP快速開啟透過進行伺服器的最優調整，把主機的作業系統升級到最新版本，可以確保每個TCP連線都具有較低的延遲和較高的吞吐量。
應用程式行為調優
資料能不發就不發使用CDN讓傳輸距離變短複用TCP連線請求的影響因素就是減少請求與壓縮體積，透過減少一些不必要的資料傳輸和減少傳輸距離，能夠使應用程式的行為最優。
小結
升級伺服器核心版本擁塞視窗大小為10禁用空閒後的慢啟動確保啟動視窗縮放減少傳輸冗餘資料壓縮傳輸的資料伺服器放到離使用者最近的地方（CDN）重用TCP連線UDP的最佳化由於UDP是一種簡單的協議，它的高效性正是因為它忽略了很多TCP的特性，但是由於這樣的高效性，可能也會造成麻煩。舉個例子來說，當你看影片的時候假如沒有經過擁塞處理，可能會佔用大量的頻寬，導致一些正常的TCP連線無法傳送正常的資料，如網頁也可能無法開啟。另一種情況也有可能造成影片一直卡頓，無法載入。
所以我們針對這種情況必須進行有效的處理，根據RFC的文件，主要有幾種最佳化方案。
控制傳輸速度對所有的流量進行擁塞控制使用與TCP相近的頻寬處理資料包丟失、重複和重排以上的最佳化必須是應用程式做出的最佳化。
前端與網路的關係大家都知道，理解TCP的核心機制已經是web最佳化的必修課，我們在專案中一般不會深入到鏈路物理層面進行最佳化，但是應用層的最佳化我們還是可以做的。