深入理解socket(转)

要写网络程序就必须用 Socket ，这是程序员都知道的。而且，面试的时候，我们也会问对方会不会 Socket 编程？一般来说，很多人都会说， Socket 编程基本就是 listen ， accept 以及 send ， write 等几个基本的操作。是的，就跟常见的文件操作一样，只要写过就一定知道。

 

对于网络编程，我们也言必称 TCP/IP ，似乎其它网络协议已经不存在了。对于 TCP/IP ，我们还知道 TCP 和 UDP ，前者可以保证数据的正确和可靠性，后者则允许数据丢失。最后，我们还知道，在建立连接前，必须知道对方的 IP 地址和端口号。除此，普通的程序员就不会知道太多了，很多时候这些知识已经够用了。最多，写服务程序的时候，会使用多线程来处理并发访问。

 

我们还知道如下几个事实：

1 。一个指定的端口号不能被多个程序共用。比如，如果 IIS 占用了 80 端口，那么 Apache 就不能也用 80 端口了。

2 。很多防火墙只允许特定目标端口的数据包通过。

3 。服务程序在 listen 某个端口并 accept 某个连接请求后，会生成一个新的 socket 来对该请求进行处理。

 

于是，一个困惑了我很久的问题就产生了。如果一个 socket 创建后并与 80 端口绑定后，是否就意味着该 socket 占用了 80 端口呢？如果是这样的，那么当其 accept 一个请求后，生成的新的 socket 到底使用的是什么端口呢（我一直以为系统会默认给其分配一个空闲的端口号）？如果是一个空闲的端口，那一定不是 80 端口了，于是以后的 TCP 数据包的目标端口就不是 80 了 -- 防火墙一定会组织其通过的！实际上，我们可以看到，防火墙并没有阻止这样的连接，而且这是最常见的连接请求和处理方式。我的不解就是，为什么防火墙没有阻止这样的连接？它是如何判定那条连接是因为 connet80 端口而生成的？是不是 TCP 数据包里有什么特别的标志？或者防火墙记住了什么东西？

 

后来，我又仔细研读了 TCP/IP 的协议栈的原理，对很多概念有了更深刻的认识。比如，在 TCP 和 UDP 同属于传输层，共同架设在 IP 层（网络层）之上。而 IP 层主要负责的是在节点之间（ End to End ）的数据包传送，这里的节点是一台网络设备，比如计算机。因为 IP 层只负责把数据送到节点，而不能区分上面的不同应用，所以 TCP 和 UDP 协议在其基础上加入了端口的信息，端口于是标识的是一个节点上的一个应用。除了增加端口信息， UPD 协议基本就没有对 IP 层的数据进行任何的处理了。而 TCP 协议还加入了更加复杂的传输控制，比如滑动的数据发送窗口（ Slice Window ），以及接收确认和重发机制，以达到数据的可靠传送。不管应用层看到的是怎样一个稳定的 TCP 数据流，下面传送的都是一个个的 IP 数据包，需要由 TCP 协议来进行数据重组。

 

所以，我有理由怀疑，防火墙并没有足够的信息判断 TCP 数据包的更多信息，除了 IP 地址和端口号。而且，我们也看到，所谓的端口，是为了区分不同的应用的，以在不同的 IP 包来到的时候能够正确转发。

 

TCP/IP 只是一个协议栈，就像操作系统的运行机制一样，必须要具体实现，同时还要提供对外的操作接口。就像操作系统会提供标准的编程接口，比如 Win32 编程接口一样， TCP/IP 也必须对外提供编程接口，这就是 Socket 编程接口 -- 原来是这么回事啊！

 

在 Socket 编程接口里，设计者提出了一个很重要的概念，那就是 socket 。这个 socket 跟文件句柄很相似，实际上在 BSD 系统里就是跟文件句柄一样存放在一样的进程句柄表里。这个 socket 其实是一个序号，表示其在句柄表中的位置。这一点，我们已经见过很多了，比如文件句柄，窗口句柄等等。这些句柄，其实是代表了系统中的某些特定的对象，用于在各种函数中作为参数传入，以对特定的对象进行操作 -- 这其实是 C 语言的问题，在 C++ 语言里，这个句柄其实就是 this 指针，实际就是对象指针啦。

 

现在我们知道， socket 跟 TCP/IP 并没有必然的联系。 Socket 编程接口在设计的时候，就希望也能适应其他的网络协议。所以， socket 的出现只是可以更方便的使用 TCP/IP 协议栈而已，其对 TCP/IP 进行了抽象，形成了几个最基本的函数接口。比如 create ， listen ， accept ， connect ， read 和 write 等等。

 

现在我们明白，如果一个程序创建了一个 socket ，并让其监听 80 端口，其实是向 TCP/IP 协议栈声明了其对 80 端口的占有。以后，所有目标是 80 端口的 TCP 数据包都会转发给该程序（这里的程序，因为使用的是 Socket 编程接口，所以首先由 Socket 层来处理）。所谓 accept 函数，其实抽象的是 TCP 的连接建立过程。 accept 函数返回的新 socket 其实指代的是本次创建的连接，而一个连接是包括两部分信息的，一个是源 IP 和源端口，另一个是宿 IP 和宿端口。所以， accept 可以产生多个不同的 socket ，而这些 socket 里包含的宿 IP 和宿端口是不变的，变化的只是源 IP 和源端口。这样的话，这些 socket 宿端口就可以都是 80 ，而 Socket 层还是能根据源 / 宿对来准确地分辨出 IP 包和 socket 的归属关系，从而完成对 TCP/IP 协议的操作封装！而同时，放火墙的对 IP 包的处理规则也是清晰明了，不存在前面设想的种种复杂的情形。

 

明白 socket 只是对 TCP/IP 协议栈操作的抽象，而不是简单的映射关系，这很重要！

 

 

 

 

： 网络编程也 进行了一段时间了，最近在看ruby的时候，发现 基本的套接字函数理解都有问题。要反思啊

 

=================================================

BSD中的 socket编程中 ，tcp 服务器端 accept的原型是这样的

int accept(int sockfd, void *addr, int *addrlen);

但返回值是什么呢 ？

是一个new_fd，新的套接字描述符，它代表的是 和客户端的新的连接 。

可以把它理解成是一个客户端的socket(??),这个 socket包含的是客户端的ip和port信息 。（当然这个new_fd会从sockfd中继承 服务器的ip和port信息，两种都有了 ）

而参数中的sockfd包含的是服务器的ip和port信息 。

于是之后的send和recv函数中的fd都是指这个 new_fd，也就是
int send(int new_fd, const void *msg, int len, int flags);
int recv(int new_fd, void *buf, int len, unsigned int flags）;

即参数其实都是目标fd(就是记录了客户端的信息 )，说明服务器是从客户端接收或者发送给客户端的。这个和文件的操作FILE *fp =fopen(); fwrite（fp,xx,xx,xx）;是差不多的，这里的fp代表的也是目标即目标文件名。

而我之前理解成 就是返回一个新的描述符 ，这个描述符还是代表了服务器端，然后客户端和这个新的描述符通信，是为了进程而进程。 这样造成的后果就是，对于 new_fd的port是多少呢 ，搞不清了。如果是和sockfd一样，那还叫新的吗？如果不和sockfd一样，那会是另外一个数字，那怎么解释 http服务器只有一个端口 80呢？


==========================================

这样，客户端的 connect函数 ，
int connect (int sockfd, struct sockaddr *serv_addr, int addrlen);
这里的sockfd 就把客户端的ip和port  ，服务器的ip和port信息都有了。所以之后的 send()，recv()都有信息了。

 

===============================================================

今天网上看到一篇帖子和我说的差不多。原文在http://bbs.pfan.cn/post-270023.html   (问一下关于socket的几个问题)

Q:
accept接受socket的描述符作为参数，之后返回另一个socket描述符，那这两个socket有什么区别和联系？ 假如调用之前的socket绑定在8000端口，那返回之后的socket是不是也绑定在8000端口？一个端口可以绑定几个socket吗?

这个顺便问问, 在shell脚本中，我想用变量存起命令执行后的字串，应该怎么做？

Q: socket看成IP+端口，server的IP x:8000 （应为8080？？by imjacob）是那个在listen的socket做参数传给accept，从这个socket可以得到一些访问它的英特网用户，它们就是那个返回的 socket，比如y:4321（？？by imjacob），然后你可以用其它的线程和这个socket通信，收和发，它代表已经连接的链路。画个图


                   server [ 192.168.1.128 : 8080 ] state: listening



        |            |            |       ......              |
    client1      client2       client3     ......     clientx [ 10.0.1.255 : 1234 ]


一开始是client知道server的IP，或者用DNS解析后的IP，和某种协议固定的端口号，然后发送连接请求，client会一直用那个 socket[ 192.168.1.128 : 8080 ]和server通信（可能协议还会建立其它链路，只一般情况），而server会用 client的IP和某个端口进行通信，那就是accept返回的socket。

我们打电话的时候，都要拿着一头的话筒，那个话筒连接着对方（技术细节忽略），通话的双方都拿着和对方相连的话筒，这两个socket是不同的，都代表着对方。

不是一个端口可以绑定几个socket 就只有一个IP的计算机来说，终端，它可以有很多服务，每一个服务或者进程会使用不同的端口，比如同一个办公楼层不同的房间号码，在应用层，能够通信的对象变成了‘进程’，只考虑进程间的网络通信，而端口就是用来分发给进程用的，OS收到了TCP包，把端口号取出来，再送到相应的进程并通知它进行处理。 accept返回的，收到的socket是对方client的IP+端口号，和你自己的进程占用的端口号不相关，这些端口号是确保你发送的信息会正确的到达对方的机器上的正确的进程中去。