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机制了，在一个执行绪就可以搞定多目的地传输。