概述：
爲了瞭解計算機網絡，我開始刷《tcp/ip詳解》這部聖經，以此博客來記錄閱讀過程中的一些感悟，和習題的解答（主要），很可惜是從第八章開始，如果有機會，慢慢把前七章補完。
習題：
8.1當IP將收到的TTL字段減1，發現它爲0時，將會發生什麼結果。
我總覺的自己看書的理解能力有問題，而且還較真，我所理解的這個問題的原意思是，IP收到，就是路由器收到了一個TTL爲1的字段，然後TTL減1，TTL變爲0，問接下來會發生什麼。
這是原版的說法，他的意思應該是收到的時候就是TTL爲0。
答案給的解釋是，收到TTL字段爲0的數據報，做減1測試後會把TTL設置爲255，並且讓數據報繼續傳輸，正常情況路由器永遠不會手奧TTL爲0的數據報。
這個問題我還是不太理解，網上很多人都認爲是丟棄這個數據包並且發送一個icmp給源端，我覺得也有道理。
8.2traceroute程序如何計算RTT的，將這種計算方法與ping相比較
traceroute是將發送時間記錄在發送時的udp報文內，因爲traceroute的udp報文包含20字節的ip首部，8字節的udp首部，12字節用戶數據（序列號，TTL，發送時間），這時計算時間，只要當回送icmp端口不可達報文到達源端的時候將當時的時間減去udp報文中的發送時間就可以計算了
ping是將發送時間記錄在icmp報文中做到的。等icmp迴應報文到源端後，再由當前時間減去icmp報文中的時間就計算出了RTT。
8.3假設源主機和目的主機之間有三個路由器（R1,R2和R3）而中間的路由器（R2）在進入TTL字段爲1時，將TTL字段減1，但卻錯誤地將該ip數據報發往下一個路由。請描述會發生什麼結果。在運行traceroute程序時會看到什麼樣的現象？
發往R1的ttl爲1的udp報文正常，且回發的icmp端口不可達報文正常，所以輸出的第行正常
發往R2的ttl爲2的報文到達R2時，ttl變爲1，將其減1後，又將ttl爲0的報文給了R3，也就是說，R3收到了源端ip爲左主機，目的ip爲R3且ttl爲0的udp報文，這個報文所指向的端口號又不存在，所以R3回送了一個端口不可達報文（不要被8.1誤導了），所以第二行輸出的是標記R3路由的行。
發往R3的tll爲3的報文，整個過程沒有路由器出錯，所以結果正常着呢。
最後出現的結果就是第一行是標記R1，後兩行都爲標記R3的行。
8.4
8.5
netb返回的icmp報文ttl爲255很正常，因爲sun主機與netb是靠着slip鏈路鏈接的，但是bunch爲253就不對了，sun與他之間明顯應該是有兩個路由，纔會出現253這樣的TTL，也就是說，輸出的結果丟了一個路由，之後的意思和這個一樣，不再熬述。
分析原因，可能是丟失的路由出錯了，但是接收icmp的路由又正確的把ttl減去了。還有一種可能就是源端發送udp報文的路徑和，路由器發送icmp報文的路徑是不同的，這也非常的可能。
8.7
ping程序是將icmp回顯請求報文的標識符字段設置成pid，icmp回顯應答報文包含同樣值的標識符字段。traceroute直接發送udp報文，也就是使用了端口號來標記。
8.8
ping程序將發送的時間記憶在icmp報文中，也就不需要ping程序等待來計算往返時間了。
traceroute返回的icmp報文中只有20字節的ip首部，8字節的udp首部（只包括了源端口和目的端口），所以無法記錄時間，這時就需要traceroute程序來記憶時間了。