計算機網絡的傳輸層的簡單介紹：

在應用層下爲傳輸層，如TCP與UDP；

傳輸層與網絡層之間的不一樣： 傳輸層負責信息在主機進程與服務器進程之間的傳遞； 網絡層負責信息在主機與服務器之間的傳遞；     差了一個進程啊；

傳輸層的信息用：segment 表示；它是這樣獲得的：把應用層的message 分紅一塊塊，而後再加上傳輸層的文件頭；

另外，TCP的信息也會用segment表示，UDP的信息用datagram（數據報）表示；網絡層上的message也用datagram表示；

UDP：user datagram protocol; 它只會進行兩個服務：1， 進程之間的數據交付；2，error checking;

TCP: transmission control protocol; 它進行的服務比較多，由於它是可靠傳輸；如：數據流控制等；

 

多路複用與多路分解：

因爲傳輸層的做用是把信息交付給不一樣的socket， 因此呢，在應用層與傳輸層之間須要用到了多路複用與多路分解；

多路複用指：不一樣的socket的信息加入身份確認標誌，通通變爲爲segment，而後用傳輸層交給了下面的網絡層進行傳送；

多路分解指：把不少segment交付給不一樣的socket；

要求：1， 存在不一樣的socket以及對應的端口；2， 每個segment上應該用用於identify的field，裏面的信息爲源端口與目的端口；

（補：端口的範圍爲0-65536，其中0-1023不能隨便用，由於它是專用的，如HTTP等 或保留着呢，其它的能夠隨意用了；）

在一個傳輸層的segment中的用於識別的字段結構以下圖，頭佔了8個字節：

 

無鏈接的多路利用/分解與面向鏈接的多路利用/分解

UDP的多路利用/分解：一個UDP socket使用目的主機的IP與目的主機的端口來肯定；

TCP的socket：由源IP、源端口、目的IP、目的端口來肯定；（一開始的握手segment除外）， 因此呢，TCP的socket能夠有相同的端口，如WEB服務器的端口好像都是80吧（無故創建鏈接的socket仍是用於傳輸數據的socket）；

 

UDP：

很簡單，它把應用層的數據加一個頭就變爲了UDP的segment. 它的segment的結構以下圖所示：

它的頭包括4個fields， 每個field的大小爲：2字節；內容分別爲： 源端口，目的端口，數據的長度和checksum(用於糾錯）；

下面的application data，爲應用層的數據；

 

可靠的傳輸：

問題1：如何解決發送的packet有誤的問題？？

解決方法：版本1：當receive收到消息之後，就回復一個ACK（acknowledgment), 若是沒有收到的消息出錯了，就發送一個NAK，表示讓發送者再從新發一遍；

              進級：爲每個信息加一個sequence numbeer, 當收到的信息有誤時，不發送該消息的NAK了，而是發送上一個收到的正確的消息的ACK;

問題2： packet在發送過程當中，若是Loss怎麼辦？

解決方法：加入消息重發機制； 當數據loss後，發送者確定就收不到ACK信息了， 加入一個計時器timer，超過必定的時間就重發；

問題3：如何提升傳輸的效率？

解決方法：採用流水線設計，具體爲： go back N 和 selective repreat;

(裏面有一些細節，省略不寫，例如：要求未迴應的信息的個數不大於N,等）

 

TCP：

它的結構以下圖：

它的頭，佔了20個字節；

總的來看TCP， 

最主要的三點吧：

第一，如何進行可靠的傳輸，包括內容與順序； 解決方法：對於錯誤的或loss的進行重傳， 對於不是順序的能夠進行丟棄或緩存下來；

其中，怎麼判斷的問題：一個是timeout，一個是收到3個同一字段有ACK;   對於ACK，TCP採用的是accumulative 的方法，這一點很重要的；

另外的怎麼計算timeout的時間啦，怎麼重發等細節省略；

第二點：  對於如何解決flow 問題與confession問題，方法基本相同，就是控制發送方的rate（或窗口大小）, 可是二者的緣由不一樣，一個是由於接收者上層應用接收的慢，一個是因爲網絡堵塞； 對於如何把出現上述緣由的狀況反饋給發送者呢： 前者使用ACK信息裏的的相應字段來解決；後者根據ACK到達發送者的狀態，如loss了，仍是收到了3個多餘的重複的ACK來判斷，其中固然還有細節；

第三點： 如何使用流水線進行提升效率的問題：關鍵字：並行發，consequence number, ACK number, 還有一個發送窗口；

 

另外，對於三次握手的創建過程的原理，字段的做用等，也頗有意思；能夠利用這個原理寫端口掃描工具啦，進行網絡攻擊等；

 

 

 

###################      2017年9月補          ########################

1、 瞭解端口號：

1.瞭解端口號； 0-1023爲周知端口號；

2. 一個UDP的套接字由目的IP地址與目的端口號來全面標識； TCP的套接字由源端口號、源IP地址、目的端口號、目的IP地址來識別；

3. 在這一層，數據常被稱爲報文段；

2、 UDP協議：

1. 使用DUP協議的例子：

2. UDP的報文段結構

如圖所示：首部由4個字段組成，每一個字段2個字節；

長度：包括首部在內的所有的UDP的報文段長度，單位爲字節；

3.

3、可靠數據傳輸：

一、 ARQ協議，自動重傳請求協議；收到消息後，給一個應答來告訴是否收到了，收到回答ACK， 沒有聽清回答NAK；

2. 後來改進：加入了一個seq， 收到了就回答對應的seq,沒有收到或收到錯誤的什麼也不幹， 由於加入了一個定時器，超時就重傳；

3. 一個一個的傳有點慢，採用了流水線的形式，而後，對於差錯恢復問題的兩個基本方法：GBN（回退N步）協議和SR（選擇重傳）協議；

  GBN協議：只要是否是按順序到的分組，所有都丟棄； SR協議中則會緩存到一個地方；

4. 一個重的的控制傳輸多少個分組的：滑動窗口協議；

4、 TCP協議

1. TCP報文段對構：

 

32比特的序號與確認號： 

16比特的接收窗口：

4比特的首部長度：

可選與變長的選項字段：

6比特的標誌字段：

• ACK：確認位，只有ACK=1的時候ack才起做用。正常通訊時ACK=1，第一次發起請求時由於沒有須要確認接收的數據因此ACK爲0。
• SYN：同步位，用於在創建鏈接時同步序號。剛開始簡歷鏈接時並無歷史接收的數據，因此ack就沒辦法設置，這時按照正常的機制就沒法運行了，SYN的做用就是來解決這個問題的，當接收端接收到SYN=1的報文時就會直接將ack設置爲接收到的seq+1的值，注意這裏的值並非校驗後設置的，而是根據SYN直接設置的，這樣正常的機制就能夠運行了，因此SYN叫同步位。須要注意的是，SYN會在前兩次握手時都爲1，這是由於通訊的雙方的ack都須要設置一個初始值。
• FIN：終止位，用來在傳輸數據完畢後釋放鏈接。
• RST 置1時重建鏈接。若是接收到RST位時候，一般發生了某些錯誤。
• ACK 置1時表示確認號（爲合法，爲0的時候表示數據段不包含確認信息，確認號被忽略。
• PSH 置1時請求的數據段在接收方獲得後就可直接送到應用程序，而沒必要等到緩衝區滿時才傳送。
• URG（緊急位）: 急指針是一個正的偏移量，和序號字段中的值相加表示緊急數據最後一個字節的序號。T C P的緊急方式是發送端向另外一端發送緊急數據的一種方式。緊急指針指向包內數據段的某個字節(數據從第一字節到指針所指字節就是緊急數據,不進入接收緩衝就直接交給上層進程,餘下的數據要進入接收緩衝的)                           其中URG不能和PSH標誌位同時使用，也對；由於緊急數據後面的要進緩衝區的；

16比特的緊急數據指針：用於指出緊急數據的最後一個字節位置；

TCP要傳輸的數據的最大值叫作最大報文段長(MSS); 它指的是最大的應用數據的長度， 不是包括TCP頭部的最大TCP報文長度；MSS的大小受限於MTU；

 

2. TCP鏈接的創建與斷開

創建鏈接：

 

斷開鏈接：

 

3. TCP擁塞的控制：

參考這裏： 寫的很好;

  TCP/IP詳解--擁塞控制 & 慢啓動 快恢復 擁塞避免

 

 

參考：計算機網絡第六版，自頂向下；