简单分析一下socket中的bind

【转自】守夜者 灵感来自于积累 的博客 
【原文链接】http://www.cnblogs.com/nightwatcher/archive/2011/07/03/2096717.html
在最开始接触bind的时候，只是在写基于tcp的server端的时候，知道在listen之前需要先bind一下，用来确保socket能在某个固定的端口监听。而bind的时候，函数参数中的端口填自己将要绑定的端口就行；而IP地址，需要填本机的IP，但是也可以用一个宏INADDR_ANY代替，用这个宏就可以不用查找本机的IP，它就可以代替本机的IP。当时只觉得这个INADDR_ANY比较神奇，但是由于当时觉得用起来很方便，也没出啥问题，也就没有再深究。 
但是最近在做RTSP服务器的时候，有种特殊的应用，导致我不得不对bind这个函数仔细地看一下。 
我们知道无论是UDP还是TCP，socket都会与一个本地的IP和端口想对应，我们往往把这个IP和端口称之为socket的源地址和源端口。当我们作为客户端利用socket去发送数据时，很少会去考虑这个源地址和源端口到底是什么，我们更关心的是它的目的地址和端口。我们往往只有在监听的时候，才去考虑这个源端口，所以我们在监听的时候会去用bind。当我们bind之后，内核就会将这个socket的源端口锁定到我们设定的端口上。但是这就有一个问题，这个bind绑定端口，是将本来没有源端口的socket绑定到我们指定的端口上，还是将一个已经分配了端口的socket重定向到我们指定的端口上呢？ 
在《UNIX网络编程》这本书中提到：“如果一个TCP客户或者服务器未曾调用bind捆绑一个端口，当调用connect或listen时，内核就要为相应的套接字选择一个临时接口。”从这句话中可以判断出，其实在调用socket函数创建socket时，内核还并未给socket分配源地址和源端口。而对于UDP，我猜测在调用sendto发送数据时，在未捆绑端口的情况下，内核也会随机分配端口。 
而我遇到的特殊应用要求我在用UDP发送数据之前要告诉对方我的发送端口，这也就意味着我在sendto之前必须要捆绑端口，因此我在发送数据之前就得调用bind函数绑定一下端口了。但是我就在想内核既然有随机分配端口的能力，而我需要的也只是让它绑定一下而不用绑定在固定端口的业务，socket中应该能够提供这种业务。然后果然我发现bind就具备这种能力，当bind的参数中端口地址为0的时候，这时候就是由内核分配端口。这样我就不用考虑端口地址重复的问题，而放心的把这个问题交给内核处理了。 
就在发现bind的这个机制的同时，我发现其实bind对于源地址也同样具备这种处理方式，当系统具有多IP（多网卡）的情况，当我们把bind函数中的ip参数置0时，就是由内核自己选择分配IP。而之前一直觉得很神奇的INADDR_ANY其实一点也不神奇，它的值其实就是0。所以当我们只有单一IP的时候，我们就可以用INADDR_ANY去代替那个单一的IP，因为内核分配的时候只能选择这一个IP。从而造成了INADDR_ANY就是本机IP的现象。