計算機網絡自頂向下方法(第六版) 課後題答案 | 第二章

複習題html

R1.

R2.

網絡體系結構是指如五層Internet架構。應用程序體系結構是由應用程序開發人員設計的，它規定了應用程序的普遍結構(例如客戶機-服務器或P2P)。java

R3.

發起請求的是客戶端，接收請求的是服務器。git

R4.

不。在P2P文件共享應用程序中，接收文件的對等點一般是客戶機，發送文件的對等點一般是服務器。github

R5.

目標主機的IP地址和目標進程中套接字的端口號。web

R6.

使用UDP，事務能夠在一個往返時間(RTT)內完成——客戶機將事務請求發送到UDP套接字，服務器將響應發送回客戶機的UDP套接字。對於TCP，至少須要兩個rtt—一個用於設置TCP鏈接，另外一個用於客戶機發送請求，服務器發送迴應答。算法

R7.

例如，使用谷歌文檔的遠程字處理就是這樣一個例子。可是，由於谷歌文檔在Internet上運行(使用TCP)，因此沒有提供計時保證。數據庫

R8.

可靠數據傳輸：TCP
(帶寬)吞吐量：都不提供
定時：都不提供
安全性：都不提供後端

R9.

SSL 在應用層操做。SSL 套接字從應用層獲取未加密的數據，對其進行加密，而後將其傳遞給 TCP 套接字。若是應用程序開發人員但願使用 SSL 加強 TCP，則必須在應用程序中包含 SSL 代碼。UDP 不能使用 SSL。瀏覽器

R10.

握手協議是指主要用來讓客戶端及服務器確認彼此的身份的一類網絡協議。除此以外，爲了保護 SSL 記錄封包中傳送的數據，握手協議還能協助雙方選擇鏈接時所使用的加密算法、MAC 算法及相關密鑰。在傳送應用程序的數據前，必須使用 握手協議來完成上述事項。緩存

R11.

與這些協議相關聯的應用程序要求以正確的順序接收全部應用程序數據，而且沒有間隙。TCP提供此服務，而UDP不提供此服務。

R12.

當用戶第一次訪問站點時，服務器建立一個唯一的標識號，在其後端數據庫中建立一個條目，並將該標識號做爲cookie號返回。這個cookie號存儲在用戶的主機上，由瀏覽器管理。在隨後的每次訪問(和購買)期間，瀏覽器將cookie編號發送回站點。所以，站點知道這個用戶(更準確地說，這個瀏覽器)何時訪問站點。

R13.

Web緩存可使所需的內容「更接近」用戶，多是與用戶的主機鏈接的同一局域網。Web緩存能夠減小全部對象的延遲，甚至是沒有緩存的對象，由於緩存減小了連接上的通訊量。

R14.

Telnet 在 Windows 7 中默認不可用。要使它可用，去控制面板，程序和功能，打開或關閉 Windows 功能，檢查 Telnet 客戶端。要啓動 Telnet，在 Windows 命令提示符中，發出如下命令> Telnet webserverver 80

R15.

FTP使用兩個並行TCP鏈接，一個鏈接用於發送控制信息(例如傳輸文件的請求)，另外一個鏈接用於實際傳輸文件。因爲控制信息不是經過文件發送的同一鏈接發送的，FTP將控制信息發送到帶外。

R16.

消息首先經過HTTP從Alice的主機發送到她的郵件服務器。而後Alice的郵件服務器經過SMTP將消息發送到Bob的郵件服務器。而後Bob經過POP3將消息從郵件服務器傳輸到主機。

R17.

略

R18.

經過下載和刪除，在用戶從POP服務器檢索消息以後，這些消息將被刪除。
在下載和保存配置中，在用戶檢索消息後不會刪除消息。

R19.

是的，組織的郵件服務器和Web服務器能夠有相同的主機名別名。MX記錄用於將郵件服務器的主機名映射到其IP地址。

R20.

能，可是若是用戶使用gmail賬戶，您將沒法看到發送方的IP地址。

R21.

Bob也沒有必要向Alice提供塊。Alice必須在Bob的前4個鄰居中Bob才能向Alice發送數據塊;即便Alice在30秒的間隔內向Bob提供塊，這種狀況也可能不會發生。

R22.

R23.

P2P文件共享系統中的覆蓋網絡由參與文件共享系統的節點和節點間的邏輯連接組成。若是節點a和節點B之間存在半永久TCP鏈接，則節點a到節點B之間存在邏輯鏈路(圖論術語中的「邊」)。覆蓋網絡不包括路由器。

R24.

Mesh DHT:
優勢是爲了將消息路由到最接近密鑰的對等節點(具備ID)，只須要一次跳轉;
缺點是每一個對等點必須跟蹤DHT中的全部其餘對等點。

循環DHT:
優勢是每一個對等點只須要跟蹤幾個其餘對等點;
缺點是須要O(N)跳來將消息路由到最接近密鑰的對等點。

R25.

文件傳輸
即時通信
視頻
分佈式計算

R26.

對於UDP服務器，不存在歡迎套接字(serverSocket)，來自不一樣客戶機的全部數據都經過這個套接字進入服務器。對於TCP服務器，有一個歡迎套接字，每當客戶機啓動到服務器的鏈接時，就會建立一個新的套接字。所以，爲了支持n個併發鏈接，服務器須要n+1個套接字。

R27.

對於TCP應用程序，客戶機一執行，它就試圖啓動與服務器的TCP鏈接。若是TCP服務器沒有運行，那麼客戶機將沒法創建鏈接。對於UDP應用程序，客戶機不會在執行後當即啓動鏈接(或嘗試與UDP服務器通訊)

習題

P1.

a.
×
由於在對於一個 web page中，每個object都須要發出一個 request ，而後收到相應的 response,因此 request 一個 web page時，全部object 的 request 和 response 都是成對出現的
b.
√
在一個持久鏈接中，由於已經客戶端瀏覽器已經服務器創建了 TCP 鏈接，在此基礎上就能夠連續傳遞多個 object，當全部 object 的 request 和來自服務器的 response 都收到後，TCP 鏈接才關閉，故這兩個不一樣的網頁能夠在同一個持久鏈接中傳送。
c.
×
在非持久鏈接中，對於要傳送的每個 object 都須要創建相應的TCP鏈接，在對應於每個 object 的 TCP 鏈接創建完成後，客戶端就向服務器發送 request ，而後在服務器收到 request 以後就會發回一個包含客戶端請求的 object 的 response 而後就關閉 TCP 鏈接，所以在一個 TCP 鏈接中不可能有兩個不一樣的 HTTP request .
d.
×
DATE 是提供日期和時間標誌,說明報文是什麼時間建立的
e.
×
能夠有空的報文體

P2.

訪問控制命令:USER, PASS, ACT, CWD, CDUP, SMNT, REIN, QUIT。
傳輸參數命令:端口，PASV，類型 STRU，模式。
服務命令:RETR, STOR, STOU, APPE, ALLO, REST, RNFR, RNTO, ABOR, DELE, RMD, MRD, PWD, LIST, NLST, SITE, SYST, STAT, HELP, NOOP。

P3.

應用層協議:DNS 和 HTTP
傳輸層協議:DNS 的 UDP;TCP HTTP

P4.

a.
gaia.cs.umass.edu/cs445 /index.html
b.
HTTP / 1.1
c.
持續鏈接，keep-alive ：300
d.
HTTP 報文中沒有 IP 地址。
e.
Mozilla / 5.0。服務器須要瀏覽器類型信息將相同對象的不一樣版本發送到不一樣類型的瀏覽器

P5.

a.
狀態碼 200 和 OK 表示服務器可以成功定位文檔。答覆於 2008 年 3月 7 日(星期二)格林威治標準時間 12:39:45。
b.
最後一次修改 html 是在 2005 年 12 月 10 日星期六 18:27:46 GMT。
Last-Modified: Sat, 10 Dec 2005 18:27:46 GMT
c.
返回的文檔中有 3874 字節。
Content-Length: 3874
d.
返回文檔的前五個字節爲:<!doc。服務器贊成持久鏈接，如鏈接:Keep-Alive 字段所示

P6.

a.
客戶端或服務器均可以向另外一方代表，它將關閉持久鏈接
b.
HTTP不提供任何加密服務
c.
(來自 RFC 2616)「使用持久鏈接的客戶機應該限制它們維護到給定服務器的同時鏈接的數量。單用戶客戶機與任何服務器或代理鏈接不該超過 2 個
d.
可能，當服務器決定關閉「空閒」鏈接時，客戶機可能已經開始發送新的請求。從服務器的角度來看，鏈接在空閒時被關閉，但從客戶的角度來看，請求正在進行中。

P7.

獲得 IP 地址的時間爲 RTT1 + RTT2 + … + RTTn
獲得 IP 後，本機與服務器須要三次握手，第一次創建連接，第二次發出請求，第三次傳送對象，因爲對象傳送時間爲 0 ，因此獲取網頁須要的時間爲 2RTT0。
接收到該對象的時間爲 2RTT0 + RTT1 + RTT2 + … + RTTn

P8.

a.
沒有並行非持續鏈接中，每次引用對象都必須從新創建連接。
創建連接 + 獲取對象 = 2 RTT0
總時間爲：獲取對象花費的時間爲：8 * 2RTT0 。
2 RTT0 + RTT1 + RTT2 + … + RTTn + 8 * 2RTT0 =
18RTT0 + RTT1 + RTT2 + … + RTTn

b.
有並行非持續鏈接中，只需創建一次 HTTP 鏈接
獲取對象花費的時間爲 2RTT0。
總時間爲：2RTT0 + RTT1 + RTT2 + … + RTTn + 2RTT0 =
4RTT0 + RTT1 + RTT2 + … + RTTn

c.
帶流水線的持續 HTTP 中，只需創建一次 HTTP 鏈接，鏈接期間能夠處理多個請求/響應，獲取對象花費的時間爲 RTT0。
總時間爲：3 RTT0 + RTT1 + RTT2 + … + RTTn

d.(不帶流水)
與帶流水區別，非流水持續 HTTP 中，每一個對象須要花費 1 個 RTT0，
獲取對象花費的時間爲 8 RTT0。
總時間爲：8 RTT0 + 2 RTT0 + RTT1 + RTT2 + … + RTTn

P9.

a.
$\Delta$：跨越接入鏈路發送一個對象的平均時間
$\beta$：該對象接入鏈路的平均到達率
$\Delta$ = (850,000 bits)/(15,000,000 bits/sec) = 0.0567 sec
$\Delta$ $\beta$ = (16 requests/sec)(0.0567 sec/request) = 0.907
平均接入時延 : $\Delta$/(1- $\Delta$ $\beta$）= (0.0567 sec)/(1 - 0.907) = 0.6 seconds
總的平均響應時延 = 平均接入時延 + 平均因特網時延 = 0.6 sec + 3 sec = 3.6 sec.

b.
由於有40％的請求網絡知足，因此訪問鏈路的流量強度減小了40％。
所以平均接入時延： $\Delta$/(1- $\Delta$ $\beta$）= (0.0567 sec)/[1 – (0.6)(0.907)] = 0.12 sec。
若是請求由緩存器知足的話，其響應時間近似爲 0 sec。
當緩存器未命中時，緩存丟失的平均響應時間是 0.12 sec + 3sec = 3.12 sec。
所以平均響應時間是：(0.4)(0 sec) + (0.6)(3.12 sec) = 1.872 sec。
所以平均響應時間由 3.6 sec 減小到 1.872sec。

P10.

todo

P11.

a.
能，由於Bob使用非持續 HTTP 並行實例，有更多的鏈接，他能夠獲得更多的鏈路帶寬。
b.
是的，Bob仍然須要執行並行下載;不然，他將獲得比其餘4個用戶更少的帶寬。

P12.

略

P13.

The MAIL FROM:在 SMTP中，是來自 SMTP 客戶端的消息，它標識發送到SMTP服務器的郵件消息的發送方。
The From:自己不是SMTP消息，而是郵件消息主體中的一行。

P14.

SMTP使用僅包含句號的行來標記消息主體的結束。HTTP使用「Content-Length header字段」表示消息體的長度。不，HTTP不能使用SMTP使用的方法，由於HTTP消息能夠是二進制數據，而在SMTP中，消息體必須是7位ASCII格式。

P15.

MTA (Mail Transfer Agents) 是郵件傳輸代理的縮寫。主機將消息發送給 MTA。而後，該消息按照 mta 序列到達接收方的郵件閱讀器。咱們能夠看到，這條垃圾郵件遵循一個 MTAs 鏈。一個誠實的 MTA 應該在收到信息的地方報告。注意，在這條消息中，「asusus-4b96([58.88.21.177])」沒有從哪裏收到電子郵件。因爲咱們假設只有發起者是不誠實的，因此「usus-4b96([58.88.21.177])」必定是發起者。

P16.

UIDL縮寫爲「唯一id列表」。當POP3客戶機發出UIDL命令時，服務器將使用用戶郵箱中全部消息的惟一消息ID進行響應。這個命令對於「下載並保存」頗有用。經過維護一個出如今早期會話中檢索到的消息的文件列表，客戶機可使用UIDL命令來肯定服務器上已經看到了哪些消息。

P17.

略

P18.

a.
對於給定的域名(如ccn.com)、IP地址或網絡管理員名稱，可使用whois 數據庫定位相應的註冊商、whois服務器、DNS服務器等。
b.
略
c.
略
d.
略
e.
略
f.
攻擊者可使用 whois 數據庫和 nslookup工具來肯定目標機構的 IP 地址範圍、DNS 服務器地址等。
g.
經過分析攻擊包的源地址，受害者可使用whois獲取攻擊來自的域的信息，並可能通知源域的管理員。

P19.

略

P20.

咱們能夠按期對本地 DNS 服務器中的 DNS 緩存進行快照。出如今 DNS 緩存中最頻繁的Web服務器是最流行的服務器。這是由於若是更多的用戶對 Web 服務器感興趣，那麼該服務器的 DNS 請求將更頻繁地由用戶發送。所以，Web 服務器將更頻繁地出如今 DNS 緩存中。

P21.

是的，咱們可使用 dig 在本地 DNS 服務器上查詢那個網站。
例如，「dig cnn.com」將返回查找cnn.com的查詢時間。若是在幾秒鐘以前訪問了 cnn.com，則 cnn.com 的條目將緩存在本地 DNS 緩存中，所以查詢時間爲 0 msec。不然，查詢時間很長。

P22.

略

P23.

略

P24.

略

P25.

覆蓋網絡中有N個節點。有N(N-1)/2條邊。

P26.

略

P27.

Peer 3 知道Peer 5 剛剛離開系統，因此Peer 3 向它的第一個繼承者(Peer 4)請求它的直接繼承者(Peer 8)的標識符，而後Peer 3 將使Peer 8 成爲第二個繼承者。

P28.

第 6 位會先給第 15 位發送一條消息，說「第 6 位的前驅和後繼是誰?」這條消息經過 DHT 被轉發，直到到達 peer 5, peer 5 意識到它將是 6 的前驅，而它的當先後繼，peer 8，將成爲 6 的後繼。接下來，對等點 5 將此前驅和後繼信息發送回 6。如今，Peer 6 能夠加入DHT，方法是讓 Peer 8 成爲它的後繼，並通知 Peer 5，它應該將後繼更改成 6。

P29.

對於每一個鍵，咱們首先計算其與全部對等點之間的距離(使用d(k,p))，而後將鍵存儲在最接近鍵的對等點中(即距離值最小)。

P30.

可能，隨機地將鍵分配給對等點根本不考慮底層網絡，所以極可能會致使不匹配。較短的邏輯路徑可能對應較長的物理路徑。

P31.

a.
若是先運行TCPClient，那麼客戶機將嘗試與不存在的服務器進程創建TCP鏈接。將不會創建TCP鏈接。
b
UDPClient不與服務器創建TCP鏈接。所以，若是首先運行UDPClient，而後運行UDPServer，而後在鍵盤上鍵入一些輸入，那麼一切均可以正常工做。
c.
若是使用不一樣的端口號，那麼客戶端將試圖創建一個TCP鏈接與錯誤的進程或不存在的進程。會發生錯誤。

P32.

在原始程序中，UDPClient在建立套接字時不指定端口號。在本例中，代碼容許底層操做系統選擇端口號。在另外一行中，當UDPClient執行時，將建立一個端口號爲5432的UDP套接字。

UDPServer 須要知道客戶機端口號，以便可以將數據包發送回正確的客戶機套接字。DPServer 經過分解從客戶機接收的數據報來肯定客戶機端口號。所以，UDP 服務器可使用任何客戶機端口號，包括 5432。所以，UDPServer 不須要修改。

P33.

優勢：能夠更快地下載文件。
缺點：可能會佔用帶寬，從而顯著下降共享相同物理連接的其餘用戶的下載速度。

P34.

對於遠程登陸(telnet和ssh)之類的應用程序，面向字節流的協議很是廣泛，由於應用程序中沒有消息邊界的概念。當用戶鍵入字符時，咱們只需將該字符放入 TCP 鏈接。在其餘應用程序中，咱們可能會發送一系列在它們之間有固有邊界的消息。例如，當一個SMTP 郵件服務器向另外一個 SMTP 郵件服務器發送多個電子郵件消息時。因爲 TCP 沒有表示邊界的機制，應用程序必須添加標識自己，以便應用程序的接收端可以區分一條消息和另外一條消息。若是將每一個消息放入一個不一樣的 UDP 段，接收端將可以區分各類消息，而不須要應用程序的發送端添加任何指示。

TCP 是流式的數據傳輸，消息沒有邊界，須要應用層本身去定義消息邊界，而 UDP 是數據報傳輸，因此協議保證了一次只能接收一個數據報。

P35.

要建立 web 服務器，咱們須要在主機上運行 web 服務器軟件。許多供應商出售 web 服務器軟件。然而，當今最流行的 web 服務器軟件是Apache，它是開源的，並且是免費的。多年來，開源社區對它進行了高度優化。

P36.

鍵是infohash，值存放 infohash 指定的文件的一個IP地址。

個人 Github：Github
我的網站: 天狼星的博客
CSDN: CSDN
E-mail: siriushly@163.com
QQ:1136513099
答案下載：https://download.csdn.net/download/sirius_hly/10830333
參考：http://www.noobyard.com/article/p-hjxgbriv-s.html 轉載請註明出處，若有錯誤，歡迎指正，感激涕零，多謝。