摘要：对于服务器编程中最重要的一步等待并接受客户的连接，那么这一步在编程中如何完成，accept函数就是完成这一步的。它从内核中取出已经建立的客户连接，然后把这个已经建立的连接返回给用户程序，此时用户程序就可以与自己的客户进行点到点的通信了。
accept函数等待并接受客户请求：
#include<sys/socket.h>
int accept(int sockfd, struct sockaddr* addr, socklen_t* len)
返回：非负描述字——成功， -1——失败
accept默认会阻塞进程，直到有一个客户连接建立后返回，它返回的是一个新可用的套接字，这个套接字是连接套接字。此时我们需要区分两种套接字，一种套接字正如accept的参数sockfd，它是监听套接字，在调用listen函数之后，一个套接字会从主动连接的套接字变身为一个监听套接字；而accept返回是一个连接套接字，它代表着一个网络已经存在的点点连接。自然要问的是：为什么要有两种套接字？原因很简单，如果使用一个描述字的话，那么它的功能太多，使得使用很不直观，同时在内核确实产生了一个这样的新的描述字。
参数sockfd
参数sockfd就是上面解释中的监听套接字，这个套接字用来监听一个端口，当有一个客户与服务器连接时，它使用这个一个端口号，而此时这个端口号正与这个套接字关联。当然客户不知道套接字这些细节，它只知道一个地址和一个端口号。
参数addr
这是一个结果参数，它用来接受一个返回值，这返回值指定客户端的地址，当然这个地址是通过某个地址结构来描述的，用户应该知道这一个什么样的地址结构。如果对客户的地址不感兴趣，那么可以把这个值设置为NULL。
参数len
如同大家所认为的，它也是结果的参数，用来接受上述addr的结构的大小的，它指明addr结构所占有的字节个数。同样的，它也可以被设置为NULL。
如果accept成功返回，则服务器与客户已经正确建立连接了，此时服务器通过accept返回的套接字来完成与客户的通信。
这周同学们在做网络编程的时候，碰到一个监听套接字的问题，在这里大概描述一下：
比如我的程序开了一个监听端口，与客户端建立连接之后，生成了一个新套接字。这时我执行了只关闭监听端口的语句，结果却发现监听端口和已建立的连接仍然存在。我都已经关闭了监听套接字，为什么客户端还可以继续往监听端口发信息？这到底是因为什么呢？新套接字和监听套接字有什么关系呢？
比如，你开了80监听端口，有一个客户连接你accept了，这时关闭80端口。但此时客户端发信息的时候必然是发向80断口，但是80已经关了啊，但是通信依然正常进行。其实我刚接触套接字的时候也是认为所有从客户端发来的数据都需要经过监听套接字转一下才能收到。所有的初学者都容易犯这个误解。
经过一段时间的使用，我现在是明白了，监听套接字就是个牵线指路的，你实质上是跟它指的那个人说话。因为你要找的那个人不可能随时等你来，而监听套接字就是专职等你来问，它回答你要找的人在哪，并唤醒你要找的人，于是通话就建立起来了，就像现实生活中的接线员一样。
也就是说，在连接建立后，客户端用发出连接的那个SOCKET向服务器发数据，是发给服务器新创建的SOCKET，而不是服务器的监听SOCKET。服务器的监听SOCKET永远只是用来接受连接请求。
这就好比你去吃饭，饭馆门口有迎宾小姐（监听SOCKET）看到你来后和你打招呼，然后（ACCEPT）找来一个新的服务员（NEW SOCKET）来接待你，然后守在门口继续监听下一个。监听的小姐走了，接待你的服务员当然不受影响。
说到这里有必要说一下accept()函数。以下是《Linux网络编程》一书，第六章 Berkeley套接字对accept()函数的描述：
函数 accept()有一些难懂。当调用它的时候，大致过程是下面这样的：
● 有人从很远很远的地方尝试调用 connect()来连接你的机器上的某个端口（当然是你已经在 listen()的）。
● 他的连接将被 listen 加入等待队列等待 accept()函数的调用（加入等待队列的最多数目由调用 listen()函数的第二个参数 backlog 来决定）。
● 你调用 accept()函数，告诉他你准备连接。
● accept()函数将回返回一个新的套接字描述符，这个描述符就代表了这个连接！
好，这时候你有了两个套接字描述符，返回给你的那个就是和远程计算机的连接，而第一个套接字描述符仍然在你的机器上原来的那个端口上 listen()。
这时候你所得到的那个新的套接字描述符就可以进行 send()操作和recv()操作了。
通过上面的解释，相信您一定已经对监听套接字有了进一步的了解了吧！
accept() 产生的Socekt端口是多少？
为了区分不同应用进程间的网络通信和连接，主要有3个参数：通信的目的IP地址、使用的传输层协议(TCP 或 UDP)和使用的端口号。
Socket的原意是“插座”。通过将这3个参数结合起来，与一个“插座”Socket绑定，应用层就可以和传输层通过套接字接口，区分来自不同应用程序进程或网络连接的通信，实现数据传输的并发服务。
accept()产生的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了——防火墙一定会阻止其通过的！
实际上，我们可以看到，防火墙并没有阻止这样的连接，而且这是最常见的连接请求和处理方式。我不理解的就是，为什么防火墙没有阻止这样的连接？它是如何判断那条连接是因为connect80端口而生成的？是不是TCP数据包里有什么特别的标志？或者防火墙记住了什么东西？
后来，我又仔细研读了TCP/IP的协议栈原理，对很多概念有了更深刻的认识。比如，TCP和UDP同属传输层，共同架设在IP层(网络层)之上。而IP层主要负责的是在节点之间(End to End)的数据包传送，这里的节点是一台网络设备，比如计算机。因为IP层只负责把数据送到节点上，而不能区分上面的不同应用，所以TCP和UDP协议在其基础上加入了端口的信息，端口于是标识的是一个节点上的一个应用。除了增加端口信息，UDP协议基本就没有对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编程接口，所以首先由Socekt层来处理)。所谓的accept函数，其实抽象的是TCP的连接建立过程。accept函数返回的新socket其实指代的是本次创建的连接，而一个连接是包括两部分信息的，一个是源IP和源端口，另一个宿IP和宿端口。这样的话，这些socket宿端口就可以都是80！而同时，防火墙的对IP包的处理规则也是清晰明了，不存在前面设想的种种复杂的情形。
明白socket只是对TCP/IP协议栈操作的抽象，而不是简单的映射关系，这很重要！
昨天和朋友聊了下网络编程，关于Socket，这里写一下我个人的一些理解:)
程序里可以创建Socket，分为普通Socket和原始Socket两种类型。
一：普通Socket是对TCP/IP协议栈中传输层的操作的编程接口(一种API)。
有面向连接的流式套接字(SOCK_STREAM)，属于针对TCP方式的应用；
有无连接数据包式套接字(SOCK_DGRAM)，属于针对UDP方式的应用。
对于普通Socket，我曾经有个模糊的问题，在多线程情况下，服务器端监听(listen)某个端口(假设8080)后，每accept一个客户端的连接就会产生一个新的Socket。那么这些新产生的Socket的端口是什么？程序里肯定没有指定，那就应该有两种可能，1：产生随机端口。2：还是8080端口。第一种假设想了就觉得不可能，防火墙非常有可能会阻止这些随机端口的包。那么就是第二种假设了，服务端端口还是8080。但这推翻了我原有的认识，就是“一个端口被程序占有，其他程序就不能用该端口了”。我觉得其实最有可能的是范围不同：就是在程序与程序间不能用同一端口，但是在程序内部不同的Socket还是可以用同一端口的。所以，为了能够使“客户端发给服务端的同一端口(8080)不同线程(即不同的Socket连接)的包能够被区分开并进行组合”，必须得有一个区分包是来自不同连接的显著特征，那就是传输层包头里的源端口了，即一个Socket连接里客户端那方的端口。总结一下，对于这种情况，就是传输层包头里源端口(客户端)会随着产生的Socket不同，而宿端口相同(服务器端)。
二：原始Socket，建立在网络层上，所以我们可以在传输层上构建自己的协议。
如果是自己做个Sniffer(网络嗅探器)，那么监听到的包是来自同一网段的普通Socket包(TCP方式或UDP方式)，所以在程序里我们要自己写数据结构(IP头和TCP或UDP头)，并绑定数据。
如果是客户端和服务端都是由自己用原始Socket写的，那么可以自己控制协议，像一些网络应用(MSN, skype等)，可以在网络层往上重写协议。
文章出处：http://hi.baidu.com/webeta/blog/item/8d1ffbf2356f9a11b07ec5b9.html
摘要：对于服务器编程中最重要的一步等待并接受客户的连接，那么这一步在编程中如何完成，accept函数就是完成这一步的。它从内核中取出已经建立的客户连接，然后把这个已经建立的连接返回给用户程序，此时用户程序就可以与自己的客户进行点到点的通信了。
accept函数等待并接受客户请求：
#include<sys/socket.h>
int accept(int sockfd, struct sockaddr* addr, socklen_t* len)
返回：非负描述字——成功， -1——失败
accept默认会阻塞进程，直到有一个客户连接建立后返回，它返回的是一个新可用的套接字，这个套接字是连接套接字。此时我们需要区分两种套接字，一种套接字正如accept的参数sockfd，它是监听套接字，在调用listen函数之后，一个套接字会从主动连接的套接字变身为一个监听套接字；而accept返回是一个连接套接字，它代表着一个网络已经存在的点点连接。自然要问的是：为什么要有两种套接字？原因很简单，如果使用一个描述字的话，那么它的功能太多，使得使用很不直观，同时在内核确实产生了一个这样的新的描述字。
参数sockfd
参数sockfd就是上面解释中的监听套接字，这个套接字用来监听一个端口，当有一个客户与服务器连接时，它使用这个一个端口号，而此时这个端口号正与这个套接字关联。当然客户不知道套接字这些细节，它只知道一个地址和一个端口号。
参数addr
这是一个结果参数，它用来接受一个返回值，这返回值指定客户端的地址，当然这个地址是通过某个地址结构来描述的，用户应该知道这一个什么样的地址结构。如果对客户的地址不感兴趣，那么可以把这个值设置为NULL。
参数len
如同大家所认为的，它也是结果的参数，用来接受上述addr的结构的大小的，它指明addr结构所占有的字节个数。同样的，它也可以被设置为NULL。
如果accept成功返回，则服务器与客户已经正确建立连接了，此时服务器通过accept返回的套接字来完成与客户的通信。
这周同学们在做网络编程的时候，碰到一个监听套接字的问题，在这里大概描述一下：
比如我的程序开了一个监听端口，与客户端建立连接之后，生成了一个新套接字。这时我执行了只关闭监听端口的语句，结果却发现监听端口和已建立的连接仍然存在。我都已经关闭了监听套接字，为什么客户端还可以继续往监听端口发信息？这到底是因为什么呢？新套接字和监听套接字有什么关系呢？
比如，你开了80监听端口，有一个客户连接你accept了，这时关闭80端口。但此时客户端发信息的时候必然是发向80断口，但是80已经关了啊，但是通信依然正常进行。其实我刚接触套接字的时候也是认为所有从客户端发来的数据都需要经过监听套接字转一下才能收到。所有的初学者都容易犯这个误解。
经过一段时间的使用，我现在是明白了，监听套接字就是个牵线指路的，你实质上是跟它指的那个人说话。因为你要找的那个人不可能随时等你来，而监听套接字就是专职等你来问，它回答你要找的人在哪，并唤醒你要找的人，于是通话就建立起来了，就像现实生活中的接线员一样。
也就是说，在连接建立后，客户端用发出连接的那个SOCKET向服务器发数据，是发给服务器新创建的SOCKET，而不是服务器的监听SOCKET。服务器的监听SOCKET永远只是用来接受连接请求。
这就好比你去吃饭，饭馆门口有迎宾小姐（监听SOCKET）看到你来后和你打招呼，然后（ACCEPT）找来一个新的服务员（NEW SOCKET）来接待你，然后守在门口继续监听下一个。监听的小姐走了，接待你的服务员当然不受影响。
说到这里有必要说一下accept()函数。以下是《Linux网络编程》一书，第六章 Berkeley套接字对accept()函数的描述：
函数 accept()有一些难懂。当调用它的时候，大致过程是下面这样的：
● 有人从很远很远的地方尝试调用 connect()来连接你的机器上的某个端口（当然是你已经在 listen()的）。
● 他的连接将被 listen 加入等待队列等待 accept()函数的调用（加入等待队列的最多数目由调用 listen()函数的第二个参数 backlog 来决定）。
● 你调用 accept()函数，告诉他你准备连接。
● accept()函数将回返回一个新的套接字描述符，这个描述符就代表了这个连接！
好，这时候你有了两个套接字描述符，返回给你的那个就是和远程计算机的连接，而第一个套接字描述符仍然在你的机器上原来的那个端口上 listen()。
这时候你所得到的那个新的套接字描述符就可以进行 send()操作和recv()操作了。
通过上面的解释，相信您一定已经对监听套接字有了进一步的了解了吧！
accept() 产生的Socekt端口是多少？
为了区分不同应用进程间的网络通信和连接，主要有3个参数：通信的目的IP地址、使用的传输层协议(TCP 或 UDP)和使用的端口号。
Socket的原意是“插座”。通过将这3个参数结合起来，与一个“插座”Socket绑定，应用层就可以和传输层通过套接字接口，区分来自不同应用程序进程或网络连接的通信，实现数据传输的并发服务。
accept()产生的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了——防火墙一定会阻止其通过的！
实际上，我们可以看到，防火墙并没有阻止这样的连接，而且这是最常见的连接请求和处理方式。我不理解的就是，为什么防火墙没有阻止这样的连接？它是如何判断那条连接是因为connect80端口而生成的？是不是TCP数据包里有什么特别的标志？或者防火墙记住了什么东西？
后来，我又仔细研读了TCP/IP的协议栈原理，对很多概念有了更深刻的认识。比如，TCP和UDP同属传输层，共同架设在IP层(网络层)之上。而IP层主要负责的是在节点之间(End to End)的数据包传送，这里的节点是一台网络设备，比如计算机。因为IP层只负责把数据送到节点上，而不能区分上面的不同应用，所以TCP和UDP协议在其基础上加入了端口的信息，端口于是标识的是一个节点上的一个应用。除了增加端口信息，UDP协议基本就没有对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编程接口，所以首先由Socekt层来处理)。所谓的accept函数，其实抽象的是TCP的连接建立过程。accept函数返回的新socket其实指代的是本次创建的连接，而一个连接是包括两部分信息的，一个是源IP和源端口，另一个宿IP和宿端口。这样的话，这些socket宿端口就可以都是80！而同时，防火墙的对IP包的处理规则也是清晰明了，不存在前面设想的种种复杂的情形。
明白socket只是对TCP/IP协议栈操作的抽象，而不是简单的映射关系，这很重要！
昨天和朋友聊了下网络编程，关于Socket，这里写一下我个人的一些理解:)
程序里可以创建Socket，分为普通Socket和原始Socket两种类型。
一：普通Socket是对TCP/IP协议栈中传输层的操作的编程接口(一种API)。
有面向连接的流式套接字(SOCK_STREAM)，属于针对TCP方式的应用；
有无连接数据包式套接字(SOCK_DGRAM)，属于针对UDP方式的应用。
对于普通Socket，我曾经有个模糊的问题，在多线程情况下，服务器端监听(listen)某个端口(假设8080)后，每accept一个客户端的连接就会产生一个新的Socket。那么这些新产生的Socket的端口是什么？程序里肯定没有指定，那就应该有两种可能，1：产生随机端口。2：还是8080端口。第一种假设想了就觉得不可能，防火墙非常有可能会阻止这些随机端口的包。那么就是第二种假设了，服务端端口还是8080。但这推翻了我原有的认识，就是“一个端口被程序占有，其他程序就不能用该端口了”。我觉得其实最有可能的是范围不同：就是在程序与程序间不能用同一端口，但是在程序内部不同的Socket还是可以用同一端口的。所以，为了能够使“客户端发给服务端的同一端口(8080)不同线程(即不同的Socket连接)的包能够被区分开并进行组合”，必须得有一个区分包是来自不同连接的显著特征，那就是传输层包头里的源端口了，即一个Socket连接里客户端那方的端口。总结一下，对于这种情况，就是传输层包头里源端口(客户端)会随着产生的Socket不同，而宿端口相同(服务器端)。
二：原始Socket，建立在网络层上，所以我们可以在传输层上构建自己的协议。
如果是自己做个Sniffer(网络嗅探器)，那么监听到的包是来自同一网段的普通Socket包(TCP方式或UDP方式)，所以在程序里我们要自己写数据结构(IP头和TCP或UDP头)，并绑定数据。
如果是客户端和服务端都是由自己用原始Socket写的，那么可以自己控制协议，像一些网络应用(MSN, skype等)，可以在网络层往上重写协议。
文章出处：http://hi.baidu.com/webeta/blog/item/8d1ffbf2356f9a11b07ec5b9.html
腾讯面试题：tcp三次握手的过程，accept发生在三次握手哪个阶段？
扫一扫
2905
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
