TCP/IP 是供已連接因特網的計算機進行通信的通信協議
在 TCP/IP 內部
TCP/IP不是一個協議，而是一個協議族的統稱。包含一系列用於處理數據通信的協議：
- TCP (傳輸控制協議) - 應用程序之間通信
- UDP (用戶數據包協議) - 應用程序之間的簡單通信
- IP (網際協議) - 計算機之間的通信
- ICMP (因特網消息控制協議) - 針對錯誤和狀態
- DHCP (動態主機配置協議) - 針對動態尋址
網絡層
IP 是無連接的
IP 用於計算機之間的通信。
IP 是無連接的通信協議。它不會佔用兩個正在通信的計算機之間的通信線路。這樣，IP 就降低了對網絡線路的需求。每條線可以同時滿足許多不同的計算機之間的通信需要。
通過 IP，消息（或者其他數據）被分割爲小的獨立的包，並通過因特網在計算機之間傳送。
IP 負責將每個包路由至它的目的地。
IP地址
每個計算機必須有一個 IP 地址才能夠連入因特網。
每個 IP 包必須有一個地址才能夠發送到另一臺計算機。
TCP/IP 使用 4 個數字來爲計算機編址。每個計算機必須有一個唯一的 4 個數字的地址。
數字在 0 到 255 之間，並由點號隔開，像這樣：192.168.1.60
IP是網絡層的地址，而網絡層的出現目的之一就是屏蔽底層硬件的差異化，也就是在LAN上，到底用什麼樣的方式來找到目標主機併發送消息，IP是不管的。
域名
12 個阿拉伯數字很難記憶。使用一個名稱更容易。
在全世界，數量龐大的 DNS 服務器被連入因特網。DNS 服務器負責將域名翻譯爲 TCP/IP 地址，同時負責使用新的域名信息更新彼此的系統。
當一個新的域名連同其 TCP/IP 地址一同註冊後，全世界的 DNS 服務器都會對此信息進行更新。
傳輸層
TCP 使用固定的連接
TCP 用於應用程序之間的通信。
當應用程序希望通過 TCP 與另一個應用程序通信時，它會發送一個通信請求。這個請求必須被送到一個確切的地址。在雙方“握手”之後，TCP 將在兩個應用程序之間建立一個全雙工 (full-duplex) 的通信。
這個全雙工的通信將佔用兩個計算機之間的通信線路，直到它被一方或雙方關閉爲止。
UDP 和 TCP 很相似，但是更簡單，同時可靠性低於 TCP。
數據進入協議棧時的封裝過程：
數據在發送端和接收端的封裝和解包順序：
TCP建立連接三次握手和釋放連接四次握手
第一次握手
客戶端向服務端發送連接請求報文段。該報文段的頭部中SYN=1，ACK=0，seq=x。請求發送後，客戶端便進入SYN-SENT狀態。
- PS1：SYN=1，ACK=0表示該報文段爲連接請求報文。
- PS2：x爲本次TCP通信的字節流的初始序號。TCP規定：SYN=1的報文段不能有數據部分，但要消耗掉一個序號。
第二次握手
服務端收到連接請求報文段後，如果同意連接，則會發送一個應答：SYN=1，ACK=1，seq=y，ack=x+1。
該應答發送完成後便進入SYN-RCVD狀態。
- PS1：SYN=1，ACK=1表示該報文段爲連接同意的應答報文。
- PS2：seq=y表示服務端作爲發送者時，發送字節流的初始序號。
- PS3：ack=x+1表示服務端希望下一個數據報發送序號從x+1開始的字節。
第三次握手
當客戶端收到連接同意的應答後，還要向服務端發送一個確認報文段，表示：服務端發來的連接同意應答已經成功收到。
該報文段的頭部爲：ACK=1，seq=x+1，ack=y+1。
客戶端發完這個報文段後便進入ESTABLISHED狀態，服務端收到這個應答後也進入ESTABLISHED狀態，此時連接的建立完成！
簡單說，讓雙方都證實對方能發收。
知道對方能收是因爲收到對方的因爲收到而發的迴應。
具體：
1：A發，B收， B知道A能發
2：B發，A收， A知道B能發收
3：A發，B收， B知道A能收
爲什麼需要第三次握手?
還要再發送一次確認是爲了，防止已失效的連接請求報文段突然又傳到了B，因而產生錯誤。
已失效的報文段：正常情況下：A發出連接請求，但因爲丟失了，故而不能收到B的確認。於是A重新發出請求，然後收到確認，建立連接，數據傳輸完畢後，釋放連接，A發了2個，一個丟掉，一個到達，沒有“已失效的報文段”
但是，某種情況下，A的第一個請求在某個節點滯留了，延誤到達，本來這是一個早已失效的報文段，但是在A發送第二個，並且得到B的迴應，建立了連接以後，這個報文段竟然到達了，於是B就認爲，A又發送了一個新的請求，於是發送確認報文段，同意建立連接，假若沒有三次的握手，那麼這個連接就建立起來了（有一個請求和一個迴應），此時，A收到B的確認，但A知道自己並沒有發送建立連接的請求，因爲不會理睬B的這個確認，於是呢，A也不會發送任何數據，而B呢卻以爲新的連接建立了起來，一直等待A發送數據給自己，此時B的資源就被白白浪費了。但是採用三次握手的話，A就不發送確認，那麼B由於收不到確認，也就知道並沒有要求建立連接。
簡而言之：第三次握手，主機A發送一次確認是爲了防止：如果客戶端遲遲沒有收到服務器返回的確認報文，這時他會放棄連接，重新啓動一條連接請求；但問題是：服務器不知客戶端沒收到，所以他會收到兩個連接請求，白白浪費了一條連接開銷。
TCP四次揮手
TCP連接的釋放一共需要四步，因此稱爲『四次揮手』。
我們知道，TCP連接是雙向的，因此在四次揮手中，前兩次揮手用於斷開一個方向的連接，後兩次揮手用於斷開另一方向的連接。
第一次揮手
若A認爲數據發送完成，則它需要向B發送連接釋放請求。該請求只有報文頭，頭中攜帶的主要參數爲：
FIN=1，seq=u。此時，A將進入FIN-WAIT-1狀態。
* PS1：FIN=1表示該報文段是一個連接釋放請求。
* PS2：seq=u，u-1是A向B發送的最後一個字節的序號。
第二次揮手
B收到連接釋放請求後，會通知相應的應用程序，告訴它A向B這個方向的連接已經釋放。此時B進入CLOSE-WAIT狀態，並向A發送連接釋放的應答，其報文頭包含：
ACK=1，seq=v，ack=u+1。
* PS1：ACK=1：除TCP連接請求報文段以外，TCP通信過程中所有數據報的ACK都爲1，表示應答。
* PS2：seq=v，v-1是B向A發送的最後一個字節的序號。
* PS3：ack=u+1表示希望收到從第u+1個字節開始的報文段，並且已經成功接收了前u個字節。
A收到該應答，進入FIN-WAIT-2狀態，等待B發送連接釋放請求。
第二次揮手完成後，A到B方向的連接已經釋放，B不會再接收數據，A也不會再發送數據。但B到A方向的連接仍然存在，B可以繼續向A發送數據。
第三次揮手
當B向A發完所有數據後，向A發送連接釋放請求，請求頭：FIN=1，ACK=1，seq=w，ack=u+1。B便進入LAST-ACK狀態。
第四次揮手
A收到釋放請求後，向B發送確認應答，此時A進入TIME-WAIT狀態。該狀態會持續2MSL時間，若該時間段內沒有B的重發請求的話，就進入CLOSED狀態，撤銷TCB。當B收到確認應答後，也便進入CLOSED狀態，撤銷TCB。
爲什麼A要先進入TIME-WAIT狀態，等待2MSL時間後才進入CLOSED狀態？
爲了保證B能收到A的確認應答。
若A發完確認應答後直接進入CLOSED狀態，那麼如果該應答丟失，B等待超時後就會重新發送連接釋放請求，但此時A已經關閉了，不會作出任何響應，因此B永遠無法正常關閉。
什麼時候應該使用TCP？
當對網絡通訊質量有要求的時候，比如：整個數據要準確無誤的傳遞給對方，這往往用於一些要求可靠的應用，比如HTTP、HTTPS、FTP等傳輸文件的協議，POP、SMTP等郵件傳輸的協議。
什麼時候應該使用UDP？
當對網絡通訊質量要求不高的時候，要求網絡通訊速度能儘量的快，這時就可以使用UDP。