為什么要把服務器放在離用戶很近的地理位置上？其中一個原因是為了實現更低的延遲。當您發送的數據是短的、應該盡可能快的傳輸數據時，這很有意義。但如果是大文件，比如視頻等大文件呢？當然，在接收第一個字節時肯定會有延遲懲罰，但之后不應該一帆風順嗎？

通過TCP發送數據時，像HTTP一樣，一個常見的誤解是帶寬與延遲無關。但是，對于TCP來說，帶寬是延遲和時間的函數。我們來看看是怎么做到的。

握手

在客戶端開始向服務器發送數據之前，它需要對TCP進行握手，對TLS進行另一個握手。

TCP使用三向握手來建立一個新的連接。

發送方選擇一個隨機生成的序列號 "x "并發送一個SYN數據包給接收方

接收方遞增 "x"，選擇一個隨機生成的序列號 "y "并發送一個SYN/ACK數據包。

發送方遞增序列號，并回復一個ACK數據包和第一個字節的應用數據。

TCP使用序列號是為了保證數據的有序、無漏洞的傳遞。

握手

握手引入了一個完整的往返，這取決于底層網絡的延遲。TLS 握手也需要最多兩次往返。在TLS連接打開之前，不能發送任何應用數據，這意味著在這之前，你的帶寬是零。回程時間越低，建立連接的速度就越快。

流量控制

流量控制是一種回避機制，實現的目的是防止發送方壓倒接收方。

接收方將傳入的TCP數據包存儲到一個接收緩沖區，等待應用程序處理。

流量控制

每當接收方承認一個數據包時，接收方也會向發送方反饋緩沖區的大小。如果發送方尊重協議，發送方就會避免發送更多可以裝入接收方緩沖區的數據。

流量控制

這種機制與應用層面的速率限制沒有太大區別。但是，與API密鑰或IP地址上的速率限制不同，TCP是在連接層面上的速率限制。

發送方和接收方之間的往返時間(RTT)越低，發送方就越能使其輸出帶寬適應接收方的容量。

擁堵控制

TCP不僅要防止接收方不堪重負，還要防止底層網絡被淹沒。

發送方如何知道底層網絡的可用帶寬是多少？唯一的方法就是通過測量來估算。

其思路是，發送方維護一個所謂的 "擁塞窗口"。擁塞窗口表示不等待對方的回執，可以發送的未完成的數據包總數。接收器窗口的大小限制了擁塞窗口的最大大小。擁塞窗口越小，在任何給定的時間內可以飛行的字節數就越少，帶寬的利用率就越低。

當建立新連接時，擁塞窗口的大小被設置為系統默認值。然后，每承認一個數據包，窗口的大小就會成指數級地增加。這意味著，我們不能在建立連接后立即使用網絡的全部容量。再次，來回時間越低，發送方就越能迅速開始利用底層網絡的帶寬。

擁堵控制

如果數據包丟失了怎么辦？當發送方通過超時檢測到漏報時，一個叫做 "擁塞避免 "的機制就會啟動，擁塞窗口大小就會減小。從此以后，時間會使窗口大小增加一定的量，超時則會使窗口大小減少另一個。

如前所述，擁塞窗口的大小定義了無需等待確認就可以發送的最大比特數。而發送者需要等待一個完整的往返，才能得到一個確認。所以，將擁塞窗口的大小除以往返時間，就可以得到最大理論帶寬。

帶寬= WinSize / RTT

這個簡單的等式表明，帶寬是延時的一個函數。TCP會非常努力地優化窗口大小，因為它對往返時間無能為力。但是，這并不總是能得到最佳配置。

總結一下，擁塞控制是一種自適應機制，用于推斷網絡的底層帶寬和擁塞情況。類似的模式也可以應用在應用層面。想一想，當你在Netflix上看一部電影時，會發生什么？它開始模糊；然后，它會穩定到合理的程度，直到出現打嗝，質量再次惡化。這種應用于視頻流媒體的機制被稱為自適應比特率流媒體。

記住這一點

如果你使用的是HTTP，那么你就得聽從底層協議的安排。如果你不知道香腸是怎么做的，你就無法獲得最好的性能。

突發請求會受到冷啟動懲罰。使用TCP和TLS握手協議發送第一個字節可能需要多次往返。而且由于擁塞控制的工作方式，往返時間越低，底層網絡的帶寬利用得越好。

在這個問題上已經寫了整整一本書，你可以做很多事情來榨取每一盎司的帶寬。但是，如果你必須記住一件事，那就是關于TCP的事情。

你不能以光速發送數據，但你可以做的是把你的服務器放在離客戶端更近的地方，并重復使用連接來避免冷啟動懲罰。

總結

以上是生活随笔為你收集整理的tcp序列号为什么是随机的_译文：每个开发人员应了解的 TCP 知识的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。