TCP/IP協定詳解

TCP/IP協定

Transmission Control Protocol /Internet Protocol  傳輸控制協定/英特爾互聯協定
TCP/IP是一個Protocol Stack，包括TCP、 IP、UDP、ICMP、RIP、TELNET、FTP、 SMTP、ARP等許多協定
最早發源於美國國防部（縮寫DOD）的英特爾的前身ARPA網專案1983年1月1日，TCP/IP取代了舊的網路控制協定NCP，成為今天的網際網路和區域網的基石和標準，由網際網路工程任務組負責維護

共定義了四層

和ISO參考模型的分層有對應關係 

TCP/IP 協定和OSI模型

TCP/IP              OSI參考模型

應用層              應用層
                        表示層
                        對談層

傳輸層              傳輸層

internet層          網路層

資料鏈路層          資料鏈路層

物理層              物理層 

TCP特性

工作在傳輸層
面向連線協定
全雙工協定
半關閉
錯誤檢查
將資料打包成端，排序
確認機制
資料恢復重傳
流量控制，滑動視窗
擁塞控制，慢啟動和擁塞避免演算法

TCP

源埠，目標埠：計算機上的進程要是和其他進程通訊是通過計算機埠的，而一個計算機埠某個時刻只能被一個進程佔用，所以通過制定源埠和目標埠，就可以知道是那兩個進程需要通訊，源埠，目標埠是用16位元表示的，可推算計算機埠個數為2^16個
序列號：表示本報文段所傳送資料的第一個位元組的編號，在TCP連結中所傳送的位元組節流的每一個位元組都會按順序編號，由於序列號有32位元表示，所以每2^32個位元組，都會出現序列號回繞，再次從0開始
確認號：表示接收方期望收到傳送方下一個報文段的第一個位元組資料的編號，也就是告訴傳送發：我希望你下一次傳送的資料的第一個位元組資料的編號是這個確認號
資料偏移： 表示TCP報文段的首部長度，共4位元 由於TCP首部包含一個長度可變的選項部分，需要指定這個TCP報文的長度到底有多長，他指出TCP報文段的資料起始處距離TCP報文段的起始處有多遠 ，該欄位單位是32位元，4位元二進最大表示15 所以資料飄逸也是TCP首部最大60位元組 

TCP包頭

  URG：表示本報文段中傳送的資料是否包含緊急資料。後面的緊急指標欄位（urgent pointer）只有當URG=1時才有效
    ACK：表示是否前面確認號欄位是否有效。只有當ACK=1時，前面的確認號欄位才有效。 TCP規定，連線建立後，ACK必須為1,帶ACK標誌的TCP報文段稱為確認報文段
    PSH：提示接收端應用程式應該立即從TCP接收緩衝區中讀走資料，為接收後續資料騰出空 間。如果為1，則表示對方應當立即把資料提交給上層應用，而不是快取起來，如果應用程式 不將接收到的資料讀走，就會一直停留在TCP接收緩衝區中
    RST：如果收到一個RST=1的報文，說明與主機的連線出現了嚴重錯誤（如主機崩潰），必 須釋放連線，然後再重新建立連線。或者說明上次傳送給主機的資料有問題，主機拒絕響應， 帶RST標誌的TCP報文段稱為復位報文段
    SYN：在建立連線時使用，用來同步序號。當SYN=1，ACK=0時，表示這是一個請求建立連 接的報文段；當SYN=1，ACK=1時，表示對方同意建立連線。SYN=1，說明這是一個請求 建立連線或同意建立連線的報文。只有在前兩次握手中SYN才置為1，帶SYN標誌的TCP報文 段稱為同步報文段
    FIN：表示通知對方本端要關閉連線了，標記資料是否傳送完畢。如果FIN=1，即告訴對方： “我的資料已經傳送完畢，你可以釋放連線了”，帶FIN標誌的TCP報文段稱為結束報文段

序號和確認號和標記為

seq:序號：傳送者的發的包的序號
ack:確認號：是接收者收到後返回的確認包

標記位：
URG:（緊急指標位）只有當URG=1時才有意義
ACK：（確認位）表示是否前面確認號欄位是否有效。只有當ACK=1時，前面的確認號欄位才有效。
RST：重置位
SYN：同步位
FIN：結束位

TCP包頭

視窗大小：表示現在允許對方傳送的資料量，也就是告訴對方，從本報文段的確認號開始允許對方傳送的資料量
校驗和：提供額外的可靠性
緊急指標：標記緊急資料在資料欄位中的位置
選項部分：其最大長度可根據TCP首部長度進行推算
常見選項：
    最大報文段長度：Maxium Segment Size，MSS
    視窗擴大：Windows Scaling
    時間戳： Timestamps 

TCP三次握手

所謂三次握手(Three-way Handshake)，是指建立一個TCP連線時，需要用戶端和伺服器總共傳送3個包。
三次握手的目的是連線伺服器指定埠，建立TCP連線,並同步連線雙方的序列號和確認號並交換 TCP 視窗大小資訊.在socket程式設計中，用戶端執行connect()時。將觸發三次握手：

三次握手過程

第一次握手：建立連線時,用戶端傳送SYN包(syn=j)到伺服器,並進入SYN_SEND狀態,等待伺服器確認；
第二次握手：伺服器收到SYN包,必須確認客戶的SYN（ack=j+1）,同時自己也傳送一個SYN包（syn=k）,即SYN+ACK包,此時伺服器進入SYN_RECV狀態；
第三次握手：用戶端收到伺服器的SYN＋ACK包,向伺服器傳送確認包ACK(ack=k+1),此包傳送完畢,用戶端和伺服器進入ESTABLISHED狀態,完成三次握手.

TCP四次揮手

TCP的連線的拆除需要傳送四個包，因此稱為四次揮手(four-way handshake)。
用戶端或伺服器均可主動發起揮手動作，在socket程式設計中，任何一方執行close()操作即可產生揮手操作。

四次揮手過程

step1：第一次揮手
首先，用戶端傳送一個FIN，用來關閉用戶端到伺服器的資料傳送，然後等待伺服器的確認。其中終止標誌位FIN=1，序列號seq=u。

step2：第二次揮手
伺服器收到這個FIN，它傳送一個ACK，確認ack為收到的序號加一。

step3：第三次揮手
關閉伺服器到用戶端的連線，傳送一個FIN給用戶端。

step4：第四次揮手
用戶端收到FIN後，並行回一個ACK報文確認，並將確認序號seq設定為收到序號加一。首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。

用戶端傳送FIN後，進入終止等待狀態，伺服器收到用戶端連線釋放報文段後，就立即給用戶端傳送確認，伺服器就進入CLOSE_WAIT狀態，
此時TCP伺服器進程就通知高層應用進程，因而從用戶端到伺服器的連線就釋放了。
此時是“半關閉狀態”，即用戶端不可以傳送給伺服器，伺服器可以傳送給用戶端。
此時，如果伺服器沒有資料包傳送給用戶端，其應用程式就通知TCP釋放連線，然後傳送給用戶端連線釋放資料包，並等待確認。
用戶端傳送確認後，進入TIME_WAIT狀態，但是此時TCP連線還沒有釋放，然後經過等待計時器設定的2MSL後，才進入到CLOSE狀態。

為什麼建立連線協定是三次握手，而關閉連線卻是四次呢

這是因為伺服器端的LISTEN狀態下的SOCKET當收到SYN報文的連線請求後，它可以把ACK和SYN(ACK起應答作用，而SYN起同步作用)放在一個報文裡來傳送。

但關閉連線時，當收到對方的FIN報文通知時，它僅僅表示對方沒有資料傳送給你了；
但未必你所有的資料都全部傳送給對方了，所以你可能未必會馬上會關閉SOCKET,也即你可能還需要傳送一些資料給對方之後，再傳送FIN報文給對方來表示你同意現在可以關閉連線了，
所以它這裡的ACK報文和FIN報文多數情況下都是分開傳送的。

為什麼不能用兩次握手進行連線

我們知道，3次握手完成兩個重要的功能，既要雙方做好傳送資料的準備工作(雙方都知道彼此已準備好)，也要允許雙方就初始序列號進行協商，這個序列號在握手過程中被傳送和確認。

現在把三次握手改成僅需要兩次握手，死鎖是可能發生的。
作為例子，考慮計算機S和C之間的通訊，假定C給S傳送一個連線請求分組，S收到了這個分組，並行 送了確認應答分組。
按照兩次握手的協定，S認為連線已經成功地建立了，可以開始傳送資料分組。
可是，C在S的應答分組在傳輸中被丟失的情況下，將不知道S 是否已準備好，不知道S建立什麼樣的序列號，C甚至懷疑S是否收到自己的連線請求分組。
在這種情況下，C認為連線還未建立成功，將忽略S發來的任何資料分 組，只等待連線確認應答分組。
而S在發出的分組超時後，重複傳送同樣的分組。這樣就形成了死鎖。 

為什麼TIME_WAIT狀態需要經過2MSL(最大報文段生存時間)才能返回到CLOSE狀態？

雖然按道理，四個報文都傳送完畢，我們可以直接進入CLOSE狀態了，但是我們必須假象網路是不可靠的，有可以最後一個ACK丟失。
所以TIME_WAIT狀態就是用來重發可能丟失的ACK報文。

TCP超時重傳

異常網路狀態下（開始出現超時或丟包），TCP控制資料傳輸以保證其承若的可靠服務
TCP服務必須能夠重傳超時時間內未收到的TCP報文段
為此，TCP模組為每一個TCP報文段都維護一個重傳定時器，該定時器在TCP報文段第一次被傳送時啟動
與TCP超時重傳相關的兩個核心引數：
/proc/sys/net/ipv4/tcp_retries1：最少執行的重傳次數
proc/sys/net/ipv4/tcp_retries2：做多執行的重傳次數預設值15

TCP協定和UDP協定的區別是什麼

    TCP協定是有連線的，有連線的意思是開始傳輸實際資料之前TCP的用戶端和伺服器端必須通過三次握手建立連線，對談結束之後也要結束連線。
    而UDP是無連線的 

    TCP協定保證資料按序傳送，按序到達，提供超時重傳來保證可靠性，
    但是UDP不保證按序到達，甚至不保證到達，只是努力交付，即便是按序傳送的序列，也不保證按序送到。

CP協定PORT

傳輸層通過port號，確認應用層協定
tcp ：傳輸控制協定，面向連線協定：通訊前需要建立虛擬鏈路：結束後拆除鏈路  0-65535
udp:無連線的協定  0-65535
IANA：網際網路數位分配機構（負責域名；數位資源；協定分配）
    0-1023：系統埠或特權埠（僅管理員可用）總所周知，永久的分配個固定 的系統應用使用  22（ssh）80(http) 443(https)
    1024-49125:    使用者埠或註冊埠但要求不嚴格
    49152-65535：動態埠或私有埠，用戶端程式隨機使用埠
    其範圍的定義：/proc/sys/net/ipv4/ip_local_port_range

Internet協定特徵

執行與OSI網路層
面向無連線的協定
獨立處理封包
分層編址
盡力而為傳輸
無資料恢復功能

單播多播廣播

    處地址類別外，還可以根據傳輸的資訊特徵將IP地址分為單播，多播，廣播。主機使用IP地址進行一對一（單播），一對多（多播），或一對所有（廣播）的通訊
            單播：單播地址是IP網路中最常見的。包含單播地址的分組傳送給特定主機，
            多播：多播地址讓原裝置能夠將元分組傳送給一組裝置
            廣播：廣播分組的目標IP地址的主機部分全為1 ，這以為著本地網路（廣播域）中的所有主機都將接收並檢視該分組

ARP地址解析協定：

IP PDU報頭

版本：占4位元，指IP協定的版本目前的IP協定版本號為4
首部長度：占4位元，可表示的最大數值是15個單位，一個單位為四個位元組，因此IP的首部長度的最大數值是60個位元組
區分服務：占8位元用來獲得更好的服務，在舊標準中叫做服務型別，到實際上未被使用過，後改名為區分服務，只有在使用區分服務時，這個欄位才起作用，一般的情況下都不使用
總長度：占16位元，指首部和資料之和的長度，單位為位元組，因此資料包的最大長度為65535位元組，總長度不能超過最大傳輸單元MTU
標識：占16位元它是一個計數器，通常,沒傳送一個只有當報文，該值會加1 ，也用於封包分片，自同一個包的若干分片中，該值是相同的
標誌：占3位，目前只有後兩位有意義
DF：中間的一位，只有當DF=1是才允許分片。
MF：最高位,MF=1表示後面還有分片，表示最後一個分片
片偏移：占12位元，指較長的分組 在分片後，該分片在原分組中的相對位置，片偏移以8個位元組為偏移單位
生存時間：占8位元，即為TTL資料包在網路中可通過的路由器的最大值，TTL欄位是有傳送端初始設定一個8bit位元組，推薦的初始值由分配數位RFC指定，當前值為64 傳送ICMP回顯應答是=時經常把TTL設為最大值255
協定：占8位元，指出此資料寶攜帶資料使用何種協定以便目的主機的IP層將資料部分上交給哪個處理過程，1表示ICMP協定，2表示為IGMP協定 ，6表示TCP協定，17表示為UDP協定
首部檢驗和：占16位元，只驗證資料包的首部不檢驗資料部分，這裡不採用CRC檢驗碼而採用簡單的計算方法
原地址和目標地址：都各自占4個位元組，分別記錄原地址和目的地址

IP地址

他們可唯一標識IP網路中的每一台裝置
每台主機（計算機，網路裝置，外圍裝置）必須具有唯一的地址
IP地址有兩部分組成：
    標識網路
    每個網路分配一個ID
主機ID：
    標識單個主機
    有組織非配給各裝置

IP地址分類

A類：
    0 000 0000 - 0111 1111:1-127
    網路數：126,127
    每個網路中的主機數：2^24-2
    預設子網掩碼：255.0.0.0
    私網地址：10.0.0.0
B類：
    10 00 0000 - 10 11 1111： 128-191
    網路數：2^14
    每個網路中的主機數：2^16 -2
    預設子網掩碼：255.255.0.0
    私網地址：172.16.0.0-172.31.0.0
C類：
    110 0 0000 -110 1 1111:192-223
    網路數：2^21
    每個網路中的主機數:2^8-2
    預設子網掩碼：255,255,255.0
D類：組播
E類：240-255

Linux公社的RSS地址：https://www.linuxidc.com/rssFeed.aspx

本文永久更新連結地址：https://www.linuxidc.com/Linux/2018-09/153854.htm