◎連結導向簡介（傳輸控制協議）
連結導向（Transmission Control Protocol，TCP）是一種面向連接的、可靠的、基於位元組流的運輸層通信協議。在電腦網路OSI模型中，它完成傳輸層所指定的功能。TCP層是位於IP層之上，應用層之下的中間層。不同主機的應用層之間經常需要可靠的、像管道一樣的連接，但是IP層不提供這樣的流機制，而是提供不可靠的包交換。
應用層向TCP層發送用於網間傳輸的、用8位位元組表示的數據流，然後TCP把數據流分割成適當長度的報文段（通常受該電腦連接的網路的數據鏈路層的最大傳送單元(MTU)的限制）。之後TCP把結果包傳給IP層，由它來通過網路將包傳送給接收端實體的TCP層。TCP為了保證不發生丟包，就給每個位元組一個序號，同時序號也保證了傳送到接收端實體的包的按序接收。然後接收端實體對已成功收到的位元組發回一個相應的確認(ACK)；如果發送端實體在合理的往返時延(RTT)內未收到確認，那麼對應的數據（假設丟失了）將會被重傳。TCP用一個校驗和函數來檢驗數據是否有錯誤；在發送和接收時都要計算校驗和（見最下方附註）。
TCP通路的建立和終結
TCP連接包括三個狀態：連接建立、數據傳送和連接終止。TCP用三路握手過程建立一個連接，用四路握手過程來拆除一個連接。在連接建立過程中，很多參數要被初始化，例如序號被初始化以保證按序傳輸和連接的強壯性。
連接建立（三路握手）
一對終端同時初始化一個它們之間的連接是可能的。但通常是由一端打開一個套接字(socket)然後監聽來自另一方的連接，這就是通常所指的被動打開。被動打開的一端就是伺服器端。而客戶端通過向伺服器端發送一個SYN來建立一個主動打開，作為三路握手的一部分。伺服器端應當為一個合法的SYN回送一個SYN/ACK。最後，客戶端再發送一個ACK。這樣就完成了三路握手併進入了連接建立狀態。
數據傳輸
在TCP的數據傳送狀態，很多重要的機制保證了TCP的可靠性和強壯性。它們包括：使用序號對收到的TCP報文段進行排序以及檢測重複的數據；使用校驗和來檢測報文段的錯誤；使用確認和計時器來檢測和糾正丟包或延時。
在TCP的連接建立狀態，兩個主機的TCP層間要交換初始序號 (ISN)。這些序號用於標識位元組流中的數據，並且還是對應用層的數據位元組進行記數的整數。通常在每個TCP報文段中都有一對序號和確認號。TCP報文發送者認為自己的位元組編號為序號，而認為接收者的位元組編號為確認號。TCP報文的接收者為了確保可靠性，在接收到一定數量的連續位元組流後才發送確認。這是對TCP的一種擴展，通常稱為選擇確認(SACK)。選擇確認使得TCP接收者可以對亂序到達的數據塊進行確認。
通過使用序號和確認號，TCP層可以把收到的報文段中的位元組按正確的順序交付給應用層。序號是32位的無符號數，在它增大到2321時便會迴繞到0。對於ISN的選擇是TCP中關鍵的一個操作，它可以確保強壯性和安全性。
數據發送者之間用對接收數據的確認或不予確認來顯式的表示TCP發送者和接收者之間的網路狀態。再加上計時器，TCP發送者和接收者就可以改變數據的流動情況。這就是通常所指的流量控制，擁塞控制/或擁塞避免。TCP使用大量的機制來同時獲得強壯性和高可靠性。這些機制包括：滑動窗口、慢啟動演算法、擁塞避免演算法、快速重啟和快速恢復演算法等等。對於TCP的可靠的丟包處理、錯誤最小化、擁塞管理以及高速運行環境等機制的優化的研究和標準制定，正在進行之中。
連接終止
連接終止狀態使用了四路握手過程，在這個過程中每個終端的連接都能獨立地被終止。因此，一個典型的拆接過程需要每個終端都提供一對FIN和ACK。
對TCP的選用情況
TCP並不是對所有的應用都適合，一些新的帶有一些內在的脆弱性的運輸層協議也被設計出來。比如，實時應用並不需要甚至無法忍受TCP的可靠傳輸機制。在這種類型的應用中，通常允許一些丟包、出錯或擁塞，而不是去校正它們。例如通常不使用TCP的應用有：實時流多媒體（如網際網路廣播）、實時多媒體播放器和遊戲、IP電話（VoIP）等等。任何不是很需要可靠性或者是想將功能減到最少的應用可以避免使用TCP。在很多情況下，當只需要多路復用應用服務時，用戶數據報協議（UDP）可以代替TCP為應用提供服務。
◎非連結導向簡介（用戶數據報協議）
非連結導向，亦稱用戶數據報協議 (User Datagram Protoco, UDP)是一個簡單的面向數據報的傳輸層(transport layer)協議，IETF RFC 768是UDP的正式規範。
在TCP/IP模型中，UDP為網路層下和應用層上提供了一個簡單的介面。UDP只提供數據的不可靠交付，它一旦把應用程序發給網路層的數據發送出去，就不保留數據備份（所以UDP有時候也被認為是不可靠的數據報協議）。UDP在IP數據報的頭部僅僅加入了復用和數據校驗（欄位）。
UDP首部欄位由4個部分組成，其中兩個是可選的。各16-bit的源埠和目的埠用來標記發送和接受的應用進程。因為UDP不需要應答，所以源埠是可選的，如果源埠不用，那麼置為零。在目的埠後面是長度固定的以位元組為單位的長度域，用來指定UDP數據報包括數據部分的長度,長度最小值為8 (octets)。首部剩下地16-bit是用來對首部和數據部分一起做校驗和的，這部分是可選的，但在實際應用中一般都使用這一功能。
由於缺乏可靠性，UDP應用一般必須允許一定量的丟包、出錯和複製。有些應用，比如TFTP，如果需要則必須在應用層增加根本的可靠機制。但是絕大多數UDP應用都不需要可靠機制，甚至可能因為引入可靠機制而降低性能。流媒體Streaming media、實時多媒體遊戲和voice over IP (VoIP)就是典型的UDP應用。如果某個應用需要很高的可靠性，那麼可以用傳輸控制協議Transmission Control Protocol來代替UDP。
由於缺乏擁塞避免和控制機制，需要基於網路的機制來減小因失控和高速UDP流量負荷而導致的擁塞崩潰效應。換句話說，因為UDP發送者不能夠檢測擁塞，所以像使用包隊列和丟棄技術的路由器這樣的網路基本設備往往就成為降低UDP過大通信量的有效工具。數據報擁塞控制協議Datagram Congestion Control Protocol (DCCP)設計成通過在諸如流媒體類型的高速率UDP流中增加主機擁塞控制來減小這個潛在的問題。
典型網路上的眾多使用UDP協議的關鍵應用一定程度上是相似的。這些應用包括域名系統Domain Name System (DNS)、簡單網路管理協議simple network management protocol (SNMP)、動態主機配置協議Dynamic host configuration protocol (DHCP)和路由信息協議Routing Information Protocol (RIP)等等。
◎連結導向與非連結導向之比較
TCP之連線過程較UDP複雜，但比UDP可靠。TCP可以防止資料的遺失，但是為了防止資料在傳輸時遺失，TCP在連線過程中顯得謹慎小心，其連線所花費之時間自然較UDP久。因此，如果資料的傳送順序不是特別重要，就算遺失某些封包也無所謂時，此時可以改用UDP協定來傳輸資料。UDP是個"不可靠"的協定，它不保證每個封包都能到達目的地，或是封包會以它們被送出的順序到達目的地，雖然這可能會影響到文字檔、或程式檔的傳輸，但如果是影像檔或聲音檔，只遺失部份影像或聲音訊號的少許位元，其實並不會對聲光效果有太大的影響，如果你使用TC P 協定去要求重傳遺失的資料，等待的時間反而會影響聲光效果。再者，我們也可以在應用層改善資料的編碼法，讓UDP資料流本身具備錯誤更正的能力，如此便可以大大減少遺失資料的影響。
◎參考資料、來源：
http://nt.ciss.idv.tw/tech/TCPIP/TCPIP2.htm
http://www.google.com/search?q=cache:oK-YqFRBfeYJ:www.oreilly.com.tw/sample_chap/a045_02.pdf+TCP/UDP&hl=zh-TW&gl=tw&ct=clnk&cd=6&lr=lang_zh-TW
http://zh.wikipedia.org/wiki/TCP
http://zh.wikipedia.org/wiki/UDP
高一下電腦課本
--------------------------------------------------------------------------------
◎附錄
校驗和
TCP的16位的校驗和的計算和檢驗過程如下：發送者將TCP報文段的頭部和數據部分的反碼和計算出來，再對其求反碼，就得到了校驗和，然後將結果裝入報文中傳輸。（這裡用反碼和的原因是這種方法的循環進位使校驗和可以在16位、32位、64位等情況下的計算結果在疊加後相同）接收者在收到報文後再按相同的演算法計算一次校驗和。這裡使用的反碼使得接收者不用再將校驗和欄位保存起來後清零，而可以直接將報文段連同校驗和一起計算。如果計算結果是-0，那麼就表示了報文的完整性和正確性。
注意：TCP校驗和也包括了96位的偽頭部，其中有源地址、目的地址、協議以及TCP的長度。這可以避免報文被錯誤地路由。
按現在的標準，TCP的校驗和是一個比較脆弱的校驗。具有高出錯率的數據鏈路層需要額外的連接錯誤糾正和探測能力。如果TCP是在今天被設計，它很可能有一個32位的CRC校驗來糾錯，而不是使用校驗和。但是通過在第二層使用通常的CRC或更完全一點的校驗可以部分地彌補這種脆弱的校驗。第二層是在TCP層和IP層之下的，比如PPP或乙太網，它們使用了這些校驗。但是這也並不意味著TCP的16位校驗和是冗余的，對於網際網路傳輸的觀察表明在受CRC保護的各跳之間，軟體和硬體的錯誤通常也會在報文中引入錯誤，而端到端的TCP校驗能夠捕捉到很多的這種錯誤。這就是應用中的端到端原則。
TCP的埠
TCP使用了埠號的概念來標識發送方和接收方的應用層。對每個TCP連接的一端都有一個相關的16位的無符號埠號分配給它們。埠被分為三類：眾所周知的、註冊的和動態/私有的。眾所周知的埠號是由網際網路賦號管理局(IANA)來分配的，並且通常被用於系統一級或根進程。眾所周知的應用程序作為伺服器程序來運行，並被動地偵聽經常使用這些埠的連接。例如：FTP、TELNET、SMTP、HTTP等。註冊的埠號通常被用來作為終端用戶連接伺服器時短暫地使用的源埠號，但它們也可以用來標識已被第三方註冊了的、被命名的服務。動態/私有的埠號在任何特定的TCP連接外不具有任何意義。可能的、被正式承認的埠號有65535個。
TCP的發展歷程
TCP是一個複雜的但同時又是在發展之中的協議。儘管許多重要的改進被提出和實施，發表於1981年的RFC793中說明的TCP的許多基本操作還是未作多大改動。RFC1122：《網際網路對主機的要求》闡明了許多TCP協議的實現要求。RFC2581：《TCP的擁塞控制》是一篇近年來關於TCP的很重要的RFC，描述了更新後的避免過度擁塞的演算法。寫於2001年的RFC3168描述了對明顯擁塞的報告，這是一種擁塞避免的信號量機制。在21世紀早期，在所有網際網路的數據包中，通常有大約95%的包使用了TCP協議。常見的使用TCP的應用層有HTTP/HTTPS（全球資訊網協議），SMTP/POP3/IMAP（電子郵件協議）以及FTP（文件傳輸協議）。這些協議在今天被廣泛地使用，這證明了它們的原作者的創造是卓越的。
最近，一個新協議已經被加州理工學院的科研人員開發出來，命名為FAST TCP（基於快速活動隊列管理的規模可變的傳輸控制協議）。它使用排隊延遲作為擁塞控制信號；但是因為端到端的延遲通常不僅僅包括排隊延遲，所以FAST TCP (或更一般地，所有基於排隊延遲的演算法) 在實際網際網路中的能否工作仍然是一個沒有解決的問題。
文章定位：
