TCP/IP不是一個協議，而是一個協議族的統稱。里面包括IP協議、IMCP協議、TCP協議。
TCP/IP分層：
這里有幾個需要注意的知識點：
- 互聯網地址：也就是IP地址，一般為網絡號+子網號+主機號
- 域名系統：通俗的來說，就是一個數據庫，可以將主機名轉換成IP地址
- RFC：TCP/IP協議的標準文檔
- 端口號：一個邏輯號碼，IP包所帶有的標記
- Socket：應用編程接口
數據鏈路層的工作特性：
- 為IP模塊發送和接收IP數據報
- 為ARP模塊發送ARP請求和接收ARP應答（ARP：地址解析協議，將IP地址轉換成MAC地址）
- 為RARP發送RARP請求和接收RARP應答
接下來我們了解一下TCP/IP的工作流程：
數據鏈路層從ARP得到數據的傳遞信息，再從IP得到具體的數據信息
IP協議
IP協議頭當中，最重要的就是TTL（IP允許通過的最大網段數量）字段（八位），規定該數據包能穿過幾個路由之后才會被拋棄。
IP路由選擇
ARP協議工作原理
ICMP協議（網絡控制文協議）
將IP數據包不能傳送的錯誤信息傳送給主機
查詢報文
- ping查詢：主機是否可達，通過計算間隔時間和傳送多少個包的數量
- 子網掩碼
- 時間戳：獲得當前時間
差錯報文
不產生的情況：
靜態路由選擇
先來看路由選擇工作流程：
靜態路由選擇
- 配置接口以默認方式生成路由表項，或者使用route add手動添加表項
- ICMP報文（ICMP重定向報文）更新表項
- 動態路由選擇（只使用在路由之間）
RIP（路由信息協議）
分布式的基于距離向量（路由器到每一個目的網絡的距離記錄）的路由選擇協議
router承擔的工作：
- 給每一個已知路由器發送RIP請求報文，要求給出完整的路由表
- 如果接受請求，就將自己的路由表交給請求者；如果沒有，就處理IP請求表項（自己部分+跳數/沒有的部分+16）
- 接受回應，更新路由表
- 定期更新路由表（一般為30s，只能說太頻繁~）
OSPF（開放最短路徑優先協議）
分布式鏈路狀態（和這兩個路由器都有接口的網絡）協議
首先我們先來了解TCP報文段
重要的標志我在圖中也有標記，重點了解標志位
ACK：確認序號有效
RST：重置連接
SYN：發起了一個新連接
FIN：釋放一個連接
三次握手的過程（客戶端我們用A表示，服務器端用B表示）
前提：A主動打開，B被動打開
- 在建立連接之前，B先創建TCB（傳輸控制塊），準備接受客戶進程的連接請求，處于LISTEN（監聽）狀態
- A首先創建TCB，然后向B發出連接請求，SYN置1，同時選擇初始序號seq=x，進入SYN-SEND（同步已發送）狀態
- B收到連接請求后向A發送確認，SYN置1，ACK置1，同時產生一個確認序號ack=x+1。同時隨機選擇初始序號seq=y，進入SYN-RCVD（同步收到）狀態
- A收到確認連接請求后，ACK置1，確認號ack=y+1，seq=x+1，進入到ESTABLISHED（已建立連接）狀態。向B發出確認連接，最后B也進入到ESTABLISHED（已建立連接）狀態。
簡單來說，就是
- 建立連接時，客戶端發送SYN包（SYN=i）到服務器，并進入到SYN-SEND狀態，等待服務器確認
- 服務器收到SYN包，必須確認客戶的SYN（ack=i+1）,同時自己也發送一個SYN包（SYN=k）,即SYN+ACK包，此時服務器進入SYN-RECV狀態
- 客戶端收到服務器的SYN+ACK包，向服務器發送確認報ACK（ack=k+1）,此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手
在此穿插一個知識點就是SYN攻擊，那么什么是SYN攻擊？發生的條件是什么？怎么避免？
在三次握手過程中，Server發送SYN-ACK之后，收到Client的ACK之前的TCP連接稱為半連接（half-open connect），此時Server處于SYN_RCVD狀態，當收到ACK后，Server轉入ESTABLISHED狀態。SYN攻擊就是 Client在短時間內偽造大量不存在的IP地址，并向Server不斷地發送SYN包，Server回復確認包，并等待Client的確認，由于源地址 是不存在的，因此，Server需要不斷重發直至超時，這些偽造的SYN包將產時間占用未連接隊列，導致正常的SYN請求因為隊列滿而被丟棄，從而引起網 絡堵塞甚至系統癱瘓。SYN攻擊時一種典型的DDOS攻擊，檢測SYN攻擊的方式非常簡單，即當Server上有大量半連接狀態且源IP地址是隨機的，則可以斷定遭到SYN攻擊了，使用如下命令可以讓之現行：
#netstat -nap | grep SYN_RECV
#netstat -nap | grep SYN_RECV
四次分手的過程（客戶端我們用A表示，服務器端用B表示）
由于TCP連接時是全雙工的，因此每個方向都必須單獨進行關閉。這一原則是當一方完成數據發送任務后，發送一個FIN來終止這一方向的鏈接。收到一個FIN只是意味著這一方向上沒有數據流動，既不會在收到數據，但是在這個TCP連接上仍然能夠發送數據，知道這一方向也發送了FIN，首先進行關閉的一方將執行主動關閉，而另一方則執行被動關閉。
前提：A主動關閉，B被動關閉
有人可能會問，為什么連接的時候是三次握手，而斷開連接的時候需要四次揮手？
這是因為服務端在LISTEN狀態下，收到建立連接請求的SYN報文后，把ACK和SYN放在一個報文里發送給客戶端。而關閉連接時，當收到對方的FIN 報文時，僅僅表示對方不再發送數據了但是還能接收數據，己方也未必全部數據都發送給對方了，所以己方可以立即close，也可以發送一些數據給對方后，再 發送FIN報文給對方來表示同意現在關閉連接，因此，己方ACK和FIN一般都會分開發送。
- A發送一個FIN，用來關閉A到B的數據傳送，A進入FIN_WAIT_1狀態。
- B收到FIN后，發送一個ACK給A，確認序號為收到序號+1（與SYN相同，一個FIN占用一個序號），B進入CLOSE_WAIT狀態。
- B發送一個FIN，用來關閉B到A的數據傳送，B進入LAST_ACK狀態。
- A收到FIN后，A進入TIME_WAIT狀態，接著發送一個ACK給B，確認序號為收到序號+1，B進入CLOSED狀態，完成四次揮手。
簡單來說就是
- 客戶端A發送一個FIN，用來關閉客戶A到服務器B的數據傳送（報文段4）。
- 服務器B收到這個FIN，它發回一個ACK，確認序號為收到的序號加1（報文段5）。和SYN一樣，一個FIN將占用一個序號。
- 服務器B關閉與客戶端A的連接，發送一個FIN給客戶端A（報文段6）。
- 客戶端A發回ACK報文確認，并將確認序號設置為收到序號加1（報文段7）。
A在進入到TIME-WAIT狀態后，并不會馬上釋放TCP，必須經過時間等待計時器設置的時間2MSL（最長報文段壽命），A才進入到CLOSED狀態。為什么？
- 為了保證A發送的最后一個ACK報文段能夠到達B
- 防止“已失效的連接請求報文段”出現在本連接中
OK~是不是很難懂的感覺？那我們來說的“人性化點的”吧
三次握手流程
- 客戶端發個請求“開門吶，我要進來”給服務器
- 服務器發個“進來吧，我去給你開門”給客戶端
- 客戶端有很客氣的發個“謝謝，我要進來了”給服務器
四次揮手流程
- 客戶端發個“時間不早了，我要走了”給服務器，等服務器起身送他
- 服務器聽到了，發個“我知道了，那我送你出門吧”給客戶端，等客戶端走
- 服務器把門關上后，發個“我關門了”給客戶端，然后等客戶端走（尼瑪~矯情?。?/li>
- 客戶端發個“我知道了，我走了”，之后自己就走了
本文來自投稿，不代表Linux運維部落立場，如若轉載，請注明出處：http://www.www58058.com/97568
