TCP/IP協議簇（DoD參考模型）
用於簡化OSI層次，以及相關的標准。
² 傳輸控制協議(tcp/ip)族是相關國防部(DoD)所創建的，主要用來確保數據的完整性及在毀滅性戰爭中維持通信
² 是由一組不同功能的協議組合在一起構成的協議簇
² 利用一組協議完成OSI所實現的功能
====================TCP / IP=====================
應用層： 它只負責產生相應格式的數據 ssh ftp nfs cifs dns http smtp pop3
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
傳輸層： 定義數據傳輸的兩種模式：
TCP（傳輸控制協議：面向連接，可靠的，效率相對不高）
UDP（用戶數據報協議：非面向連接，不可靠的，但效率高）
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
網絡層： 連接不同的網絡如以太網、令牌環網
IP （路由，分片） 、ICMP、 IGMP
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
數據鏈路層：以太網傳輸
ARP ( 地址解析協議，作用是將IP解析成MAC )
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
物理層： 主要任務是規定各種傳輸介質和接口與傳輸信號相關的一些特性
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
TCP/IP協議簇中的相關協議
TCP/IP協議簇---應用層
TCP/IP協議簇---主機到主機層
TCP與UDP對比
| 傳輸控制協議（TCP） |
用戶數據報協議(UDP) |
| 面向連接 |
無連接 |
| 可靠傳輸 |
不可靠傳輸 |
| 流控 |
盡力而為，盡力傳遞 |
| 使用TCP應用： WEB瀏覽器；電子郵件；文件傳輸程序 |
使用UDP的應用： 域名系統（DNS）；視頻流；IP語音（VoIP） |
TCP相關報文結構
源端口：即本地發起連接的端口
目標端口：即要訪問的服務的端口
序列號：因為傳輸層會將上層的數據進行分段，因此需要對分段數據進行編號
同時也便於數據的重組
驗證號：用於對數據的進行驗證
UDP相關報文結構
TCP/UDP端口號（1~65535）
1.源端口隨機分配，目標端口使用知名端口 2.應用客戶端使用的源端口號一般為系統中未使用的且大於1023的 3.目的端口號為服務器端應用服務的進程，如telnet為23
TCP三次握手過程
置位概念: 根據TCP的包頭字段，存在三個重要的標識ACK SYN FIN
² ACK：表示驗證字段
² SYN: 位數置1，表示建立TCP連接
² FIN：位數置1，表示斷開TCP連接
建立過程說明：
①由主機A發送建立TCP連接的請求報文，其中報文中包含seq序列號，是由發送 端隨機生成的，並且還將報文中SYN字段置為1，表示需要建立TCP連接 ②主機B會回復A發送的TCP連接請求報文，其中包含seq序列號，是由回復端隨 機生成的，並且將回復報文的SYN字段置1，而且會產生ACK字段，ACK字段數 值是在A發過來的seq序列號基礎上加1進行回復，以便A收到信息時，知曉自 己的TCP建立請求已得到了驗證 ③A端收到B端發送的TCP建立驗證請求后，會使自己的序列號加1表示，並且再 次回復ACK驗證請求，在B端發送過來的seq基礎上加1，進行回復
①一開始，建立連接之前服務器和客戶端的狀態都為CLOSED。*** ②服務器創建socket后開始監聽，變為LISTEN狀態。 *** ③客戶端請求建立連接，向服務器發送SYN報文，客戶端的狀態變 為SYN_SENT。 *** ④服務器收到客戶端的報文后向客戶端發送ACK和SYN報文，此時服務器的 狀態變為SYN_RCVD。 *** ⑤然后，客戶端收到ACK、SYN，就向服務器發送ACK，客戶端狀態 變為ESTABLISHED， *** 服務器收到客戶端的ACK后也變為ESTABLISHED。此時，3次握手完成， 連接建立！
TCP四次揮手過程
建立過程說明：
①主機A發送斷開TCP連接請求的報文，其中報文中包含seq序列號，是由發送端隨機生成的，並且還將報文中FIN字段置為1，表示需要斷開TCP連接 ②主機B會回復A發送的TCP斷開請求報文，其中包含seq序列號，是由回復端隨機生成的，而且會產生ACK字段，ACK字段數值，是在A發過來的seq序列號基 礎上加1進行回復，以便A收到信息時，知曉自己的TCP斷開請求已得到了驗證 ③主機B在回復完A的TCP斷開請求后，不會馬上就進行TCP連接的斷開，主機B會先確保斷開前，所有傳輸到A的數據是否已經傳輸完畢，一旦確認傳輸數據完畢 就會將回復報文的FIN字段置1，並產生隨機seq序列號。 ④主機A收到主機B的TCP斷開請求后，會回復主機B的斷開請求，包含隨機生成的seq字段和ack字段，ack字段會在主機B的TCP斷開請求的seq基礎上 加1，從而完成主機B請求的驗證回復。 至此TCP斷開的4次揮手過程完畢
由於tcp連接是全雙工的，斷開連接會比建立連接麻煩一點點。
①客戶端先向服務器發送FIN報文，請求斷開連接，其狀態變為FIN_WAIT1。 ②服務器收到FIN后向客戶端發生ACK，服務器狀態變為CLOSE_WAIT。 ③客戶端收到ACK后就進入FIN_WAIT2狀態。此時連接已經斷開了一半了。如果服務器還有數據要發送給客戶端，就會繼續發送。 ④直到發完了，就發送FIN報文，此時服務器進入LAST_ACK狀態。 ⑤客戶端收到服務器的FIN后，馬上發送ACK給服務器，此時客戶端進入TIME_WAIT狀態 ⑥再過了2MSL長的時間后進入CLOSED狀態。服務器收到客戶端的ACK就進入CLOSED狀態。 至此，還有一個狀態沒有提及：CLOSING狀態。 CLOSING狀態表示： 客戶端發生了FIN，但沒有收到服務器的ACK，卻收到了服務器的FIN。 這種情況發生在服務器發送的ACK丟包的時候，因為網絡傳輸有時會有意外。
四次分手：
由於TCP連接是全雙工的，因此每個方向都必須單獨進行關閉。這個原則是當一方完成它的數據發送任務后就能發送一個FIN來終止這個方向的連接。收 到一個 FIN只意味着這一方向上沒有數據流動，一個TCP連接在收到一個FIN后仍能發送數據。首先進行關閉的一方將執行主動關閉，而另一方執行被動關 閉。
（1）客戶端A發送一個FIN，用來關閉客戶A到服務器B的數據傳送（報文段4）。 （2）服務器B收到這個FIN，它發回一個ACK，確認序號為收到的序號加1（報文段5）。和SYN一樣，一個FIN將占用一個序號。 （3）服務器B關閉與客戶端A的連接，發送一個FIN給客戶端A（報文段6）。 （4）客戶端A發回ACK報文確認，並將確認序號設置為收到序號加1（報文段7）。
1．為什么建立連接協議是三次握手，而關閉連接卻是四次握手呢？
這是因為服務端的LISTEN狀態下的SOCKET當收到SYN報文的建連請求后，它可以把ACK和SYN（ACK起應答作用，而SYN起同步作 用）放在一個報文里來發送。但關閉連接時，當收到對方的FIN報文通知時，它僅僅表示對方沒有數據發送給你了；但未必你所有的數據都全部發送給對方了，所 以你可以未必會馬上會關閉SOCKET,也即你可能還需要發送一些數據給對方之后，再發送FIN報文給對方來表示你同意現在可以關閉連接了，所以它這里的 ACK報文和FIN報文多數情況下都是分開發送的。
2．為什么TIME_WAIT狀態還需要等2MSL后才能返回到CLOSED狀態？
這是因為雖然雙方都同意關閉連接了，而且握手的4個報文也都協調和發送完畢，按理可以直接回到CLOSED狀態（就好比 從SYN_SEND狀態到ESTABLISH狀態那樣）；但是因為我們必須要假想網絡是不可靠的，你無法保證你最后發送的ACK報文會一定被對方收到，因 此對方處於LAST_ACK狀態下的SOCKET可能會因為超時未收到ACK報文，而重發FIN報文，所以這個TIME_WAIT狀態的作用就是用來重發 可能丟失的ACK報文。
TCP的十一種狀態轉移總結
| 狀態出現方式 |
狀態出現環境 |
狀態名稱 |
狀態描述 |
| TCP建立過程 涉及5種狀態 |
服務端/客戶端 |
CLOSED |
默認初始化狀態 |
| 服務端 |
LISTEN |
建立socket，進入監聽狀態 |
|
| 客戶端 |
SYN_SENT |
發送syn報文，進入syn發送狀態 |
|
| 服務端 |
SYN_RCVD |
接收syn報文，並回復ack及syn報文 |
|
| 客戶端/服務端 |
ESTABLISHED |
接收syn報文，回復ack，建立連接(客戶端) 接收ack報文，建立連接(服務端) |
|
| TCP斷開過程 涉及6種狀態 |
服務端/客戶端 |
ESTABLISHED |
默認斷開前初始化狀態 |
| 客戶端 |
FIN_WAIT1 |
發送斷開請求FIN報文 |
|
| 服務端 |
CLOSE_WAIT |
收到FIN后向客戶端發生ACK |
|
| 客戶端 |
FIN_WAIT2 |
收到服務端返回的ACK報文，等待數據傳輸 |
|
| 服務端 |
LAST_ACK |
發送FIN斷開請求報文 |
|
| 客戶端 |
TIME_WAIT |
回復FIN斷開請求，發送ack報文 |
|
| 服務端/客戶端 |
CLOSED |
收到ack報文，立即轉變為斷開狀態 等待2MSL后，進入斷開狀態 |
|
| 客戶端 |
CLOSEING |
沒有收到回復FIN報文的ACK，直接收到FIN |
TCP/IP協議簇---因特網層
定義了最重要的協議IP協議，和路由協議。
