傳輸層協議與行程通信
乍一看標題，咦，行程通信？學作業系統了，我也很詫異，
這一章very important，同時內容太多，會按照自己的理解【自己心目的重要性進行內容篇幅的分配】來組織，
3.1 傳輸層基本概念
網路層進行的是“主機->主機”間的通信(是第四章的內容)，我們俗稱就是“點->點”，傳輸層剛好在其上面一層，其能實作的是主機行程間(就是我們作業系統里那個pid)的通信，我們稱為“端->端”通信，
網路層是由運行商提供服務的（中國移動，聯通……），用戶只能在其上加上一層傳輸層來改善服務質量，比如賦予傳輸層一些功能：對分組丟失或者線路故障進行檢測，再厲害一點就可以進行補救，
概念：傳輸層中實作傳輸協議的硬體和軟體稱為“傳輸物體”【可能在作業系統內核或者單獨的行程中】，傳輸層間傳輸的報文我們稱為“TPDU（transport protocol data unit）”，報文格式長這樣：
有效資料來自應用層，傳輸層負責加上TPDU頭部，
網路層中加上IP分組頭部后，最后到資料鏈路層加上幀頭和幀尾就成功了，
這里有個Socket套接字，這個比較適用于編程實踐當時java被逼死，建議好好學Python吧，總感覺同為腳本解釋語言，Python好一丟丟 所以就粗略講一下概念，整體的概念圖如下：
當然了我們就是開發者，我們站在應用層最高的角度看問題，屏蔽了很多問題（無需考慮物理鏈路……），
至于TCP和UDP傳輸協議，在Linux作業系統中有tcp.c源代碼，也就是說協議這玩意兒人家都給你設計好了，你啥都不用管，
你用“Socket”管啥？
你可以選擇TCP或者UDP、你也可以設定你的最大快取（是接受或發送取決于你的角色是服務器還是客戶端）、最大報文快取……就醬，
前邊我們說了傳輸層干的就是“端->端”通信，那么一個重要問題就是怎么標志一個端？其實就是標識一個行程，我其實前面也已經提到作業系統里的知識啦，就是那個pid，我們在Linux系統下可以用ps或者top還有其他來看，
那么在計網中，我們稱之為埠號，畢竟聽起來也和“端->端”更搭配，
簡單的例子：
一個IP地址為202.1.2.5的客戶端用3022號埠號，那么其套接字就是
202.1.2.5:3022，
216 = 65536，這就是我們所有的埠號了（0～65535），
我們將其做一些分類：
比如一些比較常用的服務行程像什么域名決議DNS就得到53，什么超文本傳輸協議HTTP得到80，除非你和我說你不上網！！ 這類服務行程非常重要且常用，我們稱為“熟知埠號”：給每種服務器分配確定的全域埠號，范圍為（0～1023），
我們當然也需要一些臨時埠號，當服務行程運行時由TCP/IP協議隨機選取的，范圍在（49152～65535），
顯然了，還有中間一些埠號，這些是在IANA注冊的埠號，
這一塊我自己猜測就是考個熟知的服務的埠號吧，應該不會考范圍，臨時的也沒啥好考，注冊的話課本都沒啥針對性，所以到時候記一下下面這張表：
我們剛剛講過一個套接字的結構，IP+埠號，
那么要標識一個行程實際上需要一個三元組，是 協議+IP+埠號，無非多了一個協議，UNIX中這也稱為“半相關”，應該不會這么惡心考這個吧？
然而當我們要進行通信時，需要的是一個五元組：
協議+源IP+源埠+目的IP+目的埠，UNIX稱相關，
多路復用和多路分解：
這個技術用得還是比較廣泛的，但不涉及計算機相關？？
我們需要了解就是這項技術的內容和含義：
其允許同時運行不同協議堆疊上的不同的行程，如下圖所示：
SMTP，HTTP，DNS，SNMP同時運行，不難理解，你可以開網頁的時候發郵件，可以邊看電影邊聊天……
OK小節結束，
對了，3.2原本應該是TCP和UDP對比，我尋思這兒連啥是啥都不知道搞嗎子對比？
3.2
這一節仔細講講UDP，
這是傳輸層的一種協議，其設計核心思想是簡潔高效，也正因為其簡潔，其可靠性相較于TCP會較差，它較適合在低延遲、高可靠的局域網進行，
下面是特點簡述：
【總感覺問答題這個還挺可能考的，不知道哪里的自信】
1.面向無連接，不可靠的傳輸協議，有人會說了，這是個錘子特點，害，咱也沒說是優點是吧哈哈， 無連接會減少協議開銷和傳輸的延時啊，**其報文結構里有校驗和選項但只是可選項！**如果采用了校驗和，且查出了這報文有問題，那么其只是丟棄，不會通知重傳，對于UDP，一個較好的形容詞就是“盡力而為”！
2.面向報文的傳輸，對于應用層提交的資料報文，其不做任何處理就是加個UDP頭部，就會給到IP分組，最后成TPDU……
所以，這就要求我們資料報文長度適中，
太短？如果說UDP報文頭比你資料報還長，那么效率大大降低，
太長？IP層會進行分段，對方需要為你重組，必然也會降低效率，
ppt上還有一些特點，如報文頭短：只要8Byte【TCP 要20B】，支持多對多的互動通信，
報文格式：（8位 = 1Byte別忘了哦）
根據UDP協議的特點，我們可以總結出其適用的范圍：
1.對性能的要求高于對資料完整性的要求，視頻就是典型的例子，視頻少掉一兩幀你都反應不過來！卡死了你就罵街，垃圾網路，我***，
2.需要“簡單快捷”的資料交換，只需要進行簡單的請求和應答報文互動，如在線游戲，它問你“是or否”，你就點一個？我是這么理解的，
3.需要廣播和多播的應用，源主機會恒定的發送報文，擁塞時會丟棄部分報文，
當然了其缺點也很明顯，沒有必須的差錯控制機制，校驗和只是可選的！
擁塞嚴重時缺乏必要的擁塞控制和調節機制，路堵了還往上開是不對的！
校驗和
這個是差錯控制一個較好的機制，TCP和UDP計算校驗和方式是類似的，雖然老師說了這種題考了怕錯一大堆（粗心，算錯，漏了步驟……）所以可能會體諒一下我們不考 ，但還是掌握一下吧，
這里用課本上的例子看一遍：
1.我們會在UDP資料報上面加上一個偽報頭，這個偽報頭來自IP報頭，
偽報頭簡要解釋：
第一行變為4Byte的源IP，第二行則是4Byte的目的IP，填充0，協議號17為UDP，長度為15【和UDP自己的長度里的15是一致的】，
長度 = 4 × 3（第四、五、六行都是4Byte） + 3（第七行有3Byte，0是填充位，為了湊16的整數倍） = 15Byte
2. 先為校驗和設定為0，
3. 不難看出我們每16bit一行寫出，
4. 資料位也會補0至最后資料行也是16的整數倍，
5. 求和運算，注意是回圈求和！
回圈求和就是最高位有時候還會溢位，溢位位會再給到第一位，直到最后完全停止，
那么一定要注意轉換（十進制->二進制千萬先別搞錯啊！！），還是別一串一起加吧，兩兩來吧……
應該是沒啥問題的哈，后續想附一下代碼，看看有沒有簡便方法，【還是有點麻煩，】
后續的話就是把此值插入到校驗和中，刪掉偽報頭和填充位，
那么如何驗證呢？
接收方得到的是有填充check sum的報文，同樣是按上述操作：
加偽報頭，資料位填充，分為16bit計算，回圈求和，最后結果取反碼，只要全為0，就可以證明報文正確，否則就認為報文傳輸程序中出錯！！
【咱也不知道為啥，也沒看過證明，但計算機的嘛，主要還是得會求上一個吧，后面這個證明不咋重要，但定理得知道！！】
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/287611.html
標籤：其他
上一篇：c/c++學生成績管理系統
下一篇：如何選配一臺筆記本