TFTP是基于文本的協(xié)議，各字段之間用字節(jié)0分隔，開頭的00 01表示請(qǐng)求讀取一個(gè)文件，接下來的各字段是：

c:\qwerq.qwe

blksize 512

timeout 10

tsize 0

一般的網(wǎng)絡(luò)通信都是像TFTP協(xié)議這樣，通信的雙方分別是客戶端和服務(wù)器，客戶端主動(dòng)發(fā)起請(qǐng)求（上面的例子就是客戶端發(fā)起的請(qǐng)求幀），而服務(wù)器被動(dòng)地等待、接收和應(yīng)答請(qǐng)求?？蛻舳说腎P地址和端口號(hào)唯一標(biāo)識(shí)了該主機(jī)上的TFTP客戶端進(jìn)程，服務(wù)器的IP地址和端口號(hào)唯一標(biāo)識(shí)了該主機(jī)上的TFTP服務(wù)進(jìn)程，由于客戶端是主動(dòng)發(fā)起請(qǐng)求的一方，它必須知道服務(wù)器的IP地址和TFTP服務(wù)進(jìn)程的端口號(hào)，所以，一些常見的網(wǎng)絡(luò)協(xié)議有默認(rèn)的服務(wù)器端口，例如HTTP服務(wù)默認(rèn)TCP協(xié)議的80端口，F(xiàn)TP服務(wù)默認(rèn)TCP協(xié)議的21端口，TFTP服務(wù)默認(rèn)UDP協(xié)議的69端口（如上例所示）。在使用客戶端程序時(shí)，必須指定服務(wù)器的主機(jī)名或IP地址，如果不明確指定端口號(hào)則采用默認(rèn)端口，請(qǐng)讀者查閱ftp、tftp等程序的man page了解如何指定端口號(hào)。/etc/services中列出了所有well-known的服務(wù)端口和對(duì)應(yīng)的傳輸層協(xié)議，這是由IANA（Internet Assigned Numbers Authority）規(guī)定的，其中有些服務(wù)既可以用TCP也可以用UDP，為了清晰，IANA規(guī)定這樣的服務(wù)采用相同的TCP或UDP默認(rèn)端口號(hào)，而另外一些TCP和UDP的相同端口號(hào)卻對(duì)應(yīng)不同的服務(wù)。

很多服務(wù)有well-known的端口號(hào)，然而客戶端程序的端口號(hào)卻不必是well-known的，往往是每次運(yùn)行客戶端程序時(shí)由系統(tǒng)自動(dòng)分配一個(gè)空閑的端口號(hào)，用完就釋放掉，稱為ephemeral的端口號(hào)，想想這是為什么。

前面提過，UDP協(xié)議不面向連接，也不保證傳輸?shù)目煽啃裕纾?/p>

發(fā)送端的UDP協(xié)議層只管把應(yīng)用層傳來的數(shù)據(jù)封裝成段交給IP協(xié)議層就算完成任務(wù)了，如果因?yàn)榫W(wǎng)絡(luò)故障該段無法發(fā)到對(duì)方，UDP協(xié)議層也不會(huì)給應(yīng)用層返回任何錯(cuò)誤信息。

接收端的UDP協(xié)議層只管把收到的數(shù)據(jù)根據(jù)端口號(hào)交給相應(yīng)的應(yīng)用程序就算完成任務(wù)了，如果發(fā)送端發(fā)來多個(gè)數(shù)據(jù)包并且在網(wǎng)絡(luò)上經(jīng)過不同的路由，到達(dá)接收端時(shí)順序已經(jīng)錯(cuò)亂了，UDP協(xié)議層也不保證按發(fā)送時(shí)的順序交給應(yīng)用層。

通常接收端的UDP協(xié)議層將收到的數(shù)據(jù)放在一個(gè)固定大小的緩沖區(qū)中等待應(yīng)用程序來提取和處理，如果應(yīng)用程序提取和處理的速度很慢，而發(fā)送端發(fā)送的速度很快，就會(huì)丟失數(shù)據(jù)包，UDP協(xié)議層并不報(bào)告這種錯(cuò)誤。

因此，使用UDP協(xié)議的應(yīng)用程序必須考慮到這些可能的問題并實(shí)現(xiàn)適當(dāng)?shù)慕鉀Q方案，例如等待應(yīng)答、超時(shí)重發(fā)、為數(shù)據(jù)包編號(hào)、流量控制等。一般使用UDP協(xié)議的應(yīng)用程序?qū)崿F(xiàn)都比較簡單，只是發(fā)送一些對(duì)可靠性要求不高的消息，而不發(fā)送大量的數(shù)據(jù)。例如，基于UDP的TFTP協(xié)議一般只用于傳送小文件（所以才叫trivial的ftp），而基于TCP的FTP協(xié)議適用于各種文件的傳輸。下面看TCP協(xié)議如何用面向連接的服務(wù)來代替應(yīng)用程序解決傳輸?shù)目煽啃詥栴}。

7. TCP協(xié)議

7.1. 段格式

TCP的段格式如下圖所示（該圖出自[TCPIP]）。

36.12. TCP段格式

和UDP協(xié)議一樣也有源端口號(hào)和目的端口號(hào)，通訊的雙方由IP地址和端口號(hào)標(biāo)識(shí)。32位序號(hào)、32位確認(rèn)序號(hào)、窗口大小稍后詳細(xì)解釋。4位首部長度和IP協(xié)議頭類似，表示TCP協(xié)議頭的長度，以4字節(jié)為單位，因此TCP協(xié)議頭最長可以是4×15=60字節(jié)，如果沒有選項(xiàng)字段，TCP協(xié)議頭最短20字節(jié)。URG、ACK、PSH、RST、SYN、FIN是六個(gè)控制位，本節(jié)稍后將解釋SYN、ACK、FIN、RST四個(gè)位，其它位的解釋從略。16位檢驗(yàn)和將TCP協(xié)議頭和數(shù)據(jù)都計(jì)算在內(nèi)。緊急指針和各種選項(xiàng)的解釋從略。

7.2. 通訊時(shí)序

下圖是一次TCP通訊的時(shí)序圖。

36.13. TCP連接建立斷開

在這個(gè)例子中，首先客戶端主動(dòng)發(fā)起連接、發(fā)送請(qǐng)求，然后服務(wù)器端響應(yīng)請(qǐng)求，然后客戶端主動(dòng)關(guān)閉連接。兩條豎線表示通訊的兩端，從上到下表示時(shí)間的先后順序，注意，數(shù)據(jù)從一端傳到網(wǎng)絡(luò)的另一端也需要時(shí)間，所以圖中的箭頭都是斜的。雙方發(fā)送的段按時(shí)間順序編號(hào)為1-10，各段中的主要信息在箭頭上標(biāo)出，例如段2的箭頭上標(biāo)著SYN, 8000(0), ACK 1001, <mss 1024>，表示該段中的SYN位置1，32位序號(hào)是8000，該段不攜帶有效載荷（數(shù)據(jù)字節(jié)數(shù)為0），ACK位置1，32位確認(rèn)序號(hào)是1001，帶有一個(gè)mss選項(xiàng)值為1024。

建立連接的過程：

客戶端發(fā)出段1，SYN位表示連接請(qǐng)求。序號(hào)是1000，這個(gè)序號(hào)在網(wǎng)絡(luò)通訊中用作臨時(shí)的地址，每發(fā)一個(gè)數(shù)據(jù)字節(jié)，這個(gè)序號(hào)要加1，這樣在接收端可以根據(jù)序號(hào)排出數(shù)據(jù)包的正確順序，也可以發(fā)現(xiàn)丟包的情況，另外，規(guī)定SYN位和FIN位也要占一個(gè)序號(hào)，這次雖然沒發(fā)數(shù)據(jù)，但是由于發(fā)了SYN位，因此下次再發(fā)送應(yīng)該用序號(hào)1001。mss表示最大段尺寸，如果一個(gè)段太大，封裝成幀后超過了鏈路層的最大幀長度，就必須在IP層分片，為了避免這種情況，客戶端聲明自己的最大段尺寸，建議服務(wù)器端發(fā)來的段不要超過這個(gè)長度。

服務(wù)器發(fā)出段2，也帶有SYN位，同時(shí)置ACK位表示確認(rèn)，確認(rèn)序號(hào)是1001，表示"我接收到序號(hào)1000及其以前所有的段，請(qǐng)你下次發(fā)送序號(hào)為1001的段"，也就是應(yīng)答了客戶端的連接請(qǐng)求，同時(shí)也給客戶端發(fā)出一個(gè)連接請(qǐng)求，同時(shí)聲明最大尺寸為1024。

客戶端發(fā)出段3，對(duì)服務(wù)器的連接請(qǐng)求進(jìn)行應(yīng)答，確認(rèn)序號(hào)是8001。

在這個(gè)過程中，客戶端和服務(wù)器分別給對(duì)方發(fā)了連接請(qǐng)求，也應(yīng)答了對(duì)方的連接請(qǐng)求，其中服務(wù)器的請(qǐng)求和應(yīng)答在一個(gè)段中發(fā)出，因此一共有三個(gè)段用于建立連接，稱為”’三方握手（three-way-handshake）”’。在建立連接的同時(shí)，雙方協(xié)商了一些信息，例如雙方發(fā)送序號(hào)的初始值、最大段尺寸等。

在TCP通訊中，如果一方收到另一方發(fā)來的段，讀出其中的目的端口號(hào)，發(fā)現(xiàn)本機(jī)并沒有任何進(jìn)程使用這個(gè)端口，就會(huì)應(yīng)答一個(gè)包含RST位的段給另一方。例如，服務(wù)器并沒有任何進(jìn)程使用8080端口，我們卻用telnet客戶端去連接它，服務(wù)器收到客戶端發(fā)來的SYN段就會(huì)應(yīng)答一個(gè)RST段，客戶端的telnet程序收到RST段后報(bào)告錯(cuò)誤Connection refused：

$ telnet 192.168.0.200 8080

Trying 192.168.0.200...

telnet: Unable to connect to remote host: Connection refused

數(shù)據(jù)傳輸?shù)倪^程：

客戶端發(fā)出段4，包含從序號(hào)1001開始的20個(gè)字節(jié)數(shù)據(jù)。

服務(wù)器發(fā)出段5，確認(rèn)序號(hào)為1021，對(duì)序號(hào)為1001-1020的數(shù)據(jù)表示確認(rèn)收到，同時(shí)請(qǐng)求發(fā)送序號(hào)1021開始的數(shù)據(jù)，服務(wù)器在應(yīng)答的同時(shí)也向客戶端發(fā)送從序號(hào)8001開始的10個(gè)字節(jié)數(shù)據(jù)，這稱為piggyback。

客戶端發(fā)出段6，對(duì)服務(wù)器發(fā)來的序號(hào)為8001-8010的數(shù)據(jù)表示確認(rèn)收到，請(qǐng)求發(fā)送序號(hào)8011開始的數(shù)據(jù)。

在數(shù)據(jù)傳輸過程中，ACK和確認(rèn)序號(hào)是非常重要的，應(yīng)用程序交給TCP協(xié)議發(fā)送的數(shù)據(jù)會(huì)暫存在TCP層的發(fā)送緩沖區(qū)中，發(fā)出數(shù)據(jù)包給對(duì)方之后，只有收到對(duì)方應(yīng)答的ACK段才知道該數(shù)據(jù)包確實(shí)發(fā)到了對(duì)方，可以從發(fā)送緩沖區(qū)中釋放掉了，如果因?yàn)榫W(wǎng)絡(luò)故障丟失了數(shù)據(jù)包或者丟失了對(duì)方發(fā)回的ACK段，經(jīng)過等待超時(shí)后TCP協(xié)議自動(dòng)將發(fā)送緩沖區(qū)中的數(shù)據(jù)包重發(fā)。

這個(gè)例子只描述了最簡單的一問一答的情景，實(shí)際的TCP數(shù)據(jù)傳輸過程可以收發(fā)很多數(shù)據(jù)段，雖然典型的情景是客戶端主動(dòng)請(qǐng)求服務(wù)器被動(dòng)應(yīng)答，但也不是必須如此，事實(shí)上TCP協(xié)議為應(yīng)用層提供了全雙工（full-duplex）的服務(wù)，雙方都可以主動(dòng)甚至同時(shí)給對(duì)方發(fā)送數(shù)據(jù)。

如果通訊過程只能采用一問一答的方式，收和發(fā)兩個(gè)方向不能同時(shí)傳輸，在同一時(shí)間只允許一個(gè)方向的數(shù)據(jù)傳輸，則稱為”’半雙工（half-duplex）”’，假設(shè)某種面向連接的協(xié)議是半雙工的，則只需要一套序號(hào)就夠了，不需要通訊雙方各自維護(hù)一套序號(hào)，想一想為什么。

關(guān)閉連接的過程：

客戶端發(fā)出段7，F(xiàn)IN位表示關(guān)閉連接的請(qǐng)求。

服務(wù)器發(fā)出段8，應(yīng)答客戶端的關(guān)閉連接請(qǐng)求。

服務(wù)器發(fā)出段9，其中也包含F(xiàn)IN位，向客戶端發(fā)送關(guān)閉連接請(qǐng)求。

客戶端發(fā)出段10，應(yīng)答服務(wù)器的關(guān)閉連接請(qǐng)求。

建立連接的過程是三方握手，而關(guān)閉連接通常需要4個(gè)段，服務(wù)器的應(yīng)答和關(guān)閉連接請(qǐng)求通常不合并在一個(gè)段中，因?yàn)橛羞B接半關(guān)閉的情況，這種情況下客戶端關(guān)閉連接之后就不能再發(fā)送數(shù)據(jù)給服務(wù)器了，但是服務(wù)器還可以發(fā)送數(shù)據(jù)給客戶端，直到服務(wù)器也關(guān)閉連接為止，稍后會(huì)看到這樣的例子。

7.3. 流量控制

介紹UDP時(shí)我們描述了這樣的問題：如果發(fā)送端發(fā)送的速度較快，接收端接收到數(shù)據(jù)后處理的速度較慢，而接收緩沖區(qū)的大小是固定的，就會(huì)丟失數(shù)據(jù)。TCP協(xié)議通過”’滑動(dòng)窗口（Sliding Window）”’機(jī)制解決這一問題?？聪聢D的通訊過程。

36.14. 滑動(dòng)窗口

發(fā)送端發(fā)起連接，聲明最大段尺寸是1460，初始序號(hào)是0，窗口大小是4K，表示"我的接收緩沖區(qū)還有4K字節(jié)空閑，你發(fā)的數(shù)據(jù)不要超過4K"。接收端應(yīng)答連接請(qǐng)求，聲明最大段尺寸是1024，初始序號(hào)是8000，窗口大小是6K。發(fā)送端應(yīng)答，三方握手結(jié)束。

發(fā)送端發(fā)出段4-9，每個(gè)段帶1K的數(shù)據(jù)，發(fā)送端根據(jù)窗口大小知道接收端的緩沖區(qū)滿了，因此停止發(fā)送數(shù)據(jù)。

接收端的應(yīng)用程序提走2K數(shù)據(jù)，接收緩沖區(qū)又有了2K空閑，接收端發(fā)出段10，在應(yīng)答已收到6K數(shù)據(jù)的同時(shí)聲明窗口大小為2K。

接收端的應(yīng)用程序又提走2K數(shù)據(jù)，接收緩沖區(qū)有4K空閑，接收端發(fā)出段11，重新聲明窗口大小為4K。

發(fā)送端發(fā)出段12-13，每個(gè)段帶2K數(shù)據(jù)，段13同時(shí)還包含F(xiàn)IN位。

接收端應(yīng)答接收到的2K數(shù)據(jù)（6145-8192），再加上FIN位占一個(gè)序號(hào)8193，因此應(yīng)答序號(hào)是8194，連接處于半關(guān)閉狀態(tài)，接收端同時(shí)聲明窗口大小為2K。

接收端的應(yīng)用程序提走2K數(shù)據(jù)，接收端重新聲明窗口大小為4K。

接收端的應(yīng)用程序提走剩下的2K數(shù)據(jù)，接收緩沖區(qū)全空，接收端重新聲明窗口大小為6K。

接收端的應(yīng)用程序在提走全部數(shù)據(jù)后，決定關(guān)閉連接，發(fā)出段17包含F(xiàn)IN位，發(fā)送端應(yīng)答，連接完全關(guān)閉。

上圖在接收端用小方塊表示1K數(shù)據(jù)，實(shí)心的小方塊表示已接收到的數(shù)據(jù)，虛線框表示接收緩沖區(qū)，因此套在虛線框中的空心小方塊表示窗口大小，從圖中可以看出，隨著應(yīng)用程序提走數(shù)據(jù)，虛線框是向右滑動(dòng)的，因此稱為滑動(dòng)窗口。

從這個(gè)例子還可以看出，發(fā)送端是一K一K地發(fā)送數(shù)據(jù)，而接收端的應(yīng)用程序可以兩K兩K地提走數(shù)據(jù)，當(dāng)然也有可能一次提走3K或6K數(shù)據(jù)，或者一次只提走幾個(gè)字節(jié)的數(shù)據(jù)，也就是說，應(yīng)用程序所看到的數(shù)據(jù)是一個(gè)整體，或說是一個(gè)流（stream），在底層通訊中這些數(shù)據(jù)可能被拆成很多數(shù)據(jù)包來發(fā)送，但是一個(gè)數(shù)據(jù)包有多少字節(jié)對(duì)應(yīng)用程序是不可見的，因此TCP協(xié)議是面向流的協(xié)議。而UDP是面向消息的協(xié)議，每個(gè)UDP段都是一條消息，應(yīng)用程序必須以消息為單位提取數(shù)據(jù)，不能一次提取任意字節(jié)的數(shù)據(jù)，這一點(diǎn)和TCP是很不同的。

以上就是腳本之家小編為大家介紹的TCP/IP協(xié)議棧與數(shù)據(jù)包封裝圖文教程，需要的朋友快樂看看吧，想了解更多精彩教程請(qǐng)繼續(xù)關(guān)注腳本之家！

最新評(píng)論