經過了一個國慶的頹廢，還是要收收心，繼續複習。之前對很多書籍進行了一次大掃蕩。接下去需要二刷，另外，需要一刷的書籍是《設計模式》。先利用黑皮書對網路知識進行一次鞏固吧。

• 第二章 鏈路層

乙太網（可以理解為就是一個標準（RFC894），RFC1042就是IEEE 802.2/802.3，除此之外還有SLIP封裝，PPP封裝等）的封裝圖：

MTU最大傳輸單元，資料長度假如比鏈路層的MTU大，則需要分片。
路徑MTU指的是兩臺通訊主機路徑中的最小MTU（不一定是常數，和路由選擇有關）

• 第三章 IP：網際協議

IP協議首先是，不可靠的，無連線的。
IP首部圖，普通的是20個位元組：

版本的話，現在是4，也就是IPv4。
首部長度，最大15,15*4 = 60位元組，首部最大是60位元組。
TOS，8位服務型別，部分不支援，有些支援，
總長度，16位，65536.
標識和片偏移（有點像tcp那部分了）。
TTL，初始值通常是32、64.經過一個路由器 - 1.減到0，還沒到，就會返回icmp不可達。
8位協議，在被傳輸的時候，路由器會更改TTL，但是隻是更改TTL，因此容易更新校驗和。
一般來說，B類，網路號16位，子網號8位，主機號8位（通過修改子網掩碼，可以變成，子網號11位，主機號5位）。

在進行路由選擇決策時，主機和路由器都是用路由表。在表中有三種類型的路由：特定主機型（IP地址完全匹配）

、特定網路型（網路號匹配）和預設路由型。路由表的表目具有一定的優先順序。在選擇路由時，主機路由優先於網路路由，沒有可選的，才會選擇預設路由。

• 第四章 ARP
  ARP背後的一個基本概念：那就是網路介面有一個硬體地址。在硬體層次上進行的資料幀交換必須有正確的介面地址。
  ARP快取記憶體一般是20分鐘，即短時間內詢問過的，就不再發送了
  我電腦上的：
  

關鍵的關鍵，假如對一個不存在的主機，發起ARP請求。事實上會有多次請求，第一次失敗後5.5s，第二次是24s，第三次是29.5s。

ARP代理（也稱為ARP出租，混合ARP），意思是，A要給B發，但是A發了B的IP後，沒人回答，此時A的路由器發現，有個網段包含這個，則給A發一個MAC（自己路由器的MAC），A就給路由器發資料了。

免費ARP：是指主機發送ARP查詢自己的IP地址（期望沒人回覆）。

• 第五章RARP 逆地址解析協議

具有本地磁碟的系統引導的時候，一般從磁碟上的配置檔案中讀取IP地址。但是無盤機則需要其他方式來獲得IP。
無盤系統，一般是讀取自己的MAC資訊，然後傳送一份RARP請求，請求IP（實現起來比ARP要困難）
RARP的伺服器設計，比ARP伺服器困難，ARP伺服器（通常是TCP/IP在核心中實現的一部分。由於核心知道IP地址和硬體地址，因此核心就可以應答）。
RARP伺服器的複雜性在於，伺服器一般要為多個主機（網路上的所有無盤系統）提供硬體地址到IP地址的對映，這個對映包含在一個磁碟檔案中。
（PS，我很納悶，為啥arp伺服器就可以核心，rarp就得使用者，不都是對映麼）
參考一個連結：

http://www.cnblogs.com/zhousysu/p/5483900.html
ARP server是存在於kernel中，而RARP server僅僅是一個使用者程序，RARP就有些”先天不足”。其次，RARP是尋找與實體地址對應的IP地址，這就表明了RARP request packet包中沒有IP地址，自然也就無法通過路由器進行轉發了。因為路由器是工作在網路層，網路層的協議是IP協議，ARP request能夠通過路由器進行轉發，是因為在ARP request packet中有IP地址的欄位，而RARP request packet沒有，所以路由器對RARP也就沒有幫助了。

• 第六章 ICMP:Internet 控制報文協議

緊跟20位元組的IP首部

<1>ICMP地址掩碼請求與應答：用於無盤系統在引導過程中獲取自己的子網掩碼

<2>ICMP時間戳請求與應答，向另一個系統查詢當前的時間，是個毫秒數（沒有日期）（但是，傳送，再返回的延遲，怎麼算呢？貌似有個RTT值）傳送端填寫發起時間戳。

<3>ICMP埠不可達差錯
必須包括生成該差錯報文的資料報IP首部（包含任何選項），還必須至少包括跟在該IP首部後面的前8個位元組。
exp:

目的是，這樣就獲得了UDP中的埠資訊。IP首部也包含，因此，知道最後的8位元組是UDP。
有16種不同型別的ICMP不可達報文。例如埠不可達是3。（TFTP底層貌似，發UDP，不可達（不可達不會給使用者程序），還會重發。。。然後我立馬看到了，已經被禁用。。）

• 第七章 Ping程式

Ping傳送一份ICMP回顯請求報文給主機，並等待返回ICMP回顯應答。

大多數的TCP/IP實現都在核心中直接支援Ping伺服器。

自己拿windows和linux分別測了測，感覺效果和書上還是不太一樣的，尤其是ping區域網，效果是不規律的，一個8ms，幾個0.幾ms，有時候，直接上百。我猜測是網路不是封閉式的。

• 第八章 Trace route

把TTL看成一個跳站計數器。
Traceroute的操作流程，首先發送一份TTL欄位為1的IP資料包給目的主機。處理這份資料包的第一個路由器將TTL-1，丟棄該資料包，並且發回一份，超時ICMP報文，這樣得到了路徑中的第一個路由器的地址。然後傳送TTL欄位為2的，繼續這個過程，直到到達目的主機。另一個Point，程式是傳送一個UDP資料報給目的主機，用的埠是一個30000多（不可能有程式用的），到達目的後，會產生一個埠不可達的錯誤（從而判定到達目的主機）

幾個注意點，就算是連續的IP資料報，都可能採用不同的路由；往返時間，可能並不能真正體現資料報發出和返回的時間差。

• 第九章 IP選路

選路是IP最重要的功能。單個IP層如何做出路由決策？

ICMP重定向差錯：當IP資料報應該被髮送到B路由器時，受到資料報的A路由器傳送ICMP重定向差錯報文給傳送端。一個圖來解釋：

第一步，主機給R1傳送一份IP資料報，R1收到後，發現應該給R2，但是檢測到收到的介面和R1給R2傳送的介面是同一個。此時R1傳送一份ICMP重定向給主機，告訴他，以後這類的給R2，別給我。（重定向的作用，一般是主機啟動的時候，只有一個預設選項，通過不停地重定向，豐富自己的路由表）

ICMP路由器發現報文，是一種初始化路由表的方法。

• 第十章 動態選路協議

動態選路主要指的是 路由器間的通訊，書上主要只討論RIP
路由器上有一個程序成為守護程序，它執行選路協議，並與其相鄰的一些路由器進行通訊。
每個自治系統可以選擇該自治系統中各個路由器之間的選路協議。這種協議我們稱之為內部閘道器協議IGP或域內選路協議。最常用的IGP是選路資訊協議RIP。一種新的IGP是開放最短路徑優先OSPF。
外部閘道器協議EGP或域內選路協議的分隔選路協議用於不同自治系統之間的路由器。如今用的比較多的是邊界閘道器協議BGP。

RIP報文包含在UDP資料報中，格式如下：

RIP常用的UDP埠號位520。執行過程如下：
1：初始化，在啟動一個路由守護程序的時候，先判斷，有哪些介面是啟動的（應該就是路由器上哪些口是有用），並且接著在每個介面上傳送一個請求報文，要求其他路由器傳送完整路由表。
2：接收到請求。如果這個請求是剛才提到的特殊請求，那麼路由器就將完整的路由表傳送給請求者。
3：接收到響應，更新路由表。
4：定期選路更新，每過30秒，所有或部分路由器會將完整路由表傳送給相鄰的路由器。
5：觸發更新。每當一條路由的度量發生變化時，就對它進行更新。不傳送完整的。
RIP所使用的度量是跳(hop)，直接連線的介面跳數為1。跳數最大是15，RIP只能在主機最大跳數為15的AS內。
RIP的侷限，他沒有子網地址的概念，有些用到掩碼的操作，可能會導致出錯，而且，出錯後需要比較長的時間才能穩定。

OSPF：開放最短路徑優先，克服了RIP的所有限制。直接使用IP，而不是UDP或者TCP；且支援子網。

BGP：邊界閘道器協議。
CIDR：無型別域間選路

• 第十一章 UDP：使用者資料報協議

UDP和TCP都包含一個12位元組長的偽首部，它是為了計算校驗和而設定的。目的是讓UDP兩次檢查資料是否已經正確到達目的地（例如，IP）。
看了一些資料，有些理解，例如IP首部頭，出錯的時候，恰好，錯得IP校驗識別不出來（目的IP已經變了），校驗不出來，就正常轉發，到了某個地址，UDP處理的時候，發現，這tm出錯了呀，根本不是我的IP。另一個功能，偽首部裡有8位協議，這個出錯了，到UDP這了，UDP說，這明明是TCP呀，到我這幹嘛，之類的功效，因為他只是選取IP頭的部分資訊，假如IP校驗對，偽首部也可能錯。

IP分片,物理層一般要限制每次傳送資料幀的最大長度。分片可以發生在原始傳送端的主機上，也可以發生在中間路由器上。
儘管IP分層是透明的，但是不想被用，因為即使丟棄一片資料，也要重傳整個資料報。之所以這樣，例如TCP有超時和重傳機制。當TCP某一片丟失後，TCP在超時後會重發整個TCP報文段（就是那一片），對應的就是一份IP資料報。沒有辦法只傳一個數據報片（這個把IP重傳和TCP重傳結合分析了下）
另外，之前之所以可以直接send特別大的UDP，是因為IP分片吧

• 第十二章 廣播與多播

三種IP地址：單播地址、廣播地址和多播地址。
廣播和多播僅應用於UDP。
其為什麼能廣播，多播，則先看一張圖：

網絡卡收到一個幀，假如幀沒錯，往上傳。裝置驅動程式將進行另外的幀過濾。首先，幀型別中必須指定要使用的協議（ARP），其次，進行多播過濾來檢測該主機是否屬於多播地址說明的多播組。然後往上傳，源地址，目的地址進行檢測，然後再傳（如TCP，UDP），根據埠號，進行資料過濾。

廣播的問題是，例如一個網內50臺機器，20臺需要接受這個應用，另外30臺，都需要到UDP層，發現埠沒有開啟才會被丟棄，負荷太大。

多播的地址形式：


224.0.0.1 所有組播主機
224.0.0.2 所有組播路由器
224.0.0.4 DRMRP 路由器
224.0.0.5 所有 OSPF 的路由器
224.0.0.6 OSPF 指派路由器
224.0.0.9 RPIv2 路由器
224.0.0.10 EIGRP 路由器
224.0.0.13 PIM 路由器
224.0.0.22 IGMPv3
224.0.0.25 RGMP
224.0.1.1 NTP 網路時間
再參考>http://blog.csdn.net/maopig/article/details/6868626
意思就是，首先需要網絡卡進行設定成多播傳送工作模式，指定不過濾以某一個多播傳送地址作為目的實體地址的資料幀。
當把多播擴充套件到單個物理網路以外需要通過路由器轉發多播資料的時候，複雜性就增加了，需要有一個協議讓多播路由器瞭解確定，網路中屬於確定多播組的任何一個主機。這個協議就是IGMP。

• 第十三章 IGMP ：Internet組管理協議

IGMP也被當做IP層的一部分。


IGMP有固定的報文長度。

1第一個程序加入一個組時，主機就傳送一個IGMP報告。如果一個主機的多個程序加入同一個組，則只發IGMP，報告。
2程序離開一個組時，主機不傳送IGMP報告，即便是最後一個程序。只是確定組內沒有組成員後，在隨後收到的IGMP查詢中就不再發送報告報文
3多播路由器定時傳送IGMP查詢來了解是否還有任何主機包含有屬於多播組的程序。多播路由器必須向每個介面傳送一個IGMP查詢。因為路由器希望主機對它假如的每個多播組均發回一個報告。
4主機通過傳送IGMP報告來相應IGMP查詢，假如自己還有程序，則會發這個報告。
幾個注意點，IP層是不可靠的，不一定會被接收。

• 第十四章 DNS：域名系統

域名系統（DNS）是一種用於TCP/IP應用程式的分散式資料庫，他提供主機的名字和IP地址之間的轉換以及電子郵件的選路資訊等。

指標查詢，給定一個IP地址，返回與該地址對應的域名

DNS無論是TCP還是UDP都是用的53埠。
DNS大部分情況用的UDP，因此無論是名字解析器還是名字伺服器都必須自己處理超時和重傳的情況。

區域傳送的時候，會用TCP，此時資料量遠大於一個查詢或者響應。
DNS的查詢和響應都有相同的報文格式。

• 第十五章 TFTP：簡單檔案傳輸協議

TFTP適合於只讀儲存器，僅用於無盤系統進行系統引導。它只使用幾種報文格式，其中一種是停止等待協議。
TFTP協議沒有提供安全特性。

• 第十六章 BOOTP：載入程式協議

BOOTP使用UDP，它為引導無盤系統獲得它的IP地址提供了除RARP外的另一種選擇。且BOOTP還能返回例如，路由器的IP地址，掩碼等。
BOOTP伺服器比RARP伺服器更容易實現。

• 第十七章 TCP：傳輸控制協議

TCP提供了一種可靠的面向連線的位元組流運輸層服務。

• 第十八章 TCP連線的簡歷與終止

最大報文段長度MSS（只有在SYN的報文裡傳送）

2MSL的等待，RFC793指出MSL為2分鐘，但是實際，常用值是30s，60s。

平靜時間：指得是，如果處於2MSL狀態等待的主機發生故障，他會在MSL秒內重新啟動，此時該埠可能還無法使用，因為沒到時間，因此規定，重啟後MSL秒內不能建立任何時間，這個時間則為平靜時間。

FiN_WAIT_2狀態，假如，對方時鐘不發FIN，則一直處於這個狀態。因此實際的實現中，假如這個連線空閒了10分鐘75秒（神奇的數字），則直接進入CLOSED狀態，這個是和協議違和的地方。

復位報文段這個之前也總結過，到達沒有開啟的埠，會有RST，假如某個主機異常重啟，客戶端不知道連線斷了，繼續發訊息，主機會回一個RST。

呼入連線請求佇列：
1 正等待連線請求的一端有一個固定長度的連線佇列，該佇列中的連線已被 T C P接受（即三次握手已經完成），但還沒有被應用層所接受。
2 應用層將指明該佇列的最大長度，這個值通常稱為積壓值 ( b a c k l o g )。它的取值範圍是0 ~ 5之間的整數，包括0和5（大多數的應用程式都將這個值說明為 5）
3 當有新的連線到達時，使用一個演算法，算，是否接收這個，不接受的時候是忽略的姿態（傲嬌態）。積壓值說明的是 TCP監聽的端點已被T C P接受而等待應用層接受的最大連線數。這個積壓值對系統所允許的最大連線數，或者併發伺服器所能併發處理的客戶數，並無影響。（必須的，這個積壓值只是意味著，能接收多快的請求）

• 第十九章TCP的互動資料流

經受時延的確認：原因是，A給B發了一個訊息，B在200ms內，要是也有發A的訊息，則順帶把ACK就帶上了。

Nagle演算法：這個演算法在之前也提到過（糊塗症狀），該演算法要求一個 T C P連線上最多隻能有一個未被確認的未完成的小分組，在該分組的確認到達之前不能傳送其他的小分組。

• 第二十章 TCP的成塊資料流

慢啟動：慢啟動為傳送方的TCP增加了另一個視窗：擁塞視窗congestion window)，記為cwnd。當與另一個網路的主機建立 T C P連線時，擁塞視窗被初始化為 1個報文段（即另一端通告的報文段大小）。每收到一個ACK，擁塞視窗就增加一個報文段（cwnd以位元組為單位，但是慢啟動以報文段大小為單位進行增加）。傳送方取擁塞視窗與通告視窗中的最小值作為傳送上限。擁塞視窗是傳送方使用的流量控制，而通告視窗則是接收方使用的流量控制。

緊急方式：人們常常錯誤地稱其為“帶外資料”。TCP的緊急方式只是一個從傳送方到接收方的通知，該通知告訴接收方緊急資料已被髮送，並提供該資料最後一個位元組的序號。應用程式使用的有關緊急資料部分的程式設計介面常常都不是最佳的，從而導致更多的混亂。

• 第二十一章 TCP的超時與重傳

RTT：往返時間，之前有個部落格提過這個的一種運算方式。

擁塞避免演算法：
1) 對一個給定的連線，初始化cwnd為1個報文段，ssthresh為65535個位元組。
2) TCP輸出例程的輸出不能超過 cwnd和接收方通告視窗的大小。擁塞避免是傳送方使用的流量控制，而通告視窗則是接收方進行的流量控制。前者是傳送方感受到的網路擁塞的估計，而後者則與接收方在該連線上的可用快取大小有關。
3) 當擁塞發生時（超時或收到重複確認），ssthresh被設定為當前視窗大小的一半（cwnd和接收方通告視窗大小的最小值，但最少為2個報文段）。此外，如果是超時引起了擁塞，則cwnd被設定為1個報文段（這就是慢啟動）
4) 當新的資料被對方確認時，就增加cwnd，但增加的方法依賴於我們是否正在進行慢啟動或擁塞避免。如果cwnd小於或等於ssthresh，則正在進行慢啟動，否則正在進行擁塞避免。慢啟動一直持續到我們回到當擁塞發生時所處位置的半時候才停止（因為我們記錄了在步驟 2中給我們製造麻煩的視窗大小的一半），然後轉為執行擁塞避免。
這個圖能幫助理解

快速重傳與快速恢復演算法：
快速重傳我知道，就是連續幾個ACK回來，都表示，有一個沒到，則重傳了。
快速回復應該是指，丟失了後，要突然減少資料流，但是並不想這樣子。
1) 當收到第3個重複的A C K時，將ssthresh設定為當前擁塞視窗 cwnd的一半。重傳丟失的報文段。設定cwnd為ssthresh加上3倍的報文段大小。
2) 每次收到另一個重複的 A C K時，cwnd增加1個報文段大小併發送 1個分組（如果新的
cwnd允許傳送）。
3) 當下一個確認新資料的ACK到達時，設定cwnd為ssthresh（在第1步中設定的值）。這個ACK應該是在進行重傳後的一個往返時間內對步驟 1中重傳的確認。另外，這個ACK也應該是對丟失的分組和收到的第 1個重複的ACK之間的所有中間報文段的確認。這一步採用的是擁塞避免，因為當分組丟失時我們將當前的速率減半。

• 第二十二章 TCP的堅持定時器

如果一個確認丟失了，則雙方就有可能因為等待對方而使連線終止：接收方等待接收資料（因為它已經向傳送方通告了一個非 0的視窗），而傳送方在等待允許它繼續傳送資料的視窗更新。為防止這種死鎖情況的發生，傳送方使用一個堅持定時器 (persist timer)來週期性地向接收方查詢，以便發現視窗是否已增大。這些從傳送方發出的報文段稱為視窗探查 ( windowprobe )。

糊塗視窗綜合徵：
基於視窗的流量控制方案，如TCP所使用的，會導致一種被稱為“糊塗視窗綜合症SWS(Silly Window Syndrome）的狀況。如果發生這種情況，則少量的資料將通過連線進行交換，而不是滿長度的報文段.

• 第二十三章 TCP的保活定時器

保活功能主要是為伺服器應用程式提供的。伺服器應用程式希望知道客戶主機是否崩潰，從而可以代表客戶使用資源。許多版本的Rlogin和Telnet伺服器預設使用這個選項。

在連線空閒兩個小時後，在一個連線上傳送一個探查分組來完成保活功能。可能會發生4種不同的情況：對端仍然執行正常、對端已經崩潰、對端已經崩潰並重新啟動以及對端當前無法到達。我們使用一個例子來觀察每一種情況，並觀察到在最後三個條件下返回的不同差錯。

• 第二十四 TCP的未來和效能

長肥管道
五個新的TCP特徵：路徑MTU發現、視窗擴大選項、時間戳選項、序號
迴繞保護以及使用改進的 TCP事務處理。我們觀察到中間的三個特徵是為在長肥管道——具有大的頻寬時延乘積的網路 — 上優化效能所需要的。

路徑MTU發現在MTU較大時，對於非本地連線，允許 T C P使用比預設的 536大的視窗。這樣可以提高效能。
視窗擴大選項使最大的TCP視窗從65535增加到1千兆位元組以上。時間戳選項允許多個報文段被精確計時，並允許接收方提供序號迴繞保護（ PAWS）。這對於高速連線是必須的。這些新的TCP選項在連線時進行協商，並被不理解它們的舊系統忽略，從而允許較新的系統與舊的系統進行互動。
為事務用的TCP擴充套件，即T/TCP，允許一個客戶/伺服器的請求-應答序列在通常的情況下只使用三個報文段來完成。它避免使用三次握手，並縮短了 TIME_WAIT狀態，其方法是為每個主機快取記憶體少量的資訊，這些資訊曾用來建立過一個連線。它還在包含資料報文段中使用SYN和FIN標誌。
由於還有許多關於TCP能夠執行多快的不精確的傳聞，因此我們以對 TCP效能的分析來結束本章。對於一個使用本章介紹的較新特徵、協調得非常好的實現而言， TCP的效能僅受最大的1千兆位元組視窗和光速（也就是往返時間）的限制。

25-30章都是應用，有需要再看