转: 由socket的accept说开去

from: http://ticktick.blog.51cto.com/823160/779866

今天与同学争执一个话题:由于socket的accept函数在有客户端连接的时候产生了新的socket用于服务该客户端,那么,这个新的socket到底有没有占用一个新的端口?

讨论完后,才发现,自己虽然熟悉socket的编程套路,但是却并不是那么清楚socket的原理,今天就趁这个机会,把有关socket编程的几个疑问给搞清楚吧。

先给出一个典型的TCP/IP通信示意图。

问题一:socket结构体对象究竟是怎样定义的?

我们知道,在使用socket编程之前,需要调用socket函数创建一个socket对象,该函数返回该socket对象的描述符。

函数原型:int socket(int domain, int type, int protocol);

那么,这个socket对象究竟是怎么定义的呢?它记录了哪些信息呢?只记录了本机IP及端口、还是目的IP及端口、或者都记录了?

关于这个问题,大家可以在内核源码里面找,也可以参考这篇文章《struct socket 结构详解》,我们可以看到 socket  结构体的定义如下:

struct socket   
{   
    socket_state              state;   
    unsigned long             flags;   
    const struct proto_ops    *ops;   
    struct fasync_struct      *fasync_list;   
    struct file               *file;   
    struct sock               *sk;   
    wait_queue_head_t         wait;   
    short                     type;   
};

其中,struct sock 包含有一个 sock_common 结构体,而sock_common结构体又包含有struct inet_sock 结构体,而struct inet_sock 结构体的部分定义如下:

struct inet_sock   
{   
    struct sock     sk;   
#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)   
    struct ipv6_pinfo   *pinet6;   
#endif   
    __u32           daddr;          //IPv4的目的地址。   
    __u32           rcv_saddr;      //IPv4的本地接收地址。   
    __u16           dport;          //目的端口。   
    __u16           num;            //本地端口(主机字节序)。  
    
    …………      
}

由此,我们清楚了,socket结构体不仅仅记录了本地的IP和端口号,还记录了目的IP和端口。

问题二:connect函数究竟做了些什么操作?

在TCP客户端,首先调用一个socket()函数,得到一个socket描述符socketfd,然后通过connect函数对服务器进行连接,连接成功后,就可以利用这个socketfd描述符使用send/recv函数收发数据了。

关于connect函数和send函数的原型如下:

int connect( int sockfd, const struct sockaddr* server_addr, socklen_t addrlen)  
 
int send( int sockfd, const void *msg,int len,int flags);

那么,现在的困惑是,为什么send函数仅仅传入sockfd就可以知道服务器的ip和端口号?

其实,由“问题一”中的答案我们已经很清楚了,sockfd 描述符所描述的socket对象不仅包含了本地IP和端口,同时也包含了服务器的IP和端口,这样,才能使得send函数只需要传入sockfd 即可知道该把数据发向什么地方。而代码中,目的IP和端口只是在connect函数中出现过,因此,肯定是connect函数在成功建立连接后,将目的IP和端口写入了sockfd 描述符所描述的socket对象中。

问题三: accept函数产生的socket有没有占用新的端口?

首先,回顾一下accept函数,原型如下:

/* 参数:sockfd 监听套接字,即服务器端创建的用于listen的socket描述符。  
 * 参数:addr  这是一个结果参数,它用来接受一个返回值,这返回值指定客户端的地址  
 * 参数:len 描述 addr 的长度  
 */ 
int accept(int sockfd, struct sockaddr* addr, socklen_t* len)

accept函数主要用于服务器端,一般位于listen函数之后,默认会阻塞进程,直到有一个客户请求连接,建立好连接后,它返回的一个新的套接字 socketfd_new ,此后,服务器端即可使用这个新的套接字socketfd_new与该客户端进行通信,而sockfd 则继续用于监听其他客户端的连接请求。

至此,我的困惑产生了,这个新的套接字 socketfd_new 与监听套接字sockfd 是什么关系?它所代表的socket对象包含了哪些信息?socketfd_new 是否占用了新的端口与客户端通信?

先简单分析一番,由于网站的服务器也是一种TCP服务器,使用的是80端口,并不会因客户端的连接而产生新的端口给客户端服务,该客户端依然是向服务器端的80端口发送数据,其他客户端依然向80端口申请连接。因此,可以判断,socketfd_new 并没有占用新的端口与客户端通信,依然使用的是与监听套接字socketfd_new一样的端口号。

那这么说,难道一个端口可以被两个socket对象绑定?当客户端发送数据过来的时候,究竟是与哪一个socket对象通信呢?

我是这么理解的(欢迎拍砖)。

首先,一个端口肯定只能绑定一个socket。我认为,服务器端的端口在bind的时候已经绑定到了监听套接字socetfd所描述的对象上,accept函数新创建的socket对象其实并没有进行端口的占有,而是复制了socetfd的本地IP和端口号,并且记录了连接过来的客户端的IP和端口号。

那么,当客户端发送数据过来的时候,究竟是与哪一个socket对象通信呢?

客户端发送过来的数据可以分为2种,一种是连接请求,一种是已经建立好连接后的数据传输。

由于TCP/IP协议栈是维护着一个接收和发送缓冲区的。在接收到来自客户端的数据包后,服务器端的TCP/IP协议栈应该会做如下处理:如果收到的是请求连接的数据包,则传给监听着连接请求端口的socetfd套接字,进行accept处理;如果是已经建立过连接后的客户端数据包,则将数据放入接收缓冲区。这样,当服务器端需要读取指定客户端的数据时,则可以利用socketfd_new 套接字通过recv或者read函数到缓冲区里面去取指定的数据(因为socketfd_new代表的socket对象记录了客户端IP和端口,因此可以鉴别)。

这就是我对socket编程的一些疑问的理解,有不正确的地方欢迎留言或者来信[email protected]交流。

本文出自 “Jhuster的专栏” 博客,请务必保留此出处http://ticktick.blog.51cto.com/823160/779866

时间: 2024-08-10 19:16:59

转: 由socket的accept说开去的相关文章

从Linux内核升级的必要性说开去

Linux内核更新超级频繁,但是有必要时刻升级吗?个人感觉没有必要,但是你要时刻关注新特性列表,然后把自己的内核升级到离最新版本差一两个月发布的版本而不是最新版本,以保证稳定性,因为一两个月的时间足够多的慧眼会发现足够多的问题,既然自己不是Alan Cox那个梯队的大牛,最好不要在自己的生产版本上使用最新内核,当然,做试验或者Just play例外.       为什么要升级内核?是的,很多人并不同意这种观点,可能他们认为使用内核提供的最持久最稳定的接口就已经足够,多数的定制特性需要自己在用户空

C++学习笔记--从虚函数说开去

虚函数与纯虚函数: 虚函数:在某基类中声明为virtual并在一个或多个派生类中被重新定义的成员函数,virtual  函数返回类型  函数名(参数表){函数体;} ,实现多态性,通过指向派生类的基类指针或引用,访问派生类中同名覆盖成员函数.注意虚函数在基类中是有定义的,即便定义是空. 纯虚函数:在基类中是没有定义的,必须由派生类重定义实现,否则不能由对象进行调用. 看下面的例子: #include<iostream> using namespace std; class Cshape { p

socket执行accept函数时没有进入阻塞状态,而是陷入了无限循环

接着前两天继续看<VC深入详解>的网络编程部分,这次我快速看了遍书上的函数以及套接字C-S模型,然后自己从0开始写了个简单的服务端,结果发现一直在输出 而明明我还没有写客户端程序,由于打印的代码只有一处,在如下的while循环里 while (true) { /* 5. 接收客户端发送的连接请求 */ SOCKET sockConnect = accept(sockServer, (SOCKADDR*)&addrClient, &len); /* 6. [发送/接收]数据 */

从Android Studio 说开去--未来程序员工具的发展方向——版本兼容,以及为什么我们总是要学SB&quot;新&quot;东西

抽时间学习Android. 刚刚下载了 http://developer.android.com/sdk/installing/studio.html#Updating Getting Started with Android Studio 下载安装,很简单. 启动前,先把翻墙的工具准备好,并且开动之. 否则是不行了. 我再牢骚几句啊(我自己要是开公司,门口第一个标语栏就是:大声报怨.一个连抱怨都不会的人,我不信他是一个正常人,更别提创造力了.当然,我招人也只会招参与型的人,只抱怨,但事事弃权,

从贝叶斯定理说开去

从贝叶斯定理说开去 罗朝辉 (http://kesalin.github.io/) CC 许可,转载请署名并保留出处 简介 贝叶斯定理是18世纪英国数学家托马斯·贝叶斯(Thomas Bayes)提出得重要概率论理论.以下摘一段 wikipedia 上的简介: 所谓的贝叶斯定理源于他生前为解决一个"逆概"问题写的一篇文章,而这篇文章是在他死后才由他的一位朋友发表出来的.在贝叶斯写这篇文章之前,人们已经能够计算"正向概率",如"假设袋子里面有 N 个白球,M

【原创】从罗胖子关于开会的议题说开去

从罗胖子关于开会的议题说开去 最近忽然喜欢上了罗胖子,昨天看了他的<罗辑思维>,是关于开会得方面的知识,感觉很有收获,同时也对他推荐的<罗伯特议事规则>挺感兴趣,目前先加在我的书单上,以后有时间一定会拜读. 会议基本流程 因为部门管理原因,比如提高效率,如何开会等,看了好多知识.但对于开会这块,也有些研究,比如会前事先准备.会中设计流程,最后总结概括,会后记录跟踪等等.整个流程下来,当然会比这复杂些,但所有都是流程化,缺少一些生气. 部门月会调整 比如部门月会的调整,以前是四步法,

从数字油田的关键问题说开去

昨天在“智能数字油田开放论坛”上忍不住说了一句“数据元.元数据不是解决数字油田的关键问题”就干活去了,后来发现被袁教授追问了一句“那什么才是数字油田的关键问题?”,经这么一追问,我还真一下子说不出哪些算是关键问题,这两天就根据自己从事的一些工作所掌握的情况来扯上几句. 1.数字油田的关键技术? 虽然以前承担了<数字油气田关键技术研究>863项目中的一个课题工作,但惭愧的是被赶鸭子上架,并没有理清哪些算是关键技术,也没有弄出什么高级理论,几个人整天忙着写材料.汇报.开会.验收.审计,干活的时候找

从支付宝插件无提示导入根证书带来的安全隐患说开去:谈谈HTTPS的加密方式

众所周知在12306购票,官方说明需要导入根证书,这算是良心的了.其实你安装了支付宝插件,就会被不知情的导入了某些[哔]的根证书,而这会带来一些安全隐患:提升遭遇中间人攻击的可能性:在你完全不知情,以为自己还在享受这HTTPS带来的安全保护的情况下,将未加密的信息完全暴露给第三方(比如GFW).而根证书是什么?为什么可能导入一个证书就可能会遭到中间人攻击的?我们从头说开去~ 一.基本概念 加密: 未加密信息:明文x 加密后信息:密文y 明文到密文之间的转换关系:y=f(x),而解密则是x=f -

一线城市与三线城市的IT生活——从《机器灵 砍菜刀》说开去

一线城市与三线城市的IT生活                                                       --从<机器灵 砍菜刀>说开去 最近山东济宁地区的方言神曲<机器灵.砍菜刀>悄悄的在朋友圈里面火了起来,第一次听了就感觉很震撼.后面又仔细听了几遍,20年前的少年回忆仿佛就在眼前,歌曲最后的"有多少人--"更是说出自己的心声.想想自己09年毕业->工作->读研->工作经历,对比本科毕业后与研究生毕业后的工作,