TCP/IP協議與UDP協議
TCP/IP協議
TCP/IP是“傳輸控制協議/因特網協議”的縮略語，指的是一些主要協議中的兩個協議，這些協議也被稱爲因特網協議簇。TCP/IP協議可爲任意的計算機系統提供網絡連接，其連接可以跨越不同的網絡介質、應對可能的不利條件。
因特網的一個基本設計目標是允許廣泛的網絡特質，接納諸如帶寬、延時、丟包、包失序以及數據包的最大長度方面的不同。另一個目標是健壯性，能應對單個網絡、網關和主機的失效，並在這種情況下仍能利用任何可用的帶寬。其最終目標是實現全面的“開放系統互連”：一個因特網主機必須能夠跨越不同的因特網路徑，與任何其他因特網主機穩定地、有效地互操作。
TCP/IP的強大之處在於其兼容性，它能夠兼容幾乎所有的低層網絡架構。由於其協議都基於開放標準，這一事實更鞏固了它的地位。
因特網協議所提供的服務與OSI網絡參考模型的會話層、表示層、傳輸層和網絡層相當。正如我們在第2章描述的那樣，在異構網絡中的任何位置，網絡層和傳輸層對數據編址併發送數據（可靠的或不可靠的），會話層同步兩端應用程序之間的通信，表示層爲應用程序準備信息。
圖3-1展示了TCP/IP協議簇與OSI網絡參考模型之間的相對關係，及其與Windows Sockets模型的對比。從圖中可以看到，TCP和IP並不是TCP/IP簇中僅有的兩個協議。同時還應注意到，數據鏈路層和物理層不是因特網協議簇的組成部分。正是因爲獨立於低層，使得TCP/IP得以在任何網絡驅動和網絡介質（以太網、令牌環網、FDDI等）上運行。應用層也不包含在TCP/IP簇中，因爲網絡應用和操作系統平臺之間的用戶接口變化很大。
圖3-1 TCP/IP協議簇與OSI網絡參考模型和Windows Sockets模型的比較
下面是圖3-1中提到的每個協議所提供的服務：
會話層和表示層：
文件傳輸協議（File Transfer Protocol，FTP）：文件傳輸。
簡單郵件傳輸協議（Simple Mail Transfer Protocol，SMTP）：電子郵件服務。
遠程登錄（Telnet）：用於遠程登錄的終端協商。
域名服務（Domain Name Services，DNS）：主機名到IP地址的映射。
傳輸層：
用戶數據報協議（User Datagram Protocol，UDP）：無連接數據傳輸。
傳輸控制協議（Transmission Control protocol，TCP）：可靠的數據傳輸。
網絡層：
因特網協議（Internet Protocol，IP）：獨立於硬件的尋址、路由、分片和數據包重組。
地址解析協議（Address Resolution Protocol，ARP）：IP地址到硬件地址的映射。
因特網控制消息協議（Internet Control Message Protocol，ICMP）：錯誤和控制消息。
諸如Telnet、FTP和SMTP一類的應用（上層）協議，對於TCP/IP協議簇所提供的互操作能力是很重要的，它們爲一般的網絡服務提供了公共的應用協議，還可以列舉很多其他的協議（例如，archie、gopher、talk、veronica和wais），但是前述3種協議向來被認爲是TCP/IP的組成部分，因爲它們提供了最基本的網絡服務：電子郵件、文件傳輸和遠程登錄。
WinSock API提供了對傳輸層和網絡層協議服務（即網絡系統）的訪問。高層協議不能通過WinSock API訪問，而是必須藉助WinSock應用程序來實現。域名服務（DNS）協議是一個值得注意的特例，DNS是一個“支持協議”，它使應用程序能夠查找主機名以及主機地址（如果一個應用程序知道了主機名，那麼就可以查找到地址；反之亦然）。這種便利的（如果不是必需的）服務可以通過WinSock API獲得。本章後面將會詳細地描述這個服務，並在第8章中講解如何訪問這些服務（第8章中講解諸如gethostbyname（）和WSAAsyncGetHostByName（）等WinSock函數）。
UDP協議
數據報服務可以與郵政投遞相類比，我們通常不認爲郵政服務有什麼不可靠，但是一類（first-dass）郵件並不保證投遞（到達），也不維持投遞順序，當然，大多數一類郵件都能順利地送達（我們通常並不在意送達的順序）。
無連接傳輸服務簡單，而簡單就是其優勢，它開銷小，所以效率高，因而帶來性能上的優勢，它也很容易使用。雖然數據報服務是不可靠的，但是採用數據報服務的應用程序卻不一定不可靠，任何數據報應用程序都能夠實現可靠的服務。
接收數據的應用程序可以針對每個收到的數據報發送確認信息，發送數據的應用程序如果在給定的時間內沒有收到確認信息，可以重發這個數據報。每個數據報可以攜帶一個順序號或者時間戳，這樣接收端可以根據需要重新建立起數據報的順序，並且能夠檢測出接收的重複數據，然後丟棄它。通過在基本服務上增加上述功能來提高可靠性，這與向郵局索取發送掛號信的收據沒有什麼不同。
當一個應用程序發送了一個數據報，數據報服務並不通告其是否到達，如果應用程序發送了兩個數據報，任何一個都有可能先於另一個到達
數據報服務對於短事務（short transaction）類的應用比較理想，對於這類應用，創建和拆除一個連接的工作量比數據傳輸本身還要大。數據報服務對於那些本身就隱含了確認功能的應用也很合適。例如，一個應用程序向數據庫服務器發送查詢請求並等待回覆，如果得到了完整的回覆，則應用程序完成任務；如果超時後仍沒有得到回覆，那麼應用程序就會重新發起查詢請求（或者採取其他操作，例如向用戶顯示一個錯誤信息）。
有些應用程序拿可靠性來換取更高的容量，通過採用數據報服務實現高數據吞吐量，特別是在能夠容忍數據丟失的情況下。這些應用程序在應用層上對數據進行排序、提供發送端和接收端之間的應用層同步。如那些發送視頻或音頻信號或者從實時數據採集設備上接收採樣數據的系統，都是這類應用的一些例子。
很奇怪的是，有一些應用程序在採用“可靠”服務後反而變得不可靠。例如，一些實時的音頻和視頻應用程序，並不希望等待數據重傳或者允許傳輸控制機制干擾“自然的”數據流。
由於數據報服務是無連接的（即不與遠程的某單一主機“綁定”），所以，它還能夠支持多播和廣播。有些應用程序需要使用同一個地址同時與多臺主機通信，而面向連接的協議不能提供這種服務。
用戶數據報協議（UDP）是TCP/IP簇中的一個主要的數據報協議。因特網控制消息協議（ICMP）則是另一個數據報傳輸協議，可以通過使用SOCK_RAW socket來訪問ICMP。SOCK_RAW socket是Windows Sockets API的一個可選功能，所以，ICMP並不是普遍可用的。
像任何數據報協議一樣，UDP發送和接收分離的數據分組。換言之，如果在一次發送操作中傳輸了一定數量的字節，那麼在一次接收操作中也將接收同樣數量的字節。數據在網絡傳輸過程中，將保持其分組的邊界。UDP也採用TCP/IP標準的校驗和算法（16位字的1的補碼和）來對所接收的數據進行粗略的校驗（UDP校驗和計算是TCP/IP協議棧的可選項，但是大多數棧都啓用該功能）。
UDP不提供有保證的傳輸。當TCP/IP實現軟件接收到一個UDP數據報時，並不反饋接收驗證的確認信息，UDP也不維持傳輸的順序。儘管如此，就像在前面所討論的那樣，使用UDP的Windows Sockets應用程序還是能夠實現可靠性和順序化的。
兩種協議的區別
應用程序開發人員通常也會認爲：TCP的網絡數據包及其處理開銷將對數據的吞吐量帶來不利的影響，所以他們會傾向於UDP的簡潔性，然後，試圖在應用程序中通過某些機制保證可靠性。採用UDP的結果是：比起使用TCP協議，開發人員付出了更多的勞動，並在應用程序中引入了更多的計算開銷。“誰忽視了TCP，誰就註定要推倒重來。”
經驗法則：採用TCP吧，除非你的確有不用的理由。
經驗證明，在性價比方面，TCP的計算與網絡開銷對於網絡吞吐量的影響可以忽略不計。採用TCP的一個最重要的理由是程序的編寫更容易了。在前面部分我們給出了一些適合採用無連接協議的應用例子，下面是這類應用的一些特點：
使用廣播和多播服務。
實時數據（如音頻和視頻）對延時敏感，因此，它們不能接受數據重傳或諸如TCP的慢開始和Nagle算法一類的擁塞控制機制。
需要具有內在確認功能的短事務，能接受重複的數據報。
爲了避免協議選擇問題，有時可以在應用程序的設計中採用兩個socket：分別爲每個協議建立一個socket。例如，UNIX的“talk”應用程序採用UDP發送初始的端口查詢請求，以獲取可連接的端口。這個查詢可以通過廣播的方式發送，以發現運行talk服務器的主機，當收到肯定的迴應時，返回的UDP數據報中包含了可連接的talk服務的TCP端口號。
