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機制了，在一個執行緒就可以搞定多目的地傳輸。