TCP/IP是以IP和TCP協議為核心的一整套網絡協議的總稱，所以有時候我們也稱其為TCP/IP協議簇。毫不誇張地說，TCP/IP支撐著整個互聯網，因為它就是互聯網採用的網絡協議。TCP/IP協議簇劃分為如右圖所示的4個層次[2]（應用層、傳輸層、網絡層和鏈路層），構成整個協議簇的各個子協議處於相應層次中。
既然將整個協議簇命名為TCP/IP，那麼IP和TCP自然就是其中最為核心的兩個協議了。處於網絡層的IP協議提供的IP數據報傳輸是不可靠的，因為它只承諾儘可能地將數據報發送出去，但不能保證發送的數據報能夠成功地抵達目的地。IP協議的不可靠性還體現在它不能檢測數據在傳輸過程中是否發生了改變，也就是說數據的完整性得不到保證。IP協議是一個無連接（Connectionless）的網絡協議，每次數據報的處理對它來說均是獨立的，因此IP協議也不能提供針對有序傳輸（數據接收的順序與發送的順序一致）的保證。
雖然IP協議只能提供不可靠的數據傳輸，同時有序傳輸也得不到保證，但是建立在它之上的傳輸層協議TCP有效地解決了這兩個問題。TCP是一個基於連接的協議，數據交換雙方在進行報文傳輸之前需要建立連接，報文傳輸結束之後需要關閉連接。這是一個雙工（Duplex）連接，數據交換的雙工均可以利用它向對方發送數據。
TCP利用“接收確認”和“超時重傳”機制確保了數據能夠成功抵達目的地。具體來說，接收方在成功接收到數據之後會回覆一個確認消息。發送方在本地具有一個存放尚未得到確認的已發消息的緩衝區，如果發送方在一個設定的時限內沒有接收到針對某個已發報文的確認消息，它會從該緩存區中選擇對應的報文進行重新發送。在接收到確認之後，相應的報文會從緩存區中移除。
為了解決有序傳輸的問題，發送方會為每個報文進行編號，報文的序號體現了它們被髮送的順序。接收端在接收到某個報文之後，它會利用此序號判斷是否具有尚未成功接收的已發報文，如果有的話，該報文會被存放到本地的緩衝區中。等到之前發送的報文全部被接收之後，接收方按照序號對接收的報文依次向上（應用層）遞交，成功遞交的報文會被從緩存區中移除。除了接收到“失序”的報文之外，接收方還有可能接收到重複的報文，因為沒有報文均具有一個唯一的序號，如果該序號小於已經成功遞交或者添加到緩存區中的報文序號，它會被認為是重複接收的報文而被丟棄。
由於每個TCP報文段都具有一個16位的檢驗和（Checksum），所以接收方可以根據它確認數據在傳輸過程中是否被篡改。除此之外，TCP還提供了“流量控制”功能避免了雙方因緩存區大小不一致而導致報文丟失。具體來說，如果發送方的緩衝區大於接收方的緩存區，會導致接收方在緩衝區已滿的情況下無法處理後續接收的報文，所以接收方會將自己緩存區剩餘的大小及時通知給發送端，後者據此控制報文發送“流量”。
HTTP（Hypertext Transfer Protocol），全稱為“超文本傳輸協議”，是TCP/IP協議簇的一部分。從圖1-1可以看出，這是一個位於應用層的網絡協議，在它之下的就是TCP協議。由於TCP協議是一個“可靠”的協議，HTTP自然也能提供可靠數據傳輸功能。
IP協議利用IP地址來定位數據報發送的目的地，而利用域名系統（DNS）可以實現域名與IP地址之間的轉換。TCP協議利用端口號標識應用程序，所以某個應用程序在使用TCP協議進行通信的時候必須指定目標應用的IP地址（或者域名）和端口號。HTTP默認採用的端口號為80，而HTTPS（利用TLS/SSL為HTTP提供傳輸安全保障）的默認端口號則為443，當然在網絡可達的前提下，我們可以指定任意的端口。
閱讀更多 JAVA熊 的文章
