計算機網絡自頂向下方法:第二章 應用層 課後複習題

若有錯誤, 歡迎指出~

• 第一章 計算機網絡和因特網 課後複習題
• 第二章 應用層 課後複習題
• 第三章 運輸層 課後複習題
• 第四章 網絡層:數據平面 課後複習題
• 第五章 網絡層:控制平面 課後複習題
• 第六章 鏈路層和局域網 課後複習題

第二章: 應用層

2.1節

R1. 列出5種非專用的因特網應用及它們所使用的應用層協議.

應用	應用層協議
Web衝浪	HTTP協議
電子郵件	SMTP協議
因特網電話	SIP協議
流式多媒體	HTTP協議
文件傳輸	FTP協議

 

R2. 網絡體系結構與應用程序體系結構之間有什麼區別?

• 網絡體系結構指的是因特網種的五層網絡協議.
• 應用程序體系結構一般是由開發者本身定義的.
• 它們的區別在於, 從應用程序研發者的角度看, 網絡體系結構是固定的, 併爲應用程序提供了特定的服務集合. 另外一方面, 應用程序體系結構由應用程序研發者設計, 規定了如何在各類端系統上組織該應用程序.
• 應用程序體系架構能夠經過應用網絡體系架構中的內容從而使應用程序擁有網絡傳輸功能.

 

R3. 對兩進程之間的通訊會話而言, 哪一個進程是客戶, 哪一個進程是服務器?

• 書本定義: 在一對進程之間的通訊會話場景中, 發起通訊(即在該會話開始時發起與其餘進程的聯繫)的進程被標識爲客戶, 在會話開始時等待聯繫的進程是服務器.

 

R4. 對一個P2P文件共享應用, 你贊成"一個通訊會話不存在客戶端和服務器端的概念"的說法嗎? 爲何?

• 我不一樣意. P2P文件共享應用雖然可以相互傳輸文件, 看起來每一個用戶便可以當客戶, 也能夠當服務器. 可是具體落實到一次通訊會話中, 當對等方A請求對等方B發送一個特定的文件時, 在這個特定的通訊會話中對等方A是客戶, 而對等方B是服務器.

 

R5. 運行在一臺主機上的一個進程, 使用什麼信息來標識運行在另外一臺主機上的進程?

• 經過IP地址標識另外一臺主機, 經過另外一臺主機上的目的地端口號來標識另外一臺主機上的程序.

 

R6. 假定你想盡快地處理從遠程客戶到服務器的事務, 你將使用UDP仍是TCP? 爲何?

• 我會使用UDP, 由於TCP是面向鏈接的, 在傳輸以前須要進行三次握手. 而UDP是無鏈接的, 能夠直接選定合適速率向外傳送.

 

R7. 參見圖2-4, 咱們看到在該圖中所列出的應用程序沒有一個同時既要求無數據丟失又要求定時的. 你能設想一個既要求無數據丟失又高度時間敏感的應用程序嗎?

• 發射火箭的程序.

 

R8. 列出一個運輸協議可以提供的4種寬泛類型的服務. 對於每種服務類型, 指出是UDP仍是TCP(或這兩種協議)提供這樣的服務?

服務	UDP Or TCP
可靠數據傳輸	TCP
吞吐量	TCP
定時	TCP
安全性	SSL

 

R9. 前面講過TCP能用SSL來強化, 以提供進程到進程的安全性服務, 包括加密. SSL運行在運輸層仍是應用層? 若是某應用程序研製者想要用SSL來強化UDP, 該研製者應當作些什麼工做?

 

• SSL運行在應用層.
• SSL在TCP的握手階段完成了雙方的身份確認, 生成密鑰等操做. 若是研製者要用SSL來強化UDP, 由於UDP是面向無鏈接的, 因此SSL首先要解決在UDP傳輸中的身份確認問題.

2.2 ~ 2.4節

R10. 握手協議的做用是什麼?

• 使客戶端和服務器端創建起鏈接, 可以開始傳遞信息.

 

R11. 爲何HTTP, SMTP及POP3都運行在TCP上, 而不是在UDP上?

• 首先要知道TCP幾個重要的特性: 面向鏈接, 保證數據完整性, 保證數據有序到達, 有擁塞控制功能. 而上述功能UDP都沒有.
• 再來看HTTP, 用戶經過瀏覽器以HTTP協議向服務器發起請求, 若是這個請求數據不完整, 服務器將沒法給出正確響應, 用戶也得不到想要的結果.
• SMTP和POP3兩個郵件協議也須要保證數據的完整性, 而且要保證按照必定的順序交付, 因此選擇TCP.

 

R12. 考慮一個電子商務網站須要保留每個客戶的購買記錄. 描述如何使用cookie來完成該功能?

• 用戶首次訪問電子商務網站時, 須要提供一個用戶的惟一標識, 電商網站根據用戶標識查得用戶信息, 並將特定的用戶信息做爲cookie響應給用戶. 而後用戶在電商網站發起的每一個操做都帶上該cookie, 電商網站便能保留每一個客戶的購買記錄了.

 

R13. 描述Web緩存器是如何減小接收被請求對象的延時的. Web緩存器將減小一個用戶請求的全部對象或只是其中的某些對象的時延嗎? 爲何?

• Web緩存器設置在用戶和初始服務器之間, 當用戶要向初始服務器發起請求時, 瀏覽器會先將請求定位到Web緩存器上, 若是緩存器上有請求對象的副本則直接將該副本響應給客戶. 若是緩存器中沒有, 則從Web緩存器向初始服務器發起對該對象的請求, Web緩存器收到來自初始服務器的響應對象後, 本身會保留一份該對象的副本, 而後再響應給用戶.
• 所以, Web緩存器只能減小緩存過的對象的時延.

 

R14. Telnet到一臺Web服務器併發送一個多行的請求報文. 在該請求報文中包含If-modified-since: 首部行, 迫使響應報文中出現"304 Not Modified"狀態代碼.

• 不太懂題目意思, 不過能夠解釋一下題目中出現的名詞:
• 使用Web緩存器帶來的最直觀問題是, 若是服務器上的對象在被緩存到緩存器後修改了, 該怎麼辦?
• 這涉及到HTTP協議的一種機制: 條件GET(conditional GET).
• 客戶向Web服務器發起請求, 請求首先會被緩存器攔截, 這時若是緩存中用戶請求的內容, 未了保證請求的內容在服務器上也是最新的, 緩存器會向服務器發送一個GET請求, GET請求中包含首部行If-modified-since, 該首部行的內容是該對象在緩存器中的最新副本.
• 若是服務器中被請求對象和緩存器中的最新副本同樣, 就不必再發送一次了, 這時就會響應一個"304 Not Modified"狀態碼, 不帶任何多餘數據. 若是服務器中的對象更新過, 和緩存器中的副本不同了, 服務器會將最新的副本發送給緩存器.

 

R15. 列出幾種流行的即時通訊應用.它們使用相同的協議做爲SMS嗎?

• 電子郵件, FaceBook, 微信等.
• 以上三個的應用層協議各不相同.

 

R16. 假定Alice使用一個基於Web的電子郵件帳戶(例如Hotmail或Gmail)向Bob發報文, 而Bob使用POP3從他的郵件服務器訪問本身的郵件. 討論該報文是如何從Alice主機到Bob主機的. 要列出在兩臺主機間移動該報文時所使用的各類應用層協議.

• Alice使用Web電子郵件帳戶向Bob發送報文時, Alice的瀏覽器也就是Alice的用戶代理經過HTTP鏈接到Alice的郵件服務器, 並把報文傳送到該郵件服務器上
• 而後Alice的郵件服務器經過SMTP鏈接到Bob的郵件服務器(基於TCP), 並把郵件報文傳送到Bob的郵件服務器中.
• Bob使用它的用戶代理(主機), 經過POP3協議訪問本身的郵件服務器, 並如下載保存或下載刪除的方式得到Alice發來的郵件報文.

 

#### R17. 將你最近收到的報文首部打印出來. 其中有多少Received: 首部行? 分析該報文的首部行中的每一行.

 

R18. 從用戶的觀點看, POP3協議中下載並刪除模式和下載並保存模式有什麼區別嗎?

• 從用戶的角度看是沒有的, 由於不管採起哪一種模式, 用戶都獲得了郵件報文. 可是對於郵件服務器就不一樣了, 若是是下載刪除, POP3會話結束後就會把標記的郵件報文刪除, 再次鏈接上郵件服務器這些郵件報文就不存在了.

 

R19. 一個機構的Web服務器和郵件服務器能夠有徹底相同的主機名別名嗎? 包含郵件服務器主機名的RR有什麼樣的類型?

• 能夠, 由於在DNS數據庫中, 記錄一條RR(Resource Record)須要提供4個字段: Name, Value, Type, TTL.
• 其中Type字段記錄本條記錄的類型. 這就讓機構的Web服務器和郵件服務器用相同主機別名成爲可能. 假如咱們要訪問該機構的郵件服務器, 除了要給出主機別名, 在DNS報文中還會指定RR的類型爲MX(郵件服務器的規範主機名).

 

R20. 仔細檢查收到的電子郵件, 查找由使用.edu電子郵件地址的用戶發送的報文首部. 從其首部, 可以肯定發送該報文的主機的IP地址嗎? 對於由Gmail帳號發送的報文作相同的事.

• 答案來源自網絡
• .edu的能夠
• Gmail不行

 

2.5節

R21. 在BitTorrent中, 假定Alice向Bob提供一個30秒間隔的文件塊吞吐量. Bob將必須進行回報, 在相同的間隔中向Alice提供文件塊嗎? 爲何?

• 不, Bob並沒必要須進行回報. 由於Alice會選取必定數量的"鄰居", 並從它們那裏得到塊. 而這個選擇不是基於Alice向誰發送了塊就要向誰索要塊, 而是在Alice的對等方列表中向對等方發起請求, 選取響應速度快的前4位上載者來獲取塊. Alice獲取塊的伴侶也是不停更新的.

 

R22. 考慮一個新對等方Alice加入BitTorrent而不擁有任何文件塊. 沒有任何文件快, 所以她沒有任何東西可上載, 她沒法成爲任何其餘對等方的前4位上載者. 那麼Alice是怎樣獲得她的第一個文件塊呢?

• Alice雖然不能成爲上載者, 可是她能成爲接收者呀, 接收到塊後天然就有可能成爲上載者了.
• Alice在空手加入洪流時, 追蹤器會隨機地從參與對等方集合中選擇一個對等方子集, 並將子集中對等方的IP地址發送給Alice. Alice持有這張列表並嘗試與列表中全部的對等方創建並行的TCP鏈接, 並選擇前4位上載者, 向它們請求塊(最稀缺優先原則).

 

R23. 覆蓋網絡是什麼? 它包括路由器嗎? 在覆蓋網絡中邊是什麼?

• 答案來源網絡.
• 覆蓋網絡是一種面向應用層的網絡, 包括對等方和對等方之間由虛擬聯絡構成的抽象邏輯網.
• 覆蓋網絡不包括路由器.
• 覆蓋網絡中的邊就是對等方之間的邏輯鏈路.

 

2.6節

R24. CDN一般採用兩種不一樣的服務器放置方法之一. 列舉並簡單描述它們.

• 深刻: 經過在遍佈全球的接入ISP中部署服務器集羣來深刻到ISP的接入網中. 好處是靠近端用戶, 減小端用戶和CDN集羣之間鏈路和路由器數量, 改善了用戶感覺到的時延和吞吐量. 缺點是因爲高度分佈式設計, 維護和管理集羣成本高.
• 邀請作客: 經過在少許關鍵位置建造大集羣來邀請到ISP作客. 這些CDN集羣一般放在因特網交換結點(IXP). 好處是產生較低的維護和管理開銷. 缺點是以對端用戶的較高時延和較低吞吐量爲代價.

 

R25. 除了如時延, 丟包和帶寬性能等網絡相關的考慮外, 設計一種CDN服務器選擇策略時還有其餘重要因素. 它們是什麼?

• 還要考慮它分發的內容.

2.7節

R26. 2.7節中所描述的UDP服務器僅須要一個套接字, 而TCP服務器須要兩個套接字. 爲何? 若是TCP服務器支持n個並行鏈接, 每條鏈接來自不一樣的客戶主機, 那麼TCP服務器須要多少個套接字.

• 由於UDP是面向無鏈接的, 它只須要有一個套接字用於接收和發送, 而且能夠接收來自不一樣地址主機的UDP包. 而TCP是面向鏈接的, 除了接收訪問的套接字, 每和一個客戶鏈接就要建立一個專用的套接字.
• n+1個.

R27. 對於2.7節所描述的運行在TCP之上的客戶-服務器應用程序, 服務器程序爲何必須先於客戶程序運行? 對於運行在UDP之上的客戶-服務器應用程序, 客戶程序爲何能夠先於服務器程序運行.

• 創建TCP鏈接須要通過一個3次握手的過程, 若是服務器沒有啓動根本沒法握手, 從而沒法建立鏈接.
• UDP是面向無鏈接的, 就算服務器沒有啓動, 客戶程序照樣能夠把UDP發出去, 但服務器可能就收不到了.