計(jì)算機(jī)網(wǎng)絡(luò)七層模型中，傳輸層有兩個(gè)重要的協(xié)議：
（1）用戶數(shù)據(jù)報(bào)協(xié)議UDP (User Datagram Protocol)
（2）傳輸控制協(xié)議TCP (Transmission Control Protocol)

UDP 在傳送數(shù)據(jù)之前不需要先建立連接。遠(yuǎn)地主機(jī)的運(yùn)輸層在收到UDP 報(bào)文后，不需要給出任何確認(rèn)。雖然UDP 不提供可靠交付，但在某些情況下UDP 卻是一種最有效的工作方式。

TCP 則提供面向連接的服務(wù)。在傳送數(shù)據(jù)之前必須先建立連接，數(shù)據(jù)傳送結(jié)束后要釋放連接。TCP 不提供廣播或多播服務(wù)。由于TCP 要提供可靠的、面向連接的運(yùn)輸服務(wù)，因此不可避免地增加了許多的開(kāi)銷，如確認(rèn)、流量控制、計(jì)時(shí)器以及連接管理等。

用戶數(shù)據(jù)報(bào)協(xié)議UDP

1 UDP 概述

UDP 的主要特點(diǎn)是：

1、UDP 是無(wú)連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接。
2、UDP 使用盡最大努力交付，即不保證可靠交付，同時(shí)也不使用擁塞控制。
3、UDP 是面向報(bào)文的。UDP 沒(méi)有擁塞控制，很適合多媒體通信的要求。
4、UDP 支持一對(duì)一、一對(duì)多、多對(duì)一和多對(duì)多的交互通信。
5、UDP 的首部開(kāi)銷小，只有 8 個(gè)字節(jié)。

• UDP 是無(wú)連接的
  即發(fā)送數(shù)據(jù)之前不需要建立連接，因此減少了開(kāi)銷和發(fā)送數(shù)據(jù)之前的時(shí)延。

• UDP 使用盡最大努力交付
  即不保證可靠交付，因此主機(jī)不需要維持復(fù)雜的連接狀態(tài)表（這里面有許多參數(shù)）。

• UDP 是面向報(bào)文的
  UDP 對(duì)應(yīng)用層交下來(lái)的報(bào)文，既不合井，也不拆分，而是保留這些報(bào)文的邊界。這就是說(shuō)，應(yīng)用層交給UDP 多長(zhǎng)的報(bào)文， UDP 就照樣發(fā)送，即一次發(fā)送一個(gè)報(bào)文。因此應(yīng)用程序必須選擇合適大小的報(bào)文。若報(bào)文太長(zhǎng)， UDP 把它交給IP 層后， IP 層在傳送時(shí)可能要進(jìn)行分片，這會(huì)降低IP 層的效率。反之，若報(bào)文太短， UDP 把它交給IP 層后，會(huì)使IP 數(shù)據(jù)報(bào)的首部的相對(duì)長(zhǎng)度太太，這也降低了IP 層的效率。

• 發(fā)送方 UDP 對(duì)應(yīng)用程序交下來(lái)的報(bào)文，在添加首部后就向下交付 IP 層。UDP 對(duì)應(yīng)用層交下來(lái)的報(bào)文，既不合并，也不拆分，而是保留這些報(bào)文的邊界。

• 應(yīng)用層交給 UDP 多長(zhǎng)的報(bào)文，UDP 就照樣發(fā)送，即一次發(fā)送一個(gè)報(bào)文。

• 接收方 UDP 對(duì) IP 層交上來(lái)的 UDP 用戶數(shù)據(jù)報(bào)，在去除首部后就原封不動(dòng)地交付上層的應(yīng)用進(jìn)程，一次交付一個(gè)完整的報(bào)文。

• 應(yīng)用程序必須選擇合適大小的報(bào)文

image.png

2 UDP 的首部格式

首部手段很簡(jiǎn)單，只有8 個(gè)字節(jié)，由四個(gè)字段組成，每個(gè)字段的長(zhǎng)度都是兩個(gè)字節(jié)。

• 源端口
  在需要對(duì)方回信時(shí)選用。不需要時(shí)可用全0 。
• 目的端口
  這在終點(diǎn)交付報(bào)文時(shí)必須要使用到。
• 長(zhǎng)度
  UDP 用戶數(shù)據(jù)報(bào)的長(zhǎng)度，其最小值是8 （僅有首部）。
• 檢驗(yàn)和
  檢測(cè)UDP 用戶數(shù)據(jù)報(bào)在傳輸中是否有錯(cuò)。有錯(cuò)就去棄。

UDP的首部格式

在計(jì)算檢驗(yàn)和時(shí)，臨時(shí)把“偽首部”和 UDP 用戶數(shù)據(jù)報(bào)連接在一起。偽首部?jī)H僅是為了計(jì)算檢驗(yàn)和。

image.png

傳輸控制協(xié)議TCP

1 TCP 最主要的特點(diǎn)

1、 TCP 是面向連接的運(yùn)輸層協(xié)議。
2、每一條 TCP 連接只能有兩個(gè)端點(diǎn)(endpoint)，每一條 TCP 連接只能是點(diǎn)對(duì)點(diǎn)的（一對(duì)一）。
3、TCP 提供可靠交付的服務(wù)。
4、TCP 提供全雙工通信。
5、面向字節(jié)流。

• TCP 是面向連接的運(yùn)輸層協(xié)議
  這就是說(shuō)，應(yīng)用程序在使用TCP 協(xié)議之前，必須先建立TCP 連接。在傳送數(shù)據(jù)完畢后，必須釋放已經(jīng)建立的TCP 連接。
• 每一條TCP 連接只能是點(diǎn)對(duì)點(diǎn)的
• TCP 提供可靠交付的服務(wù)
  也就是說(shuō)，通過(guò)TCP 連接傳送的數(shù)據(jù)，無(wú)差錯(cuò)、不丟失、不重復(fù)、并且按序到達(dá)。
• TCP 提供全雙工通信
  TCP 允許通信雙方的應(yīng)用進(jìn)程在任何時(shí)候都能發(fā)送數(shù)據(jù)。TCP 連接的兩端都設(shè)有發(fā)送緩存和接收緩存，用來(lái)臨時(shí)存放雙向通信的數(shù)據(jù)。在發(fā)送時(shí)，應(yīng)用程序在把數(shù)據(jù)傳送給TCP 的緩存后，就可以做自己的事，而TCP 在合適的時(shí)候把數(shù)據(jù)發(fā)送出去。在接收時(shí)， TCP 把收到的數(shù)據(jù)放入緩存，上層的應(yīng)用進(jìn)程在合適的時(shí)候讀取緩存中的數(shù)據(jù)。
• 面向字節(jié)流
  “面向字節(jié)流”的含義是：雖然應(yīng)用程序和TCP 的交互是一次一個(gè)數(shù)據(jù)塊（大小不等），但TCP 把應(yīng)用程序交下來(lái)的數(shù)據(jù)看成僅僅是一連串的無(wú)結(jié)構(gòu)的字節(jié)流。TCP 并不知道所傳送的字節(jié)流的含義。

TCP面向流的概念.png

2 TCP 的連接

前面已經(jīng)講過(guò)，每條TCP 連接有兩個(gè)端點(diǎn)，TCP 連接的端點(diǎn)叫做套接字（socket）或插口。套接字格式如下：

套接字 socket= (IP 地址：端口號(hào)）

每一條TCP 連接唯一地被通信兩端的兩個(gè)端點(diǎn)（即兩個(gè)套接宇）所確定。即：
TCP 連接＝ {socket1, socket2} = {(IP1: port1), (IP2: port2)}

3次握手鏈接

• 第一次握手
  當(dāng)客戶端向服務(wù)器發(fā)起連接請(qǐng)求時(shí)，客戶端會(huì)發(fā)送同步序列標(biāo)號(hào)SYN到服務(wù)器，在這里我們?cè)O(shè)SYN為m，等待服務(wù)器確認(rèn)，這時(shí)客戶端的狀態(tài)為SYN_SENT。
• 第二次握手
  當(dāng)服務(wù)器收到客戶端發(fā)送的SYN后，發(fā)送確認(rèn)包ACK，這里的ACK為m+1，意思是說(shuō)“我收到了你發(fā)送的SYN了”，同時(shí)，服務(wù)器也會(huì)向客戶端發(fā)送一個(gè)SYN包，這里我們?cè)O(shè)SYN為n。這時(shí)服務(wù)器的狀態(tài)為SYN_RECV。
• 第三次握手
  客戶端收到服務(wù)器發(fā)送的SYN和ACK包后，需向服務(wù)器發(fā)送確認(rèn)包ACK，這里的ACK為n+1，發(fā)送完畢后，客戶端和服務(wù)器的狀態(tài)為ESTABLISH，即TCP連接成功。

TCP三次握手.png

4次握手釋放鏈接

斷開(kāi)連接請(qǐng)求可以由客戶端發(fā)出，也可以由服務(wù)器端發(fā)出，在這里我們稱A端向B端請(qǐng)求斷開(kāi)連接。

• 第一次揮手
  A端向B端請(qǐng)求斷開(kāi)連接時(shí)會(huì)向B端發(fā)送一個(gè)帶有FIN標(biāo)記的報(bào)文段
• 第二次揮手
  B端收到A發(fā)送的FIN后，B段現(xiàn)在可能現(xiàn)在還有數(shù)據(jù)沒(méi)有傳完，所以B端并不會(huì)馬上向A端發(fā)送FIN，而是先發(fā)送一個(gè)確認(rèn)序號(hào)ACK，意思是說(shuō)“你發(fā)的斷開(kāi)連接請(qǐng)求我收到了，但是我現(xiàn)在還有數(shù)據(jù)沒(méi)有發(fā)完，請(qǐng)稍等一下唄”。
• 第三次揮手
  當(dāng)B端的事情忙完了，那么此時(shí)B端就可以斷開(kāi)連接了，此時(shí)B端向A端發(fā)送FIN序號(hào)，意思是這次可以斷開(kāi)連接了。
• 第四次揮手
  A端收到B端發(fā)送的FIN后，會(huì)向B端發(fā)送確認(rèn)ACK，然后經(jīng)過(guò)兩個(gè)MSL時(shí)長(zhǎng)后斷開(kāi)連接。

TCP四次揮手.png

各個(gè)狀態(tài)節(jié)點(diǎn)解釋如下：

• FIN_WAIT_1:
  FIN_WAIT_1和FIN_WAIT_2狀態(tài)的真正含義都是表示等待對(duì)方的FIN報(bào)文。而這兩種狀態(tài)的區(qū)別是：FIN_WAIT_1狀態(tài)實(shí)際上是當(dāng)SOCKET在ESTABLISHED狀態(tài)時(shí)，它想主動(dòng)關(guān)閉連接，向?qū)Ψ桨l(fā)送了FIN報(bào)文，此時(shí)該SOCKET即進(jìn)入到FIN_WAIT_1狀態(tài)。而當(dāng)對(duì)方回應(yīng)ACK報(bào)文后，則進(jìn)入到FIN_WAIT_2狀態(tài)，當(dāng)然在實(shí)際的正常情況下，無(wú)論對(duì)方何種情況下，都應(yīng)該馬上回應(yīng)ACK報(bào)文，所以FIN_WAIT_1狀態(tài)一般是比較難見(jiàn)到的，而FIN_WAIT_2狀態(tài)還有時(shí)常?？梢杂胣etstat看到。（主動(dòng)方）
• CLOSE_WAIT
  這種狀態(tài)的含義其實(shí)是表示在等待關(guān)閉。怎么理解呢？當(dāng)對(duì)方close一個(gè)SOCKET后發(fā)送FIN報(bào)文給自己，你系統(tǒng)毫無(wú)疑問(wèn)地會(huì)回應(yīng)一個(gè)ACK報(bào)文給對(duì)方，此時(shí)則進(jìn)入到CLOSE_WAIT狀態(tài)。接下來(lái)呢，實(shí)際上你真正需要考慮的事情是察看你是否還有數(shù)據(jù)發(fā)送給對(duì)方，如果沒(méi)有的話，那么你也就可以 close這個(gè)SOCKET，發(fā)送FIN報(bào)文給對(duì)方，也即關(guān)閉連接。所以你在CLOSE_WAIT狀態(tài)下，需要完成的事情是等待你去關(guān)閉連接。（被動(dòng)方）
• FIN_WAIT_2
  上面已經(jīng)詳細(xì)解釋了這種狀態(tài)，實(shí)際上FIN_WAIT_2狀態(tài)下的SOCKET，表示半連接，也即有一方要求close連接，但另外還告訴對(duì)方，我暫時(shí)還有點(diǎn)數(shù)據(jù)需要傳送給你(ACK信息)，稍后再關(guān)閉連接。（主動(dòng)方）
• LAST_ACK
  這個(gè)狀態(tài)還是比較容易好理解的，它是被動(dòng)關(guān)閉一方在發(fā)送FIN報(bào)文后，最后等待對(duì)方的ACK報(bào)文。當(dāng)收到ACK報(bào)文后，也即可以進(jìn)入到CLOSED可用狀態(tài)了。（被動(dòng)方）
• TIME_WAIT
  表示收到了對(duì)方的FIN報(bào)文，并發(fā)送出了ACK報(bào)文，就等2MSL后即可回到CLOSED可用狀態(tài)了。如果FIN_WAIT_1狀態(tài)下，收到了對(duì)方同時(shí)帶FIN標(biāo)志和ACK標(biāo)志的報(bào)文時(shí)，可以直接進(jìn)入到TIME_WAIT狀態(tài)，而無(wú)須經(jīng)過(guò)FIN_WAIT_2狀態(tài)。（主動(dòng)方）
• CLOSED
  表示連接中斷。

TCP可靠傳輸?shù)墓ぷ髟?/h2>

1 停止等待協(xié)議

下面為了討論問(wèn)題的萬(wàn)便，我們僅考慮A發(fā)送數(shù)據(jù)而B(niǎo) 接收數(shù)據(jù)并發(fā)送確認(rèn)。因此A 叫做發(fā)送方，而B(niǎo) 叫做接收方。

“停止等待”就是每發(fā)送完一個(gè)分組就停止發(fā)送，等待對(duì)方的確認(rèn)。在收到確認(rèn)后再發(fā)送下一個(gè)分組。

• 無(wú)差錯(cuò)情況
  A 發(fā)送分組M1，發(fā)完就暫停發(fā)送，等待B 的確認(rèn)。B 收到了M1 就向A 發(fā)送確認(rèn)。A 在收到了對(duì)M1的確認(rèn)后，就再發(fā)送下一個(gè)分組M2。同樣，在收到B 對(duì)M2的確認(rèn)后，再發(fā)送M3

無(wú)差錯(cuò)情況.png

• 超時(shí)重傳
  B 接收M1時(shí)檢測(cè)出了差錯(cuò)就丟棄M1，其他什么也不做（不通知A 收到有差錯(cuò)的分組戶。也可能是M1 在傳輸過(guò)程中丟失了，這時(shí)B 當(dāng)然什么都不知道。在這兩種情況下， B都不會(huì)發(fā)送任何信息。可靠傳輸協(xié)議是只要超過(guò)了一段時(shí)間仍然沒(méi)有收到確認(rèn)，就認(rèn)為剛才發(fā)送的分組丟失了，因而重傳前面發(fā)送過(guò)的分組。這就叫做超時(shí)重傳。要實(shí)現(xiàn)超時(shí)重傳，就要在每發(fā)送完一個(gè)分組設(shè)置一個(gè)超時(shí)計(jì)時(shí)器。如果在超時(shí)計(jì)時(shí)器到期之前收到了對(duì)方的確認(rèn)，就撤銷己設(shè)置的超時(shí)計(jì)時(shí)器。

超時(shí)重傳.png

• 確認(rèn)丟失
  B所發(fā)送的對(duì)M1的確認(rèn)丟失了。A在設(shè)定的超時(shí)重傳時(shí)間內(nèi)沒(méi)有收到確認(rèn)，因此A 在超時(shí)計(jì)時(shí)器到期后就要重傳M1?，F(xiàn)在應(yīng)注意B的動(dòng)作。假定B又收到了重傳的分組M1。這時(shí)應(yīng)采取兩個(gè)行動(dòng)：
  （1）丟棄重復(fù)的M1
  （2）重新發(fā)送確認(rèn)

確認(rèn)丟失.png

• 確認(rèn)超時(shí)
  傳輸過(guò)程中沒(méi)有出現(xiàn)差錯(cuò)，但B 對(duì)分組M1 的確認(rèn)遲到了。A 會(huì)收到重復(fù)的確認(rèn)。對(duì)重復(fù)的確認(rèn)的處理很簡(jiǎn)單：收下后就丟棄。B 仍然會(huì)收到重復(fù)的M1 ，并且同樣要丟棄重復(fù)的M1 ，并重傳確認(rèn)分組。

確認(rèn)超時(shí).png

使用上述的確認(rèn)和重傳機(jī)制，我們就可以在不可靠的傳輸網(wǎng)絡(luò)上實(shí)現(xiàn)可靠的通信。像上述的這種可靠傳輸協(xié)議常稱為自動(dòng)重傳請(qǐng)求ARQ (Automatic Repeat reQuest）。意思是重傳的請(qǐng)求是自動(dòng)進(jìn)行的。接收方不需要請(qǐng)求發(fā)送方重傳某個(gè)出錯(cuò)的分組。

2 連續(xù)ARQ協(xié)議

滑動(dòng)窗口協(xié)議比較復(fù)雜，是TCP 協(xié)議的精髓所在。這里先給出連續(xù)ARQ 協(xié)議最基本的概念，但不涉提到許多細(xì)節(jié)問(wèn)題。詳細(xì)的滑動(dòng)窗口協(xié)議將在后面討論。

下圖表示發(fā)送方維持的發(fā)送窗口，它的意義是：位于發(fā)送窗口內(nèi)的5 個(gè)分組都可連續(xù)發(fā)送出去，而不需要等待對(duì)方的確認(rèn)。這樣，信道利用率就提高了。

連續(xù)ARQ協(xié)議工作原理.png

連續(xù)ARQ 協(xié)議規(guī)定，發(fā)送方每收到一個(gè)確認(rèn)，就把發(fā)送窗口向前滑動(dòng)一個(gè)分組的位置。

接收方一般都是采用累積確認(rèn)的方式。這就是說(shuō)，接收方不必對(duì)收到的分組逐個(gè)發(fā)送確認(rèn)，而是可以在收到幾個(gè)分組后，對(duì)按序到達(dá)的最后一個(gè)分組發(fā)送確認(rèn)，這樣就表示：到這個(gè)分組為止的所有分組都己正確收到了。

累積確認(rèn)的優(yōu)點(diǎn)是容易實(shí)現(xiàn)，即使確認(rèn)丟失也不必重傳。但缺點(diǎn)是不能向發(fā)送方反映出接收方己經(jīng)正確收到的所有分組的信息。

例如，如果發(fā)送方發(fā)送了前5 個(gè)分組，而中間的第3 個(gè)分組丟失了。這時(shí)接收方只能對(duì)前兩個(gè)分組發(fā)出確認(rèn)。發(fā)送方無(wú)法知道后面三個(gè)分組的下落，而只好把后面的三個(gè)分組都再重傳一次。這就叫做Go-back-N （回退N ），表示需要再退回來(lái)重傳己發(fā)送過(guò)的N 個(gè)分組。可見(jiàn)當(dāng)通信線路質(zhì)量不好時(shí)，連續(xù)ARQ 協(xié)議會(huì)帶來(lái)負(fù)面的影響。

TCP報(bào)文格式

image.png

• 源端口和目的端口各占2 個(gè)宇節(jié)，分別寫入源端口號(hào)和目的端口號(hào)。
• 序號(hào)
  占4 宇節(jié)，TCP 是面向字節(jié)流的。在一個(gè)TCP 連接中傳送的宇節(jié)流中的每一個(gè)字節(jié)都按順序編號(hào)。首部中的序號(hào)字段值則指的是本報(bào)文段所發(fā)送的數(shù)據(jù)的第一個(gè)字節(jié)的序號(hào)。例如，一報(bào)文段的序號(hào)字段值是301 ，而攜帶的數(shù)據(jù)共有100字節(jié)。這就表明：本報(bào)文段的數(shù)據(jù)的第一個(gè)字節(jié)的序號(hào)是301 ，最后一個(gè)字節(jié)的序號(hào)是400。
• 確認(rèn)號(hào)
  占4 字節(jié)，是期望收到對(duì)方下一個(gè)報(bào)文段的第一個(gè)數(shù)據(jù)字節(jié)的序號(hào)。例如， B 正確收到了A 發(fā)送過(guò)來(lái)的一個(gè)報(bào)文段，其序號(hào)字段值是501 ，而數(shù)據(jù)長(zhǎng)度是200 宇節(jié)（序號(hào)501 ～ 700 ），這表明B 正確收到了A 發(fā)送的到序號(hào)700 為止的數(shù)據(jù)。因此， B 期望收到A 的下一個(gè)數(shù)據(jù)序號(hào)是701 ，于是B 在發(fā)送給A 的確認(rèn)報(bào)文段中把確認(rèn)號(hào)置為701 。

• 數(shù)據(jù)偏移（即首部長(zhǎng)度）——占 4 位，它指出 TCP 報(bào)文段的數(shù)據(jù)起始處距離 TCP 報(bào)文段的起始處有多遠(yuǎn)?！皵?shù)據(jù)偏移”的單位是 32 位字（以 4 字節(jié)為計(jì)算單位）。
• 保留字段——占 6 位，保留為今后使用，但目前應(yīng)置為 0。

• 緊急 URG —— 當(dāng) URG ? 1 時(shí)，表明緊急指針字段有效。它告訴系統(tǒng)此報(bào)文段中有緊急數(shù)據(jù)，應(yīng)盡快傳送(相當(dāng)于高優(yōu)先級(jí)的數(shù)據(jù))。

• 確認(rèn) ACK —— 只有當(dāng) ACK ? 1 時(shí)確認(rèn)號(hào)字段才有效。當(dāng) ACK ? 0 時(shí)，確認(rèn)號(hào)無(wú)效。

• 推送 PSH (PuSH) —— 接收 TCP 收到 PSH = 1 的報(bào)文段，就盡快地交付接收應(yīng)用進(jìn)程，而不再等到整個(gè)緩存都填滿了后再向上交付。

• 復(fù)位 RST (ReSeT) —— 當(dāng) RST ? 1 時(shí)，表明 TCP 連接中出現(xiàn)嚴(yán)重差錯(cuò)（如由于主機(jī)崩潰或其他原因），必須釋放連接，然后再重新建立運(yùn)輸連接。

• 同步 SYN —— 同步 SYN = 1 表示這是一個(gè)連接請(qǐng)求或連接接受報(bào)文。

• 終止 FIN (FINis) —— 用來(lái)釋放一個(gè)連接。FIN ? 1 表明此報(bào)文段的發(fā)送端的數(shù)據(jù)已發(fā)送完畢，并要求釋放運(yùn)輸連接。

• 窗口
  占2 字節(jié)，窗口指的是發(fā)送本報(bào)文段的一方的接收窗口（而不是自己的發(fā)送窗口）。窗口值告訴對(duì)方：從本報(bào)文段首部中的確認(rèn)號(hào)算起，接收方目前允許對(duì)方發(fā)送的數(shù)據(jù)量。例如，設(shè)確認(rèn)號(hào)是701 ，窗口字段是1000。這就表明，從701 號(hào)算起，發(fā)送此報(bào)文段的一方還有接收1000 個(gè)字節(jié)數(shù)據(jù)（字節(jié)序號(hào)是701 - 1700 ）的接收緩存空間。
  總之，窗口字段明確指出了現(xiàn)在允許對(duì)方發(fā)送的數(shù)據(jù)量。窗口值是經(jīng)常在動(dòng)態(tài)變化著。

TCP 可靠傳輸?shù)膶?shí)現(xiàn)——以字節(jié)為單位的滑動(dòng)窗口

1 以字節(jié)為單位的滑動(dòng)窗口

TCP 的滑動(dòng)窗口是以字節(jié)為單位的?，F(xiàn)假定A 收到了B 發(fā)來(lái)的確認(rèn)報(bào)文段，其中窗口是20 （字節(jié)），而確認(rèn)號(hào)是31 （這表明B 期望收到的下一個(gè)序號(hào)是31 ，而序號(hào)30 為止的數(shù)據(jù)己經(jīng)收到了）。根據(jù)這兩個(gè)數(shù)據(jù)， A 就構(gòu)造出自己的發(fā)送窗口，其位置如圖所示。

根據(jù)B給出的窗口值，A構(gòu)造出自己的發(fā)送窗口.png

發(fā)送窗口表示：在沒(méi)有收到B 的確認(rèn)的情況下， A可以連續(xù)把窗口內(nèi)的數(shù)據(jù)都發(fā)送出去。凡是己經(jīng)發(fā)送過(guò)的數(shù)據(jù)，在未收到確認(rèn)之前都必須暫時(shí)保留，以便在超時(shí)重傳時(shí)使用。

發(fā)送窗口后沿的后面部分表示己發(fā)送且己收到了確認(rèn)。這些數(shù)據(jù)顯然不需要再保留了。而發(fā)送窗口前沿的前面部分表示不允許發(fā)送的，因?yàn)榻邮辗蕉紱](méi)有為這部分?jǐn)?shù)據(jù)保留臨時(shí)存放的緩存空間。

現(xiàn)在假定A 發(fā)送了序號(hào)為31 ～ 41 的數(shù)據(jù)。這時(shí)發(fā)送窗口位置并未改變，但發(fā)送窗口內(nèi)靠后面有11個(gè)字節(jié)（灰色小方框表示）表示己發(fā)送但未收到確認(rèn)。而發(fā)送窗口內(nèi)靠前面的9 個(gè)字節(jié)（ 42 ～ 50 ）是允許發(fā)送但尚未發(fā)送的。】

A的發(fā)送窗口.png

再看一下B 的接收窗口。B 的接收窗口大小是20，在接收窗口外面，到30 號(hào)為止的數(shù)據(jù)是已經(jīng)發(fā)送過(guò)確認(rèn)，并且己經(jīng)交付給主機(jī)了。因此在B 可以不再保留這些數(shù)據(jù)。接收窗口內(nèi)的序號(hào)（31～50）足允許接收的。B 收到了序號(hào)為32 和33 的數(shù)據(jù)，這些數(shù)據(jù)沒(méi)有按序到達(dá)，因?yàn)樾蛱?hào)為31 的數(shù)據(jù)沒(méi)有收到（也許丟失了，也許滯留在網(wǎng)絡(luò)中的某處）。請(qǐng)注意， B 只能對(duì)按序收到的數(shù)據(jù)中的最高序號(hào)給出確認(rèn)，因此B 發(fā)送的確認(rèn)報(bào)文段中的確認(rèn)號(hào)仍然是31 （即期望收到的序號(hào)）。

B的接收窗口.png

現(xiàn)在假定B 收到了序號(hào)為31 的數(shù)據(jù)，并把序號(hào)為31～33的數(shù)據(jù)交付給主機(jī)，然后B刪除這些數(shù)據(jù)。接著把接收窗口向前移動(dòng)3個(gè)序號(hào)，同時(shí)給A 發(fā)送確認(rèn)，其中窗口值仍為20，但確認(rèn)號(hào)是34，這表明B 已經(jīng)收到了到序號(hào)33 為止的數(shù)據(jù)。我們注意到，B還收到了序號(hào)為37, 38 和40 的數(shù)據(jù)，但這些都沒(méi)有按序到達(dá)，只能先存在接收窗口。A收到B的確認(rèn)后，就可以把發(fā)送窗口向前滑動(dòng)3個(gè)序號(hào)，指針P2 不動(dòng)?？梢钥闯觯F(xiàn)在A 的可用窗口增大了，可發(fā)送的序號(hào)范圍是42～53。整個(gè)過(guò)程如下圖：

A收到新的確認(rèn)號(hào)，發(fā)送窗口向前滑動(dòng).png

A 在繼續(xù)發(fā)送完序號(hào)42-53的數(shù)據(jù)后，指針P2向前移動(dòng)和P3重合。發(fā)送窗口內(nèi)的序號(hào)都已用完，但還沒(méi)有再收到確認(rèn)。由于A 的發(fā)送窗口己滿，可用窗口己減小到0，因此必須停止發(fā)送。

發(fā)送窗口內(nèi)的序號(hào)都屬于已發(fā)送但未被確認(rèn).png

2 超時(shí)重傳時(shí)間的選擇

上面已經(jīng)講到， TCP 的發(fā)送方在規(guī)定的時(shí)間內(nèi)沒(méi)有收到確認(rèn)就要重傳已發(fā)送的報(bào)文段。這種重傳的概念是很簡(jiǎn)單的，但重傳時(shí)間的選擇卻是TCP 最復(fù)雜的問(wèn)題之一。

TCP采用了一種自適應(yīng)算法，它記錄一個(gè)報(bào)文段發(fā)出的時(shí)間，以及收到相應(yīng)的確認(rèn)的時(shí)間。這兩個(gè)時(shí)間之差就是報(bào)文段的往返時(shí)間RTT，TCP 保留了RTT的一個(gè)加權(quán)平均往返時(shí)間RTTs （這又稱為平滑的往返時(shí)間， S 表示Smoothed 。因?yàn)檫M(jìn)行的是加權(quán)平均，因此得出的結(jié)果更加平滑）。每當(dāng)?shù)谝淮螠y(cè)量到RTT樣本時(shí)， RTTs值就取為所測(cè)量到的RTT樣本值。但以后每測(cè)量到一個(gè)新的RTT樣本，就按下式重新計(jì)算一次RTTs:

新的RTTs = (1 － α）×（舊的RTTs) ＋ α ×（新的RTT樣本）

α 越大表示新的RTTs受新的RTT樣本的影響越大。推薦的α 值為0.125，用這種方法得出的加權(quán)平均往返時(shí)間RTTs 就比測(cè)量出的RTT值更加平滑。

顯然，超時(shí)計(jì)時(shí)器設(shè)置的超時(shí)重傳時(shí)間RTO (RetransmissionTime-Out）應(yīng)略大于上面得出的加權(quán)平均往返時(shí)間RTTs。RFC 2988 建議使用下式計(jì)算RTO:

RTO = RTTs + 4 × RTTd

RTTd是RTT 的偏差的加權(quán)平均值，它與RTTs和新的RTT樣本之差有關(guān)。計(jì)算公式如下：

新的RTTd= (1- β）×（舊的RTTd) + β × |RTTs－新的RTT樣本|

發(fā)現(xiàn)問(wèn)題：如圖所示，發(fā)送出一個(gè)報(bào)文段。設(shè)定的重傳時(shí)間到了，還沒(méi)有收到確認(rèn)。于是重
傳報(bào)文段。經(jīng)過(guò)了一段時(shí)間后，收到了確認(rèn)報(bào)文段。現(xiàn)在的問(wèn)題是：如何判定此確認(rèn)報(bào)文段是對(duì)先發(fā)送的報(bào)文段的確認(rèn)，還是對(duì)后來(lái)重傳的報(bào)文段的確認(rèn)？

收到的確認(rèn)是對(duì)哪一個(gè)報(bào)文段的確認(rèn)？.png

若收到的確認(rèn)是對(duì)重傳報(bào)文段的確認(rèn)，但卻被源主機(jī)當(dāng)成是對(duì)原來(lái)的報(bào)文段的確認(rèn)，則這樣計(jì)算出的RTTs 和超時(shí)重傳時(shí)間RTO 就會(huì)偏大。若后面再發(fā)送的報(bào)文段又是經(jīng)過(guò)重傳后才收到確認(rèn)報(bào)文段，則按此方法得出的超時(shí)重傳時(shí)間RTO 就越來(lái)越長(zhǎng)。

若收到的確認(rèn)是對(duì)原來(lái)的報(bào)文段的確認(rèn)，但被當(dāng)成是對(duì)重傳報(bào)文段的確認(rèn)，則由此計(jì)算出的RTTs 和RTO 都會(huì)偏小。這就必然導(dǎo)致報(bào)文段過(guò)多地重傳。這樣就有可能使RTO 越來(lái)越短。

Kam 提出了一個(gè)算法：在計(jì)算加權(quán)平均RTTs 時(shí)，只要報(bào)文段重傳了就不采用其往返時(shí)間樣本。這樣得出的加權(quán)平均RTTs 和RTO 就較準(zhǔn)確。

新問(wèn)題：設(shè)想出現(xiàn)這樣的情況：報(bào)文段的時(shí)延突然增大了很多。因此在原來(lái)得出的重傳時(shí)間內(nèi)，不會(huì)收到確認(rèn)報(bào)文段。于是就重傳報(bào)文段。但根據(jù)Kam 算法，不考慮重傳的報(bào)文段的往返時(shí)間樣本。這樣，超時(shí)重傳時(shí)間就無(wú)法更新。

解決方案：對(duì)Kam 算法進(jìn)行修正，方法是z報(bào)文段每重傳一次，就把超時(shí)重傳時(shí)間RTO 增大一些。典型的做法是取新的重傳時(shí)間為2 倍的舊的重傳時(shí)間。當(dāng)不再發(fā)生報(bào)文段的重傳時(shí)，才根據(jù)上面給出的公式計(jì)算超時(shí)重傳時(shí)間。

TCP 的流量控制

1 利用滑動(dòng)窗口實(shí)現(xiàn)流量控制

流量控制（flow control）就是讓發(fā)送方的發(fā)送速率不要太快，要讓接收方來(lái)得及接收。

利用滑動(dòng)窗口機(jī)制可以很方便地在TCP 連接上實(shí)現(xiàn)對(duì)發(fā)送方的流量控制。

利用可變窗口進(jìn)行流量控制舉例.png

接收方的主機(jī)B 進(jìn)行了三次流量控制。第一次把窗口減小到rwnd =300，第二次又減到rwnd = 100 ，最后減到rwnd = 0 ，即不允許發(fā)送方再發(fā)送數(shù)據(jù)了。這種使發(fā)送方暫停發(fā)送的狀態(tài)將持續(xù)到主機(jī)B 重新發(fā)出一個(gè)新的窗口值為止。我們還應(yīng)注意到，B 向A 發(fā)送的三個(gè)報(bào)文段都設(shè)置了ACK=1，只有在ACK=1 時(shí)確認(rèn)號(hào)字段才有意義。

發(fā)生死鎖：現(xiàn)在我們考慮一種情況。上圖中， B 向A 發(fā)送了零窗口的報(bào)文段后不久， B 的接收緩存又有了一些存儲(chǔ)空間。于是B 向A 發(fā)送了rwnd = 400 的報(bào)文段。然而這個(gè)報(bào)文段在傳送過(guò)程中丟失了。A 一直等待收到B 發(fā)送的非零窗口的通知，而B(niǎo) 也一直等待A 發(fā)送的數(shù)據(jù)。如果沒(méi)有其他措施，這種互相等待的死鎖局面將一直延續(xù)下去。

解決方案：TCP 為每一個(gè)連接設(shè)有一個(gè)持續(xù)計(jì)時(shí)器（persistence timer）。只要TCP 連接的一方收到對(duì)方的零窗口通知，就啟動(dòng)持續(xù)計(jì)時(shí)器。若持續(xù)計(jì)時(shí)器設(shè)置的時(shí)間到期，就發(fā)送一個(gè)零窗口探測(cè)報(bào)文段（僅攜帶1 宇節(jié)的數(shù)據(jù)），而對(duì)方就在確認(rèn)這個(gè)探測(cè)報(bào)文段時(shí)給出了現(xiàn)在的窗口值。

2.必須考慮傳輸效率

可以用不同的機(jī)制來(lái)控制 TCP 報(bào)文段的發(fā)送時(shí)機(jī):

• 第一種機(jī)制是 TCP 維持一個(gè)變量，它等于最大報(bào)文段長(zhǎng)度 MSS。只要緩存中存放的數(shù)據(jù)達(dá)到 MSS 字節(jié)時(shí)，就組裝成一個(gè) TCP 報(bào)文段發(fā)送出去。
• 第二種機(jī)制是由發(fā)送方的應(yīng)用進(jìn)程指明要求發(fā)送報(bào)文段，即 TCP 支持的推送(push)操作。
• 第三種機(jī)制是發(fā)送方的一個(gè)計(jì)時(shí)器期限到了，這時(shí)就把當(dāng)前已有的緩存數(shù)據(jù)裝入報(bào)文段（但長(zhǎng)度不能超過(guò) MSS）發(fā)送出去。

TCP的擁塞控制

1.擁塞控制的一般原理

• 在某段時(shí)間，若對(duì)網(wǎng)絡(luò)中某資源的需求超過(guò)了該資源所能提供的可用部分，網(wǎng)絡(luò)的性能就要變壞——產(chǎn)生擁塞(congestion)。
• 出現(xiàn)資源擁塞的條件：
  • 對(duì)資源需求的總和 > 可用資源
• 若網(wǎng)絡(luò)中有許多資源同時(shí)產(chǎn)生擁塞，網(wǎng)絡(luò)的性能就要明顯變壞，整個(gè)網(wǎng)絡(luò)的吞吐量將隨輸入負(fù)荷的增大而下降。

擁塞控制與流量控制的關(guān)系：

• 擁塞控制所要做的都有一個(gè)前提，就是網(wǎng)絡(luò)能夠承受現(xiàn)有的網(wǎng)絡(luò)負(fù)荷。
• 擁塞控制是一個(gè)全局性的過(guò)程，涉及到所有的主機(jī)、所有的路由器，以及與降低網(wǎng)絡(luò)傳輸性能有關(guān)的所有因素。
• 流量控制往往指在給定的發(fā)送端和接收端之間的點(diǎn)對(duì)點(diǎn)通信量的控制。
• 流量控制所要做的就是抑制發(fā)送端發(fā)送數(shù)據(jù)的速率，以便使接收端來(lái)得及接收。

擁塞控制的一般原理：

• 擁塞控制是很難設(shè)計(jì)的，因?yàn)樗且粋€(gè)動(dòng)態(tài)的（而不是靜態(tài)的）問(wèn)題。
• 當(dāng)前網(wǎng)絡(luò)正朝著高速化的方向發(fā)展，這很容易出現(xiàn)緩存不夠大而造成分組的丟失。但分組的丟失是網(wǎng)絡(luò)發(fā)生擁塞的征兆而不是原因。
• 在許多情況下，甚至正是擁塞控制本身成為引起網(wǎng)絡(luò)性能惡化甚至發(fā)生死鎖的原因。這點(diǎn)應(yīng)特別引起重視。

開(kāi)環(huán)控制和閉環(huán)控制：

• 開(kāi)環(huán)控制方法就是在設(shè)計(jì)網(wǎng)絡(luò)時(shí)事先將有關(guān)發(fā)生擁塞的因素考慮周到，力求網(wǎng)絡(luò)在工作時(shí)不產(chǎn)生擁塞。
• 閉環(huán)控制是基于反饋環(huán)路的概念。屬于閉環(huán)控制的有以下幾種措施：
  • 監(jiān)測(cè)網(wǎng)絡(luò)系統(tǒng)以便檢測(cè)到擁塞在何時(shí)、何處發(fā)生。
  • 將擁塞發(fā)生的信息傳送到可采取行動(dòng)的地方。
  • 調(diào)整網(wǎng)絡(luò)系統(tǒng)的運(yùn)行以解決出現(xiàn)的問(wèn)題。

2.幾種擁塞控制方法

1.慢開(kāi)始和擁塞避免

• 發(fā)送方維持一個(gè)叫做擁塞窗口 cwnd (congestion window)的狀態(tài)變量。擁塞窗口的大小取決于網(wǎng)絡(luò)的擁塞程度，并且動(dòng)態(tài)地在變化。發(fā)送方讓自己的發(fā)送窗口等于擁塞窗口。如再考慮到接收方的接收能力，則發(fā)送窗口還可能小于擁塞窗口。
• 發(fā)送方控制擁塞窗口的原則是：只要網(wǎng)絡(luò)沒(méi)有出現(xiàn)擁塞，擁塞窗口就再增大一些，以便把更多的分組發(fā)送出去。但只要網(wǎng)絡(luò)出現(xiàn)擁塞，擁塞窗口就減小一些，以減少注入到網(wǎng)絡(luò)中的分組數(shù)。

慢開(kāi)始算法的原理：

• 在主機(jī)剛剛開(kāi)始發(fā)送報(bào)文段時(shí)可先設(shè)置擁塞窗口 cwnd = 1，即設(shè)置為一個(gè)最大報(bào)文段 MSS 的數(shù)值。

• 在每收到一個(gè)對(duì)新的報(bào)文段的確認(rèn)后，將擁塞窗口加 1，即增加一個(gè) MSS 的數(shù)值。

• 用這樣的方法逐步增大發(fā)送端的擁塞窗口 cwnd，可以使分組注入到網(wǎng)絡(luò)的速率更加合理。

  image

傳輸輪次：

• 使用慢開(kāi)始算法后，每經(jīng)過(guò)一個(gè)傳輸輪次，擁塞窗口 cwnd 就加倍。
• 一個(gè)傳輸輪次所經(jīng)歷的時(shí)間其實(shí)就是往返時(shí)間 RTT。
• “傳輸輪次”更加強(qiáng)調(diào)：把擁塞窗口 cwnd 所允許發(fā)送的報(bào)文段都連續(xù)發(fā)送出去，并收到了對(duì)已發(fā)送的最后一個(gè)字節(jié)的確認(rèn)。
• 例如，擁塞窗口 cwnd = 4，這時(shí)的往返時(shí)間 RTT 就是發(fā)送方連續(xù)發(fā)送 4 個(gè)報(bào)文段，并收到這 4 個(gè)報(bào)文段的確認(rèn)，總共經(jīng)歷的時(shí)間。

設(shè)置慢開(kāi)始門限狀態(tài)變量ssthresh：

• 慢開(kāi)始門限 ssthresh 的用法如下：
• 當(dāng) cwnd < ssthresh 時(shí)，使用慢開(kāi)始算法。
• 當(dāng) cwnd > ssthresh 時(shí)，停止使用慢開(kāi)始算法而改用擁塞避免算法。
• 當(dāng) cwnd = ssthresh 時(shí)，既可使用慢開(kāi)始算法，也可使用擁塞避免算法。
• 擁塞避免算法的思路是讓擁塞窗口 cwnd 緩慢地增大，即每經(jīng)過(guò)一個(gè)往返時(shí)間 RTT 就把發(fā)送方的擁塞窗口 cwnd 加 1，而不是加倍，使擁塞窗口 cwnd 按線性規(guī)律緩慢增長(zhǎng)。

當(dāng)網(wǎng)絡(luò)出現(xiàn)擁塞時(shí)：

• 無(wú)論在慢開(kāi)始階段還是在擁塞避免階段，只要發(fā)送方判斷網(wǎng)絡(luò)出現(xiàn)擁塞（其根據(jù)就是沒(méi)有按時(shí)收到確認(rèn)），就要把慢開(kāi)始門限 ssthresh 設(shè)置為出現(xiàn)擁塞時(shí)的發(fā)送方窗口值的一半（但不能小于2）。

• 然后把擁塞窗口 cwnd 重新設(shè)置為 1，執(zhí)行慢開(kāi)始算法。

• 這樣做的目的就是要迅速減少主機(jī)發(fā)送到網(wǎng)絡(luò)中的分組數(shù)，使得發(fā)生擁塞的路由器有足夠時(shí)間把隊(duì)列中積壓的分組處理完畢。

  image

加法增大：
“加法增大”是指執(zhí)行擁塞避免算法后，在收到對(duì)所有報(bào)文段的確認(rèn)后（即經(jīng)過(guò)一個(gè)往返時(shí)間），就把擁塞窗口 cwnd增加一個(gè) MSS 大小，使擁塞窗口緩慢增大，以防止網(wǎng)絡(luò)過(guò)早出現(xiàn)擁塞。

“擁塞避免”并非指完全能夠避免了擁塞。利用以上的措施要完全避免網(wǎng)絡(luò)擁塞還是不可能的。
“擁塞避免”是說(shuō)在擁塞避免階段把擁塞窗口控制為按線性規(guī)律增長(zhǎng)，使網(wǎng)絡(luò)比較不容易出現(xiàn)擁塞。

2.快重傳和快恢復(fù)

• 快重傳算法首先要求接收方每收到一個(gè)失序的報(bào)文段后就立即發(fā)出重復(fù)確認(rèn)。這樣做可以讓發(fā)送方及早知道有報(bào)文段沒(méi)有到達(dá)接收方。

• 發(fā)送方只要一連收到三個(gè)重復(fù)確認(rèn)就應(yīng)當(dāng)立即重傳對(duì)方尚未收到的報(bào)文段。

• 不難看出，快重傳并非取消重傳計(jì)時(shí)器，而是在某些情況下可更早地重傳丟失的報(bào)文段。

  image

快恢復(fù)算法 ：

• (1) 當(dāng)發(fā)送端收到連續(xù)三個(gè)重復(fù)的確認(rèn)時(shí)，就執(zhí)行“乘法減小”算法，把慢開(kāi)始門限 ssthresh 減半。但接下去不執(zhí)行慢開(kāi)始算法。
• (2)由于發(fā)送方現(xiàn)在認(rèn)為網(wǎng)絡(luò)很可能沒(méi)有發(fā)生擁塞，因此現(xiàn)在不執(zhí)行慢開(kāi)始算法，即擁塞窗口 cwnd 現(xiàn)在不設(shè)置為 1，而是設(shè)置為慢開(kāi)始門限 ssthresh 減半后的數(shù)值，然后開(kāi)始執(zhí)行擁塞避免算法（“加法增大”），使擁塞窗口緩慢地線性增大。

image

發(fā)送窗口的上限值：

• 發(fā)送方的發(fā)送窗口的上限值應(yīng)當(dāng)取為接收方窗口 rwnd 和擁塞窗口 cwnd 這兩個(gè)變量中較小的一個(gè)，即應(yīng)按以下公式確定：
  發(fā)送窗口的上限值=Min [rwnd, cwnd] (5-8)
• 當(dāng) rwnd < cwnd 時(shí)，是接收方的接收能力限制發(fā)送窗口的最大值。
• 當(dāng) cwnd < rwnd 時(shí)，則是網(wǎng)絡(luò)的擁塞限制發(fā)送窗口的最大值。

常見(jiàn)問(wèn)題解析

1 TCP連接時(shí)是三次握手，那么兩次握手可行嗎？

在《計(jì)算機(jī)網(wǎng)絡(luò)》中是這樣解釋的：已失效的連接請(qǐng)求報(bào)文段”的產(chǎn)生在這樣一種情況下：client發(fā)出的第一個(gè)連接請(qǐng)求報(bào)文段并沒(méi)有丟失，而是在某個(gè)網(wǎng)絡(luò)結(jié)點(diǎn)長(zhǎng)時(shí)間的滯留了，以致延誤到連接釋放以后的某個(gè)時(shí)間才到達(dá)server。本來(lái)這是一個(gè)早已失效的報(bào)文段。但server收到此失效的連接請(qǐng)求報(bào)文段后，就誤認(rèn)為是client再次發(fā)出的一個(gè)新的連接請(qǐng)求。于是就向client發(fā)出確認(rèn)報(bào)文段，同意建立連接。假設(shè)不采用“三次握手”，那么只要server發(fā)出確認(rèn)，新的連接就建立了。由于現(xiàn)在client并沒(méi)有發(fā)出建立連接的請(qǐng)求，因此不會(huì)理睬server的確認(rèn)，也不會(huì)向server發(fā)送ACK包。這樣就會(huì)白白浪費(fèi)資源。而經(jīng)過(guò)三次握手，客戶端和服務(wù)器都有應(yīng)有答，這樣可以確保TCP正確連接。

2 為什么TCP連接是三次，揮手確是四次？

在TCP連接中，服務(wù)器端的SYN和ACK向客戶端發(fā)送是一次性發(fā)送的，而在斷開(kāi)連接的過(guò)程中，B端向A端發(fā)送的ACK和FIN是是分兩次發(fā)送的。因?yàn)樵贐端接收到A端的FIN后，B端可能還有數(shù)據(jù)要傳輸，所以先發(fā)送ACK，等B端處理完自己的事情后就可以發(fā)送FIN斷開(kāi)連接了。

3 為什么在第四次揮手后會(huì)有2個(gè)MSL的延時(shí)？

MSL是Maximum Segment Lifetime，最大報(bào)文段生存時(shí)間，2個(gè)MSL是報(bào)文段發(fā)送和接收的最長(zhǎng)時(shí)間。假定網(wǎng)絡(luò)不可靠，那么第四次發(fā)送的ACK可能丟失，即B端無(wú)法收到這個(gè)ACK，如果B端收不到這個(gè)確認(rèn)ACK，B端會(huì)定時(shí)向A端重復(fù)發(fā)送FIN，直到B端收到A的確認(rèn)ACK。所以這個(gè)2MSL就是用來(lái)處理這個(gè)可能丟失的ACK的。

TCP、UDP應(yīng)用層的使用

1 文件傳送協(xié)議

文件傳送協(xié)議FTP (File Transfer Protocol) [RFC 959］是因特網(wǎng)上使用得最廣泛的文件傳送協(xié)議，底層采用TCP協(xié)議。

盯P 使用客戶服務(wù)器方式。一個(gè)FTP 服務(wù)器進(jìn)程可同時(shí)為多個(gè)客戶進(jìn)程提供服務(wù)。FTP的服務(wù)器進(jìn)程由兩大部分組成：一個(gè)主進(jìn)程，負(fù)責(zé)接受新的請(qǐng)求：另外有若干個(gè)從屬進(jìn)程，負(fù)責(zé)處理單個(gè)請(qǐng)求。

FTP工作過(guò)程.png

在進(jìn)行文件傳輸時(shí)，客戶和服務(wù)器之間要建立兩個(gè)并行的TCP 連接：“控制連接”（21端口）和“數(shù)據(jù)連接”（22端口）?？刂七B接在整個(gè)會(huì)話期間一直保持打開(kāi)， FTP 客戶所發(fā)出的傳送請(qǐng)求，通過(guò)控制連接發(fā)送給服務(wù)器端的控制進(jìn)程，但控制連接并不用來(lái)傳送文件。實(shí)際用于傳輸文件的是“數(shù)據(jù)連接”。服務(wù)器端的控制進(jìn)程在接收到FTP 客戶發(fā)送來(lái)的文件傳輸請(qǐng)求后就創(chuàng)建“數(shù)據(jù)傳送進(jìn)程”和“數(shù)據(jù)連接”，用來(lái)連接客戶端和服務(wù)器端的數(shù)據(jù)傳送進(jìn)程。

2 簡(jiǎn)單文件傳送協(xié)議TFTP

TCP/IP 協(xié)議族中還有一個(gè)簡(jiǎn)單文件傳送協(xié)議TFfP (Trivial File Transfer Protocol），它是一個(gè)很小且易于實(shí)現(xiàn)的文件傳送協(xié)議，端口號(hào)69。

TFfP 也使用客戶服務(wù)器方式，但它使用UDP 數(shù)據(jù)報(bào)，因此TFfP 需要有自己的差錯(cuò)改正措施。TFfP 只支持文件傳輸而不支持交耳。

3 TELNET

TELNET 是一個(gè)簡(jiǎn)單的遠(yuǎn)程終端協(xié)議，底層采用TCP協(xié)議。TELNET 也使用客戶服務(wù)器方式。在本地系統(tǒng)運(yùn)行TELNET 客戶進(jìn)程，而在遠(yuǎn)地主機(jī)則運(yùn)行TELNET 服務(wù)器進(jìn)程，占用端口23。

4 郵件傳輸協(xié)議

一個(gè)電子郵件系統(tǒng)應(yīng)具如圖所示的三個(gè)主要組成構(gòu)件，這就是用戶代理、郵件服務(wù)器，以及郵件發(fā)送協(xié)議（如SMTP ）和郵件讀取協(xié)議（如POP3)， POP3 是郵局協(xié)議（Post Office Protocol）的版本3 。

電子郵件的最主要的組成構(gòu)件

SMTP 和POP3 （或IMAP ）都是在TCP 連接的上面?zhèn)魉袜]件，使用TCP 的目的是為了使郵件的傳送成為可靠的。