TCP與UDP的差異是什麼？要確實送達，還是要速度
TCP（傳輸控制協定）和UDP（使用者資料包協定），都是在IP之上運作、規定資料怎麼送達的規則。TCP會確認資料是否送達、重傳遺失的部分，並依順序交出，所以用在網頁和電子郵件這類不能有缺漏的通訊。UDP不確認就直接送出，步驟少，適合怕延遲的通話、遊戲和簡短的查詢。
這篇文章可以了解
- 只靠IP不夠的地方，以及TCP、UDP負責的工作
- 連接埠號碼代表什麼（80號、443號、53號等）
- TCP確實送達的機制（打招呼、編號與回覆、重傳、調整傳送量）
- 選擇UDP的場合，以及建構在UDP之上的新規則QUIC
先備知識：不需要。如果讀過「網際網路怎麼傳送資料？」（封包與路由器的內容），會更容易閱讀。
生活中的例子
打開網頁時，幾乎不會遇到文章中間少了一段，或段落順序對調的情況。另一方面，視訊通話時，聲音有時會中斷一下，畫面也可能突然跳格。
走的都是同一個網際網路，不同的是傳送資料的想法。網頁重視「就算多等一下，也要全部正確」，通話重視「就算缺一點，也不能延遲」。代表這2種想法的，就是TCP和UDP。
只靠IP，不知道有沒有送到
網際網路會把資料分成稱為封包的小塊，由稱為路由器的設備轉送。詳細內容在「網際網路怎麼傳送資料？」中說明。這時，負責送到目的地的規則是IP。IP只專心把封包送出去，不確認是否送達。
所以在途中，可能發生下面這些事。
- 太擁擠的路由器把封包丟掉（遺失）
- 路線改變，後送的封包先到（順序錯亂）
- 同一個封包送到2次（重複）
如果要瀏覽器、通話App各自修正這些錯亂，會非常辛苦。所以，在IP和App之間再放一層。這一層稱為傳輸層，代表就是TCP和UDP。
兩者都定在公開網際網路技術規則的文件裡，這種文件稱為RFC。UDP在1980年、TCP在1981年，把現在這種形式的基礎寫成文件。TCP在2022年，還出了一份重新整理40多年改良的文件。
連接埠號碼：設備裡的哪一個App
IP位址是表示封包要送到哪台設備的號碼（「IP位址是什麼？」）。但在1台手機裡，瀏覽器、電子郵件、通話App同時在通訊。收到的封包，該交給哪個App呢？
所以，TCP和UDP會在標頭（封包開頭寫著目的地等資訊的部分）再寫上另一個號碼。這是表示設備裡「哪一個窗口」的0～65,535號碼，稱為連接埠號碼。用IP位址和連接埠號碼的組合，就能送到對方設備裡的App。
伺服器的窗口號碼，大致依用途決定。網頁是80號（HTTP）和443號（HTTPS），從名稱查號碼的DNS是53號。0～1023號分配給廣泛使用的用途，稱為知名連接埠。
另一方面，手機瀏覽器這一端的號碼，每次開始通訊時，會從空著的號碼中選一個。回覆會送到這個號碼，所以就算和同一台伺服器同時有2條通訊，回覆也不會混在一起。
TCP：先打招呼，建立連線
TCP在傳送資料前，會先和對方簡短打個招呼。流程是下面3次交換。
- 傳送端送出「我想開始通訊。我的流水號從這裡開始」（SYN）
- 接收端回覆「知道了。我的號碼從這裡開始」（SYN+ACK）
- 傳送端回覆「了解」（ACK）
SYN代表「想開始」，ACK代表「收到了」，兩者都是標記的名稱。因為是3次交換，所以稱為三向交握。雙方互相確認號碼從哪裡開始數，可以避免和網路裡殘留的舊封包搞混。
像這樣互相確認「要和這個對象通訊」的狀態，稱為連線。
打招呼要花1次來回的時間（從送出資料到回覆回來的時間）。東京和洛杉磯之間約0.1秒。HTTPS在這之後，還要接著準備加密（「HTTPS是什麼？」）。
流水號與「已收到」的回覆
TCP會替送出的資料加上流水號。號碼表示這是從資料開頭算起的第幾個位元組（1位元組是8個0或1排在一起的量）。這個號碼稱為序號。
接收端會回覆「已收到這裡為止，下次請從這個號碼開始送」。這個回覆稱為確認應答，英文縮寫寫成ACK。
傳送端並不是每等到1個回覆，才送下一份。在一定的量以內，不等回覆就繼續送。如果每次都等，對方越遠就越慢。
沒有回覆，就重傳
傳送端送出資料後，如果在一定時間內沒收到回覆，就判斷資料在途中遺失了。然後，再送一次同樣的資料。這稱為重傳。
等待的時間，會一邊測量和對方來回的時間一邊決定。還沒測到時，標準是1秒。重傳後仍沒有回覆，等待時間就加倍。另外，如果後面的資料明明有送到，「還是只到這裡」的相同回覆卻一再出現，就判斷有缺漏，不等待直接重傳。
不過，重傳不會永遠持續。不管送幾次都沒有回覆，TCP就會放棄並切斷連線（後面的「常見的誤解」會說明）。
排好順序，丟掉重複
接收端看流水號，把資料重新排成正確的順序。同一個號碼的資料送到2次時，就丟掉其中一份。這樣交給App的，就是依送出順序排好、沒有缺漏也沒有重複的資料。
相對地，只要途中缺了1處，就算後面的資料已經送到，也不會交給App。在缺漏部分的重傳送到之前，後面的資料都得等。這種等待，是後面會提到的QUIC想減少的問題之一。
調整傳送量：流量控制與壅塞控制
接收端的設備，有暫時存放收到資料的地方（接收用的記憶體）。App讀取的速度跟不上，這個地方就會滿出來。所以接收端每次回覆時，都會告知剩餘空間「還能收這麼多」。讓傳送端不超過這個量傳送的機制，稱為流量控制。
途中的網路也可能滿出來。大家同時大量傳送，路由器處理不完就會丟掉封包。TCP一開始少送一點，再看送達的情況逐步增加。許多方式會把封包遺失當作擁擠的徵兆，大幅減少傳送量。這種機制稱為壅塞控制（壅塞就是擁擠的意思）。
壅塞控制加進TCP，是因為真的出了問題。1986年10月，在美國相距數百公尺的研究機構和大學之間，通訊速度從每秒32千位元掉到每秒40位元。各台電腦重傳遺失的部分，又讓線路更擁擠，形成惡性循環。研究人員范·雅各布森（Van Jacobson）等人想出對策，在1988年的論文中發表。
UDP：不確認，立刻送出
UDP不打招呼、不確認回覆、不重傳，也不重新排序。只在標頭寫上連接埠號碼等資訊，就把資料直接送出去。所以標頭也比TCP小。
那麼，途中缺掉的資料會怎麼樣呢？UDP本身什麼都不做，所以由App決定。如果是通話App，就放棄缺掉的那一瞬間的聲音，播放下一段聲音。必要時，App也可以自己加上號碼，只重傳重要的資料。
UDP也不調整傳送量。所以用UDP大量傳送的App，必須自己調整速度，以免讓網路擁擠。
「不延遲」最重要的通訊
對話時，延遲太大，雙方就會接不上話。國際電信聯合（ITU）在建議書G.114中，提出了延遲的標準。標準是單程0.15秒以內，多數用途幾乎不會在意交談的延遲。
如果用TCP傳送通話，在等待缺掉聲音的重傳時，後面的聲音也會停住。等重傳送到時，對話早就往下進行了。所以通話和節奏快的遊戲，偏好缺了也不會停的UDP。
分別用在哪裡
| 用途 | 主要使用 | 理由 |
|---|---|---|
| 網頁（HTTP/1.1、HTTP/2） | TCP | 文字或圖片不能有缺漏 |
| 電子郵件、檔案傳輸 | TCP | 缺了1處就會損壞 |
| DNS查詢 | UDP（大的回答用TCP） | 1次來回就結束的簡短交換 |
| 視訊通話、語音通話 | UDP（無法通過時用TCP） | 晚到的聲音沒有用 |
| 動作快速的對戰遊戲 | 多半用UDP | 最新的位置最重要 |
| 影片串流（錄影和直播） | 多半是HTTP（TCP或QUIC） | 先存好後面的部分再播放，有時間重傳 |
DNS的運作，在「DNS是什麼？」中說明。想用表格更細地比較各個面向，可以參考「TCP與UDP的差異」。
QUIC：在UDP之上加上確實性與加密
新版的網頁規則HTTP/3不使用TCP，而是使用建構在UDP之上、稱為QUIC的規則。QUIC自己負責編號與回覆、重傳、調整傳送量，也就是和TCP相同的工作。它還內建HTTPS所用的加密機制（TLS），內容一定會加密。
為什麼要特地把新的規則建構在UDP之上呢？原因之一是途中的設備。家用路由器和公司的防火牆，大多不讓不認識種類的封包通過。用UDP的話，就能直接通過現有的網路。
另一個原因是容易改良。TCP內建在作業系統（電腦和手機的基本軟體）裡，改良要普及得花上好幾年。QUIC在瀏覽器等App裡運作，所以隨著App更新就能送出改良。
QUIC把TCP的打招呼和加密的準備合在一起，1次來回就完成。TCP和TLS的組合，通常要2次來回。另外，它會依圖片、文章等每一條資料流，分別管理順序。所以，因為1處缺漏而讓無關的資料也得等待的情況變少了。
QUIC在2021年5月以RFC 9000、HTTP/3在2022年6月以RFC 9114成為標準。根據調查公司W3Techs，2026年時，調查的網站中將近4成可以使用HTTP/3。也有網路不讓UDP通過，這時瀏覽器會改用TCP的HTTP/2等。版本的差異整理在「HTTP/1.1、HTTP/2、HTTP/3的差異」的表格中。
常見的誤解
誤解：UDP任何時候都比較快
實際上，UDP省掉的是打招呼和確認的工夫，線路本身並不會變快。傳送大檔案的時間，主要由線路的速度決定。
不確認就大量傳送，封包會在路由器被丟掉，缺漏反而變多。想確實送達，App就得自己做重傳，做法不好的話可能比TCP還慢。UDP佔優勢的，是想縮小延遲時，以及1次來回就結束的簡短交換。
誤解：只要用TCP，不管什麼情況都一定送得到
實際上，TCP保證的是「送到的部分，會沒有缺漏、沒有重複，依順序交出」。網路線拔掉、走到Wi-Fi收不到的地方，或對方的伺服器停了，重傳也送不到。
這種狀態持續下去，TCP就會放棄並切斷連線。整理網際網路設備需求的1989年規格，建議資料的重傳至少要持續100秒。App會收到「連線中斷」的通知，再由App決定要不要重來。
誤解：遊戲和影片一定用UDP
實際上，錄好的影片和直播，大多和網頁一樣用HTTP傳送。因為會先存好幾秒的量再播放，有時間重傳缺掉的部分。YouTube除了TCP，也使用QUIC。
遊戲也一樣，用哪一種要看遊戲的類型。一瞬間的操作決定勝負的對戰遊戲，多半使用UDP。另一方面，不需要立即反應的遊戲，用TCP通常就夠了。
從數字來看
| 項目 | 數字 | 時間、出處 |
|---|---|---|
| 標頭的大小 | TCP 20位元組、UDP 8位元組 | TCP為沒有額外欄位時（RFC 9293、RFC 768） |
| 連接埠號碼的範圍 | 0～65,535 | 0～1023為知名連接埠（IANA） |
| 開始傳送資料前的準備 | TCP 1次來回，加上TLS為2次來回，QUIC 1次來回 | TLS為1.3時 |
| 東京–洛杉磯的1次來回 | 約0.11秒 | 2026年初的月平均（Verizon） |
| 重傳前最初的等待時間 | 1秒（之後每次加倍） | 測量來回時間前的標準（RFC 6298，2011年） |
| 1986年壅塞造成的速度下降 | 每秒32千位元→40位元 | 雅各布森等人的論文（1988年） |
| 成為標準的年份 | UDP 1980年、TCP 1981年（2022年重新整理）、QUIC 2021年、HTTP/3 2022年 | IETF的RFC |
| 可使用HTTP/3的網站 | 將近4成（37～40%） | 2026年，W3Techs |
如果和對方來回1次要0.11秒，準備少1次來回，資料就能早約0.1秒開始送達。對方越遠，減少來回次數的效果越大。
進一步學習
- 用表格看差異：TCP與UDP的差異（包括標頭、資料的分界、目的地的種類）
- 用計算試試看：資料傳輸時間計算工具（可以把標頭和重傳的影響當作「傳輸效率」輸入）
- 下一步的名詞：RTT（從送出到回覆回來的時間）、MTU（1次能搬運的封包大小）
- 安全的名詞：防火牆（看連接埠號碼等資訊，限制通訊進出的機制）
- 從系列的第一篇開始：「網際網路怎麼傳送資料？」