傳輸控制協(xié)議（英語：Transmission Control Protocol上煤，縮寫：TCP）是一種面向連接的休玩、可靠的、基于字節(jié)流的傳輸層通信協(xié)議劫狠，由IETF的RFC 793定義哥捕。在簡化的計算機網(wǎng)絡(luò)OSI模型中，它完成第四層傳輸層所指定的功能嘉熊。用戶數(shù)據(jù)報協(xié)議（UDP）是同一層內(nèi)另一個重要的傳輸協(xié)議。
在因特網(wǎng)協(xié)議族（Internet protocol suite）中扬舒，TCP層是位于IP層之上阐肤，應(yīng)用層之下的中間層。不同主機的應(yīng)用層之間經(jīng)常需要可靠的讲坎、像管道一樣的連接孕惜，但是IP層不提供這樣的流機制，而是提供不可靠的包交換晨炕。
應(yīng)用層向TCP層發(fā)送用于網(wǎng)間傳輸?shù)纳阑⒂?位字節(jié)表示的數(shù)據(jù)流，然后TCP把數(shù)據(jù)流分割成適當(dāng)長度的報文段（通常受該計算機連接的網(wǎng)絡(luò)的數(shù)據(jù)鏈路層的最大傳輸單元（MTU）的限制）瓮栗。之后TCP把結(jié)果包傳給IP層削罩，由它來通過網(wǎng)絡(luò)將包傳送給接收端實體的TCP層。TCP為了保證不發(fā)生丟包费奸，就給每個包一個序號弥激，同時序號也保證了傳送到接收端實體的包的按序接收。然后接收端實體對已成功收到的包發(fā)回一個相應(yīng)的確認(rèn)信息（ACK）愿阐；如果發(fā)送端實體在合理的往返時延（RTT）內(nèi)未收到確認(rèn)微服，那么對應(yīng)的數(shù)據(jù)包就被假設(shè)為已丟失并進(jìn)行重傳。TCP用一個校驗和函數(shù)來檢驗數(shù)據(jù)是否有錯誤缨历，在發(fā)送和接收時都要計算校驗和以蕴。
目錄
<label class="toctogglelabel" for="toctogglecheckbox" style="cursor: pointer; color: rgb(6, 69, 173);"></label>
簡介[編輯]
數(shù)據(jù)在TCP層稱為流（Stream）糙麦，數(shù)據(jù)分組稱為分段（Segment）。作為比較丛肮，數(shù)據(jù)在IP層稱為Datagram赡磅，數(shù)據(jù)分組稱為分片（Fragment）。 UDP 中分組稱為Message腾供。
運作方式[編輯]
簡化版的TCP狀態(tài)圖仆邓。更詳細(xì)的版本見： TCP EFSM 圖，包含了ESTABLISHED狀態(tài)的內(nèi)部狀態(tài)伴鳖。
TCP協(xié)議的運行可劃分為三個階段：連接創(chuàng)建(connection establishment)节值、數(shù)據(jù)傳送（data transfer）和連接終止（connection termination）。操作系統(tǒng)將TCP連接抽象為套接字表示的本地端點（local end-point）榜聂，作為編程接口給程序使用搞疗。在TCP連接的生命期內(nèi)，本地端點要經(jīng)歷一系列的狀態(tài)改變须肆。[1]
創(chuàng)建通路[編輯]
TCP用三次握手（或稱三路握手匿乃，three-way handshake）過程創(chuàng)建一個連接。在連接創(chuàng)建過程中豌汇，很多參數(shù)要被初始化幢炸，例如序號被初始化以保證按序傳輸和連接的強壯性。
TCP連接的正常創(chuàng)建
一對終端同時初始化一個它們之間的連接是可能的拒贱。但通常是由一端打開一個套接字（socket）然后監(jiān)聽來自另一方的連接宛徊，這就是通常所指的被動打開（passive open）。服務(wù)器端被被動打開以后逻澳，用戶端就能開始創(chuàng)建主動打開（active open）闸天。
- 客戶端通過向服務(wù)器端發(fā)送一個SYN來創(chuàng)建一個主動打開，作為三次握手的一部分斜做“客戶端把這段連接的序號設(shè)定為隨機數(shù)A。
- 服務(wù)器端應(yīng)當(dāng)為一個合法的SYN回送一個SYN/ACK瓤逼。ACK的確認(rèn)碼應(yīng)為A+1笼吟，SYN/ACK包本身又有一個隨機產(chǎn)生的序號B。
- 最后抛姑，客戶端再發(fā)送一個ACK赞厕。此時包的序號被設(shè)定為A+1，而ACK的確認(rèn)碼則為B+1定硝。當(dāng)服務(wù)端收到這個ACK的時候皿桑，就完成了三次握手，并進(jìn)入了連接創(chuàng)建狀態(tài)。
如果服務(wù)器端接到了客戶端發(fā)的SYN后回了SYN-ACK后客戶端掉線了诲侮，服務(wù)器端沒有收到客戶端回來的ACK镀虐，那么，這個連接處于一個中間狀態(tài)沟绪，即沒成功刮便，也沒失敗。于是绽慈，服務(wù)器端如果在一定時間內(nèi)沒有收到的TCP會重發(fā)SYN-ACK恨旱。在Linux下，默認(rèn)重試次數(shù)為5次坝疼，重試的間隔時間從1s開始每次都翻倍搜贤，5次的重試時間間隔為1s, 2s, 4s, 8s, 16s，總共31s钝凶，第5次發(fā)出后還要等32s才知道第5次也超時了仪芒，所以，總共需要 1s + 2s + 4s+ 8s+ 16s + 32s = 63s耕陷，TCP才會斷開這個連接掂名。使用三個TCP參數(shù)來調(diào)整行為：tcp_synack_retries 減少重試次數(shù)；tcp_max_syn_backlog哟沫，增大SYN連接數(shù)饺蔑；tcp_abort_on_overflow決定超出能力時的行為。
資源使用[編輯]
主機收到一個TCP包時嗜诀，用兩端的IP地址與端口號來標(biāo)識這個TCP包屬于哪個session膀钠。使用一張表來存儲所有的session，表中的每條稱作Transmission Control Block（TCB）裹虫，tcb結(jié)構(gòu)的定義包括連接使用的源端口、目的端口融击、目的ip筑公、序號、應(yīng)答序號尊浪、對方窗口大小匣屡、己方窗口大小、tcp狀態(tài)拇涤、tcp輸入/輸出隊列捣作、應(yīng)用層輸出隊列、tcp的重傳有關(guān)變量等鹅士。
服務(wù)器端的連接數(shù)量是無限的券躁，只受內(nèi)存的限制。客戶端的連接數(shù)量也拜，過去由于在發(fā)送第一個SYN到服務(wù)器之前需要先分配一個隨機空閑的端口以舒，這限制了客戶端IP地址的對外發(fā)出連接的數(shù)量上限。從Linux 4.2開始慢哈，有了socket選項IP_BIND_ADDRESS_NO_PORT蔓钟，它通知Linux內(nèi)核不保留usingbind使用端口號為0時內(nèi)部使用的臨時端口（ephemeral port），在connect時會自動選擇端口以組成獨一無二的四元組（同一個客戶端端口可用于連接不同的服務(wù)器套接字卵贱；同一個服務(wù)器端口可用于接受不同客戶端套接字的連接）滥沫。[2]
對于不能確認(rèn)的包、接收但還沒讀取的數(shù)據(jù)键俱，都會占用操作系統(tǒng)的資源兰绣。
數(shù)據(jù)傳輸[編輯]
在TCP的數(shù)據(jù)傳送狀態(tài)，很多重要的機制保證了TCP的可靠性和強壯性方妖。它們包括：使用序號狭魂，對收到的TCP報文段進(jìn)行排序以及檢測重復(fù)的數(shù)據(jù)；使用校驗和檢測報文段的錯誤党觅，即無錯傳輸[3]雌澄；使用確認(rèn)和計時器來檢測和糾正丟包或延時；流控制（Flow control）杯瞻；擁塞控制（Congestion control）镐牺；丟失包的重傳。
可靠傳輸[編輯]
通常在每個TCP報文段中都有一對序號和確認(rèn)號魁莉。TCP報文發(fā)送者稱自己的字節(jié)流的編號為序號睬涧，稱接收到對方的字節(jié)流編號為確認(rèn)號。TCP報文的接收者為了確逼煅洌可靠性畦浓，在接收到一定數(shù)量的連續(xù)字節(jié)流后才發(fā)送確認(rèn)。這是對TCP的一種擴展检疫，稱為選擇確認(rèn)（Selective Acknowledgement）讶请。選擇確認(rèn)使得TCP接收者可以對亂序到達(dá)的數(shù)據(jù)塊進(jìn)行確認(rèn)。每一個字節(jié)傳輸過后屎媳，ISN號都會遞增1夺溢。
通過使用序號和確認(rèn)號，TCP層可以把收到的報文段中的字節(jié)按正確的順序交付給應(yīng)用層烛谊。序號是32位的無符號數(shù)风响，在它增大到232-1時，便會回繞到0丹禀。對于ISN的選擇是TCP中關(guān)鍵的一個操作状勤，它可以確保強壯性和安全性鞋怀。
TCP協(xié)議使用序號（sequence number）標(biāo)識每端發(fā)出的字節(jié)的順序，從而另一端接收數(shù)據(jù)時可以重建順序荧降，無懼傳輸時的包的亂序交付或丟包接箫。在發(fā)送第一個包時（SYN包），選擇一個隨機數(shù)作為序號的初值朵诫，以克制TCP序號預(yù)測攻擊.
發(fā)送確認(rèn)包(Acks)辛友，攜帶了接收到的對方發(fā)來的字節(jié)流的編號，稱為確認(rèn)號剪返，以告訴對方已經(jīng)成功接收的數(shù)據(jù)流的字節(jié)位置废累。Ack并不意味著數(shù)據(jù)已經(jīng)交付了上層應(yīng)用程序。
可靠性通過發(fā)送方檢測到丟失的傳輸數(shù)據(jù)并重傳這些數(shù)據(jù)脱盲。包括超時重傳（Retransmission timeout邑滨，RTO）與重復(fù)累計確認(rèn)（duplicate cumulative acknowledgements，DupAcks）钱反。
基于重復(fù)累計確認(rèn)的重傳[編輯]
如果一個包（不妨設(shè)它的序號是100掖看，即該包始于第100字節(jié)）丟失，接收方就不能確認(rèn)這個包及其以后的包面哥，因為采用了累計ack哎壳。接收方在收到100以后的包時，發(fā)出對包含第99字節(jié)的包的確認(rèn)尚卫。這種重復(fù)確認(rèn)是包丟失的信號归榕。發(fā)送方如果收到3次對同一個包的確認(rèn)，就重傳最后一個未被確認(rèn)的包吱涉。閾值設(shè)為3被證實可以減少亂序包導(dǎo)致的無作用的重傳（spurious retransmission）現(xiàn)象刹泄。[4] 選擇性確認(rèn)(SACK)的使用能明確反饋哪個包收到了，極大改善了TCP重傳必要的包的能力怎爵。
超時重傳[編輯]
發(fā)送方使用一個保守估計的時間作為收到數(shù)據(jù)包的確認(rèn)的超時上限特石。如果超過這個上限仍未收到確認(rèn)包，發(fā)送方將重傳這個數(shù)據(jù)包鳖链。每當(dāng)發(fā)送方收到確認(rèn)包后县匠，會重置這個重傳定時器。典型地撒轮，定時器的值設(shè)定為 [圖片上傳失敗...(image-190583-1570713099377)] 其中[圖片上傳失敗...(image-52fa12-1570713099377)] 是時鐘粒度。[5] 進(jìn)一步贼穆，如果重傳定時器被觸發(fā)题山，仍然沒有收到確認(rèn)包，定時器的值將被設(shè)為前次值的二倍（直到特定閾值）故痊。這可對抗 中間人攻擊方式的拒絕服務(wù)攻擊顶瞳，這種攻擊愚弄發(fā)送者重傳很多次導(dǎo)致接受者被壓垮。
數(shù)據(jù)傳輸舉例[編輯]
TCP數(shù)據(jù)傳輸
- 發(fā)送方首先發(fā)送第一個包含序列號為1（可變化）和1460字節(jié)數(shù)據(jù)的TCP報文段給接收方。接收方以一個沒有數(shù)據(jù)的TCP報文段來回復(fù)（只含報頭）慨菱，用確認(rèn)號1461來表示已完全收到并請求下一個報文段焰络。
- 發(fā)送方然后發(fā)送第二個包含序列號為1461，長度為1460字節(jié)的數(shù)據(jù)的TCP報文段給接收方符喝。正常情況下闪彼，接收方以一個沒有數(shù)據(jù)的TCP報文段來回復(fù)，用確認(rèn)號2921（1461+1460）來表示已完全收到并請求下一個報文段协饲。發(fā)送接收這樣繼續(xù)下去畏腕。
- 然而當(dāng)這些數(shù)據(jù)包都是相連的情況下，接收方?jīng)]有必要每一次都回應(yīng)茉稠。比如描馅，他收到第1到5條TCP報文段，只需回應(yīng)第五條就行了而线。在例子中第3條TCP報文段被丟失了铭污，所以盡管他收到了第4和5條，然而他只能回應(yīng)第2條膀篮。
- 發(fā)送方在發(fā)送了第三條以后嘹狞，沒能收到回應(yīng)，因此當(dāng)時鐘（timer）過時（expire）時各拷，他重發(fā)第三條刁绒。（每次發(fā)送者發(fā)送一條TCP報文段后，都會再次啟動一次時鐘：RTT）烤黍。
- 這次第三條被成功接收知市，接收方可以直接確認(rèn)第5條，因為4速蕊，5兩條已收到嫂丙。
校驗和[編輯]
TCP的16位的校驗和（checksum）的計算和檢驗過程如下：發(fā)送者將TCP報文段的頭部和數(shù)據(jù)部分的和計算出來，再對其求反碼（一的補數(shù)）规哲，就得到了校驗和跟啤，然后將結(jié)果裝入報文中傳輸。（這里用反碼和的原因是這種方法的循環(huán)進(jìn)位使校驗和可以在16位唉锌、32位隅肥、64位等情況下的計算結(jié)果再疊加后相同）接收者在收到報文后再按相同的算法計算一次校驗和。這里使用的反碼使得接收者不用再將校驗和字段保存起來后清零袄简，而可以直接將報文段連同校驗加總腥放。如果計算結(jié)果是全部為一，那么就表示了報文的完整性和正確性绿语。
注意：TCP校驗和也包括了96位的偽頭部秃症，其中有源地址候址、目的地址、協(xié)議以及TCP的長度种柑。這可以避免報文被錯誤地路由岗仑。
按現(xiàn)在的標(biāo)準(zhǔn)，TCP的校驗和是一個比較脆弱的校驗聚请。出錯概率高的數(shù)據(jù)鏈路層需要更高的能力來探測和糾正連接錯誤荠雕。TCP如果是在今天設(shè)計的，它很可能有一個32位的CRC校驗來糾錯良漱，而不是使用校驗和舞虱。但是通過在第二層使用通常的CRC校驗或更完全一點的校驗可以部分地彌補這種脆弱的校驗。第二層是在TCP層和IP層之下的母市，比如PPP或以太網(wǎng)矾兜，它們使用了這些校驗。但是這也并不意味著TCP的16位校驗和是冗余的患久，對于因特網(wǎng)傳輸?shù)挠^察椅寺，表明在受CRC校驗保護(hù)的各跳之間，軟件和硬件的錯誤通常也會在報文中引入錯誤蒋失，而端到端的TCP校驗?zāi)軌虿蹲降酱蟛糠趾唵蔚腻e誤返帕。[6] 這就是應(yīng)用中的端到端原則。
流量控制[編輯]
流量控制用來避免主機分組發(fā)送得過快而使接收方來不及完全收下篙挽，一般由接收方通告給發(fā)送方進(jìn)行調(diào)控荆萤。
TCP使用滑動窗口協(xié)議實現(xiàn)流量控制。接收方在“接收窗口”域指出還可接收的字節(jié)數(shù)量铣卡。發(fā)送方在沒有新的確認(rèn)包的情況下至多發(fā)送“接收窗口”允許的字節(jié)數(shù)量链韭。接收方可修改“接收窗口”的值。
TCP包的序號與接收窗口的行為很像時鐘煮落。
當(dāng)接收方宣布接收窗口的值為0敞峭，發(fā)送方停止進(jìn)一步發(fā)送數(shù)據(jù)敦捧，開始了“保持定時器”（persist timer）瞬浓，以避免因隨后的修改接收窗口的數(shù)據(jù)包丟失使連接的雙側(cè)進(jìn)入死鎖，發(fā)送方無法發(fā)出數(shù)據(jù)直至收到接收方修改窗口的指示冒滩。當(dāng)“保持定時器”到期時轿衔，TCP發(fā)送方嘗試恢復(fù)發(fā)送一個小的ZWP包（Zero Window Probe）沉迹，期待接收方回復(fù)一個帶著新的接收窗口大小的確認(rèn)包。一般ZWP包會設(shè)置成3次害驹，如果3次過后還是0的話鞭呕，有的TCP實現(xiàn)就會發(fā)RST把鏈接斷了。
如果接收方以很小的增量來處理到來的數(shù)據(jù)裙秋，它會發(fā)布一系列小的接收窗口琅拌。這被稱作愚蠢窗口綜合癥，因為它在TCP的數(shù)據(jù)包中發(fā)送很少的一些字節(jié)摘刑，相對于TCP包頭是很大的開銷进宝。解決這個問題，就要避免對小的window size做出響應(yīng)枷恕，直到有足夠大的window size再響應(yīng)：
- 接收端使用David D Clark算法：如果收到的數(shù)據(jù)導(dǎo)致window size小于某個值党晋，可以直接ack把window給關(guān)閉了，阻止了發(fā)送端再發(fā)數(shù)據(jù)徐块。等到接收端處理了一些數(shù)據(jù)后windows size大于等于了MSS未玻，或者接收端buffer有一半為空，就可以把window打開讓發(fā)送端再發(fā)數(shù)據(jù)過來胡控。
- 發(fā)送端使用Nagle算法來延時處理扳剿，條件一：Window Size>=MSS 或是 Data Size >=MSS；條件二：等待時間或是超時200ms昼激，這兩個條件有一個滿足庇绽，才會發(fā)數(shù)據(jù)，否則就是在積累數(shù)據(jù)橙困。Nagle算法默認(rèn)是打開的瞧掺，所以對于一些需要小包場景的程序——比如像telnet或ssh這樣的交互性程序，需要關(guān)閉這個算法凡傅”俦罚可以在Socket設(shè)置TCP_NODELAY選項來關(guān)閉這個算法。
擁塞控制[編輯]
擁塞控制是發(fā)送方根據(jù)網(wǎng)絡(luò)的承載情況控制分組的發(fā)送量夏跷，以獲取高性能又能避免擁塞崩潰（congestion collapse哼转，網(wǎng)絡(luò)性能下降幾個數(shù)量級）。這在網(wǎng)絡(luò)流之間產(chǎn)生近似最大最小公平分配拓春。
發(fā)送方與接收方根據(jù)確認(rèn)包或者包丟失的情況释簿，以及定時器，估計網(wǎng)絡(luò)擁塞情況硼莽，從而修改數(shù)據(jù)流的行為庶溶，這稱為擁塞控制或網(wǎng)絡(luò)擁塞避免。
TCP的現(xiàn)代實現(xiàn)包含四種相互影響的擁塞控制算法：慢開始懂鸵、擁塞避免偏螺、快速重傳、快速恢復(fù)匆光。
此外套像，發(fā)送方采取“超時重傳”（retransmission timeout，RTO）终息，這是估計出來回通信延遲 (RTT) 以及RTT的方差夺巩。
RFC793中定義的計算SRTT的經(jīng)典算法：指數(shù)加權(quán)移動平均（Exponential weighted moving average）
- 先采樣RTT贞让，記下最近好幾次的RTT值。
- 做平滑計算SRTT公式為：[圖片上傳失敗...(image-ced961-1570713099374)] 柳譬，其中 α 取值在0.8 到 0.9之間
- 計算RTO喳张，公式：[圖片上傳失敗...(image-3a9b94-1570713099374)] ，其中 UBOUND是最大的timeout時間上限值美澳，LBOUND是最小的timeout時間下限值销部，β值一般在1.3到2.0之間。
1987年制跟，出現(xiàn)計算RTT的Karn算法或TCP時間戳（RFC 1323）舅桩，最大特點是——忽略重傳，不把重傳的RTT做采樣雨膨。但是擂涛，如果在某一時間，網(wǎng)絡(luò)閃動哥放，突然變慢了歼指，產(chǎn)生了比較大的延時，這個延時導(dǎo)致要重轉(zhuǎn)所有的包（因為之前的RTO很猩瘛）踩身，于是，因為重轉(zhuǎn)的不算社露，所以挟阻，RTO就不會被更新，這是一個災(zāi)難峭弟。為此附鸽，Karn算法一發(fā)生重傳，就對現(xiàn)有的RTO值翻倍瞒瘸。這就是的Exponential backoff坷备。
1988年，在RFC 6298中給出范·雅各布森算法取平均以獲得平滑往返時延（Smoothed Round Trip Time情臭，SRTT）省撑，作為最終的RTT估計值。這個算法在被用在今天的TCP協(xié)議中：
[圖片上傳失敗...(image-5ff28c-1570713099377)] [圖片上傳失敗...(image-dcebd6-1570713099377)] [圖片上傳失敗...(image-4dcedc-1570713099377)]
其中：DevRTT是Deviation RTT俯在。在Linux下竟秫，α = 0.125，β = 0.25跷乐， μ = 1肥败，?= 4
當(dāng)前有很多TCP擁塞控制算法在研究中。
最大分段大小[編輯]
最大分段大小 (MSS)是在單個分段中TCP愿意接受的數(shù)據(jù)的字節(jié)數(shù)最大值。MSS應(yīng)當(dāng)足夠小以避免IP分片馒稍，它會導(dǎo)致丟包或過多的重傳皿哨。在TCP連接創(chuàng)建時，雙端在SYN報文中用MSS選項宣布各自的MSS纽谒，這是從雙端各自直接相連的數(shù)據(jù)鏈路層的最大傳輸單元(MTU)的尺寸減去固定的IP首部和TCP首部長度往史。以太網(wǎng)MTU為1500字節(jié)， MSS值可達(dá)1460字節(jié)佛舱。使用IEEE 802.3的MTU為1492字節(jié)，MSS可達(dá)1452字節(jié)挨决。如果目的IP地址為“非本地的”请祖，MSS通常的默認(rèn)值為536（這個默認(rèn)值允許20字節(jié)的IP首部和20字節(jié)的TCP首部以適合576字節(jié)IP數(shù)據(jù)報）。此外脖祈，發(fā)送方可用傳輸路徑MTU發(fā)現(xiàn)（RFC 1191見RFC 1191）推導(dǎo)出從發(fā)送方到接收方的網(wǎng)絡(luò)路徑上的最小MTU肆捕，以此動態(tài)調(diào)整MSS以避免網(wǎng)絡(luò)IP分片。
MSS發(fā)布也被稱作“MSS協(xié)商”（MSS negotiation）盖高。嚴(yán)格講慎陵，這并非是協(xié)商出來一個統(tǒng)一的MSS值，TCP允許連接兩端使用各自不同的MSS值喻奥。[7] 例如席纽，這會發(fā)生在參與TCP連接的一臺設(shè)備使用非常少的內(nèi)存處理到來的TCP分組。
選擇確認(rèn)[編輯]
最初采取累計確認(rèn)的TCP協(xié)議在丟包時效率很低撞蚕。例如润梯，假設(shè)通過10個分組發(fā)出了1萬個字節(jié)的數(shù)據(jù)。如果第一個分組丟失甥厦，在純粹的累計確認(rèn)協(xié)議下纺铭，接收方不能說它成功收到了1,000到9,999字節(jié)，但未收到包含0到999字節(jié)的第一個分組刀疙。因而舶赔，發(fā)送方可能必須重傳所有1萬個字節(jié)。
為此谦秧，TCP采取了“選擇確認(rèn)”（selective acknowledgment竟纳，SACK）選項。RFC 2018對此定義為允許接收方確認(rèn)它成功收到的分組的不連續(xù)的塊油够，以及基礎(chǔ)TCP確認(rèn)的成功收到最后連續(xù)字節(jié)序號蚁袭。這種確認(rèn)可以指出SACK block，包含了已經(jīng)成功收到的連續(xù)范圍的開始與結(jié)束字節(jié)序號石咬。在上述例子中揩悄，接收方可以發(fā)出SACK指出序號1000到9999，發(fā)送方因此知道只需重發(fā)第一個分組(字節(jié) 0 到 999)鬼悠。
TCP發(fā)送方會把亂序收包當(dāng)作丟包删性，因此會重傳亂序收到的包亏娜，導(dǎo)致連接的性能下降。重復(fù)SACK選項（duplicate-SACK option）是定義在RFC 2883中的SACK的一項擴展蹬挺，可解決這一問題维贺。接收方發(fā)出D-ACK指出沒有丟包，接收方恢復(fù)到高傳輸率巴帮。D-SACK使用了SACK的第一個段來做標(biāo)志溯泣，
- 如果SACK的第一個段的范圍被ACK所覆蓋，那么就是D-SACK;
- 如果SACK的第一個段的范圍被SACK的第二個段覆蓋榕茧，那么就是D-SACK
D-SACK旨在告訴發(fā)送端：收到了重復(fù)的數(shù)據(jù)垃沦，數(shù)據(jù)包沒有丟，丟的是ACK包用押；或者“Fast Retransmit算法”觸發(fā)的重傳不是因為發(fā)出去的包丟了肢簿，也不是因為回應(yīng)的ACK包丟了，而是因為網(wǎng)絡(luò)延時導(dǎo)致的reordering蜻拨。
SACK選項并不是強制的池充。僅當(dāng)雙端都支持時才會被使用。TCP連接創(chuàng)建時會在TCP頭中協(xié)商SACK細(xì)節(jié)缎讼。在 Linux下收夸，可以通過tcp_sack參數(shù)打開SACK功能（Linux 2.4后默認(rèn)打開）。Linux下的tcp_dsack參數(shù)用于開啟D-SACK功能（Linux 2.4后默認(rèn)打開）血崭。選擇確認(rèn)也用于流控制傳輸協(xié)議 (SCTP).
TCP窗口縮放選項[編輯]
TCP窗口尺寸域控制數(shù)據(jù)包在2至65,535字節(jié)咱圆。RFC 1323定義的TCP窗口縮放選項用于把最大窗口尺寸從65,535字節(jié)擴大至1G字節(jié)。擴大窗口尺寸是TCP優(yōu)化的需要功氨。
窗口縮放選項盡在TCP三次握手時雙端在SYN包中獨立指出這個方向的縮放系數(shù)序苏。該值是16比特窗口尺寸的向左位移數(shù)，從0 (表示不位移)至14捷凄。
某些路由器或分組防火墻會重寫窗口縮放選項忱详，這可能導(dǎo)致不穩(wěn)定的網(wǎng)絡(luò)傳輸。[8]
TCP時間戳[編輯]
RFC 1323定義了TCP時間戳跺涤，并不對應(yīng)于系統(tǒng)時鐘匈睁，使用隨機值初始化。許多操作系統(tǒng)每毫秒增加一次時間戳桶错；但RFC只規(guī)定tick應(yīng)當(dāng)成比例航唆。
有兩個時間戳域:
<dl style="margin-top: 0.2em; margin-bottom: 0.5em;">
<dd style="margin-left: 1.6em; margin-bottom: 0.1em; margin-right: 0px;">4字節(jié)的發(fā)送時間戳值</dd>
<dd style="margin-left: 1.6em; margin-bottom: 0.1em; margin-right: 0px;">4字節(jié)的響應(yīng)回復(fù)時間戳值（最近收到數(shù)據(jù)的時間戳）</dd>
</dl>
TCP時間戳用于“防止序列號回繞算法”（Protection Against Wrapped Sequence numbers，PAWS）院刁，細(xì)節(jié)見RFC 1323糯钙。PAWS用于接收窗口跨序號回繞邊界。這種情形下一個包可能會重傳以回答問題：“是否是第一個還是第二個4 GB的序號？”時間戳可以打破這一問題任岸。
另外再榄，Eifel檢測算法(RFC 3522)使用TCP時間戳確定如果重傳發(fā)生是因為丟包還是簡單亂序。
最近統(tǒng)計表明時間戳的采用率停滯在~40%享潜，這歸因于Windows服務(wù)器從Windows Server 2008起降低了支持困鸥。[9].
帶外數(shù)據(jù)[編輯]
帶外數(shù)據(jù)（OOB）是指對緊急數(shù)據(jù)，中斷或放棄排隊中的數(shù)據(jù)流剑按；接收方應(yīng)立即處理緊急數(shù)據(jù)疾就。完成后，TCP通知應(yīng)用程序恢復(fù)流隊列的正常處理艺蝴。
OOB并不影響網(wǎng)絡(luò)虐译，“緊急”僅影響遠(yuǎn)程端的處理。這一協(xié)議很少被實現(xiàn)吴趴。[10][11]
強制數(shù)據(jù)遞交[編輯]
正常情況下，TCP等待200 ms以準(zhǔn)備一個完整分組發(fā)出（納格算法試圖把小的信息組裝為單一的包）侮攀。這產(chǎn)生了小的锣枝、但潛在很嚴(yán)重的延遲并在傳遞一個文件時不斷重復(fù)延遲。例如兰英，典型發(fā)送塊是4 KB撇叁，典型的MSS是1460字節(jié)，在10 Mbit/s以太網(wǎng)上發(fā)出兩個包畦贸，每個耗時約~1.2 ms陨闹，隨后是剩余1176個字節(jié)的包，之后是197 ms停頓因為TCP等待裝滿緩沖區(qū)薄坏。
對于telnet趋厉，每次用戶擊鍵的回應(yīng)，如果有200 ms將會非常煩人胶坠。
socket選項TCP_NODELAY能放棄默認(rèn)的200 ms發(fā)送延遲君账。應(yīng)用程序使用這個socket選項強制發(fā)出數(shù)據(jù)。
RFC定義了PSH能立即發(fā)出比特沈善。Berkeley套接字不能控制或指出這種情形乡数，只能由協(xié)議棧控制。[12]
終結(jié)通路[編輯]
TCP連接的正常終止
連接終止
連接終止使用了四路握手過程（或稱四次握手闻牡，four-way handshake）净赴，在這個過程中連接的每一側(cè)都獨立地被終止。當(dāng)一個端點要停止它這一側(cè)的連接罩润，就向?qū)?cè)發(fā)送FIN玖翅，對側(cè)回復(fù)ACK表示確認(rèn)。因此，拆掉一側(cè)的連接過程需要一對FIN和ACK烧栋，分別由兩側(cè)端點發(fā)出写妥。
首先發(fā)出FIN的一側(cè)，如果給對側(cè)的FIN響應(yīng)了ACK审姓，那么就會超時等待2*MSL時間珍特，然后關(guān)閉連接。在這段超時等待時間內(nèi)魔吐，本地的端口不能被新連接使用扎筒；避免延時的包的到達(dá)與隨后的新連接相混淆。RFC793定義了MSL為2分鐘酬姆，Linux設(shè)置成了30s嗜桌。參數(shù)tcp_max_tw_buckets控制并發(fā)的TIME_WAIT的數(shù)量，默認(rèn)值是180000辞色，如果超限骨宠，那么，系統(tǒng)會把多的TIME_WAIT狀態(tài)的連接給destory掉相满，然后在日志里打一個警告（如：time wait bucket table overflow）
連接可以工作在TCP半開狀態(tài)层亿。即一側(cè)關(guān)閉了連接，不再發(fā)送數(shù)據(jù)立美；但另一側(cè)沒有關(guān)閉連接匿又，仍可以發(fā)送數(shù)據(jù)。已關(guān)閉的一側(cè)仍然應(yīng)接收數(shù)據(jù)建蹄，直至對側(cè)也關(guān)閉了連接碌更。
也可以通過測三次握手關(guān)閉連接。主機A發(fā)出FIN洞慎，主機B回復(fù)FIN & ACK痛单，然后主機A回復(fù)ACK.[13]
一些主機（如Linux或HP-UX）的TCP棧能實現(xiàn)半雙工關(guān)閉序列。這種主機如果主動關(guān)閉一個連接但還沒有讀完從這個連接已經(jīng)收到的數(shù)據(jù)劲腿，該主機發(fā)送RST代替FIN[14]桦他。這使得一個TCP應(yīng)用程序能確認(rèn)遠(yuǎn)程應(yīng)用程序已經(jīng)讀了所有已發(fā)送數(shù)據(jù)，并等待遠(yuǎn)程側(cè)發(fā)出的FIN谆棱。但是遠(yuǎn)程的TCP棧不能區(qū)分Connection Aborting RST與Data Loss RST快压，兩種原因都會導(dǎo)致遠(yuǎn)程的TCP棧失去所有的收到數(shù)據(jù)。
一些應(yīng)用協(xié)議使用TCP open/close handshaking垃瞧，因為應(yīng)用協(xié)議的TCP open/close handshaking可以發(fā)現(xiàn)主動關(guān)閉的RST問題蔫劣。例如：
<pre style="font-family: monospace, monospace; color: rgb(0, 0, 0); background-color: rgb(248, 249, 250); border: 1px solid rgb(234, 236, 240); padding: 1em; white-space: pre-wrap; line-height: 1.3;">s = connect(remote);
send(s, data);
close(s);
</pre>
TCP/IP棧采用上述方法不能保證所有數(shù)據(jù)到達(dá)對側(cè)，如果未讀數(shù)據(jù)已經(jīng)到達(dá)對側(cè)个从。
狀態(tài)編碼[編輯]
下表為TCP狀態(tài)碼列表脉幢，以S指代服務(wù)器歪沃，C指代客戶端，S&C表示兩者嫌松，S/C表示兩者之一：[15]
<dl style="margin-top: 0.2em; margin-bottom: 0.5em;">
<dt style="font-weight: bold; margin-bottom: 0.1em;">LISTEN S</dt>
<dd style="margin-left: 1.6em; margin-bottom: 0.1em; margin-right: 0px;">服務(wù)器等待從任意遠(yuǎn)程TCP端口的連接請求沪曙。偵聽狀態(tài)。</dd>
<dt style="font-weight: bold; margin-bottom: 0.1em;">SYN-SENT C</dt>
<dd style="margin-left: 1.6em; margin-bottom: 0.1em; margin-right: 0px;">客戶在發(fā)送連接請求后等待匹配的連接請求萎羔。通過connect()函數(shù)向服務(wù)器發(fā)出一個同步（SYNC）信號后進(jìn)入此狀態(tài)液走。</dd>
<dt style="font-weight: bold; margin-bottom: 0.1em;">SYN-RECEIVED S</dt>
<dd style="margin-left: 1.6em; margin-bottom: 0.1em; margin-right: 0px;">服務(wù)器已經(jīng)收到并發(fā)送同步（SYNC）信號之后等待確認(rèn)（ACK）請求。</dd>
<dt style="font-weight: bold; margin-bottom: 0.1em;">ESTABLISHED S&C</dt>
<dd style="margin-left: 1.6em; margin-bottom: 0.1em; margin-right: 0px;">服務(wù)器與客戶的連接已經(jīng)打開贾陷，收到的數(shù)據(jù)可以發(fā)送給用戶缘眶。數(shù)據(jù)傳輸步驟的正常情況。此時連接兩端是平等的髓废。這稱作全連接巷懈。</dd>
<dt style="font-weight: bold; margin-bottom: 0.1em;">FIN-WAIT-1 S&C</dt>
<dd style="margin-left: 1.6em; margin-bottom: 0.1em; margin-right: 0px;">（服務(wù)器或客戶）主動關(guān)閉端調(diào)用close（）函數(shù)發(fā)出FIN請求包，表示本方的數(shù)據(jù)發(fā)送全部結(jié)束慌洪，等待TCP連接另一端的ACK確認(rèn)包或FIN&ACK請求包顶燕。</dd>
<dt style="font-weight: bold; margin-bottom: 0.1em;">FIN-WAIT-2 S&C</dt>
<dd style="margin-left: 1.6em; margin-bottom: 0.1em; margin-right: 0px;">主動關(guān)閉端在FIN-WAIT-1狀態(tài)下收到ACK確認(rèn)包，進(jìn)入等待遠(yuǎn)程TCP的連接終止請求的半關(guān)閉狀態(tài)冈爹。這時可以接收數(shù)據(jù)涌攻，但不再發(fā)送數(shù)據(jù)。</dd>
<dt style="font-weight: bold; margin-bottom: 0.1em;">CLOSE-WAIT S&C</dt>
<dd style="margin-left: 1.6em; margin-bottom: 0.1em; margin-right: 0px;">被動關(guān)閉端接到FIN后犯助，就發(fā)出ACK以回應(yīng)FIN請求，并進(jìn)入等待本地用戶的連接終止請求的半關(guān)閉狀態(tài)维咸。這時可以發(fā)送數(shù)據(jù)剂买，但不再接收數(shù)據(jù)。</dd>
<dt style="font-weight: bold; margin-bottom: 0.1em;">CLOSING S&C</dt>
<dd style="margin-left: 1.6em; margin-bottom: 0.1em; margin-right: 0px;">在發(fā)出FIN后癌蓖，又收到對方發(fā)來的FIN后瞬哼，進(jìn)入等待對方對己方的連接終止（FIN）的確認(rèn)（ACK）的狀態(tài)。少見租副。</dd>
<dt style="font-weight: bold; margin-bottom: 0.1em;">LAST-ACK S&C</dt>
<dd style="margin-left: 1.6em; margin-bottom: 0.1em; margin-right: 0px;">被動關(guān)閉端全部數(shù)據(jù)發(fā)送完成之后坐慰，向主動關(guān)閉端發(fā)送FIN，進(jìn)入等待確認(rèn)包的狀態(tài)用僧。</dd>
<dt style="font-weight: bold; margin-bottom: 0.1em;">TIME-WAIT S/C</dt>
<dd style="margin-left: 1.6em; margin-bottom: 0.1em; margin-right: 0px;">主動關(guān)閉端接收到FIN后结胀，就發(fā)送ACK包，等待足夠時間以確保被動關(guān)閉端收到了終止請求的確認(rèn)包责循≡愀郏【按照RFC 793，一個連接可以在TIME-WAIT保證最大四分鐘院仿，即最大分段壽命（maximum segment lifetime）的2倍】</dd>
<dt style="font-weight: bold; margin-bottom: 0.1em;">CLOSED S&C</dt>
<dd style="margin-left: 1.6em; margin-bottom: 0.1em; margin-right: 0px;">完全沒有連接秸抚。</dd>
</dl>
端口[編輯]
TCP使用了通信端口（Port number）的概念來標(biāo)識發(fā)送方和接收方的應(yīng)用層速和。對每個TCP連接的一端都有一個相關(guān)的16位的無符號端口號分配給它們。端口被分為三類：眾所周知的剥汤、注冊的和動態(tài)/私有的颠放。眾所周知的端口號是由因特網(wǎng)賦號管理局（IANA）來分配的，并且通常被用于系統(tǒng)一級或根進(jìn)程吭敢。眾所周知的應(yīng)用程序作為服務(wù)器程序來運行碰凶，并被動地偵聽經(jīng)常使用這些端口的連接。例如：FTP省有、TELNET痒留、SMTP、HTTP等蠢沿。注冊的端口號通常被用來作為終端用戶連接服務(wù)器時短暫地使用的源端口號伸头，但它們也可以用來標(biāo)識已被第三方注冊了的、被命名的服務(wù)舷蟀。動態(tài)/私有的端口號在任何特定的TCP連接外不具有任何意義恤磷。可能的野宜、被正式承認(rèn)的端口號有65535個扫步。
數(shù)據(jù)包結(jié)構(gòu)[編輯]
<caption style="font-weight: bold;">TCP表頭</caption>
| 偏移 | 字節(jié) | 0 | 1 | 2 | 3 |
| 字節(jié) | <tt style="font-family: monospace, monospace;">比特</tt> | <tt style="font-family: monospace, monospace;"> 0</tt> | <tt style="font-family: monospace, monospace;"> 1</tt> | <tt style="font-family: monospace, monospace;"> 2</tt> | <tt style="font-family: monospace, monospace;"> 3</tt> | <tt style="font-family: monospace, monospace;"> 4</tt> | <tt style="font-family: monospace, monospace;"> 5</tt> | <tt style="font-family: monospace, monospace;"> 6</tt> | <tt style="font-family: monospace, monospace;"> 7</tt> | <tt style="font-family: monospace, monospace;"> 8</tt> | <tt style="font-family: monospace, monospace;"> 9</tt> | <tt style="font-family: monospace, monospace;">10</tt> | <tt style="font-family: monospace, monospace;">11</tt> | <tt style="font-family: monospace, monospace;">12</tt> | <tt style="font-family: monospace, monospace;">13</tt> | <tt style="font-family: monospace, monospace;">14</tt> | <tt style="font-family: monospace, monospace;">15</tt> | <tt style="font-family: monospace, monospace;">16</tt> | <tt style="font-family: monospace, monospace;">17</tt> | <tt style="font-family: monospace, monospace;">18</tt> | <tt style="font-family: monospace, monospace;">19</tt> | <tt style="font-family: monospace, monospace;">20</tt> | <tt style="font-family: monospace, monospace;">21</tt> | <tt style="font-family: monospace, monospace;">22</tt> | <tt style="font-family: monospace, monospace;">23</tt> | <tt style="font-family: monospace, monospace;">24</tt> | <tt style="font-family: monospace, monospace;">25</tt> | <tt style="font-family: monospace, monospace;">26</tt> | <tt style="font-family: monospace, monospace;">27</tt> | <tt style="font-family: monospace, monospace;">28</tt> | <tt style="font-family: monospace, monospace;">29</tt> | <tt style="font-family: monospace, monospace;">30</tt> | <tt style="font-family: monospace, monospace;">31</tt> |
| 0 | <tt style="font-family: monospace, monospace;">0</tt> | 來源連接端口 | 目的連接端口 |
| 4 | <tt style="font-family: monospace, monospace;">32</tt> | 序列號碼 |
| 8 | <tt style="font-family: monospace, monospace;">64</tt> | 確認(rèn)號碼（當(dāng)<tt style="font-family: monospace, monospace;">ACK</tt>設(shè)置） |
| 12 | <tt style="font-family: monospace, monospace;">96</tt> | 數(shù)據(jù)偏移 | 保留
<tt style="font-family: monospace, monospace;">0 0 0</tt> | <tt style="font-family: monospace, monospace;">N
S</tt> | <tt style="font-family: monospace, monospace;">C
W
R</tt> | <tt style="font-family: monospace, monospace;">E
C
E</tt> | <tt style="font-family: monospace, monospace;">U
R
G</tt> | <tt style="font-family: monospace, monospace;">A
C
K</tt> | <tt style="font-family: monospace, monospace;">P
S
H</tt> | <tt style="font-family: monospace, monospace;">R
S
T</tt> | <tt style="font-family: monospace, monospace;">S
Y
N</tt> | <tt style="font-family: monospace, monospace;">F
I
N</tt> | 窗口大小 |
| 16 | <tt style="font-family: monospace, monospace;">128</tt> | 校驗和 | 緊急指針（當(dāng)<tt style="font-family: monospace, monospace;">URG</tt>設(shè)置） |
| 20
... | <tt style="font-family: monospace, monospace;">160
...</tt> | 選項（如果數(shù)據(jù)偏移 > 5。需要在結(jié)尾添加0匈子。
... |
- 來源連接端口（16位長）－識別發(fā)送連接端口
- 目的連接端口（16位長）－識別接收連接端口
- 序列號（seq河胎，32位長）
- 如果含有同步化旗標(biāo)（SYN），則此為最初的序列號虎敦；第一個數(shù)據(jù)比特的序列碼為本序列號加一游岳。
- 如果沒有同步化旗標(biāo)（SYN），則此為第一個數(shù)據(jù)比特的序列碼其徙。
- 確認(rèn)號（ack胚迫，32位長）—期望收到的數(shù)據(jù)的開始序列號。也即已經(jīng)收到的數(shù)據(jù)的字節(jié)長度加1唾那。
- 數(shù)據(jù)偏移（4位長）—以4字節(jié)為單位計算出的數(shù)據(jù)段開始地址的偏移值访锻。
- 保留（3比特長）—須置0
- 標(biāo)志符（9比特長）
- NS—ECN-nonce。
- CWR—Congestion Window Reduced闹获。
- ECE—ECN-Echo有兩種意思期犬，取決于SYN標(biāo)志的值。
- URG—為1表示高優(yōu)先級數(shù)據(jù)包避诽，緊急指針字段有效哭懈。
- ACK—為1表示確認(rèn)號字段有效
- PSH—為1表示是帶有PUSH標(biāo)志的數(shù)據(jù)，指示接收方應(yīng)該盡快將這個報文段交給應(yīng)用層而不用等待緩沖區(qū)裝滿茎用。
- RST—為1表示出現(xiàn)嚴(yán)重差錯遣总〔锹蓿可能需要重新創(chuàng)建TCP連接。還可以用于拒絕非法的報文段和拒絕連接請求旭斥。
- SYN—為1表示這是連接請求或是連接接受請求容达，用于創(chuàng)建連接和使順序號同步
- FIN—為1表示發(fā)送方?jīng)]有數(shù)據(jù)要傳輸了，要求釋放連接垂券。
- 窗口（WIN花盐，16位長）—表示從確認(rèn)號開始，本報文的發(fā)送方可以接收的字節(jié)數(shù)菇爪，即接收窗口大小算芯。用于流量控制。
- 校驗和（Checksum凳宙，16位長）—對整個的TCP報文段熙揍，包括TCP頭部和TCP數(shù)據(jù)，以16位字進(jìn)行計算所得氏涩。這是一個強制性的字段届囚。
- 緊急指針（16位長）—本報文段中的緊急數(shù)據(jù)的最后一個字節(jié)的序號。
- 選項字段—最多40字節(jié)是尖。每個選項的開始是1字節(jié)的kind字段意系，說明選項的類型。
- 0：選項表結(jié)束（1字節(jié)）
- 1：無操作（1字節(jié)）用于選項字段之間的字邊界對齊饺汹。
- 2：最大報文段長度（4字節(jié)蛔添，Maximum Segment Size，MSS）通常在創(chuàng)建連接而設(shè)置SYN標(biāo)志的數(shù)據(jù)包中指明這個選項兜辞，指明本端所能接收的最大長度的報文段迎瞧。通常將MSS設(shè)置為（MTU-40）字節(jié)，攜帶TCP報文段的IP數(shù)據(jù)報的長度就不會超過MTU（MTU最大長度為1518字節(jié)弦疮，最短為64字節(jié)）夹攒，從而避免本機發(fā)生IP分片蜘醋。只能出現(xiàn)在同步報文段中胁塞，否則將被忽略。
- 3：窗口擴大因子（4字節(jié)压语，wscale）啸罢，取值0-14。用來把TCP的窗口的值左移的位數(shù)胎食，使窗口值乘倍扰才。只能出現(xiàn)在同步報文段中，否則將被忽略厕怜。這是因為現(xiàn)在的TCP接收數(shù)據(jù)緩沖區(qū)（接收窗口）的長度通常大于65535字節(jié)衩匣。
- 4：sackOK—發(fā)送端支持并同意使用SACK選項蕾总。
- 5：SACK實際工作的選項。
- 8：時間戳（10字節(jié)琅捏，TCP Timestamps Option生百，TSopt）
- 發(fā)送端的時間戳（Timestamp Value field，TSval柄延，4字節(jié)）
- 時間戳回顯應(yīng)答（Timestamp Echo Reply field蚀浆，TSecr，4字節(jié)）
發(fā)展過程[編輯]
TCP是一個復(fù)雜的但同時又是在發(fā)展之中的協(xié)議搜吧。盡管許多重要的改進(jìn)被提出和實施，發(fā)表于1981年的RFC793中說明的TCP（TCP-Tahoe）的許多基本操作還是未作多大改動。RFC1122：《因特網(wǎng)對主機的要求》闡明了許多TCP協(xié)議的實現(xiàn)要求刽宪。RFC2581：《TCP的擁塞控制》是一篇近年來關(guān)于TCP的很重要的RFC顿苇，描述了更新后的避免過度擁塞的算法。寫于2001年的RFC3168描述了對明顯擁塞的報告僵刮，這是一種擁塞避免的信號量機制据忘。在21世紀(jì)早期，在所有因特網(wǎng)的數(shù)據(jù)包中搞糕，通常有大約95%的包使用了TCP協(xié)議勇吊。常見的使用TCP的應(yīng)用層有HTTP/HTTPS（萬維網(wǎng)協(xié)議），SMTP/POP3/IMAP（電子郵件協(xié)議）以及FTP（文件傳輸協(xié)議）窍仰。這些協(xié)議在今天被廣泛地使用汉规，這證明了它們的原作者的創(chuàng)造是卓越的。
最近驹吮，一個新協(xié)議已經(jīng)被加州理工學(xué)院的科研人員開發(fā)出來针史，命名為FAST TCP（基于快速活動隊列管理的規(guī)模可變的傳輸控制協(xié)議）碟狞。它使用排隊延遲作為擁塞控制信號啄枕；但是因為端到端的延遲通常不僅僅包括排隊延遲，所以FAST TCP（或更一般地族沃，所有基于排隊延遲的算法）在實際互聯(lián)網(wǎng)中的能否工作仍然是一個沒有解決的問題频祝。
應(yīng)用[編輯]
TCP并不是對所有的應(yīng)用都適合，一些新的帶有一些內(nèi)在的脆弱性的運輸層協(xié)議也被設(shè)計出來脆淹。比如常空，實時應(yīng)用并不需要甚至無法忍受TCP的可靠傳輸機制。在這種類型的應(yīng)用中盖溺，通常允許一些丟包漓糙、出錯或擁塞，而不是去校正它們烘嘱。例如通常不使用TCP的應(yīng)用有：實時流多媒體（如因特網(wǎng)廣播）昆禽、實時多媒體播放器和游戲蝗蛙、IP電話（VoIP）等等。任何不是很需要可靠性或者是想將功能減到最少的應(yīng)用可以避免使用TCP醉鳖。在很多情況下歼郭，當(dāng)只需要多路復(fù)用應(yīng)用服務(wù)時，用戶數(shù)據(jù)報協(xié)議（UDP）可以代替TCP為應(yīng)用提供服務(wù)辐棒。
參見[編輯]
參考資料[編輯]
- Timothy S. Ramteke: Networks, Second Edition., Prentice-Hall 2001, ISBN 0-13-901265-6
- Torsten Braun , Martina Zitterbart: *Hochleistungskommunikation, Bd.2, Transportdienste und Transportprotokolle *, Oldenbourg 1996, ISBN 978-3-486-23088-8
- ^ RFC 793 Section 3.2
- ^ [http://www.man7.org/linux/man-pages/man7/ip.7.html “ip - Linux IPv4 protocol implementation” in 《Linux Programmer's Manual》： IP_BIND_ADDRESS_NO_PORT (since Linux 4.2) Inform the kernel to not reserve an ephemeral port when using bind(2) with a port number of 0. The port will later be auto‐ matically chosen at connect(2) time, in a way that allows sharing a source port as long as the 4-tuple is unique. ]
- ^ <cite class="citation web" style="font-style: normal;">TCP Definition. [2011-03-12].</cite>
- ^ <cite class="citation journal" style="font-style: normal;">Mathis; Mathew; Semke; Mahdavi; Ott. The macroscopic behavior of the TCP congestion avoidance algorithm. ACM SIGCOMM Computer Communication Review. 1997, 27.3: 67–82.</cite>
- ^ Paxson, V.; Allman, M.; Chu, J.; Sargent, M.. The Basic Algorithm. Computing TCP's Retransmission Timer. IETF. June 2011: p. 2. sec. 2 [October 24, 2015]. RFC 6298.
- ^ <cite class="citation journal" style="font-style: normal;">Stone; Partridge. When The CRC and TCP Checksum Disagree. Sigcomm. 2000.</cite>
- ^ <cite class="citation web" style="font-style: normal;">RFC 879.</cite>
- ^ <cite class="citation web" style="font-style: normal;">TCP window scaling and broken routers [LWN.net].</cite>
- ^ <cite class="citation web" style="font-style: normal;">David Murray; Terry Koziniec; Sebastian Zander; Michael Dixon; Polychronis Koutsakis. An Analysis of Changing Enterprise Network Traffic Characteristics (PDF). The 23rd Asia-Pacific Conference on Communications (APCC 2017). 2017 [3 October 2017].</cite>
- ^ <cite class="citation web" style="font-style: normal;">Gont, Fernando. On the implementation of TCP urgent data. 73rd IETF meeting. November 2008 [2009-01-04].</cite>
- ^ <cite class="citation book" style="font-style: normal;">Peterson, Larry. Computer Networks. Morgan Kaufmann. 2003: 401. ISBN 1-55860-832-X.</cite>
-
^ <cite class="citation book" style="font-style: normal;">Richard W. Stevens. November 2011 TCP/IP Illustrated. Vol. 1, The protocols 請檢查
|url=值 (幫助). Addison-Wesley. 2006: Chapter 20. ISBN 978-0-201-63346-7.</cite> - ^ <cite class="citation book" style="font-style: normal;">Tanenbaum, Andrew S. Computer Networks Fourth. Prentice Hall. 2003-03-17. ISBN 0-13-066102-3.</cite>
- ^ Section 4.2.2.13 in RFC 1122
- ^ RFC 793 Section 3.2
外部鏈接[編輯]
分類：
