UDP/TCP與fork

1.既然UDP是無連接配接不保證送達的，那麼就沒有必要在關閉時通知對方了，因為這個“關閉”消息也不能保證送達，不僅如此，任何的控制資訊諸如确認都不便在傳輸層發送，因為不能保證送達。UDP是基于資料報的，第一個資料報和随後同源同目的的第二個資料報之間沒有任何的關系。是以不要指望對端能收到自己closesocket的消息，即使是有人想出用帶外資料傳輸也是徒勞的，是以隻能通過逾時機制或者心跳機制來保活；

2.對于tcp，其比udp開銷大，大就大在協定頭的空間開銷和重傳以及ip分段的時間開銷，确認并不算什麼開銷，而是可以直接就近連帶傳回的；

3.所謂的udp不拆分并不是指udp封包不分段，而是在傳輸層不拆分，在ip層還是會被分段的，視MTU而定，網絡層的分段和傳輸層的拆分并沒有什麼關系，源之後目的地之前的網絡裝置邏輯上不會觸及網絡層之上，除非實體上要做連接配接跟蹤或者七層過濾等等，資料在到達目的地後，送往傳輸層之前，ip層會将分段的資料重新組裝好。

4.TCP的connect/accept模型和unix/linux的fork模型類似，而UDP則類似于單程序單執行緒模型，它們是如此的類似，由于tcp是有連接配接的，是以如果n個用戶端連接配接同一個伺服器，那麼該伺服器必須能夠區分這n個用戶端，從資源消耗以及事先不知道有多少潛在用戶端的角度考慮，不能想象有n個伺服器程序事先在等待，套接字accept模型完美的解決了這個問題，方式正和fork機制一樣，在程序模型中，隻有在有新的作業時才fork出一個新的執行緒，accept也是同樣，有新的用戶端連接配接時就傳回一個新的套接字描述符，然後繼續accept，是以對于有連接配接的協定，首先要有一個監聽套接字，它正如unix的init程序一樣，一旦有新的用戶端就傳回一個新的套接字(對于init程序就是fork出一個新的子程序後init程序繼續監聽或者收養孤兒)。我想accept模型也是從fork中學習的，起初網絡通信隻用于遠端終端連接配接，主機并不知道一共會有幾個終端要連接配接，是以就讓一個程序getty等待在主機，一旦有終端連接配接，getty就會fork出一個shell并且建立一個僞終端對用于服務建立的遠端終端，也許，僅僅是也許，套接字學習了unix的fork這種模式，産生了accept模型，在unix中，fork一次就會産生一個獨立執行緒，英文表達中有一個thread單詞，該詞就有“線”“序列”的意思，正和“連接配接”語義相近，都有一種上下銜接的含義，這也許又是二者的另一種淵源吧。udp就沒有這樣的需求，udp可以在一個套接字上将一份資料分發給不同的接收方，因為其sendto接口中就帶有位址資訊，如此udp套接字隻需要一對即可，是以也就不需要accept機制了，在一個執行緒就可以搞定多目的地傳輸。

 本文轉自 dog250 51CTO部落格，原文連結:http://blog.51cto.com/dog250/1271810