常用網絡協議簡介

常用網絡協議簡介

作者：caoshen_vip
1.TCP協議

TCP（Transmission Control Protocol 傳輸控制協議）是一種面向連接（連接導向）的、可靠的、基於IP的傳輸層協議，由IETF的RFC 793說明（specified）。TCP在IP報文的協議號是6。

當應用層向TCP層發送用於網間傳輸的、用8位字節表示的數據流，TCP則把數據流分割成適當長度的報文段，最大傳輸段大小（MSS）通常受該計算機連接的網絡的數據鏈路層的最大傳送單元（MTU）限制。之後TCP把數據包傳給IP層，由它來通過網絡將包傳送給接收端實體的TCP層。
TCP爲了保證報文傳輸的可靠[1] ，就給每個包一個序號，同時序號也保證了傳送到接收端實體的包的按序接收。然後接收端實體對已成功收到的字節發回一個相應的確認(ACK)；如果發送端實體在合理的往返時延(RTT)內未收到確認，那麼對應的數據（假設丟失了）將會被重傳。
在數據正確性與合法性上，TCP用一個校驗和函數來檢驗數據是否有錯誤，在發送和接收時都要計算校驗和；同時可以使用md5認證對數據進行加密。
在保證可靠性上，採用超時重傳和捎帶確認機制。
在流量控制上，採用滑動窗口協議，協議中規定，對於窗口內未經確認的分組需要重傳。
在擁塞控制上，採用廣受好評的TCP擁塞控制算法（也稱AIMD算法）。該算法主要包括三個主要部分：1）加性增、乘性減；2）慢啓動；3）對超時事件做出反應。
TCP/IP

TCP/IP(Transmission Control Protocol/Internet Protocol) 即傳輸控制協議/網間協議，是一個工業標準的協議集，它是爲廣域網（WAN）設計的。它是由ARPANET網的研究機構發展起來的。
TCP/IP的標準在一系列稱爲RFC的文檔中公佈。文檔由技術專家、特別工作組、或RFC編輯修訂。公佈一個文檔時，該文檔被賦予一個RFC編號，如RFC959（FTP的說明文檔）、RFC793（TCP的說明文檔）、RFC791（IP的說明文檔）等。最初的RFC一直保留而從來不會被更新，如果修改了該文檔，則該文檔又以一個新號碼公佈。因此，重要的是要確認你擁有了關於某個專題的最新RFC文檔。通常在RFC的開頭部分，有相關RFC的更新(update)、修改（errata）、作廢（obsolete）信息，提示讀者信息的時效性。
UDP

UDP協議的全稱是用戶數據報協議，在網絡中它與TCP協議一樣用於處理數據包，是一種無連接的協議。在OSI模型中，在第四層——傳輸層，處於IP層的上一層。UDP有不提供數據包分組、組裝和不能對數據包進行排序的缺點，也就是說，當報文發送之後，是無法得知其是否安全完整到達的。UDP用來支持那些需要在計算機之間傳輸數據的網絡應用。包括網絡視頻會議系統在內的衆多的客戶/服務器模式的網絡應用都需要使用UDP協議。UDP協議從問世至今已經被使用了很多年，雖然其最初的光彩已經被一些類似協議所掩蓋，但是即使是在今天UDP仍然不失爲一項非常實用和可行的網絡傳輸層協議。　

TCP與UDP的區別

TCP協議面向連接，UDP協議面向非連接；
TCP協議傳輸速度慢，UDP協議傳輸速度快
TCP有丟包重傳機制，UDP沒有；
TCP協議保證數據正確性，UDP協議可能丟包；
3TCP首部
編輯

TCP的首部格式圖右圖所示：
—Source Port是源端口，16位。
TCP首部
TCP首部
—Destination Port是目的端口，16位。
—Sequence Number是發送數據包中的第一個字節的序列號，32位。
—Acknowledgment Number是確認序列號，32位。
—Data Offset是數據偏移，4位，該字段的值是TCP首部（包括選項）長度乘以4。
—標誌位： 6位，URG表示Urgent Pointer字段有意義：
ACK表示Acknowledgment Number字段有意義
PSH表示Push功能，RST表示復位TCP連接
SYN表示SYN報文（在建立TCP連接的時候使用）
FIN表示沒有數據需要發送了（在關閉TCP連接的時候使用）
Window表示接收緩衝區的空閒空間，16位，用來告訴TCP連接對端自己能夠接收的最大數據長度。
—Checksum是校驗和，16位。
—Urgent Pointers是緊急指針，16位，只有URG標誌位被設置時該字段纔有意義，表示緊急數據相對序列號（Sequence Number字段的值）的偏移。
4TCP連接
編輯

TCP連接建立

TCP是因特網中的傳輸層協議，使用三次握手協議建立連接。當主動方發出SYN連接請求後，等待對方回答
TCP的三次握手
TCP的三次握手
SYN+ACK[1] ，並最終對對方的 SYN 執行 ACK 確認。這種建立連接的方法可以防止產生錯誤的連接，TCP使用的流量控制協議是可變大小的滑動窗口協議。
TCP三次握手的過程如下：
客戶端發送SYN（SEQ=x）報文給服務器端，進入SYN_SEND狀態。
服務器端收到SYN報文，迴應一個SYN （SEQ=y）ACK(ACK=x+1）報文，進入SYN_RECV狀態。
客戶端收到服務器端的SYN報文，迴應一個ACK(ACK=y+1）報文，進入Established狀態。
三次握手完成，TCP客戶端和服務器端成功地建立連接，可以開始傳輸數據了。
TCP連接終止

我的手機 2018/3/17 15:33:13
建立一個連接需要三次握手，而終止一個連接要經過四次握手，這是由TCP的半關閉（half-close）造成的。具體過程如下圖所示。
TCP連接的終止
TCP連接的終止
(1) 某個應用進程首先調用close，稱該端執行“主動關閉”（active close）。該端的TCP於是發送一個FIN分節，表示數據發送完畢。
(2) 接收到這個FIN的對端執行 “被動關閉”（passive close），這個FIN由TCP確認。
注意：FIN的接收也作爲一個文件結束符（end-of-file）傳遞給接收端應用進程，放在已排隊等候該應用進程接收的任何其他數據之後，因爲，FIN的接收意味着接收端應用進程在相應連接上再無額外數據可接收。
(3) 一段時間後，接收到這個文件結束符的應用進程將調用close關閉它的套接字。這導致它的TCP也發送一個FIN。
(4) 接收這個最終FIN的原發送端TCP（即執行主動關閉的那一端）確認這個FIN。
既然每個方向都需要一個FIN和一個ACK，因此通常需要4個分節。
注意：
(1) “通常”是指，某些情況下，步驟1的FIN隨數據一起發送，另外，步驟2和步驟3發送的分節都出自執行被動關閉那一端，有可能被合併成一個分節。
(2) 在步驟2與步驟3之間，從執行被動關閉一端到執行主動關閉一端流動數據是可能的，這稱爲“半關閉”（half-close）。
(3) 當一個Unix進程無論自願地（調用exit或從main函數返回）還是非自願地（收到一個終止本進程的信號）終止時，所有打開的描述符都被關閉，這也導致仍然打開的任何TCP連接上也發出一個FIN。
無論是客戶還是服務器，任何一端都可以執行主動關閉。通常情況是，客戶執行主動關閉，但是某些協議，例如，HTTP/1.0卻由服務器執行主動關閉。
5TCP如何提供可靠性
編輯

　TCP提供一種面向連接的、可靠的字節流服務。面向連接意味着兩個使用TCP的應用（通常是一個客戶和一個服務器）在彼此交換數據包之前必須先建立一個TCP連接。這一過程與打電話很相似，先撥號振鈴，等待對方摘機說“喂”，然後才說明是誰。在一個TCP連接中，僅有兩方進行彼此通信。廣播和多播不能用於TCP。
TCP通過下列方式來提供可靠性：
1．應用數據被分割成TCP認爲最適合發送的數據塊。這和UDP完全不同，應用程序產生的數據長度將保持不變。由TCP傳遞給IP的信息單位稱爲報文段或段（segment）。
2．當TCP發出一個段後，它啓動一個定時器，等待目的端確認收到這個報文段。如果不能及時收到一個確認，將重發這個報文段。當TCP收到發自TCP連接另一端的數據，它將發送一個確認。TCP有延遲確認的功能，在此功能沒有打開，則是立即確認。功能打開，則由定時器觸發確認時間點。
3．TCP將保持它首部和數據的檢驗和。這是一個端到端的檢驗和，目的是檢測數據在傳輸過程中的任何變化。如果收到段的檢驗和有差錯，TCP將丟棄這個報文段和不確認收到此報文段（希望發端超時並重發）。
4．既然TCP報文段作爲IP數據報來傳輸，而IP數據報的到達可能會失序，因此TCP報文段的到達也可能會失序。如果必要，TCP將對收到的數據進行重新排序，將收到的數據以正確的順序交給應用層。
5．既然IP數據報會發生重複，TCP的接收端必須丟棄重複的數據。
6．TCP還能提供流量控制。TCP連接的每一方都有固定大小的緩衝空間。TCP的接收端只允許另一端發送接收端緩衝區所能接納的數據。這將防止較快主機致使較慢主機的緩衝區溢出。
兩個應用程序通過TCP連接交換8bit字節構成的字節流。TCP不在字節流中插入記錄標識符。我們將這稱爲字節流服務（bytestreamservice）。如果一方的應用程序先傳10字節，又傳20字節，再傳50字節，連接的另一方將無法瞭解發方每次發送了多少字節。只要自己的接收緩存沒有塞滿，TCP 接收方將有多少就收多少。一端將字節流放到TCP連接上，同樣的字節流將出現在TCP連接的另一端。
另外，TCP對

我的手機 2018/3/17 15:33:40
接計算機網絡
字節流的內容不作任何解釋。TCP不知道傳輸的數據字節流是二進制數據，還是ASCⅡ字符、EBCDIC字符或者其他類型數據。對字節流的解釋由TCP連接雙方的應用層解釋。
這種對字節流的處理方式與Unix操作系統對文件的處理方式很相似。Unix的內核對一個應用讀或寫的內容不作任何解釋，而是交給應用程序處理。對Unix的內核來說，它無法區分一個二進制文件與一個文本文件。
2.HTTP協議
超文本傳送協議 (HTTP-Hypertext transfer protocol) 是一種詳細規定了瀏覽器和萬維網服務器之間互相通信的規則，通過因特網傳送萬維網文檔的數據傳送協議。

HTTP協議的主要特點可概括如下：
1、支持客戶/服務器模式。支持基本認證[11] 和安全認證(見後文《安全協議》)。
http 協議 簡介
http 協議 簡介
2、 簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不同。由於HTTP協議簡單，使得HTTP服務器的程序規模小，因而通信速度很快。
3、靈活：HTTP允許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
4、HTTP 0.9和1.0使用非持續連接：限制每次連接只處理一個請求，服務器處理完客戶的請求，並收到客戶的應答後，即斷開連接。採用這種方式可以節省傳輸時間。
HTTP 1.1使用持續連接：不必爲每個web對象創建一個新的連接，一個連接可以傳送多個對象。
5、無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味着如果後續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大[12] 。
另一方面，在服務器不需要先前信息時它的應答就較快。
4請求信息
編輯

發出的請求信息包括以下幾個：
●請求行，例如GET /images/logo.gif HTTP/1.1，表示從/images目錄下請求logo.gif這個文件。
●（請求）頭，例如Accept-Language: en
●空行
●可選的消息體　請求行和標題必須以作爲結尾（也就是，回車然後換行）。空行內必須只有而無其他空格。在HTTP/1.1協議中，所有的請求頭，除host外，都是可選的。
5請求方法
編輯

HTTP/1.1協議中共定義了八種方法（有時也叫“動作”）來表明Request-URI指定的資源的不同操作方式：
OPTIONS - 返回服務器針對特定資源所支持的HTTP請求方法。也可以利用向Web服務器發送’*’的請求來測試服務器的功能性。
HEAD- 向服務器索要與GET請求相一致的響應，只不過響應體將不會被返回。這一方法可以在不必傳輸整個響應內容的情況下，就可以獲取包含在響應消息頭中的元信息。
GET - 向特定的資源發出請求。注意：GET方法不應當被用於產生“副作用”的操作中，例如在web app.中。其中一個原因是GET可能會被網絡蜘蛛等隨意訪問。
POST - 向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。
PUT - 向指定資源位置上傳其最新內容。
DELETE - 請求服務器刪除Request-URI所標識的資源。
TRACE- 回顯服務器收到的請求，主要用於測試或診斷。
CONNECT - HTTP/1.1協議中預留給能夠將連接改爲管道方式的代理服務器。
PATCH - 用來將局部修改應用於某一資源，添加於規範RFC5789。
方法名稱是區分大小寫的。當某個請求所針對的資源不支持對應的請求方法的時候，服務器應當返回狀態碼405（Method Not Allowed）；當服務器不認識或者不支持對應的請求方法的時候，應當返回狀態碼501（Not Implemented）。
HTTP服務器至少應該實現GET和HEAD方法，其他方法都是可選的。當然，所有的方法支持的實現都應當符合下述的方法各自的語義定義。此外，除了上述方法，特定的HTTP服務器還能夠擴展自定義的方法。
6響應頭
編輯

客戶端向服務器發送一個請求，服務器以一個狀態行作爲響應，響應的內容包括：消息協議的版本、成功或者錯誤編碼、服務器信息、實體元信息以及必要的實體內容。根據響應類別的類別，服務器響應裏可以含實體內容，但不是所有的響應都有實體內容。本節僅簡述響應頭[13] 。
響應頭第一行

響應頭第一行也稱爲狀態行，格式如下：
HTTP-Version 空格 Status-Code 空格 Reason-Phrase CRLF
HTTP- Version表示HTTP版本，例如爲HTTP/1.1。Status- Code是結果代碼，用三個數字表示。Reason-Phrase是個簡單的文本描述，解釋Status-Code的具體原因。Status-Code用於機器自動識別，Reason-Phrase用於人工理解。Status-Code的第一個數字代表響應類別，可能取5個不同的值。後兩個數字沒有分類作用。Status-Code的第一個數字代表響應的類別，後續兩位描述在該類響應下發生的具體狀況，具體請參見：HTTP狀態碼 。
響應頭域

服務器需要傳遞許多附加信息，這些信息不能全放在狀態行裏。因此，需要另行定義響應頭域，用來描述這些附加信息。響應頭域主要描述服務器的信息和Request-URI的信息。響應頭舉例、實體頭以及實體請參見： 服務器頭文件響應