OSI以及分層模型

OSI分層 （7層）：物理層、資料鏈路層、網路層、傳輸層、會話層、表示層、應用層。
TCP/IP分層（4層）：網路介面層、 網際層、運輸層、 應用層。
五層協議（5層）：物理層、資料鏈路層、網路層、運輸層、 應用層

OSI的7層模型主要是理論研究的意義，而實際使用的是4層的TCP/IP模型(而TCP/IP的第4層網路介面層並沒有什麼實際的內容)。5層模型是7層模型和TCP/IP四層模型的一個折中，僅僅用於學習網路的原理。

OSI的7層模型每一層的作用如下：
1. 物理層：通過媒介傳輸位元,確定機械及電氣規範（位元Bit）
2. 資料鏈路層：將位元組裝成幀和點到點的傳遞（幀Frame）
3. 網路層：負責資料包從源到宿的傳遞和網際互連（包Packet）
4. 傳輸層：提供端到端的可靠報文傳遞和錯誤恢復（段Segment）
5. 會話層：建立、管理和終止會話（會話協議資料單元SPDU）
6. 表示層：對資料進行翻譯、加密和壓縮（表示協議資料單元PPDU）
7. 應用層：允許訪問OSI環境的手段（應用協議資料單元APDU）

5層理論分析模型的每一層作用如下：
1. 應用層：直接為使用者的應用程序提供服務
2. 傳輸層：負責兩個主機中程序間的通訊提供服務
3. 網路層：負責為分組交換網上的不同主機提供通訊服務；選擇合適的路由傳送分組
4. 資料鏈路層：將網路層交付下來的分組封裝為幀，在相鄰節點的鏈路上傳遞幀中的資料
5. 物理層：透明的傳送位元流

IP地址分類

A類地址：以0開頭，第一個位元組範圍：0~127（1.0.0.0 - 126.255.255.255）
B類地址：以10開頭，第一個位元組範圍：128~191（128.0.0.0 - 191.255.255.255）
C類地址：以110開頭，第一個位元組範圍：192~223（192.0.0.0 - 223.255.255.255）
D類地址：以1110開頭，作為多播地址
保留地址：10.0.0.0—10.255.255.255， 172.16.0.0—172.31.255.255， 192.168.0.0—192.168.255.255。

TCP與UDP的區別

TCP（Transmission Control Protocol，傳輸控制協議）是面向連線的協議，也就是說，在收發資料前，必須和對方建立可靠的連線。

UDP（User Data Protocol，使用者資料報協議）是一個非連線的協議，傳輸資料之前源端和終端不建立連線，當它想傳送時就簡單地去抓取來自應用程式的資料，並儘可能快地把它扔到網路上。

兩者的區別：
1. 基於連線與無連線；
2. 對系統資源的要求TCP較多，UDP少；
3. UDP程式結構較簡單；
4. 流模式(TCP把資料看做是無結構的位元組流)與資料報模式(UDP是面向資料報)；
5. TCP保證資料正確性，UDP可能丟包，TCP保證資料順序，UDP不保證

TCP報文首部格式

TCP的三次握手與四次揮手過程及TIMEWAIT的作用

三次握手建立連線：
首先Client端傳送連線請求報文，Server段接受連線後回覆ACK報文，併為這次連線分配資源。Client端接收到ACK報文後也向Server段發生ACK報文，並分配資源，這樣TCP連線就建立了

如果三次握手修改為兩次握手，那麼會存在一種”已失效連線請求報文段”造成的無效連線的情況。假設在如下場景下，採用2次握手。client傳送一個請求報文段給server，而這個報文段在網路的某個地方阻塞了，那麼clent超時重新發送一個連線請求報文段，此時server收到第二個連線請求報文段，併為連線分配資源，建立連線,並在該連線上傳送資料，之後斷開連線。如果連線斷開之後，之前阻塞的請求建立報文又傳送給了server，那麼此時如果是2次握手，server會為這個遲到的無效請求報文建立一個無效的連線，而client並沒有資料要傳送給server,這樣資源就被浪費了。

四次揮手斷開連線：
中斷連線端可以是Client端，也可以是Server端。假設Client端發起中斷連線請求，也就是傳送FIN報文。Server端接到FIN報文後，意思是說”Client端沒有資料要發給你了”，但是如果server還有資料沒有傳送完成，則不必急著關閉Socket，可以繼續傳送資料。所以server先發送ACK，”告訴Client端，請求我收到了，但是我還沒準備好，請繼續等我的訊息”。這個時候Client端就進入FIN_WAIT狀態，繼續等待Server端的FIN報文。當Server端確定資料已傳送完成，則向Client端傳送FIN報文，”告訴Client端，好了，我這邊資料發完了，準備好關閉連線了”。Client端收到FIN報文後，”就知道可以關閉連線了，但是他還是不相信網路，怕Server端不知道要關閉，所以傳送ACK後進入TIME_WAIT狀態，如果Server端沒有收到ACK則可以重傳。“，Server端收到ACK後，”就知道可以斷開連線了”。Client端等待了2MSL後依然沒有收到回覆，則證明Server端已正常關閉，那麼Client端也可以關閉連線了。

斷開連線需要四次的原因是存在被請求斷開連線的一段，在收到斷開連線請求的時候可能還有資料需要傳送，所以只能對請求進行回覆，但是並不能立刻斷開連線，也就是斷開的時候雙方都需要在自己沒有資料傳送的時候傳送一個fin報文，並且得到對方的ack。

至於最後TIME-WAIT需要等待2MSL（2倍的報文最長生存時間）的原因，主要有兩點：
1. 保證請求斷開連線的一端A最後傳送的一個確認關閉ack一定可以傳送到對方B。在B收到A的最後一個ack的時候，存在該ack丟失的情形，所以A在等待2MSL期間，可以收到B重傳的fin+ack。A在收到重傳的fin+ack之後重新發送確認並重置2MSL計時器。這樣可以保證B可以正常的關閉，如果等待時間少於2MSL，那麼可能A關閉之後，B卻因為沒有收到這個ack而一直重傳fin+ack而無法關閉。
2. 防止出現”已失效連線請求報文段”。因為在傳送最後一個ack之後，等待2MSL可以保證此次連線過程中產生的所有報文都會消失，保證在新建立連線的時候不會受到前一次連線中的阻塞請求連線報文的影響(UNP中對這種情況有詳細的說明)。

補充：
TCP 保活計時器：假設客戶端和伺服器建立的TCP連線，但是此時客戶端故障而非正常的斷開了這個連線，伺服器並不知道客戶端之間的連線是否存在，因此可能無謂的等待在這個失效的連線上。因此需要採用一種機制來避免，服務端採用的措施就是在每次接收到客戶端的資料的時候就重啟一個保活計時器(大概2小時),如果保活計時器到時之後服務端仍然沒有收到資料，那麼服務端就傳送一個探測報文，每隔75分鐘傳送一個，連續10個報文都沒有收到客戶端的響應，就認為客戶端意外斷開。

TCP擁塞控制

計算機網路中的頻寬、交換結點中的快取和處理機等，都是網路的資源。在某段時間，若對網路中某一資源的需求超過了該資源所能提供的可用部分，網路的效能就會變壞。這種情況就叫做擁塞。

擁塞控制就是防止過多的資料注入網路中，這樣可以使網路中的路由器或鏈路不致過載。擁塞控制是一個全域性性的過程，和流量控制不同，流量控制指點對點通訊量的控制，流量控制是讓資料傳送端減慢資料的傳送速度。

擁塞控制方法：
1. 慢開始( slow-start )
2. 擁塞避免( congestion avoidance )
3. 快重傳( fast retransmit )
4. 快恢復( fast recovery )

TCP擁塞控制主要過程
慢啟動階段：
當建立新的TCP連線時，擁塞視窗（congestion window，cwnd）初始化為一個數據包大小。源端按cwnd大小發送資料，每收到一個ACK確認，cwnd就增加一個數據包傳送量，這樣cwnd就將隨著迴路響應時間（Round Trip Time，RTT）呈指數增長，源端向網路傳送的資料量將急劇增加。由於在發生擁塞時，擁塞視窗會減半或降到1，因此慢啟動確保了源端的傳送速率最多是鏈路頻寬的兩倍。

擁塞避免階段：
如果TCP源端發現超時或收到3個相同ACK副本時，即認為網路發生了擁塞（主要因為由傳輸引起的資料包損壞和丟失的概率很小（<<1%））。此時就進入擁塞避免階段。慢啟動閾值（ssthresh）被設定為當前擁塞視窗大小的一半；如果超時，擁塞視窗被置1。如果cwnd>ssthresh，TCP就執行擁塞避免演算法，此時，cwnd在每次收到一個ACK時只增加1/cwnd個數據包，這樣，在一個RTT內，cwnd將增加1，所以在擁塞避免階段，cwnd不是呈指數增長，而是線性增長。

快速重傳和快速恢復階段：
快速重傳是當TCP源端收到到三個相同的ACK副本時，即認為有資料包丟失，則源端重傳丟失的資料包，而不必等待RTO超時。同時將ssthresh設定為當前cwnd值的一半，並且將cwnd減為原先的一半。快速恢復是基於“管道”模型（pipe model）的“資料包守恆”的原則（conservation of packets principle），即同一時刻在網路中傳輸的資料包數量是恆定的，只有當“舊”資料包離開網路後，才能傳送“新”資料包進入網路。如果傳送方收到一個重複的ACK，則認為已經有一個數據包離開了網路，於是將擁塞視窗加1（這裡的1是1個報文段長度，實際上收到3個重複ack，視窗就增加了3）。

TCP滑動視窗以及回退N(Go-Back-N)

滑動視窗協議的基本原理就是在任意時刻，傳送方都維持了一個連續的允許傳送的幀的序號，稱為傳送視窗；同時，接收方也維持了一個連續的允許接收的幀的序號，稱為接收視窗。傳送視窗和接收視窗的序號的上下界不一定要一樣，甚至大小也可以不同。不同的滑動視窗協議視窗大小一般不同。傳送方視窗內的序列號代表了那些已經被髮送，但是還沒有被確認的幀，或者是那些可以被髮送的幀。

後退n協議中，傳送方在發完一個數據幀後，不停下來等待應答幀，而是連續傳送若干個資料幀，即使在連續傳送過程中收到了接收方發來的應答幀，也可以繼續傳送。而幀的確認採用累積確認的方式，也就是接收方不對接收到的幀逐個進行確認，而是子收到若干個分組之後，對按序到達的連續分組的最後一個分組傳送確認，代表到該分組為止的所有分組都被確認收到。這種累積確認的優點是實現起來比較容易，而且對於丟失的確認不必進行重傳。但是缺點是無法正確的向傳送方反映已經接受到的分組。比如，當前傳送方連續傳送了5個分組，其中第三個分組丟失了，其他四個正確接收到，那麼由於只能對前面兩個分組進行確認，因此傳送方並不知道後面3個分組的實際接收情況。於是就需要將後面的3個分組都重傳一次。這就是回退N幀，即需要再回退並重傳已經發送的N個分組。這種協議在通訊質量不好的情況小效率將會變得很低，造成大量的重複分組的傳送。